Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote:
>> $ ./bench -b=^oo[234f]
> Looks cool!
Yep.
> BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's
> related:
Strange. valgrind doesn't indicate any problem with these tests.
> I'll po
Here is the updated version with hashvalue calculation. Please test it
on different platforms:
- $ perl c2str.pl src/objects.c > src/objects.str
- enable #include "objects.str" near the top of the file
- $ make
see also "Constant strings - again" from yesterday.
Thanks,
leo
c2str.pl
Descriptio
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> The attached patch lazily changes both offs and d to unsigned, which
> seems to fine by the Tru64 cc.
Thanks, applied.
leo
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:
> Sorry, I gave the wrong impression. I meant it looks suspiciously like
> Python is doing a lazy construction on those objects, not that there is
> anything wrong with the benchmark.
No, I don't think
On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote:
With all current optimizations[1] I now have these timings:
$ ./bench -b=^oo[234f]
Numbers are relative to the first one. (lower is better)
p-j-Oc perl-th perlpython ruby
oo2 100%182%152%90% 132%
oo3 100%
On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>
> > That looks suspicious... especially Python.
>
> You have the sources in examples/benchmarks. Maybe we are comparing
> apples and oranges. But the code looks good to me.
Sorry, I gave the wrong im
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> That looks suspicious... especially Python.
You have the sources in examples/benchmarks. Maybe we are comparing
apples and oranges. But the code looks good to me.
> I would suggest using iterations that go much longer so that you can
> detect over-optim
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #28868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28868 >
In Tru64 I got a compilation warning from the src/string.c:
cc: Warning: src/st
On Fri, 2004-04-16 at 12:29, Leopold Toetsch wrote:
> With all current optimizations[1] I now have these timings:
>
> $ ./bench -b=^oo[234f]
> Numbers are relative to the first one. (lower is better)
> p-j-Oc perl-th perlpython ruby
> oo2 100%182%152%90% 132%
> o
With all current optimizations[1] I now have these timings:
$ ./bench -b=^oo[234f]
Numbers are relative to the first one. (lower is better)
p-j-Oc perl-th perlpython ruby
oo2 100%182%152%90% 132%
oo3 100%276%256%333%383%
oo4 100%137%
This vtable currently copies the string. I've tried now:
PMC_str_val(SELF) = value;
instead (perlstring.pmc:193). This breaks exactly one test which
explicitely tests this behavior nothing else.
And there is of course the assign opcode, that does the same. But we
could have:
set P0, "xx"
While trying to speed up hash lookups [1] I came (again) to the problem
that we are missing true PMC constants. We just have a special Sub PMC
for storing subroutine entries but no general way to represent a
constant PMC item. E.g.:
.const pmc s = "value"
.const pmc i = 1
...
add $P
Chromatic <[EMAIL PROTECTED]> wrote:
> After playing with vim syntax highlighting for a few minutes, I hacked
> up syntax highlighting for POD comments.
Thanks, applied.
leo
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> make_COW_reference in src/string.c does not check for a NULL string.
Thanks, applied.
leo
Chromatic <[EMAIL PROTECTED]> wrote:
> After playing with vim syntax highlighting for a few minutes, I hacked
> up syntax highlighting for POD comments. This works on my box, but I'm
> not quite sure it's portable. Are there any other vim hackers willing
> to try it out?
Works great here.
> It
It's time to come again with this topic, last discussion was AFAIK in:
Newsgroups: perl.perl6.internals
Date: Thu, 22 Jan 2004 14:35:54 -0500
Subject: Re: Another GC bug
From: [EMAIL PROTECTED] (Dan Sugalski)
Attached is the slightly modified version of c2str.pl. This generates a
string "
Hi,
make_COW_reference in src/string.c does not check for a NULL string.
Due to this, parrot crashes if the join OP is used and a PMC's __get_string
method returns a null string.
A test case (patch against t/op/string.t) as well as a patch (against
src/string.c) is attached to the message.
jen
Chromatic <[EMAIL PROTECTED]> wrote:
> What needs to be done before making it the default? I'm anxious to
> remove CALL__BUILD=1 from my parrot alias.
Waiting for famous final words by our big cheese...
leo
# New Ticket Created by chromatic
# Please include the string: [perl #28849]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28849 >
Hi there,
After playing with vim syntax highlighting for a few minutes, I hacked
up syn
On Apr 14, 2004, at 11:16 AM, Larry Wall wrote:
I think the idea of tagging complete strings with "language" is not
terribly useful. If it's to be of much use at all, then it should
be generalized to a metaproperty system for applying any property to
any range of characters within a string, such
20 matches
Mail list logo
