As discussed in the last IMCC RFC, I've committed a few of the changes.
IMCC will now generate an error if the register type is unknown
rather than just assign it a PMC register.
P reg types are pmc, object, or a valid classname. Use pmc or
object for "generic" P register to defer type checking.
I
Paul Hodges writes:
> Luke Palmer:
> > Something likely more like:
> >
> > my role property_wrap[Property [EMAIL PROTECTED] {
> > method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> > }
> > @bar but= property_wrap[false, foo];
>
> ...square brackets?
> ...r
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hodges, Paul writes:
> > How about
> >
> > use Baz; # assume object type
> > my property foo;
> > my @bar of Baz is false but foo; # maybe not what you meant?
>
> Definitely not what you meant. Fortunately, the compiler will teach
> you a thing
On Thu, Dec 04, 2003 at 11:30:47PM +, Fergal Daly wrote:
> I'm not sure about that 25%. Say the pmip calibrator doesn't fit in the CPU
> cache on any machine, then if the tested algorithm fits in the CPU cache on
> one machine but not on another then there will be a huge difference in the
>
Hodges, Paul writes:
> How about
>
> use Baz; # assume object type
> my property foo;
> my @bar of Baz is false but foo; # maybe not what you meant?
Definitely not what you meant. Fortunately, the compiler will teach you
a thing or two about it: C is not a trait.
But indeed foo would a
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
If you apply a trait like false to an array, I expect it to apply to the
"array instance object" itself and not the content, so that
push @bar, Baz.new();
if @bar{
* Michael G Schwern <[EMAIL PROTECTED]> [2003-12-04T16:51:03]
> On Thu, Dec 04, 2003 at 05:26:07AM -0500, [EMAIL PROTECTED] wrote:
> > I'd say a lot of the trouble comes from the fact that you're using the
> > automated test framework for something that isn't an automated test.
>
> But it could be
On Thursday 04 December 2003 22:51, Michael G Schwern wrote:
> Calibration would be pretty straight forward. Just have a handful of
> loops to run known snippets of Perl and calibrate the pmip based on how long
> they take to run. This would change from Perl version to Perl version
> and platform
On Thu, Dec 04, 2003 at 10:33:14PM +, Fergal Daly wrote:
> > Another useful sort of test would be "make sure this function runs in less
> > than N perlmips time" where a perlmip is some unit of CPU time calibrated
> > relative to the current hardware. So a pmip on machine A would be
> > roughl
On Thursday 04 December 2003 21:51, Michael G Schwern wrote:
> But it could be. It would be nice to have a test like "make sure the
> hand optimized version is faster than the unoptimized version" or "make sure
> the XS version is faster than the Perl version".
Yeah - this would probably be usefu
On Thu, Dec 04, 2003 at 05:26:07AM -0500, [EMAIL PROTECTED] wrote:
> I'd say a lot of the trouble comes from the fact that you're using the
> automated test framework for something that isn't an automated test.
But it could be. It would be nice to have a test like "make sure the
hand optimized ve
On Dec 2, 2003, at 8:49 PM, Melvin Smith wrote:
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
On Dec-02, Melvin Smith wrote:
Do you really want to generate the extra unused code at the end of all
the subroutines? I don't think you want to autodetect whether the code
is guaranteed to return.
Good
On Dec 3, 2003, at 12:03 PM, Dan Sugalski wrote:
At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) Exceptions we're happy with
Create an Exception class hierarchy?
I'm not 100% sure I want to go with a real OO style of exceptions, but
that might jus
Thies C . Arntzen <[EMAIL PROTECTED]> wrote:
> Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:
>> Can you use native STRINGs for that?
> sure, if we only knew the type of the variable we're accessing:
> function dump0($a)
> {
> echo printf("%s\n",$a[0]);
> }
> dump0("hallo"); // called with a
Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:
Sterling Hughes <[EMAIL PROTECTED]> wrote:
Should PerlString support a get_pmc_keyed() method (according to Perl
5/6 semantics), or is this a point where its about time to start
implementing our own PMCs?
get_pmc_keyed() seems a bit heavy to handle
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> Should PerlString support a get_pmc_keyed() method (according to Perl
> 5/6 semantics), or is this a point where its about time to start
> implementing our own PMCs?
get_pmc_keyed() seems a bit heavy to handle single chars in a
PerlString (Each char wo
Michal Wallace <[EMAIL PROTECTED]> wrote:
> 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?
Depends on what exceptions finally are. But the standard entries like
"_mess
I'd say a lot of the trouble comes from the fact that you're using the
automated test framework for something that isn't an automated test.
You'll probably find that easiest thing to do is stick something like this
in your Makefile.PL
sub MY::postamble {
return << 'EOM';
bench: pure_all
On Tuesday, December 2, 2003, at 11:49 , Melvin Smith wrote:
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
Do you really want to generate the extra unused code at the end of all
the subroutines? I don't think you want to autodetect whether the code
is guaranteed to return.
Good point. Its easy
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> I think the 'imclexer.c' is generated from 'imcc.l' during maintainance. So
> I made the patch in both files.
Just for imcc.l is enough.
Thanks, applied.
leo
Michal Wallace <[EMAIL PROTECTED]> wrote:
> What is the _return_cc attribute on an
> exception? Can I use it to resume the
> code as if the exception never happened?
When an exception is resumable, you can return by invoking this return
continuation. But details (i.e. is C<_return_cc> put into P1
Michal Wallace <[EMAIL PROTECTED]> wrote:
> Is it possible to print out the line number
> of the bad instruction when parrot encounters
> an error and fails?
Yep. I'll have a look at it.
> I don't suppose there's one magic error routine
> that controls all the error messages, and someone
> could
Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
> 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()
Sounds reasonable. Or Parrot_set_pf().
> 0x4C56
leo
23 matches
Mail list logo
