Hi! Tried again - things are much better now :) However, two issues
still remain, one of them being resource management.
Indeed, test app loads its icons correctly in both versions.
Unfortunately, this is not the case for my app. What I've found yet:
- the app loads all the qx.* resources correctly (window
minimize/maximize/close icons etc.);
- none of the application's own resources could be loaded. The request
is made to "build-output/myapp/foo.png", which obviously results in a
404.
- in resource-db.json, all resources that *do* load contain non-empty
metadata block, while those that do *not* have an empty literal {}.
The same could be observed in qxt for com/zenesis/qx/upload/*
resources.
(Please note that our app contains not only images, but audio files in
different formats, mainly mp3/ogg. We put them into "resource/sounds".)
The app still cannot load. That unmarshalling error seems to have
gone, but now I've got a "too much recursion" somewhere around the
same location in code. (stacktrace)
I'll try to produce MWEs for both issues later today. Some other stuff
to consider:
1. NodeJS <= 0.12 is not supported, while 4.x and 5.x are fine (due to
object literal extension used at lib/qxcompiler/ClassFile.js:329).
Some distros still ship NodeJS 0.x with their stable versions. I think
this should be mentioned in the docs. OTOH, why not babelize
QxCompiler itself? :)
2. What practice would you recommend for using QxCompiler on a build
server? For each build, a clean checkout is made. Doing npm install in
the project directory is very expensive (~15MB deps). Assuming
QxCompiler resides in its own directory, what would you recommend?
symlink <project>/node_modules -> <QxCompiler>/node_modules? install
deps with npm -g and use linklocal ? Ideally, I'd like some practice
that wouldn't change when we finally have a NPM distro of QxCompiler.
3. It's worth mentioning in the docs that ImageMagick is required (due
to "identify" binary being used in qxcompiler/ResourceManager.js).
Cheers,
Dimitri
> HI Dimitri
>
> Ready and waiting ;)
>
> Re 1 testdata/qxt: fixed now, but what you did is fine (my version
> just has a couple of irrelevant test/demo tweaks)
>
> Re 2 build process, messages: fixed
>
> Re 2 build process, too many open files: ah – OK I can throttle
> that, I just saw that on my mac ulimit is unlimited (!)
>
> Re 3 icon resource not found: when you copied the source directory
> into testdata/qxt did you copy the resource directory also? I don’t
> understand this because it works for me :( You’re right that it
> should be looking in the resource/ folder for resources, and that’s
> what mine’s doing here. I’ve just done a fresh checkout from the
> repo and tried it OK, so please can you try pulling, deleting the
> build-output directory and try again?
>
> Re 3 all resources being copied: fixed (this should fix your ulimit
> issue too)
>
> Re 4 UploadMgr: yes that’s exactly how to add a contrib. I’ve fixed
> the problem in UploadMgr so that it is not strict mode compatible
> and added it to the qxt app as a demo.
>
> Re 5 this.self() not working: fixed
>
> Re 6 environment settings: yes, I’ve added a property to
> qxcompiler.Maker that is a map you can set; test/compile-app-demo.js
> now looks like 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")
> });
> maker.setEnvironment({
> "qxt.customEnvironment": "this is custom (source target)"
> });
> Re 7: Locales and translation: Locales are supported but
> translations not yet; it should be straightforward though, so I’ll
> take a look at translations maybe tonight, probably tomorrow
>
> Re 8: Large build-target output: the output isn’t
> compressed/minified yet, but I’ll be adding that in “real soon now”;
> I’m planning on using UglifyJS to do this, my quick test so far
> shows that the size of the qxt app is reduced from 3.9Mb to 1.1Mb,
> so not as good yet as generate.py but in the general area. I think
> the remaining reduction in size will come by dead code elimination
> because the superfluous qx.debug code is not removed from the Build
> Target yet
>
> Well I’m pleased with that for a morning’s work :) There’s a bit
> more to do that I’ll get onto tonight/tomorrow but it should be
> enough to get you going on the next step. Don’t forget to checkout
> the qooxdoo repo as well as the main QxCompiler one.
>
> Cheers
> John
>
>
> From: Dimitri <mi...@cargosoft.ru>
> Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
> Date: Monday, 15 February 2016 at 03:28
> To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
> Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> compilation, and 100% Javascript API to building applications
>
> Hi John! Ready for another dozen of questions and bug reports? ;)
>
> 1. As for testdata/qxt directory - yup, it is indeed present, but I
> don't see "source" subdirectory, where I would expect the actual
> application code to reside. So I just ran "create-application.py -n
> qxt" in another location and copied the generated "source"
> subdirectory to testdata/qxt. Is it how it is supposed to work?
>
> 2. The build process spits a lot of trace messages like this:
> Function enter: anonymous
> Function exit: anonymous
>
> SourceTarget completes successfully, but BuildTarget fails with the
> following:
>
> 2016-02-15 04:10:22.045 [info ] makers Writing target Build
> Target: ../testdata/qxt/build-output/
> events.js:141
> throw er; // Unhandled 'error' event
> ^
>
> Error: EMFILE: too many open files, open '../testdata/qxt/build-
> output//resource/qx/icon/Tango/48/actions/go-home.png'
> at Error (native)
>
> I had to increase open file descriptors limit (ulimit -n 8192 worked
> for me). If this cannot be fixed/optimized, probably it should be
> reflected in the docs.
>
> 3. There seems to be a big mess with resources. Test app works well
> in its source variant, but the single-script build fails to load an
> icon:
>
> GET http://localhost:8282/qxcompiler/testdata/qxt/build-
> output/qxt/test.png [HTTP/1.0 404 File not found 2ms]
> 000472 qx.ui.basic.Image[45-0]: Image could not be loaded:
> qxt/test.png boot.js:54698:13
> 000474 qx.ui.basic.Image[45-0]: Image could not be loaded:
> qxt/test.png boot.js:54698:13
> 000569 ImageLoader: Not recognized format of external image
> 'qxt/test.png'! boot.js:54698:13
>
> Shouldn't it look in "resources" subdirectory instead? The subdir is
> present and does contain resources; however, it seems to contain
> *all* the available qooxdoo+app resources (~3600 files, ~25M).
> generate.py usually produces a ~150K subdir containing resources
> that are actually required.
>
> At the same time, my application was unable to load resources
> neither in source nor in build variant. In both cases it tried to
> (unsuccessfully) look up resources in that very same "source-output"
> or "build-output" directory.
>
> 4. Our project uses your (excellent :) UploadMgr contrib. I've added
> the following to the async.series block:
>
> function(cb) {
> maker.addLibrary("/path/to/qooxdoo-contrib/UploadMgr", cb);
> },
>
> Is this the right way to integrate a contrib into the project?
>
> Can't yet say whether it worked or not, as I didn't manage to make
> application work (see below). I've noticed the following in console:
> SyntaxError: in strict mode code, functions may be declared only at
> top level or immediately within another function (source-
> output/transpiled//com/zenesis/qx/upload/XhrHandler.js:212:19)
> (original file line 212, function sendAsMime definition)
>
> 5. One of my classes invokes its static method from a constructor.
> According to qooxdoo docs, this should be done this way:
> this.self(arguments).foo();
>
> The application failed to load because of "this.constructor.self"
> being undefined. The following however worked fine:
> this.constructor.foo();
>
> This could potentially break applications that access static members
> from constructors and/or instance methods. (I'm not sure if
> constructor is some special case.)
>
> 6. Is there a way to pass qooxdoo environment keys to the app a la
> config.js? Much better if the values could be passed via command
> line. Our build system produces metadata (version, build number,
> revision, timestamp) which we are planning to pass to the app in the
> form of qx.core.Environment keys.
>
> 7. What about locales & translation? For us, it is essential because
> our app is already bilingual, and more languages are to come.
>
> 8. For our app, "generate.py build" produces a ~900K script, and it
> takes less than a second for the app to be up and running.
> QxCompiler/BuildTarget produces a huge ~5M single script, and
> application startup takes up to 10 seconds (!)
> What is the recommended way to produce optimized/minified build that
> would be comparable to the original one?
>
> Okay, that's enough for today :) Tomorrow I'll try to figure out the
> cause of another failure that prevents our app from starting up.
> It's something related to JSON unmarshalling; the data is
> unmarshalled as auto-generated class
> (qx.data.model.prop1"prop2"prop3[123-0]), while it should be an
> application class resolved by a marshal delegate. This works fine
> with generate.py.
>
> Good luck!
> Dimitri
>
> > Further to this - I've added some docs about the API, but also
> > seen that the BuildTarget has a bug and doesn't work - it's only a
> > minor issue but I probably wont have time to fix it until tonight
> >
> > John
> >
> >
> >
> > From: "John Spackman" <john.spack...@zenesis.com>
> > Sent: Sunday, February 14, 2016 9:50 AM
> > To: "qooxdoo Development" <qooxdoo-devel@lists.sourceforge.net>
> > Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> > compilation, and 100% Javascript API to building applications
> >
> > Hi Dimitri
> >
> > Thanks for checking out so quickly :)
> >
> > Re: npm and docs: done
> >
> > Re: qooxdoo submodule and https: fixed
> >
> > Re: QOOXDOO_PATH: no - that's a generator.py/config.json setting
> > and config.json files are completely ignored; when using the
> > QxCompiler API, once you have told it where the Qooxdoo library is
> > you have done the equivalent of setting QOOXDOO_PATH. Of course,
> > as it's API based you can define variables etc as suits you best :)
> >
> > In test/compile-app-demo.js it adds the Qooxdoo library like this:
> > maker.addLibrary("../qooxdoo/framework", cb);
> >
> > Just change the path to point to your preferred location for
> > qooxdoo. To make this a bit clearer, I've just modified the
> > test/compile-app-demo.js to declare a variable QOOXDOO_PATH
> >
> > I expect that the command line version will imply have a search
> > path for libraries and just auto-discover by searching for
> > Manifest.json files.
> >
> > Re: missing testdata/qxt: something went wrong with your checkout,
> > that directory is definitely there.
> >
> > Re: build (and source-hybrid) targets: to control output for
> > Source vs Build vs Source-Hybrid, the API classes
> > qxcompiler.targets.SourceTarget, qxcompiler.targets.BuildTarget,
> > and qxcompiler.targets.SourceHybridTarget are used; test/compile-
> > app-demo.js uses the SourceTarget but you should be able to switch
> > it easily enough. I say "should" because I realise now that I
> > havn't tested them for a few weeks now and I should give them the
> > once over ASAP :) I've got to go out shortly so I'll take a look
> > this evening.
> >
> > John
> >
> >
> > From: "Dimitri" <mi...@cargosoft.ru>
> > Sent: Sunday, February 14, 2016 2:27 AM
> > To: "qooxdoo Development" <qooxdoo-devel@lists.sourceforge.net>
> > Subject: Re: [qooxdoo-devel] QxCompiler - add ES6, faster
> > compilation, and 100% Javascript API to building applications
> >
> > John, congratulations with the long awaited release! :) qooxdoo
> > guys, do you think that project like this could at some moment
> > land in qooxdoo and get official support? What about qooxdoo
> > patches (mostly strict mode compatibility related, AFAIK) - could
> > they be merged upstream? This would reduce maintainship costs for
> > those who want to experiment with both QxCompiler and official
> > toolchain. I didn't yet try QxCompiler with my project - I feel I
> > yet lack some understanding of how it works. However, I tried to
> > test it with the skeleton app. Off the top of my head: - one needs
> > to do "npm install" first and to run test scripts with "node
> > .js". This might be quite obvious for those experienced
> > with Node, but I guess the docs will nevertheless benefit from
> > mentioning this; - it's not easy to clone a repo unless you've set
> > up Github SSH access. This is because of "qooxdoo" submodule
> > pointing to "g...@github.com:john spackman/qooxdoo.git". Could it
> > be a HTTPS URL instead? - does QxCompiler honour QOOXDOO_PATH
> > setting? How do I define qooxdoo location if it is different from
> > the bundled one? - testdata/qxt directory doesn't contain skeleton
> > app. In order to play with test scripts, one needs to create the
> > app manually (as "skeleton.Application"?) and copy it to the said
> > location; - does lib/compiler.jar really belong there? Most
> > importantly, I was unable to find clear instructions how to
> > produce a single-script minified build (a-la "generate.py build").
> > By deafult, QxCompiler produces a bunch of JS files, which
> > significantly slows down loading and, obviously, is not acceptable
> > for production. Is it possible at all with the current version
> > (maybe in combination with classic generator)? I hope these are
> > just minor issues. After all, you've done a great job :) I wish
> > you good luck and further progress wih QxCompiler. 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 > qooxdoo-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel---------
> > -------------------------------------------------------------------
> > -- Site24x7 APM Insight: Get Deep Visibility into Application
> > Performance APM + Mobile APM + RUM: Monitor 3 App instances at
> > just $35/Month Monitor end-to-end web transactions and take
> > corrective actions now Troubleshoot faster and improve end-user
> > experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > _______________________________________________ qooxdoo-devel
> > mailing list qooxdoo-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> > -------------------------------------------------------------------
> > -----------
> > Site24x7 APM Insight: Get Deep Visibility into Application
> > Performance APM + Mobile APM + RUM: Monitor 3 App instances at
> > just $35/Month Monitor end-to-end web transactions and take
> > corrective actions now Troubleshoot faster and improve end-user
> > experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > _______________________________________________
> > qooxdoo-devel mailing list
> > qooxdoo-devel@lists.sourceforge.nethttps
> > ://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> ---------------------------------------------------------------------
> --------- Site24x7 APM Insight: Get Deep Visibility into Application
> Performance APM + Mobile APM + RUM: Monitor 3 App instances at just
> $35/Month Monitor end-to-end web transactions and take corrective
> actions now Troubleshoot faster and improve end-user experience.
> Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/
> 4140_______________________________________________ qooxdoo-devel
> mailing list qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> ---------------------------------------------------------------------
> ---------
> Site24x7 APM Insight: Get Deep Visibility into Application
> Performance APM + Mobile APM + RUM: Monitor 3 App instances at just
> $35/Month Monitor end-to-end web transactions and take corrective
> actions now Troubleshoot faster and improve end-user experience.
> Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
