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

[armedbear-devel] Maxima status: Can't compile due to i18n changes
by Erik Huelsmann 13 Mar '10

13 Mar '10

Dear Robert, Maxima developers, >From time to time, I check ABCL's status with Maxima. Today I updated to the latest, but found that I can't compile anymore. The issue is with intl.lisp: the defvar form defining *default-domain* contains an _N reader macro, which expands into multiple symbols on ABCL: This is what I found after expansion: --- fasl content (DEFVAR *DEFAULT-DOMAIN* "maxima" NIL "The message-lookup domain used by INTL:GETTEXT and INTL:NGETTEXT. Use (INTL:TEXTDOMAIN \"whatever\") in each source file to set this.") --- fasl content As you see, there's an additional NIL there. I'm hoping to work out together with you what's going on here, as support for Maxima is one of the important items on the list of ABCL developers. With kind regards, Erik ABCL developer

2 1

Re: [armedbear-devel] [armedbear-cvs] r12526 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 13 Mar '10

13 Mar '10

This e-mail was caused by me testing the post-commit hookscript. Sorry. Bye, Erik. On Sat, Mar 13, 2010 at 7:49 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Mar 12 17:38:32 2010 > New Revision: 12526 > > Log: > Fix ticket #85: CL-JSON throws an error where SBCL doesn't. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp Fri Mar 12 17:38:32 2010 > @@ -1078,9 +1078,9 @@ > ;; (dolist (name (second symbols-form)) > ;; (let ((variable (make-variable :name name :special-p t))) > ;; (push > - (setf (progv-form block) > - `(progv ,symbols-form ,values-form ,@(p1-body body)) > - (progv-environment-register block) t) > + (setf (progv-environment-register block) t > + (progv-form block) > + `(progv ,symbols-form ,values-form ,@(p1-body body))) > block)) > > (defknown rewrite-progv (t) t) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Error: value is not of type CONS
by Axel Rauschmayer 12 Mar '10

12 Mar '10

CL-JSON throws an error under ABCL where SBCL doesn't. The code is: (require 'asdf) (asdf:operate 'asdf:load-op :cl-json) (json:decode-json-from-string "{\"foo\": [10,20,50], \"bar\": true}") The error message is: The value 50 is not of type CONS. I'm using Yason as a work-around, but thought that you guys might want to know, maybe this points to a deeper issue. Greetings, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

2 2

[armedbear-devel] integrating abcl into Protege
by Alan Ruttenberg 12 Mar '10

12 Mar '10

Protege is an ontology development tool. I'm interested in using abcl to develop plugins and TIm Redmond was kind enough to have a stab at doing a first pass integration, but ran into trouble. I wonder if his report makes rings a bell? -Alan ---------- Forwarded message ---------- From: Timothy Redmond <tredmond(a)stanford.edu> Date: Wed, Mar 10, 2010 at 2:12 PM Subject: [POSSIBLE VIRUS:###] Re: further on common lisp integration To: Alan Ruttenberg <alanruttenberg(a)gmail.com> There is something of a difficulty in using this library. It is doing some funky stuff with urls and class loaders and this doesn't work with Protege. Probably could be made to work by making some changes to the abcl sources. In particular it seems to detect that it is loading through the class loader if the prefix begins with jar which is not a correct assumption in general. But here is a start if you want to debug a bit more. -Timothy java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.armedbear.lisp.ZipCache.getZip(ZipCache.java:54) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1305) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1462) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:770) at org.armedbear.lisp.Lisp.error(Lisp.java:354) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1329) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619)

5 14

[armedbear-devel] class-prototype
by Alan Ruttenberg 10 Mar '10

10 Mar '10

Hi, Thanks for adding class-prototype. Unfortunately I realize that the specification doesn't guarantee the behavior I was looking for, so I though I would solicit advise. Basically I want to be able to access class-allocated slot values before I create any real instances. I thought I could grab the class prototype and do slot value on them, but according to the doc below initialize is not called, which I guess is when class-allocated slots are being set up. Is there a portable way of asking for the values of class slots absent the creation of at least one initialized instance? -Alan http://www.franz.com/support/documentation/8.2/doc/mop/dictionary.html#clas… Generic Function class-prototype class Returns a prototype instance of class. Whether the instance is initialized is not specified. The results are undefined if a portable program modifies the binding of any slot of prototype instance. This generic function signals an error if class has not been finalized.

3 11

[armedbear-devel] Problems with compiled PROGV?
by Mark Evenson 09 Mar '10

09 Mar '10

In analyzing the [bug with CL-JSON][1], I think the culprit lies in improper compilation of PROGV forms, although I have yet to come up with a simple example factored out of the CL-JSON codebase. Reading last night's #abcl logs, I saw that Erik made a comment about problems with PROGV as well, without specifics. Thinking that if I had other examples of how PROGV misbehaves it might shed some light on my problems, I'd like to ask for details about other misbehavior of compiled PROGV forms however scant. Cases that are reproducible would be most welcome. [1]: http://trac.common-lisp.net/armedbear/ticket/85 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 7

[armedbear-devel] regarding ticket #87: input history for REPL
by Ville Voutilainen 03 Mar '10

03 Mar '10

We don't necessarily need to use jline for this, there's an utility called rlwrap that provides GNU Readline functionality for the wrapped application. I'm not sure about the availablity of rlwrap on windows, though.

5 4

[armedbear-devel] [PATCH] SYS:GETPID
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

The following patch adds SYS:GETPID which works by making the abcl wrapper shell script store the current PID as a system property. For some reason, I see the following behaviour: tcr@thaleron:~/src/from-upstream/abcl$ abcl-svn Armed Bear Common Lisp 0.19.0-dev Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.47 seconds. Startup completed in 1.099 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:getpid) Unable to autoload SYSTEM:GETPID tcr@thaleron:~/src/from-upstream/abcl$ I.e. the patch is not yet finished; I hope that it'll be clear what's missing to the more experienced ABCL hackers on the list. On Windows, (SYS:GETPID) will just return NIL. There may be some way to do similiar magic with batch files, but googling didn't reveal anything promising. -T.

2 1

[armedbear-devel] #P"SRC"
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

Could ABCL set up a #P"SRC:", or #P"SYS:SRC:" logical pathname to the source directory that was used for the build? -T.

2 5

[armedbear-devel] recording source file locations
by Alan Ruttenberg 03 Mar '10

03 Mar '10

Can anyone summarize what kinds of source information are recorded? Is source location for generic function methods recorded? Variables? Constants? Stuctures? I'd like to extend source recording for functions defined interactively in slime as well, if I can understand what needs to be done on the abcl side. I could hunt around the source but figured I'd ask in case someone has thought of this recently. I'm losing in slime most of the time I meta-point things. On another debugging front, is it possible to get local variables for functions that are interpreted, in the context of an exception? I understand it's more difficult for compiled functions. -Alan

3 3