From: dave.joubert on
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
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
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
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
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