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

[armedbear-devel] debug assert considered bad for health
by Alan Ruttenberg 06 May '10

06 May '10

Blood pressure, specifically. What does one do with this: ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.Package.shadowingImport(Package.java:601) at org.armedbear.lisp.PackageFunctions$9.execute(PackageFunctions.java:190) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) No message - go hunt in source code. Yuck. -Alan

5 11

Re: [armedbear-devel] debug assert considered bad for health
by Ville Voutilainen 06 May '10

06 May '10

> On 6 May 2010 20:18, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: >> With the above example, you could show _how_ the boolean is computed. >> That assert would print stuff like >> "Assertion failed at foobar.java:123: ((5 + 6 + 8) == 18)" > Yes, but I think what's needed is more like: > Debug.fail("Expected pathname host of '"+ p + "' to be a > string, symbol, or cons"); Yes, that would be helpful. We could start with that at least, and pipe-dream about macros later. :)

1 0

[armedbear-devel] Moving toward a release
by Erik Huelsmann 06 May '10

06 May '10

Just writing a note that it's time to move toward a release. Over the past days a number of fixes have been committed, especially with respect to pathname code, but in other areas as well. If you have time to excersize some testing, please do and report any failure (or succes!). Before branching the 0.20.x branch, I hope to be able to see 2 additional changes: * finishing METACLASS tests - this is my action item, but is more or less blocked by the next item * ABCL being able to run its own tests - on Windows, this is currently broken by one of the Pathname changes; if you have time to contribute (and hence take some weight off Mark's shoulders) please do! Once again, any feedback appreciated. Bye, Erik.

3 5

[armedbear-devel] Idea to fix ticket 79: identical uninterned symbols coalesced in fasl
by Erik Huelsmann 02 May '10

02 May '10

Ticket 79 is one of the "correctness" category: we do something which we shouldn't (although it hasn't been seen in real life yet). When we compile a file containing 2 *different* -yet similarly named - uninterned symbols, they are coalesced into the same object when reading that fasl. The above behaviour is a consequence of the design choice: the same uninterned symbol may occur in multiple places in the sources, meaning that multiple CompiledClosures may need to refer to the same symbol in their constructor. ABCL solved this problem by interning all unintered symbols into the same anonymous package. When that happens, all occurrances of the same uninterned symbols are coalesced into the same object. However, the same happens to all equally named uninterned symbols which are *not* the same symbol. Here's my idea to resolve this situation, in a simple step-by-step representation: 0. Install a dispatch macro function (in some unused dispatch macro character); something like #n# 1. Adjust DUMP-FORM to generate the dispatch output for uninterned symbols 1. Create all uninterned symbols at the start of the FASL (filling a table with them) 2. Let the reader resolve the uninterned symbols by looking up in the table This approach has the nice side-effect that we can eliminate the need for the anonymous package - although we will need to maintain a table. It will resolve the issues we currently have with the coalesced symbols. It uses standard Lisp infrastructure; no heavy code changes required. Comments? Bye, Erik.

4 9

[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