Scratch

They weren't? That explains a lot that was going wrong a couple of weeks ago, I never thought this would be the issue. 

For the Mac app, should I give options for varying levels of tolerance to unSnap!ly ( ) features (like the When () > () event) that can be replicated with a hack?

Jens wrote:

a video would be great. You can name the files with any extension you want, doesn't have to be named ".xml". In fact, we might think about officially naming them something else. Any thoughts / suggestions?

   * projects: xpr
   * sprites: xsp
   * blocks: xlb

or would you rather use *.snap ?

I would suggest to use Y rather than X, this giving *.yob for Your own block, *.yop for Your own project, *.yos for Your own sprites ...just to remind this good old Byob

Wow, I've slept through a whole page of messages!  It's great how the Barcelona conference is fanning everyone's excitement about Snap!!

@Jens:  Will there be a way for people who present remotely to participate remotely in the rest of the conference?

@jfb/Jens:  We already have the "relabel" feature that lets you turn "<" into ">" etc. inside a script.  I hereby make the radical proposal that relabel should sometimes include choices not in the palette; in particular, the comparison blocks should include choices "<cs", "=cs", and ">cs" for case-sensitive versions.  (Case-insensitive should of course be the default!)

Your (jfb) other example was variadic anonymous functions.  What I would propose for that situation is that anonymous functions using implicit parameters (substitution into empty input slots) don't allow for complexity, but that explicit formal parameters can be edited with the same right-to-down arrowhead convention as in the block editor to get the long input dialog, in which all the input type declarations can be made.  That way we don't have to invent two different ways to achieve each declaration purpose.  (For example, you might want auto-lambdafication of a procedure-type input to an anonymous function.)

Then we just have to invent a way to make the input slots visible in the lambda, maybe before the body?

OTOH, all this may be unnecessary if I win the argument in progress with Jens about allowing internal procedure definitions within the block editor.

@tb:  Aww, no fair backing out after I used you as an example to nXIII! 

@xly:  I like the .yo* extensions, with the minor reservation that "yob" is a derogatory slang word in British English.  So, @blob, you're the expert: would foo.yob make Britons either get angry or just not take us seriously?  I slightly prefer separate extensions for different kinds of files over .snap for all, because, even though Snap! can tell the type from the XML, human beings can't easily, and shouldn't have to run emacs just to find out what kind of file this is.  And you might have a project and a block library with the same name.

@n: The dumb Scratch forum spell checker doesn't think "emacs" is a word.  You'll make sure that's fixed in 2.0, right?

@hm/Jens:  I hereby reiterate my proposal that we include a generic WHEN < > block in Snap!.

bharvey wrote:

So, @blob, you're the expert: would foo.yob make Britons either get angry or just not take us seriously?

"Expert" says: do not use .yob. 

Elaboration: I'm too, uh, "middle class" to comment on whether anyone would get angry. But it might not help with getting people to take you seriously.

I slightly prefer separate extensions for different kinds of files

How about:

* game.snap
* gobo.sprite.snap
* mindstorms.blocks.snap

The dumb Scratch forum spell checker

Isn't that a feature of your browser? Mine's quite happy with "emacs"...

@tb:  Aww, no fair backing out after I used you as an example to nXIII! 

Are you coming to Barcelona, Brian?

PS: I love how you assume that people will be using Emacs.    (*cough* Viiim! *cough*)

Last edited by blob8108 (2013-03-12 12:13:29)

blob8108 wrote:

"Expert" says: do not use .yob. 

Okay, then, I vote for Jens's original .xpr, etc. -- I say again, the user should be able to determine what's in the file without reading the XML, and should be able to have a project and a block library with the same name.  If y'all want Snap!'s name in it, how about .spp, .spb, etc.?

Are you coming to Barcelona, Brian?

What, you think I'm pushing so hard for the rest of you to come out of disinterested altruism?  I just want to meet you all!  (Maybe especially the über-mysterious hm, who I think is really a BEM on Aldebaran.)

I'm of the generation for which "social networking" means a bunch of people all in the same room.  When I was a kid you couldn't phone someone in another city without the intervention of a human operator.  I was in high school when the first experiment in direct distance dialing was done between New York and Newark, NJ.

@Jens:  Fine, you have my permission to translate WHEN < > into when green flag clicked, forever if.  You can even make the block say WHEN (flag) AND < >.

bharvey wrote:

the über-mysterious hm, who I think is really a BEM on Aldebaran.

I love this idea. 

nXIII wrote:

.snap-project
.snap-sprite
.snap-module

+1!

I hope at least one person gets the above.

I support moving to JSON, but I don't get the joke. 

nXIII wrote:

.snap-project
.snap-sprite
.snap-module

That would work.

(Another thing about my generation is that it makes us nervous when we see extensions of more than three letters.     I'm already out of my comfort zone when the main filename is more than six letters!)

Last edited by bharvey (2013-03-12 13:54:54)

nXIII wrote:

It's a wonderful editor

I have heard of it, but never tried it. Too much love for vim    It does look shiny, though...

blob8108 wrote:

Jens wrote:

suggest a panel discussion with all of you (err, all of us) together onstage.

technoboy10 wrote:

it'd be really fun to do a panel discussion.

Oh yeah, about that. What would you talk about?

Hardware extensions of Snap!?    IDK, what do you think?

bharvey wrote:

contributions by everyone

So kind of like the Chrome store? That'd be fun to program a UI for. 

bharvey wrote:

technoboy10 wrote:

So kind of like the Chrome store?

Oh, I hadn't thought that far ahead.  Yes, for things like hardware interfaces, that would make sense.  But I was thinking of things (such as graphics effects) that would be vetted by Jens and added to the language for everyone, not as options.

Ah, okay.

roijac wrote:

#WayTooLongFileExtensions

Why are long file extensions bad?

roijac wrote:

#WayTooLongFileExtensions

like .an-excessively-long-file-extension, aren't used, because they're too long. .snap-project really isn't too long—even "a-long-filename.snap-project" fits on almost all file browsers without truncation (and you don't need to worry about length at all if you don't show file extensions).

can't we just go for .spjt, .sspt, .smdl or something similar?

Those are really cryptic. Why do you prefer those over .snap-*?

Edit:
I assume the UTIs are:
- edu.berkeley.snap.project
- edu.berkeley.snap.sprite
- edu.berkeley.snap.module
Right?

Last edited by nXIII (2013-03-12 16:59:23)