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/

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 all

(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 all

 (find-all {f\w+} "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 all

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

and you could mark subexpressions with parenthesis:

Code: Select all

(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 all

(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 all

(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 all

(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?