Jens wrote:

Hi frodewin,

thanks for the hint to optimizing “broadcast and wait” for atomic subroutines in Snap! that'll be in the next maintenance release. So, I've dived just a little bit more into your project, and tweaked a few minor things, and now your game runs reasonably fast in Snap! for me, even faster than in Scratch, I think:

https://snap.berkeley.edu/snapsource/snap.html#present:Username=jens&ProjectName=A%20day%20at%20the%20pond

Awesome, thanks a lot for optimizing it!

The idea of free software is that the people who use a program must have the right to examine and modify the source code. The difference between GPL and AGPL is that the former does not envision the case in which people use programs that don't live on their own computers.

So, the users of Snap!, such as you, must have the right to examine and modify the code, even though there is no compiled version on their computers. If you make an improvement to Snap!, and it's a worthwhile improvement that users want to use, we require that you have to make your improvement free, also — that is, your users must have the right to examine and modify the code. This is the same principle as in the GPL: third parties can't imprison users in secret code that builds on our free code.

(As in the GPL, third parties have a slightly more complicated obligation: You must also tell people where they can get our source code, so they can figure out whether any problems are our fault or yours. But all that that requires is including the URL of our site somewhere in your site.)

Many teams of programmers are happily living with these terms and writing great Snap! extensions, such as BeetleBlocks, NetsBlox, Edgy, Bags, and others.

bharvey wrote:

The idea of free software is that the people who use a program must have the right to examine and modify the source code. The difference between GPL and AGPL is that the former does not envision the case in which people use programs that don't live on their own computers.

So, the users of Snap!, such as you, must have the right to examine and modify the code, even though there is no compiled version on their computers. If you make an improvement to Snap!, and it's a worthwhile improvement that users want to use, we require that you have to make your improvement free, also — that is, your users must have the right to examine and modify the code. This is the same principle as in the GPL: third parties can't imprison users in secret code that builds on our free code.

(As in the GPL, third parties have a slightly more complicated obligation: You must also tell people where they can get our source code, so they can figure out whether any problems are our fault or yours. But all that that requires is including the URL of our site somewhere in your site.)

Many teams of programmers are happily living with these terms and writing great Snap! extensions, such as BeetleBlocks, NetsBlox, Edgy, Bags, and others.

There is one major flaw in this argument, the flaw that suggests that Snap! is not run on our own computers.
Snap is run on our own computers.

And by releasing the program, I agree with you, if we release the program without source code, that is unethical.
However, we should not be forced to release the program.
We never imprison users in secret code by not releasing a program at all.

Under your logic, Snap! should be licensed under the GPL, which was what I originally suggested.

badatprogrammingibe wrote:

There is one major flaw in this argument, the flaw that suggests that Snap! is not run on our own computers. Snap is run on our own computers.

I can't tell if you're being disingenuous or just not getting it.

If you run it on your own computer for yourself, then you are not “conveying” the program and you have no obligations under any FSF license.

If you run it on your own computer as a service to which people other than you can connect, then you are conveying the program, and you should have obligations under a free license, namely, you may not trap users into your modified version by keeping its mechanisms secret.

If you are providing access to the software as a web service and you want to entrap users by finding license loopholes, then you're not a friend of free software and I don't see why we should encourage you in that.

P.S. I didn't say “run on”; I said “live on.” I'm aware that Javascript that's part of a web page is run on the client computer, but that's not where it lives, not unless the user takes the trouble to download the source, which of course we allow.

bharvey wrote:

badatprogrammingibe wrote:

There is one major flaw in this argument, the flaw that suggests that Snap! is not run on our own computers. Snap is run on our own computers.

I can't tell if you're being disingenuous or just not getting it.

If you run it on your own computer for yourself, then you are not “conveying” the program and you have no obligations under any FSF license.

If you run it on your own computer as a service to which people other than you can connect, then you are conveying the program, and you should have obligations under a free license, namely, you may not trap users into your modified version by keeping its mechanisms secret.

If you are providing access to the software as a web service and you want to entrap users by finding license loopholes, then you're not a friend of free software and I don't see why we should encourage you in that.

P.S. I didn't say “run on”; I said “live on.” I'm aware that Javascript that's part of a web page is run on the client computer, but that's not where it lives, not unless the user takes the trouble to download the source, which of course we allow.

The license of the code says that any interaction is considered as “conveying.” Whether this is a service or not is irrelevant, even sending a single http request counts as interaction.
For my intended use of Snap!, I intend to release the source code, but I do not want to force other people to release private modifications of my program.

Okay, now I'm really annoyed. Instead of trolling us with legal rabbulism will you *please* tell us what it is exactly you want to do but can't? Then we'll help you and find a way. Oh, and don't tell me you can't read our source code or tinker with it. We've told you that you totally can. Also, please tell us something about yourself. Are you a kid, like, a teen, then you're forgiven. If you're an adult, please (removed by moderator - please keep it polite), we've got actual work to do.

Jens wrote:

Okay, now I'm really annoyed. Instead of trolling us with legal rabbulism will you *please* tell us what it is exactly you want to do but can't? Then we'll help you and find a way. Oh, and don't tell me you can't read our source code or tinker with it. We've told you that you totally can. Also, please tell us something about yourself. Are you a kid, like, a teen, then you're forgiven. If you're an adult, please (removed by moderator - please keep it polite), we've got actual work to do.

I plan to make a GPL-licensed piece of software that essentially replaces the scratch website—this would be useful in schools that don't want to expose their students to the actual scratch community, which I consider to be quite hostile. This would be also useful in using scratch for things against the community guidelines. Say for example, a 18+ version of the scratch site, or like a school hosting their own version of the site.
For the reasons I have stated, I really have a strong dislike for the AGPL, and you guys seem to like it, so I guess we can agree to disagree.
I was planning to use parts of Snap! as a way to play scratch files without the proprietary flash plugin. However, it looks like as I won't be able to use Snap! for this, and might be forced to use something else.
It really just boils down to my strong dislike for the AGPL, and that's pretty much it.
Sorry for wasting your and bharvey's time.

We have noticed that the projects saved after February 14, 2018 have disappeared and are not recoverable. What happened? Is it possible to recover them?

Class 1B Anna Frank from Castelvetro di Modena Italy

thebigbug wrote:

… What happened? Is it possible to recover them?

Brian warned us all in his post here on February 8.

bharvey wrote:

snip snip

Warnings!
1. Any work you save on this test version will be overwritten when we do the official cutover (see below), so also save your work on your own computer during this test period.

2. The development team have used this new version successfully, but it hasn't had a bunch of people banging on it at once, so be prepared for back end crashes.

3. Even if you don't try the new version, it might be wise to keep your current project saved locally as well as on the cloud, for the next week.

If no problems are found, we plan to cut over to the new cloud for real in a week. In order to avoid losing projects during the switch, there will be no cloud service Friday evening 2/16 through Sun 2/18. People logging in after that will be using the new cloud. Passwords won't change, and projects saved before this week will be fine. There's a chance that people might lose the very latest changes to a project on 2/16, although the purpose of this no-cloud weekend is to try to be sure there's no problem along those lines.

You should see no immediate change in behavior, but being in charge of our own back end will enable all sorts of improvements down the road.

I guess you didn't notice it.
As Brian told us to do, I made sure to export my recent projects to my local disc to prevent them from being lost.

thebigbug wrote:

We have noticed that the projects saved after February 14, 2018 have disappeared and are not recoverable. What happened? Is it possible to recover them?

Were you using the …/dev/… version, or the regular URL? If you were using dev, then as scratchmouse said it's not surprising that they disappeared. If not, please send a Snap! username and project name for us to investigate.

The Snap! cloud will be unavailable tomorrow, Tuesday 2/27, for about an hour at 1700 UTC, noon in New York, 9am in California. This is because our new cloud provider is installing anti-malware security patches.

Sorry for the short notice! Snap! itself will still work.

I subscribed for the free Snap!Cloud.

a)
I may upload Snap! applications, and may execute it by loading the URL to the browser.
If I am logged in at Snap! by this browser.

b)
If I use another browser, I get the error message
“Could not fetch project karnification. This project is not public”
http://snap.berkeley.edu/snapsource/snap.html#present:Username=hemmerling&ProjectName=kamification

I “guessed” that from the example applications linked on the main site
https://snap.berkeley.edu/#examples
e.g.
https://snap.berkeley.edu/snapsource/snap.html#present:Username=jens&ProjectName=tree%20animation

–

So is there any option for me as ordinary user, to make my application public?

Sincerely
Rolf
http://www.github.com/hemmerling/snap_kamification

hemmerling wrote:

So is there any option for me as ordinary user, to make my application public?

Try using the “Open” or “Save As” dialog. Select the project you want to share, then click on the “Share” button. The project URL will automatically be put into the location bar, which you can copy-paste to forums or your site or anywhere else.

_nix wrote:

hemmerling wrote:

So is there any option for me as ordinary user, to make my application public?

Try using the “Open” or “Save As” dialog. Select the project you want to share, then click on the “Share” button. The project URL will automatically be put into the location bar, which you can copy-paste to forums or your site or anywhere else.

Thanks !

Please find my first ML project with a “predicting” functionality.
Its performances are dramatically improved thanks to Jens pre-released Just In Time compiler.

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

xly wrote:

Please find my first ML project with a “predicting” functionality.
Its performances are dramatically improved thanks to Jens pre-released Just In Time compiler.

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

I'm embarrassed to say that I would need to learn a lot more about Machine Learning to be able understand what you did in your project. Do you have any short explanation for people like me who don't know much about ML but find it fascinating, anyway? I'm not qualified to say it, but I think you made a great job by doing what you did in the project you shared.

I have a much simpler project, ok, an update to my robot-path-following project, to share. I made a video https://www.youtube.com/watch?v=Uh5nEfwLDMY that has a link to the project (below in the video description on Youtube). Hope you will like it, although it is very simple…

scratchmouse wrote:

xly wrote:

Please find my first ML project with a “predicting” functionality.
Its performances are dramatically improved thanks to Jens pre-released Just In Time compiler.

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

I'm embarrassed to say that I would need to learn a lot more about Machine Learning to be able understand what you did in your project. Do you have any short explanation for people like me who don't know much about ML but find it fascinating, anyway? I'm not qualified to say it, but I think you made a great job by doing what you did in the project you shared.

I have a much simpler project, ok, an update to my robot-path-following project, to share. I made a video https://www.youtube.com/watch?v=Uh5nEfwLDMY that has a link to the project (below in the video description on Youtube). Hope you will like it, although it is very simple…

You are right, NN is a fascinating think 1 - because its opens the door for a lot of useful applications 2 - the technique itself : you take 2 lists of any numbers and the NN find a mathematical link between both…even if it takes a while.
By the way I had made a similar robot car :
https://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=130-pathxl

Do you wanna try something like s_federici's BlockC/bloP that covers on JS?
See here:
BlockJS

window.alert ("[Have fun!]" :: operators) :: looks

MichaelOlifant wrote:

BlockJS

Wow. Very impressive.

But, I've always had mixed feelings about Federici's programming-language projects. It's impressive (both for the project author and for Snap! itself) that another programming language can be exactly implemented in block form. But it gives support to the view that blocks are a skin over some “real” programming language, rather than a language in its own right. (That's the design philosophy of Blockly, most notably; its UI features the ability to see the translation of the blocks into a “real” program.)

I suppose I could be accused of doing the same thing, using blocks as a skin over Scheme. Certainly the call/cc primitives in Snap! are an exact copy of a Scheme feature. But call/cc in Snap! is a special case, because I intended it as a joke; I wanted to watch Mitch Resnick's head explode when I showed it to him. (Alas, he took it in stride.) It does have serious use cases, most notably catch and throw, but we might easily have made those primitives instead. For the most part, we've found it useful to introduce notations quite different from those of Scheme to make the ideas more clearly visible in blocks. Upvars are the clearest example of that; as far as we know, no other language has that feature. (The problem that upvars solve is solved with macros in Scheme.) But I'm very proud of building a lambda into an input slot in the form of an empty gray ring. It means you can start using higher order functions without knowing anything about function-as-data, and then naturally grow into wondering why there has to be a gray ring in that slot and experimenting with rings outside the context of HOFs. Doing what we do is a real departure from Scheme semantics, because it requires us to have typed inputs. (Other input types in Snap! are merely advisory; you can put any value into any slot regardless of its appearance. But the function types really matter.)

So, Snap! doesn't have another language buried inside it, not even Scheme. If I were designing a text language, it wouldn't make a distinction between commands and reporters; everything would be a reporter, as in Scheme. But in a block language, the distinction really buys you a lot in program readability and in ease of entry.

How is an upvar different to a ref cell or a pointer?