On Fri, Jun 15, 2012 at 5:55 PM, Joe Ryan <[email protected]> wrote: > > Hi C Anthony, > > Thanks so much for your comments. With your help, I was able to build some > examples, and I'm very impressed with pyjs!
hooray! :-) > After the initial helloworld example, I decided to test some code from > rosettacode, as many of the examples there reflect the types of functions > that we'll need to translate to javascript (data structure manipulation and > number crunching). I am quite pleased with pyjs's performance, for an > extreme example, running the Hailstone Sequence benchmark > (http://rosettacode.org/wiki/Hailstone_sequence) for 1 million iterations > (an over-extreme number to hopefully factor out loading times in order to > discover the computational overhead of pyjs) produces results for: > > Raw javscript: 11s > Python, in terminal: 31s > Pyjs: 70s > > While a server would probably run the python example more quickly, a > slowdown of less than an order of magnitude even compared to pure javascript > is very acceptable for us. This example in Empythoned would likely have > taken several days to run, lol... very interesting; that's definitely encouragement toward setting up a performance tracker ... a la http://speed.pypy.org/ ... you may also want to try translating with `--enable-strict --disable-debug` (if you didn't already) to get a good estimate of the worst-case scenario. those options are groupings -- the former enables all python features, and the latter disables any feature that is *also* considered a "debug" feature. for example, storing the original source + lines + tracking infos is needed for stack traces, but can make the blimp the output by a multiple of 2 or 3 or more! `--enable-strict --disable-debug` will get you as close to python as possible, reasonably sacrificing the more ... pedantic ... options in the name of performance. > It sounds like I'll probably have to do a bit of manual plumbing to connect > the pyjs-generated module to the pure-js dispatcher function. The pure-js > dispatcher is what connects the user-inputted commands to the actual > function that will execute them - e.g. what runs the code that brings up the > inventory window with his inventory items when the user presses 'i' on his > keyboard, or executes the commands to move left and end the current turn > when he presses the left arrow key. Hopefully that won't be too bad though. > I think that if I write a python assistant dispatcher that simply dispatches > to whichever function the pure-js dispatcher requests, I'll only have to > "hack" the call to the pyjs-converted assistant dispatcher from javascript > and manually cast its input arguments (only strings and numbers) to the pyjs > datatypes. that sounds like a sound plan; you can embed JS('var x = function(){}') blocks into your python, or IIRC, use something like: from __javascript__ import my_dispatcher ... to access to javascript identifiers. also take a look at how the stdlib and _pyjs.js use @{{python-identifier}} to embed python objects into JS() blocks, so maybe something like (untested): def py_dispatcher(str_val, int_val): // do something ... JS(''' $pyjs_dispatcher = function($string, $integer){ @{{py_dispatcher}}(@{{str}}($string), @{{int}}($integer)) } ''') ... then you call $pyjs_dispatcher from your javascript code (with primitive args), and it should properly call your python function. > Unfortunately, I cannot give you a link to our project just yet, as we're > still working on cleaning up the connectivity and writing docs before we > bring it "live" - we don't want the first impression people have of it to be > vapourware. However, rest assured that once we do bring it live, I'll link > it to this discussion group! Hopefully sometime in the next couple of > months! sounds peachy :-) ... looking forward to it! -- C Anthony
