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

[armedbear-devel] Compiler bug in call to MAX
by Eric Marsden 29 Oct '12

29 Oct '12

Hi, The following illustrates what looks like a bug in the compiler's handling of type propagation (bug disappears without the type declaration). CL-USER(25): (lisp-implementation-version) "1.1.0-dev-svn-14222M" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_03-b21)" "amd64-Linux-3.3.0-trunk-amd64)" CL-USER(26): (defun foo (a b) (declare (type (integer * 6488318769) b)) (max 1 (the (integer * 5711538578) a) b 2 1351352470)) FOO CL-USER(27): (foo 5711538444 6488318765) 6488318765 CL-USER(28): (compile 'foo) FOO NIL NIL CL-USER(29): (foo 5711538444 6488318765) 1351352470 -- Eric Marsden

2 1

[armedbear-devel] BABEL-TESTS on ABCL
by Erik Huelsmann 28 Oct '12

28 Oct '12

Hi Luis, Today we've been working on ABCL being able to compile and load BABEL; actually, it could do that already, but didn't work with BABEL-TESTS. We've committed some fixes which handle reader issues uncovered by the library, but we're now stuck: there's a bit of code commented out on CCL. It seems we're running into the same problems as CCL, due to strictness of interpretation of code points. Could you mark the #-ccl section in tests/tests.lisp as #-(or ccl abcl)? That solves our problem with the #\udcf0 code point. Thanks in advance! Bye, Erik.

2 1

[armedbear-devel] Current CFFI and Hunchentoot patches for ABCL
by Mark Evenson 28 Oct '12

28 Oct '12

With [my latest CFFI patches][1], I am able to at least get CFFI to load for its tests under OSX and Solaris. Currently, the test suite fails around 32 tests depending on the hosting operating system. [1]: http://slack.net/~evenson/abcl/cffi/cffi-abcl-20121021a.patch This patch at least allows one to run the tests against Hunchentoot if [it has been patched for socket timeouts][2]. [2]: http://slack.net/~evenson/abcl/hunchentoot/hunchentoot-1.2.6-abcl-20121020a… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 1

[armedbear-devel] Fwd: Re: [armedbear-cvs] r14218 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 27 Oct '12

27 Oct '12

sent from my phone ---------- Forwarded message ---------- From: "Erik Huelsmann" <ehuels(a)gmail.com> Date: Oct 27, 2012 11:24 AM Subject: Re: [armedbear-cvs] r14218 - trunk/abcl/src/org/armedbear/lisp To: <mevenson(a)common-lisp.net> Cc: <Armedbear-devel(a)lists.sf.net> Hi mark, If the intended type is right, this should not be required, right? Then my question is: why isn't the intended type correct? Bye, Erik. sent from my phone On Oct 27, 2012 10:50 AM, <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Sat Oct 27 01:50:30 2012 > New Revision: 14218 > > Log: > Always bypass method access checks for JSTATIC. > > Enables a (to be released) patched CFFI to actually use callbacks. > > Modified: > trunk/abcl/src/org/armedbear/lisp/Java.java > > Modified: trunk/abcl/src/org/armedbear/lisp/Java.java > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Java.java Fri Oct 26 23:40:54 2012 > (r14217) > +++ trunk/abcl/src/org/armedbear/lisp/Java.java Sat Oct 27 01:50:30 2012 > (r14218) > @@ -472,6 +472,7 @@ > else > methodArgs[i-2] = arg.javaInstance(argTypes[i-2]); > } > + m.setAccessible(true); > Object result = m.invoke(null, methodArgs); > return JavaObject.getInstance(result, translate, > m.getReturnType()); > } > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] lisp source files encoding
by Anton Vodonosov 21 Oct '12

21 Oct '12

Hello. Starting from ASDF 2.21 it is possible to specify lisp source files encoding in defsystem (see asdf manual: http://common-lisp.net/project/asdf/asdf.html#Miscellaneous-additional-func…) ABCL now comes with ASDF 2.25. But still encoding specification doesn't work on ABCL. See this log for example: https://cl-test-grid.appspot.com/blob?key=564037 The system being compiled specifies :encoding :ut8 in its defsystem, and we saw the encoding specification working - it fixed compiilation on SBCL. But on ABCL it still fails. Does anyone have idea why so? Is it because of the way ASDF is integrated into ABCL? Or ABCL just doesn't support utf-8 lisp files at all? Best regards, - Anton

3 4

[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