tewk wrote:
This is a clean up attempt.
Passes tests.
Excellent! I applied tewk's patch and Patrick R's comments, then pulled
more comments out of the thread and cleaned up the code a bit (reusing
the new macros where relevant). What I ultimately ended up with (based
on which idioms were rep
chromatic wrote:
On Sunday 22 April 2007 18:35, Allison Randal wrote:
(I've been getting intermittent test
hangs with STM on various different tests for a few weeks now, and they
always go away when I run 'realclean'. And, when I set out to track them
down, they disappear.)
(For the record, th
On Sunday 22 April 2007 17:57, Alek Storm wrote:
> > That's as far as I've been able to trace however. The tests do pass if I
> > revert the patch. Any ideas?
>
> I think the patch exposed either a GC or SMOP bug. Here's the smallest I
> could get the test case and still have it segfault withou
On 4/17/07, chris <[EMAIL PROTECTED]> wrote:
I am installing Parrot both on Mandriva ans Debian.
This error only occurs on Debian distrib.
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
real_exception (severity:2 error:30): Complex: malformed string
likely reason: argument cou
Alek Storm <[EMAIL PROTECTED]> wrote:
On 4/19/07, Allison Randal via RT <[EMAIL PROTECTED]> wrote:
> Do you have a test case that shows where the current behavior is incorrect?
The attached test case...
Looks like either (a) you forgot to attach the patch or (b) RT ate it.
Care to try again? :
On Sunday 22 April 2007 18:35, Allison Randal wrote:
> It fails for me too (MacOSX 10.4.9, Intel Core 2 Duo), but it was marked
> as TODO for the release.
>
> t/stm/llqueueok 1/2
> # Failed (TODO) test (t/stm/llqueue.t at line 59)#
> got: ''# expected: 'su
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sun, 22 Apr 2007 20:38:11 -0400
The attached patch completely reworks Parrot_process_args. The changes
are extensive and I think they make the code much clearer. Rather than
just check it in, I thought I'd try to get feedback here to
Andy Dougherty wrote:
On Thu, 19 Apr 2007, chromatic via RT wrote:
On Thursday 19 April 2007 11:35, Andy Dougherty wrote:
While trying to run 'make test' today, t/stm/llqueue_2.pir hung and had
to be killed manually. Trying it again, I got an out-of-memory error
The hanging behavior appears
On 4/22/07, chromatic <[EMAIL PROTECTED]> wrote:
It came in just before the release and it touched a lot of files, so I
(speaking only for myself) let it sit for a couple of days. Unfortunately,
it also came in after Steve Peters's "No C++ Keywords" patch, so it didn't
apply cleanly.
Thanks.
The attached patch completely reworks Parrot_process_args. The changes
are extensive and I think they make the code much clearer. Rather than
just check it in, I thought I'd try to get feedback here to make sure
that it is clearer to everyone else and not just to myself.
This patch also fixes a f
This is a clean up attempt.
Passes tests.
Kevin Tew
Index: src/gc/register.c
===
--- src/gc/register.c (revision 18297)
+++ src/gc/register.c (working copy)
@@ -321,6 +321,12 @@
interp->ctx.bp_ps = old->bp_ps;
}
+
+#define SL
Well this is embarrassing.
I tested it yes, but when I tested it I had:
reg_alloc = ((reg_alloc + 7) >> 3) << 3
const int slot = reg_alloc / 8;
Then I remembered that some less friendly compilers
won't like the the declaration being after a statement.
So I pulled it out and changed it to:
cons
Am Sonntag, 22. April 2007 23:34 schrieb Patrick Rutkowski:
> + const int slot;
> + /* round reg_alloc up to the nearest multiple of 8 */
> + reg_alloc = ((reg_alloc + 7) >> 3) << 3;
> +
> + /* reg_alloc now divides evenly by 8 because of the previous
> + rounding. A granualrity o
On Apr 22, 2007, at 5:14 PM, chromatic wrote:
On Sunday 22 April 2007 14:08, Uri Guttman wrote:
"JP" == Joerg Plate <[EMAIL PROTECTED]> writes:
const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
This is where I start not to understand. Why reg_alloc + 7? Why
shift left and righ
Am Sonntag, 22. April 2007 23:14 schrieb chromatic:
> I figured it was a rounding, but I saw two magic numbers and didn't want to
> guess what it was.
Well, sorry. I thought the rounding was obvious. But obviously I was wrong.
Some macros for rounding up are for sure a good thing. The packfile c
Am Sonntag, 22. April 2007 22:47 schrieb Patrick Rutkowski:
> Yes, I see that now, but that doesn't answer the questions.
>
> Why did you choose reg_alloc/8 as an index into free_list?
A granualrity of 8 is of course arbitratly, could be some bigger power of 2
too.
> Why does the code need to in
On Sunday 22 April 2007 14:08, Uri Guttman wrote:
> > "JP" == Joerg Plate <[EMAIL PROTECTED]> writes:
> >>
> >> const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
> >>
> >> This is where I start not to understand. Why reg_alloc + 7? Why
> >> shift left and right by 3?
>
>
> "JP" == Joerg Plate <[EMAIL PROTECTED]> writes:
>> const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
>> This is where I start not to understand. Why reg_alloc + 7? Why
>> shift left and right by 3?
JP> That's just a rounding up (if necessary) to a multiple of 8 (2<<3).
Yes, I see that now, but that doesn't answer the questions.
Why did you choose reg_alloc/8 as an index into free_list?
Why does the code need to increase the size of free_list so
dramatically in the branching into the first if()?
I was also going to ask again how free_list is meant to be used,
On Sunday 22 April 2007 08:44, Steve Peters wrote:
> The const char * f below causes failures when compiled with C++. The
> patch below switches it to a plain char *.
Thanks, applied as r18297.
-- c
# New Ticket Created by "Steve Peters"
# Please include the string: [perl #42662]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42662 >
The const char * f below causes failures when compiled with C++. The
patch below swit
Am Sonntag, 22. April 2007 14:40 schrieb Patrick Rutkowski:
> Ok, so I see now that reg_alloc is rounded up to a multiple of 8 by
> the following two lines:
>
>/*code*/ const int slot = (reg_alloc + 7) >> 3;
>/*code*/ reg_alloc = slot << 3;
>
> However, this still begs the question of what
> const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
> This is where I start not to understand. Why reg_alloc + 7? Why shift left
> and right by 3?
That's just a rounding up (if necessary) to a multiple of 8 (2<<3).
This week on the Perl 6 mailing lists
"The current pugs implementation is just translating to the old form
underneath, so it's not surprising it's a bit off. That's the sort of
thing that happens when the language designer gives the language
implementor whiplash. However, I rathe
This is in response to your being puzzled about the "*(void **)ptr"
statement. I'm going to assume that you know about void/non-void
context in C and that you're already comfortable with the standard
uses of pointers and type casting.
*(type **)ptr_to_type
gives the same effect as:
(type *)(*pt
Ok, so I see now that reg_alloc is rounded up to a multiple of 8 by
the following two lines:
/*code*/ const int slot = (reg_alloc + 7) >> 3;
/*code*/ reg_alloc = slot << 3;
However, this still begs the question of what the slot variable is
for. Clearly it's being used as an index into
interp
Am Sonntag, 22. April 2007 09:11 schrieb Patrick Rutkowski:
> I think Leo would be the best person to go to for an explanation,
> especially if you plan to dramatically rework the code.
> >> This is where I start not to understand. Why reg_alloc + 7? Why
> >> shift left
> >> and right by 3?
> >
On Sun, 22 Apr 2007 02:31:26 -0700
Mark Glines <[EMAIL PROTECTED]> wrote:
> On Sat, 21 Apr 2007 18:24:18 -0700
> chromatic <[EMAIL PROTECTED]> wrote:
> > Then it calculates a slot value:
> >
> > const int slot = (reg_alloc + 7) >> 3;
> > reg_alloc = slot << 3;
> >
> > This is where I sta
On Sat, 21 Apr 2007 18:24:18 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> Then it calculates a slot value:
>
> const int slot = (reg_alloc + 7) >> 3;
> reg_alloc = slot << 3;
>
> This is where I start not to understand. Why reg_alloc + 7? Why
> shift left and right by 3?
To me it looks
I think Leo would be the best person to go to for an explanation,
especially if you plan to dramatically rework the code. He moved the
whole Parrot_alloc_context() routine from inter_create.c to
gc/register.c in r9645. Along with the move in r9645 he added the slot
variable and all of its side eff
30 matches
Mail list logo
