Prev: ANNOUNCE: Jeszra ZERO-ONE
Next: PureTkGUI v0.9.0 is out
From: dave.joubert on 9 Dec 2009 13:58 Sorry, too used to vi, and hit tab and cr.... On Dec 9, 6:41 pm, "dave.joub...(a)googlemail.com" <dave.joub...(a)googlemail.com> wrote: > Hi Christian, > > On Dec 9, 6:00 pm, CKL <christian.klugesh...(a)gmail.com> wrote: > > > > > Nevertheless, I think that the second point: "buffer all your un- > > expected events" will not be easy. > > I have no idea for the moment, how to store these events ?? > > > Christian > > The obvious way may be the easiest: > set todoBuffCount 0 .. .. .. While blocked events pending # Waiting for incoming packet vwait ... if {$mustBufferThisMessage} { set todoBuff($totdoBuffCount) $message incr todoBuffCount } else { # expected event ..... } } # All expected events done if {$todoBuffCount > 0} { for {set todoBuffPointer 0} ...... handle $todoBuff($totdoBuffPointer) } } set todoBuffCount 0 Could as worst case send you my actual code for this particular problem, but then you need to get your head around a lot of app specific detail, which may obscure the big picture. Dave
From: dave.joubert on 9 Dec 2009 14:07 On Dec 9, 6:44 pm, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote: > > Have you looked into expect? > look into the exp_background command. > > uwe Yup, if you get the overall design right, then expect may be a good way to write it. If however your app can go away and do other things and get async message during that time, then it could be a bit tricky. Dave
From: CKL on 9 Dec 2009 15:38 On 9 déc, 20:07, "dave.joub...(a)googlemail.com" <dave.joub...(a)googlemail.com> wrote: > On Dec 9, 6:44 pm, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote: > > > > > Have you looked into expect? > > look into the exp_background command. > > > uwe > > Yup, if you get the overall design right, then expect may be a good > way to write it. > If however your app can go away and do other things and get async > message during that time, then it could be a bit tricky. > > Dave Hi, Thanks for these information Now just some precision relative to what I want to do. I don't know if you understood really my problem The difficulty, is * When clicking on an button, launch an action (unexpected events) ** to write data to the Device ** Limit the answer by a timeout threshold (some ms) in case of issue I need * vwait: to wait the timeout, during the time the data is read For this (unexpected events) it is not mandatory to buffer future action. I want only block all new action, until the write task (unexpected event) has finished Overhead this (unexpected event) * I wanted to make the necessary task (expected events) each 5 seconds, with ** Ask the device to see if it has something to return to the PC ** Limit the answer by a timeout threshold (some ms) in case of issue I need * vwait: to control when the task have to be run (each 5 seconds) to avoid that the CPU of my PC will be 100% used * vwait: to wait the timeout, during the time the data is read We see that I have to use at minimum 3 vwaits, meaning that I don't know how to do this with "ONE" as you proposed Dave The tcl code above, try to do this, but .... don't work as I want :-(( Christian
From: Uwe Klein on 9 Dec 2009 17:07 CKL wrote: > We see that I have to use at minimum 3 vwaits, meaning that I don't > know how to do this with "ONE" as you proposed Dave I assume you will use the package expect you write a proc repeat {delay script} { if 1 $script after $delay repeat $delay $script } repeat 5000 {dev_trigger ...} proc dev_trigger ... { .... incr ::globalstate(typeA,message,cnt) lappend ::globalstate(eventq) outgoing after $trigger_timeout lappend ::globalstate(eventq) outgoing_timeout } # ok 1 vwait fixed exp_background \ $typeamessage { do_typea_Thing incr ::globalstate(typeA,message,cnt) lappend ::globalstate(eventq) typeA } $typebmessage { do_TypeB_Thing incr ::globalstate(typeB,message,cnt) lappend ::globalstate(eventq) typeB } eof { puts stderr "aijeehh, you've killed it" } any GUI interaction changes something in ::globalstate # ok 2. vwait fixed while true { vwait ::globalstate ;# this is the place were all the background stuff ;# is done as events roll in. set currq ::globalstate(eventq) ; set ::globalstate(incoming) {} foreach item $currq { switch -- $item \ ... { } exit { # cleanup and leave programm } } } # ok vwait 3 is actually done There are certainly other ways to do it but if you have one single item that is event triggered ( gui here ) the remaining functionality should heed that and work to similar priciples. uwe
From: CKL on 9 Dec 2009 18:21 On 9 déc, 23:07, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote: > CKL wrote: > > We see that I have to use at minimum 3 vwaits, meaning that I don't > > know how to do this with "ONE" as you proposed Dave > > I assume you will use the package expect > you write a > proc repeat {delay script} { > if 1 $script > after $delay repeat $delay $script > > } > > repeat 5000 {dev_trigger ...} > > proc dev_trigger ... { > .... > incr ::globalstate(typeA,message,cnt) > lappend ::globalstate(eventq) outgoing > after $trigger_timeout lappend ::globalstate(eventq) outgoing_timeout} > > # ok 1 vwait fixed > > exp_background \ > $typeamessage { > do_typea_Thing > incr ::globalstate(typeA,message,cnt) > lappend ::globalstate(eventq) typeA > } $typebmessage { > do_TypeB_Thing > incr ::globalstate(typeB,message,cnt) > lappend ::globalstate(eventq) typeB > } eof { > puts stderr "aijeehh, you've killed it" > } > > any GUI interaction changes something in ::globalstate > # ok 2. vwait fixed > > while true { > vwait ::globalstate ;# this is the place were all the background stuff > ;# is done as events roll in. > > set currq ::globalstate(eventq) ; set ::globalstate(incoming) {} > foreach item $currq { > switch -- $item \ > ... { > } exit { > # cleanup and leave programm > } > }} > > # ok vwait 3 is actually done > > There are certainly other ways to do it > but if you have one single item that is event triggered ( gui here ) > the remaining functionality should heed that and work to similar > priciples. > > uwe Thanks for your proposition Uwe. Nevertheless, if it could be possible, I would like not use immediately Expect. Don't misunderstood, I really really appreciate want you proposed me, and I thank you for the time you took to answer to my quest. Why, I would not use Expect for the moment and find a solution thanks to pure tcl language. (Actual choice for the moment) I use freewrap to "compile" my tcl code (which is relative large) and I prefer not add (for the moment) another package, which perhaps could add some other difficulties Uwe, I will perhaps change my opinion in some days, but for now, please let me the "hope" to find another solution Again, I really really appreciate your help Regards Christian PS: please apologizes
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: ANNOUNCE: Jeszra ZERO-ONE Next: PureTkGUI v0.9.0 is out |