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

[armedbear-devel] Change in merge semantics which fixes loading CFFI
by Mark Evenson 21 Oct '12

21 Oct '12

After extensive testing and refactoring, I have pushed a series of changes (from [r14176][] through [r14179][]) to trunk that should, among other things, finally fix the issues associated with loading CFFI. To affect the fixes, I have introduced a slight change in the merge pathname semantics in [r14178][], which I described in the Manual by the following text: When merging pathnames and the defaults point to a JAR-PATHNAME, we set the DEVICE of the result to :UNSPECIFIC if the pathname to be be merged does not contain a specified DEVICE, does not contain a specified HOST, does contain a relative DIRECTORY, and we are not running on a MSFT Windows platform. The intent of this rather arcane sounding deviation from conformance is so that the result of a merge won't fill in a DEVICE with the wrong "default device for the host" in the sense of the fourth paragraph in the CLHS description of MERGE-PATHNAMES (the paragraph beginning "If the PATHNAME explicitly specifies a host and not a device"). A future version of the implementation may return to conformance by using the HOST value to reflect the type explicitly. Additionally TRUENAME on non-Windows now fills in the DEVICE component with :UNSPECIFIC, but this is conforming behaviour. I will close the relevant tickets when I get a chance (and no one has proved me a liar in the meantime). [r14176]: http://trac.common-lisp.net/armedbear/changeset/14176 [r14178]: http://trac.common-lisp.net/armedbear/changeset/14178 [r14179]: http://trac.common-lisp.net/armedbear/changeset/14179 Comments, criticisms, usage reports (especially of the "Yay! CFFI works now!" variety), solicited. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

[armedbear-devel] cl-test-grid results for ABCL rev 14200 - all regressions are gone
by Anton Vodonosov 17 Oct '12

17 Oct '12

Hello. The last revision tested by test gird is 14200. The report is here: http://common-lisp.net/project/cl-test-grid/abcl.html As you can see, all the regressions comparing the 1.0.1 release have gone. The red result for shelly in the right column is not problem of ABCL. It's just because new ABCL has upgrated ASDF and shelly was not ready to work with new ASDF (BTW, fixed in the shelly repository). Best regards, - Anton

2 1

[armedbear-devel] The road to abcl-1.1.0
by Mark Evenson 11 Oct '12

11 Oct '12

# Features ## CLOSER-MOP ## CFFI ## Quicklisp ## JSS ## ABCL-ASDF ## JFLI Follow the [release engineering for abcl-1.1.0][abcl-1.0.0] [abcl-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] BigNum question
by archisman rudra 09 Oct '12

09 Oct '12

Is this correct behavior? CL-USER(17): (type-of 1234567898723618080928927362387) (INTEGER 2147483648) The relevant java code is in Bignum.java: (the value field is a java BigInteger) @Override public LispObject typeOf() { if (value.signum() > 0) return list(Symbol.INTEGER, new Bignum((long)Integer.MAX_VALUE + 1)); return Symbol.BIGNUM; } for comparison: CL-USER(23): (type-of -1234567898723618080928927362387) BIGNUM which makes intuitive sense.

4 9

[armedbear-devel] Question about jnew-runtime-class
by archisman rudra 09 Oct '12

09 Oct '12

Hi, hopefully this is the correct list. If not please let me know. Background: I am trying to use abcl to generate jars to send off to a hadoop cluster for execution. The svn version of the jnew-runtime-class does not store the actual method bodies in the generated class file, but rather loads the generated class file and sets the relevant field. Here is the relevant code : (multiple-value-bind (class-file method-implementation-fields) (apply #'java::%jnew-runtime-class class-name stream args) (sys::put-memory-function memory-class-loader class-name (sys::%get-output-stream-bytes stream)) * (let ((jclass (java:jcall "loadClass" memory-class-loader class-name)))* * (dolist (method method-implementation-fields)* * (setf (java:jfield jclass (car method)) (cdr method)))* jclass)))) This means that the generated jar file cannot be easily used from standard java code. I would like to add some code in the static initialization block of generated class file to do something equivalent. I will have to save the lambda expression for the method and have been experimenting as follows: (defvar *cf*) (defvar *mif*) (with-open-file (stream "test.class" :direction :output :element-type '(unsigned-byte 8)) (multiple-value-bind (class-file method-implementation-field) (java::%jnew-runtime-class "test" stream :methods `(("forty_two_method1" :int () ,(lambda (this) 42)))) (setf *cf* class-file) (setf *mif* method-implementation-field))) (with-open-file (stream "test_forms" :direction :output) (dolist (m *mif*) (system:dump-form (list (car m) (function-lambda-expression (cdr m))) stream))) This assumes that the lambda expression does not refer to any variable or user defined function, but perhaps the asdf-jar contrib might help here. I was going to write the relevant code and start using it for my project, but I was wondering if I am duplicating work that others have already done or are doing and whether there are other libraries (jffli perhaps, I am not very familiar with it) that have similar functionality. Also if there are other interactions with other parts of the system that I am perhaps missing. I would e grateful for any advice. Archi

2 3

[armedbear-devel] Status of my work towards abcl-1.1
by Mark Evenson 08 Oct '12

08 Oct '12

After much banging around against issues involved in merging PATHNAME objects when the defaults points to a JAR-PATHNAME, I think I am finally converging on a solution. I have [committed a design document][1] that describes my approach. The main user visible result here would be the successful location and retrieval from the network of the JNA component necessary for loading CFFI. [1]: http://trac.common-lisp.net/armedbear/changeset/14172 The gist of the problem lies in that on non-Windows, the default DEVICE component is NIL, which when merged with a JAR-PATHNAME which represents the filesystem location of the jar archive in DEVICE, results in some rather bad interactions. At the top of problem, on non-Windows when the defaults contain a JAR-PATHNAME: 1. (truename #p"/") fails. 2. Loading ASDF systems from jar files which declare dependencies on other ASDF systems will fail. My proposed solution is to: 1. On non-Windows, TRUENAME for a non-JAR-PATHNAME will set the DEVICE of the result to :UNSPECIFIC. 2. Treat a JAR-PATHNAME as implicitly having a different HOST from normal file PATHNAME, so that the result of a merge won't fill in a DEVICE with the wrong "default device for the host" in the sense of the fourth paragraph in the [CLHS description of MERGE-PATHNAMES][2] (the paragraph beginning "If the PATHNAME explicitly specifies a host and not a device…"). [2]: http://www.lispworks.com/documentation/HyperSpec/Body/f_merge_.htm My (uncommitted) patches seem to resolve all the problems, and work on both Windows and non-Windows. I still have two remaining ANSI failures that the changes introduced, involving the value of *COMPILE-FILE-TRUENAME* for which I need to rewrite the form which the compiler dumps pathnames from #p"/foo/bar" to the #p(:directory (:absolute "foo") :name "bar") form. Somehow, the new form isn't being read correctly (Erik I could use your advice here). In addition, since namestrings are no longer always roundtrippable as they discard an :UNSPECIFIC DEVICE, I've had to change a bit of code in the compiler and the Pathname implementation which assumed otherwise. A cleaner solution would probalby have been to actually populate the HOST field with a type nonce, like SBCL does. But we already use HOST to store information for a URL-PATHNAME. And given the reality that we should release an abcl-1.1.0 as soon as realistically possible, when I estimated that going down this route would change much more code I opted for the current solution where we take a cut at "Do What I Mean" reasoning we could potentially retrofit this with HOST containing various HOST forms for abcl-1.2.x if enough objections were raised. Comments solicited. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Fixes to trunk for cl-test-grid regressions
by Erik Huelsmann 04 Oct '12

04 Oct '12

Hi, Last two weeks I've committed several fixes for regressions reported by cl-test-grid on http://common-lisp.net/project/cl-test-grid/abcl.html. The page might be updated today or tomorrow based on r14163 (I think). Today I committed a fix for CL-ROUTES, which means the MAPPER-TEST-SUITE regressions shown in that page (even after the update) have also been fixed. That's it for the update for now :-) Bye, Erik.

1 0