ZeroMq IRC Log

Friday August 27, 2010

[Time] Name	Message
[03:01] andrewvc	cremes, you around?
[03:03] AndrewBC	Woah, hi. :D
[03:10] andrewvc	we have similar names eh?
[03:21] AndrewBC	Indeed
[03:27] andrewvc	Quick question about pub/sub if anyone's got a moment
[03:28] andrewvc	is it best practice to send the topic separately with SNDMORE, then send the rest separately? Or is that just optional. I've seen examples both using and not using that technique
[04:24] sustrik	andrewvc: it's up to you
[04:24] sustrik	there's no fundmantal difference between the two
[04:25] sustrik	other than in the former case the "topic" is cleanly separated from the "body"
[04:36] sustrik	cremes, andrew_cholakian: no, it's OK to use context from multiple threads
[04:36] sustrik	just use each socket only in the thread it was created in
[04:59] CIA-20	zeromq2: 03Jon Dyte 07master * r3cb84b5 10/ (src/forwarder.cpp src/queue.cpp src/streamer.cpp): forwarder and streamer devices handle multi-part messages correctly - http://bit.ly/b55mvk
[09:33] guido_g	anyone experienced a problem with zmq::poll?
[09:34] guido_g	_sometimes_ it doesn't sent revents correctly, as it seems
[09:34] guido_g	it returns with a return value of 0, ignoring the received messages
[09:35] guido_g	ÃMQ version is latest from zeromq/zeromq2
[09:36] theICEBeardk	Is it like this issue http://github.com/zeromq/zeromq2/issues#issue/7 ?
[09:36] guido_g	reading...
[09:37] guido_g	we have an issue then :)
[09:37] guido_g	yep, seems to be the same problem
[09:39] guido_g	any ideas why this happens?
[09:39] theICEBeardk	I hope the workaround in the issue can help you
[09:39] theICEBeardk	None
[09:41] guido_g	scary that no one seems to be interested in this issue
[09:41] guido_g	it renders nearly everything useless
[09:41] theICEBeardk	agreed
[09:43] theICEBeardk	Maybe the devs can't verify the problem or reproduce it. What platform are you on?
[09:43] guido_g	GNU/linux Debian testing w/ 2.6.35 kernel
[09:44] theICEBeardk	Okay nothing too obscure then :)
[09:44] guido_g	ouch...
[09:44] guido_g	the problem in the issue is different
[09:45] guido_g	i had a timeout of -1
[09:46] guido_g	the code says that errors other then EINTR are to be ignored
[09:48] theICEBeardk	hmm, if you have some test code, I have to do the unhelpful thing and suggest you raise the issue on the github.
[09:48] theICEBeardk	I know it doesn't help much.
[09:49] guido_g	sure
[09:55] guido_g	okay... on a different machine it works
[09:56] theICEBeardk	Different os or just a different machine?
[09:57] guido_g	same os, a little bit older, kernel 2.6.27.31
[09:57] guido_g	and older Ã¸mq lib
[09:57] guido_g	from jul 15
[09:57] guido_g	hmm hmm hmm
[09:58] theICEBeardk	ah a release and not from github
[09:58] sustrik	guido_g: what timeout do you use?
[09:58] guido_g	-1
[09:58] guido_g	hi sustrik btw :)
[09:58] sustrik	hello :)
[09:59] sustrik	hm, that should never return 0
[09:59] guido_g	http://github.com/guidog/cpp/tree/master/zmqcpp/ <- code is receiver_poll.cpp and sender.cpp
[09:59] sustrik	0 means "timeout"
[09:59] guido_g	right
[10:00] sustrik	that's 2.0.8 you are using?
[10:00] guido_g	yes
[10:00] sustrik	let me have a look...
[10:00] guido_g	cloned a few hours ago
[10:01] sustrik	2.0.8 or trunk?
[10:02] sustrik	the zmq_poll code have changed immediately after 2.0.8 release
[10:02] guido_g	then it is trunk i fear
[10:02] sustrik	ok, wait a sec
[10:03] sustrik	are you using windows or something else?
[10:04] guido_g	nope, GNU/linux Debain testing
[10:04] sustrik	ok
[10:05] guido_g	ok, now same on the other machine that worked with 2.0.7
[10:05] sustrik	guido_g: ok, the new version is buggy
[10:05] guido_g	so there is something wrong in zmq
[10:06] sustrik	the whole zmq_poll functionality should be in loop
[10:06] sustrik	and restart the loop if there are no events to return
[10:07] sustrik	it was like that in the old version
[10:07] sustrik	doesn't appear to be like that now...
[10:07] guido_g	2.0.8 is safe?
[10:07] sustrik	yes
[10:07] sustrik	mato: summon!
[10:07] pieterh	guido_g: would it be easier if there was a branch "stable" for 2.0.8?
[10:07] sustrik	bug in zmq_poll!
[10:07] guido_g	pieterh: YES!
[10:07] guido_g	:)
[10:07] pieterh	ok, please harass Mato about that
[10:08] guido_g	or have a brachn vor this kind of development, so that master is always tested
[10:09] pieterh	hah
[10:10] pieterh	master should be tested, of course
[10:10] pieterh	some disagreement about whether new code goes to master or 'develop' branch
[10:10] guido_g	develop, please
[10:11] guido_g	'cause this was half a day of fuzzing for me on the software that worked
[10:11] guido_g	before the update
[10:11] pieterh	please make your wishes known to mato
[10:11] guido_g	send location pls ]:->
[10:12] pieterh	via zeromq-dev list, guido_g
[10:12] guido_g	oh...
[10:12] pieterh	i'd suggest simply state your requirements as user of the git
[10:12] pieterh	perhaps referencing practice of other projects
[10:12] sustrik	yes, that's the best
[10:13] guido_g	sure, going to write a mail
[10:13] sustrik	the issue is not that easy as in the future there can be several stable versions etc.
[10:13] pieterh	sustrik: yes, indeed
[10:13] guido_g	then we should have release branches
[10:13] pieterh	but only one (max two) maintained stable version, normally
[10:14] pieterh	guido_g: that would seem obvious but... last time i suggested that it was not welcomed
[10:14] pieterh	however i think mato is coming round to that point of view
[10:15] guido_g	pieterh: i remember there was something...
[10:15] pieterh	up to now releases have been tags
[10:15] guido_g	ok, then
[10:15] pieterh	after 2.0.8 we immediately got a patch (zmq_term)
[10:15] guido_g	how do i get the 2.0.8 release out of github?
[10:15] pieterh	lol
[10:15] pieterh	well, it's tagged
[10:15] pieterh	checkout from the tag
[10:16] pieterh	it should work obviously for git n00bs IMO
[10:16] pieterh	none of us are linux kernel hackers
[10:17] sustrik	no way it could work without knowing how to check out a branch
[10:17] sustrik	i had that last week
[10:17] sustrik	i had a branch i wasn't able to access
[10:17] sustrik	i think it's something like:
[10:18] sustrik	git checkout -b name-of-the-branch remotes/origin/name-of-the-branch
[10:20] pieterh	sustrik: you had an old version of Git
[10:20] pieterh	actually that command was also documented in the original proposal I made
[10:21] guido_g	git show v2.0.8 <- shows commit
[10:21] pieterh	but with git 1.7 you no longer need to specify the remote
[10:21] guido_g	git reset <commit> seems to work
[10:21] pieterh	yes, the tag is just a nicer name for the commit id
[10:22] pieterh	problem is that once we need to maintain a stable release, we can't use tags
[10:22] pieterh	so all the commands change
[10:22] sustrik	:(
[10:22] pieterh	it become git checkout branchname
[10:22] pieterh	not git reset tagname
[10:22] pieterh	that's why i'd prefer a branch, always, for the last stable release
[10:23] pieterh	so it's always "git checkout master" or "git checkout stable" or "git checkout develop"
[10:23] guido_g	right
[10:23] guido_g	ok, 2.0.8 works
[10:23] pieterh	then we can argue about whether master is the bleeding edge, or not
[10:23] sustrik	pieterh: a patch without MIT in the mailing list
[10:24] pieterh	sustrik: yeah, but it's a 1-line change...
[10:24] sustrik	should i ignore it?
[10:24] guido_g	pieterh: wasn't that you who posted that link to http://nvie.com/git-model?
[10:24] pieterh	... i don't think copyright applies to single line fixes
[10:25] pieterh	guido_g: someone else posted it, i tried it, it's great but way too complex for our needs
[10:25] guido_g	ok
[10:25] sustrik	if it does and if i apply the patch, project is stuck with current license forever
[10:25] pieterh	sustrik: I'd much rather have patches arriving on a website/wiki/issue tracker where it says in huge letters, BY SUBMITTING A PATCH YOU ETC.ETC.
[10:25] sustrik	should i proceed?
[10:26] sustrik	yes/no
[10:26] pieterh	i'll do the necessary, sustrik
[10:26] pieterh	hang on...
[10:27] pieterh	done
[10:28] pieterh	sustrik: if I had to receive patches I'd set-up an issue tracker where anyone posting a patch had to register and accept terms of use that clearly stated the licensing for their contributions
[10:28] pieterh	email is really suboptimal for this except that it lets everyone see the patch (do people actually review it?)
[10:28] sustrik	it should be clear what the licensing is
[10:29] pieterh	there should be a template for each patch
[10:29] sustrik	please write an email explaining what the current contribution policy is
[10:29] pieterh	it's not changed
[10:29] pieterh	it is documented on the website afair
[10:30] sustrik	the anouncement about a community project have confused people
[10:30] pieterh	http://www.zeromq.org/area:contribute
[10:30] sustrik	so make it clear that it's still not in effect
[10:30] pieterh	"Please send it to the developer mailing list and explicitly state that you are licensing the patch under the MIT/X11 license."
[10:30] pieterh	sustrik: if this was the cause of confusion people would be submitting patches under LGPL
[10:31] pieterh	that's not the problem here IMO
[10:31] pieterh	it's just that there is no automation of this
[10:31] sustrik	they do
[10:31] pieterh	i missed that
[10:31] sustrik	patch to LGPL'd project is a derivative work thus LGPL
[10:32] pieterh	not necessarily
[10:32] pieterh	a patch that is not explicitly licensed under LGPL is simply unusable
[10:32] pieterh	if you redistribute code with incorrect licensing you can be asked to change it
[10:33] pieterh	however it's not automatic
[10:34] pieterh	no matter what policy there is, the author of a patch MUST license it, or it falls under simple copyright and cannot be reused, period
[10:34] sustrik	how does linux kernel process work then?
[10:34] pieterh	presumably all contributors sign off somewhere along the line
[10:34] sustrik	how does that work?
[10:35] pieterh	i don't know how it works in the linux kernel process, martin
[10:35] sustrik	what I see is just signed-of-by someone
[10:35] sustrik	no mention of licensing
[10:35] pieterh	however try to submit random piece of code without license, see what happens
[10:35] sustrik	that's the standard
[10:36] pieterh	note how it works for the www.zeromq.org site
[10:36] pieterh	sorry, i need to catch a plane
[10:36] sustrik	ok, cya
[10:36] pieterh	the sane model is upfront agreements
[10:36] guido_g	have a safe trip
[10:36] pieterh	when you join a community you agree (once) about licensing your contributions
[10:36] pieterh	thanks
[10:37] pieterh	this is the problem with the mailing list
[10:37] pieterh	you can fix it, but i'm repeating myself, by putting patches via a web site of some kind
[10:37] pieterh	where you accept Terms of Use and IP Policy when you join
[10:37] pieterh	cyal
[13:01] CIA-20	zeromq2: 03Martin Sustrik 07master * r56faac7 10/ src/zmq.cpp : zmq_poll returns prematurely even if infinite timeout is set - fixed - http://bit.ly/8XghUD
[13:16] keffo	any particular reason why the null delimiter between routinginfo and payload thinks it's size is 17?
[13:16] sustrik	that's not a delimiter
[13:16] sustrik	that's an identity
[13:16] sustrik	if you don't set the identity yourself
[13:16] sustrik	0mq generates one
[13:16] sustrik	it's an UUID (in binary form) thus 16 bytes
[13:17] sustrik	+binary zero at the beginning to distinguish it from user defined identities
[13:17] sustrik	summa summarum 17 bytes
[13:17] keffo	ah makes sense
[13:19] mato	sustrik: hmm, so a fd returned by ZMQ_FD can still become ready even if there are no events?
[13:20] sustrik	well, there are events, such as "new connection established"
[13:21] sustrik	but these don't map directly to pollin/pollout
[13:21] sustrik	anyway, i've fixed it
[13:21] mato	sure, but isn't that exposing an implementation detail to the api?
[13:22] sustrik	if there was a workaround i would use it :(
[13:22] sustrik	the whole ZMQ_FD thing is a hack
[13:22] sustrik	0MQ socket should be a _real_ file descriptor
[13:23] mato	yes, yes, but i'm talking about the current state of affairs, not the ideal state of affairs in five years time
[13:23] sustrik	well, the current state of affairs looks like this
[13:23] sustrik	i think you cannot really fix it
[13:24] mato	isn't this because the fd returned by ZMQ_FD is zeromq's internal signalling fd?
[13:24] sustrik	yes
[13:24] mato	ok, and, hypothetical question, couldn't ZMQ_FD return a fd that only responds to a subset of the events (i.e. those exported to the API)
[13:25] sustrik	how would you filter out the other events
[13:25] sustrik	?
[13:25] mato	well, the naive idea is that ZMQ_FD actually registers a 2nd signalling fd internally
[13:26] mato	and the signalling stuff only signals the events exported to the user on that fd
[13:26] sustrik	then you have a synchronisation problem
[13:26] sustrik	how to get two signal streams into sync
[13:28] mato	right, because the signalling is also used for synchronization
[13:28] sustrik	exactly
[13:28] sustrik	on a different thread: how is submitting patches done on LKML?
[13:28] sustrik	there doesn't seem to be explicit licensing mentioned
[13:28] mato	ah, yes, i saw the discussion
[13:28] mato	yes there is
[13:28] mato	and i wrote an email about it at least once to the ml
[13:29] sustrik	which one was that?
[13:29] mato	email?
[13:29] sustrik	yes
[13:30] mato	sustrik: see my replies to Pieter's RFC: ÃMQ Contributions, Copyrights and Control thread
[13:30] sustrik	on the wiki?
[13:30] mato	no
[13:30] mato	on email
[13:31] sustrik	"Apropos contributions, to ensure we don't run afoul of any licensing
[13:31] sustrik	problems I think it would be useful to institute a "Certificate of Origin"
[13:31] sustrik	policy using Signed-Off-By: tags in patches or Git commits, similar to what
[13:31] sustrik	is done by the Linux kernel.
[13:31] sustrik	"
[13:31] sustrik	that's it?
[13:31] mato	i also explain in another reply i think where the Linux guys explain that
[13:32] mato	http://lxr.linux.no/#linux+v2.6.35/Documentation/SubmittingPatches
[13:32] mato	see point 12) in that document
[13:32] mato	basically the presence of Signed-Off-By: on a patch or Git commit indicates acceptance of the "Developer's Certificate of Origin"
[13:33] mato	so, patches w/o a Signed-Off-By: cannot be applied (or discussed in fact, the sender should just be told to go read SubmittingPatches)
[13:33] mato	the Signed-Off-By: tag(s) propagate from the patch into Git
[13:33] mato	and are thus kept as history
[13:34] mato	git also has direct support for Signed-Off-By
[13:34] sustrik	how is the certificate bound to signed-off-by?
[13:34] mato	by using -s on commits, or configuring your Git install/repo to automatically sign commits
[13:34] sustrik	does the developer have to sign some agreement in advance?
[13:34] mato	no
[13:35] mato	why should they?
[13:35] mato	they must add the Signed-Off-By
[13:35] mato	if they add it, it states their agreement with the certificate
[13:35] mato	i don't see the problem
[13:35] sustrik	what's the legal procedure to infer that you've signed the certificate
[13:35] sustrik	if you've filled up the signed-off-by?
[13:36] mato	you don't "sign" the ceritifcate
[13:36] mato	IANAL, but your adding of the Signed-off-by: states your intent of agreement with the ceritifcate since it's in the project policy (SubmittingPatches in this case)
[13:37] sustrik	sounds pretty creaky from legal point of view
[13:37] sustrik	IANAL myself
[13:37] mato	well, it was explicitly introduced after the SCO affair IIRC
[13:38] mato	so it must be "good enough" for Linux...
[13:38] sustrik	presumably
[13:38] sustrik	i just don't see the link between certificate and the signed-off-by field
[13:38] sustrik	i can write a different certificate
[13:39] sustrik	and say you agree with it if you fill in siged-off-by
[13:39] sustrik	then i will claim linux for myself
[13:39] sustrik	muahaha
[13:40] mato	sustrik: well, if you're really worried, ask some of our lawyer friends for an opinion
[13:40] mato	i see it as a much better alternative to the business of someone writing in email "Yes, that patch is submitted under MIT"
[13:41] mato	there is of course no perfect alternative
[13:41] sustrik	yes. it's much better
[13:41] mato	unless you want to force people to go through silly click-through agreements (the legality of which is questionable anyway)
[13:41] sustrik	but i simply don't understand how it works
[13:41] sustrik	is it a contract between Linus Torvalds and the developer?
[13:42] sustrik	who'e the authority to impose particular working of the certificate and accept the sing-off-by's?
[13:42] sustrik	wording*
[13:43] mato	http://kerneltrap.org/node/3180
[13:44] mato	there is Linus' original request for discussion from 2004
[13:44] mato	sustrik: anyway, what is your worry? that it's legally unenforceable?
[13:45] sustrik	nope
[13:46] sustrik	i'm just wondering about what pieter said that patch for GPL'd code is not necessarily a GPL code itself
[13:46] sustrik	so that when you are submitting a patch you have to explcitly state that it's GPL
[13:46] sustrik	or LGPL
[13:46] sustrik	or whatever
[13:47] sustrik	the sign-off-by afaics is only a tracking feature
[13:47] sustrik	not meant to explicitly state what license the patch is submitted under
[13:49] sustrik	to my naive understanding, sending the patch to the mailing list constitutes the act of "distribution"
[13:49] mato	did you read the certificate?
[13:49] mato	(d) I understand and agree that this project and the contribution 319 are public and that a record of the contribution (including all 320 personal information I submit with it, including my sign-off) is 321 maintained indefinitely and may be redistributed consistent with 322 this project or the open source license(s) involved.
[13:49] sustrik	and?
[13:50] sustrik	what i mean it doesn't even look to be a contract
[13:50] sustrik	there's only one party involved
[13:50] sustrik	that's kind of strange
[13:51] mato	it's a compromise to lower the overhead of contributing
[13:51] mato	if you want a legal opinion, ask a lawyer
[13:51] sustrik	shrug
[13:52] sustrik	it's tracking system
[13:52] sustrik	it's explicitly state in the preamble
[13:52] sustrik	To improve tracking of who did what, ...
[13:52] mato	feel free to suggest something better
[13:52] sustrik	it's automatic IMO
[13:52] mato	go and research how other sucessful projects do it
[13:53] sustrik	patch of GPL'd work is a derivative work
[13:53] sustrik	when you send it to the ML it's "distributed"
[13:53] sustrik	so you are obliged to do it under the same license
[13:53] mato	yes, but the point of signed-off-by is to track the original person claiming the right to distribute
[13:53] sustrik	sure, that's ok
[13:54] sustrik	what i was talking about was that pieter says the above reasoning doesn't apply
[13:55] mato	shrug :)
[13:55] sustrik	to my understanding linux relies on it and uses sign-off-by as an additional tracking measure
[13:55] mato	it seems it's either that or signing over copyright explicitly
[13:56] sustrik	yes
[14:17] sustrik	GPLv2 says that modified versions, if released, must be âlicensed â¦ to all third parties.â
[14:22] guido_g	sustrik: just tested the latest master version, poll still not working
[14:24] sustrik	what happens?
[14:25] guido_g	nothing on first req
[14:25] guido_g	then it hangs sometimes after 2nd or 3rd message
[14:25] sustrik	nothing = exits with 0
[14:25] guido_g	going to put the debug output back into my test programs
[14:25] sustrik	?
[14:26] guido_g	wait a second
[14:26] guido_g	now poll does not return when a message has been sent
[14:27] sustrik	hangs, right
[14:27] sustrik	that's poll on the rep side of req/rep pair, right?
[14:28] guido_g	these changes really should go into a branch
[14:28] guido_g	yes, req -> xrep (with poll)
[14:28] guido_g	code is http://github.com/guidog/cpp/blob/master/zmqcpp/receiver_poll.cpp
[14:29] sustrik	let me try
[14:36] sustrik	ok, reproduced
[14:38] guido_g	ahh, good to know ,)
[14:39] cremes	is there any long term plan to add some behavioral testing to 0mq so we can quickly catch regressions?
[14:40] guido_g	or better a short term one?
[14:41] mato	cremes, guido_g: good point, i've also been thinking about this
[14:42] guido_g	mato: while you're here: how do i get the stable (not fuxxed up) 2.0.8 from github w/o typing for an hour?
[14:42] mato	i'm not a fan of the various TDD methodologies, but having at least a baseline "make test" that verifies that things more or less work would be a good start
[14:42] cremes	http://thechangelog.com/post/268009308/cspec-bdd-for-c
[14:42] mato	guido_g: 1) clone the repo 2) git checkout v2.0.8 :)
[14:43] guido_g	you can checkout a tag?
[14:43] mato	sure you can
[14:43] cremes	guido_g: check the ML; i posted an answer to this 1 or 2 days ago
[14:43] mato	you can't easily base work off that tag w/o turning it into a branch, but that's a different issue
[14:44] guido_g	going to check this git thing now...
[14:44] cremes	guido_g: here's a better answer...
[14:44] cremes	http://lists.zeromq.org/pipermail/zeromq-dev/2010-August/005526.html
[14:44] mato	and git in fact will tell you straight away that if you want a local branch it's just git checkout -b <name> at that point
[14:44] cremes	mato: what are your thoughts on a set of regression tests?
[14:45] cremes	aside from 'make test'
[14:45] mato	cremes: well, the major hurdle is that the system we're testing is distributed
[14:45] sustrik	pretty hard to write sane tests
[14:45] mato	yes and no
[14:45] sustrik	some basic stuff can be done though
[14:45] guido_g	why the *** hell is not mentioned those books...
[14:45] guido_g	*is this
[14:46] mato	tests can be written to use tcp over localhost
[14:47] mato	or ipc
[14:47] mato	and inproc separately since that is a different code path
[14:47] sustrik	yes
[14:47] mato	sustrik: in fact, we can have multiple contexts in a single process
[14:47] sustrik	true
[14:47] mato	so a test can even use multiple contexts if you need it
[14:47] mato	basically you do all the "distributed" stuff using multiple threads
[14:48] sustrik	the hard part is starting individual components in synchronised manner
[14:48] mato	give me an example?
[14:48] sustrik	it's often like:
[14:48] sustrik	start component 1
[14:48] sustrik	start component 2
[14:48] sustrik	press any key at 1
[14:48] guido_g	mato: any chance to write the git shuffle for a version into the README?
[14:48] sustrik	etc.
[14:49] mato	guido_g: well, until now the assumption was if you're wanting the stable release you don't work out of git
[14:49] guido_g	ah ok
[14:50] mato	guido_g: also, i'm still trying to get my head around what the best way to hold patches for a stable release in git actually is
[14:50] guido_g	may i say that this assumption isn't a good one?
[14:50] mato	well, ultimately, we can't teach people who want to use git how they should do that
[14:50] guido_g	what about a maintenance branch?
[14:51] mato	guido_g: yes, the plan is for a maintenance branch of some sort, but i've been spending the last day trying to understand what the best workflow for us (i.e. sustrik and myself) is
[14:51] mato	please be patient :-)
[14:52] mato	guido_g: anyhow, the tags are all there, for all past 2.0.x releases
[14:52] guido_g	well, you should, 'cause these people are the user base (at least a significant part of)
[14:52] mato	guido_g: sure, d'you have a git expert i can talk to ? :-)
[14:52] sustrik	guido_g: are you running the code from trunk in production?
[14:52] guido_g	mato: if i'd have, i'd talk to him myself first
[14:53] guido_g	this is one big problem: limited understanding of the tool chain
[14:53] mato	of course
[14:54] mato	guido_g: anyhow, any code you're using in real production should come out of a release tarball in my opinon
[14:54] sustrik	that's what i wanted to say
[14:54] sustrik	it may work using a git for a while
[14:54] sustrik	but in long run it's dangerous
[14:55] guido_g	problem here is: Ã¸mq is so young, that important fixes and updates are quite frequent
[14:55] guido_g	tarballs are only available for official releases
[14:55] mato	yes, which is what the maintenance branch is for, which i'm trying to define, etc etc :)
[14:55] guido_g	between the two are huge gaps
[14:56] sustrik	mato: have you tried talking to martin hurton
[14:56] sustrik	i don't know whether he's an expert but he's definitely with git longer than we are
[14:57] mato	yeah, that's a good idea... or possibly asking for help on the Git mailing list/IRC
[14:57] mato	the only problem with mailing lists/IRC is figuring out if the answers are any good :-)
[14:57] sustrik	ha
[14:57] guido_g	:)
[14:58] sustrik	well, even if you define a viable process, there's still a question of who's going to work on the maintenance branch
[14:58] cremes	try asking on stack overflow
[14:58] sustrik	backporting bugfixes is not much fun
[14:59] mato	sustrik: the process i want to define forces the committer applying the fix to evaluate whether or not it also applies to the maint branch
[14:59] mato	sustrik: it's the only viable way at the moment imo
[14:59] sustrik	you mean that every contributor would have to post a diff for every maitenence branch?
[14:59] mato	no
[15:00] mato	the person integrating those changes is responsible
[15:00] sustrik	for bakcporting?
[15:00] mato	no
[15:00] mato	the point is
[15:00] mato	at the moment we have a bunch of changes which are common to stable and master
[15:00] mato	so those changes should be merged verbatim into both
[15:01] mato	now, about backporting
[15:01] mato	this is entirely voluntary
[15:01] sustrik	the above _is_ backporting, no?
[15:02] mato	no
[15:02] sustrik	"bunch of changes which are common to stable and master"
[15:02] guido_g	backporting a feature should be the exception
[15:02] cremes	regarding git, this may help just a little bit
[15:02] cremes	http://tom.preston-werner.com/2009/05/19/the-git-parable.html
[15:02] sustrik	i meant backporting the bugfixes
[15:02] mato	sustrik: if the code has not diverged there is no concept of backporting
[15:02] mato	sustrik: we do have a bunch of changes like that at the moment
[15:02] sustrik	cremes: what's that?
[15:02] mato	sustrik: e.g. the device stuff from jon dyte
[15:03] sustrik	yes, it works as long as you don't get conflicts on merge
[15:03] mato	if those conflicts are trivial to solve then there is no problem
[15:04] sustrik	ok, i see what you mean
[15:04] sustrik	sounds viable
[15:04] mato	if they are not, then you are in a different situation
[15:05] guido_g	i think the other way is much more important, a bug in stable has been fixed and this has to be incorporated into dev
[15:05] sustrik	it's the same thing
[15:05] sustrik	"bunch of changes which are common to stable and master"
[15:06] guido_g	ok
[15:06] mato	well, my view would be that the stable release is a volunteer effort
[15:06] guido_g	elaborate
[15:07] mato	what i mean by that is: if we get a fix for stable, it's our interest to merge it also into master if relevant
[15:08] mato	however, i would expect most development to be concentrated on master
[15:08] mato	and the backporting of fixes into stable from master to be minimal
[15:08] mato	does that make sense?
[15:08] guido_g	i figure you define "development" as developing new features in contrast to bug fixes
[15:09] mato	no, not really
[15:09] guido_g	then it doesn't make sense
[15:09] mato	ok, let me put it this way
[15:10] mato	the problem is that 2.1.x and 2.0.x have diverged due to large infrastructure changes
[15:10] mato	1) if a fix is applicable trivially to both, no problem, it goes in both
[15:10] guido_g	ok so far
[15:10] mato	2) if not, someone has to make a decision on what effort needs to be spent
[15:11] mato	sustrik would obviously want to concentrate on master
[15:11] guido_g	in this case, backports shouldn't be done. stop.
[15:12] mato	yes, pretty much
[15:12] mato	that's what i was trying to say
[15:12] mato	unless someone actually steps up to do the work, i won't stop them :)
[15:12] sustrik	i think it a question of money flow
[15:12] mato	(if it is a backport of a fix, obviously features don't get backported into stable. ever.)
[15:13] sustrik	if support license business launches off
[15:13] sustrik	it would obviously focus on stable
[15:13] sustrik	not development
[15:13] guido_g	mato: which is why there is a new version, so no problem
[15:13] mato	guido_g: precisely
[15:14] mato	sustrik: in that case a person from said business will step up to backport fixes
[15:14] sustrik	exactly
[15:14] mato	the point is, anyone can backport fixes if they want to
[15:14] sustrik	and the said business is ourselves
[15:14] guido_g	or adopt fixes from stable to master
[15:15] sustrik	the people on this list are probably those that can be hired to maintain the stable
[15:15] guido_g	anyhow, a "stable" branch should be there
[15:15] mato	sustrik: you're mixing money with community, different issues
[15:15] sustrik	i mean, if a business wants stable to be supported, who are they going to hire?
[15:15] sustrik	you
[15:15] sustrik	me
[15:15] guido_g	did I hear hired? :)
[15:15] sustrik	guido
[15:16] sustrik	people from the community
[15:16] mato	sustrik: it's still a different issue. the point is a stable branch can be there, fixes can flow into it, and releases will be made when someone has the motivation to do so
[15:16] sustrik	eh, isn't that the right word?
[15:16] mato	whether that motivation comes from being hired or not is irrelevant
[15:17] mato	if the community (paid or not) has no interest in further stable releases of 2.0.x then there won't be any
[15:17] sustrik	i'm just commenting on the fact that maintaining stable is not a fun job
[15:17] mato	maintaining anything is not a fun job
[15:17] mato	you can ignore all bug fixes that don't affect you
[15:17] guido_g	what about the following: if dev has a fix, it is cut down and put aside as a commit into a branch, then _someone_ can get to this branch and try to apply the fixes to stable
[15:17] mato	but then other people won't use your software :)
[15:17] guido_g	full ack
[15:18] guido_g	had a day of today and wanted to play with Ã¸mq, instead i chased a bug...
[15:18] mato	sustrik: the key point is to encourage contributions, to stable or not
[15:18] mato	more people = more manpower
[15:18] sustrik	sure
[15:18] mato	= you find more people who are trustworthy, and you delegate to them
[15:19] keffo	or a crappy tasting soup!
[15:19] guido_g	unfortunately: more people -> needs more structure
[15:19] sustrik	so guido_g today contributes as a tester :)
[15:19] mato	precisely
[15:19] guido_g	sustrik: sigh
[15:19] guido_g	btw, just installed expect and going to use it for some tests scripts
[15:20] guido_g	idea is to have small programs with defined output and using expect to verify it
[15:21] sustrik	aha
[15:21] sustrik	yes it would be good to put a test suite together
[15:22] guido_g	and for devs a dependency like expect shouldn't be to hard to meet
[15:22] sustrik	does it have to be a part of the build system?
[15:23] mato	why use expect at all?
[15:23] mato	the test programs themselves should either assert/abort or succeed
[15:23] mato	no dependency required
[15:23] guido_g	ok
[15:23] guido_g	i'll rewrite my experiments (which uncoverd the poll issue) into one test program
[15:24] sustrik	thanks
[15:24] mato	sustrik: also, brian has a bunch of poll tests in the pyzmq repo
[15:24] mato	sustrik: these could be trivially rewritten into c/c++
[15:24] sustrik	ack
[15:24] sustrik	but right now it exceeds my resources
[15:24] guido_g	this is what i had in mind :)
[15:25] mato	guido_g: take a look at the poll tests in pyzmq, it's what i had in mind
[15:25] guido_g	guess what i'm doing atm? :)
[15:26] mato	all that's needed is then figuring out the automake stuff to make a driver that runs the tests on "make test"
[15:26] mato	i can do that
[15:26] mato	it's just "run all of this stuff and error if any step asserts/aborts"
[15:26] mato	which is automatic since the assert/abort will get you a non-zero exit status
[15:27] guido_g	ack
[15:27] guido_g	let me hack a simple test progam
[15:55] mato	sustrik: guido_g: ok, i've figured out the automake stuff for tests
[15:56] guido_g	oh oh
[15:56] mato	sure, which is why /me figured it out for you :)
[15:56] guido_g	thx a lot then :)
[15:56] mato	end result is, i have a tests/ directory, with a single test case in it
[15:57] mato	and you can run "make check" which runs all the tests and prints a nice summary, complains which failed/passed, etc
[15:57] mato	sustrik: a couple of questions
[15:57] sustrik	yes?
[15:57] guido_g	mato: ok
[15:57] mato	sustrik: 1) the tests should be mostly C, not C++, right?
[15:57] mato	sustrik: since the C API is our main deliverable
[15:58] mato	sustrik: (there can of course be C++ tests in there, later)
[15:58] sustrik	yes
[15:59] mato	sustrik: then the only problem i have is this business of linking C against C++ runtime when --disable-shared is used
[15:59] sustrik	but iirc you had a problem compiling c files anyway
[15:59] mato	well, kind of
[15:59] sustrik	that's why you changed the perf tests to .cpp
[15:59] mato	yes
[15:59] mato	this happens when you use --disable-shared
[15:59] sustrik	i'm using it
[15:59] mato	:)
[15:59] guido_g	mato: if you would like to check the test_poll.cpp at http://github.com/guidog/cpp/tree/master/zmqcpp
[16:00] sustrik	ha, i thougt it is a project called "GUI dog"
[16:00] sustrik	now i see it's guido_g :)
[16:00] guido_g	sigh :)
[16:01] mato	guido_g: yeah, nice, that's kind of the idea i have
[16:01] guido_g	good
[16:01] guido_g	going to fill in some more tests now
[16:01] mato	except i'm wondering whether test cases should be using just the C api
[16:01] mato	or not... not sure if it matters
[16:02] guido_g	the c++ api is the native one, right?
[16:02] mato	no, the C API is
[16:02] sustrik	C++ is a wrapper
[16:02] mato	the C++ API is just a thin wrapper in zmq.hpp
[16:02] sustrik	but it's distributed with the package so i don't really see a problem
[16:02] sustrik	and using C++ api is much easier
[16:02] mato	yeah, i guess not
[16:02] guido_g	but the software is written in c++
[16:02] sustrik	the exceptions just run out of main
[16:03] sustrik	and cause fault
[16:03] mato	yup
[16:03] mato	guido_g: one minor point; independent tests should be independent programs
[16:03] mato	in other words, in your program, test_pair() is basically main()
[16:03] mato	the reason for this is "make check" will run all the tests
[16:04] guido_g	ok, going to change that
[16:04] mato	not just stop at the 1st one
[16:04] mato	it'll then give you a nice pass/fail summary
[16:04] guido_g	what is the grouping attribute? socket type? access type? moon phase?
[16:05] mato	grouping? of tests?
[16:05] guido_g	yes, because having programs for every permuation of socket type for every way to access it plus special cases would lead to an enormous amount of programs
[16:06] guido_g	i'd say lets do it like: test_pair, test_reqrep, test_pushpull or so
[16:06] guido_g	as a start
[16:07] CIA-20	zeromq2: 03Dhammika Pathirana 07master * r98dc118 10/ src/zmq_decoder.cpp : assert on malformed messages - http://bit.ly/a3XkbQ
[16:07] guido_g	later we'll likely add tests for special cases
[16:07] guido_g	going to rename test_poll.cpp to test_pair.cpp and see how far it goes
[16:08] sustrik	i don't believe you will ever be able to devise a systematic naming for test programs
[16:08] mato	i think start somewhere
[16:08] mato	we can change things as we go along
[16:08] mato	no big deal, they're just test programs
[16:08] mato	sustrik: ok, i'm going to have to go to dinner soon
[16:08] mato	what i can do
[16:09] guido_g	but they have to be maintained!
[16:09] mato	of course
[16:09] mato	but if you don't maintain them you'll get shot pretty quickly since they'll stop working :)
[16:09] mato	so, what i can do now, if you guys want to continue
[16:09] guido_g	make test would make a niche pre-push hook :)
[16:10] mato	guido_g: that is some way away, but yes, autobuilders and test is what we need
[16:10] mato	so much to do :)
[16:10] guido_g	as usual
[16:10] mato	anyhow, i can push to master the framework that adds a test/ subdirectory with my one lone silly test in it (just creates and destroys a context)
[16:11] mato	then you can start adding tests as you like
[16:11] mato	does that sound like a plan?
[16:11] guido_g	and i will move my test_*cpp into that dir on my local clone
[16:11] guido_g	and see if it works
[16:11] mato	yup yup
[16:11] guido_g	if it does, i do what?
[16:12] mato	sustrik: last question (i can choose here): should "make" build the tests or should they only be built if you also want to run them (with make check)
[16:12] mato	sustrik: /me thinks 1st option is better for now
[16:12] sustrik	build them immediately
[16:12] mato	ok, but they'll only get run when you do "make check"
[16:13] sustrik	sure
[16:13] sustrik	ultimately they'll take several minutes to run
[16:13] mato	guido_g: you send a patch with your contribution to the ml, stating it's under the MIT license, as usual and sustrik or myself can apply it
[16:13] sustrik	so not by default please
[16:13] mato	yes, but build by default
[16:13] mato	ok
[16:14] guido_g	may i use this nifty git email feature?
[16:14] mato	indeed you may :) the only problem is how do you get the "this is under MIT license" into it?
[16:14] mato	if you can do that, please do, but email to the list of course
[16:14] guido_g	ok, i'll have a look then
[16:15] mato	you could for now, if sustrik is happy, even just use git-email and then reply to your own email with "Patch is under the MIT license"
[16:15] mato	assuming you can't figure out a way of getting git-email to do that
[16:15] guido_g	otherwise i'll send the patches as attachments and state the license stuff in the main mail
[16:15] mato	yup, thx
[16:16] mato	the license stuff will hopefully go away soon, there's been an RFC out about dropping the MIT requiremenet, but this is for iMatix to decide
[16:41] CIA-20	zeromq2: 03Martin Lucina 07master * r35cb1fa 10/ (Makefile.am configure.in tests/Makefile.am tests/simple.cpp):
[16:41] CIA-20	zeromq2: Add a basic framework for a test suite
[16:41] CIA-20	zeromq2: The test suite uses the standard automake support. Tests are always built,
[16:41] CIA-20	zeromq2: but run only when you do a "make check". - http://bit.ly/8YwkAR
[16:41] CIA-20	zeromq2: 03Martin Lucina 07master * r0b76f23 10/ src/zmq_decoder.cpp : Merge branch 'master' of github.com:zeromq/zeromq2 - http://bit.ly/dt0av0
[16:41] mato	sustrik: guido_g: ok, there you go
[16:42] mato	for now all tests need to xyz.cpp even if you're using the C API
[16:42] mato	to add a test, add it's source file to tests/, update tests/Makefile.am (should be self-explanatory)
[16:42] mato	make check runs the tests
[16:42] mato	have to go now, cyl
[16:43] guido_g	ok, thx
[16:43] sustrik	vya
[16:43] sustrik	cya
[16:45] mems	hey, I'm trying to work out if zeromq can do what I need for my application
[16:46] mems	I have a server which manages a list of compute jobs
[16:46] mems	then a variable number of worker nodes that get jobs from it
[16:46] mems	and (because I'm new to zmq) I can't work out if with zmq I would have to have a polling based situation
[16:48] sustrik	mems: the works will be load-balanced among workers?
[16:48] mems	I'd like each worker to request a job from the server and then perform it
[16:49] mems	I'm not completely familiar with the terminology here... dunno if that's what you'd regard as "load-balanced"
[16:49] sustrik	so it's worker who plays the active role?
[16:49] sustrik	i.e. decides to do some work
[16:49] mems	that was my plan
[16:50] sustrik	then create a REQ socket at each worker
[16:50] sustrik	and a REP socket at the server
[16:50] sustrik	it's classic client/server scenario
[16:50] mems	and when the server's job queue is empty?
[16:50] mems	(but will be full in the future)
[16:50] sustrik	no jobs then :)
[16:51] mems	but would the clients have to repeatedly poll the server in that situation?
[16:51] sustrik	no
[16:51] sustrik	they can idly wait for the work
[16:52] mems	hmm... it would appear that I'm not sure what a REP and REQ socket are
[16:52] mems	are there some API docs?
[16:55] sustrik	manual pages
[16:55] sustrik	man zmq
[16:55] mems	yup. just found them, thanks :)
[16:55] sustrik	also online here:
[16:55] sustrik	http://api.zeromq.org/
[16:56] mems	ok, so, to complicate matters, I have multiple types of worker that work on the jobs at different points in their lifetime
[16:57] mems	so the request from the worker is more like "give me a job in state X"
[16:57] mems	presumably this means that the server will need to be able to say "I don't have anything in that state at the moment"
[17:00] sustrik	separate REP sockets in the server for separate kind of work then
[17:02] mems	hmm. I'll have a play
[17:10] guido_g	ha! first tests work
[17:11] sustrik	:)
[17:11] guido_g	now for the patch thing...
[17:13] mems	is there a way of discovered from which client a message has come from?
[17:13] mems	**discovering
[17:14] sustrik	no unless you put that into the message itself
[17:14] ModusPwnens	Hi
[17:14] sustrik	hi
[17:14] ModusPwnens	are you helping someone already?
[17:14] mems	sustrik: this seems odd to me -- is this not a really common requirement?
[17:14] ModusPwnens	mm, that answers my question
[17:14] sustrik	:)
[17:15] sustrik	it's the nature of the thing
[17:15] sustrik	use 0mq where you want to communicate with a lot of homogenous peers
[17:16] sustrik	if you want to treat each connection separately, use standard TCP sockets, that's what they are for
[17:16] mems	mmm... but then one loses zmq's framing
[17:17] sustrik	shrug
[17:17] mems	hehe
[17:17] sustrik	framing is easy
[17:17] sustrik	write the size, then data
[17:18] sustrik	0mq is a scalability solution
[17:18] mems	ok
[17:18] sustrik	thus it makes you communicate with an unknown number of peers
[17:18] sustrik	that way you can add and remove processing nodes as you wish
[17:18] sustrik	without tweaking your code
[17:21] mems	ok. I see what it's going for.
[17:21] mems	one last question ;)
[17:21] mems	if I have a bunch of sockets, can I block on getting a message from any one of them?
[17:21] mems	(zmq sockets obviously)
[17:22] sustrik	have a look at zmq_poll
[17:22] mems	excellent
[17:23] guido_g	when it works... ]:->
[17:24] ModusPwnens	oh guido is here too!
[17:24] guido_g	yes
[17:26] ModusPwnens	ok so, i was trying to do the throughput/latency tests that zeromq has in their install package, but for some reason the remote end doesnt think the address is valid
[17:27] ModusPwnens	in the example, they use eth0 for the local end, but I don't think that identifier means anything in windows
[17:28] sustrik	in windows you have no sane NIC names
[17:28] sustrik	use an IP address
[17:28] sustrik	guido_g: i think I've found the problem
[17:28] ModusPwnens	Yeah, i tried that. I used the IPv4 address of the computer that the local test was running on
[17:30] guido_g	sustrik: good, because with the current master the tests fail :)
[17:31] guido_g	ok, first coffee
[17:38] guido_g	ahh... format-patch is nice
[17:42] keffo	finally, I got the routing working across two queues :)
[17:50] ModusPwnens	so does anyone know whats going on with the test suite..?
[17:51] cremes	ModusPwnens: we just started chatting about it a few hours ago
[17:54] sustrik	cremes: there's a testing infrastructure added to trunk
[17:54] sustrik	no tests yet though
[17:55] cremes	good progress for a few hours work!
[17:55] sustrik	'make check' will run them
[17:55] sustrik	cremes: btw, the diagram we've made yesterday
[17:55] cremes	yes?
[17:56] sustrik	what about changing the terminal nodes to REQ and REP
[17:56] sustrik	that way it will show how all 4 socket types work
[17:56] ModusPwnens	Really? what a coincidence..so what were you talking about regarding the test suite?
[17:56] cremes	sure
[17:57] cremes	since you have the source for the graphic, make the change and i'll update the text
[17:57] sustrik	ok
[17:57] sustrik	ModusPwnens: that it has to be done :)
[17:57] ModusPwnens	but there is a test suite for zeromq already..
[17:58] ModusPwnens	well at least for latency and throughput
[17:59] sustrik	that are performace tests
[17:59] sustrik	we were talking about functionality tests
[17:59] ModusPwnens	Oh. I think there is a misunderstanding or something then. I'm just having trouble to get the performance tests running
[18:00] sustrik	cremes: done
[18:01] sustrik	Modus: paste you command lines here
[18:01] ModusPwnens	k
[18:02] ModusPwnens	on the local computer: local_thr.exe tcp://192.168.1.176:5555 1 100000
[18:02] ModusPwnens	where the ipaddress used their is the ip address of that computer itself
[18:02] ModusPwnens	there*
[18:03] sustrik	and the remote?
[18:03] ModusPwnens	well its the same thing except it uses remote_thr.exe
[18:03] sustrik	what version are you using?
[18:03] ModusPwnens	2.07
[18:04] sustrik	does it hang?
[18:05] ModusPwnens	yeah they seem to run but not do anything..and i changed it to 10 so that i wouldn't have to wait so long
[18:06] sustrik	none of the two programs exits?
[18:06] ModusPwnens	Nope.
[18:07] sustrik	do they or do they not?
[18:07] ModusPwnens	they don't
[18:07] sustrik	that's pretty strange
[18:08] sustrik	the remote at least should exit after 10 seconds
[18:08] sustrik	can you get the backtrace from the remote, to show where it is hanging?
[18:08] ModusPwnens	maybe something else is going on. the computer i've been using has been having a slew of other problems
[18:08] ModusPwnens	hmm, i will try that and get back to you
[18:19] cremes	sustrik: i have a different idea
[18:20] cremes	make a copy of the image as x2.png with req/rep as the terminal nodes and restore the original pic
[18:20] cremes	i'll write a separate paragraph explaining the new diagram
[18:20] sustrik	ok, but i already overwrote the original pic
[18:20] cremes	i don't want to rewrite a bunch of the text but i have no problem adding another paragraph or two for a new config
[18:21] sustrik	so x2 will be the original one
[18:21] cremes	fine, then make x2.png with xreq/xrep
[18:24] sustrik	cremes: there you go
[18:24] cremes	thank you
[18:29] sustrik	guido_g: testutil.hpp:36: error: extra â;â
[18:29] sustrik	i'll fix it
[18:29] sustrik	namespaces should not be followed by ;
[18:29] sustrik	c++ syntax is plain weird
[18:30] guido_g	oh the mail is through :)
[18:30] guido_g	compiled here
[18:30] sustrik	was that a generated email?
[18:30] guido_g	no, that would have involved things via imap
[18:31] sustrik	ok
[18:31] guido_g	just a format-patch as attachment
[18:31] guido_g	sustrik: which compiler version should one use?
[18:32] sustrik	guido_g: any
[18:32] sustrik	the more the better
[18:32] guido_g	ok
[18:32] sustrik	it even compiles on icc or xlc etc.
[18:34] guido_g	c++ --version
[18:34] guido_g	c++ (Debian 4.4.4-8) 4.4.5 20100728 (prerelease)
[18:35] guido_g	ok, now that the process of sending patches is understood even by me, i'll produce some more
[18:35] sustrik	anyway, the point is the more compilers the better so we catch all possible deviations from standard syntax
[18:35] guido_g	i'll not try to compile Ã¸mq on my n900... no way :)
[18:36] sustrik	iirc someone already did :)
[18:36] guido_g	sustrik: any other remarks on the patch?
[18:36] sustrik	coding style... i'll fix that
[18:36] guido_g	sigh would be nice, but given that maemo has been killed by nokia... waste of time
[18:36] guido_g	ouch yes, i tend to forget such things
[18:39] sustrik	one more thing:
[18:39] sustrik	when including zmq.hpp
[18:39] guido_g	is there a description of the wanted coding style?
[18:39] sustrik	use #include "../include/zmq.hpp"
[18:39] sustrik	the headers are not yet installed
[18:39] guido_g	right
[18:40] sustrik	so you can end up including old headers from the previously installed version
[18:40] guido_g	yup, got it
[18:40] guido_g	just copied the files over from my dev dir
[18:40] sustrik	http://www.zeromq.org/docs:style
[18:42] guido_g	ahh... 've been looking in the wrong place
[18:52] sustrik	guido_g: i would say making the context global is not a good idea
[18:52] guido_g	why?
[18:52] sustrik	that way zmq_term gets called _after_ the return from main
[18:52] sustrik	which is kind of strange
[18:53] guido_g	ok, i'll move it into main then
[18:53] sustrik	i'll do it
[18:53] sustrik	just commenting
[18:53] guido_g	as you wish :)
[18:53] guido_g	don't do too much
[18:53] guido_g	i already have more changes here
[18:54] guido_g	actually making the things work and such :)
[18:54] sustrik	wait a sec!
[18:54] guido_g	no problem
[18:54] sustrik	i am reformatting it so it'll be pain in the ass to merge it
[18:55] guido_g	no merges planned
[18:55] guido_g	only plain typing to get used to the coding style
[18:56] sustrik	ok
[18:56] sustrik	using assert without including <assert.h>
[18:56] sustrik	that may fail on some platforms
[18:57] guido_g	did i say that my last exposure to c++ was roughly 10 years ago?
[18:57] sustrik	i'm not complaining
[18:57] guido_g	i really need to re-learn a lot as it seems
[18:57] sustrik	just commenting so that you are aware of it
[18:57] guido_g	thx
[18:58] guido_g	i completely forgot what i wanted to do today...
[18:58] sustrik	:o)
[19:01] sustrik	why are you including iostream?
[19:01] sustrik	it doesn't look to be used anywhere
[19:01] guido_g	i tested the thing using cout
[19:01] sustrik	ack
[19:07] sustrik	============================================
[19:07] sustrik	2 of 3 tests failed
[19:07] sustrik	Please report to zeromq-dev@lists.zeromq.org
[19:07] sustrik	============================================
[19:07] sustrik	woohoo!
[19:09] guido_g	yeah, it's the broken poll
[19:11] sustrik	guido: do you want this address attached to the patch:
[19:11] sustrik	zmq@a-nugget.de
[19:11] sustrik	?
[19:11] sustrik	guido_g
[19:11] guido_g	it's ok with me
[19:13] guido_g	at least, i did something useful today :)
[19:14] CIA-20	zeromq2: 03Guido Goldstein 07master * r4d9b046 10/ (6 files in 2 dirs): two tests added - http://bit.ly/cIptEz
[19:14] sustrik	great, done
[19:14] sustrik	thanks for that!
[19:14] guido_g	cool, i'll pull and have a look
[19:14] guido_g	you're welcome
[19:27] guido_g	i'll send the fixes i have so you have some working tests
[19:27] guido_g	more tests should be written once we have a working poll again
[19:27] guido_g	is that ok?
[19:36] guido_g	so the fixes are out
[19:41] sustrik	guido_g: sure, it's ok
[19:41] sustrik	thanks
[19:47] mato	back for a bit
[19:47] mato	guido_g: good to see the test framework is useful
[19:50] guido_g	mato: it sure is
[19:50] mato	i'll look at your tests over the weekend, kind of late now
[19:50] guido_g	we have 2 tests for now
[19:50] mato	but the general feel is good
[19:51] mato	i think there will be some general guidelines we'll want to write for people contributing test cases
[19:51] guido_g	they're just testing the basics of req/reqp and pair incl. poll
[19:51] mato	sure, it's a start, that's good!
[19:51] guido_g	ack
[19:51] guido_g	i'll write more after poll is back on master
[19:57] guido_g	i'm off too, good night all
[19:57] mato	good night guido_g
[20:41] cremes	under what circumstances should i expect to see this error? Assertion failed: false (object.cpp:342)
[20:41] cremes	this is on 2.0.8
[20:42] cremes	i think it is happening when a socket is blocked on recv and i call zmq_close() on the sockets
[20:52] cremes	obviously, i am calling zmq_close on those sockets from another thread :)
[20:54] mato	there you go then :-)
[21:49] tyler	trying to compile with the bundled pgm (./configure --with-pgm && make) results in an error in both 2.0.7 and 2.0.8 source distributions
[21:49] tyler	/usr/bin/ld: .libs/libzmq_la-txwi.o: relocation R_X86_64_PC32 against `pgm_rs_create' can not be used when making a shared object; recompile with -fPIC
[21:49] tyler	/usr/bin/ld: final link failed: Bad value
[21:49] tyler	any help would be appreciated
[21:54] mato	tyler_: you're on redhat ?
[21:54] tyler	centos 5.4
[21:54] mato	thought so
[21:54] mato	see this thread:
[21:54] mato	http://thread.gmane.org/gmane.network.zeromq.devel/1667/focus=1670
[21:55] mato	specifically:
[21:55] mato	Just quickly check altering this line in src/Makefile,
[21:55] mato	-DPGM_GNUC_INTERNAL=G_GNUC_INTERNAL \
[21:55] mato	to
[21:55] mato	-DPGM_GNUC_INTERNAL= \
[21:55] mato	try that, the problem should go away
[21:57] tyler	that did the trick, thank you!
[21:57] mato	tyler_: no problem... as far as i can see it's a redhat 5.4 issue only with their gcc