What flags should be set to build multithreading application?
I see that there are QMAKE_CFLAGS_THREAD and QMAKE_LFLAGS_THREAD. I've found this document, there are this flags described, but lacks information how to set them.
I've also found that I should add:
CONFIG += thread
You only need:
CONFIG += thread
This will set up appropriate compiler and linker flags. The _THREAD variables allow you to modify those default flags in case they don't suit you.
However, you shouldn't actually need to even add thread to CONFIG. The default nowadays is to build with threading support anyway.
Related
Qt 5.8 was supposed to come with the optional use ahead of time qtquick compiler, instead it arrived with a sort-of-a-jit-compiler, a feature that's enabled by default and caches compiled QML files on disk in order to improve startup performance and reduce memory usage.
The feature however arrives with serious bugs which greatly diminish, or in my case even completely negate its benefits, as I didn't have a problem with startup times to begin with, and testing didn't reveal any memory usage improvements whatsoever.
So what I would like to do is opt out of that feature in my project, but I don't seem to find how to do that. Going back to Qt 5.7.1 is not an option since my project relies on other new features, introduced with 5.8.
Add QML_DISABLE_DISK_CACHE (set to 1) to your environment variables. You should be able to do it inside your application via qputenv -- put it somewhere in main before loading QML content.
Credit to peppe for informing us of the environment variable, but qputenv()only takes a QByteArray as the value parameter, so 1 won't work.
The two options that work:
qputenv("QML_DISABLE_DISK_CACHE", "1"); // or
qputenv("QML_DISABLE_DISK_CACHE", "true");
This successful disables the cache and prevents the associated bugs from manifesting.
Firstly: The "official" (?) node.js externs are located here: https://github.com/google/closure-compiler/tree/master/contrib/nodejs
But i can't use it because the high amount of warnings (and errors sometimes) that are generated. For example: The declaration of "process" module is very "thin"; Only has one property defined on his prototype, besides not inherit from EventEmitter, so i can't register callback when, for example, i want to do a clean job on process SIGINT (process.on('SIGINT', callback)).
When i mix several externs files declaring the core modules of node.js, more and more warnings and errors are raised (i always respect the deps tree between externs). For example: If i include the events.js and stream.js externs files, an error is raised because the "event" global var is redeclared: Once in events and again in stream.
So: What am i doing wrong?
The closure compiler that i am using is the latest git, whit --new_type_inf and --env flags activated, among others.
For example: If i include the events.js and stream.js externs files, an error is raised because the "event" global var is redeclared: Once in events and again in stream.
This highlights the core of the problem - and why they are not well maintained. The compiler doesn't recognize that these variables are in fact NOT global. The compiler currently does not have a method to correctly interpret externs as modules. The were originally contributed and consumed by a fork of the project that could understand externs as modules.
I am currently working on adding support to the compiler for this and hope to some day soon be able to completely rewrite this answer.
In the mean time, you might be able to work around some of this by adding #suppress {duplicate} annotations to the files. However keep in mind that they will still be global types.
If you wish to improve the files (like having process properly extend EventEmitter), I will happily review pull requests for such changes.
All,
I'm trying to get Play Framework to recognize JVM arguments in all modes (test, run start) by setting them in Build.scala.
Unfortunately, Play ignores everything I've thrown at it.
I've set Keys.javaOptions and Keys.fork, but it SBT flat out ignores the fork command. I also tried going at this by replacing Build.scala with build.sbt, but that doesn't seem to work either.
I realize you can set JAVA_OPTS or PLAY_OPTS in your environment, but this is really lousy way of doing things. One should be able to configure this at the application level and play should be smart enough to either spawn a new process or re-launch itself with the appropriate configuration.
Anyone able to get this to work? If so, can you provide a complete, working solution?
The Play Framework SBT keys override javaOptions you pass, and therefore it will not work.
The way to do it ,according to the documentation, is to pass those arguments at the start command.
The syntax changes a bit from version to version, but at 2.2.x it is:
$ /path/to/bin/<project-name> -J-Xms128M -J-Xmx512m -J-server
in FlashProfessional, there is a concept called "Config constants" which get set in the Publish Settings. They can be used for conditional compilation as explained here http://help.adobe.com/en_US/Flash/10.0_UsingFlash/WS3e7c64e37a1d85e1e229110db38dec34-7fa4a.html#WS7D94A7C3-8F91-421a-936C-F076374C470F
Question: how do you set config constants in the FlexBuilder IDE?
Thanks!
Set it in Additional compiler option in the following way: -define+=CONFIG::isRelease,false
I'm using a pretty recent version of SBT (seems to be hard to figure out what the version is). I want to pass system properties to my application with sbt run as follows:
sbt -Dmyprop=x run
How could I do that?
SBT's runner doesn't normally create new processes, so you also have to tell it to do this if you want to set the arguments that are passed. You can add something like this to your build settings:
fork := true
javaOptions := Seq("-Dmx=1024M")
There's more detail on forking processes in the SBT documentation.
I found the best way to be adding this to build.sbt:
// important to use ~= so that any other initializations aren't dropped
// the _ discards the meaningless () value previously assigned to 'initialize'
initialize ~= { _ =>
System.setProperty( "config.file", "debug.conf" )
}
Related: When doing this to change the Typesafe Configuration that gets loaded (my use case), one needs to also manually include the default config. For this, the Typesafe Configuration's suggested include "application" wasn't enough but include classpath("application.conf") worked. Thought to mention since some others may well be wanting to override system properties for precisely the same reason.
Source: discussion on the sbt mailing list
Thanks for the pointer, this actually helped me solve a somewhat related problem with Scala Tests.
It turned out that sbt does fork the tests when there are sub-projects (see my code) and some of the tests fail to pick up the system property.
So in sbt -Dsomething="some value" test, some of the tests would fail when failing to find something in the system properties (that happened to be my DB URI, so it kinda mattered!)
This was driving me nuts, so I thought I'd post it here for future reference for others (as #akauppi correctly noted, chances are high that "others" may well be me in a few weeks!).
The fix was to add the following to build.st:
fork in Test := false
I think the best is to use the JAVA_OPTS environment variable:
#update the java options (maybe to keep previous options)
export JAVA_OPTS="${JAVA_OPTS} -Dmyprop=x"
#now run without any extra option
sbt run
You can pass system properties at the end of the sbt command:
sbt run -Dmyprop=x
If you have to pass program parameters into a stage, just pass system properties after the quotes again:
sbt "runMain com.example.MyClass -p param-value" -Dmyprop=x