I wrote a JavaScrip application a few years back using the closure framework and compiler. It uses goog.require, goog.provides and goog.inherits a lot, and was working fine using the old python script to build it.
I wanted it working again so I updated the library and compiler and used my old make script. But get this.
Closure Compiler now natively understands and orders Closure
dependencies and is prefererred over using this script for performing
JavaScript compilation. Please migrate your codebase. See:
https://github.com/google/closure-compiler/wiki/Managing-Dependencies
I read the link provided and did not see anything wrong. So I replaced the script with this.
java -jar C:/closure/closure-compiler-v20160713.jar --output_manifest _manifest.txt
--compilation_level ADVANCED_OPTIMIZATIONS --js M*.js
--js_output_file _M_min.js
It compiles fine, however when running I get errors such as...
_M_min.js?v=4:23 Uncaught ReferenceError: goog is not defined
_M_min.js?v=4:54 Uncaught TypeError: Cannot read property 'extend' of undefined
I thought the compiler unrolled all of this and did not require including the goog library at run time?
If I do include the library with "js/goog/base.js" I get goog.yb is not a function and so on. But I really did not think I needed to do this.
What am I doing wrong.
I think there are multiple problems:
You have to include closure library in your compilation as source. Adding --js path/to/closure/**.js will do it.
You need to use the dependency management flags. If you use goog.require and goog.provide in ALL of your files, you'll want strict mode.
Related
Is there a way in Groovy to import code from JDK11 modules such as javafx? So far, groovyc fails to compile, hitting an error when it imports the JavaFX module's code. I can't even get a HelloWorld groovy script to compile if it imports JavaFX.
A command such as this fails:
./groovy3/groovy-3.0.0-beta-2/bin/groovyc grscript.groovy -j -Fmodule-path=/usr/share/openjfx/lib/ -Fadd-modules=javafx.controls:javafx.base
Gives the error:
unable to resolve class javafx.application.Application
# line 2, column 1.
import javafx.application.Application;
^
Equivalent HelloJFX.java works just fine. Thus I know everything in OpenJDK11 and OpenJFX is working fine. It's just the Groovy side of things that is broken.
I am using OpenJDK11 and OpenJFX on Linux, Debian Buster. I've tried the stable version of Groovy and also the newest alpha of Groovy 3.
I can find almost no information online/anywhere about using Java 11 modules in Groovy.
If the answer is simply "No version of Groovy can use JDK11's modules such as JavaFX" I'd simply like to know.
Any other ideas very welcome. Thanks for reading.
You could try to put the JavaFX jars on the classpath instead of the modulepath and
then add a line like this to your program.
class MyProgramLauncher {public static void main(String[] args) {MyProgram.main(args);}}
The program must then be launched via this launcher class to make this work.
I don't know what the equivalent for this line is in Groovy but I am sure you can figure that out. I do this all the time in order to avoid all these module system headaches and so far it has never failed.
An upcoming release is planning to solve this issue. (The version 3 series, which is pre-release now.) I'll wait for it to be released as final and then try again.
JDK 11 is known not to work in earlier Groovy versions. In fact Groovy 3 is advertised as being JDK8+ compatible. (Website today says: "Groovy 3.0 is a bleeding edge version of Groovy designed for JDK8+ and with the new Parrot parser enabled by default. Pre-stable versions are available".)
From what I've read, there is a llvm program that converts java bytecode to llvm's intermediate form called class2llvm. My question is, how do I access this. What front end do I have to install in order to access this.
VMkit is their implementation of a JVM, but I am looking for how to compile the java source code with llvm, not how to run it.
The Java frontend translates Java bytecode (.class files) into LLVM
bytecode. Take a look at this link:
https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt
You may take a look at dragonegg, which enables llvm to use gcc's frontends. As gcc already has a frontend for java, called gcj, perhaps llvm can use it to compile java code. But I'm not sure how well llvm interfaces with the gcc frontend, so this may not work.
I have executed a java class using vmkit ( http://vmkit.llvm.org/ ) based on LLVM. It uses LLVM for compiling and optimizing high-level languages to machine code. J3 is an implementation of a JVM with VMKit.
[NOTE: From November 2015 it is no longer open source, so this hack is mostly useless.]
RoboVM might become the solution you're looking for. It's open source and compiles JVM bytecode (.class files) to machine code.
I assume they do it using something like class2llvm.
Unfortunately, it's still in alpha. I just tested it on HelloWorld.java. It gave 5x speed up of load time running on a single core. (Most of the run time is load time.)
echo Hello World! : <1 ms : 31K (/usr/bin/echo binary)
java HelloWorld : ~70 ms : 0.4K (HelloWorld.class JVM bytecode)
./HelloWorld : ~13 ms : 9.4MB (9.3MB binary + 57K robovm-rt.jar)
Note that java calls a 32MB $JAVA_HOME/lib/rt.jar file (and maybe more). Searching in such a large file must be part of the reason java is so slow to load. If RoboVM gets smarter, perhaps it can throw out most of the 9.3MB binary for an even faster load?
The website mentions iOS, but I think that's because they're selling their add-on UI libraries. RoboVM compiled fine for me on a flavor of Ubuntu. Just make sure to do
$ sudo apt-get install g++-multilib
first (and maybe install libpthread-stubs0-dev and libpthread-workqueue0...don't know if they mattered).
I'm using Google closure compiler application and can't figure out which of the following commands from the help menu would turn off the printing of standard output.
I'm combining multiple js files:
compiler-latest TimPeterson$ java -jar compiler.jar --js assets/js/file1.js
assets/js/file2.js --js_output_file assets/js/file.min.js
note: here's the command to access the help menu
compiler-latest TimPeterson$ java -jar compiler.jar --help
When using the --js_output_file option, the compiler prints warnings and errors to the terminal (to standard error). The compiler should not write anything to standard output in this case.
Note that the standard error can include significant portions of the code you'd like to have compiled in its compiled form. This is not standard output though.
You can use https://github.com/knyga/kjscompiler
It compiles js files in project. And watch the dependencies
I am an struggling with using a C++ library I have just sucessfully
compiled on ubuntu in sbcl.
I have tried to use the .h file parser 'ah2cl' but from the
documentation it is not clear if I require UFFI or CFFI (is there a
difference?). My attempts to use the dummy test library and the
dummy header file provided with 'ah2cl' have failed. I get a message
about a missing CALLBACK package from sbcl. But does sbcl not support
callback natively ?
Is there another .h file parser that I should use for this
kind of task ?
You might want to try CFFI's groveller, which parses header files to produce the corresponding CFFI bindings. BTW, UFFI is basically deprecated in favour of CFFI for a while now.
I am using Qt in a project and am now trying to include another project that uses boost.
I have added no_keywords to my config in the qt project file to avoid collision between the signal and slots functionality that is present in boost and Qt. But now I get a compilation error which seems to stem from double definition of a function called "check". Is there some way to avoid this?
An example is has_postfix_operator.hpp (line 141):
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
Apparently there is a "check" defined in Qt.
I'm using Qt4.7 and boost 1.48. Running MacOSX 10.6.8
You should also look at /usr/include/AssertMacros.h, which defines a macro named "check" - that could be the cause of your problem.
To check this, add -d __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 to your compiler flags.
If that works, that was your problem.
Here's a comment from that file:
Prior to Mac OS X 10.6 the macro names used in this file conflicted
with some user code, including libraries in boost and the proposed C++
standards efforts, and there was no way for a client of this header to
resolve this conflict. Because of this, most of the macros have been
changed so that they are prefixed with
__ and contain at least one capital letter, which should alleviate the current and future conflicts. However, to allow current sources to
continue to compile, compatibility macros are defined at the end with
the old names. A tops script at the end of this file will convert
all of the old macro names used in a directory to the new names.
Clients are recommended to migrate over to these new macros as they
update their sources because a future release of Mac OS X will remove
the old macro definitions ( without the double-underscore prefix ).
Clients who want to compile without the old macro definitions can
define the macro
__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before this file is included.