Looking at the Perl bug overview yesterday, I noticed that we have 90-odd
open bugs which are listed as "notabug"! How odd.
Most of these are miscategoriezed. Some are just really old bugs that
have long since been fixed. Anyhow, its a big branch of low hanging fruit
to work on for closing perl
Leopold Toetsch:
# Brent Dax wrote:
# > First of all, spf_render.c:18-20:
# > /* Per Dan's orders, we will not use sprintf if snprintf isn't
# > * around for us.
# > */
# >
# > So we can't use vfprintf, unless Dan thinks otherwise.
#
# Sorry, I don't get that. I see/know the point WR
got warnocked ;-)
- is the event queue the struct QUEUE with handling in tsq.c?
- and - as this is thread-safe - this seems to imply, that we goona do
event handling in the main thread which then dispatches signal events to
the appropriate thread. This seems reasoable for pthreads with POSIX
be
Simon Glover <[EMAIL PROTECTED]> wrote:
> Dan,
> Firstly, when your doing the initialization for a new ParrotClass PMC,
> you create an Array to hold various other PMCs, but you don't size the
> array; this means that when you later try to put things in it in
> Parrot_new_class, it dies with
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23022]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23022 >
The new timer.pmc introduces a struct timer_t. This collides with the
timer_t in /usr/
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> ... Switching the whole op_func_table() or
> ops_addr[] (for CG cores) is simpler,
If have it running now for the slow and the computed goto core.
The signal handler (interrupt code) switches the op_func_table (ops_addr)
and returns.
Then the next execu
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
>
> To be able to switch function tables, this then should become:
>
> PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
>
> Thus predereferncing the function pointer would place an of
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> The new timer.pmc introduces a struct timer_t. This collides with the
> timer_t in /usr/include/time.h
Where get this file pulled in? Anyway ...
> Renaming timer_t to parrot_timer_t makes parrot compile again.
Thanks, appplied.
leo
If memory serves me right, Paolo Molaro wrote:
> > You're insane. :)
Why does this sentence keep popping up whenever anyone discusses modding
gcc :)
> > registers, and register starvation's one of the more annoying things
> > a compiler has to deal with.
imcc !
But this is what Dan had to say
Sean O'Rourke wrote:
To be able to switch function tables, this then should become:
PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
Or is there a better way to do it?
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> > Replacing the next instruction with a branch to the signal handler
> > (like adding a breakpoint) out of the question?
>
> I don't know, how to get the address of the next instruction i.e. the
> "PC" above. Going this way would either mean:
> - fill t
Okay, this needs more attention than I've got at the moment, but I
want to address it quickly so we don't end up going too far afield
yet.
Events are notice of something happening (though different from
notficications, which are separate, I think). IO was complete,
signals pinged, timers fired
At 9:14 AM -0700 7/16/03, Tupshin Harper wrote:
Dan Sugalski wrote:
Traditional processors aren't stack-oriented, not even ones that
are more register-starved than the x86 family. (I'm thinking of the
6502 with it's 1.75 registers here)
Yes, I know. The issue is that GCC is practically hard-wired
At 9:24 AM +0200 7/17/03, Leopold Toetsch wrote:
Simon Glover <[EMAIL PROTECTED]> wrote:
Dan,
Firstly, when your doing the initialization for a new ParrotClass PMC,
you create an Array to hold various other PMCs, but you don't size the
array; this means that when you later try to put thin
Sean O'Rourke wrote:
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don't know, how to get the address of the next instruction i.e. the
"PC" above.
Thinking more of this: There is no
At 9:51 AM +0200 7/17/03, Leopold Toetsch wrote:
got warnocked ;-)
- is the event queue the struct QUEUE with handling in tsq.c?
Yep
- and - as this is thread-safe - this seems to imply, that we goona
do event handling in the main thread which then dispatches signal
events to the appropriate th
On Thu, Jul 17, 2003 at 09:52:35PM +0200, Leopold Toetsch wrote:
> Remaining is:
> 1) save & fill the byte_code with event handler ops.
> 2) use address relative to op_func_table
> 3) Or the "official" way: do regular checks.
> I estimate 2) to be best for prederefed code.
I'm not sure about this.
I've got some extra time to spend on Parrot in the next few months and
I'd really like to get involved. I have decent C and perl skills.
Where would I be most useful?
Thanks! =)
--Tim Howell
Sean O'Rourke wrote:
>
> On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> > PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
> >
> > To be able to switch function tables, this then should become:
> >
> > PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
> >
> > Thus prederefernc
Having just had a really old notabug I sent a few years ago via an old
email address pointed out to me, I tried searching on bugs.perl.org for
"Requestor email address contains 'schwern'" and "Status isn't resolved".
Found seven, many about really old or development versions of Perl that I
can eas
I've been re-reading A5 (regexen), and I was trying to work out how to
incorporate a preprocessor into regex, without a separate lexer. I came
to the conclusion that preprocessor commands are part of the whitespace
in the higher layer of the grammer. So we just need to define the
rule appropri
> I've been re-reading A5 (regexen), and I was trying to work out how to
> incorporate a preprocessor into regex, without a separate lexer. I came
> to the conclusion that preprocessor commands are part of the whitespace
> in the higher layer of the grammer. So we just need to define the
> rul
On Thu, Jul 17, 2003 at 12:58:12PM -0400, Dan Sugalski wrote:
> The first is done in the case of readw or writew, for example. The
> second for event-driven programs that set up callbacks and park
> themselves forever in one big ProcessEvent call. (Tk programs come to
> mind) The third is to be
On Thu, Jul 17, 2003 at 03:53:45PM -0700, Tim Howell wrote:
> I've got some extra time to spend on Parrot in the next few months and
> I'd really like to get involved. I have decent C and perl skills.
> Where would I be most useful?
Having answered a few of these queries, each time in a somewhat
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #23025]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23025 >
There's no reason to test for the presence of setenv/unsetenv in libc
- these f
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #23027]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23027 >
I've added a way to add or remove options on a per-c-file basis.
Right now all
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #23028]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23028 >
(but not on Solaris/SPARC...)
t/op/stacks.NOK 11# Failed test (t/o
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #23029]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23029 >
-Wpadded seems to be more trouble than it's worth at this stage, so I
suggest g
28 matches
Mail list logo
