64-bit milestone development release 8.9.7

[Lutz]

This is a milestone development release leading into the v.9.0 series of newLISP releases.



All integer arithmetic using the +,-,*,/,%,>>,<<,&,|,^ operators is now done in 64 bit. Many built-in functions like 'dotimes', 'factor', 'for', the new 'gcd','seek' and others now can take 64-bit size arguments additionally to the floats which where limiting precision to 52 bits.



Besides 64-bit handling some functions have benefitted in speed when running on CPUs with 64-bit registers like the PPC and many others from AMD and Intel, i.e. the function 'factor' about 5x on G4 PPC/OS X, or 2x on an Intel Celeron/MinGW. The overall size of the newLISP executable has only increased by about 3-4 % (part of this due to the new 'uuid' and 'gcd')



For files and detailed change notes see: http://newlisp.org/downloads/development/">http://newlisp.org/downloads/development/



Lutz

[pjot]

This 8.9.7 release runs out-of-the-box in Tru64Unix as well. Both Tru64 4.x and Tru64 5.x compile without problems. Also I found a new, fresh machine running 5.x, and following my own instructions :-)  newLisp compiled straight away.



All tests in 'qa-dot', and all my Unix-based console programs as well as Norman's, run in Tru64Unix without any modifications. Impressive!!



Thanks for this important milestone!



Peter

[newdep]

Also here..compilation for OS/2 without problems...



I still need to test the enhancements... ;-)



Thanks lutz..!

[cormullion]

Can you explain a bit more about find-all? What's the third option doing - is it like replace? Having trouble with statements like this:

Code Select Expand

(println (find-all {f*} "fee fi fo fum" (println $0) 0) )

(println (find-all {f*} "fee fi fo fum"))

[Lutz]

What you see is 'find-all' going into a loop on your example.



Your pattern expression {f*} says "match zero, one or more f", so it effectively can match "nothing". At this moment I do not know if this can be avoided by newLISP or PCRE or if it is like doing: (while true), which simply should be avoided ;)



You probably wanted to say:

Code Select Expand

(find-all {fw+} "fe fi fo fum")
=>("fe " "fi " "fo " "fum")


an 'f' followed by one or more word characters.



The third parameter does something to the expressions found, before assembling them in the list returned:

Code Select Expand

(find-all {fw+} "fe fi fo fum" (title-case $0))
=>("Fe" "Fi" "Fo" "Fum")

and you could mark subexpressions with parenthesis:

Code Select Expand

(find-all {(f)(w+)} "fe fi fo fum" (append $2 $1))
=> ("ef" "if" "of" "umf")

Lutz

[cormullion]

Thanks. I like the idea of find-all. Though it's interesting that you've made it different from replace, and regular expressions are the default. So i can't do the following, which seems an obvious parallel:

Code Select Expand


(println (replace "*m" "i learn by *making *mistakes" "m"))
;-> i learn by making mistakes
(println (find-all "*m" "i learn by *making *mistakes"))
;-> expecting  ("*m" "*m") but get regex error


member is more consistent, I think:

Code Select Expand

(println (member "*m" "i learn by *making *mistakes" ))
;-> *making *mistakes     not regex by default
(println (member "m+" "i learn by *making *mistakes" 0))
;-> making *mistakes


but I think I thought it wasn't before...



For the next version of my intro document, I'm going to put more about these functions in...! So expect more questions... :-)

[Lutz]

You can baskslash the *:

Code Select Expand

(find-all "\*m" "i learn by *making *mistakes")
=> ("*m" "*m")

On the above example you also see the reason why 'find-all' always will want a regular expression. If not you will just end up with a list where all members are the same. The purpose of 'find-all' is always to find substrings with certain characteristics, but different. The optional <expr> parameter then can be used to manipulate subexpressions in the found pattern.



Lutz



ps: I deleted my earlier post about this because it was logically flawed

[Dmi]

Lutz!

Is there any plans to implemnt something like "ref-all", which will return coordinates for all items, not only the first one?

The tasks related to XML or LDAP (LDIF parsing) will be simpler with it.

[Lutz]

Others have also asked for this and the idea came to me too, I will put it on my to-do list.



Lutz

[cormullion]

ps: I deleted my earlier post about this because it was logically flawed

:-) I did read it, though...



How about calling it regex-all?