Looking more at exceptions here... I
used to be able to put arbitrary
stuff in the _message slot of a
ParrotException... Now we can only use
strings. Is that permanent?
PythonException will need to be able
to hold an arbitrary python object.
I'm faking it by stuffing my PMC into
a string regis
Is it possible to print out the line number
of the bad instruction when parrot encounters
an error and fails? I'm trying to get my
generated code to work with the latest version
of pirate and I'm having to rely on "GOT THIS FAR"
print statements to find the lines that are
giving me errors.
I
On Wed, 3 Dec 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
>
> >>Create an Exception class hierarchy?
>
> > I'm not 100% sure I want to go with a real OO style of exceptions,
> > but that might just be the neo-luddit
Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Sent: Wednesday, December 03, 2003 12:05 PM
>> The bug is already fixed. But we have to separate interpreter globals
>> and real globals finally. Some time ago, I suggested to change the init
>> functions sl
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
>>Create an Exception class hierarchy?
> I'm not 100% sure I want to go with a real OO style of exceptions,
> but that might just be the neo-luddite in me.
It probably depends what HLL want to have. Anywa
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 12:05 PM
> The bug is already fixed. But we have to separate interpreter globals
> and real globals finally. Some time ago, I suggested to change the init
> functions slightly to take a parent interpreter argument:
Do
From: "Dan Sugalski" <[EMAIL PROTECTED]>
Sent: Tuesday, December 02, 2003 5:27 PM
> Well, bah. I'll disable the table freeing for now and that should
> take care of the bug at the moment, though it certainly won't cure
> the underlying memory leak.
>
> Arguably, and this is getting into the rea
Have a look at the following code fragment
Parrot_PackFile pf;
char *bc = "file.pbc";
pf = Parrot_readbc(interpreter, bc);
Parrot_loadbc(interpreter, pf);
Did you catch the difference between the 2nd actual parameter and
the function name? Maybe it's worth renaming? E.g. Parrot_loadpf()
0x4C56
At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The code definitely needs some looking at and cleanup. It's not
perfect and I expect it's flawed in a number of places. I'm just
happy to get the damn stuff into the repository so the bytecode tests
can s
> I don't think there was ever a consensus about opcode naming.
> It seems that we need this but can you give an example
> of where you are using it, just to give me some context to think
> with?
I've been implementing a Lisp interpretter (and hopefully at some point,
compiler) and was using the
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: "Jonathan Worthington" <[EMAIL PROTECTED]>
Cc: "P6I" <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 4:34 PM
Subject: Re: [CVS ci] pmc compiler 2nd edition
> Jonathan Worthington wrote:
>
> > Hope bug reports ar
I don't think there was ever a consensus about opcode naming.
It seems that we need this but can you give an example
of where you are using it, just to give me some context to think
with?
-Melvin
Cory Spencer <[EMAIL PROTECTED]>
12/03/2003 11:18 AM
To: [EMAIL PROTECTED]
We should have 1 recommended way for testing NULL registers.
If we support get_bool() then lets make sure it works for REAL NULL
pmc registers as well as PMCNULL.
If not, code will appear to work correctly on a "safe" core
but will seg fault on some other. Also, I see no reason not
to use PMCNUL
Jonathan Worthington wrote:
Hope bug reports are welcome too. :-) On Win32:-
Always.
perl -e "print @ARGV" *.*
*.*
Dumb "operating" system :)
C:\Perl\bin\perl.exe pmc2c2.pl --dump *.pmc
Can't read '*.pmc' at pmc2c2.pl line 253.
I've inserted this before 253:
# help these dumb 'shells' t
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm curently playing around with open calls returning a PMCNULL
> instead of a half valid IO-Object. But the main problem with that is
> that there is currently no way for the byte-code to detect such a
> case.
C tests for PMCNULL too and is usa
> We're already using 'eq' to perform equality testing, and in the interests
> of maintaining a consistent design I would choose to stick with something
> eq-related as opposed to changing it to 'same'.
>
> eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
So just to follow up on this thread,
> I've put in a really long pending patch. The upcoming vtable changes are
> simplified a lot, as e.g. null.pmc is fully generated now.
> Currently line numbers in generated .c files are wrong and disabled.
> Fixes welcome.
Hope bug reports are welcome too. :-) On Win32:-
> perl -e "print @ARG
Hi,
Configure fails on the "Determining some sizes" stage. This is because the
test.c that is generated contains the following:-
printf("\thugeintvalsize => %d,\n", sizeof(long long));
Putting long long is illegal in cl. It appears to me that hugeintvalsize is
looked for by some later code in
Melvin Smith <[EMAIL PROTECTED]> writes:
[...]
> My intention for PMCNULL was to catch invalid interpreter state, or
> invalid bytecode; cases which used to give us core dumps.
>
> Explicitly returning PMCNULL and allowing tests on PMCNULL may
> or may not fit into this, depending on your point
Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 11:10 AM 12/3/2003 +0100, Leopold Toetsch wrote:
>>I've put in a really long pending patch. The upcoming vtable changes are
>>simplified a lot, as e.g. null.pmc is fully generated now.
>>Currently line numbers in generated .c files are wrong and disabled
At 03:46 PM 12/3/2003 +0100, Juergen Boemmels wrote:
I'm curently playing around with open calls returning a PMCNULL
instead of a half valid IO-Object. But the main problem with that is
that there is currently no way for the byte-code to detect such a
case.
The if and unless ops call the get_boolea
At 10:37 AM 12/3/2003 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> 1) Currently typenames are not checked except with 'new '
As Dan layed out WRT PMC enums, we might have to defer type checking to
runtime. That is for core PMCs we do strict type checking, other types
ge
Hi,
I'm curently playing around with open calls returning a PMCNULL
instead of a half valid IO-Object. But the main problem with that is
that there is currently no way for the byte-code to detect such a
case.
The if and unless ops call the get_boolean vtable method which throws
an internal excepti
At 03:01 PM 12/3/2003 +0100, Leopold Toetsch wrote:
Pete Lomax <[EMAIL PROTECTED]> wrote:
> The following demonstrates that $I1 and .local int i map to the same
> register in the output pasm code:
Yep. The problem seems to be the backward branch. When you put the
"test" sub after the "end" op, its
At 11:10 AM 12/3/2003 +0100, Leopold Toetsch wrote:
I've put in a really long pending patch. The upcoming vtable changes are
simplified a lot, as e.g. null.pmc is fully generated now.
Currently line numbers in generated .c files are wrong and disabled. Fixes
welcome.
I think we still have 2 versi
David Chan <[EMAIL PROTECTED]> wrote:
> Hi,
> IMCC appears to choke on comments after "setline", especially if they
> contain digits.
Thanks for reporting that - and sorry for the late answer.
I've fixed the lexer.
> David
leo
--
Leopold Toetsch <[EMAIL PROTECTED]> http://www.toetsch.at/linux
Pete Lomax <[EMAIL PROTECTED]> wrote:
> The following demonstrates that $I1 and .local int i map to the same
> register in the output pasm code:
Yep. The problem seems to be the backward branch. When you put the
"test" sub after the "end" op, its working fine.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>This is 3 times faster and saves ~1000 DOD runs.
> Wow.
> Okay. Go for it.
Done.
CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms
- --- -- --
743 findclass_i_sc1000.478843
The following demonstrates that $I1 and .local int i map to the same
register in the output pasm code:
.sub _main
goto L1
test:
$I1 = 1
ret
L1:
.local int i
i = 2
call test
print i # prints 1, not 2
end
.end
parrot -o - t.imc shows:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The code definitely needs some looking at and cleanup. It's not
> perfect and I expect it's flawed in a number of places. I'm just
> happy to get the damn stuff into the repository so the bytecode tests
> can start.
I've put in a first test. Needed some c
Hey,
I'm right now looking at getting a proper implementation of array/string
offsets done for the PHP compiler.
Here's the problem, in PHP you can access indices of both string's an
array's in the same way, meaning:
Is just as valid as:
To have this available easily using Perl's types, get
I've put in a really long pending patch. The upcoming vtable changes are
simplified a lot, as e.g. null.pmc is fully generated now.
Currently line numbers in generated .c files are wrong and disabled.
Fixes welcome.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Well, bah. I'll disable the table freeing for now and that should
> take care of the bug at the moment, though it certainly won't cure
> the underlying memory leak.
The bug is already fixed. But we have to separate interpreter globals
and real globals fin
Melvin Smith <[EMAIL PROTECTED]> wrote:
> 1) Currently typenames are not checked except with 'new '
As Dan layed out WRT PMC enums, we might have to defer type checking to
runtime. That is for core PMCs we do strict type checking, other types
get resolved at runtime.
> C<.local identifier>
34 matches
Mail list logo
