Sunday October 31, 2010

[Time] NameMessage
[00:44] nettok I am here but can't help you
[03:07] rphillips gandhijee: what version of gcc are you using?
[03:08] rphillips your toolchain may be too old
[05:19] adalrsjr1 hi, i need a help
[05:20] pieterh adalrsjr1: hi
[05:20] adalrsjr1 how i install java binding zmq on ubuntu
[05:21] pieterh did you read the page at
[05:22] adalrsjr1 i've read this page
[05:23] adalrsjr1 but i don't find the classpath with the zmq classes
[05:24] adalrsjr1 i follow the steps at
[05:25] pieterh "Make sure that you have set the Java classpath to the directory where ØMQ classes reside."
[05:25] adalrsjr1 and.. where 0mq classes reside?
[05:26] pieterh good question
[05:26] pieterh actually I don't use Java and I'm reading this page
[05:26] pieterh I'm not sure what it means by "0MQ classes"... libraries?
[05:27] adalrsjr1 yes.. classes are like libraries
[05:27] pieterh i think that page needs to be improved
[05:27] adalrsjr1 i will try found them
[05:28] adalrsjr1 thanks for your help o/
[05:29] adalrsjr1 i think it too
[05:30] pieterh i fixed the text a little, it looks like it explains how to build 0MQ but it really wants you to download and build jzmq from
[07:38] gandhijee rphillips: 3.3.4
[08:36] sustrik gandgijee: just make the destructor public
[09:57] CIA-21 zeromq2: 03Martin Sustrik 07signaler * r20884a7 10/ (6 files): initial version of new signaler -
[11:37] CIA-21 zeromq2: 03Martin Sustrik 07signaler * r99606af 10/ src/signaler.cpp :
[11:37] CIA-21 zeromq2: Synchronisation bug in new signaler fixed.
[11:37] CIA-21 zeromq2: Signed-off-by: Martin Sustrik <> -
[12:27] Guthur how does Zeromq compare to Tibco Rendezvous?
[12:28] Guthur a quick search did not turn up any benchmarks
[12:35] shales Has anyone played with zeromq and python's eventlet together?
[12:39] shales reason I ask is I want a process written in python that talks to both zeromq and sends HTTP gets and posts. I'd like the http client library to be asynchronous also so I'm looking at using eventlet+httplib2
[12:39] shales eventlet's support for zmq is only about 10 days old from the looks of it though
[12:40] shales any better approaches for doing the asynchronous HTTP client part?
[12:40] sustrik Guthur: do you have any RV benchmarks?
[12:41] Guthur sustrik I seen one comparing it to SonicMQ, but not ZMQ
[12:41] sustrik never mind, can you provide the link?
[12:42] Guthur sustrik, On another note; are you still actively developing clrzmq
[12:42] sustrik hm
[12:42] Guthur I notice its a few releases behind zmq
[12:42] sustrik does it break with current version?
[12:43] sustrik the daily builds seem to be ok
[12:43] Guthur RV vs sonicMQ ->
[12:43] Guthur sustrik, Probably fine, sorry I've only started checking it out and noticed it said 2.0.7
[12:44] sustrik where does it say so?
[12:44] sustrik i'll correct that
[12:46] Guthur Actually to be honest its probably me miss reading it
[12:47] sustrik ok
[12:47] sustrik as for the RV document it looks pretty old
[12:48] Guthur it was just that the only mention of version was on some commits that said "updated to match 0MQ/2.0.7"
[12:48] sustrik they use 10MbE
[12:48] Guthur ah ok, fair enough
[12:49] sustrik even though, it looks like 0mq would be much faster even on 10MbE
[12:50] sustrik the graphs seem to suggest that they need 20secs to transfer 20Mb of data on 10MbE
[12:51] sustrik that means the link is utulised only by 10%
[12:51] sustrik with 0MQ we are able to exhaust 1000MbE quite easily
[12:52] Guthur I may actually have the opportunity to compare them myself, no promises though
[12:52] sustrik that would be nice
[12:57] Guthur My team will be overhauling our application and I am hoping to suggest zmq. The current architecture is an absolute mess, it's actually going over HTTP; it was once a webapp that has since been converted to being a dedicated client.
[12:58] Guthur RV is being mentioned because some other applications are using that
[12:58] Guthur I like the idea of zmq because we could also use it to provide some concurrency to the application.
[13:01] sustrik not mentioning the fact that RV is pretty expensive :)
[13:02] Guthur Ye, very expensive from what I hear
[13:02] Guthur I'm not sure what licensing details are like on that
[13:03] sustrik i don't know how it is today but iirc the contracts were negotiated in one-by-one fashion once
[13:16] DerGuteMoritz hi, would it be possible to make ZMQ_FD not edge-triggered?
[13:16] DerGuteMoritz or is this technically impossible?
[13:32] CIA-21 zeromq2: 03Martin Sustrik 07signaler * r3b0e528 10/ src/event.cpp :
[13:32] CIA-21 zeromq2: HP-UX and AIX now use default implementation of event_t
[13:32] CIA-21 zeromq2: Signed-off-by: Martin Sustrik <> -
[14:26] CIA-21 zeromq2: 03Martin Sustrik 07signaler * r7a9ec19 10/ ( src/event.cpp src/event.hpp):
[14:26] CIA-21 zeromq2: eventfd implementation of event_t added
[14:26] CIA-21 zeromq2: Signed-off-by: Martin Sustrik <> -
[14:46] sustrik DerGuteMoritz: It's technically impossible
[14:46] DerGuteMoritz sustrik: ok!
[14:46] DerGuteMoritz sustrik: no problem though, I can work with it :-)
[14:47] sustrik to be precise, it's possible, but requires hacking the kernel
[14:47] sustrik that in turn would make 0mq non-portable
[14:48] DerGuteMoritz well I'm happy that ZMQ_FD is available at all :-)
[14:51] DerGuteMoritz alright, I just pushed version 0.0.1 of the chicken binding
[14:57] DerGuteMoritz there you go: :-)
[14:58] DerGuteMoritz is there an official way for announcing bindings?
[15:34] gandhijee sustrik: you think making the destuctor public will cause any problems in the future?
[15:37] gandhijee hey all, i am still trying to cross compile ZeroMQ for ARM (ts-7260 board), i now get this error when i compile, any ideas
[15:37] gandhijee
[15:52] gandhijee what gcc do ineed to build zeroMQ?
[16:09] adalrsjr1 hi, somebody here is a zmq java developer?
[16:10] adalrsjr1 i need help for install jzmq on my ubuntu
[16:11] xraid DerGuteMoritz: use the mailing list and edit the wiki + write a blog entry => twitter it ...
[16:12] xraid adalrsjr1: di you already follow the way of doing it ?
[16:13] adalrsjr1 yes i already follow this steps
[16:14] adalrsjr1 but i don't found the class/.jars for import in my project
[16:15] xraid k what os you at
[16:16] xraid you have java set up right its just some path to set
[16:16] adalrsjr1 ubuntu 10.10
[16:16] adalrsjr1 my CLASSPATH and JAVA_HOME are ok
[16:17] adalrsjr1 the problem is found the zmq =(
[16:17] xraid ahhh if you built the zmq and make installed it should be in /usr/local by default
[16:18] xraid is that in your path
[16:19] adalrsjr1 the zmq is in this path
[16:19] adalrsjr1 but how i use the zmq in my java aplication?
[16:19] xraid do a env on shell
[16:19] adalrsjr1 how i do it?
[16:20] xraid access the shell and write env
[16:20] xraid or better yet env | grep PATH
[16:21] adalrsjr1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[16:21] adalrsjr1 CLASSPATH=/usr/lib/jvm/java-6-sun/lib/tools.jar
[16:22] xraid ldconfig
[16:22] adalrsjr1 i already did ldconfig
[16:22] xraid that will update your conf after installing new libs
[16:22] xraid ahhh
[16:22] xraid whats the err you se
[16:23] adalrsjr1 i don't seer err... i simply found the jars for import in my project
[16:24] adalrsjr1 dont fount
[16:24] adalrsjr1 dont found
[16:24] xraid you did conf build install the zmq ?
[16:25] DerGuteMoritz xraid: will do that (minus the twitter bit probably :-)) thanks!
[16:25] xraid from or tarball before do the j binding
[16:26] xraid DerGuteMoritz: there should be a wiki changed twitter auto ;-)
[16:27] DerGuteMoritz xraid: neat :-)
[16:41] sustrik DerGuteMoritz: Create a page for the binding
[16:41] sustrik copy some of the existing pages on the wiki
[16:41] sustrik and change it suit yout binding
[16:41] sustrik then announce the binding via the mailing list
[16:41] DerGuteMoritz sustrik: will do that
[16:42] sustrik gandhijee: no, it won't cause problems
[16:42] sustrik it's awkward but not dangerous
[16:42] sustrik feel free to submit the patch so that it gets into the mainline
[16:42] gandhijee sustrik: i think the gcc is just way to old, i did what you suggested but then it complained about something in one of the templates
[16:43] sustrik i see
[16:43] sustrik looks like something to do with stl
[16:43] sustrik any chance of getting newer gcc?
[16:45] gandhijee yeah
[16:46] gandhijee i just did, but i think if i do that i might have to rebuild the world on the embedded arm board
[16:46] gandhijee which isn't all that big a deal
[16:49] sustrik 3.3.4 was released back in 2004, long before 0mq project was started, i doubt anyone tried to compiled with gcc that old till now
[16:50] DerGuteMoritz wtf, wikidot says that the page I want to create is locked but the person owning the lock is me
[16:51] sustrik that happens when you get disconnected or something
[16:52] DerGuteMoritz hmmmm
[16:52] sustrik you can force getting the lock
[16:52] DerGuteMoritz yeah
[16:52] DerGuteMoritz just odd, I mean the system knows who I am
[16:52] DerGuteMoritz I'm still signed in
[16:52] sustrik shrug
[16:52] DerGuteMoritz I wonder why they don't use optimistic locking
[16:52] DerGuteMoritz oh well
[16:55] gandhijee sustrik: well that explains a lot
[18:36] Guthur sustrik, Does clrzmq not support devices yet?
[18:37] sustrik Guthus: no, it does not
[18:37] sustrik Guthur: feel free to add them though
[18:40] Guthur sustrik, Would it be a big change?
[18:41] DerGuteMoritz I sometimes get an "Invalid argument" error when accessing the ZMQ_FD option. I think it happens when I access it very quickly after creating the socket. Is this a known problem?
[18:43] sustrik no it's not
[18:43] sustrik is it reproducible?
[18:43] DerGuteMoritz yeah but it could also be my binding's fault, I'll try to cook up a reproduction in C
[18:45] sustrik are you on win platform?
[18:45] DerGuteMoritz no, Linux
[18:45] sustrik it looks like the only way to get EINVAL
[18:45] sustrik is when you pass wrong optvallen argument
[18:45] sustrik it's supposed to be sizeof (int)
[18:45] DerGuteMoritz odd
[18:46] sustrik see socket_base.cpp:225
[18:48] DerGuteMoritz thanks for your help so far, I'll investigate and let you know if I find anything
[18:54] Guthur sustrik, Is the lack of clrzmq due to devices being experimental?
[18:55] Guthur are they likely to become stable soon?
[19:07] Guthur Looks like a simple enough change, need to go now but I'll have something ready later
[19:25] sustrik Guthur: the plan is to make devices a separate project
[19:27] pieterh sustrik: it's *already* a separate project, has been for several months
[19:27] sustrik the devices are still in the core
[19:27] sustrik can't remove them until 3.0
[19:27] sustrik :|
[19:28] pieterh we already discussed and agreed on this more than once
[19:28] pieterh it's good to provide core devices in the core
[19:28] pieterh it's good to provide a space for additional devices
[19:28] pieterh people need the core devices to get started, it's too hard to make your own initially
[19:29] pieterh you can deprecate the zmq_device API call in 3.0 but it'll be a handicap for users
[19:30] pieterh in fact the set of core devices will probably need to grow slowly
[19:30] pieterh since 0MQ core defines the common API among all languages
[19:30] pieterh otherwise you break language interoperability at a larger scale
[19:30] sustrik having them in core means the device semantics are bound by compability guidelines
[19:30] pieterh indeed
[19:30] sustrik i.e. no change to device semantics till 4.0
[19:30] pieterh which is precisely what you want
[19:30] pieterh for core devices
[19:31] sustrik there'll be need for changing the devices
[19:31] pieterh i don't see why
[19:31] sustrik for subscription propagation for example
[19:31] pieterh there'll be a need for adding devices
[19:31] pieterh subscription propagation doesn't affect the APIs anywhere
[19:31] pieterh nor the device APIs, only their internals
[19:32] sustrik their semantics
[19:32] pieterh that may affect one device and it's not clear how
[19:32] pieterh 'connect frontend to backend' is all the semantics we have
[19:32] sustrik exactly, that's why they should not be in the core
[19:32] pieterh ?
[19:33] pieterh please explain how these semantics would chantge
[19:33] sustrik it's not clear how they should change
[19:33] pieterh *change
[19:33] sustrik thus better having them apart
[19:33] pieterh well, it'
[19:33] pieterh it's as you like
[19:33] pieterh move them to zdevices (they are already there in fact)
[19:33] pieterh but it breaks interoperabilty
[19:33] sustrik ack, in 3.0
[19:33] sustrik ?
[19:33] pieterh it's not a good idea
[19:33] pieterh but feel free, you can fix it again in 4.0
[19:33] sustrik 3.0 breaks compatibility by definition
[19:34] sustrik how much branches would i have to maintain then?
[19:34] pieterh interoperability, not compatibility
[19:34] sustrik 2.0.x, 2.1, 3.0, 4.0
[19:34] sustrik yuck
[19:34] pieterh you ask weird questions
[19:34] pieterh the number of branches you maintain has nothing to do with this
[19:34] sustrik the only point is that i want to have core stable
[19:35] sustrik with devices in core that's going to take very long time
[19:35] pieterh you're the one saying the devices will change semantics
[19:35] sustrik yes
[19:35] pieterh you didn't explain what that meant
[19:35] pieterh so i've no idea what you mean by instability
[19:35] pieterh it seems largely fictious, but like i said, there's a home for devices if you want to move them out of the core
[19:35] sustrik simply that they are going to change
[19:36] pieterh the price will be that different languages no longer interoperate at that levek
[19:36] pieterh that's all
[19:36] sustrik sure
[19:36] pieterh you'll get each language inventing somewhat different devices
[19:36] sustrik yes
[19:36] pieterh eventually people will put them back into core
[19:36] pieterh like I said, 4.0 or somesucjh
[19:36] pieterh *somesuch... keyboard is touchy today
[19:36] sustrik not likely imo
[19:37] sustrik there are too many ways to be a device
[19:37] sustrik to get it standardised or something
[19:37] pieterh you standardize by imposing stability, not allowing change
[19:37] pieterh it's an act of will
[19:38] sustrik example: do we want a queue length monitoring in queue device?
[19:38] sustrik both options are valid
[19:38] pieterh consider the devices as base classes
[19:38] pieterh the defaults do something useful
[19:38] pieterh maybe over time they'll become configurable
[19:39] sustrik they are not base classes, they have no extension points
[19:39] pieterh that can be added trivially
[19:39] pieterh without breaking backwards compatibility
[19:39] pieterh anyhow, it's moot
[19:39] sustrik how?
[19:39] pieterh i agree that devices are a growing set
[19:40] pieterh and it's sane to provide a more flexible space for that
[19:40] sustrik anyway, it won't happen until 3.0
[19:40] sustrik so no worries as for now
[19:41] sustrik pieterh: 2.1 release
[19:41] pieterh ja
[19:41] pieterh 2.1 release is overdue
[19:41] pieterh how can I help?
[19:41] sustrik i need mato to check the INSTALL file problem
[19:41] sustrik it seems missing from 2.0.10 package
[19:41] sustrik no idea why
[19:42] pieterh is not building it
[19:43] sustrik it used to iirc
[19:43] sustrik the README is refering to it
[19:43] pieterh configure doesn't build it either
[19:43] sustrik yup, something have changed in the build process
[19:44] pieterh yeah
[19:45] pieterh sustrik: this shouldn't stop us releasing a 2.1.0
[19:45] sustrik it's a documentation bug
[19:46] sustrik should be solved
[19:47] pieterh is there an issue on the tracker?
[19:47] sustrik i don't think mato is checking those regularly, i've sent him an email
[19:48] pieterh afaics the INSTALL file isn't generated, but it's mandatory and included with the distribution if present
[19:48] sustrik hm
[19:48] pieterh mato: ping
[19:49] pieterh mato: when you read this tomorrow, wanna check what happened to INSTALL?
[19:49] sustrik :)
[19:49] pieterh ok, martin, I gotta catch a bus at 4am tomorrow to get to BA in time
[19:49] pieterh g/nite
[19:49] sustrik good night
[19:50] pieterh ryanair moved their flight to 7am
[21:21] DerGuteMoritz hm, just to be sure: the zguide gives this as an example for setting the identity of a socket: zmq_setsockopt (socket, ZMQ_IDENTITY, "Lucy", 4);
[21:21] DerGuteMoritz however, shouldn't the size argument be 5 actually?
[21:23] DerGuteMoritz hmmm
[21:23] DerGuteMoritz I guess it depends[tm]
[21:24] Guthur I don't think it requires null terminated strings, if that is what you mean
[21:24] DerGuteMoritz yeah
[21:24] Guthur I vaguely remember reading something about it
[21:32] DerGuteMoritz hmm maybe I am doing something wrong
[21:34] DerGuteMoritz I have this program:
[21:34] DerGuteMoritz oh wait
[21:34] DerGuteMoritz now :-)
[21:35] DerGuteMoritz and it prints this:
[21:35] DerGuteMoritz 3
[21:35] DerGuteMoritz 4
[21:35] DerGuteMoritz 'foo'
[21:35] DerGuteMoritz when I change the size in the setsockopt call to 4, it prints:
[21:35] DerGuteMoritz 4
[21:35] DerGuteMoritz 3
[21:35] DerGuteMoritz 'foo'
[21:35] DerGuteMoritz not sure what to make from that
[21:41] Guthur Its possible that the strlen result is no actually very meaningful, as it is looking for a null terminated string which id isn't
[21:41] Guthur no/not
[21:41] Guthur and so the result is fine in my eyes
[21:43] DerGuteMoritz good
[21:43] DerGuteMoritz I guess my FFI is confused by that
[21:43] DerGuteMoritz i.e. it is also looking for a zero
[21:46] DerGuteMoritz ah, no, that can't be it
[21:47] sustrik DerGuteMoritz: you are storing the result into the pointer to the string
[21:47] sustrik instead of the buffer itself
[21:48] sustrik zmq_getsockopt(socket, ZMQ_IDENTITY, &id, &id_size);
[21:48] sustrik should be:
[21:48] sustrik zmq_getsockopt(socket, ZMQ_IDENTITY, id, &id_size);
[21:48] DerGuteMoritz sustrik: hmmm
[21:48] DerGuteMoritz so the example in is also wrong?
[21:49] sustrik that one is ok
[21:49] DerGuteMoritz because it is an int?
[21:49] sustrik yes
[21:49] DerGuteMoritz I see
[21:49] DerGuteMoritz :-)
[21:49] sustrik the parameter is pointer to integer
[21:49] sustrik the string is pointer by itself
[21:49] sustrik so you don't have to & it
[21:50] DerGuteMoritz I then get:
[21:50] DerGuteMoritz opt.c: In function ‘main’:
[21:50] DerGuteMoritz opt.c:13:5: warning: passing argument 3 of ‘zmq_getsockopt’ discards qualifiers from pointer target type
[21:50] DerGuteMoritz /usr/include/zmq.h:206:16: note: expected ‘void *’ but argument is of type ‘const unsigned char *’
[21:50] sustrik it should be size_t
[21:50] sustrik not int
[21:51] DerGuteMoritz oh, indeed
[21:51] DerGuteMoritz my bad
[21:51] DerGuteMoritz still the same warning though, of course
[21:52] sustrik cast it to void* explicitly
[21:52] sustrik to get rid of it
[21:52] DerGuteMoritz ah that works
[21:52] DerGuteMoritz ugh :-)
[21:52] sustrik :)
[21:53] sustrik you miss this kind of fun then :)
[21:53] DerGuteMoritz right :-D
[22:20] Guthur sustrik, I got a queue device working ok for clrzmq
[22:21] Guthur I basically done the multithreading demo from the guide
[22:22] Guthur only minor issue is that to do it the the device creation method requires the IntPtr from the socket objects
[22:23] Guthur which meant providing a getPtr method, which muddies the object interface slightly
[22:24] Guthur I'll fork your github and push the changes there so you can have a look, might take awhile though as I don't have git on my windows VM.
[23:23] Guthur is the clrzmq essentially windows only?
[23:37] sustrik Guthur: it can be buillt with Mono as well
[23:39] sustrik Why the need for IntPtr? can't you pass the socket object itself as an argument?
[23:48] Guthur sustrik, the underlying C function requires the pointer
[23:48] Guthur The user of clr will of course only have to pass the socket object
[23:49] Guthur maybe there is a cleaner way of getting the ptr than the accessor I added
[23:49] Guthur the code is up on my github
[23:50] Guthur when using mono is there some way of using the zmq .so file built on the linux?