This seems like a simple thing, but I can't find an answer in the existing questions:
How do you add a global argument to all your present and existing run or debug configurations? In my case, I need a VM argument, but I see that this could be useful for runline arguments as well.
Basically, every time I create a unit test I need to create a configuration (or run, which creates one), and then manually edit each one with the same VM argument. This seems silly for such a good tool.
This is not true. You can add the VM arguments to the JRE definition. This is exactly what it is for. I use it myself so that assertions are enabled and heap is 1024mb on every run, even future ones.
Ouch: 7-years bug, asking for running configuration template, precisely for that kind or reason.
This thread proposes an interesting workaround, based on duplicating a fake configuration based on string substitution:
You can define variables in Window->Preferences->Run/Debug->String Substitution. For example you can define a projectName_log4j variable with the
correct -Dlog4j.configuration=... value.
In a run configuration you can use ${projectName_log4j} and you don't have to remember the real value.
You can define a project-specific "empty" run configuration.
Set the project and the arguments fields in this configuration but not the main class. If you have to create a new run configuration for this project select this one and use 'Duplicate' from its popup-menu to copy this configuration.
You have to simply set the main class and the program arguments.
Also you can combine both solutions: use a variable and define an "empty"
run configuration which use this variable. The great advantage in this case
is when you begin to use a different log4j config file you have to change
only the variable declaration.
Not ideal, but it may alleviate your process.
Related
i have a bitbucket classic build pipeline and i need to have the ability to set the build clean option at queue time. it seems like this used to be possible via the Build.Clean variable but that has since been deprecated.
When editing a build pipeline the Clean option uses an editable drop down but anytime you try and type something, it erases what you just wrote. i would like to set this option to a variable like $(CleanBuild)
Assign build clean option at queue time
Indeed, the variable Build.Clean is already deprecated. But the document Use predefined variables provided another variable Build.Repository.Clean, which will help us to clean the Sources:
Besides, if you want to clean other options fields, like All build directories:
I do not believe there is a way to assign the clean options at queue-time. Even if we use deprecated Build.Clean variable, we still can clear Sources only.
You could check the similar thread for some more details.
Hope this helps.
I have this in a .conf file and I want to overwrite the value at index 0 in array field1
database {
master {
field1:["a","b","c"]
}
}
and I run the application via sbt like this:
sbt -Ddatabase.master.field1.0="11.111.11.111:3306" package
then I look inside the jar at the .conf file and nothing is changed.
This guide indicates to change each array element by index instead of the whole array (which I also tried but to no avail): https://salsa.debian.org/java-team/typesafe-config/blob/master/HOCON.md#array-and-object-concatenation
How do you overwrite array elements in HOCONS?
I think the problem is, that your hocon is part of what you try to pack, but the -D will give the params to the JVM of sbt. Why should the config of the sbt's JVM have any influence to the .jar you pack?
Edit
Adrian taught me, that this is actually possible. Still my solution below is what I would prefer. It is explicit and good to understand. Some params and the sbt call seems to me to not be nice and clean.
I guess you want to have an environment specific database config.
You could start the application with your config as you tried with sbt or put all configs for different systems in different hocons and load the hocons depending on the system you start, which you can define by a parameter for the program.
Look at the docs to see how to load additional files.
I am new in Akka and I faced the problem below.
I want to externalize the configuration in my App. More specifically, I have some variables that are different per each environment. So I think that I can have specific environment variables (secrets, etc) for each environment.
But what I can do with some variables (non-secrets) which are different per each environment?
What is the difference between, dev.properties, application.conf, deploy.json files?
What is the proper way to load variables from those files?
There's a few options:
Environment variables and using the support for substitution (there is also support for having default in the file and only use the environment vars if they are set). - https://github.com/lightbend/config#optional-system-or-env-variable-overrides
System properties, if you set a system property when you start the JVM, and that system property matches a path in the config file, it overrides the setting
You can point to an alternative application.conf file using a system property - https://github.com/lightbend/config#standard-behavior
If that is not enough you could also do completely custom logic around selecting logic by programmatically creating a Config instance and passing that to the ActorSystem when you create it.
The dev.properties and deploy.json is AFAIK not related to Akka, unless something specifically done in your application.
I was wondering if it's currently possible to have an 'external' (.so/.dylib) LLVM plugin (module) pass scheduled at LTO time? The reason for wanting this is a inter-modular optimization I want to add.
I also found this topic; How to write a custom intermodular pass in LLVM?
But a separate tool is not an option for me.
Thanks
I think the most helpful thing here might be to understand how passes are run and what the state of the code is during LTO.
First of all, when optimization passes are run by the compiler, they are done as a set that has been added to a PassManager. This means that LLVM/Clang, when passed something like -O3 will create a copy of a PassManager and subsequently provide it the set of passes expected to provide O3 level of optimization. This is very different from what you are doing with an external library which must be provided manually and cannot be fit into the pass pipeline normally.
Then we have the state of things when doing LTO. During Link Time Optimization, all of the individual translation units have been consolidated and are now a single Module. This means that an optimization which runs on each function will run on every function in the code base. Similarly, a per-module optimization will run on the full Module and therefor offer Inter-Procedural Analysis/Optimization.
If you're looking to use an Intra-Modular Pass then there is no reason to do this at LTO time and instead you can simply make a ModulePass and run that on each unit.
I'm trying to run an algorithm that requires a few hundred megabytes of memory within eclipse, and I've specified VM arguments -Xmx512m, but I can't get past some arbitrary memory limit which seems to decrease as I continually try to run my programs. Physical memory is fine...what could be the issue?
Eclipse takes VM arguments, but those are for the Eclipse platform itself, you need to modify the applications Launch Configuration to ensure it has enough memory.
When you run a program within Eclipse it creates a new Launch Configuration with default parameters. You can modify those parameters by selecting Run->Run Configurations.. (or Debug->Debug Configurations...), then select the relevant configuration. If it is a Java main app, the configuration will be under Java Application, probably with the name of the class or project you selected when you first ran it.
Select the launch configuration, then the Arguments tab, then enter the relevant JVM arguments (i.e -Xmx512m) in the VM arguments pane. You can also enter Program arguments to pass to the main method if you wish.
(source: modumind.com)
Update: another parameter to try passing is -XX:MaxPermSize=128m, if your algorithm is creating lots of method and/or class objects (which sounds like it is the case).
Look at the arguments -Xms too. Be sure that the argument is specify to your Run mode ( Run / debug).
If you still have some problem, you can use a profiler to see what happen in memory, or just logging the Runtime.getRuntime().freeMemory() can help.
You should ensure that you are specifying the arguments for your test application in the Run Dialog, and not in arguments to Eclipse itself.