Don't remove the JSFunction block

It's a pretty intense warning. But anyway, yes, we have roughly the same issue.

what does that do?

A partial solution and we'll have to wait for it to move from experimental status. And I'd like to hear from those working with robots if this would cover all their needs. What about Bluetooth?

But USB is only part of the I/O universe that browsers offer that Snap! is missing. E.g. text-to-speech and speech-to-text.

Yes, though since I'm always logged into Google it only asked for permission the first time. It isn't a perfect solution and someone could make a project that would delete the contents of the cloud folder they designated for saving Snap! projects. But the cloud services I know of have a way to undelete if noticed within 30 days.

A safer solution but not as featureful is to save a project to a file that is automatically backed up to Google Drive, DropBox, Microsoft, etc. Or to a file that is on a network drive (I think many schools only provide network drives on student PCs). Then they can load their projects from any computer that has access to the cloud drives.

To share or publish Snap! projects one could do that on the Snap! site without using Snap!. Just a drag and drop of a local project file would be required.

How bad would it be if Snap! checked before running any user JavaScript whether the user is logged in. A dialog would appear saying "For security reasons Snap! can't run block X while you are logged in. Logout if you really want to run it."? Maybe that's a better price to pay for security than turning off user JavaScript.

it deletes all of the system files in your computer, rendering it worthless.

But doesn't

Harvey, Brian, and Jens Mönig. "Bringing “no ceiling” to scratch: Can one language serve kids and computer scientists." Proc. Constructionism (2010): 1-10

argue that Snap! is also for computer scientists? And computer scientists can rely upon JSF to explore new directions for block-based languages. JSF is a much better solution than forking the source code and hosting a variant when the changes are largely additive.

Yes, that's one of the solutions we're considering. But we still would want it to be possible to use libraries while logged in, so we'd still probably put library JS code into the Snap! kernel.

We have a library for that. :~)

Sorry I probably should have combined all these into one message...

Anyway, yes, that's true.

We're not going to take any hasty action. This discussion is helpful. But we do have to reach some resolution to the security issues in the fairly near future.

Not directly related to the current discussion, but

Well, it's not directly about security, but it is relevant to the discussions we're having.

Actually I'm sort of in the middle of this issue; just about two hours ago I got yelled at by Jens for trying to write a piece of JS to do something that could be done in a different way in Snap!, namely, use the dimension input to SET PEN (dimension) TO ... to dispatch automatically to a helper procedure that does the work of that kind of setting. After a ton of debugging, which turned out to be mostly because I don't really speak JS rather than because I don't really understand how Snap! works (although that's true too), I wrote this:


and Jens said "you're like those forum kids" because my first thought was using JS rather than building a list like this:

So the reason I'm telling you all this is that I, too, want to know how Snap! works on the inside, but I'm 70+ years old, and I've read (and taught) SICP, so I know a thing or two about computer science, and I'm not preventing myself from learning computer science by poking around inside Snap!.

(Plus, I'm allegedly a Snap! developer, even though my contributions have mainly been in libraries and documentation, so I feel like I really should know my way around the code. But that's not really pertinent to this conversation.)

Edit: Jens yelling at me was before I finally got it debugged.

Interesting story. Note that your JS solution works even if a user adds a set pen to block which may or may not be intended. And that if Snap! itself added new set pen to blocks the Snap! version would need to be edited while the JS version would include the new ones.

Perhaps Snap! should have a block that searches for blocks...

And variables ! (Searching function into a project)

As Jens says, you and I, in slightly different ways, are starting down the road of metaprogramming, leading to macros, which are the last remaining major Scheme feature we lack.

OTOH he points out that if I dispatch in JS rather than use an explicit dispatch list, it's no longer possible to do Unused blocks or to figure out the transitive closure when the user asks to export only a subset of the blocks in a project.

Everything is complicated. This all feels like doing my income tax.

P.S. Snap! does have a search-for-blocks feature, namely the control/command-F thing that gives you a palette of blocks with the characters you type in their names. That's where I stole the code that I modified to end up with the above.

Do not search in the palette, but inside the code! (In the code, where do I use this block or variable)

Oh. Yes. We know we need that as a debugging aid. But it's not the problem I was trying to solve in that other thread (as you know!), where the situation is that I know a block exists and I want to use it, but all I have is its name, not the reified block itself.

I didn't read the whole discussion.

I must say that to me the JS block is very peculiar of Snap and I would be really sad if this won't be there anymore before replacing it with a safe strategy.

Don't worry, you can archive the Snap! editor :blush:
Here's the latest archive: Snap! 6.8.1 Build Your Own Blocks

you can't log in, there will be other features not released there.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.