Friday July 22, 2011

[Time] NameMessage
[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 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 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 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 ?
[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!