Hi all, as part of SUSE HackWeek8, David started work on a GUI extension using Qt4, which is a C++ project. One of the early annoyances is that an extension module must include the declarations from defs.h, and we currently use some C identifiers which happen to be keywords in C++, namely: - struct namespace - struct namespace namespace (in struct symbol_table_data) - char *typename (in struct gnu_request) Can I rename them? But you said earlier that the existing API must never change... Any other suggestions to make this include file parseable by a C++ compiler?

Dne Čt 26. července 2012 14:02:56 Adrien Kunysz napsal(a): > On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik <ptesarik(a)suse.cz&gt; > wrote: > > Hi all, > > > > as part of SUSE HackWeek8, David started work on a GUI extension using > > Qt4, which is a C++ project. One of the early annoyances is that an > > extension module must include the declarations from defs.h, and we > > currently use some C identifiers which happen to be keywords in C++, > > namely: > > > > - struct namespace > > - struct namespace namespace (in struct symbol_table_data) > > - char *typename (in struct gnu_request)

> > > > Can I rename them? But you said earlier that the existing API must never > > change... Any other suggestions to make this include file parseable by a > > C++ compiler? > > One hack you could consider would be to do something like this: > > extern "C" { > #define namespace ns > #include "defs.h" > #undef namespace > } Yes! That works, although I'm not entirely sure it can't do any harm. After all, it's what you called it - a hack. ;-)

I wonder whether Dave (Anderson) can suggest a cleaner solution (or make an official statement that he doesn't care about C++ compatibility). Petr Tesarik SUSE Linux

----- Original Message ----- > > > ----- Original Message ----- >> Dne Čt 26. července 2012 14:02:56 Adrien Kunysz napsal(a): >>> On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik <ptesarik(a)suse.cz&gt; >>> wrote: >>>> Hi all, >>>> >>>> as part of SUSE HackWeek8, David started work on a GUI extension using >>>> Qt4, which is a C++ project. One of the early annoyances is that an >>>> extension module must include the declarations from defs.h, and we >>>> currently use some C identifiers which happen to be keywords in C++, >>>> namely: >>>> >>>> - struct namespace >>>> - struct namespace namespace (in struct symbol_table_data) >>>> - char *typename (in struct gnu_request) > > And it seems that "namespace" is used for other purposes in files > like ppc.c and ppc64.c... Of course that's irrelevant to the discussion... > The "typename" is changeable, in fact I don't think it's really used > except for debugging purposes, although it would break the capability > of using other (earlier) versions of gdb. I would say that most people > use the most recent gdb version, but it always seems that there's somebody > still doing things differently. But that could be dealt with by #ifdef'ing > the structure member declaration in defs.h based upon the relevant GDB_X_X > setting, because gdb/symtab.c wouldn't see it. Kind of ugly, > though... > >>>> >>>> Can I rename them? But you said earlier that the existing API must never >>>> change... Any other suggestions to make this include file parseable by a >>>> C++ compiler? >>> >>> One hack you could consider would be to do something like this: >>> >>> extern "C" { >>> #define namespace ns >>> #include "defs.h" >>> #undef namespace >>> } >> >> Yes! That works, although I'm not entirely sure it can't do any harm. >> After all, it's what you called it - a hack. ;-) > > But it can't harm the crash utility, right? ;-) > >> I wonder whether Dave (Anderson) can suggest a cleaner solution (or make an >> official statement that he doesn't care about C++ compatibility). >> >> Petr Tesarik >> SUSE Linux > > To be honest, I really don't care about C++ compatibility -- with the realization > that I'm already offending somebody. If Adrien's suggestion works, I suppose I'd > prefer to keep things as they are. But if you really want to submit a patch, > I'll entertain it as always... > > Dave Petr, On second thought, I'll just take of this in crash-6.0.9. It's not that big a deal...

Hi all, as part of SUSE HackWeek8, David started work on a GUI extension using Qt4, which is a C++ project.

On July 26, 2012 11:57:05 AM Petr Tesarik wrote: > Hi all, > > as part of SUSE HackWeek8, David started work on a GUI extension > using Qt4, which is a C++ project. Hi all, I have a working prototype (still in Alpha) of Python-Qt based GUI that works remotely using the following approach: - at server side, you load PyKdump and do 'epython server' - at your local PC, you run 'python guimain.py' Communication is done using TCP and exchanging records with headers containing data length. At this moment the project is in early stages (proof of concept) but already usable. Because PyQT is portable, the same sources work both on Linux and Windows clients. I think that building GUI directly on top of crash is not the best approach - it is easier to add a small extension to crash and then communicate with it (if done locally, we could use shared memory or AF_UNIX sockets). A similar approach (driving GDB externally instead of linking with it) is already used in several GUI debuggers, e.g. 'ddd'.

On July 26, 2012 11:57:05 AM Petr Tesarik wrote: > Hi all, > > as part of SUSE HackWeek8, David started work on a GUI extension using Qt4, > which is a C++ project. Hi all, I have a working prototype (still in Alpha) of Python-Qt based GUI that works remotely using the following approach: - at server side, you load PyKdump and do 'epython server' - at your local PC, you run 'python guimain.py' Communication is done using TCP and exchanging records with headers containing data length. At this moment the project is in early stages (proof of concept) but already usable. Because PyQT is portable, the same sources work both on Linux and Windows clients. I think that building GUI directly on top of crash is not the best approach - it is easier to add a small extension to crash and then communicate with it (if done locally, we could use shared memory or AF_UNIX sockets). A similar approach (driving GDB externally instead of linking with it) is already used in several GUI debuggers, e.g. 'ddd'.