newLISP Maintenance Release v10.3.3

Notices and updates
Locked
Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

newLISP Maintenance Release v10.3.3

Post by Lutz »

Maintenance Release v10.3.3 fixes bugs and makes performance enhancements.

Release notes: http://www.newlisp.org/downloads/newLIS ... lease.html

Downloads: http://www.newlisp.org/index.cgi?page=Downloads

HPW
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by HPW »

Hello,

The windows installer does not install newlisp.dll in my newlisp folder, only in windows\system32.
(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.
Last edited by HPW on Wed Sep 21, 2011 6:04 pm, edited 2 times in total.
Hans-Peter

rickyboy
Posts: 607
Joined: Fri Apr 08, 2005 7:13 pm
Location: Front Royal, Virginia

Re: newLISP Maintenance Release v10.3.3

Post by rickyboy »

Release notes wrote: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. :)
(λx. x x) (λx. x x)

HPW
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by HPW »

This change was motivated by this diskussion:

http://newlispfanclub.alh.net/forum/vie ... f=9&t=3924

Maybe it would be good to install it in both places to make sure it always is found.
Hans-Peter

rickyboy
Posts: 607
Joined: Fri Apr 08, 2005 7:13 pm
Location: Front Royal, Virginia

Re: newLISP Maintenance Release v10.3.3

Post by rickyboy »

Here's what the installer says to me when I try to install 10.3.3:
Error opening file for writing:

C:\Windows\system32\newlisp.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
(λx. x x) (λx. x x)

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by Lutz »

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.

HPW
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by HPW »

Hello,

I can understand all arguments here.
I would vote for leaving it in the distribution. (whereever it goes)
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.
;-)
Hans-Peter

johu
Posts: 143
Joined: Mon Feb 08, 2010 8:47 am

Re: newLISP Maintenance Release v10.3.3

Post by johu »

Hello, Lutz.

I updated the manual translated to Japanese.

newlisp_manual-10303
CodePatterns-20110920

There are in here.

Thanks,

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by Lutz »

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

HPW
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by HPW »

Hello,

Has anything changed in default-setting the locale?

My turtle demo for pdScript starts with:

Code: Select all

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

Code: Select all

(context 'Turtle)

(set-locale "C")

(set 'color "blue")

(set 'direction -425.6857918)
...
Or can the calling host influence this behaviour in the DLL?
Hans-Peter

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by Lutz »

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.

HPW
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: newLISP Maintenance Release v10.3.3

Post by HPW »

Hello Lutz,

that does explain it. They contained a UTF-Dll so this shows this behaviour.
Hans-Peter

Locked