armedbear-devel October 2012

armedbear-devel@common-lisp.net

14 participants
17 discussions

[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] Incomplete file lisp/digest.lisp in r14198
by Eric Marsden 02 Dec '12

02 Dec '12

Hi, File src/org/armedbear/lisp/digest.lisp in current SVN contains an incomplete function named SHA256 (unbalanced parentheses). -- Eric Marsden

5 7

[armedbear-devel] Issue finding methods in JSS
by Jonathan P. Bona 09 Nov '12

09 Nov '12

Hello, We found this issue while working with LSW. It seems to be a bug in how public methods are found for inner classes. The last line of code below results in an exception rather than finding and running the size() method: ;;;---------------- (require :abcl-contrib) (require :jss) (jss::ensure-compatibility) (setq headers (#"getHeaderFields" (#"openConnection" (jss::new 'java.net.url "http://google.com")))) ; a java.util.Collections$UnmodifiableRandomAccessList (setq ural (#"get" headers (second (jss::set-to-list (#"keySet" headers))))) ;finds: #<method public int java.util.Collections$UnmodifiableCollection.size()> (find "size" (#"getMethods" (#"getClass" ural) ) :test 'string-equal :key #"getName") ; Java exception 'java.lang.NoSuchMethodException: No applicable method named size found in java.lang.Object or java.util.Collections$UnmodifiableRandomAccessList'. (#"size" ural) ;;;---------------- I chased this into org.armedbear.lisp.Java, where findMethod is returning null. - Jonathan Bona

4 7

[armedbear-devel] cffi requires maven
by Anton Vodonosov 09 Nov '12

09 Nov '12

Hello. In ABCL CFFI requires maven. Maven is used to fetch jna.jar. This is done via abcl-contrib.jar/mvn/jna.asd What I think is inconvenient is that maven is tried even if jna.jar is in classpath. IMHO it would be to not require maven installed if JNA is available. The current workaround is (provide 'jna). With that I can do: (java:add-to-classpath "my-jna/jna.jar") (provide 'jna) (ql:quickload :drakma) BTW, I think it's probably makes sense to ship jna.jar together with official ABCL release. Best regards, - Anton

3 8

[armedbear-devel] has anyone reviewed ticket #247?
by Anton Vodonosov 09 Nov '12

09 Nov '12

Hello. It's not a pressing issue for me. Just to ensure the ticket is not overlooked before the release, has anyone reviewd #247?

2 2

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel October 2012