From: Blake M. <bl...@mc...> - 2008-08-01 01:25:58
|
Running the code: (defclass meta-class1 (standard-class) (cv1 cv2 cv3) (:metaclass standard-class)) (defclass class1 (standard-object) (iv1 iv2 iv3) (:metaclass meta-class1)) The second object returns: #<STANDARD-CLASS CLASS1 {F673CC}> > It should be: #<META-CLASS1 CLASS1 {F673CC}> > Not only is it reporting the wrong class of class1 but it doesn't work either. I suppose ABCL doesn't support the :metaclass option. It just ignores it. The problem is that without that option ABCL's CLOS is severely limited. Any plans to fix this? Thanks. Blake McBride |
From: Blake M. <bl...@mc...> - 2009-01-15 15:57:52
|
I just wanted to renew this report. I tested it and it still doesn't work. I think this is kind of a big issue with respect to CLOS. Thanks. Blake McBride On Thu, Jul 31, 2008 at 7:26 PM, Blake McBride <bl...@mc...> wrote: > > Running the code: > > > (defclass meta-class1 (standard-class) > (cv1 cv2 cv3) > (:metaclass standard-class)) > > (defclass class1 (standard-object) > (iv1 iv2 iv3) > (:metaclass meta-class1)) > > The second object returns: > >> #<STANDARD-CLASS CLASS1 {F673CC}> > > It should be: > >> #<META-CLASS1 CLASS1 {F673CC}> > > Not only is it reporting the wrong class of class1 but it doesn't work > either. I suppose ABCL doesn't support the :metaclass option. It just > ignores it. The problem is that without that option ABCL's CLOS is severely > limited. Any plans to fix this? > > Thanks. > > Blake McBride > > |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-16 20:00:50
|
Hi, Blake You're right: ABCL doesn't support the :metaclass option and it just ignores it. ABCL's MOP implementation (clos.lisp) is claimed that "based on Closette", it's true, but after comparing clos.lisp with the original Closette implementation in AMOP Book, I found the two have quite big differences. You may know that: DEFCLASS is actually a macro, any DEFCLASS form will be convert a call to ENSURE-CLASS first: CL-USER(1): (defclass a-meta-class (standard-class) ()) #<STANDARD-CLASS A-META-CLASS {51E77418}> CL-USER(2): (macroexpand-1 '(defclass a-class () () (:metaclass a-meta- class))) (SYSTEM:ENSURE-CLASS (QUOTE A-CLASS) :DIRECT-SUPERCLASSES (SYSTEM:CANONICALIZE-DIRECT- SUPERCLASSES (QUOTE NIL)) :DIRECT-SLOTS (LIST) :METACLASS (FIND-CLASS (QUOTE A-META-CLASS))) T After reading ABCL's ENSURE-CLASS (start line 539 in clos.lisp), I'm quite sure that ENSURE-CLASS just ignore it and every new instances created is based on (find-class 'standard-class), following is the beginning of ABCL's ENSURE-CLASS: (defun ensure-class (name &rest all-keys &allow-other-keys) The ENSURE-CLASS of AMOP Closette have additional keyword argument, METACLASS: (defun ensure-class (name &rest all-keys &key (metaclass the-class-standard-class) &allow-other-keys) I'll try to solve this issue in following weekend but cannot make any guarantee, I'm just MOP newbie. On 2009-1-15, at 23:57, Blake McBride wrote: > I just wanted to renew this report. I tested it and it still doesn't > work. I think this is kind of a big issue with respect to CLOS. > > Thanks. > > Blake McBride > > > On Thu, Jul 31, 2008 at 7:26 PM, Blake McBride <bl...@mc...> > wrote: >> >> Running the code: >> >> >> (defclass meta-class1 (standard-class) >> (cv1 cv2 cv3) >> (:metaclass standard-class)) >> >> (defclass class1 (standard-object) >> (iv1 iv2 iv3) >> (:metaclass meta-class1)) >> >> The second object returns: >> >>> #<STANDARD-CLASS CLASS1 {F673CC}> >> >> It should be: >> >>> #<META-CLASS1 CLASS1 {F673CC}> >> >> Not only is it reporting the wrong class of class1 but it doesn't >> work >> either. I suppose ABCL doesn't support the :metaclass option. It >> just >> ignores it. The problem is that without that option ABCL's CLOS is >> severely >> limited. Any plans to fix this? >> >> Thanks. >> >> Blake McBride >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- Chun Tian (binghe) NetEase.com, Inc. P. R. China |
From: Blake M. <bl...@mc...> - 2009-01-16 20:39:26
|
Thanks, Chun. I have a framework that depends on being able to determine a class' metaclass. When you get it working I'll test it with the framework right away. Thanks again. Blake McBride On Fri, Jan 16, 2009 at 2:00 PM, Chun Tian (binghe) <bin...@gm...> wrote: > Hi, Blake > > You're right: ABCL doesn't support the :metaclass option and it just ignores > it. ABCL's MOP implementation (clos.lisp) is claimed that "based on > Closette", it's true, but after comparing clos.lisp with the original > Closette implementation in AMOP Book, I found the two have quite big > differences. > > You may know that: DEFCLASS is actually a macro, any DEFCLASS form will be > convert a call to ENSURE-CLASS first: > > CL-USER(1): (defclass a-meta-class (standard-class) ()) > #<STANDARD-CLASS A-META-CLASS {51E77418}> > CL-USER(2): (macroexpand-1 '(defclass a-class () () (:metaclass > a-meta-class))) > (SYSTEM:ENSURE-CLASS (QUOTE A-CLASS) > :DIRECT-SUPERCLASSES > (SYSTEM:CANONICALIZE-DIRECT-SUPERCLASSES (QUOTE NIL)) > :DIRECT-SLOTS (LIST) > :METACLASS (FIND-CLASS (QUOTE A-META-CLASS))) > T > > After reading ABCL's ENSURE-CLASS (start line 539 in clos.lisp), I'm quite > sure that ENSURE-CLASS just ignore it and every new instances created is > based on (find-class 'standard-class), following is the beginning of ABCL's > ENSURE-CLASS: > > (defun ensure-class (name &rest all-keys &allow-other-keys) > > The ENSURE-CLASS of AMOP Closette have additional keyword argument, > METACLASS: > > (defun ensure-class (name &rest all-keys > &key (metaclass the-class-standard-class) > &allow-other-keys) > > I'll try to solve this issue in following weekend but cannot make any > guarantee, I'm just MOP newbie. > > On 2009-1-15, at 23:57, Blake McBride wrote: > >> I just wanted to renew this report. I tested it and it still doesn't >> work. I think this is kind of a big issue with respect to CLOS. >> >> Thanks. >> >> Blake McBride >> >> >> On Thu, Jul 31, 2008 at 7:26 PM, Blake McBride <bl...@mc...> wrote: >>> >>> Running the code: >>> >>> >>> (defclass meta-class1 (standard-class) >>> (cv1 cv2 cv3) >>> (:metaclass standard-class)) >>> >>> (defclass class1 (standard-object) >>> (iv1 iv2 iv3) >>> (:metaclass meta-class1)) >>> >>> The second object returns: >>> >>>> #<STANDARD-CLASS CLASS1 {F673CC}> >>> >>> It should be: >>> >>>> #<META-CLASS1 CLASS1 {F673CC}> >>> >>> Not only is it reporting the wrong class of class1 but it doesn't work >>> either. I suppose ABCL doesn't support the :metaclass option. It just >>> ignores it. The problem is that without that option ABCL's CLOS is >>> severely >>> limited. Any plans to fix this? >>> >>> Thanks. >>> >>> Blake McBride >>> >>> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> armedbear-j-devel mailing list >> arm...@li... >> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > > -- > Chun Tian (binghe) > NetEase.com, Inc. > P. R. China > > |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-19 11:15:15
Attachments:
mop.diff
|
Hi, Blake I think I cannot fix it, it's obvious not bug, but a feature (no MOP) ... I'll explained by following words: At first, I made a patch on clos.lisp and print-object.lisp, which fixed two things: 1) Let ENSURE-CLASS really use the :METACLASS option 2) Make (PRINT-OBJECT CLASS) handle correctly on classes with no name, i.e. (make-instance 'standard-class) The 2) is very important, or I cannot see any backtrace. Then I can try this: CL-USER(1): (defclass m-class (standard-class) ()) #<STANDARD-CLASS M-CLASS {7CCF6}> CL-USER(2): (defclass a-class () () (:metaclass m-class)) Debugger invoked on condition of type TYPE-ERROR: The value #<M-CLASS NIL {515979}> is not of type CLASS. Restarts: 0: TOP-LEVEL Return to top level. See, the #<M-CLASS NIL {515979}> is just what we want! But see the backtrace: [1] CL-USER(5): :bt 0: (BACKTRACE-AS-LIST) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {717334}>) 2: (SYSTEM:%SET-CLASS-DIRECT-SUPERCLASSES #<M-CLASS NIL {515979}> (#<STANDARD-CLASS STANDARD-OBJECT {ACCD65}>)) 3: (MOP::STD-AFTER-INITIALIZATION-FOR-CLASSES #<M-CLASS NIL {515979}> :NAME A-CLASS :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL :METACLASS #<STANDARD-CLASS M-CLASS {7CCF6}>) 4: (APPLY #<FUNCTION MOP::STD-AFTER-INITIALIZATION-FOR-CLASSES {912A56}> #<M-CLASS NIL {515979}> (:NAME A-CLASS :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL :METACLASS #<STANDARD-CLASS M-CLASS {7CCF6}>)) 5: (#<FUNCTION (LAMBDA (CLASS &REST MOP::ARGS)) {8BEA70}> #<M-CLASS NIL {515979}> :NAME A-CLASS :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL :METACLASS #<STANDARD-CLASS M-CLASS {7CCF6}>) 6: (APPLY #<FUNCTION (LAMBDA (CLASS &REST MOP::ARGS)) {8BEA70}> (#<M-CLASS NIL {515979}> :NAME A-CLASS :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL :METACLASS #<STANDARD-CLASS M-CLASS {7CCF6}>)) 7: (#<FUNCTION (LAMBDA (MOP::ARGS)) {CCA07B}> (#<M-CLASS NIL {515979}> :NAME A-CLASS :DIRECT-SUPERCLASSES NIL :DIRECT-SLOTS NIL :METACLASS #<STANDARD-CLASS M-CLASS {7CCF6}>)) It failed on SYSTEM:%SET-CLASS-DIRECT-SUPERCLASSES, which is a function defined on Java-side: (Primitives.java) // ### %set-class-direct-superclasses private static final Primitive _SET_CLASS_DIRECT_SUPERCLASSES = new Primitive("%set-class-direct-superclasses", PACKAGE_SYS, true) { @Override public LispObject execute(LispObject first, LispObject second) throws ConditionThrowable { try { ((LispClass)first).setDirectSuperclasses(second); ///// HERE !!!!! return second; } catch (ClassCastException e) { return type_error(first, Symbol.CLASS); } } }; The problem is that the "LispObject first" argument cannot be downcasted into LispClass instance, because it's a StandardObject, which is the superclass of LispClass. I don't know if I can make you understand the core of this issue, my English is not good: A DEFCLASS form with :METACLASS option will actually call MAKE- INSTANCE on the metaclass. MAKE-INSTANCE will first call STD-ALLOCATE- INSTANCE to get a StandardObject (with no class-related slots!), then the finalize step (set the direct-superclasses, direct-subclasses slots) failed ... The most interesting part of MOP is that the STANDARD-CLASS itself is just defined by DEFCLASS, just like other class definition: (though some bootstrap issue need to be solved) (defclass standard-class () ((name :initarg :name) (direct-superclasses :initarg :direct-superclasses) (direct-slots) (class-precedence-list) (effective-slots) (direct-subclasses :initform ()) (direct-methods :initform ()))) A MetaClass is essential trying to extend above definition by adding more slots (The basic way to use MOP). But in ABCL, above DEFCLASS definition does NOT exist, just a built-in Java class (StandardClass) there. So there's NO way to extend it by lisp code. I think ABCL's CLOS implementation is terrible, it shouldn't be done by Java-side work. If I had more time in rest of this year, I think I can make it better: first remove all CLOS code from ABCL, and build the full-featured PCL (Portable CommonLoops, used by CMUCL and SBCL) on an "raw" (- ABCL CLOS). So, sorry. I failed. |
From: Philip H. <phi...@in...> - 2009-01-19 14:34:39
|
On 19 Jan, 2009, at 11:14 am, Chun Tian (binghe) wrote: > I think ABCL's CLOS implementation ... shouldn't be done by Java- > side work. +1 -- Phil Hudson PGP/GnuPG ID: 0x887DCA63 |
From: Alessio S. <ale...@gm...> - 2009-01-19 14:41:14
|
On Mon, Jan 19, 2009 at 3:34 PM, Philip Hudson <phi...@in...> wrote: > On 19 Jan, 2009, at 11:14 am, Chun Tian (binghe) wrote: > >> I think ABCL's CLOS implementation ... shouldn't be done by Java- >> side work. > > > +1 I'm not very convinced about this. I think some sort of Java integration can provide some benefits (i.e. as I said tight integration between CLOS and the Java object system). I'm not saying that ABCL's CLOS should be written entirely/mostly in Java, but the lower-level building blocks (let's say the minimal object system implementation needed to bootstrap CLOS, where it makes sense) could imho be written in Java. Just my €.02... Alessio |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-19 16:42:47
|
On 2009-1-19, at 22:41, Alessio Stalla wrote: > I'm not very convinced about this. I think some sort of Java > integration can provide some benefits (i.e. as I said tight > integration between CLOS and the Java object system). I'm not saying > that ABCL's CLOS should be written entirely/mostly in Java, but the > lower-level building blocks (let's say the minimal object system > implementation needed to bootstrap CLOS, where it makes sense) could > imho be written in Java. Below is just a brain-storm ... The standard CLOS class hierarchy is a bit like this: T |- STANDARD-OBJECT | |- STANDARD-CLASS (classes served as other class' :metaclass) | `- other classes (defined by DEFCLASS with superclass not under STANDARD-CLASS) | |- STRUCTURE-OBJECT (objects defined by DEFSTRUCT) | |- NUMBER |- SYMBOL |- ARRAY |- ... But since ABCL is a pure-java CL implementation, I think we can easily add a new class called "JAVA-OBJECT": T |- STANDARD-OBJECT |- STRUCTURE-OBJECT |- ... |- JAVA-OBJECT JAVA-OBJECT and its every subclasses should have a fixed metaclass "JAVA-CLASS", I don't know if there can be a MOP to extend it by defining subclass of JAVA-CLASS, but we can just leave it for the future. The JAVA-OBJECT class is just mapped to Java's Object class, all other Java class should be its subclass. The whole JAVA-OBEJCT hierarchy and language mapping should be obviously written mainly in Java, and it can be integrated into PCL, if we really do it. Is that a good design? |
From: Alessio S. <ale...@gm...> - 2009-01-19 17:14:13
|
On Mon, Jan 19, 2009 at 5:42 PM, Chun Tian (binghe) <bin...@gm...> wrote: > > On 2009-1-19, at 22:41, Alessio Stalla wrote: > >> I'm not very convinced about this. I think some sort of Java >> integration can provide some benefits (i.e. as I said tight >> integration between CLOS and the Java object system). I'm not saying >> that ABCL's CLOS should be written entirely/mostly in Java, but the >> lower-level building blocks (let's say the minimal object system >> implementation needed to bootstrap CLOS, where it makes sense) could >> imho be written in Java. > > Below is just a brain-storm ... > > The standard CLOS class hierarchy is a bit like this: > > T > |- STANDARD-OBJECT > | |- STANDARD-CLASS (classes served as other class' :metaclass) > | `- other classes (defined by DEFCLASS with superclass not under > STANDARD-CLASS) > | > |- STRUCTURE-OBJECT (objects defined by DEFSTRUCT) > | > |- NUMBER > |- SYMBOL > |- ARRAY > |- ... > > But since ABCL is a pure-java CL implementation, I think we can easily add a > new class called "JAVA-OBJECT": > > T > |- STANDARD-OBJECT > |- STRUCTURE-OBJECT > |- ... > |- JAVA-OBJECT > > JAVA-OBJECT and its every subclasses should have a fixed metaclass > "JAVA-CLASS", I don't know if there can be a MOP to extend it by defining > subclass of JAVA-CLASS, but we can just leave it for the future. > > The JAVA-OBJECT class is just mapped to Java's Object class, all other Java > class should be its subclass. The whole JAVA-OBEJCT hierarchy and language > mapping should be obviously written mainly in Java, and it can be integrated > into PCL, if we really do it. > > Is that a good design? > Well... that's more or less the current design in the scripting branch so, I hope it's good enough ;) As for integrating them with PCL, I don't know PCL so I can't estimate how hard would it be, but probably not very hard since JAVA-OBJECT - JAVA-CLASS are actually pretty simple and separate from the rest (as you have correctly noted). Of course, a well functioning CLOS + MOP is more important than Java integration which is just an extra... but if such an integration is easy to achieve with PCL, I'll be happy to contribute it. Ale |
From: Ville V. <vil...@gm...> - 2009-01-19 17:26:18
|
On Mon, Jan 19, 2009 at 7:14 PM, Alessio Stalla <ale...@gm...> wrote: > Of course, a well functioning CLOS + MOP is more important than Java > integration which is just an extra... but if such an integration is > easy to achieve with PCL, I'll be happy to contribute it. Well, since that's probably a 30k change, would it be prudent to create a branch for it? Erik? |
From: Mark E. <ev...@pa...> - 2009-01-19 12:43:14
|
Chun Tian (binghe) wrote: […] > So, sorry. I failed. I consider your detailed analysis quite useful. Your analysis of the current state of CLOS gives a clear symptoms (ABCL's CLOS misses common usages patterns by a quite a bit), diagnosis (ABCL roots its class defintions in Java rather than Lisp), and prescription (re-implement from PCL) gives us a clear directions for fixing CLOS. Thanks for your work! -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Alessio S. <ale...@gm...> - 2009-01-19 13:36:42
|
For what is worth (probably little), I add that in the 'scripting' branch I have added a new kind of (limited) metaclass which maps Java classes on CLOS classes. (limited in the sense that e.g. afaik it cannot be used to instantiate new CLOS objects but only to specialize methods on Java classes, which was my objective). It's mostly Java code, so probably of little help for the OP, but I found that adding a new metaclass type besides standard-class is not that hard and so probably a generic user-defined metaclass could be provided with relatively little effort. hth, Alessio On Mon, Jan 19, 2009 at 1:43 PM, Mark Evenson <ev...@pa...> wrote: > Chun Tian (binghe) wrote: > > […] > >> So, sorry. I failed. > > I consider your detailed analysis quite useful. Your analysis of the > current state of CLOS gives a clear symptoms (ABCL's CLOS misses common > usages patterns by a quite a bit), diagnosis (ABCL roots its class > defintions in Java rather than Lisp), and prescription (re-implement > from PCL) gives us a clear directions for fixing CLOS. > > Thanks for your work! > > > -- > "A screaming comes across the sky. It has happened before, but there is > nothing to compare to it now." > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-19 14:09:07
|
Hi, Thanks for your kindly words, so my passed two days didn't waste:) (I only start to read ABCL code from last Friday) I myself have a SNMP project which should be able to run a SNMP thread on any CL implementations for monitor and management uses. ABCL is quite useful for me: I think if I can run my project on ABCL, I just can run a SNMP server thread with any JVM-base applicaions -- just let abcl.jar run with other jars, say, a Tomcat. That will beat all other "SNMP for Java" solutions... I hope I can do more for ABCL in the future, but I need finish projects on my hand first. On 2009-1-19, at 20:43, Mark Evenson wrote: > Chun Tian (binghe) wrote: > > […] > >> So, sorry. I failed. > > I consider your detailed analysis quite useful. Your analysis of > the current state of CLOS gives a clear symptoms (ABCL's CLOS misses > common usages patterns by a quite a bit), diagnosis (ABCL roots its > class defintions in Java rather than Lisp), and prescription (re- > implement from PCL) gives us a clear directions for fixing CLOS. > > Thanks for your work! > > > -- > "A screaming comes across the sky. It has happened before, but > there is > nothing to compare to it now." -- Chun Tian (binghe) NetEase.com, Inc. P. R. China |
From: Ville V. <vil...@gm...> - 2009-01-19 14:57:15
|
On Mon, Jan 19, 2009 at 4:41 PM, Alessio Stalla <ale...@gm...> wrote: >>> I think ABCL's CLOS implementation ... shouldn't be done by Java- >>> side work. > I'm not very convinced about this. I think some sort of Java > integration can provide some benefits (i.e. as I said tight > integration between CLOS and the Java object system). I'm not saying > that ABCL's CLOS should be written entirely/mostly in Java, but the > lower-level building blocks (let's say the minimal object system > implementation needed to bootstrap CLOS, where it makes sense) could > imho be written in Java. Well, if PCL drops into place easily, it's a bit hard to come up with arguments against it, since it allows us to avoid writing AMOP from scratch. I have no idea what PCL requires, so this remains to be seen. A complete rewrite of abcl CLOS from the ground up is likely months away and that's optimistic. The idea of using PCL sounds a bit more attractive on the surface. |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-19 16:17:53
|
Hi, Ville The latest PCL source code by Xerox PARC can still be downloaded at ftp://ftp.parc.xerox.com/pub/pcl/September-16-92-PCL-f.tar.Z First look it's quite big, 36314 lines (which almost as big as the whole ABCL's lisp code), though big part of them are implementation- specific. The SBCL's "src/pcl" directory has only 20841 lines which also include a Gray Stream implementation which isn't part of original PCL. Generally speaking, PCL requires nothing. It just use CL structs to hold CLOS instances (by default), and provide other ways to store instances through MOP interface. If ABCL's low-level part is well, that is, features like DEFUN, DEFSTRUCT, LAMBDA ... all works as respect, then run PCL in ABCL should be possible. On 2009-1-19, at 22:57, Ville Voutilainen wrote: > On Mon, Jan 19, 2009 at 4:41 PM, Alessio Stalla <ale...@gm... > > wrote: >>>> I think ABCL's CLOS implementation ... shouldn't be done by Java- >>>> side work. >> I'm not very convinced about this. I think some sort of Java >> integration can provide some benefits (i.e. as I said tight >> integration between CLOS and the Java object system). I'm not saying >> that ABCL's CLOS should be written entirely/mostly in Java, but the >> lower-level building blocks (let's say the minimal object system >> implementation needed to bootstrap CLOS, where it makes sense) could >> imho be written in Java. > > Well, if PCL drops into place easily, it's a bit hard to come up > with arguments > against it, since it allows us to avoid writing AMOP from scratch. I > have no idea > what PCL requires, so this remains to be seen. A complete rewrite of > abcl CLOS > from the ground up is likely months away and that's optimistic. The > idea of > using PCL sounds a bit more attractive on the surface. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- Chun Tian (binghe) NetEase.com, Inc. P. R. China |
From: Mark E. <ev...@pa...> - 2009-01-19 18:46:48
|
Ville Voutilainen wrote: > On Mon, Jan 19, 2009 at 7:14 PM, Alessio Stalla <ale...@gm...> wrote: >> Of course, a well functioning CLOS + MOP is more important than Java >> integration which is just an extra... but if such an integration is >> easy to achieve with PCL, I'll be happy to contribute it. > > Well, since that's probably a 30k change, would it be prudent to create a branch > for it? Erik? The branch is a fine proposal, but we first should have someone who wants to do the work. Shouldn't we get the 'scripting' branches non-JDK 6 changes over to the main branch before we try to integrate CLOS? My [development snapshots on googlecode][1] have a proposed integration failing 51 of the interpreted GCL ANSI tests, but I haven't really had the time to sort out what is failing because of what. [1]: http://code.google.com/p/abcl-dynamic-install/wiki/abclXXX0XXX12XXX30XXXtestXXXansi -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2009-01-19 19:07:11
|
On Mon, Jan 19, 2009 at 8:46 PM, Mark Evenson <ev...@pa...> wrote: >> On Mon, Jan 19, 2009 at 7:14 PM, Alessio Stalla <ale...@gm...> wrote: >>> Of course, a well functioning CLOS + MOP is more important than Java >>> integration which is just an extra... but if such an integration is >>> easy to achieve with PCL, I'll be happy to contribute it. >> Well, since that's probably a 30k change, would it be prudent to create a branch >> for it? Erik? > The branch is a fine proposal, but we first should have someone who > wants to do the work. Oh, pardon me, I thought Alessio was talking about the PCL adoption, silly me. :) Volunteers? > Shouldn't we get the 'scripting' branches non-JDK 6 changes over to the > main branch before we try to integrate CLOS? My [development snapshots I'm imagining that the scripting branch will be merged much before PCL. Hence the idea of having a separate branch for it. I don't think the scripting branch has that much overlap with that kind of big CLOS work, and as Alessio said, should changes be necessary, they're likely not hard to fix-up when the PCL stuff merges. Having said that, we're in no hurry with the PCL merge, so we can do the scripting branch merge first and then reconsider the idea of using PCL as our CLOS implementation. |
From: Alessio S. <ale...@gm...> - 2009-01-19 20:34:52
|
On Mon, Jan 19, 2009 at 8:07 PM, Ville Voutilainen <vil...@gm...> wrote: > On Mon, Jan 19, 2009 at 8:46 PM, Mark Evenson <ev...@pa...> wrote: >>> On Mon, Jan 19, 2009 at 7:14 PM, Alessio Stalla <ale...@gm...> wrote: >>>> Of course, a well functioning CLOS + MOP is more important than Java >>>> integration which is just an extra... but if such an integration is >>>> easy to achieve with PCL, I'll be happy to contribute it. >>> Well, since that's probably a 30k change, would it be prudent to create a branch >>> for it? Erik? >> The branch is a fine proposal, but we first should have someone who >> wants to do the work. > > Oh, pardon me, I thought Alessio was talking about the PCL adoption, > silly me. :) > Volunteers? Hehe, I'd be happy to do it if I had the time, surely my knowledge of CLOS would greatly benefit... but who knows, I might be able to lend an hand (but not soon unfortunately). >> Shouldn't we get the 'scripting' branches non-JDK 6 changes over to the >> main branch before we try to integrate CLOS? My [development snapshots > > I'm imagining that the scripting branch will be merged much before PCL. Hence > the idea of having a separate branch for it. I don't think the scripting branch > has that much overlap with that kind of big CLOS work, and as Alessio said, > should changes be necessary, they're likely not hard to fix-up when the > PCL stuff merges. Looking at logicmoo's last patch (I haven't forgotten you ;), it seems that the scripting branch has not much overlap with the whole of ABCL, let alone CLOS. That's fine as it was amongst my objectives, however as time passes the differences from the branch and trunk will likely increase. So the next thing I'll try to do is to estimate the amount of changes the merge would require. If that turns out to be not too frightening, and if there's will to do it, I can take the time to do it myself. (the integration with both build systems seems to me to be the most uncertain part). bye, Alessio |