|
From: Naba K. <kh...@gm...> - 2005-05-03 05:33:19
|
Hi all, We have been forwarded this email in our mailing list and find it interesting. > This type of IDE integration is something that is of great interest to > us at LANL. We have launched a project called the Eclipse Parallel > Tools Platform (see http://www.eclipse.org/ptp/). Valgrind-based tools > being integrated into this environment would be of interest to us. To > start, doing an Eclipse Rich Client Interface for them would be great. > This would allow them to be used as standalone tools with GUIs or used > as plugins to the Eclipse IDE. We're always looking for folks who are > interested in collaborating on projects like this with us. If this > would be of interest to you, please contact me directly. We would definitely like to have such an integration and I will give a brief idea of how such integration is possible. However, we are rather resource limited and hence will not be in a position to implement it. If there are people interested in such integration, we will be glad to offer help with the implementation. There are basically three levels of integration currently possible with Anjuta (2.0). 1) The classic "run and show stdout/stderr in message pane": This is the most basic way of 'integration' and doesn't even need an implementation. The user can simply set up the tool in preferences. Apart from showing the outputs, there is no interaction between Anjuta and the tool. However, I believe, this is not the kind of integration you are expecting. 2) CLI interface: If valgrind supports some kind of CLI interface (ala gdb), and I am not sure if such interface is even required for valgrind, Anjuta can have a plugin that proxies valgrind's CLI interface to IDE's GUI (menus and windows). This is actually a very complicated integration and rather prone to breakages. If full blown CLI is not required for valgrind, at least having a machine parsable outputs (e.g. xml) could make it easier. 3) API interface: This is the best and most preferred way for the integration. In this case, valgrind offers a library that an Anjuta plugin proxies to the IDE's internal interfaces. In case(2) and case(3), the integration requires developing an Anjuta plugin, but that is the least difficult part since it will hardly span more than one source file. I hope someone wishing to implementation such an integration would find it useful. Thanks. Regards, -Naba |
|
From: Nicholas N. <nj...@cs...> - 2005-05-04 02:12:14
|
On Tue, 3 May 2005, Naba Kumar wrote: >>> 3) API interface: This is the best and most preferred way for >>> the integration. In this case, valgrind offers a library that >>> an Anjuta plugin proxies to the IDE's internal interfaces. >> >> Out of interest, what does the API look like? Do you have a webpage >> describing it? >> > I think you misunderstood me. I was suggesting to have a library in > valgrind (e.g libvalgrind or something) that will give the necessary API > to IDE developers. So what would that look like? N |
|
From: Josef W. <Jos...@gm...> - 2005-05-04 10:20:33
|
On Wednesday 04 May 2005 08:07, Naba Kumar wrote: > > Here's how I imagine the KDevelop plug-in works: you invoke Valgrind > > somehow, and KDevelop works out what options to pass to Valgrind, > > then runs Valgrind (and the user program under it), then collects > > the output somehow, parses it, and presents it to the programmer > > in the IDE somehow. > > There is nothing wrong in doing it the hard way, except that every IDE > would be implementing it (which is a waste to begin with) and all of > them would be struggling to maintain their parsers. Ask any developer > who has maintained such CLI output (meant for human readability) parsers > for a reasonable time how much fun it is. You can start by copying the parser from KDevelop or contact them for joined efforts, and make the library with the API you propose yourself, basing it on valgrind-listener; this is part of Valgrind itself, a redirection utility for valgrinds output. It is perfect to put the CLI parser in there, and provide a library instead. If the API is simple and easy enough, the patched valgrind-listener (as a library, and with the CLI parser) can be put back into Valgrind. And if the parser is part of the valgrind package, I am sure that it will be kept up to date for CLI changes. I think this is even better than the "displayer plugin". No idea if this works bidirectional (e.g. for attaching to gdb). > The whole point of the suggestion is to make life easier for the IDE > developers at the cost of offering some helpful API from valgrind. Even > if full blown library interface is not feasible, as I mentioned earlier, > having some sort of predictable and machine-readable output from > valgrind would still be useful. > > Thanks. > > Regards, > -Naba > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: David F. <dav...@bl...> - 2005-05-04 10:58:40
|
It might be worthwhile perusing the gdb <-> DDD interface. --david |
|
From: Jeffrey S. <fe...@no...> - 2005-05-04 15:43:42
|
the parser in Alleyoop is pretty robust and supports all past versions of valgrind from 1.0's format up through 2.4 (at least in CVS... forget if I've made a release supporting 2.4 yet or not) it's also an incremental state parser so should be relatively nice for other apps to use (e.g. no blocking the ui, etc). Jeff On Wed, 2005-05-04 at 12:15 +0200, Josef Weidendorfer wrote: > On Wednesday 04 May 2005 08:07, Naba Kumar wrote: > > > Here's how I imagine the KDevelop plug-in works: you invoke Valgrind > > > somehow, and KDevelop works out what options to pass to Valgrind, > > > then runs Valgrind (and the user program under it), then collects > > > the output somehow, parses it, and presents it to the programmer > > > in the IDE somehow. > > > > There is nothing wrong in doing it the hard way, except that every IDE > > would be implementing it (which is a waste to begin with) and all of > > them would be struggling to maintain their parsers. Ask any developer > > who has maintained such CLI output (meant for human readability) parsers > > for a reasonable time how much fun it is. > > You can start by copying the parser from KDevelop or contact them for joined > efforts, and make the library with the API you propose yourself, basing it on > valgrind-listener; this is part of Valgrind itself, a redirection utility for > valgrinds output. It is perfect to put the CLI parser in there, and provide a > library instead. > If the API is simple and easy enough, the patched valgrind-listener (as a > library, and with the CLI parser) can be put back into Valgrind. And if the > parser is part of the valgrind package, I am sure that it will be kept up to > date for CLI changes. > I think this is even better than the "displayer plugin". > > No idea if this works bidirectional (e.g. for attaching to gdb). > > > The whole point of the suggestion is to make life easier for the IDE > > developers at the cost of offering some helpful API from valgrind. Even > > if full blown library interface is not feasible, as I mentioned earlier, > > having some sort of predictable and machine-readable output from > > valgrind would still be useful. > > > > Thanks. > > > > Regards, > > -Naba > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > Get your fingers limbered up and give it your best shot. 4 great events, 4 > > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <nj...@cs...> - 2005-05-03 12:31:09
|
On Tue, 3 May 2005, Naba Kumar wrote: > 1) The classic "run and show stdout/stderr in message pane": > This is the most basic way of 'integration' and doesn't even > need an implementation. The user can simply set up the tool in > preferences. Apart from showing the outputs, there is no > interaction between Anjuta and the tool. However, I believe, > this is not the kind of integration you are expecting. > > 2) CLI interface: If valgrind supports some kind of CLI interface > (ala gdb), and I am not sure if such interface is even required > for valgrind, Anjuta can have a plugin that proxies valgrind's > CLI interface to IDE's GUI (menus and windows). This is actually > a very complicated integration and rather prone to breakages. > If full blown CLI is not required for valgrind, at least > having a machine parsable outputs (e.g. xml) could make it easier. Valgrind does not support a CLI interface. Its output is currently text only, albeit fairly structured text that should be easy to parse. We have thought about possibilities for more flexible output, ie. by having replacing a "displayer" module/program that is given the raw outputs and displays them appropriately (eg. normally, or in XML, or graphically) but no work has been done on this. > 3) API interface: This is the best and most preferred way for > the integration. In this case, valgrind offers a library that > an Anjuta plugin proxies to the IDE's internal interfaces. Out of interest, what does the API look like? Do you have a webpage describing it? > In case(2) and case(3), the integration requires developing > an Anjuta plugin, but that is the least difficult part since > it will hardly span more than one source file. Yes. And unless a very general mechanism (such as the "displayer" module) can be implemented in Valgrind, I think this is the right way to do it: have extra code in Anjuta to deal with Valgrind, rather than extra code in Valgrind to deal with Anjuta. > I hope someone wishing to implementation such an integration would > find it useful. As I mentioned before, KDevelop's plug-in would definitely be worth looking at for anyone interested in this. Valgrind GUIs like Alleyoop and Valgui are worth looking at also. N |
|
From: Naba K. <kh...@gm...> - 2005-05-03 13:28:18
|
Hi Nicholas, On Tue, 2005-05-03 at 18:00, Nicholas Nethercote wrote: > > 3) API interface: This is the best and most preferred way for > > the integration. In this case, valgrind offers a library that > > an Anjuta plugin proxies to the IDE's internal interfaces. > > Out of interest, what does the API look like? Do you have a webpage > describing it? > I think you misunderstood me. I was suggesting to have a library in valgrind (e.g libvalgrind or something) that will give the necessary API to IDE developers. The reason why I believe it's a better solution than parsing CLI output is that it is easier to track and manage API changes in a library than CLI format changes. Maintaining a parser of valgrind output, that could change arbitrarily, is surely not going to be easier. > > In case(2) and case(3), the integration requires developing > > an Anjuta plugin, but that is the least difficult part since > > it will hardly span more than one source file. > > Yes. And unless a very general mechanism (such as the "displayer" module) > can be implemented in Valgrind, I think this is the right way to do it: > have extra code in Anjuta to deal with Valgrind, rather than extra code in > Valgrind to deal with Anjuta. > The suggested code in valgrind is not to deal with Anjuta, but to have an easy way for any IDE to deal with valgrind. The anjuta-plugin thing I said was for Anjuta and not for valgrind. I was just highlighting the point that if valgrind offers such a library, many IDEs will find it much easier to implement their plugins. It was also a comment for someone interested to write such a plugin for Anjuta (reference to a previous message in the thread). The "displayer" thing you suggested is a nice approach. I hope we it is implemented soon. Thanks. Regards, -Naba |
|
From: Naba K. <kh...@gm...> - 2005-05-04 06:19:40
|
Hi Nicholas,
On Wed, 2005-05-04 at 07:42, Nicholas Nethercote wrote:
> So what would that look like?
>
Okay, the kind of API we (the IDE developers) would generally prefer is
a sort of async updates from valgrind library while it executes the
process under scrutiny. There needs to be additional API to meaningfully
interpret the delivered data.
Now, I know little about the kind of data valgrind reports, but as an
example let's take the memory corruption/leak reports which are usually
accompanied by stack snapshots. Here is a rough sketch of such an API.
/* We begin by invoking valgrind to run the process: */
int valgrind_execute (update_callback, options, additional info ..);
/* The IDE updates its UI based on the callback. */
void
update_callback (ValgrindRecord *r, other info ...)
{
switch valgrind_record_get_type (r)
{
case VALGRIND_RECORD_MEMLEAK:
... update mem leak report ...
case VALGRIND_RECORD_MEMCORRUPT:
... update mem corruption report ...
}
}
/* Record functions */
ValgrindStackTrace* st = valgrind_record_get_stack(ValgrindRecord *r);
... Other functions to retrieve record information ...
/* Stack functions */
int valgrind_stack_get_length(ValgrindRecord *r);
ValgrindFrame* sf = valgrind_stack_get_frame(ValgrindRecord *r, int
index);
... Other stack and frame operations ...
Well, that was overly simplified view of the API in a language that I am
used to, but I hope you get the point.
I understand that valgrind could not be operated in the same process
space as the main program and hence the difficulty in making it a
library. It's one unfortunate situation that I hope you people could
come around :).
>
> Here's how I imagine the KDevelop plug-in works: you invoke Valgrind
> somehow, and KDevelop works out what options to pass to Valgrind,
> then runs Valgrind (and the user program under it), then collects
> the output somehow, parses it, and presents it to the programmer
> in the IDE somehow.
>
There is nothing wrong in doing it the hard way, except that every IDE
would be implementing it (which is a waste to begin with) and all of
them would be struggling to maintain their parsers. Ask any developer
who has maintained such CLI output (meant for human readability) parsers
for a reasonable time how much fun it is.
The whole point of the suggestion is to make life easier for the IDE
developers at the cost of offering some helpful API from valgrind. Even
if full blown library interface is not feasible, as I mentioned earlier,
having some sort of predictable and machine-readable output from
valgrind would still be useful.
Thanks.
Regards,
-Naba
|
|
From: Nicholas N. <nj...@cs...> - 2005-05-06 13:20:49
|
On Wed, 4 May 2005, Naba Kumar wrote:
> void
> update_callback (ValgrindRecord *r, other info ...)
> {
> switch valgrind_record_get_type (r)
> {
> case VALGRIND_RECORD_MEMLEAK:
> ... update mem leak report ...
> case VALGRIND_RECORD_MEMCORRUPT:
> ... update mem corruption report ...
> }
> }
>
> [snip]
>
> I understand that valgrind could not be operated in the same process
> space as the main program and hence the difficulty in making it a
> library. It's one unfortunate situation that I hope you people could
> come around :).
Yes, that is a challenge. Something like a socket-based approach, passing
packets describing errors, could be the way to do it. I wouldn't hold
your breath for someone to implement it, though, since there has been
little demand for such a thing so far.
N
|