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

[armedbear-devel] ASDF 2.30 released
by Faré 21 Feb '13

21 Feb '13

Dear Lisp hackers, ASDF 2.30 is another stability release in preparation for ASDF 3. Since 2.29, in addition to specific portability fixes for CCL and CMUCL, it notably restores some backward compatible behavior for syntax tables around loading .asd files, using mutable global tables, instead of standard syntax tables. Just like 2.29, 2.28 and 2.27 before it, ASDF 2.30 is a pre-release of ASDF 3, an almost complete rewrite of ASDF, and includes a vast number of improvements since ASDF 2.26. http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… We invite all implementation vendors to update to ASDF 2.30. We also invite all implementations to make the standard *readtable* and *print-pprint-dispatch* tables immutable, with useful error messages when a modification is attempted. See how the CLHS forbids conformant programs from modifying them: http://clhs.lisp.se/Body/26_glo_s.htm#standard_readtable http://clhs.lisp.se/Body/26_glo_s.htm#standard_pprint_dispatch_table Such modification can only result in problems down the line for users, and it would be nice if at least when SAFETY isn't 0, that were checked. In some unspecified future, we'd like to revert to ASDF 2.29's behavior of binding the syntax tables to their standard values, and then we hope that most implementations will immediately catch misguided attempts by users to modify them (SBCL is the only implementation enforced immutability on both tables). Many thanks to stassats and avodonosov for their help in testing ASDF and helping make it more robust, more portable and more backward compatible. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a free market there are no market failures, only market opportunities. In a bureaucracy there is no possible success, only a perpetual ever-worsening crisis.

2 1

[armedbear-devel] Seamless ABCL / Java integration proposal
by Blake McBride 20 Feb '13

20 Feb '13

I have an idea for a largely seamless integration method for ABCL with Java that involves changing the ABCL REPL. It would work as follows. 1. From within Java or lisp, have the ability to register any number of Java classes with ABCL. 2. When executing lisp code of the form (fun args ...), try running the code as regular lisp code as it does now, but if it fails to find the lisp function and has at least one argument then: 3. Examine the arguments and, through reflection, try to find a Java method (with the same name as the lisp function) in one of the registered Java classes that matches the number and types of arguments and execute that. So, it would auto translate (in effect): (fun arg1 arg2 arg3 ...) into Java arg1.fun(arg2, arg3, ...); 4. There must be better auto-translation of lisp <-> java data types to include arrays and lists in order for this to work. So, in other words, when executing a lisp function passing a lisp array as one of the arguments, the Java reflection query will see a Java array argument type. It will also be auto-converted when making the call. 5. There must be some sort of cacheing mechanism to avoid redundant Java reflection calls. 6. This mechanism must take into account and correctly handle similar Java method names with different number and types of arguments both within and across different classes. It must also handle the fact that methods may be declared in Java superclasses. 7. This functionality can be enabled or disabled through some (Java and/or lisp function). Off by default to avoid troubles. Adding this functionality would make ABCL a plugin-and-go extension to Java. Any code could be written in Java or lisp immediately without complicated and cumbersome interface/translation code in most cases. There would be no huge initial hill to climb (to create all the interface code), and the usage would be natural and uncomplicated. Thanks. Blake McBride

5 14

Re: [armedbear-devel] Catching CL errors in java
by Alessio Stalla 20 Feb '13

20 Feb '13

I don't think the package is the culprit. Your package most probably USEs the CL package, or many other things would not work as you'd expect. Answering your earlier question, the correct way would be (setf *debugger-hook* ...) rather than defparameter, or even better binding instead of assigning - (let ((*debugger-hook* ...)) (do-your-stuff)). But I don't think that can make a difference between working and not working at all. It is more of a question of good style. Perhaps you're not considering thread-local bindings? If you run your defparameter/setf form on one thread, but .eval is called on another thread (and with a GUI involved, that is very probable), then chances are that the code in your .eval call is running in a dynamic environment where *debugger-hook* is locally rebound, and thus the global binding that you modify with defparameter/setf is shadowed. You can detect it by printing the value of *debugger-hook* in an .eval call triggered by the GUI. If that is the case, you should make sure to assign a new value to *debugger-hook* on the right thread, or, better, to use (let ...) as shown above. Let me stress that using LET is usually what you want in Lisp, especially when dealing with dynamic variables; a good rule of thumb is: avoid SETF and friends (defparameter is a friend) unless you're working on local variables. Of course, experts know when and how to break the rules :D but if you're a beginner, sticking to that style will make things easier to understand and debug, once you enter the right mindset. hth, Alessio On Tue, Feb 19, 2013 at 5:50 PM, Jonathan Fischer Friberg <odyssomay(a)gmail.com> wrote: > It might be that I'm in the wrong package. Although the repl is in cl-user, > and even if I change to that package the code in the previous mail has no > effect. > > Jonathan > > > On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg > <odyssomay(a)gmail.com> wrote: >> >> I don't know if this is the correct way to do it, but I did: >> >> (defparameter *debugger-hook* #'sys::%debugger-hook-function) >> >> In the repl (from running java -jar abcl.jar), this worked as expected. >> However, I can't seem to get it working with the .eval function of my >> interpreter instance. >> >> Jonathan >> >> >> On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla(a)gmail.com> >> wrote: >>> >>> Short story: if you call into Lisp using the JSR-223 API, conditions >>> are automatically rethrown as Java exceptions. >>> >>> Long story: the way this is implemented is by binding *debugger-hook* >>> to an internal, probably undocumented function, that already does what >>> you want. It is called sys::%debugger-hook-function. >>> >>> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg >>> <odyssomay(a)gmail.com> wrote: >>> > I should add that a solution from inside CL would also work. I'm using >>> > the >>> > ABCL eval to execute all code, so maybe I could wrap the call with >>> > something >>> > like this: >>> > >>> > (handler-case >>> > (... do-stuff ...) >>> > (... catch CL-condition + throw java exception ...)) >>> > >>> > I don't know if that would work. Also, my CL skills are not good enough >>> > to >>> > finish the code above (how do I capture all conditions?), so help would >>> > be >>> > appreciated. >>> > >>> > Jonathan >>> > >>> > >>> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg >>> > <odyssomay(a)gmail.com> wrote: >>> >> >>> >> Hi again, :) >>> >> >>> >> I'm currently running CL-code from java. The gui is completely >>> >> implemented >>> >> on the java side. It would be nice if all errors occuring inside abcl >>> >> could >>> >> be captured from the java side (to be displayed in the gui as an >>> >> error). Is >>> >> that possible? >>> >> >>> >> Jonathan >>> > >>> > >>> > >>> > _______________________________________________ >>> > armedbear-devel mailing list >>> > armedbear-devel(a)common-lisp.net >>> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >>> > >>> >>> >>> >>> -- >>> Some gratuitous spam: >>> >>> http://ripple-project.org Ripple, social credit system >>> http://villages.cc Villages.cc, Ripple-powered community economy >>> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM >>> http://code.google.com/p/tapulli my current open source projects >>> http://www.manydesigns.com/ ManyDesigns Portofino, open source >>> model-driven Java web application framework >> >> > -- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

2 6

[armedbear-devel] Fwd: Catching CL errors in java
by Jonathan Fischer Friberg 19 Feb '13

19 Feb '13

Sorry! Accidentally sent mail only to Alessio. If anyone else would like to help, the info/questions are below. Jonathan ---------- Forwarded message ---------- From: Jonathan Fischer Friberg <odyssomay(a)gmail.com> Date: Tue, Feb 19, 2013 at 5:50 PM Subject: Re: [armedbear-devel] Catching CL errors in java To: Alessio Stalla <alessiostalla(a)gmail.com> It might be that I'm in the wrong package. Although the repl is in cl-user, and even if I change to that package the code in the previous mail has no effect. Jonathan On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg < odyssomay(a)gmail.com> wrote: > I don't know if this is the correct way to do it, but I did: > > (defparameter *debugger-hook* #'sys::%debugger-hook-function) > > In the repl (from running java -jar abcl.jar), this worked as expected. > However, I can't seem to get it working with the .eval function of my > interpreter instance. > > Jonathan > > > On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla(a)gmail.com>wrote: > >> Short story: if you call into Lisp using the JSR-223 API, conditions >> are automatically rethrown as Java exceptions. >> >> Long story: the way this is implemented is by binding *debugger-hook* >> to an internal, probably undocumented function, that already does what >> you want. It is called sys::%debugger-hook-function. >> >> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg >> <odyssomay(a)gmail.com> wrote: >> > I should add that a solution from inside CL would also work. I'm using >> the >> > ABCL eval to execute all code, so maybe I could wrap the call with >> something >> > like this: >> > >> > (handler-case >> > (... do-stuff ...) >> > (... catch CL-condition + throw java exception ...)) >> > >> > I don't know if that would work. Also, my CL skills are not good enough >> to >> > finish the code above (how do I capture all conditions?), so help would >> be >> > appreciated. >> > >> > Jonathan >> > >> > >> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg >> > <odyssomay(a)gmail.com> wrote: >> >> >> >> Hi again, :) >> >> >> >> I'm currently running CL-code from java. The gui is completely >> implemented >> >> on the java side. It would be nice if all errors occuring inside abcl >> could >> >> be captured from the java side (to be displayed in the gui as an >> error). Is >> >> that possible? >> >> >> >> Jonathan >> > >> > >> > >> > _______________________________________________ >> > armedbear-devel mailing list >> > armedbear-devel(a)common-lisp.net >> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >> > >> >> >> >> -- >> Some gratuitous spam: >> >> http://ripple-project.org Ripple, social credit system >> http://villages.cc Villages.cc, Ripple-powered community economy >> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM >> http://code.google.com/p/tapulli my current open source projects >> http://www.manydesigns.com/ ManyDesigns Portofino, open source >> model-driven Java web application framework >> > >

1 0

[armedbear-devel] Catching CL errors in java
by Jonathan Fischer Friberg 19 Feb '13

19 Feb '13

Hi again, :) I'm currently running CL-code from java. The gui is completely implemented on the java side. It would be nice if all errors occuring inside abcl could be captured from the java side (to be displayed in the gui as an error). Is that possible? Jonathan

2 2

[armedbear-devel] Predicate Dispatching
by Blake McBride 18 Feb '13

18 Feb '13

The following is a link to an article talking about Predicate Dispatching in CLOS. I think this may solve the problem I have been speaking about - dispatching based on number and types of arguments. Thought I'd share the idea: http://people.csail.mit.edu/jrb/Projects/ucko-thesis.pdf Would love to hear some opinions. Thanks. Blake

1 0

[armedbear-devel] Problem building documentation
by Blake McBride 16 Feb '13

16 Feb '13

In order to build the tex documentation from the trunk I had to edit abcl.tex as follows: --- abcl.tex~ 2013-02-16 09:01:31.000000000 -0600 +++ abcl.tex 2013-02-16 09:02:04.000000000 -0600 @@ -892,7 +892,7 @@ will load and execute the Quicklisp setup code. The implementation currently breaks \textsc{ANSI} conformance by allowing the -types able to be \code{CL:READ} for the \var{DEVICE} to return a possible \code{CONS} of +types able to be \code{CL:READ} for the \code{DEVICE} to return a possible \code{CONS} of \code{CL:PATHNAME} objects. %% citation from CLHS needed. In order to ``smooth over'' the bit about types being \code{CL:READ} from

2 1

[armedbear-devel] ASDF 2.29 released
by Faré 16 Feb '13

16 Feb '13

Dear ABCL developers, ASDF 2.27 was a major rewrite of ASDF, and everything since then should be considered as candidate releases for ASDF 3: http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… ASDF 2.28 was released shortly after 2.27, without an announcement, to fix an issue found by Stelian Ionescu using TEST-OP on some systems. ASDF 2.29 is a stability release, with which I'm once again inviting implementers to update the ASDF they distribute. Please update ABCL to use ASDF 2.29. NB: I haven't looked at ASDF-JAR yet, but it would probably be a good thing to merge it with our bundle support. Since ASDF 2.27, ASDF 2.29 further brings: * deferred-warnings support for Allegro, CMUCL, SCL; fixes to the CCL support. * Upgrade fixes regarding fallback system versions; making it possible (via massive use of eval-when) to compile ASDF without loading it first. * Compatibility with private use of :D package nickname by not claiming it for package ASDF/DRIVER anymore. Also explicitly handle NIL in safe-file-write-date, in case the implementation doesn't issue a file-error in that case; make UTF-8 the default encoding for with-input-file. Be portable to #+(and sbcl (not sb-eval)). * Bugfixes to old bugs: inline-methods can now be unqualified (lp#485393), defsystem-depends-on accepts arbitrary specs, not just names (lp#1027521). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Inside of many liberals is a fascist struggling to get out. — John McCarthy

2 1

[armedbear-devel] Using ABCL with large Java app
by Blake McBride 16 Feb '13

16 Feb '13

Greetings, I have a large Java app with more than 15K Java classes. I linked it up with ABCL and successfully used it in several places. However, I had a couple of problems that caused me to use ABCL significantly less than I had hoped. I thought I would share my problems and perhaps there might be a helpful suggestion. Although I don't interface with most of the 15K Java classes, there are still a lot of classes to interface ABCL with. I wrote some lisp code that, through Java reflection, creates CLOS classes that mirror the Java classes I wish to interface with. In CLOS it encapsulates the Java instance, mirrors the class hierarchy, and creates generics to match the Java methods. I found a way to create variable argument generics that feed fixed argument methods in order to handle the fact that similarly named methods can take different arguments across different Java classes. I ran into two problems that have caused me to use ABCL much less than I'd like to. The first seems like won't be too hard to solve, but the second is something I still need to find a solution to. Remember, I cannot build this interface manually. There are too many classes and methods. The first problem is that I have Java classes and instances mirrored as CLOS classes and instances. At times it was more convenient (from lisp) to deal with Java objects directly instead of CLOS mirrors. While it was more convenient, it ended up being too confusing. With all these classes, objects, and methods, it was too easy to forget what the heck I was dealing with at any point in the code. I think the only answer to this is to only deal with lisp objects when in lisp. This would avoid the confusion at the cost of wrapping and unwrapping certain Java objects at times - not too bad. I would need to have a way to pack Jeve arguments from Jave when calling Lisp. Doing it in Lisp is a problem because I am back to the confusion of knowing when I am dealing with a Java object and when a lisp object. The second problem has to do with the fact that a single Java class can use the same method name multiple times with different arguments. Remember, I am using variable argument generics to handle similar Java method names taking different argument across different classes. I still have argument checking because I dispatch to a fixed argument CLOS method. However, I cannot do this within a single class. The first obvious answer is to name mangle the generics. This is too sloppy. The other answer would be to name mangle the methods and have the generic be smart enough to dispatch to the correct method based on the argument number and types (all in CLOS). This would be a lot of work so I thought I might solicit alternative suggestions. Perhaps there is a simple answer that I hasn't come to me. Thanks. Blake McBride

3 6

[armedbear-devel] abcl-1.1.1 released
by Mark Evenson 14 Feb '13

14 Feb '13

On behalf of the ABCL developers, I am pleased to announce the release of abcl-1.1.1, a maintenance release which addressed the following issues: * (A)MOP All reported errors with the MOP implementation have been addressed. * SETF autoloader An autoloader for SETF expansion functions has been implemented, eliminating the errors associated with not being able to use (SETF SYMBOL) without first invoking SYMBOL as a function. * ANSI Tests All outstanding regressions in the ANSI test suite with respect to abcl-1.0.1 have been fixed. * ABCL-ASDF The ability to resolve Maven components in ASDF system definitions has been restored. downloads: http://common-lisp.net/project/armedbear/releases/1.1.1/ source: http://svn.common-lisp.net/armedbear/tags/1.1.1/abcl/ manual: http://abcl-dynamic-install.googlecode.com/files/abcl-20130214a.pdf -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0