Dino Morelli wrote:
I'm working on more p6rules unit tests.
Having some trouble. First, understanding when :w means \s* and when it
means \s+
Also, these tests are failing when I use :: to separate the modifier
from the pattern. But they work when I do ':w blah' (separate with a
space). I'm not sur
I'm working on more p6rules unit tests.
Having some trouble. First, understanding when :w means \s* and when it
means \s+
Also, these tests are failing when I use :: to separate the modifier
from the pattern. But they work when I do ':w blah' (separate with a
space). I'm not sure which ways are
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 04 May 2005 09:38:41 +0200
Bob Rogers wrote:
>. . . but I can't figure out why. I thought the patch below would
> help, but it appears that the value of c is itself broken somehow.
The memory handling was broken and disas
On Wed, 11 May 2005, Patrick R. Michaud wrote:
>On Wed, May 11, 2005 at 06:16:27PM +0200, Uwe Voelker wrote:
>>
>> Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed
>> to reflect the correct number of tests? I have this patch ready, but I'm
>> too shy to post :-)
>
>Feel free
Leopold Toetsch wrote:
I have now implemented a C opcode and the one used signature for
MD5 as a JIT opcode for x86. But the speedup is much smaller: around 5%.
Thanks!
The problem with md5 code and Parrot JIT seems to be related to the
register allocator. md5 code is one big basic block of inte
On Wed, May 11, 2005 at 06:16:27PM +0200, Uwe Voelker wrote:
> Hello,
>
> I fixed a small typo in PBC_COMPAT.
>
> Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed
> to reflect the correct number of tests? I have this patch ready, but I'm
> too shy to post :-)
Feel free to
That seems reasonable to me. Please do.
Here it is (together with a gentle reminder at the end of the .t file :-)
But feel free to leave this line out.
Uwe
Index: t/p6rules/anchors.t
===
--- t/p6rules/anchors.t (revision 8065)
+++ t/p
# New Ticket Created by jerry gay
# Please include the string: [perl #35413]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35413 >
i'm converting many of the remaining internal_exception() calls to
real_exception() (excep
Tim wrote:
Seems like the last major thread on namespace issues, especially
inter-language issues, was around October last year and didn't reach
any firm conclusions.
What's the current status?
Pretty much the same. There is now an additional namespace
"__parrot_core", where MMD subroutines are ga
I've now changed the class attribute code, so that short attribute names
work too. The short names are stored in the same hash as the qualified
names. The hash is rebuilt in reverse MRO order so that a subclassed
short name invalidates a parent's short name. This attribute is still
available wi
> this simple patch removes a build warning in io\io_win32.c:
> io\io_win32.c(272) : warning C4550: expression evaluates to a function
> which is missing an argument list
The patch is applied.
This warning surfaces only because I had inadvertedly enabled
PARROT_NET_DEVEL in io/io_private.h in SV
chromatic schrieb:
On Wed, 2005-05-11 at 18:16 +0200, Uwe Voelker wrote:
I fixed a small typo in PBC_COMPAT.
Thanks, applied.
From reading PBC_COMPAT I gathered that PBC_COMPAT should only be
changed, when the PBC syntax has changed.
# The text in this file is also the base of the
# fi
On Wed, 2005-05-11 at 18:16 +0200, Uwe Voelker wrote:
> I fixed a small typo in PBC_COMPAT.
Thanks, applied.
> Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed
> to reflect the correct number of tests? I have this patch ready, but I'm
> too shy to post :-)
That seems rea
# New Ticket Created by jerry gay
# Please include the string: [perl #35412]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35412 >
this simple patch removes a build warning in io\io_win32.c:
io\io_win32.c(272) : warning C
Hello,
I fixed a small typo in PBC_COMPAT.
Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed
to reflect the correct number of tests? I have this patch ready, but I'm
too shy to post :-)
Bye,
Uwe
Index: PBC_COMPAT
==
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
>
> Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
As Decreed on perl6-language, henceforth PGE shall be using
$0, $1, $2, ... for subpattern captures and aliases into the
match object's array.
Thus It has been M
Seems like the last major thread on namespace issues, especially
inter-language issues, was around October last year and didn't reach
any firm conclusions.
What's the current status?
Tim.
all is good in r8061.
seems i had forgotton to flush during internal_exception in my working
copy, so i still had test failures. leo's applied your patch and added
the interpreter flushes as well, so i can revert my changes back to
HEAD.
thanks.
~jerry
On 5/10/05, François PERRAD <[EMAIL PROTEC
Patrick R. Michaud wrote:
On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote:
So the right thing for the logical functions seems to be, to just return
the left or right side according to their boolean value (or return a new
Boolean false in case of xor), i.e. you get a reference to o
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #35410]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35410 >
The attached patch modifies find_cclass and find_not_cclass
to return the length
On Wed, May 11, 2005 at 09:19:50AM +0200, Leopold Toetsch wrote:
> We should just have:
> x = getattribute o, "x"
> and the set equivalent:
> setattribute o, "x", x
I would much prefer this. I don't have much problem with
grabbing and using the offsets, but at the moment they're
really only
On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote:
>
> So the right thing for the logical functions seems to be, to just return
> the left or right side according to their boolean value (or return a new
> Boolean false in case of xor), i.e. you get a reference to one of the
> PMCs
Jerry Gay <[EMAIL PROTECTED]> wrote:
> the new *_config$(O) files are not cleaned up during make
> clean/realclean... until now. 'svn status' reports these files have
> been removed after 'make clean'
Thanks, applied.
leo
FranÃois PERRAD (via RT) wrote:
After building different revision of Parrot without 'make clean',
Just don't do that in the same directory.
The following patch (quick & dirty) delete all .pbc after linking parrot.
Not the best idea. Think: Dan's big subs, which compile for 6 hours. And
the funtio
# New Ticket Created by FranÃois PERRAD
# Please include the string: [perl #35405]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35405 >
This transaction appears to have no content
After building different revision of Par
On Tue, May 10, 2005 at 10:22:35PM +0200, Jens Rieks wrote:
> On Tuesday 10 May 2005 20:29, Patrick R. Michaud wrote:
> > This is *excellent*.
> >
> > However, now that I look at things, I'm wondering if a slight
> > change to the specification would be in order -- in my original
> > post I said th
On Wed, May 11, 2005 at 09:19:50AM +0200, Leopold Toetsch wrote:
> 2) named access
>
> x = getattribute o, "Point\0x"
>
> This needs a full qualified attribute name "Class" ~ NUL ~ "Attribute".
> That's unusable for at least Python and probably more HLLs as the
> compiler has to know in which c
On Tue, May 10, 2005 at 01:13:48PM -0400, Jeff Horwitz wrote:
> as part of both the pugs and mod_parrot effort, i've started working on
> bringing the embedding and extending interfaces into the modern parrot
> era. i'd like to start by adding public APIs (Parrot_*) where necessary
> and adding mi
The logical MMD functions currently try to set a passed in destination
PMCs value via assign, or they return a clone of themselves.
This is verly likely wrong: not all PMCs have to implement assign:
: That's why the destination controls assignment.
Additionaly we can't assign to singletons or r/o
Jens Rieks wrote:
IMO, we should deprecate the old find_* ops.
It's a lot of (more or less) duplicate code, and not easy to maintain.
Yep, as well as the old is_foo opcodes and interfaces.
jens
leo
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> +++ trunk/compilers/pge/PGE/Hs.pirTue May 10 07:10:43 2005
That's the synopsis:
>@@ -8,7 +8,7 @@
> load_bytecode "PGE.pbc"
why don't you here just the same?
> .sub "__onload" @LOAD
> +.local pmc load
> +load = find_global "PG
On Wednesday 11 May 2005 04:30, Patrick R. Michaud wrote:
> ...well, in looking at it some more it's reasonable until I see
> that returning -1 is the way the other find_* ops work. So,
> part of me thinks we should either be consistent with those, or
> make the others consistent with the interpre
Autrijus Tang <[EMAIL PROTECTED]> wrote:
> class Point {
> has $.x;
> has $.y;
The progress pugs makes is really impressive.
[ ... ]
> Pugs's Parrot codegen backend needs to be updated
Object attribute access, yeah. IMHO Parrot's current implementation is
wrong.
0) class const
33 matches
Mail list logo
