Re: OpenGl.l and Segmentation fault
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 = (int)evCnt(ex, cddr(ex));
switch (fontNum) {
// These GLUT_BITMAP values are system dependent.
case 2: font = GLUT_BITMAP_9_BY_15;break;
case 3: font = GLUT_BITMAP_8_BY_13;break;
case 4: font = GLUT_BITMAP_TIMES_ROMAN_10;break;
case 5: font = GLUT_BITMAP_TIMES_ROMAN_24;break;
case 6: font = GLUT_BITMAP_HELVETICA_10;break;
case 7: font = GLUT_BITMAP_HELVETICA_12;break;
case 8: font = GLUT_BITMAP_HELVETICA_18;break;
default: font = GLUT_BITMAP_TIMES_ROMAN_24;break;
}
//printf("BitmapCharacter, font = %10p\n", font);
glutBitmapCharacter(font, character);
return T;
}
// (glut:StrokeCharacter 'mono 'character) -> T
any StrokeCharacter(any ex) {
void* font = GLUT_STROKE_ROMAN;
int mono;
int character;
mono = (int)evCnt(ex, cdr(ex));// correct? - jk
character = (int)evCnt(ex, cddr(ex));
if (mono) font = GLUT_STROKE_MONO_ROMAN;
glutStrokeCharacter(font, character);
return T;
}
.. and this is how it was called in my china.l:
(glut:BitmapCharacter FontNum (char Chr))
I know that parameters in calls to C library functions are done quite
differently nowadays, in pil64.
/Jon
On 11/8/12 9:43 PM, Jorge Acereda wrote:
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
Announce: PicoLisp 64-bit Emulator
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 a byte-code architecture, but each instruction is not
an 8-bit byte, but a 16-bit word. Each word denotes a complete
instruction, without exception, not just an opcode which may require
further operands.
It can be compiled with (see the INSTALL file)
$ (cd src64/; make emu)
and started as always
$ ./pil +
The usual prerequisite of a running PicoLisp system for bootstrapping
must be met (also see the INSTALL file).
It is not perfect. It will currently not compile on 32-bit little-endian
systems. This is due to some inconsistency in the C99 spec about the
handling of "designated initialization" of anonymous structure members.
The speed is lousy. About 10 to 20 times slower than the real thing. So
this is in the same range as other emulators like 'qemu'.
Another drawback is the fixed stack size (currently 1 M entries (8 MB)).
As expected, the implementation of 'native' in plain C posed the biggest
problem. There is no way to pass arguments to a C function generically.
The emulator uses a brute-force approach, by hard-coding combinations of
supported argument types.
Therefore, 'native' supports only up to 8 arguments, the first 6 of
which might be floats or doubles. Also, if the first argument to a
native function is a float or double, then the function's return value
should also be a float or double.
Calls to 'native' with structures in arguments or return values are
naturally non-portable between pil32 and pil64. They will work probably
best on 64-bit platforms.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Macros
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 CL language after definition time but before runtime. > In this case you cannot use Alexander's suggestion of using reader > macros at definition time. Here is a solution: > > (de defmacro "F" >(let (@Name (car "F") >@Fun (cdr "F") >@Arg (pack "X") >@Id (pack "WILL EVAL:") ) > (macro > (de @Name @Arg > (unless (== (car @Arg) @Id) >(con @Arg (apply '@Fun @Arg)) >(set @Arg @Id) ) > (eval (cdr @Arg)) ) ) ) ) > () Nice! Very clever! :) Minor: I would suggest to use 'name' instead of 'pack' to produce the unique transient symbol, as it is cheaper and probably more clear. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: OpenGl.l and Segmentation fault
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 integer, while 'native' will pass two long integers. This shouldn't make any difference, though, especially not on 64-bit systems (where all three types have a size of 64 bits), and not when arguments are passed in registers anyway. Where is the hitch? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Token read
Hi all,
Axel Svensson pointed out in a recent IRC discussion, that the current
implementation of the token-mode of the 'read' function in PicoLisp does
not distinguish between strings and punctuation.
This makes 'read' less useful in certain cases.
Therefore, I propose to change 'read', so that it will return a list of
characters instead of a string (i.e. a list of single-char transient
symbols instead of a multi-char transient symbol).
Thus,
: (make (do 5 (link (read "_"
{"abc"+123}
-> ("{" "abc" "+" 123 "}")
will change to
: (make (do 5 (link (read "_"
{"abc"+123}
-> ("{" ("a" "b" "c") "+" 123 "}")
In addition to now being able to distinguish punctuation like "{" from
strings like ("a" "b" "c"), this has the advantage that these lists of
characters can be directly processed with list functions (without
needing to 'chop' them first).
This change might possibly break existing applications, but I suspect it
is not a heavily used feature ;-)
Any objections?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Token read
On November 9, 2012 at 6:13 PM Alexander Burger 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 -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
