ZeroMq IRC Log

Tuesday June 21, 2011

[Time] Name	Message
[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