let me try
Short example about my first problem:
qx.Interface.define("test.IItem",
{
members :
{
method : function() {}
}
}
qx.Class.define("test.AbstractItem",
{
extend : qx.core.Object,
type : "abstract",
members :
{
method : function() {
console.log("AbstractItem");
}
}
}
qx.Class.define("test.Item",
{
extend : test.AbstractItem,
implement : [test.IItem],
members :
{
method : function() {
this.base(arguments);
console.log("Item");
}
}
}In class qx.Interface we have method __checkMembers with code:
object[key] = this.__wrapInterfaceMember(
iface, object[key], key, members[key]
);__wrapInterfaceMember : qx.core.Environment.select("qx.debug",
{
"true": function(iface, origFunction, functionName, preCondition)
{
function wrappedFunction()
{
// call precondition
preCondition.apply(this, arguments);
// call original function
return origFunction.apply(this, arguments);
}
origFunction.wrapper = wrappedFunction;
return wrappedFunction;
},
"default" : function(iface, origFunction, functionName, preCondition) {}
}),So, our test.Item.prototype.method is going to be replaced with wrapper and this wrapper doesn't have base property.
I think we can add here:
wrappedFunction.base = origFunction.base;
cause test.Item.prototype.method is a wrapper
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.
@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.
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.
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)
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 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.
@/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.
@derrel: After rebuilding api viewer your searched property is there: https://qooxdoo.org/qxl.apiviewer/#qx.ui.form.AbstractField
And a big shout-out to @johnspackman and @hkollmann who have made a self-hosted compiler possible!
I am using the following
compile.js with my qooxdoo projectqx.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.
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.
This bug should be fixed with qooxdoo/qooxdoo-compiler#752 (once the PR gets merged). Thanks for reporting.
@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?
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.
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.