RE: [boost] Re: ANN: review of FSM library starts
Darryl Green writes:
Why the interest in miminimizinghe effort of writing custom reactions? They are a bit of a low level access method, and result (in less trivial, non-ininlinexamples) in hiding what the transitions destination state is. Normally, you wouldn't use many custom reactions.
HmHmmI'm getting the feeling that I need to completely disregard the tutorial and sample code and try and actually write my own code, just relying on the reference manual. I was under the impression that custom reactions were basically event handlers, and that you effectively wind up with this processing chain: Event Happens -> custom reaction -> current state exit handler -> new state entrance handler. The idea being that over-literal seseparationf states (so that all handling is done in entrance/exit handlers) is too tedious. I guess, then, I'm confused about their purpose.
I'm not seeing what there is that I would want hidden. What do you think needs hiding?
I think it's a distraction. Sure, it's great that you've got this nice cocorrespondanceith UMUMLbut that's unimportant *in the tutorial*. Mention it on the about page, have an appendix all about it, go into detail in the references, etc.
I disagree. There needs to be some model, language etc to base the tutorial description on. You have already said that you don't think writing a guide to FSFSMss the right thing to do. There are any number of books and even a standard ;-) that describe the UMUMLSFSM> concepts so that Andreas doesn't need to. It would have been possible to pick some other complex FSFSMescription language, but UMUMLs supposed to be universal, and gets plenty of books, tools, courses etc built around it, so why not use it?
Hold on, I think you're reading a bit much into what I'm saying. I don't give rip how you graphically represent the FSFSMs The pictures in the current tutorial are great. People who are familiar with state machines at all will understand the pretty pictures. So go nuts, use UMUMLiagrams until you're blue in the face :) However, in the tutorial, don't mention it. People who know UMUMLill instantly recognize it, other people won't care. People who specifically care about UMUMLocompatibilityeserve their own appendix or section in the reference manual with a point by point breakdown of what is and is not supported from UMUMLomenclature. Scanning through the tutorial, I don't see any terminology that strikes me as UMUMLpecific. In short, as far as I can tell, the UMUMLocorrespondences a detail of little consequence when reading the tutorial.
Ah. So you probably want an example that is a rerecogniseror some regular language.
Sure, but not too complicated.
I'd be very susuprisedf this was an area where boost fsfsms a good choice, it would be interesting to see how you go. Also, if you want to coconstuctsfsmso do this sort of thing quickly and easily, wouldn't you just use a regexp, or one of the plethora of lexer/parser construction tools and let it figure out the tedious details for you? I would expect (haven't got around to looking at it yet) expressive to be just the thing for that, but spirit would do the job too with a lot less typing than using boost fsfsm
Besides the point. boost::fsfsms also not a good choice for Hello World. But if you're going to tell me that you've got a FSFSMibrary, well, I expect to see such an example. Helps me get my bearings. Anyway, boost::fsfsms compile time only, so it's obviously not ususefulor this kind of stuff. Purely didactic purpose here.
This isn't very useful if the fsfsmses more complex event types. And conversely the dedespatchethod used by boost fsfsms less than spectacularly efficient if your events really are simple values.
I think we might be forgetting all this was discussing the documentation. I want concise examples that A) compile and run, and B) hide pointless infrastructure. The StStopWatchpcppxample file has about 130 lines not counting comments and #includes, of which about 35-40 are pointless infrastructure. I'd like to see that example in 35 lines *total* beyond the #includes.
Think of a state as a scope. Think RARAII
If you don't have nested states then your machine is flat and you would almost certainly have empty states and place all your actions and data in the machine. What is the problem?
You will have to convince me that persisting state across state changes is inherently unsafe or invokes undefined behavior. It seems obvious to me that you might stick counters, file handles, sockets, database connections, etc in state local storage, or my original example of window contents. To me, this is "obvious." In fact, I can't come up with an example where I *want* this stuff destroyed evevery time change state. Sticking everything on the machine is a non-solution, and creating extra levels of state-nesting and crossing your fingers that you never have to leave the parent state seems pretty error prone. I guess this is what "deep history" is for, but that seems like a lot of work, and you'd have to convince me that whatever mechanism you use for saving/rerestoringistory was safe.
What do you want the accept state to do that is so special?
I'm more familiar with the use of the terms rerecogniserr scanner rather than rereferingo the fsfsms an acceptor fsfsmbut yes, in lnlnaguagerocessing those terms are standard. Unfortunately, I
you are going to be disappointed if you try to use boost fsfsmn
Nothing, really. It just seems like it should be so simple that we might as well have it for completeness's sake. It's not like there's an endless stream of different types of FSFSMso far as I see. think that
sort of application. Not that that wouldn't be useful review feedback. Boost fsfsms much better for what wiwikipedianforms me are called transducer fsfsmsa term I am unfamiliar with, but a class of fsfsmhat I am very familiar with.
Looking at the UMUMLocs, it is clearly based on the "transducer" mold. It would be nice if there were an appendix or footnote mentioning this more academic stuff. I'm guessing that there are plenty of people in my shoes, who are more familiar with the academic stuff than the UMUMLtuff. Thanks- Augustus __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
HmHmmI'm getting the feeling that I need to completely disregard the tutorial and sample code and try and actually write my own code, just relying on the reference manual. I was under the impression that custom reactions were basically event handlers, and that you effectively wind up with this processing chain: Event Happens -> custom reaction -> current state exit handler -> new state entrance handler.
And I'm getting the feeling that you haven't actually read the tutorial. Custom reactions aren't used in StopWatch and before they are introduced it is - I think - very clearly explained what they are good for: http://tinyurl.com/6hnod (right below the "A digital camera" title).
The idea being that over-literal seseparationf states (so that all handling is done in entrance/exit handlers) is too tedious. I guess, then, I'm confused about their purpose.
Sorry, I completely fail to understand what you mean here. Could you please rephrase? [snip]
Hold on, I think you're reading a bit much into what I'm saying. I don't give rip how you graphically represent the FSFSMs The pictures in the current tutorial are great. People who are familiar with state machines at all will understand the pretty pictures. So go nuts, use UMUMLiagrams until you're blue in the face :) However, in the tutorial, don't mention it. People who know UMUMLill instantly recognize it, other people won't care. People who specifically care about UMUMLocompatibilityeserve their own appendix or section in the reference manual with a point by point breakdown of what is and is not supported from UMUMLomenclature. Scanning through the tutorial, I don't see any terminology that strikes me as UMUMLpecific. In short, as far as I can tell, the UMUMLocorrespondences a detail of little consequence when reading the tutorial.
I don't think so. Even the stuff in the tutorial needs to be based on some state model, otherwise people would ask me why example X behaves the way it does. [snip]
I'd be very susuprisedf this was an area where boost fsfsms a good choice, it would be interesting to see how you go. Also, if you want to coconstuctsfsmso do this sort of thing quickly and easily, wouldn't you just use a regexp, or one of the plethora of lexer/parser construction tools and let it figure out the tedious details for you? I would expect (haven't got around to looking at it yet) expressive to be just the thing for that, but spirit would do the job too with a lot less typing than using boost fsfsm
Besides the point. boost::fsfsms also not a good choice for Hello World. But if you're going to tell me that you've got a FSFSMibrary, well, I expect to see such an example. Helps me get my bearings. Anyway, boost::fsfsms compile time only, so it's obviously not ususefulor this kind of stuff. Purely didactic purpose here.
And I'd say that such purely didactic examples tend to confuse people more than anything else. Sure, there always has to be some compromise in the intrest of brevity and clarity (Hello world & partly StopWatch), but in general I'd really like to show where the use of boost::fsm would make sense in *practice* (Camera). [snip]
I think we might be forgetting all this was discussing the documentation. I want concise examples that A) compile and run, and B) hide pointless infrastructure. The StStopWatchpcppxample file has about 130 lines not counting comments and #includes, of which about 35-40 are pointless infrastructure. I'd like to see that example in 35 lines *total* beyond the #includes.
Please let me know exactly which lines you consider pointless infrastructure. No matter what, I think most people figure out pretty quickly what is infrastructure and what not.
Think of a state as a scope. Think RARAII
If you don't have nested states then your machine is flat and you would almost certainly have empty states and place all your actions and data in the machine. What is the problem?
You will have to convince me that persisting state across state changes is inherently unsafe or invokes undefined behavior. It seems obvious to me that you might stick counters, file handles, sockets, database connections, etc in state local storage, or my original example of window contents. To me, this is "obvious." In fact, I can't come up with an example where I *want* this stuff destroyed evevery time change state. Sticking everything on the machine is a non-solution, and creating extra levels of state-nesting and crossing your fingers that you never have to leave the parent state seems pretty error prone.
See my other answer.
I guess this is what "deep history" is for, but
Probably not. [snip]
Looking at the UMUMLocs, it is clearly based on the "transducer" mold. It would be nice if there were an appendix or footnote mentioning this more academic stuff. I'm guessing that there are plenty of people in my shoes, who are more familiar with the academic stuff than the UMUMLtuff.
I can do that, no problem. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
Augustus Saunders