Develop Reference

Sikulix/Python: RuntimeError when trying to load .dll

As mentioned in the title im getting a RuntimeError when trying to load a .dll in a sikuli script using ctypes.
import ctypes
path = %path to dll file%
mydll = ctypes.CDLL(path)
The error shows as follows:
[error] script (Test_ctypes) stopped with error in line 6
[error] RuntimeError (path)
[error] ---Traceback--- error source first
line: module (function) statement
262: __init__ (__init__) RuntimeError: path
6: main (<module>) mydll = ctypes.CDLL(path)
[error] ---Traceback --- end ---------------
I've tried the very same code in an anaconda build i have in another pc, and works fine, i can even interact with the functions within the .dll.
My guess would be an installation issue of some sort. As i don't have total control of the pc im running the script in, i'd need to know exactly the cause of the error, if possible...
Thanks in advance.

compiling and running jars with scalac vs sbt?

I am trying to compile a fat jar for my Scala project that contains all of my dependencies according to this stackoverflow post, so that I can use it in a Java application. I am new to Scala/Java/JVM, so please be patient. I am using IntelliJ and scala 2.12.4, however I am running my sbt commands from the OS X Terminal.
To start, I am able to run sbt assembly and get a padsystem-assembly-0.0.1.jar in /target/scala-2.12/. (I had to make an assembly.sbt and modify my build.sbt with a "Merge Strategy" to get it to work.) However when I try to run this jar with scala
computer: dir user$ scala target/scala-2.12/padsystem-assembly-0.0.1.jar
scala target/scala-2.12/padsystem-assembly-0.0.1.jar
java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at scala.reflect.internal.util.ScalaClassLoader.$anonfun$tryClass$1(ScalaClassLoader.scala:45)
at scala.util.control.Exception$Catch.$anonfun$opt$1(Exception.scala:242)
at scala.util.control.Exception$Catch.apply(Exception.scala:224)
at scala.util.control.Exception$Catch.opt(Exception.scala:242)
at scala.reflect.internal.util.ScalaClassLoader.tryClass(ScalaClassLoader.scala:45)
at scala.reflect.internal.util.ScalaClassLoader.tryToInitializeClass(ScalaClassLoader.scala:41)
at scala.reflect.internal.util.ScalaClassLoader.tryToInitializeClass$(ScalaClassLoader.scala:41)
at scala.reflect.internal.util.ScalaClassLoader$URLClassLoader.tryToInitializeClass(ScalaClassLoader.scala:125)
at scala.reflect.internal.util.ScalaClassLoader.run(ScalaClassLoader.scala:92)
at scala.reflect.internal.util.ScalaClassLoader.run$(ScalaClassLoader.scala:91)
at scala.reflect.internal.util.ScalaClassLoader$URLClassLoader.run(ScalaClassLoader.scala:125)
at scala.tools.nsc.CommonRunner.run(ObjectRunner.scala:22)
at scala.tools.nsc.CommonRunner.run$(ObjectRunner.scala:21)
at scala.tools.nsc.JarRunner$.run(MainGenericRunner.scala:14)
at scala.tools.nsc.CommonRunner.runAndCatch(ObjectRunner.scala:29)
at scala.tools.nsc.CommonRunner.runAndCatch$(ObjectRunner.scala:28)
at scala.tools.nsc.JarRunner$.runAndCatch(MainGenericRunner.scala:14)
at scala.tools.nsc.JarRunner$.runJar(MainGenericRunner.scala:26)
at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:72)
at scala.tools.nsc.MainGenericRunner.run$1(MainGenericRunner.scala:85)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:96)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:101)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
And when I try to run it with java (which is my main goal):
computer: dir user$ java target/scala-2.12/padsystem-assembly-0.0.1.jar
Error: Could not find or load main class target.scala-2.12.padsystem-assembly-0.0.1.jar
Now, before you ask, "Are you sure your code is working?", I will note that I am able to sbt run my code successfully, and I can also sbt compile and sbt package it successfully as well.
Interestingly, if I try to sbt compile src/main/scala/OdinExtractor.scala from the base directory:
sbt compile src/main/scala/OdinExtractor.scala
[info] Loading settings from idea.sbt ...
[info] Loading global plugins from /Users/user/.sbt/1.0/plugins
[info] Loading project definition from /Users/user/PAD_IE/project/project
[info] Loading settings from assembly.sbt,plugins.sbt ...
[info] Loading project definition from /Users/user/PAD_IE/project
[info] Loading settings from build.sbt ...
[info] Set current project to padsystem (in build file:/Users/user/PAD_IE/)
[info] Executing in batch mode. For better performance use sbt's shell
[success] Total time: 4 s, completed Mar 16, 2018 3:35:49 PM
[error] Expected ID character
[error] Not a valid command: src (similar: set)
[error] Expected project ID
[error] Expected configuration
[error] Expected ':' (if selecting a configuration)
[error] Expected key
[error] Not a valid key: src (similar: sources, ps, run)
[error] src/main/scala/OdinExtractor.scala
[error] ^
OR if I try to scalac src/main/scala/OdinExtractor.scala or if I cd into the src/main/scala dir and try to run sbt compile OdinExtractor.scala I get:
[info] Loading settings from idea.sbt ...
[info] Loading global plugins from /Users/user/.sbt/1.0/plugins
[info] Updating ProjectRef(uri("file:/Users/user/.sbt/1.0/plugins/"), "global-plugins")...
[info] Done updating.
[info] Set current project to scala (in build file:/Users/user/PAD_IE/src/main/scala/)
[info] Executing in batch mode. For better performance use sbt's shell
[info] Compiling 1 Scala source to /Users/user/PAD_IE/src/main/scala/target/scala-2.12/classes ...
[error] /Users/user/PAD_IE/src/main/scala/OdinExtractor.scala:3:12: object clulab is not a member of package org
[error] import org.clulab.odin.Mention
[error] ^
[error] /Users/user/PAD_IE/src/main/scala/OdinExtractor.scala:4:12: object clulab is not a member of package org
[error] import org.clulab.processors.Document
[error] ^
[error] /Users/user/PAD_IE/src/main/scala/OdinExtractor.scala:5:12: object vinci is not a member of package org
[error] import org.vinci.pad.padsystem.PadSystem
[error] ^
[error] three errors found
[error] (Compile / compileIncremental) Compilation failed
[error] Total time: 1 s, completed Mar 16, 2018 3:38:06 PM
Why would I be able to sbt run my code successfully, but not be able to run the jar with scala or java, especially when all of the dependencies are included in the fat jar?
Why do I get errors with my depdencies when I do scalac src/main/scala/OdinExtractor.scala and sbt compile OdinExtractor.scala? The first I am guessing because scalac wants something like
scalac -cp "all:of:the:classpath:stuff:ever" OdinExtractor.scala.
(By the way, I can't figure out how to do this...)
Which, as I understand, is why we use sbt to begin with, yes? To avoid the messy classpath stuff. Which brings me to my next question: Why does sbt compile fail when I point it at the specific file? And why does it fail when I run it from the src/main/scala directory? I don't know about the first one, but my guess for the second question is that sbt must always be run from the base directory?
Back to the main goal: producing a fat jar that I can run with Java... Does anyone have any idea how I can debug this? I don't understand why the assembly jar fails, but the code still runs with sbt run. I originally thought the best way to debug this would be to just compile the object with def main(), and try to run it with both Scala and Java, but this has proven very troublesome.
In the end, I have an eerie feeling that perhaps all of this boils down to either 1) my confusion about classpaths, or 2) perhaps my project structure? But since my stuff runs with sbt run, I'm just at a total loss... Please help! Let me know if there's anything else I need to add to my post to make it more clear. Thanks!
Edit -
Per my build.sbt I did include the scala-library jar, so that it can be parsed by Java.
I.e. "org.scala-lang" % "scala-library" % "2.12.4"
Also, if its of any importance, my Object has a def main instead of extends App. Not sure if that matters...

The answer ended up being with the build.sbt. I found the answer in this stackoverflow post. I had to add
mainClass in assembly := Some("NameOfMyMainClass")
into the build.sbt.
After that, I did
sbt clean assembly
and was able to run both java -jar target/.../my-fat-jar.jar and scala target/.../my-fat-jar.jar.
Shoutout to #laughedelic for pointing out that I should use java -jar, and for answering my question about sbt compile src/... :')

Cannot get gomobile binding to work with java

Go version: 1.7.5
GOPATH = D:/GoWork
React Native version 0.41
Code below is the binding go package at D:\GoWork\src\rngo\rngo\rngo.go
Very simple, just returning a string
package rngo
// RNcall is used to bind with RN
func RNcall() string {
return "From Go platform"
}
Running the below command from > D:\GoWork\src\rngo
gomobile bind -target android -o rngo.aar -v .
Verbose Output below seems to be fine
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\classes.go
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\classes.h
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\classes.c
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gen\src\Java\interfaces.go
rngo/rngo
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\fakegopath\pkg\android_arm\rngo\rngo.a
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\go_rngomain.go
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\go_main.go
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\androidlib\main.go
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\android\src\main\java\rngo\Rngo.java
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\java_rngo.c
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\rngo.h
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\android\src\main\java\go\Universe.java
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\android\src\main\java\go\error.java
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\java_universe.c
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\universe.h
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\seq_android.go
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\seq_android.c
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\seq.h
write C:\Users\Minty\AppData\Local\Temp\gomobile-work-855641675\gomobile_bind\seq.go
Java
/C/Users/Minty/AppData/Local/Temp/gomobile-work-855641675/gomobile_bind command-line-arguments rngo/rngo Java
/C/Users/Minty/AppData/Local/Temp/gomobile-work-855641675/gomobile_bind command-line-arguments rngo/rngo Java
/C/Users/Minty/AppData/Local/Temp/gomobile-work-855641675/gomobile_bind command-line-arguments rngo/rngo Java
/C/Users/Minty/AppData/Local/Temp/gomobile-work-855641675/gomobile_bind
/# /C/Users/Minty/AppData/Local/Temp/gomobile-work-855641675/gomobile_bind
D:\Android\sdk\ndk-bundle\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld:
warning: skipping incompatible
D:\Android\sdk\ndk-bundle\platforms\android-21\arch-x86_64/usr/lib/liblog.so
while searching for log
D:\Android\sdk\ndk-bundle\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld:
warning: skipping incompatible
D:\Android\sdk\ndk-bundle\platforms\android-21\arch-x86_64/usr/lib/libdl.so
while searching for dl
D:\Android\sdk\ndk-bundle\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld:
warning: skipping incompatible
D:\Android\sdk\ndk-bundle\platforms\android-21\arch-x86_64/usr/lib/libc.so
while searching for c
D:\Android\sdk\ndk-bundle\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld:
warning: skipping incompatible
D:\Android\sdk\ndk-bundle\platforms\android-21\arch-x86_64/usr/lib/libdl.so
while searching for dl
command-line-arguments
aar: AndroidManifest.xml
aar: proguard.txt
aar: classes.jar
jar: META-INF/MANIFEST.MF
jar: go/LoadJNI.class
jar: go/Seq$GoObject.class
jar: go/Seq$Proxy.class
jar: go/Seq$Ref.class
jar: go/Seq$RefMap.class
jar: go/Seq$RefTracker.class
jar: go/Seq.class jar: go/Universe$proxyerror.class jar:
go/Universe.class
jar: go/error.class
jar: rngo/Rngo.class
aar: jni/armeabi-v7a/libgojni.so
aar: jni/arm64-v8a/libgojni.so
aar: jni/x86/libgojni.so
aar: jni/x86_64/libgojni.so
aar: R.txt
aar: res/
Successfully created rngo.aar since there is no error message and I can see that file at D:\GoWork\src\rngo\rngo.aar
I then manually import rngo.aar file into React Native project from android studio
File > New > New Module > Import .aar/.jar Package > #give the path
to rngo.aar#
File > Project Structure > app > Dependencies >
Module dependency > rngo.aar
Inside IDE, in MainActivity.java I can successfully do 'import go.rngo.*;', but I cannot get 'go.rngo.Rngo.RNcall()' or 'go.rngo.Rngo;' to work
Building this android app throws error 'cannot find symbol'
D:\RN\gomobile\android\app\src\main\java\com\gomobile\RngoModule.java:10:
error: cannot find symbol
import go.rngo;
^
symbol: class rngo
location: package go
1 error
:app:compileDebugJavaWithJavac FAILED
Conclusion
I am doing something horribly wrong, that I cannot get this simple thing to work. I wasted whole day on google but with no avail. Hence I need help getting this to work. All I need is a simple go code with that connects to react native hasselfree.
Thanks for reading all this. I appreciate it.

Thanks to eliasnaur. Finally, I got this working. As of go 1.7.* you dont have access to go package. Instead access your package directly like this
Before:
import go.rngo.Rngo;
After:(Since 1.7.*)
import rngo.Rngo;

Smart can't install...no package provides shared object file

Problem
I'm attempting to create a Bitbake recipe which will install Oracle JRE 8 onto my target OS.
I've tried to use metadata from meta-oracle-java, but had some difficulties due to one of the .inc files which are provided for general JREs has a JRE-7-specific URI.
I've changed some of the metadata from meta-oracle-java and created my own recipe to do this install.
Tests
A Build of the JRE Recipe by Itself
When building the recipe by itself:
bitbake oracle-jse-jre
The build completes without error. I've added a dependency on libav into the oracle-jse-jre recipe, so I can do the following from TMPDIR:
$ find . -name libavformat*so
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so.54.20.4
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so.54
./sysroots/genericx86-64/usr/lib/libavformat.so.54.20.4
./sysroots/genericx86-64/usr/lib/libavformat.so
./sysroots/genericx86-64/usr/lib/libavformat.so.54
Runtime Dependency Success
If I add the default package from the oracle-jse-jre recipe to RDEPENDS_${PN} of another recipe xenoros_0.1.bb, I can run bitbake xenoros and build without errors.
Core Image Failure
If I add xenoros to the IMAGE_INSTALL variable of a core-image-xenoros, the build fails with the following error:
ERROR: Unable to install packages. Command '/home/presslertj/yocto-OS/poky-jethro-build/build/tmp/sysroots/x86_64-linux/usr/bin/smart --log-level=warning --data-dir=/home/presslertj/yocto-OS/poky-jethro-build/build/tmp/work/genericx86_64-poky-linux/core-image-my-server/1.0-r0/rootfs/var/lib/smart install -y message-generation#core2_64 catkin#core2_64 python-distutils#core2_64 ldd#core2_64 xenoros#core2_64 rosgraph#core2_64 gedit#core2_64 actionlib#core2_64 python-compression#core2_64 dhcp-server#core2_64 libpthread-stubs#core2_64 tf2#core2_64 python-email#core2_64 catkin-dev#core2_64 git#core2_64 rosbash#core2_64 python-json#core2_64 python-wstool#core2_64 connman#core2_64 ros-config#core2_64 packagegroup-core-boot#genericx86_64 libsdl-1.2-0#core2_64 rosjava#core2_64 quagga#core2_64 nginx#core2_64 rospy#core2_64 apt#core2_64 libc6#core2_64 netcat#core2_64 shadow#core2_64 bash#core2_64 roscpp#core2_64 roslaunch#core2_64 run-postinsts#all python-rosinstall#core2_64 elfutils#core2_64 openssl#core2_64 font-alias#all gradle#core2_64 python-catkin-pkg#core2_64 catkin-runtime#core2_64 catkin-runtime-dev#core2_64 pciutils#core2_64 base-passwd#core2_64' returned 1:
Loading cache...
Updating cache... ######################################## [100%]
Computing transaction...error: Can't install oracle-jse-jre-1.8.0-u77r0#core2_64: no package provides libavformat.so.53(LIBAVFORMAT_53)(64bit)
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/presslertj/yocto-OS/poky-jethro-build/build/tmip/work/genericx86_64-poky-linux/core-image-my-server/1.0-r0/temp/log.do_rootfs.22073
ERROR: Task 7 (/home/presslertj/yocto-OS/poky-jethro-build/meta-myLayer/recipes-core/images/core-image-my-server.bb, do_rootfs) failed with exit code '1'
Looking inside TMPDIR, I can find this:
/sysroots/genericx86-64/usr/lib/libavformat.so.54
It seems there's a version mismatch, where smart expects version 53, but 54 is provided.
Reverting libav's version
Just to test what's going on, I've made a recipe which fetches version 0.8.17 of libav (which uses version 53). When using this instead of 9.18, I have the exact opposite problem, that smart expects but can't find version 54.
Questions
How does smart determine the version number for these shared object files?
What about the do_rootfs() task causes the build to fail at this specific time?
Is there a simple resolution to my specific problem?

1) It's not smart, but rather rpmbuild, that is adding dependencies derived from the ELF DT_NEEDED field (see elfutils -a).
2) The do_rootfs() task is failing because of unresolved dependencies.
3) Since you are using Poky/Yocto and rpm5, there is a simple way to mask the issue (substituting whatever dependencies are causing you heartburn)
echo "unresoved_dependency" > /etc/rpm/sysinfo/Providename
That is just a band-aid; you still need to figure out the packaging issues rather than masking the underlying problem with how you are building rpm packages.

For anyone that still encounter this error: as stated in the README file of the meta-oracle-java repo
There are some known install problems for JRE packages due to dependencies reported by RPM package manager.
Switching to DEB or IPK packaging temporarily fixes this.
ie:
PACKAGE_CLASSES = "package_deb"
or
PACKAGE_CLASSES = "package_ipk"
in your 'local.conf' file

warning when i am generating .jar

I have this warning:
warning: Supported source version 'RELEASE_6' from annotation processor
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor' less than -source
'1.7'
Note: Creating non-static metadata factory ...
Note: Found Option : eclipselink.canonicalmodel.use_static_factory, with value: false
Note: Optional file was not found: META-INF/orm.xml continuing with generation.
Note: Optional file was not found: META-INF/eclipselink-orm.xml continuing with
generation.
Note: Found Option : eclipselink.canonicalmodel.use_static_factory, with value: false
Note: Optional file was not found: META-INF/orm.xml continuing with generation.
Note: Optional file was not found: META-INF/eclipselink-orm.xml continuing with
generation.
warning: The following options were not recognized by any processor:
'[eclipselink.canonicalmodel.use_static_factory]'
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
Copying 5 files to E:\NetBeansProjects\votaciones\build\classes
compile:
Created dir: E:\NetBeansProjects\votaciones\dist
Copying 1 file to E:\NetBeansProjects\votaciones\build
Copy libraries to E:\NetBeansProjects\votaciones\dist\lib.
Building jar: E:\NetBeansProjects\votaciones\dist\votaciones.jar
To run this application from the command line without Ant, try:
java -jar "E:\NetBeansProjects\votaciones\dist\votaciones.jar"
jar:
BUILD SUCCESSFUL (total time: 8 seconds)
what happen?

It says build was successful. The first warning is saying you use Java 7(1.7) where the source supports Java 6 (1.6). The second waring is a consequence of the first one. If your application works, i dont think there is any problem. If it doesnt work, try using java 1.6 or get the updated versions that support java 1.7.