newLISP release version 8.7.0

Lutz · Post by **Lutz** » Sat Oct 15, 2005 2:39 pm

* many additions, improvements and some bug fixes

for release notes 8.7.0 see: http://newlisp.org/downloads/newLISP_87 ... Notes.html

for files see: http://newlisp.org/index.cgi?page=Downloads

new packages/links for RPM and Slackware will follow later, when they come available.

Thanks to everybody on this board contributing with ideas for new functions and features and identifying bugs and other shortcomings.

Lutz

Fanda · Post by **Fanda** » Sat Oct 15, 2005 7:37 pm

You were quick. There is a new command 'append-file'!

Fanda

newdep · Post by **newdep** » Sat Oct 15, 2005 10:00 pm

Nice release Lutz, Thanks for the addons!

tom · Post by **tom** » Sun Oct 16, 2005 3:22 am

Need an Arch Linux package?
http://perpetualnewbie.info/archlinux/p ... pkg.tar.gz
or it's PKGBUILD?
http://perpetualnewbie.info/archlinux/p ... p/PKGBUILD

pjot · Post by **pjot** » Sun Oct 16, 2005 3:21 pm

The newLisp 8.7.0 package for Slackware 10.2 has been accepted with a rate of 3 ("Excellent') at Linuxpackages.net.

Details can be found here:

http://www.linuxpackages.net/pkg_details.php?id=7883

Please note that this package also will run on Slackware 10.1 and 10.0.

Regards
Peter

pjot · Post by **pjot** » Sun Oct 16, 2005 8:14 pm

NewLisp 8.7.0 survives all tests again on Tru64Unix, so I created a new installpackage (SETLD) which can be downloaded from here:

http://www.turtle.dds.nl/newlisp/NEWLISP870.tar.gz

Unzip, untar and install with 'setld -l NEWLISP870'.

This package will run on Tru64Unix 4.x and 5.x.

Regards
Peter

pjot · Post by **pjot** » Sat Oct 22, 2005 12:52 pm

This new release does not seem to work anymore on WindowsME (I know, WinME is not supported). Funny thing however is, that at least until newLisp 8.6.2 there were no problems.

If I run a newlisp 8.7 program now on WinME, I receive the error "newLisp has caused an error in KERNEL32.DLL". Also after rebooting etc. If I put back the 8.6.2 binary the problem vanishes.

A diff between newLisp 8.6.2 'win32-utils.c' and the same file in release 8.7 gave no results. So I must seek it somewhere else.

Is there a place where I still can download development releases 8.6.3, 8.6.4, 8.6.5, 8.6.6, 8.6.7 ? It's just for my curiousness, to see what causes this issue, since my own tools may suffer from the same thing in the future, for I compile with MinGW also.

(In a worst case scenario this problem may also reveal a genuine Win32 issue, but on Win2000/XP newLisp 8.7 runs fine though. Maybe these platforms have better memory protection? Or WinME really is no good at all?)

Peter

Lutz · Post by **Lutz** » Sat Oct 22, 2005 1:18 pm

I can email you some of the older development releases. I am not sure if I have your correct email address, drop me a private message with you email and I send you some of the older files.

Lutz

pjot · Post by **pjot** » Sat Oct 22, 2005 3:01 pm

Well, the older releases you sent me also crash! After searching my other computers as well, it appears I compiled 8.6.2 myself previously, with an adjusted Makefile.

The thing I changed in the MinGW makefile, was removing the '-O3' optimization flag to the GCC compiler. Then it runs fine.

Now in every release, also 8.7.0, if I remove this flag and recompile, the 'newlisp.exe' runs like a dream, on WindowsME.

One other thing you might like to know: the size of the 8.7.0 binary when recompiled without the '-O3' optimization flag is only 203264 bytes. While your original 'newlisp.exe' binary consists of 217.600 bytes, almost 14k bigger.

The '-g' flag for debugging purposes does not create extra overhead.

Maybe interesting to know. For me it is :-)

Thanks!
Peter

pjot · Post by **pjot** » Sat Oct 22, 2005 3:12 pm

By the way: if size is important, you can also compile with the '-Os' optimization flag.

The resulting 8.7.0 newlisp.exe binary has a size of only 140288 bytes!!! And runs fine in WinME also.

HPW · Post by **HPW** » Sat Oct 22, 2005 6:33 pm

Removing '-O3' optimization flag does not give me any filesize reduction (They get bigger).
(MINGW 3.1 on WIN XP PRO german)

But changing to '-Os' gives me:

EXE 151552 Bytes
DLL 167936 Bytes (with runtimepacker 86016 Bytes)

This is pretty smaller. So is it save to do so?
Then I would like to use it in the future!

Small is beautifull!
;-)

pjot · Post by **pjot** » Sat Oct 22, 2005 7:00 pm

Hm that is strange! Without the -O3 I save about 14k, but I use a newly installed MinGW 4.1 on WinME. Maybe the newer MinGW version is the reason? (WinME definitely not!)

Anyway, a smaller newLisp binary may reduce execution speed of newLisp programs, this is something we should check first, I guess....

Peter

Lutz · Post by **Lutz** » Sat Oct 22, 2005 8:25 pm

I have used MinGW 4.1.1 for the 8.7.0 Win32 release. Perhaps I make a -O2 compiled .exe available for WinME users.

I guess that -O3 is inlining more stuff to gain speed. The function inlining makes the code bigger.

Lutz

HPW · Post by **HPW** » Sun Oct 23, 2005 7:18 am

I upgrade to 4.1.0 (I see no 4.1.1 on MinGW site):

Changing to '-O2' gives me:

EXE 180224 Bytes
DLL 196608 Bytes (with runtimepacker 90112 Bytes)

(A little bigger than '-Os')

So is this the best option for performance and WIN compatibility?

pjot · Post by **pjot** » Sun Oct 23, 2005 7:51 am

The '-O2' optimization also crashes on WindowsME... With '-O1' or '-Os' however newlisp.exe runs fine.

Lutz: for me it is not necessary to host an additional binary for Windows9x/ME platforms, but maybe you could add an additional line (commented out) to the makefile_mingw file as you do with makefile_linux?

HPW: strange thing is, when I compile with '-O2' the binary becomes smaller (178688 bytes ) and with '-O1' even smaller (171008 bytes). Without any optimization I get 203264 bytes.

With '-Os' my resulting binary is 140288 bytes, I have put this binary on my website here: http://www.turtle.dds.nl/newlisp/newlisp.exe

Maybe we should benchmark some newLisp programs to find out the best optimization?

Peter

HPW · Post by **HPW** » Mon Oct 24, 2005 8:17 am

`-Os'
Optimize for size. `-Os' enables all `-O2' optimizations that do
not typically increase code size. It also performs further
optimizations designed to reduce code size.

`-Os' disables the following optimization flags:
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks -fprefetch-loop-arrays

If you use multiple `-O' options, with or without level numbers,
the last such option is the one that is effective.

`-Os' disables a lot of optimizations.
But subjectiv my application does not run signifikant slower.
Have to test more (and also on WIN95).