[armedbear-devel] No :DARWIN, "No tag" & no ASDF
Hello list, I'm inching my way towards working with ABCL (stupid day job) and I thought I'd mention a few things that have cropped up. I'm running on OS X 10.5.8 using the OpenJDK 6 (for JSR-223, and the server VM). I updated the source from the SVN repo this morning. When I build ABCL, I get the warning "Use of Java version 1.6.0-internal not recommended." Perhaps '<matches string="${java.version}" pattern="1\.6\.0-internal"/>' could be added to the appropriate spot in build.xml to suppress this warning. When I run ABCL, I get :JAVA-1.6 in *FEATURES* but not :DARWIN (or any other OS identifier). (*FEATURES* is (:DARWIN :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6). What's :CDR6?) When my '(load ".../start-swank.lisp")' fails, I get an error when I enter ':cont 0': shadow:abcl john$ ./abcl Armed Bear Common Lisp 0.17.0-dev Java 1.6.0-internal Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 1.699 seconds. Startup completed in 8.5 seconds. [on my Dell Mini 9, not real Apple h/w] Type ":help" for a list of available commands. CL-USER(1): (load "/Users/john/src/lisp/abcl/start-swank.lisp") Error loading /Users/john/src/lisp/asdf/asdf.lisp at line 193 (offset 7111) Debugger invoked on condition of type SIMPLE-ERROR: The long form of DEFINE-METHOD-COMBINATION is not implemented. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): :cont 0 Debugger invoked on condition of type CONTROL-ERROR: No tag named #:G140089 is currently visible Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4): Which brings me to the last problem: asdf.lisp won't load, since it uses the long form of DEFINE-METHOD-COMBINATION. Is there a workaround for this? If anyone can shed some light on these issues, that would be great. As an aside, does anyone want to share their .emacs settings for Java development? I've installed JDE (which was a PITA FWIW), CC-Mode etc. and I'm curious as to what other (Emacs-minded) people are using. Cheers, John :^P -- John Pallister john@johnp.net john@synchromesh.com
On Mon, Oct 5, 2009 at 5:47 PM, John Pallister <john@synchromesh.com> wrote:
Hello list,
I'm inching my way towards working with ABCL (stupid day job) and I thought I'd mention a few things that have cropped up.
Hello, you're welcome!
I'm running on OS X 10.5.8 using the OpenJDK 6 (for JSR-223, and the server VM). I updated the source from the SVN repo this morning.
When I build ABCL, I get the warning "Use of Java version 1.6.0-internal not recommended." Perhaps '<matches string="${java.version}" pattern="1\.6\.0-internal"/>' could be added to the appropriate spot in build.xml to suppress this warning.
Fair enough.
When I run ABCL, I get :JAVA-1.6 in *FEATURES* but not :DARWIN (or any other OS identifier). (*FEATURES* is (:DARWIN :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6). What's :CDR6?)
CDR6 is http://cdr.eurolisp.org/document/6/index.html About OS detection in *features*, I don't know how it is supposed to work.
When my '(load ".../start-swank.lisp")' fails, I get an error when I enter ':cont 0':
shadow:abcl john$ ./abcl Armed Bear Common Lisp 0.17.0-dev Java 1.6.0-internal Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 1.699 seconds. Startup completed in 8.5 seconds. [on my Dell Mini 9, not real Apple h/w] Type ":help" for a list of available commands. CL-USER(1): (load "/Users/john/src/lisp/abcl/start-swank.lisp") Error loading /Users/john/src/lisp/asdf/asdf.lisp at line 193 (offset 7111) Debugger invoked on condition of type SIMPLE-ERROR: The long form of DEFINE-METHOD-COMBINATION is not implemented. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): :cont 0 Debugger invoked on condition of type CONTROL-ERROR: No tag named #:G140089 is currently visible Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4):
This happens to me too with recent versions from SVN. I guess it's a bug.
Which brings me to the last problem: asdf.lisp won't load, since it uses the long form of DEFINE-METHOD-COMBINATION. Is there a workaround for this?
You can (require 'asdf), which should load the version of asdf bundled with abcl (which afaik is an older version without the long form of d-m-c).
If anyone can shed some light on these issues, that would be great.
As an aside, does anyone want to share their .emacs settings for Java development? I've installed JDE (which was a PITA FWIW), CC-Mode etc. and I'm curious as to what other (Emacs-minded) people are using.
I'm interested in this too. I used to use Eclipse for the Java parts, but I'm moving more and more to Emacs (and simply Ant to build/run). However, I have a very minimal .emacs setup (I'm an Emacs newbie). Bye, Alessio
Hi Alessio, John, Just a quick response, since I'm at work:
Low-level initialization completed in 1.699 seconds. Startup completed in 8.5 seconds. [on my Dell Mini 9, not real Apple h/w] Type ":help" for a list of available commands. CL-USER(1): (load "/Users/john/src/lisp/abcl/start-swank.lisp") Error loading /Users/john/src/lisp/asdf/asdf.lisp at line 193 (offset 7111) Debugger invoked on condition of type SIMPLE-ERROR: The long form of DEFINE-METHOD-COMBINATION is not implemented. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): :cont 0 Debugger invoked on condition of type CONTROL-ERROR: No tag named #:G140089 is currently visible Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4):
This happens to me too with recent versions from SVN. I guess it's a bug.
It is indeed a bug. It's fall-out from the change Mark Evenson committed to catch unmatched Go and Return exceptions. I committed a change yesterday which should prevent that type of exception (unmatched, that is) to ever happen. I'll check his change and revert the bit which causes these control errors.
Which brings me to the last problem: asdf.lisp won't load, since it uses the long form of DEFINE-METHOD-COMBINATION. Is there a workaround for this?
You can (require 'asdf), which should load the version of asdf bundled with abcl (which afaik is an older version without the long form of d-m-c).
That's true.
If anyone can shed some light on these issues, that would be great.
We're looking for someone (or funding so I can quit my day-job :-) to implement d-m-c. It's been one of the things we deerly want to implement but which exceeds the time and effort available at the moment. Hence we're addressing other issues, such as performance, first. Hope that explains some. Regards, Erik.
On Mon, Oct 5, 2009 at 5:08 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
Just a quick response, since I'm at work:
A quick response is always appreciated... ;)
This happens to me too with recent versions from SVN. I guess it's a bug.
It is indeed a bug. It's fall-out from the change Mark Evenson committed to catch unmatched Go and Return exceptions. I committed a change yesterday which should prevent that type of exception (unmatched, that is) to ever happen. I'll check his change and revert the bit which causes these control errors.
I thought this would be the case.
We're looking for someone (or funding so I can quit my day-job :-) to implement d-m-c. It's been one of the things we deerly want to implement but which exceeds the time and effort available at the moment. Hence we're addressing other issues, such as performance, first.
Is it a lot of work, then?
Hope that explains some.
That's great, thanks for that.
On 10/5/09 6:08 PM, Erik Huelsmann wrote: […]
It is indeed a bug. It's fall-out from the change Mark Evenson committed to catch unmatched Go and Return exceptions. I committed a change yesterday which should prevent that type of exception (unmatched, that is) to ever happen. I'll check his change and revert the bit which causes these control errors.
I found some time to test and revert this as [svn 12177][1]. I'll close [ticket 63][2] as well. [1]: http://trac.common-lisp.net/armedbear/changeset/12177 [2]: http://trac.common-lisp.net/armedbear/ticket/63 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Mon, Oct 5, 2009 at 4:57 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
When I run ABCL, I get :JAVA-1.6 in *FEATURES* but not :DARWIN (or any other OS identifier). (*FEATURES* is (:DARWIN :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6). What's :CDR6?)
OK, thanks.
About OS detection in *features*, I don't know how it is supposed to work.
This is an OpenJDK-related issue, I think; when I use Apple's java, I get :UNIX and :DARWIN in *FEATURES*. I'll try and investigate this further.
You can (require 'asdf), which should load the version of asdf bundled with abcl (which afaik is an older version without the long form of d-m-c).
Thanks, I'll look for & try to use that. Although I couldn't find it in the current source tree (i.e. I was using that, but it seems to have gone away.)
I'm interested in this too. I used to use Eclipse for the Java parts, but I'm moving more and more to Emacs (and simply Ant to build/run). However, I have a very minimal .emacs setup (I'm an Emacs newbie).
Alright, I'll post my setup (once it's settled down a bit). Cheers, John :^P
Sorry to reply to my own post.
This is an OpenJDK-related issue, I think; when I use Apple's java, I get :UNIX and :DARWIN in *FEATURES*. I'll try and investigate this further.
For OpenJDK 6 on OS X, System.getProperty("os.name") returns "Darwin". So isPlatformUnix in Utilities.java needs to be amended. I imagine this will fix the problem. I'd be happy to file bug reports and add/amend documentation to the Trac system if someone would make me a common-lisp.net login (or does that come from elsewhere?). Or would people prefer patches? If so, what's the preferred format? Cheers, John :^P
2009/10/5 John Pallister <john@synchromesh.com>:
Sorry to reply to my own post. For OpenJDK 6 on OS X, System.getProperty("os.name") returns "Darwin". So isPlatformUnix in Utilities.java needs to be amended. I imagine this will fix the problem.
We do need OS X testers, so help would be very welcome.
I'd be happy to file bug reports and add/amend documentation to the Trac system if someone would make me a common-lisp.net login (or does that come from elsewhere?). Or would people prefer patches? If so, what's the preferred format?
For patches, unified diffs are preferred. You generate those with diff -u or with svn diff. For cl-net account, Erik can help you with that, he has contacts for the cl-net admins.
On Mon, Oct 5, 2009 at 10:00 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
2009/10/5 John Pallister <john@synchromesh.com>:
Sorry to reply to my own post. For OpenJDK 6 on OS X, System.getProperty("os.name") returns "Darwin". So isPlatformUnix in Utilities.java needs to be amended. I imagine this will fix the problem.
We do need OS X testers, so help would be very welcome.
I fixed it in Lisp.java, which sets up *FEATURES* and I fixed it in Utilities.java, which indicates the platform type. Fix committed already, but please test!
I'd be happy to file bug reports and add/amend documentation to the Trac system if someone would make me a common-lisp.net login (or does that come from elsewhere?). Or would people prefer patches? If so, what's the preferred format?
For patches, unified diffs are preferred. You generate those with diff -u or with svn diff. For cl-net account, Erik can help you with that, he has contacts for the cl-net admins.
This change is too small (if it works - I don't have darwin) to open an issue for. However, if you have patches, please don't hesitate to send them. Shall I contact the c-l.net admins for an account so you can log into the bug database yourself? Bye, Erik.
On Mon, Oct 5, 2009 at 9:21 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
I fixed it in Lisp.java, which sets up *FEATURES* and I fixed it in Utilities.java, which indicates the platform type. Fix committed already, but please test!
You beat me to it... ;) But I've attached my patch anyway (just for the practice). You're right, it's a pretty trivial fix. I've tested it, and it does seem to work. Please let me know if there's anything wrong with my patch.
This change is too small (if it works - I don't have darwin) to open an issue for. However, if you have patches, please don't hesitate to send them.
It's not so much Darwin per se, just my use of the OpenJDK 6 VM (http://openjdk.java.net/).
Shall I contact the c-l.net admins for an account so you can log into the bug database yourself?
That would be great, I'd appreciate that. "synchromesh" is my preferred username, but anything is fine. Cheers, John :^P -- John Pallister john@synchromesh.com john@johnp.net
On Mon, Oct 5, 2009 at 10:36 PM, John Pallister <john@synchromesh.com> wrote:
On Mon, Oct 5, 2009 at 9:21 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
I fixed it in Lisp.java, which sets up *FEATURES* and I fixed it in Utilities.java, which indicates the platform type. Fix committed already, but please test!
You beat me to it... ;) But I've attached my patch anyway (just for the practice). You're right, it's a pretty trivial fix. I've tested it, and it does seem to work. Please let me know if there's anything wrong with my patch.
Thanks for the patch. I reviewed it and it looks fine to me.
This change is too small (if it works - I don't have darwin) to open an issue for. However, if you have patches, please don't hesitate to send them.
It's not so much Darwin per se, just my use of the OpenJDK 6 VM (http://openjdk.java.net/).
Shall I contact the c-l.net admins for an account so you can log into the bug database yourself?
That would be great, I'd appreciate that. "synchromesh" is my preferred username, but anything is fine.
I'm affraid the policy is different: like my own, I have e.huelsmann; I'm expecting something along those lines for you. I sent a mail about the account request privately. They require a PGP key could you send it in response to my mail? Thanks! Bye, Erik.
On 10/5/09 5:47 PM, John Pallister wrote: […]
As an aside, does anyone want to share their .emacs settings for Java development? I've installed JDE (which was a PITA FWIW), CC-Mode etc. and I'm curious as to what other (Emacs-minded) people are using.
I'm not a fan of JDE, as it really never helped with my primary use of Java based IDEs by giving insight into the class structure. Supposedly [CEDET][1] will be included in the next point release of Emacs 23, but I haven't really integrated it into my Java-based workflow. CEDET's primary consumer seems to be C++ development, but it seems to have the basis for Java-based inspection that I would use. I have yet to really have the time to understand what CEDET offers. [1]: http://cedet.sourceforge.net/ As for Java settings for Emacs 23, I don't use much more than the defaults. The relevant portions of my .emacs: (require 'java-mode-indent-annotations) (require 'cc-mode) (add-hook 'java-mode-hook 'java-mode-indent-annotations-setup) (setq-default indent-tabs-mode nil) (setq c-basic-offset 2) (add-hook 'java-mode-hook (lambda () (set (make-local-variable 'compile-command) "/opt/local/bin/ant -emacs -find build.xml"))) The only thing non-standard here is [java-mode-indent-annotations][2], which adjusts cc-mode for Java annotations from @Annotation public Code starts(here) { to @Annotation public Code starts(here) { [2]: http://www.emacswiki.org/cgi-bin/wiki/java-mode-indent-annotations.el For navigating the ABCL source, note that the 'TAGS' target in 'build.xml' has specialized logic to grovel the '###SYMBOL###' comments that link Lisp symbols to their Java implementations, which makes Emacs's M-x find-tag interface quite a bit more useful. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 10/5/09 5:47 PM, John Pallister wrote: […]
When I build ABCL, I get the warning "Use of Java version 1.6.0-internal not recommended." Perhaps '<matches string="${java.version}" pattern="1\.6\.0-internal"/>' could be added to the appropriate spot in build.xml to suppress this warning.
Maybe we should invert the test so we only emit the warning if we match 'java.version' for values of '1.6.0_1' through '1.6.0_9'? The sense being that we only know that we have problems with the Sun JDK 6 releases from U1 through U9. Some background might be in order. For reasons that were never clear, but attributed to problems with the huge number of classes that ABCL generates (mostly from the "one per CONS" requirement), performance seemed subjectively slow under JDK 6, and was backed objectively by benchmarking the time it took ABCL to a) run the ANSI test suite, and to b) compile its own Lisp classes. Some guesses were made as to the cause of the problem, but by the time we got serious about thinking about implementing the rather involved strategies that seemed like it might help, jdk-1.6.0_10 was released with dramatically improved performance. John: how did you build your OpenJDK6? Or did you get binaries from somewhere? I just built the version in MacPorts to test ABCL with, seeing the same '1.6.0-internal' version string in 'java.version'. The MacPorts port metadata claims this is 'b16', which seems to be the last change in the [OpenJDK6 mercurial repository][1]. Does 'b16' correspond to 'u16' in the Sun JDK release? [1]: http://hg.openjdk.java.net/jdk6/jdk6 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Hi Mark, Thanks for the Emacs notes. I'll fold those into my setup. I agree that CEDET looks a little daunting. I just installed OpenJDK 6 from MacPorts. I thought it'd be good to have Java 6 for the JSR-223 stuff, and I'm not in a huge hurry to upgrade to OS X 10.6 (a.k.a. Snow Leopard, which has the Apple Java 6 JDK). SoyLatte (now folded into OpenJDK) seemed the easiest way to go. I don't know what the relation is to the latest Sun JDK release. Cheers, John :^P On Tue, Oct 6, 2009 at 10:30 AM, Mark Evenson <evenson@panix.com> wrote:
On 10/5/09 5:47 PM, John Pallister wrote: […]
When I build ABCL, I get the warning "Use of Java version 1.6.0-internal not recommended." Perhaps '<matches string="${java.version}" pattern="1\.6\.0-internal"/>' could be added to the appropriate spot in build.xml to suppress this warning.
Maybe we should invert the test so we only emit the warning if we match 'java.version' for values of '1.6.0_1' through '1.6.0_9'? The sense being that we only know that we have problems with the Sun JDK 6 releases from U1 through U9.
Some background might be in order. For reasons that were never clear, but attributed to problems with the huge number of classes that ABCL generates (mostly from the "one per CONS" requirement), performance seemed subjectively slow under JDK 6, and was backed objectively by benchmarking the time it took ABCL to a) run the ANSI test suite, and to b) compile its own Lisp classes. Some guesses were made as to the cause of the problem, but by the time we got serious about thinking about implementing the rather involved strategies that seemed like it might help, jdk-1.6.0_10 was released with dramatically improved performance.
John: how did you build your OpenJDK6? Or did you get binaries from somewhere? I just built the version in MacPorts to test ABCL with, seeing the same '1.6.0-internal' version string in 'java.version'. The MacPorts port metadata claims this is 'b16', which seems to be the last change in the [OpenJDK6 mercurial repository][1]. Does 'b16' correspond to 'u16' in the Sun JDK release?
[1]: http://hg.openjdk.java.net/jdk6/jdk6 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
participants (5)
-
Alessio Stalla -
Erik Huelsmann -
John Pallister -
Mark Evenson -
Ville Voutilainen