From: Mark E. <ev...@pa...> - 2008-08-11 11:38:47
|
Thanks to Peter for all his work: hope we can make something he will want to use! My interest is in more or less pure ABCL, especially when it comes to patches necessary to use ASDF-INSTALL intelligently. I think someone needs to fix CLOS: I can at least write tests? Looking forward to what sort of directions that Erik has up his sleeves, Mark <ev...@pa...> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2008-08-11 12:27:23
|
> My interest is in more or less pure ABCL, especially when it comes to > patches necessary to use ASDF-INSTALL intelligently. I think someone > needs to fix CLOS: I can at least write tests? Any idea which parts of CLOS work in abcl and which parts don't? Or is it just a performance thing? |
From: Mark E. <ev...@pa...> - 2008-08-11 13:47:53
|
Ville Voutilainen wrote: >> [...]I think someone >> needs to fix CLOS: I can at least write tests? > > Any idea which parts of CLOS work in abcl and which parts don't? Or is it just a > performance thing? I'm a dual SBCL/ABCL user, so I can only report what works on SBCL that doesn't seem to work on ABCL. For most I can (given enough time) generate test cases. An example could be made out of [OCML][1], an implementation of an "Operational Concept Modeling Language", as an ASDF installable process inference engine that works by modifying metaclasses of (possibly) persistent object graphs (don't confuse with OCAML!). [1]: http://kmi-forge.open.ac.uk/gitweb?p=ocml.git;a=summary Things die rather mysteriously in the DEFCLASS macro expansions, which SLIME's client implementation (swank-abcl.lisp) from [2] isn't good enough to take advantage of (like stack traces). I've gotten some work on this committed to the SLIME CVS HEAD, so all current users of ABCL should be able to use SLIME HEAD without issues. If not, I would be interested in test cases that fail. [2]: http://common-lisp.net/project/slime/ yers in the REPL, -- Mark Evenson <ev...@pa...> "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Berlin B. <ber...@gm...> - 2008-08-11 14:17:26
|
On Mon, Aug 11, 2008 at 9:47 AM, Mark Evenson <ev...@pa...> wrote: > Ville Voutilainen wrote: >>> [...]I think someone >>> needs to fix CLOS: I can at least write tests? >> >> Any idea which parts of CLOS work in abcl and which parts don't? Or is it just a >> performance thing? > > I'm a dual SBCL/ABCL user, so I can only report what works on SBCL that > doesn't seem to work on ABCL. For most I can (given enough time) > generate test cases. > > An example could be made out of [OCML][1], an implementation of an > "Operational Concept Modeling Language", as an ASDF installable process > inference engine that works by modifying metaclasses of (possibly) > persistent object graphs (don't confuse with OCAML!). > > [1]: http://kmi-forge.open.ac.uk/gitweb?p=ocml.git;a=summary > > Things die rather mysteriously in the DEFCLASS macro expansions, which > SLIME's client implementation (swank-abcl.lisp) from [2] isn't good > enough to take advantage of (like stack traces). I've gotten some work > on this committed to the SLIME CVS HEAD, so all current users of ABCL > should be able to use SLIME HEAD without issues. If not, I would be > interested in test cases that fail. > > [2]: http://common-lisp.net/project/slime/ > > > yers in the REPL, > > -- > Mark Evenson <ev...@pa...> > > "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 the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > Me too. I have been quietly following ABCL over the years and wishing for activity. -- Berlin Brown http://ghostbots.com/botlist/spring/help/about.html |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-11 17:34:54
|
On Mon, Aug 11, 2008 at 2:27 PM, Ville Voutilainen <vil...@gm...> wrote: >> My interest is in more or less pure ABCL, especially when it comes to >> patches necessary to use ASDF-INSTALL intelligently. I think someone >> needs to fix CLOS: I can at least write tests? > > Any idea which parts of CLOS work in abcl and which parts don't? Or is it just a > performance thing? I believe that the part which is actually implemented is said to be slow (and consing), whereas there are parts of the MOP which are not implemented at all. It would be nice to identify which parts those are and which options there are to get the consing out of the GF invocation protocol - hopefully speeding it up. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-11 17:57:35
|
On Mon, Aug 11, 2008 at 8:34 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > I believe that the part which is actually implemented is said to be > slow (and consing), whereas there are parts of the MOP which are not > implemented at all. So the normal class stuff, (multiple) inheritance, :around, :before, :after, multimethods etc. basic stuff should be ok? I'll need to check out the cvs version and play with it a little.. For MOP, I cannot help much. I'm about to get some books on the subject but it'll probably take months before I can even hope to understand what's going on there. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-11 18:09:42
|
On Mon, Aug 11, 2008 at 7:57 PM, Ville Voutilainen <vil...@gm...> wrote: > On Mon, Aug 11, 2008 at 8:34 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> I believe that the part which is actually implemented is said to be >> slow (and consing), whereas there are parts of the MOP which are not >> implemented at all. > > So the normal class stuff, (multiple) inheritance, :around, :before, > :after, multimethods > etc. basic stuff should be ok? I'll need to check out the cvs version and play > with it a little.. A quick test: (defgeneric q (v)) (defmethod q :around (b) b) (defmethod q (b) 1) (q t) -> T Means that around methods at least seem to work as expected. The only issue I have is that it takes ABCL quite a bit of time to process its first defgeneric. After that, most of it is quite speedy. > For MOP, I cannot help much. I'm about to get some books on the subject but > it'll probably take months before I can even hope to understand what's going on > there. Well, you never know :-) It may be open doors from day one! Obviously, not all of it is, but I must say I was surprised to see how much MOP made CLOS "just a program" instead of a set of primitives. Bye, Erik. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-14 15:35:28
|
On Wed, Aug 13, 2008 at 4:24 AM, Blake McBride <bl...@mc...> wrote: > > Meta classes don't seem to work in ABCL. For example: > > CL-USER(1): (defclass meta-class1 (standard-class) (cv1 cv2 cv3) (:metaclass > standard-class)) > #<STANDARD-CLASS META-CLASS1 {75A744}> > CL-USER(2): (defclass class1 (standard-object) (iv1 iv2 iv3) (:metaclass > meta-class1)) > #<STANDARD-CLASS CLASS1 {4134E0}> > CL-USER(3): > > The second return should have been: > #<META-CLASS1 CLASS1 {4134E0}> > > I think ABCL is ignoring the :metaclass option. Without the :metaclass > option ABCL CLOS is very weak. Right. When trying to run the ansi tests, it turned out that the long form of DEFINE-METHOD-COMBINATION is also not implemented. That should probably be considered a weak spot too. Bye, Erik. |