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

[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

[armedbear-devel] Figuring out the provenance of trunk
by Mark Evenson 11 Jun '12

11 Jun '12

Over the course of maintaining the Bear, it has become clear to me that we have pieces of code in trunk whose original licensing terms indicate that their author should be contacted as to their status, especially when they would conflict with the terms we distribute under, namely those of the GNU Public License. Recently I discovered such a licensing lacunae [in working with Jorge Tavares to patch the CL:SORT and CL:STABLE-SORT routines][1], that 'sort.lisp' contains code that has both SBCL and ECL code attributions. Are we in violation of anything here? Dunno. But we certainly have *lots* of SBCL tucked into our tree… We obviously need an estimate of our non-compliance. As a first step, it seems useful to construct/use a tool that allows us to establish provenance of all commits to ABCL trunk. With this history in hand, we can start figuring out the set of all authors to work through potential conflicts. A fair amount of work for a non-specialist, but anyone who does this regularly should have an analysis toolset lying around that they could apply to [ABCL trunk][2]. Is there a language lawyer geek in the house? [1]: http://trac.common-lisp.net/armedbear/ticket/196 [2]: https://code.google.com/p/abcl-dynamic-install/source/browse/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

3 3

[armedbear-devel] Patch to quicklisp/cffi-0.7.1 for abcl-1.1.0-dev
by Mark Evenson 30 May '12

30 May '12

Mebbe [this can help somewhat with the problems loading JNA automatically for CFFI on ABCL][1]. I still need to figure out exactly what is broken under which JVM/OS combinations. Interesting stuff in analyzing regressions. [1]: http://slack.net/~evenson/quicklisp/cffi-abcl-1.1.0-dev-20120530a.patch -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Is anybody interested in jfli-abcl?
by Alex Mizrahi 29 May '12

29 May '12

jfli-abcl, basically, allows one to quickly create Lisp function wrappers for Java classes. E.g. (def-java-class "java.sql.DriverManager") (use-package :|java.sql|) (DriverManager.getConnection ...) The benefit over java:jcall and JSS is that it looks more-or-less like normal Lisp function calls, pretty similar to a wrapper you could write yourself. Also, potentially, it might carry less runtime overhead because everything can be resolved at compile-time. And if you use SLIME, auto-completion works. It doesn't like mixed case, though, so you need to write it like (|java.sql|:drivermanager.getcollection ...) Still, better than nothing. As far as I can tell, jfli-abcl isn't currently maintained. But as I'm used to jfli-abcl I maintain my own version with some fixes. If there is any interest in jfli-abcl I could, perhaps,. publish my version and polish it a bit. (I'm personally not interested in new-class functionality which allows one to create Java class from Lisp.) (I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/… But haven't yet checked if it works with latest ABCL and what are improvements against old one.)

6 11

[armedbear-devel] Fwd: Is anybody interested in jfli-abcl?
by Anton Vodonosov 28 May '12

28 May '12

[forwarding Alessio's reply to the list - was my mistake to send the previous letter to him directly, instead of Reply All] ----------------------------------------------------------------------------------------------------- 28.05.2012, 17:25, "Alessio Stalla" <alessiostalla(a)gmail.com>: On Mon, May 28, 2012 at 3:18 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > 28.05.2012, 17:08, "Alessio Stalla" <alessiostalla(a)gmail.com>: >> On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >>> 28.05.2012, 16:22, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>>> If independent version of new-class is not ready, probably it's possible to >>>> deliver runtime-class a a contrib [...] >>> I've checked the ABCL sources and see that runtime-class.lisp is now >>> included into ABCL. So we don't even need to create a contrib for it. >>> >>> Could anyone help me understand the problem with new-class, why removing >>> it? Namely, when the asm.jar will be needed, >>> >>> What I understand now: >>> >>> 1. abcl-jfli function jrc calls java:jnew-runtime-class. >>> 2. java:jnew-runtime-class needs asm.jar. >> 2. is wrong. jnew-runtime-class used to require asm, was disabled, and >> was reintroduced (incomplete) without a dependency to asm and with a >> slightly different API. In other words, jrc right now is probably >> broken. >> >> To restore jrc right now, you'd need to restore runtime-class.lisp >> from version control, and bundle it in contrib under a different >> package (assuming it still works with present-day asm). > Ah I see, it's different runtime-class. Thanks for the explanation. >> That would be possible, but I object that having 2 different APIs for >> the same thing is a potential source for confusion. > Yes, but it's also the way of software evolution: we use some API, > notice it's deficiencies, deprecate it and introduce new, better > API. Let me note that it could have been called runtime-class2 > to avoid confusion and compatibility issues. Yes, maybe it could, but the situation as I saw it was that runtime-class was effectively dead code nobody was using (and in fact, until now nobody asked about it on this list). > Probably now, if packaging the old runtime-class as a contrib, we will > need to rename it to old-runtime-class, or even deprecated-runtime-class. Or just deprecated:runtime-class, or backwards-compatibility:..., so you can shadowing-import-from it and forget about it. > Could you explain about the asm.jar dependency in case of the > deprecated-runtime-class? Would it be a load-time dependency, > or a call-time dependency? IIRC, it is a call-time dependency, but note that I never used the old runtime-class, so I may be wrong. Alessio -- 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 1

[armedbear-devel] Fwd: Is anybody interested in jfli-abcl?
by Anton Vodonosov 28 May '12

28 May '12

28.05.2012, 17:08, "Alessio Stalla" <alessiostalla(a)gmail.com>: > On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >> 28.05.2012, 16:22, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>> If independent version of new-class is not ready, probably it's possible to >>> deliver runtime-class a a contrib [...] >> I've checked the ABCL sources and see that runtime-class.lisp is now >> included into ABCL. So we don't even need to create a contrib for it. >> >> Could anyone help me understand the problem with new-class, why removing >> it? Namely, when the asm.jar will be needed, >> >> What I understand now: >> >> 1. abcl-jfli function jrc calls java:jnew-runtime-class. >> 2. java:jnew-runtime-class needs asm.jar. > 2. is wrong. jnew-runtime-class used to require asm, was disabled, and > was reintroduced (incomplete) without a dependency to asm and with a > slightly different API. In other words, jrc right now is probably > broken. > > To restore jrc right now, you'd need to restore runtime-class.lisp > from version control, and bundle it in contrib under a different > package (assuming it still works with present-day asm). Ah I see, it's different runtime-class. Thanks for the explanation. > That would be possible, but I object that having 2 different APIs for > the same thing is a potential source for confusion. Yes, but it's also the way of software evolution: we use some API, notice it's deficiencies, deprecate it and introduce new, better API. Let me note that it could have been called runtime-class2 to avoid confusion and compatibility issues. Probably now, if packaging the old runtime-class as a contrib, we will need to rename it to old-runtime-class, or even deprecated-runtime-class. Could you explain about the asm.jar dependency in case of the deprecated-runtime-class? Would it be a load-time dependency, or a call-time dependency? Best regards, - Anton

1 0

[armedbear-devel] abcl trunk build doesn't work for me
by Alex Mizrahi 27 May '12

27 May '12

hi When I run ABCL built from trunk I get this error when I run it: ---- Armed Bear Common Lisp 1.1.0-dev Java 1.6.0_21 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 1.072 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.Lisp.error(Lisp.java:380) at org.armedbear.lisp.Load.loadSystemFile(Load.java:276) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:703) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:550) at org.armedbear.lisp.Lisp.eval(Lisp.java:515) at org.armedbear.lisp.Load.loadStream(Load.java:570) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:538) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:428) at org.armedbear.lisp.Load.loadSystemFile(Load.java:327) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:679) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads' in boot classpath. ---- I tried both version from SVN and from Mark's (?) hg repo, upgraded OpenJDK to 1.6.0_21, upgraded ant from 1.7.1 to 1.8.0 (that's top version I can get via package manager for Ubuntu 10.04). I was able to build and run ABCL 1.0.1. I noticed a bug on abcl 1.0.1: in certain rather contrived code return-from was ignored, i.e. evaluation continued as if it wasn't called. And was going to check whether it's present in the latest devel version before investigating it further.

4 7