When trying to generate our application with the variant "qx.debug" set to "on" in the config.json I get a lot of errors like this:
Error: Variantoptimizer: No default case found for (qx.debug:off) at (qx.core.Property:1004)
I could fix those by adding the "default" cases, but I was wondering, if I was doing something wrong in the first place or if this these are actual issues in the qooxdoo SDK.
For one thing, qx.debug is set to "on" in the source version by default, so you don't have to do anything for that.
For the build version, you need to configure this in your config.json, e.g. in the "jobs" section add
"build" : {
"variants" : {
"=qx.debug" : [ "on" ]
}
}
Is this what your config looks like? The error message you gave is weird, which qooxdoo version are you using? You shouldn't need to provide any "default" cases for this variant in the framework code.
Related
I am using VS code together with the C/C++ and CMake extensions to develop a C project that is built with CMake. I have added a custom target to my CMakeLists.txt file that runs doxygen. I would like to see warnings from doxygen in the problems view of VS code. However they are not parsed, because doxygen doesn't include the column in its output. It prints something like this:
/path/to/file.c:4: warning: Found unknown command '#xyz'
While VS code only parses something like this:
/path/to/file.c:4:2: warning: Found unknown command '#xyz'
Doxygen cannot print the column. My only option there would be to add a dummy column. Is there a way to change VS code's behavior?
You wrote, correctly:
doxygen doesn't include the column in its output
I'm not sure about what you meant with / where to do this:
My only option there would be to add a dummy column
but indeed in doxygen you can accomplish this by changing the WARN_FORMAT setting to e.g.:
WARN_FORMAT="$file:$line:1: $text"
If you run doxygen as a task defined in tasks.json, you should be able to define your own custom problem matcher (put this in the "problemMatcher" field of a task in tasks.json. This is adapted from the example shown in VS Code's help page on tasks, in the section on defining a problem matcher):
{
// The problem is owned by the cpp language service.
"owner": "cpp",
// The file name for reported problems is relative to the opened folder.
"fileLocation": ["relative", "${workspaceFolder}"], // or just "absolute" if it's an absolute path
// The actual pattern to match problems in the output.
"pattern": {
// The regular expression. Example to match: helloWorld.c:5:3: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
// The first match group matches the file name which is relative.
"file": 1,
// The second match group matches the line on which the problem occurred.
"line": 2,
// No match group matches the column at which the problem occurred.
// "column": // not applicable
// The third match group matches the problem's severity. Can be ignored. Then all problems are captured as errors.
"severity": 3,
// The fourth match group matches the message.
"message": 4
}
}
Otherwise, if this is behaviour you're getting from an extension you have installed, you should go talk to the maintainer of that extension.
I'm using this babel plugin https://github.com/gilbsgilbs/babel-plugin-i18next-extract. Haven't configured it much beyond the basics.
it generates an extractedTranslations folder but I just end up with keys and no values. Is that the correct behavior? I would figure that it would reconcile the values from the translations files that i already have.. I'm kind of confused on how this is useful?
Creator of the plugin here. By default, babel-plugin-i18next-extract indeed extracts the keys to extractedTranslations/{{locale}}/{{ns}}.json. If you want to change this, you must set the outputPath configuration option to something else. For instance:
{
"plugins": [
[
"i18next-extract",
{
"outputPath": "locales/{{locale}}/{{ns}}.json"
}
]
]
}
If the outputPath you set already exists for a given locale and namespace, the plugin should only add new keys and leave the values of existing keys untouched.
You may want to look at the other configuration options to make the plugin match to your workflow.
when i tired to remove an index, I typed wrong GLOBAL_OFFLINE setting in userConfig in the ManagementSystem, which I mistake typed the "index.search.backend" with a directory string ......
when i try to open this janusgraph, the print out as below :
WARN org.janusgraph.graphdb.configuration.GraphDatabaseConfiguration
Local setting index.search.backend=lucene (Type: GLOBAL_OFFLINE) is overridden by globally managed value (/data/lucene). Use the ManagementSystem interface instead of the local configuration to control this setting.
INFO org.janusgraph.diskstorage.Backend - Configuring index [search]
Could not find implementation class: /data/lucene
I wonder whether i could not drop this table at the backend and fix this problem !
many thx !
I think i have fix this problem !
I just use the KCVS backend , and find out the source code of GraphDatabaseConfiguration ;
I tried and get the KCVSConfig use the code following :
PropertiesConfiguration configuration = new PropertiesConfiguration(GRAPH_PROPERTIES);
ReadConfiguration localConfig = new CommonsConfiguration(configuration);
BasicConfiguration localBasicConfiguration = new BasicConfiguration(ROOT_NS,localConfig, BasicConfiguration.Restriction.NONE);
KeyColumnValueStoreManager storeManager = Backend.getStorageManager(localBasicConfiguration);
KCVSConfiguration KCVSConfig =Backend.getStandaloneGlobalConfiguration(storeManager,localBasicConfiguration);
Just using the KCVSConfiguration to remove all the index configuration !
I am using Sencha Grid Exporter plugin, while it works perfectly fine when exported to Excel, I cant get it to export to CSV or any other types from my app.
It works fine as listed on the KitchenSink example.
KitchenSink Exporter Example
http://docs.sencha.com/extjs/6.2.1/classic/Ext.grid.plugin.Exporter.html
Ext.getCmp('grid').saveDocumentAs({
type: 'csv', // What other possible values can go here
title: globals.reportName,
fileName: 'myExport.csv'
});
Comes with an error as below:
Uncaught Error: [Ext.createByAlias] Unrecognized alias: exporter.CSV
at Ext.Inventory.instantiateByAlias (app.js?_dc=1481916938387:13520)
at Ext.Factory.create (app.js?_dc=1481916938387:23199)
at constructor.getExporter (app.js?_dc=1481916938387:204593)
at constructor.saveDocumentAs (app.js?_dc=1481916938387:204520)
at constructor.saveDocumentAs (app.js?_dc=1481916938387:5355)
at constructor.onMenuitemClick (app.js?_dc=1481916938387:255332)
at constructor.fire (app.js?_dc=1481916938387:19281)
at constructor.doFireEvent (app.js?_dc=1481916938387:20248)
at constructor.doFireEvent (app.js?_dc=1481916938387:65488)
at constructor.prototype.doFireEvent (app.js?_dc=1481916938387:56438)
You are missing a requires.
If you tell ExtJS to use type:'csv', it will try to instantiate exporter.csv. If you tell ExtJS to use type:'excel', it will try to instantiate exporter.excel. To get that one from the file system, you have to include the fully qualified name somewhere, e.g. in your requires section:
requires:[
'Ext.exporter.text.CSV'
]
The heading in the docs has two parts: First the full qualified class name, which is "Ext.exporter.text.CSV", and then, the short name ("exporter.csv"). If you haven't provided the full name anywhere, the file cannot be loaded, unless the framework itself already requires the exporter by full name. Which it, according to the error message, doesn't.
Background info, before you ask "Why doesn't it?": Since the plugin can work with any of the dozens of exporters, and you wouldn't want to load all just to create one type of export, you have to import the exporter manually.
I have the following values in my hiera yaml file:
test::config_php::php_modules :
-'soap'
-'mcrypt'
-'pdo'
-'mbstring'
-'php-process'
-'pecl-memcache'
-'devel'
-'php-gd'
-'pear'
-'mysql'
-'xml'
and following is my test class:
class test::config_php (
$php_version,
$php_modules = hiera_hash('php_modules', {}),
$module_name,
){
class { 'php':
version => $php_version,
}
$php_modules.each |String $php_module| {
php::module { $php_module: }
}
}
While running my puppet manifests I get the following error:
Error: Evaluation Error: Error while evaluating a Function Call, create_resources(): second argument must be a hash at /tmp/vagrant-puppet/modules-f38a037289f9864906c44863800dbacf/ssh/manifests/init.pp:46:3 on node testdays-1a.vagrant.loc.vag
I am quite confused on what exactly am I doing wrong. My puppet version is 3.6.2 and I also have parser = future
I would really appreciate any help here.
Looks like your YAML was slightly off.
You don't really need quotes in YAML.
Your indentation was two instead of one.
Your first colon on the first time was spaced. This will throw a syntax error.
it should look more like this:
test::config_php::php_modules:
- soap
- mcrypt
- pdo
- mbstring
- php-process
- pecl-memcache
- devel
- php-gd
- pear
- mysql
- xml
In the future try and look up YAML parsers like this: link
The problem was with my puppet version, somehow version 3.6 acts weird while creating resources, for instance it was failing on the following line,:
create_resources('::ssh::client::config::user', $fin_users_client_options)
The code snippet above is part of ssh module from puppet labs, which I assume is throughly tested and shouldn't be a reason for the an exception.
A further analysis led to the fact that the exception was thrown when the parameter parser = future was set in the config file
I cannot iterate using each without setting future as the parser, therefore I decided to change my source as follow:
I created a new class:
define test::install_modules {
php::module { $name: }
}
and then I changed the config config_php to:
class test::config_php (
$php_version,
$php_modules = [],
){
class { 'php':
version => $php_version,
}
install_modules { $php_modules: }
}
Everything seems to be much better now.