Hi,

Yes, I found your work when I was porting SWCLOS (again). I didn’t start with your code base because I want to keep the original file extension (*.cl) so that one day my changes can be merged back to Seiji’s repository.  But I must have read some of your work and used them in my code base.

LispWorks didn’t crash during my work, I guess that’s because they have fixed related issues because of your bug reports. (Thanks!)

In my porting work, I have used several portable packages (puri, flexi-streams, closer-mop, named-readtables) to fill the gaps between Allegro CL and other platforms. And I consulted with Pascal Costanza for replacing many platform-dependent MOP method definitions into standard MOP calls.  But the core MOP issue is still there:


;;;                                         ........................
;;;                                         :                      :
;;;                                         :                    rdfsClass
;;;                                         :              ...../..:
;;;                                         :              :   /
;;; cl:standard-class -- rdf-node ----------:--------rdfs:Class
;;;                             :...........:

(defclass rdf-node (standard-class) ())

(defmethod sb-pcl:validate-superclass
    ((class rdf-node) (superclass standard-class))
  t)

(defclass rdfsClass (rdf-node) ()
  (:metaclass rdf-node))

(defclass |Class| (rdf-node) ()
  (:metaclass rdfsClass))

;; redefine rdfsClass
(defclass rdfsClass (|Class|) ()
  (:metaclass rdf-node))

Christophe (SBCL maintainer) told me that:

        Well, SBCL's behaviour might not be optimal, but this code is definitely
        not "totally legal": AMOP specifies that "portable metaobject classes
        cannot be redefined”.

I think this problem is solvable: for commercial platforms (LispWorks and Allegro CL) they do support “redefing portable metaobjects”, for open source platforms we have their CLOS source code (therefore it’s possible to do some internal hacks)

Regards,

Chun Tian (binghe)

> Il giorno 08 lug 2017, alle ore 09:45, Fabrice Popineau <fabrice.popineau@supelec.fr> ha scritto:
>
> Hi,
>
> I did this a couple of years ago :
>
> https://github.com/fpopineau/SWCLOS
>
> Seiji was interested at this time in getting the project back on its feet, but he failed to.
> SWCLOS was crashing LispWorks in several ways.
> I had to send 2 bug reports to LispWorks so they fix their CLOS implementation.
> After that, the porting was possible.
>
> Regards,
>
> Fabrice
>
> 2017-07-08 1:12 GMT+02:00 Chun Tian (binghe) <binghe.lisp@gmail.com>:
> Hi,
>
> If you just want to read RDF or RDFS files into LispWorks but do not need any kind of reasoning, there’s another choice called SWCLOS, with this package, in theory you can load everything in a RDF/RDFS/OWL into CLOS classes and instances.
>
>         SWCLOS is an RDF(S) and OWL Full processor built on top of CLOS. Every resources in RDF,
>         e.g., rdfs:Class, rdfs:Resource, rdf:Property, and resource instances and properties
>         are realized as CLOS objects with straightforward-mapping RDFS classes/instances to CLOS
>         classes/instances. Axioms and entailment rules in RDF(S) and OWL are embodied in the system
>         so that a lisp programmer can make ontology in RDF(S) and OWL, and then use the ontology
>         within the semantics specified by RDF(S) documents and OWL documents.
>
> The original author is Seiji Koide from Japan in 2009-2011, running platforms was Allegro CL 9 only.  Last year I spent a month porting it to LispWorks (all versions since 5.0, platform-independent) and Allegro CL 10, the resulting code is on GitHub:
>
>         https://github.com/binghe/SWCLOS
>
> This porting project is not fully finished yet (I plan to finish it in this year, it’s actually my school project), but at this moment it does build correctly in all versions of LispWorks. It doesn’t support other open-source CL platforms yet, because of some necessary but non-standard uses of MOP interfaces and various other small issues.
>
> If you met any issues when using them, I may help resolving them. so please feel free to submit issue tickets to me.
>
> Meanwhile, for Wilbur, I think all its code has been merged and maintained as part of the open-source Racer 2.0 project: (It was a commercial Semantic Web product supported by Franz, Inc.)
>
>         https://github.com/ha-mo-we/Racer
>
> If you compare the core code files of above Racer project with Wilbur:
>
>         https://github.com/lisp/de.setf.wilbur
>
> I believe you’ll see that, each Wilbur file now lives in Racer code base, and they’re fixed and maintained to support almost all major CL platforms, except for SBCL (I remember there’s a complicated macro expansion issue when loading WIlbur into SBCL, as a result the Racer server clearly states that SBCL is outside of the supporting platform list)
>
> Hope this helps,
>
> Chun Tian (binghe)
>
> > Il giorno 07 giu 2017, alle ore 10:50, Gross, Daniel <daniel.gross@intel.com> ha scritto:
> >
> > Hi,
> >
> > I am trying to parse an RDF file into LispWork. I noticed the Wilbur library, which has an quickload installation routine.
> >
> > https://github.com/lisp/de.setf.wilbur/wiki
> >
> >
> > Unfortunately, the installation fails with the following error. Any help in understanding and overcoming this error would be much appreciated.
> >
> > Also, my intent is to import and query RDF files – are there any other open source packages I could use with LispWorks to work with RDFS (and even OWL/OWL2) files.
> >
> > thank you,
> >
> > Daniel
> >
> >
> >
> >
> > Error: COMPILE-FILE-ERROR while compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "wilbur" "packages">
> >    1 (continue) Retry
> >                 compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "wilbur" "packages">.
> >    2 Continue, treating
> >      compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "wilbur" "packages"> as
> >      having been successful.
> >    3 Retry ASDF operation.
> >    4 Retry ASDF operation after resetting the configuration.
> >    5 (abort) Give up on "wilbur"
> >    6 Return to level 1.
> >    7 Return to debug level 1.
> >    8 Give up on "wilbur"
> >    9 Return to level 0.
> >   10 Return to top loop level 0.
> >
> >
> >
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
>
>
>
>
> --
> Fabrice Popineau
> -----------------------------
> SUPELEC
> Département Informatique
> 3, rue Joliot Curie
> 91192 Gif/Yvette Cedex
> Tel direct : +33 (0) 169851950
> Standard : +33 (0) 169851212
> ------------------------------
>