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

[armedbear-devel] Understanding Unicode support
by Erik Huelsmann 04 Apr '10

04 Apr '10

Hi all, In an effort to make our Unicode support comprehensible, I've started a wiki page to document what's all to be considered. The page is at http://trac.common-lisp.net/armedbear/wiki/CharsetSupport Please contribute directly to the page or send your amendments here for inclusion. Bye, Erik.

1 0

[armedbear-devel] Unicode, CHAR-UPCASE/CHAR-DOWNCASE and char-upcase.1/char-upcase.2
by Erik Huelsmann 04 Apr '10

04 Apr '10

Ever since ABCL raised its CHAR-CODE-LIMIT from 256 to #x10000, 2 tests started failing: char-upcase.1 and char-upcase.2. These 2 tests iterate through all integers between 0 and CHAR-CODE-LIMIT. While doing so, they test for the property that upcasing and downcasing returns the same character again ("round-tripping"). This property of characters is specified in section 13.1.4.3 (http://www.lispworks.com/documentation/lw51/CLHS/Body/13_adc.htm) "Characters with case". In short: characters with case are defined in pairs; additional characters with case have to be defined in pairs too. The spec provides char-upcase and char-downcase to convert characters-with-case to their 'other-case equivalent'. However, in section 13.1.10, there seems to be an escape hatch: "Documentation of implementation-defined scripts". A script is a subtype of CHARACTER, nothing more nothing less. An implementation-defined script gets to document the effect on CHAR-UPCASE and CHAR-DOWNCASE. Now, if I were to define our Unicode script to be every character except those in the base set, char-upcase and char-downcase may have different semantics, except for the standard characters. That way, there's no need to have the round-tripping requirement apply to most of unicode - as can't be expected, see latin-small-letter-dotless-i for an example. In the light above, is it really portable for the tests to assume all characters must be round-tripped? I think it's not. What are your opinions? Bye, Erik.

3 4

[armedbear-devel] Loading from jar - status
by Reinhard Oldenburg 03 Apr '10

03 Apr '10

Dear ABCL-Team, some time a go the theme of loading compiled files from jar-archives has been discussed on this list but somehow I missed the final conclusion. There seems to be no example or documentaion of this feature. Especially I'm interested in loading Maxima from a jar file - is this possible? Yours, Reinhard Oldenburg

2 1

[armedbear-devel] lisp interpreter inside a beanshell JConsole?
by Alan Ruttenberg 03 Apr '10

03 Apr '10

Hi, I'm trying to set up a lisp shell inside protege, by copy pasting from the bean shell example they have: http://code.google.com/p/co-ode-owl-plugins/source/browse/trunk/org.coode.s… (see http://www.beanshell.org/manual/jconsole.html) Unfortunately I'm losing, with the first eval I call resulting in a null pointer exception. I expect I don't know how to set up the top level loop to run with the JConsole streams. Can anyone help? Thanks, Alan

3 8

[armedbear-devel] Proposal for URL to be used as Pathnames
by Mark Evenson 02 Apr '10

02 Apr '10

I've [committed to an initial design][1] for URLs to be used as Pathnames, which I am in the process of implementing. The primary use of this functionality will be to be able to eventually express OSGi bundles within ASDF system definitions. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/url-pat… The gist of the proposal is to represent a URL with a Pathname whose HOST component is a list. The list will be an association list with the key :SCHEME containing the URL scheme and :AUTHORITY containing the URL authority. The DIRECTORY, NAME, and TYPE components will be used to construct the PATH of the URL. As an example, "http://example.org:8080/org/armedbear/lisp/boot.lisp" would be converted to a Pathname as follows pathname: { host: (:SCHEME "http" :AUTHORITY "example.org:8080"), directory: (:ABSOLUTE "org" "armedbear" "lisp"), name: "boot", type: "lisp" } As an answer to Alessio's question (long ago) about whether URLs should really be a Pathname or if we are better off using a class, I think that they really are better abstracted as a Pathname because they a) have a hierarchical path b) the network location has a strong resemblance to how HOST is used for UNC mounts under Windows and c) being able to express OSGi bundles in ASDF has a chance of working. Critique welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

5 10

Re: [armedbear-devel] [armedbear-cvs] r12577 - branches/metaclass
by Erik Huelsmann 28 Mar '10

28 Mar '10

This commit completes the METACLASS functionality I was planning to provide on trunk/. The only thing which remains is writing regression tests. I don't see any problems to do that with the code on trunk, as the ANSI tests show no new breakage. Since 0.20 is scheduled to be released beginning of may - as per our normal release cycle - please test this functionality as much as possible and report any issues you find. It will help improve the quality of our 0.20 release: this functionality has the potential of destabilizing our code, although I haven't found that to have acctually happened. Thanks in advance, Erik. On Sun, Mar 28, 2010 at 9:20 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Mar 28 16:20:09 2010 > New Revision: 12577 > > Log: > Re #38: Delete merged metaclass branch. > > Removed: > branches/metaclass/ > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] SEQUENCE == SlotClass?
by Erik Huelsmann 27 Mar '10

27 Mar '10

Hi Alessio, You implemented the user-extensible sequence protocol. Did you by any chance change the type of Sequence from BUILT-IN-CLASS to SLOT-CLASS? If so, I have a little bit of a negative interaction with my METACLASS changes. Nothing that can't be fixed; I'll probably need to study AMOP for the solution, but I was just wondering. Does crhodes specify the new class of SEQUENCE in his protocol? Should we switch it to STANDARD-CLASS? Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.19.1 released
by Erik Huelsmann 27 Mar '10

27 Mar '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.19.1 release. Version 0.19.0 was never released. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - a fix for unbinding PROGV bound variables upon exiting the PROGV scope and a much improved integration of access to filenames specified by URLs. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.19.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.zip.asc

1 0

[armedbear-devel] Losing type information after storing in java.util.ArrayList
by David Kirkman 24 Mar '10

24 Mar '10

I've got a subtle problem: if I create a byte array, store it in a java.util.ArrayList, and then retrieve the stored byte array, what I get back is not quite the same type as the original byte array. I think that everything is the same, except that the JavaObjects have different values for the intendedClass field. Here is an example: (setq array1 (jnew-array "byte" 1)) (setq array2 (let ((array-list (jnew (jconstructor "java.util.ArrayList")))) ;; put the byte array into the ArrayList (jcall (jmethod "java.util.AbstractList" "add" "java.lang.Object") array-list array1) ;; and pull it back out (jcall (jmethod "java.util.AbstractList" "get" "int") array-list 0))) (describe array1) ;#<jarray [B@c4ff22 {4A44DD}> is an object of type JAVA-OBJECT. ;The wrapped Java object is an array of bytes with 1 element.; No value (describe array2) ;#<jarray [B@c4ff22 {5E6B62}> is an object of type JAVA-OBJECT. ;The wrapped Java object is an array of bytes with 1 element.; No value At this point array1 and array2 look pretty compatible, but ... (sys::%make-byte-array-input-stream array1) ; works fine, gives a #S(SYSTEM::SYSTEM-STREAM) (sys::%make-byte-array-input-stream array2) ; gives a TYPE-ERROR, with message "java.lang.Object is not assignable to [B" The TYPE-ERROR comes from JavaObject.javaInstance(Class<?> c) (line 248 of JavaObject.java). It seems that array1 has intendedClass="[B", and array2 has intendedClass="java.lang.Object", so I'm pretty sure that's my problem. Is there a way to specify the intendedClass of array2? Thanks, -david k.

4 6

Re: [armedbear-devel] long
by Alan Ruttenberg 23 Mar '10

23 Mar '10

On Mar 16, 2010, at 8:47 AM, dmiles(a)users.sourceforge.net wrote: > This is because ABCL: > Fixnum => int > Bignum => BigInteger > > ABCL does not have a 'long' type so it is normal workaround to produce > a new 'long in your case. > > So depends who is desiring: There is no real spec other than Allegro > http://www.franz.com/support/documentation/8.0/doc/jlinker.htm#data=types-c… > But Allegro spec here is lossy.. > (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would > scaled back to Long.MAX_VALUE) So their spec is even more > undesirable. Agreed. > It would be possible that when the Bignum is within normal java long > range the javaInstance() could return a java.lang.Long instead. > > Does everyone think this would be better behavior than current ABCL and Allegro? I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup. -Alan > > > On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg > <alanruttenberg(a)gmail.com> wrote: >> >> Am I right to observe that abcl coerces any number > fixnum size to bigint? >> I'm having trouble calling a java method that takes a long. I seem to >> have worked around it calling the method with (new 'long >> "9223372036854775807") rather than 9223372036854775807 . >> >> Is this the desired behavior? >> >> -Alan >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 5