I posted a question for Lyn in another topic and then saw that it had been closed due to inactivity so I'm reposting here as a separate topic per suggestion from the system.
Lyn mentioned in April last year that on his ToDo list was fixing "... a bug in AI2 (...) where unbound local variable getters encountered in a DoIt are treated as Gnu package names inside the Companion interpreter."
I wrote:
I'm tripping over what appears to be exactly the same issue - the Segment function evaluates Start to be "package $number" rather than a numeric value. Screenshot attached for more info (I hope it's self-explanatory). I'm stepping through a user-entered string of text to remove any non-valid characters (valid characters are provided by a reference string) to produce a "cleaned" version (which is later tested for being null before going on to further processing).
I've pulled out DoIt responses to illustrate the trace. The variable name for Each is the default (I've tried using my own variable names to no effect, and globally-defined variables make no difference). The error message from either Segment is the same: "Error from Companion: The operation segment cannot accept the arguments: 123456 package $number 1".
I wondered whether you had had a chance to fix the issue you identified, and if so, why the error might persist. At the moment this is something of a deal-breaker for me - I can find no way around needing to step through the input text in order to clean it up.
Grateful for any feedback,
--
you can't debug local variables
see again ABG's sample of how you can use Do It inside a loop.
--
The problem began when I tested an installed .apk under development and the app crashed with an error message: "Invalid text operation. Segment: Start is less than 1 (0)" and an End Application button. I'd had problems trying to get the emulator to function reliably so I'd transferred the work in progress to an elderly Android device to test functionality.
When I examined the blocks for my project in AI2 there were a number of warnings (red triangle containing an exclamation mark), all of them saying the same thing (which I included in my post): "Error from Companion: The operation segment cannot accept the arguments: {entered text} package $number 1" where {entered text} was provided by the user. If you pull up the graphic I included you can see the warning symbols.
This meant that Segment was not looping from 1 to the length of the provided text string in increments of 1 as it should have. I understand that it's not possible to debug local variables (at least, not without laboriously stepping through from right to left in each block within a loop), but that's not the issue here. The issue is the trigger of warnings and AI2 reporting that Companion cannot accept the values being passed to Segment.
In the meantime I have updated Companion in the emulator and it seems to be a little more reliable; however, the warnings in the Blocks Viewer persist. I have since recompiled the .apk and tested it again on the Android device, and this time there is no fatal error in the app and the cleaning process appears to work as intended. But the warnings (six of them) still persist in AI2 Blocks Viewer online and they all report the same issue: "... The operation Segment cannot accept the arguments..."
If those warnings will go away eventually (when there's a fix for the problem that Lyn identified) I can live with that.
--
just delete these comments
number is a local variable and you can't debug this
--
There is no option to delete the red triangle (!) warnings. The comments (?) I invoked in order to show how the warnings arose.
There is no option to delete the red triangle (!) warnings. The comments (?) I invoked in order to show how the warnings arose.
--
as a workaround you can replace the affected blocks with new blocks from the text drawer to get rid of the warnings
--
An interesting solution but it worked - thank you! Not something I would ever have thought of doing...
PS Actually I just duplicated the whole set of blocks, deleted the original, and renamed the duplicate (and fixed a failed call in another procedure), but it had the same effect. PB
--
댓글 없음:
댓글 쓰기