newLISP development release v.10.1.10

[Lutz]

• new functions and bug fixes



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

[cormullion]

New 'extend' works like 'append' but modifies first list or string parameter.

Awesome! Thanks...

[HPW]

Usage of write-buffer for string extension is discouraged and will be deprecated and then removed in future versions.

Will extend offer the same speed as write-buffer?

[itistoday]

Congrats on the release! Some questions though:



What's the difference between extend and push and write-buffer? Three things doing the same thing?



Is a fix for http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=3452">read-buffer planned? If not, why not?

[xytroxon]

It's deja vu all over again...  



Either (date) or (date-value) is doing something funny...

(At least on Win 98 ;)

Code Select Expand

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

> (date (date-value 2010 1 26) 0 "%A, %B %d, %Y")
"Monday, January 25, 2010"
>


2010 1 26 should be: "Tuesday, January 26, 2010"



Also does this with  v 10.1.9



-- xytroxon

[TedWalther]

Lutz, thanks for the big step forward in the configure script!



I have some further ideas, and would like your feedback:



Because the language changes with each release, I put the version number in the install directory, so you could have multiple versions installed at once.  In looking at how this is done on Linux and BSD, I see that instead of $package-$version, they have $package/$version.  This is almost universal.  I think $package/$version is a good default.



An uninstall script.  If you specially customized your installation paths, you may not be able to do a full uninstall afterward, if you blew away your source tree.  I would like to generate a custom uninstall script, called "uninstall-newlisp", which would go in the $datadir.  That way you could always do a clean uninstall of a particular version, even without the original source tree or configuration options.



I'm not sure how to handle multiple versions of manpages; will have to look into this.



I would like to update newlisp-edit to match the correct load paths for the release.  sed doesn't work because of the slashes in the pathnames.  Any ideas?  If not I'll have to play around with auto-escaping. In shell script.  (actually, I just had an idea, if the "r" function in sed works as advertised...)

[Lutz]

itistoday:



As mentioned in the manual and release notes, the string-device syntax for 'write-buffer' will be deprecated. 'push' has only overlapping functionality with string appending, as it also can insert at any location and is also the inverse to 'pop'. Regarding 'read-buffer' I expressed my views already in an earlier thread, and 'read-buffer' will not change.



xytroxon:



You have to give the correct offset for your locale/geographical location when using 'date' with format; you can take that from the 'now' function:

Code Select Expand

(date (date-value 2010 1 26) ((now) -2) "%A, %B %d, %Y")

=> "Tuesday, January 26, 2010"

This may not be clear from the doc examples which are all for GMT.



TedWalther:



Except for the binary installers, I am doing a versioning already when doing 'make install' for the binary in /usr/bin. A /usr/bin/newlisp-x.x.x is installed and a link created to an un-versioned /usr/bin/newlisp.



I saw you are also doing a versioned /usr/share/doc/ install via 'configure-alt', but I want to keep that un-versioned in the standard configure. I like to have it as simple and less error-prone as possible.

I would like to update newlisp-edit to match the correct load paths for the release[/code]



This has already been done for newlisp-edit.lsp in 10.1.10 (but haven't tested it yet). Not sure what problem you have with the 'sed' utility. I updated the 'make version' part in 'Makefile' to update 'configure-alt' via 'sed' too and it worked fine for me.

[m i c h a e l]

Thank you for the new release, Lutz! extend is a welcome addition.



m i c h a e l



P.S. I think Hans-Peter's question got overlooked:

Will extend offer the same speed as write-buffer?

[HPW]

Code Select Expand


> (setq a "123")
"123"
> (time(dotimes (x 1000000)(write-buffer a "456")))
2878.385
> (setq a "123")
"123"
> (time(dotimes (x 1000000)(extend a "456")))
2784.525


So seems slightly faster! ;-)

Time to replace write-buffer in our code.

[Lutz]

xytroxon:



More clarification regarding 'date' and 'date-value':



'date-value' (with or without parameters) will always give the same UTC number regardless of geographical location, it also always will interpret the dates in parameters as UTC.



'date' will give the local time relative the UTC value it gets, therefore the  date appearing is lower when in the western hemisphere. Its UTC parameter must be adjusted therefore:

Code Select Expand

> (date 0)
"Wed Dec 31 19:00:00 1969"   <--- "negative" epoch time in EST offset by 300 min
>
> (date 0 ((now) -2))
"Thu Jan  1 00:00:00 1970"   <--- UNIX epoch time
>




HPW:



Yes its faster and even more pronounced when you measure without the 'dotimes' overhead:

Code Select Expand


> (let (s "") (time (write-buffer s "x") 1000000))
220.135
> (let (s "") (time (extend s "x") 1000000))
174.689
>


Also: 'extend' can take more then one string (or list) argument to extend the string (or list). Because of this, the string-device syntax of 'write-line' can be deprecated as well; you can do:

Code Select Expand

; on UNIX
(extend s str "n")
; or on Windows
(extend s str "rn")

Version 10.2.0 will not document string-device modes for 'write-buffer' and 'write-line' anymore, but they will still work for a few versions.

[TedWalther]

I see newlisp-edit has been updated.  Beautiful little one-liner.  When I ran diff, somehow I missed seeing that change.

After thinking about it some more, I observe the following on Ubuntu for multiple (possibly incompatible) versions:

Code Select Expand


drwxr-xr-x   2 root root        4096 2009-10-11 17:41 /usr/share/automake-1.11
drwxr-xr-x   2 root root        4096 2009-10-11 17:41 /usr/share/automake-1.9


So the shared data at least is being stored in a location consisted with Debian/Ubuntu standards, and likely also the BSD standards.



I would also like to start doing the symlink thing with newlisp-edit and newlispdoc to match the newlisp binary, so the three pieces of code always stay coordinated in the same version, in case someone does an install without doing an uninstall first.

[Lutz]

Versioning beyond the newLISP executable binary is not required. Even if not uninstalled, newlisp-edit and newlispdoc are overwritten with a new install and this way the three programs will always be in sync.



With the newlisp file binary the situation is different. Typically it happens, that a new newLISP version is installed and one or more scripts by the user begin to fail. At this moment it is convenient to just rename the first line in script to the previous working version, e.g.:



!/usr/bin/newlisp

to

#!/usr/bin/newlisp-newlisp-10.1.7



The only reason for a user to go back to an older version is, to make user scripts working again or to develop and test scripts for a server installation with an older version installed.



ps: uploaded a fixed Makefile and makefile_original_install, which had the version number missing.

[TedWalther]

Thanks for clarifying Lutz.  You are right.  If someone really wants to run separate version of newlisp, the --prefix stuff allows them to do a completely separate install.