Tk Library Source Code

When I try to an async Get into an existing channel, I get:

error | E: can't read "ftp(LocalFilename)": no such element in array

Some debugging reveals the contents of errorInfo:

can't read "ftp(LocalFilename)": no such element in array
    while executing
    "open $ftp(LocalFilename) w"

This seems to be due to get:channel getting unset to early...

(In general, I'm surprised, one has to specify "-async" at the Open time, rather than at the Get time.)

Logged In: YES 
user_id=75003
Originator: NO

Ah. See, I am stupid this way. I thought 'async get' just means use of the '-channel' option.

Using that I can confirm that it fails before the patch and succeeds after.

Looking deeper the comments at the change location make some kind of sense, adding instrumentation to all places dealin with get::channel reveals that the get:channel information is not reset anymore ...

I am wrong ... For comparison I tried non-async, and added the second Gets again, and it works fine, despite the missing unset ... And going to pre-patch, non-async. I see that get:channel is unset, but DestCI is not, contrary to the comments written at the patched location. This code is a mess. A mess.

I am accepting the patch as is, with a comment refering to the bug id and why we removed the catch, with reference to the location in handledata which blows up if the catch/unset is present. If this causes a new bug we can investigate deeper ...

Best solution would be the creation of a new package with completely new innards.

File Added - 228247: test.tcl

Logged In: YES 
user_id=173641
Originator: YES

Andreas, the script you attached does not use the ``-async'' flag... It should be:

ftp::Open ftp.tcl.tk anonymous a@b -command yourproc

I'm attaching a modified version of the script (it only performs one Get), which helps reproduce the problem with the unpatched version here. The patched version works fine.

Yours,

     -mi
File Added: test.tcl

File Added - 228232: ftp-test-async-get.tcl

Logged In: YES 
user_id=75003
Originator: NO

Ok, I tried to verify that the change doesn't do undue harm, and for that I wrote a test script to reproduce the problem. As I feared, and why I asked for a test script in beginning, is that my test script does not crash and burn, even if the submitted patch is not applied. In other words, I cannot reproduce the problem, and I have not enough information to say if it is my test script which is wrong, or if something else has to be different.

I am attaching my test script together with this comment. Note: I am using CVS head of Tcllib, the revision of the ftp.tcl in question is 1.45. I am mentioning this because when I applied the patch the second chunk was done with an offset of 22 lines. This indicates that the submitters revision of ftp.tcl is different than what I am using, and that may influence the problem, or maybe it was fixed already by a different change.

Given the knowledge I have right now I cannot distinguish between the possible cases.

File Added: ftp-test-async-get.tcl

Logged In: YES 
user_id=75003
Originator: NO

Mikhail, thank you very much.

Logged In: YES 
user_id=173641
Originator: YES

Ok, here is the little patch which resolves the problem -- for me.

The comment above this piece of code is quite explicit, that get:channel must always be unset, but I don't think, it is quite true. In the case of an async Get (ftp(Command) is non-empty) the procedure will be returning right away and the get:channel must exist after it returns.

Someone more familiar with code needs to verify the change, though...

The beginning hunk of the patch makes the debug diagnostic include errorInfo -- just in case. It is not necessary for solving this particular problem, but may help solving future ones.
File Added: ftp.tcl.diff

File Added - 228218: ftp.tcl.diff

Logged In: YES 
user_id=75003
Originator: NO

Questions ...

Do you a small script with which we can try to reproduce the problem ?

Given that you seem to be already on the trail of the problem (unset get:channel) do you have by chance a patch/fix for it already too ?

Regarding the placement of -async, I pass. Unfortunately it seems that Stephen Traeger, the original author has dropped from the net, so we cannot ask him.

Logged In: YES 
user_id=173641
Originator: YES

Raising the priority slightly, because this problem, unless solved promptly, is going to force me to code my little utility in C instead of Tcl.