Apologies if this is NOT a bug.
SNAP 5.4.4 Offline Version
- What browsers show this problem?
Chrome Version 80.0.3987.132 (Official Build) (64-bit)
- Please share an example project (if possible).
Attached
- Describes the steps to reproduce this issue.
Below
- What does Snap! currently do?
Clone count in "my clones" and "say my clones" do not match
- What should Snap! do instead?
Display and process correct clone count.
In the attached program, click the START flag to set up the LEDs.
Then click "my clones" to display the clone table.
Right click the table and select "open in dialog" to get a permanent Table View.
At this point, things should look like this:
As you can see, the clone table has 5 items and the "length of my clones" also displays 5.
The code is simple:
When a LED is clicked, it will flip its costume to the LIT version and calculate a string var "myLEDs" to store all the LED status:
0 for not lit and 1 for lit. This happens in "When I am clicked" block.
What is wrong is:
-
When a LED is clicked, the in code display for "say my clones" shows 4 (four) clones instead of 5. And the clicked LED costume is not right, even though the open clone table shows it right.
-
The LIT status of the clicked LED is not correctly picked up in the "for each LED" loop, even though it is correctly displayed in the clone table open.
-
Each click of the LEDs, is processed one behind in sequence. Meaning: when I click a LED first time, it is not reflected in the myLEDs string. When I click another LED, the first one shows up but not the curently clicked one. When the 3rd is clicked, the second one shows up, etc. Clone Table images are always updated correctly. But the "say my clones" display is always one behind as well.
-
I tried WARP with no success, and I tried the "say my clones for n sec" without success; trying to give the "my clones" enough time to update itself.
HOWEVER:
-
If I separate the "for each LED " loop from the statements above and click it after wards myself to complete the process, the myLEDs string is correctly calculated for ALL 5 LEDs. Yet the "my clones" display still displays only four.
-
As a verification, the "broadcast next" block correctly switches all costumes for all five LEDs.
Obviously, I have no idea what is happening and could use some help or explanation.
Thanks.
Program Link: Problem Program
Hi @tguneysu,
I think here we have two different threads.
- "clones" and "other clones" reporter
- Using "my clones" of a sprite (for example clicking this reporter on the scripting area) you will get "all its clones". So, in your example, you'll get 5.
- Using "my clones" of a clone (I like to use "my other clones") you will get "all the other clones", but not that clone (the sprite is doing the action) itself. So, when your code calls "my clones" inside a clone action (when you click a clone) you get only 4.
Then, to have all the clones, calling this info from a clone, you can use
-
I see some strange behavior with the "for each" loop with "my clones" list. I think it is re-evaluating the list (and got it with different order) and it's not fine. I'll investigate this (maybe it is a bug) and I'll report it here.
In the meantime, you can use "# for each item of a list" (you have this on the List Utilities library) and it is running ok with these "clones" reporters.
-
Ordering your "myLEDs" info
You have seen "my clones" have all the clones, but their order is not well-controlled. If you need order, you can store all your clones in an orderly way when you create them, storing them inside a variable (inside a list).
I will check this "for each" behavior. Continue...
Joan
You can call method in the context of "main" sprite with expected results
Hi @tguneysu,
I see now that "strange behavior".
"For each" block acts different with linked and arrayed lists. This is great because we can work easily with dynamic data. But here, with the "clones" reporter, this may cause strange behaviors because every evaluation could change the result (the order of the clones) and then, we are repeating some "items" and other are forgotten.
To show this, you can force an arrayed behavior, and the result will be fine:
Note that without "keep true" (to force the arrayed way) the result is wrong. Also, "# for each item..." is fine because it is also forcing an arrayed (fixed) operation.
Not a bug. But we must be careful with some special linked lists 
Joan
Hi Joan,
Thanks for the pointers ! I have to read on the dual behaviour of the LISTS. I know @bh had posted some good material. But I do NOT get your comment that "it is not a bug". Do we have to start coding now depending on the intended use of the various data types?
I am hesitant, but I must make this comment: I have been using SNAP! for over 4 years now and never had to be so aware of details of the data types and different operating modes of the "seemingly same" data types. I keep asking myself, is SNAP! getting easier to use or just harder and harder to understand.
I also get the same impression when I read the forum posts. It is becoming a "contest of outsmarting", rather than explanation of features and how to go about things. To be honest, I am getting tired of reading JS ways to every issue that one discovers. Please, no offense to anybody who revel in these matters! There are some users like myself who really do not care to explore the innards of the code stacks. Of course, my clicks should be indicative of my interests, but reading a forum is like watching an accident on the road - no matter how much you want to you just cannot ignore it.
I fully understand and emphatize with the CS orientation of SNAP! But maybe the CS has managed to expell the FUN! from SNAP!
I apologize again in advance to Jens and others in the team who are working hard to improve Snap! But also keep my comment in mind.
Please, I do NOT intend to start an opinion war to my comments, but would welcome some feedback from non-CS users !
Hi @tguneysu,
I'm sorry about this, and I think I understand your comments. But I'm sure that feeling is not about Snap! way, it is more about a this forum is very diverse and with varied and sometimes cross-border interest.
You know here there are kids, teachers, developers... maybe we can try to sort it all out for "less crossover" and more meaningful conversations.
Anyway, my thoughts about your comments...
- I think we all want a hard fun coding experience!
- Snap! metaphors are made to get the best understanding of CS things.
- Sometimes (but few) these metaphors are not are not so obvious, but they are because they allow access to more complex concepts.
- One of those "more complex things" are to be able to use "linked" and "arrayed" lists. Brian's docs also explain recommendations for a basic and simple use: use one technique or the other and not mix them.
- Apart from all this, the problem we talked about is only due to the coincidence of using a very specific block (my clones) where the order of the list is not constant and we get a rather curious and non-generalizable effect. Again, this is because we are using a dynamic intervention (linked arrays) with a list (my clones) that already have their own special dynamics.
Joan
