RedHawk installs JARs for eclipse plugins from redhawk-yum-1.10.2-5-el6-x86_64.tar.gz. In RedHawk 1.9 it only installed 4 JARs for IDL parsing and editing, but in RedHawk 1.10 it installs these 4 but also 2 from Eclipse Corba Package.
gov.redhawk.eclipsecorba.idl_7.1.0.201501292343.jar
gov.redhawk.eclipsecorba.idl.source_7.1.0.201501292343.jar
gov.redhawk.eclipsecorba.idl.edit_4.1.0.201501292343.jar
gov.redhawk.eclipsecorba.idl.edit.source_4.1.0.201501292343.jar
net.sf.eclipsecorba.idl_0.7.0.218.jar
net.sf.eclipsecorba.idl.edit_0.7.0.218.jar
Many java files have the same names but there are also many differences.
From comments in the source java files it appears that the gov jars used JavaCC to build the parser while those from ECP used SableCC.
Which ones are actually used in RedHawk 1.10 or are they both used for different purposes?
I am trying to look into a parser bug and would like to know which parser to look at.
Sorry, I am not familiar with Eclipse plugin development and have not figured out how to tell what plugins are actually loaded or how they are used.
Redhawk uses the Eclipse Corba Plugin (ECP) project to provide an editor for IDL files:
http://eclipsecorba.sourceforge.net/
The editor does not support constant IDL expresions (e.g. const foo = bar + 1). Unfortunately, the project is not maintained any more (last release in 2008).
For all other IDL functions in the IDE, such as displaying IDLs under the "Target SDR" in the explorer view, the Redhawk IDE has its own parser code which handles this. The IDE's parser currently has the same limitation - it does not recognize constant IDL expressions.
RedHawk uses three distinct IDL parsers. 1) omnicpp (omniorbs version of idl2cpp) uses its own parser. 2) the code that builds a tree for the IDL Repository in Target SDR uses a plugin in gov.redhawk.eclipsecorba.idl.* which has a parser based on JavaCC compiler-compiler. 3) the IDL editor that was introduced in RedHawk 1.9 uses a different plugin in net.sf.eclipsecorba.idl.* which as a parser based on SableCC, a different compiler-compiler.
Related
All groovyconsole binary distros I have found don't support Java 14. The console complains if you try to specify a Jar file that has been compiled with Java 14, for example.
The obvious solution, I thought, was to build Groovy with Java 14. That seems non-trivial.
gradle.wrapper.properties files contain
distributionUrl=http://services.gradle.org/distributions/gradle-2.3-bin.zip
which is a broken URL. Change that to https and then it works, partially.
You then get
FAILURE: Build failed with an exception.
What went wrong:
Could not determine java version from '14.0.2'.
Reading the docs for gradle makes it clear that most (all?) versions of gradle do not support Java 14. Definitely version 2.3 does not. Why - I have no idea.
So... back to my original question. How can I get a groovy installation to support Java 14?
Thanks!
If the Jar cannot be loaded, it is most likely the asm lib, which is unable to read it. To read Java14 you need at least ASM 7.2 I think. ASM in Groovy is not provided as standalone library, because of possible conflicts with other jar dependencies it is shadowed (bytecode is transformed by renaming the packages and directly added to the Groovy jar). I see here 2 options:
compile Groovy yourself and change the dependencies to have at least ASM 7.2. It does not matter if you build Groovy with a lower version of the JDK, the JDK still allows to read "old" jars.
use at least Groovy 2.5.9, 3.0.0 or 2.4.19, as they include asm 7.2 or higher
Of course this does not mean it will change the Groovy Gradle is using easily. For that I would use Groovy 2.5 and read Bumping Groovy version in Gradle?
If this does not solve the problem or answer the question I would need more details.
I'm using Eclipse 4.5 with the Groovy-Eclipse 2.9.2/4.5 plugin which I thought was supposed to have the Groovy 2.5 compiler. However, it didn't have any picocli support so I added the groovy-cli-picocli-2.5.2-indy.jar to my classpath and was able to compile. However #2, when trying to run the script via Eclipse I get:
java.lang.ClassNotFoundException: picocli.CommandLine$ParameterException
It looks like groovy-cli-picocli-2.5.2-indy.jar does not have CommandLine class at all.
I would just throw jars at this from the fullblown picocli distribution but I'm under the impression they all have to somehow wrap nicely into Eclipse Groovy library via groovy.cli.picocli.CliBuilder.
Is my Groovy 2.5.2 missing this or am I somehow missing the boat on how it's supposed to work because picocli is not working for me in this configuration. Thanks!
You are correct: groovy-cli-picocli-2.5.2.jar (and groovy-cli-picocli-2.5.2-indy.jar) do not contain the picocli classes.
You need to add the picocli jar to the classpath.
If you use Maven, the groovy-all POM should include all dependencies.
(My original answer mentioned picocli classes that are shaded into the groovy-2.5.x.jar under the groovyjarjarpicocli package but these are intended for use internally by Groovy and not meant to be used by applications.)
I would like to use the old codegen capabilities (before Xcode 8) for core data: Therefor I am setting the Tools Versions at the File Inspector to Xcode 7.3 but no success. Using "Editor -> CreateNSManagedObject Subclass" still generates files Recipe+CoreDataClass.h/m and Recipe+CoreDataProperties.h/m in my example and not as expected Recipe.h/m
It makes no different if I am choosing "Class Definition" or "Category/Extension" at Class -> Codegen at the Data Model inspector.
To use the manual triggered NSManagedObjectsubclass code generation like used to in older Xcode versions (<= Xcode7), set Codegen to none.
You can find details in this answer.
My application has minSdk at 15 and targetSdk at 20. I need a support library because my application uses the PageViewer view.
Reading the documentation I read that the support library vx is designed to be used on the API level x. I think that the version's number x should be between 15 and 20.
How should I choose that number?
Secondly, using android studio I have to add the following line in a file named build.grandle, for using the support library v4.
compile 'com.android.support:support-v4:20.0.0'
What is the meaning of the suffix 20.0.0?
The support libraries have different revisions/versions. You can check more info here
Adding this part in your gradle file:
compile 'com.android.support:support-v4:20.0.0'
you are telling gradle to get the support-library-v4 with revision 20.0.0.
About which version you should use. If you compiling with api20, you can use the revision 20.
I am trying to build an application which depends on Boost. So I downloaded Boost 1_41_0 to my Linux box and followed the instructions found on the Boost site for Unix variants,
http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html.
They basically suggest that I run ./bjam install, which I did. The build completed successfully. However, the library names don't seem to match the Boost naming convention described both in the documentation above, and what is specified in the makefile of the application I am trying to build.
I noticed that there are a bunch of options that I can specify to bjam and I tried to play with those, but no matter what happens I can't seem to get it quite right. My understanding is that the libraries should go into the $BOOST_ROOT/lib directory. This is where the libraries show up, but named:
libboost_thread.a
libboost_thread.so
libboost_thread.so.1.41.0
I'd expect them to be named libboost_thread-gcc41-mt-d-1_41_0 or something similar.
I did try ./bjam --build-type=complete --layout=tagged and I see:
libboost_thread.a
libboost_thread-mt.a
libboost_thread-mt-d.a
libboost_thread-mt-d.so
libboost_thread-mt-d.so.1.41.0
libboost_thread-mt-s.a
libboost_thread-mt-sd.a
libboost_thread-mt.so
libboost_thread-mt.so.1.41.0
libboost_thread.so
libboost_thread.so.1.41.0
So, I am not sure if I should just make stage my -L directory? Is there any documentation which describe this in more detail?
The names was changed in 1.40.0 - see in release notes:
Build System
The default naming of libraries in
Unix-like environment now matches
system conventions, and does not
include various decorations.
They probably forgot to update this part in the build documentation.
There are two variables here. First is "install" vs. "stage" (default). "install" copies both libraries and headers into a directory -- /usr/local by default, and you can then remove source tree. "stage" puts libraries to "stage/lib", and you should add "-L /stage/lib -I " flags.
Second is --layout=versioned and --layout=system. It seems like you have discovered what they do already, and indeed, system is default since 1.40. The getting started guide fails to mention this, and I've added an action item to update it. Ideally, you should talk to the authors of the application to use the system naming of boost libraries. If that's not possible, then building with --layout=versioned is the only option.
From the Boost documentation at http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming, the convention is:
-mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.
-d ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when:
s linking statically to the C++ standard library and compiler runtime support libraries.
g using debug versions of the standard and runtime support libraries.
y using a special debug build of Python.
d building a debug version of your code.
p using the STLPort standard library rather than the default one supplied with your compiler.
n using STLPort's deprecated “native iostreams” feature.
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library in “native iostreams” mode, the tag would be: -sgdpn. If none of the above apply, the ABI tag is ommitted.