Fixed website to point to non-draft location.
On Oct 16, 2007, at 3:36 AM, Allison Randal wrote:
I've just launched PDD 24 out of the draft directory. Comments and
suggestions welcome.
Allison
--
Will "Coke" Coleda
[EMAIL PROTECTED]
On Fri, 2004-05-14 at 06:27, Rachwal Waldemar-AWR001 wrote:
> It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot
> event'?
> One advantage... it'd be easy searchable. I recall a pain whenever I searched for
> 'thread', or 'Icon'.
If you're talking about search engine
Butler, Gerald wrote:
> How about: "tocsin"
[...thinking out loud...]
I'm not sure it's a good idea to use an obscure word, even if it is
appropriate to the usage. It should be a word that the average user
would recognise, and hopefully be able to intuit some sense of what it
does.
How about "P
I LOVE IT: "PARrot Container for Event Lobbing!!!"
-Original Message-
From: Andy Wardley [mailto:[EMAIL PROTECTED]
Sent: Friday, May 14, 2004 7:36 AM
To: Butler, Gerald
Cc: 'Gordon Henriksen'; '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject
It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot event'?
One advantage... it'd be easy searchable. I recall a pain whenever I searched for
'thread', or 'Icon'.
Regards,
Waldemar
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Wednesday
TECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Events (I think we need a new name)
Matt Fowles wrote:
> I think Page already has a different meaning in computers,
> namely a page of memory.
Not to mention a web page.
> For what it is worth, I support event as the name.
Being as I think I'm
On Wed, May 12, 2004 at 06:15:54PM +0200, K Stol wrote:
| >It does, though, sound like we might want an alternate name for this
| >stuff. While event is the right thing in some places it isn't in
| >others (like the whole attribute/property mess) we may be well-served
| >choosing another name. I
On 12 May 2004, at 17:38, Brent 'Dax' Royal-Gordon wrote:
It's Parrot telling you that something happened.
Squawk?
Mike
Matt Fowles wrote:
> I think Page already has a different meaning in computers,
> namely a page of memory.
Not to mention a web page.
> For what it is worth, I support event as the name.
Being as I think I'm largely responsible for the sense that the name
needs to be changed, I should point ou
All~
I think Page already has a different meaning in computers, namely a page
of memory. This one might be going to far afield for names. For what it
is worth, I support event as the name.
Matt
James Mastros wrote:
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the right
On Wed, May 12, 2004 at 12:08:08PM -0400, Dan Sugalski wrote:
> Okay, so I'm working on redoing the events document based on the
> critiques from folks so far. (Which have been quite helpful) I should
> have a second draft of the thing soon.
>
> It does, though, sound like we might want an alter
On Wed, 2004-05-12 at 12:08, Dan Sugalski wrote:
> It does, though, sound like we might want an alternate name for this
> stuff. While event is the right thing in some places it isn't in
> others (like the whole attribute/property mess) we may be well-served
> choosing another name. I'm open to
Dan Sugalski wrote:
> It does, though, sound like we might want an alternate name for this
> stuff. While event is the right thing in some places it isn't in others
> (like the whole attribute/property mess) we may be well-served choosing
> another name. I'm open to suggestions here...
>
incid
Dan Sugalski wrote:
It does, though, sound like we might want an alternate name for this
stuff. While event is the right thing in some places it isn't in others
(like the whole attribute/property mess) we may be well-served choosing
another name. I'm open to suggestions here...
Notice? (Too sim
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the right
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Or just issue a generic process_events op and spin through the events
DS> in the event queue forevermore. :)
i love spinning the cpu. idle loops are your friend! :)
>> if you set the callbacks, they should be triggered. but if you
At 1:07 PM -0400 5/4/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> sure. a simple double buffering stream program. it starts an async read
>> and waits for it. when ready starts another read in the other buffer, it
>> mungs the data in the first buffer and
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> sure. a simple double buffering stream program. it starts an async read
>> and waits for it. when ready starts another read in the other buffer, it
>> mungs the data in the first buffer and does an async write out (say, to
>> a sock
At 12:00 PM -0400 5/4/04, Aaron Sherman wrote:
On Tue, 2004-05-04 at 11:36, Dan Sugalski wrote:
At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
>So, all Parrot IO will be asynchronous? Does that mean that there's no
>way to perform an atomic read or write?
Yes, and there isn't now anywhere anyw
At 11:03 AM -0400 5/4/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> However...
DS> There are those pesky repeating events, and events from outside
DS> sources. Signals, mouse clicks, window resizes, repeating timer
DS> firings... stuff like that. Can any
On Tue, 2004-05-04 at 11:36, Dan Sugalski wrote:
> At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
> >So, all Parrot IO will be asynchronous? Does that mean that there's no
> >way to perform an atomic read or write?
>
> Yes, and there isn't now anywhere anyway so it's not a big deal.
I was speaki
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The way things are going to work with specific actions a program has
DS> asked to be done, such as a disk read or write, is that you get back a
DS> handle PMC that represents the request, and you can wait on that
DS> handle for the
At 4:17 PM +0200 5/4/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... stuff like that. Can anyone think of a reason that someone
would want to wait *specifically* on one type of event like this,
Well, just for symmetry
new Px, EventWait
set Px, 0.1
waitfor Px
But
At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
On Tue, 2004-05-04 at 09:25, Dan Sugalski wrote:
Okay, I'm working up the design for the event and IO system so we can
get that underway (who, me, avoid the unpleasantness of strings?
Nah... :) and I've come across an interesting question.
The way
On Tue, 2004-05-04 at 09:25, Dan Sugalski wrote:
> Okay, I'm working up the design for the event and IO system so we can
> get that underway (who, me, avoid the unpleasantness of strings?
> Nah... :) and I've come across an interesting question.
>
> The way things are going to work with specific
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... stuff like that. Can anyone think of a reason that someone
> would want to wait *specifically* on one type of event like this,
Well, just for symmetry
new Px, EventWait
set Px, 0.1
waitfor Px
But that's normally (and now) done like:
sle
Jeff Clites <[EMAIL PROTECTED]> wrote:
> But if the "event dispatch" thread is setting some flag for the target
> thread to detect, it's going to need to lock (or something similar) to
> make sure that the value of this flag is visible to other threads.
Yep, that's true. The event thread puts an
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
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
On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
Where in the stream would we patch? If not in a loop, you may never
hit
the single patched location again, but still might not end for a very
long time
Same as with prederefed run cores: backward branc
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
What if control leaves the current code segment before you finish
patching it?
Ops that can leave the code segment have to explicitely check for
events.
Then no need to patch invoke*.
I
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> What if control leaves the current code segment before you finish=20
> patching it? If an event is being delivered from another thread, this is=20=
Ops, that can leave the code segment have to explicitely check for
events.
> Gordon Henriksen
leo
On Saturday, January 17, 2004, at 05:51 , Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
... Also, once the handler is entered we'd have to fix all of patched
locations, which again could be time-consuming for large bytecode.
Please remember: only the current code segment has to b
On Saturday, January 17, 2004, at 05:53 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Other threads than the target could be executing the same chunk of
JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are conver
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Other threads than the target could be executing the same chunk
> of JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are converted to absolute memory locations.
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Where in the stream would we patch? If not in a loop, you may never hit
> the single patched location again, but still might not end for a very
> long time
Same as with prederefed run cores: backward branches, invoke*
> If we are patching all location
On Jan 16, 2004, at 1:20 PM, Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
2) Patch the native opcodes at these places with e.g. int3
I don't think that bytecode-modifying versions should fly; they're not
threadsafe,
Why? The bytecode is patched by a d
Leopold Toetsch wrote:
> Why? The bytecode is patched by a different thread *if* an
> event is due (which in CPU cycles is rare). And I don't see a
> thread safety problem. The (possibly different) CPU reads an
> opcode and runs it. Somewhere in the meantime, the opcode at
> that memory positi
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> 2) Patch the native opcodes at these places with e.g. int3
> I don't think that bytecode-modifying versions should fly; they're not
> threadsafe,
Why? The bytecode is patched by a different thread *if* an event is due
(which
Michal Wallace <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Jan 2004, Dan Sugalski wrote:
>> interrupts. Even if they aren't doing any IO at all they're still
>> potentially watching for keyboard (or other OS-initiated)
>> breaks/interrupts.
> I see your point. In python if you press ^C, it should
> ra
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
>>Event handling currently works for all run cores[1] except JIT.
> What I'd planned for with events is a bit less responsive than the
> system you've put together for the non-JIT case, and I think it'll be
Michal,
> But rather than always monitoring for that, I'd want
> to register a listener and then have parrot handle the
> polling for me.
This is precisely what's being discussed.
> This is probably a dumb question but: what if signals
> threw exceptions instead?
I'd hope that the event handle
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> >I don't understand that part. Why the compiler?
>
> Because we don't have the sort of control of the async environment
> that hardware does to deal with interrupts.
>
> And, realistically, all code has to deal with the possibility of
> interrupts. Even
Leopold Toetsch wrote:
> Event handling currently works for all run cores[1] except JIT.
>
> The JIT core can't use the schemes described below, but we could:
> 2) Patch the native opcodes at these places with e.g. int3 (SIG_TRAP,
> debugger hook) cpu instruction and catch the trap. Running the
At 1:45 PM -0500 1/16/04, Michal Wallace wrote:
On Fri, 16 Jan 2004, Dan Sugalski wrote:
2) Those that explicitly check for events
...
Ops like spin_in_event_loop (or whatever we call it) or checkevent is
in category two. They check events because, well, that's what they're
supposed to do. C
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> 2) Those that explicitly check for events
...
> Ops like spin_in_event_loop (or whatever we call it) or checkevent is
> in category two. They check events because, well, that's what they're
> supposed to do. Compilers should emit these with some frequen
At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
Event handling currently works for all run cores[1] except JIT.
The JIT core can't use the schemes described below, but we could:
1) explicitely insert checks, if events are to be handled
1a) everywhere or
1b) in places like described below under [
On Tue, Jul 22, 2003 at 11:41:25PM -0400, Dan Sugalski wrote:
> First, to get it out of the way, I don't have to convince you of
> anything. You have to convince me. For better or worse I'm
> responsible for the design and its ultimately my decision. If you
> don't want async IO, it's time to ma
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> We are going to do all I/O under the hood asynchronously.
> Completed async IO puts an event in the event queue...
I am new to parrot, but I've had plenty of experience with (non-unix)
I/O systems. Having a totally async core in Parrot is pretty clea
Dan Sugalski wrote:
[snip]
> Here's what we *are* doing.
>
> We are going to do all I/O under the hood asynchronously. Completed
> async IO puts an event in the event queue.
>
> We are going to have a single unified event queue. All IO, timer,
> signal, and UI events go in it. All of 'em. We aren
At 6:29 PM -0700 7/21/03, Damien Neil wrote:
[Stuff I've snipped]
I was going to refute this point by point, but I was getting cranky
and the responses were less than helpful. So let's start over.
First, to get it out of the way, I don't have to convince you of
anything. You have to convince me.
On Tue, Jul 22, 2003 at 10:05:49AM -0700 it came to pass that Damien Neil wrote:
> Some Java programs, as you say, build a
> single-threaded, non-blocking, event-dispatched IO mechanism on top
> of this. Java does not, however, have any support for interrupts;
> it is not possible to do AIO in Jav
On Tue, Jul 22, 2003 at 01:10:24PM +0200, Jos Visser wrote:
> Lots of Java programs simulate AIO by using threads. Almost all Java IO
> mechanisms are blocking and this means that doing interesting work while
> the IO is in progress requires some mechanism that involves a separate
> thread with a c
On Mon, Jul 21, 2003 at 06:29:36PM -0700 it came to pass that Damien Neil wrote:
>
> Do you know of a program that does this (simulated AIO via threads)?
> (Again, I'm not disputing your claim--it's just that this is
> completely contrary to my experience, and I'd like to know more
> about it.)
>
On Sun, Jul 20, 2003 at 11:59:00AM -0400, Dan Sugalski wrote:
> We're supporting interrupts at the interpreter level because we must.
> It doesn't matter much whether we like them, or we think they're a
> good idea, the languages we target require them to be there. Perl 5,
> Perl 6, Python, and
At 1:09 PM -0400 7/20/03, Michal Wallace wrote:
On Sun, 20 Jul 2003, Dan Sugalski wrote:
>It would be entirely possible for Parrot (or a Parrot library) to
>use AIO at a low level, without introducing interrupts to the VM layer.
Sure. But what'd be the point? Adding in interrupts allows a numb
On Sun, 20 Jul 2003, Dan Sugalski wrote:
> >It would be entirely possible for Parrot (or a Parrot library) to
> >use AIO at a low level, without introducing interrupts to the VM layer.
> Sure. But what'd be the point? Adding in interrupts allows a number
> of high-performance idioms that aren't
At 3:25 PM -0700 7/18/03, Damien Neil wrote:
On Fri, Jul 18, 2003 at 05:58:41PM -0400, Uri Guttman wrote:
and event loop i/o doesn't usually support async file i/o. many people
conflate the two. event i/o handles sockets, pipes and such but none
support files. the issue is that the async file i/
On Fri, Jul 18, 2003 at 05:58:41PM -0400, Uri Guttman wrote:
> and event loop i/o doesn't usually support async file i/o. many people
> conflate the two. event i/o handles sockets, pipes and such but none
> support files. the issue is that the async file i/o api is so different
> (or non-existant)
On Fri, Jul 18, 2003 at 05:42:10PM -0400, Benjamin Goldberg wrote:
> AIO is unpopular because it's not widely/portably supported, whereas
> non-blocking event-loop IO is, (one generally does have either select or
> poll), as is blocking threaded IO (even if the thread starting stuff may
> need to b
On Fri, Jul 18, 2003 at 01:06:03PM -0700, Damien Neil wrote:
> Also, given that asynchronous IO is a fairly unpopular programming
> technique these days (non-blocking event-loop IO and blocking
> threaded IO are far more common), I would think long and hard before
> placing support for it as a core
> "BG" == Benjamin Goldberg <[EMAIL PROTECTED]> writes:
BG> Damien Neil wrote:
BG> [snip]
>> Also, given that asynchronous IO is a fairly unpopular programming
>> technique these days (non-blocking event-loop IO and blocking
>> threaded IO are far more common), I would think long and
Damien Neil wrote:
[snip]
> Also, given that asynchronous IO is a fairly unpopular programming
> technique these days (non-blocking event-loop IO and blocking
> threaded IO are far more common), I would think long and hard before
> placing support for it as a core design goal of the VM. If there
>
On Fri, Jul 18, 2003 at 11:29:27AM -0400, Dan Sugalski wrote:
> Nope, that won't work. A lot of what's done is really "main thread
> with interrupts" and that doesn't map well to doing all signal
> handling in separate threads. You really do want to pause the main
> program to handle the events
At 6:01 PM +0200 7/18/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Events should be checked and processed in several instances:
3) When we do a quick check to see if there are pending events to
be processed
I have now a patch ready, which does 3) without additioal performa
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Events should be checked and processed in several instances:
> 3) When we do a quick check to see if there are pending events to be processed
I have now a patch ready, which does 3) without additioal performacne
penalty for all cores except JIT.
(A short
At 2:59 PM -0700 7/17/03, Damien Neil wrote:
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 progr
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 Sat, 06 Jan 2001 13:09:47 -0500, Dan Sugalski wrote:
>Okay, here's a big question that ties the two major pains we have in perl
>6--how do we tie threads and events together?
>
>* Can all events be delivered to any thread?
Yes, but in practice events probably would only be delivered to
threa
71 matches
Mail list logo
