ZeroMq IRC Log

Saturday August 28, 2010

[Time] Name	Message
[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 - http://bit.ly/cC6CA7
[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 - http://bit.ly/9RVhvI
[06:45] CIA-20	zeromq2: 03Martin Sustrik 07master * r92923cd 10/ (4 files in 2 dirs): bug in pipe deactivation fixed - http://bit.ly/azqLvw
[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 zeromq.org
[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_: http://gist.github.com/554955 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 - http://bit.ly/cg8yex
[11:27] CIA-20	zeromq2: 03Martin Sustrik 07master * rd90b407 10/ (src/pipe.cpp src/pipe.hpp): refactoring of pipe/swap interaction - http://bit.ly/bwmYWY
[11:27] CIA-20	zeromq2: 03Martin Sustrik 07master * rd8b975f 10/ (7 files): msg_store_t renamed to swap_t - http://bit.ly/cHT1MH
[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 - http://bit.ly/9fAL4u
[11:27] CIA-20	zeromq2: 03Martin Sustrik 07master * r6ec783e 10/ (6 files): prefix_tree_t renamed to trie_t - http://bit.ly/bVnAyB
[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 - http://bit.ly/c9dA8c
[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 - http://bit.ly/aut9jg
[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	http://github.com/guidog/cpp/tree/master/zmqcpp/ <- 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 = tcp_socket.read (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 http://github.com/zeromq/zeromq2
[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(). - http://bit.ly/b42OTG
[22:44] CIA-20	pyzmq: 03Brian Granger 07master * r42a1472 10/ README.rst : Updating README.rst with build info for Windows and Linux. - http://bit.ly/dbBzus