Say / Think () for N secs blocks display empty object tables when there are no objects.
However, when an empty text/number field or property is SAID, there is no display of any kind.
Is it possible to display an empty "cloud like thingy: " in these cases ?
The reason I am asking is, when temp clones are created, they apparently have no names, and when one tries to SAY the name nothing is displayed. It would be easier to see that there is that but nothing in it, and realize there is no value.
I realize that an empty SAY block is also used to erase what was displayed previously.
However, the SAY/THINK for N secs already erases itself after the specified time.
Yes, if we want to say nothing, we should be able to do it (for now, does a single space work?), and if we don't want to say anything, we can use say _ for (0) secs
All I am saying is that when an empty table is "SAY" ed, it shows up as an empty table frame in the thingy. No custom coding etc. Asking for the same for consistency sake.
Of course, I can create all sorts of custom blocks - nevertheless a very annoying approach for existing primitives that do different things depending on content.
If the SAY block is using the then it should also use it when the value is empty, because the is only a frame and an indication of SAY has executed.
Oh, you're as bad as Jens; you want users to think as if they were language implementors.
The speech balloon isn't "only a frame"; it's a speech balloon! As every kid knows, it means that the character out of whose mouth it's coming is saying something. If the character isn't saying anything, no speech balloon. You never, ever see an empty speech balloon in a comic.
Yes, if we were to invent an UNSAY primitive, we could extend the domain of SAY to include empty speeches. But that would be an abstraction violation. Comic characters never say a nothing.
EDIT: You do, occasionally, see a speech balloon with "..." in it. This is a speech of zero amplitude, but nonzero duration. So "never say a nothing" isn't quite true, but if they're going to say a nothing they denote it with an ellipsis, not with an empty speech balloon.
Comic strips and characters...
I guess we are on two different planets!
I was talking about ability of reaching into Snap and displaying what is going on. As we all know, the "debug" capabilities of Snap is very limited. Blocks like SAY are one of the few windows into that domain.
And NO, I don't at all want users to think like language implementors - I would not even know what that implies. Rather I would like Snap developers to think like a simple user; and not expect everyone to act like a computer scientist when it's convenient for them.
But I get the point: a rather lengthy and useless exchange is preferred to a simple "no" to the request.
Thx, got it.
Aw, jeez. It's true, I don't like to just say "no." When someone does that to me, I get very frustrated. I'd much rather have a reason for the "no," even if it's a stupid economic reason like "hardly anyone wants that."
You're right that our debugging leaves a lot to be desired. But SAY isn't the solution to that, I think, because it's ephemeral. What I do is make a global variable called LOG, set it to an empty list, and then ADD to it from inside the procedures I'm debugging. And put a watcher on the stage. That lets me scroll back as needed to recall the results of previous tests. Sort of like writing to the Javascript console only different.
That's a stopgap; we need much better text handling. It's high on my list, less high on Jens's I think but still on it somewhere.
MS Make code has an extension that lets one track variables by turning on a debug icon that is actually a bug. Very cute and works well. The Log method you meniton is something we already do given the lack of debug context. However, since you guys were recently discussing how to make Snap look more "real" by hiding blocks and other means, a serious debug facility (not just text handling) with correctly pinpointed errors and local & global var tracking would a great step towards convincing users.
Eagerly awaiting developments, but definitely not holding my breadth.
Just so it's proper, I'm changing the title and adding debugging to it, since we side-tracked again.
Thank you. Yes, debugging is very urgent. We had a much better debugging capability, although still not good enough, in BYOB 3.
All of Jens's effort for the last few months has been absorbed by this Chrome white-screen bug, which we believe is under control in 6.0. After that will come a tidy-loose-ends 6.1, and after that we can think about major new features. For example, we need a who-calls-this-block block. We can already set breakpoints (with PAUSE ALL), and since it's just a block we can do things like conditional breakpoints by putting it inside an IF. In other words, the user doesn't have to learn a whole other language to use the debugger. The existing single-step mode needs controls for step-over vs. step-into. When an error happens we should open a Block Editor on the block inside which the error was triggered.
All of which is just to say that we agree with you about the importance and urgency of debugging, and we have a lot of plans for how to do it. What we don't have is the large, paid programming staff you'd find in a commercial shop. So "urgent" tends to mean "within the next couple of years" for us, not because we like it that way.
" in these cases ?
type of use, where the reporter value is empty. Single SPACE is not nothing !
.
