armedbear-devel December 2009

armedbear-devel@common-lisp.net

14 participants
21 discussions

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

28 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] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[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] 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 30 Jan '10

30 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] 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

Re: [armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 30 Dec '09

30 Dec '09

Thanks, you are right, much better to use the built-in key stuff (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance nil instance-supplied-p) unused-value) (declare (ignore unused-value)) (if instance-supplied-p (jfield class-ref-or-field field-or-instance instance newvalue) (jfield class-ref-or-field field-or-instance newvalue))) ----- Original Message ----- From: "Thomas Russ" <tar(a)ISI.EDU> To: <dmiles(a)users.sourceforge.net> Sent: Tuesday, November 24, 2009 9:24 AM Subject: Re: [armedbear-devel] SETF for JFEILDS On Nov 23, 2009, at 6:47 AM, logicmoo(a)gmail.com wrote: > So actually > > (defun (setf jfield) (newvalue class-ref-or-field field-or- > instance &optional ( instance :noinst) unusedvalue) > (if (eq instance :noinst) > (jfield class-ref-or-field field-or-instance newvalue) > (jfield class-ref-or-field field-or-instance instance newvalue))) > > Would be a little better.. good eye. For what it's worth, I am not a fan of using special values to determine whether optional (or keyword) arguments are actually passed or not. I prefer to use the predicate forms from the lambda list, so something more like (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance nil instance-supplied-p) unusedvalue) (declare (ignore unusedvalue)) (if instance-supplied-p (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) > > > ----- Original Message ----- > From: <dmiles(a)users.sourceforge.net> > To: "Alessio Stalla" <alessiostalla(a)gmail.com> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Monday, November 23, 2009 6:27 AM > Subject: Re: [armedbear-devel] SETF for JFEILDS > > >> >> ----- Original Message ----- >> From: "Alessio Stalla" <alessiostalla(a)gmail.com> >> To: <dmiles(a)users.sourceforge.net> >> Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> >> Sent: Monday, November 23, 2009 5:42 AM >> Subject: Re: [armedbear-devel] SETF for JFEILDS >> >> >> On Mon, Nov 23, 2009 at 2:36 PM, <logicmoo(a)gmail.com> wrote: >>>> Does anyone object to adding this to java.lisp? If not could it >>>> be done? >>>> >>>> (defun (setf jfield) >>>> (newvalue class-ref-or-field field-or-instance &optional >>>> ( instance :noinst) (value :novalue)) >>>> (if (eq instance :noinst) >>>> (jfield class-ref-or-field field-or-instance newvalue) >>>> (jfield class-ref-or-field field-or-instance instance newvalue))) >> >>> It seems a nice idea to me, but there are a couple of things that I >>> don't understand: >> >> A>- why :noinst and not simply nil? >> >> JFIELD is defined as: class-ref-or-field field-or-instance >> &optional instance value >> The valid argument patterns for this operation are: >> (class-ref field-name): to retrieve the value of a static field. >> (class-ref field-name instance-ref): to retrieve the value of a >> class field of the instance. >> (class-ref field-name primitive-value:) to store primitive-value >> in a static field. >> (class-ref field-name instance-ref value): to store value in a >> class field of the instance. >> (class-ref field-name nil value): to store value in a static >> field (when value may be confused with an instance-ref). >> (field-name instance): to retrieve the value of a field of the >> instance. The class is derived from the instance. >> (field-name instance value): to store value in a field of the >> instance. The class is derived from the instance. >> >> JFIELD doesn't distingusih between static and non static fields >> >> Also cases of "class-ref field-name instance-ref >> value" (accessing superclass field) >> >> Depending on how the field is defined >> >> (setf (jfield *MyClass* "someStaticBooleanField") NIL) >> it is distinguable from >> (setf (jfield *MySuperClass* "nonStaticBooleanField" *my- >> instance* ) NIL) >> >> >> -------------------------------------------------------------------------------------------------------------------------- >> A>- value is not used, what's the point of it? >> >> correct the "default :novalue" is not needed. >> (I was debugging and trying to find corner cases with all those >> bizzare legal jfield signatures ) >> >> >> but... "value" as an &optional was needed to match the signature >> of what is legal for jfield so things like this can work: >> >> (define-symbol-macro %iscold (jfield "org.armedbear.lisp.Lisp" >> "cold")) >> %iscold ;; ==> NIL >> (setq %iscold T) ;; ==> T >> %iscold ;; ==> T >> (setq %iscold NIL) ;; ==> NIL >> >> > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

7 19

[armedbear-devel] How do I release ABCL's "package-lock"?
by Peter Olsen 30 Dec '09

30 Dec '09

I'm writing to ask how to redefine the "or" macro in ABCL. I'm working on a project and there's one package in which I need "or" to mean something else than its usual definition. I've tried simply to redefine it, but it doesn't work. I understand that the Common Lisp spec requires special provision for that to be done --- such as the package-lock construct in SBCL. How can I do that in ABCL? I want to be able to do this within the code, for example, with in a "let" so that I can bound its scope. Can anyone point me in the right direction? My first --- failed --- experiment is below. Thanks! Peter ------------------------------------------------------- A way that doesn't work. slipstream:~ pcolsen$ abcl Armed Bear Common Lisp 0.17.0 Java 1.5.0_20 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 1.476 seconds. Startup completed in 4.363 seconds. Type ":help" for a list of available commands. CL-USER(1): (or nil t) T CL-USER(2): (defmacro or (x) (+ 1 x)) ; My very own new "or" OR CL-USER(3): (or 3) ; Result should be 4 3 CL-USER(4): (or nil nil) ; My "or" should take only one argument. NIL CL-USER(5): (or nil t) T CL-USER(6): ;;; Redefinition didn't work. Peter Olsen olsen(a)sigmaxi.net I have loved the stars too fondly to be fearful of the night. Galileo Galilei

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel December 2009