Snap! Team development discussion, vol. 2

bharvey

blob8108 wrote:
I think it would take me a week just to understand the current interpreter

I wasn't counting that week. That week is an investment in all the other projects you could do!

blob8108

bharvey wrote:
That week is an investment in all the other projects you could do!

Haha!

Seriously, though: I don't think Jens wants me mucking about in his interpreter…

bharvey

blob8108 wrote:
Seriously, though: I don't think Jens wants me mucking about in his interpreter…

It's true that Jens would much rather do everything himself. But you're not 12, and you have a track record, especially flowy, and if you make Snap! competitive with JS for computation-intensive projects, and your code is beautiful, I think he'll pull it. (He'll also yell at me, but he won't yell at you; being proxy-yelled-at is one of my roles in the partnership. Not so much lately, but back when Nathan was a 12-year-old smartass…)

EDIT: Oh, and if you understand the 90/10 rule and follow up on the bugs later.

Last edited by bharvey (Jan. 30, 2017 01:26:38)

blob8108

Okay, Brian; because I'm feeling nice, today you get scratchblocks export, the feature no-one wanted or asked for!

EDIT: if anyone feels like testing the above, that'd be grand. I don't have any real-world Snap! scripts to test on.

bharvey wrote:
being proxy-yelled-at is one of my roles in the partnership. Not so much lately, but back when Nathan was a 12-year-old smartass…)

I don't think flowy really counts; it never worked half as well as I wanted it to, and you could hardly call it a compiler either! Nevertheless, you've got me interested… I'll add it to the stack of projects.

Do you have some benchmarks/projects that you'd like to be made faster? That'd save me a ton of time.

One of the barriers is I really do need a mechanism for detecting whether a block has changed. That way I can support liveness, but still cache compilation results so I don't have to re-compile the warp block every time. (Assuming we do restrict this to warp blocks.) Is there a mechanism for detecting this? trackChanges perhaps?

Last edited by blob8108 (Jan. 30, 2017 11:05:50)

Jens

I love your idea to compile warped sections of code!! Sure, I'll (proxy-) yell at anyone all the time, but that's often just a way to display my excitement :-)
Let me know anything I can supply to help!

Jens

Also, yes, I'm sure you do know much more about compilation that I do!

Jens

So, are you going to go for it? (can't wait!)

blob8108

blob8108 wrote:
Okay, Brian; because I'm feeling nice, today you get scratchblocks export, the feature no-one wanted or asked for!

EDIT: if anyone feels like testing the above, that'd be grand. I don't have any real-world Snap! scripts to test on.

Jens blessed my PR (yay!). In the meantime you can test it here: http://test.tjvr.org/snap-sb/snap.html

Jens wrote:
So, are you going to go for it?!

I hadn't realised you'd be so excited

Right now I need to think about it (and finish my final year project

). But I might come up with something.

The main problem is I think it would involve rewriting large parts of the interpreter. I suspect a rewritten interpreter is beyond the size of things you want and would accept a PR for!

BookOwl

Script:

Scratch blocks:

I think that there is a bug in your code, blob.

Edit: Completely unrelated, but tinypic is just awful. When will cubeupload come back on line?

Last edited by BookOwl (Jan. 30, 2017 19:32:43)

NitroCipher

Is there any talk of a re-write of Snap! once scratch 3 comes out?

PullJosh

NitroCipher wrote:
Is there any talk of a re-write of Snap! once scratch 3 comes out?

What would be the point? Snap! and Scratch are entirely different program based on completely separate codebases.

-Io-

BookOwl wrote:
Script:
http://i66.tinypic.com/2w5ooz8.png

Scratch blocks:
I think that there is a bug in your code, blob.

Edit: Completely unrelated, but tinypic is just awful. When will cubeupload come back on line?

You can check out their twitter, though they aren't very active, but they noticed the problems. They also have a Scratch account, but they stopped using it.

Relating to buggy Scratchblocks export, (EDIT: some) upvars seem to be exported as an up arrow instead of something like ((item)::list), which IIRC is the way we agreed to represent them a while ago.

Example:

And yet another problem, dialogs are not a nice way of outputting code. At least in Firefox, they aren't multiline.

Last edited by -Io- (Jan. 30, 2017 19:53:26)

BookOwl

-Io- wrote:
BookOwl wrote:
Script:
http://i66.tinypic.com/2w5ooz8.png

Scratch blocks:
I think that there is a bug in your code, blob.

Edit: Completely unrelated, but tinypic is just awful. When will cubeupload come back on line?
You can check out their twitter, though they aren't very active, but they noticed the problems. They also have a Scratch account, but they stopped using it.

OK, that's good news.

-Io- wrote:
Relating to buggy Scratchblocks export, (EDIT: some) upvars seem to be exported as an up arrow instead of something like ((item)::list), which IIRC is the way we agreed to represent them a while ago.

Example:
And yet another problem, dialogs are not a nice way of outputting code. At least in Firefox, they aren't multiline.

They aren't multiline in Safari either.

PullJosh

BookOwl wrote:
-Io- wrote:
And yet another problem, dialogs are not a nice way of outputting code. At least in Firefox, they aren't multiline.
They aren't multiline in Safari either.

Nor anywhere else. Built-in dialog boxes are great for development, but it makes much more sense to use a morphic popup for the real deal.

bharvey

PullJosh wrote:
NitroCipher wrote:
Is there any talk of a re-write of Snap! once scratch 3 comes out?
What would be the point? Snap! and Scratch are entirely different program based on completely separate codebases.

Although I'd say the answer is definitely “no,” it's not a silly question. Scratch-in-Blockly is a proof of concept, showing that Blockly can host languages that don't look like Blockly; it can, sort of, play the role of Morphic as the substrate for a language. And it has definite advantages, such as very active efforts to support vision-impaired users.

But Jens has always been very, very resistant to letting Snap! be dependent on any third party software; he won't even use jsquery, which everyone uses and which therefore is surely not going to disappear. By contrast, Google has been known to discontinue software projects. So, that's why “no.”

bharvey

blob8108 wrote:
I don't have any real-world Snap! scripts to test on.

Start with the ones in the Examples section, in the Open dialog box. There are even more example projects here.

I don't think flowy really counts

But Jens was really excited by it and, in particular, liked your code in it.

Do you have some benchmarks/projects that you'd like to be made faster? That'd save me a ton of time.

Well, there's the SICP picture language project. (Hit space bar to run the slow part, although it's already infinitely faster than it was in BYOB.)

One of the barriers is I really do need a mechanism for detecting whether a block has changed. That way I can support liveness, but still cache compilation results so I don't have to re-compile the warp block every time. (Assuming we do restrict this to warp blocks.) Is there a mechanism for detecting this? trackChanges perhaps?

On a quick pass through blocks.js the only thing I see is a bunch of places that do

this.cachedInputs=null;

That has a somewhat different purpose but maybe it will also serve your purposes.

trackChanges is about setting the dirty region for screen updating; I think it's too broad for your purposes. (E.g., just moving an entire script over a bit counts as a change for that purpose.) There's a big comment about it in morphic.js.

P.S. Jens didn't even yell at me for encouraging you.

P.P.S. Thanks!

blob8108

bharvey wrote:
he won't even use jsquery, which everyone uses and which therefore is surely not going to disappear

Nah; no-one uses jQuery anymore! The hip new framework is vanilla-js.

blob8108

BookOwl wrote:

-Io- wrote:
Relating to buggy Scratchblocks export, (EDIT: some) upvars seem to be exported as an up arrow instead of something like ((item)::list), which IIRC is the way we agreed to represent them a while ago.

Thanks both! Those should be fixed now

Let me know if you find any more bugs!

Regarding the dialog: you're absolutely right that a Morphic dialog would be a better way to go (assuming Morphic does, now, in fact, support copy/paste everywhere?). But I'm not interested in fixing that one myself! If someone else wants to send a PR (or even a meta-PR!), go right ahead

Last edited by blob8108 (Jan. 30, 2017 22:32:58)

bharvey

blob8108 wrote:
The hip new framework is vanilla-js.

Oh. Don't tell Jens; he'll only say “See?”

jokebookservice1

bharvey wrote:
blob8108 wrote:
The hip new framework is vanilla-js.
Oh. Don't tell Jens; he'll only say “See?”

Looks like vanilla-js is just a joke. It is just vanilla JS. Pretty funny joke albeit!

Discuss Scratch