Hi, > But I’d be interested to collaborate on an official community fork; there may > not be a huge explosion of development activity ;) but it would give us (the > community) the opportunity to take the project forward, merging in changes by > the core 1&1 team. > > What do you/anyone think?
We would definitively be part of it as we have invested too much in it to leave. The goal should not be set too high at least in the start. Instead try to focus on some necessary improvements and take it from there. You are already on the road in that direction... It would be good cause then there will be three roads to go: 1. the currently somnolent 1&1 road 2. the at-least-something-happen-community-road 3. the joint-road where 1&1 opens up, as they should have done long ago.... I prefer alt 3 but can as well choose the alt 2. Stefan > John > > > > > On 16/02/2016, 11:25, "d...@cost-savers.net" <d...@cost-savers.net> wrote: > >>Congratulations John! >> >>This is the major step taken the last 18 months!!! (cause nothing much >>happens with qooxdoo anymore while ExtJS and other frameworks develop quite >>fast) >>You have proven it come be done in a very delicate way. >>You give the core team a huge challenge...the question is if they can handle >>it the right way. No proven good track record in this area...;-( >>Anyways, we have been testing it and it looks amazing and I am sure all your >>work can be reused by all of us to increase modularity... >> >>Thanks! >> >>Stefan >> >>> Thanks Thomas :) >>> >>> I like the API approach too, I think it opens up some possibilities (I >>> remember you had it on your todo list for a while and I can see why). Its >>> definitely been a while coming, I wrote the proof of concept years ago with >>> Esprima but mortgage-paying work always took priority! >>> >>> With my approach to dependencies, QxCompiler is taking a shortcut but >>> reducing that target appears to be very profitable; there have been a >>> couple of cases where I’ve had to add in @require to Qooxdoo classes, this >>> is typically where (e.g.) a qx.core.Environment provider class uses a >>> static method to initialise instead of directly in .defer() and there is an >>> additional dependency, but there’s a lot of cases where explicit @require() >>> is already present so my mods to the framework have been kept to a minimum. >>> >>> I quite like that the database (the equivalent of generator’s cache) is >>> kept quite small too - around 1Mb, and tracking the dependencies of methods >>> would add a lot of data as well as code complexity so if I can keep it this >>> way then that would be ideal. >>> >>> Regards >>> John >>> >>> From: thron7 <thr...@users.sourceforge.net> >>> Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net> >>> Date: Monday, 15 February 2016 at 22:34 >>> To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net> >>> Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and >>> 100% Javascript API to building applications >>> >>> John, >>> >>> this looks interesting! I like the API-based approach (Reminds me of the >>> Clojure "boot" build system's tag line, "Builds are programs"[1]). It seems >>> you have been working on that for a while. >>> >>> [1] http://boot-clj.com/ >>> >>> On Mon, Feb 15, 2016 at 9:28 AM, John Spackman <john-li...@zenesis.com> >>> wrote: >>> >>> >>> The QxCompiler fixes are to do with dependencies – basically, the load >>> dependencies of a Qooxdoo app are greatly complicated because classes can >>> have a defer() method, which allows code to be run before the app is fully >>> loaded. The way (I think/guess) that the generate.py does it is to >>> recursively interpret the code in .defer() and all of the methods it calls, >>> ie it tries to predict at compile-time what methods will be called at >>> runtime so that it can make sure that the load order is correct. As you >>> can imagine this is non-trivial, but IMHO this makes it easy for minor code >>> changes to have a big impact on load order and to cause unresolvable >>> recursive dependency issues. >>> >>> My solution is to not call the class .defer() method until all classes are >>> loaded (that’s not strictly possible because some classes .defer() must be >>> called, but the dependencies are a lot simpler). This solution needs a a >>> couple of backwards compatible mods, mostly in qx.Bootstrap, and these are >>> in the qxcompiler branch >>> >>> There’s bit more detail here: >>> https://github.com/johnspackman/qxcompiler/blob/master/docs/Dependencies.md >>> >>> What really complicates dependency inference is to find the transitive >>> closure for each (what you put as "recursively interpret the code"). But I >>> think you need that for both load-time and run-time dependencies alike. >>> This entails that any small change in far away code can have an impact on >>> the overall set of classes and their load order. (But only load-time makes >>> cyclic dependencies an issue, and that's probably what you care about). >>> >>> Once recursive analysis is in place, adding the symbols from .defer() to >>> the load-time dependencies is easy as you write. So it's not that .defer() >>> makes the general mechanism of treating dependencies more difficult - it >>> just enlarges the set of load-time dependencies, and hence increases the >>> risk of not being able to create a partial order for all the classes. But >>> .defer() is not particularly more problematic than, say, static >>> initializers in the class, or #require's. >>> >>> But I see how .defer() is a good target to minimize on that risk. >>> >>> T. >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance APM >>> + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor >>> end-to-end web transactions and take corrective actions now Troubleshoot >>> faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ >>> qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> >> >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> qooxdoo-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> >> >>------------------------------------------------------------------------------ >>Site24x7 APM Insight: Get Deep Visibility into Application Performance >>APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>Monitor end-to-end web transactions and take corrective actions now >>Troubleshoot faster and improve end-user experience. Signup Now! >>http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >>_______________________________________________ >>qooxdoo-devel mailing list >>qooxdoo-devel@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
