Erps, macro.t had a slight bug. The included version of macro.t fixes it.
--Jeff
<[EMAIL PROTECTED]>
#! perl -w
use Parrot::Test tests => 7;
output_is( <<'CODE', <
The following patch fixes the following bugs with macros:
1) Macros with zero parameters were disallowed
2) Local branches inside macros were not being given unique names on a
per-invocation basis. This made it impossible to write the following
code:
--- cut here ---
answer macro R
eq R,42,$
Hi Brent,
>
> It just means you have to be more explicit. I consider that a Good
> Thing--Perl 5's regular expressions are compact enough to be represented
> like: but the internals to support them are an absolute jungle. I'd rather
> have a few exposed ops than have a chunk of code like Perl 5
On Sun, 11 Nov 2001, Alex Gough wrote:
(but not quite enough...)
> On Sat, 10 Nov 2001, Jeff wrote:
>
> > string.pasm patches the operators mentioned
> > The other file, 'parrot.pasm', is a miniature Parrot compiler, written
> > in Parrot.
> >
> > The patches in the string.diff file are requir
On Sat, 10 Nov 2001, Jeff wrote:
> string.pasm patches the operators mentioned
> The other file, 'parrot.pasm', is a miniature Parrot compiler, written
> in Parrot.
>
> The patches in the string.diff file are required to make this work.
ook, cool, but string_length returns an INTVAL, not an int
string.pasm patches the operators mentioned
The other file, 'parrot.pasm', is a miniature Parrot compiler, written
in Parrot.
The patches in the string.diff file are required to make this work.
It's currently -very- limited, due to some issues that I found with
macro processing and some problems
At 07:13 PM 11/8/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > [native code regexps] There's a hugely good case for JITting.
>
>Yes, for JITing the regexp engine. That looks like a much easier
>problem to solve than JITing all of Parrot.
The problem there's no different than for the rest of
You may think that this is a silly patch, but it's real.
mops.pasm uses a very simple loop to figure out how many operations a
second parrot can go. However, the loop it uses is inefficient: it
does a "branch" *and* an "eq" every time around. Real code shouldn't
do this: I try and explain this at
At 01:39 PM 11/9/2001 -0800, Brent Dax wrote:
>Dan Sugalski:
># At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
># >3. We've adopted a register machine architecture to
># >reduce push/pop stack traffic. Register save/load
># >traffic is similar, but not nearly as bad.
># >
># >Do we want t
