On Wed, Apr 15, 2009 at 11:02 AM, Linda Erlenhov <linda.erlen...@gmail.com> wrote: > Hello > Sorry to mass-spam email you, but I solved the problem myself after a food > break and some more thinking. The problem was the way I was trying to solve > the data requests i asked about in another mail. So this is not a problem > anymore, thank you! > <snip/>
This isn't remotely close to spam, in fact its quite useful to know when issues are resolved so thanks for following up. -Rahul > //Linda > > On Wed, Apr 15, 2009 at 2:16 PM, Linda Erlenhov > <linda.erlen...@gmail.com>wrote: > >> Hello again. >> I run the standalone test and it looks like the timers work fine there (An >> infinit loop between the two states, the logs, except for those that was >> nested as you pointed out, are printed one or two seconds apart as specified >> in the scxml ), so now I´m a bit clueless with how to proceed, any idéas? Is >> there anything I might have forgotten in my java files since it doesn´t work >> there? >> >> best regards >> //Linda >> >> On Tue, Apr 14, 2009 at 9:11 PM, Rahul Akolkar >> <rahul.akol...@gmail.com>wrote: >> >>> On Tue, Apr 14, 2009 at 8:19 AM, Linda Erlenhov >>> <linda.erlen...@gmail.com> wrote: >>> > Hello! >>> > >>> > This may be a stupid question but: >>> > I have read through the code for the simple scheduler and I´m not sure >>> i >>> > understand what happens. >>> > We have written a simple scxml for a small statechart containing two >>> states >>> > with timers and used the simple scheduler as described in your previous >>> > e-mail. As I understand the timers would make the machine just jump >>> between >>> > the two states. This doesn´t happen. Why? >>> <snip/> >>> >>> The Commons SCXML version and the relevant driver (Java) code will >>> help towards answering -- we know this works, so we'll need to know >>> whats being done differently. Bear in mind that the timers execute as >>> daemons. >>> >>> I suggest trying your example standalone [1] first, and we'll go from >>> there. >>> >>> As an aside, in the markup below, <log> is nested in <send> which >>> isn't legal, so the nested <log> will be ignored. >>> >>> -Rahul >>> >>> [1] http://commons.apache.org/scxml/guide/testing-standalone.html >>> >>> >>> >>> > --------------------------- >>> > <scxml version="1.0" initialstate="167" xmlns:cs=" >>> > http://commons.apache.org/scxml"; xmlns="http://www.w3.org/2005/07/scxml >>> "> >>> > <state id = "167"> >>> > <transition target="StateA"/> >>> > </state> >>> > <state id ="StateA"> >>> > <onentry> >>> > <log label="Renegade" expr="'Entering state: A'"/> >>> > <send sendid="1" event="'ToB'" delay="'1000ms'"> >>> > <log label="Renegade" expr="'Timer starting...'"/> >>> > </send> >>> > </onentry> >>> > <transition event="ToB" target="StateB"/> >>> > </state> >>> > <state id="StateB"> >>> > <onentry> >>> > <log label="Renegade" expr="'Entering state: B'"/> >>> > <send sendid="2" event="'ToA'" delay="'2000ms'"> >>> > <log label="Renegade" expr="'Timer starting...'"/> >>> > </send> >>> > </onentry> >>> > <transition event="ToA" target="StateA"/> >>> > </state> >>> > </scxml> >>> > --------------------- >>> > >>> > The output when this is run is simply: >>> > 2009-apr-14 13:08:57 org.apache.commons.scxml.model.Log execute >>> > INFO: Renegade: Entering state: A >>> > 2009-apr-14 13:08:57 org.apache.commons.scxml.env.SimpleScheduler send >>> > INFO: send ( sendId: 1, target: null, targetType: scxml, event: ToB, >>> params: >>> > null, hints: null, delay: 1000) >>> > >>> > best regards >>> > //Linda >>> > >>> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
