bharvey wrote:

BookOwl wrote:

I wrote a 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.

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.

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.

bharvey wrote:

The social site depends on some enhancements to the Snap! 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.)

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?

TruDev wrote:

Can we get a screenshot at least?

Sure, go to 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.

BookOwl wrote:

This website has a great explanation…

Okay, over the weekend…

bharvey wrote:

Sure, go to http://beetleblocks.com – we're stealing their code.

So, mutual code-stealing?

after all, they didn't even change the about dialog

or the logo

Also, the name's clunky and weird.

I'd rather make my own Snap! 3D mod.

TruDev wrote:

So, mutual code-stealing?

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 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.

bharvey wrote:

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 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.

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?

TruDev wrote:

Can you show me how or link me to someone who does?

Do you know trig?

bharvey wrote:

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?

TruDev wrote:

Scratch-written 3D engines tend to be slow, is this different in Snap!?

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.

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!

bharvey wrote:

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?

TruDev wrote:

So Jens thinks that if anyone touches his code, it'll break or something?

Yeah, basically. Except for a few people.

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.

bharvey wrote:

Well now it's evening, so you're distracting me from reading.

Reading what? Just any books?

TruDev wrote:

Reading what? Just any books?

[wayofftopic]Right now, The Rise and Fall of D.O.D.O.[/wayofftopic]

Grouped Variadic Inputs: (shouldn't this be in the dev thread?)

bharvey wrote:

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.

bharvey wrote:

Also, there should be a way to specify something that appears only the first time, like the words “with inputs” in the CALL block.

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.

(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.)

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.

bharvey wrote:

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.

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.)