development release newLISP v.9.9.92

[Lutz]

• more changes towards http://www.newlisp.org/downloads/development/newLISP-10.0-Release.html">version 10.0



files and changes notes: http://www.newlisp.org/downloads/development">http://www.newlisp.org/downloads/development

[HPW]

The changes in 9.9.92 for inc/dec breaks some more code.



Turtle.lsp from newLISP-TK:

Code Select Expand


(define (dragon sign level)
  (if (= 0 level)
   (turtle-forward 4)
   (begin
    (dec level) ;Remove quote for newLISP 10 (9.9.92)
    (turtle-right (sign 45))
    (dragon - level)
    (turtle-left (sign 90))
    (dragon + level)
    (turtle-right (sign 45)))))


Hanoi.lsp from newLISP-TK:

Code Select Expand


(define (setup-poles n)
  (set 'pole1 (set 'pole2 (set 'pole3 '())))
  (tk ".hw.can create rectangle 50 250 440 260 -fill green")
  (tk ".hw.can create rectangle 110 90 120 250 -fill green")
  (tk ".hw.can create rectangle 230 90 240 250 -fill green")
  (tk ".hw.can create rectangle 350 90 360 250 -fill green")
  (tk-yield)
  (while (> n 0)
   (push n pole1)
   (make-disk n 'pole1 (length pole1))
   (dec n))) ;Remove quote for newLISP 10 (9.9.92)


A lot of my own code will also be affected. ;-(

Has to be done. A FindAndReplace will do it. ;-)

[xytroxon]

Wouldn't it be better to introduce incf and decf to the setf family of functions?



And keep inc and dec with the set family?



--xytroxon

[Lutz]

I thought about this too, I know newLISP 'inc' and 'dec' work now similar to 'incf' and 'decf' in CL. But then I don't like weird function names and stopped short of redoing 'set' to work like 'setf' and abandoning the 'xxxf' business altogether, but thought that was too dramatic of a change.



There was also the idea of suffixing all destructive functions with a '!', set!, inc!, dec!, replace! etc. That would get rid of 'xxxf' too, but again , I thought that was too much of a change, and I wasn't sure it felt Ok either.



The way it is now, albeit not perfectly consistent, is a good compromise and maintains a minimum of continuity between versions 9.0 and 10.0.



From my point of view 10.0 is ready for release. The following November weeks will just be testing, testing, testing. 10.0 should last for a good while, so my and the community's effort can go into writing interesting modules, applications and into promoting the "new" newLISP.

[itistoday]

The status header feature introduced in 9.9.91 has been reworked and is

    simpler to use now. Whenever the first line output by an CGI program starts

    with "HTTP/", newLISP server mode will suppress putting out the standard

    status "HTTP/1.0 200 Ok" line and "Server: newLISP ..." line. Instead

    *all* header information must be supplied by the CGI program.

Thanks Lutz.  What would be perfect is if newLISP behaved like Apache by looking for the Status header, but this is OK too.  If you're going to do it this way though, what would help people easily write programs compatible with newLISP *and* Apache, is if newLISP were to provide a special environment variable to the program indicating it was running in newLISP -http mode.



This distinction is necessary because the 'cgi standard' and Apache don't want scripts spitting out the HTTP/1.0 header, that's their job.

I thought about this too, I know newLISP 'inc' and 'dec' work now similar to 'incf' and 'decf' in CL. But then I don't like weird function names and stopped short of redoing 'set' to work like 'setf' and abandoning the 'xxxf' business altogether, but thought that was too dramatic of a change.



There was also the idea of suffixing all destructive functions with a '!', set!, inc!, dec!, replace! etc. That would get rid of 'xxxf' too, but again , I thought that was too much of a change, and I wasn't sure it felt Ok either.



The way it is now, albeit not perfectly consistent, is a good compromise and maintains a minimum of continuity between versions 9.0 and 10.0.

This is indeed a slightly annoying situation.  I'm personally in favor of complete consistency... and so I like the set! -type functions (plus I think that would make it similar to Scheme).   But I also understand your worries of breaking too much code.  On the other hand, you've broken so much code with all these other changes so you may as well go for broke...

[Lutz]

If you're going to do it this way though, what would help people easily write programs compatible with newLISP *and* Apache, is if newLISP were to provide a special environment variable to the program indicating it was running in newLISP -http mode.

No problem, how about SERVER_SOFTWARE. The Apache server is setting this to "Apache/x.x". newLISP server mode could create/set this variable to "newLISP/10.0" or whatever version is running. Microsoft IIS also uses it, e.g. "Microsoft-IIS/6.0".



The script then could check this environment variable and react accordingly.

[itistoday]

No problem, how about SERVER_SOFTWARE. The Apache server is setting this to "Apache/x.x". newLISP server mode could create/set this variable to "newLISP/10.0" or whatever version is running. Microsoft IIS also uses it, e.g. "Microsoft-IIS/6.0".



The script then could check this environment variable and react accordingly.

That sounds perfect! :)

[unixtechie]

From my point of view 10.0 is ready for release.

Great. So we can consider the changes completed and start coding ;)).



One smaller thing though. It's a widely accepted and good practice to supply SHA1 crypto hashes with a software package, to assure the downloaders they get unmodified software.



I think it might be useful to post SHA1s both in the download dir and here.

This forum is just another place, so including a hash into an announcement here might help as one more security precausion/assurance that requires no effort.

[cormullion]

On the other hand, you've broken so much code with all these other changes so you may as well go for broke...

Don't encourage him. :)

[itistoday]

Don't encourage him. :)

lol. :-p

[HPW]

Hello Lutz.



In topic: http://www.alh.net/newlisp/phpbb/viewtopic.php?t=2495">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=2495



you explained the new init-loading.

The initialization file in either $HOME/.init.lsp or $USERPROFILE/.init.lsp or $DOCUMENT_ROOT/.init is loaded if it exists, else if $NEWLISPDIR/init.lsp exists, it is loaded.

and:

The rules are now the same for the main executable as for the imported DLL. This way several .init.lsp (with the dot) files can exist for different users in their home directories. You always can overwrite these rules by predefining NEWLISPDIR at the os-level during os startup. Then only that directory will be searched for init.lsp (without the dot).

In the first statement the NEWLISPDIR loading is 'else if'.

The second statement is, if NEWLISPDIR is there it is the only loading.

What's correct?



And when I use the WIN-API-call 'SetEnvVarValue' to set NEWLISPDIR for the current process, it is still using the OS-level-variable. (While API-CALL GetEnvVarValue shows the new value)



So is it possible to let the newLISP.DLL first look after a process-enviroment variable and when present only use this?



(Unexpected loading from a init.lsp could cause strange side-effects)

[Lutz]

The first quote is true, for both the newlisp executable and the library.



Both look for .init.lsp in the home directory first. The home directory depends on the owner of the process invoking newlisp.dll.



For libraries we could do the following:



The library newlisp.dll or newlisp.so will look for the environment variable NEWLISPLIB_INIT and load the file specified there instead of looking for HOME/.init.lsp or NEWLISPDIR/init.lsp. NEWLISPLIB_INIT must contain the full path/file-name of the file to be loaded.

[HPW]

The library newlisp.dll or newlisp.so will look for the environment variable NEWLISPLIB_INIT

When this will be read from the process environment variables, then it should solve this problem. It should not be the same environment storage place like NEWLISPDIR.

[Lutz]

NEWLISPLIB_INIT is working now for 9.9.93, but has to be defined at the OS system level on Windows. To do anything else for the Windows version its too late for 10.0. On Mac OS X and other Unix it does inherit from the caller.



If this is not what you want, just define NEWLISPLIB_INIT at the system level with some empty file. At least then you inhibit it from loading any potential %HOME%/.init.lsp. Any necessary initialization then can be handled by the lib-importing parent calling into the newlisp.dll.

[HPW]

Thanks for the new env variable.

I will try your advice.





New observation:



(write-line "Test")



works in prior releases to output to console.



Crashes on my WIN2K box and returns a '2' on my WIN XP box.

(Breaks most of my commandline scripts)