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 identified:
* 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!
Bye,
Erik.
Can't remember whether unicode strings have come up. What's the status of this? -Alan
On Mon, Nov 2, 2009 at 4:17 PM, Erik Huelsmann ehuels@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 identified:
- 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!
Bye,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hi Alan,
On Tue, Nov 3, 2009 at 4:17 AM, Alan Ruttenberg alanruttenberg@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 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.
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?
Regards,
Erik.
On Mon, Nov 2, 2009 at 4:17 PM, Erik Huelsmann ehuels@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 identified:
- 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!
Bye,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Tue, Nov 3, 2009 at 3:46 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alan,
On Tue, Nov 3, 2009 at 4:17 AM, Alan Ruttenberg alanruttenberg@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).
-Alan
Regards,
Erik.
On Mon, Nov 2, 2009 at 4:17 PM, Erik Huelsmann ehuels@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 identified:
- 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!
Bye,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
armedbear-devel@common-lisp.net