development release newLISP v.9.2.6

HPW · Post by **HPW** » Fri Nov 23, 2007 6:34 pm

(1) there will be only one version of the newLISP executable on all platforms and the utf-8 mode is switchable by a function 'set-utf8' 'true/nil'

Great! Seems the most flexibel solution for me.
(What the default will be is not so important)

newdep · Post by **newdep** » Fri Nov 23, 2007 6:57 pm

actualy..what the default is IS very important..

Setting everything off by default informs the user that its not utf8. (= normal) no extra script settings needed.
Setting it to (set-utf8 true) informs the user that its about a special char case.

If UTF8 will be default in Unix please let the user select a seperate makefile to compile without UTF8 for local use.

Norman.

Fanda · Post by **Fanda** » Fri Nov 23, 2007 8:39 pm

It would be nice to separate UTF-8 and decimal point/comma settings.

This way we could choose from 4 combinations - nonUTF-8/UTF-8 and point/comma decimal.

Fanda

Lutz · Post by **Lutz** » Fri Nov 23, 2007 9:04 pm

You can do (set-locale "C") in the UTF-8 version and force the decimal point this way, to be different from your local locale. This is what I did for newlisp-edit.lsp and all demo files in the last newLISP-GS for Win32 posted.

But I will probably go back to non-UTF-8 for the Win32 distribition, but post a newlisp.exe with UTF-8 enabled as optional download. The guiserver will adapt automatically to whatever mode newLISP is running.

On Mac OS X all will stay the same with everything UTF-8.

Lutz

newdep · Post by **newdep** » Fri Nov 23, 2007 9:46 pm

Lutz,

This means unix versions will have utf8 included and on by default as from 9.2.7?

Norman.

Lutz · Post by **Lutz** » Fri Nov 23, 2007 10:09 pm

The newlisp core will stay as it is with different makefiles for utf8 and non-utf-8. utf-8 cannot be included in all versions, because some platforms don't offer the support for the wchar data type (unicode wide characters).

So for Linux and BSD and other UNIX things basically will stay the same. Win32 will be shipped as non-utf-8 as before, and Mac OS X will be shipped utf-8 as before.

The only change will be that the guiserver will switch to utf-8 if newLISP is running utf-8, and that it can be overwritten using gs:set-utf8.

For Win32 utf-8 compiled newlisp.exe and newlisp.dll will be put in a separate directory.

Lutz

newBert · Post by **newBert** » Sat Nov 24, 2007 10:26 am

NewLISP 9.2.6 now works on my machine, but I must just change all my accented characters ... and:

newBert wrote: When I double-clic on a NewLISP script I get only a black DOS-console ... or nothing.

... because NewLISP v.9.2.6 doesn't like accented characters in file names. So I must modify all my file names too.

But:

Lutz wrote:The newlisp core will stay as it is with different makefiles for utf8 and non-utf-8. utf-8 cannot be included in all versions, because some platforms don't offer the support for the wchar data type (unicode wide characters).

(...)

For Win32 utf-8 compiled newlisp.exe and newlisp.dll will be put in a separate directory.

Lutz

So I'll wait a moment before modifying anything at all :-)

Lutz · Post by **Lutz** » Sat Nov 24, 2007 12:01 pm

Using UTF-8 on Windows may only make sense if all your other text processing tools use UTF-8 too, especially any editors you are using.

So for Windows it seems to be better to stay without UTF-8, but you always can enable it by just replacing the newlisp.exe. Guisierver will adapt automatically to it.

Lutz

Dmi · Post by **Dmi** » Sat Nov 24, 2007 9:14 pm

Lutz wrote: It seems that on Windows, although it can support UTF-8, most applications are written to use the ISO/IEC-8859 one-byte-length character set, where the accented, umlaut and other special characters are encoded in one-byte values > 128. I believe even Russian language or Hebrew language Windows uses ISO 88xx one-byte-length character sets. Perhaps some Russian and Israeli users can confirm this.

Rissian Windows 9x/2k/XP uses one byte Windows-1251 (mostly for windows apps) mixed with one byte CP866 (file system names and console apps) mixed with two byte utf-8 (Registry and some internals in Win2k/XP).
ISO8859-5 isn't wide spreaded in Russia, but there are a few...

Compatibility with Win98 (for console scripting only, GS and newlisp-edit aren't needed) and compatibility with one-byte encodings is much sufficient for business apps (the enterprise automatisation is arhaic sometimes ;-)

Support for one-byte encodings in Unix is too mandatory for the business, because many applications are related to interacting with windows and many applications are related to interacting with commercially supported transaction systems, that are based on one byte encodings.

In the other hand - to have a switchable utf-8/single byte behavior would be nice.
But what about simple proper locale supporting? I.e., usage of OS libraries for all locale-related stuff?
The question is: what for the support for utf-8 in a system which haven't a locale libs at all?