<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">You could send strings for function blocks that can later be eval-ed. But the eval itself might slow things down a lot. </blockquote>yep, also it's not recommended ( <a href="http://javascript.crockford.com/code.html">http://javascript.crockford.com/code.html</a>, look for "eval is evil") <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Some browsers serialise the JSON to string and then re-eval it, others send the actual object. </blockquote>afaik, ff takes the message and then converts it to JSON.. <div class="gmail_quote">2009/8/26 Lucian Branescu <<a href="mailto:lucian.branescu@gmail.com">lucian.branescu@gmail.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 from it anyway. Message passing is desirable most of the time. 2009/8/25 Felipe López Toledo <<a href="mailto:zer.subzero@gmail.com">zer.subzero@gmail.com</a>>: <div><div></div><div class="h5">> 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 html elements (div, img, ...) > What about canvas content? > Under a normal browser clearing and redrawing the canvas objects may not be > a problem, but remember that the XO has not that kind of normal resources. > We must use them efficiently. > If we have no option, it's preferable to spend cpu than spend memory. > We emphasize rendering speed over quality > image-rendering / firefox 3.6 alpha > webkit has nothing > Quadrilaterals (<a href="http://karma.sugarlabs.org/quadrilaterals/" target="_blank">http://karma.sugarlabs.org/quadrilaterals/</a>) > how does it work? > 2 canvases > the first for temporal drawing of the current line > cleared and re drawn when "mousemove" > the second has the drawn polygon, background, etc.. > Quadrilaterals under Browse has a severe lag problem (unusable) > Quadrilaterals under Surf works nice > Surf-106 is faster than Browse-102, should we use Webkit or Gecko? > -- > Web Workers (slide #30) > We tried to use web workers to handle animations: an animation core. > The animation core would be running as a worker thread: doing the neccesary > calculations for the animated objects and sending messages to the root > document to manipulate (update) the neccesary html elements (canvas...) > We try to combine actions with predictable behaviour. > Problems: > it's not possible to send functions as worker messages, so, it's hard to use > callbacks. > how to share memory (variables) between the root document and the worker > thread without copying that data? > -- > 2009/8/21 Christoph Derndorfer <<a href="mailto:christoph.derndorfer@gmail.com">christoph.derndorfer@gmail.com</a>> >> >> 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 question is >> whether we should really make that a requirement? >> slide #32: "i81n";-) >> slide #43: add link to Karma blog at <a href="http://karmaproject.wordpress.com/" target="_blank">http://karmaproject.wordpress.com/</a>, >> add at least one e-mail address for direct contact, add link to Sugar >> mailing-list (<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>) >> That's all I can think of for now... >> Christoph >> 2009/8/21 Felipe López Toledo <<a href="mailto:zer.subzero@gmail.com">zer.subzero@gmail.com</a>> >>> >>> 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 free software community on projects >>>> like Gnash and the GameSWF library, there is very little in terms of sharing >>>> and collaboration of free software Flash projects. >>> >>> +1 >>>> >>>> - There is no free software Flash development tool, >>> >>> mmm, I remember MTASC <a href="http://www.mtasc.org/" target="_blank">http://www.mtasc.org/</a> >>>> >>>> instead almost all Flash development is done through the proprietary >>>> software created by Macromedia. >>> >>> +1 >>> >>> Bryan, really good draft, here some initial feedback: >>> >>> 1. SVG vs canvas >>> I used RaphalJS (<a href="http://raphaeljs.com/" target="_blank">http://raphaeljs.com/</a>) demos to test SVG animatios using >>> Browse and Surf, >>> results: >>> under surf: the XO crashed several times :( >>> under Browse: the animations look really good, but the performance is >>> really bad (you will get a several lag when clicking something, etc...) >>> >>> canvas is low level so, canvas drawing is faster than SVG drawing. >>> about manipulation, well, It's really easy to manipulate SVG Objects >>> (everything you draw is an object) but canvas is just a box where you can >>> draw, Karma provides (some of) that objects. >>> >>> 2. why not processingjs? >>> processingjs by default uses processing language, then if you want to use >>> it you'll need to learn processing syntax... to support that syntax, >>> processingjs uses a parser, so, it's slower than simple JS. >>> in fact, you can use javascript to access processingjs objects, but.. the >>> actual processingjs library is not designed to work under the XO, neither to >>> work as a jQuery plugin. >>> I think jresig doesn't encourage to use processing (syntax), he just take >>> processing because processing was there (looking for the reference) >>> >>> I will add more info on the technical stuff. >>> >>> regards >>> >>> On Thu, Aug 20, 2009 at 7:57 PM, Joshua Gay <<a href="mailto:jgay@ck12.org">jgay@ck12.org</a>> 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 Style of Powerpoint) for people to read along with and to >>>> look at afterward. >>>> * I think overall it can be trimmed down abit when it is being pitched >>>> to specific groups (e.g., JS crowd). >>>> * 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 free software community on projects >>>> like Gnash and the GameSWF library, there is very little in terms of sharing >>>> and collaboration of free software Flash projects. >>>> - There is no free software Flash development tool, instead almost all >>>> Flash development is done through the proprietary software created by >>>> Macromedia. >>>> * I would introduce some more lucid examples of the kinds of things you >>>> would like to use this library to create. >>>> >>>> >>>> I had some other thoughts on the internationalization parts, too. I will >>>> try to respond later with them. The short of it is that I think the examples >>>> you gave me (in our phone call) about gettext being an overly-burdonsome >>>> approach for JS made a lot of sense and I think it would also help to >>>> explain that you are looking for the JS equivalent of gettext; kind of >>>> abstract this part away from your specific needs as an organization, and >>>> talk about how this could benefit projects in general. >>>> >>>> -Josh >>>> >>>> On Thu, Aug 20, 2009 at 12:51 PM, Bryan Berry <<a href="mailto:bryan@olenepal.org">bryan@olenepal.org</a>> >>>> wrote: >>>>> >>>>> josh, kcd, subzero >>>>> >>>>> 1st off, let me introduce Josh Gay, a js dev and free textbook guru. He >>>>> is interested to make a presentation about karma to the JS devs group >>>>> in >>>>> Boston on Aug 27th. >>>>> >>>>> here is a more technically-oriented presentation for karma >>>>> >>>>> It is long on introduction and short on technical details. Much of the >>>>> first part could be cut out depending on the target audience. I made it >>>>> longer and more general for my first draft. >>>>> >>>>> It lacks a lot of technical detail on what we need help w/ for >>>>> animation, i18n, web workers, localstorage >>>>> >>>>> -- >>>>> Bryan W. Berry >>>>> Technology Director >>>>> OLE Nepal, <a href="http://www.olenepal.org" target="_blank">http://www.olenepal.org</a> >>>> >>> >>> >>> >>> -- >>> Felipe López Toledo >>> >>> _______________________________________________ >>> Sugar-devel mailing list >>> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> >>> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> >>> >> >> >> >> -- >> Christoph Derndorfer >> co-editor, olpcnews >> url: <a href="http://www.olpcnews.com" target="_blank">www.olpcnews.com</a> >> e-mail: <a href="mailto:christoph@olpcnews.com">christoph@olpcnews.com</a> > > > > -- > Felipe López Toledo > > _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > > </div></div></blockquote></div> -- Felipe López Toledo