development release newLISP v.9.9.92

[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]

In new version

Code Select Expand

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 Expand

strncmp(content, "HTTP/", 5)

To this:

Code Select Expand

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.