Thursday September 22, 2011

[Time] NameMessage
[02:21] bitcycle Hey all. Could someone comment on what I'm doing wrong on this? I'm trying to use zeromq + python bindings (pyzmq) to implement a pub/sub abstraction. I'm getting a "Segmentation fault"...
[07:57] bitcycle Hey all. I'm wondering if someone could help me out with a pub/sub issue. I run my script with the pub and sub in different child processes. When the processes end, the sockets are closed... but it leaves the file descriptors around. I've searched online for a bit, but haven't found a way to get it stop leaving them around.
[10:58] mikko good day all
[10:59] samsoir morning
[11:00] mikko have you moved?
[11:01] samsoir not yet
[11:01] samsoir 28th November
[11:01] mikko is there going to be a party?
[11:01] samsoir yes
[11:01] samsoir 29th October
[11:01] mikko you should hire meat wagon to that party
[11:01] mikko do they do that?
[11:01] samsoir heh, we're going one beter
[11:01] samsoir better*
[11:01] samsoir making two fire pits in the garden, and pit roasting some wildlife
[11:01] mikko foie gras wagon?
[11:02] mikko
[11:02] mikko you can do this
[11:02] samsoir that sounds awesome
[11:03] mikko it's also fair bit of work to get going
[11:03] mikko but so good
[11:04] samsoir we're purchasing a pig and goat for the day
[11:06] mikko interesting
[11:07] mikko you coming tomorrow?
[11:07] mikko
[11:12] samsoir I am
[11:13] samsoir right, gtg - see you tomorrow mikko
[14:02] someone-noone hello! Why zmq_recv (socket,ZMQ_NONBLOCK) returns 0 even no clients are connected? Here is what i'm talking about:
[14:02] someone-noone this code prints "@" symbol, but noone connected
[14:04] Steve-o on the latest versions?
[14:04] someone-noone 2.1.10
[14:07] Steve-o same with the C api?
[14:08] someone-noone i looked at api here
[14:08] someone-noone here is told that zmq_recv should return 0 if successful and -1 otherwise
[14:08] Steve-o yup, I'm just reviewing the docs
[14:09] Steve-o I haven't looked at the C++ API for a while though
[14:09] someone-noone but i'm using c api...
[14:09] Steve-o socket.recv is c++
[14:10] someone-noone oh my god
[14:10] Steve-o otherwise I expect to see zmq_recv
[14:10] someone-noone you're right
[14:10] Steve-o :P
[14:10] someone-noone i was thinking i'm using c api :D
[14:11] someone-noone so, my problem solved by changing if (socket.recv (&request,ZMQ_NOBLOCK) == 0) to if (socket.recv (&request,ZMQ_NOBLOCK) == true)
[14:12] Steve-o so it is binding specific,
[14:12] Steve-o always easy to get mixed up
[14:14] someone-noone yeah
[14:14] someone-noone btw, thanks for help!
[17:21] michelp morning!
[17:46] pieterh michelp: hi
[21:45] minrk1 mikko: hi, I have some buildbot questions
[21:50] Steve-o minrk1: anything interesting?
[21:51] minrk1 not really, just permissions - I used to be able to manually re-run builds, but can't anymore
[21:52] minrk1 and a recent pyzmq build failed with an error I can't reproduce (and identical code to the previous successful build)
[21:52] Steve-o k
[21:54] minrk1 It would probably also make sense to have builds for libzmq-3.0 - not just 2.1,2.2 and 4.0.
[21:55] Steve-o does pyzmq build on Windows?
[21:55] minrk1 sure
[21:56] Steve-o I only see Linux builds on the bot, but I don't know how complicated the bindings are
[21:57] minrk1 should be 3 lines to build and run tests
[21:58] Steve-o do different Python versions need to be targeted differently? 2.6, 2.7, 3?
[21:58] minrk1 in what way?
[21:59] Steve-o as in does your binding work with all these versions with no changes?
[21:59] minrk1 the source does, not the compiled result
[21:59] Steve-o out of interest, I only use Python in Scons
[22:00] minrk1 Cython generates a a set of .c extension files that will compile correctly on all Pythons >= 2.5
[22:00] minrk1 and the pure-Python part of the code is taken care to be valid on >= 2.5 as well
[22:01] Steve-o So does Cython handle any incompatibilities from v3 then?
[22:01] Steve-o Because are there not some big changes, hence 2.x is still default on many distros
[22:01] minrk1 yes, Cython takes care of all of that
[22:02] minrk1 (it's pretty awesome)
[22:02] Steve-o nice
[22:03] minrk1 well, Cython takes care of *most* of it - I have to help a little bit when writing explicit C-API calls to the buffer interface, which keeps changing
[22:04] minrk1 It's relatively straightforward to write multiple-version support in C (more so than Python), because you can just use a big pile of #if directives
[22:04] Steve-o sure, but it can become a headache soon enough
[22:04] minrk1 yes - it would be a huge pain to write it manually
[22:05] minrk1 but the C-code is all generated from Cython sources, which don't care about Python versions.
[22:08] minrk1 All this multiversion support is the reason the 58-line version.pyx results in a 1400 line version.c
[22:14] Steve-o well line count in such cases is a tad misleading, but the increased size probably has a lot of legibility overhead for debugging
[22:15] minrk1 certainly - it's hugely verbose with tons of comments, to help map the C-code to your Cython source
[22:15] minrk1 but there's still 100s of lines of boilerplate for handling changes in the C-API
[22:18] Steve-o PHP has been the most entertaining for boilerplate so far
[22:19] minrk1 pyzmq itself has some, in order to properly support libzmq 2.1, 3.0, and 4.0