# 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
# 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 #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 #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
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
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
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
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
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.
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
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: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
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
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
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
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
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
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
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
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
# 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/
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
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
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
24 matches
Mail list logo
