On Oct 12, 2013 7:54 AM, "Kees Bos" <cornelis....@gmail.com> wrote: > > On Fri, 2013-10-11 at 19:23 -0500, C Anthony Risinger wrote: > > 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 '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).
I'm pretty sure the cachebuster/signature stuff is enabled... I thought that used the original python source as input (not in front of comp ATM)? Using the flags as part of the signature would be good though, I know we've talked about that before. IIRC, the problem is not actually a collision per se -- pyjsbuild doesn't even *try* to build modules with identical names because it thinks they are already built... If it tried, the output files would not actually conflict (if signature hashing is enabled)... In the event of an existing output file, and if the output file has a sig, maybe pyjsbuild should compute the new sig to make sure they match before deciding to skip. > > > 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? Sure; I'll rerun the builder thing tonight. -- 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.
