I'm using the OPAL framework to implement static analyses. I wondered if it is possible to suppress the console output of the framework which is printed on the console while execution. The following shows a part of the output.
...
[info][OPAL] Bytecod Representation - Development Build (asserstions are enables)
[info][project configuration] the JDK is part of the analysis
[warn][project configuration] supertype information incomplete
...
I found that OPAL has several LogLevels (i.e. WARN, INFO, ERROR) but I couldn't find a way to specify the logging granularity. I'm really interested in warnings and errors but I would like to suppress the (massive) output at info level.
By now I figured out that it is possible to suppress the console output of OPAL. The OPAL logging mechanism uses several LogContext objects. It exists one GlobalLogContext and one LogContext per available Project. Since both are independent it is necessary to silence both types.
The first context is used for every logging event which does not happen in the context of a specific project whereas the project-specific context is used to log messages in a given context.
The OPALLogger.update(...) method can be used to update the Logger that is used for a LogContext. With this method, it is possible to associate a new Logger with a LogContext. If you are running OPAL with the command line, a ConsoleOPALLogger can be used as follows.
val project = ...
OPALLogger.updateLogger(project.logContext, new ConsoleOPALLogger(true, org.opalj.log.Error))
OPALLogger.updateLogger(GlobalLogContext, new ConsoleOPALLogger(true, org.opalj.log.Error))
Related
I'm frustrated by unintelligible stacktraces when my Scala.js code throws an exception. I thought I had a solution using a Javascript library (see Getting a scala stacktrace) but it breaks too often.
How do you extract meaning (where the program broke; how it got there -- in terms of the Scala code) from a stacktrace like the following. Or am I doing something wrong to even get an untranslated stacktrace?
Take a look at this code I wrote a while back in my youi framework: https://github.com/outr/youi/tree/e66dc36a12780fa8941152d07de9c3a52d28fc10/app/js/src/main/scala/io/youi/app/sourceMap
It is used to reverse JS stack traces to Scala stack traces. In youi I send the errors to the server so I can monitor browser errors that occur with the complete traceback.
Brief Overview
source-map.js
You need source-map.js to parse the js.map file that Scala.js
generated when it compiled your code. See:
https://github.com/mozilla/source-map
Load the js.map file via Ajax
The SourceMapConsumer needs a js.Object (JSON) of the js.map file. See https://github.com/outr/youi/blob/e66dc36a12780fa8941152d07de9c3a52d28fc10/app/js/src/main/scala/io/youi/app/sourceMap/ErrorTrace.scala#L58 for an example of loading via youi's Ajax features.
Process the Throwable
The trace represents line and columns in the JS file and you can pass
that information to SourceMapConsumer to get the original Scala line
numbers back (see SourceMapConsumer.originalPositionFor). See
ErrorTrace.toCause
(https://github.com/outr/youi/blob/e66dc36a12780fa8941152d07de9c3a52d28fc10/app/js/src/main/scala/io/youi/app/sourceMap/ErrorTrace.scala#L98)
for an example iterating over the Throwable's trace elements.
Handling Errors
Now that you have the capacity to process JavaScript errors and
convert them back to Scala traces, you need to actually receive the
errors. If you want to globally handle uncaught errors set a function
to window.onerror to capture errors. As of this writing, the
function signature in Scala.js isn't ideal for handling all
information, so in youi I use js.Dynamic to set it to what I need
(see:
https://github.com/outr/youi/blob/e66dc36a12780fa8941152d07de9c3a52d28fc10/app/js/src/main/scala/io/youi/app/ClientApplication.scala#L35).
Also, notice that in ErrorTrace it supports multiple incoming types
of errors (ErrorEvent, Throwable, and a more generic scenario).
This is because in JavaScript the errors come in different ways based
on what's happening. This is a fairly complex topic, and why I
created this functionality in youi to simplify things.
Not nearly as brief an overview as I would have liked, but this isn't a simple problem to solve. The source-map GitHub project (https://github.com/mozilla/source-map) has decent documentation and is what I used originally to write my solution (with some added trial and error). If the information I've provided is incomplete I'd recommend reading more there as it should provide the majority of information, and probably better explained.
I'd like to be able to turn off a particular compiler warning, but only for a single file in my project. Is this possible?
The context is that I have a single source file that makes calls to an external macro library that produces adapted-arg warnings. I found that I can eliminate these warnings by changing my build.sbt file:
scalacOptions ++= Seq("-Xlint:-adapted-args,_" /*, ... */)
However, this turns off the warning globally, and I only want it off for the single file that raises them.
I haven't had any luck searching for any of the following possible solutions I thought might exist:
Specifying separate compilation options for different files in my project in my build.sbt file
Providing some pragma-like comment in my source file to change the warnings generated by the compiler, similar to the special scalastyle:on/off comments recognized by Scalastyle
Some annotation for smaller regions of code, like #unchecked
So, is there any way to have different linting options in effect for different files, or even for limited regions of code?
The expectation was that folks would write a custom Reporter that would filter out undesirable warnings.
It's easy to write one that filters by file name, perhaps given a whitelist.
The error/warn API supplies the textual Position. It would also be easy to parse the position.lineContent for a magic comment token like IGNORE or SUPPRESS, which is not as convenient as a SuppressWarnings annotation but is easy to implement.
The compiler asks the reporter if there were errors.
The custom reporter is specified with -Xreporter myclass, or it wouldn't surprise me if someone has written an sbt plugin.
In Paper [A Software Product Line for Static Analyses(2014)], there is an illustration related constructing call graph(Listing7).
In this example, Line14 is related to construct call graph. while i check the src code and API, what i could find is DefaultCHACallGraphDomain.scala which has no implementation of construct call graph.
As my purpose is using OPAL to construct call graph. Is there any demo or documents help me understanding existing CallGraphDomain in OPAL? currently, i can only find some class declaration.
I'll be really appreciated if anyone can give me some suggestions related this topic.
Thanks in advance.
Jiang
The interface that was shown in the paper doesn't exist anymore, so you can totally forget about it.
The default interface to get a CallGraph class is provided by the Project object you retrieve when you load the bytecode a Java project.
A general code Example:
val project = ... // a java project
val computedCallGraph = project.get(/* Some call graph key */)
val callGraph = computedCallGraph.callGraph // the final call graph interface.
The computed call graph contains several things. It contains the entry points, unresolved method calls, exceptions when something went wrong at the construction time and the actual call graph.
OPAL provides you several call graph algorithms, you can retrieve each by passing the corresponding call graph key to the Project's get method.
Currently, the following two keys are available and can be passed to Project.get (more information is available in the documentation of this classes):
CHACallGraphKey
VTACallGraphKey
Analysis mode - Library vs Application
To construct a valid call graph for a software project it depends on the project kind which analysis mode to chose. While applications provide complete information (except incomplete projects, class loading and so on), software libraries are intended to be used by other projects. However, those two different scenarios have to be kept in mind, when construction call graphs. More details can be found here: org.opalj.AnalysisModes
OPAL offers the following analysis modes:
DesktopApplication (safe for application call graphs)
LibraryWithClosePackagesAssumption (safe for call graphs that are used for security-insensitive analyses)
LibraryWithOpenPackagesAssumption (very conservative/safe for security analyses)
The analysis mode can be either configured in OPAL's config file or set as project setting at runtime. You can find the config file in the Common project under /src/main/resources/reference.conf.
All of those analysis modes are supported by the the CHACallGraphKey while VTACallGraphKey only supports applications so far.
NOTE: The interface may change in upcoming versions again.
Using the standard GWT logger, is it possible to disable the Log statements for a complete package in the xml?
Or at least individual class's?
At the moment in the xml I can disable/endable all the logging with;
<set-property name="gwt.logging.enabled" value="TRUE"/>
This seems to set it globally for all class's in all packages. Is it possible to do this selectively in the xml?
The guide here; http://www.gwtproject.org/doc/latest/DevGuideLogging.html seems to only cover configuring the rootlogger, covering every log in the project. I am probably missing the obvious, but I don't "get" how to apply this selectively.
Given all my log statements are named;
protected static Logger Log = Logger.getLogger("parent.childc");
It seems like selectively turning them on/off should be possible.
Thanks,
Thomas
If you have all of your logger instances really initialized as Logger.getLogger("Example"), you can't selectively turn them off and on, since they are all one instance called 'Example', so I'm assuming that this isn't actually the case.
For the most part, this is normal JULI - the standard mechanisms that work on the JVM will work here. This is doubly true in dev mode, which actually uses the standard java.util.logging.Logger implementation. So if you are just looking for cleaned up logging in dev mode, treat it as you would any other logger - from the root instance, find the package or class that you want to disable/enable, and set the log level to where you want it.
In compiled code this behaves a little differently, you may need to experiment a bit to see exactly how, I don't recall at the moment. However, you can still use LogManager, and can walk all existing loggers, packages:
LogManager manager = LogManager.getLogManager();
Enumeration<String> allLoggers = manager.getLoggerNames();
// for each String in the list, grab the logger via manager.getLogger
The advantage to this as opposed to Logger.getLogger is that this will only tell you about loggers that already exist, instead of creating them as you go. This way you could have a config file or url param that specifies which details you wish to see logged, and disable the rest.
EDIT: I ran an old sample I had made again, and it appears that the chief difference between dev mode and prod mode is that in prod mode you get a logger per package, with root at the top and the specific named loggers as 'leaf nodes', while in dev mode all loggers seem to be placed in the root logger directly, with no intermediate packages. It is possible that if you requested a logger for a particular package that it would then make one, but I didn't test to find out.
GWT compiles the Java source into Javascript, and names the files according to a hash of their contents. I'm getting a new set of files every compile, because the javascript contents are changing, even when I don't change the source at all.
The files are different for OBF and PRETTY output, but if I set it to DETAILED, they're no longer different every compile. In PRETTY, I can see that all/most of the differences between compiles are in the value parameters for typeId. For example, a funciton called initValues() is called with different values for it's typeId parameter.
In PRETTY mode, the differences you see are allocation of Java Classes to TypeIds. It's how GWT manages run time type checking. You'll notice a table at the bottom of each script essentially mapping each typeId to all compatible superclasses. This is how GWT can still throw ClassCastException in JavaScript (though you should run into this very rarely!).
In OBF mode, the differences are due to the allocation of minified function names.
In both cases, it's due to the order the compiler is processing the code. Some internal symbol tables might be using a non-ordered collection store symbols for processing. It can happen for lots of reasons.
As far as I know, GWT will compile a new version every time you compile it, this is a feature ;)
You can use ant to control it though, so that it only builds the GWT section of your application if it's actually changed:
http://wiki.shiftyjelly.com/index.php/GWT#Use_The_Power_of_Ant_to_Build_Changes_Only