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

[armedbear-devel] Common central location for system-wide configuration.
by Olsen, Peter C. 30 Jan '10

30 Jan '10

Ladies and Gentlemen, I've come to the point where it would be convenient for me to establish a system-wide run-time configuration so that every invocation of ABCL for every user starts with a few common packages. The only way I can find to do that is to have everyone put the appropriate code in their .abclrc files. I've tried to put a load command in the shell script that starts the interpreter, but it doesn't work. /usr/bin/java -classpath abcl.jar:jscheme.jar org.armedbear.lisp.Main "(load \"invoke.lisp\")" $@ I suggest that we consider changing the processInitializationFile method in Interpreter.java to look for some sort of initialization file in the directory in which abcl.jar is located when the Interpreter starts. That seems to be a simple change. A more elegant solution would be add some code to determine the OS and then look for configuration files in an appropriate place for each one. I'm a newbie to this project, so I don't want to overstep my bounds. Having said that, I'd be happy to make and test the changes I've proposed. Comments (particularly on the OS variation)? Thanks! Peter -- Peter Olsen, P.E., Ae.E. Registered Professional Engineer, Maryland License 12283 The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road, M/S 17-214 Laurel, Maryland, 20723 Baltimore: 443-778-2577; Washington DC 240-228-2577 Heterogeneity is inevitable and must be supported by design. (RFC 1958)

4 4

[armedbear-devel] [BUG] EXT:ARGLIST produces bogus case-sensitive arglists
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

`arglist' in `arglist.java' calls `readObjectFromString' which uses the FASL Readtable which is case sensitive. This ain't good because this way the lambda-list keywords (&OPTIONAL etc.) are not properly read back (EXTENSIONS:|&optional|) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] No restarts available on error in thread
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

Evaluating the following (threads:make-thread #'(lambda () (error "foof")) :name "foof") will get you into the debugger. But there's not restart available. As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an error occuring in a thread, I think there should be a TERMINATE-THREAD restart instead. And the debugger should probably print the thread's name the error occured in. -T.

2 1

[armedbear-devel] Autoloads
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

I *always* forget what the autoload stuff is about, and when I have to add something to it. Could anyone please add a comment to Autoload.java and autoloads.lisp? -T.

2 3

[armedbear-devel] jcall and t/nil boolean arguments
by Alan Ruttenberg 29 Jan '10

29 Jan '10

Can it be made so that within jcall, t or nil is understood as a java boolean argument? -Alan

3 3

[armedbear-devel] 0.18 and beyond
by Erik Huelsmann 29 Jan '10

29 Jan '10

This evening, I've updated the list of tickets at http://trac.common-lisp.net/armedbear/report/1. Assigning the tickets in the list to specific releases makes the roadmap view (http://trac.common-lisp.net/armedbear/roadmap) nicely indicate our progress. If you have an issue, but it's not mentioned in the list of tickets, 2 things can be the case: 1) We don't know about your ticket, or have forgotten about it 2) The ticket is more of a general thing we need to keep doing (there's no specific goal or target to be achieved) In the second case, we can't file a ticket, because I would like to be able to close tickets some day. As you'll find, I've assigned some tickets to the milestone "too-vague". If we can't come up with more specific descriptions, I think we'll have to reclassify these to "reminder" type tickets. (We don't have those, yet, btw.) So, I'd like to hear your comments on missing tickets. I'd also like to discuss assignment of tickets to milestones. This won't mean that they will be fixed by then, but they *are* meant to be a guideline for priorities and hopefully an indication for interested users on which larger issues we intend to tackle and roughly when. Bye, Erik.

5 12

[armedbear-devel] asdf loading from jar files
by Alan Ruttenberg 29 Jan '10

29 Jan '10

I've believe I've written code that can load a compiled asdf system from a jar file. Final testing is pending the patch for loading a compiled file from a subdirectory of a jar. In order to do that I needed to do 3 things. 1) Patch probe file so that it understands jar:file pathnames 2) Patch truename so that it understands jar:file pathnames 3) Create a new asdf op that knows to load only the compiled files. These patches are in http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp I used advise (http://svn.mumble.net:8080/svn/lsw/trunk/util/encapsulate.lisp) to patch, probe-file, directory, and truename, but don't mind merging the changes into source if it's deemed that they are the right thing. I'd submit the code for advise too (adapted from MCL), but it's not quite cleaned up yet. The asdf op is in that file too. It's a bit hacky because I use asdf-binary-locations[1] and I didn't see how to cleanly integrate it. If someone knows how to drive asdf better than I do, please suggest a better way. There's still a nit in that if you load the system a second time it warns about file-write-date not working. I'm not sure file write date should return for a jar:file pathname. The write date of the containing jar? FWIW, I think that you should consider having asdf-binary-locations be part of the standard distribution. As ABCL is under active development I was always running into issues with stale fasls, but no more since I've been using it. -Alan [1] http://common-lisp.net/project/asdf-binary-locations/ laptop:~/ % jar tf test.jar META-INF/ META-INF/MANIFEST.MF bar/ bar/armedbear-0.18.0-dev-darwin-unknown/ bar/armedbear-0.18.0-dev-darwin-unknown/bar1.abcl bar/armedbear-0.18.0-dev-darwin-unknown/bar2.abcl bar/bar.asd CL-USER> (advise load (if (eql 0 (search "jar:file" (namestring (car arglist)))) (format t ";; would have loaded ~a~%" (car arglist)) (:do-it)) :when :around :name stub) #<FUNCTION (ENCAPSULATE::ADVISED 'LOAD) {ACB16B}> CL-USER> (load "jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd") ; Loading jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd ... ; Loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd (0.0030 seconds) T CL-USER> (asdf::oos 'asdf::load-just-fasls-op 'bar) ;; would have loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/armedbear-0.18.0-dev-darwin-unknown/bar1.abcl ;; would have loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/armedbear-0.18.0-dev-darwin-unknown/bar2.abcl CL-USER> (asdf::oos 'asdf::load-just-fasls-op 'bar) WARNING: Missing FILE-WRITE-DATE for #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar1.lisp": treating operation #<ASDF::LOAD-JUST-FASLS-OP NIL {8C2182}> on component #<ASDF:CL-SOURCE-FILE "bar1" {B93BB6}> as done. WARNING: Missing FILE-WRITE-DATE for #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar2.lisp": treating operation #<ASDF::LOAD-JUST-FASLS-OP NIL {8C2182}> on component #<ASDF:CL-SOURCE-FILE "bar2" {7242FD}> as done.

5 8

[armedbear-devel] problem with error reporting on undefined class during make instance
by Alan Ruttenberg 29 Jan '10

29 Jan '10

CL-USER(25): (defclass c (d) ((q :initarg :q))) #<STANDARD-CLASS C {B5BEE0}> CL-USER(26): (make-instance 'c :q t) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :Q. The error should say instead something about d not being defined. This in build of a freshly updated trunk abcl -Alan

2 1

[armedbear-devel] Using Java variable arguments
by Blake McBride 29 Jan '10

29 Jan '10

Java has had support for variable argument methods since version 5. Wouldn't it be cleaner to use that? For example, in LispObject.java there are several "execute" methods, one to support various numbers of arguments. In Java 5+ you could write: public LispObject execute(LispObject ... arg) { whatever } You call it like you do now, i.e. execute(a, b, c, d) but arg gets an array of the arguments. This way you could create one method that would handle virtually any number of arguments in one clean method. I'm sure this technique can be used in more places too. Blake McBride

3 2

[armedbear-devel] ABCL OpenOffice.org Extension
by Knut Olav Bøhmer 28 Jan '10

28 Jan '10

Hi, I want to make lisp the preferred way of developing openoffice.orgextensions, but I have to much problems with the java part. I have been able to make an extension for openoffice.org using an openoffice.org plugin for eclipse. Now, I have to figure out how to embed it with ABCL. I would be very happy if some one could help me by giving me some hints or even a step by step procedure to import abcl into the eclipse project. The first thing I want to do is to be able to load lisp files from the openoffice.org basic interface. Then I'll extend it to be able to start swank and run expressions from strings. -- Knut Olav Bøhmer

2 1