"more details" very difficult to debug because there is no feedback mechanism by which to trap the actual cause(s) of the problem. Initially I had some obvious problem with creating an incomplete remote URL for libURL/TsNet to "put" the data into to… "developer/scripter's error" but later I fixed those and still had issues.
I'm working on tool for blogging and creating slideshows on our web site, or for a reporter to upload images to our server in San Franscisco while on the road.… locally the images files that we need to push to the server are typically on the local in house LAN server/network mounted volume, or on the users local hard drive… should not make a difference…. I thought for sure all my code was perfect. I would turn on your debug stack…run my upload routine, which loops through the files in the folder and tries to put them on the server. I set break points and watched/fixed every variable…the path to the file(s) and the path to the remote URL were perfect… The debug field would just show an initial handshake/login/authentication success, but then the subsequent loops over the contents of the folder (small jpgs for a test) … nothing happened.. in fact your script to post the time stamp was also blocked. debug field would just go blank/no output FYI the context was a pretty low bandwidth/wi-fi context. Everytime it got "stuck" weird things started happening. My long stack script 1300 + lines would take forever to appear in the script editor… any attempts to try to edit the script were blocked with "cannot edit script when it is executing." the whole IDE starts to degrade (as it often does in any 8.*… weird stuff just starts happening all over the place, like getting script errors at line 1240 in a script that only has 120 lines… the only way to survive and get work done is reboot LC, which I find I have to do 20 times a day now…way beyond anyone's ability to report issues to the Quality center.. [One has to wonder about the testing process at the mother ship! All this innovation, but we need a deeper broader focus on making it work well. Please: out 1 or to developers in a room, with a video camera behind them and let them build stackware intensively day after day… watch what happens </end minirant about LC8>] I could not even save or quit LC.. but had to force quit from the finder. I switched to my TSNet testing stack which reduces the code to the bare minimum. It was still blocking… I thought perhaps it was invisible files… tried filtering those… that did not help. on mouseUp put initializeConnectionDetails() into tStem # produces the initial string for the url # sftp://user:[email protected]/home/public_html/blog/wp-content/uploads/2016/08/"; put fld "remoteTarget" after tStem answer folder "Choose a folder to upload" put it into tSourceFolder put files (tSourceFolder) into tFilesToUpload --filter tFilesToUpload without "*DS_Store" repeat for each line x in tFilesToUpload put x into tFileForWeb replace space with "_" in tFileForWeb # path to each file put tSourceFolder & "/" & x into tFileToUpload # path on remote put tStem& "transferTests/" & tFileForWeb into tRemoteFile put url ("binfile:/" & tFileToUpload) into url( tRemoteFile) end repeat end mouseUp huh! it still failed and locked up.. that's where I added "put the result" at the end of the loop and there it was again: "error Previous request not completed" again, LC was completely locked/blocked, not further script editing possible… OK.. ran out of time… shut down…. Later I moved to a different venue here which had a wi-fi router right nearby and band width is about as good as it gets.. I thought I would just step through the code again, thinking I must still have some errors in my script… but first let me turn off debugging and just run it and see what happens. Debugging can be painful and sometimes just letting thing run and hit the error is an easier way to work… HA! now I see in the debug field output " "We are completely uploaded and fine Connection #0 to host dev.himalayanacademy.com left intact" six times for the six files in the folder Wow!. so there *was* nothing wrong with my scripts at all. (well.. there was initially, as I was building invalid remote URL's, but later fixed those) I will test again later today on Ethernet. But this is way too fragile to send into production. we *must* have a means to a) inform the user what the problem is. b) release all the blocks c) let them try again d) provide better info…at the very least "You have a connectivity problem, please try again later." OR "invalid URL, please contact admin" (where the issue is caused by the code and not the connection) would be a minimum requirement. Imagine a reporter in a hotel room in Jakarta, or New York (a real scenario in my world) trying to upload some images and the local wifi is spotty and libURL tool just locks up… I will keep testing here on Ethernet today and see if things are working OK… but we need more robust error trapping/reset/feedback methods. Possibly these are present, and I just need to learn what to do…. BR On 8/3/16, 8:50 PM, "use-livecode on behalf of Charles Warwick" <[email protected] on behalf of [email protected]> wrote: If this is new in DP3, that sounds like it is possibly a bug in tsNet that needs to be addressed. Can you provide any more details on when this happens? Regards, Charles _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
