- armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] Ticket #93: (VALUES) interpreted as NIL by the reader
by Erik Huelsmann 01 May '10

01 May '10

Hi James, Working towards an 0.20 release, I had a look at ticket 93 which was filed by you (from the wording I concluded that it must have been a regression). Although it didn't turn out to be a regression: this issue must have been in our sources for a looong time, it turned out to be easy to fix: r12645 fixes this bug and its cousin in read-delimited-list, which caused the same error. Anyway, the issue you reported has been fixed. Thanks for your report! Bye, Erik.

1 0

[armedbear-devel] Patches for ABCL against asdf-1.641
by Mark Evenson 01 May '10

01 May '10

Attached are patches in 'abcl-asdf.patch' to get asdf-1.641 to work against ABCL for the run-tests.sh. Unfortunately, you will need to build [ABCL from trunk][1] using at least svn r12550, because I had to patch ABCL to work with ASDF. And you'll need to apply the 'abcl-translate-pathname.patch'. [1]: svn://common-lisp.net/project/armedbear/svn/trunk/abcl Notes: 1. The fugliness of the conditional around ASDF:GET-UID works around a bug in the ABCL compiler. We are in the process of [analyzing the error][2]. [2]: http://trac.common-lisp.net/armedbear/ticket/89 2. There is some undiagnosed problem in translating the binary location for the new ASDF2 "~/.cache" conventions, as ABCL seems to "collapses" everything into a single directory. Somehow, the default *output-translations* have a "/**/**/*.*" where there should be "/**/*.*". I'm not sure if this is a problem in "abcl-translate-pathname.patch", which is why I didn't apply this to ABCL trunk. 3. ASDF's run-tests.sh seems to ignore the "flags" setting, which seems to be broken on the ASDF side. 4. The changes for ASDF look quite interesting. However I would advocate that you should make ASDF2 work *exactly* like ASDF1 out of the box, meaning you shouldn't do any of the subsumed ASDF-BINARY-LOCATIONS stuff without being asked to by configuration. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 28

[armedbear-devel] Running "ant test.abcl": Pathname error
by Erik Huelsmann 01 May '10

01 May '10

Hi Mark, Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows: [java] Error while trying to load definition for system abcl from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log. While I'm not asking you to fix it, could you indicate where I should start looking? Thanks in advance! Bye, Erik.

3 5

[armedbear-devel] debug stack overflow? (to track down regression)
by Alan Ruttenberg 01 May '10

01 May '10

Hi, This (a call in my LSW system) used to work for me and is now failing in trunk. However I don't seem to have anything to go on in the stack trace. Any suggestions? Thanks, Alan CL-USER(2): (load-ontology "~/repos/obi/ontology/obi.owl") #<THREAD "interpreter" {FE90EF}>: Debugger invoked on condition of type STORAGE-CONDITION Stack overflow. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (APPLY #<FUNCTION SYSTEM:BACKTRACE {55C752}> NIL) 2: (SYSTEM:BACKTRACE) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {1985DA}>) 4: org.armedbear.lisp.Lisp$1.execute(Lisp.java:288) 5: org.armedbear.lisp.Symbol.execute(Symbol.java:776) 6: org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92)

4 8

[armedbear-devel] READ-LINE inlining fixed, but READ-LINE shouldn't be inlined?
by Erik Huelsmann 30 Apr '10

30 Apr '10

Ticket 89 was about a class verification error which is now fixed, I'm wondering whether we should be inlining calls to Stream.readLine() at all: it seems like this would be incompatible with Gray streams support, after we complete it. Regards, Erik.

1 0

[armedbear-devel] Stack issues fixed: what to do with their workaround?
by Erik Huelsmann 30 Apr '10

30 Apr '10

Hi Mark, A while ago, it looked we had a few regressions in the compiler regarding stack consistency: ticket #89 and the issue reported by Alan (PROGV inside AND). The former you ran into when trying to get ASDF2 running on ABCL. As it turned out, these were both were not regressions, but very old bugs. Both are fixed too. For ticket 89, you implemented a work-around, where the compiler would ask the user to replace the compiled form with an interpreted version. Other than this question, are there any side effects of your change? Anything we might want to consider reverting before our next release? Regards, Erik.

1 0

Re: [armedbear-devel] [armedbear] #89: compiler stack inconsistency
by Mark Evenson 27 Apr '10

27 Apr '10

I tracked this back to before the split of 'abcl' from 'j' observing the error through [rev0 of the copy of abcl][1] I keep in Mercurial], so can confirm the lack of regression back to 2008-12-20. 0 e7def953d497 2008-12-20 20:35 +0100 ehuelsmann [svn r11457] Create separate project directories for ABCL and J. [1]: http://trac.common-lisp.net/armedbear/changeset/11457/trunk/abcl -- "No, this is not a disentanglement from, but a progressive /knotting-into/ […]"

1 0

[armedbear-devel] encoding bug in Stream.readPreservingWhitespace (classpath)
by Eric Marsden 25 Apr '10

25 Apr '10

Hi, Attempting to run ABCL with jamvm (which uses the classpath libraires), I get ,---- | Armed Bear Common Lisp 0.20.0-dev | Java 1.5.0 GNU Classpath | JamVM | Low-level initialization completed in 0.371 seconds. | Exception in thread "interpreter" java.lang.IllegalStateException | at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:163) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:168) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:156) | at org.armedbear.lisp.Stream._unreadChar(Stream.java:1708) | at org.armedbear.lisp.Stream._readToken(Stream.java:1144) | at org.armedbear.lisp.Stream.readToken(Stream.java:1009) | at org.armedbear.lisp.Stream.processChar(Stream.java:508) | at org.armedbear.lisp.Stream.readList(Stream.java:660) | at org.armedbear.lisp.LispReader$3.execute(LispReader.java:88) | at org.armedbear.lisp.Stream.processChar(Stream.java:505) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:484) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:492) | at org.armedbear.lisp.Stream.read(Stream.java:430) | at org.armedbear.lisp.Load.loadStream(Load.java:556) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:522) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:412) | at org.armedbear.lisp.Load.loadSystemFile(Load.java:337) | at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:159) | at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:93) | at org.armedbear.lisp.Main$1.run(Main.java:48) | at java.lang.Thread.run(Thread.java:745) `---- I see in org.armedbear.lisp.Stream.read() a sequence int n = _readChar(); if (n >= 0) { char c = (char) n; // ### BUG: Codepoint conversion Readtable rt = rta.rt(thread); if (!rt.isWhitespace(c)) _unreadChar(c); } which seems likely to be related to this problem. If I print the offending character in DecodingReader.unread() it looks like a #\space. Any suggestions on how to proceed? -- Eric Marsden

2 3

[armedbear-devel] eql for java objects
by Alan Ruttenberg 25 Apr '10

25 Apr '10

(eql (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle") (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle")) -> NIL I think it should be eql, probably eq. I know they are equal. The documentation for eq says: Returns true if its arguments are the same, identical object; otherwise, returns false. They are and they are not. That they are not is only a quirk of the implementation. eql adds equality for characters and numbers I'd argue that was done because of uncertainly over boxing in different implementations and not wanting to fall back to a more expensive equal call. Seems that java objects are an equivalent case. Where this matters is that case and friends use eql for comparison. One ought to be able to write a standard case statement that switches off of an enum defined java, but one can't at the moment. That's all, Alan

6 18

[armedbear-devel] Fwd: threads, join, clos
by Erik Huelsmann 25 Apr '10

25 Apr '10

Sent mail to David personally; meant to include the list. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Sat, Apr 24, 2010 at 9:37 AM Subject: Re: [armedbear-devel] threads, join, clos To: David Kirkman <dkirkman(a)ucsd.edu> Hi David, On Sat, Apr 24, 2010 at 6:52 AM, David Kirkman <dkirkman(a)ucsd.edu> wrote: > Hi, > > Is there an equivalent of java.lang.Thread.join() on the lisp side of > things? I looked around in LispThread.java and threads.lisp, but I > don't see anything obvious. I'd like to be able to write something > like: > > (let ((threads (loop for i from 0 to 5 > collect > (make-thread #'(lambda() > (format t "hey~%")))))) > (mapc #'thread-join threads) > (format t "is for horses~%")) > > I've attached a patch that implements this version of thread-join. It > implements java semantics, this thread-join always returns nil. I guess we didn't join our threads until now :-) Thanks for taking the time to code it up. I have one question regarding the patch though: How would the caller know the difference between the scenario where an Interrupted exception occurs and the one where the thread is really joined? Should we use the return value NIL to signal "not joined" and T for "joined"? Bye, Erik.

3 8