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

[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

[armedbear-devel] Running abcl outside awt thread
by Jonathan Fischer Friberg 04 Feb '13

04 Feb '13

Hi, It seems that abcl is currently running on the awt thread. As when I get an error, it says something along the lines "#<THREAD "AWT-EventQueue-0" {3C6B5}>" This has some nasty side effects, namely: 1. eval blocks the ui (until the eval has finished) 2. On error, the version 1.1.0 locks down the ui completely. That is, the ui locks and doesn't come back. So it would be nice if I could run abcl on it's own separate thread. Is such a thing possible? I guess in worst case I'll have to start up a separate thread in the eval (that is, in common lisp), which I think would do what I want. I would prefer to have the whole of abcl in its' own thread though. Jonathan

4 3

[armedbear-devel] patch for automagical JAR loading
by Milos Negovanovic 30 Jan '13

30 Jan '13

Hi all, patch is attached. With it this kind of .asd spec works out of the box and resolves all JARs and puts them in classpath: (require :asdf) (require :abcl-contrib) (require :abcl-asdf) (require :jss) (asdf:defsystem #:test-asdf :serial t :description "" :author "" :license "Specify license here" :components ((:module jetty :serial t :components ((:mvn "org.eclipse.jetty/jetty-server/8.1.8.v20121106") (:mvn "org.freemarker/freemarker/2.3.19"))) (:module source :pathname "" :serial t :components ((:file "package") (:file "example")) :depends-on (:jetty)))) The bug is someplace in abcl-asdf:resolve ... didnt figure out where, i just used abcl-asdf:resolve-dependencies ... not sure why you want resolving code in 2 places anyway :). Regards -- Milos Negovanovic milos.negovanovic(a)gmail.com

1 0

[armedbear-devel] patch for runtime-class.lisp
by Milos Negovanovic 29 Jan '13

29 Jan '13

Hi all, As mentioned on #abcl on freenode, I needed the following patch to make my simple jetty example work. Patch is attached. Example for which I needed this is at: http://paste.lisp.org/display/134966 Regards -- Milos Negovanovic milos.negovanovic(a)gmail.com

2 1

[armedbear-devel] ASDF support for deferred warnings in ABCL?
by Faré 27 Jan '13

27 Jan '13

Dear ABCL developers, I've been adding support for ASDF to save deferred warnings (typically, forward function references) in a file, so that if you do an incremental compilation, warnings from previously compiled files are still correctly handled at the end of the virtual with-compilation-unit. I've added support for SBCL and CCL myself, which was made much easier by being able to read the source code to their compilers, but I don't feel like groveling through four more free sofware compilers. Would you be interested in implementing the same feature for ABCL, or at least in guiding me on how to do so? The code is mainly in asdf/lisp-build.lisp functions reify-deferred-warnings unreify-deferred-warnings reset-deferred-warnings. http://common-lisp.net/gitweb?p=projects/asdf/asdf.git Best regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I don't know if might makes right, but lack of might sure makes lack of right.

2 1

[armedbear-devel] abcl-1.1.0 vs. abcl-1.1.0.2 known differences
by Mark Evenson 25 Jan '13

25 Jan '13

To address a question that came up on #abcl: what is the difference between the abcl-1.1.0 and abcl-1.1.0.2 releases? The short answer is that there should be no difference. The release of abcl-1.1.0 (and accompanying signatures) were updated "in-place" within twenty-four hours of their release. As stated in the abcl-1.1.0.2 release announcement, the only known initial difference between the 1.1.0 and 1.1.0.2 releases of ABCL was that somehow the ABCL-CONTRIB ASDF definition in 1.1.0 was syntactically invalid as it included an extra comma (",") character preventing it from loading. After this was discovered, the abcl-1.1.0 release was rebuilt and "updated" in place on common-lisp.net. Because googlecode requires that published URIs point idempotently to their resources over time (probably to make universal distribution easier) a release designated abcl-1.1.0.2 release was made to googlecode.com If there are any observed differences between the two releases, I would appreciate knowing more details accompanied by information on how the distribution was obtained. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Upgrade issues
by Faré 24 Jan '13

24 Jan '13

ABCL is one of the three implementations, together with CLISP and CMUCL, where I ultimately punted on ASDF hot-upgrade, by just trying to rename away the ASDF package if it's too old. I don't know if you're interested in making the kind of package surgery I was indulging in work, but it involves rehoming symbols from ASDF to subpackages such as ASDF/COMPONENT, including for class slot names. Anyway, please test the latest ASDF with ABCL, I think it's ripe for release, but I'd like your feedback considering the massive amount of hacking that happened. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If the human mind were simple enough to understand, we'd be too simple to understand it. — Pat Bahn

4 7