On Wed, 10 Nov 2004 08:34:26 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Adam Thomason <[EMAIL PROTECTED] > wrote:
> > On Mon, 8 Nov 2004 11:38:11 +0100, Leopold Toetsch <[EMAIL PROTECTED] >
> > wrote:
> >> Adam Thomason <[EMAIL PROTECTED] > wrote:
> >>
> >> > Now to figure out why the JIT
Whoops, thanks applied.
Bernhard Schmalhofer via RT wrote:
It looks like the the 'all' target wasn't properly changed, when
applying the patch.
Applying the updated patch from ticket 31643 should fix this.
CU, Bernhard
[This message has also been posted.]
Gopal V <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Gopal V
> # Please include the string: [perl #32421]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32421 >
> The follow
At 4:59 PM -0500 11/12/04, Matt Diephouse wrote:
On Fri, 12 Nov 2004 10:16:31 -0800, via RT Gopal V
<[EMAIL PROTECTED]> wrote:
# New Ticket Created by Gopal V
# Please include the string: [perl #32421]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:8
On Fri, 12 Nov 2004 10:16:31 -0800, via RT Gopal V
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Gopal V
> # Please include the string: [perl #32421]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32421 >
>
> The
At 10:51 AM -0800 11/12/04, Michel Pelletier wrote:
> Date: Fri, 12 Nov 2004 04:10:20 -0800
From: Bill Coffman <[EMAIL PROTECTED]>
> > And spilling?
>
> Well, I'm proposing a variable-sized register frame. With very little
> additions we could run with more then 32 registers per kind (there
> Date: Fri, 12 Nov 2004 04:10:20 -0800
> From: Bill Coffman <[EMAIL PROTECTED]>
> > > And spilling?
> >
> > Well, I'm proposing a variable-sized register frame. With very little
> > additions we could run with more then 32 registers per kind (there are a
> > few bitmasks currently that would nee
On Sat, Nov 13, 2004 at 12:46:16AM +1100, Leif Eriksen wrote:
>Even though Test::More is reporting (via make test) that every test
> ran and I had a 100% pass, some subs (such as ldap_groups that I expand
> upon here) are marked by D::C as never being run - even though there is
> a whole t-
# New Ticket Created by Gopal V
# Please include the string: [perl #32421]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32421 >
The following code segfaults with parrot poicephalus
.sub _MAIN
$I0=1
if$I0 < 2
Title: [PATCH] for option perl6 -V
Hello,
the -V option from the program languages/perl6/perl6
don't work as it should.
> perl6 -V
perl6 driver 0.1.1
error:imcc:main No source file specified
I think the output is not what the author of the program
want
# New Ticket Created by Bill Coffman
# Please include the string: [perl #32418]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32418 >
Failed Test Stat Wstat Total Fail Failed List of Failed
---
Hi perl-qa'er's,
I am puzzled as to how to get D::C to report that I ran a test over
a sub. Lets start with some background.
I am using Test::More to write 't-files' for a module, and I am
writing one t-file per subroutine. The subroutine is fully exercised in
that t-file, all branches th
At 5:39 PM +0100 11/12/04, Leopold Toetsch wrote:
In that thread I also asked:
POSTCOMP subs are executed as soon as compilation is done, once again
with no parameters. Whether they do a whole lot is up in the air, but
that's not my problem, and it'll be useful for compile-and-go systems.
Can th
Just keeping folks up to date.
When this goes in, Parrot will guarantee that there are at least
three distinct character sets referrable-to in C source by macro:
BINARY_CHARSET
UNICODE_CHARSET
DEFAULT_CHARSET
and the encodings they need:
FIXED_8_ENCODING (for binary)
DEFAULT_F
As outlined by Dan in [1] subs marked IMMEDIATE are run during
compilation, as soon as the compiler (in pbc.c) sees the end of that
subroutine.
There are a lot of caveats, nothing is checked currently: if that sub
does load_bytecode you'll have much fun ...
In that thread I also asked:
> POSTCO
Here's a question for people to ponder.
I'm adding facilities for a default character set and encoding for
parrot to use in the absence of any other reasonable information.
This is what text strings will use unless code explicitly changes it,
and there'll be a build-time setting at some point to
Bill Coffman wrote:
In that case, I'll focus on the register renaming, live-range
analysis, etc.
Great.
In light of this, I think I'll send in my patch, in case it is
helpful. The problem is that some routine outside of imc_reg_alloc()
is sending in conflicting register preallocation.
Yep. I've
At 7:24 AM -0700 11/11/04, Patrick R. Michaud wrote:
Does Parrot have anything available (yet?) for testing membership in
character classes-- things like isspace, isupper, islower, etc?
I searched around a bit in the docs, online references, and P6PE
and found very little about it.
Not yet. I've go
On Mon, 8 Nov 2004 12:20:19 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote:
>
> >> If frames aren't adjacent, normal argument copying can be done anyway.
>
> > This would seem to require the same typ
Bill Coffman wrote:
You're patch looks suspiciously like a typo. strchr("ISPN", r->set == 0))
Brrr, massive lack of coffein must have misdirect my fingers ...
I'll check it.
For now please just don't call allocate_wanted_regs().
Thanks,
leo
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Interesting. I did a little more research, and checked out a fresh
> CVS tree.
I've committed the tailcall patch a minute ago with that one line
changed in reg_allog.c - please rediff.
> ... I did nothing more than insert a conflict checker into
> reg_al
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Does Parrot have anything available (yet?) for testing membership in
> character classes-- things like isspace, isupper, islower, etc?
RSN or when Dan's string stuff is merged.
> How about for creating and manipulating character classes?
There is a
> These errors look remarkable the same, when I turn on OPT_SUB that is,
> when allocate_wanted_regs() is used. And this code did miss registers
> sets like 'K' (compound keys).
>
> Changing imcc/reg_alloc.c:890 to:
>
>if (r->color >= 0 || r->want_regno == -1 || strchr("ISPN", r->set
> ==
Interesting. I did a little more research, and checked out a fresh
CVS tree. I did nothing more than insert a conflict checker into
reg_alloc.c That is, whatever pre-colored registers have been
assigned to symbols, I verify that none of them are conflicting.
Guess what I got?
make[1]: Leaving
Bill Coffman wrote:
Hello,
* I have the below failed tests. I haven't looked into these. Can
someone tell me if the tests are broken, or is my allocator broken. I
know they don't fail for the current cvs code (as of yesterday).
Failed TestStat Wstat Total Fail Failed List of Failed
---
Does Parrot have anything available (yet?) for testing membership in
character classes-- things like isspace, isupper, islower, etc?
I searched around a bit in the docs, online references, and P6PE
and found very little about it.
How about for creating and manipulating character classes?
Apologi
Dan Sugalski wrote:
The problem is that you're using the wrong signature type here. 't' is
for plain c strings passed into functions for temporary usage. It is
*not* for passing in of long-lived buffers. You really want the 'b' type
if it's a long-lived thing. That pulls the buffer pointer out o
27 matches
Mail list logo
