by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 18 20:58
    lucapivato commented #10037
  • Sep 18 07:24
    oetiker labeled #10037
  • Sep 18 07:24
    oetiker commented #10037
  • Sep 18 07:22
    oetiker edited #10037
  • Sep 16 16:15
    lucapivato labeled #10037
  • Sep 16 16:15
    lucapivato opened #10037
  • Sep 11 08:35

    github-actions[bot] on gh-pages

    deploy: 514690aa24bb25ae0295c8d… (compare)

  • Sep 11 08:33

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 11 08:33

    hkollmann on master

    Bump node-fetch from 2.6.0 to 2… (compare)

  • Sep 11 08:33
    hkollmann closed #759
  • Sep 10 23:19
    gasoved starred qooxdoo/qooxdoo
  • Sep 10 20:11
    dependabot[bot] labeled #759
  • Sep 10 20:11
    dependabot[bot] review_requested #759
  • Sep 10 20:11
    dependabot[bot] review_requested #759
  • Sep 10 20:11
    dependabot[bot] review_requested #759
  • Sep 10 20:11
    dependabot[bot] opened #759
  • Sep 10 20:11

    dependabot[bot] on npm_and_yarn

    Bump node-fetch from 2.6.0 to 2… (compare)

  • Sep 07 13:04
    cboulanger assigned #10036
  • Sep 07 13:04
    cboulanger opened #10036
  • Sep 07 12:36
    zaucker edited #10035
Oleg Philippov
@ofilippov
But in any case test.Item.prototype.method.base is undefined here
cause test.Item.prototype.method is a wrapper
Derrell Lipman
@derrell
But aren't you saying that the wrapper has been broken for 15 years and it's never come up before? Certainly possible, but seems there's something else going on that's missing...???
Oleg Philippov
@ofilippov
well, it works fine in qooxdoo 5.0.2 at least :) but I'm not sure that this.base(arguments) was compiled to test.Item.prototype.method.base() before
Derrell Lipman
@derrell
What is the set of circumstances in which this problem would occur? Not likely whenever an interface is used, but that seems a requirement to cause this. What are the other requirements to cause it?
Ah, a possible change. Yes that's a potential cause. But still, interfaces are used throughout the core code, so what else is required to cause this?
@johnspackman Is this.base(arguments) implemented differently with the compiler than it was with the generator?
@ofilippov are you able to try a small test with 6.0 qooxdoo code but compiled with the generator instead of the compiler? The generator is deprecated but still included with 6.0.
I'm just really concerned about a change as invasive as something in the wrapper functions.
Oleg Philippov
@ofilippov
as far as I see, in qx 5.x function base from qx.core.Object is used in debug
Derrell Lipman
@derrell
@ofilippov Let's see what @johnspackman says. He's the expert in that area.
John Spackman
@johnspackman
@ofilippov @derrell the change between generator and compiler is that the generator would rely on the method base in the code - so this uses the Javascript runtime to figure out what that should be. However, the compiler has to predict what the method would be, and replaces this.base(arguments, …) with an explicit call, eg test.AbstractItem.method.call(this, …). So, the upshot is that it is possible that the compiler has not properly figured out the correct method to explicitly call. Please can you create an issue with a reproducable test case and I will have a look. BTW the reason that the compiler must figure it out is because the compiler transpiled to ES6 which requires strict mode - and in strict mode, it is illegal to use arguments to figure out the function being called, and therefore the default implementation of base in qx.Object cannot and will not execute. The fix is to edit the code to transpile this.base() as the explicit function call.
Derrell Lipman
@derrell
Thanks @johnspackman
tobscada
@tobscada
Hi
I'm try to use "qx create helloworld -type mobile -I " command to create new mobile app but it messaged error to me like ' unknow argument : y, p, e' how could i would do?
Until now I still not touching the new Qooxdoo Mobile App features with no use of Python command.
tobscada
@tobscada
Please be suggested me.
Henner Kollmann
@hkollmann
you have to use --type or just -t
Derrell Lipman
@derrell
G'morning, all. See my comment on qooxdoo/qooxdoo#9979. A property added to AbstractForm in May is not showing up in the API viewer for some reason. Pulling master, it does appear that the code is there. I don't see anything inherently wrong with the property definition. I suspect some problem with the API viewer...
(or regeneration of API docs)
Derrell Lipman
@derrell
Huh... It's in master, but not in the version of qooxdoo that comes with the compiler... but the compiler npm version is really old! npm install @qooxdoo/compiler; npx qx --version yields 1.0.0-beta.20200613-2032... unless there's a more propery way to upgrade the compiler and its dependencies?
Has nothing to do with upgrade. I removed node_modules and reinstalled it, and end up with the same ancient version...
Derrell Lipman
@derrell
@hkollmann Maybe this is related to the dependency work you're actively involved in?
Christian Boulanger
@cboulanger
@derrell We're remodelling the deployment system (see https://github.com/qooxdoo/deployment), which required some time-intensive architectural groundwork. As we speak, @hkollmann is working on re-enabling NPM deployment. We just need @johnspackman to have a final look.
Derrell Lipman
@derrell
That's what I hoped and expected. Thanks, @cboulanger . I'll wait on those changes for now.
Christian Boulanger
@cboulanger
@/all :bell: Thank you for your patience during the redesign of the NPM publication process. We will soon resume releasing new packages of the compiler, the framework and the server component of qooxdoo. Because of its beta status, you should always upgrade to the newest NPM version with caution, but since this will be the first release based on a new workflow and a new "self-hosted" compiler (i.e. the compiler code is compiled using itself), some initial hiccups might occur that we will try to fix immediately. If you find that something is broken, please create an issue. You can always revert to a previous release by executing npm install @qooxdoo/compiler@1.0.0-beta.20200613-2032. We'll post another message once the new packages are out.
Henner Kollmann
@hkollmann
@derrel: After rebuilding api viewer your searched property is there: https://qooxdoo.org/qxl.apiviewer/#qx.ui.form.AbstractField
Derrell Lipman
@derrell
Great!
Christian Boulanger
@cboulanger
That is to say: @qooxdoo/compiler v1.0.0-beta-20200803-1413 is out, containing all the improvements of the current master branch. Try it and let us know if it works for you!
And a big shout-out to @johnspackman and @hkollmann who have made a self-hosted compiler possible!
Tobias Oetiker
@oetiker
cool will test tonight
Christian Boulanger
@cboulanger
my app compiles without problems with the new compiler version!
Tobias Oetiker
@oetiker
I am using the following compile.js with my qooxdoo project
qx.Class.define("callbackery.compile.CompilerApi", {
    extend: qx.tool.cli.api.CompilerApi,
    members: {
        async load() {
            let config = await this.base(arguments);
            if (!config.libraries) {
                config.libraries = ['.'];
            }
            let cbr = process.env.CALLBACKERY_QX;
            if (cbr) {
                ["callbackery"].forEach(dir => {
                    config.libraries.push(cbr+"/"+dir);

                });
            }
            return config;
        }
    }
});


module.exports = {
    CompilerApi: callbackery.compile.CompilerApi
};
after upgrading to the current compiler, it fails horribly
any hint ?
(node:29916) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'libraries' of undefined
    at wrapper.callbackery.compile.CompilerApi.prototype.load() [as load] (/home/oetiker/checkouts/o2h/o2hsrv/frontend/compile.js:6:25)
    at async wrapper.qx.tool.cli.Cli.prototype.__parseArgsImpl() [as __parseArgsImpl] (/home/oetiker/checkouts/o2h/o2hsrv/frontend/node_modules/@qooxdoo/compiler/lib/compiler/index.js:40082:9)
    at async wrapper.qx.tool.cli.Cli.prototype.run() [as run] (/home/oetiker/checkouts/o2h/o2hsrv/frontend/node_modules/@qooxdoo/compiler/lib/compiler/index.js:40032:9)
    at async wrapper.qx.tool.cli.Application.prototype.main() [as main] (/home/oetiker/checkouts/o2h/o2hsrv/frontend/node_modules/@qooxdoo/compiler/lib/compiler/index.js:39517:9)
(node:29916) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:29916) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
rommni
@rommni
Hi all, thank you for the work on this update ;)
I'm currently on holiday and haven't access to my app however i will test it as soon as I come back ( 17 August).
Pat Buxton
@rad-pat
My App is compiling without error on the latest compiler. It told me that I needed to run qx package migrate, which I did and that updated my Manifest.json, changing the versions of @qooxdoo/compiler and @qooxdoo/framework, which is fine. It also updated compile.json, changing the "extends" member inside the "esLintConfig" from "@qooxdoo/qx/browser" to "@qooxdoo/@qooxdoo/qx/browser" which didn't seem right, so I changed it back.
Christian Boulanger
@cboulanger
This bug should be fixed with qooxdoo/qooxdoo-compiler#752 (once the PR gets merged). Thanks for reporting.
Derrell Lipman
@derrell

@johnspackman @hkollmann This question pertains to compiler dependency analysis and location. I have a project which has a top-level compile.json and Manifest. It uses some git submodules each stored in $TOP/library, so for example there is a $TOP/library/dialog.git directory there. The compile.json for this project lists each of the libraries (git submodules) in its "libraries" array, as something like "./library/dialog.git". It all works perfectly.

Now I have a new project that makes use of that first one, so that whole first project is in the new project's library directory, including its submodules. Should it be necessary for the new project's compile.json to list each of the first project's submodules as libraries? Or shouldn't those just be automatically included when I list the first project in the library key of the new project's compile.json? To rephrase, is it necessary for an application which makes use of qooxdoo libraries, to know about all of the used libraries' dependencies?

Yeshua Rodas
@yybalam_gitlab
I'm still using the python compiler :sweat_smile:
At the University we have 3 app where one is build over other, and all of them relies on two shared library, so the config.json files still is the easiest way to attach other qx apps via Manifest.json, and also other js scrips and css files, and getting a single build js file to deploy. So, I want to ask if already there is support at the new compiler for doing some similiar configuration like the "libraries" declaration at config.json for the python compiler.
Henner Kollmann
@hkollmann
@yybalam_gitlab : we have the package system for this
@derrell : Packages loads there dpendencies recursive. Together with the possibility to define local packages this should to the job.
packages do this by reading there qx-lock.json file.
Derrell Lipman
@derrell
@hkollmann It doesn't seem to do that. It wasn't finding dialog, for example, which was a dependency of the library I included in my new app.
Henner Kollmann
@hkollmann
That was the theory. Needs to be tested and debugged then
Christian Boulanger
@cboulanger
@yybalam_gitlab Have a look at https://qooxdoo.org/documentation/#/development/cli/packages. Packages contain one or more libraries (i.e bundles of code and resources organized with a Manifest.json). Packages need not be published - you can also use them locally.
Derrell Lipman
@derrell
We all know that the reason there is theory is because not all things can be facts :-)
Thanks. It's good to know at least that it's supposed to work as I expected