development release newLISP v.9.9.95

[Lutz]

• file:// URLs in get-, put- and delete-url



• keyword tab-expansion in newLISP console



• bug fixes



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





ps: final 10.0 release probably next week

[HPW]

Tried the DLL and get an crash:

Code Select Expand


> (import "newlisp.dll" "newlispEvalStr")
newlispEvalStr <6BD6B5F0>
> (get-string (newlispEvalStr "(+ 3 4)"))


Does not work from newLISP and neobook either.

(WIN XP Pro german)

[Lutz]

do both things work on 9.9.94? Are you on XP or Vista?

[newBert]

Seems to work on 9.9.94 (a quick try before installing v.9.9.95) ... and on WinXP-SP3

 ;-)

Code Select Expand

newLISP v.9.9.94 on Win32 IPv4, execute 'newlisp -h' for more info.

> (import "newlisp.dll" "newlispEvalStr")
newlispEvalStr <6BD6B34D>
> (get-string (newlispEvalStr "(+ 3 4)"))
"7n"
>

and on 9.9.95

Code Select Expand

newLISP v.9.9.95 on Win32 IPv4, execute 'newlisp -h' for more info.

> (import "newlisp.dll" "newlispEvalStr")
newlispEvalStr <6BD6B5F0>
> (get-string (newlispEvalStr "(+ 3 4)"))


outputs "7n" ... only after some seconds !

[Lutz]

I have reposted:



http://www.newlisp.org/downloads/development/newlisp-9995-win-gs-125.exe">http://www.newlisp.org/downloads/develo ... gs-125.exe">http://www.newlisp.org/downloads/development/newlisp-9995-win-gs-125.exe



and source:



http://www.newlisp.org/downloads/development/newlisp-9.9.95.tgz">http://www.newlisp.org/downloads/develo ... 9.9.95.tgz">http://www.newlisp.org/downloads/development/newlisp-9.9.95.tgz



correcting the problem with the Win32 shared DLL

[newBert]

Thanks, now it works !... What a quick correction !



:-)

[HPW]

Yes, everything is running now again!



Thanks!



;-)

[Cyril]

ps: final 10.0 release probably next week

Lutz, I have reported this bug already, it is minor but annoying: the utility link.lsp, used to linking newlisp script with win32 executable, does NOT work with latest releases: it passes a quoted symbol as a parameter to write-buffer.

Code Select Expand

   ;; this field gets read by the newLISP startup
    (write-buffer handle 'buff 4)
    (set 'buff (read-file lispSourceName))
    (set 'keylen (pack "ld" (length buff)))
    (write-buffer handle 'keylen 4)

    ;; append lisp source encrypted at the end
    (seek handle size)
    (set 'buff (encrypt buff (string (length buff))))
    (write-buffer handle 'buff (length buff))
    (close handle))


The obvious fix works fine, I hope it will be included in 10.0 release. I have noted this, because I use it for shipping an executables to non-geeky users on a regular basis, and it breaks suddenly. ;-) And, if we are talking about write-buffer, the error message about the old usage is misleading:

Code Select Expand

newLISP v.9.9.95 on Win32 IPv4, execute 'newlisp -h' for more info.

> (setq x "xxx")
"xxx"
> (setq y "yyy")
"yyy"
> (write-buffer x 'y 3)

ERR: string expected in function write-buffer : 3

Why 3, why not 'y?

[Lutz]

The source package was updated twice this morning shortly after the first upload, and has a fixed link.lsp.



ps: I'll look into the error message reporting a wrong parameter

[Cyril]

The source package was updated twice this morning shortly after the first upload, and has a fixed link.lsp.

Yes, I see now, it is exactly three bytes shorter! ;-) I've missed this, because I've downloaded windows binary, not source. Now I have both.

[Cyril]

ps: final 10.0 release probably next week

Preparing my newlisp.vim to 10.0 release, I've found a bunch of predefined functions which status is unclear for me. I am confused which is the preferred way to highlight them. The functions in question are:



* integer -- shares the code with int, removed from documentation long ago. I believe I should move it to "obsolete" section of my highlighter. This is the simple case, I think.



* default -- this one was a big surprise for me. It returns the value of the default functor of context given, but I failed to find any note about it in documentation. Is it to be removed, or to be documented, or is it already documented but mislooked by me?



* dump-symbol -- as far as I have understood, this is a debugging function used during development and not compiled into production release. I think it is worth to highlight it in "do not use" colors nevertheless, just to avoid collisions of debugging builds with user code.



Any comments? I am going to prepare new release of newlisp.vim for inclusion into 10.0 release. No major changes are planned, only the function list cleanup.

[Lutz]

- integer -

Yes, move to obsolete, and I will finally disable it completely in 9.9.96.



- default -

Will be documented again for 10.0, has little usage, because now in most situations default functors are assumed automatically, but there might still be instances where one is happy to have it.



- dump-symbol -

Yes, this is/was only for debugging and not compiled into normal releases. I am constantly looking for faster symbol tree code, but so far haven't found anything. The current one at least is rock solid.



There will be a 9.9.96 on Friday or Saturday with bug fixes.

[xytroxon]

Module infix.lsp only has limited set of functions...



(set 'operators '(

  ("=" setq 2 2)

  ("+" add 2 3)

  ("-" sub 2 3)

  ("*" mul 2 4)

  ("/" div 2 4)

  ("^" pow 2 5)

  ("sin" sin 1 9)

  ("cos" cos 1 9)

  ))



Needs %, sqrt, log, tan, etc...



-- xytroxon