ZeroMq IRC Log

Friday November 5, 2010

[Time] Name	Message
[01:06] teruokun	Hello
[01:08] teruokun	I'm very new to using 0MQ and was trying to see if it would work for a project I'm working on
[01:09] teruokun	I have a master than needs to keep track of a bunch of slaves
[01:10] teruokun	multiple slaves will exist per server and they are meant to be more-or-less autonomous
[01:11] teruokun	what they depend on the master for are orders (NEW data, kill yourself, etc.)
[01:11] teruokun	but they have to be able to respond back to the master
[01:14] teruokun	I'm attempting having an incoming 'upstream' channel for the master to receive communications on and a pubsub relationship for the master to send out orders
[01:15] teruokun	However, I'm ending up with some 'address in use' issues for the server itself
[01:16] teruokun	for instance, if the master has to be shut down temporarily and brought back up, occasionally (but not predictably), it will not be able to bind it's addresses
[01:16] teruokun	anyone have any ideas what I'm doing wrong?
[02:36] Guthur	sustrik, ping
[02:44] Guthur	oh nvm, I got it sorted
[04:36] andrewvc	cremes: I found the cause of the MRI and RBX hangs running the spec suite, repeatedly creating contexts was the issue
[09:12] mikko	pyzmq builds seem to be failing against master and maint branches of 0MQ
[09:22] sustrik	mikko: yes, i've seen that
[09:23] sustrik	morning
[09:23] mikko	morning
[09:23] sustrik	btw, i'm in london on 9th and 10th
[09:23] mikko	this month?
[09:23] sustrik	yes
[09:23] sustrik	next week
[09:24] mikko	my calendar looks pretty empty this far
[09:24] sustrik	if you want to have a beer in the evening
[09:24] mikko	maybe we could finally be in the same place at the same time
[09:24] sustrik	right
[09:24] mikko	all i've done this far is recommended meeting places
[09:24] sustrik	:)
[09:25] mikko	are you working for a customer?
[09:25] sustrik	yes
[09:25] mikko	do you know whereabouts in london?
[09:25] sustrik	southwark
[09:25] sustrik	i'll be online till so we can arrange it then
[09:25] mikko	sure
[09:26] mikko	i'm close to tottenham court road
[09:26] mikko	so going down to waterloo is pretty easy
[09:26] Guthur	Is there an active maintainer for pyzmq?
[09:27] sustrik	or the other way round, we can have a diner in soho
[09:27] sustrik	Guthur: yes
[09:27] sustrik	it's Brian Granger and MinRK
[09:27] mikko	sustrik: there is a nice pub pretty close there http://www.doggettscoatandbadge.co.uk/
[09:27] mikko	it's north from southwark, riverside
[09:28] mikko	but let's see closer
[09:28] mikko	especially if there are others coming as well
[09:28] sustrik	dunno, i haven't arranged anything yet
[09:29] mikko	Jon Dyte is in london iirc
[09:29] mikko	and a few others
[09:29] sustrik	yep
[09:30] Guthur	sustrik: How important do you feel the raw socket support in PollItem is? I implemented polling in the clrzmq last night, but not sure how to support raw sockets.
[09:30] sustrik	well, support what you can
[09:30] sustrik	other features can be added later on
[09:31] sustrik	the raw sockets support is useful when integrating 0mq sockets into events loop
[09:31] sustrik	so say you have an application that uses raw sockets
[09:31] sustrik	and want to use 0mq for particular job
[09:31] Guthur	I could probably get it working on windows platform, but cross platform would be a bit of a pain
[09:31] sustrik	just ignore it then
[09:32] sustrik	you don't have to support everything
[09:32] Guthur	I was pretty please to get polling going last night anyway
[09:33] Guthur	It even uses C# event handler delegates, hehe
[09:35] sustrik	so you are basically ready?
[09:35] sustrik	announce it then and let's see
[09:35] sustrik	whether C#-friendly API attracts more .net devs
[09:36] Guthur	I'd like to take the weekend to finish off the guide examples
[09:37] sustrik	ack
[09:38] Guthur	I'm about half through them now., just completed the second divide and conquer with the kill signal.
[09:38] Guthur	well a bit less than half way, but close
[10:37] mikko	symbol lookup error: /usr/local/lib/libzmq.so.0: undefined symbol: _ZN3zmq15zmq_connecter_tC1EPNS_11io_thread_tEPNS_9session_tERKNS_9options_tEPKcS9_
[10:37] mikko	this is slightly strange error
[10:38] mikko	ZERMQ2
[10:38] mikko	typo in my autoconf
[15:40] CIA-20	zeromq2: 03Martin Sustrik 07master * r9cfdb44 10/ (28 files):
[15:40] CIA-20	zeromq2: slots renamed to tids
[15:40] CIA-20	zeromq2: Threads were so far identified by integers called 'slots'.
[15:40] CIA-20	zeromq2: This patch renames them to more comprehensible 'tid's (thread IDs).
[15:40] CIA-20	zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/d3zXQD
[16:04] mato	sustrik: yo
[16:15] cremes	sustrik: why not just write 'thread_id' instead of 'tid'? are saving those few characters that important when it reduces comprehension?
[16:15] mato	cremes: i'm guessing sustrik likes his compressed variable names :-) but fair point...
[16:17] cremes	mato: it took me years to break that habit but i'm glad i did; i no longer fear long variable names!
[16:17] cremes	and coming back to review old code is so much easier then
[16:17] mato	cremes: i agree
[16:17] mato	cremes: submit a patch :-)
[16:17] cremes	:)
[16:18] mato	seriously
[16:18] mato	[PATCH] Uncompress variable names
[16:18] mato	:-)
[16:18] kyuss	Hello. I'm trying to run basic REQ/REP example in C from the guide. It works fine on Debian, but zmq_connect hangs on Fedora 8. How can I debug it?
[16:18] cremes	perhaps i will... search and replace are pretty quick these days
[16:18] mato	You can do it trivially by taking sustrik's commit and running sed over it :-)
[16:18] cremes	ha
[16:19] cremes	kyuss: let me take a quick look here...
[16:19] cremes	kyuss: do you have a link to the specific code you used from the guide? there are lots of examples...
[16:20] kyuss	one sec
[16:20] kyuss	cremes: server http://pastebin.com/5Hy8dzWU
[16:21] cremes	ok
[16:21] kyuss	cremes: client http://pastebin.com/C8AERFSk
[16:21] cremes	step 1, replace the asterisk in the call to zmq_bind with 127.0.0.1
[16:21] cremes	it's more portable (i.e. that syntax doesn't work on windows from my experience)
[16:22] cremes	try it again with that small change
[16:23] cremes	also, be sure that you are starting the server before starting the client
[16:23] mato	cremes: "*" doesn't work on windows? It just binds to INADDR_ANY
[16:23] mato	cremes: if it really doesn't work, that's a bug...
[16:24] kyuss	cremes: I have changed asterisk to 127.0.0.1. I have run server, then client in gdb and it hangs on zmq_connect again.
[16:24] cremes	mato: perhaps it is fixed in later releases but it definitely didn't work in 2.0.8
[16:24] kyuss	cremes: I tried with 2.0.10 and 2.0.8
[16:24] cremes	kyuss: check to see if any other processes are using port 5555 via netstat
[16:26] cremes	kyuss: also, in the client code change localhost to 127.0.0.1
[16:27] kyuss	cremes: I did that, no change. And there is nothing on 5555 execept server (when I run it)
[16:28] cremes	well, that doesn't make any sense to me then
[16:28] mato	cremes: '*' definitely works with 2.1 master, ergo also 2.0.10 since that did not change
[16:28] mato	cremes: just tried it on win2k3
[16:28] cremes	mato: good to know
[16:28] cremes	i'll need it for win7 sometime soon...
[16:28] cremes	we need to get 0mq building under mingw cleanly
[16:29] mato	cremes: there's no reason why it shouldn't, it doesn't do anything special (just uses INADDR_ANY for the unerlying bind call)
[16:29] mato	cremes: patches welcome :-) 2.0.x used to cross-compile OK from Linux to Windows using MinGW
[16:29] cremes	kyuss: exact same code runs ok on debian but fails on fedora?
[16:29] mato	cremes: no idea about an actual build on Windows
[16:29] kyuss	cremes: yes sir
[16:30] cremes	mato: roger that
[16:30] cremes	kyuss: do any of the examples work on fedora?
[16:30] cremes	try running some of the code provided in the 'perf' subdir
[16:30] mato	cremes: I'd get him to try local_thr and remote_thr
[16:30] mato	precisely :-)
[16:30] cremes	like local_lat & remote_lat
[16:31] kyuss	cremes: No. I try basic one because my previous code with queue device was not working as well (but works fine on debian).
[16:32] cremes	kyuss: so none of the 0mq code examples work on fedora, right?
[16:32] kyuss	cremes: I have installed uuid-dev from source (e2fsprogs), then 2.0.10 from source
[16:33] kyuss	cremes: That's right
[16:33] cremes	kyuss: i dont' know what to do to help; 0mq works fine on my osx and archlinux boxes and clearly it works ok on your debian box
[16:33] cremes	i don't know why fedora is failing
[16:34] cremes	i think you're going to have to dig a bit deeper; see where the hang happens via gdb or use strace
[16:34] kyuss	cremes: Ok. Thanks. Maybe I will try on more recent version of Fedora
[16:42] CIA-20	zeromq2: 03Martin Sustrik 07master * r9da84a5 10/ (14 files in 3 dirs):
[16:42] CIA-20	zeromq2: signaler renamed to mailbox
[16:42] CIA-20	zeromq2: For historical reasons queue to transfer commands between
[16:42] CIA-20	zeromq2: threads was called 'signaler'. Given that it was used to
[16:42] CIA-20	zeromq2: pass commands rather than signals it was renamed to 'mailbox',
[16:42] CIA-20	zeromq2: see Erlang mailboxes.
[16:42] CIA-20	zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/alBcFR
[16:45] sustrik	cremes: it's modeled after POSIX pid (process id)
[16:45] mato	sustrik: is there some reason why you added whitespace (blank lines) before comments in some functions of the (now) mailbox, but not others?
[16:46] sustrik	i've missed some?
[16:46] sustrik	ugh
[16:46] mato	sustrik: is this part of coding style?
[16:46] sustrik	yes
[16:46] mato	sustrik: blank line before any comment?
[16:46] sustrik	the structure is: block of code preceded by a comment
[16:46] mato	sustrik: you ignored the win32 implementation at least
[16:46] sustrik	separated by blank line
[16:47] sustrik	sorry?
[16:47] mato	sustrik: the problem is, you end up with stuff like this:
[16:47] mato	if (block_) {
[16:47] mato	// Set the reader to blocking mode.
[16:47] mato	int flags = fcntl (r, F_GETFL, 0);
[16:47] mato	errno_assert (flags >= 0);
[16:47] mato	int rc = fcntl (r, F_SETFL, flags & ~O_NONBLOCK);
[16:47] mato	errno_assert (rc == 0);
[16:47] mato	}um
[16:47] mato	um
[16:47] mato	with a blank line after the if(block_) {
[16:47] sustrik	yeah, the commet should be before the if
[16:48] mato	well, then do it properly :-)
[16:48] sustrik	i should
[16:48] sustrik	:\|
[16:48] mato	i mean do it properly or not at all
[16:48] mato	and/or you should have complained when I posted my patch
[16:49] mato	anyway, no big deal
[16:49] sustrik	yes, i'll fix it
[16:49] mato	it's just those orphaned if statments make no sense
[16:49] sustrik	yes
[16:49] sustrik	i find comment+block coding style more comprehensible
[16:49] sustrik	but it should be done properly
[16:50] mato	as i said, in future complain to the submitter
[16:50] sustrik	ok
[16:51] mato	oh, incidentally I added stuff like // !something in #else blocks
[16:51] mato	i think it would be nice to arrive at a convention for that
[16:51] sustrik	sure, feel free to propose one
[16:51] mato	since with stuff like the signa^H^H^H^H^Hmailbox code, it's good to be able to see what the #else means
[16:51] mato	right?
[16:51] sustrik	howeve i would like to avoid something like this:
[16:51] mato	especially if the #if is somewhere 5 pages up
[16:51] sustrik	if (X)
[16:52] sustrik	y = 1;
[16:52] sustrik	else // !X
[16:52] sustrik	y = 2;
[16:52] mato	i would only do it if the block is big
[16:52] mato	for some definition of big
[16:52] sustrik	yes
[16:52] sustrik	on the other hand it creates some management burden
[16:52] sustrik	if the if part is changed and else part ignored
[16:53] sustrik	you'll end up with inconsitent comments
[16:53] mato	review, refuse to accept
[16:53] mato	if it becomes part of the coding style, enforce it
[16:53] sustrik	then the burden is on me, as maintainer :)
[16:53] mato	it does make code with platform-dependent ifdefs much easier to follow
[16:54] mato	sustrik: as the maintiner, you should be reading each patch anyway :-)
[16:54] sustrik	actually, yes, #ifdefs are mess
[16:54] mato	sustrik: so there is no "extra" burden
[16:54] sustrik	mato: the point is that the offending comment is not part of the patch
[16:54] sustrik	so i would have to check the original code aside of the patch
[16:55] mato	sustrik: dunno.
[16:55] sustrik	what i say is: easy to get wrong
[16:55] sustrik	if wrong, it has no value
[16:55] mato	true
[17:03] sustrik	thinking about the coding style wrt comments
[17:04] sustrik	i believe it forces developer to separate body of function in small "sub-functions"
[17:04] sustrik	with clear semantics
[17:04] sustrik	if i can't think of a comment to place on top of the block of code
[17:05] sustrik	it's probably mixing several issues
[17:05] sustrik	and shoud be cleaned up anyway
[17:06] mato	sustrik: sure, the comments inside the block body in my case should go above the if, i guess
[17:06] mato	// If ...., we do special foo.
[17:06] sustrik	right
[17:06] mato	etc
[17:08] sustrik	actually, it is documented:
[17:08] sustrik	# Code should be broken to small pieces (couple of lines each), every piece doing one simple task.
[17:08] sustrik	# Each piece should be preceded by a comment explaining what is its intent.
[17:08] sustrik	# Each code piece should be followed by a blank line.
[17:08] sustrik	good
[17:28] shales	I'm confused about message envelopes and routing with XREP socket. Is the following true? If both XREQ and REP sockets connect to an XREP socket, then the XREP socket has to the type of the socket on the other end so that that it knows when the delimeter after the address in a multipart message is necessary
[17:29] shales	meant to say "then the XREP socket has to _know_ the type"
[18:06] cremes	shales: make sure your multi-part messages all follow the same rules if you are going to mix XREQ and REQ sockets on the same XREP endpoint
[18:06] cremes	then the XREP doesn't need to know anything; all sockets are managing the message parts the same way
[18:06] cremes	i.e. always use the null part as a delimiter
[18:08] cremes	shales: read this... i wrote it a while ago when i was having the same issues: http://www.zeromq.org/tutorials:xreq-and-xrep
[20:09] Guthur	when does the RECVMORE get set, before calling Recv or afte
[20:10] Guthur	after*
[20:10] Guthur	Does one have to call the Recv to find out there is a multipart message
[20:14] shales	cremes: thanks! that makes sense. I see what I was doing wrong now
[20:24] twomashi	helloo
[20:24] twomashi	I have a question
[20:24] twomashi	My understanding is that creating a zeromq context creates a thread in your application which allows socket operations to run asynchronously
[20:25] cremes	twomashi: correct so far...
[20:25] twomashi	Assuming thats right, if I fork my application, does that thread keep running in 2 separate processes?
[20:26] twomashi	It seems like I can't fork, because if I do I'll have one set of redundant background operations
[20:26] cremes	hmmm.... does fork also copy all threads or does it just copy the main?
[20:27] cremes	so i guess it's a question of the semantics of fork
[20:27] twomashi	I suppose it copies all of them,
[20:27] cremes	but assuming fork copies everything, i'd say that's a really bad idea :)
[20:27] twomashi	Rght
[20:27] twomashi	Right*
[20:27] cremes	don't fork
[20:27] twomashi	sort of a zeromq "gotcha"
[20:27] cremes	perhaps
[20:28] cremes	you might want to ask this question on the ML too; not everyone who can answer this question is awake right now
[20:28] twomashi	yep, fork duplicates threads too.
[20:28] twomashi	Yea, could do. I'm going to test this as a theory of why my app isnt working right tho
[20:28] twomashi	thanks
[20:33] cremes	np
[20:55] Guthur	Hehe, it's cool that CL is one of the most consistent language bindings providing examples from the guide
[21:35] takeda	Hey guys, how hard is it to add a new protocol to 0MQ?
[21:38] twomashi	you mean like make it speak http?
[21:39] takeda	well particularly I'm thinking http://www.ccnx.org/
[21:39] takeda	and use bindings
[21:40] takeda	the protocol is more like request response, though it doesn't guarantee delivery
[21:40] twomashi	no idea
[21:44] takeda	ok
[21:44] takeda	I just want to know if it's a waste of time or not
[21:45] twomashi	i dont really understand the fundamental issues
[21:45] twomashi	im sure there are others that do
[21:46] Guthur	From there own description it seems a little early for that protocol
[21:46] Guthur	Very much in the realms of research
[21:48] takeda	yeah, that's why I'm thinkinking to implement it myself only things that I would need in order to use the 0MQ bindings in other languages. The protocol is still research and I'm prototyping an application that would use it
[21:49] twomashi	0mq supports different transports so I guess they have an abstraction for that
[21:49] twomashi	socket, ipc, memory..
[21:50] takeda	yeah... the interface is clean, and also if I would need to use other ways it is consistent way of communicating :)