Scratch

fullmoon wrote:

This mod is <font size="eleventyseven">ABSOLUTELY AMAZING!</font>

  Thanks!

It's super slow, but I get the feeling that's my fault, not BYOB's.

Alas, it's probably BYOB's.  All my projects run slow as molasses, too.  We'll try hard to get that fixed by summer.  That's the top priority along with debugging support.  Which brings us to...

have you considered implementing some sort of socket functionality?

We do want better networking, somehow or other, but imho it'll be better if we leave that for 3.1 than if we leave debugging for 3.1.  For one thing, all those other modders will be creative in attacking networking, so we don't have to.     At some point we should have technology cross-licensing treaties, just like IBM and Microsoft. 
OTOH, Jens enjoys playing with the network, so it might be higher on his list than mine, and he's the programmer of this team.

nXIII wrote:

@Jens: do you mind if I use your (awesome!) scrolling-by-dragging technique in Panther? I will give credit 

Thanks, nXIII, coming from you I feel very honored! Please take anything you need from BYOB, including zebra coloring. Do you want changesets or can you figure out how these work yourself?

BTW: There's a bug report in the BYOB mailbox about "very large 'the script' issues" we're assuming is coming from you. If that's the case (and you agree) I can send you the changeset(s) to that e-mail address.

Last edited by Jens (2010-05-09 20:21:54)

Jens wrote:

nXIII wrote:

@Jens: do you mind if I use your (awesome!) scrolling-by-dragging technique in Panther? I will give credit 

Thanks, nXIII, coming from you I feel very honored! Please take anything you need from BYOB, including zebra coloring. Do you want changesets or can you figure out how these work yourself?

BTW: There's a bug report in the BYOB mailbox about "very large 'the script' issues" we're assuming is coming from you. If that's the case (and you agree) I can send you the changeset(s) to that e-mail address.

Yes, the bug report is me...
I think I can just figure out how you did it (I opened a few browsers in BYOB)
one question: I believe that the ScratchScriptsMorph is harvesting all the clicks so they are not sent to the ScrollFrameMorph2... how can I fix this? (I will probably find this in a browser about a minute in the future, sorry...)

bharvey wrote:

New BYOB 2.99.007 (licensed to kill) at http://byob.berkeley.edu

Fixes, among other things, nXIII's deleted-variables-return bug! 

YOU FIXED IT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! YAY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!anti-caps-lock-filter

Last edited by nXIII (2010-05-09 21:26:59)

Whoa, I can hardly keep up with all these releases! I was about to submit a bug report for .006, too, but it appears to have been fixed (at least for now) in 007. The problem was when I tried to drag custom blocks (usually the # repeat {} loop) from the Tools sprite into a block editor pane and then mouse over them, I would get some sort of runtime error. I'm not going to submit a report unless I find the same problem with 7, though.

Also, is it just me, or is Gobo's head mutation getting bigger with each subsequent release? It looks like there's a coral reef sprouting up.

fullmoon wrote:

Whoa, I can hardly keep up with all these releases! I was about to submit a bug report for .006, too, but it appears to have been fixed (at least for now) in 007. The problem was when I tried to drag custom blocks (usually the # repeat {} loop) from the Tools sprite into a block editor pane and then mouse over them, I would get some sort of runtime error. I'm not going to submit a report unless I find the same problem with 7, though.

Also, is it just me, or is Gobo's head mutation getting bigger with each subsequent release? It looks like there's a coral reef sprouting up.

Hi fullmoon,

yes, I fixed two situations in which the error message you're been observing popped up recently, one for 007.

Lambda-Gobo's (Lobo(?)) hair underwent some community-driven styling in recent versions to make its meaning more obvious, but I didn't change it from 006 to 007.

Nice to see you again 

I built a library that includes hash functionality and JSON encoding/decoding. You can download it in the form of a BYOB sprite here.

This library basically allows you to create lists whose indices are objects rather than just numbers. So instead of having a items at 1,2,3 and so on, you can access them through string keys. That way you can have values at "name","password","email", etc. This is what the library looks like:


To create a new hash, you need two lists, one with the keys and one with the values for the new hash. These can be empty if you like:


Once you have a hash, you can put all sorts of things inside of it (including other hashes):



You can also:

- Add something to the hash
- Find the value at a specified key (returns a reference, not a duplicate, so you can modify this directly)
- Find the key of a specified value (careful, doesn't check for duplicates)
- Get a list of keys
- Get a list of values
- Test if a reporter returns a hash object

But my favorite feature allows you to encode or decode data as JSON. This is a lightweight data format used for sending data back and forth across the web. It stands for JavaScript Object Notation, so named because it looks like the code for creating objects in JavaScript. You can encode any hash, list, string, or boolean as JSON:


You can also create a Scratch object from a JSON string. This block has the added bonus of being so slow that it gives you time to go make a sandwich while it runs:


Don't try this at home, kids:

The encode/decode function is basically useless now, but I had a lot of fun building it. I imagine that a future, HTTP-connected Scratch would probably need some sort of functionality like this.

To use this library, just  import the hash library.ysp sprite into your BYOB .007 project. You'll also get every other block I had imported while creating the library (including a duplicate of the Tool Sprite's blocks, as well as some of my own).

Last edited by fullmoon (2010-05-10 13:22:26)

fullmoon wrote:

I built a library that includes hash functionality and JSON encoding/decoding.

Very cool project.

Want us to put a link to it in the user-contributed section of the web page?

fullmoon wrote:

Hey, that would be great!

Done!

PS Why do you make copies of the x and y inputs in your POINT block?  I think you could just use the input variables themselves.

PPS It's great that you're adopting dispatch procedure style OOP!  I'm waiting to see the first contributed project with delegation. 

Doesn't Scratch already use OOP?

I mean, it has sprites which are different objects, and it's oriented around programming them. Sorry if I am sounding stupid, but I am confused.

soupoftomato wrote:

Doesn't Scratch already use OOP?

I mean, it has sprites which are different objects, and it's oriented around programming them. Sorry if I am sounding stupid, but I am confused.

No, not stupid at all.

You're quite right, Scratch's sprites are objects.  But they're only semi-objects.

Object oriented programming rests on three legs.  (There's a slide about this in the movie; the ideas are part of the SICP course I teach.)  They are message passing, local state, and inheritance.

Sprites sort of have message passing; they get 1/2 credit for this one.  You can send a message with BROADCAST, but you can't direct it to a single sprite, and you can't include program-generated arguments with the message. (Edit: And BROADCAST-receiving scripts can't report values to the sender.)

Sprites do have persistent local variables; full marks (sorry, comes from hanging out with all those UK Panther people) for that one.

And they don't have inheritance at all.  There's no way to say "I want a sprite just like that one, except for these things" and have changes to the parent reflected in the child.  And no way even to say "I want a sprite just like that one" within a program!

Part of the long-term BYOB plan for taking over the world is to bring sprites up to full OOP status.  We've already solved the message-passing problem; you can use the Sensing-palette [<var> OF <sprite>] block to get access to another sprite's methods; you can call them with arguments, you can get return values from them, you can launch one in a separate thread.  We haven't made sprite inheritance a priority because so many other people are already thinking about that, including the Scratch Team and the Panther gang.  (Maybe we'll just steal their code without attribution --- JUST KIDDING!)

So, why have this other OOP mechanism?  Three reasons I can think of offhand (although based on past performance I'll either forget one or think of another one by the time I get to the end of the list).

1.  Sprites are kind of heavyweight.  They have costumes and collision detection and all kinds of time-and-space-consuming bells and whistles.  If all you want is a counter, you shouldn't need all that other stuff cluttering up your project.

2.  Dispatch-procedure OOP comes free if you have a lexically scoped language and you add lambda.  A visually programmed language in which you physically drag a variable from its point of definition to where you want to use it can't help but be lexically scoped!  [Actually this is a lie; OOP didn't work for a while in pre-alpha BYOB3 versions, because someone, either the Scratch Team or Jens, I'm not sure, thought it was okay to allocate frames on a stack like Those Other Languages.  But since I knew it should have been true, I made Jens fix it.  ]  Of course the tutorial I'm going to have to write about this eventually isn't free. 

3.  As a teacher, I think it's valuable for people learning about OOP to be able to look under the hood --- to see that OOP isn't some magic property you sprinkle on a language, but a fairly simple thing anyone can implement.  Sprites are opaque (no puns about the ghost effect please) but dispatch procedure OOP is transparent.

(Edit) 4. nXIII and fullmoon are finding it useful!

Last edited by bharvey (2010-05-11 10:24:19)

bharvey wrote:

On http://byob.berkeley.edu near the bottom there's a pointer to a writeup and skeleton project file for an exploration of Church numerals (how to do arithmetic with nothing but THE BLOCK as a starting point -- kind of like starting a fire by rubbing two Boy Scouts together) that the mathematicians in the crowd (MathWizz?) will enjoy.  No fair looking it up on Wikipedia or Google.

I accidentally built POWER while trying to build SUM  . I need to do my homework...

Last edited by fullmoon (2010-05-11 19:34:35)

BYOB 2.99.008 now at http://byob.berkeley.edu, fixes some bugs, especially about non-English versions.