Release newLISP v 9.4.0

Started by Lutz, July 01, 2008, 06:25:41 AM

Previous topic - Next topic

Lutz

• many additions, changes and bug fixes



Read more about it here:

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



For source and Mac OS X, Win32 and Ubuntu Linux installers see:

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



For documentation, tutorials and instructional videos see here:

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



Many thanks to all in the newLISP community who helped to make this the best release ever.

m i c h a e l

#1
Congratulations on the release of 9.4.0, Lutz!



Thank you for providing us with such an awesome language to program in. Looking forward to seeing what's in store for newLISP.



m i c h a e l

Kazimir Majorinc

#2
Also, thank you and congratulations.



What do you expect to be the most active area of development in next period?
http://kazimirmajorinc.com/\">WWW site; http://kazimirmajorinc.blogspot.com\">blog.

newdep

#3
http://www.nodep.dds.nl/downloads/newlisp/thumbs.png">



;-)
-- (define? (Cornflakes))

Lutz

#4
Thanks for all the messages and thumbs up (literally :) ) to the 9.4 release.


QuoteWhat do you expect to be the most active area of development in next period?


There are still some gaps to fill in the new introduced general reference passing mechanism and in the new Cilk API.



There will be a point release (9.4.2 or 9.4.4) before the new school/college year starts in August/September. This is always the time of the year with most downloads. That release will not introduce new functions.



After that I want to write some code showing and applying the new techniques.

hsmyers

#5
Given the number of things not implemented for windows I think it is about time that you abandoned the platform.



--hsm
\"Censeo Toto nos in Kansa esse decisse.\"—D. Gale \"[size=117]ℑ♥λ[/size]\"—Toto

HPW

#6
QuoteGiven the number of things not implemented for windows I think it is about time that you abandoned the platform.


Nonsens. Even when some things are not implemented there, newlisp is great for doing a tiny lisp on windows!

And it is a good tradition to run on so much platforms as possible.

(And you should consider the market share of the OS's)
Hans-Peter

Lutz

#7
Even on Windows, newLISP has built-in far more functionality than any other Lisps or scripting languages. For many essential areas of functionality you would need extra modules in Pyhton, Perl or Commonn Lisp and Scheme.



newLISP is far beyond "tiny", if you refer to functionality. The only thing tiny about newLISP is its footprint on disk ;-)



The few things missing on Windows versus Unix are either not implemented in the GCC C-lib of the Windows version, like 'parse-date', or the functionality is simply not available on that OS, like Unix style forks, which also supports the new Cilk API in newLISP. There is a fork implementation form the Red-Hat Linux folks for Cygwin, but it is slow and unreliable. Cygwin is a Unix-like environment under Windows.



Although developing on Mac OS X is more fun than on Windows, I have no intention to abandon this platform. Still more than 65% of users world wide run newLISP on Windows. Many users run on both: the Windows and some sort of Unix platform. And as HPW mentioned, newLISP should be as multi-platform as possible.



Some users like Pjot and Norman have ported newLISP to less popular platforms like TRU64 Unix, OS-2 and Symbian and I always try to support these projects too. The current release also includes a makefile for i386 based OpenSolaris.

DrDave

#8
I'm pleased to hear that development continues for Windows. When I come across a function not availalble in newLisp, I can probably go to the WIN API and get what I need. If my end-user target is Windows, it doesn't matter if the app is no longer cross-platform.



Or to keep it cross-platform, include the newLisp code and the Win32 API code and just check which OS is running and use the appropriate code.
...it is better to first strive for clarity and correctness and to make programs efficient only if really needed.

\"Getting Started with Erlang\"  version 5.6.2

hsmyers

#9
As long as I have multiple processor boxes and do not have the ability to benefit from them, I'm hardly likely to enjoy second class citizen ship. Regards date and time parsing, precisely what is the problem--- lack of an existing library? Given that there is very little if anything about time and dates that should be OS dependent, there must be some portion of code somewhere that would provide a platform independent solution?



--hsm
\"Censeo Toto nos in Kansa esse decisse.\"—D. Gale \"[size=117]ℑ♥λ[/size]\"—Toto

Jeff

#10
PHP's time-parsing function is also os dependent, because it is based on the same code.  Someone could probably write something using scanf, but what takes time is getting the time zone and dst stuff right.



It is easy enough to write your own if you don't need to support all timezones and dst variants.
Jeff

=====

Old programmers don\'t die. They just parse on...



http://artfulcode.net\">Artful code

HPW

#11
QuotenewLISP is far beyond "tiny", if you refer to functionality. The only thing tiny about newLISP is its footprint on disk ;-)


Of cource I did not refer to functionality!!

I did mean footprint on disk and memory.

And it is so easy to integrate with other applications.



Glad to hear the commitment and that there are so much (65%) co-fellows on newlisp for windows.



;-)
Hans-Peter

cormullion

#12
Congratulations Lutz! Thanks for another great release of newLISP with loads of interesting and challenging new features for us...


QuoteGiven the number of things not implemented for windows...


What is that number? About 6...? 6 out of about 350 functions is pretty good really - about 98%. Surely that's a good score as regards cross-platform compatibility?



But - seriously - I do think that there's space in a future (9.5?) manual for a compatibility chart; lots of us might want to know of areas where users on other systems might have problems with our code. Not just Windows/Unix/Mac issues; I once had a problem where directory produced platform-dependent results. (Yes, I should have realised...!)



I get asked for my code sometimes, and I can't test it on other platforms: it would be useful to have some idea of where problems might lurk...



I think a general sscanf function - the opposite of format? - would be a good idea. No idea what it would look like though! I don't think the parsing of date/time strings poses many problems. And if the incoming data isn't consistent, then parse-date wouldn't be good enough anyway.

Ryon

#13
A compatibility chart is also an excellent idea as a promotional tool. Users could graphically see what can be done with their machines, click on the newLISP Manual and Reference, then think "Gee, is it really that easy?"
\"Give me a Kaypro 64 and a dial tone, and I can do anything!\"

Lutz

#14
Regarding a 'sscanf': it is on my list of things to do, and it will come one day as an inverse compatible function with current 'format'. Until then use 'regex' or other functions in newLISP handling regular expressions. Working with parenthesized regular sub expressions everything can achieved what a 'sscanf' would do, and more ;-)



Here is a page of differences between Win32 and Unix versions, I wrote some time ago, and updated for 9.4:



http://www.newlisp.org/index.cgi?page=Diff_UNIX_Win32">http://www.newlisp.org/index.cgi?page=Diff_UNIX_Win32



I am not sure at the moment if it is complete. If there is anything to add, let me know. The page was produced searching for Win32 in the manual and collecting all differences. There are also some subtle differences between different flavors of the Unix family, which are not covered here.



I will also update the current release 9.4 with a 9.4.1 this weekend, rounding out reference passing and fixing some leaks discovered using the fantastic Valgrind utility and running an extended test suite.