On Sun, Feb 5, 2012 at 5:39 PM, Pascal Chambon <[email protected]> wrote:
> Hi,
>
> I've just pushed to /master misc. branches that were on SF previously,
> and that have never been merged. That way if someone wants to dig them
> and check if there is some good stuff to be picked in them, he'll be
> able to.
>
> Also, I've somehow finished merging Daniel Kluev's works on the translator.
hooraay!
> In some cases (for loops, assignments), it meant commenting out current
> functions to replace them by Daniel's, which looked more feature-full.
> I'll leave to experienced people the task of combining both versions
> instead, in case some mini-features would have been lost in the process.
>
> All tests are passing, except some added by Daniel (maybe his last
> commit wasn't stable, or maybe I've broken stuffs while merging), so I
> consider there is no regression.
ok, that's great to hear.
> I'll file bugreports later to "silence" these broken tests (mainly
> dealing with sets and extended slices).
> Anyway, I hope some people will check that /master can still compile
> their current projects (I work on windows...)
>
> BTW, some questions to experienced pyjs contributors:
> - what's the deal with "@{{}}" notations ?
that's to tell the JS("""....""") parser to understand that those are
python variables, and to correctly substitute whatever syntax has been
chosen to represent python variables in javascript.
if those identifiers are removed it fucks everything up as it would
require almost 2,000 individual changes to make any kind of
improvements to the JS code. for example i was planning to recommend
going back to x.abc rather than using x['abc'] and that would be a
dead-easy change of a few lines of code NOT a massive search through
thousands of lines of code looking for one bug because there's one JS
variable that isn't covered by the notation system.
they HAVE to be put back in.
if you look at GWT, they have exactly the same system, because there
is exactly the same problem to solve. i think they use "L\{.....}" or
something like that.
> Daniel had begun replaing
> them all with standard string substitutions,
what??? and he didn't consult anyone??
> to make them
> "parser-friendly" (I don't know why), but aren't those handy shortcuts
> actually ?
aw shit. i wish he'd f*****g well actually consulted us on the
mailing list rather than charging ahead. that _was_ supposed to be
how gsoc works: you work _with_ the mentors.
some time last year everyone did a stellar collaborative effort to
put those in: it was something like 1,500 substitutions. they
*cannot* be left out.
> - what's up with the two __builtin__.py and pyjslib.py modules of
> pyjs/src/pyjs sources ? __builtin__.py looks much bigger and featureful
i have no idea what __builtin__.py is. this is the first mention, on
the pyjamasdev mailing list, of the existence of such a file.
a diff -uwbB on the two files is rather instructive.
might be worthwhile just using __builtin__.py and see what happens.
l.
