Hi Dimitri
So further to this – I’ve made a lot of progress with translations today, but
I’ve run out of time so rather than release anything half baked I’ll hold off
until tomorrow
John
From: John Spackman <john.spack...@zenesis.com>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Tuesday, 16 February 2016 at 07:26
To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and
100% Javascript API to building applications
Hi Dimitri
So it sounds like resources with paths have an issue, or maybe libraries with
“.” in the namespace – I’ll have a look this morning but as it’s happening with
UploadMgr then I have a reproducible case I can work on.
I’ve had a look at the stack trace – but I can’t see any clues to what might be
causing it; by marshalling, do you mean the qx.data.marshall.*? That should
not be affected, the only change to code was to allow .defer() to not be called
immediately after the class was defined. I’ve just realised that this means
that dynamically defined classes will not have their defer called, and there’s
a fix in the next commit for that but I don’t think that’s the issue your
coming across.
Re Node 0.12: I think there was another problem with early versions of Node <=
0.12 other than just language – I can’t remember exactly what now but there was
something that didn’t work properly until I upgraded. But you’re right,
QxCompiler could be babelified :) At one point, the Babel plugin part was
written as a proper, standalone babel plugin in ES6 but I had some trouble
getting Webstorm to compile and debug properly so I switched back to native code
Re build server: I’d expect QxCompiler to be installed once, globally and then
used externally to the projects, i.e. your build code could do the project
checkout and then use the API to build each project. The project wouldn’t know
about QxCompiler at all.
This sounds similar to my use case, except my builds are on-the-fly on product
servers rather than as part of release: In my case I have multi homed Tomcat
servers, and each website uses Qooxdoo on the server and client; the server
apps generate html (think ASP/PHP/JSP but with javascript & Qooxdoo running
under Rhino) as well as implement server processes, and there is often more
than one client application per website. Doing a major release requires
deleting and recompiling all applications (and typically the cache also), and
with a minimum of 2 apps (1 server + 1 client) per website that can be quite
expensive. At the moment, making a minor patch to the presentation of the
website (e.g. modifying the html output from my PHP/ASP-like pages) means an
expensive build process too which is pretty tedious.
So what I want is to have QxCompiler sitting as a background process, watching
all these applications and the source files they depend on; when a source file
changes it rebuilds the app instantly (e.g. 250ms per affected application) and
notifies Tomcat to reload the server code if necessary. At the moment,
incremental builds take QxCompiler approx 700ms including the (not
insignificant) overhead of starting up node.
Re requirements: I’ve updated the docs to match
I’m working on QxCompiler again this morning and should have an update for you
by lunchtime
Cheers
John
From: Dimitri <mi...@cargosoft.ru>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Monday, 15 February 2016 at 18:16
To: <qooxdoo-devel@lists.sourceforge.net>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and
100% Javascript API to building applications
Hi! Tried again - things are much better now :) However, two issues still
remain, one of them being resource management.
Indeed, test app loads its icons correctly in both versions. Unfortunately,
this is not the case for my app. What I've found yet:
- the app loads all the qx.* resources correctly (window
minimize/maximize/close icons etc.);
- none of the application's own resources could be loaded. The request is made
to "build-output/myapp/foo.png", which obviously results in a 404.
- in resource-db.json, all resources that *do* load contain non-empty metadata
block, while those that do *not* have an empty literal {}. The same could be
observed in qxt for com/zenesis/qx/upload/* resources.
(Please note that our app contains not only images, but audio files in
different formats, mainly mp3/ogg. We put them into "resource/sounds".)
The app still cannot load. That unmarshalling error seems to have gone, but now
I've got a "too much recursion" somewhere around the same location in code.
(stacktrace)
I'll try to produce MWEs for both issues later today. Some other stuff to
consider:
1. NodeJS <= 0.12 is not supported, while 4.x and 5.x are fine (due to object
literal extension used at lib/qxcompiler/ClassFile.js:329). Some distros still
ship NodeJS 0.x with their stable versions. I think this should be mentioned in
the docs. OTOH, why not babelize QxCompiler itself? :)
2. What practice would you recommend for using QxCompiler on a build server?
For each build, a clean checkout is made. Doing npm install in the project
directory is very expensive (~15MB deps). Assuming QxCompiler resides in its
own directory, what would you recommend? symlink <project>/node_modules ->
<QxCompiler>/node_modules? install deps with npm -g and use linklocal ?
Ideally, I'd like some practice that wouldn't change when we finally have a NPM
distro of QxCompiler.
3. It's worth mentioning in the docs that ImageMagick is required (due to
"identify" binary being used in qxcompiler/ResourceManager.js).
Cheers,
Dimitri
------------------------------------------------------------------------------
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
