armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] *command-line-argument-list* backwards
by Alan Ruttenberg 15 Mar '10

15 Mar '10

java -cp ~/Desktop/test.jar org.armedbear.lisp.Main --noinit -a -b -c -d Armed Bear Common Lisp 0.20.0-dev Java 1.5.0_19 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.364 seconds. Startup completed in 0.893 seconds. lType ":help" for a list of available commands. CL-USER(1): *command-line-argument-list* ("-d" "-c" "-b" "-a")

3 2

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #38: CLOS :metaclass support
by Erik Huelsmann 13 Mar '10

13 Mar '10

The mail below was induced by the "automatic ticket annotator" from Trac. While I installed it many moons ago, I was under the impression it wasn't working. Nothing like that was the case: I just didn't get it enough. See http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-com… on how you can annotate or close tickets from your commit message. Bye, Erik. On Sat, Mar 13, 2010 at 8:05 PM, armedbear <armedbear-devel(a)common-lisp.net> wrote: > #38: CLOS :metaclass support > -------------------------+-------------------------------------------------- > Reporter: ehuelsmann | Owner: ehuelsmann > Type: defect | Status: accepted > Priority: major | Milestone: 0.20 > Component: other | Version: > Resolution: | Keywords: > -------------------------+-------------------------------------------------- > > Comment(by ehuelsmann): > > (In [12527]) Make all class accessor functions generic functions instead > of normal ones, to support METACLASS. Additionally, make > it possible to store general objects in Layout.lispClass. > Because classes may be of a different Java type than > StandardClass, fall back to the generic functions to access > the required fields from Java. > > See #38. > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/38#comment:2> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0

[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 11 Mar '10

11 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 04 Mar '10

04 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel