armedbear-devel April 2010

armedbear-devel@common-lisp.net

19 participants
37 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel April 2010