Scratch

that is amazing!

Jens wrote:

Morphic framework for browser-based JavaScript

Hi gang, recently I have been working on a new HTML5 based Morphic framework for web browsers called morphic.js, which might serve as a platform for BYOB4 or someting similar (yeah, it does work on the iPad). I just finished the documentation and released it under a free and open source MIT license. If you're interested you're invited to check it out at:

  http://www.chirp.scratchr.org/blog/?p=34

it's a blog post with a link to a live Morphic web page that looks and feels a lot like the Squeak version Scratch is written in, plus a video showing some tricks.

This is the very beginning of what might eventually turn out to be a complete re-write of BYOB...

Wow... I looked at it expecting a rectangle and maybe a string morph but there is the whole base for a new program! Then I looked at the source which I thought would be a few hundred lines of code, but... 5000!!! WOW! You HAVE be busy! 

Thanks, guys!

Actually creating a Morphic UI for JavaScript wasn't all that hard, because Morphic has been around for a long time, co-invented and pioneered by Scratch's very own lead developer John Maloney for the SELF programming language, an offshot of Smalltalk. JavaScript in turn is a hybrid of Scheme and SELF. So, it's been a proven concept for more than 15 years.

As I'm about to resume work on the next version of (Squeak based) BYOB 3 there is enough time for you to aquaint yourselves with the framework and - contribute!

If anyone is interested in contributing, here are some things you might try looking into:

   - extending CursorMorph (for multi-line editing and text selection)
   - tooltips
   - turtles (sprites with pen trails)
   - a "virtual keyboard" for text entry on touch screens

The last item ("virtual keyboard") is probably the easiest to begin with. And if you have any questions, don't hesitate to ask.

Last edited by Jens (2011-01-06 03:28:46)

@Jens

Words are missing to describe this giant lap you are accomplishing.
.
As far as I'm concerned, on one hand I could have feared that your new involvement  would not leave much time to support Byob. But on the other hand I must admit that, programming daily with Byob, it is now perfectly stable and reliable, with no bug or any teasing issue. Accomplishment of your new project will not leave behind orphan Byobers !

Good luck !

As far as morphic.js I've had an eye on the demo of DesignBlocksJS, similar to Scratch/Byob and was impressed by the speed of applications. I hope that Byob4 will run like that in the future.

Could someone help me with a block I've been making?
(i'll just type it because a picture of it won't save because it's read only)

word 'number' of 'block'
script variables 'process letter' 'final word'
set process letter to 1
delete all of 'list letters'
repeat 'number'
[delete all of 'list letters'
[change process letter by 1
[add 'letter 'process letter' of 'block'' to 'list letters'
-----------------------------------------------------------------------
set 'final word' to 'list letters' as text
report 'final word'

When I try it as saying word 2 of answer, it says 'letters' If I'm doing something wrong or I've completely misunderstood a block, please tell me (BTW I'm new to BYOB)

Last edited by Shadowed1 (2011-01-06 17:02:23)

xly wrote:

I could have feared that your new involvement would not leave much time to support Byob.

Don't worry, there will be a version 3.1 that'll be even better than 3.0!     And Jens's Morphic in Javascript will (if all goes according to plan) provide the GUI for BYOB4, which will (if ditto) run existing BYOB projects, as well as add new features, but fast!  (Speed is the biggest problem with 3.0 -- that and the weak support for debugging.)

My guess (not a promise!) is that February will see another almost-daily series of 3.099 alpha-test releases converging on something I can show off March 11 at SIGCSE.  And after that comes the 4.0 development, with the final release in time for the Fall 2011 offering of CS 10 at Berkeley!

Today we've started arguing about how to do first class sprites. 

bharvey wrote:

xly wrote:

I could have feared that your new involvement would not leave much time to support Byob.

Don't worry, there will be a version 3.1 that'll be even better than 3.0!     And Jens's Morphic in Javascript will (if all goes according to plan) provide the GUI for BYOB4, which will (if ditto) run existing BYOB projects, as well as add new features, but fast!  (Speed is the biggest problem with 3.0 -- that and the weak support for debugging.)

My guess (not a promise!) is that February will see another almost-daily series of 3.099 alpha-test releases converging on something I can show off March 11 at SIGCSE.  And after that comes the 4.0 development, with the final release in time for the Fall 2011 offering of CS 10 at Berkeley!

Today we've started arguing about how to do first class sprites. 

Are there plans for OOP in BYOB4?

Jens wrote:

14God wrote:

Are there plans for OOP in BYOB4?

Well, as Brian mentioned we're really planning to get some more OOP into BYOB 3.1 

Anyway, I think that Byob, as it is now, can be considered as a good paradigm of OOP : you can have sprites used as parent of different classes, you can duplicate each one to get new Members of these Classes, methods and local variables are also duplicated, you can play wih local/global variables and methods . Byob also offers a mean to handle properties of object-sprites (see Ch 4 of Brian Harvey Byob tutorial) . Byob is not so far from a full-fledged OOP language, but having in addition the advantage of its graphics interface which "shows" how OOP works practically better than typing a lot of instructions just to say that Dingo is a new object of the Class Dog, which barks.

Presently, when you create dozens of new sprites by duplicating a "master" class-sprite you need to do some typing to define : name of the new object-sprite, its local and global variables, set the methods etc (it  is useful to create a Global variable having the same name as the object-sprite, because this variable can be used as a parameter of many useful Byob instructions like <property OF sprite >, <distance TO >, broadcast etc).

All this typing could be simplified by having an instruction like DUPLICATE class-sprite TO object-name . We could also have a Byob instruction like : MAKE VARIABLE local-variable FOR object-name . By setting these instructions in a simple script (or C-shape) a new object could be easily created.

Jens wrote:

14God wrote:

Are there plans for OOP in BYOB4?

Well, as Brian mentioned we're really planning to get some more OOP into BYOB 3.1 

that would be awesome

bharvey wrote:

This does raise the technical question of exactly what object properties should be inherited by the children.  For example, if you're making a breakout game, you've built a brick sprite, and you want a bazillion of them to make a wall, you want the children to inherit the shape and the methods of the parent, but not its position, probably.

this is the way unreal script handles it:
the inputs are:
1. class to spawn
2. what to name object (optional)
3. location (optional)
4. direction (optional)
(left out the inputs that wouldn't be relevant to BYOB)
If no name is given name the object ('class name' # x).
If no position or direction inputs are filled then inherit parents direction and position.

@ bharvey - Refering to Object Logo on Macintosh.

This Logo was derived from the "Object Lisp" initially created to be implemented on (few ) dedicated Lisp-Machines. When the first big Macintosh arrived (I don't remember its name )Object Lisp was directly ported on Macintosh. Later on it became "Object Logo". The Lisp-Machines have been the first (and probably the last) machines entirely based on OOP language and concepts... 30 years ago !!!

14God wrote:

1. class to spawn
2. what to name object (optional)
3. location (optional)
4. direction (optional)

Sprites have many more properties than just position and heading.  They have costumes, sounds, colors, sizes, special graphics effects, pen state (up/down, color, size), and I'm sure I'm forgetting even more.  And besides those things that all sprites have, particular sprites can have user-created variables and methods.

I think method inheritance will be straightforward; the child sees changes made in the parent, unless the child explicitly shadows the method (by editing it in the child).  Parents don't see changes made in children.

All the other ones are trickier.  Most of the time users will want all the built-in sprite state attributes to be separate in parent and child, so if the parent changes color, the child doesn't.  But sometimes people will want a dozen things on the screen that all have the same color -- when one changes, so do the others.

In Object Logo, when you create an instance by saying ONEOF <object>, the new object shares all state with its parent, but it automatically runs an EXIST method (this is like the "when cloned" hat block in Panther) that typically has a lot of instructions like

HAVEMAKE "FOO :FOO

which means "create a new instance variable named FOO and give it the same value I inherited from my parent," i.e., thereafter, changes in the parent's variable aren't seen by the child.  This gives the user complete control over what's shared and what isn't, but it means that the default is to share, which may not be the right thing for BYOB.  We're going to have to decide about that.

P.S. About names, sprites should be first class, which means that instead of having a name input to the CLONE method, you'll just be able to say

SET <variable> TO [CLONE <sprite>]

or maybe

SET <variable> TO [CALL [[CLONE] OF <sprite]]

But this does raise the question of whether or not a clone should appear in the sprite corral (down in the bottom right corner).  Pro: How else do you edit a child?  Con: There may be an awful lot of them.