Some threads with Snap! questions popped up:
https://scratch.mit.edu/discuss/topic/279150/
https://scratch.mit.edu/discuss/topic/279152/

djdolphin wrote:

Some threads with Snap! questions popped up:

Thanks, answered.

@ jens &bharvey

I'm going to dig out my 6 years old (!!!) Byop Oop Examples.
Each example start using SPAWN function, which is not an user block.
As far as I remember this block was used to make a clone of a sprite.
Is it possible to get a copy ?
I'm currently using Byob 3.1 Alpha 22-Mar-2011

xly wrote:

Each example start using SPAWN function, which is not an user block.

I don't remember a SPAWN block. And I can't find it in BYOB 3.1.1, including its tools library. There's a CLONE reporter in Operators; could that be what you're looking for?

It needed to be done, so I've gone and done it.

I have implemented scrolling text and automatic word wrap, using pen trails and sprites. (The text is a bit blurry but apparently there is nothing I can do about that.)

For my next act, I shall build a full CLI with simulated file storage in lists, and simulated file handles. (Okay, maybe not.)

Also I seem to have made a variable and the Snap script editor extremely unhappy, because I decided to paste the entire contents of the book Alice in Wonderland into the variable, from the Gutenberg project.

Oh well, at least I can still set it to fullscreen, click Go, and read the book.

http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=Scrolly%20v1.0.2%20-%20Alice%20in%20Wonderland%20-%20Gutenberg

Dale_Mahalko wrote:

Also I seem to have made a variable and the Snap script editor extremely unhappy, because I decided to paste the entire contents of the book Alice in Wonderland into the variable, from the Gutenberg project.

Snap! is, we believe, happy for you to have large amounts of text in a variable while your project is active. (I admit I haven't tried it with an entire book.) But you can't save such a project to the cloud; you can only save it on your own computer (with “export project”).

Can you use the HTTP block (soon named the URL block) after loading your project to initialize the variable? If so, you could right-click on the variable in the palette and check the “transient” block so the variable will be set to zero before saving the project.

My Alice word wrap / scroller / book reader is only about 350kb and seems to be stored in the Snap cloud without any problems, though the script viewer is having an utter heart attack dealing with about 140,000 characters in a variable string.

Snap either needs better handling for huge data in a variable such as putting it inside a scrolling window within the variable block, or it should impose some sort of maximum string limit for sanity. Anyway, it's impossible to edit an unwrapped variable string that shoots off to the right of the script window by 50 meters.

The maximum Snap cloud save size is 10 megabytes, as has been discovered by students I am working with, importing MP3 sounds and songs into their projects.

,

Here is my word-wrap scroller with a small text input block, which is not driving the script editor bonkers, so that you can actually see how the code works to scroll text using pen trails:

http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=Scrolly%20v1.0.1%20-%20Auto%20Word%20Wrap

Also, something else I discovered, which you can see in the scroller project, is that I discovered blocks don't need to have names to work properly.

For comments and multiline text input blocks, is fine by me, because I find it extremely annoying how the block name + code constantly jumps around in a block depending on how much text has been entered.

Comment block without any block name on it. Steps to reproduce:

New script
Variables -> Make a Block -> Name it Foo, Command block for All sprites (default) - Click OK
Block Editor -> add an input name, call it Bar - Click OK
Block Editor -> click on “Foo” -> Edit label fragment, click Delete
Block Editor now shows this: + (Bar) + -> Click OK
This now appears on the block palette as a block with no name and an input box.

Libraries -> Import -> Multi-line -> OK
Right-click on Multiline command block -> Edit
Block Editor -> Click on “multiline” -> Edit label fragment, click Delete, OK
This appears on the block palette as a green block with no name and an input box.

In the script, drop in the gray block with no name
In the script, drop the green block with no name in the gray block

Voila, we now have a multi-line comment block with no name on it. Just copy and paste this as needed to insert comments inline in your script…

https://imgur.com/xSvs5hY

,

And if you still want a multiline block with the name multiline on it, after editing the original block in this manner, you can go back and re-import it and it appears below the nameless block as it looks normally.

I don't know if I mentioned it already (hate this single thread / million-post communication), but something else I have found is that by default Snap does not see any difference between uppercase and lowercase characters. This to me is teaching kids really bad programming practice as no normal language works like this.

Fortunately I have found a workaround, via the Unicode operators. Rather than doing direct string comparisons, instead convert characters to their unicode value, and then compare them based on that. So now Snap finally recognizes that ‘A’ does not equal ‘a’.

Also for this scroller project, I am relieved to see that CR/LF are preserved in pasted string data, even when not using the “multiline” entry block, and that yes, it is possible to detect these control codes in string data, via char to unicode value conversion.

,

Though the next challenge is figuring out how to do text input without that annoying script-freezing input box, and which will accept input from “any key” into a variable, similar to INKEY$ or X = PEEK(-16368) on the old Apple II…. and properly handles uppercase, lowercase, control characters, and symbols.

Case sensitivity: I strongly disagree. What's “bad programming practice” is having two different things named “foo” and “Foo” in a program. I don't care if C-derived programming languages have case-sensitive symbols. Our raison d'être isn't training future C programmers, or future programmers at all. It's lowering the barriers to entry for kids who want to explore programming.

What's more, in a visual language, it's unusual to compare symbols, since variables and procedures are embodied in blocks, not text strings. People use text comparison for, you know, text, such as people's names, or answers to quiz questions, or “type Yes or No.” Almost all of those are easier with case-insensitive comparison.

Better handling for long strings: Ah, I've finally gotten around to running your project and now I understand where the problem arises. I thought you were joining another complaint, about SAYing long strings, but you're concerned with input text boxes. Yes, that's a bug and we'll fix it at some point, although non-showstopper bug fixes are currently on hold until 4.1 is out. (Meanwhile, in the dev version, click on the keyboard button and your code will reappear.)

Blocks without names: Yes, this is a technique well known among the cognoscenti.

Is it possible that hardware-acceleration could be added in the future? My larger projects have very high CPU usage and can become a slideshow at times.

cupOfJava2014 wrote:

Is it possible that hardware-acceleration could be added in the future?

I'm pretty sure that this is up to your browser, not under our control. Am I wrong about that?

bharvey wrote:

cupOfJava2014 wrote:

Is it possible that hardware-acceleration could be added in the future?

I'm pretty sure that this is up to your browser, not under our control. Am I wrong about that?

WebGL?

comp09 wrote:

WebGL?

Oh. That looks too complicated for my simple mind. Maybe some 12-year-old could write a library using JSFunction blocks? It sounds like it would be a change to Morphic rather than to Snap!.

But we use a 2D canvas, not 3D. Would it really make enough speed difference to be worth the hassle?

We regularly meet on this forum Snap! users complaining that “snap!” is slow, going then to propose their own remedies.
For sure Snap! is not the ideal tool to make games or applications with a large number of sprites, costumes, blocks.

To do this kind ot thing- according to my experience - you have a tool like Phaser based on Javascript and using dozens of specialized libraries.But to use this you need to speak fluently Javascript AND master not only the vocabulary bat also the syntax of hundreds of dedicated functions contained in dozens of libraries. (see http://phaser.io/)

This is definitevely not the agenda of Snap! Inventors

ps _ when I was younger I've converted some of my Snap! applications to Phaser.
It works pretty well …but time investment is huge !

xly wrote:

This is definitevely not the agenda of Snap! Inventors

Not that we're against speed…

But you have to bear in mind the always-live programming interface. You can shove a block into a script while it's running. That's one reason why we'll never have the speed of a static program that can be precompiled and optimized.

Using graphics cards for speed wouldn't kill liveness, but on quick read it seems to me that it's not just a question of setting a flag someplace. It'll turn out that some things are optimizable and some aren't, and we'll have to have two versions of Morphic because some people don't have GPUs, or they have the wrong one… If there ever comes a day when Jens and I feel Snap! is otherwise complete, we'll start talking about speed. Meanwhile, as long as we're about as fast as Scratch, we're happy.

Because I tend to write compute-heavy programs (rather than graphics-heavy), my own future aspirations for speed have to do with JIT compilation. I'm waiting for some CS student to take a compilers course that requires a project.

bharvey wrote:

Meanwhile, as long as we're about as fast as Scratch, we're happy.

To be fair, that's a pretty low bar.

bharvey wrote:

Because I tend to write compute-heavy programs (rather than graphics-heavy), my own future aspirations for speed have to do with JIT compilation. I'm waiting for some CS student to take a compilers course that requires a project.

You should probably start with the “run all at once” blocks by “compiling” them (i.e. translating the blocks into a series of direct method calls) into a JavaScript function, since you can't really modify them while they're running.

Or you could, y'know, refactor Snap! so it's easier to optimize.

bharvey wrote:

comp09 wrote:

WebGL?

Oh. That looks too complicated for my simple mind. Maybe some 12-year-old could write a library using JSFunction blocks? It sounds like it would be a change to Morphic rather than to Snap!.

But we use a 2D canvas, not 3D. Would it really make enough speed difference to be worth the hassle?

I think it would be worth using WebGL, since graphics cards are much better at pushing pixels than CPUs. Maybe a good place to start would be rendering the sprites on the stage.

If you were to stick with 2D, I think some low hanging fruit for optimization could be caching text rendering, since fillText (or whatever it is) can be really slow. (in StringMorph? TextMorph? I can't tell. )

The main interest of Snap! is not to increase your applis speed, but to increase your brain speed…
Take for example this Jens project :

https://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=150-antsandeggs

The interest is not to see ant making quicker its egg heaps, but to understand the making of blocks by Jens the Wizard and then…try to reuse them for your applis in your own way. The challenge is there..

bharvey wrote:

Case sensitivity: I strongly disagree. What's “bad programming practice” is having two different things named “foo” and “Foo” in a program. I don't care if C-derived programming languages have case-sensitive symbols. Our raison d'être isn't training future C programmers, or future programmers at all. It's lowering the barriers to entry for kids who want to explore programming.

I think the concern is more about the way equality is handled. I think I agree with you about case-insensitive symbols, but equality comparisons are different and, I think it's reasonable to want to check whether “apple” is different from “APPLE”. Certainly the single character test for “A” = “a” does seem weird to most students I've encountered. (Which makes sense; English treats upper and lowercase letters very differently. With that in mind, Scratch targeting kids as young as ~5 years, I can see this making more sense. But we're targeting 13 and up, where almost all kids have learned the rules.)

As far as “kids who want to explore programming.” We do need to walk the line between ease of use in the present and hindering people in the future.
In general, I think we're far more on the right than wrong with Snap!, but some stuff like case sensitivity does give me pause, but that's also partially because our extreme simplifications cause more problems. (See also colors debates.)

As a more general point about Snap!'s equals function: Abstractions leave rooms for leaky abstractions. We haven't been able to completely remove the distinctions between numbers and strings. There's still plenty of subtle edge cases. Again, on-balance, I do think Snap! (and Scratch) made the right choice, but whenever a student runs into an edge case you either lose their trust or have to teach them stuff they otherwise might not need to know.

—

Re speed: My biggest feeling with speed is that it's the graphics of drawing things manually – while many programs are compute heavy Snap! (through Morphic) is literally drawing everything by hand. Browsers aren't optimized for this case, where as all the crazy work goes into optimizing all the DOM interfaces and APIs.

When you look at flame graphs of where time is spent, a lot of spent just on the drawing. Even for normal projects. This is why turbo mode works so well – though even then I bet there's room for improvements.