<div dir="ltr">On Sun, Nov 17, 2013 at 11:58 AM, Michael Haberler <span dir="ltr"><<a href="mailto:mail17@mah.priv.at" target="_blank">mail17@mah.priv.at</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Michel,<br>
<br>
just rewrote a protobuf/pyzmq Python application to use pyczmq (because I'm interested in beacon and securitiy support)<br>
<br>
first - no surprise; great job!<br></blockquote><div><br></div><div>Awesome, and thanks!  You could be pyczmq's first real-world user.  :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
just a note on the zframe wrapping:<br>
It would be handy to have a wrapping which supports the buffer call interface (such as strings, arrays, and buffers).<br>
<br></blockquote><div><br></div><div>zframe.data() returns a cffi.buffer object, which is sort of a quasi-buffer object.  I don't know much about the rational behind it,but the cffi docs point to some frustration reconciling the different buffer/Py_buf interfaces between various python versions, which I gather is the rational behind cffi.buffer.</div>
<div><br></div><div>See this thread:</div><div><br></div><div><a href="https://groups.google.com/d/msg/python-cffi/9uc6aqX7z0Q/_wotsY59xwYJ">https://groups.google.com/d/msg/python-cffi/9uc6aqX7z0Q/_wotsY59xwYJ</a><br></div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
        f = zframe.recv(socket)<br>
        m = buffer(zframe.data(f),0,zframe.size(f))<br>
        r = Container() # my toplevel protobuf message<br>
        r.ParseFromString(m)<br>
<br></blockquote><div><br></div><div>I don't know protobuf, but it seems like there should be a way for it to work directly with cffi.buffer, or maybe cffi needs a little patch in that regard (I've already half-forgotten the issue there, the thread above might clear that up).</div>
<div><br></div><div>As way of example, I worked out this little bit of code that exercises the "one less copy" operation in straight libzmq.  This code depends on pyczmq, and <a href="https://github.com/michelp/cmmap">https://github.com/michelp/cmmap</a></div>
<div><br></div><div><a href="https://gist.github.com/michelp/7522179">https://gist.github.com/michelp/7522179</a><br></div><div><br></div><div>This uses ctypes.Structure.from_buffer to copy objects to and from an mmaped file with no serialization, in theory the only serializing happens "out of process" by the kernel to and from the mapped file.  Maybe some ideas here might help?</div>
<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The other thing I noted is that handling of KeyboardInterrupt is different from pyzmq - which exits; pyczmq doesnt. Not necessarily a defect.<br>
<br></blockquote><div><br></div><div>I'll look into that this week, thanks for your comments!</div><div><br></div><div>-Michel</div></div></div></div>