Discuss Scratch
- Discussion Forums
- » Advanced Topics
- » Snap! user discussion
- BookOwl
- Scratcher
1000+ posts
Snap! user discussion
Basically it is a parsing library that instead of generating a parser from a grammar provides basic building blocks (aka combinators) that can be combined to create more powerful parsers. I figured that parser combinators would work great with Snap! since they are based off of combining functions (or blocks) and I could make the blocks have better names than if I was limited to single word names.parser combinator library and a demo JSON parser.Not ignoring you – I started looking at this project but it'll take a while for me to figure it out. I wrote a
This website has a great explanation of how parser combinators work and may also help you understand the code since I based my project off of that site's code.
who needs signatures
- TruDev
- Scratcher
80 posts
Snap! user discussion
! cloud server. That code is written, and slightly tested, but not yet with real data. We are waiting for school to be over (June 30 in New York) so we don't have any year-end disasters. With luck that will happen the first week of July. At that point, we can take the also-written-and-slightly-tested front end and put it up for users. Of course what will probably happen is a huge disaster that first week and then more debugging. So I think that mid-July is the earliest you can expect to see it, and late August the latest. (We are all totally hoping to be able to show it off at the Scratch conference in Bordeaux July 18-21.)The social site depends on some enhancements to the Snap
Can we get a screenshot at least?
Berkeley isn't putting any money into it – universities are poor, especially these days. In our first National Science Foundation grant for the BJC curriculum, we budgeted $100K in 2012 for the initial Snap! development. (That was a huge chunk out of a $500K total budget, especially given that the NSF solicitation was about teacher professional development, which is where the rest of the money went. We had to work at talking them into it.)
But really, since BYOB3 in 2008, almost all of the development has been Jens volunteering his time.
We are hoping that Jens's current employer will support Snap! development. Nothing is at all settled so far, but people there have made encouraging noises. Cross your fingers.
Then, if universities are poor, what is MIT doing with Scratch?
Since beginnings of 1.4, three accounts so far
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
Sure, go to Can we get a screenshot at least?http://beetleblocks.com – we're stealing their code.
Then, if universities are poor, what is MIT doing with Scratch?I wish I understood how the ST is funded! Most of the early funding was NSF. They recently set up an independent 501(c)3 nonprofit foundation that can accept donations directly for Scratch, but I don't know where the donations come from.
The thing about NSF is that it supports research. New stuff. Once you're an established success, you can of course still get NSF funding for moving in some new direction, but not for keeping on running the same stuff you've always done.
But, our cases are hardly parallel. Scratch is world-famous. We are a young upstart whippersnapper.
Last edited by bharvey (June 26, 2017 17:55:10)
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
This website has a great explanation…Okay, over the weekend…
- TruDev
- Scratcher
80 posts
Snap! user discussion
http://beetleblocks.com – we're stealing their code.Sure, go to
So, mutual code-stealing?
Since beginnings of 1.4, three accounts so far
- TruDev
- Scratcher
80 posts
Snap! user discussion
after all, they didn't even change the about dialog
or the logo
Also, the name's clunky and weird.
or the logo
Also, the name's clunky and weird.
Since beginnings of 1.4, three accounts so far
- TruDev
- Scratcher
80 posts
Snap! user discussion
I'd rather make my own Snap! 3D mod.
Since beginnings of 1.4, three accounts so far
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
We're all friends in this community. The original BYOB was based on the Scratch source code, with the blessings of the ST. And Jens and I are So, mutual code-stealing? delighted when people build specialized applications on top of Snap!. I have six bookmarks set to such variations.
I really have nothing to say about your other comments; we each have our own taste. Personally I'd be happier if BeetleBlocks didn't require the hideous Flat Design that's an option in Snap!. But, whatever.
You can write 3D motion blocks in Snap! itself, you know. The only thing that really required a mod is the ability to write a local file in the format 3D printers like.
- TruDev
- Scratcher
80 posts
Snap! user discussion
delighted when people build specialized applications on top of Snap!. I have six bookmarks set to such variations.We're all friends in this community. The original BYOB was based on the Scratch source code, with the blessings of the ST. And Jens and I are
I really have nothing to say about your other comments; we each have our own taste. Personally I'd be happier if BeetleBlocks didn't require the hideous Flat Design that's an option in Snap!. But, whatever.
I personally like the Flat Design, but whatever…
You can write 3D motion blocks in Snap! itself, you know. The only thing that really required a mod is the ability to write a local file in the format 3D printers like.
Can you show me how or link me to someone who does?
Since beginnings of 1.4, three accounts so far
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
Do you know trig? Can you show me how or link me to someone who does?
- TruDev
- Scratcher
80 posts
Snap! user discussion
Do you know trig?
Oh… So that's what you mean…
First, yes I know trig, second, I'd rather use a 3D engine someone already wrote in Scratch.
EDIT:—
Also, Scratch-written 3D engines tend to be slow, is this different in Snap!?
Also, Jens does coding while you answer questions?
Last edited by TruDev (June 22, 2017 19:06:40)
Since beginnings of 1.4, three accounts so far
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
!?I dunno, you'd have to try it. But I think you can do it more cleanly when you can write custom reporters as well as custom commands. Scratch-written 3D engines tend to be slow, is this different in Snap
Also, Jens does coding while you answer questions?Mostly what I do is collaborate on the design details (everything we stole from Scheme is my design, mostly, e.g. grey rings) and documentation (the help screens for the non-Scratch blocks as well as the manual). But right now almost all my time is going into the curriculum (http://bjc.edc.org). We're doing our third huge rewrite; if you look at http://bjc.edc.org/mini17 you can see this year's rewritten Units 1 and 2, and tomorrow we're uploading Unit 3 there. I did write some of the list operators, and some of the libraries using JSFunction. But yeah, mostly the code is Jens, with a few contributions from other people, but not many, because there aren't that many people Jens trusts.
Edit: Answering questions is what I do to take a break from curriculum writing!
Last edited by bharvey (June 22, 2017 20:29:35)
- TruDev
- Scratcher
80 posts
Snap! user discussion
I dunno, you'd have to try it. But I think you can do it more cleanly when you can write custom reporters as well as custom commands.
Ok
Mostly what I do is collaborate on the design details (everything we stole from Scheme is my design, mostly, e.g. grey rings) and documentation (the help screens for the non-Scratch blocks as well as the manual). But right now almost all my time is going into the curriculum (http://bjc.edc.org). We're doing our third huge rewrite; if you look at http://bjc.edc.org/mini17 you can see this year's rewritten Units 1 and 2, and tomorrow we're uploading Unit 3 there. I did write some of the list operators, and some of the libraries using JSFunction. But yeah, mostly the code is Jens, with a few contributions from other people, but not many, because there aren't that many people Jens trusts.
So Jens thinks that if anyone touches his code, it'll break or something?
Edit: Answering questions is what I do to take a break from curriculum writing!
So by asking a ridiculously stupid amount of questions, I'm distracting you from your job?
Since beginnings of 1.4, three accounts so far
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
Yeah, basically. Except for a few people. So Jens thinks that if anyone touches his code, it'll break or something?
So by asking a ridiculously stupid amount of questions, I'm distracting you from your job?Well now it's evening, so you're distracting me from reading.
- TruDev
- Scratcher
80 posts
Snap! user discussion
Well now it's evening, so you're distracting me from reading.
Reading what? Just any books?
Since beginnings of 1.4, three accounts so far
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
[wayofftopic]Right now, Reading what? Just any books?The Rise and Fall of D.O.D.O.[/wayofftopic]
- cycomachead
- Scratcher
100+ posts
Snap! user discussion
Grouped Variadic Inputs: (shouldn't this be in the dev thread?)
The palette should show either 0 or 1 expansions of the inputs, IMO. It depends on the use case and intent of the block, I think for what makes sense. However, some of the primitives (i.e. LIST and JOIN do deviate from this standard, but that's OK.)
I'm not sure whether such a setting needs to be settable by users, at least not initially.
(Technically, this would also allow you expand the text multiple times, but you wouldn't need to. We could overcome that by either having a flag with each part of a variadic group OR by specifying how many times you can expand a group. So an outer group is max 1 and the inner group would be unlimited. A max length on variadic inputs would be useful in other cases too.)
But what I meant was, what does the finished block look like to users, in the palette?
The palette should show either 0 or 1 expansions of the inputs, IMO. It depends on the use case and intent of the block, I think for what makes sense. However, some of the primitives (i.e. LIST and JOIN do deviate from this standard, but that's OK.)
I'm not sure whether such a setting needs to be settable by users, at least not initially.
This seems like a useful, but secondary problem. However, I think we can solve this in some generic way. I've been mulling over the idea, recently, aside from this thread. However, if we use the same block editor UI (with minor tweaks) to edit the group, then you could accomplish this if we allowed nested groups. i.e you'd have some text, and then an input which is also variadic. Also, there should be a way to specify something that appears only the first time, like the words “with inputs” in the CALL block.
(Technically, this would also allow you expand the text multiple times, but you wouldn't need to. We could overcome that by either having a flag with each part of a variadic group OR by specifying how many times you can expand a group. So an outer group is max 1 and the inner group would be unlimited. A max length on variadic inputs would be useful in other cases too.)
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
I was more worrying about how to tell the user of the block what clicking the arrows will do – that it expands more than the immediately preceding input slot. But maybe that's not important?
There's a lot to think about. Someone once proposed an expandable HTTP block in which each right click would expose a different aspect of the connection, with text before each slot labelling it. That same idea would be great for Uri Leron's lesson to introduce procedure as object. He started with a procedure with no inputs that draws a row of four squares with a little space between them. Then he'd have students add inputs one at a time:
SQUARES NUMBER: ( )
SQUARES NUMBER: ( ) SIZE: ( )
SQUARES NUMBER: ( ) SIZE: ( )
SQUARES NUMBER: ( ) SIZE: ( ) SPACING: ( )
and so on, until finally asking them to show an arbitrary shape, not necessarily a polygon, so they'd want to use a procedure as input and he could teach them how to RUN it. My point here is that it'd be great if all those inputs were optional with defaults, so you could expose them one at a time, with only one set of arrows, not one per input.
There's a lot to think about. Someone once proposed an expandable HTTP block in which each right click would expose a different aspect of the connection, with text before each slot labelling it. That same idea would be great for Uri Leron's lesson to introduce procedure as object. He started with a procedure with no inputs that draws a row of four squares with a little space between them. Then he'd have students add inputs one at a time:
SQUARES NUMBER: ( )
SQUARES NUMBER: ( ) SIZE: ( )
SQUARES NUMBER: ( ) SIZE: ( )
SQUARES NUMBER: ( ) SIZE: ( ) SPACING: ( )
and so on, until finally asking them to show an arbitrary shape, not necessarily a polygon, so they'd want to use a procedure as input and he could teach them how to RUN it. My point here is that it'd be great if all those inputs were optional with defaults, so you could expose them one at a time, with only one set of arrows, not one per input.
- cycomachead
- Scratcher
100+ posts
Snap! user discussion
I was more worrying about how to tell the user of the block what clicking the arrows will do – that it expands more than the immediately preceding input slot. But maybe that's not important?
There's a lot to think about. Someone once proposed an expandable HTTP block in which each right click would expose a different aspect of the connection, with text before each slot labelling it. That same idea would be great for Uri Leron's lesson to introduce procedure as object. He started with a procedure with no inputs that draws a row of four squares with a little space between them. Then he'd have students add inputs one at a time:
SQUARES NUMBER: ( )
SQUARES NUMBER: ( ) SIZE: ( )
SQUARES NUMBER: ( ) SIZE: ( )
SQUARES NUMBER: ( ) SIZE: ( ) SPACING: ( )
and so on, until finally asking them to show an arbitrary shape, not necessarily a polygon, so they'd want to use a procedure as input and he could teach them how to RUN it. My point here is that it'd be great if all those inputs were optional with defaults, so you could expose them one at a time, with only one set of arrows, not one per input.
Yeah, I proposed the crazy HTTP block a few times, though I'm sure others have as well. I probably wasn't even the first.
For this specific case, in my model, I would have 1 variadic group, that contains a nested group, and another nested group. [number [size ]].
That seems a bit tedious to build, but it preserves the prerequisite chain of inputs, so there's some logical connection to the nesting.
However, in the same model, you could have it such that you use 3 distinct input groups , and you could toggle those individually, but I imagine it would look quite funny as that would lead to an input with 3 expandable toggles right next to each other.
I think if you didn't need the inputs to be chained, you're essentially exposing keyword arguments, which could be nicely implemented as a variadic group of
A slight challenge in al of this, is how to expose the inputs to the programmer. Obviously, they'd be some form of list, and it seems natural that they'd be nested. This probably isn't a huge deal, since people working with crazy input types are probably comfortable with nested lists, but it's worth considering. My thought process was to approach this is a way of building nearly any possible input grouping, rather than making just a few cases simple. IMO, it seems that if we go down the route of providing a really powerful feature like this, we should aim for maximal flexibility, because the primary users of such a feature will the advanced kids, and us making curricula and libraries.
Last edited by cycomachead (June 29, 2017 06:11:41)
- bharvey
- Scratcher
1000+ posts
Snap! user discussion
Yes, well, I think you're right that we should move this to dev. We've probably said enough to convince TruDev that this isn't a trivial design issue! (That's how we ended up talking about this on user.)