On Jan 3, 2012, at 11:36, Mark Evenson wrote:

On Jan 3, 2012, at 12:45 AM, Rudolf Schlatte wrote:

...

Hi,

These two patches add the metaobject and specializer classes (ref. Table 5.1 in AMOP). They are at the proper place in the class hierarchy as far as possible -- there are some structures that should be classes (eql-specializer, method-combination) and [standard-]generic-function still have the wrong metaclass and superclasses.

Unfortunately, after applying these patches things did not go well with running ABCL on my old hardware (circa 2008). I'm going to try a clean compile with your patches, as maybe it was something other than your patches

Thanks for taking a look. Would you mind sending a backtrace or problem description? I had some out-of-memory errors running the test suite, but I did a number of rebuilds yesterday and it works for me (start abcl under slime, find new classes, check class precedence lists etc.).

vis a vis Pascal Constanza's test suite as mentioned on #abcl. Which version are you running? [The one from darcs on common-lisp.net][1]?

Correct, the one referenced from http://common-lisp.net/project/closer/features.html

I'm not so much running it as watching it crash into abcl limitations, like finding a struct when a class is expected -- I'll declare victory once it can run to completion and print a list of errors.

Rudi

On Jan 3, 2012, at 12:50, Mark Evenson wrote:

On Jan 3, 2012, at 12:04 PM, Rudolf Schlatte wrote:

[…]

...

I'm not so much running it as watching it crash into abcl limitations, like finding a struct when a class is expected -- I'll declare victory once it can run to completion and print a list of errors.

We're all for dirty, short term victories as they can be eked out. Famous last words: "We can always swap it out in the future, right?".

Adding a dummy stub to closer-mop for ABCL shouldn't be that hard, right? I'm running into enough problems with my current darks bridge, that I've decided just to diff against Quicklisp distributions into my local repository.

mop-features just needs some #+abcl branches; I plan to submit a patch to Pascal once abcl can successfully run it (where by "successfully" I mean "manages to finish running and spit out a list of MOP deficiencies"). Currently, it doesn't make much sense to add mop-features to the abcl test suite yet, if that's what you were asking.

Rudi

On Jan 3, 2012, at 12:04 PM, Rudolf Schlatte wrote:

[…]

...

Unfortunately, after applying these patches things did not go well with running ABCL on my old hardware (circa 2008). I'm going to try a clean compile with your patches, as maybe it was something other than your patches

Thanks for taking a look. Would you mind sending a backtrace or problem description? I had some out-of-memory errors running the test suite, but I did a number of rebuilds yesterday and it works for me (start abcl under slime, find new classes, check class precedence lists etc.).

No crashes, just major slowness under OS X 10.7 that I haven't instrumented. Your patches seem to run fine under my oi-151a server, which is a contemporary free Solaris environment with beefy hardware and "grown-up" I/O, so I will probably commit them after I finish analyzing the runs of the GCL-ANSI test and the CL-BENCH suite. Since these patches mostly adjust the Java-side implementation of the Lisp hierarchy after defining a Java METACLASS and SPECIALIZER, I fail to see how they could be problematic.

Or someone else can just push the patches to trunk if they have the time.

Mark

On Jan 4, 2012, at 14:53, Mark Evenson wrote:

On Jan 4, 2012, at 8:28 AM, Mark Evenson wrote: […]

...

Since these patches mostly adjust the Java-side implementation of the Lisp hierarchy after defining a Java METACLASS and SPECIALIZER, I fail to see how they could be problematic.

Or someone else can just push the patches to trunk if they have the time.

Committed to trunk as [r13713][] and [r13714][].

Hi, thanks for applying! Actually, I added some unused bits because of cargo-culting (Specializer.java, Metaobject.java). The attached patch removes these files again, and converts eql-specializer into a class. (intern-eql-specializer now contains a bit of the "quick and dirty means" that AMOP mentions in appendix C -- it's called while initalizing the generic function call machinery so we have to open-code the behavior of make-instance.)

Cheers,

Rudi

On Jan 4, 2012, at 21:40, Mark Evenson wrote:

On Jan 4, 2012, at 5:59 PM, Rudolf Schlatte wrote:

[…]

...

Hi, thanks for applying! Actually, I added some unused bits because of cargo-culting (Specializer.java, Metaobject.java). The attached patch removes these files again, and converts eql-specializer into a class. (intern-eql-specializer now contains a bit of the "quick and dirty means" that AMOP mentions in appendix C -- it's called while initalizing the generic function call machinery so we have to open-code the behavior of make-instance.)

<0001-Convert-EQL-SPECIALIZER-from-a-structure-into-a-CLOS.patch>

Good move, pushing the whole thing into CLOS. The less Java the better.

I "corrected" the Java class naming to common conventions, as typically this marks code that we want to maintain.

Hi, thanks for applying!

I'm not sure the renaming is consistent with the rest of the code. The Lisp class eql-specializer is defined in StandardClass.lisp, EqualSpecializerObject.java (nee eql_specializer_object.java) only implements an object accessor, similar to the existing cell_error_name.java or unbound_slot_instance.java files which I took as guidance.

Small coding-style questions, while I have your attention: there's java files indented with 2 and with 4 spaces. What's the canonical way for new files? Also, is there a good file that shows how you want code documented?

Cheers,

Rudi