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

[armedbear-devel] test, please ignore
by Alessio Stalla 14 May '11

14 May '11

This is a test message. Blake McBride reported that one mail of his got rejected.

1 0

Re: [armedbear-devel] *print-case* :downcase breaks DEFSTRUCT compilation
by Erik Huelsmann 04 May '11

04 May '11

Dan, On Mon, May 2, 2011 at 10:08 AM, Dan Corkill <corkill(a)gbbopen.org> wrote: > >> It'll take more than the 20 minutes I had to analyze the best >> solution. I'll come back hopefully later this week. > > Thanks Erik. I'm using the short-term workaround of allowing > ABCL to shout back at me (by not setting *print-case* to my > usual :downcase personal preference...). Just committed the fix to trunk. Enjoy! Bye, Erik.

2 1

[armedbear-devel] *print-case* :downcase breaks DEFSTRUCT compilation
by Dan Corkill 02 May '11

02 May '11

Compiling the following file in the latest ABCL (r13272) illustrates the error: --------------------------- (in-package :cl-user) (eval-when (:compile-toplevel :load-toplevel :execute) (setf *print-case* ':downcase)) (defstruct rec a b) --------------------------- Alternatively, remove the EVAL-WHEN and set *PRINT-CASE* as :downcase before compiling the file containing only the DEFSTRUCT.

3 2

[armedbear-devel] Patch: call reinitialize-instance on metaclass on class redefinition
by Alessio Stalla 01 May '11

01 May '11

Hello, I found out that ABCL, when redefining a class, modifies the old class metaobject in-place, slot by slot. This has the implication that the redefinition of an instance of a custom metaclass does not update custom slots. Now, I didn't check on the AMOP, but I'm pretty sure the proper class redefinition protocol is more articulate than the one implemented in ABCL; still, applying the patch that you find attached fixes the problem of custom slots not being updated by calling reinitialize-instance where the old code manually updated the class metaobject, so it is, I think, a valid temporary solution until we have a full MOP. However, before committing the patch, I'd like to hear your opinion about it. The patch also includes some tabs converted to spaces, sorry for the noise. Bye, Alessio

1 2

[armedbear-devel] json-rpc?
by Axel Rauschmayer 27 Apr '11

27 Apr '11

I think ABCL would make an excellent Ajax server. As such, it would have to support json-rpc. Any suggestions as to how to make this happen? The first part is obviously the server, where the two choices that I can see are Hunchentoot and a servlet container such as Tomcat. In the latter case, I would expect to use a technique like abcl-web (which seems a little bit complicated, but doable). The second part is the JSON parsing. How would I do that? Via CL-JSON? Via Yason? Via a Java library? Sorry for these newbie questions. I’m just getting started with Common Lisp and ABCL. Thanks, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

4 10

[armedbear-devel] Mixing Java/Lisp abstraction barrier in ABCL implementation
by Mark Evenson 16 Apr '11

16 Apr '11

Alessio has nicely [committed an simple implementation of RUN-PROGRAM][1] to help out Faré's request for XCVB. [1]: http://trac.common-lisp.net/armedbear/changeset/13270 As I think most of would rather do things in Lisp than Java were possible, his implementation uses the JAVA package FFI primtives (JCALL, JMETHOD, etc) to manipulate the underlying JVM ProcessBuilder abstraction. When I was mucking around with the PATHNAME work, Ville objected to code that I had written in a similar manner, and I re-wrote my patch in Java. As I understand it his objection stememd from the architectural principle that the core ABCL Lisp is to be written without direct calls to Java classes to maintain the Java/Lisp abstraction barrier. So, theoretically, if all the ABCL primitives written in Java were running on a different JVM (say Dalvik or the CLR), the rest of ABCL would run as well, modulo the compiler. But since getting features like RUN-PROGRAM implemented quickly helps everyone out, maybe we should relax this somehow? Maybe placing such code in a different directory ("org/armedbear/lisp/jvm"?) Or use the CL package system to have a SYSTEM-JVM from which SYSTEM can inherit symbols? Does this architectural principle still make sense? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

Re: [armedbear-devel] XCL and ASDF
by Faré 14 Apr '11

14 Apr '11

> Thanks! I've committed asdf.lisp 2.014.2 to XCL's tree on github. Thanks! > Fixed on github. (quit :status 42) or (exit :status 42) should work now. Excellent. >> * Your make-pathname erroneously merges directories as in >> merge-pathnames. It shouldn't. > > Can you give an example of this misbehavior, and what the correct > behavior should be? > for i in sbcl ccl clisp ecl ccl abcl xcl gclcvs allegro scl ; do echo $i ; cl-launch -l $i -s asdf -f ~/bug/xcl-make-pathname.lisp; done 2> /dev/null |& tee /tmp/foo Everyone correctly replies #p"" except abcl and xcl that reply #p"/home/fare/". the bug file contains: (defparameter *h* "/home/fare/") (defparameter *make* (make-pathname :directory nil :defaults *h*)) (format t "~S~%" *make*) I wonder why I didn't detect the bug in abcl earlier. Cc'ing the abcl mailing-list. Also, it's very annoying for cl-launch that xcl doesn't have a --no-inform mode. Even more annoying when some output goes to standard-output *after* I print my stuff and call quit. Can you fix this? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] In a centralized society social status is a zero-sum game along a single hierarchy. That's why politics can never help the weak, only swap roles.

2 2

[armedbear-devel] Function.execute and in-package
by Pablo Duboue 12 Apr '11

12 Apr '11

Hello, How can I issue a Function.execute so that it executes in the context of a given package? That is, I have an instance of the Function class, obtained from a .getSymbolFunction() call on a findAccessibleSymbol over a Package instance, per the examples in the source tree. This function call executes fine, but it runs on package "CL". I need it to run on package, say, "FOO". I have tried a number of things, to no avail: * Issuing an interpreter.evaluate("(in-package "FOO")") beforehand. That seemed very reasonable, but doesn't work. Looking into the code, it seems related to packages being special bindings and said bindings being reset between calls to evaluate. * Fiddling with the thread.markSpecialBindings calls which seem to reset in-package bindings in Lisp, Interpreter and Function. I haven't had much success there, am I on the right track at all? * Trying to use other calls instead of function.execute, which include an environment and a thread, that was very cumbersome (and didn't work either). Might this work at all...? * Using the JSR-223 interface. That did work, but as I'm planning to put this in a Web service, I don't want any interpreter on the way (for security reasons). By the way, the JSR-223 page is the only instance of "in-package" in the whole wiki. (The mailing list search function for 'in-package' split it as two words and return half the mailing list as output.) Any pointers will be appreciated and I'll add the information to the wiki afterward (suggesting where to put it will also be appreciated). You can also reply on #abcl, my nick there is DrDub. Gracias! P.

2 3

[armedbear-devel] ABCL and XCVB
by Faré 11 Apr '11

11 Apr '11

Dear ABCL developers, did you ever get to look at the make-pathname bug? for i in sbcl ccl clisp scl allegro ecl gclcvs abcl xcl ; do cl-launch -l $i -iw '(make-pathname :directory nil :defaults #p"/home/fare/")' ; done Also, I'd like to support ABCL in XCVB, and for that I need something more powerful than run-shell-command, since I need to be able to grab the output. I support I could write to a temporary file with a shell redirect, but it's dirty and racy and requires figuring out where the temporary files are to be located. Could you implement a variant of run-program? It might require some trickery to support both Unix and Windows, but it would be very useful, probably beyond just XCVB. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe

4 4

[armedbear-devel] Fwd: ASDF 2.014 released
by Faré 28 Mar '11

28 Mar '11

[Note: I have skipped ECL and Allegro maintainers from the notification, since I know they subscribe to the announcement. You too can subscribe to the asdf-announce mailing-list or its gmane mirror gmane.lisp.asdf.announce and ask me to take your list off the Cc:] ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 28 March 2011 14:08 Subject: ASDF 2.014 released To: asdf-announce(a)common-lisp.net, ASDF-devel <asdf-devel(a)common-lisp.net> Dear ASDF users, I just blessed ASDF 2.013.7 as 2.014. As compared to 2.013, it includes a significant quality item that makes it essential for everyone who distributes ASDF without an implementation (e.g. Quicklisp). It also includes better SCL support, cosmetic improvements, and robustification of some corner cases. Tests have been added to prevent the regressions observed in the 2.013 release. * Fixed bug preventing upgrade from 2.000 to 2.008 (test added) * Better support for URL pathnames on SCL (test added) * Robustified defsystem-depends-on * Cosmetic changes: * better more portably readable error messages. * remove forward references, again (test added) * canonicalize system names earlier (slight robustness improvement) As usual, I invite people who distribute ASDF to update the version they ship, be it with their implementations, with their software distribution, etc. Happy Happy Joy Joy [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." — Howard Aiken

2 1