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

[armedbear-devel] Fwd: Question about jnew-runtime-class
by archisman rudra 21 Sep '12

21 Sep '12

[Possibly duplicate post, sorry] Hi Alessio, Thanks for the quick and detailed response. Interesting! I'm answering because I wrote the current (incomplete) > version of jnew-runtime-class. Just FYI, you can find some notes about > it at <http://trac.common-lisp.net/armedbear/wiki/JavaFfi/RuntimeClass>. > I read that, and that did help a lot in understanding the new code. BTW, regarding the constructors, shouldn't you be able to define a method entry with name as :constructor and have that work? From looking at the function map-method-name in jvm-class-file.lisp, but not actually tested it yet. > What I wanted to achieve is to have methods that can be: > * arbitrary functions, including closures > * possibly redefined after the class has been loaded. Redefinition is > possible by using symbols as method implementations. > > There's also a hidden goal that is to keep the implementation simple > enough, and compiling Lisp code to the body of methods in an arbitrary > class is not easy at the moment. > > What explicitly is NOT a requirement is to have the generated class be > independent from ABCL (the methods are implemented in Lisp and will > always need runtime support). So, no matter how you arrange things, > you will never be able to distribute your class without abcl.jar. Note > that it is the same for Clojure, Scala, Groovy, etc. > > I don't know specifically how Hadoop works, but, as I see things, you need > to > 1. provide abcl.jar + your class to it > 2. have Hadoop execute enough code to load ABCL and initialize your class. > > Right. This is the same in clojure where I implemented something similar, but the language was unfamiliar and the way to actually call compile felt clunky, but some of that surely was simply unfamiliarity. So what I want to do is the following: 1. have abcl.jar and generated_filename_with_method_implementations.lisp in the classpath 2. Do the jvm equivalent of the following java code: Interpreter interp = Interpreter.createInstance(); interp.eval("(load \"generated_filename_with_method_implementations.lisp\")"); in the static initialization block of the class. > Now, probably the key point is who loads your class. > * if you can arrange to have ABCL load it and pass it to Hadoop, you > should be good with the current design. > * if Hadoop wants to load it by itself from a jar, then yes, you have > to somehow dump the method implementations somewhere and have the > class auto-load them from there when it is initialized. > > For the second case, I propose an intermediate design that is, imho, > simpler than dumping arbitrary forms: special-case the situation when > a method implementation is a symbol. In that case, directly generate > an instruction in the class file to find that symbol in its package > and assign it to the appropriate field. If the implementation of a > method is not a symbol nothing changes. That way, you will still need > to init ABCL before loading your class, but, when all your method > implementations are symbols, the class will be able to initialize > itself without external support. If some methods are proper functions, > instead, the class won't be self-contained, but will need some Lisp > code to be executed to be properly initialized. > > Does it make sense to you? Do you find it acceptable? If yes, I can > give a shot at implementing it, if you want. > > This certainly seems reasonable, but I don't understand the bit about "directly generate an instruction to find the package and do the assignement". Do I not need to change the compile infrastructure to get at the jvm representation of the (fdefinition name) ? The code in %jvm-compile (in compiler-pass2.lisp) seems to do the compilation to a (sys::%make-byte-array-output-stream) rather than to arbitrary output-streams. Don't know the reason for this. If this can be changed, we can do this for arbitrary forms, rather than just symbols. ie, we can compile the relevant forms into classname_methodname.abcl and generate a static method call to Load.load(filename) in the static init block as before, to do the autoloading, and then we will know the LispObject name holding the jmethod and can assign that to the appropriate field as you suggest above. Other than this (the compile issue), I find this entirely reasonable and would love it if you do implement it. much regards, Archi > Peace, > 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 0

[armedbear-devel] Closer-mop support for ABCL
by Rudi Schlatte 19 Sep '12

19 Sep '12

Greetings, ABCL 1.1, expected in 2-3 months from now, will have a mop implementation that passes the mop test suite without missing features. The work is finished in svn and can be checked out at http://svn.common-lisp.net/armedbear/trunk/abcl/. It would be great if we had closer-mop support by release time; attached is a naive patch (which assumes that abcl needs nothing in closer-mop-shared). I also re-send the abcl patch for mop-feature-tests. The closer-mop patch is written to give an error if :mop isn't on *features*, this feature is present in the mop-supporting svn version of abcl and will be in the released version as well, so if you decide to merge the patch, users of the old release will get a sensible error message. Cheers, Rudi

3 17

[armedbear-devel] NEWBIE
by emeka okafor 13 Sep '12

13 Sep '12

Hello Guys, I would like to use abcl on some project and I have a couple of questions for you guys: - What IDE do you guys use? - What build system do you use? - Can I integrate abcl in maven? Thx.

5 6

[armedbear-devel] Ansi tests fail to execute
by Rudolf Schlatte 05 Sep '12

05 Sep '12

Hi, Currently the ansi test suite crashes with this error: Error loading /Users/rudi/Source/ansi-tests/load-arrays.lsp at line 3 (offset 55) #<THREAD "interpreter" {712A95C7}>: Debugger invoked on condition of type TYPE-ERROR The value CL-TEST::OPTIONS is not of type LIST. Restarts: 0: TOP-LEVEL Return to top level. According to git bisect, the offending commit is r14130 (Replace a Java primitive LAMBDA-LIST-NAMES with a lisp function) although I haven't investigated further yet. Rudi

2 2

[armedbear-devel] changes to autoloading affecting PermGen space?
by Alan Ruttenberg 05 Sep '12

05 Sep '12

I've recently been getting ; Evaluation aborted on #<JAVA-EXCEPTION java.lang.OutOfMemoryError: PermGen space {2D9FD5EA}>. I'm wondering whether it is possible that the recent changes to autoloading are filling more of this space, leading to my (and presumably others at some point) errors. -Alan

3 5

[armedbear-devel] CLOS / D-M-C tests failure DMC-TEST-MC.1 help requested
by Erik Huelsmann 31 Aug '12

31 Aug '12

Hi all, In an attempt to solve ticket 201 and everything related (now that I'm into it anyway), I've been staring at the failure of one of ABCL's own tests and can't seem to understand what's going on. So, DMC-TEST-MC.1 is failing because it uses a non-standard METHOD-QUALIFIER. STD-COMPUTE-EFFECTIVE-METHOD throws an error when matching the qualifiers of the defined methods with the method groups and finds that the method combination isn't one of type long-form. However, the problem is: it really *is* of type long form. However, this seems to happen *only* in the compiled case....s So, I inserted a trace: (eval-when (:compile-toplevel) (trace mop::STD-COMPUTE-EFFECTIVE-METHOD)) and extracted the test form from outside the test case, in order to be able to see the error triggered (RT just prints #<simple-error >): (dmc-test-mc.1 :k 1) The result is this backtrace: [java] 0: (MOP::STD-COMPUTE-EFFECTIVE-METHOD #<STANDARD-GENERIC-FUNCTION DMC-TEST-MC.1 {10D3D99}> #<METHOD-COMBINATION {69B861}> (#<STANDARD-METHOD {C821EF}>)) which clearly shows the method combination is of type METHOD-COMBINATION and not of type LONG-METHOD-COMBINATION. I do understand that this is the error, but I can't for the life of me figure out how we get into the situation that the method combination being instantiated is of the resulting type METHOD-COMBINATION... Any help on debugging or additional insights would be extremely appreciated! Bye, Erik.

3 12

[armedbear-devel] asdf 2.24 released
by Faré 26 Aug '12

26 Aug '12

I am pleased to announce the release of ASDF 2.24. Since previous release 2.23, the changes are as follow: Portability: * ACL: handle SMP vs non-SMP builds in Allegro 9.0 * MKCL: add support for ManKai Common Lisp * ECL: merge improvements from ECL git. Refactor ECL support somewhat. * Remove broken-fasl-support: first, cormanlisp is supposed to have fixed it; second, cormanlisp is dead; third, one can now (setf *load-system-operation* 'load-source-op) instead. Internals: * renaming ends-with to string-suffix-p to avoid conflict with alexandria. * Refactor load-system to use *load-system-operation*, and change require-system and module-provide-asdf to use that. Also note: * We recommend you use asdf-utils to access the utilities in asdf. Some time next year, we may stop exporting the utilities from asdf itself. * To avoid conflicts between alexandria, fare-utils, xcvb-driver, asdf-utils, etc., you can use xcvb-utils that solves the conflicts. Or you can use fare-utils:define-package-mix that will help you automatically resolve them. 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 Obscenity is the crutch of inarticulate motherfuckers.

1 0

[armedbear-devel] Recommended ABCL development setup
by Jonathan P. Bona 24 Aug '12

24 Aug '12

Greetings, As a user of ABCL, I've found it useful to browse the Java source, make slight modifications, run it in a debugger, and so on. I'm doing this rather inelegantly right now by linking to the source folder in an Eclipse project, and it's not working very well. Is there a recommended IDE setup that ABCL developers use? Regards, Jonathan Bona

2 1

Re: [armedbear-devel] Inflexible logic in FIND-SYSTEM-JAR and FIND-CONTRIB
by Mark 22 Aug '12

22 Aug '12

The point of the current procedure is that abcl-contrib.jar is not on the classpath at all, so it should be less configuration. That being said, I'm always open to easier ways for deployment as long as it doesn't break existing usages. I'm "on the road" camping right now so I really won't be able to work on this until perhaps September. A thought might be that the user can extend the CL:REQUIRE mechanism by pushing closures into a special variable whose name is something like *module-provider-hooks*, perhaps in a local system.lisp. This path may allow some experimentation before we merge those semantics with those of ABCL-CONTRIB.

1 0

[armedbear-devel] Inflexible logic in FIND-SYSTEM-JAR and FIND-CONTRIB
by Eric Marsden 22 Aug '12

22 Aug '12

Hi, I am trying to use the new abcl-contrib JSS functionality, which looks very useful; thanks. I have the ABCL classes (and in fact the ABCL-CONTRIB classes) embedded into a jar file containing other code, and both the FIND-SYSTEM-JAR and FIND-CONTRIB logic are failing. Would it be possible perhaps to search for abcl-contrib.jar on the classpath, instead of assuming that it is installed next to abcl-XXX.jar? Thanks, -- Eric Marsden

1 1