oe at csli.Stanford.EDU
Tue Aug 22 17:54:17 CEST 2006
hi ben, apologies for the long turn-around. australia and back takes a
surprising amount of time :-).
> The latest release of ECL (0.9i) provides a certain amount of support
> for use of Unicode:
> "ECL can also be built with support for strings and symbols with unicode
> characters (patches by B. Spilsbury). However, since the reader still
> does not understand external formats, there is some way until we can
> claim that ECL supports unicode."
> Unicode support is needed by the (C++) fspp module in order to
> compute (Unicode) character offsets. Would anyone object to upgrading
> PET to this new version of ECL? (There is some non
> backwards-compatibility in the naming of functions calls in the new
> version, which presumably could be worked around with suitable
it sounds as if we are not going to have a UniCode-enabled version of
FSPP when moving to ECL 0.9i quite yet? right now, when i turn on the
FSPP tokenizer in PET, i get several messages like the following:
read-preprocessor():  invalid pattern ` (["]) '
i suspect the reader got confused by two-byte characters in the file?
in a nutshell, if we gained a working FSPP by requiring 0.9i, then i
would be happy making that move. if not, i would rather wait for the
ECL version that actually has enough UniCode for FSPP to work.
best - oe
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++ --- oe at csli.stanford.edu; oe at ifi.uio.no; stephan at oepen.net ---
More information about the developers