At 22:37 on 02/06/2002 EST, Jason Gloudon <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2002 at 12:09:22PM -0800, Steve Fink wrote:
>
> > but I think that's because re_backtrack returns a void*. run_native()
> > returns an opcode_t*, which is fine for the regular core_ops.c but
> > gets returned
On Wed, Feb 06, 2002 at 12:09:22PM -0800, Steve Fink wrote:
> but I think that's because re_backtrack returns a void*. run_native()
> returns an opcode_t*, which is fine for the regular core_ops.c but
> gets returned as void** in core_ops_prederef.c. I think the computed
> goto path does a third
Also, reading
http://www.javalobby.org/clr.html
is a good antidote. Admittedly it's a bit Java-centric, but what
do you expect from a place named "javalobby"?
Black pots and kettles aside, they bring up a lot of interesting issues
that we have to think about if we're going to be more langu
On Wednesday 06 February 2002 04:53, Simon Glover wrote:
> 1. What should we do if the array contains strings of more than one type
> and/or encoding? Clearly we need to do some kind of transcoding, but how
> do we decide what to transcode to? I've had a look in strings.pod but it
> doesn't se
Aaron Sherman:
# Ok, so I read Miguel's message:
#
# http://mail.gnome.org/archives/gnome-hackers/2002-February/msg
# 00031.html
#
# I drank the cool-aid and now I find myself thinking... should Perl6
# compile down to its own byte-code or to Mono's CIL? Miguel
# feels this is
# the way to go, and
On Tue, Feb 05, 2002 at 10:06:42PM -0500, Josh Wilmes wrote:
>
> Who understands this? :)
>
> op enternative() {
> goto ADDRESS(( run_native(interpreter, CUR_OPCODE, (opcode_t *)interpreter->c$
> }
>
>
> The "goto ADDRESS()" syntax appears to be broken, but I have no idea how
> to fix it.
Ok, so I read Miguel's message:
http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00031.html
I drank the cool-aid and now I find myself thinking... should Perl6
compile down to its own byte-code or to Mono's CIL? Miguel feels this is
the way to go, and if Mono's bytecode is in fact s
On Wed, 6 Feb 2002, Josh Wilmes wrote:
>
> > # > Probably not: IIRC the standard requires the parts inside
> > # > #if 0/#endif to be tokenizable.
> > Then just delete the stuff. It's just some Perl 5 code I tried to adapt
> > to Parrot but gave up on.
>
> OK. Revised patch:
Thanks, applied
At 8:42 on 02/06/2002 PST, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> Andy Dougherty:
> # On Wed, 6 Feb 2002, Mattia Barbon wrote:
> # > Probably not: IIRC the standard requires the parts inside
> # > #if 0/#endif to be tokenizable.
> #
> # If I recall correctly, some AIX compilers will complain ab
Andy Dougherty:
# On Wed, 6 Feb 2002, Mattia Barbon wrote:
#
# > > "misc.c", line 541: Error:
# > > [ISO 6.1.4]: End of line in string literal.
# > >
# > > Here's a patch. That last one is particularly odd, as it
# is in a #if 0.
# > > I'm leaving it for now, as I think this is a case of th
Andy Dougherty:
> Oh, agreed in general. Specifically, though, is this one of those rare
> occasions?
I don't think so. We always want to treat the bytecode as opcode_t*. Change
it, and if it breaks, we'll find out why and fix *that* instead. :)
--
Actually Perl *can* be a Bondage & Discipline
On Wed, 6 Feb 2002, Simon Cozens wrote:
> Andy Dougherty:
> > Well, I know (at least) two ways to get rid of the warnings. I just don't
> > know which one's right. For example, making the bytecode be type
> > opcode_t* instead of char* gets rid of a lot of them
>
> Generally when I see char* in
On Wed, 6 Feb 2002, Mattia Barbon wrote:
> > "misc.c", line 541: Error:
> > [ISO 6.1.4]: End of line in string literal.
> >
> > Here's a patch. That last one is particularly odd, as it is in a #if 0.
> > I'm leaving it for now, as I think this is a case of the compiler being on
> > cra
> "misc.c", line 541: Error:
> [ISO 6.1.4]: End of line in string literal.
>
> Here's a patch. That last one is particularly odd, as it is in a #if 0.
> I'm leaving it for now, as I think this is a case of the compiler being on
> crack.
Probably not: IIRC the standard requires the parts
Melvin --
> I'd like to do a Parrot Trooper t-shirt or something along those
> lines. Maybe some of you guys have some cool theme we could
> use, but I'd like to do it like an award basis so when someone
> did something particularly noteworthy or applaudable (spelling?)
> for the cause we could
On Wed, 6 Feb 2002, Brent Dax wrote:
> Jonathan Stowe:
> # - if(!(targ=Parrot_sprintf_c(interpreter, "%S at %S line
> # %d.\n", targ, interpreter->current_file,
> # interpreter->current_line))) {
> # + if(!(targ=Parrot_sprintf_c(interpreter, (const char
> # *)"%S at %S line %d.\n", targ, inte
On Mon, 4 Feb 2002, Alex Gough wrote:
> On Mon, 4 Feb 2002, Simon Glover wrote:
>
> > Re the former, am I right in thinking that assignment from a PerlArray
> > to a non-PMC register should always be in scalar context; ie that:
> >
> > new P0, PerlArray
> > set S0, P0
> >
> > shou
Jonathan Stowe:
# - if(!(targ=Parrot_sprintf_c(interpreter, "%S at %S line
# %d.\n", targ, interpreter->current_file,
# interpreter->current_line))) {
# + if(!(targ=Parrot_sprintf_c(interpreter, (const char
# *)"%S at %S line %d.\n", targ, interpreter->current_file,
# interpreter->current_
On Tue, 5 Feb 2002, Jonathan Stowe wrote:
> This might spoil someones future plans but doesn't break anything existing
> AFAICT - apart from those pesky ones left in misc.c the only ones left
> should be from generated code which I have a plan for which I will share
> later :)
>
This is the same
19 matches
Mail list logo
