Good bye Jorge Acereda <jacer...@gmail.com> :-(
You are now unsubscribed
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
, 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
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
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
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
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
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:
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
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
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.
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
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
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
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
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
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
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
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
...
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
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.
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 )
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?
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
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
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) #
] 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
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,
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
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
/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
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,
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
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
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
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
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
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
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
Hello Jorge Acereda jacer...@gmail.com :-)
You are now subscribed
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Good bye Jorge Acereda jacer...@brainstorm.es :-(
You are now unsubscribed
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
41 matches
Mail list logo
