Am Sonntag, 24. September 2006 03:43 schrieb Bob Rogers:
>The attached patch creates a C in C for
> the exclusive use of the C ops. herwise. Is that right?
Separating stacks is a good thing, as code paths are simplified.
Q: do we really want or need a return stack per context?
bsr/ret ough
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 24 Sep 2006 13:16:08 +0200
Am Sonntag, 24. September 2006 03:43 schrieb Bob Rogers:
>The attached patch creates a C in C for
> the exclusive use of the C ops. herwise. Is that right?
Separating stacks is a good thing, as
Hi folks,
I've started hacking postgres.pir and related stuff. Some remarkable notes:
* there's a test now (or the beginnings of it):
$ ./parrot t/library/pg.t
(the old code didn't even load_bytecode)
The test assumes, there's a user's default table.
* I've removed the 'PostgreSQL::' pref
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 24 Sep 2006 20:55:51 +0200
Hi folks,
I've started hacking postgres.pir and related stuff. Some remarkable notes:
* there's a test now (or the beginnings of it):
$ ./parrot t/library/pg.t
(the old code didn't even load_
On 9/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 14. September 2006 02:54 schrieb Karl Forner:
> Hello,
>
> So I propose a new implementation that solve the bugs, and that is
linear
> in space and time, and hopefully produce
> an optimal list of moves. It is to be found in t
