Sunday May 8, 2011

[Time] NameMessage
[07:08] CIA-75 libzmq: 03Pieter Hintjens 07master * rda1ef4d 10/ (src/rep.cpp src/xrep.cpp src/xrep.hpp): Fixed REP assert on missing envelope ...
[07:09] CIA-75 libzmq: 03Martin Sustrik 07master * r4938787 10/ (src/err.cpp src/err.hpp src/tcp_connecter.cpp): Async connect doesn't fail on EWSANETDOWN ...
[07:45] jond sustrik: not sure you've read that patch i sent correctly.....
[08:06] sustrik jond: hi
[08:06] sustrik which part?
[08:06] sustrik you mean this one: outpipes.erase (it++);
[08:06] sustrik the compiler translates that to: outpipes.erase (it); it++;
[08:06] jond sustrik: him the associative (map), yes
[08:07] jond sorry that was mean to be hi
[08:07] sustrik :)
[08:08] jond the post increment should return a copy of the original value
[08:08] sustrik sure
[08:08] sustrik the problem is that erase invalidates iterators
[08:08] sustrik all iterators
[08:08] sustrik for example, if the underlying array is reallocated
[08:09] jond yes that's why on vector erase should return the new iterator but
[08:09] sustrik it's a problem with old HP implementation of STL
[08:09] sustrik it does not return the iterator
[08:09] sustrik it's pretty annoying
[08:10] sustrik what about using remove_if?
[08:11] jond the outpipes case however is correct. erase is not being passed iter, it is being passed a copy, the iterator has been moved before the call
[08:11] jond gcc seems to be going the correct things
[08:11] sustrik imagine this scenario:
[08:11] sustrik it points to memory at 0x1000
[08:12] jond are we talking about a map or vector?
[08:12] sustrik vector
[08:12] sustrik it's a map there?
[08:12] jond outpipes is a map, inpipes is a vector. this is why I think you misread the patch
[08:13] sustrik right
[08:13] jond inpipes code needs work around if vector::erase doesnt return the new iterator
[08:14] jond but as it stands i believe the patch is correct c++
[08:16] sustrik hm
[08:17] sustrik imo what happens is:
[08:17] sustrik cope of it is made
[08:17] sustrik one copy is passed to erase
[08:17] sustrik which invalidates both copies of the iterator
[08:17] sustrik then ++ is done on already invalid iterator
[08:18] sustrik what can be done is something like this:
[08:18] sustrik iterator tmp = it;
[08:18] sustrik tmp++;
[08:18] sustrik erase (it);
[08:18] sustrik it = tmp;
[08:20] jond I really believe in the outpipes case it should be safe to do outpipes.erase(iter++), isnt it effectively the same?
[08:22] sustrik what outpipes(it++) does IMO is this:
[08:22] jond josuttis : page 205 in my copy does it the same way for maps......
[08:22] sustrik iterator tmp = it;
[08:22] sustrik erase(it);
[08:22] sustrik tmp++;
[08:22] sustrik it = tmp;
[08:24] jond i think for maps it's safe!
[08:25] jond sustrik: I've gotta go now, but maybe it's worth getting some input on the mailing list??
[08:28] sustrik ISO C++ should be consulted
[08:29] sustrik exact semantics of postfix ++
[08:30] sustrik "When a postfix operator is applied to a function argument, the value of the argument is not guaranteed to be incremented or decremented before it is passed to the function. See section 1.9.17 in the C++ standard for more information."
[09:19] jond sustrik: good find. so 1) we are in agreement these iterators in two cases need fixing. map one can be solved by order of increment, vector perhaps using remove_if
[09:50] sustrik jond: yes, agreed
[11:07] mikko pieterh: overall the issue tracker is now better
[11:07] mikko (github)
[11:14] mikko i've been using cmake lately and it seems a lot nicer than autotools
[11:19] jond sustrik: actually the outpipes case is redundant. once element to erase is found it returns anyhow and no further iteration happens.....
[11:22] jond sustrik: as is the inpipes as far I can tell , it's only really an issue if you intend to continue the iteration post erase
[11:22] mikko odd that cppcheck doesn't complain about it
[12:31] pieterh mikko: hi
[12:33] mikko hey
[12:36] mikko 17:33 at brussels tomorrow
[12:37] iFire is there a survey of what people use for zeromq message encoding
[12:38] pieterh mikko: cool, small meetup tomorrow evening then
[12:38] pieterh mikko: you staying at my place?
[12:39] guido_g is this meetup a public one?
[12:40] pieterh guido_g: I'd guess so, yes
[12:40] guido_g iFire: not that i know of, most people use the serialization that's best for their tool-chain
[12:40] guido_g pieterh: ah great
[12:40] pieterh guido_g: you'll be in Brussels tomorrow evening?
[12:41] pieterh excellent!
[12:42] guido_g i guess it'll take me an hour or so to get to th hotel
[12:43] pieterh demarkten has wifi, not a bad place to work
[12:43] guido_g i personally prefer cable but wifi sounds good :)
[12:44] pieterh you can come to work at iMatix if you like
[12:45] pieterh We can meet at 2pm or so at demarkten and then walk back to iMatix
[12:45] pieterh it's about 10 minutes by foot
[12:45] guido_g ah ok
[12:46] pieterh it's a little out of the way
[12:47] guido_g hmmm... no address in the site
[13:00] pieterh indeed... I removed that, have added it back again on contact page
[13:00] guido_g ahh cool
[13:01] guido_g too much people comming in i guess :)
[13:10] mikko pieterh: yes, staying at yours if that's ok
[13:10] mikko pieterh: do you want me to bring linen?
[13:10] pieterh mikko: sure, if it's not a bother
[13:19] mikko pieterh: will do
[13:20] pieterh mikko: great... mato will also be staying at my place
[13:20] pieterh i've tweeted a meetup at 7pm in town
[13:20] mikko do i come straight to yours?
[13:20] mikko is it far from brussels midi?
[13:21] pieterh you can take a metro from brussels midi, it'
[13:21] pieterh it's too far to walk
[13:21] pieterh metro to yzer, then by foot
[13:22] pieterh you're traveling alone, I guess?
[13:29] mikko yes
[13:29] mikko i'm alone
[13:33] pieterh ok, if you get lost beep me on +32 475 235 984, and I'll come pick you up / find you
[13:38] guido_g google maps is funny, it shows the Rue de Ateliers label only if i zoom in to the maximum, otherwise only the dutch name is visible
[13:38] guido_g will be fun to navigate... :)
[22:00] notostraca I'm a little confused about 0MQ
[22:01] notostraca Could it work with something like Flash Sockets or Socket.IO on the client side, in the browser?
[22:02] notostraca I'm fairly new to networking in general, but 0MQ looks like it might be better than the alternatives (by a lot)
[22:02] notostraca hey mikey_w
[22:03] mikey_w Hello
[22:15] jer notostraca, could i'm sure, however, it's my experience that you don't want to have 0mq facing outwards -- i.e., where anybody might be able to connect to it. if they don't speak the 0mq protocol properly, the listening endpoint could die hitting an assert()
[22:16] jer which wouldn't be a problem normally, except there are all sorts of garbage fed to all sorts of listening ports on the internet -- just check an http server log sometime =p