I just want the errors, and nothing else, to be printed out for now. Thanks :)
Have you tried
<javac .... nowarn="on">
Note that this does not disable all kinds of warnings.
Related
I want to set optuna's study.optimize verbosity to 0. I thought optuna.logging.set_verbosity(0) might do it, but I still get the Trial 0 finished with value .... updates for every trial
What is the correct way to do this? Unfortunately, extensive searching through the docs still only results in the above method.
Many thanks in advance
Try this:
optuna.logging.set_verbosity(optuna.logging.WARNING)
It basically changes the level of verbosity.
For more level choices, check optuna's official guides here.
optuna warnings tend to be raised using standard pythonic warnings.warn() (which explains why optuna.logging.set_verbosity() does not always work to suppress them), so you can silence them all at once with:
# treat all python warnings as lower-level "ignore" events
warnings.filterwarnings("ignore")
Be aware however, that this will silence also the useful and infrequent ones like deprecation warnings.
When trying to compile a Javadoc taglet, which requires $JAVA_HOME/lib/tools.jar, I discovered that ant (version 1.8.4) sets java.home to $JAVA_HOME/jre rather than just $JAVA_HOME. I verified this thusly:
<echo>${java.home}</echo>
<echo>${env.JAVA_HOME}</echo>
[echo] /usr/java/jdk1.7.0_21/jre
[echo] /usr/java/jdk1.7.0_21
According to ant -diagnostics, there isn't any property like a jdk.home. Thus, to use tools.jar I have to do:
<classpath location="${java.home}/../lib/tools.jar"/>
So, I have two questions:
1) Is there something wrong with my setup of ant that's causing java.home to point to the JRE instead of the JDK?
2) If this is the way ant is supposed to work, is using the .. in my classpath the way I'm supposed to do things? Or should I do ${env.JAVA_HOME}/lib/tools.jar? Or something else entirely?
Here are the answers:
"Is there something wrong with my setup ...?" No. Ant is setting it's internal java.home based on JVM System properties. The code for HotSpot (JVM internals) sets it with "/jre" appended on purpose. In fact, the Java(TM) Tutorials for System Properties describes it exactly that way. The "java.home" variable from inside ant really isn't one-in-the-same as the "JAVA_HOME" that is set in your environment -- different but with similar names.
"(What is) the way I'm supposed to do things?" You can really do whatever you feel is appropriate, but remember that Ant can and usually does run in a separate JVM process. I'd assume that your system environment is probably specifying the JVM that was used to develop the app, so I would just use "${env.JAVA_HOME}" to ensure that development expectations meet build expectations.
For more information, please see another similar answer here.
Also, consider that more info can be collected from ant by running it with the -debug, -diagnostics and/or -verbose flags.
Had the same problem. I found that adding fork="true" to the javac tag solves this issue. So do something like this:
<javac target="1.7" source="1.7" fork="true" ...>
I will thank whoever can explain why this works.
Ok, We all love fsi, but I hate it when I type in the wrong thing and then I want to go up a line and it won't let me....
Is there some kind of shortcut I am missing?
For example, here is a mutually recursive discriminated union. Oh crap, I screwed it up. I want to go back, but I can't.
How do I go up one line and fix stuff?
If you've already committed the line, you can either redefine it (you can define the same types/functions as many times as you want in FSI), or start over. That's why the preferred way to use FSI is: write the code in a script file and 'Send to Interactive'. That avoids this issue.
We are using Hudson as our build machine and I am trying to configure the excludes fileset for the Compilier Warnings plugin. Hudson parses the build log to determine warnings/errors and our Clover scripts output duplicates of real warnings.
As documented by Hudson you can configure an ANT fileset to exclude certain warnings:
Warnings to ignore:: Fileset 'excludes' setting that specifies the warnings to exclude from the report (based on their filename).
I am getting the following warnings (duplicates):
C:/vsfz/temp/1/clover1710786373818922904.tmp/src4952837385592305293.tmp/corp/app/path
....
I have set the excludes fileset to:
*vsfz/temp/*/clover*/**
I expected the Fileset to match the warnings and for them not be added to the Compiler Warnings report, this is not the case. Does anyone see a problem with the above Fileset definition?
Try something like:
C:/vsfz/temp/*/clover*/**
or
**/vsfz/temp/*/clover*/**
another problem might be that clover* doesn't match correctly so that you have to write it as clover*.* but I don't think this is the issue.
I was just messing with this today and I could only get it to work when I specified the file extension*.csor maybe *.* would work?
anyway **/old*/**/*.cs worked for me.
Hope this helps.
I managed to get this going (it has been on the back burner for quite some time now).
The template that I ended up using:
**/temp/**
I need the list of files that were compiled during this run. I want to feed this list to a subsequent post-processing step.
I have found an option to list (see listfiles option) the files compiled during this run, but it seems only good for displaying the list on console.
Any idea?
Edit: I am talking about incremental compiles, so taking a fileset of the build folder is not an option.
Edit: One idea seems to be custom logger but I am still looking for something simpler
Edit: Another idea is to use depend selector with FileSet before javac and somehow keep the list in memory, to be used after javac has executed
You simply can form a fileset about all class-files in the target-directory of the javac.
Edit: After the clarification I have to adjust my answer. I didn't such thing yet, but I would try my luck with selectors. The modified-selector looks like the one you want - a fileset of all class-files in a directory, that have changed since the last run. Here is a code-snippet:
<fileset dir="${build}">
<filename name="**/*.class"/>
<modified/>
</fileset>
It does not directly post-process the output of the javac-task, but should solve your problem.