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

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] Stack overflow when compiler macro with fallback is triggered
by James M. Lawrence 12 Aug '12

12 Aug '12

(eval-when (:compile-toplevel :load-toplevel :execute) (defun foo () 99) (define-compiler-macro foo () `(locally (declare (notinline foo)) (foo)))) (defun call-foo () (foo)) Of course, the use case is a compiler macro that says, "OK, let's optimize! ... Never mind, I don't want to optimize that." Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.7.0_04 Oracle Corporation [...] ; (DEFUN FOO ...) ; (DEFINE-COMPILER-MACRO FOO ...) ; (DEFUN CALL-FOO ...) java.lang.StackOverflowError at org.armedbear.lisp.StructureObject$pf_make_structure.execute(StructureObject.java:671) at org.armedbear.lisp.Symbol.execute(Symbol.java:865) at org.armedbear.lisp.LispThread.execute(LispThread.java:760) at org.armedbear.lisp.jvm_714.execute(jvm.lisp:567) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.jvm_746.execute(jvm.lisp:572) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) [...]

5 5

[armedbear-devel] Double printing of the prompt
by Blake McBride 12 Aug '12

12 Aug '12

Greetings, The latest version of ABCL is double printing the prompt at times as follows: Armed Bear Common Lisp 1.1.0-dev-svn-13783 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.465 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): 3 3 CL-USER(2): 'hello HELLO CL-USER(3): '(a b c) (A B C) CL-USER(4): nil NIL CL-USER(5): CL-USER(5): 77 77 CL-USER(6): (cdr '(hello)) NIL CL-USER(7): nil NIL CL-USER(8): CL-USER(8): 3 3 CL-USER(9):

3 3

[armedbear-devel] destroy-thread and unwind-protect
by James Lawrence 08 Aug '12

08 Aug '12

(defun test-cleanup () (let* ((cleanedp nil) (thread (threads:make-thread (lambda () (unwind-protect (sleep 999) (setf cleanedp t)))))) (sleep 0.5) (threads:destroy-thread thread) (sleep 0.5) cleanedp)) (test-cleanup) ABCL-1.0.0 and ABCL-0.27.0 return NIL. Other implementations I tested all return T -- Allegro, Clozure, LispWorks, SBCL (changing "threads" to "bordeaux-threads"). Of course this isn't a bug since ABCL is free to do what it wishes. Does ABCL wish that?

5 5

[armedbear-devel] asdf::*OPERATING-SYSTEM* => :solaris for (LISP-IMPLEMENTATION-VERSION) => "1.0.1-svn-13750-13751"
by Alan Ruttenberg 28 Jun '12

28 Jun '12

Don't know if this is fixed in a later version, but I was noticing asdf put my binaries in an odd-looking directory. -Alan

2 1

[armedbear-devel] Fwd: How to compile and run Maxima with ABCL?
by Phuc Luoi 24 Jun '12

24 Jun '12

---------- Forwarded message ---------- From: Phuc Luoi <phucluoi(a)gmail.com> Date: Tue, Jun 19, 2012 at 12:51 PM Subject: Re: [armedbear-devel] How to compile and run Maxima with ABCL? To: Robert Dodier <robert.dodier(a)gmail.com> Thanks for your answer. I tried this and got these errors: Can't intern zero-length symbol. Restarts: 0: RETRY Retry compiling #<ASDF:CL-SOURCE-FILE "maxima" "utilities" "mformt">. 1: ACCEPT Continue, treating compiling #<ASDF:CL-SOURCE-FILE "maxima" "utilities" "mformt"> as having been successful. 2: TOP-LEVEL Return to top level. by compiling the file /maxima-5.27.0/src/mformt.lisp (step 9) I have choose the option 1 to accept this. I got some more errors by compiling. After all I got Out of memory PermGen space Restarts: 0: TOP-LEVEL Return to top level. and abcl did not compiled maxima. Can you tell me why I got these error? And how can repair them? On Tue, Jun 19, 2012 at 5:04 AM, Robert Dodier <robert.dodier(a)gmail.com> wrote: > On 2012-06-16, Phuc Luoi <phucluoi(a)gmail.com> wrote: > >> How can I compile and run Maxima with ABCL? > > (1) Unpack a Maxima tarball. > http://sourceforge.net/projects/maxima and follow links to download page. > Look for "Maxima-source". > > (2) cd /path/to/maxima-5.27.0 > > (3) java -jar /path/to/abcl.jar > > (4) (configure) ;; you can probably accept defaults for most/all questions > > (5) (quit) > > (6) cd src > > (7) java -jar /path/to/abcl.jar > > (8) (require 'asdf) > > (9) (asdf:operate 'asdf:load-op :maxima) > > (10) (quit) > > (11) java -jar /path/to/abcl.jar > > (12) (require 'asdf) > > (13) (asdf:operate 'asdf:load-op :maxima) ;; yes, same as (9) > > (14) (cl-user::run) ;; should bring up Maxima banner & input prompt > > >> Furthermore can I emmbed maxima in a Java Programm with ABCL? > > Yes. I've appended an example program. Command line to compile it: > > javac -cp /path/to/abcl.jar -d /path/to/compiled/class abcl_maxima.java > > To execute it: (you must be in the Maxima src directory) > > java -cp /path/to/compiled/class:/path/to/abcl.jar abcl_maxima > > I get: (takes a minute or two to load Maxima) > > loading Maxima ... finished. > x.getClass => class org.armedbear.lisp.Cons > x = org.armedbear.lisp.Cons@1748ba8 > x.javaInstance => org.armedbear.lisp.Cons@1748ba8 > x.javaInstance.getClass => class org.armedbear.lisp.Cons > 4 factors of 12341234 > factor: 2, multiplicity: 1 > factor: 73, multiplicity: 1 > factor: 137, multiplicity: 1 > factor: 617, multiplicity: 1 > > > Note that all user functions have names which begin with dollar sign. > E.g. user function ifactors <==> $IFACTORS in Lisp > > If you need help with Lisp programming for Maxima, ask questions on the > mailing list. See: http://maxima.sourceforge.net/maximalist.html > > Hope this helps, have fun, & good luck. > > Robert Dodier > > PS. Example program abcl_maxima.java: > > // abcl_maxima.java -- example program for calling Maxima from Java via ABCL > // copyright 2012 by Robert Dodier > // I release this work under terms of the GNU General Public License > > import org.armedbear.lisp.Interpreter; > import org.armedbear.lisp.Package; > import org.armedbear.lisp.Packages; > import org.armedbear.lisp.Symbol; > import org.armedbear.lisp.Function; > import org.armedbear.lisp.LispObject; > import org.armedbear.lisp.Fixnum; > import org.armedbear.lisp.Bignum; > import org.armedbear.lisp.Cons; > > public class abcl_maxima > { > public static void main (String [] args) throws Exception > { > int a; > > if (args.length > 0) > a = Integer.parseInt (args [0]); > else > a = 12341234; > > Interpreter I = Interpreter.createInstance (); > System.out.print ("loading Maxima ... "); > I.eval ("(require 'asdf)"); > I.eval ("(asdf:operate 'asdf:load-op :maxima)"); > System.out.println ("finished."); > Package P = Packages.findPackage ("MAXIMA"); > > // java.util.List <Symbol> L = P.getAccessibleSymbols (); > // for (Symbol S : L) > // { > // if (P.equals (S.getPackage ())) > // System.out.println (S.toString ()); > // } > > Symbol S = P.findAccessibleSymbol ("$IFACTORS"); > Function F = (Function) S.getSymbolFunction (); > LispObject x = Bignum.getInstance (a); > x = F.execute (x); > System.out.println ("x.getClass => " + x.getClass ()); > System.out.println ("x = " + x); > System.out.println ("x.javaInstance => " + x.javaInstance ()); > System.out.println ("x.javaInstance.getClass => " + x.javaInstance () . getClass ()); > > int n = ((Cons) x).length (); > System.out.println ((n - 1) + " factors of " + a); > > for (int i = 1; i < n; i++) > { > Cons x1 = (Cons) ((Cons) x).NTH (i); > Fixnum f = (Fixnum) x1.NTH (1); > Fixnum m = (Fixnum) x1.NTH (2); > System.out.println ("factor: " + f.intValue () + ", multiplicity: " + m.intValue ()); > } > } > } > > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 16

[armedbear-devel] Does ABCL reload abcl.jar after it starts up?
by Marshall 21 Jun '12

21 Jun '12

I have a quick (I hope) question. Does ABCL reload abcl.jar after it starts up? Or do something else unusual with the jar once it's running? Context: I'm exploring using ABCL as an add-on to NetLogo, an agent-based modeling environment. (It might be more correct to say that I'm using NetLogo as an add-on to ABCL, since the primary code is in Lisp.) With the add-on method, NetLogo "extensions", one usually doesn't have to tell NetLogo where additional jars such as abcl.jar can be found. As long as they're in the extension's own directory, NetLogo will find the extra jars. This is apparently due to a little bit of voodoo that NetLogo engages in. However, in the case of my ABCL extension, NetLogo will load the extension, but then generate an error when I invoke ABCL via Interpreter.evaluate(). The problem is avoided if specify abcl.jar in the classpath explicitly, either on the command line (undesirable for NetLogo), or by adding abcl.jar to the classpath in Java (which works fine--so that's what I'm doing). Just curious about what ABCL is doing--thanks. (The ABCL NetLogo extension is very simple, now that I've figured out the details, and seems to be working beautifully, by the way. I'm surprised that there haven't been some glitches. It just works.) Marshall Abrams mabrams(a)uab.edu

2 1

[armedbear-devel] How to compile and run Maxima with ABCL?
by Phuc Luoi 19 Jun '12

19 Jun '12

Hello, How can I compile and run Maxima with ABCL? Furthermore can I emmbed maxima in a Java Programm with ABCL? Hong Phuc

2 1

[armedbear-devel] asdf 2.22 released
by Faré 13 Jun '12

13 Jun '12

I am pleased to announce the release of ASDF 2.22. Since previous release 2.21, the changes are as follow: * require is now mapped to the recently defined require-system, not to load-system anymore. * more sensible inheritance semantics for default-component-class, which can be either a class or a class name. (hat tip to Nikodemus) * accept wildcards in directory-files for physical pathnames. (hat tip to Erik Pearson). These changes are few and subtle, but nonetheless significant to those who'd use these features. As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pyramid schemes are illegal. Social Security is a pyramid scheme.

2 1

[armedbear-devel] jfli-abcl revisited
by Alex Mizrahi 12 Jun '12

12 Jun '12

hi Some people mentioned that keeping jfli interface is desirable. Also I've noticed a problem with Ole's version: java array accessor (jref) doesn't do boxing correctly. It isn't a big deal, but I kinda used that functionality, and I have no idea what motivated those changes so I don't know to to fix them correctly. So I went back to original jfli-abcl version by Andras Simon and did minimal amount of changes to make it work with new version. Also there are several conservative improvements. Here it is: https://gist.github.com/2916760#file_jfli.lisp And here's a diff against jfli-abcl.lisp still available on Andras' site: https://gist.github.com/2916760#file_jfli_abcl.diff (This one: http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar ) Here's a description of changes: 1. make-immediate-object is deprecated now, so we use java:+null+ and friends 2. boxing extension by A. Vodonosov is described in comment 3. ensure-java-class was renamed to %ensure-java-class to avoid collision with java:ensure-java-class which does completely different thing. (I thought about shadowing it, but I think renaming makes it clearer.) 4. support for both int and long in overloads (or however they are called in Java) 5. new-class functionality was commented out because abcl-side interface have changed. (together with its helper jrc) As I understand, Alessio already reimplemented jnew-runtime-class, so we just need some brave soul to adapt code to new APi and implement missing parts This isn't particularly hard, I think, but I'm not interested in new-class at all, so I wouldn't do this. And for the sake of completeness here's diff between original jfli-abcl and Ole's version: https://gist.github.com/2916945 It seems that the major difference is "Ripped out CLOS mirror support". I have no idea if 'CLOS mirror support' is required according to jfli spec or it is useless. Also there is a lot of refactoring. Which is great, but it can break things... So again, unless somebody has resources to check Ole's changes and verify that they adhere to jfli documentation, I recommend replacing it with my 'conservative' version in ABCL's contrib repo. Also, I've noticed that jfli maintainer said it would be cool to merge different versions, but I don't think it's necessary: the only common part is defpackage, pretty much all the code is specific to ABCL. (This was true for old jfli version, at least.) So it's better to treat jfli as a specification rather than as a library.

2 1