>
> You could send strings for function blocks that can later be eval-ed.
> But the eval itself might slow things down a lot.
>
yep, also it's not recommended ( http://javascript.crockford.com/code.html,
look for "eval is evil")
Some browsers serialise the JSON to
> string and then re-eval it, oth
You could send strings for function blocks that can later be eval-ed.
But the eval itself might slow things down a lot. You can also send
JSON objects between workers. Some browsers serialise the JSON to
string and then re-eval it, others send the actual object.
About shared data, try to stay away
Hi
in my early post I talked about
canvas vs SVG (slide #28)
why not processingJS? (slide #28)
here some technical stuff:
---
Browser Optimization (slide #29)
Karma lessons must run under the XO-1.
Default browser: Browse ( based on Gecko )
Experimental: Surf ( based on webkit )
No problem with
Hey guys,
I basically agree with the points raised here so far and have a couple to
add myself:
slide #11: I would also mentioned that you had tried eToys/Squeak
slide #24: I'm not sure we agreed on each lesson having to include a
tutorial and an exercise. Of course this is a good goal but the que
Hi guys
Joshua, Bryan has talked Christoph and me about you, thanks for writing :)
* I would update the slide "Nobody Wants to Help", to something like, "Flash
> is a poor longterm solution." I would drop the claim "Flash Devs don't like
> to share." I would
> - Despite the great work of the fr
On Thu, 2009-08-20 at 13:57 -0400, Joshua Gay wrote:
> Bryan,
>
> This is looking good so far. Here are some initial thoughts,
>
> * It would be good to have a handout that puts all this info on a
> single double side sheet of paper (a suggestion taken from Edward
> Tufte's essay "The Cognitive
6 matches
Mail list logo
