Saturday August 28, 2010

[Time] NameMessage
[04:31] CIA-20 zeromq2: 03Guido Goldstein 07master * r67aa788 10/ (tests/test_pair.cpp tests/test_reqrep.cpp tests/testutil.hpp): Fixed socket states in tests -
[06:45] CIA-20 zeromq2: 03Martin Sustrik 07master * r035c937 10/ src/zmq.cpp : zmq_poll: account for the fact that ZMQ_FD is edge-triggered -
[06:45] CIA-20 zeromq2: 03Martin Sustrik 07master * r92923cd 10/ (4 files in 2 dirs): bug in pipe deactivation fixed -
[08:35] guido_g oh ich checked things in while i was dreaming...
[08:35] guido_g thanks
[09:04] sustrik np
[09:05] sustrik pieterh: i think people are starting to have problems with navigating through
[09:05] guido_g i'm going to change the tests so that all transports are tested
[09:05] sustrik there's too much content and too little structure
[09:05] sustrik guido_g: great
[09:05] sustrik btw, i've fixed the poll bug
[09:05] guido_g greater!
[09:05] sustrik but there are other bugs still lurking around
[09:06] sustrik it'll take couple of days to make the trunk reasonable stable
[09:06] guido_g what about some output from the tests, so one can actually see which test failed on which transport?
[09:06] sustrik it works that way
[09:06] sustrik i see the assert
[09:06] guido_g the asserts are a little sparse i think
[09:07] sustrik it leads you directly to the test program failed
[09:07] sustrik and to the right line number
[09:07] sustrik which is pretty good
[09:07] guido_g yes, but imagine the tests are run 3 times each with a different transport
[09:07] guido_g you don't know wich transport failed
[09:08] guido_g it's the same code line
[09:08] sustrik hm, what about putting the test body itself into a common header file
[09:08] sustrik and having multiple mains to use it?
[09:08] guido_g we're approaching a test framework... :/
[09:09] guido_g for the simple tests that are in the repo now, this will work fine
[09:09] sustrik i, as a developer, have a single requirement:
[09:09] sustrik 'make check' should report which executable had failed
[09:09] sustrik then i can run it myself and debug it
[09:09] guido_g ok
[09:11] guido_g as i said yesterday, maintainting lots of test programs will not make it easier
[09:11] sustrik the nice thing about test programs is they are self-maintaining
[09:12] sustrik in the sense that if you break them your tests faile
[09:12] sustrik => you have to fix it
[09:12] guido_g yes, but if you see 20 programs fails, it's easyier to comment them out in the makefile
[09:12] guido_g i've seen that in practice, so...
[09:13] sustrik yuck
[09:13] guido_g ack
[09:13] sustrik tests should _not_ fail
[09:13] sustrik tests should be a whip to drive the developers towards perfect code :)
[09:14] sustrik commenting tests out makes them useless
[09:14] guido_g still it has been done
[09:14] sustrik no doubt
[09:14] guido_g and it hasnt been a hobby project
[09:14] guido_g anyway
[09:15] guido_g going to make the tests transport aware
[09:15] sustrik ack
[09:17] guido_g you added an assert(false) after the return in test_pair, why?
[09:18] sustrik uh
[09:18] sustrik sorry
[09:18] guido_g ok, i'll remove it then
[09:19] sustrik yes, please
[09:19] sustrik i'll fix it in the git
[09:19] guido_g dont't, i'll change the files anyway
[09:19] sustrik ok
[09:36] guido_g sustrik_: this is what i've in mind, comments please
[10:19] sustrik guido_g: looks fine
[10:20] sustrik i would however prefer to have the main split into three different mains
[10:20] sustrik it's not that much work, mostly copy-and-paste
[10:20] sustrik and it's helpful for debugging
[10:20] sustrik i.e. you can debug only the use case that fails
[10:21] sustrik rather than having to run the whole batch
[10:42] guido_g ok, i'll do it
[10:50] mato hi guys
[10:51] guido_g hi mato
[10:51] guido_g PASS: simple
[10:51] guido_g PASS: test_reqrep
[10:51] guido_g PASS: test_pair_inproc
[10:51] guido_g PASS: test_pair_ipc
[10:51] guido_g ==================
[10:51] guido_g All 4 tests passed
[10:51] guido_g ==================
[10:51] mato yay
[10:51] guido_g ha! :)
[10:51] mato good stuff :-)
[10:51] mato sustrik has good points about the test programs
[10:52] mato i like it
[10:52] guido_g going to do it his way
[10:52] mato it's the right way :-)
[10:52] guido_g by definition ,)
[10:52] mato indeed
[10:53] guido_g don't be mad at me, i'm going to remove the simple.cpp from the tests
[10:53] mato guido_g: hey, it's just a placeholder
[10:53] mato feel free to take it out, but people could use it as a template maybe?
[10:54] guido_g the other tests are as small
[10:54] guido_g and do show how to handle the naming and stuff
[10:54] mato sure, go for it
[10:54] mato i just added something so you had a test to start with
[11:27] CIA-20 zeromq2: 03Martin Sustrik 07master * r42000d2 10/ (7 files): terminology unified: revive->activate -
[11:27] CIA-20 zeromq2: 03Martin Sustrik 07master * rd90b407 10/ (src/pipe.cpp src/pipe.hpp): refactoring of pipe/swap interaction -
[11:27] CIA-20 zeromq2: 03Martin Sustrik 07master * rd8b975f 10/ (7 files): msg_store_t renamed to swap_t -
[11:27] CIA-20 zeromq2: 03Martin Sustrik 07master * rbeea535 10/ (src/config.hpp src/swap.cpp src/swap.hpp): swap's block size made into a compile-time parameter -
[11:27] CIA-20 zeromq2: 03Martin Sustrik 07master * r6ec783e 10/ (6 files): prefix_tree_t renamed to trie_t -
[11:35] sustrik mato: btw, the problem in zmq_poll was with the fact that ZMQ_FD is edge triggered
[11:45] mato sustrik_: please elaborate....
[11:46] sustrik some messages may have already been delivered to the socket
[11:46] sustrik waiting to be received
[11:46] sustrik if that's the case ZMQ_FD won't signal
[11:47] sustrik so you have to check events first
[11:47] sustrik then poll
[11:47] sustrik otherwise poll may block even though there are messages available
[11:47] sustrik i've already fixed it, please, do review
[11:48] sustrik guido_g:
[11:48] sustrik cc1plus: warnings being treated as errors
[11:48] sustrik test_pair_inproc.cpp:25: error: ‘TEST_NAME’ defined but not used
[11:48] mato i'll review it soonish, fighting some client panic here
[11:49] sustrik ok
[11:58] CIA-20 zeromq2: 03Guido Goldstein 07master * r0a8473d 10/ (11 files): Added tests for transports per socket -
[12:04] guido_g ok, i'll remember that
[12:07] CIA-20 zeromq2: 03Martin Sustrik 07master * r68d62cf 10/ builds/msvc/libzmq/libzmq.vcproj : MSVC build fixed -
[12:09] sustrik re
[12:10] guido_g wb
[12:11] sustrik i've commited your latest tests
[12:11] guido_g yes, thx
[12:11] sustrik all seem to pass on my box
[12:11] guido_g here too
[12:15] guido_g but one of the other test programs segfaults now in poll
[12:22] sustrik guido_g: which other test?
[12:22] sustrik mato: there's one problem with the new connection with the same identity
[12:22] guido_g the program i discovered the poll bug in yesterday
[12:23] sustrik ah, the one with the timeout?
[12:23] mato sustrik: are the two assertions i'm seeing the same issue?
[12:23] sustrik mato: can be
[12:23] mato sustrik: one on the receiving end, and one on the connecting end?
[12:23] sustrik quite possible
[12:23] mato sustrik: would seem to make sense from the behaviour i'm seeing
[12:23] sustrik anyway, when fixing it
[12:23] guido_g sustrik: no, poll w/o timeout but threads
[12:24] sustrik you have to drop one of the connections
[12:24] sustrik if you drop the new one
[12:24] sustrik you have no way to force hanged connection to go away
[12:24] sustrik it you drop the old one
[12:25] sustrik two clients with same identities create a busy loop of connecting & dropping
[12:25] mato hang on
[12:25] sustrik guido_g: can you pass the test?
[12:25] mato sustrik: the thing is, it's the same client
[12:25] sustrik oh
[12:25] mato sustrik: the client is *not* being restarted
[12:26] sustrik server is restarted?
[12:26] guido_g <- using the zmqcpp program with the sender program gives segfault in poll according to ltrace
[12:26] sustrik guido_g: thx
[12:26] mato no, nothing is restarted
[12:27] guido_g sustrik: using ømq master from just before your msvc commit
[12:27] sustrik mato: so what do you do?
[12:27] sustrik guido_g: ok
[12:27] mato sustrik: i don't know if i can discuss it here :(
[12:27] guido_g i'll close my eyes then :)
[13:31] sustrik pieter_hitnjens: are you there?
[13:46] speedy1 hey guys, does 0mq work well when compiled for x64 arch on windows, visual studio 2008 SP1?
[13:48] speedy1 compilation goes through but gives lots of warnings like
[13:48] speedy1 1>..\..\..\src\zmq_engine.cpp(97) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
[13:48] speedy1 on line insize = (inpos, insize);
[13:49] speedy1 zmq_engine.cpp
[13:50] speedy1 for example this is conversion betwenn unsigned and signed int
[13:53] speedy1 and it looks like it would work ok
[13:54] speedy1 but it's kinda bad coding style to mix unsigned and signed ints like that
[13:59] sustrik speed1: i don't have a win64 box
[13:59] sustrik feel free to submit a patch
[14:01] speedy1 ok, can I submit it to you?
[14:02] guido_g who's the moderator of the ml? the last patch mail seems to be to big :/
[14:03] guido_g added generated file to pacht
[14:03] guido_g *patch
[14:05] sustrik guido_g: i've already allowed itr
[14:05] guido_g oh thx
[14:05] sustrik sppedy1: just generate the patch and send it to the mailing lis
[14:05] sustrik list
[14:05] sustrik stating it's submitted under MIT license
[14:06] guido_g stay below 40kb :=)
[14:06] speedy1 :)
[14:06] speedy1 do you have an open SVN repository?
[14:07] speedy1 ah its git - ok
[14:07] sustrik it's git repo
[14:07] guido_g it's on github
[14:34] speedy1 yo keffo :)
[15:24] keffo yoyo! :)
[18:19] pieter_hintjens martin_sutsirk: yo!
[19:31] keffo rawr, I calc pi :)
[19:55] keffo ah, this is so coool!
[20:04] andrewvc Question, what's the recommended way to stop a thread blocked on recv?
[20:06] andrewvc or are you just not supposed to do that?
[20:19] pieter_hintjens andrewvc: stop all threads by killing context
[20:19] pieter_hintjens stop one thread by sending it a message
[20:21] pieter_hintjens what this means in practice, I think, is using a second control socket and zmq_poll rather than zmq_recv
[20:21] andrewvc gotcha, interesting
[20:22] pieter_hintjens reactors are one example
[20:23] andrewvc thanks pieter, I'l definitely look into that
[20:27] KBrock Anyone know just how sensitive to cancelation slot zmq is internally? I.e. after a reset_pollout, will zmq deal with data that comes in unexpectedly ok or will it get pissy?
[20:28] KBrock *slop
[20:32] pieter_hintjens KBrock: polling does not affect message arrival processing
[20:33] pieter_hintjens only signaling to calling app
[20:33] KBrock Well, I'm working on the IOCP stuff, worried about some of the internal behavior.
[20:34] KBrock IOCP doesn't work even vaguely like kevent/epoll. :)
[20:34] pieter_hintjens you'll have to ask Sustrik
[20:34] KBrock Well, going to give it a try. Suspect I'll get fireworks.
[20:34] pieter_hintjens i suspect the closer you can emulate kevent/epoll the better
[20:35] pieter_hintjens but having never used IOCP that is just unfounded opinion :-)
[20:35] KBrock Yup, but canceling things is nasty under IOCP. :(
[20:35] pieter_hintjens how so?
[20:36] KBrock Well, you actually perform the recv/send "first" and then wait for success on the port. Instead of kevent/epoll where you wait for available buffer space on the socket.
[20:36] pieter_hintjens right, i'm reading about iocp now...
[20:37] KBrock I'm going to try the slow way and request 0 byte read/writes and just monitor for activity but it's still not a very comparable thing.
[20:37] pieter_hintjens you're using this to do inproc: or to do kevent/epoll?
[20:37] pieter_hintjens sorry
[20:37] pieter_hintjens ipc:
[20:37] KBrock I'm just throwing this together really quick and stupid to see what a proper version will require.
[20:38] pieter_hintjens good... luck...
[20:38] KBrock sockets/pipes only right now.
[20:38] pieter_hintjens :-)
[20:39] KBrock Yeah, it's unfortunate that Winblows has to be such a pain in the ass sometimes. Not to mention that's the platform I'm paid to work on. :)
[20:42] KBrock Hate when things work the first time.. :)
[21:15] KBrock Anyone have a copy of the head branch available for a code comparison check?
[21:15] KBrock socket_base.cpp line 162 looks like the comparison is supposed to be "==" ?
[22:23] CIA-20 pyzmq: 03Brian Granger 07master * r6633c5d 10/ (zmq/_zmq.c zmq/_zmq.pyx): Added comment about PyEval_InitThreads(). -
[22:44] CIA-20 pyzmq: 03Brian Granger 07master * r42a1472 10/ README.rst : Updating README.rst with build info for Windows and Linux. -