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
