Melvin Smith:
# For those of you not on cvs list:
#
# I committed a rewrite of the find_op() code generator.
# You'll need to re run Configure.
#
# Uses a sorted hash and nets about 40% of the speed of the
# 500k unrolled switch() statement. Feel free to tune it even
# more than I did. Upside i
OK, I've neglected to fix a bunch of mistakes in the embedding system
for a few months. These have now been fixed.
-Parrot becomes Parrot_Interp
-Parrot_String is gone and the string_funcs.h functions are no longer
externally visible.
-A few structures have been renamed.
-config.h has been rearr
Many thanks, this really rocks on my machine with 128MB of RAM :) I think
compiles are about a minute faster now :)
One thing that worries me is the size of the parrot executable, right now it's
about 350k and growing. When compressed with UPX, it's 55k, but still, we should
avoid executable bloa
At 11:12 AM 5/15/2002 +0300, SlowByte wrote:
>Many thanks, this really rocks on my machine with 128MB of RAM :) I think
>compiles are about a minute faster now :)
Thats good to hear.
>One thing that worries me is the size of the parrot executable, right now it's
>about 350k and growing. When com
On Sun, 2002-05-12 at 15:43, Miko O'Sullivan wrote:
> From: "David Whipp" <[EMAIL PROTECTED]>
> > It it too much to ask, of the creator of a tied array, to implement
> > their code in such a way that *reading* an element of that array
> > does not have significant side-effects?
>
> Actually, I th
On Sat, 2002-05-11 at 17:43, Damian Conway wrote:
> Paul Johnson wrote:
>
> > I've always found the word "like" to be very wishy-washy in a computer
> > langauge. In what way is newbaz like baz? And just how alike are they?
> > There must be a better way to describe this.
>
> Perhaps:
>
>
On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
> > Wouldn't those be the same?
>
> Not quite. C<$.bar> is a direct access to the attribute. C<.bar> is a call
> to the accessor. There might well be performance issues.
I would expect that there won't be, but perhaps I'm optimistically
over-hyp
On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote:
> At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote:
> >I was wondering how perl6 would stringify (as in Data::Dumper):
>
> That's not stringification. It's serialization, which is a different
> thing entirely.
>
> What you'll potentially get is
On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
> method world is public_to(Bar) {
Might as well make that:
method world is private(Bar)
I tend to take any opportunity to recycle syntax, plus keywords with
underscores give me gas. ;)
On Tue, 2002-05-14 at 20:13, Larry Wall wrote:
> It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe we'll
> have something like this:
>
> Perl 5Perl 6
> {1,3} <1..3>
> {3} <3>
> {3,} <3+>
> {0,3} <3->
>
> Then again, maybe
At 10:10 AM -0400 5/15/02, Aaron Sherman wrote:
>On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote:
>> At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote:
>> >I was wondering how perl6 would stringify (as in Data::Dumper):
>>
>> That's not stringification. It's serialization, which is a different
At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
>On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
>
>> > Wouldn't those be the same?
>>
>> Not quite. C<$.bar> is a direct access to the attribute. C<.bar> is a call
>> to the accessor. There might well be performance issues.
>
>I would expect th
At 11:15 PM + 5/14/02, Steve Fink (via RT) wrote:
>The most potentially controversial attribute of these hashtables is
>the use of direct memory pointers to and between the buckets. These
>pointers are invalidated every time buffers are compacted, so at the
>beginning of every public entry poi
At 12:51 AM -0700 5/15/02, Brent Dax wrote:
>-Parrot becomes Parrot_Interp
>-Parrot_String is gone and the string_funcs.h functions are no longer
>externally visible.
>-A few structures have been renamed.
>-config.h has been rearranged so that INTVAL, etc. are now aliases for
>Parrot_Int, etc.
>-A
Aaron Sherman writes:
: Hopefully there will be some replacement. I can't count the number of
: times I've relied on things like:
:
: $b = qr/\d{1,3}/;
: if (@ip = ($addr =~ /($b)\.($b)\.($b)\.($b)/)) {
: die "$0: \"$addr\": bad IP\n" if grep {$_>255} @ip;
: print("0x",(map {s
Melvin Smith wrote:
> BUT... for the string_replace internal API it might still be worthwhile
> for performance to add additional semantics so we don't have to
> next stuff for performance.
>
> I'm open to adding a dest_len arg or something, but consider this a
> request for comments on any addit
# New Ticket Created by Steve Fink
# Please include the string: [netlabs #579]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=579 >
This is a patch to the hashtable test suite, but the bug looks like it
might be in stri
Dear all,
I'm trying to print the following string:
\0
I.e. the output of the perl instruction
print "\\0";
See attached test.
It's getting treated as a string terminator.
Am I escaping incorrectly, or is it incorrect treatment of "\0" at some point?
Thanks,
Joe Yates
#! perl
use Parrot::Test tests => 5;
use Test::More;
output_is(<<'CODE', <
Aaron Sherman writes:
: Should a tied and/or lazy array be forced to present a length on demand,
: or can length return undef on indeterminate arrays?
An array implementation can return anything it jolly well pleases, but
I'd say undef would be a reasonable thing to return if the length is
indete
On Wed, 2002-05-15 at 10:36, Dan Sugalski wrote:
> At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
> >On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
> >
> >> > Wouldn't those be the same?
> >>
> >> Not quite. C<$.bar> is a direct access to the attribute. C<.bar> is a call
> >> to the accesso
Steve Fink wrote:
> This is a patch to the hashtable test suite, but the bug looks like it
> might be in string.c:
> a is coming in marked as UTF-32, which seems incorrect (I can view
> a->bufstart as a plain char*, and it has more than one letter in it.)
> b comes in as usascii, which is correct
Does Parrot compile on ICC , if yes is it faster ?
http://www.osnews.com/story.php?news_id=1056
CoyoteGulch.com has published an interesting article, benchmarking GCC 3.04 and ICC 6
(the article will be updated again after GCC 3.1's release). In the tests, ICC seems
to pull ahead in most t
On Wednesday, May 15, 2002, at 10:17 AM, Aaron Sherman wrote:
> On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
>
>> method world is public_to(Bar) {
>
> Might as well make that:
>
> method world is private(Bar)
>
> I tend to take any opportunity to recycle syntax, plus keywords with
The attached patch is the next set of proposed changes to the memory
management routines, with the copy-on-write logic removed.
Performance numbers on my 166-MHz Pentium (linux 2.2.18) for 5000-generation
life.pasm are:
Current CVS - 50.41 generations/second
With this patch - 57.40
With COW & str
(Note: My first attempt at this message bounced from onion.perl.org,
which is why it's going to p6i. Reported to [EMAIL PROTECTED], who's
looking into it.)
==
Seems to be cross-x86, if not global.
t/op/stacks.ok 28/29#Failed test (t/op/stacks.t at line 592)
# got: ''
#
Dan Sugalski:
# At 12:51 AM -0700 5/15/02, Brent Dax wrote:
# >-Parrot becomes Parrot_Interp
# >-Parrot_String is gone and the string_funcs.h functions are
# no longer
# >externally visible. -A few structures have been renamed.
# >-config.h has been rearranged so that INTVAL, etc. are now
# ali
Chris Ball wrote:
> t/op/stacks.ok 28/29#Failed test (t/op/stacks.t at line 592)
> # got: ''
> # expected: '43210-1
This test has a missing 'end' in the code and segfaults. Patch below.
--
Peter Gibbs
EmKel Systems
Index: t/op/stacks.t
# New Ticket Created by "Peter Gibbs"
# Please include the string: [netlabs #583]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=583 >
Chris Ball wrote:
> t/op/stacks.ok 28/29#Failed test (t/op/stacks.t at
Chris Ball:
# (Note: My first attempt at this message bounced from
# onion.perl.org, which is why it's going to p6i. Reported to
# [EMAIL PROTECTED], who's looking into it.)
# ==
# Seems to be cross-x86, if not global.
#
# t/op/stacks.ok 28/29#Failed test (t/op/stacks.t
# at li
Peter Gibbs:
# Chris Ball wrote:
#
# > t/op/stacks.ok 28/29#Failed test (t/op/stacks.t
# at line 592)
# > # got: ''
# > # expected: '43210-1
#
# This test has a missing 'end' in the code and segfaults. Patch below.
#
# --
# Peter Gibbs
# EmKel Systems
#
# Index: t/op
# New Ticket Created by Brent Dax
# Please include the string: [netlabs #584]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=584 >
Peter Gibbs:
# Chris Ball wrote:
#
# > t/op/stacks.ok 28/29#Failed test (t/
When submitting patches through the bugtracker, please do not CC the
list as well. (This leads to duplicate tickets, because people reply
to the non-managed version and CC the tracker etc.)
the bugtracker (http://bugs6.perl.org) automagically sends new tickets
to the list.
If you have any prob
On Wed, May 15, 2002 at 09:53:48PM +0200, Peter Gibbs wrote:
> [Steve - it seems to me that the 'normal' buffer pool should just be
> replaced by the size 0 pool in your new system? I would think twice about
> incorporating strings, as that might complicate COW, if it ever happens.]
Yes. In my p
On Wed, May 15, 2002 at 01:20:21PM -0700, Robert Spier wrote:
>
> When submitting patches through the bugtracker, please do not CC the
> list as well. (This leads to duplicate tickets, because people reply
> to the non-managed version and CC the tracker etc.)
>
> the bugtracker (http://bugs6.pe
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> Chris Ball:
BD> # (Note: My first attempt at this message bounced from
BD> # onion.perl.org, which is why it's going to p6i. Reported to
BD> # [EMAIL PROTECTED], who's looking into it.)
BD> # ==
BD> # Seems to be cross-x86, if not global
From: "Larry Wall" <[EMAIL PROTECTED]>
> It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe
we'll
> have something like this:
>
> Perl 5 Perl 6
> {1,3} <1..3>
> {3} <3>
> {3,} <3+>
> {0,3} <3->
What are your feelings on multiple ranges for matches? E.g. t
Towers of Hanoi in parrot assembler. Feel free to use it as an example,
or just as a test-case for PerlArrays.
Enjoy!
++t
#
# Towers of hanoi in parrot assembler
#
# Author: Tony Payne
# Date: 05/15/2002
#
# Data structure:
#
# P0 is a PerlArray with three entries. Each entry is a PerlAr
Steve Fink writes:
>What about followups? The way I've settled on doing things is to send
>only to the bugs address initially, but then reply to both bugs and
>the list for any followup correspondence. I know that replying to just
>the bugs address isn't enough because it only forwards the initial
# New Ticket Created by Kevin Falcone
# Please include the string: [netlabs #585]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=585 >
Brent added a patch to make the assembler notice when people leave end
off their .p
Miko O'Sullivan writes:
: From: "Larry Wall" <[EMAIL PROTECTED]>
: > It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe
: we'll
: > have something like this:
: >
: > Perl 5 Perl 6
: > {1,3} <1..3>
: > {3} <3>
: > {3,} <3+>
: > {0,3} <3->
:
: What are your
It seems something messed up while I tried to send this earlier. If this
is essentially a duplicate, ignore it.
I've always liked how VB allowed you to do "instance methods." They allow
for more elegant callbacks, and more structure if callbacks are
complicated. Will Perl6 allow this? (Perl5 s
This is perfectly possible in Perl5, so I don't see why it wouldn't be
possible in Perl6...
Create a new package.
Add the sub to that package.
Set the @INC of that package to your current package.
Re-bless yourself into the new package.
Granted a nice simple syntax would be nice, but that's what
"Kevin Falcone (via RT)" wrote:
>
> # New Ticket Created by Kevin Falcone
> # Please include the string: [netlabs #585]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=585 >
>
> Brent added a patch to make the assemble
Steve Fink wrote:
>
> Unrelated note for Jeff G: speaking of weird bounces, I can't seem to
> get any mail to you. For example, I sent a message warning that you
> hadn't cvs added hash.c and hash.h, and I'm pretty sure you never got
> it. A week or two ago, I got a bounce message back for anothe
45 matches
Mail list logo
