Unsubscribe
Good bye Jorge Acereda <jacer...@gmail.com> :-( You are now unsubscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Solved: Tell mechanism issue (perhaps OT)
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, at least on FreeBSD. On 06 Aug 2014, at 23:09, Henrik Sarvell hsarv...@gmail.com wrote: Hi Jorge, how much RAM does it have, 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 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 OS, but since they just go forward until they wrap, getting a pid bigger than 16 bits is probably even to be expected. However, they don't plainly wrap. There is a system limit in the kernel, controlled via /proc/sys/kernel/pid_max. Even on 64-bit machines (where pid_t is also an 'int', i.e. a 64-bit number), PIDs don't get up to such huge numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Solved: Tell mechanism issue (perhaps OT)
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, at least on FreeBSD. On 06 Aug 2014, at 23:09, Henrik Sarvell hsarv...@gmail.com wrote: Hi Jorge, how much RAM does it have, 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 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 OS, but since they just go forward until they wrap, getting a pid bigger than 16 bits is probably even to be expected. However, they don't plainly wrap. There is a system limit in the kernel, controlled via /proc/sys/kernel/pid_max. Even on 64-bit machines (where pid_t is also an 'int', i.e. a 64-bit number), PIDs don't get up to such huge numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- 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: Solved: Tell mechanism issue (perhaps OT)
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 OS, but since they just go forward until they wrap, getting a pid bigger than 16 bits is probably even to be expected. However, they don't plainly wrap. There is a system limit in the kernel, controlled via /proc/sys/kernel/pid_max. Even on 64-bit machines (where pid_t is also an 'int', i.e. a 64-bit number), PIDs don't get up to such huge numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Regarding the implementations of PicoLisp
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 stdlib.h
extern void foo(void *);
void test() {
foo(alloca(100));
}
bash-3.2$ cc -fomit-frame-pointer -fno-stack-protector -c -O3 test.c
bash-3.2$ otool -tV test.o
test.o:
(__TEXT,__text) section
_test:
subq$0x68, %rsp
0004leaq0x4(%rsp), %rdi
0009callq _foo
000eaddq$0x68, %rsp
0012ret
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Regarding the implementations of PicoLisp
Why not alloca()? El 12 May 2014, a las 16:31, Joe Bogner joebog...@gmail.com escribió: The proper solution is likely to use malloc/fre -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Problems with 'call'
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: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: REPL and OpenGL
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 oskar.wiel...@gmx.de wrote: Hi, I'm trying to create an OpenGL window without loosing control to the glutMainLoop. Thus I added the following definition from glut to OpenGL: : (de glutMainLoopEvent () (native `*GlutLib glutMainLoopEvent) ) I set up some kind of main loop: : (mouseFunc '((Btn State X Y) (setq _run NIL))) # Exit upon mouse click : (de go () (setq _run T)(while _run (glutMainLoopEvent))) Is there a function to keep the REPL in the console alive, like (de go () (setq _run T)(while _run (glutMainLoopEvent DO_THE_REPL))) or is there another (better) way to create a OpenGL window without loosing control to glutMainLoop? Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
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 calling C Surely %r9 could be freed for general purposes. I don't remember if that would solve any problem. Why do you think of NIL especially? You're right, upon deeper inspection it seems it doesn't solve any problem, it just postpones it. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
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. http://www.mail-archive.com/picolisp@software-lab.de/msg03816.html 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 calling C shouldn't be much of a problem and would probably make code cleaner and faster. I've done some preliminary experiments with that and it looks promising. What do you think of such approach? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Missing o in -lcrypt in scr/Makefile
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 -lcrypt (according to the man page of crypt(3)). Seems we must make src/Makefile aware of the OS-depenencies again :( There's another option, embedding a libcrypt in picolisp sources. Dealing with changes upstream is always a pain, but OpenBSD's could be a good option. According to the CVS logs it seems quite stable. Didn't try to build it though. http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/ -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
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
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 for me to build 64-bit PicoLisp, so I did the (cd src64; ... runtime. As I'm not very convinced that such a Java SE 6 runtime would give me the 64-bit PicoLisp, I have not accepted that offer yet. Am I wrong? ;-) If you install Java, you can cross-assemble PicoLisp via ErsatzLisp. This is usually not necessary, because you might as well download the pre-assembled '*.s'-files. BUT: In case of the Mac, both approaches won't work, as the Mac's a.out-format is still not supported (you know .. ye old problems). So better don't install Java ;-) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
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 integer of different size [-Wpointer-to-int-cast] So for 32-bits, we must still first cast to an uint32_t. I'd say we change it to: ... (p (if *Bits64 (_genCC A.n = (uint64_t)(uint8_t*)@1(@2);@3) (_genCC A.n = (uint64_t)(uint32_t)(uint8_t*)@1(@2);@3) ) ) ... Does this work for you? If so, I'll put it into the release. Ok, if that's the problem this is nicer… Does it compile without warnings on your 32-bit system? emu2.patch Description: Binary data
Re: Are PicoLisp's coroutine stacks legal?
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 save exception context. That's all right. Each task has a different stack using a single user-mode stack pointer. In Amiga there is no memory protection, a context switch just involves saving the registers in the stack, saving the stack pointer itself in the stack structure, restoring the stack pointer of the next task and returning to it in a way that restores the registers. It seems not forbidden, however, to allocate several frames below each other, where the active stack pointer points into some upper frame, right? That's the problem I'm talking about. I thought you were talking about micro stacks. If your stacks are 1 Mb I guess there won't be any problem. If at some point you face problems on a system that happens to unmap stack pages (I doubt it), you can probably workaround it by marking the stack pages with mlock() or similar. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Are PicoLisp's coroutine stacks legal?
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 on Windows). On POSIX, it's usually a matter of using some dirty hack (setjmp()/longjmp() being the most portable, swapcontext() is also quite popular). When working in embedded/mobile I have seen a couple of platforms with broken setjmp()/longjmp() implementations, so that can also be troublesome. The problem is so complex that perhaps your approach is the simplest. Just take a look at how nasty the thing can get: http://code.google.com/p/libaw/source/browse/coroutine/source/Coro.c Regards, Jorge-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Are PicoLisp's coroutine stacks legal?
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 exception routine operates in the same context the task's normal code; it operates in the CPU's user mode and uses the task's stack. http://wiki.amigaos.net/index.php/Exec_Tasks#Task_Stack Task stacks are normally used to store local variables, subroutine return addresses, and saved register values. Additionally, when a task loses the processor, all of its current registers are preserved on this stack (with the exception of the stack pointer itself, which must be saved in the task structure). On May 20, 2013, at 6:43 PM, Alexander Burger a...@software-lab.de wrote: Hi all, since nearly three years PicoLisp supports coroutines (64-bit version). Now suddenly it occurred to me that the way I implemented them might be illegal. The problem is how individual stacks for the coroutines are allocated. I do this by reserving space on the stack (by decrementing the stack pointer) upon starting a new coroutine. Execution of that coroutine may be suspended (with 'yield', so that execution continues in the main program or some other coroutine), to be resumed later. Switching between individual (co)routines is done by moving the stack pointer up and down between the corresponding stack frames. Everything seems to work fine - though I haven't used coroutines in serious projects yet. Now I remember to have read that (in POSIX?) no valid data should be stored *below* the current position of the stack pointer. Is that really the case? I can't find any conclusive information about that. This switching between stack frames, as described above, of course leaves temporarily suspended stack frames *below* the stack pointer, while it points into a higher frame. Does this mean that the operating system might dispose or overwrite them? For example, when paging is required? Interrupts are probably not a problem, as they push their contexts on the system stack. Some sources say that even GCC stores (small amounts of) data below the stack pointer, while others (possibly some ABIs from Intel) say this is an absolute no-no. Can anybody point to a definite answer? ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: picoLisp on FreeBSD 9.1 x64
On Fri, Jan 4, 2013 at 12:56 PM, Alexander Burger a...@software-lab.de wrote: Hi Mansur, I've got working pil x64 on BSD. All tests are passed, Great! Congratulations :) but with ext and ht: [test/src/ext.l:5] !? (ext:Snx PicoLisp is not Common Lisp) ext:Snx -- Undefined ... [test/src/ht.l:5] !? (ht:Prin 123äöüiÄÖÜß) ht:Prin -- Undefined I suspect that this is a problem of the 'LD-SHARED' value in src64/Makefile. The libraries lib/ext and lib/ht may be created wrongly, so that they are either not recognized by dlopen(), or the symbols are not found by dlsym(). Perhaps it's the same problem I experienced under Darwin. Try changing the 'STRIP=strip' line to 'STRIP=echo' and see if that fixes the problem. Then it should just be a matter of finding the right strip flags for your platform. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu, OpenGL?
Just a note, the Frameworks/ part is irrelevant. Looks like it uses just the 2 last components of the path (OpenGL.framework/OpenGL). I have changed it to /foo/bar/OpenGL.framework/OpenGL and it works the same. On Nov 8, 2012, at 9:01 PM, Alexander Burger wrote: Hi Jon, hi Jorge, I suggest, in lib/openGl.l, to replace (default *GluLib libGLU.so *GlutLib libglut.so ) with (if (= *OS Darwin) (default *GluLib Frameworks/OpenGL.framework/OpenGL *GlutLib Frameworks/GLUT.framework/GLUT ) (default *GluLib /usr/lib/libGLU.so *GlutLib /usr/lib/libglut.so ) ) It works like a dream on my iMac! Exactly why I can leave out /System/Library/ as Jorge suggested, I'm not sure, but it works. Hmm, the more I think about it, the more I agree with you both. Though keeping the library path out of the way is somewhat cleaner, it is tedious to use. I've put the above into lib/openGl.l. Thanks and cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: OpenGl.l and Segmentation fault
On Nov 8, 2012, at 9:09 PM, Alexander Burger wrote: Hi Jon, work to make OpenGl.l a little more complete (lots missing). The problem I have right now, is with glutBitmapCharacter and glutStrokeCharacter; they give me Segmentation fault, and I suspect they'll fail on Linux as well. Yes. At least 'glutStrokeCharacter' does. I'm wondering whether (or why) (glutStrokeCharacter 2 (char A)) is correct, as the corresponding C function signature is void glutStrokeCharacter(void *font, int character); i.e. '2' is a pointer. #if defined(_WIN32) /* Stroke font constants (use these in GLUT program). */ #define GLUT_STROKE_ROMAN ((void*)0) #define GLUT_STROKE_MONO_ROMAN ((void*)1) .. #else .. #define GLUT_STROKE_ROMAN (glutStrokeRoman) #define GLUT_STROKE_MONO_ROMAN (glutStrokeMonoRoman) .. #endif I faintly remember I saw this usage before (perhaps in your OpenGl / ErsatzLisp code?), and it seems passing '2' as a pointer is legal use. But then I have no idea why it crashes. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu, OpenGL?
On Nov 6, 2012, at 7:07 AM, Alexander Burger wrote: Hi Jorge, The following patch makes it work on Mac: (default - *GluLib libGLU.so - *GlutLib libglut.so ) + *GluLib (if (= *OS Darwin) + /System/Library/Frameworks/OpenGL.framework/OpenGL + libGLU.so ) + *GlutLib (if (= *OS Darwin) + /System/Library/Frameworks/GLUT.framework/GLUT + libglut.so ) ) Great, thanks! However, instead of hard-coding a system dependency, I would suggest we stay with the current version of lib/openGl.l Shouldn't it just provide sane defaults for the platform in question? There is no libGLU.so on OS X... (default *GluLib libGLU.so *GlutLib libglut.so ) and pass such special pathes in the application before calling the library: (setq *GluLib /System/Library/Frameworks/OpenGL.framework/OpenGL *GlutLib /System/Library/Frameworks/GLUT.framework/GLUT ) (load @lib/openGl.l) In that way, the 'default' in the library won't override it. But that seems contrary to the DRY motto. All applications will need to do that in order to run on OS X. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pil64emu, OpenGL?
On Nov 6, 2012, at 9:34 PM, Alexander Burger wrote: Hi Jorge, + ... + /System/Library/Frameworks/OpenGL.framework/OpenGL + ... + /System/Library/Frameworks/GLUT.framework/GLUT + ... Shouldn't it just provide sane defaults for the platform in question? There is no libGLU.so on OS X... Hmm, I'm not sure I understand that. Are the above not libraries? Sort of. Those are frameworks, frameworks encapsulate headers/shared libraries (bundles) and resources. (setq *GluLib /System/Library/Frameworks/OpenGL.framework/OpenGL *GlutLib /System/Library/Frameworks/GLUT.framework/GLUT ) (load @lib/openGl.l) In that way, the 'default' in the library won't override it. But that seems contrary to the DRY motto. All applications will need to do that in order to run on OS X. Well, it could be encapsulated in a commont source file or even command line argument. I just feel uneasy to hard-code special library locations. Shouldn't that be provided by the system environment, like load-library paths? Ok, in that case just remove /System/Library/ from the paths. I tested and it works OK. That's why I removed /usr/lib/ from the two variables. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
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, OpenGL?
The following patch makes it work on Mac: gl.patch Description: Binary data On Nov 5, 2012, at 7:35 PM, Alexander Burger wrote: Hi Jon, Here OpenGL works already since last week. I tried, for example, your pyramids.l (also attached to this mail): ./pil pyramids.l + (default *GluLib /usr/lib/libGLU.so *GlutLib /usr/lib/libglut.so ) From what I can see, there's no libglut.so to be found on my Mac. ... via VirtualBox on Mac. So where/how can one then obtain libglut.so (and libGLU.so) for use on Mac, if they are required? I don't know what to do on the Mac, but as a generalization I changed the above two default lines in lib/openGl.l to (default *GluLib libGLU.so *GlutLib libglut.so ) i.e. I removed the absolute paths. This should make it less dependent on the specific system installation. Works well here. Any objections? Cheers, - Alex -- 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
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
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
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: Parallel command execution
Hi, On Jun 2, 2012, at 10:10 AM, Alexander Burger wrote: Having said this, I see that your test program doesn't operate on a database at all. Calling the C compiler in parallel tasks _does_ make sense. Then we talk about something completely different. It was just an example. I'll have a database recording all the dependencies for each target. In that case I would need something like the following to be able to invoke the shell commands and update the database with the results. This would indeed make sense, if the shell commands induce a heavy load. It does, say we have to invoke in the order of 1 gcc commands. My toy application is a 'make' replacement. I don't like it, too convoluted for my taste. Any suggestion on how to improve the performance/style? Perhaps a different approach would be better? Yes, I think so too. If I understand you right, you want to call a number of shell commands (in a batch list), and then store the results in a database. If so, you could use something like that: Not exactly, I would prefer not to compose that list in advance. Would be good to be able to keep queueing commands while previous commands are running. My guess is that deciding what to execute next will be time-consuming, as soon as it can be determined that a target is ready for execution its command should be queued. (de processJobs (CPUs Batch) (let Slots (need CPUs free) (for Exe Batch (let Pos (wait NIL (seek '((Pos) (cond ((== free (car Pos)) # Found a free slot (set Pos busy) ) ((n== busy (car Pos)) # Found a result (msg (car Pos)) # Instead of 'msg': Store result in DB (set Pos busy) ) ) ) Slots ) ) (later Pos (eval Exe)) ) ) ) ) I guess an additional step is needed that performs the equivalent of my waitJobs: (bench (processJobs 2 (mapcar '((X) (list '* X X)) (range 1 10 1 4 9 16 25 36 49 64 0.006 sec No result for 8 and 9. I didn't completely analyze your code. Just a warning about an error: (de completeJob (Pos) (let (cdar Pos) (let RESULT (caar Pos) (eval (caddar Pos)) ) ) The second line redefines the function 'cdar'. Is that intended? Of course not :-) It should read something like: (bind (cadar Pos) ... Each slot contains (result environment expression), and that line tries to restore the environment of the instant when the command was queued, so that it restores all the bound variables before evaluating the expression. Time to experiment a bit more. Thanks. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Parallel command execution
Hi Alexander, On Jun 2, 2012, at 1:01 PM, Alexander Burger wrote: (task -2000 0# Run once every 2 sec Slots (need 4 free) # QuadCore (map '((Pos) (cond ((== free (car Pos)) # Found a free slot (when (fifo '*Batch) # Any jobs? (set Pos busy) # Yes (later Pos (eval @)) ) ) ((n== busy (car Pos)) # Found a result (msg (car Pos)) # Handle result (ifn (fifo '*Batch) # More jobs? (set Pos free) # No (set Pos busy) # Yes (later Pos (eval @)) ) ) ) ) Slots ) ) OK, if I understood 'task' correctly this runs entirely on the 'main' process (the one that will be accessing the database and queueing the commands). Looks like if the main process is busy in a very CPU-intensive task (no IO at all) it could be missing some chances to launch additional processes, but I guess I can workaround that inserting a (wait 0) at some point in the expensive calculation to give the task a chance to run, right? This is perfect, nice and simple. Thanks, Jorge -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Parallel command execution
Hi again, On May 29, 2012, at 4:40 PM, Alexander Burger wrote: Another option to avoid the fork() would be to have a pool of pre-forked instances reading from a jobs queue or something like that (perhaps taking advantage of an additional database to implement the queue?), but my skills are still lacking on how to implement that. That's also an interesting approach. An important question is: Does this parallel processing of database objects also involve modifications of these objects? If so, the necessary synchronization between the processes will produce additional costs. Yes, I need to update the database with results from the executed commands. So, you suggest limiting the updates to happen only in the main process, right? In that case I would need something like the following to be able to invoke the shell commands and update the database with the results. I don't like it, too convoluted for my taste. Any suggestion on how to improve the performance/style? Perhaps a different approach would be better? Note that *maxProcesses should be set to something like the number of cores and that increasing the length of *L can result in fork() errors in the simple later/wait benchmark. Thanks, Jorge (setq *maxProcesses 2) (setq *idle '(NIL NIL nil)) (setq *batches (make (do *maxProcesses (link *idle (de findPred (Pred L) (seek '((X) (Pred (car X))) L) ) (de completeJob (Pos) (let (cdar Pos) (let RESULT (caar Pos) (eval (caddar Pos)) ) ) (set Pos *idle) Pos ) (de waitJob () (completeJob (wait NIL (findPred 'pair *batches (de waitAll () (wait NIL (not (findPred 'atom *batches))) (map 'completeJob *batches)) (de batch (Cont . Job) (let Pos (waitJob) (set Pos 'busy) (later Pos (list (run Job) (env) Cont) ) ) ) (mapcar '((X) (batch '(msg RESULT) (* X X))) (range 1 10)) (waitAll) (de mycmd () (in '(cc -c ../picolisp/src/main.c -o /dev/null)) T) (setq *L (range 1 50)) (bench (mapcar '(() (batch '(nil RESULT) (mycmd))) *L) (waitAll) ) (bench (prog1 (mapcan '(() (later (cons) (mycmd))) *L) (wait NIL (full @)) ) ) (bench (mapcan '(() (mycmd)) *L)) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Parallel command execution
On May 29, 2012, at 12:30 AM, José Romero wrote: On Mon, 28 May 2012 23:51:21 +0200 Jorge Acereda jacer...@gmail.com wrote: Hi, I need to invoke external commands for each entry in my database and I want to run those in parallel, but restricting the number of simultaneous jobs to a certain number to avoid bringing the machine to its knees (sort of 'make -jN'). How would you approach such problem? First a bit more of information is needed, what do you need to parallelize? The processing steps within each entry, or the processing of the entries themselves? Are there any dependencies that should be taken into account? I'll try to explain better what I'm trying to do. As a learning exercise, I'm implementing a build tool (sort of 'scons'). A target can have explicit dependencies (specified when the target is inserted in the database) or calculated dependencies (in the case of a C target, obtained via 'cc -M', 'mkdep' or something similar). I still don't know how fast will be the stage that determines the build order, so at this stage i'm only worried about being able to run the mkdeps stage and the build stage in parallel. Regards, Jorge Thanks, Jorge Cheers, José -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Parallel command execution
On May 29, 2012, at 9:15 AM, Alexander Burger wrote: (de processCustomers (N . Prg) (let Lst (need N) (iter (tree 'nr '+CuSu) '((This) (let Pos (wait NIL (memq NIL Lst)) (set Pos T) (later Pos (run Prg) NIL ) ) ) ) ) ) Thanks, that looks good. My only objection would be the additional fork() implied by 'later'. I'll try to get it running with that approach and do some benchmarking. Later, I'll try to compare that to a patched version that uses vfork() instead of fork() and see if that makes a difference. Another option to avoid the fork() would be to have a pool of pre-forked instances reading from a jobs queue or something like that (perhaps taking advantage of an additional database to implement the queue?), but my skills are still lacking on how to implement that. I'll worry about that if the fork() time is noticeable. Thanks, Jorge -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Parallel command execution
Hi, I need to invoke external commands for each entry in my database and I want to run those in parallel, but restricting the number of simultaneous jobs to a certain number to avoid bringing the machine to its knees (sort of 'make -jN'). How would you approach such problem? Thanks, Jorge -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Reading from stderr
Hi, I'm trying to figure out how to capture the standard error of a piped process without resorting to forking an additional sh process. Any hint? Thanks in advance, Jorge -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello Jorge Acereda jacer...@gmail.com :-) You are now subscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Unsubscribe
Good bye Jorge Acereda jacer...@brainstorm.es :-( You are now unsubscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
