Re: Are PicoLisp's coroutine stacks legal?

2013-05-20 Thread Jorge Acereda Maciá
Hi, I can only say that under AmigaOS it would certainly be a no-no: http://wiki.amigaos.net/index.php/Exec_Tasks#Task_Exceptions When an exception occurs, Exec stops executing the tasks normal code and jumps immediately into the exception routine, no matter what the task was doing. The

Re: Are PicoLisp's coroutine stacks legal?

2013-05-21 Thread Jorge Acereda Maciá
Hi, On May 21, 2013, at 6:56 AM, Alexander Burger a...@software-lab.de wrote: They talk about task stacks and preserved on this stack. I assume that these stacks all reside on the single hardware stack, right? So there is a stack *frame* for each task, and this frame might also be used to

Re: Are PicoLisp's coroutine stacks legal?

2013-05-21 Thread Jorge Acereda Maciá
Hi, On May 21, 2013, at 7:46 AM, Alexander Burger a...@software-lab.de wrote: The big question is: Will the system (which system?) do that? If so, how do other languages implement green threads, coroutines or continuations? Some OSs do provide the required functionality (e.g, the fibers API

Re: Quick try at building 64-bit on OSX 10.8.3

2013-05-22 Thread Jorge Acereda Maciá
I tried to build the emu version on OSX and it failed. Here is the culprit line: emu.patch Description: Binary data Regards, Jorge On May 22, 2013, at 5:24 PM, Alexander Burger a...@software-lab.de wrote: Hi Jon, to see if something magical have happened that would make it possible

Re: Quick try at building 64-bit on OSX 10.8.3

2013-05-22 Thread Jorge Acereda Maciá
On May 22, 2013, at 8:19 PM, Alexander Burger a...@software-lab.de wrote: Hi Jorge, I tried to build the emu version on OSX and it failed. Here is the culprit line: Thanks! Unfortunately, it is not so easy, because then you get a warning on 32-bit systems: cast from pointer to

Re: Quick try at building 64-bit on OSX 10.8.3

2013-05-23 Thread Jorge Acereda Maciá
Hi, A quick question, what's the status of the *FPic variant on Linux? Is it working? If it works properly, I guess I could get it running on OSX as well when I find some spare time...-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Quick try at building 64-bit on OSX 10.8.3

2013-05-24 Thread Jorge Acereda Maciá
Hi Alex, On May 24, 2013, at 10:49 AM, Alexander Burger a...@software-lab.de wrote: If it works properly, I guess I could get it running on OSX as well when I find some spare time...-- That would be great! I must say that I gave up on that, see e.g.

Re: Missing o in -lcrypt in scr/Makefile

2013-05-24 Thread Jorge Acereda Maciá
On May 24, 2013, at 4:11 PM, Alexander Burger a...@software-lab.de wrote: Hi Jon, I believe there is a missing o at the end of line 104 in the current scr/Makefile. Adding the o to make it -lcrypto helped me build 32-bit PicoLisp, v. 3.1.2.9 C (on Mac OS X 10.8.3). Under Linux it is

Re: Quick try at building 64-bit on OSX 10.8.3

2013-05-25 Thread Jorge Acereda Maciá
On May 25, 2013, at 9:22 AM, Alexander Burger a...@software-lab.de wrote: HI Jorge, Well, x64 sucks, no surprise here, but not as much as x86. Perhaps a good strategy here would be to use one of the C calling registers (%r9 for instance) as a preloaded NIL. Restoring that value after

Re: REPL and OpenGL

2013-05-28 Thread Jorge Acereda Maciá
A couple of options: - Use coroutines and yield control to the main thread in the glutIdleFunc. - Use a library that doesn't take control of the main loop. I can think of mine ( http://code.google.com/p/libaw/ ) and GLFW ( http://www.glfw.org ). On May 28, 2013, at 10:57 AM, Oskar Wieland

Re: Problems with 'call'

2013-05-29 Thread Jorge Acereda Maciá
On May 29, 2013, at 7:05 PM, Thorsten Jolitz tjol...@gmail.com wrote: - the variable is set and known to BASH, but somehow PicoLisp does not know about it: Did you export it? (export FOO=x instead of just FOO=x) -- UNSUBSCRIBE:

Re: Regarding the implementations of PicoLisp

2014-05-13 Thread Jorge Acereda Maciá
On 13 May 2014, at 07:06, Alexander Burger a...@software-lab.de wrote: Basically you are implementing you own malloc(), which is still far away from a single-instruction push, pop or stack arithmetic. Am I missing something? alloca() just adds an offset to the stack pointer: #include

Re: Solved: Tell mechanism issue (perhaps OT)

2014-08-06 Thread Jorge Acereda Maciá
I’m getting pids well above 64k on my laptop (OS X). On 06 Aug 2014, at 22:33, Alexander Burger a...@software-lab.de wrote: Hi Randall, I believe that modern Linux and FreeBSD implementations use 32 bit ints for the pid_t. Right. There will never be that many processes on a 32 bit

Re: Solved: Tell mechanism issue (perhaps OT)

2014-08-07 Thread Jorge Acereda Maciá
, is it a 64bit machine? I have checked the number Alex mentioned on some of our servers, all running Ubuntu 12.04, servers below 64GB RAM have that number set to 32768 per default, machines with 128GB got 98304. On Thu, Aug 7, 2014 at 12:49 PM, Jorge Acereda Maciá jacer...@gmail.com wrote: I’m getting

Re: Solved: Tell mechanism issue (perhaps OT)

2014-08-07 Thread Jorge Acereda Maciá
Oh, you mean the 32 bit version of pico lisp? Thats right… On 06 Aug 2014, at 23:23, Jorge Acereda Maciá jacer...@gmail.com wrote: It’s a 64bit 8 GB machine. BSDs work differently: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/basics-processeshtml Maximum seems to be 9