ZeroMq IRC Log

Friday July 22, 2011

[Time] Name	Message
[06:16] CIA-32	libzmq: 03Martin Sustrik 07master * r75c4e0e 10/ src/mailbox.cpp : mailbox::recv correctly passes EINTR to the caller ...
[06:35] CIA-32	libzmq: 03Martin Sustrik 07master * r5650743 10/ (builds/msvc/libzmq/libzmq.vcproj src/zmq.cpp): MSVC build brought up to date ...
[08:24] mvriel	Perhaps a silly question but can ZeroMQ also process vanilla TCP requests (thus sent via the socket extension of PHP for example
[08:24] mvriel	?)
[08:25] mvriel	I have a project which has the requirement to be compatible with plain TCP requests since it needs to operate with systems that do not communicate via ZeroMQ
[08:26] mvriel	I assume it is impossible but still wanted to ask (saves me a proxy)
[08:27] so_solid_moo	mvriel: I had a requirement like that; I just ended up with a little proxy that turned the tcp requests into zeromq
[08:29] mikko	mvriel: you need a proxy
[08:43] mvriel	so_solid_moo, mikko: thanks for the reply. Was afraid of that ;)
[09:09] pieterh	sustrik: is there an issue for 75c4e0e?
[09:10] sustrik	no
[09:10] sustrik	it was reported on the ML yesterday
[09:11] sustrik	sorry, not ML, on IRC
[09:11] sustrik	are you looking for a test case?
[09:12] so_solid_moo	mvriel: it's pretty easy to write, tbh
[09:12] pieterh	sustrik: I need a test case and someone to verify any fix
[09:12] pieterh	we have our contracts for backporting changes
[09:12] sustrik	cause a signal during a blocking call
[09:12] sustrik	say Ctrl+C
[09:12] pieterh	this was the Python issue?
[09:12] sustrik	no, it's libzmq issue
[09:12] sustrik	generic
[09:13] sustrik	blocking calls fail on signal
[09:13] mvriel	so_solid_moo: I had written one in the train; really easy. Just hoped I didn't have to have that point of failure / maintenance ;)
[09:13] sustrik	instead of returning EINTR
[09:13] pieterh	I know, but it was xristos reporting it via pyzmq, right?
[09:13] sustrik	i guess so
[09:14] pieterh	ok, I'll apply the fix to 2.1 master and ask him to test it
[09:14] pieterh	could you pretty please insist on people making Jira issues for bugs?
[09:14] pieterh	it is not correct to make fixes to code without a reference of some kind
[09:15] sustrik	well, it was an obvious error
[09:15] pieterh	as we try to maintain 3 or 4 versions, this gets more and more important
[09:15] pieterh	bug fixes absolutely need issue numbers
[09:15] sustrik	i've tried that kind of approach
[09:15] pieterh	look, sustrik, I'm asking for this
[09:15] sustrik	the problem being that people often do not create the issue
[09:15] pieterh	we have our contracts with users
[09:15] sustrik	and the bug remains in the codebase
[09:15] pieterh	if you send me random patches, it breaks the releases
[09:16] pieterh	we had two stable releases in a row that were broken like that
[09:16] pieterh	i'm not asking, this is a rule, if you can't respect it I'll be unable to maintain the codebases
[09:17] pieterh	i'm prepared to make test cases myself
[09:17] pieterh	but if I make the test cases and the issues then it's not safe
[09:17] sustrik	xristos: can you please create an issue in the bug tracker
[09:17] pieterh	and when you send me a patch, I need the issue number so I can properly find or make a test case
[09:18] pieterh	I do not want to have to ask you each time "what was this fix for and how do I test it?"
[09:18] sustrik	pieterh: in this case the problem is that you've backported an untested patch i haven't sent you
[09:18] pieterh	sustrik: you're kind of not reading what I'm writing here
[09:18] sustrik	the asserts in mailbox.cpp issue
[09:18] pieterh	yes, that happens, it's why we allow master to sit there for a while
[09:19] pieterh	new code going into stable is unavoidable sometime4s
[09:19] pieterh	this was a tradeoff, fix all the mailbox asserts, risk some new bugs
[09:20] pieterh	please review http://www.zeromq.org/docs:distributions#toc3 and tell me if there's anything there to change
[09:20] pieterh	this is a contract with our users
[09:22] sustrik	pieterh: ok, i have a proposal
[09:23] pieterh	sustrik: it's ok, I'm making a test case... I overreacted, sorry
[09:23] pieterh	lack of caffeine is toxic
[09:23] sustrik	n[
[09:23] sustrik	np
[09:23] sustrik	i don't want to leave the bugs in the codebase if it's reported but no issue is created
[09:23] sustrik	so what i can do is fix it in master
[09:23] pieterh	the problem is that unless there is quite strong structure, I will take shortcuts and trust your code implicitly
[09:23] sustrik	and ask people to create an issue
[09:24] pieterh	yes, and ask me to help making a test case
[09:24] sustrik	if there's no issue
[09:24] sustrik	the fix won't get into stable
[09:24] pieterh	when you have a test case against master, we can backport the fix and the testcase
[09:24] pieterh	i need (a) test case (b) issue and (c) external person to confirm fix
[09:25] pieterh	the NEWS for stable should just be a list of issue numbers (and this is what I managed to get, in the latest releases)
[09:25] sustrik	yes
[09:28] sustrik	anyway, in this case the test case could be: start perf/local_thr
[09:28] sustrik	press Ctrl+C
[09:29] pieterh	OK, I've confirmed the fix
[09:29] pieterh	I'll make a jira issue and create a test case in the issues repo
[09:30] sustrik	ok
[09:40] sustrik	pieterh: ok, the policy makes sense
[09:40] pieterh	ok, good
[09:40] pieterh	I've made an issue, tested the fix
[09:40] pieterh	now we need to ask xristos to test the new zeromq2-1 master...
[13:03] neale1	Hi, I'm trying to fix the s390x build - in particular the buildslave - and, apart from having to update automake, m4, autoconf, have found that -std=gnu99 is creating grief when used with gcc-4.3.2. Where grief is defined as: math.c:(.text+0x98): multiple definition of `gnu_dev_makedev'
[13:03] neale1	./.libs/libpgm_noinst.a(libpgm_noinst_la-thread.o):thread.c:(.text+0x98): first defined here
[13:03] neale1	./.libs/libpgm_noinst.a(libpgm_noinst_la-math.o): In function `stat':
[13:03] neale1	Getting rid of the autoconf AC_PROG_CC_C99 check circumvents the problem but I'm not sure that's a correct fix
[13:07] xristos	pieterh: 2-1 master works fine
[13:07] screen-dsuch	neale1: I've no idea how to help you but would like to say thanks for taking your time to make sure it works on z :-) (just a user here, not a dev)
[13:07] pieterh	xristos: yay! :-) thanks for the confirmation
[13:24] neale1	The problem relates to the following change in gcc: When compiling with -std=c99 or -std=gnu99, the extern inline keywords changes meaning. GCC 4.3 conforms to the ISO C99 specification, where extern inline is very different thing than the GNU extern inline extension. For the following code compiled with -std=c99
[13:53] samBiotic	hi all, is there a simple way of doing lan service discovery using zeromq without using zeroconf/bonjour/mdns?
[13:57] sustrik	samBiotic: no, there's no such in-build functionality in 0mq
[13:57] sustrik	of course you can create one using 0mq itself
[13:57] samBiotic	sustrik, thanks, that's a shame
[13:57] samBiotic	yes sure
[13:57] sustrik	say pub/sub on top of multicast
[13:58] samBiotic	i'm using the mdns library in node.js at the mo and it's a little sketchy
[13:58] pieterh	samBiotic: there is a way but it's not really simple
[13:58] pieterh	in the VTX project I have a UDP discovery service that integrates into 0MQ
[13:59] pieterh	https://github.com/imatix/vtx/blob/master/v3/vtx_locate.c is an example of use
[14:00] samBiotic	pieterh, thanks... looking
[14:00] pieterh	it would be fairly simple to reimplement in JS, if you have UDP sockets
[14:00] pieterh	https://github.com/imatix/vtx/tree/master/v1 shows a minimal client/server
[14:01] pieterh	it uses UDP broadcast to locate a listening server anywhere on the network
[14:11] samBiotic	pieterh, hmm look pretty good for my needs, thanks.
[14:11] samBiotic	looks*
[14:11] pieterh	samBiotic: nice, let me know how you get on with it...
[14:14] samBiotic	pieterh, i will, if I choose to move to a different transport protocol.
[14:21] screen-dsuch	pieterh: on a (not so) related note, what have you been using for drawing the diagrams, such as the one at https://github.com/imatix/vtx/raw/master/images/README_1.png ?
[14:22] pieterh	ditaa
[14:22] pieterh	also, gitdown, which wraps that up
[14:22] screen-dsuch	aha, cheers
[14:25] sustrik	neale1: hi, still here?
[14:33] neale1	Yes
[14:33] sustrik	hi
[14:34] sustrik	mikko: here by chance?
[14:34] sustrik	anyway
[14:34] sustrik	where's are the extern inlines?
[14:34] sustrik	i am not aware of such construct in 0mq codebase
[14:36] neale1	THey're not in 0mq or pgm. They are in std headers. I'm using gcc 4.3.2 on a SLES10 SP3 system. The glibc it uses has headers that cause the problem. I'm just wondering if the C99 check is actually required, otherwise I'll try and find a SLES11 system that should be ok.
[14:36] mikko	sustrik: yes
[14:36] mikko	partially
[14:36] sustrik	mikko: just discussing a build problem
[14:36] sustrik	just though you may have some insight
[14:38] mikko	looks like a very odd build error
[14:38] mikko	which distro is this?
[14:39] neale1	SLES10 SP3 s390x.
[14:39] mikko	does this happen with all code compiled with std=gnu99 ?
[14:42] neale1	It has happened with other packages I've built (I had to build m4 the other day because 0MQ requires autoconf/automake at a higher level than comes with SLES10 SP3 and it required me to get rid of the std=gnu99 or std=c99 stuff)
[14:43] mikko	hmm, should this issue be fixed in sles10 or zeromq ?
[14:43] mikko	it looks like a bug the shipped compiler
[14:44] mikko	does openpgm compile without c99?
[14:45] neale1	No, it's a case of 4.3.2 not being the compiler for SLES10 SP3 with the level of GLIBC that comes with it.
[14:45] mikko	ah
[14:45] mikko	i think the C99 is for openpgm
[14:45] neale1	Unfortunately not. mem.c: In function âpgm_parse_debug_stringâ:
[14:45] neale1	mem.c:84: error: âforâ loop initial declaration used outside C99 mode
[14:45] mikko	there is no code in zeromq that is compiled with c compiler
[14:47] neale1	Yes, it appears to be openpgm only (although 0MQ does include the C99 check in configure)
[14:49] mikko	maybe tests are C
[14:49] mikko	can't remember
[14:49] mikko	no, cpp
[14:49] mikko	well, they actually look like c code
[14:53] sustrik	mikko: they are C code
[14:53] sustrik	but are compiled as C++
[14:54] sustrik	to make the build system simpler iirc
[14:57] neale1	Just gonna have to move build system to SLES11 I guess. May take some time so s390x autobuilds will fail for some time to come
[14:57] mikko	neale1: thats fine
[14:57] mikko	i can put the node on scheduled maintenance
[15:02] neale1	k
[15:08] neale1	I have another build option. A fedora 14 system running behind a firewall. I'm attempting to fire it up to see if can get to your system.
[15:09] neale1	Apparently it can
[15:15] neale1	I'll see if this build works okay or if I have to update some things on that system too
[15:17] mikko	cool
[15:18] neale1	This is a MUCH slower machine than the previous box so build time will blow out considerably
[15:58] cremes	is 3.x planned to print better error messages users accidentally try to connect mismatched sockets? e.g. PUSH/SUB, PULL/PULL, etc
[15:58] ianbarber	that should be doable now there is the type in the wire format
[16:00] cremes	good to hear... i'm hoping some of these details are taken care of with the big 3.x change
[16:00] cremes	since we've been living with these problems since 2.0.x
[20:09] neale1	sustrik: Looks like we're back in business with s390x builds. 1st one completed ok.
[20:10] sustrik	great!