gmane.editors.j.devel

Mark Evenson | 11 Aug 13:35

New maintainer structure for ABCL

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 <evenson <at> panix.com>

--
"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=/

headers

Ville Voutilainen | 11 Aug 14:27

Re: New maintainer structure for ABCL

> 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?

-------------------------------------------------------------------------
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=/

headers

Mark Evenson | 11 Aug 15:47

Re: New maintainer structure for ABCL

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,

--

--

(Continue reading)

headers

Berlin Brown | 11 Aug 16:17

Re: New maintainer structure for ABCL

On Mon, Aug 11, 2008 at 9:47 AM, Mark Evenson <evenson <at> panix.com> 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,

(Continue reading)

headers

Erik Huelsmann | 11 Aug 19:34

Re: New maintainer structure for ABCL

On Mon, Aug 11, 2008 at 2:27 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> 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.

-------------------------------------------------------------------------
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=/

headers

Ville Voutilainen | 11 Aug 19:57

Re: New maintainer structure for ABCL

On Mon, Aug 11, 2008 at 8:34 PM, Erik Huelsmann <ehuels <at> gmail.com> 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.

-------------------------------------------------------------------------
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=/

headers

Erik Huelsmann | 11 Aug 20:09

Re: New maintainer structure for ABCL

On Mon, Aug 11, 2008 at 7:57 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> wrote:
> On Mon, Aug 11, 2008 at 8:34 PM, Erik Huelsmann <ehuels <at> gmail.com> 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.

(Continue reading)