Following instructions on http://docs.ckeditor.com/#!/guide/dev_build I clone the repo from https://github.com/ckeditor/ckeditor-dev and run build.sh in dev/builder.
It clones the ckbuilder repo and then crashes:
Starting CKBuilder...
Exception in thread "main" org.mozilla.javascript.EvaluatorException:
Function importClass must be called with a class; had
"[JavaPackage com.google.javascript.jscomp.CompilationLevel]"
instead. (c:\ckbuilder\src/lib/javascript.js#12)
I'm running on OS X with Java 1.6.0_65. I get the same error on a linux machine running basically the same version.
I was having the same issue. I downloaded the latest version of Java and that handled it for me. Here is JDK 8, the current latest:
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
Related
I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!
I've been unable to query my existing contract recently due to Unable to create Enum via index 128, in Alive, Tombstone when using api.query.contracts.contractInfoOf. I get this error both on the command line and in the polkadot-js apps explorer.
These are the steps I took:
Deploy a contract with a salt
Retrieve the contract deployedAddress
Use contractInfoOf
const contractInfo = await api.query.contracts.contractInfoOf(deployedAddress);
I've tried downgrading ink! to 3.0-rc5, 3.0-rc4, 3.0-rc3 and then compiling but it doesn't seem to make any difference. Whenever my contract is built it references rc6 at the top:
{"metadataVersion":"0.1.0","source":{"hash":"0x...","language":"ink! 3.0.0-rc6","compiler":"rustc 1.58.0-nightly",
Which suggests its ignoring my .toml and using rc6 to compile the contract.
I changed my cargo-contract version to 0.14 but that causes polkadot-js to fail at reading the contract abi.
I've tried using the substrate-contracts-node using the latest commit from master and also using the v0.1.0 release. Same error in both cases.
> rustup info
stable-x86_64-unknown-linux-gnu (default)
rustc 1.56.1 (59eed8a2a 2021-11-01)
There are more details in an issue on polkadot-js.
Any pointers on how to get a working setup would be very helpful!
The problem here was substrate-contracts-node using an old version of the metadata.
I was able to check out the repo before the metadata merge was reverted and build locally (cargo build).
So checkout 8d91b8e to get the node to work with versions 7.7.1 and 6.6.1 of polkadot-js packages.
> git checkout 8d91b8e578065a7c06433cbd41ac059bf478a0bd
> cargo build
> ./target/debug/substrate-contracts-node --dev --tmp --version
substrate-contracts-node 0.1.0-8d91b8e-x86_64-linux-gnu
My project path: c:\dev_latest
Java-version: JDK7 update 21 (I cannot use any other version due to project limitation)
Build Tools: Ant, Gradle
IDE: IntelliJ 17.3,
OS: Windows 10.
tried but not worked for me links:
1) CreateProcess error=206, The filename or extension is too long when running main() method
2) Createprocess error=206; the filename or extension is too long
3) https://coderwall.com/p/795oma/eclipse-junit-createprocess-error-206-filename-or-extension-is-too-long
4) How to set a long Java classpath in Windows?
I am sick of getting this exception :
Caused by: java.io.IOException: Cannot run program "C:\Java\jdk1.7.0_21\jre\bin\java.exe": CreateProcess error=206, The filename or extension is too long
at org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:428)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:442)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1257)
A week before my code was running just fine. Now I am stuck.
None of the previous answers on the forum resolved my issue.
My colleagues are on same environment but they are not experiencing the same issue.
Thanks in advance.
Just change the launch configuration to avoid using the default shorten line.
see this image for more info.
This will worked for me.
This is very similar to CreateProcess error=206 The filename or extension is too long, and the issue is related (even though it is a different version of IntelliJ, and what you are doing is different).
The problem exists in the IntelliJ workspace, and so you must manually add dynamic.classpath in order for it to work as you expect -- this is in addition to "shorten classpath" setting in the run configuration.
I would not say this is a duplicate question, but it's 90% the same (as it's the same underlying fault causing the issue).
I have built a Cordova-based Windows application. As soon as I add any plugin, the app starts crashing with the exception cordova/windows8/commandProxy not found.
Cordova version: 4.3.0
It seems that cordova/windows8/commandProxy is deprecated in Cordova 4.3.0.
I have replaced this statement in plugin file
require("cordova/windows8/commandProxy")
to
require("cordova/exec/proxy")
and it seems to work.
For example I changed line number 18 in PushPluginProxy.js from
require("cordova/windows8/commandProxy").add("PushPlugin", module.exports);
to
require("cordova/exec/proxy").add("PushPlugin", module.exports);
The name in the string varies depending on the plugin.
Alternatively, you can patch the plugin like in this pull request from the AppVersion plugin i.e.:
Change
require("cordova/windows8/commandProxy").add("AppVersion", AppVersionProxy);
to
cordova.commandProxy.add("AppVersion", AppVersionProxy);
I'm unable to use PAM plugin on SonarQube 5.1 on Debian 8 (64bit).
I did setup according to https://github.com/SonarCommunity/sonar-pam and still getting following error during login:
Java::JavaLang::UnsatisfiedLinkError (no jpam in java.library.path):
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
java.lang.Runtime.loadLibrary0(Runtime.java:849)
java.lang.System.loadLibrary(System.java:1088)
net.sf.jpam.Pam.<clinit>(Pam.java:51)
org.sonar.plugins.pam.PamConfiguration.newInstance(PamConfiguration.java:61)
org.sonar.plugins.pam.PamConfiguration.getPAM(PamConfiguration.java:49)
org.sonar.plugins.pam.PamAuthenticator.authenticate(PamAuthenticator.java:45)
org.sonar.api.security.SecurityRealm$1.doAuthenticate(SecurityRealm.java:60)
Here's setup (sonar is located at /var/lib/sonarqube-5.1):
/var/lib/sonarqube-5.1/lib/JPam-1.1.jar
native libs (64bit and 32bit) have been put to /var/lib/sonarqube-5.1/bin/linux-x86-64/lib/libjpam.so and /var/lib/sonarqube-5.1/bin/linux-x86-32/lib/libjpam.so (just for sure in case sonar was run as 32bit)
All directories leading to native libraries and libraries themselves have +rx access
Any idea what can be causing problem?
I'd print the java.library.path variable. The only thing I can think of is that the jpam lib is in the wrong place or there is an issue with permissions. (Did you check the SonarQube user can actually read that file?)
UPDATE
Check java.library.path in Settings->System Info page
Move jpam lib to one of those paths