John,
Just to clarify - by "translations" I mean the process of integrating
*.po files into the final build, so that tr() functions correctly pick
up locale and produce localized messages. By "translations" I don't
mean the process of extraction of strings from the source and
generating *.po files. I consider the latter to be of much lower
priority, since it's usually done once. Just wanted to make sure that
you don't focus on a low-priority task due to some misunderstanding :)
Dimitri
> 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 /node_modules -> /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------------------------------------------------------------------------------
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
