newLISP v.10.7.0 Stable Release

[Lutz]

Stable release v.10.7.0 adds functionality to existing functions, adds a new function and fixes bugs.



Release Notes: http://www.newlisp.org/downloads/newLISP-10.7.0-Release.html">http://www.newlisp.org/downloads/newLIS ... lease.html">http://www.newlisp.org/downloads/newLISP-10.7.0-Release.html

Downloads: http://www.newlisp.org/index.cgi?Downloads">http://www.newlisp.org/index.cgi?Downloads



Thanks to everybody for their contributions and suggestions.



Ps: on Mac OS X this is the last release for the PPC CPU architecture, discontinued in 2005/6

[HPW]

Hello Lutz,



Thanks for the ongoing development. Getting better and better.

Also thanks for the spererate UTF-8 version's of the windows-bineries on the download-page

I updated my neobook plugin-zip with the new 10.7 Dll.



Regards

[rrq]

On the downloads page, I noticed that the Ubuntu packages are wrongly named:

UBUNTU Debian installer newLISP v.10.7.0 for UBUNTU on i386

    UBUNTU Debian installer newLISP v.10.7.0 for UBUNTU on i386 UTF-8 enabled

though being for amd64 rather than i386.

[johu]

Hello, Lutz.



I finished translartions of manuals.



CodePatterns-10604

guiserver_manual-171

newlisp_manual-10700



There are in https://onedrive.live.com/?cid=23a9a25e1aec3626&sc=documents&id=23A9A25E1AEC3626!1450">here.



and maybe

line 24222 in newlisp_manual v10.7.0

syntax all random functions called subsequenly like

　　　　　　　　　　　　　　　　　　　↓

syntax all random functions called subsequently like

Regards,

[Lutz]

Many thanks, Johu and Ralph. Everything is updated.

[protozen]

Thanks Lutz! I'm glad to see that updates and development still goes on =)



Newlisp makes me enjoy programming again.

[rrq]

Incidentally, the "UBUNTU on amd64 UTF-8 enabled" package installs nicely on Debian 8 (Jessie) as well, and probably the non-UTF-8 version does as well.



However, the zlib.lsp module needs an update to insert a path option

Code Select Expand

"/lib/x86_64-linux-gnu/libz.so.1" ; Debian 8, 64bit
That path option is also for Ubuntu 14.04, although there is the additional link "/usr/lib/x86_64-linux-gnu/libz.so.1" remnant from 12.04. I don't have a 64bit 12.04 available, so I can't (re-)confirm that the "/usr" prefix is needed for 12.04.



Note that both Ubuntu and Debian (with multi-arch installed) sport a  /lib/i386-linux-gnu/libz.so.1 library as well, so the 64bit path must be tested before that path. All in all, it becomes

Code Select Expand

(set 'files '(
    "/lib/x86_64-linux-gnu/libz.so.1" ; Ubunto 14.04 64bit, & Debian 8 64bit
    "/usr/lib/x86_64-linux-gnu/libz.so.1" ; Ubuntu 12.04 LTS 64bit
    "/lib/i386-linux-gnu/libz.so.1" ; Ubuntu 13.04
    "/usr/lib/libz.so" ; Linux, BSD, Solaris
    "/usr/lib/libz.so.4.1" ; OpenBSD 4.6
    "/usr/lib64/libz.so" ; for 64Bit CentOS 6 Linux
    "/usr/lib/libz.dylib" ; Mac OSX / Darwin
    "libz1.dll" ; MS Windows
))
I haven't checked all other modules.

[abaddon1234]

so the 64bit path must be tested before that path.

https://www.sbobet168.com/sbobet777/">sbobet777

[hartrock]

Title of http://www.newlisp.org/downloads/newLISP-10.7.0-Release.html">//http://www.newlisp.org/downloads/newLISP-10.7.0-Release.html is

newLISP v.1.7.0 Release Notes...

At bottom there is

- development version 1.64

- guiserver.jar version 1.65 (probably wrong, too),

.



Besides this: Thanks for the ongoing work!

[johu]

Hello Lutz,



I have a question.



About now function,

Linux version or newLISP in web

> (now 0 -2)

540

but, Windows version newLISP v.10.7.0

> (now 0 -2)

600

and Windows version newLISP v.10.6.2

> (now 0 -2)

540

In this connection, the time zone offset in minutes of Japan is 540.



Did only Windows version change?



Regards,

[Lutz]

It is incorrectly adjusting for daylight bias in 10.7.0 on Windows. This will be set back to previous 10.6.2 behavior in a future version.



The intend was to make values compatible between Unix and Windows during daylight savings time. But it breaks when outside of daylight savings time. The assumption was, that the daylight bias is only reported when daylight savings is active, which is not true at least on Windows. Unfortunately the whole daylight savings behavior is inconsistent even between different Unix flavors.

[johu]

I understand.



Thank you for the detailed explanation.

[johu]

Hello Lutz,



https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms724421%28v=vs.85%29.aspx">Windows API GetTimeZoneInformation's return value is

Return-value　Description

　　　0　　　Daylight saving time is not used in the current time zone, because there are no transition dates or automatic adjustment for daylight saving time is disabled.

　　　1　　　The system is operating in the range covered by the StandardDate member of the TIME_ZONE_INFORMATION structure.

　　　2　　　The system is operating in the range covered by the DaylightDate member of the TIME_ZONE_INFORMATION structure.

Therefore, it may be used for (now -1) on MS Windows, though daylight bias in minutes. And it seems like Linux/Unix.

Or when the return value is 2, it may be able to adjust (now -2) for daylight bias.



Regards,

[Lutz]

Thanks Johu, for better testing, I will come back to this mid March when daylight savings time starts in the US.

[Lutz]

... time zone offset in the 'now' function now switching fine between standard and daylight savings time on Windows:



http://www.newlisp.org/downloads/development/inprogress/newlisp_manual.html#now">http://www.newlisp.org/downloads/develo ... l.html#now">http://www.newlisp.org/downloads/development/inprogress/newlisp_manual.html#now



http://www.newlisp.org/downloads/development/inprogress">http://www.newlisp.org/downloads/development/inprogress