Scratch

To Jens & bharvey

I've finished a tutorial application -Tangram - which extensively uses the combination of "property OF sprite" AND "methods". It shows how any sprite ("command" in this example can change the main properties of any other sprite. If it can help, see scripts here :

http://www.xleroy.net/ByobTuto/thumbnails.html

Congratulations for your efforts to continuously improve Byob, in all extents.

To Jens&bharvey

See Error report : http://www.xleroy.net/ByobErrors/Tangram-error.gif

See also the application Byob-Tangram which applies "method" and "property OF sprite" for a multi-sprite application.

http://www.xleroy.net/ByobTuto/thumbnails.html

nXIII wrote:

My awesome block maker idea:
The 'default value' slot in the long input name slot should be a block argument of the selected type. That way, you can type a number in the 'number' type, a string in the 'string' type, etc., but you can also put blocks in these default values, as well as being able to put reporter blocks in the 'reporter' type and commands in the 'command' type. A mockup:

(full size)
You should also be able to give a default value for inputs that are a list. You click the left arrow, and the new input has the default value given in the block editor.

Did anyone see this?

Last edited by MathWizz (2010-06-21 14:35:52)

Jens wrote:

That's indeed on our wish list, especially the part that you can put other blocks into the default values, and to also allow default values for variadic (multiple) inputs! But I'm not so sure when I'll get around to implement it 

Keeeewl!

Huh?! that's certainly weird and very interesting, John. But I cannot reproduce it in 2.99.020. Can you perhaps send me your project or - better yet - post a bug report to our Bugzilla site: byobugs.com

Thanks!

Hi henley,

that's an excellent question, thanks for asking it! And, no, this certainly doesn't make you sound like a noob at all.

The term "predicate" means different things in different contexts, in BYOB a predicate is a reporter of a Boolean value. Boolean values are TRUE or FALSE, and the functions (reporters) that return Boolean values are called predicates:

[blocks]
<(  <=>  )>
<(  <>>  )>
<(  <<>  )>
<<  <and>  >>
<<  <or>  >>
<<  <not>  >>
[/blocks]

are all called predicates in BYOB, because they answer either TRUE or FALSE. The reason why we're calling them predicates instead of Booleans is that in BYOB 3 the new thing is first class procedures and higher order functions. A higher order function is a block that takes other blocks as inputs and can also return blocks.

So, how can you tell if you need a Boolean or a predicate? The rule of thumb is this: Ask yourself if you're going to want to test the Boolean expression (the hexagonal green reporter block) more than once or at a later time. If that's the case then you're probably talking about a predicate.

Examples for predicates are the diamond shaped blocks that go into such loops as

[blocks]
<forever if>
<end>

<repeat until>
<end>

<wait until>
[/blocks]

because the hexagonal block will be executed anew in each loop cycle.

Ah, I'm not good at explaining these things. I'll let Brian take over now 

Last edited by Jens (2010-06-21 19:55:35)

2.99.021 is a bug fix release, most notably ESC-click finally works on the Mac! 

Jonathanpb wrote:

When do you expect BYOB 3 to come out? 

Our target date is the Scratch conference in August.

The releases between now and then will be bug fixes and speedups; new features (of which we have a wish list) will wait until 3.1 (hard as it is to resist first class sprites).

I've got a bug:
If you put a forever block into an atomic custom reporter, it freezes BYOB. You should fix that.

ScratchReallyROCKS wrote:

I've got a bug:
If you put a forever block into an atomic custom reporter, it freezes BYOB. You should fix that.

Thanks for this bug report! I've added it to our bugtracking list and will give it a shot for the next release.

BTW, please feel free to report any bugs you come across to our bugtracker at: BYOBugs.com.

Thanks!

Glitch:

Type in

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Or some other equivalently long string into the "report []" section at the bottom of the block dialog. It is now impossible to close.

Oh, wait, you can select it and press enter, but the layout is still quite messed up and it's impossible to resize the dialog without deleting the text.

Glitch #2:
make an input variable, then rename it. A block variable is made with the old name.

Last edited by nXIII (2010-06-22 18:29:52)

Jens wrote:

So what you can do is drag the variable from the block vars pane over the prototype and drop it onto an orange plus-sign. This was my first attempt at a drag-n-drop way to define prototype arguments, before we came up with the click-the-plus-sign rule, and it still works 

Nifty!

MathWizz wrote:

I have to wait 'til then for first class sprites?!?    I have started playing with first class images and it's fairly easy!

Even easy changes mean another cycle of posting an alpha test version, waiting for bugs to trickle in, and fixing them.  Or waiting a while, even if no bugs trickle in, just in case.  Right now we have a large number of fairly trivial bugs (like the ones in the past few messages, no offense bug posters, "trivial" doesn't mean unimportant, just that it isn't something users are likely to do and/or it doesn't kill your project and/or arguably it's a user error) and user interface glitches.  And making it faster!