s_federici wrote:

Is the source code of the Snap website https://cloud.snap.berkeley.edu/site/ (or is it going to be) opensource?

I don't see why not. Mostly it's built out of standard free software, but yeah, we should publish the parts that are specific to us.

bharvey wrote:

s_federici wrote:

Is the source code of the Snap website https://cloud.snap.berkeley.edu/site/ (or is it going to be) opensource?

I don't see why not. Mostly it's built out of standard free software, but yeah, we should publish the parts that are specific to us.

It is open source! It's at bromagosa/SnapSite – right now it's mostly all homegrown.

cycomachead wrote:

s_federici wrote:

Is the source code of the Snap website https://cloud.snap.berkeley.edu/site/ (or is it going to be) opensource?

It is open source! It's at bromagosa/SnapSite – right now it's mostly all homegrown.

Found! Thanks a lot. I will certainly give it a try

I got a profile message from _nix pointing me at a suggestion-for-Scratch-3 thread about unevaluated input types, and that in turn pointed me to Jonathan50's suggestion of lambda, with 17 pages of discussion, including people recapitulating all the stages in our syntax design, starting from BYOB 3.0's THE BLOCK and THE SCRIPT blocks! I don't think there's any chance they'll accept it, but it's heartwarming nonetheless.

But a possibly-winnable struggle y'all could have with them would be to revisit the syntactic decision (namely, keeping block definitions visible in a scripting area) that led them to the semantic decision that all custom blocks are sprite-local. I hardly ever make a sprite-local block, unless I'm showing off OOP. And the whole point of procedures is to hide code details, which is defeated by keeping the body in the scripting area.

bharvey wrote:

I got a profile message from _nix pointing me at a suggestion-for-Scratch-3 thread about unevaluated input types, and that in turn pointed me to Jonathan50's suggestion of lambda, with 17 pages of discussion, including people recapitulating all the stages in our syntax design, starting from BYOB 3.0's THE BLOCK and THE SCRIPT blocks! I don't think there's any chance they'll accept it, but it's heartwarming nonetheless.

As an aside, I wrote a suggestion for custom C-shape blocks. I tried to phrase it as, er, persuasively as possible.. I don't know if I'm actually any good at that though. https://github.com/LLK/scratch-blocks/issues/1800

_nix wrote:

I wrote a suggestion for custom C-shape blocks.

Where does the user find the NUMBER variable block? Does it have to be a global variable? You really want an upvar!

Edit: … the point being, not to criticize your proposal, but just musing on the idea that as soon as you try to raise the ceiling a teeny bit in Scratch you end up inexorably pulled to Snap!. Another example: You can't have nested lists unless you make lists first class.

bharvey wrote:

_nix wrote:

I wrote a suggestion for custom C-shape blocks.

Where does the user find the NUMBER variable block? Does it have to be a global variable? You really want an upvar!

Yes, you're right. This raises an interesting, important point that if you try to stick a “for numbers from A to B” inside another “for numbers…”, you end up with a broken loop: both blocks reuse the same variable. The only way to deal with that without upvars would be by using a stack system for local variables. Or you could be considerably more elegant by using recursion:

define for numbers from (A) to (B)
if <(A) < (B)> then
  set [number v] to (A)
  script :: custom-arg
  for numbers from ((A) + (1)) to (B) {
    script :: custom-arg
  } :: custom
end

If you need to keep track of both indices of a parent loop and the one nested inside it, you could do the following:

for numbers from (1) to (10) {
  set [i1 v] to (number)
  for numbers from (1) to (10) {
    set [i2 v] to (number)
  } :: custom
} :: custom

But of course, this leads us back to your point: you really just want an upvar!

Like with custom C-blocks, it's not too complicated to present upvars to the user - just name the button “add an output” or something like that, and put it beside the “add an input” buttons, and you'll have already solved a good chunk of the UI. The problem is… I don't know how to present that to the Scratch Team. Custom C-blocks and upvars are both very related ideas - but they're not exactly the same idea. If I bring up C-blocks and upvars at the same time, it's easier to understand the potential of working the two ideas with each other; but I worry that it might also make the idea seem too big, causing the ST to spend far longer prioritizing other features rather than “C-blocks + upvars” (versus prioritizing just C-blocks or just upvars, separately).

(PS, Thanks for the input )

_nix wrote:

define for numbers from (A) to (B)
if <(A) < (B)> then
  set [number v] to (A)
  script :: custom-arg
  for numbers from ((A) + (1)) to (B) {
    script :: custom-arg
  } :: custom
end

I don't think that'd work; the script might refer to NUMBER after the inner for loop (not the recursive call!) finishes.

On the subject of Scratch Team indoctrination, I think they're smart enough to work through the implications of a proposed feature. I mean, they might not invent upvars, but they'll realize that there's an issue, and they'll either invent something or decide C-shaped blocks would be too hard to use. And, they know about Snap!, even if they're not experts on the details.

But the more serious issue is that (for reasons I don't really understand) they haven't taken the (intellectually and chronologically) prior step of inventing script variables. They're happy with all variables being global in scope. (I'm including sprite-local ones, which are global as far as the procedure calling environment is concerned.)

And even before that – way before that – is that they figure “8-year-olds won't understand X” and then instead of concluding "so we'd better make sure you don't have to use X in your projects“ they conclude ”so we'd better not let 15-year-olds use X either." (It's not quite as stupid as I'm making it sound; the intermediate step is “an 8-year-old might discover the 15-year-old's project, look inside it, and get confused.”) Apparently it took them quite a long time to add lists in Scratch 1.4, based on the same reasoning. And indeed some 8-year-olds were confused. But then they grew up! (Grew more up, anyway, enough to understand lists.)

When was Snap! 4.0?

The forum thread started May 9, 2013.

The HISTORY file in the distro shows 4.0 released 2015-05-01. (The first pre-release history entry is in 2011.)

So either we had a forum thread two years before the actual software release, or I'm confused.

(I need to know for the Snap! article in the Scratch wiki, which I'm rewriting.)

Nvm, I found the official announcement in the forum thread May 1, 2015, just as the history said. Good grief, it was in alpha for two years?

bharvey wrote:

When was Snap! 4.0?

The forum thread started May 9, 2013.

The HISTORY file in the distro shows 4.0 released 2015-05-01. (The first pre-release history entry is in 2011.)

So either we had a forum thread two years before the actual software release, or I'm confused.

(I need to know for the Snap! article in the Scratch wiki, which I'm rewriting.)

Yes, according to the Wayback Machine Snap! 4.0 was in beta starting at some point between February 19 and March 26, 2013, until it was released some point between April 28 and May 8, 2015 (at which point _nix had already redesigned the website)

Jonathan50 wrote:

according to the Wayback Machine

Thanks! Makes me feel old, that I never thought of looking there.

I don't think there was ever a 4.0 announcement… I have things from Jens for the final RC and then after that for 4.0.1 tweaks.

According to the HISTORY file, the date should be 2015-05-01 https://github.com/jmoenig/Snap/blob/master/HISTORY.md#v40 – or at least that's the closest I can get. (Because the version number line should probably have the date on it…anyway…)

And while writing I searched GitHub, which points to the same date.
https://github.com/jmoenig/Snap/commit/8e92c65cae699004342092133b0a7f99a6f1ed5c#diff-efe46937eeab9deb51d62504ede27fd5

Edit: Oh, I missed you post about history.

Yes, it was in alpha for two years! I remember this because the main bug preventing the alpha release was using an upvar with nested for loops. The scoping was all wrong. We had a talk about this a year and some into the alpha and then it got fixed, and at that point it took until may for the final release.

The 4.0 Saga basically mirrors my undergrad life. It was pretty much just getting started when I started CS10, and it was released a couple weeks (or less) before graduating.

cycomachead wrote:

According to the HISTORY file, the date should be 2015-05-01

Yeah, that's the date I ended up with, too.

Y'all should check out the article,
https://en.scratch-wiki.info/wiki/Snap!_(programming_language)
and let me know what I got wrong.

bharvey wrote:

Y'all should check out the article,
https://en.scratch-wiki.info/wiki/Snap!_(programming_language)
and let me know what I got wrong.

For some reason that image in the BYOB 1.0 documentation rendered super weirdly in whatever PDF viewer you opened it in. (It looked the same for me in Firefox.) I uploaded a new version screenshotted from Preview, which displays it correctly.

djdolphin wrote:

I uploaded a new version

Thanks!

Today's “teach Brian Javascript” problem: What am I doing wrong here?

Edit: buggy.xml
Edit 2: Nvm, I fixed it!

What was the fix you made?

In your first conditional, you could simply write `!world.property` because a missing property is `undefined` which is false.
And in the case of Snap<em>!</em>, `world` isn't a great variable name as it's the global top-level morph, though it shouldn't have been the issue here. (But y'know, why make the reader think about scoping when then don't need to.)

Why was ‘True’ used rather than ‘true’ (or was that the mistake?)

So, yeah, true vs. True, but also world.foo vs. world[“foo”]. This is part of a small string library that'll be in the next maintenance release, mainly because we want it for BJC.

world.foo *is* world[“foo”] (the spec calls them equivalent to each other, I believe), bar the latter allowing special characters which you don't use. Are you sure that was the issue?