Hi Stefan Glad you like it :) I think that the important thing about a VCS like git is that it is easier to take things forward ourselves if we want to. So my qxcompiler branch is designed to easily fit in with anyone elses. 1&1 have their own corporate direction which may not have much focus on Qooxdoo any more, and although there might be a connection between the MIT license and decentralising the core repo I haven’t heard anything yet
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? 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
