[Ecls-list] ECL gaining Unicode support [CC from News]

[Teunis Peters]

Juan Jose Garcia-Ripoll wrote:
> Ok, we have reached a point where the unstable branch, built with
> threads and Unicode, passes the ANSI tests with the same number of
> errors as the bare build (no threads, no extended characters, just
> default flags).
>   
That's wonderful news!  This will make my use of this system much easier.
> There remains an important issue though: performance.  As you will see
> below, the whole test suite takes 25% more time and 40% more space
> with Unicode+threads than with the bare bones ECL. I am unsure whether
> these numbers can be decreased significantly without breaking the ANSI
> standard. Namely, some of the things that cons most are related to
> string-input/output-streams which now have to build, by default,
> extended strings, and these take 4 times more space than ordinary
> ones.
>   

(aside: I'm using 'or' in the binary inclusive sense here)
The thing - as I understand it about threading - is this:   a 
single-threaded application on a single processor will always run faster 
than a multi-threaded application or a single-threaded application on a 
multiple-processor system.   The strength from multi-threaded code is 
seen when multiple discrete threads are in play or multiple processors 
are handling it.

and re: wide characters and space: optimizations of this are possible 
and probably should be explored once the system is working, I'd 
guess.    I wouldn't mind looking into this myself once I understand why 
long long integers aren't present...   (something in the type system?)

I've been caught up in life issues for the last wee while but the 
possibilities of a mingw32 build of ecl got me paying attention again.   
(last time I tried, it didn't - not as cross-compiled under linux anyway)
- Teunis