QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

classic Classic list List threaded Threaded
70 messages Options
1234
dev
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

dev
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, "[hidden email]" <[hidden email]> 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 <[hidden email]>
>>> Reply-To:  qooxdoo Development <[hidden email]>
>>> Date:  Monday, 15 February 2016 at 22:34
>>> To:  qooxdoo Development <[hidden email]>
>>> 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 <[hidden email]> 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 [hidden email] 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
>>> [hidden email]
>>> 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
>>[hidden email]
>>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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
In reply to this post by John Spackman
Hi John,

Sorry for all the stir I've raised around resource handling. The problem was in our code. It turned out that we were still using old-style compiler hints (#asset, #use, #require etc.) ignored by QxCompiler.

This in fact caused both issues (resources and unmarshalling). With #asset being ignored, obviously, no resources could be loaded. The second case was a bit more complex. By some obscure reason (Java habit?), we used the following construct in IMarshalDelegate implementation:

/**
 #require(foo.Bar)
*/
...
    getModelClass: function(properties) {
        switch(properties) {
            case 'foo"bar':
                return qx.Class.getByName("foo.Bar");
            default:
                return null;
        }
    }
Obviously, foo.Bar wasn't available at runtime, and the data was unmarshalled to default (generated) class, while foo.Bar was expected. I've eliminated compiler hints completely and replaced qx.Class.getByName calls with direct references. Everything works perfectly now! :)

(I don't think old-style syntax is worth being supported in QxCompiler, but in order to aid oblivious guys like me it would be nice to mention in the docs that #-hints are not supported and should be replaced with @-hints.)

The only two remaining issues are translation (the app runs with its default locale and doesn't pick up *.po files) and script size for single-script build. Load time is much better now, I guess that 10 second delay was caused by unoptimized resource handling. Yet I didn't try any actual Babel transformations; as far as I know, it doesn't do anything by default. For those unfamiliar with Babel, it would be nice if the docs contained some examples of how to actually enable Babel transformations.

As for build setup, I've come up with the following. The script that drives the build lives in VCS in the project directory; upon checkout, "npm link async" is executed, which is a cheap operation that installs a symlink for async module (previously installed globally). It's the only module that is required by the driver script; the rest is successfully pulled from QxCompiler directory.

Cheers, and keep going! QxCompiler is definitely the coolest thing that happened to qooxdoo in last months and maybe years :)

Dimitri

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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
In reply to this post by John Spackman
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 <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Tuesday, 16 February 2016 at 07:26
To: qooxdoo Development <[hidden email]>
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 <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Monday, 15 February 2016 at 18:16
To: <[hidden email]>
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 <a href="https://linklocal? ">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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
In reply to this post by dev
Hi everyone,

I second every word: there's too much invested. After all, qooxdoo is
too cool to let it become abandonware :)

Be it 2nd or 3rd road, I'm in.

Dimitri

В Вт, 16/02/2016 в 16:21 +0100, [hidden email] пишет:

> 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, "[hidden email]" <[hidden email]>
> > 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 <[hidden email]>
> > > > Reply-To:  qooxdoo Development <[hidden email]
> > > > .net>
> > > > Date:  Monday, 15 February 2016 at 22:34
> > > > To:  qooxdoo Development <[hidden email]>
> > > > 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-lists@zene
> > > > sis.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/q
> > > > xcompiler/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://puba
> > > > ds.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140__________
> > > > _____________________________________ qooxdoo-devel mailing
> > > > list [hidden email]
> > > > 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=/414
> > > > 0
> > >
> > > >
> > > > _______________________________________________
> > > > qooxdoo-devel mailing list
> > > > [hidden email]
> > > > 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
> > > [hidden email]
> > > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
In reply to this post by mitya
Hi Dimitri

No worries, those are the kind of bug reports I like to hear, ones where it’s not my fault! :D

Actually I’m a little surprised that the generator supports the # compiler hints still, I thought that had been dropped ages ago; I have yet to add warnings output for unresolved symbols etc so I’ll include warnings for old style hints too.

Babel is on by default, so there’s nothing extra you have to do to start using ES6.  In the qxt Application.js there is this:
button1.addListener("execute", () => alert("Hello World!"));
I’ve got some customer work I have to get done this morning but hopefully have some time put aside this afternoon to finish off translations.  It’s not too big a deal, most of the work is in reading and writing the .po file format so both the extraction of strings process and the loading of translations will be included.  Hopefully todays release will include build target compression too.

Regards
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Tuesday, 16 February 2016 at 21:34
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Hi John,

Sorry for all the stir I've raised around resource handling. The problem was in our code. It turned out that we were still using old-style compiler hints (#asset, #use, #require etc.) ignored by QxCompiler.

This in fact caused both issues (resources and unmarshalling). With #asset being ignored, obviously, no resources could be loaded. The second case was a bit more complex. By some obscure reason (Java habit?), we used the following construct in IMarshalDelegate implementation:

/**
 #require(foo.Bar)
*/
...
    getModelClass: function(properties) {
        switch(properties) {
            case 'foo"bar':
                return qx.Class.getByName("foo.Bar");
            default:
                return null;
        }
    }
Obviously, foo.Bar wasn't available at runtime, and the data was unmarshalled to default (generated) class, while foo.Bar was expected. I've eliminated compiler hints completely and replaced qx.Class.getByName calls with direct references. Everything works perfectly now! :)

(I don't think old-style syntax is worth being supported in QxCompiler, but in order to aid oblivious guys like me it would be nice to mention in the docs that #-hints are not supported and should be replaced with @-hints.)

The only two remaining issues are translation (the app runs with its default locale and doesn't pick up *.po files) and script size for single-script build. Load time is much better now, I guess that 10 second delay was caused by unoptimized resource handling. Yet I didn't try any actual Babel transformations; as far as I know, it doesn't do anything by default. For those unfamiliar with Babel, it would be nice if the docs contained some examples of how to actually enable Babel transformations.

As for build setup, I've come up with the following. The script that drives the build lives in VCS in the project directory; upon checkout, "npm link async" is executed, which is a cheap operation that installs a symlink for async module (previously installed globally). It's the only module that is required by the driver script; the rest is successfully pulled from QxCompiler directory.

Cheers, and keep going! QxCompiler is definitely the coolest thing that happened to qooxdoo in last months and maybe years :)

Dimitri

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

------------------------------------------------------------------------------ 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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
Hi again

There’s a new release which includes support for translations; you don’t have to do anything to enable it, just rerun the qxcompiler.

If you want to update your .po files with new translation strings, there is an example of how to do this for the qxt application in test/update-app-translations-demo.js, but basically after maker.make() has completed, you just call maker.updateTranslations()
// ...snip...
/*
* Make it
*/
function (cb) {
maker.make(cb);
},

/*
* Translations
*/
function (cb) {
maker.updateTranslations(appLibrary, cb);
}
// ...snip...
BUT:: because this modifies the original *.po files in your source directory, please take a backup of your files first.

Build Target compression is next :)

John

From: John Spackman <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 09:08
To: qooxdoo Development <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Hi Dimitri

No worries, those are the kind of bug reports I like to hear, ones where it’s not my fault! :D

Actually I’m a little surprised that the generator supports the # compiler hints still, I thought that had been dropped ages ago; I have yet to add warnings output for unresolved symbols etc so I’ll include warnings for old style hints too.

Babel is on by default, so there’s nothing extra you have to do to start using ES6.  In the qxt Application.js there is this:
button1.addListener("execute", () => alert("Hello World!"));
I’ve got some customer work I have to get done this morning but hopefully have some time put aside this afternoon to finish off translations.  It’s not too big a deal, most of the work is in reading and writing the .po file format so both the extraction of strings process and the loading of translations will be included.  Hopefully todays release will include build target compression too.

Regards
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Tuesday, 16 February 2016 at 21:34
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Hi John,

Sorry for all the stir I've raised around resource handling. The problem was in our code. It turned out that we were still using old-style compiler hints (#asset, #use, #require etc.) ignored by QxCompiler.

This in fact caused both issues (resources and unmarshalling). With #asset being ignored, obviously, no resources could be loaded. The second case was a bit more complex. By some obscure reason (Java habit?), we used the following construct in IMarshalDelegate implementation:

/**
 #require(foo.Bar)
*/
...
    getModelClass: function(properties) {
        switch(properties) {
            case 'foo"bar':
                return qx.Class.getByName("foo.Bar");
            default:
                return null;
        }
    }
Obviously, foo.Bar wasn't available at runtime, and the data was unmarshalled to default (generated) class, while foo.Bar was expected. I've eliminated compiler hints completely and replaced qx.Class.getByName calls with direct references. Everything works perfectly now! :)

(I don't think old-style syntax is worth being supported in QxCompiler, but in order to aid oblivious guys like me it would be nice to mention in the docs that #-hints are not supported and should be replaced with @-hints.)

The only two remaining issues are translation (the app runs with its default locale and doesn't pick up *.po files) and script size for single-script build. Load time is much better now, I guess that 10 second delay was caused by unoptimized resource handling. Yet I didn't try any actual Babel transformations; as far as I know, it doesn't do anything by default. For those unfamiliar with Babel, it would be nice if the docs contained some examples of how to actually enable Babel transformations.

As for build setup, I've come up with the following. The script that drives the build lives in VCS in the project directory; upon checkout, "npm link async" is executed, which is a cheap operation that installs a symlink for async module (previously installed globally). It's the only module that is required by the driver script; the rest is successfully pulled from QxCompiler directory.

Cheers, and keep going! QxCompiler is definitely the coolest thing that happened to qooxdoo in last months and maybe years :)

Dimitri

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

------------------------------------------------------------------------------ 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 [hidden email]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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js 
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

Cheers!
Dimitri

Hi again

There’s a new release which includes support for translations; you don’t have to do anything to enable it, just rerun the qxcompiler.

If you want to update your .po files with new translation strings, there is an example of how to do this for the qxt application in test/update-app-translations-demo.js, but basically after maker.make() has completed, you just call maker.updateTranslations()
// ...snip...
/*
* Make it
*/
function (cb) {
maker.make(cb);
},

/*
* Translations
*/
function (cb) {
maker.updateTranslations(appLibrary, cb);
}
// ...snip...
BUT:: because this modifies the original *.po files in your source directory, please take a backup of your files first.

Build Target compression is next :)

John

From: John Spackman <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 09:08
To: qooxdoo Development <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Hi Dimitri

No worries, those are the kind of bug reports I like to hear, ones where it’s not my fault! :D

Actually I’m a little surprised that the generator supports the # compiler hints still, I thought that had been dropped ages ago; I have yet to add warnings output for unresolved symbols etc so I’ll include warnings for old style hints too.

Babel is on by default, so there’s nothing extra you have to do to start using ES6.  In the qxt Application.js there is this:
button1.addListener("execute", () => alert("Hello World!"));
I’ve got some customer work I have to get done this morning but hopefully have some time put aside this afternoon to finish off translations.  It’s not too big a deal, most of the work is in reading and writing the .po file format so both the extraction of strings process and the loading of translations will be included.  Hopefully todays release will include build target compression too.

Regards
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Tuesday, 16 February 2016 at 21:34
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Hi John,

Sorry for all the stir I've raised around resource handling. The problem was in our code. It turned out that we were still using old-style compiler hints (#asset, #use, #require etc.) ignored by QxCompiler.

This in fact caused both issues (resources and unmarshalling). With #asset being ignored, obviously, no resources could be loaded. The second case was a bit more complex. By some obscure reason (Java habit?), we used the following construct in IMarshalDelegate implementation:

/**
 #require(foo.Bar)
*/
...
    getModelClass: function(properties) {
        switch(properties) {
            case 'foo"bar':
                return qx.Class.getByName("foo.Bar");
            default:
                return null;
        }
    }
Obviously, foo.Bar wasn't available at runtime, and the data was unmarshalled to default (generated) class, while foo.Bar was expected. I've eliminated compiler hints completely and replaced qx.Class.getByName calls with direct references. Everything works perfectly now! :)

(I don't think old-style syntax is worth being supported in QxCompiler, but in order to aid oblivious guys like me it would be nice to mention in the docs that #-hints are not supported and should be replaced with @-hints.)

The only two remaining issues are translation (the app runs with its default locale and doesn't pick up *.po files) and script size for single-script build. Load time is much better now, I guess that 10 second delay was caused by unoptimized resource handling. Yet I didn't try any actual Babel transformations; as far as I know, it doesn't do anything by default. For those unfamiliar with Babel, it would be nice if the docs contained some examples of how to actually enable Babel transformations.

As for build setup, I've come up with the following. The script that drives the build lives in VCS in the project directory; upon checkout, "npm link async" is executed, which is a cheap operation that installs a symlink for async module (previously installed globally). It's the only module that is required by the driver script; the rest is successfully pulled from QxCompiler directory.

Cheers, and keep going! QxCompiler is definitely the coolest thing that happened to qooxdoo in last months and maybe years :)

Dimitri

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

------------------------------------------------------------------------------ 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 [hidden email]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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js 
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
Couldn’t resist one more push – I’ve just uploaded another version, this time with uglify for the BuildTarget.  

There is a little more work to do here, because there is code that can be eliminated for known qx.core.Environment values, e.g. “qx.debug” code should be stripped; this will reduce the final code size as well as reduce dependencies, which will reduce the code size even more.  My guess is that this will bring qxcompiler into the same ball park as generate.py in terms of the size of the final output

John

From: John Spackman <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 20:56
To: qooxdoo Development <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email]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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
In reply to this post by John Spackman
No cigar this time :-\

[[hidden email] test]$ ./compile-app-demo.js 
/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.addConfig (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:10)
    at OptionManager.findConfigs (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:434:16)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:482:12)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)

Dunno why it looks for presets in my home dir. In my previous experiment, everything went smooth (except that it didn't in fact collect any qooxdoo deps, since I removed all plugins - but transpiling itself went fine).

As for uglify - ah, that was stupid. I used original uglify, not uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10 secs for qxt. Not bad.

В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js 
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
Hmm - what happens if you change directory to the root of the QxCompiler repo and run ./test/compile-app-demo.js?

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 22:31
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

No cigar this time :-\

[[hidden email] test]$ ./compile-app-demo.js
/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.addConfig (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:10)
    at OptionManager.findConfigs (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:434:16)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:482:12)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)

Dunno why it looks for presets in my home dir. In my previous experiment, everything went smooth (except that it didn't in fact collect any qooxdoo deps, since I removed all plugins - but transpiling itself went fine).

As for uglify - ah, that was stupid. I used original uglify, not uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10 secs for qxt. Not bad.

В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email]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
[hidden email]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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
[[hidden email] qxcompiler]$ ./test/compile-app-demo.js 
Error: Error: ENOENT: no such file or directory, open '../testdata/qxt/Manifest.json'


Hmm - what happens if you change directory to the root of the QxCompiler repo and run ./test/compile-app-demo.js?

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 22:31
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

No cigar this time :-\

[[hidden email] test]$ ./compile-app-demo.js 
/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.addConfig (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:10)
    at OptionManager.findConfigs (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:434:16)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:482:12)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)

Dunno why it looks for presets in my home dir. In my previous experiment, everything went smooth (except that it didn't in fact collect any qooxdoo deps, since I removed all plugins - but transpiling itself went fine).

As for uglify - ah, that was stupid. I used original uglify, not uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10 secs for qxt. Not bad.

В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js 
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email]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
[hidden email]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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
Hi Dimitri

Sorry I realise now that was a rash suggestion, obviously it had to be in the test directory to work.

I think there’s something odd with your installation because I’ve just switched to a Centos 6.5 VM that has never had node installed, installed Node 4, ImageMagick, cloned the QxCompiler repo, and run npm install.  I discovered a problem with package.json where babel-types wasn’t listed, but once I fixed that with "npm install babel-types —save” I was able to “cd test ; ./compile-app-demo.js” and get a working app, with resources and Bable transpiling.

I tried Node 5 too on the same machine (deleting my ~/.npm, node_modules, and testdata/qxt/source-output directories first) and that also works for me; also the ./compile-app-demo-build.js

If I list installed plugins I get:
$ npm list | grep 2015
├─┬ babel-preset-es2015@6.5.0
│ ├─┬ babel-plugin-check-es2015-constants@6.5.0
│ ├─┬ babel-plugin-transform-es2015-arrow-functions@6.5.2
│ ├─┬ babel-plugin-transform-es2015-block-scoped-functions@6.5.0
│ ├─┬ babel-plugin-transform-es2015-block-scoping@6.5.0
│ ├─┬ babel-plugin-transform-es2015-classes@6.5.2
│ ├─┬ babel-plugin-transform-es2015-computed-properties@6.5.2
│ ├─┬ babel-plugin-transform-es2015-destructuring@6.5.0
│ ├─┬ babel-plugin-transform-es2015-for-of@6.5.2
│ ├─┬ babel-plugin-transform-es2015-function-name@6.5.0
│ ├─┬ babel-plugin-transform-es2015-literals@6.5.0
│ ├─┬ babel-plugin-transform-es2015-modules-commonjs@6.5.2
│ ├─┬ babel-plugin-transform-es2015-object-super@6.5.0
│ ├─┬ babel-plugin-transform-es2015-parameters@6.5.0
│ ├─┬ babel-plugin-transform-es2015-shorthand-properties@6.5.0
│ ├─┬ babel-plugin-transform-es2015-spread@6.5.2
│ ├─┬ babel-plugin-transform-es2015-sticky-regex@6.5.0
│ ├─┬ babel-plugin-transform-es2015-template-literals@6.5.2
│ ├─┬ babel-plugin-transform-es2015-typeof-symbol@6.5.0
│ ├─┬ babel-plugin-transform-es2015-unicode-regex@6.5.0

The array of plugins that was in QxCompiler previously was the equivalent of the es2015 preset, albeit the list was slightly out of date so updating the code to use a preset instead of plugins should only improve support, but you had it working with the preset yesterday so I don’t understand why it is not working now.

Is it possible that you have Babel installed globally and it’s conflicting somehow?  I’ve updated the package.json at GitHub to explicitly reference babel-types, and rechecking out etc on my Centos 6 VM now runs without any complaints so it might be worth updating and trying again.

Regards
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 23:02
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

[[hidden email] qxcompiler]$ ./test/compile-app-demo.js 
Error: Error: ENOENT: no such file or directory, open '../testdata/qxt/Manifest.json'


Hmm - what happens if you change directory to the root of the QxCompiler repo and run ./test/compile-app-demo.js?

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 22:31
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

No cigar this time :-\

[[hidden email] test]$ ./compile-app-demo.js
/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.addConfig (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:10)
    at OptionManager.findConfigs (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:434:16)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:482:12)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)

Dunno why it looks for presets in my home dir. In my previous experiment, everything went smooth (except that it didn't in fact collect any qooxdoo deps, since I removed all plugins - but transpiling itself went fine).

As for uglify - ah, that was stupid. I used original uglify, not uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10 secs for qxt. Not bad.

В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email]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
[hidden email]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 [hidden email]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
[hidden email]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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
John,

This turns to be one of that "bug reports that you like to hear" ;) I've identified the culprit, it was .babelrc in my home dir. We were totally wrong in that Babel ignores .babelrc in embedded mode. In fact, it looks for it *everywhere*:

[mitya@localhost test]$ strace node ./compile-app-demo.js 2>&1 | grep babelrc
access("/home/mitya/qxcompiler/testdata/qxt/source/class/qxt/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/qxt/source/class/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/qxt/source/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/qxt/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/.babelrc", F_OK)    = 0
open("/home/mitya/.babelrc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 11

After the file has been encountered, seems like it tries to resolve presets/plugins relative to that file location.

With that file removed, everything finally worked with qxt! But then I tried to build my own project, and got similar error:

/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya/Projects/foo/source/class/foo"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:486:10)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)
    at Pipeline.transform (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/pipeline.js:48:16)
    at /home/mitya/qxcompiler/lib/qxcompiler/ClassFile.js:220:32

This time no .babelrc files anywhere in the project structure. Remember I earlier did "npm link async" in the project dir so that build script would run. To get rid of this, I removed foo/node_modules and symlinked qxcompiler/node_modules to the project dir. Got yet another error, this time with UploadMgr:

Error: Couldn't find preset "es2015" relative to directory "/home/mitya/qooxdoo-contrib/UploadMgr/source/class/com/zenesis/qx/upload"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:486:10)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)
    at Pipeline.transform (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/pipeline.js:48:16)
    at /home/mitya/qxcompiler/lib/qxcompiler/ClassFile.js:220:32

With node_modules symlinked to qooxdoo-contrib/UploadMgr, finally everything worked. This is easily reproducible if you move qxt outside of QxCompiler dir, place build script inside qxt and adjust paths accordingly (I used absolute paths).

Transpiling and compression work just fine. Yet I've encountered a small bug with translations. If a message is translated with this.tr*() set of functions, everything works fine. If qx.locale.Manager.tr() is used, such a message simply won't make it into the build.
I think we should unconditionally transfer all the *.po strings into the build, since translation in the app could be done based on dynamic, computed values.

I think that as soon as the remaining issues are fixed, QxCompiler can be considered fairly stable. I'm already integrating it into our build process.

Cheers!
Dimitri

Hi Dimitri

Sorry I realise now that was a rash suggestion, obviously it had to be in the test directory to work.

I think there’s something odd with your installation because I’ve just switched to a Centos 6.5 VM that has never had node installed, installed Node 4, ImageMagick, cloned the QxCompiler repo, and run npm install.  I discovered a problem with package.json where babel-types wasn’t listed, but once I fixed that with "npm install babel-types —save” I was able to “cd test ; ./compile-app-demo.js” and get a working app, with resources and Bable transpiling.

I tried Node 5 too on the same machine (deleting my ~/.npm, node_modules, and testdata/qxt/source-output directories first) and that also works for me; also the ./compile-app-demo-build.js

If I list installed plugins I get:
$ npm list | grep 2015
├─┬ babel-preset-es2015@6.5.0
│ ├─┬ babel-plugin-check-es2015-constants@6.5.0
│ ├─┬ babel-plugin-transform-es2015-arrow-functions@6.5.2
│ ├─┬ babel-plugin-transform-es2015-block-scoped-functions@6.5.0
│ ├─┬ babel-plugin-transform-es2015-block-scoping@6.5.0
│ ├─┬ babel-plugin-transform-es2015-classes@6.5.2
│ ├─┬ babel-plugin-transform-es2015-computed-properties@6.5.2
│ ├─┬ babel-plugin-transform-es2015-destructuring@6.5.0
│ ├─┬ babel-plugin-transform-es2015-for-of@6.5.2
│ ├─┬ babel-plugin-transform-es2015-function-name@6.5.0
│ ├─┬ babel-plugin-transform-es2015-literals@6.5.0
│ ├─┬ babel-plugin-transform-es2015-modules-commonjs@6.5.2
│ ├─┬ babel-plugin-transform-es2015-object-super@6.5.0
│ ├─┬ babel-plugin-transform-es2015-parameters@6.5.0
│ ├─┬ babel-plugin-transform-es2015-shorthand-properties@6.5.0
│ ├─┬ babel-plugin-transform-es2015-spread@6.5.2
│ ├─┬ babel-plugin-transform-es2015-sticky-regex@6.5.0
│ ├─┬ babel-plugin-transform-es2015-template-literals@6.5.2
│ ├─┬ babel-plugin-transform-es2015-typeof-symbol@6.5.0
│ ├─┬ babel-plugin-transform-es2015-unicode-regex@6.5.0

The array of plugins that was in QxCompiler previously was the equivalent of the es2015 preset, albeit the list was slightly out of date so updating the code to use a preset instead of plugins should only improve support, but you had it working with the preset yesterday so I don’t understand why it is not working now.

Is it possible that you have Babel installed globally and it’s conflicting somehow?  I’ve updated the package.json at GitHub to explicitly reference babel-types, and rechecking out etc on my Centos 6 VM now runs without any complaints so it might be worth updating and trying again.

Regards
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 23:02
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

[[hidden email] qxcompiler]$ ./test/compile-app-demo.js 
Error: Error: ENOENT: no such file or directory, open '../testdata/qxt/Manifest.json'


Hmm - what happens if you change directory to the root of the QxCompiler repo and run ./test/compile-app-demo.js?

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 22:31
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

No cigar this time :-\

[[hidden email] test]$ ./compile-app-demo.js 
/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.addConfig (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:10)
    at OptionManager.findConfigs (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:434:16)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:482:12)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)

Dunno why it looks for presets in my home dir. In my previous experiment, everything went smooth (except that it didn't in fact collect any qooxdoo deps, since I removed all plugins - but transpiling itself went fine).

As for uglify - ah, that was stupid. I used original uglify, not uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10 secs for qxt. Not bad.

В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js 
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email]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
[hidden email]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 [hidden email]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
[hidden email]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 [hidden email] 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
In reply to this post by John Spackman-3
Feature request: shared cache
=============================

It's common practise in continuous integration that CI server does a
clean checkout per each build. Incremental builds are common practise
too, but they can be unreliable and problematic, especially for complex
builds.

At the moment, QxCompiler maintains a per-project cache that is
populated on first compilation. This might take significant time (up to
1 minute; subsequent builds are incredibly fast though). Original
qooxdoo generator solves this by using platform-wide cache, usually in
$TMPDIR/qx{version}/cache. This also speeds up compilation if there are
several projects using the same qooxdoo version.

It would be nice if QxCompiler supported shared cache in the same
manner. Please mind that configurable cache path is important.
Hardcoded $TMPDIR/smth works bad, because on modern Linux distros
$TMPDIR lives in ramdisk and is cleared at each boot.

Dimitri

> Hi all
>
> There is a first release of my QxCompiler that adds ES6 to Qooxdoo
> applications and replaces the generate.py toolchain with a faster,
> 100% Javascript tool that is easily extensible.
>
> You can find the first release at GitHub here: https://github.com/joh
> nspackman/qxcompiler
>
> It’s an alpha release, but something that’s been in development for a
> while now and which I’m starting to build into my production
> servers.  
>
> I’m very open to pull requests or collaboration, and keen to see this
> become a useful tool for myself as well as others so any questions
> etc please ask.
>
> Regards
> John
>
>
>
>
>
> -------------------------------------------------------------------
> -----------
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
No problem; the next release will have a dbFilename property on qxcompiler.makers.Maker, so compile-app-demo.js now has this:
// Makers use an Analyser to figure out what the Target should write
var maker = new qxcompiler.makers.SimpleApp("qxt.Application", "qxt.theme.Theme").set({
// Targets know how to output an application
target: new qxcompiler.targets.SourceTarget("../testdata/qxt/source-output"),
locales: [ "en", "es" ],
dbFilename: "my-qxcompiler-db.json"
});
dbFilename is relative to the target output dir, or it can be absolute.

John

On 18/02/2016, 11:16, "Dimitri" <[hidden email]> wrote:

Feature request: shared cache
=============================

It's common practise in continuous integration that CI server does a
clean checkout per each build. Incremental builds are common practise
too, but they can be unreliable and problematic, especially for complex
builds.

At the moment, QxCompiler maintains a per-project cache that is
populated on first compilation. This might take significant time (up to
1 minute; subsequent builds are incredibly fast though). Original
qooxdoo generator solves this by using platform-wide cache, usually in
$TMPDIR/qx{version}/cache. This also speeds up compilation if there are
several projects using the same qooxdoo version.

It would be nice if QxCompiler supported shared cache in the same
manner. Please mind that configurable cache path is important.
Hardcoded $TMPDIR/smth works bad, because on modern Linux distros
$TMPDIR lives in ramdisk and is cleared at each boot.

Dimitri

Hi all
There is a first release of my QxCompiler that adds ES6 to Qooxdoo
applications and replaces the generate.py toolchain with a faster,
100% Javascript tool that is easily extensible.
You can find the first release at GitHub here: https://github.com/joh
nspackman/qxcompiler
It’s an alpha release, but something that’s been in development for a
while now and which I’m starting to build into my production
servers.  
I’m very open to pull requests or collaboration, and keen to see this
become a useful tool for myself as well as others so any questions
etc please ask.
Regards
John
-------------------------------------------------------------------
-----------
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!
_______________________________________________
qooxdoo-devel mailing list

------------------------------------------------------------------------------
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!
_______________________________________________
qooxdoo-devel mailing list


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John Spackman
In reply to this post by mitya
Hi Dimitri

Well done for finding that, what a nightmare.  I think I’ve found how to disable the .babelrc, but I think the real issue is a bug in Babel with presets; whatever, the fix is to not use presets and load the plugins individually which is what I’ve done and I’ve just pushed it up.  Please can you reinstate your .babelrc’s and see if this solves it?

This release includes the custom database path; translations I’ll get back onto later on today (I’m a bit behind on my schedule)

That’s great that your using this in production, you’re beating me to it in mine!

Cheers
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Thursday, 18 February 2016 at 08:16
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

John,

This turns to be one of that "bug reports that you like to hear" ;) I've identified the culprit, it was .babelrc in my home dir. We were totally wrong in that Babel ignores .babelrc in embedded mode. In fact, it looks for it *everywhere*:

[mitya@localhost test]$ strace node ./compile-app-demo.js 2>&1 | grep babelrc
access("/home/mitya/qxcompiler/testdata/qxt/source/class/qxt/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/qxt/source/class/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/qxt/source/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/qxt/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/testdata/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/qxcompiler/.babelrc", F_OK) = -1 ENOENT (No such file or directory)
access("/home/mitya/.babelrc", F_OK)    = 0
open("/home/mitya/.babelrc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 11

After the file has been encountered, seems like it tries to resolve presets/plugins relative to that file location.

With that file removed, everything finally worked with qxt! But then I tried to build my own project, and got similar error:

/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya/Projects/foo/source/class/foo"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:486:10)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)
    at Pipeline.transform (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/pipeline.js:48:16)
    at /home/mitya/qxcompiler/lib/qxcompiler/ClassFile.js:220:32

This time no .babelrc files anywhere in the project structure. Remember I earlier did "npm link async" in the project dir so that build script would run. To get rid of this, I removed foo/node_modules and symlinked qxcompiler/node_modules to the project dir. Got yet another error, this time with UploadMgr:

Error: Couldn't find preset "es2015" relative to directory "/home/mitya/qooxdoo-contrib/UploadMgr/source/class/com/zenesis/qx/upload"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:486:10)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)
    at Pipeline.transform (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/pipeline.js:48:16)
    at /home/mitya/qxcompiler/lib/qxcompiler/ClassFile.js:220:32

With node_modules symlinked to qooxdoo-contrib/UploadMgr, finally everything worked. This is easily reproducible if you move qxt outside of QxCompiler dir, place build script inside qxt and adjust paths accordingly (I used absolute paths).

Transpiling and compression work just fine. Yet I've encountered a small bug with translations. If a message is translated with this.tr*() set of functions, everything works fine. If qx.locale.Manager.tr() is used, such a message simply won't make it into the build.
I think we should unconditionally transfer all the *.po strings into the build, since translation in the app could be done based on dynamic, computed values.

I think that as soon as the remaining issues are fixed, QxCompiler can be considered fairly stable. I'm already integrating it into our build process.

Cheers!
Dimitri

Hi Dimitri

Sorry I realise now that was a rash suggestion, obviously it had to be in the test directory to work.

I think there’s something odd with your installation because I’ve just switched to a Centos 6.5 VM that has never had node installed, installed Node 4, ImageMagick, cloned the QxCompiler repo, and run npm install.  I discovered a problem with package.json where babel-types wasn’t listed, but once I fixed that with "npm install babel-types —save” I was able to “cd test ; ./compile-app-demo.js” and get a working app, with resources and Bable transpiling.

I tried Node 5 too on the same machine (deleting my ~/.npm, node_modules, and testdata/qxt/source-output directories first) and that also works for me; also the ./compile-app-demo-build.js

If I list installed plugins I get:
$ npm list | grep 2015
├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]
│ ├─┬ [hidden email]

The array of plugins that was in QxCompiler previously was the equivalent of the es2015 preset, albeit the list was slightly out of date so updating the code to use a preset instead of plugins should only improve support, but you had it working with the preset yesterday so I don’t understand why it is not working now.

Is it possible that you have Babel installed globally and it’s conflicting somehow?  I’ve updated the package.json at GitHub to explicitly reference babel-types, and rechecking out etc on my Centos 6 VM now runs without any complaints so it might be worth updating and trying again.

Regards
John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 23:02
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

[[hidden email] qxcompiler]$ ./test/compile-app-demo.js
Error: Error: ENOENT: no such file or directory, open '../testdata/qxt/Manifest.json'


Hmm - what happens if you change directory to the root of the QxCompiler repo and run ./test/compile-app-demo.js?

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 22:31
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

No cigar this time :-\

[[hidden email] test]$ ./compile-app-demo.js
/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393
          throw new Error("Couldn't find preset " + JSON.stringify(val) + " relative to directory " + JSON.stringify(dirname));
          ^

Error: Couldn't find preset "es2015" relative to directory "/home/mitya"
    at /home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:393:17
    at Array.map (native)
    at OptionManager.resolvePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:385:20)
    at OptionManager.mergePresets (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:369:10)
    at OptionManager.mergeOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328:14)
    at OptionManager.addConfig (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:10)
    at OptionManager.findConfigs (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:434:16)
    at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/options/option-manager.js:482:12)
    at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:211:75)
    at new File (/home/mitya/qxcompiler/node_modules/babel-core/lib/transformation/file/index.js:129:22)

Dunno why it looks for presets in my home dir. In my previous experiment, everything went smooth (except that it didn't in fact collect any qooxdoo deps, since I removed all plugins - but transpiling itself went fine).

As for uglify - ah, that was stupid. I used original uglify, not uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10 secs for qxt. Not bad.

В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
Got it – it was a bug in my plugin I introduced a while ago, but Chrome obviously supports arrow functions natively so I didn’t pick up that the translation wasn’t happening any more.  The .babelrc is not needed for this because we’re using it embedded, I think the .babelrc is only for the CLI

That’s very a good point about the polypill BTW because it’s not being included and it should be, I’ll add that in tomorrow.

The problem with translations is fixed now too, sorry about that I should have deleted the output directory before retesting :oops:

What options are you running Uglify with, and what version are you running?  I’m using "uglify boot.js -m -c”, I just timed it on mine and it’s mangled the qxt app in 11 seconds (I’m using uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve nearly got Uglify done, but stopped for dinner and then saw your email so switched back.

I’ve done the #! entries too

I’ve pushed a new release, give it a go :)

John

From: Dimitri <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 17 February 2016 at 19:33
To: <[hidden email]>
Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

Just a quick follow-up on Babel - I've rolled back to yesterday's version, edited lib/qxcompiler/ClassFile.js:218, replaced that plugins array with presets: [ "es2015" ]. Suddenly, it worked :)
I'm still wondering why it doesn't try to look for any .babelrc file. It's clearly stated in the docs that the "babelrc" option is true by default. And it definitely would be good to have control over Babel via (optional) config file.

Another issue to consider is that not every ES6 feature is implemented via code transformation. Some (ex., Promises) require babel-polyfill. (Mention in the docs? Integrate polyfill into build?)

Dimitri

Hi John,

That pace you're keeping, it's incredible :) Glad to hear translations finally landed!

Unfortunately, I couldn't make them work :(

[[hidden email] test]$ node compile-app-demo.js
[BABEL] Note: The code generator has deoptimised the styling of "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/core/Widget.js" as it exceeds the max of "100KB".
2016-02-17 21:30:13.229 [info ] makers          Writing target Source Target: ../testdata/qxt/source-output/
/home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
              pkgdata.locales["C"] = db.cldr["en"];
                                            ^

TypeError: Cannot read property 'en' of undefined
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:45
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
    at async.forEachOf.async.eachOf (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:13)
    at _parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9)
    at Object.async.parallel (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9)
    at /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:15
    at /home/mitya/qxcompiler/lib/util.js:321:9
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
    at /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16

(removed qxcompiler dir & did clean checkout, didn't help either)

Re: Babel - sadly, didn't make it work either :( that arrow function in qxt/Application.js goes unchanged first to [source|build]-output/transpiled, then to [source|build]-output/script. The same with string templates, etc. Note the above [BABEL] message - that means, Babel is invoked, but doesn't apply any actual transformations. I tried "strace -e trace=open node compile-app-demo.js", and didn't see it open .babelrc or any plugin and/or preset modules. Could you please make sure it's indeed enabled? If it works for you, could you please assist me in tracing/debugging (since I'm a newbie in a Node world)?

As for script compression, I played a bit with the standalone uglify tool. Works pretty fine, but it takes ~30 seconds to process a skeleton app. Do you think it can be sped up if integrated into QxCompiler?

Minor issue: test/*.js scripts could have a shebang string (#!/usr/bin/node) and +x mode so that they could be run directly, without typing "node ..." each time.

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 [hidden email]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
[hidden email]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 [hidden email]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
[hidden email]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 [hidden email]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
[hidden email]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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
John,

Tried recent version, everything seems to work now. .babelrc's are
ignored; it's no longer needed to symlink node_modules to the app and
contribs directories, "npm link async" in the project dir is
sufficient. However, I have to admit that .babelrc/.babelignore is a
useful mechanism, since (if it worked properly) it would allow to use
different Babel settings, or completely disable it, on a per-directory
basis. Ideally, the compiler should honour .babelrc/.babelignore *and*
pull all the presets and plugins from a single location, be it
qxcompiler/node_modules or /usr/lib/node_modules (as soon as NPM
packaging is ready).

Re: database path - well done! is it safe to use a single shared db
file for a set of projects + particular qooxdoo version (provided that
no parallel compilations occur)?

Wow, we are only one step away from production :) It will be pretty
easy for us to migrate to QxCompiler, since our setup is much simpler
than yours. It's a real-time communication application with pure JavaEE
backend and qooxdoo RIA frontend, so no (yet) JavaScript on server
side.

Slightly offtopic: did you try Nashorn with your server-side? Should be
much faster and feature-rich. Besides, we are planning an opensource
project - JavaScript console for JavaEE with qooxdoo frontend a la
Playground. It would allow to author/run/manage server-side scripts,
with support for CDI injections, scheduled execution, user/system
script library etc. I'd like to ask you (and everyone else here) to let
me know if you're interested.

Dimitri

> Hi Dimitri
>
> Well done for finding that, what a nightmare.  I think I’ve found how
> to disable the .babelrc, but I think the real issue is a bug in Babel
> with presets; whatever, the fix is to not use presets and load the
> plugins individually which is what I’ve done and I’ve just pushed it
> up.  Please can you reinstate your .babelrc’s and see if this solves
> it?
>
> This release includes the custom database path; translations I’ll get
> back onto later on today (I’m a bit behind on my schedule)
>
> That’s great that your using this in production, you’re beating me to
> it in mine!
>
> Cheers
> John
>
> From: Dimitri <[hidden email]>
> Reply-To: qooxdoo Development <[hidden email]>
> Date: Thursday, 18 February 2016 at 08:16
> To: <[hidden email]>
> Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> compilation, and 100% Javascript API to building applications
>
> John,
>
> This turns to be one of that "bug reports that you like to hear" ;)
> I've identified the culprit, it was .babelrc in my home dir. We were
> totally wrong in that Babel ignores .babelrc in embedded mode. In
> fact, it looks for it *everywhere*:
>
> [mitya@localhost test]$ strace node ./compile-app-demo.js 2>&1 | grep
> babelrc
> access("/home/mitya/qxcompiler/testdata/qxt/source/class/qxt/.babelrc
> ", F_OK) = -1 ENOENT (No such file or directory)
> access("/home/mitya/qxcompiler/testdata/qxt/source/class/.babelrc",
> F_OK) = -1 ENOENT (No such file or directory)
> access("/home/mitya/qxcompiler/testdata/qxt/source/.babelrc", F_OK) =
> -1 ENOENT (No such file or directory)
> access("/home/mitya/qxcompiler/testdata/qxt/.babelrc", F_OK) = -1
> ENOENT (No such file or directory)
> access("/home/mitya/qxcompiler/testdata/.babelrc", F_OK) = -1 ENOENT
> (No such file or directory)
> access("/home/mitya/qxcompiler/.babelrc", F_OK) = -1 ENOENT (No such
> file or directory)
> access("/home/mitya/.babelrc", F_OK)    = 0
> open("/home/mitya/.babelrc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 11
>
> After the file has been encountered, seems like it tries to resolve
> presets/plugins relative to that file location.
>
> With that file removed, everything finally worked with qxt! But then
> I tried to build my own project, and got similar error:
>
> /home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:393
>           throw new Error("Couldn't find preset " +
> JSON.stringify(val) + " relative to directory " +
> JSON.stringify(dirname));
>           ^
>
> Error: Couldn't find preset "es2015" relative to directory
> "/home/mitya/Projects/foo/source/class/foo"
>     at /home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:393:17
>     at Array.map (native)
>     at OptionManager.resolvePresets
> (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:385:20)
>     at OptionManager.mergePresets
> (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:369:10)
>     at OptionManager.mergeOptions
> (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:328:14)
>     at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:486:10)
>     at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/index.js:211:75)
>     at new File (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/index.js:129:22)
>     at Pipeline.transform (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/pipeline.js:48:16)
>     at /home/mitya/qxcompiler/lib/qxcompiler/ClassFile.js:220:32
>
> This time no .babelrc files anywhere in the project structure.
> Remember I earlier did "npm link async" in the project dir so that
> build script would run. To get rid of this, I removed
> foo/node_modules and symlinked qxcompiler/node_modules to the project
> dir. Got yet another error, this time with UploadMgr:
>
> Error: Couldn't find preset "es2015" relative to directory
> "/home/mitya/qooxdoo-
> contrib/UploadMgr/source/class/com/zenesis/qx/upload"
>     at /home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:393:17
>     at Array.map (native)
>     at OptionManager.resolvePresets
> (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:385:20)
>     at OptionManager.mergePresets
> (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:369:10)
>     at OptionManager.mergeOptions
> (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:328:14)
>     at OptionManager.init (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/options/option-manager.js:486:10)
>     at File.initOptions (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/index.js:211:75)
>     at new File (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/file/index.js:129:22)
>     at Pipeline.transform (/home/mitya/qxcompiler/node_modules/babel-
> core/lib/transformation/pipeline.js:48:16)
>     at /home/mitya/qxcompiler/lib/qxcompiler/ClassFile.js:220:32
>
> With node_modules symlinked to qooxdoo-contrib/UploadMgr, finally
> everything worked. This is easily reproducible if you move qxt
> outside of QxCompiler dir, place build script inside qxt and adjust
> paths accordingly (I used absolute paths).
>
> Transpiling and compression work just fine. Yet I've encountered a
> small bug with translations. If a message is translated with
> this.tr*() set of functions, everything works fine. If
> qx.locale.Manager.tr() is used, such a message simply won't make it
> into the build.
> I think we should unconditionally transfer all the *.po strings into
> the build, since translation in the app could be done based on
> dynamic, computed values.
>
> I think that as soon as the remaining issues are fixed, QxCompiler
> can be considered fairly stable. I'm already integrating it into our
> build process.
>
> Cheers!
> Dimitri
>
> > Hi Dimitri
> >
> > Sorry I realise now that was a rash suggestion, obviously it had to
> > be in the test directory to work.
> >
> > I think there’s something odd with your installation because I’ve
> > just switched to a Centos 6.5 VM that has never had node installed,
> > installed Node 4, ImageMagick, cloned the QxCompiler repo, and run
> > npm install.  I discovered a problem with package.json where babel-
> > types wasn’t listed, but once I fixed that with "npm install babel-
> > types —save” I was able to “cd test ; ./compile-app-demo.js” and
> > get a working app, with resources and Bable transpiling.
> >
> > I tried Node 5 too on the same machine (deleting my ~/.npm,
> > node_modules, and testdata/qxt/source-output directories first) and
> > that also works for me; also the ./compile-app-demo-build.js
> >
> > If I list installed plugins I get:
> > $ npm list | grep 2015
> > ├─┬ babel-preset-es2015@6.5.0
> > │ ├─┬ babel-plugin-check-es2015-constants@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-arrow-functions@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-block-scoped-functions@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-block-scoping@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-classes@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-computed-properties@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-destructuring@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-for-of@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-function-name@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-literals@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-modules-commonjs@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-object-super@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-parameters@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-shorthand-properties@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-spread@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-sticky-regex@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-template-literals@6.5.2
> > │ ├─┬ babel-plugin-transform-es2015-typeof-symbol@6.5.0
> > │ ├─┬ babel-plugin-transform-es2015-unicode-regex@6.5.0
> >
> > The array of plugins that was in QxCompiler previously was the
> > equivalent of the es2015 preset, albeit the list was slightly out
> > of date so updating the code to use a preset instead of plugins
> > should only improve support, but you had it working with the preset
> > yesterday so I don’t understand why it is not working now.
> >
> > Is it possible that you have Babel installed globally and it’s
> > conflicting somehow?  I’ve updated the package.json at GitHub to
> > explicitly reference babel-types, and rechecking out etc on my
> > Centos 6 VM now runs without any complaints so it might be worth
> > updating and trying again.
> >
> > Regards
> > John
> >
> > From: Dimitri <[hidden email]>
> > Reply-To: qooxdoo Development <[hidden email]>
> > Date: Wednesday, 17 February 2016 at 23:02
> > To: <[hidden email]>
> > Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> > compilation, and 100% Javascript API to building applications
> >
> > [mitya@localhost qxcompiler]$ ./test/compile-app-demo.js 
> > Error: Error: ENOENT: no such file or directory, open
> > '../testdata/qxt/Manifest.json'
> >
> >
> > > Hmm - what happens if you change directory to the root of the
> > > QxCompiler repo and run ./test/compile-app-demo.js?
> > >
> > > From: Dimitri <[hidden email]>
> > > Reply-To: qooxdoo Development <[hidden email]
> > > t>
> > > Date: Wednesday, 17 February 2016 at 22:31
> > > To: <[hidden email]>
> > > Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> > > compilation, and 100% Javascript API to building applications
> > >
> > > No cigar this time :-\
> > >
> > > [mitya@localhost test]$ ./compile-app-demo.js 
> > > /home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:393
> > >           throw new Error("Couldn't find preset " +
> > > JSON.stringify(val) + " relative to directory " +
> > > JSON.stringify(dirname));
> > >           ^
> > >
> > > Error: Couldn't find preset "es2015" relative to directory
> > > "/home/mitya"
> > >     at /home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:393:17
> > >     at Array.map (native)
> > >     at OptionManager.resolvePresets
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:385:20)
> > >     at OptionManager.mergePresets
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:369:10)
> > >     at OptionManager.mergeOptions
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:328:14)
> > >     at OptionManager.addConfig
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:234:10)
> > >     at OptionManager.findConfigs
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:434:16)
> > >     at OptionManager.init
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/options/option-manager.js:482:12)
> > >     at File.initOptions
> > > (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/index.js:211:75)
> > >     at new File (/home/mitya/qxcompiler/node_modules/babel-
> > > core/lib/transformation/file/index.js:129:22)
> > >
> > > Dunno why it looks for presets in my home dir. In my previous
> > > experiment, everything went smooth (except that it didn't in fact
> > > collect any qooxdoo deps, since I removed all plugins - but
> > > transpiling itself went fine).
> > >
> > > As for uglify - ah, that was stupid. I used original uglify, not
> > > uglify-js. Just tried the latter (2.6.1) - indeed, it takes ~10
> > > secs for qxt. Not bad.
> > >
> > > В Ср, 17/02/2016 в 20:56 +0000, John Spackman пишет:
> > > > Got it – it was a bug in my plugin I introduced a while ago,
> > > > but Chrome obviously supports arrow functions natively so I
> > > > didn’t pick up that the translation wasn’t happening any more.
> > > >  The .babelrc is not needed for this because we’re using it
> > > > embedded, I think the .babelrc is only for the CLI
> > > >
> > > > That’s very a good point about the polypill BTW because it’s
> > > > not being included and it should be, I’ll add that in tomorrow.
> > > >
> > > > The problem with translations is fixed now too, sorry about
> > > > that I should have deleted the output directory before
> > > > retesting :oops:
> > > >
> > > > What options are you running Uglify with, and what version are
> > > > you running?  I’m using "uglify boot.js -m -c”, I just timed it
> > > > on mine and it’s mangled the qxt app in 11 seconds (I’m using
> > > > uglify 2.6.1)  Still not great but better than 30 secs :)  I’ve
> > > > nearly got Uglify done, but stopped for dinner and then saw
> > > > your email so switched back.
> > > >
> > > > I’ve done the #! entries too
> > > >
> > > > I’ve pushed a new release, give it a go :)
> > > >
> > > > John
> > > >
> > > > From: Dimitri <[hidden email]>
> > > > Reply-To: qooxdoo Development <[hidden email].
> > > > net>
> > > > Date: Wednesday, 17 February 2016 at 19:33
> > > > To: <[hidden email]>
> > > > Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> > > > compilation, and 100% Javascript API to building applications
> > > >
> > > > Just a quick follow-up on Babel - I've rolled back to
> > > > yesterday's version, edited lib/qxcompiler/ClassFile.js:218,
> > > > replaced that plugins array with presets: [ "es2015" ].
> > > > Suddenly, it worked :)
> > > > I'm still wondering why it doesn't try to look for any .babelrc
> > > > file. It's clearly stated in the docs that the "babelrc" option
> > > > is true by default. And it definitely would be good to have
> > > > control over Babel via (optional) config file.
> > > >
> > > > Another issue to consider is that not every ES6 feature is
> > > > implemented via code transformation. Some (ex., Promises)
> > > > require babel-polyfill. (Mention in the docs? Integrate
> > > > polyfill into build?)
> > > >
> > > > Dimitri
> > > >
> > > > > Hi John,
> > > > >
> > > > > That pace you're keeping, it's incredible :) Glad to hear
> > > > > translations finally landed!
> > > > >
> > > > > Unfortunately, I couldn't make them work :(
> > > > >
> > > > > [mitya@localhost test]$ node compile-app-demo.js 
> > > > > [BABEL] Note: The code generator has deoptimised the styling
> > > > > of
> > > > > "/home/mitya/qxcompiler/qooxdoo/framework/source/class/qx/ui/
> > > > > core/Widget.js" as it exceeds the max of "100KB".
> > > > > 2016-02-17 21:30:13.229 [info ] makers          Writing
> > > > > target Source Target: ../testdata/qxt/source-output/
> > > > > /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239
> > > > >               pkgdata.locales["C"] = db.cldr["en"];
> > > > >                                             ^
> > > > >
> > > > > TypeError: Cannot read property 'en' of undefined
> > > > >     at
> > > > > /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:239:4
> > > > > 5
> > > > >     at
> > > > > /home/mitya/qxcompiler/node_modules/async/lib/async.js:718:13
> > > > >     at async.forEachOf.async.eachOf
> > > > > (/home/mitya/qxcompiler/node_modules/async/lib/async.js:233:1
> > > > > 3)
> > > > >     at _parallel
> > > > > (/home/mitya/qxcompiler/node_modules/async/lib/async.js:717:9
> > > > > )
> > > > >     at Object.async.parallel
> > > > > (/home/mitya/qxcompiler/node_modules/async/lib/async.js:731:9
> > > > > )
> > > > >     at
> > > > > /home/mitya/qxcompiler/lib/qxcompiler/targets/Target.js:236:1
> > > > > 5
> > > > >     at /home/mitya/qxcompiler/lib/util.js:321:9
> > > > >     at
> > > > > /home/mitya/qxcompiler/node_modules/async/lib/async.js:52:16
> > > > >     at
> > > > > /home/mitya/qxcompiler/node_modules/async/lib/async.js:269:32
> > > > >     at
> > > > > /home/mitya/qxcompiler/node_modules/async/lib/async.js:44:16
> > > > >
> > > > > (removed qxcompiler dir & did clean checkout, didn't help
> > > > > either)
> > > > >
> > > > > Re: Babel - sadly, didn't make it work either :( that arrow
> > > > > function in qxt/Application.js goes unchanged first to
> > > > > [source|build]-output/transpiled, then to [source|build]-
> > > > > output/script. The same with string templates, etc. Note the
> > > > > above [BABEL] message - that means, Babel is invoked, but
> > > > > doesn't apply any actual transformations. I tried "strace -e
> > > > > trace=open node compile-app-demo.js", and didn't see it open
> > > > > .babelrc or any plugin and/or preset modules. Could you
> > > > > please make sure it's indeed enabled? If it works for you,
> > > > > could you please assist me in tracing/debugging (since I'm a
> > > > > newbie in a Node world)?
> > > > >
> > > > > As for script compression, I played a bit with the standalone
> > > > > uglify tool. Works pretty fine, but it takes ~30 seconds to
> > > > > process a skeleton app. Do you think it can be sped up if
> > > > > integrated into QxCompiler?
> > > > >
> > > > > Minor issue: test/*.js scripts could have a shebang string
> > > > > (#!/usr/bin/node) and +x mode so that they could be run
> > > > > directly, without typing "node ..." each time.
> > > > >
> > > > > 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://puba
> > > > ds.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140__________
> > > > _____________________________________ qooxdoo-devel mailing
> > > > list qooxdoo-
> > > > [hidden email]://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=/414
> > > > 0
> > > > _______________________________________________
> > > > qooxdoo-devel mailing list
> > > > [hidden email]://lists.sourceforge.ne
> > > > t/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-
> > > [hidden email]://lists.sourceforge.net/lists/li
> > > stinfo/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
> > > [hidden email]://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-
> > [hidden email]://lists.sourceforge.net/lists/list
> > info/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
> > [hidden email]://lists.sourceforge.net/li
> > sts/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 [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: QxCompiler - add ES6, faster compilation, and 100% Javascript API to building applications

mitya
In reply to this post by John Spackman
John,

I gave it a shot, but not sure if I did it right. In create-app-
demo.js, I adjusted dbFilename to point to absolute location in /tmp.
First time compilation took ~30 seconds. Then I removed source-output,
as if it were a clean checkout, tried to recompile and observed no
speed-up at all.

It suddenly came to my mind: does Babel transpile all the (required)
qooxdoo classes each time? I think it's a redundant step since qooxdoo
itself is pretty much ES5 compliant.

I'm not a Node.js pro (I'm a JavaEE architect in fact :) so I'm not
experienced in profiling Node applications. It would be nice if some
verbose output (with timings) was produced by QxCompiler, as a poor
man's profiling facility :)

Dimitri

P.S. Sorry for "practise" instead of "practice", I usually don't do
such stupid mistakes. I even looked it up in the dictionary before
writing a message, but finally screwed everything up :-D

> No problem; the next release will have a dbFilename property on
> qxcompiler.makers.Maker, so compile-app-demo.js now has this:
> // Makers use an Analyser to figure out what the Target should write
> var maker = new qxcompiler.makers.SimpleApp("qxt.Application",
> "qxt.theme.Theme").set({
>   // Targets know how to output an application
>   target: new
> qxcompiler.targets.SourceTarget("../testdata/qxt/source-output"),
>   locales: [ "en", "es" ],
>   dbFilename: "my-qxcompiler-db.json"
> });
> dbFilename is relative to the target output dir, or it can be
> absolute.
>
> John
>
> On 18/02/2016, 11:16, "Dimitri" <[hidden email]> wrote:
>
> Feature request: shared cache
> =============================
>
> It's common practise in continuous integration that CI server does a
> clean checkout per each build. Incremental builds are common practise
> too, but they can be unreliable and problematic, especially for
> complex
> builds.
>
> At the moment, QxCompiler maintains a per-project cache that is
> populated on first compilation. This might take significant time (up
> to
> 1 minute; subsequent builds are incredibly fast though). Original
> qooxdoo generator solves this by using platform-wide cache, usually
> in
> $TMPDIR/qx{version}/cache. This also speeds up compilation if there
> are
> several projects using the same qooxdoo version.
>
> It would be nice if QxCompiler supported shared cache in the same
> manner. Please mind that configurable cache path is important.
> Hardcoded $TMPDIR/smth works bad, because on modern Linux distros
> $TMPDIR lives in ramdisk and is cleared at each boot.
>
> Dimitri
>
> Hi all
> There is a first release of my QxCompiler that adds ES6 to Qooxdoo
> applications and replaces the generate.py toolchain with a faster,
> 100% Javascript tool that is easily extensible.
> You can find the first release at GitHub here: https://github.com/joh
> nspackman/qxcompiler
> It’s an alpha release, but something that’s been in development for a
> while now and which I’m starting to build into my production
> servers.  
> I’m very open to pull requests or collaboration, and keen to see this
> become a useful tool for myself as well as others so any questions
> etc please ask.
> Regards
> John
> -------------------------------------------------------------------
> -----------
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
1234