|
osdir.com mailing list archive |
|
Subject: Re: Simple-streams patch (mostly) - msg#00228List: lisp.cmucl.develHow does this interact with the encoding-related parts of the Unicode branch (which I'm intent on merging step-wise into the main-branch soonishly). Sorry for not looking myself, but I'm currently at a location without CMUCL sources... Those pieces are prototypes only. I'd like to get iconv compatibility in place as well, while also supporting translators in lisp. The simple-streams external-format interface may well be suitable here. I should get my development machine back in a week or two, and then I can fix up the external-format support for normal streams also, at which point I'll have an updated, compilable source tree for you. In any case, I wouldn't worry about preserving any of the unicode external-format or character-database code, since it should be replaced in the near future anyhow. I've come to the conclusion that the character database should probably be handled in terms of the union of character repertoires, which could then link directly into later work for supporting actual character repertoire types. Grouping the characters this way also helps with attributes, since many attributes are quite constrained within a character set or repertoire, but not between them. Regards, Brian. Thread at a glance:
Previous Message by Date: click to view message previewRe: Simple-streams patch (mostly)On Tue, 24 Jun 2003 09:09:17 +0200 (CEST), Pierre R Mai wrote: > Paul Foley said: >> On 23 Jun 2003 16:24:46 -0400, Raymond Toy wrote: >> Paul> * Add "ef" directory for external formats >> >>> Will probably rename this directory to external-formats. > How does this interact with the encoding-related parts of the Unicode > branch (which I'm intent on merging step-wise into the main-branch > soonishly). It doesn't. Or rather, it should work just fine in a Unicode-enabled image, but will still only read ISO 8859-1. I've never looked in the Unicode branch. When you merge it, I'll look at it/merge my stuff with it. -- Just because we Lisp programmers are better than everyone else is no excuse for us to be arrogant. -- Erann Gat (setq reply-to (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>")) Next Message by Date: click to view message previewRe: Simple-streams patch (mostly)"Pierre R. Mai" <pmai@xxxxxxx> writes: >>> Can't this be computed via (c::backend-byte-order c::*target-backend*)? >> >> Yup; Christophe Rhodes pointed that out, too, and I'm doing that >> now... > > While this is true, having corresponding features is often nicer than > accessing backend-byte-order. While one can play tricks with *features* > and eval-when, those aren't all that reliable and nice... The idiom I proposed is something like (eval-when (:compile-toplevel) ;; if I were really paranoid, I would suggest not :BIG-ENDIAN or ;; :LITTLE-ENDIAN, but C::BIG-ENDIAN and C::LITTLE-ENDIAN. (ecase (c::backend-byte-order c::*target-backend*) (:little-endian (pushnew :little-endian *features*)) (:big-endian (pushnew :big-endian *features*))) (assert (not (and (member :little-endian *features*) (member :big-endian *features*))))) (eval-when (:execute) (if (member :big-endian *features*) (when (member :little-endian *features*) (error "only one of :BIG-ENDIAN or :LITTLE-ENDIAN on ~ *FEATURES, please.")) (unless (member :little-endian *features*) (error "one of :BIG-ENDIAN or :LITTLE-ENDIAN required ~ on *FEATURES* to load as source.")))) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) Previous Message by Thread: click to view message previewRe: Simple-streams patch (mostly)On Tue, 24 Jun 2003 09:09:17 +0200 (CEST), Pierre R Mai wrote: > Paul Foley said: >> On 23 Jun 2003 16:24:46 -0400, Raymond Toy wrote: >> Paul> * Add "ef" directory for external formats >> >>> Will probably rename this directory to external-formats. > How does this interact with the encoding-related parts of the Unicode > branch (which I'm intent on merging step-wise into the main-branch > soonishly). It doesn't. Or rather, it should work just fine in a Unicode-enabled image, but will still only read ISO 8859-1. I've never looked in the Unicode branch. When you merge it, I'll look at it/merge my stuff with it. -- Just because we Lisp programmers are better than everyone else is no excuse for us to be arrogant. -- Erann Gat (setq reply-to (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>")) Next Message by Thread: click to view message previewRe: Simple-streams patch (mostly)"Pierre R. Mai" <pmai@xxxxxxx> writes: >>> Can't this be computed via (c::backend-byte-order c::*target-backend*)? >> >> Yup; Christophe Rhodes pointed that out, too, and I'm doing that >> now... > > While this is true, having corresponding features is often nicer than > accessing backend-byte-order. While one can play tricks with *features* > and eval-when, those aren't all that reliable and nice... The idiom I proposed is something like (eval-when (:compile-toplevel) ;; if I were really paranoid, I would suggest not :BIG-ENDIAN or ;; :LITTLE-ENDIAN, but C::BIG-ENDIAN and C::LITTLE-ENDIAN. (ecase (c::backend-byte-order c::*target-backend*) (:little-endian (pushnew :little-endian *features*)) (:big-endian (pushnew :big-endian *features*))) (assert (not (and (member :little-endian *features*) (member :big-endian *features*))))) (eval-when (:execute) (if (member :big-endian *features*) (when (member :little-endian *features*) (error "only one of :BIG-ENDIAN or :LITTLE-ENDIAN on ~ *FEATURES, please.")) (unless (member :little-endian *features*) (error "one of :BIG-ENDIAN or :LITTLE-ENDIAN required ~ on *FEATURES* to load as source.")))) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) Loading Comments...
|
|
