Sunday April 3, 2011

[Time] NameMessage
[09:05] pieterh sustrik: hi
[09:45] sustrik hi
[09:45] pieterh git rename seems to have worked :-)
[09:46] sustrik yes, looks there are no problems
[09:47] sustrik well, aside of broken CIA
[09:47] sustrik i need mato to fix it
[09:47] sustrik presumably on Tuesday
[09:50] sustrik btw, are the library version numbering rules outlined somewhere?
[09:53] pieterh afair the original release policies page covered versioning of the library
[09:53] sustrik thx
[09:54] pieterh sustrik: sorry, I'm wrong, reading the original text now and it doesn't discuss this
[09:54] sustrik never mind
[09:54] sustrik i'll google it
[09:55] pieterh worth writing down once it's clear...
[09:55] sustrik maybe just copy it from somewhere
[09:55] sustrik it's not specific to 0mq
[09:55] sustrik or link the relevant text
[09:56] pieterh it's the version of the ABI, right?
[09:56] sustrik yes
[09:56] pieterh presumably as long as it's a different number, that's sufficient to allow tools to recognize it
[09:56] pieterh but there is a justification somewhere that would be useful to link to
[10:01] sustrik i think there are detailed guidelines somewhere
[10:02] sustrik it should be done right, as iirc the linker uses it to choose the right library version
[10:02] pieterh indeed
[10:02] pieterh mato is the expert in this area, you may want to wait till he gets back
[10:03] sustrik
[10:03] sustrik anyway, i'll wait for mato
[10:03] sustrik just to be sure
[10:05] pieterh looks right
[10:23] mikko good morning
[10:26] pieterh hi mikko
[10:28] mikko did you merge from 2-2 to 2-1 or both from libzmq?
[10:28] pieterh mikko: I merged from libzmq into both 2-1 and 2-2
[10:29] pieterh cherry-picked the various patches
[10:29] pieterh hmm, sorry, the various commits
[10:29] pieterh I'm not sure why that sometimes gives a conflict
[10:32] mikko i can check
[10:32] pieterh apart from those conflicts, downstreaming seems to work fine
[10:34] pieterh e.g., cherry-picking bdeddb89f727c434ad499da5a349f3959eba322 from libzmq gave a conflict on acinclude.m4
[10:37] mikko 2.2 still has devices?
[10:37] pieterh shouldn't have...
[10:37] mikko and no openpgm build fixes
[10:38] mikko what i did was:
[10:38] mikko git remote add 2-1 <url>
[10:38] mikko git remote add 2-2 <url>
[10:38] mikko git fetch 2-1
[10:38] mikko git fetch 2-2
[10:38] mikko git diff 2-2/master 2-1/master
[10:40] mikko 2-2 is missing some other commits as well
[10:40] mikko 32ded2b4
[10:41] pieterh nice catch, let me get 2-2 up to scratch
[10:41] mikko the diff helps a lot
[10:42] pieterh for some reason when I tried that it gave diffs that weren't accurate
[10:42] pieterh didn't do it quite the same way, my git fu is too weak :-(
[10:43] pieterh mikko: in fact the 32ded2 commit is in 2-2 but not in 2-1 and that's deliberate
[10:44] mikko ok
[10:44] pieterh what are the missing openpgm fixes?
[10:45] pieterh short message abort?
[10:45] mikko just a sec
[10:46] mikko ZMQ_MAXMSGSIZE is 2.2 only?
[10:46] pieterh yes, also
[10:47] mikko -!foreign/openpgm/
[10:47] pieterh I see the missing openpgm fixes, 5.1.115 upgrade
[10:47] mikko 2.2 needs that to gitignore
[10:47] mikko yeah
[10:47] mikko the devices clutter the diff a bit
[10:50] pieterh ok, I'm searching around for the correct commits to cherry-pick for openpgm...
[10:52] mikko have you got gitk?
[10:52] pieterh gitk sounds fun, what does it do?
[10:53] mikko it's a repository browser
[10:53] mikko visualises commit graphs etc
[10:53] pieterh sigh... why can't I find those OpenPGM commits in libzmq?
[10:53] mikko fbf1f5146860a2557f247cdb0f94bda647c75ceb on pre30
[10:53] mikko git show fbf1f5146860a2557f247cdb0f94bda647c75ceb
[10:54] mikko if you want to see the log on all branches you can do git log --all
[10:54] pieterh ah, that one
[10:55] pieterh ok, I see the confusion
[10:55] pieterh you sent me individual patches, I applied to 2-1, then you sent a single patch to master
[10:55] pieterh that never got downstreamed again, so I didn't apply it to 2-2
[10:56] mikko does fbf1f5146860a2557f247cdb0f94bda647c75ceb merge cleanly?
[10:56] pieterh nope, just tried, got conflicts
[10:56] mikko did you remove decives?
[10:57] pieterh should we be using LIBZMQ_ or AC_ZMQ now?
[10:57] mikko devices*
[10:57] pieterh yes, I've removed the devices
[10:57] mikko let me pull and see why it conflicts
[10:57] mikko ZMQ_ or LIBZMQ_ is fine
[10:57] pieterh I'll resolve the conflicts, they're not complex
[10:57] pieterh hang on...
[10:57] mikko but AC_ZMQ_ ac_zmq_ causes warning
[10:57] mikko not sure why
[10:59] pieterh having to checkout /reset HEAD three times to undo a failed merge
[10:59] mikko you can do git merge --no-commit ?
[10:59] mikko that way you can just stash the changes
[11:00] pieterh sure, I can go back 30 seconds in time :-) and fix my stupid optimistic command
[11:00] mikko you learn every time
[11:00] pieterh mikko: ok, I've pushed 2-2 without devices
[11:01] pieterh you're committer on that repo
[11:02] pieterh if you could merge fbf1f5, that'd be lovely
[11:03] mikko i shall
[11:03] pieterh apart from glitches like this it's fairly simple to maintain multiple branches
[11:13] mikko pieterh: builds/msvc/
[11:14] mikko still has devices in it
[11:14] pieterh ack, checking...
[11:14] mikko and the spec-file for rpms has them
[11:15] pieterh tough little buggers are hard to squash, they get everywhere...
[11:15] pieterh how do you want to do it?
[11:16] pieterh I'd take the files from 2-1, where they're correct
[11:17] pieterh mikko: give me 1 min, I'll do that and push a new 2-2
[11:19] pieterh ok, done
[11:22] mikko ok, here goes merge
[11:22] mikko hmm
[11:23] mikko heh
[11:23] mikko ok
[11:23] pieterh conflicts, right?
[11:23] mikko nope
[11:23] mikko small issue
[11:23] mikko just a sec
[11:25] mikko
[11:25] mikko this needs to go to 2-2 and 2-1
[11:25] mikko 2-2 and 2-1 have both in the
[11:28] pieterh error in my conflict resolution?
[11:28] mikko in the earlier patches
[11:28] mikko
[11:28] mikko did you see this?
[11:29] pieterh didn't see it, presumably the test code hasn't moved to the 3.0 api
[11:29] pieterh will you fix up acinclude.m4 or shall I do it?
[11:30] mikko either way
[11:30] mikko have you got 2-1 and 2-2 in one local repo?
[11:30] pieterh I'd be happier if you do it, less chance of mistake...
[11:30] mikko or do you use two repos?
[11:30] pieterh I use two repos
[11:30] pieterh two directory trees
[11:30] mikko ok
[11:30] pieterh so there's no state to remember, I go there and it's all ready
[11:30] mikko i just did this:
[11:31] mikko git branch --track 2-1-master 2-1/master && git branch --track 2-2-master 2-2/master
[11:31] mikko so now i got two local branches tracking two remote masters
[11:31] pieterh that's what I figured was possible, so you get the same effect as if it was one repo with two branches
[11:32] pieterh read/write?
[11:32] mikko that way when i am in 2-2-master 'git diff' is against 2-2/master
[11:33] mikko git pull/push etc follow that
[11:33] pieterh right
[11:36] pieterh mikko: I need to do an errand, bbl
[11:37] mikko ok
[11:37] mikko i'll push the changes in a min
[11:37] pieterh excellent!
[11:56] mikko interesting
[12:12] mikko pieterh: pushed to 2-2 and 2-1
[12:20] pieterh mikko: thanks, tested build, it works
[12:20] pieterh btw I like the new compact makefile output
[12:21] pieterh aw, inproc_lat.cpp:70: error: ‘zmq_recvmsg’ was not declared in this scope
[12:22] pieterh this is what you were saying... I missed it
[12:22] pieterh one of the downstream patches was bogus
[12:24] mikko pieterh: cool
[12:24] mikko that breaks
[12:24] pieterh :q
[12:24] mikko all red
[12:24] mikko i'm now adding all the builds that need to be executed
[12:24] mikko libzmq, zeromq2-2, zeromq2-1, libzapi, libzfl
[12:25] mikko do we need libzapi builds against libzmq, zeromq2-2 and zeromq2-1 ?
[12:25] pieterh mikko: I'd say against 2-1 only for now
[12:25] pieterh eventually against all versions when libzapi handles 3.0
[12:26] pieterh I need to fix the inproc tests, they're not valid for 2.x
[12:28] pieterh ok, done
[12:28] pieterh all builds correctly now
[12:41] mikko cool
[16:24] pieterh mikko: what do you think of an --with-valgrind option for configure?
[16:26] sustrik we should create a valgrind suppression file instead imo
[16:26] sustrik mato promissed to create one long time ago
[16:26] sustrik but never actually done it
[16:27] pieterh I like it
[16:27] pieterh so no compile changes, automatically works with valgrind
[16:27] pieterh I'm using valgrind systematically, it's extremely useful
[16:29] pieterh sustrik: I assume that such a file will have to be completed over time as people use different parts of 0MQ
[16:29] pieterh I'll try to make one that works for me...
[16:29] sustrik pieterh: sure
[16:29] sustrik i don't have experience with suppressions files myself
[16:29] sustrik
[16:30] pieterh their docs are... painful :-)
[16:30] pieterh I'm sure there's a way to turn the error report into a file automatically
[16:31] pieterh hehe
[16:31] pieterh  --gen-suppressions=all
[16:42] mikko yeah, valgrind would be nice
[16:42] mikko some builds might be broken atm
[16:42] mikko don't worry about that yet
[16:42] mikko i'm adding more diskspace to the box
[16:42] pieterh np :-)
[16:42] mikko so things might still be in-flight
[16:48] pieterh sustrik: I have a minimal suppression file that works for all of my examples I've tested so far
[16:49] pieterh what I'll do is make a wiki page explaining how it works, and how to extend it
[16:49] pieterh when we have something more complete we can package it up
[16:50] sustrik ack
[17:00] neopallium which thread is the zmq_free_fn callback set in zmq_msg_init_data() called from? I would think it is called from one of the IO threads and that it would need to be thread-safe.
[17:00] neopallium If that callback needs to be thread-safe, then a note should be added to the man page for zmq_msg_init_data().
[17:08] pieterh ok, suppression file made, documented, announced
[17:08] pieterh it's 7 lines of code, at least initially
[17:08] pieterh neopallium: good catch, you may want to submit a patch to the man page
[17:10] sustrik pieterh: the link on the valgrind page is broken
[17:11] sustrik neopallium: it's called from arbitrary thread
[17:11] pieterh yugh, thanks, you fixing it?
[17:11] pieterh page is edit locked
[17:11] sustrik so yes, it has to be thread-safe
[17:11] sustrik pieterh: no
[17:12] sustrik force unlock
[17:13] pieterh sustrik: ok, works now
[17:16] neopallium How do you edit the manpages? Do you edit the .txt or .3 file in the libzmq/doc folder?
[17:16] pieterh neopallium: edit the .txt
[17:21] neopallium pieterh: How about this: CAUTION: The deallocation function 'ffn' needs to be thread-safe, since it
[17:21] neopallium will be called from an arbitrary thread.
[17:21] pieterh sounds fine, maybe Caution rather than CAUTION
[17:22] neopallium in the .txt file the outher Cautions are all upper-case.
[17:22] pieterh ah, sure then
[17:24] sustrik pieterh: just checking old email; haven't you forgot about smalltalk examples?
[17:24] sustrik the email looks unaswered
[17:25] pieterh sustrik: hmm, let me check... yup, forgotten
[17:25] pieterh email is a lousy workflow tool
[17:25] sustrik use tagging
[17:25] pieterh use pull requests
[17:25] pieterh thanks for catching this
[17:26] pieterh ah, hang on, this email was not aimed at the Guide
[17:26] pieterh or else I need to explain how to properly translate examples...
[17:26] sustrik ok
[17:28] pieterh 'sender send: (Random between: 0 and: 100) asString'
[17:28] pieterh very nice
[17:30] neopallium pieterh: patch sent to mailing list.
[17:30] pieterh neopallium: your target is actually sustrik, for patches... :)
[17:30] neopallium oh
[17:30] pieterh I just tend to say "submit a patch then" whenever someone has a good idea for an improvement...
[17:31] pieterh the list is the right place, np
[17:32] sustrik neopallium: thanks
[17:32] neopallium The list thread "Zero-copy message API" is what got me thinking about that missing note on thread-safety.
[17:33] sustrik will apply the patch shortly
[17:33] neopallium your welcome.
[17:43] neopallium what is the mailing list and how do I un-subscribe from it? I sometimes get duplicate e-mails from it.
[17:55] pieterh neopallium: there are links in every email, at the footer IMO
[17:56] pieterh you are perhaps subscribed to two lists, the main one and the announcements list
[17:56] pieterh or else you are subscribed with two email addresses
[18:03] sustrik pieterh: no, it happens for me as well
[18:04] pieterh shrug... email lists are just 0MQ done badly
[18:07] sustrik neopallium: which email are you looking at?
[19:17] neopallium pieterh: The last one that I got a dup on is from the "Re: [zeromq-dev] flushing (again)" thread from "Martin Sustrik". The e-mail's CC: field includes <>.
[19:17] neopallium It is like there are two mailing lists. Maybe an old list that is forwarding to the current zeromq-dev list.
[19:17] pieterh neopallium: it's because people do "Reply to all" and you're there twice
[19:18] pieterh most email clients will filter this out
[19:18] neopallium no not for that e-mail
[19:18] pieterh I'll do a test, hang on...
[19:18] neopallium this is the post I am talking about:
[19:19] neopallium I will pastebin a copy of the e-mail headers.
[19:19] pieterh neopallium: you will maybe get two emails containing "Nice, thanks. I've updated the 2.1 and 2.2 distribution branches as well."
[19:20] neopallium yup, but that is not what I am talking about. I know why I get dups of those types of e-mails.
[19:21] pieterh sometimes the email list is also repeated as destination
[19:21] pieterh it'll give the same effect
[19:22] pieterh there is an explanation which someone familiar with SMTP could provide based on email headers that clients set when they post to the list
[19:22] pieterh emails from sustrik, and yourself, for example always reply-to the person, whereas emails from other people reply-to the list
[19:23] neopallium correct e-mail: , dup e-mail:
[19:24] neopallium take a look at lines 12 & 13 of both.
[19:24] neopallium in the dup you have: X-Original-To:
[19:25] pieterh so someone is sending emails to the wrong address?
[19:25] neopallium sometimes people CC
[19:25] pieterh they shouldn't, that's an invalid address
[19:25] neopallium let me try sending a test e-mail to that address.
[19:25] pieterh well, it's valid, it's the same as the list, but clients won't detect the duplicates then
[19:26] pieterh don't bother, it's clear what the problem is
[19:26] pieterh the two addresses resolve to the same list address
[19:26] pieterh people should not be emailing, IMO
[19:27] neopallium some mailservers or mail clients might detect the duplicate message and merge then or reject the dup.
[19:27] pieterh right, but some won't
[19:27] pieterh for example I'm not seeing duplicates, at all
[19:28] neopallium both messages have the same "Message-ID:" header. That must be why you don't get dups.
[19:29] pieterh what email client are you using?
[19:30] neopallium kmail on debian linux.
[19:30] pieterh file a bug with the kmail folk, they seem to be getting this wrong then
[19:31] pieterh I have to go tuck the kids into bed, cyal
[19:35] mikko
[19:54] mikko pieterh: there?