Scratch

shadow_7283 wrote:

The antanae look kinda like a one..

Oh!  It only took me 25 hours to figure out why you thought it looked like a one!  Duh.      No, what it represents is right side up, not tilted left.  Hope that helps...

Kingdaro wrote:

here are the custom blocks that don't work in presentation:

Thanks! I'll look into this issue. Presentation is a little little faster than edit mode, because some display cycles are optimized, i.e. skipped. Could be that the code that executes custom block definitions further skips display cycles which would make it apear that nothing is happening.

I wonder, could you check two things for me: You say this only fails in presentation mode. Is the "atomic" setting for these scripts turned on or off? Does it work in presentation mode with the atomic setting turned off? That would be helpful, thank!

Brian wrote:

The speed problem in BYOB, as I understand it from Jens, has to do with the tight interaction between expression evaluation and managing the display.  One design principle in Scratch that we've moved away from (but that still survives in BYOB's implementation, which is mostly still Scratch) is that everything in the program should be visible onstage; this is why variable and list watchers default on.  So it made sense  in the context of Scratch to integrate computation and display, but if we ever rewrite it from (sorry) scratch, the two parts of the program will be separate and computation that /isn't/ visible will be much, much faster.

Jens?  You want to weigh in on this one?

Speed problem, what speed problem? 
as Alan Kay might have said: "It's fast enough for our neurons" 

But, honestly, Brian is right about this. Scratch is slow by design, because you're supposed to see every computational step. BYOB parts with this principle if you mark the "atomic" check box in the Block Editor. But still it's "slow as molasses", because,

   - it's interpreted
   - the blocks are the code, not just a visual representation
   - I don't know zip about programming language design and/or optimization

However, it's important to me that this sluggishness is not due to Scratch or BYOB being a graphical blocks based language. If you look at the underlying Squeak/Elements code, that's acutally lightning fast!

right now i'm trying to compile a project using byob but nothing is happening.

http://scratch.mit.edu/projects/bharvey/1018642

Nice Gobo Seal lol

To BHarvey
From xly Today 11:24

1st : The "make a counter" is not a system title, so it's up to me to name it ("Faire un compteur", for example).

2nd : this being done, SAY (CALL (Counter1) for 1 sec) does not report 1

In my case the variable Counter1 - in the SAY Instruction has a grey border -  contrarily to your example page 19 ??

Thanks

Nice, cnt wait until finished!

bharvey wrote:

ElectricSparx wrote:

I used the "repeat while" block and it gave me an error whenever I moused over the block.

Whoa!  Sure enough.  Thanks for reporting this.

No problem.

xly wrote:

To BHarvey
From xly
Ref My message Today 12h52

I've fixed the problem. Not obvious for anyone who does not know the trick !!

Ah, good.  Sorry I didn't get to reply earlier; it's one of those days when I actually had to do what I get paid for all day. 

What was the problem?  Figuring out how to use ASK?  If we just put an ASK <counter1> NEXT picture in the manual will that make it clear?  Thanks.

PS We didn't include adults (or at least people we know to be adults) on the certificate for lack of room, but thanks to you guys too!

NEW BUG! In the block editor, when you have a block variable with a default value such as (Begin =1) if you duplicate it, you still have the default value there.

EDIT: Other duplicate errors. When you are in the block editor, create a reporter block. Insert a variable (or something) in the "report" section at the bottom. Now duplicate it and click on the current variable in the "report" section. You will get a series of errors.
NOTE: This happpens with any reporter block that you are trying to replace the current one with, even if it isn't duplicated.

Question: Why can you insert just a reporter into a predicate? What use does it have?

Last edited by shadow_7283 (2010-04-30 19:44:57)

shadow_7283 wrote:

NEW BUG! In the block editor, when you have a block variable with a default value such as (Begin =1) if you duplicate it, you still have the default value there.

EDIT: Other duplicate errors. When you are in the block editor, create a reporter block. Insert a variable (or something) in the "report" section at the bottom. Now duplicate it and click on the current variable in the "report" section. You will get a series of errors.
NOTE: This happpens with any reporter block that you are trying to replace the current one with, even if it isn't duplicated.

Question: Why can you insert just a reporter into a predicate? What use does it have?

Thank you.  Jens, to clarify the second one, when I tried it, if I used a "Make a variable" variable, the one in the report slot duplicates without problems and the one off on the left of the block editor doesn't have "duplicate" in its context menu.  But if it's a Script Variables variable, then the oval in the s.v. block itself can be duplicated, and that's when the one in the report slot starts erroring.

Shadow, about your question, putting a reporter into an input slot of type predicate is probably a mistake (although nothing stops a custom reporter from reporting TRUE), but Scratch in general tries not to give error messages and we've stuck with that.  So we think of the input types as more advisory than compulsory.  (I was surprised to discover that Scratch really enforces the numeric input type, but it does it by not letting you type non-digits into the slot in the first place, not by erroring; if you say something like

MOVE [JOIN <hello > <world>] STEPS

you can run that and it just takes any non-numeric result as zero.)

Jakey22 wrote:

I would also be able to customize the interface more, possibly the option of themes, and being able to change the color of watchers in the variables and lists.

Yeah, there are probably a couple of bazillion things we could do along these lines.  I'm not /against/ doing them, but I'd have to say it's lower priority than debugging aids, so maybe not in the August release, depending on how long the big things take!