[armedbear-devel] Focusing 0.18 efforts
alanruttenberg at gmail.com
Tue Nov 3 15:06:02 UTC 2009
On Tue, Nov 3, 2009 at 3:46 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
> Hi Alan,
> On Tue, Nov 3, 2009 at 4:17 AM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> Can't remember whether unicode strings have come up. What's the status of this?
> Well, I guess they didn't: I didn't know (until you asked the
> question) how Java internally encodes Unicode. So, what I didn't know
> is that Java supports "supplementary characters" [characters outside
> the BMP].
I'm not an expert at all in this. Googling, here's what java says:
String represents a string in the UTF-16 format in which supplementary
characters are represented by surrogate pairs (see the section Unicode
Character Representations in the Character class for more
information). Index values refer to char code units, so a
supplementary character uses two positions in a String.
The String class provides methods for dealing with Unicode code points
(i.e., characters), in addition to those for dealing with Unicode code
units (i.e., char values).
> I guess we have a need to implement "codepoint strings" or something
> alike: a means to make sure every character in a string is actually a
> full character.
The situation now is that one can land up with strings that lisp
doesn't understand or munges, for instance if one does a toString from
an http stream, or from a node in an XML parse.
> Thanks for pointing this out. Yesterday after I sent this mail, I
> realised we need a separate thread: "Beyond 0.18: determining the ABCL
> roadmap". How about making this one of the things on our roadmap?
Would be great. Not munging strings that pass through abcl lisp
processing would be a good thing (tm).
>> On Mon, Nov 2, 2009 at 4:17 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
>>> Today, I branched for 0.17 (to be released soon), meaning that trunk
>>> has become free for 0.18 development.
>>> Personally, I found there are a number of items open any one of which
>>> could become part of our 0.18 effort. These are the points I
>>> * Investigate and improve startup performance
>>> * CLOS conformance improvements (including define-method-combination support?)
>>> * Cleanup of Load.java - which would allow loading compressed fasls off streams
>>> * Gray stream compatibility finalization [we're 99% compatible, but
>>> FUNDAMENTAL-STREAM should be recognized as a subtype of STREAM]
>>> * Some random other stuff that comes along
>>> Do you have your own, or opinions on the points I mentioned above?
>>> Let's hear it!
>>> armedbear-devel mailing list
>>> armedbear-devel at common-lisp.net
More information about the armedbear-devel