IRC Log

Monday February 14, 2011

[Time] NameMessage
[07:19] sustrik mikko: yes, clear roadmap to 2.1 would be nice
[07:20] sustrik however, i am not sure how to manage it within a distributed development model
[07:20] sustrik would it mean that patches out of scope of the roadmap are not accepted?
[09:45] mikko sustrik: sure they would
[09:45] mikko sustrik: im talking about feature roadmap
[09:45] mikko things that we know needs to be done
[10:30] mikko pieterh: there?
[10:31] pieterh mikko: hi
[10:31] mikko pieterh: is pkgconfig dependency acceptable in zfl?
[10:32] pieterh you mean autoconf tooling?
[10:33] mikko yes
[10:34] sustrik mikko: there's 3.0 roadmap
[10:34] mikko pieterh: let me show you a patch
[10:34] mikko sec
[10:34] pieterh mikko: I used the same framework as for zmq
[10:34] pieterh but all suggestions welcome, of course
[10:34] mikko pieterh: https://github.com/mkoppanen/zfl/commit/25219e93d42e8fff6fac696c7ebcbe6e661fa2c3
[10:34] mikko pieterh: i sent one pull request for mingw32 fixes earlier
[10:35] mikko that can be rewritten without pkgconfig as well
[10:35] mikko to remove the dependency
[10:35] pieterh sorry to be ignorant... I'm not even sure what pkgconfig is/does
[10:36] mikko NAME pkg-config - Return metainformation about installed libraries
[10:36] pieterh right
[10:36] mikko cflags, libs to link etc
[10:36] pieterh if you're happier removing the dependency, that's fine by me
[10:37] mikko ok, ill tinker with it this evening
[10:37] mikko the mingw32 fix is more straight-forward
[10:37] mikko https://github.com/mkoppanen/zfl/commit/ce88c706fc0c1bb023cc422e0c707a1a90a07fe8
[10:37] pieterh let me apply that mingw32 patch then...
[10:37] mikko the assumption before was that build happens on linux if gnu compiler is used
[10:37] mikko so -DLINUX got defined in mingw32 and bsd
[10:37] mikko etc
[10:37] pieterh right
[10:38] pieterh there is some plausible benefit in having zfl build the same way as zeromq2
[10:38] pieterh and i assume you made a similar patch for the zeromq2 configure.in?
[10:38] mikko pieterh: zeromq2 hasn't had that in ages
[10:39] pieterh the dependency, you mean?
[10:39] pieterh aight
[10:39] mikko the dependency to pkg-config can be removed
[10:39] mikko ill make a clean patch this evening
[10:39] pieterh nice
[10:39] mikko i think it's easier for users to do: ./configure --with-libzmq=/usr/local
[10:39] mikko rather than having to specify CFLAGS and LDFLAGS
[10:40] mikko this is really more zfl specific as it uses zeromq as a dependency
[10:41] mikko i'll add zfl build on solaris and freebsd at some point
[10:48] pieterh mikko: pull request merged
[10:49] mikko pieterh: will run mingw32 build now
[10:49] mikko sec
[10:49] mikko mingw32 and linux builds running now
[10:49] pieterh on linux it looks in /usr/local by default, right?
[10:49] mikko nope
[10:50] pieterh hmm, so how does this work on all my linux boxes without any special options...?
[10:50] mikko you've added /usr/local to runtime linkers conf
[10:50] mikko ?
[10:50] mikko or your distro adds it
[10:50] pieterh let me check...
[10:50] mikko cd /etc/ld.so.conf.d/
[10:51] pieterh LD_LIBRARY_PATH...
[10:51] mikko https://build.valokuva.org/job/zfl-master_ZeroMQ2-master_mingw32/19/
[10:51] mikko mingw builds now
[10:51] mikko and linux builds as well
[10:52] mikko this is how i got it configured on build box:
[10:52] mikko CFLAGS="-I${ZEROMQ2_PREFIX_MASTER_MINGW32}/include" LDFLAGS="-L${ZEROMQ2_PREFIX_MASTER_MINGW32}/lib" ./configure --target=mingw32 --build=i686-linux --host=i586-mingw32msvc
[10:52] mikko for mingw32
[10:52] mikko linux is: CFLAGS="-I${ZEROMQ2_PREFIX_MASTER_GCC}/include" LDFLAGS="-L${ZEROMQ2_PREFIX_MASTER_GCC}/lib" ./configure
[10:54] pieterh hmm, I don't seem to need any of that... need to investigate
[10:55] mikko pieterh: the macro you use uses runtime linker
[10:55] mikko so if you got it configured then it should work (not sure about includes)
[10:55] stimpie I need to implement a push-pull with a custom loadbalancing strategy, what would be the recommend method? adjust the source and create a new socket type? implement it using PAIR's?
[10:55] mikko do echo | gcc -v -x c -E -
[10:55] mikko and check for default includes
[10:56] pieterh mikko: yes, gcc goes looking in /usr/local/include
[10:57] pieterh stimpie, read the Guide and Ch3 on custom routing using XREP sockets
[10:57] pieterh to do custom routing you *always* use an XREP socket
[11:01] pieterh mikko: IMO it's Ubuntu doing smart stuff with gcc configuration
[11:01] stimpie pieterh, ok thanks I will do some more reading
[11:01] pieterh stimpie, if it's not clear in the Guide, let me know
[11:02] mikko pieterh: yes
[11:02] mikko pieterh: hence the build flag would be nice
[11:02] pieterh mikko: so basically any gcc system that is not set-up to look in /usr needs these build flags
[11:02] pieterh that's clear
[11:02] pieterh feel free to change the README.txt file for zfl (patch)
[11:03] mikko pieterh: i'll create a new patch to add the flag and update docs while im at it
[11:03] mikko probably won't have time until this evening
[11:04] pieterh mikko: :-) there is no hurry
[11:40] Guthur mikko: what was the link to your logs again?
[11:40] mikko http://valokuva.org/~mikko/zeromq.log
[11:41] Guthur cheers, you don't mind me using it?
[11:41] mikko don't like to it if possbly
[11:41] mikko possible*
[11:42] Guthur oh no certainly, it was just for my personal use
[11:42] Guthur to check anything I missed
[11:42] mikko thats fine
[11:43] Guthur i see the talk of 2.1 roadmap earlier, this for movement to a stable release I assume?
[11:52] sustrik yeah
[11:52] sustrik i am not sure how to fomalise it though
[11:58] Guthur sustrik: are there many outstanding issues?
[11:58] mikko gant chart!
[11:59] sustrik :)
[11:59] sustrik the problem is that everyone here is a volunteer
[11:59] sustrik so there's no way to estimate anything
[12:01] Guthur are the issues prioritized at all yet?
[12:01] sustrik what would that be good for?
[12:02] Guthur well maybe there are some that must be resolved and some that would be nice to have resolved
[12:03] Guthur I've not looked at the issues though, so I don't know what there is
[12:03] Guthur is it just the list on github?
[12:03] sustrik well, the point is that even an issue with highest priority won't be solved unless someone decides to solve it
[12:03] sustrik so having priorities is kind of mute
[12:06] Guthur very true
[12:08] Guthur though from the github issue list it seems hard to know what is an issue stopping 2.1 becoming stable
[12:08] Guthur what/which
[12:09] sustrik there's no formal criterion
[12:09] sustrik if people are happy with stability of 2.1 it will become stable
[12:10] sustrik i think it has to do with migration to 2.1
[12:10] sustrik some people have switched already
[12:10] sustrik some have not
[12:12] sustrik if there's enough people using 2.1 in prodution, i believe we can make it "stable"
[12:20] Guthur is 0MQ then working towards a 2.2 after that
[12:22] sustrik either 2.2 or 3.0
[12:22] sustrik depends on overall sentiment of the community
[12:27] Guthur is the ØMQ/3.0 Roadmap up to date with current desires for 3.0?
[12:28] mikko i got a couple of desires that i would like to get in later releases
[12:28] mikko but it will take some time to produce patches
[12:29] mikko investigating UDT is one and another one is PUSH/PULL acks
[12:29] sustrik mikko: ack
[12:30] sustrik Guthur: the distinction is that 2.2 has to be backward compatible
[12:30] sustrik while 3.0 can break backward compatibility
[12:30] sustrik so 3.0 is a chance to fix API bugs and mis-designs
[12:31] sustrik however, introducing incompatible API is a painful process
[12:31] sustrik so people may choose to stick with existing API and work on 2.2 instead
[12:32] mikko do we have any outstanding ones?
[12:32] sustrik outstanding what?
[12:32] mikko "so 3.0 is a chance to fix API bugs and mis-designs"
[12:32] mikko api bugs and misdesign
[12:32] sustrik ah, many of them
[12:32] sustrik see socket option types
[12:32] sustrik they are a mess
[12:34] Guthur is that the: Review the types of socket options for getsockopt/setsockopt (it's kind of arbitrary now).
[12:34] sustrik another example: zero-copy should not be default
[12:34] sustrik zmq_send should look like POSIX send:
[12:34] sustrik zmq_send (void *buff, size_t size, int flags);
[12:34] sustrik Guthur: yes
[12:38] sustrik one intriguing option would be to provide both version of the API from the same library
[12:39] sustrik however, i am not sure whether that's technically possible
[12:40] Guthur like some compatibility layer on top the new API
[12:40] sustrik yep
[12:40] mikko LD_PRELOAD sumbols
[12:40] mikko symbols*
[12:41] mikko messy though
[12:41] sustrik not sure how portable that is
[12:41] mikko not very probably
[12:41] sustrik an alternative would be to export symbols such as:
[12:41] sustrik _zmq_init
[12:41] sustrik _zmq_socket
[12:41] sustrik etc.
[12:41] sustrik then have 2 header files
[12:42] sustrik containing simple inline functions
[12:42] sustrik that would call the appropriate _zmq routine
[13:40] pieterh sustrik: wrt 2.1 stable, IMO it's self-regulating...
[13:41] pieterh when there are no patches for a certain period you can assume it's stable
[13:41] sustrik yes, that's what i was saying
[13:41] pieterh difficulty is when you mix old and new code, it can remain unstable forever
[13:41] sustrik ack
[13:41] pieterh i'd not take master HEAD to stable, ever
[13:41] pieterh but rather the 2.1 unstable + patches -> stable
[13:42] sustrik i've missed that
[13:42] pieterh there is an unstable branch, no?
[13:42] sustrik master
[13:42] pieterh ah... well... this won't be optimal then
[13:43] pieterh not if you develop on master
[13:43] sustrik development should go on on topic branches
[13:43] pieterh yes but then it does not get tested...
[13:43] sustrik true
[13:43] pieterh i think the basic principle is that any specific code ages and becomes stable (or unused) automatically
[13:44] pieterh like fine wine
[13:44] sustrik that's the case with 2.1 i think
[13:44] sustrik people are already switching
[13:44] pieterh right but if you mix new wine with the old wine there is a problem
[13:44] pieterh you risk making a stable release that has relatively new, unproven code in it
[13:45] sustrik there's still a maint branch
[13:45] sustrik bugs are still patched in maint
[13:45] pieterh this is something to discuss with Mato when he's back from down-under
[13:45] sustrik yes
[13:46] pieterh if you can cleanly separate older code (6 months+) into its own branch you can push it to 'stable' safely
[13:46] pieterh e.g. stuff like the socket shutdown mechanics from 2.1
[13:47] mikko but in that case you need to separate well-tested from old
[13:47] pieterh but it would be a pity to have e.g. the bug I found on win32 yesterday to still be in a 'stable' release
[13:47] mikko older code that is implicitly used by everyone is more tested than some feature just used by some
[13:47] pieterh yeah
[13:47] mikko in the former you expect to see bugs quicker
[13:47] pieterh so you'd expect, IMO, to see
[13:47] pieterh - very stable (2.0.x), does not change except for major bugs
[13:48] pieterh - (almost) stable (2.1.x), maintained
[13:48] pieterh - raw (master HEAD)
[13:48] pieterh and all new work as rapidly as possible into HEAD
[13:48] pieterh e.g. xsub, xpub should be in HEAD now, so we actually test it
[13:49] pieterh but people have an 'official latest' release to work with
[13:49] pieterh to have to choose between 2.0.x and HEAD is kind of painful
[13:49] sustrik that's 2.1.0
[13:49] pieterh yeah, but it's not maintained :-)
[13:50] sustrik wait a sec
[13:50] sustrik there are 3 things there"
[13:50] sustrik 1. latest stable (2.0.10)
[13:50] sustrik 2. latest dev (2.0.1)
[13:50] sustrik 3. head
[13:51] pieterh 2. latest dev (2.1.0) ?
[13:51] sustrik 2.1.0, sorry
[13:51] pieterh ack
[13:51] pieterh let me add two things I think would help
[13:51] pieterh a. new code goes into HEAD asap, not topic branches unless extremely unstable
[13:52] pieterh b. latest dev is a branch and gets bug fixes from head
[13:52] pieterh rationale for a = faster testing of new code is very valuable
[13:52] mikko latest dev is bug fixes only?
[13:52] pieterh hmm, yes
[13:53] pieterh at least
[13:53] sustrik then it's same as maint
[13:53] mikko so when do new features get in?
[13:53] pieterh well, this rolls around
[13:53] mikko and is new version branched of from HEAD?
[13:53] pieterh latest dev becomes stable at a certain point
[13:53] pieterh and then new dev is branched from head
[13:53] pieterh like I'd suggest 2.1.0 + patches is today ready for stable
[13:53] pieterh we want people to move off 2.0.10
[13:54] pieterh of course the packages can remain available
[13:54] pieterh but we don't want people asking about stuff that was fixed 6 months ago
[13:54] sustrik i still don't see why we need two maintenance branches instead of a single one
[13:55] pieterh because you have two generations of 'officially released' code
[13:55] pieterh that is standard operating procedure
[13:55] pieterh and you need to maintain both branches
[13:55] sustrik me?
[13:55] pieterh while also having space for new functionality that is raw and liable to break
[13:55] pieterh not you
[13:55] pieterh one
[13:55] pieterh :-)
[13:55] sustrik :)
[13:56] pieterh i'm happy to do this
[13:56] pieterh i've said that often
[13:56] mikko if the process is being reviewed can we also look into using pull requests on github instead of signed patches?
[13:56] pieterh mikko: +1
[13:57] pieterh it allows the author of a patch to request explicitly that it be applied to a set of target branches
[13:57] pieterh and it creates an asynchronous workflow
[13:57] pieterh +100
[13:58] sustrik ok, we can have as many maintenance branches as we want
[13:59] sustrik have a look at linux, there are some 4-5 of them
[13:59] pieterh indeed
[13:59] sustrik as for new features, linux kernel uses concept of merge windows
[13:59] mikko do they still use the even and odd versions?
[13:59] sustrik nope
[14:00] sustrik basically, there's a week or two in each cycle
[14:00] sustrik when people can ask their new code to be merged
[14:00] pieterh linux kernel processes are *weird*, they don't always make good examples
[14:00] sustrik the rest of the cycle is used to stabilise the new codebase
[14:01] sustrik the merge windows eases the stabilisation process
[14:02] sustrik it makes the development of new features to happen in discrete steps
[14:02] pieterh i'd really avoid trying to imitate the Linux processes unless they solve real problems we face
[14:02] mikko i think one of the issues to solve is: clear and visible roadmap for new features
[14:02] sustrik well, this is the problem we face:
[14:03] sustrik the new fetures are merged in continuously
[14:03] sustrik so what you have is a shifting landscape
[14:03] pieterh i think the roadmap for 2.1 worked pretty well
[14:04] pieterh what sustrik says is right
[14:04] pieterh you cannot take a shifting landscape to stability
[14:04] pieterh today we have no way to produce a stable 2.1 release afaics
[14:04] pieterh except by putting all new work into topic branches and waiting for another 3 months
[14:04] pieterh and even then it would not be based on a real 'unstable'
[14:05] mikko we don't really classify incoming features much
[14:06] sustrik classify?
[14:06] pieterh mikko: you just need to ask Sustrik more often, "what are you going to make?" :-)
[14:07] mikko pieterh: im trying more and more be able to produce patches
[14:07] Guthur i'd like to +1 the pull request, more from a laziness point of view, hehe
[14:07] mikko sustrik: we get a fair amount of feature requests
[14:07] mikko sustrik: which i think could be classified based on two factors: value and effort
[14:08] mikko maybe more factors needed but as a baseline
[14:08] sustrik i see
[14:08] mikko small effort, large value -> you want to do those first
[14:08] sustrik in theory
[14:08] mikko large effort, large value -> maybe schedule somewhere future
[14:08] mikko etc
[14:08] sustrik the reality is that everyone scratches his own itch
[14:09] sustrik so people are going to do work on what they need rather than on effort/value estimates
[14:09] mikko i think this would also give 'tools' to people wanting to contribute
[14:09] mikko they could start from the small effort ones
[14:09] mikko sustrik: that is true as well
[14:10] sustrik sure, but do you really see people asking for something to do
[14:10] sustrik ?
[14:10] sustrik it's rather like they choose what to do depending on what they want to use 0mq for
[14:11] sustrik GSoC may be a bit like what you have in mind
[14:11] mikko GSoC and also individuals
[14:11] sustrik but even with GSoC you just sketch some ideas
[14:11] pieterh mikko, what could be nice is an area on the wiki where people *ask* for help on areas
[14:11] mikko there are people who contribute just for the sake of it
[14:11] pieterh i.e. acting as mentors
[14:11] sustrik and people are free to work on something completely different
[14:12] mikko is it too late for GSoC this year?
[14:12] sustrik nope
[14:12] sustrik the applications are to be posted shortly
[14:12] mikko we should apply. i think there are a couple of things that GSoC students could do
[14:13] pieterh mikko: there is a page on the wiki with about 50 ideas
[14:13] mikko pieterh: which one?
[14:13] pieterh it should be visible from the main community page
[14:13] pieterh hang on...
[14:14] pieterh yeah
[14:14] pieterh http://www.zeromq.org/topics:google-summer-of-code
[14:14] mikko hot topics
[14:16] pieterh :-)
[14:21] mikko udt and sctp are on the list
[14:21] mikko both very interesting transports
[14:22] mikko sustrik: https://github.com/zeromq/zeromq2/issues/issue/160 is this likely to be major change?
[14:23] Guthur From a prospective contributor point of view I think it would be nice to have a list of areas needing work
[14:23] Guthur i was looking at the GSoC and the 3.0 roadmap like that though
[14:23] Guthur i also have an interest in adding win32 IPC
[14:24] pieterh what do you think of the mentor idea?
[14:24] pieterh i.e. area of work means working with someone who helps you get into that code
[14:25] Guthur yeah that's a neat idea, though devs here tend to be very helpful as well
[14:25] Guthur i've been asking here regarding pointers in starting the win32 IPC
[14:26] Guthur got a lot the preliminary research done at the weekend there
[14:26] Guthur sustrik gave me a lot of pointers on where to start looking in ZMQ as well
[14:27] pieterh Grrr. we need ipc: working on windows... :-/
[14:27] pieterh just hitting problems due to that
[14:28] pieterh Guthur, can I help you make IPC work on win32?
[14:30] pieterh Oh... I'm using inproc: ... I take it back :-)
[14:35] mikko pieterh: zfl doesn't need to link against libuuid, right?
[14:36] Guthur pieterh: hehe, well hopefully someone will need it, I'm sure they will
[14:36] Guthur I just need to write some code now for it, my time is limited during the week though due to work, and I'll be in dublin on saturday
[14:37] Guthur hopefully slow but steady progress will be made
[14:39] sustrik btw guys, there's a need for backup mentor for GSoC
[14:39] sustrik i can be the mentor as i know the code best
[14:39] sustrik but the rules of GSoC require to have a backup mentor as well
[14:40] sustrik in case i got run over by car or something
[14:40] sustrik any volunteers?
[14:44] Guthur probably need to send that on ml
[14:44] sustrik i've already did :)
[14:45] sustrik no answer though
[14:51] pieterh mikko: well, zfl links with zeromq, which links with libuuid
[14:51] mikko pieterh: but zfl doesn't need to link libuuid
[14:51] mikko ?
[14:52] pieterh mikko: it's like I said... there are zfl classes that link zmq functions
[14:52] pieterh like zfl_msg and zfl_rpc
[14:52] sustrik zfl->libzmq->libuuid
[14:52] pieterh sustrik: that email had too many questions in it, I doubt many read the part about backup mentor
[14:52] mikko yeah, but zfl links against libuuid as well which i think is unnecessary dependency
[14:53] pieterh zfl_selftest will need it
[14:53] pieterh remove the dependency, see if it still works :-)
[14:54] pieterh sustrik: do you know any place to get kefir seeds in bratislava?
[14:54] mikko pieterh: i think it should be fine as libzmq doesnt expose any libuuid stuff directly
[14:55] sustrik hm, some bio-food store, i would say
[14:55] mikko so there should be no need for dependent programs/libraries to link with libuuid
[14:55] mikko will test
[14:55] sustrik never tried to buy it myself
[14:55] pieterh ah, katka will know... :-)
[14:56] sustrik you can buy kefir in any shop here
[14:56] sustrik but it's pasteurized
[14:56] sustrik so the culture is dead i suppose
[14:56] pieterh made from pasteurized milk but not itself pasteurized
[14:57] pieterh otherwise there'd be no point
[14:57] pieterh i've cultured kefir here, you can buy imported Polish kefir in some places
[14:57] pieterh but it's kind of hard to find
[14:58] pieterh mikko: regarding uuid, IMO it's better to leave the check in there
[14:58] pieterh since otherwise people will just get an error when they try to link their apps, if they don't have libuuid
[15:00] sustrik i have bottle of kefir in the fridge, it says nothing about pasteurisation, so it's probably alive
[15:01] sustrik my girlfriend suggests that the culture may be sold in pharmacy
[15:01] sustrik no guarantee though
[15:02] pieterh hmm, there are some online stores, will check them out
[15:03] pieterh heh, there are even kefir grain sharing communities :-)
[15:06] mikko pieterh: what do you mean?
[15:06] mikko pieterh: people shouldnt need to link libuuid
[15:07] pieterh mikko: we seem to have a misunderstanding...
[15:07] pieterh if you link with libzfl, you're going to need the uuid functions
[15:07] mikko pieterh: libzfl doesn't seem to use them directly (from what i can see)
[15:08] mikko pieterh: only through libzmq
[15:08] mikko or am i missing something (?)
[15:10] pieterh link is link
[15:10] pieterh there will be a dependency on uuid functions
[15:10] sustrik i think it's different for staci and dynamic libraries
[15:11] sustrik static*
[15:11] pieterh i don't think so
[15:12] sustrik if zfl links static version of libzmq, it has to link with libuuid
[15:12] pieterh if you do a static link, linker will search for uuid functions at link time
[15:12] mikko unless libzmq links static version of uuid
[15:12] mikko in which case they would collide
[15:12] pieterh mikko: libraries do not link...
[15:13] pieterh if you use dynamic libraries, executable will look for uuid functions at run time
[15:13] pieterh it's the same result
[15:13] pieterh if you use zfl you will eventually have to have uuid on your box
[15:13] pieterh libzmq *never* includes other libraries
[15:14] pieterh on no system, ever, afaik
[15:14] mikko libuuid is shared library dependency for libzmq
[15:15] pieterh if you remove the dependency check in configure.in, in zmq, libzmq will build fine
[15:17] pieterh and if you don't have libuuid installed, your apps will run until a peer tries to generate an identity
[15:18] pieterh alternatively if you're doing static links, your apps won't link at all
[15:18] pieterh this is precisely the same situation for a zfl app
[15:18] pieterh and therefore the check has exactly the same purpose and value
[15:21] mikko what happens in a situation where i have libzmq statically linked with libuuid and i try to use that with libzfl?
[15:23] mikko i guess thats more rare scenario
[15:24] sustrik i have no idea of how it is to be done
[15:25] sustrik however, i would suggest following the best practices
[15:25] mikko i guess it doesn't harm to have the explicit dependency there
[15:25] sustrik rather than trying to figure it out yourselves
[15:25] pieterh mikko: there is no such thing afaik as a "statically linked library"
[15:26] pieterh you create statically linked executables that pull in all referenced object files from various lbraries
[15:27] pieterh I don't know if any linkers allow a mix of static and dynamic
[15:27] mikko pieterh: on linux you seem to be able to include static libraries inside shared libraries
[15:27] mikko did some investigation a while ago regarding pgm builds
[15:27] mikko but it's non-portable case anyway
[15:28] pieterh weird and wonderful and in that specific case, if libzmq was changed to do that, we could drop the uuid check in zfl for those platforms
[15:28] mikko the only reason i know this is because i was looking into openpgm autotools builds and how to include the results of those in zeromq
[15:29] sustrik mikko: btw have you seen the email wrt. openvms builds?
[15:29] mikko but my original thinking was related to libzmq making a dependency to libuuid already it wouldnt be necessary in libzfl
[15:29] mikko but i guess it's ok to be explicit about it especially when its almost identical to zeromq build check
[15:30] mikko sustrik: yeah, haven't formulated a response yet
[15:30] sustrik actually, i think there's java on openvms
[15:31] sustrik but i have no idea whether hudson will run on it
[15:31] sustrik s/hudson/jenkins
[15:32] mikko we should be able to execute a script over ssh as well
[15:32] sustrik ack
[15:36] mikko sustrik: responded
[15:36] sustrik thx
[18:05] Guthur would a socket pool make much sense from a 0MQ perspective?
[18:06] Guthur I'm thinking of implementing in C# and was curious if it would translate down into the 0MQ lib
[18:34] pieterh Guthur, what problem does that solve?
[18:36] Guthur pieterh, so that sockets can be reused
[18:36] Guthur not sure if it will really benefit much
[18:36] Guthur in a managed environment it may have more benefit
[18:37] bitweiler can zeromq send any kind of data or does it have to be string data?
[18:38] Guthur bitweiler, the messages can contain any byte data
[18:38] bitweiler okay thanks :)
[18:42] Guthur pieterh, I had the situation where there is many differing threads coming in and I was thinking of having a pool of already connected sockets for them to use and reuse
[18:43] Guthur probably too specialized to be relevant to 0MQ
[18:57] Guthur it's partly inspired by WCF which is quite fast once it is 'warmed up', in part due to reusing the connection
[18:57] Guthur i need to bench of course
[19:03] pieterh Guthur, sorry, was away...
[19:03] pieterh Reusing connections could be a fun optimization but you may hit the issue of flushing messages on sockets
[19:03] pieterh I've seen apps that did a lot of socket opening and closing
[19:04] pieterh but they were IMO badly designed
[19:04] pieterh TCP startup costs are significant compared to message transfer
[19:13] Guthur it's a interesting minor wee exercise
[19:19] Guthur pieterh, are other socket types (in ZMQ) reasonable cheap to create
[19:57] pieterh Guthur, I'd expect them to be very cheap, yes... it's something to measure if you want figures
[20:02] cremes on linux do i need to do anything special to compile the lib to use epoll?
[20:02] cremes or does it pick that up automatically?
[20:06] Guthur cremes, will epoll is #ifdef ZMQ_HAVE_LINUX if that makes any difference
[20:06] Guthur will/well
[20:07] cremes Guthur: ah, i see that now
[20:08] cremes my config.log shows it set to 1 so i assume it picked it up correctly
[20:17] neale1 vargaz: I just pushed my s390x unwind changes. It hits a couple of common files in mini so you may want to inspect
[20:20] neale1 Sorry wrong window!
[20:28] cremes i am seeing something quite odd on linux (2.6.35-ARCH)
[20:29] cremes processes that should be idle are showing 80% cpu; it looks like it's all in zmq_poll
[20:29] cremes which is set for a 10ms timeout
[20:29] cremes that shouldn't tax the machine at all
[20:29] cremes suggestions on debugging this?
[20:34] pieterh cremes: perhaps you're doing other heavy work in that loop
[20:34] pieterh profiler should help
[20:34] cremes pieterh: nope, i'm not doing *any* work
[20:34] cremes running the exact same code on OSX shows around 3-5% cpu
[20:34] cremes do you have a suggested profiler?
[20:35] pieterh gprof springs to mind
[20:35] pieterh it sounds like a bug in zmq
[20:35] cremes okay, i'll poke at it with gprof
[20:36] Guthur cremes, you have remembered poll takes micro seconds, not sure if that would effect CPU load, but it's something I keep forgetting
[20:37] cremes Guthur: yes, i pass 10000 as the value for a 10ms timeout
[20:37] cremes it looks like a platform bug; osx is okay with it (for once) and linux is not
[20:43] mikko pieterh: pull req sent
[20:43] mikko pieterh: does that look sensible?
[20:47] pieterh mikko: hang on a sec
[20:49] pieterh mikko: yeah, but you removed the check for uuid :-)
[20:50] mikko i did?
[20:50] pieterh looks like it
[20:50] pieterh actually I don't mind, people building zfl will normally have built zmq already
[20:50] mikko oh, didnt save file before reverting that
[20:50] mikko i also noticed one thing
[20:51] mikko majority of the tests in configure.in for zfl are done in C++
[20:51] pieterh lol, yes, inherited from zmq
[20:51] pieterh feel free to rip em out
[20:54] mikko are you planning to use these things in the build in future?
[20:54] mikko as there is much inherited from zmq build
[20:54] mikko like checks for atomic operations
[20:54] pieterh to some extent this was meant to be a template for other libraries
[20:54] pieterh but I doubt that will happen
[20:55] mikko on zeromq side i tried to isolate these things into functions
[20:55] pieterh take an axe to it, you have a blank check
[20:55] mikko https://github.com/zeromq/zeromq2/blob/master/acinclude.m4
[20:55] mikko these should be fairly reusable if needed
[20:56] pieterh it's a shame it's not reusable as-is
[20:56] pieterh nice work
[20:56] pieterh mikko: are you volunteering to give the zfl tooling a clean-up?
[20:57] pieterh :-)
[20:57] pieterh for me, it works, which is kind of sufficient
[20:57] pieterh since what I really like doing is writing beautiful C code
[20:57] mikko pieterh: yes, i think the build can be simplified a lot
[20:57] pieterh mato yells from the back of the room, "keep trying old man, one day you'll get it right!"
[20:58] mikko i'll take a poke at it
[20:58] pieterh yay!
[20:59] pieterh i doubt we'll have more C/C++ libraries but it's always possible
[21:03] Guthur pieterh, It's ok there is probably only a handful of people how can write beautiful C code, and even less than that for C++ (probably none)
[21:03] Guthur how/who
[21:08] pieterh Guthur, I wasn't being modest :-)
[22:28] Luke234 Hey I'm trying to build and install the ZMQ java bindings for windows but can't locate the java class files the docs mention
[22:29] Luke234 http://www.zeromq.org/bindings:java
[22:29] Luke234 "Secondly, make sure that you have set the Java classpath to the directory where ØMQ classes reside." anyone know where I can get those classes?
[22:40] mikko Luke234: iirc you build them with ant
[23:18] Guthur sustrik: will it be possible for 0MQ to pass in an extended OVERLAPPED struct to pipe ops for use with IOCP, where the OVERLAPPED struct basically has the standard content plus what would usually be in poll_entry_t
[23:19] Guthur there is other possibilities though
[23:20] Guthur we could just pass a generic extend OVERLAPPED struct with the OP set, and use the completion key to get the poll_entry_t
[23:20] Guthur which might be neater

Web site design and content is copyright © 2010-2011 Peter Alexander, ProDataLab. Site content licensed under the Creative Commons Attribution-Share Alike 3.0 License. ØMQ is copyright © Copyright © 2007-2011 iMatix Corporation and Contributors. Contact us for professional support. ØMQ is free software licensed under the LGPL. ØMQ, ZeroMQ, and 0MQ are trademarks of iMatix Corporation. Terms of Use ? Privacy Policy