development release newLISP v.9.2.6

[newBert]

Sorry but newlisp-edit.lsp doesn't work any more with the new release. I can only launch newlisp.exe 9.2.6 UTF-8 and newlisp-edit doesn't react !!!



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

[HPW]

When I double-clic on a NewLISP-GS start-icon I get also only the splash popup.

[Cyril]

New version is completely broken for Windows 98! (yes, I know, there is a few Windows 98 users around today, but I am one of them). It does no file I/O. I mean no I/O at all! The interpreter even cannot run scripts! And I have removed 9.2.5 release before I have noted this... No, no, don't worry, I, as a responsible citizen, have a backup, 9.2.5 is reinstalled already!



Lutz, is it possible to compile non-unicode version of newlisp executable and put in the development directory (marking clearly which is which)?

[Lutz]

All Win32 users:



I posted http://newlisp.org/downloads/development/newlisp-9206-win-gs-107.exe">http://newlisp.org/downloads/developmen ... gs-107.exe">http://newlisp.org/downloads/development/newlisp-9206-win-gs-107.exe again.



Thanks for all of your patience, to get this UTF-8 stuff on Win32 right, may take a while. Please make sure to report with each problem the version you are running and the country or locale of your Windows installation. I believe that France and Germany use both comma and Great Britain uses the point for decimals, but I am not sure about any other country.



For this version the newlisp.exe runtime is still UTF-8 enabled but newlisp-edit.lsp and all demo programs do a (set-locale "C") in the beginning because newlisp-edit.lsp and most demo programs use the decimal point when specifying color floats.



Worst case I can conditionally go back to non-UTF8 in both newLISP-GS (the Java part) and ship the non-UTF-8 newlisp.exe executable with it (on Win32).



I would hate to so this though, and we should at least try to get it going with all-UTF-8 :-). Java is Unicode through and through and it would be sad not to take advantage of it.



Also most newLISP users live in countries with non-ASCII character sets and would appreciate the flexibility UTF-8 brings to the table.





HPW:



I am not familiar with Autocad and do not fully understand the problem you are having, but here is a function which does more or less what you are trying to do:

Code Select Expand

(define (encode str)
(letn (len (length str) lst (unpack (dup "b" len) str))
(format (dup {%03d} (length lst)) lst)))

> (println (encode "ABC"))
414243
"\041\042\043"
>


or this:

Code Select Expand

(define (encode str)
(letn (len (length str) lst (unpack (dup "b" len) str))
(format (dup {x%2X} (length lst)) lst)))

> (println (encode "ABC"))
x41x42x43
"\x41\x42\x43"
>


unpack works always on byte boundaries. Is there perhaps a way to switch Autocad to UTF-8? IT seems to use one of the 256byte ISO character set, where special characters still only use one byte?



Lutz

[Cyril]

Please make sure to report with each problem the version you are running and the country or locale of your Windows installation.

Alas still doesn't working with Windows 98. It just cannot open any file (including script files intended to run). Russian Windows 98, Russian locale.



I believe there are not many Windows 98 users around here (maybe I am the only one), and I don't need GS. In fact GS just doesn't run on my system  (I have not reported this, because I believe it is Windows 98 specific problem, and nobody aside me uses it, and I don't need GS at all -- I am a console fan).



Maybe it is possible to put non-utf8 newlisp.exe on the site somewhere? Neither non-utf newlisp.dll nor non-utf newlisp-edit.lsp are needed by me.

[HPW]

For my decode problem I solved it with this:

Code Select Expand


(if utf8
 (setq pchar (pack "c"(-((unpack "b"(substr cstr dcount))0)shiftval)))
 (setq pchar (char(-(char(substr cstr dcount))shiftval)))
)


But still struggling with the other influenced commands:

newLISP v.9.2.6 on Win32, execute 'newlisp -h' for more info.

> (trim(trim "tinterlübket" "t")" ")

"interl129bke"

>



newLISP v.9.2.6 on Win32 UTF-8, execute 'newlisp -h' for more info.

> (trim(trim "tinterlübket" "t")" ")

"interl-übke"

The Umlauts readed from ASCII-Text files and processed in UTF gets different when I write them back to disk.



I understand your wish to move to UTF and as long you provide the makefile for NON-UTF, I could switch myself to the needed flavour.

I have set up MinGW to the version mentioned in the history and can now compile myself again.



But what happens when I do not know which flavour is installed on the end-user mashine?

[HPW]

Not sure if it is possible, but how about a dual-mode version which runs per default in UTF8-mode.

Then it can be set to ASCII-mode per command:



(set-encode "ASCII")

(set-encode "UTF8")

(set-encode)

>UTF8



Would add some size to the core, but everyone could use what he needs.

[Lutz]

The Umlauts readed from ASCII-Text files and processed in UTF gets different when I write them back to disk.

Yes, they get written back in UTF-8 by newLISP-GS. Your other applications probably generate files where umlaut characters are ISO/IEC-8859 one-byte-length characters.



This is, what we will try for version 9.2.7:



(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'



(2) Win32 versions are by default (set-utf8 nil) while Mac OS X/Unix/Linux versions are by default (set-utf8 true) on startup. Or should Windows also be UTF8 by default ???



(3) The newLISP-GS guiserver has a gs:set-utf8 to switch the mode on an of too and will set itself to 'nil' when starting up on Windows and to 'true' when starting up on any other platform.



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.



Comments from users familiar with UTF-8 issues, and specially those using multi-byte character sets (Asia, Middle East, Africa) are greatly appreciated.



Lutz

[newdep]

I dont understand why UTF-8 should be on by default?



From the history of computing UTF-8 is an extention to the OS

which is enabled by the user but default its off.



I would at least make unix versions default off.

[cormullion]

Please leave it on for Mac users ... :-)  I don't want to go backwards...!

[HPW]

(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]

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]

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]

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]

Lutz,



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



Norman.