Nth behaviour?

[pjot]

Code Select Expand


peter@AsteroidRider:~$ newlisp
newLISP v.9.2.17 on Linux, execute 'newlisp -h' for more info.

> (sys-info)
(362 268435456 358 1 0 140733193390080 9217 1)
> (nth 6 (sys-info))
140733193397249
> (nth 7 (sys-info))
140733193388033
> (nth 8 (sys-info))

list index out of bounds
> (nth 5 (sys-info))
140733193390080


Why is this happening? An (nth 6 (sys-info)) used to return the version number of newLisp (here 9217).



Peter

[Lutz]

Still works over here on Mac OS X, Free BSD 4.9 and Linux 2.6

Code Select Expand


~/newlisp-9.2.17> uname -a
Linux webserver28 2.6.16-xenU #1 SMP Mon May 28 03:41:49 SAST 2007 i686 athlon i386 GNU/Linux
~/newlisp-9.2.17> ./newlisp
newLISP v.9.2.17 on Linux, execute 'newlisp -h' for more info.

> (nth 6 (sys-info))
9217
> (sys-info 6)
9217
> ((sys-info) 6)
9217
>


what kind of Linux are your running? The above Linux is a custom Amazon Ec2 services Linux, RedHat based.



Can you do a uname -a to fined out? Do previous versions give the same error?



Lutz



ps: and what makefile did you use to compile, if this is a 64-bit Linux, then you can compile as either 32bit or 64bit Linux. That big number should be 2038 (stack depth)

[pjot]

It is the 64 bit version of Slackware Linux 12.0 called 'SLAMD' (http://www.slamd64.com">www.slamd64.com).

peter@AsteroidRider:~$ uname -a

Linux AsteroidRider 2.6.22.8 #1 SMP Tue Sep 25 20:41:25 BST 2007 x86_64 x86_64 x86_64 GNU/Linux

I have compiled newLisp as follows:

make -f makefile_linux_readline

If I run 'make', it will automatically use the 'linux_makefile' version.

peter@AsteroidRider:~/installation/newlisp-9.2.17$ make

./build



Discovered Linux:

make[1]: Map '/home/peter/installation/newlisp-9.2.17' wordt binnengegaan

make -f makefile_linux

make[2]: Map '/home/peter/installation/newlisp-9.2.17' wordt binnengegaan

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX newlisp.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-symbol.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-math.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-list.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-liststr.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-string.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-filesys.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-sock.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-import.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-xml.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-web.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-matrix.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-debug.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX pcre.c

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 -g -lm -ldl -o newlisp

strip newlisp

make[2]: Map '/home/peter/installation/newlisp-9.2.17' wordt verlaten

make[1]: Map '/home/peter/installation/newlisp-9.2.17' wordt verlaten

Peter

[Lutz]

Assuming that it has 32-bit libs installed, try using:

Code Select Expand

make -f makefile_linux64ILP32

if that doesn't work do:

Code Select Expand

make -f makefile_linux64LP64

but the first will most likely work, most 64-bit Linux are configured with two sets of libraries, and the header of the binary lets the loader automatically choose the right one.



Lutz



ps: makefile_linux64 is the same as makefile_linux64ILP32

[pjot]

The first makefile does not work at all:

peter@AsteroidRider:~/installation/newlisp-9.2.17$ make -f makefile_linux64ILP32

make: *** No rule to make target `makefile_linux64LP32', needed by `newlisp.o'.  Stop.

The second makefile works, but there is no difference:

peter@AsteroidRider:~/installation/newlisp-9.2.17$ make -f makefile_linux64LP64

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 newlisp.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-symbol.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-math.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-list.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-liststr.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-string.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-filesys.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-sock.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-import.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-xml.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-web.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-matrix.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 nl-debug.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX -DNEWLISP64 pcre.c

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  -g -lm -ldl -o newlisp

strip newlisp

peter@AsteroidRider:~/installation/newlisp-9.2.17$ ./newlisp

newLISP v.9.2.17 64-bit on Linux, execute 'newlisp -h' for more info.



> (nth 6 (sys-info))

140733193397249

> (nth 5 (sys-info))

2048

> (sys-info)

(362 576460752303423488 358 1 0 2048 9217 1)

However, I noticed that implicit indexing works well:

newLISP v.9.2.17 64-bit on Linux, execute 'newlisp -h' for more info.



> (sys-info)

(362 576460752303423488 358 1 0 140733193390080 140733193397249 1)

> ((sys-info) 6)

9217

> (sys-info)

(362 576460752303423488 358 1 0 2048 9217 1)

As you may see, the (sys-info) is generating some other value again.



Peter

[pjot]

Later I saw your remark:

makefile_linux64 is the same as makefile_linux64ILP32

The 'makefile_linux64ILP32' does not work:

peter@AsteroidRider:~/installation/newlisp-9.2.17$ make -f makefile_linux64ILP32

make: *** No rule to make target `makefile_linux64LP32', needed by `newlisp.o'.  Stop.

But the 'makefile_linux64' does work:

peter@AsteroidRider:~/installation/newlisp-9.2.17$ make -f makefile_linux64

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX newlisp.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-symbol.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-math.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-list.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-liststr.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-string.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-filesys.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-sock.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-import.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-xml.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-web.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-matrix.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX nl-debug.c

gcc -m32 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DLINUX pcre.c

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 -m32 -g -lm -ldl -o newlisp

strip newlisp

peter@AsteroidRider:~/installation/newlisp-9.2.17$ ./newlisp

newLISP v.9.2.17 on Linux, execute 'newlisp -h' for more info.



> (sys-info)

(362 268435456 358 1 0 2048 9217 1)

> (nth 6 (sys-info))

9217

> ((sys-info) 6)

9217

Now the (sys-info) and the (nth) and also implicit indexing are working correctly!



From C compilation point of view it seems to come down to the '-m32' flag which is missing in the other situations...?



Peter

[pjot]

Hm, I cannot import 64-bit libraries anymore with this last compilation:

newLISP v.9.2.17 on Linux, execute 'newlisp -h' for more info.



>  (import "libgtk-server.so" "gtk")



problem loading library in function import : "libgtk-server.so: wrong ELF class: ELFCLASS64"

This used to work with the plain 'makefile_linux', I can run all my GTK-server apps in 64bit. Obviously I do not use 'nth' that much.

peter@AsteroidRider:~/apps/comic$ file /usr/bin/newlisp

/usr/bin/newlisp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

peter@AsteroidRider:~/apps/comic$ file /usr/lib/libgtk-server.so

/usr/lib/libgtk-server.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped

Peter

[Lutz]

You have to locate the 32-bit libraries on that machine, when you run newLISP as a 32-bit app.



running 64-bit newLISP with nth does it fine on OS X:

Code Select Expand

newLISP v.9.2.17 64-bit on OSX, execute 'newlisp -h' for more info.

> (nth 6 (sys-info))
9217
>


Can you give me access to that machine? Also I wonder if this occurs only for sys-info. Can you run: ./newlisp qa-dot ? What about the whole test suite: make test ?



Lutz

[pjot]

You can have access to my machine, I'll send the details tonight by PM.



Peter

[newdep]

Big and Little where sitting on the wall... !!

[pjot]

Indeed, we think this maybe an Endian issue.



If I look to the datatypes in (sys-info), then it appears that the first elements are of type 'long' and 'size_t', each of which is 8 bytes. These are shown correctly.

Code Select Expand


cell = stuffIntegerList(
8,
cellCount,
MAX_CELL_COUNT,
symbolCount,
(UINT)recursionCount,
(UINT)envStackIdx,
MAX_CPU_STACK,
version,
opsys);


The problem starts when arriving at MAX_CPU_STACK, which is an int of 4 bytes. Also the 'version' is an int of 4 bytes.



There might be a problem aligning the bytes in memory. There are systems like the IA64 with 'switchable Endiannes', but I cannot find hard proof that this 64bit Intel machine has this feature. See also http://en.wikipedia.org/wiki/Endianness">http://en.wikipedia.org/wiki/Endianness



Peter

[Lutz]

Seems to be a sign extension issue from 4 byte int to 8 byte unsigned long,



this should fix it:

Code Select Expand

cell = stuffIntegerList(
    8,
    cellCount,
    MAX_CELL_COUNT,
    symbolCount,
    (UINT)recursionCount,
    (UINT)envStackIdx,
    (UINT)MAX_CPU_STACK,
    (UINT)version,
    (UINT)opsys);


because on 64 bit newLISP:

Code Select Expand

> (format "%x" 140733193397249)
"2401"
> 0x2401
9217


Lutz





ps: that machine seems to be turned off now, so I couldn't try myself

pps: there also may be 'import' issues

[pjot]

Hi Lutz,



This indeed seems to work:

peter@AsteroidRider:~/installation/newlisp-9.2.17$ ./newlisp

newLISP v.9.2.17 on Linux, execute 'newlisp -h' for more info.



> (sys-info)

(362 268435456 358 1 0 2048 9217 1)

> (nth 6 (sys-info))

9217

> (import "libgtk-server.so" "gtk")

gtk <2B193AD47A59>



peter@AsteroidRider:~/installation/newlisp-9.2.17$ ldd newlisp

        libm.so.6 => /lib64/libm.so.6 (0x00002abcdbbd7000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00002abcdbe5a000)

        libc.so.6 => /lib64/libc.so.6 (0x00002abcdc05e000)

        /lib64/ld-linux-x86-64.so.2 (0x00002abcdb9ba000)

Funny this 'signed-issue' does not occur in other places as well...?



The machine went to power saving and therefore was not reachable... sorry about that, it is available now for any further testing.



Thanks!



Peter