On Tue, 2002-05-28 at 18:11, [EMAIL PROTECTED] wrote:
I cannot give final POE code since I'm not quite sure about the syntax that
would be used to specify place types. The net could be described similar to
the small sum test (just list all the transitions together with their arcs,
the arcs'
On Fri, May 31, 2002 at 11:18:18AM -0400, Peter Chen wrote:
Is this ready for public consumption? I downloaded the first snapshot
and took a peak. The code is well organized. I like what I see. It
seems to be a very promising tool for describing and coding a state
machine. It would
On Fri, 2002-05-24 at 19:03, Matt Cashner wrote:
are you familiar with POE::Component::SubWrapper? if not, you might want
to become so. it seems like it would be a great win for you.
Thank you for pointing this out. I did.
What I find is that it requires many intermediate states in cases
On Fri, 2002-05-24 at 13:05, [EMAIL PROTECTED] wrote:
(event-listener) - [step1] - (step2 args) - [step2] ... - [step n]
using my coloured Petri net implementation you could either use the graph
editor or write a simple hash describing the net. So it either gives you
a good graphical
On (05/28/02 06:44), Peter Chen wrote:
This is another issue that troubles me at times. There seems to be a
tendency for events to proliferate. And all events handled by a session
are exposed externally. There are many internal states of a session
that one may not wish to expose.
On Tue, May 28, 2002 at 06:54:44AM -0400, Peter Chen wrote:
On Fri, 2002-05-24 at 13:05, [EMAIL PROTECTED] wrote:
(event-listener) - [step1] - (step2 args) - [step2] ... - [step n]
using my coloured Petri net implementation you could either use the graph
editor or write a simple
On Thu, 2002-05-23 at 21:19, Matt Cashner wrote:
when you get done with this, would you be agreeable to it being included
in poed? (poed is the languishing project to rewrite the poe docs.) all
(well most) of our docs are under the bsd license. let me know what you
think :)
I am honored. :-)
On Fri, 2002-05-24 at 00:47, Rocco Caputo wrote:
I think after writing about two of those, I'd go slightly mad and
create a function that built these for me. If it turned out that I
was doing this a lot, I would probably assume it's a generic pattern
and write a new type of Session to do it.
I suggest using some kind of automaton. Most types can handle looping
and branching, and if they get extended or can run code or store data they
are powerful enough. Creating yet another way is probably not good for
the learning curve you talked about.
You do not really need a new session type.
On (05/24/02 09:35), Peter Chen wrote:
I am honored. :-) Yes. Let me know how to submit this, and I shall.
just toss it to me in email. if there is editing/formatting work to do,
i'll take care of that and let you review it before i commit it.
that goes for all you documentation whiz's out
On (05/24/02 11:16), Peter Chen wrote:
Most of the developers I work with are much more accustomed to
procedural programming. Event driven programming presents a substantial
paradigm shift and consequently a steep learning curve. This makes it
harder for them to adopt POE.
are you
I am working on a tutorial explaining how to poeize a procedural
program, in the hope of making it easier for my coworkers to pick up
POE.
Since I have not worked with POE for that long, I am wondering whether
there is an easier and more elegant way of doing this. This is what I
have so far,
On Thu, May 23, 2002 at 09:16:44PM -0400, Peter Chen wrote:
I am working on a tutorial explaining how to poeize a procedural
program, in the hope of making it easier for my coworkers to pick up
POE.
Since I have not worked with POE for that long, I am wondering whether
there is an easier
13 matches
Mail list logo