Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
[ calculating registers to save ]
>> ... once per sub per location where the sub is called from. But there
>> isn't any knowledge that a sub might be called. So the cost is actually
>> more per PMC instruction t
# New Ticket Created by chromatic
# Please include the string: [perl #29521]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29521 >
Hi there,
This one-line change to t/pmc/nci.t demonstrates an apparent bug
somewhere in
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>>
>>>Not quite for this case. Or in theory yes, but... As calling the
>>>subroutine mustn't have any changes to the caller's registers, it's just
>>>simpler to save these registers th
Steve Fink wrote:
>
> I suspect a slight variant of the above may work best. Rather than
> doing a full-out LALR(1) parser for the bottom-up components, you'd do
> a somewhat more naive but still table-driven (shift/reduce) parser,
> carefully limiting what it is assuming about the FIRST() etc. of
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> None of this is set in stone, but take a look and see how everyone feels
> about this.
> I'll get to IO after, since the two are pretty tightly intertwined, and
> changes to this will affect the IO stuff too.
> >Snip here<---
> Eve
Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Not quite for this case. Or in theory yes, but... As calling the
subroutine mustn't have any changes to the caller's registers, it's just
simpler to save these registers that the subroutine might change.
But generating the save signa
> "mab" == mark a biggar <[EMAIL PROTECTED]> writes:
mab> You wrote:
>> i don't think there is a need for all those variants. why would alarm
>> need any special opcode when it is just a timer with a delay of abs_time
>> - NOW? let the coder handle that and lose the extra op codes.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> i disagree with the two classes. how can you handle an unexpected event
>> without know it could happen? effectively all events are expected, some
>> are more expected than others. :)
DS> The terminology there's a bit strained, and
Dan Sugalski wrote:
> chromatic wrote:
>
> > So for SDL, I'd start a separate thread that blocks on
SDL_WaitEvent,
> > creating and posting events when they happen. My main program would
> > handle the events as normal Parrot events. Standard producer
consumer
> > stuff.
> >
> > Since it's blo
The Perl 6 Summary for the week ending 2004-05-09
Ooh look. Stuff's been happening in perl6-internals again. Will wonders
never cease?
Building NCI by default
Bernhard Schmalhofer posted a patch to turn on building libnci.so by
default so that the tests in t/pmc/nci.t would get
Dan Sugalski wrote:
> At 10:33 AM -0700 5/11/04, chromatic wrote:
> >On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
> >
> >> >I'm also curious how to write an interface to an
> existing event system.
> >> >Being able to write it all in PASM is a bonus.
> >>
> >> I don't think it can be all-P
On Tue, 2004-05-11 at 11:23, Dan Sugalski wrote:
> >Since it's blocking, it won't eat up too many resources -- that's nice.
> >It'd be nice to have the SDL event thread ignore events I don't care
> >about though, instead of creating event PMCs I'll just throw away later.
>
> You can always Get Ho
At 11:18 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:45, Dan Sugalski wrote:
That'll still need some C. The event system as it stands is all
active--all event sources put events into the system, rather than
having the event system go looking at event sources for events. You'd
e
On Tue, 2004-05-11 at 10:45, Dan Sugalski wrote:
> That'll still need some C. The event system as it stands is all
> active--all event sources put events into the system, rather than
> having the event system go looking at event sources for events. You'd
> either need to queue up regular timer
At 1:10 PM -0400 5/11/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Event Classes
DS> =
DS> There are two main classes of events, which we'll call expected and
DS> unexpected.
DS> An expected event is one that your program is specifically
> "c" == chromatic <[EMAIL PROTECTED]> writes:
c> On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
>> >I'm also curious how to write an interface to an existing event system.
>> >Being able to write it all in PASM is a bonus.
>>
>> I don't think it can be all-PASM, except maybe (an
At 10:33 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
>I'm also curious how to write an interface to an existing event system.
>Being able to write it all in PASM is a bonus.
I don't think it can be all-PASM, except maybe (and maybe not...)
with a separat
On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
> >I'm also curious how to write an interface to an existing event system.
> >Being able to write it all in PASM is a bonus.
>
> I don't think it can be all-PASM, except maybe (and maybe not...)
> with a separate thread for the existing event sour
At 10:09 AM -0700 5/11/04, chromatic wrote:
On Tue, 2004-05-11 at 09:44, Dan Sugalski wrote:
Thinking we might want:
waitall Parray_of_events
waitany Parray_of_events
?
I certainly do!
Fair enough.
I'm also curious how to write an interface to an existing event system.
Being able to
> "SG" == Simon Glover <[EMAIL PROTECTED]> writes:
SG> One quick point: unless I'm misunderstanding something, there seems to
SG> be no easy way to wait on multiple events to complete if those events
SG> can occur in any order. For instance, suppose we have 5 events, P1 - P5
SG> If
On Tue, 2004-05-11 at 09:44, Dan Sugalski wrote:
> Thinking we might want:
>
> waitall Parray_of_events
> waitany Parray_of_events
>
> ?
I certainly do!
I'm also curious how to write an interface to an existing event system.
Being able to write it all in PASM is a bonus.
-- c
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Event Classes
DS> =
DS> There are two main classes of events, which we'll call expected and
DS> unexpected.
DS> An expected event is one that your program is specifically expecting
DS> to get as a result of a requ
Top-down and bottom-up are not mutually exclusive. At least not
completely. But self-modifying parsers are *much* easier to do with
top-down than bottom-up, because the whole point of bottom-up is that
you can analyze the grammar at "compile" (parser generation) time, and
propagate the knowledge th
At 12:20 PM -0400 5/11/04, Simon Glover wrote:
One quick point: unless I'm misunderstanding something, there seems to
be no easy way to wait on multiple events to complete if those events
can occur in any order. For instance, suppose we have 5 events, P1 - P5
If we know that the events will occ
One quick point: unless I'm misunderstanding something, there seems to
be no easy way to wait on multiple events to complete if those events
can occur in any order. For instance, suppose we have 5 events, P1 - P5
If we know that the events will occur in some specified order (say
1-2-3-4-5), t
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> - if it calls a PASM routine, registers have to be preserved. Which
>>> registers depend on the subroutine that actually gets called (ok, this
>>> informat
On May-10, Joseph Ryan wrote:
>
> The Parse::RecDescent in parrot/lib is a hacked version that removes
> a bunch of stuff (tracing code, iirc) from the outputted grammer so
> that it runs many orders faster than the regular version. Or, to
> put it another way, it increases P6C's runspeed from "i
None of this is set in stone, but take a look and see how everyone feels
about this.
I'll get to IO after, since the two are pretty tightly intertwined, and
changes to this will affect the IO stuff too.
>Snip here<---
Events, another design sketch
Overview
Event
All~
Speaking as a mathematician it is pretty useful, but this is the sort of
thing that could be coded in pure PASM using I registers. After jit it
would be likely fast enough for any application. Recall that in
cryptographic stuff this is never the bottle neck as this algorithm is
already
All~
If I recall my dragon book correctly, shift reduce parsers (which are
what most compilers use) can actually parse a larger class of grammars
then recursive descent parsers which can only parse LL(k) grammars. So
that is another good reason to have it. Perhaps Perl 6 grammars should
prov
At 2:15 PM -0500 5/10/04, Allison Randal wrote:
Dan Sugalski wrote:
I think the first step here is to get the low-level perl operations
defined, and their parrot translations worked out. For this I mean
that we need to have a list of:
Perl:
a = b + c;
Parrot:
add a, b, c
I
At 10:27 PM +0200 5/10/04, Jens Rieks wrote:
Hi,
I have written a gcd op that takes 5 arguments (3 out, 2 in)
gcd d, x, y, a, b
and returns the gcd (in d) of a and b, as well as x and y so that
d = gcd(a,b) = x*a + y*b
This op can be useful for some cryptographic stuff, should I check
At 1:02 PM -0700 5/10/04, Brent 'Dax' Royal-Gordon wrote:
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... As such I've started a FAQ in
docs/compiler_faq.pod.
When I read that file name, I though about gcc, Win32 compilers usable
for Parrot. Could be misleading ...
Index: docs/c
At 12:40 PM -0700 5/10/04, TOGoS (via RT) wrote:
This patch adds some more questions (which I,
personally, would like to know the answers to but
don't) to docs/compiler_faq.pod. It also puts them in
nice categories. Well, I think they're nice...
Looks good--applied, thanks. Now I've more work cut o
At 1:24 PM -0500 5/10/04, Allison Randal wrote:
Dan Sugalski wrote:
I'm not so sure about that. (Not that it won't be replaced, but that
it needs the grammar engine) I'm pretty sure that grammars as Larry's
defined 'em are recursive-descent, and if that's true then I've this
really nasty feelin
Bob Diertens <[EMAIL PROTECTED]> wrote:
> I found the following two bugs with the use of macro's in IMC.
Good. Thanks, applied.
leo
# New Ticket Created by Bob Diertens
# Please include the string: [perl #29502]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29502 >
Hi,
I found the following two bugs with the use of macro's in IMC.
The first bug ha
# New Ticket Created by TOGoS
# Please include the string: [perl #29488]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29488 >
OK, this is my first patch EVAR, so feel free to chew
me out if I totally screwed it up :)
38 matches
Mail list logo
