Maintenance Release v10.3.3 fixes bugs and makes performance enhancements.
Release notes: http://www.newlisp.org/downloads/newLISP-10.3.3-Release.html
Downloads: http://www.newlisp.org/index.cgi?page=Downloads
Hello,
The windows installer does not install newlisp.dll in my newlisp folder, only in windowssystem32.
(German win xp pro)
Edit: Ok, the release notes state this. In the first draft of the doc I thought there was written that it get into both places.
Quote from: "Release notes"
On MS Windows newlisp.dll is now installed in windows/system32 or what the main 32-bit DLL directory may be on a specific Windows platform.
Dang. This could be bad for me because I don't have an admin account on my office Windoze machine- , and the install could fail for me. Any reason why newlisp.dll
HAS to be in windows/system32?
Thanks! --Ricky
____________
- -- Draconian office rules prevail, and I wouldn't have a Windoze machine at home, of course. :)
This change was motivated by this diskussion:
http://newlispfanclub.alh.net/forum/viewtopic.php?f=9&t=3924
Maybe it would be good to install it in both places to make sure it always is found.
Here's what the installer says to me when I try to install 10.3.3:
Quote
Error opening file for writing:
C:Windowssystem32newlisp.dll
Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.
Just as I suspected. :(
At least, if it is copied to both places, as Hans-Peter suggests, I could just click "Ignore" for the above dialog and the installer could go on (it does BTW--I checked it), and then I'd have newlisp.dll in my newlisp directory. Thoughts?
Thanks! --Rick
I have to think about this a little bit more, but here are my current thoughts:
newLISP does not need newlisp.dll to run. The DLL is only needed when importing newLISP functionality into other applications.
Few people use the DLL at all, e.g. Windows is the only platform where it gets distributed. The DLL is only used by more advanced newLISP programmers. If there is no administrator access on a machine, there is always a workaround to install on a different machine and copy the DLL over into user space.
Having a standard place for newlisp.dll which is part of the standard library path, makes it easier to find the DLL for other applications w/o the need for extra environment variables. Other 3rd party Windows applications frequently take the same path.
I believe having the file in both places creates problems down the road. I have had several incidences of finding DLLs in different places on Windows and out of sync version wise. Sometimes the version is unknown and only the size or date gives a hint.
The need for an administrator password to install software on a machine, is a standard procedure on most platforms. Perhaps that should be respected? Again newLISP is full usable without newlisp.dll.
Another possibility would be to leave it our completely from the installer, have it downloadable on newlisp.org and let the developer deal with it, like it is already on Mac OSX and Unix.
Hello,
I can understand all arguments here.
I would vote for leaving it in the distribution. (whereever it goes)
Quote
newLISP does not need newlisp.dll to run.
Right, but when I want to callback from some other enviroments I use the DLL as the callback-bridge.
;-)
Hello, Lutz.
I updated the manual translated to Japanese.
newlisp_manual-10303
CodePatterns-20110920
There are in here (//https).
Thanks,
Thank you very much, Johu. The new Japanese versions are online:
http://www.newlisp.org/newlisp_manual-jp.html
and
http://www.newlisp.org/CodePatterns-jp.html
Hello,
Has anything changed in default-setting the locale?
My turtle demo for pdScript starts with:
(context 'Turtle)
(set 'color "blue")
(set 'direction -425.6857918)
...
And now bombs with: ERR: symbol expected in function set: .6857918
Now I have to set the locale:
(context 'Turtle)
(set-locale "C")
(set 'color "blue")
(set 'direction -425.6857918)
...
Or can the calling host influence this behaviour in the DLL?
Nothing has changed in the setting of the locale. UTF8 versions take the locale from the OS environment and non-UTF8 versions set the POSIX C default locale with decimal point.
But I could imagine that in an UTF8 environment the process importing newlisp.dll could change the OS environment in a way, that newlisp.dll sees the locale set by the importing process. But as far as I know, you are using the non-UTF8 version of newLISP and at least on Mac OS X such an effect cannot be seen when using newLISP itself as the importer.
Hello Lutz,
that does explain it. They contained a UTF-Dll so this shows this behaviour.