Re speed: What if an option was added to Snap! that allowed a project to be run without the stage entirely? That way, when working with data/computation heavy projects, there's no need to worry about lag caused by rendering sprites.

That being said, it's quite possible that rendering the regular Snap! gui is just as computation-intensive as rendering the stage. I don't know.

@PullJosh: Isn't that what WARP does? There's no redisplay while warped.

@cycomachead: I would be open to having the IS IDENTICAL TO block do case-sensitive comparison of strings, but I'm not convinced about the appeal to English rules. In the sentence “Easy come, easy go” do you really think anyone believes that the first and third words aren't the same word?

About speed, I think Jens is not going to abandon Morphic. If WebGL would help in Morphic, maybe we might think about that down the road.

Snap! 4.1 will be officially released this Sunday, Oct 22.

v4.1 Features:
* polymorphic sprite-local custom blocks
* inheritance of sprite-local custom blocks
* inheritance of sprite attributes (x, y, direction, size, costumes, costume #, sounds, scripts)
* first-class costumes and sounds
* visual indicator (map-pin icon) for sprite-local custom blocks (i.e. methods)
* camera snapshots for costumes and new sprites
* localization support when typing expressions
* support for user-forced line-breaks in custom block labels
* ternary Boolean slot setting: support to limit Boolean input slots to “true/false” outside of rings and in palette
* support for default values in custom block Boolean slots
* experimental: duplicate block definition (hidden in shift-click context menu)
* support for codification of String, Number and Boolean value types
* costume icons indicate svg costumes
* sprites’s rotation centers can be adjusted onstage
* clones share their original sprite’s scripts, not a shallow-copy of them
* a highlight-colored balloon indicates the number of active processes per shared script
* new musical “notes”, “location”, “footprints”, “cross” and “keyboard” symbols
* new “visible stepping” toggle button in the control bar
* new “keyboard entry” toggle button in the scripts tool bar
* turn on the “Inheritance support” setting per default
* Assert data types to list operations for more meaningful error messages
* programmatically hide and show primitives in the palette
* new “pen trails” reporter primitive and stage context menu entry
* two-item lists as x-y coordinate arguments for “point towards”, ”go to“ and “distance to” primitives
* Piano keyboard as drop-down menu for entering musical notes, Thanks, Michael!
* Basic “instruments” support: sine, square, sawtooth and triangle waves
* Support https in “url” reporter
* splitting csv-text
* prevent context menu and dragging for stage watchers in presentation mode
* ”floating“ search and make-a-block buttons in the blocks palette
* ”Make a block“ button in every category
* experimental ”download script“ feature
* new ”Animation“ library
* new ”Pixels“ library for MediaComp
* double-clicking a corral sprite icon flashes the sprite onstage

Fixes:
* changed keyboard shortcut indicator for “find blocks” to “^”
* prevent Snap from “hanging” when encountering certain errors in visible stepping
* only mark implicit parameters if no formal ones exist
* optimized thread-launch and script highlighting to a single frame instead of formerly two
* changed direction attribute of sprites to automatically confine to 0-360 degrees
* fixed rotation-bug when flipping costumes in ”only turn left/right“ mode”
* fixed variable renaming (“refactoring”) bugs, thanks, Bernat!
* fixed “fill” block crash when applying the same color twice
* fixed occasional empty drop-down menu items named “close”

support for user-forced line-breaks in custom block labels

How can I use this feature?

bharvey wrote:

@cycomachead: I would be open to having the IS IDENTICAL TO block do case-sensitive comparison of strings, but I'm not convinced about the appeal to English rules. In the sentence “Easy come, easy go” do you really think anyone believes that the first and third words aren't the same word?

From a semantic standpoint, no, there is no difference.
From a grammatical standpoint, there is a huge difference! The first word starts with a capital, while the second word is all lowercase. You can't swap them around without getting an invalid sentence fragment like “easy come, Easy go”.

Also, the case insensitive comparison doesn't even always work when using non-Latin characters like
If you are going to get true case insensitive comparisons in Snap!, a proper unicode normalization library will have to be used.

I also prefer the case sensitive equality operator since if you have a lowercase (or uppercase) block and a case sensitive equality block it is easy to get the current case insensitive equality block with

<(lowercase [ABC] :: operators) = (lowercase [aBc] :: operators)>

but it is much harder to get a case sensitive equality block from the case insensitive equality block.

Line breaks in custom blocks: In the Block Editor, click the plus sign where you want the break, then click title text, then click the downarrow in the text slot, and choose “new line” (at the bottom of the menu).

“Each” vs. “each”: Yes, they fill different slots in the sentence. But that's not the point. Find someone who isn't a computer person and doesn't know the context of this discussion, and ask whether they're the same word or different words. Alternatively, look them up in the dictionary! You'll only find one of them it.

Internationalization: Yes, you're right, it should work in different languages. Feel free to file a bug report. I think the right thing is to compare toLower(toUpper(char)), right? (Has to be in that order because of the ß thing.) (So your version of case-independent comparison based on case-sensitive doesn't quite work either.)

bharvey wrote:

Line breaks in custom blocks: In the Block Editor, click the plus sign where you want the break, then click title text, then click the downarrow in the text slot, and choose “new line” (at the bottom of the menu).

Thanks!

bharvey wrote:

“Each” vs. “each”: Yes, they fill different slots in the sentence. But that's not the point. Find someone who isn't a computer person and doesn't know the context of this discussion, and ask whether they're the same word or different words. Alternatively, look them up in the dictionary! You'll only find one of them it.

Yes, they are one word, but they are still two different sets of symbols. You wouldn't want a data compressor to get rid of all case distinctions in whatever text you are compressing, would you? Or if you write a cipher in Snap! for learning purposes, you wouldn't want decrypt(encrypt(text)) to be the lowercase form of text, would you?

bharvey wrote:

Internationalization: Yes, you're right, it should work in different languages. Feel free to file a bug report. I think the right thing is to compare toLower(toUpper(char)), right? (Has to be in that order because of the ß thing.) (So your version of case-independent comparison based on case-sensitive doesn't quite work either.)

Doing toLower(toUpper(char)) helps, but still fails on some input. The correct thing (as shown in this SO answer) is to do something like the following Python code:
Unfortunately, JS doesn't have anyway to do this without pulling in an external library.

BookOwl wrote:

You wouldn't want a data compressor to get rid of all case distinctions in whatever text you are compressing, would you?

It wouldn't bother me unless the text were a C/C++/etc. program. You have to bear in mind that I grew up with six bits per character, so lower case letters were a great luxury when they appeared.

Apparently the current Right Thing in JS is localeCompare(): https://stackoverflow.com/questions/2140627/javascript-case-insensitive-string-comparison.

Couldn't you just use the JavaScript function block to call the JavaScript string comparison?

TheAspiringHacker wrote:

Couldn't you just use the JavaScript function block to call the JavaScript string comparison?

Yes, but are you suggesting that that would be case-insensitive, or that BookOwl should do that to get the case-sensitive comparison he wants?

Hi,
I am helping my kids do some coding in Scratch and discovered Snap.
I helped them build a very simplified physics engine with collision resolution in Scratch, but I want to do a rewrite to solve issues, and I am locking for a more “proper” or better way to execute in SpriteX: set CreatedVariableA of SpriteY to Z, without creating global variables.

This was sort of possible backwards in Snap by using the following small program in which the created variable vx had to exist locally in both Sprite1 and Sprite2 for the drop down menu of set to work, and this will set vx of sprite2 to 5.

Sprite1:
set vx to 0
set nx to 5
tell Sprite2 { set vx to nx of Sprite1}

Any idea how to do this otherwise would be appreciated.

Best wishes Mattias

Yeah, the variable dropdowns have always been a tough problem (I think?). Basically, the proposed idea is that Snap! detects what the context of that ring (inside of “tell sprite 2 to…”) is, and then sets the contents of variable dropdowns appropriately. But, in practice, there's no way for Snap! to know what context that is – for example, what if you drop “item (random) of (my neighbors)” into the sprite input?

But there's a way to do what you did that's easier – drag out the “set vx to ()” block while Sprite2 is selected, so that the menu item “vx” is selected. Then drag the “set vx” block over Sprite1, in the sprite corral. This will make a copy of the “set vx” block appear inside of Sprite1. So now you can drop the “set vx” block from Sprite2 back into the palette. Then select Sprite1, and you'll see a “set vx” block, which you can drop into your “tell” script.

It sounds complicated, but it's actually faster! This way you don't need to create any “pretend” variables.

(Alternatively, you could drag out a “script variables” block, create a variable named “vx” (by clicking on “a” and renaming it to “vx”), then attach a “set” block, then select “vx” from its menu, then disconnect the “set vx” block and attach that to your “tell” script. Then just get rid of the no longer needed “script variables” block. This might be a little bit faster because you don't need to switch sprites; you do need to type the name of the variable again, though.)

Thanks! _nix both ways works to get around having to use pretend-variables.

I should maybe mention that I tried tried without success.

In sprite1:
Launch (Set to 0) with inputs (vx of Sprite2), 10

Did not set vx of Sprite2 to 10, whether or not “vx of Sprite2” was ringified or not.

bharvey wrote:

TheAspiringHacker wrote:

Couldn't you just use the JavaScript function block to call the JavaScript string comparison?

Yes, but are you suggesting that that would be case-insensitive, or that BookOwl should do that to get the case-sensitive comparison he wants?

I meant the latter.

AlfredThulin wrote:

I am locking for a more “proper” or better way to execute in SpriteX: set CreatedVariableA of SpriteY to Z, without creating global variables.

How do you feel about global procedures? You could just make a SetVX block with an input that does a set. Then you could TELL right?

Hi, bharvey.

I tried and have tried things similar to that (I think). Possibly it can be made to work, but at least it flies over my head how to do it in practice.
I will do the rewrite by letting SpriteA use velocities and position of the SpriteB, with which it has collided, to calculate both its own new velocities and SpriteB's new velocities. Then Tell SpriteB to Set its x,y,vx,vy variables from the calculated-update-variables in Sprite1 that would be nx,ny,nx,vx.

Typos. Last part should read nx,ny,nvx,nvy

Snap! 4.1 is now installed.

The manual is almost ready.

@AlfredThulin: Going crazy with two deadlines at once, sorry; I'll get to your message shortly.

bharvey wrote:

Snap! 4.1 is now installed.

The manual is almost ready.

@AlfredThulin: Going crazy with two deadlines at once, sorry; I'll get to your message shortly.

What are the new features?

Also the make a block button now appears in every category. The new blocks are:

(pen trails ::pen)
tell [ v] to ({} @addInput :: grey ring) @addInput :: control
(ask [ v] to (() @addInput :: grey ring) @addInput :: control)
(a new clone of [myself v] :: control)
(url [snap.berkeley.edu] :: sensing) // renamed in 4.1
inherit [ v]:: variables