[armedbear-devel] [Patch] add classes METAOBJECT, SPECIALIZER
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. Regards, Rudi
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 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]? [1]: http://common-lisp.net/project/closer/repos/mop-features/
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: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. Patches coming up in the next day or so; contributions are solicited. Mark
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 2:02 PM, Rudolf Schlatte wrote:
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.
Not looking to necessarily add mop-features to ABCL-TEST, but just to locate a version that I can easily sync upstream patches from, as I can't get Mercurial to 'hg convert' he darcs repo on common-lisp.net as the format is too old. Guess I'll manage revisions/patches "manually" with [mq][1], my [current quilt derivative du jour][2]. [1]: http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ [2]: http://www.suse.de/~agruen/quilt.pdf Getting CLOSER-MOP working for ABCL should be a fairly high priority for everyone, as it will open up another third (estimated) of the Quicklisp ASDF systems…
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 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][]. [r13713]: http://trac.common-lisp.net/armedbear/changeset/13713 [r13714]: http://trac.common-lisp.net/armedbear/changeset/13714 The "slowness" which I encountered on OS X turned out to be the result of my having inadvertently turned the experimental (in JDK6) "garbage first" (G1) collector. Thanks for the patch!
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][].
[r13713]: http://trac.common-lisp.net/armedbear/changeset/13713 [r13714]: http://trac.common-lisp.net/armedbear/changeset/13714
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 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. Published as [svn r13715][1]. [1]: http://bit.ly/xEDz89
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
On 5 January 2012 16:33, Rudolf Schlatte <rudi@constantly.at> wrote:
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?
Our codebase is a mess of inconsistent indenting. I follow the following pseudo-rules: 1) when modifying a file, try and avoid reindenting, reindent in a separate patch if you think you'll maintain the file 2) for new files, 4 spaces sounds saner. Some of us just use what emacs uses by default in its java-mode.
participants (3)
-
Mark Evenson -
Rudolf Schlatte -
Ville Voutilainen