On Oct 11, 2013 2:11 PM, "C Anthony Risinger" <anth...@xtfx.me> wrote: > > On Fri, Oct 11, 2013 at 12:58 PM, Kees Bos <cornelis....@gmail.com> 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 <anth...@xtfx.me> >> > wrote: >> > On Fri, Oct 11, 2013 at 6:51 AM, Łukasz Mach >> > <lukasz.m...@pagema.net> 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 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. > > 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. -- C Anthony [mobile] -- --- 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 pyjs-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
