Scratch

Jens wrote:

Wait, I thought the query took less than a msec? What's taking so long, getting the xhr's responseText?

I don't know, it's just that the time between queries (internal thread gunk?) is pretty huge.

Hardmath123 wrote:

you use the iPad as a remote control for Snap! on the computer.

Why?  Why not just run Snap! on the iPad?

blob8108 wrote:

@Hardmath: show code! 

Yeah, I need to upload it to gdocs. I want to get the speed issue resolved first, though.

Also, it should also work with Android, so someone can someone test it? The only thing that won't work is the compass sensor, but that should theoretically not matter (it'll just return 0 in Snap!).

The Snap! "API" basically provides a set of 5 or 6 blocks, each of which is a different sensor (accelerometer, compass, etc.). Each one returns a list of values for each axis (like a 3D vector). I'm using SENTENCE->LIST for decrypting what comes from the server, but for some reason that block doesn't work unless all the tools are loaded. 

Last edited by Hardmath123 (2013-03-14 10:13:21)

Hardmath123 wrote:

The only thing that won't work is the compass sensor, but that should theoretically not matter (it'll just return 0 in Snap!).

Why not?  It does have a compass...

I'm using SENTENCE->LIST for decrypting what comes from the server, but for some reason that block doesn't work unless all the tools are loaded. 

I didn't pay him to say that, Jens. 

Jens wrote:

don't use the official tools, they're slow. write your own parser and WARP it, that'll make things a lot faster!

Okay, fine, I put WARPs in the tools (except for FOR and FOR EACH -- for that, I really want an UNWARP block to put around the RUN of the user's code, right?)

... except that WARP should keep count of the number of nested WARPs, and UNWARP should decrease the count and not really unwarp unless the count goes down to zero, kind of like a semaphore.

Last edited by bharvey (2013-03-14 10:55:20)

I think it's fast if you WARP it. Thing is, if you're doing hardware interfaces, especially if you're constantly polling the same data, you might be even faster by just directly accessing the information in the answer. For example, if you know that the number you're looking for is always at the sixtenth position of the response string, I'd go for looking that up directly instead of parsing everything first.

Jens wrote:

I think it's fast if you WARP it. Thing is, if you're doing hardware interfaces, especially if you're constantly polling the same data, you might be even faster by just directly accessing the information in the answer. For example, if you know that the number you're looking for is always at the sixtenth position of the response string, I'd go for looking that up directly instead of parsing everything first.

This necessary leads to define a set of prefomatted Ascii messages. I have used a system like that when I was working for Qualcomm "in the good old days".

technoboy10 wrote:

Jens wrote:

@technoboy10: Got your proposal for the Barcelona Scratch conference, Yay!!

More to come today.

You're submitting multiple proposals? 

bharvey wrote:

EDIT: ... but in this case my guess is that they'll be combined into one session.

Actually, I am submitting multiple proposals. 

#Barcelona All of my proposals have been submitted! ( ) 

Last edited by technoboy10 (2013-03-15 18:13:26)

Hardmath123 wrote:

I think I'll write a custom parser.

Try sentence->list again; I put in a warp block.

Hardmath123 wrote:

my mom wants me to teach an "intro to game-making" class to the kids in our building.

Ah, so you don't live in a mud hut in a rainforest somewhere. 

Yeah, Pong is what I generally pick as a first game project, too.  And you want to use Scratch, not for reasons of difficulty one way or the other, but because the kids will want to share their work with the Scratch audience of a quarter-million (estimated active accounts) other kids.

A good idea if you can swing it is to invite the kids' parents to come work with their kid.  We do that in the elementary school strand of our K12 outreach organization.  It has two big advantages.  (1) After your five hours are up, there's a better chance that the kids will keep going with Scratch if their parents continue to encourage and support them; (2) the kids will be on their best behavior and each parent can be in charge of keeping that kid focused and of answering the easiest of kid questions.

Plan on losing one of the five hours to creating a Scratch account and getting the hang of clicking blocks together.

Actually, you know, there's another choice, namely Scratch 2.0, which avoids the download and, because of cloning, puts Breakout within the bounds of possibility.

And finally, if this is pre-Barcelona, send Jens another talk proposal!