Melvin Smith wrote:
At 08:44 PM 1/9/2004 +, Harry Jackson wrote:
So, are they staying, staying for now or not sure yet? I have a few
hundred lines of imcc that uses macros and if they are being removed
then I would rather change now and save myself some pain later.
I think we are going to h
On Sat, 2004-01-17 at 12:12, Leopold Toetsch wrote:
> But I'm a bit worried about the reason, why it actually hangs here:
>
> > (gdb) bac
> > #0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
> ...
> > #3 0x0fd0a694 in exit () from /lib/libc.so.6
> > #4 0x0fcf23a8 in __libc_st
Benjamin K. Stuhl writes:
> Other than the special case of :readonly, can you give me an example
> of when you'd need to, rather than simply writing a PMC class that
> inherits from some base? I'm having trouble thinking of an example of
> when you'd want to be able to do that... After all, since o
Thusly did Dan Sugalski inscribe:
At 3:33 PM -0500 1/16/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtable has a
Luke Palmer writes:
>
> -memcpy(buf->data.bufstart, chunk->data.bufstart, stack->chunk_size);
> +memcpy(buf->data.bufstart, chunk->data.bufstart,
> +stack->frame_size * FRAMES_PER_CHUNK);
Silly me -- left over from benchmarks. Of course I mean:
+ memcpy(buf->data.buf
Leopold Toetsch writes:
> Luke Palmer clearly should, that optimizations WRT register frame stacks
> are possible.
> The follwing numbers seem to second that:
>
> FRAMES_PER_CHUNK time real user
> 4 1.2s 0.9
> 8 1.6
> 16 2.3 1.4
On Jan 17, 2004, at 12:33 PM, Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Ops that can leave the code segment have to explicitely check for
events.
But if the "event dispatch" thread is setting some flag for th
Luke Palmer clearly should, that optimizations WRT register frame stacks
are possible.
The follwing numbers seem to second that:
FRAMES_PER_CHUNK time real user
4 1.2s0.9
8 1.6
16 2.3 1.4
These are runs of
parrot -j -Oc exam
On 17 Jan 2004, at 21:47, Leopold Toetsch wrote:
[...]
BTW don't we have some docs/*.pod with a summary of sending patches?
Also the F seems to be missing in the tree.
I have a submissions.pod on the wiki which I'll put in. Problem is at
the moment I can't see either the wiki or cvs.perl.org. No
# New Ticket Created by "Tamilmani, Arvindh Rajesh (Cognizant)"
# Please include the string: [perl #24941]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24941 >
>> When running this I would expect the 2 files to
>> look th
>> do
>> $ cvs update -A classes/timer.pmc
>> to remove the "sticky tag" and try committing again.
>
>Ah, yes thanks, that worked.
If you wish to get a particular revision/branch of a file,
but don't want the sticky tag to be set, you may use this command:
$ cvs update -r -p file >f
Arvindh Rajesh Tamilmani <[EMAIL PROTECTED]> wrote:
> The attached patch fixes the above two bugs:
> a) when the buffer is full, it is not completely flushed; fixed.
> b) setbuf sets b->size to PIO_GRAIN (and wrongly sets io->flags) when
>passed 0. The patch sets b->size to 0 - hope it is the
>> When running this I would expect the 2 files to
>> look the same, but they don't.
>
>Additionally to the reported bug these seem to be broken:
>
>1) Turning off buffering:
The attached patch fixes the above two bugs:
a) when the buffer is full, it is not completely flushed; fixed.
b) setbuf set
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
> What I meant was, _every_ backward branch (etc.) in the bytecode, or
> just one location that we thought would execute "soon". (But you
> implicitly answered this, below.)
Every backward branch. Guessin
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
>> Ops that can leave the code segment have to explicitely check for=20
>> events.
> Then no need to patch invoke*.
Yep, that's true. I'm waiting for the ops-file hints, then that can be
Chromatic <[EMAIL PROTECTED]> wrote:
> On Sat, 2004-01-17 at 04:29, Leopold Toetsch wrote:
>> I've converted this exit() to Parrot_exit() now. If that helps, I'll
>> change a bunch of other such code too.
> Yep, that fixed. Now there are hangs in some of the t/src files. Right
> now, it's t/src
Harry Jackson <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> [ Please provide patches relative to parrot root to simplify applying ]
> Do you mean we should be using:
> cvs -Q diff -c > patchfile.txt
> when creating our patches rather than just diff'ing two files and then
> sending them
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> the important part is the change to config/init/hints/mswin32.pl,
> without which the build fails.
> The other changes are just warning fixes.
> Tested with GCC 3.3 (and 3.2 and 2.95) with GNU make 3.79
Thanks, applied
> Mattia
leo
18 matches
Mail list logo
