Snap! Team development discussion, vol. 2

bharvey

_nix wrote:
But… no passports.

Hmm. I don't think I could help with that one.

P.S. Passports plural because your parents would come too?

Last edited by bharvey (Feb. 14, 2019 22:16:34)

Hardmath123

bh wrote:
Hypothetical question: Suppose there were a Snap! conference in Germany in October. Who'd come?

Ooh, I suppose it depends on who's paying…

bharvey

Hardmath123 wrote:
Ooh, I suppose it depends on who's paying…

So, that means yes iff you don't have to pay the costs?

(It's extremely unlikely that we would be able to provide scholarships for our entire gang; you're a big kid.)

Last edited by bharvey (Feb. 15, 2019 03:07:04)

Hardmath123

bharvey wrote:
Hardmath123 wrote:
Ooh, I suppose it depends on who's paying…
So, that means yes iff you don't have to pay the costs?

Yes if. Would also need to check to make sure I wouldn't miss too much school… >_<

(It's extremely unlikely that we would be able to provide scholarships for our entire gang; you're a big kid.)

Well, yes, you should definitely put limited funds towards scholarships current K12 students who want to go. :-)

Though, if you decide instead to host the conference at Berkeley… or even Stanford…

cycomachead

Hardmath123 wrote:
Well, yes, you should definitely put limited funds towards scholarships current K12 students who want to go. :-)

Though, if you decide instead to host the conference at Berkeley… or even Stanford…

Where's that?

But also, I'm sure you could make missing school work. There'd be a way to submit things, and surely someone at that CS department knows where to find the money.

Last edited by cycomachead (Feb. 15, 2019 05:54:37)

s_federici

bharvey wrote:
Hypothetical question: Suppose there were a Snap! conference in Germany in October. Who'd come?

I'm really tempted.

_nix

bharvey wrote:
_nix wrote:
But… no passports.
Hmm. I don't think I could help with that one.

Yeah, I know. There could be some trouble getting passports, but maybe with some luck it's possible, so let's assume so for the sake of discussion.

PS Basically.
PPS Ooh, back to your old profile picture? This is the one I've known you by for, well, as long as I've known you, honestly. But I've only known you for, like, a third the time you've been on Scratch. So out of curiosity's sake, was there an older profile picture you used to use?

══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

bharvey

_nix wrote:
So out of curiosity's sake, was there an older profile picture you used to use?

Yeah, I started with my official faculty-photo-wall photo:

s_federici

(This is a duplicate of a post in the “Snap user discussion”. Sorry for this, but no one was able to help me there)

I quickly need help in order to make a working fast javascript version of the FOR EACH block in project https://snap.berkeley.edu/snapsource/snap.html#present:Username=s_federici&ProjectName=average%20test%20(running%20but%20not%20working).

If you try to run the slow standard version of the FOR EACH block on list {1,2,3} (second script) you correctly get 6 as the sum of the three items of the list.

Instead, the fast javascript version, from space_elephant, gets 9 as the sum. I don't know much on how to implement javascript functions for Snap. Can someone help me in order to correctly implement the fast javascript FOR EACH?

Thanks in advance

Last edited by s_federici (March 11, 2019 23:31:48)

_nix

s_federici wrote:
Can someone help me in order to correctly implement the fast javascript FOR EACH?

Just glancing at the implementation, what I notice is that you are effectively setting the variable to the final value right away. Here's what's really happening in your code:

Sets variable to list[0] = 1
Tells Snap! to run given script when possible
Sets variable to list[1] = 2
Tells Snap! to run given script when possible
Sets variable to list[2] = 3
Tells Snap! to run given script when possible
Snap! gets a chance to run your script…
Says variable = list[2] = 3
Says variable = list[2] = 3
Says variable = list[2] = 3

So by the time Snap! actually runs the script, the variable has already been set to the final value.

What you need to do is a process more like this:

Sets variable to list[0] = 1
Tells Snap! to run given script when possible
(Waits until Snap! runs the script)
Snap! gets a chance to run your script…
Says variable = list[ = 1
(The script has been run, so passes back control to the for loop…)
Sets variable to list[1] = 2
(…etc…)

Essentially, JavaScript does not automatically wait for the Snap! script to finish; you need to explicitly tell it to.

Unfortunately, um, I have no idea how. I haven't worked with JS functions in a very long time, so I'm not sure how to wait for the given script to be evaluated and finished. Since JS doesn't have a builtin keyword to wait for a function to complete (okay, that's a lie, there's async/await, but that's not available or relevant here), you will end up needing a recursive function. Here's what it could look like:

function loop(n, max) {
  if (n >= max) return;
  evaluate(...).oncomplete = function() {
    loop(n + 1);
  };
}

(Of course, the “.oncomplete = function()” is pseudocode – I don't know what would go in place there, but that's the approximate idea.)

══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

cycomachead

I just tried this. I'm not actually sure it's the for-each that's broken. The way you're invoking a function immediately has challenges with blocks like SAY, which explicitly take a long time to run.

I'd have to re-read the source to better figure out what's going on.

On the other hand, there's no reason you can't use the native fast map to do the same thing – providing you are willing to forgo the SAY block.
See this project:
https://snap.berkeley.edu/snapsource/snap.html#present:Username=cycomachead&ProjectName=using%20fast%20map%20with%20commands

The “native” fast map has the same challenges when you put a say block in there.

Jonathan50

cycomachead wrote:
I just tried this. I'm not actually sure it's the for-each that's broken. The way you're invoking a function immediately has challenges with blocks like SAY, which explicitly take a long time to run.

I'd have to re-read the source to better figure out what's going on.

On the other hand, there's no reason you can't use the native fast map to do the same thing – providing you are willing to forgo the SAY block.
See this project:
https://snap.berkeley.edu/snapsource/snap.html#present:Username=cycomachead&ProjectName=using%20fast%20map%20with%20commands

The “native” fast map has the same challenges when you put a say block in there.

If you're happy without SAY, you could just use invoke, which is what s_federici originally did. But, if all you're doing is finding the average of the items of a list, you might consider rather using fast COMBINE (in the same library):

((⚡️ combine ((() + ()) @addInput) with (numbers) :: list) / (length of (numbers) :: list))

(Shouldn't the WITH come before the reporter input?)

Last edited by Jonathan50 (March 12, 2019 07:49:45)

Not yet a Knight of the Mu Calculus.

s_federici

cycomachead wrote:
I just tried this. I'm not actually sure it's the for-each that's broken. The way you're invoking a function immediately has challenges with blocks like SAY, which explicitly take a long time to run.

I'd have to re-read the source to better figure out what's going on.

On the other hand, there's no reason you can't use the native fast map to do the same thing – providing you are willing to forgo the SAY block.
See this project:
https://snap.berkeley.edu/snapsource/snap.html#present:Username=cycomachead&ProjectName=using%20fast%20map%20with%20commands

The “native” fast map has the same challenges when you put a say block in there.

Thanks cycomachead, and thanks to _nix too for their analysis. I think I just hadn't realized that I could embed a script inside the “fast map” ring by using a command ring instead of the available reporter ring. The foreach is now working fine. I had hoped I could reduce a bit more the running time, but even passing from about 11 mins to 6 mins for a list of 400k items is a good result for me. I guess javascript cannot do much better when interacting with Snap without creating an ad-hoc block.

bharvey

Jonathan50 wrote:
(Shouldn't the WITH come before the reporter input?)

Indeed. I'll make a note to fix that!

bharvey

Need help with SVG costume. The costume “abby d” is missing its bottom half. I learned in Illustrator that its “artboard” is dimensioned wrong, but when I fix that (“fit to artwork bounds”), the costume is still imported incorrectly. Its rotation point is wrong, and it gets clipped when size is set to more than 100%. Here is the costume I think I fixed:

https://snap.berkeley.edu/abby-d.svg

The one in the library is at

https://snap.berkeley.edu/snapsource/Costumes/abby-d.svg

Help! (There are others like this, but I hope that once I understand the problem they'll all be easy to fix.)

EDIT: I solved the problem by just downloading it from Scratch again.

But I'd still like to understand what the issue is.

Last edited by bharvey (April 18, 2019 08:18:30)

PullJosh

bharvey wrote:
Need help with SVG costume. The costume “abby d” is missing its bottom half. I learned in Illustrator that its “artboard” is dimensioned wrong, but when I fix that (“fit to artwork bounds”), the costume is still imported incorrectly. Its rotation point is wrong, and it gets clipped when size is set to more than 100%. Here is the costume I think I fixed:

https://snap.berkeley.edu/abby-d.svg

The one in the library is at

https://snap.berkeley.edu/snapsource/Costumes/abby-d.svg

Help! (There are others like this, but I hope that once I understand the problem they'll all be easy to fix.)

EDIT: I solved the problem by just downloading it from Scratch again. But I'd still like to understand what the issue is.

The problem is the SVGs “viewBox”. The correct version, your first link, has the following:

<svg viewBox="0 0 62.807 200.015" ...etc></svg>

The broken version has the following:

<svg viewBox="-1 -1 266 122" width="266" height="122" ...etc></svg>

You should replace the incorrect viewBox attribute in the broken SVG with the correct value from the working SVG. You'll also want to update width and height to match your changes to viewBox.

(I don't know how to do this in any particular vector editor, but you can always open the SVG in a text editor and do it yourself.)

Convert your Scratch projects to JavaScript automatically with Leopard!

bharvey

PullJosh wrote:
The problem is the SVGs “viewBox”.

Thanks. For some reason, changing the viewBox (what they call the “artboard”) in Illustrator also changes other things in mysterious ways. So, this is an unsolicited endorsement of Inkscape, which does the right thing in an intuitive manner.

blob8108

It's weird to me how few of y'all in the US have passports.

tosh · slowly becoming a grown-up adult and very confused about it

s_federici

blob8108 wrote:
It's weird to me how few of y'all in the US have passports.

?

bharvey

s_federici wrote:
blob8108 wrote:
It's weird to me how few of y'all in the US have passports.
?

He's reacting to people saying that the lack of a passport is an obstacle to attending SnapCon in Germany.

Bear in mind, Tim, that minors (which our gang mostly is) travel on their parent's passport. Those adults who can afford air fare typically do have passports, but that isn't everyone.

Discuss Scratch