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.
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
Hi Daniel
thank you for your feedback.
On Fri, Jan 18, 2013 at 11:22 AM, Daniel Trstenjak
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
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 still in the same way as in version 7.4. module Gdbmi.V7_5.Commands (module Gdbmi.V7_4.Commands, newCommand) where newCommand = ... Greetings, Daniel
On Sat, Jan 19, 2013 at 1:14 PM, Daniel Trstenjak
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
participants (2)
-
Alexander Bernauer -
Daniel Trstenjak