Arthur Bergman wrote:
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
follow the scheme used in
t/src/basic_3, i.e. run your code via Parrot_run_native().
Tried this, I think the interface to Parrot_run_native() is wrong, it
should most likely be
void* Parrot_run_native(Parrot, func, void*) ;
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
follow the scheme used in
t/src/basic_3, i.e. run your code via Parrot_run_native().
Tried this, I think the interface to Parrot_run_native() is wrong, it
should most likely be
void* Parrot_run_native(Parrot, func, void*) ;
so you can pass in arg
At 10:35 AM + 3/3/04, Arthur Bergman wrote:
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
I wasn't aware that the Parrot DOD/GC would run even if I wasn't
running any parrot bytecode, so when we started executing larger
amounts of perl code, things got ugly because parrot was GCing from
und
Arthur Bergman wrote:
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
Do you initialize interpreter->lo_var_ptr? If you aren't entering any
runloop and this pointer isn't set, you will still have DOD bugs,
because the processor stack will not be marked properly.
You can set this pointer to the add
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
I wasn't aware that the Parrot DOD/GC would run even if I wasn't
running any parrot bytecode, so when we started executing larger
amounts of perl code, things got ugly because parrot was GCing from
under our feet!
Do you initialize interpreter->lo_v
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> So today we managed to solve the problem.
> I wasn't aware that the Parrot DOD/GC would run even if I wasn't
> running any parrot bytecode, so when we started executing larger
> amounts of perl code, things got ugly because parrot was GCing from
> under
