Scratch

joefarebrother wrote:

Every time an object with that should have an ID is encountered, it is given the "ID counter" (which starts off at 0) and it is incremented. The object along with it's ID is stored in a table so when the same object is encountered again, the resulting  XML code is  <ref id=whatever the object's ID stored in the table is/>

Thanks, that makes sense. So it's not object specific? That's what confused me.

blob8108 wrote:

dreamod wrote:

joefarebrother wrote:

Every time an object with that should have an ID is encountered, it is given the "ID counter" (which starts off at 0) and it is incremented. The object along with it's ID is stored in a table so when the same object is encountered again, the resulting  XML code is  <ref id=whatever the object's ID stored in the table is/>

Thanks, that makes sense. So it's not object specific? That's what confused me.

It's specific to that list, is it not?

If you get Jens to explain it it will be more clearer

Jens wrote:

object IDs is something we don't have in BYOB, because Scratch doesn't have (need) them. But we need them on order to deal with circularity, because we have first-class lists.

The idea is to give every object a unique identifier when it's being stored. At first the identifier is nil, but when you first touch it to store it, you increment a counter and assign it to the object's identifier. Then when you come across an object you've already stored (which you recognize because it already has the id set to something other than nil) you don't store it again, but instead you just store a reference to that object. That reference is the object's ID.

In Smalltalk it's very hard to add object attributes on the fly, so it's probably best to add another instance variable (how about "serialization_id" to the Object class, or to use the existing object's #hash as an ID.

Thanks. By the way, what is the color property? Pen color?

@bharvey: Dug out my old Scheme interpreter I was writing a few months ago this morning. I tinkered with it, then uploaded it to gdocs. I figured you'd want to check it out.    Here's the link.

EDIT: My favorite program is the NQueens solver: input (@run "Examples/queens")

Last edited by Hardmath123 (2012-10-19 06:39:14)

blob8108 wrote:

@bharvey: posted this on another thread, HardMath thought it might amuse you... 

@HardMath123: this seems cool! I like the pretty colours    Although I haven't used nearly enough LISP/Scheme/whatever to try it out properly...

Thanks!

P.S. I'm Hardmath. Lowercase m: sometimes people call me math to distinguish from Math (MathWhizz).

Hardmath123 wrote:

My favorite program is the NQueens solver: input (@run "Examples/queens")

Yeah, that's a great problem.  Now solve it using call/cc! 
(I mean, instead of those comparisons to 8.)

Check out Snap! in Japanese and http://snap.berkeley.edu/snapsource/sna … ng:ja_HIRA, both by the amazing Kazuhiro Abe!

Last edited by Jens (2012-10-22 14:13:11)

joefarebrother wrote:

Jens wrote:

Check out Snap! in Japanese and http://snap.berkeley.edu/snapsource/sna … ng:ja_HIRA, both by the amazing Kazuhiro Abe!

The http block and the two Unicode blocks are still in English. Other than that... I don't know any Japanese so I can't tell you if they are translated correctly.

Japanese readers and writers use roman letters for some words of foreign origin (as in http and Unicode) in addition to two phonetic alphabets and characters.

I read enough Japanese to assure you that they are an outstanding draft that will improve as the English keys continue to mature.

The bigger implication of this milestone is that it is the first fully Unicode translation that shows Snap can now be translated for a much broader range of world languages.

Last edited by scspaeth (2012-10-23 13:14:50)

Jens wrote:

Snap! is quickly becoming ever more internal. Check it in Korean and in Portuguese!

I am excited to see these contributions. I hope they develop into equally enthusiastic Snap! user communities.

I'm curious to know how the addition of these language files influences both machine requirements and performance of Snap. As you have it set currently, the snap.html loads all lang-xx.js files. So, it takes a little longer to start Snap but it uses only one translation dictionary at a time.

Are there any advantages to turning language loading scripts of languages I don't know into comments on my local copy of Snap?
Disadvantages?

Jens wrote:

I've done some experiments with this, but they all turned out to be significantly slower and much more instable than what we have now.

var script = document.createElement('script');
script.src = 'lang-de.js';
script.onload = function () {
    // update UI…
};
document.head.appendChild(script);

Will work in all modern browsers.

Thanks, nXIII, that's a very good suggestion, and a lot easier to accomplish than what I had in mind! The only problem left is how to touch each file once to retrieve the language "header" info (lanugage name, translator credentials) before actually loading all of it later.

Jens wrote:

You've asked for it: Morphic.js, Snap's central component and GUI engine, now on Github: https://github.com/jmoenig/morphic.js

Jens:

Thank you. This is yet another reason it is so gratifying to participate in this project. I not only get a chance to stand on others' shoulders, I get to see incremental process, learn by doing and reflect on it, too!
Wikipedia: Standing_on_the_shoulders_of_giants

-----------
Stephen Spaeth