Scratch

So, green flag and stop all has been taken out of byob 4?

shadow_7283 wrote:

jji7skyline wrote:

So, green flag and stop all has been taken out of byob 4?

Nope!    They have yet to be implemented, that's all.

kay! 

shadow_7283 wrote:

On the other hand, a teenager has to pay college tuition (and fund various frivilous technological ventures) somehow.

OK, you're a friend, give it a try.  But it looks like you'll have to be the one to do the Box2D integration -- I don't hear anyone else leaping at the prospect.  Maybe it'd be easier to walk dogs. 

By the way, your pamphlet (for want of a better word) looks great!

Thanks!

@ roijac

bharvey wrote:

It took me a long time to get the joke in your sig because my browser is set to white-on-black display. 

OMG, now I'm seeing it, too. Yes, that's original for sure 

roijac wrote:

actually the reason behind suggesting that is to improve speed: they are so common that it would really reduce speed in longer algorithms, where you sometimes really need them

You're wrong about the speed issue, but don't feel bad; it took me a long time to convince Jens, too. 

You're thinking (we teachers don't actually have eyes in the back of our heads; we're just telepathic  ) that making something a primitive block makes it faster than writing it as a script.  And that's true, of course, but it's true only by a constant factor.

In BYOB it's a huge constant factor, which is why having a COPY OF (list) primitive block made sense.  In Snap! it'll be much smaller.  But, let's say it's a factor of 100 speed difference between a Snap! script and raw JS.

For small list lengths, up to 30 or so, that constant factor will be the most visible influence on overall program speed.  But for small lists, your program will be fast enough no matter what.  If the primitive version takes less than a second, then (by hypothesis) the Snap! script will take less than 100 seconds, i.e., less than two minutes.  And a second is a really long time for a computer; in most cases it'll be more like milliseconds vs. deciseconds.

But for larger lists, over 100 or so, the critical factor in program speed is the order of growth of running time as a function of size.  And no matter how you implement it, appending or subsetting lists requires linear time -- if you double the size, you double the running time.  By contrast, for linked lists, the IN FRONT OF (cons) and ALL BUT FIRST OF (cdr) operations are constant time, independent of the length of the list.

Try writing the mergesort example I gave earlier by recopying lists, and you'll see what I mean.

Yes, we could have our cake and eat it too by providing the primitives you want in addition to the ones I want.  But yours can be implemented straightforwardly in terms of mine, and as usual our policy is to put only the bare minimum in the primitive set, writing the other useful things as custom tool blocks.

We definitely also want to work on constant factors.  At some time, maybe not in 4.0, we're going to replace the interpreter with a compiler that compiles into JS, and that will dramatically improve speed, I hope.

Last edited by bharvey (2011-12-05 14:26:42)

No comment !

The aim is to entirely convert Byob 3.1 to Snap!
And even basic functions like Save/Load are not yet implemented !
There is still a "long way to Alpha"

14God wrote:

Why does it still say "pre alpha"? Its good enough to be alpha 

P.S. to the above:  Until recently it said "pre-pre-pre-alpha"!  We've made progress in the naming. 

Jens wrote:

Hardmath123 wrote:

I've got a question: what does 'morphic' actually mean? I know it relates to morphs which (I think) are like widgets, but is there something deeper? A quick Google gave a Wiki result. The Wikipedia page actually returned a link to your Morphic.js ( ), but there was nothing useful and explanatory.

Hi Hardmath123,

you're right, the Wikipedia article is just a stub. Here are three papers that explain what Morphic is all about:

http://selflanguage.org/documentation/p … ctness.pdf
http://ftp.squeak.org/docs/Self-4.0-UI-Framework.pdf
http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final.pdf

Thanks! I finally got a chance to read those.

I'm working on a simplified version of Morphic which makes it easier to implement a GUI. You have to create objects (I'm not saying morphs because I'm not sure whether they have all the features needed to be morphs) in code (var button = new button()), and they are manually undraggable and uneditable during runtime, though you can dynamically edit them in the code. Screenshot:

Is this Morphic?

Oh, and in BBCode [url] tags, you can omit the "=http://path" bit if you want the linked text to be the path itself: [url]http://www.google.com[/url]. 

Jens wrote:

Hi Hardmath123,

I share your feeling that it's important to create "locked up" GUIs. This is not in the spirit of the original Morphic where everything and anything can be taken apart and modified directly by the user anytime in any way imaginable, and I believe that exactly this is "real" Morphic's worst mistake and the reason why mostly everybody who is working with Squeak hates it (and Squeak, too).

Therefore Morphic.js has ways to "lock up" a GUI. You can set the "isDraggable" property of any Morph to false, and you can specify the World to be in "userMode". You can also set the World's contextMenu property to null, and then you have a completely locked up Morphic GUI, that cannot be taken apart or inspected by the user at runtime (no "secret" keys either).

Having conceded this I do think that a directly editable, metacircular GUI system that can be manipulated by way of itself is totally cool and offers brilliant self documenting features. So you really want to have your cake and eat it, too, i.e. you want to have both "modes" in a GUI, the "locked up" one and the "dev" mode which lets you inspect and debug everything.

Which do you prefer — end-user editable mode or "locked up" mode? Which would be easier to develop, and use? I personally see little user-side advantage in a "dev" mode, maybe a little help for developers nitpicky about aesthetics. But I guess I'll implement a "dev" move anyway; it may prove useful.

PS: Congratulations on 1500 posts! 

xly wrote:

January, February...That is not so far ahead !!

Note I didn't say the first of the month.  The actual beta deadline is 28 Feb.  That still wouldn't be much time if we had a team of 5000 programmers, but instead we have Jens, so it should be plenty.

MathWizz wrote:

When's saving planned, because that's the only reason I'm not making complicated projects in Snap!.

Yeah, me too.  nXIII is working on it.  Should be soon.

EDIT: A reader for BYOB projects, too, he plans.

Last edited by bharvey (2011-12-06 10:41:59)