www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - =?UTF-8?B?4oiFTVFELA==?= a =?UTF-8?B?4oiFTVE=?= wrapper for D

reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
∅MQD is a D library that wraps the low-level C API of the ∅MQ 
messaging framework.  It is a rather thin wrapper that maps 
closely to the C API, while making it safer, easier and more 
pleasant to use.  The API is designed to feel familiar to 
existing ∅MQ users, yet natural to D users.

For more information, check out the following links.

   GitHub/README:  https://github.com/kyllingstad/zmqd
   API docs:       http://kyllingstad.github.io/zmqd
   DUB package:    http://code.dlang.org/packages/zmqd

A while ago, I posted an RFC about this on the digitalmars.D 
forum.  I've since incorporated some of the suggestions I got and 
made a few additions, and I now deem the library ready for 
release.  It hasn't seen a lot of serious field testing yet, 
though, so there are surely a few bugs lurking in there.  
Therefore, I am calling this the first beta release, and 
encourage you to report any issues you encounter here:

   https://github.com/kyllingstad/zmqd/issues
Jan 24 2014
parent reply Justin Whear <justin economicmodeling.com> writes:
On Fri, 24 Jan 2014 17:45:44 +0000, Lars T. Kyllingstad wrote:


 ∅MQD is a D library that wraps the low-level C API of the ∅MQ messaging
 framework.  It is a rather thin wrapper that maps closely to the C API,
 while making it safer, easier and more pleasant to use.  The API is
 designed to feel familiar to existing ∅MQ users, yet natural to D users.
 
 For more information, check out the following links.
 
    GitHub/README:  https://github.com/kyllingstad/zmqd API docs:      
    http://kyllingstad.github.io/zmqd DUB package:   
    http://code.dlang.org/packages/zmqd
 
 A while ago, I posted an RFC about this on the digitalmars.D forum. 
 I've since incorporated some of the suggestions I got and made a few
 additions, and I now deem the library ready for release.  It hasn't seen
 a lot of serious field testing yet, though, so there are surely a few
 bugs lurking in there. Therefore, I am calling this the first beta
 release, and encourage you to report any issues you encounter here:
 
    https://github.com/kyllingstad/zmqd/issues


Nicely done.  It looks like you haven't wrapped the poll functionality at 
all, something that I use in most of my 0MQ programs.
Jan 24 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Friday, 24 January 2014 at 18:59:54 UTC, Justin Whear wrote:

 Nicely done.  It looks like you haven't wrapped the poll 
 functionality at
 all, something that I use in most of my 0MQ programs.


Thanks!  I'm glad that you mention zmq_poll(); I've been 
wondering how to deal with that.  It's slightly more low-level 
than the other functions, since it also deals with standard OS 
file descriptors, and I'd rather not expose OS-level stuff in 
∅MQD more than strictly necessary.  Do you ever use that 
functionality, or do you just poll ∅MQ sockets?

Lars
Jan 24 2014
parent reply Justin Whear <justin economicmodeling.com> writes:
On Fri, 24 Jan 2014 19:11:56 +0000, Lars T. Kyllingstad wrote:


 On Friday, 24 January 2014 at 18:59:54 UTC, Justin Whear wrote:

 Nicely done.  It looks like you haven't wrapped the poll functionality
 at all, something that I use in most of my 0MQ programs.


 
 Thanks!  I'm glad that you mention zmq_poll(); I've been wondering how
 to deal with that.  It's slightly more low-level than the other
 functions, since it also deals with standard OS file descriptors, and
 I'd rather not expose OS-level stuff in ∅MQD more than strictly
 necessary.  Do you ever use that functionality, or do you just poll ∅MQ
 sockets?
 
 Lars


I think I've mixed a file descriptor in with sockets once, but not in 
current production code.  A quick thought: you might template the poll 
wrapper so that the user could pass a mix of Socket and int (or whatever 
the proper name is for the file descriptor type per OS).  Inside, you set 
the appropriate property on each zmq_pollitem_t structure based on the 
argument type.

Now that I think of it, you also need to find a scheme for indicating 
which events you want to listen for.  Which means either a simple pairing 
type (socket, event mask) or a getopt-style interface.
Jan 24 2014
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Friday, 24 January 2014 at 19:20:26 UTC, Justin Whear wrote:

 Now that I think of it, you also need to find a scheme for 
 indicating
 which events you want to listen for.  Which means either a 
 simple pairing
 type (socket, event mask) or a getopt-style interface.


I have suggested a few possible poll APIs here:

     https://github.com/kyllingstad/zmqd/issues/3

Comments are very welcome.
Jan 26 2014