Re: pil64emu testing features
On Nov 5, 2012, at 7:43 AM, Alexander Burger wrote: Hi Jorge, cool! Thanks for researching! :) Ok, what about this? Right. However, this is src/Makefile, we should to the analog with src64/Makefile, right? Uh? The .patch was changing both files... According to the strip man page: -x Remove all local symbols (saving only global symbols). This is good news. So I added -x to the STRIP variable for Darwin. Also, I can put in back again the stripping for 'ext' and 'ht' libs, right? I did that now. Please test again if you have time. Works with the stripped ext and ht. The only remaining bit is stripping also in src/Makefile. ♪♫ - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex, I just tested the latest ongoing on my Mac, and it seems to work quite fine: f3bmac3:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function ‘run’: emu.base.c:42120: warning: format not a string literal and no format arguments emu.base.c:42175: warning: format not a string literal and no format arguments f3bmac3:picoLispEmu jkleiser$ ./pil misc/fibo.l + : (fibo 9) - 34 : *CPU - emu : (load misc/sieve.l) - sieve : (sieve 20) - (2 3 5 7 11 13 17 19) Something else: While I was looking into the 'misc' folder I found 'reverse.l' and 'setf.l' (the most perverse concept ...). Can you explain what these two do? /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, I just tested the latest ongoing on my Mac, and it seems to work quite fine: Good. Something else: While I was looking into the 'misc' folder I found 'reverse.l' and 'setf.l' (the most perverse concept ...). Can you explain what these two do? misc/reverse.l is just a simple server check. You can connect with telnet, and it echoes back each line reversed. misc/setf.l is just a joke ;-) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Mon, Nov 05, 2012 at 02:25:13PM +0100, Alexander Burger wrote: Sorry, didn't look carefully then. But why should we change pil32? It worked all right, didn't it? Sorry again ;-) It didn't strip at all in pil32. I'll change it. Thanks! - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, misc/setf.l is just a joke ;-) Unfortunately I still don't understand that joke. :-( There must be some reason why it's there ... Not really. I'm a strong opponent of the CL 'setf' function. I think it completely violates the spirit of how Lisp functions evaluate their arguments. But I don't want to start a flame war here ... It makes no sense to use this 'setf' in PicoLisp. Better use plain 'set' on 'var' arguments. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon,
so the only remaining issue with eum64 is currently the fact that
fcntl() gives a runtime error on the Mac:
MacBook-Air:picoLispEmu jkleiser$ ./pil +
[/Users/jkleiser/.pil/history:1] File lock: Invalid argument
This happens when it tries to lock the history file of the line editor
in debug mode. But it will probably also happen in other cases where
files need to be locked (e.g. in the database).
The corresponding source is line 28 of src64/io.l:
(code 'lockFileAC)
st2 (Flock) # 'l_type'
ld (Flock L_START) 0 # Start position ('l_whence' is SEEK_SET)
shr A 16 # Get length
ld (Flock L_LEN) A # Length
do
cc fcntl(C F_SETLKW Flock) # Try to lock
This boils down to (line 19477 of src64/emu.base.c):
// lockFileAC:
2644, // 18454: st2 (Flock)
2645, // 18455: ld (Flock . 4) 0
2646, // 18456: shr A 16
2647, // 18457: ld (Flock . 12) A
2650, // 18458: cc fcntl (C 14 Flock)
The '14' here is the value of F_SETLKW on x86-32 Debian. It is system
dependent, and is perhaps different on the Mac.
The last line results in the call (line 39073):
case 2650: // cc fcntl (C 14 Flock)
A.l = (uint32_t)fcntl((int)C.n, 14, (int)((uint64_t)(unsigned
long)((uint8_t*)Data+7844)));
break;
So either the value '14' is wrong here, or the whole call to fcntl().
The value of F_SETLKW is taken from the standard output of the command
'src64/sysdefs', which is compiled in the build process on the host
system.
Anybody has an idea what is wrong? Any Mac programmer awake?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Sun, Nov 04, 2012 at 09:55:27AM +0100, Alexander Burger wrote: This boils down to (line 19477 of src64/emu.base.c): // lockFileAC: 2644, // 18454: st2 (Flock) The exact line numbers are subject to change, of course. Actually, I mistakenly looked at an a bit outdated version. The above part is at line 19479 in the current release. The last line results in the call (line 39073): case 2650: // cc fcntl (C 14 Flock) A.l = (uint32_t)fcntl((int)C.n, 14, (int)((uint64_t)(unsigned long)((uint8_t*)Data+7844))); break; Same here. This is now at 39079. Just to avoid confusion ;-) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex,
Hi Jon,
so the only remaining issue with eum64 is currently the fact that
fcntl() gives a runtime error on the Mac:
MacBook-Air:picoLispEmu jkleiser$ ./pil +
[/Users/jkleiser/.pil/history:1] File lock: Invalid argument
This happens when it tries to lock the history file of the line editor
in debug mode. But it will probably also happen in other cases where
files need to be locked (e.g. in the database).
The corresponding source is line 28 of src64/io.l:
(code 'lockFileAC)
st2 (Flock) # 'l_type'
ld (Flock L_START) 0 # Start position ('l_whence' is SEEK_SET)
shr A 16 # Get length
ld (Flock L_LEN) A # Length
do
cc fcntl(C F_SETLKW Flock) # Try to lock
This boils down to (line 19477 of src64/emu.base.c):
// lockFileAC:
2644, // 18454: st2 (Flock)
2645, // 18455: ld (Flock . 4) 0
2646, // 18456: shr A 16
2647, // 18457: ld (Flock . 12) A
2650, // 18458: cc fcntl (C 14 Flock)
The '14' here is the value of F_SETLKW on x86-32 Debian. It is system
dependent, and is perhaps different on the Mac.
Yes, this is from my Mac's ...Headers/sys/fcntl.h:
#define F_SETLKW9 /* F_SETLK; wait if blocked */
Does this 9 explain our fcntl() problem?
/Jon
The last line results in the call (line 39073):
case 2650: // cc fcntl (C 14 Flock)
A.l = (uint32_t)fcntl((int)C.n, 14, (int)((uint64_t)(unsigned
long)((uint8_t*)Data+7844)));
break;
So either the value '14' is wrong here, or the whole call to fcntl().
The value of F_SETLKW is taken from the standard output of the command
'src64/sysdefs', which is compiled in the build process on the host
system.
Anybody has an idea what is wrong? Any Mac programmer awake?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, 2650, // 18458: cc fcntl (C 14 Flock) The '14' here is the value of F_SETLKW on x86-32 Debian. It is system dependent, and is perhaps different on the Mac. Yes, this is from my Mac's ...Headers/sys/fcntl.h: #define F_SETLKW9 /* F_SETLK; wait if blocked */ Does this 9 explain our fcntl() problem? If it is 9 according to the include file on the Mac, is this also the value returned by 'src64/sysdefs', and which thus appears in the above 'fcntl' line (which is (correctly) 14 for Debian)? I mean, how do these lines look on your system? Do they show 9 instead of 14? If it is so, what else might be wrong with the call to fcntl()? Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Sun, Nov 04, 2012 at 01:07:40PM +0100, Alexander Burger wrote: If it is 9 according to the include file on the Mac, is this also the value returned by 'src64/sysdefs', and which thus appears in the above 'fcntl' line (which is (correctly) 14 for Debian)? I mean, how do these lines look on your system? Do they show 9 instead of 14? What I want to say: I don't care what the actual value of F_SETLKW is. It just has to be the _correct_ one on the system where it runs on. If not, then the question is where it goes wrong. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
I'm not familiar with the syntax, but could this be the problem?
--- a/src64/io.lSat Nov 03 15:07:11 2012 +0100
+++ b/src64/io.lSun Nov 04 15:08:35 2012 +0100
@@ -26,7 +26,7 @@
(code 'rdLockFileC)
ld A F_RDLCK # Read lock, length 0
(code 'lockFileAC)
- st2 (Flock) # 'l_type'
+ st2 (Flock L_TYPE) # 'l_type'
ld (Flock L_START) 0 # Start position ('l_whence' is SEEK_SET)
shr A 16 # Get length
ld (Flock L_LEN) A # Length
On Nov 4, 2012, at 2:59 PM, Alexander Burger wrote:
On Sun, Nov 04, 2012 at 01:07:40PM +0100, Alexander Burger wrote:
If it is 9 according to the include file on the Mac, is this also the
value returned by 'src64/sysdefs', and which thus appears in the above
'fcntl' line (which is (correctly) 14 for Debian)? I mean, how do these
lines look on your system? Do they show 9 instead of 14?
What I want to say: I don't care what the actual value of F_SETLKW is.
It just has to be the _correct_ one on the system where it runs on. If
not, then the question is where it goes wrong.
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
After applying that, some tests are still failing. In test/lib/misc.l and
test/src/main.l there are checks for chdir that use /tmp. On Mac, /tmp is a
symlink to /private/tmp.
I would just change /tmp for /bin.
Also, test/src/ext.l and test/src/ht.l fail quite early:
bash-3.2$ ./pil lib/test.l $(/bin/pwd) -bye +
[test/src/ext.l:5] !? (ext:Snx PicoLisp is not Common Lisp)
ext:Snx -- Undefined
?
(commented ext.l loading)
bash-3.2$ ./pil lib/test.l $(/bin/pwd) -bye +
[test/src/ht.l:5] !? (ht:Prin 123äöüiÄÖÜß)
ht:Prin -- Undefined
((pipe (ht:Prin 123äöüiÄÖÜß) (line T)))
[test/src/ht.l:5] 1lt;2gt;3amp;äöült;igt;ÄÖÜß -- 'test' failed
?
On Nov 4, 2012, at 3:10 PM, Jorge Acereda wrote:
I'm not familiar with the syntax, but could this be the problem?
--- a/src64/io.lSat Nov 03 15:07:11 2012 +0100
+++ b/src64/io.lSun Nov 04 15:08:35 2012 +0100
@@ -26,7 +26,7 @@
(code 'rdLockFileC)
ld A F_RDLCK # Read lock, length 0
(code 'lockFileAC)
- st2 (Flock) # 'l_type'
+ st2 (Flock L_TYPE) # 'l_type'
ld (Flock L_START) 0 # Start position ('l_whence' is SEEK_SET)
shr A 16 # Get length
ld (Flock L_LEN) A # Length
On Nov 4, 2012, at 2:59 PM, Alexander Burger wrote:
On Sun, Nov 04, 2012 at 01:07:40PM +0100, Alexander Burger wrote:
If it is 9 according to the include file on the Mac, is this also the
value returned by 'src64/sysdefs', and which thus appears in the above
'fcntl' line (which is (correctly) 14 for Debian)? I mean, how do these
lines look on your system? Do they show 9 instead of 14?
What I want to say: I don't care what the actual value of F_SETLKW is.
It just has to be the _correct_ one on the system where it runs on. If
not, then the question is where it goes wrong.
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jorge, I'm not familiar with the syntax, but could this be the problem? ... (code 'lockFileAC) - st2 (Flock) # 'l_type' + st2 (Flock L_TYPE) # 'l_type' Yes!! Very true! A stupid mistake on my side. I don't remember the reason, but somehow I must have been under the assumption that 'l_type' is always zero. Is it non-zero on the Mac? Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Nov 4, 2012, at 4:05 PM, Alexander Burger wrote: On Sun, Nov 04, 2012 at 03:56:04PM +0100, Alexander Burger wrote: I would just change /tmp for /bin. I see. The test does a chdir to /tmp, and then verifies that it is indeed there. But can we be sure that /bin isn't a symlink either on some systems? Then I would propose simply to use / - This shouldn't be a symlink on any system, right? :) Sure :-) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Nov 4, 2012, at 3:56 PM, Alexander Burger wrote: There should be two libraries in lib/ (here, on a 32-bit x86-32): $ file lib/ht lib/ext lib/ht: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped lib/ext: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped Are they there? If not, wasn't there an error during the make process? No error. bash-3.2$ file lib/ext lib/ext: Mach-O 64-bit dynamically linked shared library x86_64 I guess there's a problem with the the symbol loading. nm lib/ext shows the symbols are prefixed with _: .. 1238 D _Snx -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jorge, bash-3.2$ file lib/ext lib/ext: Mach-O 64-bit dynamically linked shared library x86_64 I guess there's a problem with the the symbol loading. nm lib/ext shows the symbols are prefixed with _: .. 1238 D _Snx Yeah, that would explain it. Crappy a.out format on the Mac. I wonder why it worked in pil32 (or didn't it?)? Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Sun, Nov 04, 2012 at 05:09:14PM +0100, Jorge Acereda wrote: Then I would propose simply to use / - This shouldn't be a symlink on any system, right? :) Sure :-) Released a new testing version with all your suggested changes. ♪♫ - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex, Things are looking much better now: MacBook-Air:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function run: emu.base.c:42119: warning: format not a string literal and no format arguments emu.base.c:42174: warning: format not a string literal and no format arguments MacBook-Air:picoLispEmu jkleiser$ ./pil + : (load misc/fibo.l) - NIL : (fibo 9) - 34 : (bye) MacBook-Air:picoLispEmu jkleiser$ ./pil + misc/fibo.l : (fibo 9) - 34 /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Nov 4, 2012, at 5:27 PM, Alexander Burger wrote: On Sun, Nov 04, 2012 at 05:09:14PM +0100, Jorge Acereda wrote: Then I would propose simply to use / - This shouldn't be a symlink on any system, right? :) Sure :-) Released a new testing version with all your suggested changes. test/scr/main.l contains a similar test that should also be changed to /. ♪♫ - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, Things are looking much better now: ... MacBook-Air:picoLispEmu jkleiser$ ./pil + : (load misc/fibo.l) - NIL : (fibo 9) - 34 Yes, indeed. MacBook-Air:picoLispEmu jkleiser$ ./pil + misc/fibo.l Oops. Please note that this is probably not what is intended, and should actually give an error. The '+' must be at the very end of the line: $ ./pil misc/fibo.l + In pil32: $ ./pil + misc/fibo.l + open: No such file or directory ? Strangely, pil64 (and also the emulator) doesn't signal an error here. Instead, it creates an empty file with the name +. I never noticed that, as I never tried to call it this way ;-) Let me investigate ... - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Nov 4, 2012, at 6:43 PM, Alexander Burger wrote: On Sun, Nov 04, 2012 at 06:12:36PM +0100, Jorge Acereda wrote: Works ok on 32 bits: bash-3.2$ ./pil lib/test.l $(/bin/pwd) -bye + OK Interesting. What might be the reason? Is the library format different between those versions? Or do we need some linker command line flag to get the proper format (i.e. holding 'Snx' instead of '_Snx')? I'm now doubting the underscore is the problem. I wrote the following test and it resolves properly the Snx symbol without underscores. test.c Description: Binary data I guess the best is printing dlerror() after the failed dlopen()/dlsym(), that might give some hints. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Ok, no need to modify the sources, this is an interpreter, right? ;-) ? (native @ dlopen 'N lib/ext 9) (native @ dlopen 'N lib/ext 9) dyld: loaded: /Users/jacereda/picolisp/lib/ext dyld: unloaded: /Users/jacereda/picolisp/lib/ext - 0 ? (native @ dlerror 'S) (native @ dlerror 'S) - dlopen(lib/ext, 9): Symbol not found: _A^J Referenced from: /Users/jacereda/picolisp/lib/\ ext^J Expected in: flat namespace^J in /Users/jacereda/picolisp/lib/ext ? Perhaps the executable shouldn't be stripped? On Nov 4, 2012, at 6:59 PM, Jorge Acereda wrote: On Nov 4, 2012, at 6:43 PM, Alexander Burger wrote: On Sun, Nov 04, 2012 at 06:12:36PM +0100, Jorge Acereda wrote: Works ok on 32 bits: bash-3.2$ ./pil lib/test.l $(/bin/pwd) -bye + OK Interesting. What might be the reason? Is the library format different between those versions? Or do we need some linker command line flag to get the proper format (i.e. holding 'Snx' instead of '_Snx')? I'm now doubting the underscore is the problem. I wrote the following test and it resolves properly the Snx symbol without underscores. test.c I guess the best is printing dlerror() after the failed dlopen()/dlsym(), that might give some hints. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Nov 4, 2012, at 7:35 PM, Jorge Acereda wrote: Ok, no need to modify the sources, this is an interpreter, right? ;-) ? (native @ dlopen 'N lib/ext 9) (native @ dlopen 'N lib/ext 9) dyld: loaded: /Users/jacereda/picolisp/lib/ext dyld: unloaded: /Users/jacereda/picolisp/lib/ext - 0 ? (native @ dlerror 'S) (native @ dlerror 'S) - dlopen(lib/ext, 9): Symbol not found: _A^J Referenced from: /Users/jacereda/picolisp/lib/\ ext^J Expected in: flat namespace^J in /Users/jacereda/picolisp/lib/ext ? Perhaps the executable shouldn't be stripped? Bingo, removing the stripping did the trick. All tests pass now. I think it would be better to just mark the symbols that should be exported. Depending on the unstripped executable seems a bit dirty. On Nov 4, 2012, at 6:59 PM, Jorge Acereda wrote: On Nov 4, 2012, at 6:43 PM, Alexander Burger wrote: On Sun, Nov 04, 2012 at 06:12:36PM +0100, Jorge Acereda wrote: Works ok on 32 bits: bash-3.2$ ./pil lib/test.l $(/bin/pwd) -bye + OK Interesting. What might be the reason? Is the library format different between those versions? Or do we need some linker command line flag to get the proper format (i.e. holding 'Snx' instead of '_Snx')? I'm now doubting the underscore is the problem. I wrote the following test and it resolves properly the Snx symbol without underscores. test.c I guess the best is printing dlerror() after the failed dlopen()/dlsym(), that might give some hints. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Joe, I had the same issue on another machine. I was able to get this working by changing the gcc args to -m32 in lib/native.l instead of -m64 (apply call L 'gcc -o (tmp Nm) -fPIC -m32 -shared -export-dynamic Good! I don't know enough about this to offer an opinion on whether -m64 is appropriate on a 32bit machine. It sounds like it's possible to cross You are very right. I removed the -m64 from lib/native.l and did some tests. It is not needed, and probably better (system independent) simply without the flag. Thanks! - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, At least something has changed during the make: MacBook-Air:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function run: emu.base.c:42115: warning: format not a string literal and no format arguments emu.base.c:42170: warning: format not a string literal and no format arguments No, no change. As I said in the previous mail, this is a warning message which can be ignored (the compiler doesn't know the format string for 'printf', which it _of_course_ can't know because it is passed dynamically at runtime). This warning (-Wformat-security) is enabled on some system, for example also on Ubuntu. It could be switched off. MacBook-Air:picoLispEmu jkleiser$ ./pil + [/Users/jkleiser/.pil/history:1] File lock: Invalid argument This is strange. I expected this error to be gone. Are you sure you used the latest tarball (from yesterday, 02nov12, 18:35)? : (load misc/fibo.l) [misc/fibo.l:40] !? (here /**/) here -- Undefined Again started without the standard libraries? MacBook-Air:picoLispEmu jkleiser$ ./bin/picolisp : (load misc/fibo.l) [lib/native.l:31] !? (** 2 32) ** -- Undefined Yup ;-) MacBook-Air:picoLispEmu jkleiser$ ./bin/picolisp misc/fibo.l [misc/fibo.l:38] !? (load @lib/native.l) @lib/native.l -- Open error: No such file or directory Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Joe joebo@joebo:~/tmp/picolisp$ ./pil + : *CPU - emu : (load misc/fibo.l) /usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.4.5/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.4.5/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status Strange. A problem of incompatible library installations? Linux 2.6.32-5-686-bigmem #1 SMP Wed Jan 12 04:40:25 UTC 2011 i686 GNU/Linux Nearly the same as I have: Linux lab 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux I'm running Debian 6.0 I have squeeze with some sprinkles of wheezy and sid. I tried some very basic picolisp operations and they worked fine. So the problem seems mainly with the loading of dynamic libs. I haven't done any native work since I had been running 32bit and so I don't know if there's something broken on my install or if it's an issue with pil64emu. In any case, I wanted to share my findings. Sure. Many thanks! Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, Yes, quite sure, and I have repeated the whole thing just now, with the latest ongoing, and I haven't spotted a single change from what I reported yesterday. That's a pity. Then I have no idea why fcntl() doesn't work :( The function ** is now obviously not defined in pil32 when I start it globally with just picolisp. If I start with ./dbg, then (** 2 32) - 4294967296. Why is that? Because just 'picolisp' is not very useful by itself. It is only the bare interpreter, without any runtime environment, and without the fundamental libraries loaded. Most notably, lib.l should be loaded, and it should be the first argument to bin/picolisp. In short, unless you want to do something special or write scripts, it is always recommended to start PicoLisp as: [./]pil [+] Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, Starting pil64emu with file argument, like ./bin/picolisp misc/fibo.l, still gives me a Segmentation fault. What's definitely still missing is 'native' support. As misc/fibo.l also does some native stuff, perhaps this is the culprit? Are there other interesting 64-bit features I could try at the moment? I hope I can finish some basic 'native' support during this week. Let's postpone testing until then? Meanwhile, we have an improved version! :) I'm not sure about the crash on your Mac yet (and other probable bugs), but pil4emu is now rather complete. The unit tests pass, and a subset of 'native' is supported (I've tested it with some of your openGl examples). When the smoke clears, I'll write up some more details. Let's first see how it works on your Mac. I've tested on Linux/x86-32 and Ubuntu/x86-64 so far. To build it, it is now only necessary to do: $ (cd src64/; make emu) This will force building the emulator, even on machines which are natively supported (like x86-64 or ppc64). A new global *CPU will tell us for which architecture the binary was actually built: : *CPU - emu or : *CPU - x86-64 etc. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex, On 11/2/12 1:44 PM, Alexander Burger wrote: Hi Jon, Starting pil64emu with file argument, like ./bin/picolisp misc/fibo.l, still gives me a Segmentation fault. What's definitely still missing is 'native' support. As misc/fibo.l also does some native stuff, perhaps this is the culprit? Are there other interesting 64-bit features I could try at the moment? I hope I can finish some basic 'native' support during this week. Let's postpone testing until then? Meanwhile, we have an improved version! :) I'm not sure about the crash on your Mac yet (and other probable bugs), but pil4emu is now rather complete. The unit tests pass, and a subset of 'native' is supported (I've tested it with some of your openGl examples). When the smoke clears, I'll write up some more details. Let's first see how it works on your Mac. I've tested on Linux/x86-32 and Ubuntu/x86-64 so far. To build it, it is now only necessary to do: $ (cd src64/; make emu) This will force building the emulator, even on machines which are natively supported (like x86-64 or ppc64). A new global *CPU will tell us for which architecture the binary was actually built: : *CPU - emu or : *CPU - x86-64 etc. Cheers, - Alex It builds more or less as before, and it's still got problems loading .l files (on my Mac): f3bmac3:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function ‘run’: emu.base.c:42115: warning: format not a string literal and no format arguments emu.base.c:42170: warning: format not a string literal and no format arguments strip: symbols referenced by indirect symbol table entries that can't be stripped in: /Volumes/P3/picoLispEmu/lib/ext _exit _fwrite make: *** [../lib/ext] Error 1 f3bmac3:picoLispEmu jkleiser$ ./bin/picolisp : (== 64 64) - T : *CPU - emu : (load misc/fibo.l) [lib/native.l:31] !? (** 2 32) ** -- Undefined ? : (bye) f3bmac3:picoLispEmu jkleiser$ ./bin/picolisp misc/fibo.l [misc/fibo.l:38] !? (load @lib/native.l) @lib/native.l -- Open error: No such file or directory ? : (bye) Am I doing something wrong? /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, It builds more or less as before, and it's still got problems loading .l files (on my Mac): f3bmac3:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function ‘run’: emu.base.c:42115: warning: format not a string literal and no format arguments OK, this is correct. It is a warning which doesn't make sense here (printf called dynamically). It could be switched off (-Wformat-security). strip: symbols referenced by indirect symbol table entries that can't be stripped in: /Volumes/P3/picoLispEmu/lib/ext _exit _fwrite make: *** [../lib/ext] Error 1 I see. Then it is perhaps better not to strip the shared libraries at all? I remove the lines $(STRIP) $(lib)/ext and $(STRIP) $(lib)/ht from src64/Makefile. Does anybody know a better solution? f3bmac3:picoLispEmu jkleiser$ ./bin/picolisp : (== 64 64) - T : *CPU - emu Good :) : (load misc/fibo.l) [lib/native.l:31] !? (** 2 32) ** -- Undefined ? : (bye) It seems you started only bin/picolisp, right? '**' is defined in lib.l, so at least bin/picolisp lib.l must be started. As ever, the recommended way is ./pil +. f3bmac3:picoLispEmu jkleiser$ ./bin/picolisp misc/fibo.l [misc/fibo.l:38] !? (load @lib/native.l) @lib/native.l -- Open error: No such file or directory Same reason here. If the first argument is not correctly set up (typically lib.l), then the path to the installation directory (to be used by '@..') is missing. So ./pil + should be the first thing to try. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex, On 11/2/12 4:30 PM, Alexander Burger wrote: Hi Jon, .. : (load misc/fibo.l) [lib/native.l:31] !? (** 2 32) ** -- Undefined ? : (bye) It seems you started only bin/picolisp, right? '**' is defined in lib.l, so at least bin/picolisp lib.l must be started. As ever, the recommended way is ./pil +. f3bmac3:picoLispEmu jkleiser$ ./bin/picolisp misc/fibo.l [misc/fibo.l:38] !? (load @lib/native.l) @lib/native.l -- Open error: No such file or directory Same reason here. If the first argument is not correctly set up (typically lib.l), then the path to the installation directory (to be used by '@..') is missing. So ./pil + should be the first thing to try. Cheers, - Alex It didn't work too well: f3bmac3:picoLispEmu jkleiser$ ./pil + [/Users/jkleiser/.pil/history:1] File lock: Bad address ? : (bye) /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, f3bmac3:picoLispEmu jkleiser$ ./pil + [/Users/jkleiser/.pil/history:1] File lock: Bad address Hmm, that's the same we had last week. For some reason, fcntl() doesn't work. It workes on pil32, I believe. Any ideas anybody (hello, Mac programmers?). ♪♫ - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
On Fri, Nov 02, 2012 at 05:38:40PM +0100, Alexander Burger wrote: For some reason, fcntl() doesn't work. It workes on pil32, I believe. Perhaps found the reason. I've changed the calling pattern of fcntl(). Please try once more. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex, On Fri, Nov 02, 2012 at 05:38:40PM +0100, Alexander Burger wrote: For some reason, fcntl() doesn't work. It workes on pil32, I believe. Perhaps found the reason. I've changed the calling pattern of fcntl(). Please try once more. Cheers, - Alex At least something has changed during the make: MacBook-Air:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function run: emu.base.c:42115: warning: format not a string literal and no format arguments emu.base.c:42170: warning: format not a string literal and no format arguments MacBook-Air:picoLispEmu jkleiser$ ./pil + [/Users/jkleiser/.pil/history:1] File lock: Invalid argument ? : (== 64 64) - T : *CPU - emu : (load misc/fibo.l) [misc/fibo.l:40] !? (here /**/) here -- Undefined ? : (bye) MacBook-Air:picoLispEmu jkleiser$ ./bin/picolisp : (load misc/fibo.l) [lib/native.l:31] !? (** 2 32) ** -- Undefined ? : (bye) MacBook-Air:picoLispEmu jkleiser$ ./bin/picolisp misc/fibo.l [misc/fibo.l:38] !? (load @lib/native.l) @lib/native.l -- Open error: No such file or directory ? : (bye) /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Alex, pil64emu sounds very interesting. In case it helps, here is some output from running pil64emu joebo@joebo:~/tmp/picolisp$ ./pil + : *CPU - emu : (load misc/fibo.l) /usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.4.5/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.4.5/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status - NIL : Here is my uname output: Linux 2.6.32-5-686-bigmem #1 SMP Wed Jan 12 04:40:25 UTC 2011 i686 GNU/Linux I'm running Debian 6.0 I tried some very basic picolisp operations and they worked fine. I haven't done any native work since I had been running 32bit and so I don't know if there's something broken on my install or if it's an issue with pil64emu. In any case, I wanted to share my findings. Thank you ! Joe On Fri, Nov 2, 2012 at 3:47 PM, Jon Kleiser jon.klei...@usit.uio.no wrote: Hi Alex, On Fri, Nov 02, 2012 at 05:38:40PM +0100, Alexander Burger wrote: For some reason, fcntl() doesn't work. It workes on pil32, I believe. Perhaps found the reason. I've changed the calling pattern of fcntl(). Please try once more. Cheers, - Alex At least something has changed during the make: MacBook-Air:picoLispEmu jkleiser$ (cd src64; make) emu.base.c: In function ‘run’: emu.base.c:42115: warning: format not a string literal and no format arguments emu.base.c:42170: warning: format not a string literal and no format arguments MacBook-Air:picoLispEmu jkleiser$ ./pil + [/Users/jkleiser/.pil/history:1] File lock: Invalid argument ? : (== 64 64) - T : *CPU - emu : (load misc/fibo.l) [misc/fibo.l:40] !? (here /**/) here -- Undefined ? : (bye) MacBook-Air:picoLispEmu jkleiser$ ./bin/picolisp : (load misc/fibo.l) [lib/native.l:31] !? (** 2 32) ** -- Undefined ? : (bye) MacBook-Air:picoLispEmu jkleiser$ ./bin/picolisp misc/fibo.l [misc/fibo.l:38] !? (load @lib/native.l) @lib/native.l -- Open error: No such file or directory ? : (bye) /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Shaun, Now that it's out of the bag, what is the purpose of pil64emu? I've been seeing it on the repo, and I am curious. :-) Yes, that's a valid question. I think it is necessary for completeness, to make pil64 available also on systems not explicitly supported. pil64 has features not available in pil32, like a better database serialization format, short numbers, coroutines, namespaces and native C call.s I myself actually want it for not time-critical purposes like replicating 64-bit databases to a 32-bit server. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
pil64emu testing features
Hi Alex, Using the latest ongoing picoLisp, I have briefly tested coroutines in pil64emu, and it works. I used the pythag code at http://picolisp.com/5000/!wiki?Coroutines Starting pil64emu with file argument, like ./bin/picolisp misc/fibo.l, still gives me a Segmentation fault. Are there other interesting 64-bit features I could try at the moment? /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu testing features
Hi Jon, Using the latest ongoing picoLisp, I have briefly tested coroutines in pil64emu, and it works. I used the pythag code at Thanks for the testing! Perhaps you are a little bit too early. pil64emu isn't even announced here yet ;-) Starting pil64emu with file argument, like ./bin/picolisp misc/fibo.l, still gives me a Segmentation fault. What's definitely still missing is 'native' support. As misc/fibo.l also does some native stuff, perhaps this is the culprit? Are there other interesting 64-bit features I could try at the moment? I hope I can finish some basic 'native' support during this week. Let's postpone testing until then? Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
