Eclipse plugin development: Disabling Java Structure Compare when comparing files? - java

I used the following code to compare two files:
CompareConfiguration config = new CompareConfiguration();
config.setRightEditable(false);
config.setLeftEditable(false);
config.setLeftLabel("Klasse 1");
config.setRightLabel("Klasse 2");
config.setProperty(CompareConfiguration.USE_OUTLINE_VIEW, Boolean.FALSE);
CompareUI.openCompareEditorOnPage(new EditorInput(config, file1, file2), page);
This works and a compare editor is opened. But unfortunately, the Java Source Compare and the Java Structure Compare is openend. I want to permanently disable Java Structure Compare. How can I do that?

Windows -> Preferences -> General -> Compare/Patch
un-check 'Open structure compare automatically'.
Apply and Close.

Try using a CompareEditorInput (instead of EditorInput) and then setting the Configuration property of that to a CompareConfiguration which you can set the set a preference store using one of it's constructors. The ComparePreferences has a preference of doing the structure compare (or not presumably).

Related

How to create a tensorflow serving client for the 'wide and deep' model?

I've created a model based on the 'wide and deep' example (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/examples/learn/wide_n_deep_tutorial.py).
I've exported the model as follows:
m = build_estimator(model_dir)
m.fit(input_fn=lambda: input_fn(df_train, True), steps=FLAGS.train_steps)
results = m.evaluate(input_fn=lambda: input_fn(df_test, True), steps=1)
print('Model statistics:')
for key in sorted(results):
print("%s: %s" % (key, results[key]))
print('Done training!!!')
# Export model
export_path = sys.argv[-1]
print('Exporting trained model to %s' % export_path)
m.export(
export_path,
input_fn=serving_input_fn,
use_deprecated_input_fn=False,
input_feature_key=INPUT_FEATURE_KEY
My question is, how do I create a client to make predictions from this exported model? Also, have I exported the model correctly?
Ultimately I need to be able do this in Java too. I suspect I can do this by creating Java classes from proto files using gRPC.
Documentation is very sketchy, hence why I am asking on here.
Many thanks!
I wrote a simple tutorial Exporting and Serving a TensorFlow Wide & Deep Model.
TL;DR
To export an estimator there are four steps:
Define features for export as a list of all features used during estimator initialization.
Create a feature config using create_feature_spec_for_parsing.
Build a serving_input_fn suitable for use in serving using input_fn_utils.build_parsing_serving_input_fn.
Export the model using export_savedmodel().
To run a client script properly you need to do three following steps:
Create and place your script somewhere in the /serving/ folder, e.g. /serving/tensorflow_serving/example/
Create or modify corresponding BUILD file by adding a py_binary.
Build and run a model server, e.g. tensorflow_model_server.
Create, build and run a client that sends a tf.Example to our tensorflow_model_server for the inference.
For more details look at the tutorial itself.
Just spent a solid week figuring this out. First off, m.export is going to deprecated in a couple weeks, so instead of that block, use: m.export_savedmodel(export_path, input_fn=serving_input_fn).
Which means you then have to define serving_input_fn(), which of course is supposed to have a different signature than the input_fn() defined in the wide and deep tutorial. Namely, moving forward, I guess it's recommended that input_fn()-type things are supposed to return an InputFnOps object, defined here.
Here's how I figured out how to make that work:
from tensorflow.contrib.learn.python.learn.utils import input_fn_utils
from tensorflow.python.ops import array_ops
from tensorflow.python.framework import dtypes
def serving_input_fn():
features, labels = input_fn()
features["examples"] = tf.placeholder(tf.string)
serialized_tf_example = array_ops.placeholder(dtype=dtypes.string,
shape=[None],
name='input_example_tensor')
inputs = {'examples': serialized_tf_example}
labels = None # these are not known in serving!
return input_fn_utils.InputFnOps(features, labels, inputs)
This is probably not 100% idiomatic, but I'm pretty sure it works. For now.

Creating a new Java project

I am able to create a default project in PDE just like mentioned here.
However I want to know how to create a Java project. How can I do that?
As a minimum you need to add the Java project nature to the project you create. Use something like:
private void addNatureToProject(IProject proj, String natureId, IProgressMonitor monitor) throws CoreException
{
IProjectDescription description = proj.getDescription();
String[] prevNatures = description.getNatureIds();
String[] newNatures = new String[prevNatures.length + 1];
System.arraycopy(prevNatures, 0, newNatures, 0, prevNatures.length);
newNatures[prevNatures.length] = natureId;
description.setNatureIds(newNatures);
proj.setDescription(description, monitor);
}
The nature id for a Java project is 'org.eclipse.jdt.core.javanature' (also in the JavaCore.NATURE_ID constant).
Note that this does not add the various builders that are normally used in a Java project. The IProjectDescription.setBuildSpec method adds those in a similar way. Create a command for the build spec with:
ICommand command = description.newCommand();
command.setBuilderName(builderID);
where 'builderId' is 'org.eclipse.jdt.core.javabuilder' for the main Java builder (JavaCore.BUILDER_ID constant).
All this information is stored in the '.project' file in the project root folder. This is an XML file which you can look at to see the set up of existing projects.
Window->Open Perspective->Java
then
File->New->Java Project (you may have to go via "Project..." to get to the "Java Project" option)
Please refer to New Project Creation Wizards
On the Plug-in Project page, use com.example.helloworld as the name
for your project and check the box for Create a Java project (this
should be the default). Leave the other settings on the page with
their default settings and then click Next to accept the default
plug-in project structure.

How to do code format switching in eclipse?

A)
public class SomeClass
{
private SomeClass()
{
}
public String someMethod()
{
return "";
}
}
B)
public class SomeOtherClass{
private SomeOtherClass(){
}
public String someOtherMethod(){
return "";
}
}
I have joined a new team and will be working on a project which follows the A) convention. However, I have always been the B) java style person and am way more comfortable with B).
1)On the checked out code, is there a way I could convert the java code style in my eclipse to B)
2)And also ensure the project->Team->Synch with Repo ignores this style change when checking for updates ?
3)Before comitting, I want to switch the code back to the commonly followed style and check it in. I synch for changes every morning and commit changes throughout the day.
Is creating a new profile in the preferences->code style->Formatter the only way ? I also looked at http://astyle.sourceforge.net/ but I am somehow confident there is a simpler eclipse solution to this. How could I achieve this in the simplest possible way ?
I am using eclipse kepler
Work flow:
In Windows > Preferences > Java > Editors Save Actions deselect formatting on save.
Check out code.
Clean up your code(Right click on project go to Source > Clean up. Note this works on project level but not on working set, so you have to do it on each and every project) with your Formatter(B) profile enabled.
In Windows > Preferences > Java > Editors Save Actions select formatting on save and start working.
Same as step 1.
Same as 3 but with formatter profile A.
Commit the code.
These steps can be automated with Ant/Maven script(?) or by developing your own eclipse plug-in.
On sync comparator will NOT ignore style change. IMHO there is no escape. Clean up before sync is only the go.
In Git SCM there are some commit and checkout hooks but I haven't explored on this.

How do I programmatically change the Eclipse CDT tool settings for a file?

I want to programmatically (from a plugin) change the "Other flags" field in the Miscellaneous settings in the Tool Settings tab for an individual file in a CDT managed build project. (See this Eclipse documentation page for a screenshot and brief description of how this change would be made using the UI.)
Note: I've updated this twice now as I approach a solution. But instead of adding an update onto the end (as I do for shorter questions), I'm revising the entire question. If it helps to see the breadcrumbs leading to where I am now, you can read the history.
The following code will result in settings written to the .cproject file (I'll go into detail on that below), but when I open the Properties dialog for the file, and click on C/C++ Build->Settings and then Miscellaneous, the changes do not appear in the "Other flags" field (as they do when I make changes using the dialog).
IWorkbench workbench = PlatformUI.getWorkbench();
IWorkbenchWindow workbenchwindow = workbench.getActiveWorkbenchWindow();
IWorkbenchPage workbenchpage = workbenchwindow.getActivePage();
IEditorPart editorpart = workbenchpage.getActiveEditor();
IEditorInput editorinput = editorpart.getEditorInput();
IResource file = ((IFileEditorInput)editorinput).getFile();
IProject project = file.getProject();
IManagedBuildInfo buildInfo = ManagedBuildManager.getBuildInfo(project);
IConfiguration[] configurations = buildInfo.getManagedProject().getConfigurations();
IConfiguration conf = configurations[0];
IFileInfo fileInfo = conf.createFileInfo(file.getFullPath());
ITool[] tools = fileInfo.getTools();
ITool tool = tools[0];
IOption option = tool.getOptionById("my.gnu.compiler.misc.other");
String oldOptionValue = option.getDefaultValue().toString();
String newOptionValue = oldOptionValue + " -eg";
ManagedBuildManager.setOption(fileInfo, tool, option, newOptionValue);
ManagedBuildManager.saveBuildInfo(project, true);
I looked at the differences between the .cproject file where I changed the tool settings manually, and in a different .cproject file after running the above code. Below are the pertinent bits from each.
Here is the XML from the .cproject file where the tool settings were changed manually:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?fileVersion 4.0.0?><cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
<storageModule moduleId="org.eclipse.cdt.core.settings">
<cconfiguration id="com.company.product.toolchain.configuration.changed.1964078554">
...
<storageModule moduleId="cdtBuildSystem" version="4.0.0">
<configuration artifactName="${ProjName}" buildProperties="" cleanCommand="rm -f" description="" id="com.company.product.toolchain.configuration.changed.1964078554" name="changed" parent="com.company.product.toolchain.configuration.changed">
...
<fileInfo id="com.company.product.toolchain.configuration.changed.1964078554.915152327" name="code.cpp" rcbsApplicability="disable" resourcePath="src/code.cpp" toolsToInvoke="com.company.product.toolchain.compiler.1643348654.1411455203">
<tool id="com.company.product.toolchain.compiler.1643348654.1411455203" name="Company GNU compilers" superClass="com.company.product.toolchain.compiler.1643348654">
<option id="company.gnu.compiler.misc.other.789167779" name="Other flags" superClass="company.gnu.compiler.misc.other" value="-c -fmessage-length=0 -eg" valueType="string"/>
<inputType id="com.company.product.toolchain.cxxinputtype.877052163" name="C++ Input" superClass="com.company.product.toolchain.cxxinputtype"/>
<inputType id="com.company.product.toolchain.cinputtype.1390394900" name="C input" superClass="com.company.product.toolchain.cinputtype"/>
</tool>
</fileInfo>
...
And here is the XML from the .cproject file where they were changed programmatically:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?fileVersion 4.0.0?><cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
<storageModule moduleId="org.eclipse.cdt.core.settings">
<cconfiguration id="com.company.product.toolchain.configuration.changed.2057644715">
...
<storageModule moduleId="cdtBuildSystem" version="4.0.0">
<configuration artifactName="${ProjName}" buildProperties="" cleanCommand="rm -f" description="" id="com.company.product.toolchain.configuration.changed.2057644715" name="changed" parent="com.company.product.toolchain.configuration.changed">
...
<fileInfo id="com.company.product.toolchain.configuration.changed.2057644715./test3/src/code.cpp" name="code.cpp" rcbsApplicability="disable" resourcePath="test3/src/code.cpp" toolsToInvoke="com.company.product.toolchain.compiler.1482360042.1005761865">
<tool id="com.company.product.toolchain.compiler.1482360042.1005761865" name="Company GNU compilers" superClass="com.company.product.toolchain.compiler.1482360042">
<option id="company.gnu.compiler.misc.other.999025984" superClass="company.gnu.compiler.misc.other" value="-c -fmessage-length=0 -eg" valueType="string"/>
<inputType id="com.company.product.toolchain.cxxinputtype.1253686787" name="C++ Input" superClass="com.company.product.toolchain.cxxinputtype"/>
<inputType id="com.company.product.toolchain.cinputtype.1141524787" name="C input" superClass="com.company.product.toolchain.cinputtype"/>
</tool>
</fileInfo>
...
Aside from the numbers, which I assume are some kind of GUIDs, there are three differences:
For some reason, the id attribute of the fileInfo element in the programmatic changes contains the path to the file, including the project name: id="com.company.product.toolchain.configuration.changed.2057644715./test3/src/code.cpp"
The resourcePath attribute value of the fileInfo element contains the project name, only in the programmatic changes: resourcePath="test3/src/code.cpp".
The option element in the fileInfo element as a name attribute (name="Other flags") that matches the field in the dialog, only in the manual changes.
I'm guessing that one or all of these differences are preventing my programmatic changes from being "compatible" with the manual ones (so they show up in the dialog). I'm trying to figure out how to create the IFileInfo, IOption (and ITool?) objects without causing these differences. I'm trying to find how these objects are created for the dialog, but haven't yet.
Any suggestions appreciated.
Update: I got an answer from Doug Schaefer to my question on the cdt-dev mailing list. He suggested I "stick breakpoints in places and see how the UI does it." I wrote back:
I have been doing that. I set a breakpoint in org.eclipse.cdt.managedbuilder.core.ManagedBuildManager.setOption(IResourceInfo, IHoldsOptions, IOption, String) and it triggers when I open the Properties dialog for a file, expand "C/C++ Build", select "Settings", and then "Miscellaneous" in the Tool Settings tab. I can see the arguments, and presumably if I can call setOption with the same arguments I'll get the same results in the .cproject file. But I haven't been able to figure out how to do that. Do you have any suggestions for how I figure out where those objects are created so I can set breakpoints there?
Update #2: Vladimir's answer solved my problem. While I was more concerned with difference number 3 in the two .cproject file fragments above, the key was difference 2 and the inclusion of the project name in difference 1.
I changed the code to create the IFileInfo object to:
IFileInfo fileInfo = conf.createFileInfo(file.getProjectRelativePath());
...which resulted in the fileInfo element not having the project name:
<fileInfo id="com.company.product.toolchain.configuration.changed.838214286.src/code.cpp" name="code.cpp" rcbsApplicability="disable" resourcePath="src/code.cpp" toolsToInvoke="com.company.product.toolchain.compiler.2027651356.1970239371">
...and most importantly, resulted in the programmatic changes showing up in the "Other flags" field in the Miscellaneous settings in the Tool Settings tab for the individual file. (I guess the other differences in the .cproject files are not important.)
I suspect there might be problem in you IFileInfo creation. Here's the code that we use to obtain IResourceInfo for a translation unit to set per-file options:
protected IResourceInfo getResourceInfo(ITranslationUnit translationUnit, ICProjectDescription prjDescription) {
ICProject cProject = translationUnit.getCProject();
if (cProject != null) {
ICConfigurationDescription cfgDescription = prjDescription.getActiveConfiguration();
IConfiguration configuration = ManagedBuildManager.getConfigurationForDescription(cfgDescription);
IPath projectPath = translationUnit.getResource().getProjectRelativePath();
IResourceInfo ri = configuration.getResourceInfo(projectPath, true);
if (ri == null) {
ri = configuration.createFileInfo(projectPath);
}
return ri;
}
return null;
}
Note this line, in particular:
IPath projectPath = translationUnit.getResource().getProjectRelativePath();
Maybe, all you need is to use getProjectRelativePath() in your code?
Generally you can set an option to different objects, i.e. a configuration (if you want the option to apply to all files of a given type in a configuration) or a resource (if you want the option to apply only to the files in a folder or to a single file).
setOption() has multiple prototypes; it looks like you used the one that applies to a file resource.
In my GNU ARM Eclipse Plug-in I successfully used another version:
setOption(IConfiguration config, IHoldsOptions holder, IOption option, String value)
You can see an example in this file, line 583.
I guess this will work in your case too.

Programmatically analyze java heap dump file

I want to write a program (preferably in java) that will parse and analyze a java heap dump file (created by jmap). I know there are many great tools that already do so (jhat, eclipse's MAT, and so on), but I want to analyze the heap from a specific perspective to my application.
Where can I read about the structure of the heap dump file, examples how to read it, and so on? Didn't find anything useful searching for it...
Many thanks.
The following was done with Eclipse Version: Luna Service Release 1 (4.4.1) and Eclipse Memory Analyzer Version 1.4.0
Programmatically Interfacing with the Java Heap Dump
Environment Setup
In eclipse, Help -> Install New Software -> install Eclipse Plug-in Development Environment
In eclipse, Window -> Preferences -> Plug-in Development -> Target Platform -> Add
Nothing -> Locations -> Add -> Installation
Name = MAT
Location = /path/to/MAT/installation/mat
Project Setup
File -> new -> Other -> Plug-in Project
Name: MAT Extension
Next
Disable Activator
Disable Contributions to the UI
Disable API analysis
Next
Disable template
Finish
Code Generation
Open plugin.xml
Dependencies -> Add
select org.eclipse.mat.api
Extensions -> Add
select org.eclipse.mat.report.query
right click on report.query -> New
Name: MyQuery
click "impl" to generate the class
Implementing IQuery
#CommandName("MyQuery") //for the command line interface
#Name("My Query") //display name for the GUI
#Category("Custom Queries") //list this Query will be put under in the GUI
#Help("This is my first query.") //help displayed
public class MyQuery implements IQuery
{
public MyQuery{}
#Argument //snapshot will be populated before the call to execute happens
public ISnapshot snapshot;
/*
* execute : only method overridden from IQuery
* Prints out "My first query." to the output file.
*/
#Override
public IResult execute(IProgressListener arg0) throws Exception
{
CharArrayWriter outWriter = new CharArrayWriter(100);
PrintWriter out = new PrintWriter(outWriter);
SnapshotInfo snapshotInfo = snapshot.getSnapshotInfo();
out.println("Used Heap Size: " + snapshotInfo.getUsedHeapSize());
out.println("My first query.")
return new TextResult(outWriter.toString(), false);
}
}
ctrl+shift+o will generate the correct "import" statements.
Custom queries can be accessed within the MAT GUI by accessing the toolbar's "Open Query Browser" at the top of the hprof file you have opened.
The ISnapshot interface
The most important interface one can use to extract data from a heap dump is ISnapshot. ISnapshot represents a heap dump and offers various methods for reading object and classes from it, getting the size of objects, etc…
To obtain an instance of ISnapshot one can use static methods on the SnapshotFactory class. However, this is only needed if the API is used to implement a tool independent of Memory Analyzer. If you are writing extensions to MAT, then your coding will get an instance corresponding to an already opened heap dump either by injection or as a method parameter.
Reference
Built in Command Line Utility
If you're looking to have a program generate the usual reports, there is a command line utility called ParseHeapDump available with any download of Eclipse's MAT tool. You'll be able to get useful html dumps of all the information MAT stores.
> ParseHeapDump <heap dump> org.eclipse.mat.api:suspects org.eclipse.mat.api:top_components org.eclipse.mat.api:overview #will dump out all general reports available through MAT
Hopefully this is enough information to get you started.
I'm not familiar with jhat, but Eclipse's MAT is open source. Their SVN link is available, perhaps you could look through that for their parser, perhaps even use it.

Categories