Scratch

roijac wrote:

any chance of regex features? 

Nah, this is a perfect example of something you should be able to write for yourself in Snap!  But of course we should have a library repository so that when you implement regexps other people can use your code.

Edit:  ... and of course the same argument applies to my word-and-sentence suggestion earlier.  So we should just do strings, like Scratch, and I should provide a sentence library.

Last edited by bharvey (2012-03-05 11:36:26)

Jens wrote:

bharvey wrote:

joefarebrother wrote:

If you drag a reporter that reports a list onto the left/right arrows of a variadic input slot, it should evaluate the list as the inputs it takes.

Oh, that is a cool idea!  Then we wouldn't need a special case for call and run.  Jens?  What do you think?

Ummm..., well..., you know that's exactly what my first version did,and I still believe it's the right thing, but you didn't like it so I disabled it. The good thing is that I only need to take out a single line of code to re-enable this feature 

But you're right, and now I remember that's the reason why, in fact, both of us wound up not liking it, that this also removes the variadic slot's label which makes the resulting block non-obvious to understand. And that's why we decided to turn the "... WITH INPUT LIST" variations into separate blocks. But if we come up with a better, more concise solution, I'm perfectly willing to reconsider.

maybe it could look different to distinguish a single input from a list acting as the input to the varadic slot (sorta like the grey border system)

scimonster wrote:

Lol I was just thinking maybe I should make a RegExp project for Scratch. I could probably make a Snap! version too when my project and Snap! are done.

i was thinking this too a couple of weeks ago but delayed it for scratch since , after doing some tests, it would probaly be to slow to work properly but Snap! may be fast enough...

bharvey wrote:

joefarebrother wrote:

maybe it could look different to distinguish a single input from a list acting as the input to the varadic slot (sorta like the grey border system)

Yeah.  The list-valued expression replaces the input slot, but the arrows remain, but they're greyed out and attached to the expression somehow:

http://byob.berkeley.edu/variadic.png

There is a small voice in the back of my head saying "Overengineered!"  I can't decide if this will really be understandable or not.  We sure want to make it hard to do by accident.

Maybe we should redesign the way the multiple-input slot looks. Since it's really just a convenience for constructing a list and immediately passing it as an argument, I think it should actually look like an embedded list block (minus the word "list"). That way, it would be very clear when you replace it with a block that you're passing the block instead of the list, rather than as one item of the list.

Brian, I'm guessing you and Jens are aware of how the other graphical dev environments handle block search and insertion. Just in case you're not, I'd like to recommend that you borrow from StarLogo TNG since, IMO, it has the smoothest workflow among the environments that I follow (Scratch, BYOB, Snap!, StencylWorks) when it comes to finding a block and placing it. I've made a quick screencast to demonstrate this for anyone caring to see. I realize that UI/usability is something that will be looked at when the project is closer to release, but it might help to keep this in mind.

http://www.scratch.mit.edu/ext/youtube/?v=Koh4ZYxmrAo

I can see how such a features is convenient, but I'm not overly enthusiastic about the way it's implemented. In particular I don't like how when you type text into a combo box it shows you subsets of blocks's labels instead of the blocks themselves. But I'm sure this can be changed.

My first Snap! game (?)
When Turtle hits Turtle2, Turtle2 hides
Turtle is pivoted with brodcast dirleft and dirtir
Shoot wit Green Flag

xly wrote:

My first Snap! game (?)
When Turtle hits Turtle2, Turtle2 hides
Turtle is pivoted with brodcast dirleft and dirtir
Shoot wit Green Flag
http://www.xleroy.net/ByobTuto/New/HitTarget0102.jpg

Save game link please?

xly wrote:

rookwood101 says "Save game link please?"
I don't know how to do that ! Please give me the method.

Click on the little pencil thingy at the top and choose "save."  Then, look at the URL up above the browser window, and it should be this huge long thing, which you copy (select all, control/command A, then copy, control/command C), then paste it in here!

(Yes, this is a horrible kludge.  It'll get better.)

@bharvey

(Yes, this is a horrible kludge.  It'll get better.)


Follow the link above, which displays 3 sceen copies.
Click on the first screen.
Then click on Download.
This zip file contains 1 - hitarget.txt which is copy of the project link, 2 - copy of the htm pages given by Chrome Save.

@Jutros

You can actually just bookmark the URL (with the hash part) in your browser, and access your projects as bookmarks. The red "obsolete!" blocks you see are probably the result of the blocks dictionary not being updated properly, that should be fixed.

I was able to create a (round (number) ) block for Snap.

I realized Snap has no round block, so I made it myself.

Who wants it?

bharvey wrote:

nXIII wrote:

Since it's really just a convenience for constructing a list and immediately passing it as an argument

This is true from an implementor's standpoint, but not necessarily from a user's standpoint.  I really like your picture for the case of CALL because of the "with inputs" in its name, but think about a case like SCRIPT VARIABLES.  The distinction between one variable name (which would have arrows after it) and a list of names of variables (which wouldn't) would be seriously non-obvious.  That's the most extreme example, but even for JOIN WORDS, say, it wouldn't be obvious whether an expression is providing one word or a list of words.

well script variables is a varadic [b]upvar[b/] not a varadic [b]input[b/]