development release newLISP v.9.9.92

[Lutz]

• more changes towards version 10.0

files and changes notes: 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 all

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

(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

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)

[Lutz]

Good catch!

From the 9.9.93 changes notes:

'write-line' with just one argument will still take that argument as a either a file or string device to write too and write the string found in 'current-line'. The previous behavior of writing that string to the console is a historic relic when there was no 'println'. So the first argument is always the device to write too.

syntax: (write-line [int-file [str]])
syntax: (write-line [str-device [str]])

[Kazimir Majorinc]

! I think that ! for destructive functions is not that good idea because it suggests that destructive functions are somehow bad. In my opinion, such functions are just normal, and non-destructive functions are luck. Conrad Barski wrote that "Things only change a little bit from one moment to the next." If both destructive and non-destructive versions of some functions have sense, they should follow some other naming convention. In some languages, for example, there are append and append-to.

inc or incf? In old version

Code: Select all

x:=x+1 <=> (inc 'x) 
x^:=x^+1 <=> (inc x) 
X^^:=x^^+1 <=> (inc (eval x)) 
x^^^:=x^^^+1 <=> (inc (eval (eval x)))
...

In new version

Code: Select all

x:=x+1 <=> (inc x) 
x^:=x^+1 <=> (eval (list 'inc x)) 
x^^:=x^^+1 <=> (eval (list 'inc (eval x)))
x^^^:=x^^^+1 <=> (eval (list 'inc (eval (eval x))))

In new version "base" case (x:=x+1) is simpler, other cases are more complicated. As base case is usually needed, I think new inc has sense. But both? I think yes, in natural languages, science, programming, we try hard to keep our statements, formulas and expressions simple by introduction of new words and symbols. It seems to be very important for us. We have "if", "when" and "unless" - all very similar. Especially, we have "<" and ">=" although one of these and "not" are enough. I think everyone could agree that these small things are important, although not essential. From that point of view, more functions is always better so I agree with xytroxon.

[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! :)

Actually, I take that back. My apologies for not looking more into this in the past, but I've just been far too busy with other things and haven't had time to update my newLISP code to version 10 on the site--until today.

I've discovered that you cannot do it this way, currently newLISP searches for "HTTP/" and if it sees that it will suppress its headers and will simply spit out whatever the .cgi script spit out.

However, this is a Catch-22 situation as cgi scripts are *not supposed* to put out that header. That is the server's job, and if it's not allowed it will complain.

In other words, even if you check for the SERVER_SOFTWARE variable, you can't do anything about it because outputting HTTP/1.0 to prevent newLISP from saying things are "OK" will cause Apache to complain. And outputting Status: will cause newLISP to print out the HTTP/1.0 OK header, making Apache ignore the Status: header.

Luckily, it's easy to fix this bug, I've already fixed it in my version of 10.0.1.

In nl-web.c, simply change this line:

Code: Select all

strncmp(content, "HTTP/", 5)

To this:

Code: Select all

strncmp(content, "Status:", 7)

Edit: Unfortunately, additional changes are required to then get the newLISP server to work with this. It would need to copy the status number from the status header of the CGI script, and output the appropriate HTTP/1.0 header with that status number. I don't think suppressing the original Status: header of the CGI is necessary though.