IRC Log


Tuesday June 21, 2011

[Time] NameMessage
[06:22] CIA-32 libzmq: 03Martin Sustrik 07master * rab99975 10/ (17 files in 3 dirs): LABEL flag added to the wire format ...
[06:22] CIA-32 libzmq: 03Martin Sustrik 07master * rf437c9e 10/ doc/zmq_getsockopt.txt : Fix errors in zmq_getsockopt(3) manpage ...
[06:22] CIA-32 libzmq: 03Martin Sustrik 07master * ra28928f 10/ (7 files in 2 dirs): Introduce ZMQ_ROUTER and ZMQ_DEALER sockets ...
[07:23] private_meta When I've set my socket not to linger on close (ZMQ_LINGER 0) and I terminate my context, is there any reason why zmq_term might not return? it seems to hang in recv()
[07:29] pieterh private_meta: you also need to close the socket before calling zmq_term
[07:29] pieterh or is it in a different thread?
[07:31] sustrik recv() should return ETERM when zmq_term() is called
[07:31] sustrik if it does not it's a bug
[07:31] eurobax Hi! Where can I found php_zmq.dll for windows PHP 5.2?
[07:33] sustrik have you checked this: http://www.zeromq.org/bindings:php
[07:34] eurobax yes, I've visited http://snapshot.zero.mq/ but what is it?
[07:34] sustrik daily builds
[07:35] eurobax dayly builds of lib, or binding?
[07:36] sustrik dunno, looks like it's the lib
[07:37] eurobax yes, It seems to me too. But I cant understand how to build php_lib
[07:38] sustrik the instructions at http://www.zeromq.org/bindings:php are not clear enough?
[07:38] sustrik if so, send your question to the mailing list
[07:38] sustrik that will help us to improve the instructions
[07:40] eurobax ok, I'll check this
[08:52] pieterh sustrik: ping
[08:52] sustrik pieterh: pong
[08:52] pieterh hi, is it safe to do a zmq_msg_copy of a message on the stack?
[08:52] pieterh i.e. to grab a reference
[08:52] sustrik yes
[08:52] pieterh nice, thanks
[08:53] sustrik you don't have to wore about the location
[08:53] sustrik there's no difference in whether the message is on the stack or on the heap
[08:53] pieterh right
[08:53] sustrik it's semantically equivalent
[08:53] pieterh and it'll do reference counting for larger messages, right?
[08:54] sustrik yes
[08:54] pieterh excellent, this is very useful stuff
[08:55] mikko howdy boys
[08:55] mikko and girls
[08:55] pieterh hi mikko!
[08:55] sustrik morning
[08:56] mikko how's things ?
[08:56] mikko i had an accident last week
[08:56] mikko full mug of coffee on the keyboard
[08:57] mikko and naturally because it's a mac they need to change the whole casing to change the keyboard
[08:57] sustrik hehe
[08:57] sustrik been offline because of that?
[08:58] pieterh mikko: heh, my thinkpad has holes for coffee to drip through
[08:58] mikko my spare machine was a win7 laptop with 11" screen
[08:58] pieterh ugh
[08:58] mikko havent been using it much
[08:58] mikko i got my laptop back eventually and noticed that the backlight isnt working
[08:58] mikko booked another appointment and apparently they didnt attach the cable properly
[08:59] mikko next thing i noticed that bluetooth wasnt working so i opened the case, reattached the bluetooth cable and now it works again
[08:59] mikko surprisingly sloppy work imho
[10:38] glebiao hello
[10:40] glebiao i have troubles with latest version from git://github.com/zeromq/libzmq.git
[10:40] glebiao previously worked code just asserts on rc == 0 (external/zmq/src/io_thread.cpp:78)
[10:41] glebiao (code cross-compiled by mingw32 for Windows). Under linux, bot x86_32 and x86_64, it works fine
[10:41] glebiao can anybody help me?
[10:42] mikko you might want to use stable versions
[10:42] mikko zeromq2-1
[10:44] glebiao mikko: probably yes... btw, i can not find where latest stable version resides
[10:44] mikko zeromq2-1
[10:44] glebiao on github?
[10:44] mikko yes
[10:44] mikko https://github.com/zeromq/zeromq2-1 or just http://www.zeromq.org/intro:get-the-software
[10:45] glebiao but in any way, there is defenitely a bug :)
[10:45] mikko the master branch has gone throuhg a lot of changes
[10:46] mikko im surprised that your code even compiles against it without changes
[10:48] glebiao well... firstly i've try to work with a commit from yesterday and ops... a bug is here. then try to use the latest commit, yes, it compiles well, but the bug is still present
[10:58] pieterh glebiao: how come you're building from the libzmq master?
[10:58] glebiao pieterh: pardon? my "english" is very bad
[10:59] pieterh glebiao: I mean, are you deliberately using the 3.0 unstable version?
[10:59] pieterh and how did you find that, from what web page?
[10:59] glebiao well... it just a try, if course
[11:00] glebiao no, not from web. that was the only zmq git i was able to found on github
[11:00] pieterh hmm, ok
[11:02] glebiao i was i little shoked when after some regullary "git pull" my zmq2 copy suddenly pretend to be zmq3. well, if so, i realize to try
[11:05] glebiao pieterh: so you do not recommend to try to use zmq3 for any more or less serious purpose?
[11:06] pieterh glebiao: it's unstable, has a changed API, and a changed wire protocol from 2.x
[11:06] glebiao i see
[11:06] pieterh for any normal development you should use 2.1 stable (from zeromq.org)
[11:06] pieterh if you need the specific new features of 3.0, then it makes sense to use that
[11:07] pieterh sustrik: we should put a strong warning on https://github.com/zeromq/libzmq
[11:08] glebiao anyway, is there any method to register/track a bug?
[11:09] pieterh glebiao: please go to http://zeromq.org and read that site
[11:10] pieterh sustrik: I've modified the project description for libzmq, see if it makes sense...
[11:10] pieterh at https://github.com/zeromq/libzmq
[11:13] glebiao pieterh: sorry, i wish not to offend / disturb you and of course, i'm too inattentive... yes... now i see a tracker page. probably i was blind yesterday
[11:13] pieterh glebiao: it's really OK, we like to know how people find 0MQ... it's normal you search on github
[11:16] glebiao well... firstly i mentioned some news on http://linux.org.ru, than try to search github. pitty, there was some discourage migrations between repositories.
[11:28] jack-e hi all
[11:29] pieterh jack-e: hi
[11:29] jack-e i saw at the mailinglist, that someone is using zeromq with MATLAB .. is there any example / howto do this ??
[11:29] jack-e hey pieterh !
[11:29] pieterh have you looked on google?
[11:29] sustrik glebiao: what error does it print before the assert?
[11:29] glebiao sustrik: no one
[11:29] jack-e pieterh: yeah .. it just comes up with that one mail on zeromq-users ..
[11:30] glebiao just rc == 0 (external/zmq/src/io_thread.cpp:78)
[11:30] sustrik hm, there should be one
[11:30] jack-e you'ld probably have to write a mex extension .. but i'ld just like to save some work ;-)
[11:30] glebiao alas
[11:31] glebiao the behavoiur is the same under wine, virtual anr real Windows. Under linux all works fine.
[11:31] glebiao anr == and
[11:31] sustrik ack
[11:31] sustrik still, not printing out the error is strange
[11:32] sustrik you you possibly print the error out by hand?
[11:32] jack-e the mail was from David Kantowitz in january this year ..
[11:32] pieterh jack-e: I'd suggest contacting David Kantowitz, he may be able to help
[11:32] sustrik like adding printf ("%d\n", errno); ?
[11:32] glebiao compilation keys are: i586-pc-mingw32-g++ -o build/windows/32/zmq/libzmq/zmq_listener.o -c -march=i586 -m32 -D_DEBUG_ -g -DQT_THREAD_SUPPORT -DMx8632 -D__WINDOWS__ -DQ_OS_WIN -DQXT_WINDOWS -DZMQ_HAVE_MINGW32 --param=ssp-buffer-size=4 -mms-bitfields -march=i586 -m32 -D_DEBUG_ -g -DQT_THREAD_SUPPORT -DMx8632 -D__WINDOWS__ -DQ_OS_WIN -DQXT_WINDOWS -DZMQ_HAVE_MINGW32 --param=ssp-buffer-size=4 -mms-bitfields -static-libgcc -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NETWORK_LIB
[11:32] glebiao -DQT_OPENGL_LIB -DQT_XML_LIB -DQT_SVG_LIB -DQT_SHARED -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NETWORK_LIB -DQT_OPENGL_LIB -DQT_XML_LIB -DQT_SVG_LIB -DQT_SHARED -D_FORTIFY_SOURCE=2 -D_REENTRANT -D_THREAD_SAFE -DHAVE_CONFIG_H
[11:33] jack-e pieterh; :-) yup .. it's probably the easiest way ..
[11:33] glebiao sustrik: moment, will try
[11:37] glebiao heh
[11:38] glebiao errno = 0
[11:38] glebiao : Success
[11:38] glebiao errno = 0
[11:38] glebiao Success
[11:38] glebiao rc == 0 (external/zmq/src/io_thread.cpp:81)
[11:39] glebiao i can understand nothing...
[11:41] sustrik glebiao: there were some code changes there recently
[11:41] sustrik probably the function returns -1 while not setting errno
[11:41] sustrik let me see
[11:44] glebiao if i just comment the assertion (errno_assert (rc == 0); on line 78 of io_thread) out, than i got ""Assertion failed: fds.size () <= FD_SETSIZE (external/zmq/src/select.cpp:67)
[11:44] glebiao probably it may help
[11:46] CIA-32 libzmq: 03Martin Sustrik 07master * r10a93bb 10/ src/mailbox.cpp : Unspecified error code from mailbox_t::recv on Win32 fixed ...
[11:46] sustrik glebiao: try now
[11:46] glebiao moment
[11:48] glebiao now seems to be working.
[11:48] glebiao but...
[11:49] glebiao there is some memory error. probably my one... exploring
[11:53] sustrik pieterh: modified the description to: ØMQ libzmq core library - development version - UNSTABLE 3.0
[11:53] pieterh nice
[11:53] sustrik that should be clear enough
[14:55] twomashi Hi all
[15:01] twomashi is anyone using Zeromq along with another persistant queue for persistance / reliability?
[15:02] mikko some people are using rabbitmq-zeromq bridge
[15:02] mikko what is persistence / reliability in this case?
[15:03] mikko being able to recover from crash?
[15:06] twomashi yes crash or link down, it should be able to persist messages and support transactions
[15:06] twomashi get a job, work, acknowledge that work is done
[15:07] twomashi zeromq seems great for actor model style programming and distributed messaging but doesn't offer much in the way of reliability
[15:08] twomashi the rabbitmq - zeromq bridge could solve it
[15:08] ssi you have to think about it in terms of what it is
[15:09] ssi ip is great for distributed messaging but it doesn't offer much in the way of reliability
[15:09] mikko if link goes down / your node crashes you dont really get anything from storing the messages into persistnet storage
[15:09] twomashi mikko: you dont run out of memory so quickly ;)
[15:09] twomashi ssi: true
[15:09] mikko if you think about the architecture in a way that any node can fail at any time, having traditional disk based storage doesnt help you much
[15:10] mikko you can replicate the disk based storage, sure but how do you guarantee that everything has been replicated before failure?
[15:11] pieterh twomashi: there are a couple of patterns for reliability over 0MQ, in the Guide Ch4 and Ch5
[15:11] mikko i think reliablity and persistance need to be thinked per application / environment
[15:12] pieterh the use case for amqp reliability is crashing applications
[15:20] NickServ identify s1lvert0n
[18:28] k0ral hi, I have troubles with unclosed REP sockets
[18:29] k0ral any program that tries to send them a message will wait forever
[18:29] k0ral how can I avoid this ?
[18:40] cremes k0ral: have you read the guide at http://zero.mq/zg ?
[18:40] cremes it explains the difference between REP and XREP sockets
[18:40] cremes (i think XREP is now called ROUTER)
[18:41] k0ral hmmm, what's the point ?
[18:41] k0ral :s
[18:41] k0ral ok nevermind, I guess the answer is in the guide if you tell me so
[18:42] michelp the answer is in the guide
[18:42] k0ral ah fine, so XREP = REP - blocking
[18:43] cremes k0ral: no, not true
[18:43] cremes it depends on if you are talking about the "pattern" blocking or send/recv blocking
[18:43] cremes which is it?
[18:44] michelp k0ral, also reading this whole page is very helpful http://api.zeromq.org/2-1:zmq-socket for details on the various differences between sockets
[18:45] k0ral cremes: actually I don't know what would mean a non blocking rep
[18:45] k0ral cremes: I can easily imagine what it means for a req
[18:45] k0ral you just don't wait for a recipient, right ?
[18:46] cremes k0ral: start from the beginning and explain what you are doing, what socket types, your expectations and the problem you are seeing
[18:46] k0ral cremes: I've just solved it by another way, but still I think I may be interested in your wisdom on the topic
[18:47] cremes fire away... whatever wisdom i have is yours for the taking
[18:47] k0ral I'm developing an application that just forks a thread to act as a REP socket
[18:47] k0ral in an endless loop
[18:47] cremes it forks endlessly? or the thread loops endlessly?
[18:47] k0ral the loop is endless
[18:48] cremes ok
[18:48] k0ral so the way I close the socket is quite dirty actually
[18:48] cremes and what are you trying to do with this thread?
[18:48] k0ral while it is listening for a request, at exit, I call the close socket function
[18:48] cremes yeah, that isn't thread-safe
[18:48] k0ral well, just listening for requests from outside
[18:49] k0ral didn't find any other way to do that
[18:49] k0ral but then, sometimes socket aren't closed
[18:49] cremes if you close the context via zmq_terminate() then your socket will return with EINTR
[18:49] cremes detect that and call zmq_close() on it from the proper thread
[18:49] cremes you are missing that second part
[18:50] k0ral terminate hmmm
[18:50] cremes zmq_terminate() blocks forever waiting for all sockets to clean up after themselves
[18:50] cremes it's documented behavior... suggest a better name for the 3.0 api
[18:51] k0ral the thing is: I'm coding in HAskell
[18:51] k0ral so each time you talk about a C function I try to find it's equivalent in HAskell
[18:51] k0ral Haskell*
[18:51] cremes right... i can't help with that binding; i don't know that lang at all
[18:51] cremes but here's the sequence... it's the same regardless of language
[18:51] k0ral no problem, but there is a term function that is said to correspond to zmq_term
[18:52] cremes thread A creates a context
[18:52] cremes thread A creates thread B (passing it the context) and then thread B creates a socket
[18:52] cremes thread B starts blocking on a recv
[18:52] k0ral ahhhh
[18:52] cremes thread A terminates the context
[18:52] k0ral currently I create the context in thread B too
[18:53] k0ral that is surely a bad thing
[18:53] cremes thread B sees the recv return EINTR and calls close on the socket
[18:53] cremes thread A unblocks from the terminate
[18:53] cremes yeah, calling terminate on the context from A when you created the context in B is a bad idea
[18:53] cremes i mean, what's the point?
[18:53] cremes make thread A your coordinator
[18:54] cremes did that help?
[18:54] k0ral well, I'm fixing that and I tell you if it helped :)
[18:55] cremes heh
[19:04] k0ral don't know why, but I suddenly have a "socket: failed (Bad address)" error
[19:05] k0ral though I didn't change anything in the address
[19:05] k0ral I must have screwed something while moving out the context creation
[19:09] pieterh k0ral: actually, DEALER is more like a non-blocking REP
[19:10] k0ral what would that mean ?
[19:11] k0ral if you're supposed to answer a request, how could you be in another state than blocked until a request arrives ?
[19:11] pieterh means you can receive requests asynchronously and send replies back asynchronously
[19:12] pieterh if you've not read the Guide, you're not going to understand, tbh
[19:12] k0ral cremes: not sure it helped, the terminate function never ends
[19:12] k0ral cremes: I guess it's waiting for the socket to end its last action
[19:13] k0ral cremes: which is waiting for a request
[19:14] k0ral pieterh: I'm sure I can understand it without reading your bible :)
[19:15] k0ral pieterh: do you mean it just registers a callback which is triggered on a request arrival ?
[19:15] sustrik if you are forking the new process you can't share the context
[19:15] sustrik context can't be shared between processes, just between threads within a single process
[19:16] k0ral sustrik: that's only a new thread
[19:16] pieterh k0ral: you do realize you're wasting our time, if you don't bother reading the docs and ask questions that are answered in them
[19:16] sustrik then it's ok
[19:17] cremes k0ral: when you call terminate, is your recv unblocking? it should return with EINTR
[19:17] cremes if not it's a bug
[19:18] cremes what version are you running?
[19:18] k0ral 2.1.7
[19:18] pieterh cremes: you bored?
[19:18] cremes pieterh: :)
[19:18] k0ral cremes: I was using a blocking REP, I'm trying with a XREP
[19:19] pieterh k0ral: have you tried setting the HWM on the receiver side?
[19:19] pieterh also, make sure you're using ZMQ_POLLOUT before writing
[19:19] cremes pieterh: i don't think he's using zmq_poll
[19:19] cremes ah, i get it now
[19:20] pieterh k0ral: what language binding are you using?
[19:21] k0ral pieterh: :) guess what I'm going to answer you ?
[19:21] k0ral incorrect
[19:21] k0ral scroll up
[19:22] pieterh ah, if you're using Haskell, then you are smarter than me
[19:23] cremes k0ral: to be clear, when you terminate the context your thread with the socket never returns, correct?
[19:24] pieterh k0ral: this is of course explained in detail in the Guide but it'll be fun to watch you figure it out
[19:25] k0ral cremes: I'm looking at Haskell's binding's source which provides 2 ways to do the same thing so for now I'm trying the other way and I'll come back to you
[19:25] k0ral cremes: but to be clear, that's exactly what you said
[19:27] k0ral pieterh: I guess I find it as funny as you
[19:27] k0ral pieterh: :)
[19:28] pieterh k0ral: I guess it can be fun to learn by shooting blindly at stuff
[19:28] pieterh but it's kind of inefficient when you involve others in that process
[19:29] pieterh particularly when there's a series of worked examples (12 in Haskell) online that cover most of the common use cases
[19:30] k0ral pieterh: not involving anyone, I first asked a question, then I said I solved it, I just keep discussing with cremes who is sharing his wisdom
[19:30] k0ral pieterh: you know, I've read them all, and none of them close the context
[19:30] pieterh closing the context is not easy to get right
[19:30] k0ral pieterh: I even created a haskell piece of software as debug tool for zmq library
[19:31] k0ral pieterh: so actually I don't think I'm wasting people's time since I'm contributing
[19:31] pieterh http://zguide.zeromq.org/page:all#Making-a-Clean-Exit
[19:31] pieterh set LINGER to 0 on all sockets
[19:31] pieterh then close all sockets
[19:31] pieterh then terminate context
[19:32] pieterh you can take shortcuts, e.g. only set LINGER on sockets with outstanding connects and/or requests
[19:32] pieterh you should not be "trying an XREP"
[19:32] pieterh either you need a ROUTER socket in your pattern or you don't
[19:33] pieterh it will not work by accident
[19:33] k0ral pieterh: thank you, I'm reading it
[19:33] pieterh actually, with 0MQ nothing will work by accident
[19:33] pieterh however, once you internalize the semantics, either by reading the bible, or by spending 4x longer working at it, you can make things work by design
[19:34] k0ral :)
[19:35] pieterh i advise you, if you want to learn (and it's fun), to improve the Haskell binding and to contribute the missing examples for the bible
[19:35] pieterh future generations of over-optimistic geniuses will thank you for it
[19:37] k0ral you're a very nice character
[19:40] pieterh you're welcome
[19:54] k0ral okay so I'm not asking any question, but just to say that even when setting LINGER to 0, closing socket first and context then, I get an "epollControl: invalid argument (Bad file descriptor)" error
[19:57] sustrik that's sounds like haskel binding error
[19:57] pieterh k0ral: post a test case (to a gist or somesuch), please?
[19:57] sustrik fill an bug ticket with the project
[19:58] k0ral I'll contact the author
[20:00] k0ral anyway, may I'd like to thank the authors and maintainers of 0MQ, it's a very convenient library
[20:00] k0ral -may
[20:01] sustrik thanks
[21:14] nightmorph howdy. what would it take to get OSC running over zeromq?
[21:14] sustrik what's osc?
[21:15] nightmorph opensoundcontrol...
[21:16] sustrik no idea :)
[21:17] nightmorph there was some discussion of doing it last year, and another guy had the same idea, to use ruby bindings to run osc stuff over zeromq
[21:17] nightmorph this is all for monomes
[21:17] nightmorph right now we have to use zeroconf/bonjour/avahi, and there are cross-platform issues.
[21:18] sustrik osc seems to be a protocol
[21:18] nightmorph so by dispensing with the problems that each OS has with the zeroconf networking stack, also between OSes/apps, i'm thinking zeromq would be a way of doing that
[21:18] sustrik to support it you would have to change 0mq's wire format
[21:18] sustrik or write a new transport
[21:18] nightmorph more like just porting osc to 0mq
[21:18] sustrik the application you mean
[21:19] nightmorph was hoping it would be something simple, like writing bindings for liblo, but it's probably a lot more involved than that
[21:19] sustrik ignoring the protocol specs
[21:19] nightmorph serialosc for sure would have to be recoded to use 0mq, rather than the zeroconf dns resolve stuff
[21:19] nightmorph apps are supposed to talk to serialosc, which then talks to the monome device itself
[21:20] nightmorph but the apps also have to resolve/advertise/register themselves to the zeroconf service. that's the standard model.
[21:20] sustrik not going to help you much, sorry
[21:20] nightmorph figured as much
[21:21] nightmorph i'll poke around more in the docs
[21:21] sustrik you can also try asking on the mailing list
[21:23] nightmorph seems to have already been brought up: http://lists.create.ucsb.edu/pipermail/osc_dev/2010-September/001934.html
[21:23] nightmorph and sadly: https://github.com/corntoole/osc-over-zeromq
[21:25] nightmorph zeroconf kinda sucks; when i found 0mq, i immediately thought it'd be a much nicer way of advertising monome devices to connect to, and for passing OSC messages between apps, and between the monome+apps
[21:29] nightmorph sustrik: how suitable is 0mq for just passing these messages around on a single local machine? not over the network, but internal udp traffic or something
[21:33] michelp nightmorph, it's equally adept at both ipc and tcp message transport. no code changes are required, just a change in the endpoint.
[21:33] nightmorph that's pretty hot
[21:33] michelp that's one of 0mqs great benefits, you can write code that communicates between threads, processes, and machines without changing any code.
[22:19] CIA-32 pyzmq: 03Paul Colomiets 07master * r4b8374e 10/ zmq/core/poll.pyx : Fixed timeout in select call - http://bit.ly/mEkJ6q
[22:33] brianjarita hey all .... what does "rc != -1 (epoll.cpp:69)" mean? I keep gettting Bad file descriptor
[22:33] brianjarita rc != -1 (epoll.cpp:69)
[22:33] brianjarita Aborted
[22:33] brianjarita wait sorry wrong room