<br><br><div class="gmail_quote">On 26 August 2011 03:28, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Aug 26, 2011 at 11:11 AM, Michael Foord <<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>> wrote:<br>
> Plus IronPython runs in the Silverlight runtime. Probably of less interest<br>
> to this crowd though. :-)<br>
<br>
</div>In the talk at PyConAU that mentioned gumbyapp [1], trypython was the<br>
first version Tim showed. Gumbyapp was his follow-up for the cases<br>
where Silverlight wasn't an option (or ran too slowly). Although it<br>
turns out many browsers aren't happy about being sent 2.8 MB JSON<br>
objects, either :)<br>
<br></blockquote><div><br><br>Interesting. Last year I wrote a commercial app with a Silverlight front-end (choice of the client) where we were sending 10mb or more of json over the wire (per view). We found IronPython in Silverlight *much faster* than Javascript, both for json handling (using the Silverlight json apis) and for the user interface, which was a grid displaying the large amounts of data we were sending. (I was porting a Javascript app to Silverlight and performance was one of the big reasons.)<br>
<br>My understanding is that even with recent javascript engines the Silverlight runtime *typically* runs code faster than Javascript. As gumbyapp is translating llvm bytecode to Javascript I'd be *surprised* if it was faster than Silverlight (not that aren't other reasons to prefer a 'browser native' solution though). Just because I'd be surprised doesn't make it impossible of course. :-)<br>
<br>All the best,<br><br>Michael Foord<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It's actually a really cool talk (and my personal favourite of the<br>
whole weekend at PyConAU) about how the National Computer Science<br>
School run by the University of Sydney uses OS level sandboxing to<br>
permit safe execution of arbitrary Python code on the NCSS servers<br>
(alas, UoS has not made the code backing the site open source at this<br>
point in time and Tim wasn't sure if or when that would happen).<br>
<br>
To add another possible mechanism into the mix, freezing modules may<br>
be another way to get them into the LLVM bytecode. Dynamic import<br>
mechanisms are hard, since you run into bootstrapping issues (cf.<br>
Brett's hassles with making importlib the underlying implementation of<br>
the __import__ builtin).<br>
<br>
[1] <a href="http://www.youtube.com/watch?v=y-WPPdhTKBU&feature=channel_video_title" target="_blank">http://www.youtube.com/watch?v=y-WPPdhTKBU&feature=channel_video_title</a><br>
<br>
Cheers,<br>
Nick.<br>
<font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></blockquote></div><br><br clear="all"><br>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>May you do good and not evil<br>May you find forgiveness for yourself and forgive others<br>
May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>
<br>