Re: OpenGl.l and Segmentation fault

2012-11-09 Thread Jon Kleiser
Hi all, This is how it was done in simul/gl/glut.c, which worked with (32-bit) picoLisp-2.3.5: // (glut:BitmapCharacter 'fontNum 'character) - T any BitmapCharacter(any ex) { void* font; int fontNum; int character; fontNum = (int)evCnt(ex, cdr(ex)); character =

Announce: PicoLisp 64-bit Emulator

2012-11-09 Thread Alexander Burger
Hi all, this is now the Announcement of the PicoLisp 64-bit Emulator. A little bit late, as we've already discussed about it here in this list. It emulates the PicoLisp machine as a Large Instruction Set Computer (LISC -- as opposed to RISC, Reduced Instruction Set Computer)). It is similar to

Re: Macros

2012-11-09 Thread Alexander Burger
Hi Axel, I suppose you mean that you want to arrange syntax in a complex manner, then evaluate it and you are concerned about the cost of rearranging every time the function/macro is called. Suppose also that this rearranging can be done as soon as you know the code inside the macro form, in

Re: OpenGl.l and Segmentation fault

2012-11-09 Thread Alexander Burger
Hi Jon, This is how it was done in simul/gl/glut.c, which worked with (32-bit) picoLisp-2.3.5: ... void* font = GLUT_STROKE_ROMAN; ... int character; ... glutStrokeCharacter(font, character); Yes. The only difference is that glutStrokeCharacter() expects a pointer and an

Re: Token read

2012-11-09 Thread Jakob Eriksson
On November 9, 2012 at 6:13 PM Alexander Burger a...@software-lab.de wrote: [read changes] Any objections? On the contrary! Not that I am a daily PicoLisp user these days, but I remember stumbling over that once and being confused. The proposed behavior is better. best regards, Jakob --