On Mon, 9 Feb 2004, Melvin Smith wrote:
> At 02:00 PM 2/9/2004 -0500, Michal Wallace wrote:
> >On Mon, 9 Feb 2004, Melvin Smith wrote:
> > > My take on it is, since it is an intermediate language, we don't need
> > > ability to have keywords as variables. Compilers can generate all
> > > variables
On Mon, 2004-02-09 at 13:34, Leopold Toetsch wrote:
> chromatic <[EMAIL PROTECTED]> wrote:
> > Now, I'm seeing an odd error whenever I use the 'loadlib' op, though:
>
> > set_pmc_keyed_str() not implemented in class 'PerlInt'
> Time for an example ;)
I see it on examples/sdl/anim_parrot_log
On Mon, Feb 09, 2004 at 11:57:28AM +0100, Leopold Toetsch wrote:
> Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > Back from unwellness and the subsequent need to catch up with a stack of
> > stuff, I finally found time to sync up my parrot tree and try a Win32 build.
> > Turns out i
Le Mon, Feb 09, 2004 at 09:52:28PM +0100, le valeureux mongueur Leopold Toetsch a dit:
> Stéphane Payrard <[EMAIL PROTECTED]> wrote:
>
> > The implementation of the methods key_* in keys.c imposed
> > to the PMCs to be of type Key. I don't' see the interest
> > for atomic keys that could be mere
Chromatic <[EMAIL PROTECTED]> wrote:
> Now, I'm seeing an odd error whenever I use the 'loadlib' op, though:
> set_pmc_keyed_str() not implemented in class 'PerlInt'
Time for an example ;)
leo
On Sun, 2004-02-08 at 15:06, Leopold Toetsch wrote:
> So you create an initializer for that struct (above layout? - a bad name
> BTW) and *assign* it to the screen:
>
> assign screen, screen_struct_layout
> w = screen["w"] # presumed your struct initializer defines that
>
> s. docs/pmcs/st
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> The implementation of the methods key_* in keys.c imposed
> to the PMCs to be of type Key. I don't' see the interest
> for atomic keys that could be mere PMCs.
> This concretely means that one can write the following and save a
> intermediate registe
The get_*_keyed methods were missing from PerlArray. Inheriting from Array did not
cut it when accessing elements beyond the array end.
The patch adds the missing methods. They really are a cut and paste
from the Array methods. They access the corresponding get_*_keyed_int() methods,
or the get_p
The implementation of the methods key_* in keys.c imposed
to the PMCs to be of type Key. I don't' see the interest
for atomic keys that could be mere PMCs.
This concretely means that one can write the following and save a
intermediate register:
P3 = PO[P1]
instead of:
P3 = new P2, .Key
At 02:00 PM 2/9/2004 -0500, Michal Wallace wrote:
On Mon, 9 Feb 2004, Melvin Smith wrote:
> My take on it is, since it is an intermediate language, we don't need
> ability to have keywords as variables. Compilers can generate all
> variables with names like $T01JHGJ_001
That can make it kind of nas
On Mon, 9 Feb 2004, Melvin Smith wrote:
> At 07:26 PM 2/5/2004 -0500, Will Coleda wrote:
> >Melvin:
> >
> >Here's a warnocked imcc issue for you:
> >int main () {
> >> int if = 1;
> >>
> >> if (if) {
> >> if = 0;
> >> }
> >>}
>
> My take on it is, since it is an intermediate language, we
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > Back from unwellness and the subsequent need to catch up with a stack of
> > stuff, I finally found time to sync up my parrot tree and try a Win32
build.
> > Tur
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:19 PM +0100 1/4/04, Leopold Toetsch wrote:
>>Its a bit complicated and brain-mangling, the more in the absence of
>>any examples, but the current design in pdd16 seems to lack some
>>flexibility and is IMHO missing the proper handling of the
>>(library
Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
>> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
>> Seems that we got a problem on alphas then. I can see several solutions
>> to accomodate such CPUs:
> From my point of view, these solutions have the following merits and
> demerits:
>> - use only PMCs t
Smylers writes:
> > ... It's almost getting to the point where we want to allow
> > disambiguating underscores in operators: >>_+<_<<. Alternately we
> > give up on <<>> as a qw// replacement and allow spaces: >> +< <<.
>
> How about going back to what you originally decreed in Apocalypse 2,
> th
At 07:26 PM 2/5/2004 -0500, Will Coleda wrote:
Melvin:
Here's a warnocked imcc issue for you:
int main () {
int if = 1;
if (if) {
if = 0;
}
}
do you have a patch? I think its a nice to have so If you sourself
provide a nice patch guess it would be applied :)
I thought I replied to this
I keep forgetting about this, but...
If you want to put in a proposal for OSCON 2004, you've got until
midnight today. (Midnight PST, -0800, I think) What you get for them
varies, but any accepted proposal gets at least admission to the
conference. (Tutorial acceptance gets plane fare and some
> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Seems that we got a problem on alphas then. I can see several solutions
> to accomodate such CPUs:
>From my point of view, these solutions have the following merits and
demerits:
> - use only PMCs that don't cross cache lines
+) No need for memory
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> Hi,
> Back from unwellness and the subsequent need to catch up with a stack of
> stuff, I finally found time to sync up my parrot tree and try a Win32 build.
> Turns out it fails in event.c with a whole string of errors and warnings:-
I've now dis
Jeff Clites <[EMAIL PROTECTED]> wrote:
> This patch should allow $cpuarch be set correctly whether
> $Config{archname} is "darwin" or "darwin-thread-multi-2level". (It was
> failing in the former case.)
Thanks, applied.
leo
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> This patch implements the inc_i and dec_i ops (cf. math.ops), for the
> Sun/Sparc JIT core.
Thanks, applied.
leo
Damian Conway writes:
> Larry mused:
>
> > ... I don't think people would be terribly pleased when they see
> > things like:
> >
> > @a »+<<« @b
>
> > [it] would certainly motivate people to move toward editors and
> > terminals that can display:
> >
> > @a »+<<« @b
>
> Yes, it would
# New Ticket Created by Stephane Peiry
# Please include the string: [perl #26201]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=26201 >
This patch implements the inc_i and dec_i ops (cf. math.ops), for the Sun/Sparc
J
Larry Wall writes:
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
>
> : Larry Wall writes:
> :
> : > On the other hand, we've renamed all the other bitwise operators,
> : > so maybe we should rename these too:
> : >
> : > + : > +>
Austin Hastings writes:
> With Larry's new "vectorized sides" suggestion, putting a guillemot on
> the right side of the operator ...
Austin, we've been through this before -- kindly return that guillemot
to wherever you picked it up from. It's hassle enough having unicode in
Perl, without us al
Larry Wall writes:
> On Wed, Jan 21, 2004 at 08:51:33PM -0500, Joe Gottman wrote:
>
> : Great, so
> : $x = foo(), bar();
> : means the same thing as
> : $x = ( foo(), bar() );
>
> No, we haven't changed the relative precedence of assignment and
> comma. I've been tempted to, but I alway
[Apologies for the delay in responding to this (and other) messages -- I
read some of these a couple of weeks ago but didn't want to reply till
I'd read the entire thread, then I was away a bit ...]
Larry Wall writes:
> On the other hand, it's possible that we should extend the visual
> metaphor
# New Ticket Created by Jeff Clites
# Please include the string: [perl #26212]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=26212 >
This patch should allow $cpuarch be set correctly whether
$Config{archname} is "darwi
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Patch below.
Applied, thanks.
> JEff
leo
29 matches
Mail list logo
