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
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
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
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
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
>> 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
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
>> 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
# 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
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
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 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
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
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
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
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
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
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
18 matches
Mail list logo
