armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] Unicode support vs spec conformance
by Erik Huelsmann 05 Apr '10

05 Apr '10

This started with Douglas Miles remarking that 2 tests in the ansi test suite have been failing ever since we increased CHAR-CODE-LIMIT to #x10000.That change was associated with our intended support for Unicode. As it turns out, Unicode has defined characters which conflict with a requirement from the CLHS: CLHS requires that characters be defined in exact pairs, if they have 'case'. This means that the functions char-upcase and char-downcase can be used to retrieve the character's "other case" equivalent. However, in Unicode there are characters which don't have that property: for example LATIN SMALL LETTER DOTLESS I maps to the LATIN CAPITAL LETTER I, just as the LATIN SMALL LETTER I. Obviously, the capital can't map back to both. See here the issue with CLHS compliance emerge. Three possible solutions have come up: 1a. Be CLHS compliant, but not Unicode 1b. Same as (1a), but provide specific Unicode up/down casing functions 2. Be Unicode compliant and not CLHS. SBCL (and from Sam Steingold's remark CLISP too) chooses 1a: I haven't found a function to do Unicode up/down casing; it defines the uppercase of the dotless i to be itself (caseless). This solution results in CLHS compliance, but in my opinion, isn't the solution with the least surprise: if you decide you want to upcase a string - without in-depth awareness of the issue - you're suddenly faced with a string which is upcased, except for a number of characters. I would propose we - documentedly - diverge from the CLHS on this issue: we follow Unicode and the upper case version of the dotless i is just the capital i. From a user perspective, this seems like the solution of least surprise: I would expect people who use characters which can't be round-tripped to understand about that. Sam suggests there's an issue with symbol i/o. He's probably referring to *readtable-case* and *print-case*. My reasoning here too is that people using characters like these in their symbols would expect to be familiar with both the casing behaviour of the Common Lisp reader/printer and the behaviour of their letters in such circumstances: if a string were uppercased in a certain way, wouldn't it be extremely weird if your symbols wouldn't too - given that your Common Lisp claims Unicode support? So, my proposal here is to diverge. What are your opinions? Bye, Erik.

2 1

[armedbear-devel] Where is ASDF2?
by Blake McBride 05 Apr '10

05 Apr '10

git clone http://common-lisp.net/project/asdf/asdf.git seems to have the latest ASDF 1. I can't seem to find ASDF 2. A pointer would be appreciated. Thanks. Blake McBride

2 1

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel