Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - rickyboy

Pages1 2 3
#1
newLISP and the O.S. / newlisp builds with libffi on OpenBSD 5.9
April 06, 2016, 08:22:31 AM
Well, the title says it all.  This is in response to a question Ted had http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=2&p=23650#p23650">here.



I just happen to have an OpenBSD 5.9 system with libffi installed


Code Select
$ uname -srm
OpenBSD 5.9 amd64
$ pkg_info -Q libffi
libffi-3.2.1p0 (installed)
I successfully built newlisp-10.7.0 with libffi, just now


Code Select
~/builds/newlisp-10.7.0 $ ./newlisp
newLISP v.10.7.0 64-bit on BSD IPv4/6 UTF-8 libffi, options: newlisp -h

> (import "libc.so.84.2" "atof" "double" "char*")
atof@F9D5A9BEB00
> (atof "3.141")
3.141
But bare in mind that if you (package) install newlisp-10.7.0 via `pkg_add newlisp`, it is NOT built with libffi.
#2
newLISP newS / Manual erratum: example in `index`
September 29, 2015, 08:13:36 AM
As reported by github user https://github.com/fuxoft">fuxoft in https://github.com/kosh04/newlisp/issues/3">//https://github.com/kosh04/newlisp/issues/3.


QuoteIn the documentation of the "index" function, the last example line says:



(select '(1 10 3 6 4 5 11) '(1 3 6)) → (1 3 6)



This is wrong. The returned value is not (1 3 6) but (10 6 11).

The culprit can currently be spotted here:

http://www.newlisp.org/downloads/newlisp_manual.html#index">//http://www.newlisp.org/downloads/newlisp_manual.html#index
#3
newLISP in the real world / Weird behavior for function `symbol?`
January 10, 2015, 06:51:47 PM
Running 10.6.0 on FreeBSD.



Check this:


Code Select
> (context 'Another)
Another
Another> (symbol? 'x)
true
Another> (symbol? 'Try:x)

ERR: context expected in function symbol? : Another:Try
But the same calls work in MAIN.


Code Select
> (symbol? 'x)
true
> (symbol? 'Try:x)
true
Why?
#4
newLISP newS / newlisp 10.6.2 build on FreeBSD 10.0
October 02, 2014, 08:34:40 PM
Just a quick note FYI.  For another topic in the fanclub, I needed to build 10.6.2.  I was on one of my FreeBSD machines, so I did the build there.  Bottom line is that it builds without an issue.



There was only one change I had to make for the build.  This:


Code Select
$ make
should now be this:


Code Select
$ make CC=clang
because clang is now the default compiler (vice gcc) starting with FreeBSD 10.



I could have `pkg install`ed gcc first, then built newlisp, but hey I didn't really need gcc anyway; so why bother.  :)
#5
Anything else we might add? / Welch's t-test
September 04, 2013, 02:30:10 PM
Lutz,



Have you ever thought about adding http://en.wikipedia.org/wiki/Welch%27s_t_test">Welch's t-test as a primitive to newLISP?  Could be another "mode" of the current t-test primitive or you could come up with another name.



Here's a newLISP implementation -- for fun, but also I had to implement it for a stat analysis I recently performed because I couldn't assume that the two population variances were equal, and people better than I at this inform me that this is the better test under this condition.


Code Select
(define (welch-t-test xs ys)
  (letn (nx (length xs) ny (length ys)
         nx-1 (- nx 1) ny-1 (- ny 1)
         mx (mean xs) my (mean ys)
         s2x (s2 xs) s2y (s2 ys)
         s2x/nx (div s2x nx) s2y/ny (div s2y ny)
         df (div (sq (add s2x/nx s2y/ny))
                 (add (div (sq s2x/nx) nx-1)
                      (div (sq s2y/ny) ny-1)))
         t  (div (sub mx my)
                 (sqrt (add s2x/nx s2y/ny))))
    (list mx my (ssd xs) (ssd ys)
          t df (mul 2 (prob-t (abs t) df)))))

Helpers.


Code Select
;; Arithmetic mean
(define (mean xs) (div (apply add xs) (length xs)))

;; Square function
(define (sq x) (mul x x))

;; Sum of squares
(define (sumsq xs) (apply add (map sq xs)))

;; The sample variance, just the numerator.
(define (s2-num xs)
  (let (n (length xs))
    (sub (sumsq xs) (div (sq (apply add xs)) n))))

;; Sample variance
(define (s2 xs) (div (s2-num xs) (- (length xs) 1)))

;; Sample standard deviation
(define (ssd xs) (sqrt (s2 xs)))

In action.


Code Select
> (t-test '(10 4 7 1 1 6 1 8 2 4) '(4 6 9 4 6 8 9 3 9 7))
(4.4 6.5 3.238655414 2.273030283 -1.678359739 18 0.1105533782)
> (welch-t-test '(10 4 7 1 1 6 1 8 2 4) '(4 6 9 4 6 8 9 3 9 7))
(4.4 6.5 3.238655414 2.273030283 -1.678359739 16.13523413 0.1126979729)

> ;; Now, try unequal sample sizes (which will yield different t values).
> (t-test '(10 4 7 1 1 6 1 8 2 4) '(4 6 9 4 6 8 9 3))
(4.4 6.125 3.238655414 2.356601669 -1.260037546 16 0.2257247063)
> (welch-t-test '(10 4 7 1 1 6 1 8 2 4) '(4 6 9 4 6 8 9 3))
(4.4 6.125 3.238655414 2.356601669 -1.30656126 15.90049882 0.2110406063)

Thanks and happy hacking!
#6
Whither newLISP? / The semantics of newLISP's if
August 16, 2013, 12:23:48 PM
The if expression in newLISP can usually be found to have different semantics than ifs in other lisps.  Lutz has chosen for it to have semantics which are in the spirit of cond.



I believe that this is a great choice, because newLISP's if is a general type of if.  What do I mean by this?  In http://www.newlisp.org/downloads/newlisp_manual.html#if">the manual discussion, we are presented with the two different forms of if; but in fact, the second form (the one that takes an arbitrary number of clauses) is just a generalization of the first form.[1]



http://www.newlispfanclub.alh.net/forum/viewtopic.php?t=4381&p=21628#p21628">Lutz may not like for me to say this, but there is a beauty and a consistency[2] in its simple semantics.  (Programming language geeks like me love it, but I think other users would too. This is something that I think can bring us all together. :)



I believe that Lutz made a great decision in choosing the semantics of newLISP's if expression, and in the following, I am going to detail why this is so.



The arguments to if are a list of clauses, which in the non-degenerate cases, are pairs of test and consequent clauses.  The situation looks like this:



( if test-clause-1 consequent-clause-1 . . . test-clause-N consequent-clause-N )



These pairs are continually looped though until the first such test clause evaluates to http://docs.nodejitsu.com/articles/javascript-conventions/what-are-truthy-and-falsy-values">a "truthy" value, in which case its corresponding consequent clause is evaluated and yielded as the value of the if expression itself.



The degenerate cases are when the if expression has one clause (argument) or none.  But these cases can be thought of as base cases of a recursive evaluator for if.  In fact, you can write such an evaluator in newLISP.  Here is one.


Code Select
(define (eval-if EXPR)
  (if (empty? EXPR)        nil
      (= 'if (EXPR 0))     (eval-if (1 EXPR))
      (= 1 (length EXPR))  (eval (EXPR 0))      
      (let (test-clause (EXPR 0)
            consequent-clause (EXPR 1)
            rest-of-the-clauses (2 EXPR))
        (if (eval test-clause)
            (eval consequent-clause)
            (eval-if rest-of-the-clauses)))))
There is something important lurking here, and it is that this function describes the semantics of newLISP's if in newLISP itself!!!  Yeah, that's cool.



Now, it is clear why the degenerate cases yield the values they do for newLISP's if.  Here are some examples of these cases.


Code Select
(if)          ;=> nil
(if 42)       ;=> 42
(if (+ 2 40)) ;=> 42

Our evaluator treats them the same.


Code Select
(eval-if '(if))          ;=> nil
(eval-if '(if 42))       ;=> 42
(eval-if '(if (+ 2 40))) ;=> 42

Next, examples from the first form of if in the manual look like this.


Code Select
(set 'x 50)
(if (< x 100) "small" "big") ;=> "small"
(set 'x 1000)
(if (< x 100) "small" "big") ;=> "big"
(if (> x 2000) "big")        ;=> nil

Our evaluator in action now.


Code Select
(set 'x 50)
(eval-if '(if (< x 100) "small" "big")) ;=> "small"
(set 'x 1000)
(eval-if '(if (< x 100) "small" "big")) ;=> "big"
(eval-if '(if (> x 2000) "big"))        ;=> nil

Finally, the examples from the second form of if in the manual.


Code Select
(define (classify x)
  (if (< x 0) "negative"
      (< x 10) "small"
      (< x 20) "medium"
      (>= x 30) "big"
      "n/a"))

(classify 15)   ;=> "medium"
(classify 100)  ;=> "big"
(classify 22)   ;=> "n/a"
(classify -10)  ;=> "negative"

Our evaluator.


Code Select
(define (classify-eval-if x)
  (eval-if '(if (< x 0) "negative"
                (< x 10) "small"
                (< x 20) "medium"
                (>= x 30) "big"
                "n/a")))

(classify-eval-if 15)   ;=> "medium"
(classify-eval-if 100)  ;=> "big"
(classify-eval-if 22)   ;=> "n/a"
(classify-eval-if -10)  ;=> "negative"


__________

[1] No doubt though that the manual presents two forms of if to the user because the first form is well-known; so it will communicate its ideas (about it and the second form) best to the broadest section of readers.



[2] There you go, Lutz; I used both terms. :)
#7
newLISP and the O.S. / qa-ffi: On finding libc on Linux
August 14, 2013, 09:58:01 AM
In a recent newlisp build on Linux by user hartrock (Stephan), the test qa-ffi failed because it couldn't find where libc was located on hartrock's Linux system.  hartrock was building on a 64 bit system and qa-ffi was looking for the 32 bit libc (which naturally didn't exist on his system).  The discussion was fleshed out a little here: http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=16&t=4377">http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=16&t=4377.



The upshot is that the current expression which establishes the libc pointer is now the following.


Code Select
(define LIBC (case ostype
               ("Win32" "msvcrt.dll")
               ("OSX" "libc.dylib")
               ("Linux" (if is64bit
                            "/lib/x86_64-linux-gnu/libc.so.6"
                            "/lib/i386-linux-gnu/libc.so.6"))
             ))
But hartrock suggested that the definition might be changed to be more robust ("Works for me (Debian 64-bit), but should be checked for other Linuxes, too").  He's right, of course.



So, here are two methods I found which seem more robust than the current method.  I wonder if you Linux gearheads here would scrutinize these.



One method is to ask gcc where libc is located.  This method is discussed here: http://stackoverflow.com/questions/9705660/check-glibc-version-for-a-particular-gcc-compiler#9706172">http://stackoverflow.com/questions/9705 ... er#9706172">http://stackoverflow.com/questions/9705660/check-glibc-version-for-a-particular-gcc-compiler#9706172.  Here it is implemented.


Code Select
(define LIBC
  (case ostype
    ("Win32" "msvcrt.dll")
    ("OSX" "libc.dylib")
    ("Linux"
     (letn (libc-name (first (exec "gcc -print-file-name=libc.so"))
            libc-filetype (first (exec (string "file -b " libc-name))))
       (if (find "ASCII" libc-filetype)
           (first (regex "[^ t]+/libc\.so\.*[0-9]*" (read-file libc-name)))
           libc-name)))
    ))

Another method is to call ldd on the newlisp executable.  This resource talks about this: http://mylinuxbook.com/how-to-determine-gnu-c-library-glibc-version-on-linux-system/">http://mylinuxbook.com/how-to-determine ... ux-system/">http://mylinuxbook.com/how-to-determine-gnu-c-library-glibc-version-on-linux-system/. Here is that one implemented.  It assumes that the user has built the newlisp executable in the build directory.


Code Select
(define LIBC
  (case ostype
    ("Win32" "msvcrt.dll")
    ("OSX" "libc.dylib")
    ("Linux"
     (nth 2
      (parse
       (first
        (filter (curry find "libc.so")
                (if (ends-with (real-path) "qa-specific-tests")
                    (exec "ldd ../newlisp")
                    (exec "ldd ./newlisp")))))))
    ))

I've only tested these on an Ubuntu 12.04 system.  I favor the first method.  Thoughts?  Thanks!
#8
newLISP in the real world / Update on newlisp-mode for Emacs
May 30, 2013, 12:54:07 PM
Hey everyone,



I did a not-so-thorough, but not-so-cursory, internet search on the "state of newlisp-mode (for Emacs)".  Here's the little I unearthed, but there may be more; so please add to these findings (or correct them if they are wrong somehow).  What I seem to have found is that there are two basic type of variants of newlisp-mode:



(1) Forks of the Tim Johnson version (which is based on scheme-mode) and



(2) Another version with a different code-base than TJ's, and is most likely a complete write from scratch, by Kobayashi Shigeru (codename kosh04 on github).



Anyway, here are my search notes.  These may be useful to to decide which to use or which to fork (for more goodies :).



** newlisp-mode (Emacs)

:LOGBOOK:

- Note taken on [2013-05-30 Thu 13:01] \

  Versions of newlisp-mode I could find on the net today.



  - https://github.com/may/newlisp-mode">https://github.com/may/newlisp-mode

    - By: Nicholas May

    - Has a nice README on how to install and run.

    - Mar 08, 2010 first commit (stolen from Jeff Ober's version, who stole it from Tim Johnson).

    - May 05, 2010 latest edit of newlisp.el.

    - Mar 10, 2012 latest edit of project (of README).



  - https://github.com/kosh04/newlisp-files">https://github.com/kosh04/newlisp-files

    - By: kosh04

    - This is not a Tim Johnson fork, but an original mode.

    - kosh04 also includes a swank wrapper (see swank-newlisp.lsp).

    - Feb 25, 2013 latest commit (of newlisp.el).



  - http://www.newlisp.org/code/newlisp.el">http://www.newlisp.org/code/newlisp.el

    - Claims to be stolen from http://paste.lisp.org/display/72178">http://paste.lisp.org/display/72178, which exists no longer.

    - This version seems to be either a stripped-down or proto version of kosh04's.

    - It looks like there is a copy of this version on github here: https://github.com/semperos/emacs-config/blob/master/site-lisp/newlisp.el">https://github.com/semperos/emacs-confi ... newlisp.el">https://github.com/semperos/emacs-config/blob/master/site-lisp/newlisp.el.

:END:



Same notes but with indenting preserved. (Curse you, phpBB, with your jacked up markup, wanting to  make me manually enter all that crap!  You will not, I say!) :)


Code Select
** newlisp-mode (Emacs)
:LOGBOOK:
- Note taken on [2013-05-30 Thu 13:01] \
  Versions of newlisp-mode I could find on the net today.
  - https://github.com/may/newlisp-mode
    - By: Nicholas May
    - Has a nice README on how to install and run.
    - Mar 08, 2010 first commit (stolen from Jeff Ober's version, who
      stole it from Tim Johnson).
    - May 05, 2010 latest edit of newlisp.el.
    - Mar 10, 2012 latest edit of project (of README).
  - https://github.com/kosh04/newlisp-files
    - By: kosh04
    - This is not a Tim Johnson fork, but an original mode.
    - kosh04 also includes a swank wrapper (see swank-newlisp.lsp).
    - Feb 25, 2013 latest commit (of newlisp.el).
  - http://www.newlisp.org/code/newlisp.el
    - Claims to be stolen from http://paste.lisp.org/display/72178,
      which exists no longer.
    - This version seems to be either a stripped-down or proto version
      of kosh04's.
    - It looks like there is a copy of this version on github here:
      https://github.com/semperos/emacs-config/blob/master/site-lisp/newlisp.el.
:END:
#9
Anything else we might add? / Keywords for newLISP in the Clojure style
May 21, 2013, 10:15:04 AM
Lutz, I was wondering if anyone has asked you about adding a keyword data type to newLISP -- keywords in the style of Clojure, that is.  For instance, consider the following. (Sorry that this is an older version of Clojure; however, keywords work the same even in the current version.)


Code Select
$ clj
Clojure 1.2.0-master-SNAPSHOT
user=> ;;
user=> ;; Keywords in Clojure are symbols that start with a colon.
user=> ;; They are self-evaluating.
user=> ;;
user=> :x
:x
user=> (= :x :x)
true
user=> (= ':x :x)
true
Like the comment in the REPL session says, keywords are special symbols that evaluate to themselves.



Here are some useful properties of keywords for newLISP use.



1.  When you need to use a symbol per se, i.e. you need to use a symbol as a handy tag or token and you are not going to reference it for a value, these keywords are very handy.  And since they will never reference another value, you avoid some potential variable capture issues.



2.  These kind of keywords don't clutter the context symbol table.  They are simply data encountered by eval, which in turn just makes them self-evaluating, like literal numbers, e.g. 42.  An ancillary advantage then is that you don't have to quote them.



3.  Also, the reader of your code using keywords will recognize that you are using a special class of symbols only as data (literals).  The meaning of what you are trying to do with this class of symbols then is much more apparent to the reader, who might be you going back to read your code after 6 months or more. :)



4.  These kind of keywords wouldn't belong to a context (see #2 above) and in fact are great at passing around symbols (per se) around from context to context.  For instance, have you ever written module code (in a context that's not MAIN) and passed a list constructed by your module back into the MAIN context?  In this case, currently newLISP will contextify the symbols, e.g. 'mytag becomes 'mymodule:mytag, when you only wanted to pass back 'mytag.



5. You can use these keywords for a keyword parameter/argument to a function.  (Of course, it would just aid you in rolling your own such interface.)



6. You should be able to use such keywords as keys to hash tables (like current newLISP symbols).



There may be more goodness I've overlooked.  Lutz, what do you think of this idea as an addition to newLISP?  Thoughts, anyone else?  Thanks!
#10
So, what can you actually DO with newLISP? / For Fun: Clojure-style Tail Recursion in newLISP
April 02, 2013, 03:03:22 PM
Today, I just read an http://www.mikeivanov.com/2010/08/tail-recursion-without-tco.html">old blog post by Mike Ivanov where he explains how he implemented Clojure-style (loop/recur) tail recursion in Emacs Lisp.  My first thought was, "Hey, that's cool!"  My second thought was, "Hey, I think we can do this in newLISP too!" :)



So, just for fun, here is my newLISP port of Mike's implementation. [EDIT: I updated the code in the following block after my original posting to fix a bug.  The details of the bug (error) are described in a TL;DR reply of mine further down in this discussion.]


Code Select
(constant '[loop/recur-marker] '[loop/recur-marker])

(define (loop- BODY-FN)
  (let (.args (args) .res nil)
    (while (begin
             (setq .res (apply BODY-FN .args))
             (when (and (list? .res) (not (empty? .res))
                        (= [loop/recur-marker] (first .res)))
               (setq .args (rest .res)))))
    .res))

(define (recur) (cons [loop/recur-marker] (args)))

(define (flat-shallow-pairs LIST)
  (let (i 0 acc '())
    (dolist (e LIST)
      (cond ((even? i) ; Indicator i is even = abscissa
             (cond ((and (list? e) (not (empty? e)))
                    (extend acc (0 2 (push nil e -1))))
                   ((symbol? e)
                    (push e acc -1)
                    (inc i))))
            ((odd? i) ; Indicator i is odd = ordinate
             (push e acc -1)
             (inc i))))
    acc))

(define (parms<-bindings BINDINGS)
  (map first (explode (flat-shallow-pairs BINDINGS) 2)))

(define-macro (loop INIT)
  (letn (.parms (parms<-bindings INIT)
         .body-fn (letex ([body] (args)
                          [parms] .parms)
                    (append '(fn [parms]) '[body]))
         .loop-call (letex ([body-fn] .body-fn
                            [parms] .parms)
                      (append '(loop- [body-fn]) '[parms])))
    (letex ([init] INIT [loop-call] .loop-call)
      (letn [init] [loop-call]))))

You can't use Mike's (Emacs Lisp) applications examples verbatim, but here they are in newLISP.


Code Select
(define (factorial x)
  (loop (x x acc 1)
    (if (< x 1)
        acc
        (recur (- x 1) (* x acc)))))

(define (fibo x)
  (loop (x x curr 0 next 1)
    (if (= x 0)
        curr
        (recur (- x 1) next (+ curr next)))))
They work like a charm!


Code Select
> (factorial 10)
3628800
> (fibo 10)
55
Please let me know if you spot an error or if it can be accomplished better in any way.  Thanks and happy hacking! :)
#11
newLISP newS / sqlite3 module: how to maintain lib paths
January 17, 2013, 11:17:27 AM
Hello everyone,



I recently had to test an application of the sqlite3 module and when I first ran the application, it complained about not being able to find the library.



Here is the code from the module that contains various possible locations of where the library could be, and uses that to check one-by-one if they exist on the system.


Code Select
; set library to path-name of the library on your platform OS
;
(set 'files (list
        "/usr/lib/libsqlite3.so" ; SuSE Linux
        "/usr/local/lib/libsqlite3.so" ; Linux, BSD, Solaris
        "/usr/pkg/lib/libsqlite3.so" ; NetBSD
        "/usr/local/lib/libsqlite3.so.13.3" ; OpenBSD 4.6
        "/usr/lib/libsqlite3.0.dylib" ; Mac OSX Darwin
        "/usr/lib64/libsqlite3.so" ; for 64Bit CentOS 6 Linux
        (string (env "PROGRAMFILES") "/sqlite3/sqlite3.dll") ; Win32/MinGW
))


(set 'library (files (or
                       (find true (map file? files))
                       (throw-error "cannot find sqlite3 library"))))
I was running on an Ubuntu 12.04 box and this yielded yet another location (everybody *HAS* to do things differently, eh? :)).  Here's the location I had to add, in diff form.


Code Select
$ git diff HEAD^ HEAD
diff --git a/modules/sqlite3.lsp b/modules/sqlite3.lsp
index 66b8b2c..c53a798 100644
--- a/modules/sqlite3.lsp
+++ b/modules/sqlite3.lsp
@@ -87,6 +87,7 @@
        "/usr/local/lib/libsqlite3.so.13.3" ; OpenBSD 4.6
        "/usr/lib/libsqlite3.0.dylib" ; Mac OSX Darwin
        "/usr/lib64/libsqlite3.so" ; for 64Bit CentOS 6 Linux
+        "/usr/lib/x86_64-linux-gnu/libsqlite3.so" ; for Ubuntu 12.04
        (string (env "PROGRAMFILES") "/sqlite3/sqlite3.dll") ; Win32/MinGW
 ))
I don't know who maintains the module, but maybe they'd like to know; however, for anybody sake, here's the kludge to get you by on Ubuntu 12.04.  Who knows how many more places that the distros (or rather package maintainers can put their libraries).  The decision is not mine to make what the module should be doing here; so, I'll stop here. As the father said in the movie My Big Fat Greek Wedding, "Therrrre you go!"  :)
#12
newLISP in the real world / newLISP Wiki: How to get the user's login name
December 11, 2012, 12:59:08 PM
Hello everyone,



I'm trying to run newlisp wiki 4.6, behind our firewall here at work.  I want for the wiki to know who is hitting it without the users having to login (to the wiki; they're already logged into the network).  I thought I might see this in the context of a web request, so I dumped the environment (using Lutz's environment.cgi), but the only item related to login name is USERNAME.  Unfortunately, that is the login name of the user who fired up the wiki server (namely, me), not the client's login name.  I can't find anything in the environment to help.



The clients are running on Windows 7 WSes on our intranet.  Has anybody fooled with this before?



Thanks for any help!  --Ricky
#13
newLISP and the O.S. / MinGW64 build issue
December 04, 2012, 03:17:42 PM
Lutz,



The MinGW (32-bit) compile of newLISP is clean as a whistle.


Code Select
~/builds-mingw/newlisp-10.4.5 $ make
make
./configure

removing old objects and setting correct permissions ...
discovering platform and default memory model ...

detected memory model ILP32
detected Operating System WIN_32
creating makefile_build ...

to make for ILP32 on WIN_32 type:
    make
to make for any other system do:
    make -f makefile_xxx
where makefile_xxx is one of the preconfigured makefiles

make -f makefile_build
make[1]: Entering directory `/c/Users/rick.hanson/builds-mingw/newlisp-10.4.5'
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI newlisp.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-symbol.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-math.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-list.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-liststr.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-string.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-filesys.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-sock.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-import.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-xml.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-web.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-matrix.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI nl-debug.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI pcre.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI win32-util.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -c -O1 -g -DWIN_32 -DFFI win32-path.c
/MinGW/bin/gcc  newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o pcre.o win32-util.o win32-path.o -lws2_32 -lffi -o newlisp.exe
/MinGW/bin/strip newlisp.exe
make[1]: Leaving directory `/c/Users/rick.hanson/builds-mingw/newlisp-10.4.5'
~/builds-mingw/newlisp-10.4.5 $

But when I use any of the MinGW 64-bit toolchains, the compiler complains about initializers not being constant in nl-import.  (The other *.c files compile just fine, albeit with more warnings.)



BTW, /MinGW now points to a 64-bit MinGW toolchain, and I added some -Wno-* flags to suppress some warning noise.


Code Select
~/builds-mingw64/newlisp-10.4.5 $ ./configure
./configure

removing old objects and setting correct permissions ...
discovering platform and default memory model ...

detected memory model LLP64
detected Operating System WIN_32
creating makefile_build ...

to make for LLP64 on WIN_32 type:
    make
to make for any other system do:
    make -f makefile_xxx
where makefile_xxx is one of the preconfigured makefiles

~/builds-mingw64/newlisp-10.4.5 $ make -f makefile_build
make -f makefile_build
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 newlisp.c
newlisp.c:158:1: warning: overflow in implicit constant conversion [-Woverflow]
newlisp.c: In function 'getInteger':
newlisp.c:3683:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
newlisp.c:3684:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
newlisp.c: In function 'getInteger64':
newlisp.c:3736:5: warning: overflow in implicit constant conversion [-Woverflow]
newlisp.c:3737:5: warning: overflow in implicit constant conversion [-Woverflow]
newlisp.c: In function 'getIntegerExt':
newlisp.c:3784:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
newlisp.c:3785:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-symbol.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-math.c
nl-math.c:64:5: warning: '_matherr' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-list.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-liststr.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-string.c
nl-string.c: In function 'p_symbol':
nl-string.c:1196:8: warning: unused variable 'fmt' [-Wunused-variable]
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-filesys.c
nl-filesys.c: In function 'p_makeDir':
nl-filesys.c:813:1: warning: implicit declaration of function '_mkdir' [-Wimplicit-function-declaration]
nl-filesys.c: In function 'p_removeDir':
nl-filesys.c:825:1: warning: implicit declaration of function '_rmdir' [-Wimplicit-function-declaration]
nl-filesys.c: In function 'getUUID':
nl-filesys.c:3049:5: warning: right shift count >= width of type [enabled by default]
nl-filesys.c:3050:5: warning: right shift count >= width of type [enabled by default]
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-sock.c
/MinGW/bin/gcc -Wall -pedantic -Wno-long-long -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -m64 -c -O1 -g -DWIN_32 -DNEWLISP64 nl-import.c
nl-import.c:451:5: error: initializer element is not constant
nl-import.c:451:5: error: (near initialization for 'callback[0].func')
nl-import.c:452:5: error: initializer element is not constant
nl-import.c:452:5: error: (near initialization for 'callback[1].func')
nl-import.c:453:5: error: initializer element is not constant
nl-import.c:453:5: error: (near initialization for 'callback[2].func')
nl-import.c:454:5: error: initializer element is not constant
nl-import.c:454:5: error: (near initialization for 'callback[3].func')
nl-import.c:455:5: error: initializer element is not constant
nl-import.c:455:5: error: (near initialization for 'callback[4].func')
nl-import.c:456:5: error: initializer element is not constant
nl-import.c:456:5: error: (near initialization for 'callback[5].func')
nl-import.c:457:5: error: initializer element is not constant
nl-import.c:457:5: error: (near initialization for 'callback[6].func')
nl-import.c:458:5: error: initializer element is not constant
nl-import.c:458:5: error: (near initialization for 'callback[7].func')
nl-import.c:459:5: error: initializer element is not constant
nl-import.c:459:5: error: (near initialization for 'callback[8].func')
nl-import.c:460:5: error: initializer element is not constant
nl-import.c:460:5: error: (near initialization for 'callback[9].func')
nl-import.c:461:5: error: initializer element is not constant
nl-import.c:461:5: error: (near initialization for 'callback[10].func')
nl-import.c:462:5: error: initializer element is not constant
nl-import.c:462:5: error: (near initialization for 'callback[11].func')
nl-import.c:463:5: error: initializer element is not constant
nl-import.c:463:5: error: (near initialization for 'callback[12].func')
nl-import.c:464:5: error: initializer element is not constant
nl-import.c:464:5: error: (near initialization for 'callback[13].func')
nl-import.c:465:5: error: initializer element is not constant
nl-import.c:465:5: error: (near initialization for 'callback[14].func')
nl-import.c:466:5: error: initializer element is not constant
nl-import.c:466:5: error: (near initialization for 'callback[15].func')
make: *** [nl-import.o] Error 1
~/builds-mingw64/newlisp-10.4.5 $
Curious as to why the 32-bit gcc did not complain about this too.  http://stackoverflow.com/questions/3025050/error-initializer-element-is-not-constant-when-trying-to-initialize-variable-w">Some dudes on SOF claim that the C standard says that you can't do this.  (Even though, I think it's cool that you can.)  BTW, 64-bit gcc on Linux has no problem with this.  So, I wonder if there is a GNU extension that enables the 32-bit MinGW to accept this, but which is turned off by default in the 64-bit MinGW toolchain.



Have you tried using the 64-bit target compilers of MinGW to compile newLISP before?  Curious.



Thanks for any feedback.
#14
newLISP and the O.S. / Cygwin build issue: template function in nl-import
November 29, 2012, 12:27:29 PM
I'm building 10.4.5 from sources on Cygwin and get this message on the compile of nl-import.


Code Select
gcc -m32 -Wall -pedantic -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE -DCYGWIN nl-import.c
nl-import.c: In function ‘p_importLib’:
nl-import.c:196:1: warning: ISO C forbids nested functions
nl-import.c:196:1: warning: ISO C90 forbids mixed declarations and code
nl-import.c:247:1: warning: ISO C forbids nested functions
nl-import.c:321:1: warning: ISO C forbids nested functions
nl-import.c:393:1: warning: ISO C forbids nested functions
nl-import.c:412:1: warning: ISO C forbids nested functions
nl-import.c:414:1: warning: ISO C forbids nested functions
nl-import.c:416:1: warning: ISO C forbids nested functions
nl-import.c:418:1: warning: ISO C forbids nested functions
nl-import.c:420:1: warning: ISO C forbids nested functions
nl-import.c:422:1: warning: ISO C forbids nested functions
nl-import.c:424:1: warning: ISO C forbids nested functions
nl-import.c:426:1: warning: ISO C forbids nested functions
nl-import.c:428:1: warning: ISO C forbids nested functions
nl-import.c:430:1: warning: ISO C forbids nested functions
nl-import.c:432:1: warning: ISO C forbids nested functions
nl-import.c:434:1: warning: ISO C forbids nested functions
nl-import.c:436:1: warning: ISO C forbids nested functions
nl-import.c:438:1: warning: ISO C forbids nested functions
nl-import.c:440:1: warning: ISO C forbids nested functions
nl-import.c:442:1: warning: ISO C forbids nested functions
nl-import.c:451:5: warning: initializer element is not computable at load time
nl-import.c:451:5: warning: initializer element is not computable at load time
nl-import.c:452:5: warning: initializer element is not computable at load time
nl-import.c:452:5: warning: initializer element is not computable at load time
nl-import.c:453:5: warning: initializer element is not computable at load time
nl-import.c:453:5: warning: initializer element is not computable at load time
nl-import.c:454:5: warning: initializer element is not computable at load time
nl-import.c:454:5: warning: initializer element is not computable at load time
nl-import.c:455:5: warning: initializer element is not computable at load time
nl-import.c:455:5: warning: initializer element is not computable at load time
nl-import.c:456:5: warning: initializer element is not computable at load time
nl-import.c:456:5: warning: initializer element is not computable at load time
nl-import.c:457:5: warning: initializer element is not computable at load time
nl-import.c:457:5: warning: initializer element is not computable at load time
nl-import.c:458:5: warning: initializer element is not computable at load time
nl-import.c:458:5: warning: initializer element is not computable at load time
nl-import.c:459:5: warning: initializer element is not computable at load time
nl-import.c:459:5: warning: initializer element is not computable at load time
nl-import.c:460:5: warning: initializer element is not computable at load time
nl-import.c:460:5: warning: initializer element is not computable at load time
nl-import.c:461:5: warning: initializer element is not computable at load time
nl-import.c:461:5: warning: initializer element is not computable at load time
nl-import.c:462:5: warning: initializer element is not computable at load time
nl-import.c:462:5: warning: initializer element is not computable at load time
nl-import.c:463:5: warning: initializer element is not computable at load time
nl-import.c:463:5: warning: initializer element is not computable at load time
nl-import.c:464:5: warning: initializer element is not computable at load time
nl-import.c:464:5: warning: initializer element is not computable at load time
nl-import.c:465:5: warning: initializer element is not computable at load time
nl-import.c:465:5: warning: initializer element is not computable at load time
nl-import.c:466:5: warning: initializer element is not computable at load time
nl-import.c:466:5: warning: initializer element is not computable at load time
nl-import.c:470:1: warning: ISO C forbids nested functions
nl-import.c:470:6: error: static declaration of ‘template’ follows non-static declaration
nl-import.c:410:6: note: previous declaration of ‘template’ was here
nl-import.c:507:1: warning: ISO C forbids nested functions
nl-import.c:620:1: error: expected declaration or statement at end of input
nl-import.c:620:1: warning: control reaches end of non-void function
makefile_build:22: recipe for target `nl-import.o' failed
make[1]: *** [nl-import.o] Error 1
make[1]: Leaving directory `/cygdrive/c/Users/rick.hanson/builds/newlisp-10.4.5'
Makefile:31: recipe for target `default' failed
make: *** [default] Error 2

There's nothing wrong with code that I can see.  template shows up in a prototype first and then its definition follows, after the callback function definitions.  The warnings might indicate that there is a problem with coding matching braces, in the code before template, that could trip the error, but the braces all match.



It compiles fine on my Linux box, and both are running gcc.



Weird.
#15
newLISP and the O.S. / Cygwin build issue: icmp
November 29, 2012, 11:09:27 AM
Lutz and any adventurous people,



I pulled down the 10.4.5 sources and ran make under Windoze cygwin.  Got the following message when it came to the nl-sock compile.


Code Select
gcc -m32 -Wall -pedantic -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE -DCYGWIN nl-sock.c
nl-sock.c:65:8: error: redefinition of ‘struct icmp’
/usr/include/netinet/icmp6.h:143:8: note: originally defined here
nl-sock.c:70:19: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ token
nl-sock.c: In function ‘p_netConnect’:
nl-sock.c:433:9: warning: array subscript has type ‘char’
nl-sock.c: In function ‘p_netListen’:
nl-sock.c:1224:9: warning: array subscript has type ‘char’
nl-sock.c: In function ‘ping’:
nl-sock.c:1965:21: error: storage size of ‘filter’ isn’t known
nl-sock.c:2006:5: warning: implicit declaration of function ‘ICMP6_FILTER_SETPASSALL’
nl-sock.c:2007:36: error: ‘ICMP6_FILTER’ undeclared (first use in this function)
nl-sock.c:2007:36: note: each undeclared identifier is reported only once for each function it appears in
nl-sock.c:2090:17: error: dereferencing pointer to incomplete type
nl-sock.c:2090:32: error: ‘ICMP6_ECHO_REQUEST’ undeclared (first use in this function)
nl-sock.c:2091:17: error: dereferencing pointer to incomplete type
nl-sock.c:2092:49: error: dereferencing pointer to incomplete type
nl-sock.c:2098:16: error: ‘struct icmp’ has no member named ‘icmp_hun’
nl-sock.c:2155:16: error: dereferencing pointer to incomplete type
nl-sock.c:2155:32: error: ‘ICMP6_ECHO_REPLY’ undeclared (first use in this function)
nl-sock.c:2156:16: error: dereferencing pointer to incomplete type
nl-sock.c:2157:59: error: dereferencing pointer to incomplete type
nl-sock.c:2162:15: error: ‘struct icmp’ has no member named ‘icmp_hun’
nl-sock.c:1965:21: warning: unused variable ‘filter’
makefile_cygwin:22: recipe for target `nl-sock.o' failed
make: *** [nl-sock.o] Error 1

nl-sock.c, lines 60 to 73 read:


Code Select
#ifdef CYGWIN
#include <netinet/icmp6.h> /* not on Cygwin, get from other OS */

#define ICMP_ECHO 8

struct icmp
{
   unsigned char icmp_type;
   unsigned char icmp_code;
   unsigned short icmp_cksum;
   unsigned short icmp_id;
   unsigned short icmp_seq;
};
#endif

I noticed the comment on line 61.  I can't remember but I may have grabbed a icmp6.h in the far past from somewhere else -- I don't remember.  Lutz, are you expecting that the icmp6.h that we have has no definition for icmp?  Mine does; so I may have the "wrong" one.  Here's icmp from my icmp6.h.


Code Select
struct icmp
{
 u_int8_t icmp_type; /* type of message, see below */
 u_int8_t icmp_code; /* type sub code */
 u_int16_t icmp_cksum; /* ones complement checksum of struct */
 union
 {
 u_char ih_pptr; /* ICMP_PARAMPROB */
 struct in_addr ih_gwaddr; /* gateway address */
 struct ih_idseq /* echo datagram */
 {
 u_int16_t icd_id;
 u_int16_t icd_seq;
 } ih_idseq;
 u_int32_t ih_void;

 /* ICMP_UNREACH_NEEDFRAG -- Path MTU Discovery (RFC1191) */
 struct ih_pmtu
 {
 u_int16_t ipm_void;
 u_int16_t ipm_nextmtu;
 } ih_pmtu;

 struct ih_rtradv
 {
 u_int8_t irt_num_addrs;
 u_int8_t irt_wpa;
 u_int16_t irt_lifetime;
 } ih_rtradv;
 } icmp_hun;
#define icmp_pptr icmp_hun.ih_pptr
#define icmp_gwaddr icmp_hun.ih_gwaddr
#define icmp_id icmp_hun.ih_idseq.icd_id
#define icmp_seq icmp_hun.ih_idseq.icd_seq
#define icmp_void icmp_hun.ih_void
#define icmp_pmvoid icmp_hun.ih_pmtu.ipm_void
#define icmp_nextmtu icmp_hun.ih_pmtu.ipm_nextmtu
#define icmp_num_addrs icmp_hun.ih_rtradv.irt_num_addrs
#define icmp_wpa icmp_hun.ih_rtradv.irt_wpa
#define icmp_lifetime icmp_hun.ih_rtradv.irt_lifetime
 union
 {
 struct
 {
 u_int32_t its_otime;
 u_int32_t its_rtime;
 u_int32_t its_ttime;
 } id_ts;
 struct
 {
 struct ip idi_ip;
 /* options and then 64 bits of data */
 } id_ip;
 struct icmp_ra_addr id_radv;
 u_int32_t id_mask;
 u_int8_t id_data[1];
 } icmp_dun;
#define icmp_otime icmp_dun.id_ts.its_otime
#define icmp_rtime icmp_dun.id_ts.its_rtime
#define icmp_ttime icmp_dun.id_ts.its_ttime
#define icmp_ip icmp_dun.id_ip.idi_ip
#define icmp_radv icmp_dun.id_radv
#define icmp_mask icmp_dun.id_mask
#define icmp_data icmp_dun.id_data
};
Yeah, it's ugly, and very different from the one in nl-sock.c.  What do you think I should do?  When you wrote the comment "not on Cygwin, get from other OS" in nl-sock.c, what exactly did you mean?  Or, can you send us your icmp6.h that you use for cygwin builds? :)



Thanks!  --Rick
#16
newLISP in the real world / Student's t-distribution (inverse) in newLISP
March 21, 2012, 12:51:20 PM
Hello everyone,



I'm in need of a handy function to help me compute confidence intervals based on the Student's t-distribution.  It is easy to do in Excel, for instance, since they provide a Student t inverse; they call it TINV.  See https://courses.washington.edu/dphs568/course/excel-t.htm">//https://courses.washington.edu/dphs568/course/excel-t.htm for more info.



I'd love to have something in newLISP like Excel's TINV or a way to compute such confidence intervals straightaway, because newLISP will be way better than Excel at generating the parametrized computations of the CIs that I have in mind.



Has anyone done this in newLISP already?  I hope so.  Thanks!
#17
Dragonfly / Apache + .htaccess Gotcha
September 09, 2011, 07:47:35 AM
Hello all,



This is just a little tidbit, but it got me.  (Gotcha!)  I set up Dragonfly locally on my Mac, fired up Apache -- and after that QUERY_STRING problem was resolved (see http://newlispfanclub.alh.net/forum/viewtopic.php?f=17&t=3942">Help on first time Dragonfly install) -- I could get the start page OK.  However, when I tried to access other pages, I kept getting 404s.



I put some garbage in the .htaccess file, expecting to get a 500. Nothin' doin' -- still got the 404.  Ah, the .htaccess file is not being read. Why?  Because the server's config file (httpd.conf) had an AllowOverride None for the DocumentRoot.  I then added the following to httpd.conf.


Code Select
<Directory "/document_root/of/your/dragonfly/site">
    Options +ExecCGI
    AddHandler cgi-script .cgi
    AllowOverride Options Limit FileInfo
    Order allow,deny
    Allow from all
</Directory>

Change /document_root/of/your/dragonfly/site accordingly.  It works now with this change, even though there may be some unnecessary directives there.  The main deal maker here is the AllowOverride Options Limit FileInfo line.  One could also put AllowOverride All, but it's a little overkill.



Aside: If you are in a situation where Apache is setup not to allow overrides (i.e. it will not regard your .htaccess file) and you cannot change Apache's httpd.conf (because you don't have admin access, as in a web hosting environment), you need to tell your admin to allow Apache to read your .htaccess file by adding the AllowOverride Options Limit FileInfo directive for your web docs path or virtual host.  If they won't do it, you're hosed from running such as Dragonfly there and you should find another provider (because this is a common allowance anymore).



Thanks to the Dragonfly guys for coding the .htaccess file for us.  (I love and hate mod_rewrite!)  The URLs look great.
#18
Dragonfly / Help on first time Dragonfly install
September 07, 2011, 10:23:21 PM
Hello all,



Pulled down dragonfly v070.  Followed the directions to move .htaccess, index.cgi, and dragonfly-framework to DOCUMENT_ROOT.



Fired up Apache2, pointed to http://localhost">http://localhost in the browser and got:


Code Select
ERR: list expected : (parse-query QUERY_STRING)
called from user defined function load-once
called from user defined function load-files-in-dir

Looks like the scripts can't see the value of QUERY_STRING.  It's certainly not a list.  Tried changing the hash bang line on index.cgi to point right at newlisp.  Still get the same message.  Has anyone seen this before?  Thanks for any help.  --Rick
#19
Anything else we might add? / Off topic: What web hosting do you like/recommend?
May 29, 2008, 09:05:13 PM
Hello everyone!



I am shopping for web hosting services and I'd like to get your opinions on any that you have used so far.  Personally, I'm looking for myself and a small group of customers to set up small sites (some with simple commerce capability, i.e. get charge card info securely, and to be able to grow more).  I'd like to get something that I could setup a Linux on, but I'd be OK too with a pre-installed OS by the hosting service.  But I have to have root access.



I know several people like Nearly Free Speech and at least Lutz has used Amazon EC2.  Please let me know how you like these services, or others I might have overlooked.



Thanks!  --Ricky
#20
Anything else we might add? / Bug in 'randomize' primitive
May 22, 2008, 07:23:45 PM
I just discovered today that the randomize function in newLISP is not an unbiased shuffler.



For those who don't know what randomize does: it takes a list and gives it back to you with the elements randomly rearranged.  Another way of saying it is that it gives you a random permutation of the list you provide.  Now, http://www.newlisp.org/downloads/newlisp_manual.html#randomize">in the manual, it doesn't say that the permutation you get is as equally likely as any other you would get.  So technically, randomize is working as advertised, but I think that Lutz and the user base would agree that it would be best to get an equally likely random permutation from randomize.



Here is the culprit code, from nl-math.c, lines 1104-1110, in function p_randomize():
Code Select
for(i = 0; i < (length - 1); i++)
  {
  j = random() % length;
  cell = vector[i];
  vector[i] = vector[j];
  vector[j] = cell;
  }

According to Don Knuth (The Art of Computer Programming, Volume 2: Seminumerical Algorithms), the index j should be drawn (uniformly) randomly from i to length - 1.



In newLISP, this would be:
Code Select
;; From Algorithm P of Knuth in TAOCP: Seminumerical Algorithms.
(define (randomize* lst)
  (let ((N-1 (- (length lst) 1)))
    (for (i 0 (- N-1 1))
      (swap i (unif i N-1) lst))
    lst))

;; Uniformly draw an integer in the range {a,...,b}.
(define (unif a b) (+ a (rand (+ 1 (- b a)))))
Pages1 2 3