Community
Participate
Working Groups
Build Identifier: M20110909-1335 I would like to have the ability to add a widget to a launch configuration tab which allows the choosing of a remote file or directory. This could be used to choose an executable, working directory, or other resource needed for a remote launch. Reproducible: Always Steps to Reproduce: N/A
Created attachment 210095 [details] Patch to add remote resource selector widget and supporting infrastructure This is quite a large patch. It follows along the lines of how the IRemoteFileProxy and IRemoteCommandLauncher work, adding a new extension point so that resource selectors for other filesystem types can be added relatively easily. In this patch, local- and RDT-based selectors are supported. Note that in order for this to work correctly, you must be using the HEAD of the PTP's 5_0 branch, as it contains a couple of minor bug fixes to get the RSE and Remote Tools resource selectors to work correctly.
Created attachment 210096 [details] Screen shot of example usage of the resource browser widget (3 instances) This is a screenshot from a Valgrind launcher I put together. The idea is to be very flexible about the locations of the source of the executable, where the executable is to be placed (if it is to be copied), and also the working directory on the same machine.
I just want to add that if you are interested in a video demo, I could put one together. I'm open to criticisms, suggestions, etc. Please let me know what you think.
(In reply to comment #3) > I just want to add that if you are interested in a video demo, I could put one > together. > > I'm open to criticisms, suggestions, etc. Please let me know what you think. Reviewing this right now.
(In reply to comment #3) > I just want to add that if you are interested in a video demo, I could put one > together. > > I'm open to criticisms, suggestions, etc. Please let me know what you think. Looks good, but I have a few questions/comments: 1. Doesn't seem to be a reference to the default Local File system proxy 2. It looks like a user needs to fill in a URI (not a path) so the label should perhaps be changed 3. Each selector should use the URI path in the text field to determine what the file system selector shows 4. Thus, a tool can fill in a default URI on creation (e.g. for the executable which it can find when the user right clicks on it). This might point to a remote project or a local project. The URI will set the combo box based on the schema (or lack there-of) unless there is no text in the field 5. Does the RDT select directory only deal with existing directories or can the user specify a new one? I assume that the file browser allows a way for the user to specify a new file in an existing directory. 6. You might as well call your schema id: RemoteResourceSelectorProxy (the last o is no savings and will lead to confusion from developers trying to use it).
(In reply to comment #5) > (In reply to comment #3) > > I just want to add that if you are interested in a video demo, I could put one > > together. > > > > I'm open to criticisms, suggestions, etc. Please let me know what you think. > > Looks good, but I have a few questions/comments: > > 1. Doesn't seem to be a reference to the default Local File system proxy Yes, you're right. This was a mistake. I originally had intended to treat the local file system selector the same as any remote one that was added via an extension, but then I messed up and went with the approach taken by your code where it treats the default proxy as a special case. I will fix this. > > 2. It looks like a user needs to fill in a URI (not a path) so the label > should perhaps be changed Good point. I'm a little concerned that seeing dialog box marked "URI" might scare people away, but you're right that that's what it is. > > 3. Each selector should use the URI path in the text field to determine > what the file system selector shows Yes, the selector should default to what shown in the dialog. I'll see if I can make that work. > > 4. Thus, a tool can fill in a default URI on creation (e.g. for the > executable which it can find when the user right clicks on it). > This might point to a remote project or a local project. The URI > will set the combo box based on the schema (or lack there-of) unless > there is no text in the field OK > > 5. Does the RDT select directory only deal with existing directories or can > the user specify a new one? I assume that the file browser allows > a way for the user to specify a new file in an existing directory. > I don't think it's handled in a uniform way across all of the different selector types. This is something we can request of the selector providers. In the mean time, users can edit the URI after browsing. > 6. You might as well call your schema id: RemoteResourceSelectorProxy (the > last o is no savings and will lead to confusion from developers trying > to use it). Oh, I found that there seems to be a limit on the length of these identifiers! I should have added a comment, as it was very hard to figure out what was going wrong. If I add the 'o', the identifier is somehow too long and will *not* show up in the extension selector gui. I will double check that I wasn't hallucinating when I made this change :-) Good catch, by the way!
Ok, I've addressed issues 1, 2, 3, and 6. It turns out I was hallucinating on (6)... when I went back and tried it again, I could not reproduce the problem I was seeing before. As for (4), because the binary parser is turned off for remote executables (it doesn't work when it's turned on anyway), you cannot right-click on an executable and create a launch config. The only thing you can do is select "Run As.." -> "Run configurations..." (or Debug/Profile configurations), and that does not create a new launcher, it just allows you to select an existing one, or click the * button to create a new one. If you create a new one, I don't know of a way to find out which file the use had right-clicked on to do the launch. I haven't addressed (5) yet. That may take a bit of time to get the create upstream fixes for the three existing browser types (local, RSE, RemoteTools), and get them accepted. I think the work-around of being able to type in a new path is probably good enough for now. I will post up the new widget implementation patch in a couple of minutes, but I can revise it again if you have some ideas about how to solve (4).
Created attachment 210419 [details] Add ResourceSelectorWidget patch (version 2) I wrote this patch myself and have permission from my employer (IBM Corp.) to submit it.
(In reply to comment #7) > Ok, I've addressed issues 1, 2, 3, and 6. It turns out I was hallucinating on > (6)... when I went back and tried it again, I could not reproduce the problem I > was seeing before. > > As for (4), because the binary parser is turned off for remote executables (it > doesn't work when it's turned on anyway), you cannot right-click on an > executable and create a launch config. The only thing you can do is select > "Run As.." -> "Run configurations..." (or Debug/Profile configurations), and > that does not create a new launcher, it just allows you to select an existing > one, or click the * button to create a new one. If you create a new one, I > don't know of a way to find out which file the use had right-clicked on to do > the launch. > Should this not work with local executables to be run remotely as it does for normal profile launches? The ProfileLaunchShortcut.java code has checks for what has been selected and passes it on to the launch or am I mistaken. > I haven't addressed (5) yet. That may take a bit of time to get the create > upstream fixes for the three existing browser types (local, RSE, RemoteTools), > and get them accepted. I think the work-around of being able to type in a new > path is probably good enough for now. > > I will post up the new widget implementation patch in a couple of minutes, but > I can revise it again if you have some ideas about how to solve (4). Regarding 5, so the end-user has to edit the URI created by the browser to add a new directory or file - correct? This is fine for everything but RSE. I would have thought you could extend your current browser and add a text widget for the additional directory segment or file name, however, another possibility might be to have the query stripped off and hidden from the user (i.e. not shown in the text window). A user doesn't have to worry about it then as they can't screw it up and only the callers will see it when they get the URI result. Does that seem reasonable?
(In reply to comment #9) > (In reply to comment #7) > > Ok, I've addressed issues 1, 2, 3, and 6. It turns out I was hallucinating on > > (6)... when I went back and tried it again, I could not reproduce the problem I > > was seeing before. > > > > As for (4), because the binary parser is turned off for remote executables (it > > doesn't work when it's turned on anyway), you cannot right-click on an > > executable and create a launch config. The only thing you can do is select > > "Run As.." -> "Run configurations..." (or Debug/Profile configurations), and > > that does not create a new launcher, it just allows you to select an existing > > one, or click the * button to create a new one. If you create a new one, I > > don't know of a way to find out which file the use had right-clicked on to do > > the launch. > > > > Should this not work with local executables to be run remotely as it does for > normal profile launches? It'd be nice if it did, but it doesn't. I verfied exactly why you get a different cascaded context menu when you right click on a remote executable file and select Profile As... (or Run As.. etc), as opposed to a local executable, but I have a heavy suspicion that it's because the files are not detected as executables. So actually, you can right-click on any file (e.g. a source file) in a project, select Profile As... and you'll get the same cascaded context menu. > The ProfileLaunchShortcut.java code has checks for > what has been selected and passes it on to the launch or am I mistaken. You apparently know more about how that works than I do. I'll have a look at that; thanks for the tip. > > > I haven't addressed (5) yet. That may take a bit of time to get the create > > upstream fixes for the three existing browser types (local, RSE, RemoteTools), > > and get them accepted. I think the work-around of being able to type in a new > > path is probably good enough for now. > > > > I will post up the new widget implementation patch in a couple of minutes, but > > I can revise it again if you have some ideas about how to solve (4). > > Regarding 5, so the end-user has to edit the URI created by the browser to add > a new directory or file - correct? He can either edit in the URI field, or in the file browser widget's path field before he clicks its OK button. I just checked, and the latter works with the RemoteTools file browser, but not the RSE one. :-( > > This is fine for everything but RSE. I would have thought you could extend > your current browser and add a text widget for the additional directory segment > or file name, The file browser widget is not something I wrote. I use the browser provided by RDT and the one for local files. It hadn't occurred to me that I could extend those browsers to add a "new file" or "new directory" ability. Interesting idea. > however, another possibility might be to have the query stripped > off and hidden from the user (i.e. not shown in the text window). > A user > doesn't have to worry about it then as they can't screw it up and only the > callers will see it when they get the URI result. Does that seem reasonable? Oh, I was a little confused at first what you meant by query. You mean the query part of the URL. On RemoteTools URI's, the query field is empty, so I hadn't thought of that issue of editing it. So you're saying that the field would have some hidden content and some exposed content and we'd glue the two pieces together to form the actual URI to use. Hmm... I like the idea of being able to see and edit the entire URI, but I can also see your point. I'll think about it some more. If I were able to create a file browser that's capable of creating new directories and files (Remote Tools and Local already can, RSE currently cannot), do you think that would be good enough? That way you wouldn't ever have to modify the resulting URI for the case of new file or directory.
A correction to my last comment: I said, "I verified ...", but I meant to write "I haven't verified ..."
Just an update. I've been having a lot of difficulty debugging this launch shortcut code. Whenever I set a breakpoint in ContextualLaunchAction.fillMenu, my entire GUI session locks up... every window in my session stops taking input. My guess is that method must be on the thread of a Gnome window manager callout, and simply doesn't allow any windowing event to occur until that method returns. At first I thought it was just a fluke, or that I had run out of virtual memory, etc... so it took awhile to come up with this hypothesis. I did verify that the shortcut menu items are not showing up because the none of the properties that are OR'd together are being met. One of them is that the object is an "IBinary" type, which says that it checks whether the selected object is a binary by running the designated binary parser on it. For remote C/C++ projects, we don't have any binary parser enabled. I was also able to hot-wire the shortcut to show up by making sure its enablement expression was always true. However, this makes *all* files show up as profile-able.
(In reply to comment #12) > Just an update. I've been having a lot of difficulty debugging this launch > shortcut code. Whenever I set a breakpoint in ContextualLaunchAction.fillMenu, > my entire GUI session locks up... every window in my session stops taking > input. My guess is that method must be on the thread of a Gnome window manager > callout, and simply doesn't allow any windowing event to occur until that > method returns. At first I thought it was just a fluke, or that I had run out > of virtual memory, etc... so it took awhile to come up with this hypothesis. > > I did verify that the shortcut menu items are not showing up because the none > of the properties that are OR'd together are being met. One of them is that > the object is an "IBinary" type, which says that it checks whether the selected > object is a binary by running the designated binary parser on it. For remote > C/C++ projects, we don't have any binary parser enabled. I was also able to > hot-wire the shortcut to show up by making sure its enablement expression was > always true. However, this makes *all* files show up as profile-able. You could add a test which is added to the UI menu tests. You need to use the org.eclipse.core.expressions.propertyTesters extension to add a new property to test and you can back up that test with a class to run. The class could parse a Makefile, look for a.out on Unix/Linux/etc.., *.exe on Windows, etc... and return true in the case where there is an executable. Failing that, you could always look at remote binary parsing like the remote indexer.
(In reply to comment #13) > (In reply to comment #12) > > You could add a test which is added to the UI menu tests. You need to use the > org.eclipse.core.expressions.propertyTesters extension to add a new property to > test and you can back up that test with a class to run. The class could parse > a Makefile, look for a.out on Unix/Linux/etc.., *.exe on Windows, etc... and > return true in the case where there is an executable. Parsing a Makefile would be a non-trivial thing to do, I think. Just because something's a target, doesn't make it an executable. Looking for a.out is a no-go too, because it's quite unusual, actually for the executable to be named a.out. Managed makefile projects, for example, always generate an executable with a name that's the same as the project, placed in the subdirectory of the active build config. I suppose that for a managed project we could look for a file named the same as the project in the active build configuration subdirectory (e.g. Debug). For standard makefile projects (and Autotools, too), we would have to resort to looking for binaries somehow. > > Failing that, you could always look at remote binary parsing like the remote > indexer. I was hoping to avoid that. I don't know how hard that would be to do, to be honest, but it may be the best bet. - Corey
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > > You could add a test which is added to the UI menu tests. You need to use the > > org.eclipse.core.expressions.propertyTesters extension to add a new property to > > test and you can back up that test with a class to run. The class could parse > > a Makefile, look for a.out on Unix/Linux/etc.., *.exe on Windows, etc... and > > return true in the case where there is an executable. > > Parsing a Makefile would be a non-trivial thing to do, I think. Just because > something's a target, doesn't make it an executable. > > Looking for a.out is a no-go too, because it's quite unusual, actually for the > executable to be named a.out. > > Managed makefile projects, for example, always generate an executable with a > name that's the same as the project, placed in the subdirectory of the active > build config. I suppose that for a managed project we could look for a file > named the same as the project in the active build configuration subdirectory > (e.g. Debug). > > For standard makefile projects (and Autotools, too), we would have to resort to > looking for binaries somehow. > > > > > Failing that, you could always look at remote binary parsing like the remote > > indexer. > > I was hoping to avoid that. I don't know how hard that would be to do, to be > honest, but it may be the best bet. > > - Corey The point I was trying to make is that you "can" do this with a tester. The logic is up to you. The tester itself can steal logic from existing binary parsers to determine if you have a legit file or you can fake it. You aren't interested in actually parsing the file as much as designating it as a potential binary for profiling. For example, you might create a tester that looks for a valid ELF header in a file when the remote file is on Linux/OSX/etc.... You might look for a.out as a quick check or *.exe on Windows systems. If someone designates a regular file as a.out or *.exe in these instances, too bad, it won't execute and they will get a failure.
There are two cases, I think, and one is quite a lot easier than the other one, especially performance-wise, to implement. 1) The user right-clicks on a file he believes to be an executable. In this case, we could write a simple property class that runs /usr/bin/file <file> or /usr/bin/objdump --file-headers <file> or /usr/bin/readelf --file-header <file> on the remote machine, and then parses the text output looking for evidence that <file> is an executable. Actually, looking at readelf, the output would be easy to parse because there's a line that looks like this: Type: EXEC (Executable file) So this would be doable and should have decent performance. 2) The user right-clicks on a project that he knows contains an executable. Now Eclipse has to try to find a file on the remote machine. Perhaps one way would be to run /usr/bin/find in some clever way to find the executable files. I'm looking into that now. In either case, maybe I can at least do 1) as a first cut, and work on 2) later.
Better yet, I found this command: /bin/find -type f -executable -exec /usr/bin/file --mime '{}' \; | grep 'x-executable; charset=binary' here: http://unix.stackexchange.com/questions/1484/how-to-find-binary-executables-within-a-directory Looking at the man page for find, I found (forgive the pun) that by replacing "\;" with "\+", the performance would improve by about 20% because more than one file can be fed into "file" at a time. Running this command on the entire linux kernel source tree took 265ms on a Power6 machine, and 226ms on my laptop, once the files were loaded into the buffer. The linux kernel tree is a pretty representative "large project" containing ~45,000 files. So now to be resolved is to figure out which binary to choose if there is more than one in the find result.
(In reply to comment #8) > Created attachment 210419 [details] > Add ResourceSelectorWidget patch (version 2) > > I wrote this patch myself and have permission from my employer (IBM Corp.) to > submit it. Comments: 1. Any new plug-ins must have an about.html license file and that file must appear in the build.properties binary distribution. 2. The plug-in name and vendor should be % NLS strings that appear in the plugin.properties. You need to manually adjust the MANIFEST.MF file to use these. See org.eclipse.linuxtools.cdt.autotools.core for details. 3. The plug-ins should be marked (Incubation) for the mean-time as you will find with the Autotools plug-ins. 4. Your Ui plug-in should not have a name of Ui. Something a bit more expansive e.g. Profiling Launch UI Plug-in. Follow the same case as is done in the Autotools UI plug-in. Other than that, looks good. We can deal with nits later.
Created attachment 211535 [details] Minor fixes on profiling.launch.ui plugins Fixes proposed by Jeff on previous comment.
(In reply to comment #19) > Created attachment 211535 [details] > Minor fixes on profiling.launch.ui plugins > > Fixes proposed by Jeff on previous comment. Thanks for making these changes. A few minor comments to be addressed from the changes and I approve. 1. Please add the plugin.properties file to the list of binary includes in build.properties. 2. Please add the following line to the MANIFEST.MF files of the plug-ins you are adding that use plugin.properties: Bundle-Localization: plugin 3. You need to make the version numbers less than 1.0.0 for the new plug-ins. I suggest 0.9.2 and remember to change the pom.xml files to match. My apologies for not spotting this earlier.
Created attachment 211570 [details] Minor fixes on profiling.launch.ui plugins
(In reply to comment #21) > Created attachment 211570 [details] > Minor fixes on profiling.launch.ui plugins Great, thanks for doing this. Approved for commit.
Created attachment 211586 [details] Minor fixes on profiling.launch.ui plugins (version 3) Forgot to fix the version in the "Require-Bundle" sessions of MANIFEST.MF files. I've ended up removing the version requirement, since it's not really necessary at this point.
Jeff, you approved, but you didn't commit that. Can I do it? And what about the rafaelmt patches? And do they need to state that the patch is epl and that they did the patches themselves? Do they need to do it for every patch?
(In reply to comment #24) > Jeff, you approved, but you didn't commit that. Can I do it? > And what about the rafaelmt patches? > And do they need to state that the patch is epl and that they did the patches > themselves? Do they need to do it for every patch? Hold off while I get clarification on the iplog process. We have already submitted our iplog for 1.0. I had expected you to have checked in these patches due to their size (it required a committer from the same company because they are >250 lines).
Created attachment 216397 [details] Minor fixes on profiling.launch.ui plugins Original patch won't apply cleanly anymore, fixing plugin version and adding org.eclipse.linuxtools.profiling.launch.ui to the Maven build.
Pushed to master branch in commits 592a9da0fbdc42c6c7d0dad561c19af5080dd511 and 994a46cba9a92b3f657f5d9cb6447bde80c12725. Not pushed to stable-1.0, so it won't be in the 1.0 release.
