Jeff Clites [EMAIL PROTECTED] wrote:
Patch below.
Applied, thanks.
JEff
leo
# New Ticket Created by Jeff Clites
# Please include the string: [perl #26212]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=26212
This patch should allow $cpuarch be set correctly whether
$Config{archname} is
# New Ticket Created by Stephane Peiry
# Please include the string: [perl #26201]
# in the subject line of all future correspondence about this issue.
# URL: 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
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
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
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 disabled
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
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
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
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 that don't cross
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-provided)
- 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.
Turns out it fails
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 don't need
ability to have
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 nasty
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
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
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 register:
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/struct.pod
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
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 PMCs.
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 it fails in
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_logo.imc
22 matches
Mail list logo
