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
"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
# 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
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
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
> "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
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
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
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
# 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/
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
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
# 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 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
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
(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: ''
#
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
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
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
#! perl
use Parrot::Test tests => 5;
use Test::More;
output_is(<<'CODE', <
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
# 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
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
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
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 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
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
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
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
29 matches
Mail list logo
