> > 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'.
>
> Hi Alex,
>
> It's my Hack Week work that Petr was talking about, I'm interested in
> the idea of merging anything useful into your project or re-basing my
> thoughts on your interface, do you have a site or list I can contribute at?
*
Hi David,
*
the development of PyKdump is done using
*
http://sourceforge.net/projects/pykdump/
*
but I did not push GUI yet as I played with several different approaches and was not sure the code is good for release yet (the server part is already in PyKdump git-repository, the 'devel' branch). At this moment the GUI client has some hard-wired pieces (links into HP-hosted server with unpacked kernel sources) so it needs a cleanup before you can use it.
*
I'll send you the sources later this week so you could try GUI and provide your comments. I find Python-Qt more suitable for rapid development than C++ (and it more portable). But this really does not matter at this moment - it is more important to understand what benefits (compared to plain command-line crash) GUI can provide.
*
Yes, it would be great if we could work on this together!
*
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
08-20-2012, 09:25 PM
David Mair
Extension modules in C++
Hi Dave,
On 08/08/2012 09:24 AM, Dave Anderson wrote:
>
>
> ----- 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@suse.cz>
>>>> 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...
I noted the changes to defs.h in 6.0.9 that permitted me to include it
without macros to rename uses of namespace and typename. Thanks for
putting the time into it.
--
David Mair.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
08-21-2012, 03:49 PM
Dave Anderson
Extension modules in C++
----- Original Message -----
> >>> 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...
>
> I noted the changes to defs.h in 6.0.9 that permitted me to include it
> without macros to rename uses of namespace and typename. Thanks for
> putting the time into it.
>
> --
> David Mair.
No problem -- I meant to say "take _care_ of this" above...
And I apologize if you were among the offended by my initial response. ;-)
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility