On Fri, 2013-10-11 at 19:23 -0500, C Anthony Risinger wrote: > On Oct 11, 2013 2:11 PM, "C Anthony Risinger" <[email protected]> wrote: > > > > On Fri, Oct 11, 2013 at 12:58 PM, Kees Bos <[email protected]> > wrote: > >> > >> On Fri, 2013-10-11 at 12:30 -0500, C Anthony Risinger wrote: > >> > On Fri, Oct 11, 2013 at 12:23 PM, C Anthony Risinger > <[email protected]> > >> > wrote: > >> > On Fri, Oct 11, 2013 at 6:51 AM, Łukasz Mach > >> > <[email protected]> wrote: > >> > > >> > W dniu 11.10.2013 13:34, Kees Bos pisze: > >> > > >> > On Fri, 2013-10-11 at 12:58 +0200, Łukasz > Mach > >> > wrote: > >> > W dniu 11.10.2013 07:37, Kees Bos > >> > pisze: > >> > Currently all examples > are in > >> > the same output > directory. > >> > This gives > >> > naming conflicts (e.g. > >> > kitchensink is not > working for > >> > that reason). > >> > There are two ways (that > I > >> > know of) to overcome > this: > >> > > >> > 1. Put every example > in its > >> > own output directory > >> > 2. Build static > (monolithic > >> > files) and remove the > >> > __output__/lib > >> > directory before building > an > >> > app. > >> > > >> > How (2) will prevent from doing > >> > conflicts? > >> > > >> > By removing the lib file before > translating > >> > the files. All generated js > >> > files are placed in the output/lib > directory > >> > and then included (copied) > >> > into the monolithic file. After that, the > >> > lib/*.js files are not needed > >> > anymore. The removal of the lib directory > also > >> > ensure that all files are > >> > translated (again). With the options for > the > >> > specific project. > >> > > >> > > >> > > >> > I think I'm for (1), because I feel that (2) will > make > >> > still conflicts, eg. when building all examples > at > >> > once. > >> > > >> > > >> > it used to be like (1) and i explicitly changed it to to > >> > compile at once... else it literally takes 45 min to > compile, > >> > and i end up with a couple GB of repeated data (and > github > >> > rejects any attempt to upload) > >> > > >> > > >> > same output directory allows the cache hits, and a 5 min > >> > rebuild. > >> > > >> > > >> > what needs to happen, though slightly annoying, is each > >> > example should be namespaced and imported from, like real > >> > modules... currently the all pretend like they are > top-level > >> > modules and this is problematic on a number of fronts > (eg. > >> > this very issue) and makes it more difficult to mix them > (say, > >> > in a KitchenSink super-example) > >> > > >> > > >> > i think they all need to be make cleanly importable -- > >> > side-by-side -- once and for all. > >> > > >> > > >> > just to emphasize: it's critical they all compile to the same > >> > location, as nobody wants to sling around GBs of JS :) > >> > > >> > > >> > as an brief example, it would look something like this: > >> > > >> > > >> > from examples.anchor import Anchor > >> > from examples.flowpanel import FlowPanel > >> > > >> > [...] > >> > > >> > > >> > ...this is the only sane way to handle moving forward, and > requires no > >> > other hacks/PATH manipulation/etc... once done it will provide a > >> > simple path forward. > >> > > >> Rrright. But that's probably a "longterm" goal. Right now some > examples > >> don't work (i.e. throw errors) because of this issue. That's > >> particularly annoying with the public examples on pyjs.org. > >> > >> BTW. We might need different libs (dirs or md5s) for different > compile > >> options (if there are any). > > > > > > yes... but i can't *physically* upload the examples if they are > separate, due to other constraints... so, unless you want to redo > where/how all the examples get uploaded, they must coexist. > > ^^^^ this might read much harsher than intended... Please insert some > uncertain and winky smiley faces ;) > The 'BTW' is more for a generalized solution. Maybe adding hashes for source directory of the py file, or content of the file could prevent collisions in a generic way (as namespacing does).
> > the short term simple solution is to identify examples that are > colliding, and change one module name to be less generic... like > "logging" for example, which no one should be defining. I've done some renaming/moving of example files. Can you compile and upload them? > > > > everything is compiled with --strict IIRC, i don't see much reason > to putz around with significant deviations from that. > > Sorry, it just calls examples/__main__.py ... So all examples are > built per their individual configs; so long as the names do not > conflict, they can coexist with different flags. > -- --- You received this message because you are subscribed to the Google Groups "Pyjs.org Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
