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
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
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
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:
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.
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
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
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
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
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
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) #
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
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
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
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,
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
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:
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
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.
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
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
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)
-
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
?
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
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
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
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
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
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
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
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
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:
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:
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
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:
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
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
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
38 matches
Mail list logo
