From: dave.joubert on 29 Nov 2009 16:17 Hi, I have a strange problem, and I do not know where to start looking. Enviroment: tclkit-8.5b1-x86_64 Previously the code used to work under Tcl 8.4, but I decided to start using a starkit based approach (first timer) at the same time as swapping to 8.5 Essential code: (needSync is expected to change its value in response to an incomimg TCP packet in a completely separate proc) lib/EAI/EAIdata.tcl:413: proc sendMessage {senderObjName senderObjClass op args} { .. lib/EAI/EAIdata.tcl:427: upvar #0 needSync needSync .. .. lib/EAI/EAIdata.tcl-651- } else { lib/EAI/EAIdata.tcl:652: sendEAImsg $path $types $argList lib/EAI/EAIdata.tcl-653- } lib/EAI/EAIdata.tcl-654- lib/EAI/EAIdata.tcl-655- if { 1 == $expectReply} { lib/EAI/EAIdata.tcl:657: set needSync Pending lib/EAI/EAIdata.tcl:658: vwait needSync And: inc/sendTCPEAImsg.tcl:1: proc sendEAImsg {path types values} { inc/sendTCPEAImsg.tcl:7: global needSync inc/sendTCPEAImsg.tcl:39: set needSync Pending Error message: can't wait for variable "needSync": would wait forever while executing "vwait needSync" (procedure "::EAIData::sendMessage" line 238) invoked from within "::EAIData::sendMessage $iam $myclass $op $nodeName" Is this a known tclkit issue, or a known 8.5 issue ? Is 'upvar #0 needSync needSync' no longer functionally equivalent to 'global needSync' ? or is my problem elsewhere ? Dave
From: Alexandre Ferrieux on 29 Nov 2009 16:33 On Nov 29, 10:17 pm, "dave.joub...(a)googlemail.com" <dave.joub...(a)googlemail.com> wrote: > > can't wait for variable "needSync": would wait forever > while executing > > Is 'upvar #0 needSync needSync' no longer functionally equivalent to > 'global needSync' ? or is my problem elsewhere ? Elsewhere. The "would wait forever" message does not care about the variable nor its visibility (it could very well be non-existent at the time [vwait] is called, and made to exist by an event handler). Instead, this message means that there is no longer any event source. So whatever fileevent or timer that's been active previously must be dead by that time. If this surprises you, note that a fileevent is torn off when an uncaught error breaks out of it (and into bgerror). -Alex
From: miguel sofer on 29 Nov 2009 16:40 dave.joubert(a)googlemail.com wrote: > Hi, > > I have a strange problem, and I do not know where to start looking. > > Enviroment: > > tclkit-8.5b1-x86_64 <snip> > Is 'upvar #0 needSync needSync' no longer functionally equivalent to > 'global needSync' ? or is my problem elsewhere ? Don't know. But please test with a newer tclkit, 8.5 has been out of beta for ages! It might well be a bug in that beta version ... Miguel Try http://code.google.com/p/tclkit/downloads/list for 32 bit binaries; 64 bit binaries are available as basekits within ActiveTcl, or else ... where?
From: dave.joubert on 29 Nov 2009 17:05 On Nov 29, 9:40 pm, miguel sofer <mso...(a)users.sf.net> wrote: > dave.joub...(a)googlemail.com wrote: > > > Hi, > > > > I have a strange problem, and I do not know where to start looking. > > > > Enviroment: > > > > tclkit-8.5b1-x86_64 > > <snip> > > > Is 'upvar #0 needSync needSync' no longer functionally equivalent to > > 'global needSync' ? or is my problem elsewhere ? > > Don't know. But please test with a newer tclkit, 8.5 has been out of > beta for ages! It might well be a bug in that beta version ... > > Miguel > > Tryhttp://code.google.com/p/tclkit/downloads/listfor 32 bit binaries; > 64 bit binaries are available as basekits within ActiveTcl, or else ... > where? Good question. As you say, 8.5b1/tclkit-linux-x86_64.gz is the latest there. I will hunt around so more. Dave
From: dave.joubert on 29 Nov 2009 17:08 On Nov 29, 9:33 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > On Nov 29, 10:17 pm, "dave.joub...(a)googlemail.com" > > <dave.joub...(a)googlemail.com> wrote: > > > can't wait for variable "needSync": would wait forever > > while executing > > > Is 'upvar #0 needSync needSync' no longer functionally equivalent to > > 'global needSync' ? or is my problem elsewhere ? > > Elsewhere. The "would wait forever" message does not care about the > variable nor its visibility (it could very well be non-existent at the > time [vwait] is called, and made to exist by an event handler). > Instead, this message means that there is no longer any event source. > So whatever fileevent or timer that's been active previously must be > dead by that time. If this surprises you, note that a fileevent is > torn off when an uncaught error breaks out of it (and into bgerror). > > -Alex OK, thanks. I will trace through the code. At the moment, the remote app goes down at the same time (according to human perception) but you are more that likely right, and the order of events are reversed. Will try and find a later version of tclkit (64bit Linux) and figure this out. Dave
|
Next
|
Last
Pages: 1 2 Prev: Getting unique list of paths in C? Next: tdom parser problems with xmlns keyword |