On Fri, Mar 28, 2008 at 2:20 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 10:33:54PM +0100, Klaas-Jan Stol wrote:
> > On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
> wrote:
> > > On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wro
On Fri, Mar 28, 2008 at 10:51:16AM +0100, Klaas-Jan Stol wrote:
> Attached is a patch implementing:
>
> * ++ and -- postfix operators, implemented as n_sub and n_add (taking
> "1" as the 3rd operand), this is because each instruction must have an
> output register as far as I can tell (so "inc"/"d
On Fri, Mar 28, 2008 at 07:41:25AM -0500, Patrick R. Michaud wrote:
> Ideally += should be implemented as the two-argument 'add' opcode
> in PIR... something like
>
> add %0, %1
>
> But the PAST compiler doesn't yet have a great way for distinguishing
> a 2-argument add from a 3-argument add.
On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 10:51:16AM +0100, Klaas-Jan Stol wrote:
> > Attached is a patch implementing:
> >
> > * ++ and -- postfix operators, implemented as n_sub and n_add (taking
> > "1" as the 3rd operand), this
On Mon Mar 24 10:53:02 2008, coke wrote:
> This usage now only appears in these files:
>
> t/compilers/pge/p6regex/context.t
> t/compilers/pge/p6regex/01-regex.t
> t/compilers/pge/p6regex/builtins.t
> runtime/parrot/library/PGE/P6Grammar.pir
> runtime/parrot/library/PGE/P6Grammar.pbc
> runtime/par
On Mon Feb 04 21:36:31 2008, coke wrote:
> On Sun Nov 18 10:30:59 2007, bernhard wrote:
> > On Di. 26. Jun. 2007, 02:57:42, ptc wrote:
> >
> > As of r22887 the default policies all succeeded, as I had moved
> > RequireTidyCode to the extra policies.
> >
> > I propose to enable this test after the 0
On Fri, Mar 28, 2008 at 02:41:28PM +0100, Klaas-Jan Stol wrote:
> On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > It really needs to be inc/dec. And not only that, but the output
> > value of postfix ++ and -- needs to be the value _before_ the
> > inc/dec op
thanks for the clarifications;
attached an updated patch including some tests.
I left out += and friends for now.
kjs
On Fri, Mar 28, 2008 at 4:18 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 02:41:28PM +0100, Klaas-Jan Stol wrote:
> > On Fri, Mar 28, 2008 at 1:4
HaloO,
Larry Wall wrote:
As it stands the .() forms are a great way to stack ops after
a term. Together with knowing about the ops on the symbolic unary
level you can easily read expressions from the terms outwards.
I'm not actually parsing expressions. Or as you point out below
with respect t
Author: larry
Date: Fri Mar 28 10:42:39 2008
New Revision: 14528
Modified:
doc/trunk/design/syn/S04.pod
Log:
typo from cognominal++
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(o
# New Ticket Created by James Keenan
# Please include the string: [perl #52196]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52196 >
This ticket will serve as a marker for logging the occurrence of
events where the Parr
# New Ticket Created by James Keenan
# Please include the string: [perl #52198]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52198 >
This is one of a series of tickets reporting issues encountered at a
Parrot/Rakudo bui
Marking ticket as resolved, since it is possible now to have 'value' as
a rule name and not conflict with Match objects.
There can still be conflicts with rules having names such as 'from' or
'to', but I'm pretty sure we can solve that with MMD if we need it. If
there are other conflicts, we can
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #52200]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52200 >
In languages/json/JSON/grammar.pg there's an XXX note starting
around line 29 that
# New Ticket Created by James Keenan
# Please include the string: [perl #52202]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52202 >
This is one of a series of tickets reporting issues encountered at a
Parrot/Rakudo bui
On Friday 28 March 2008 11:06:40 James Keenan wrote:
> An experienced Perl-Win32 developer was able to configure Parrot
> successfully with 'perl Configure.pl' and build it with 'nmake'. All
> Parrot tests passed except those in the 4 named files. See
> attachment for output of 'prove -v'.
Any
# New Ticket Created by James Keenan
# Please include the string: [perl #52206]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52206 >
This is one of a series of tickets reporting issues encountered at a
Parrot/Rakudo build
On Fri Mar 28 11:41:28 2008, [EMAIL PROTECTED] wrote:
>
> Any chance of getting the diagnostic output from the failing tests?
>
Am confused. What diagnostic output beyond 'prove -v' are you referring to?
Once I complete all the postings from this session, I'll be posting
links to the various
On Fri, Mar 28, 2008 at 04:35:42PM +0100, Klaas-Jan Stol wrote:
>
> attached an updated patch including some tests.
Patch applied in r26597. I made a few modifications before
applying:
- Updated the precedence of postfix:++ and postfix:-- to match
- Fixed the relational ops to use e.g., infix:
On Friday 28 March 2008 11:55:30 James Keenan via RT wrote:
> Am confused. What diagnostic output beyond 'prove -v' are you referring
> to?
For example...
t/op/arithmetics1..26
ok 1 - take the negative of a native integer
ok 2 - take the absolute of a native integer
Ah, I see that all I was sent was the output of 'prove' -- not 'prove -v'.
I'll have to see if the original tester can re-run the tests.
Larry Wall wrote:
On Thu, Mar 27, 2008 at 12:15:52AM +0100, Jonathan Worthington wrote:
That would duplicate the term:sym<*> entry, actually.
D'oh, I completely hadn't spotted that.
I'll probably get rid of the whatever rule entirely and just put '*' into
version.
OK, removed it from Ra
# New Ticket Created by James Keenan
# Please include the string: [perl #52212]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52212 >
This is one of a series of tickets reporting issues encountered at a
Parrot/Rakudo build
HaloO,
just re-reading S03 I saw that it defines the Rat to Int
conversion as truncation. Why not floor semantics like in %?
Actually I would recommend floor semantics whenever an integer
is coerced. With the sole exception of Num propably using
rounding.
Regards, TSa.
--
The Angel of Geometry
# New Ticket Created by James Keenan
# Please include the string: [perl #52214]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52214 >
This is one of a series of tickets reporting issues encountered at a
Parrot/Rakudo build
At 09:46 -0400 3/27/08, Mark J. Reed wrote:
>Is it just me, or is all this talk about precedence and functions vs operators
>vs methods creating a niggling sensation in anyone else's head? It feels like
>we're in the vicinity of another one of them Big Simplifying Idea things.
>Unfortunately, I
I think nearest makes more sense. People will be really surprised when
/1 turns into 0.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
>
> just re-reading S03 I
TSa wrote:
> just re-reading S03 I saw that it defines the Rat to Int
> conversion as truncation. Why not floor semantics like in %?
> Actually I would recommend floor semantics whenever an integer
> is coerced. With the sole exception of Num propably using
> rounding.
If the difference matters t
The choice of floor vs ceiling is essentially arbitrary, as long as
its consistent; using truncation or rounding is mathematically
unsound. Most implementations use floor, though.
So in general I would expect these to hold:
x div y = floor(x/y)
x mod y = x - y * floor(x/y)
Most importantly, thi
On Fri, Mar 28, 2008 at 3:47 PM, <[EMAIL PROTECTED]> wrote:
> I think nearest makes more sense. People will be really surprised when
> /1 turns into 0.
They shouldn't be, if they're asking for an integer specifically.
That's what happens now in Perl 5...
If you have a rational
On Fri Mar 28 11:11:41 2008, pmichaud wrote:
> In languages/json/JSON/grammar.pg there's an XXX note starting
> around line 29 that reads
>
> # XXX This should be called 'value', but...
> # RT#40069: [PGE] "value" can't be used as a rule name.
>
> token thing {
> ...
>
> PGE
On Monday 21 January 2008 02:12:36 Klaas-Jan Stol wrote:
> Not sure, but I don't think all '.const .Sub foo = "foo" ' is gone
> already
>
> before we rip out the dot stuff from IMCC, these should be rephrased.
Here's a patch to remove the dot stuff from IMCC.
Note that the parrot binary bu
On Fri, Mar 28, 2008 at 9:30 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 28 March 2008 13:20:56 chromatic wrote:
>
> > Here's a patch to remove the dot stuff from IMCC.
> >
> > Note that the parrot binary builds, but not everything else in 'make' does.
> > It's finding errors for sure.
First, kudos and compliments to Klaas-Jan Stol on the excellent
PCT tutorial. I have some comments; the minor ones (typos, etc.)
I'll send off-list, but others may merit some discussion and
PCT implementation changes so I'll put them here.
This message has to do with scope handling of variables i
On Sat, Mar 29, 2008 at 01:04:22AM -0500, Patrick R. Michaud wrote:
> This message has to do with scope handling of variables in Episode 6
> of the tutorial (the 'identifier' method for Squaak). The tutorial
> points out an area where PCT doesn't yet work the way I had
> envisioned and solicits op
35 matches
Mail list logo
