In the interests of brevity, I cut huge tracts of quoted text.
On Mon, 6 May 2002, Brent Dax wrote:
> (FYI, I'm the main author of Parrot's rx package.)
>
I'm pleased to meet you.
> Mark Kvale:
> # Warning: this is a long message, a small paper really. The
> # So creating (A) or (B) wil
(FYI, I'm the main author of Parrot's rx package.)
Mark Kvale:
# Warning: this is a long message, a small paper really. The
# synopsis is that I have created a simple regex compiler with
# multiple backends to test proposed regex coding schemes.
# Details and test results are below.
#
# Hi al
Warning: this is a long message, a small paper really. The synopsis is
that I have created a simple regex compiler with multiple backends to
test proposed regex coding schemes. Details and test results are
below.
Hi all,
One of the upcoming decisions that needs to be made is on the design
of th
The broken 64bit systems seem to be related to compiling
Parrot with a different wordsize than Perl5, since I'm currently
getting byteorder from Perl5 Config.pm.
I guess we will have to compute it ourselves after Parrot
has picked what type to use for INTVAL/opcode_t
-Melvin
On Mon, 6 May 2002, Melvin Smith wrote:
> At 01:44 PM 5/6/2002 -0400, you wrote:
> >When I try to build parrot with gcc, I get 754 warnings. Obviously I
> >won't post them all here, but some typical ones are:
>
> I'm working on some of them. I saw quite a few issues while
> reworking the byte
At 01:44 PM 5/6/2002 -0400, you wrote:
>When I try to build parrot with gcc, I get 754 warnings. Obviously I
>won't post them all here, but some typical ones are:
Firstly I just did a big patch to make the bytecode portable, so thats
the reason you are seeing packfile issues, however they aren't
I haven't been following Parrot lately, but I just checked out the current
version to see how well it gets along with my current perl-5.7.3. My
perl is compiled with IV='long long', which means Parrot will default
to using 'long long' as INTVAL. (I suspect this is likely to be a
reasonably commo
On Sat, 4 May 2002, Brent Dax wrote:
> Melvin Smith:
> # I have a patch almost complete that makes Parrot handle
> # bytecode files across platforms (does endian and wordsize
> # transform), but there is one glaring non-portability, and
> # that is that we are storing floating point constants
Although the tidying up of resources.c is not complete yet, I decided to
implement COW strings anyway.
This implementation handles the following:
Copied strings and substrings are COWed instead of copied (i.e. new string
header only); this applies to normal and constant strings.
Functions that al
