Alexander Bernauer | 17 Jan 22:17 2013
Picon

ANN: hgdbmi 0.2, GDB Machine Interface

Hi

I am happy to announce the second release of hgdbmi, a Haskell
implementation of the GDB Machine Interface.

The Machine Interface is a machine-readable variant of the
stdin/stdout-based interface of the GNU debugger. With hgdbmi you can
control the execution of a GDB instance to drive debugging of
arbitrary targets.

Version 0.2 of this library is a substantial, non-compatible extension
of version 0.1. The API provides a thread-safe and synchronous
command-response function and supports user-defined call-backs for
asynchronous notifications. All commands, responses and notifications
are supported in this version. Also, for some response and
notification types, we additionally provide semantic data types and
corresponding translation functions.

The package:
http://hackage.haskell.org/package/hgdbmi-0.2

Greetings, Alex

PS: This is my first serious Haskell package. If you see something
that you consider odd, I might have done this simply because I didn't
know better. I would appreciate if you would let me know in such a
case.
Daniel Trstenjak | 18 Jan 11:22 2013
Picon

Re: ANN: hgdbmi 0.2, GDB Machine Interface


Hi Alexander,

On Thu, Jan 17, 2013 at 10:17:33PM +0100, Alexander Bernauer wrote:
> I am happy to announce the second release of hgdbmi, a Haskell
> implementation of the GDB Machine Interface.

Nice project! :)

> PS: This is my first serious Haskell package. If you see something
> that you consider odd, I might have done this simply because I didn't
> know better. I would appreciate if you would let me know in such a
> case.

Looking at the function names: have you got a c programming background?

Instead of using these prefixes you could put the functions into separate
modules.

If the interface depends on the GDB version, than it could make sense to
encode the GDB version into the module name, something like:
Gdbmi.V7_4.Commands

Greetings,
Daniel
Alexander Bernauer | 18 Jan 20:26 2013
Picon

Re: ANN: hgdbmi 0.2, GDB Machine Interface

Hi Daniel

thank you for your feedback.

On Fri, Jan 18, 2013 at 11:22 AM, Daniel Trstenjak
<daniel.trstenjak <at> gmail.com> wrote:
> Looking at the function names: have you got a c programming background?
> Instead of using these prefixes you could put the functions into separate
> modules.

Although I do have some background in C programming, these naming
schemes are not my idea. Instead the function names match the names of
the corresponding GDB/MI commands. I thought it would make sense to
use these names for ease of reference. Given this, would you still
prefer them being grouped in separate modules?

> If the interface depends on the GDB version, than it could make sense to
> encode the GDB version into the module name, something like:
> Gdbmi.V7_4.Commands

Gdbmi.Commands is not the only module that depends on the GDB version.
GDB/MI is in general still evolving and GDB's compliance with the
documentation keeps on changing on all levels. So I would have to
maintain all hgdbmi modules for each GDB version. Do you think this
makes sense and is worth the effort?

Greetings, Alex
Daniel Trstenjak | 19 Jan 13:14 2013
Picon

Re: ANN: hgdbmi 0.2, GDB Machine Interface


Hi Alex,

On Fri, Jan 18, 2013 at 08:26:10PM +0100, Alexander Bernauer wrote:
> I thought it would make sense to use these names for ease of
> reference. Given this, would you still prefer them being grouped in
> separate modules?

Yes, I still think that having separate modules can be beneficial,
also for the ease of reference.

> Gdbmi.Commands is not the only module that depends on the GDB version.

I thought of putting all of your modules under the version indicating
module.

> GDB/MI is in general still evolving and GDB's compliance with the
> documentation keeps on changing on all levels. So I would have to
> maintain all hgdbmi modules for each GDB version. Do you think this
> makes sense and is worth the effort?

At the current level of development, the version indicating module might
be unnecessary and overhead, but you also don't have to support multiple
GDB versions. It's just a more explicit way of telling your user for
which GDB version the binding should work.

You can reuse most of your code for several GDB versions.

Supposed you've implemented the GDB 7.4 bindings and now would like
to support a new command in GDB 7.5 and all other commands behave
(Continue reading)

Alexander Bernauer | 23 Jan 23:32 2013
Picon

Re: ANN: hgdbmi 0.2, GDB Machine Interface

On Sat, Jan 19, 2013 at 1:14 PM, Daniel Trstenjak
<daniel.trstenjak <at> gmail.com> wrote:
> Yes, I still think that having separate modules can be beneficial,
> also for the ease of reference.

> I thought of putting all of your modules under the version indicating
> module.

Thank you, Daniel. I will consider these changes (hopefully) soon.

Greetings, Alex

Gmane