On Sun, Jul 1, 2012 at 1:39 PM, Łukasz Mach <lukasz.m...@pagema.net> wrote: > > Anthony, I hope you don't mind if I push this discussion into group.
nah of course not :-) ... i intended to do the same. > W dniu 01.07.2012 10:28, C Anthony Risinger pisze: >> >> i can't pull this -- i'm hesitant to even have it as an example. >> >> merging into the repository proper gives the impression it's some sort of >> supported or official API, which is very much not the case. when i wrote >> this hack on-list, it was really only meant to be educational, and provide >> some insight into how the translator **currently** works. >> >> i will elaborate on-list, but any API for improving integration with JS >> must, at the minimum: >> >> - neither depend on nor constrain the translator's implementation in any >> way > > Do you mean that it will work with pyjs/pyjsbuild but not with pyjd and it's > the problem? no no, nothing to do with pyjd, and pyjd is of no concern here (since it related to JS integration only) what i meant is any proper/supported solution must not depend on any implementation details about the translator, because they are internal, and subject to change. an example is probably better: this py_dispatcher reaches into the compiled code and calls/interacts with `$py _dispatcher`. the fact that python identifiers tend to start with `$` when viewed from JS is an implementation detail ... by permitting the dispatcher to rely on this detail we have essentially locked ourselves into making sure it's _always_ there, even if it becomes onerous/problematic. such an API should be capable of bidirectionally marshalling simple types, and some complex types (callbacks/closures), as well as invoking functions. i don't have a huge amount of experience here, but i recently spent about 4 days straight reading pygobject code and learning how it dynamically bridged Python -> C ... i would definitely recommend checking this out: https://live.gnome.org/GObjectIntrospection/Annotations ... and other related docs, because the problems are identical. here is an example API that does not interfere with the translator impl (note: NOT async): <script src="pyjs.js" /> <script> // window is an app frame, not the main frame ctx = pyjs.get_app_ctx(window) func = ctx.get_func_ref('mod.awesome.some_func') args = [1, 2, 3, 'string'] // recursively convert args to python types args = ctx.arr2list(args) kwds = {'hi': 'there', 'wonder': 200} // recursively convert kwds to python types kwds = ctx.obj2dict(kwds) res = ctx.invoke(func, args, kwds) </script> `pyjs.js` would be a JS "module" output by the translator. this modules would maintain a stable API on the JS side, and be automatically linked to the correct places on the python side, even if the translator impl should change radically from one version to the next! this gives the freedom to experiment/improve without breaking code already using the API. again, this example is synchronous (i'll explain the desire for async in a moment). >> - be complete enough to fulfill 95% of what users continually request > > I'm not 100% sure that I understand above. Do you mean, that there too > little ppl who want such feature (I know 1 so far - me :D)? heh, no not at all :-) there have been numerous requests since i've been around, and in general, a standard way of interfacing with JS is probably a Good Thing. i meant the impl needs to be flexible enough that it can handle the overwhelming majority of things people may need from it, which is primarily: - calling arbitrary functions in/from JS - deferring closure calls to/from JS - sending primitive types to/from JS - means of exposing complex types (say a resource-like object) ... that link above on pygobject annotations is a great intro to the language and concepts behind all this. >> - almost certainly needs to be asynchronous > > I don't have even rough idea what did you mean by writing that. the translator in the future may operate in a more async fashion, to improve performance, responsiveness, and/or allow for advanced features like Threading or non-blocking imports. note: the Python "runtime" still _appears_ synchronous ... but since we are working in JS, we get to see things as the *really* operate ... in all it's ugly glory. the problem is this: in the example i provided, any call "into" python may not really take place until a later time, so it becomes necessary to provide a callback to _every_ statement. a normal block of code must then be written as a chain of closures, like a continuation, or CPS-passing style code. it's more convoluted, and the code is less readable, but it can cope with the python engine pausing/breaking (say to run a new "thread" for awhile) and then returning at some arbitrary time in the future. does that make sense? >> this dispatcher relies on implementation details within the translator, >> and is likely to break for obscure reasons. it would also preclude the >> translator from pursuing more ambitious/radical architectures. >> >> i don't mean to discourage -- this just isn't the right way. it would >> however make for a great wiki entry, with the caveat of being a hack, or >> possibly unstable (for the reasons above). > > Ok, so the main question is - do you think that my goal, which means: > - I have site (existing, written in something different than pyjs) where > I embed pyjbuild compiled code, > - I want to eg. launch pyjs based popup panel with > question/widget/something after clicked on some button I already have in > html, > > a) is achievable with quality standards mentioned above - In such case I > will try to follow your standards and guidelines, to have it in pyjamas. I > believe that it's very needed, to have nice looking and good working > equivalent of "<button > onClick='window.frames[0].$pyjs.loaded_modules.all._export()'>" which I had > to use. yes i do think it's achievable, but it's something that will need several iterations of discussion and prototype to get right. > b) it's against pyjamas philosophy, in such case I will just make external > util library which will have this functionality. nah nah, not at all -- things are less driven by "philosophy" these days, and more by "practicality" and "positivity" ;-) if you want to start drafting an API and hacking on the translator, i'll be more than happy to assist/clarify as i'm able. -- C Anthony
