newLISP development release v.10.1.10
newLISP development release v.10.1.10
• new functions and bug fixes
Files and changes notes: http://www.newlisp.org/downloads/development/
Files and changes notes: http://www.newlisp.org/downloads/development/
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: newLISP development release v.10.1.10
Awesome! Thanks...New 'extend' works like 'append' but modifies first list or string parameter.
Re: newLISP development release v.10.1.10
Will extend offer the same speed as write-buffer?Usage of write-buffer for string extension is discouraged and will be deprecated and then removed in future versions.
Hans-Peter
Re: newLISP development release v.10.1.10
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 read-buffer planned? If not, why not?
What's the difference between extend and push and write-buffer? Three things doing the same thing?
Is a fix for read-buffer planned? If not, why not?
Get your Objective newLISP groove on.
Re: newLISP development release v.10.1.10
It's deja vu all over again...
Either (date) or (date-value) is doing something funny...
(At least on Win 98 ;)
2010 1 26 should be: "Tuesday, January 26, 2010"
Also does this with v 10.1.9
-- xytroxon
Either (date) or (date-value) is doing something funny...
(At least on Win 98 ;)
Code: Select all
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"
>
Also does this with v 10.1.9
-- xytroxon
"Many computers can print only capital letters, so we shall not use lowercase letters."
-- Let's Talk Lisp (c) 1976
-- Let's Talk Lisp (c) 1976
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: newLISP development release v.10.1.10
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...)
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...)
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
Re: newLISP development release v.10.1.10
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:
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.
[quote]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.
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 all
(date (date-value 2010 1 26) ((now) -2) "%A, %B %d, %Y")
=> "Tuesday, January 26, 2010"
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.
[quote]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.
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
Re: newLISP development release v.10.1.10
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:
m i c h a e l
P.S. I think Hans-Peter's question got overlooked:
Hans-Peter wrote:Will extend offer the same speed as write-buffer?
Re: newLISP development release v.10.1.10
Code: Select all
> (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
Time to replace write-buffer in our code.
Hans-Peter
Re: newLISP development release v.10.1.10
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:
HPW:
Yes its faster and even more pronounced when you measure without the 'dotimes' overhead:
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:
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.
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 all
> (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 all
> (let (s "") (time (write-buffer s "x") 1000000))
220.135
> (let (s "") (time (extend s "x") 1000000))
174.689
>
Code: Select all
; on UNIX
(extend s str "\n")
; or on Windows
(extend s str "\r\n")
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: newLISP development release v.10.1.10
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:
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.
After thinking about it some more, I observe the following on Ubuntu for multiple (possibly incompatible) versions:
Code: Select all
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
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.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
Re: newLISP development release v.10.1.10
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.
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.
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: newLISP development release v.10.1.10
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.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.