Wednesday November 17, 2010

[Time] NameMessage
[04:52] pen hey
[09:32] kobus Hi
[09:33] kobus I downloaded the git master just now. Has the mingw fixes been incorporated yet?
[09:36] kobus And the git master does not contain a configure script and I can't run
[09:36] sustrik kobus: no, the mingw fixes are not yet there
[09:36] sustrik mato's going to work on that today, afaik
[09:37] kobus sustrik: Ok, I'm running out of time on a concept demonstrator. I will have to move on to another messaging lib. Any suggestions :-(
[09:41] sustrik depends on what you need
[09:44] kobus sustrik: I want a distributed notification mechanism with apps subscribing to specific notifications and also generate notifications
[09:52] mikko kobus: i can give you fix to test
[09:55] kobus mikko: Great
[09:56] mikko
[09:56] mikko fresh from the oven
[09:56] mikko when you link against the generated DLL define LIBZMQ_DLL_IMPORT
[09:57] mikko i haven't yet tested this on windows, only cross compilation build
[10:01] kobus mikko: I will try it. Thanks!
[10:01] mikko let me know how it goes
[10:06] mato back
[10:08] mikko mato: did you see my email?
[10:09] mato mikko: yes, going to look at it
[10:09] mikko mato: either we define a new define in our build saying "LIBZMQ_BUILDING" or let user define a constant when they link
[10:10] mikko because the static library build mingw32 does ends up using dllimport
[10:10] mikko which is not correct afaik. i understood that dllimport should be used when the DLL is linked against
[10:10] mato correct
[10:11] mikko but in the current code we end up using dllimport for static build
[10:11] mikko because DLL_EXPORT is not defined for static build
[10:11] mikko (no pic)
[10:11] mato do we care about the static library on win32 at all?
[10:12] mikko mingw32 static library on win32 can only be used with ming32 binaries
[10:12] mato precisely
[10:12] mato which really is a minority use case
[10:12] mikko we could use AC_DISABLE_STATIC
[10:12] mato 99% of windows developers just want a DLL they can link with
[10:12] mato the other 1% can go figure it out themselves
[10:13] mikko this probably affects cygwin build as well
[10:13] mato that is such a minority inside a minority that i really don't care too much, at least not right now
[10:13] mikko are we right to assume that if DLL_EXPORT is not defined we are linking against a dll? I think not
[10:14] mikko as you might compile statically using MSVC
[10:14] mato the MSVC project defines DLL_EXPORT
[10:14] mato the thing is, we can't solve all of these cases elegantly
[10:14] mato so let's solve the "joe user" case
[10:14] mikko that is true
[10:14] mato which is, zmq being built as a DLL, application linking against a DLL
[10:14] mikko disable static build for cygwin and mingw32
[10:15] mato yes
[10:15] mato and we don't ship MSVC static build projects either so that is not an issue right now
[10:15] mikko i think AC_DISABLE_STATIC needs to be called before AC_PROG_LIBTOOL
[10:15] mikko i can produce a patch for this if you like
[10:15] mato we need to do two things.
[10:15] mato 1. AC_DISABLE_STATIC
[10:16] mato 2. test if the user force-enabled static and stop with an error
[10:16] mato telling them outright that static builds are not supported
[10:17] mato mikko: well, i can try and make a patch, i have native mingw on win2k3 working now
[10:18] mato so we're agreed that the best approach is to disable static builds entirely?
[10:19] mato mikko: or you make the patch, since you've already got that patch series in progress, and i'll test it
[10:19] mato up to you
[10:19] mikko mato: i can do the patch
[10:19] mato ok. let me know when it's ready and i'll test it
[10:20] mato so there should be no need to change the definition of ZMQ_EXPORT?
[10:25] mikko no need
[10:25] mikko if we assume that link is against dll
[10:25] mato ok, good
[10:25] mato sustrik: you following this at all?
[10:26] sustrik slightly
[10:26] mikko mato: found a possible autoconf annoyance on the way
[10:26] sustrik i don't understand it much
[10:26] mato sustrik: the outcome is, we want to disable static library builds for Mingw
[10:26] mato sustrik: because it's impossible to support them elegantly
[10:27] mato sustrik: our assumption is that 99% of windows developers only ever want a DLL anyway
[10:27] sustrik sure, nobody uses static libs on win today anyway
[10:27] mato mikko: what's that?
[10:27] mato sustrik: ok, so we'll officially disallow that
[10:27] sustrik ok
[10:27] mato sustrik: since the alternative is not worth the effort
[10:31] mikko mato: AC_DISABLE_STATIC doesn't play nice in a conditional
[10:33] mato mikko: ah, as in inside an if statement?
[10:33] sustrik Guthur: hi, there's an email at ML that looks like related to clrzmq2
[10:34] sustrik "System.AccessViolationException with multiple subscriptions"
[10:34] Guthur sustrik, cheers, I didn't get to check my emails this morning, I will check it out
[10:35] sustrik thx
[10:36] mikko mato: yes
[10:38] mato mikko: this seems to suggest it at least sort of works:
[10:39] mato
[10:40] Guthur sustrik, Not the most descriptive ticket ever, hehe
[10:40] mikko mato: saw that
[10:41] sustrik Guthur: yeah, i'm not even sure it's clrzmq2
[10:41] mikko mato: i'll send you what i got
[10:41] mikko mato: in theory this should work
[10:41] mikko but it disables static build for everything
[10:42] Guthur sustrik, I'm at work at the moment so I may have to wait until I get home before getting very far with it
[10:42] Guthur I can't post to the ML from here
[10:42] sustrik Guthur: sure, no haste
[10:43] mikko mato: looks like i need AC_ENABLE_STATIC for the non cygwin/mingw32 branch
[10:43] mato mikko: :-(, ok but how does that interact with what the user asks for on the command line?
[10:43] mikko mato: command line overrides that
[10:46] mato mikko: my main concern is that at least some people on *NIX like to build with --disable-shared, e.g. when developing
[10:47] mato anyway, we can try all the sane combinations and see what happens
[10:50] sustrik mato, mikko: --disable-shared should work on *nix
[10:50] sustrik debugging without it is a pain
[10:50] mato sustrik: yes, yes, of course, by "some people" I meant precisely you :-)
[10:50] sustrik :)
[10:52] mikko mato:
[10:52] mikko slightly weird at the moment
[10:52] mikko but seems to work
[10:52] mikko just need to clean up a bit
[10:55] mato ok, am going to test
[10:56] sustrik mikko, mato: i've sent the proposal to make mikko a maintainer
[10:56] sustrik if nobody objects, we'll move on with it
[11:00] mato mikko: you're missing a "test" on line 56
[11:00] mato mikko: it should read "if test "x$enable..."
[11:03] mikko mato: that part is a bit shady anyway
[11:03] mikko if you look carefully
[11:03] mikko it checks enable_static and errors out before AC_PROG_LIBTOOL has been called
[11:03] mikko not very logical
[11:07] mato mikko: yes, i'm just inspecting the configure output
[11:07] mato mikko: it doesn't look entirely happy
[11:08] kobus mikko: Thanks, look like it builds ok. I just get an error: g++.exe: C:/msys/1.0/mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory. My MSYS has been configured to use a MinGW in the Qt SDK. So, I have to figure out why it is looking there
[11:08] mikko mato: this is the second iteration
[11:08] mikko mato: possibly a bit cleaner
[11:09] mato yes
[11:09] mato i'll try that
[11:09] mikko "whether to build static libraries" doesnt say "no"
[11:09] mikko it just leaves blank
[11:09] mato that's fine
[11:12] mikko autoconf is such a hack
[11:14] mato mikko: the 2nd iteration is much better, I no longer get weird errors from configure during it's operation
[11:14] mato mikko: so it seems you moved the libtool initialization "early" enough to make it work correctly
[11:15] mato ok, works on Linux with and without --disable-shared, going to check on windows
[11:22] kobus mikko: My mingw doesn't even have a libstdc++.dll.a
[11:22] mikko hmm
[11:22] mikko kobus: do you have libstdc++.dll ?
[11:26] kobus mikko: In the mingw bin dir I have libstdc++-6.dll...
[11:27] mikko kobus: i can only talk for cross-compile
[11:27] mikko mato: does it build?
[11:28] mato mikko: building now
[11:30] kobus mikko: Strnage that gcc wants libstdc++.dll.a, I have a linstdc++-6.dll and libstdc++.a
[11:30] mikko i wonder if it does have anything to do with the qt sdk
[11:30] mikko kobus: try building --disable-static
[11:30] mikko kobus: thats what the newer revisions of the patches do
[11:31] kobus mikko: should I get the latest git master
[11:32] mikko kobus: it's gonna take a few moments to get there. mato is testing the build on windows now
[11:32] mikko kobus: so if you wait until the build finishes we should know whether the fixes work
[11:34] mato mikko: ok, it builds, and make check works apart from inproc and ipc
[11:34] mato sustrik: win32 does not do "inproc" ?
[11:34] mato sustrik: i thought only "ipc" was unsupported
[11:35] sustrik it does
[11:35] sustrik why do you think so?
[11:35] mato oh, it's only the reqrep test that's failing
[11:35] mato interesting
[11:36] mato terminate called after throwing an instance of 'zmq::error_t' what(): Protocol not supported
[11:36] mato This application has requested the Runtime to terminate it in an unusual way.
[11:36] mato Please contact the application's support team for more information.
[11:36] mato FAIL: test_reqrep_ipc.exe
[11:36] mato sustrik: possibly a portability issue. those tests have not been checked on windows at all
[11:36] mato something to check eventually...
[11:36] mato ./c
[11:37] sustrik ok
[11:40] Guthur sustrik, I tried 16 subscribing processes on my box here, using clrzmq2, no exception
[11:41] sustrik Guthur: sure, just say so
[11:41] Guthur Once I get home, I'll reply on the ML
[11:41] sustrik you don't have to do other prople's homework, just let them know you are paying attention
[11:43] Guthur sustrik: ack
[11:47] mato mikko: ok, all seems to work, i checked that on mingw --disable-shared / --enable-static behave as expected (i.e. fail)
[11:48] kobus mato: So can I use --disable-static?
[11:49] mato kobus: I'd suggest you want until these fixes we're working on land on master.
[11:50] mato kobus: *wait
[11:50] mikko mato: happy with the patch?
[11:50] mato mikko: yes, the question now is, we should probably get this into maint as well as master, right?
[11:50] mato mikko: since 2.0.10 will have the same problems
[11:52] mato mikko: so, shall we take your patches from yesterday, #1,#2,#3,#5 plus this patch, and apply all to maint and master?
[11:53] mato there doesn't appear to be anything specific to master in any of those patches AFAICT, let me try and apply them to maint now...
[11:53] mikko mato: are all of them relevant to maint as well?
[11:53] mikko like removing the stdint substs etc
[11:54] mato mikko: probably, checking now
[11:55] mato mikko: hmm, actually they'd have to be re-done for maint
[11:55] mato mikko: stuff has changed
[11:55] mikko mato: line numbers wont match etc
[11:55] mato sustrik: do we want to fix mingw in maint at all?
[11:55] mikko mato: i don't know whether we even should do these for maint
[11:55] mato sustrik: is it worth it?
[11:55] mato mikko: yeah
[11:55] mato mikko: i'd be inclined to leave maint as is
[11:56] mikko mato: i agree
[11:56] mato ok
[11:56] mikko it also adds pressure to get 2.1.x beta / alpha out
[11:56] mikko which is a good thing
[11:56] mato yes
[11:56] mato i finally have time to get through the bits i have pending, so that will happen soon
[11:57] mato only thing pending from my side is documentation review and DSO symbol visibility
[11:57] mato the latter implies we can finally start numbering the DLL/SO ABI versions properly
[11:57] mato so master would be (I guess)
[11:59] sustrik +1
[11:59] sustrik let people move to 2.1
[11:59] mato ok
[12:23] mikko mato:
[12:23] mikko happy with those going to ML?
[12:23] mikko will send after lunch
[12:52] mato mikko: yes, happy, just when you send them, please expand the commit messages a bit
[12:52] mato mikko: "MinGW32 build fixes" is not very descriptive
[12:52] mato mikko: otherwise, it's all good
[12:52] mato mikko: thanks!
[13:01] mato i have to go, bbl maybe
[13:30] Guthur pieterh: In zmsg.c the comments for encode and decode in zmsg.c are little confusing
[13:31] Guthur they are both the same yet obviously one is from string -> byte and the other byte -> string
[13:31] pieterh Guthur, feel free to send me a patch...
[13:31] pieterh I don't have my pc here, mobile phone only
[13:32] pieterh That code is also in zfl now, zfl_msg class
[13:33] Guthur pieterh, ok I'll try to get something sent later this evening
[13:33] pieterh Nice :)
[13:34] Guthur pieterh: Also, in regards to ZPL, do you see it only being used for device configuration? or should there be some support for arbitrary connections as well?
[13:35] pieterh I'd like to use zpl as a general config format, and layer device configs on top of that
[13:36] Guthur ok, it's just that the examples only really showed context and device
[13:36] pieterh It's confused now, two problems solved together
[13:36] Guthur in regards to device creation I was thinking some sort of factory pattern might be nice, to remove the creation away from the config class
[13:37] pieterh It came out of device configuration but we're starting to use it more widely
[13:37] pieterh Yes, a factory pattern
[13:37] Guthur I have a prototype working in C# for the current devices (queue, forwarder, and streamer)
[13:37] pieterh zfl_device or somesuch
[13:38] pieterh See also the zdevices project where I hope to collect example devices in random languages
[13:38] Guthur oh, I'll check that out
[13:39] pieterh It should probably move to the ZeroMQ organisation on github
[13:40] Guthur yeah it would make sense
[13:41] Guthur I don't think devices should really have been including in the main 0MQ lib
[13:41] Guthur included*
[13:41] Guthur but on the other side are worth having around
[14:07] Guthur pieterh: I can put my implementation of device creation on github if you would be interested in having a look
[14:08] Guthur Even if you are not familiar with C# you should be able to understand it
[14:09] pieterh Ah, for sure, sharing code is always good... do use the list, many people are interested in devices imo
[14:11] mikko howdy pieterh
[14:11] pieterh Hi mikko!
[14:12] mikko hows tricks?
[14:15] pieterh Ah, well enough...
[14:15] pieterh Kind of laid up for a while, but have my trusty Android
[14:15] CIA-20 zeromq2: 03Mikko Koppanen 07master * r3dbd5d5 10/ ( tests/
[14:15] CIA-20 zeromq2: Fix mingw32 build
[14:15] CIA-20 zeromq2: MinGW32 defines __int64_t as long long, which causes the build to fail
[14:15] CIA-20 zeromq2: unless -Wno-long-long is used. In addition the shutdown_stress test
[14:15] CIA-20 zeromq2: isn't currently compatible with Win.
[14:15] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[14:15] CIA-20 zeromq2: 03Mikko Koppanen 07master * r9255952 10/ (acinclude.m4
[14:15] CIA-20 zeromq2: MinGW32 build fixes
[14:15] CIA-20 zeromq2: After long discussions in IRC we came to conclusion that there is no
[14:15] CIA-20 zeromq2: elegant way to handle static builds with MinGW32. This patch sets
[14:15] CIA-20 zeromq2: AC_DISABLE_STATIC by default on MinGW32 and Cygwin
[14:15] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[14:15] CIA-20 zeromq2: 03Mikko Koppanen 07master * rb83d0a1 10/ ( src/
[14:15] CIA-20 zeromq2: Remove unnecessary conditional
[14:15] pieterh Mato is working on a 2.1 I hear, that'll be nice to see
[14:16] CIA-20 zeromq2: Remove unneeded substitutions
[14:16] CIA-20 zeromq2: Couldn't find a place where these substs were actually used
[14:16] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[14:16] CIA-20 zeromq2: 03Mikko Koppanen 07master * r72a7b93 10/ acinclude.m4 :
[14:16] CIA-20 zeromq2: Allow building without documentation.
[14:16] CIA-20 zeromq2: Allows building without documentation even if asciidoc and xmlto are
[14:16] CIA-20 zeromq2: installed. This eases up working with the build system because doc
[14:16] CIA-20 zeromq2: generation take quite a while on repeated builds.
[14:16] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[15:10] toni hey there. I want to send a msg from an XREP to a REQ socket. The message came from a further XREP socket and therefore still has the envelope of the original sender. So I append another envelope containing the address of the REQ socket. So, the message the REQ socket receives contains one envelope. It seems that REQ socket require msgs without any envelopes. So I guess I have to store the envelope information as part of the payload. P
[15:12] toni fyi I get an "Assertion failed: zmq_msg_size (msg_) == 0" in case the incoming message at the REQ socket contains an envelope
[15:12] guido_g there is a whole chapter in the guide about routing
[15:13] guido_g the address stack is delimited by a 0 sized message part, this is hardcoded
[15:15] toni okay, the message contains this 0 sized part. But is it illegal to have an envelope prepended when the message is received by the REQ socket?
[15:17] guido_g obviously your address stack isn't valid
[15:18] guido_g <- check this first, i'd say
[15:35] toni I read the guide and this chapter. So my problem is, when poping the envelope and passing this to the XREP: [req_sock_addr, '', data] it works. In case the message looks like this: [req_socket_addr, client_addr, '', data] it is received by the REQ socket, but I am getting this error. So my question is if a REQ sockets does not allow envelopes when it receives a message.
[15:36] sustrik toni_: req socket expects only the backtrace stack delimiter (i.e. empty message part) to be present in the reply aside of its actual content
[15:37] toni sustrik: ah okay, so I have to pack the "client_addr" as part of the payload
[15:37] toni thanks
[15:37] sustrik np
[15:55] mikko heyo
[15:55] mikko now when sustrik applied my patches it looks like my git tree locally is clean
[15:55] mikko no diffs and nothing to commit
[15:55] mikko still git status shows Your branch is ahead of 'origin/master' by 6 commits.
[15:56] mikko how do i reset the state without git remote rm origin and readd?
[16:01] mikko git reset --hard origin/master probably
[16:17] kobus mikko: Has the mingw issues now been resolved? If so, how should I get the new code?
[16:20] mikko kobus: please try the master
[16:20] mikko kobus: it works for mato's clean mingw32 environment
[16:20] mikko kobus: can't say anything about the QT mingw
[16:21] mikko kobus: for master you need to run ./ if that is not possible in your env i can wrap you a dist package
[16:22] kobus mikko: It is just mingw installed under the Qt SDK dir. I installed MSYS and configured it to use the mingw by added the dir in /etc/fstab
[16:23] kobus mikko: If I run ./ I get: error: could not find pkg-config. pkg-config is required to run
[16:23] mikko kobus: i can do you a dist package if you want
[16:24] kobus mikko: I would appreciate it. Thanks for your effort! You are "a scholar and a gentleman" :-)
[16:25] kobus mikko: BTW just checking, you run autogen on Linux...
[16:29] mikko kobus: yes
[16:29] mikko you can run it on windows as well but you need to install pkg-config
[16:29] mikko which comes with hefty dependencies
[16:29] mikko like glib etc
[16:31] kobus mikko: So autogen generates the configure script? Based on what "inputs"?
[16:32] mikko kobus: try
[16:33] mikko kobus: yes, autogen runs all the required tools to generate configure
[16:33] kobus mikko: Thanks, wil try...
[16:33] mikko autoreconf etc
[16:39] kobus mikko: Well it still gives the libstdc++.dll.a error.
[16:40] mikko whats the exact error message again?
[16:40] kobus mikko: g++.exe: C:/msys/1.0/mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory
[16:41] mikko kobus:
[16:41] mikko similar error
[16:42] mikko kobus: this suggests a mingw bug
[16:45] mikko kobus: not sure if my tests are with same mingw version
[16:49] kobus mikko: I quickly try to switch a different mingw, but it didn't work. But I will try it with a later version at home. The wife sent an SMS
[16:50] mikko kobus: i can try on windows later today
[16:50] mikko need to do a couple of things first
[16:50] kobus mikko: Thanks again for your help and effort. I will chat again later today or tomorrow
[16:51] mikko cool
[16:51] mikko talk to you later
[16:51] kobus Ciao!
[17:08] mikko mingw32 succeeded on faily builds
[17:10] sustrik nice
[17:11] mikko still a couple of fixes coming
[17:11] mikko but the build looks pretty good now
[17:11] sustrik yep, only couple on bindings failing
[17:11] sustrik the core looks ok
[17:12] mikko well, it gives this: libtoolize: Remember to add `LT_INIT' to
[17:12] mikko which i assume because AC_PROG_LIBTOOL is called from a macro
[17:12] mikko but i got a fix for that and a couple of other things done this evening
[17:12] sustrik good, just post them to the list and i'll apply them
[17:13] mikko test_close (zmq.tests.test_socket.TestSocket) ... Assertion failed: !pgm_supported () (zmq.cpp:245)
[17:13] mikko pyzmq error test failure message
[17:14] sustrik seen that
[17:14] sustrik that's maint?
[17:14] sustrik yes
[17:14] mikko yes
[17:15] sustrik aha, the test in question opens two contexts
[17:15] sustrik which in turn initialises OpenPGM twice
[17:15] sustrik which fails with old version of OpenPGM
[17:16] sustrik solved in OpenPGM/5 which is included in master
[18:13] bgranger minrk1: hi
[18:27] s0undt3ch hello ppl
[18:27] s0undt3ch I've built pyzmq using --inplace, however when running tests I'm getting
[18:27] cremes interesting new project for building complex 0mq devices:
[18:27] cremes
[18:27] s0undt3ch
[18:28] bgranger s0undt3ch: where are you running the tests from?
[18:29] bgranger What platform are you on?
[18:29] s0undt3ch linux
[18:29] bgranger Did you build zeormq with pgm support?
[18:29] s0undt3ch bgranger: from where I've built it
[18:29] s0undt3ch zeromq is from my distro, ubuntu
[18:29] bgranger Version?
[18:30] s0undt3ch dunno if they build it or not with pgm
[18:30] s0undt3ch hmm
[18:30] s0undt3ch 2.0.10
[18:31] s0undt3ch hmm pyzmq 2.0.9
[18:31] s0undt3ch problem?
[18:32] bgranger Can you try it with 2.0.10. But this is an odd error that I have not seen before. We just released 2.0.10 pyzmq yesterday.
[18:32] s0undt3ch hmm
[18:32] s0undt3ch updating git
[18:33] s0undt3ch now I can't build pyzmq
[18:33] s0undt3ch
[18:35] s0undt3ch what's up with it?
[18:38] bgranger You just grabbed pyzmq master, which is not tracking 2.1. You need to grab our atual 2.0.10 release from here:
[18:39] bgranger
[18:41] bgranger Or if you want to follow the de branch for 2.0.x you can grab the 2.0.x branch.
[18:45] s0undt3ch Graterle Commu
[18:45] s0undt3ch opps sorry
[18:45] s0undt3ch bgranger: ah, ok
[18:50] bgranger Hi: we hare having an issue with pgm enabled zeromq and the pyzmq test suite.
[18:50] bgranger We don't use pgm in the test suite at all, but we are seeing a failure like this:
[18:51] bgranger Assertion failed: !pgm_supported () (zmq.cpp:240)
[18:51] minrk which happens in zmq_init()
[18:51] bgranger Are there limitations about how many contexts you can have per process if pgm is enabled.
[18:51] bgranger Yes, as Min said, it is zmq_init() that is failling.
[19:00] minrk zmq_assert (!pgm_supported ());
[19:00] minrk int rc = pgm_init (&pgm_error);
[19:01] minrk zmq_init() contains:
[19:01] minrk zmq_assert (!pgm_supported ());
[19:01] minrk ...
[19:01] minrk int rc = pgm_init (&pgm_error);
[19:01] minrk which seems to suggest that zmq_init can only be called once if you have PGM.
[19:01] minrk Is this correct?
[19:03] minrk If that's true, we need a way to check at runtime whether PGM is being used. Is there such a method?
[19:05] bgranger But I think the the assert should not assert. If pgm is already init'd, just pass?
[19:05] bgranger sustrik: are you around?
[19:06] minrk comments at the assert:
[19:06] minrk // Unfortunately, OpenPGM doesn't support refcounted init/shutdown, thus,
[19:06] minrk // let's fail if it was initialised beforehand.
[19:06] bgranger I would think that the pgm_supported assert should be turned into a flag that zeromq sets to track if it has called pgm_init
[19:06] bgranger Only assert is someone else has called pmg_init beforehand.
[19:16] sustrik re
[19:17] sustrik bgranger: well, it's a problem with OpenPGM
[19:17] bgranger OK
[19:17] sustrik it uses a global state
[19:17] sustrik 0MQ does not
[19:17] sustrik (all the global state is in contexts)
[19:17] sustrik so creating 2 contexts creates a problem with OpenPGM
[19:18] bgranger OK, so that is a known problem.
[19:18] sustrik in new version it was solved by adding reference counting to pgm_init
[19:18] sustrik yes, it's a known problem
[19:18] bgranger Is there a simple way we can determine if pgm is used, so pyzmq doesn't assert here.
[19:18] bgranger Or should be just wait for the new pgm.
[19:18] sustrik there's a new pgm with 2.1
[19:19] bgranger OK
[19:19] bgranger So this is only a 2.0 issue.
[19:19] sustrik yes
[19:19] sustrik it's kind of dirty
[19:19] sustrik but that's the way it is
[19:19] sustrik "solved in next version"
[19:19] sustrik shrug
[19:19] minrk it's still important to be able to check if 0MQ was built with PGM, how do we check that?
[19:19] sustrik hm
[19:20] sustrik even before creating a context?
[19:20] sustrik i don't think there's a way to find out
[19:20] minrk is there a way after creating one?
[19:20] sustrik trying to open a PGM endpoint :)
[19:20] sustrik if you get EPROTONOTSUP
[19:20] sustrik there's no PGM :)
[19:21] sustrik is it a problem?
[19:21] sustrik can't we do with "known problem, solved in next version"?
[19:21] minrk well, the pyzmq test suite fails, because one of the test categories creates multiple contexts
[19:22] sustrik yep, seen that
[19:22] sustrik if it really matters
[19:22] minrk And if we can check, we can skip the invalid tests as known failures
[19:22] sustrik in theory the refcounting code from newer versions of openpgm can be backported to old version
[19:22] bgranger Which is a problem because pgm is built on ubuntu by default, so the test suite will always fail there.
[19:22] sustrik is it?
[19:23] sustrik i am using ubuntu
[19:23] sustrik and i have to say ./configure --with-pgm
[19:23] sustrik to get pgm compiled
[19:23] sustrik or you mean mikko's auto builds?
[19:24] minrk I think he means the prebuilt package, yes
[19:24] minrk it does not build against pgm from source by default
[19:25] sustrik ok guys, if you believe it's a problem, please complain on the mailing list
[19:25] sustrik it's up to Steve McCoy to backport the fix
[19:25] minrk okay
[19:26] bgranger But I guess we can just try to use the pgm transport and set a flag in our test suite. Not pretty though. I would be tempted to simply let this go for now...
[19:27] minrk bgranger: if I just change the MQ test to use Processes instead of Threads, it would work
[19:28] bgranger Is that the only place we create a second Context in the test suite?
[19:28] bgranger If so I am fine with that.
[19:28] minrk it's a matter of one word in the test
[19:28] minrk I'm not 100% sure, but possibly
[19:31] bgranger OK, lets try that in 2.0.x
[19:31] minrk okay
[19:31] bgranger Unless you want to try to put out a 2.0.10 fix
[19:31] minrk In general, since this means that PGM introduces a pretty significant difference in what you are allowed to do, there should probably be a runtime-accessible ZMQ_HAS_PGM flag or something.
[19:31] minrk I'll put it in 2.0.x
[19:32] bgranger Yes, I agree (in zeromq).
[19:32] bgranger I think there is something like that, but it is not in the header file.
[19:33] minrk there's a macro used at compile time, but I don't think it's available at runtime
[19:33] bgranger Right
[19:48] s0undt3ch sorry ppl, how do I checkout a specific branch with git? I need to pull 2.0.x
[19:50] s0undt3ch solved
[19:50] Guthur mikko, What is the build website tracking?
[19:51] Guthur mikko, Can we get clrzmq2 added?
[19:51] s0undt3ch bgranger: still have the same issues with the 2.0.x branch
[19:51] s0undt3ch ie, the assertion error
[19:52] minrk That's because I haven't pushed the fix yet
[19:53] s0undt3ch ah, ok minrk. So there's a fix for this already?
[19:53] minrk well, workaround is more accurate
[19:53] minrk did you see the earlier discussion on this (~45 minutes ago here)?
[19:54] bgranger But pyzmq itself is working fine, the bug only affects situations where you create 2 contexts in the same process.
[19:54] s0undt3ch if it stops complainging and just works ;)
[19:54] s0undt3ch minrk: I was away, just read it now
[19:54] minrk ZeroMQ built with PGM can't have multiple contexts in one process, and some tests do that
[19:54] s0undt3ch bgranger: ah, my app did create more than one context
[19:55] s0undt3ch well, test script is more like it
[19:55] minrk that's a zeromq issue, not a pyzmq issue
[19:55] minrk If you want more than one context, you may not use PGM and 2.0.x
[19:56] s0undt3ch minrk: I probably won't need more than one context. At least for now
[19:56] minrk okay
[19:57] minrk I understand it's no longer a problem with 0MQ 2.1
[20:02] sustrik context is meant to be a singleton
[20:02] sustrik no point in creating multiple contexts
[20:03] sustrik (except for test purposes)
[20:03] minrk RIght, and it's tests that are failing
[20:04] sustrik yes, it makes sense there
[20:04] minrk will it still raise the assertion if I create the second context after closing the first?
[20:04] sustrik i was responding to <s0undt3ch>
[20:04] minrk sure
[20:04] sustrik minrk: it should not
[20:04] minrk okay
[20:16] bgranger minrk:
[20:16] minrk yes
[20:17] bgranger I am testing 2.1dev, have you changed EINTR to KeyboardInterrupt like we talked about...
[20:17] bgranger It seems to work that way...
[20:17] minrk ok, good
[20:17] bgranger Works super well!
[20:19] bgranger But I don't see the commit where you fixed this...
[20:19] minrk fixed what?
[20:19] bgranger Or did you do nothing?
[20:19] minrk I haven't pushed anything today
[20:19] bgranger I thought we would manually have to catch EINTR and raise KeyboardInterrupt.
[20:19] bgranger But it looks like it "just works"
[20:20] bgranger I think I understand what is going on...
[20:20] bgranger When you do ctrl-C, Python puts the KeyboardInterrupt on a queue to be handled when the interpreter is free.
[20:21] bgranger zeromq raises ENITR, and that allows the Python interpreter to actually raise the KeyboardInterrupt
[20:21] bgranger But the EINTR itself is silenced.
[20:21] minrk so we don't actually have to handle it at all?
[20:21] bgranger Right
[20:21] minrk very nice
[20:21] bgranger Yes, It worries me a little that the EINTR just sort of vanishes, but as long as it does so in a nice way, it is fine.
[20:22] bgranger I think the key is that both python and zeromq see the signal.
[20:22] bgranger But the test suite passes for 2.1 just fine.
[20:23] bgranger Which is huge.
[20:23] bgranger And FD and EVENTS seem to work fine.
[20:24] bgranger This will make it easier to integrate zmq sockets into Twisted.
[20:24] minrk ok, good
[20:25] minrk I didn't know enough about the new options to write good tests, but I did test that they are at least the right values, which we wouldn't get if we used uint64 like the others.
[20:25] bgranger That is fine.
[20:26] bgranger minrk: back to #ipython...
[20:26] minrk okay
[20:29] Guthur hehe, I was wondering what #ipython was
[20:35] minrk mikko: Is it possible to stop building pyzmq-master against zeromq-maint? pyzmq-master now depends on zeromq 2.1. We have a '2.0.x' branch that is the equivalent of zeromq's 'maint'
[20:35] mikko minrk: sure
[20:36] mikko i can disable the build
[20:36] minrk thanks
[20:36] minrk If you want pyzmq+zeromq-maint, you should use pyzmq-2.0.x
[20:36] mikko is it a different branch?
[20:37] minrk yes, the branch is actually called '2.0.x'
[20:37] mikko the build is now pyzmq-2.0.x_ZeroMQ2-maint_GCC
[20:38] mikko and the branch it builds from is 2.0.x
[20:38] minrk perfect, thanks!
[20:38] mikko building now as a test
[20:39] mikko minrk: builds, the tests still fail for that branch as well
[20:39] minrk Ah, sorry, I was actually just in the process of pushing a possible fix
[20:41] minrk It's a pgm issue in the test suite, but at least the target is right, so once I fix the bug, it will work
[20:41] minrk pyzmq-master would never build against zeromq-maint, until zeromq-maint is 2.1 though
[20:42] mikko ok
[20:42] mikko hopefully the builds are now sorted
[20:42] mikko i can add you an account if you want to configure pyzmq builds further
[20:42] minrk oh, sure
[20:42] mikko email notifications or such
[20:42] mikko sec
[20:42] minrk That would be great
[20:43] mikko minrk: see query for user / pass
[20:43] mikko oh wait
[20:43] mikko i need to add permissions as well
[20:44] mikko now if you try with the details
[20:44] mikko you should be able to login / edit builds
[20:45] minrk great, thanks
[21:10] Guthur mikko: did you see my message about clrzmq2 earlier
[21:20] mikko Guthur: nope
[21:21] mikko missed that one
[21:21] mikko what was it about?
[21:21] Guthur It was about how we would go about adding clrzmq2 to the build system
[21:21] mikko give me url to the repo and instructions how to build and i can add it
[21:22] mikko does it build in mono?
[21:22] Guthur it has a 4 build configurations in the solution
[21:22] Guthur mikko yep
[21:22] mikko current clrzmq uses "xbuild clrzmq.sln"
[21:23] Guthur it has POSIX/WIN-Debug/Release
[21:23] Guthur and can target x86 or x64
[21:23] mikko is the repo under zeromq organisation?
[21:24] Guthur yep
[21:24] Guthur 2 secs i will get the link
[21:24] mikko ok, let me try to build it
[21:24] Guthur
[21:25] Guthur I would definitely be appreciative of feedback on the build process
[21:26] mikko /usr/lib/mono/3.5/Microsoft.Common.targets: warning : TargetFrameworkVersion 'v4.0' not supported by this toolset (ToolsVersion: 4.0).
[21:26] Guthur oh darn, that should be defaulting to 2.0
[21:27] Guthur MSVS changed it
[21:27] mikko /usr/lib/mono/3.5/Microsoft.CSharp.targets: error : Error executing tool '/usr/bin/dmcs': ApplicationName='/usr/bin/dmcs', CommandLine='/noconfig @/tmp/tmp6f5fdb71.tmp', CurrentDirectory='/tmp/clrzmq2/clrzmq'
[21:27] mikko getting that as well
[21:27] Guthur oh that's new
[21:27] Guthur let me try here, the solution most have got changed by MSVS
[21:27] Guthur It's a challenge to juggle the two
[21:28] Guthur sorry mikko, give me a couple of minutes here
[21:29] Guthur The problem is now that if I change it with Mono it will probably be troublesome for MSVS
[21:30] mikko sure
[21:31] Guthur ok give me a bit longer and I will see if I can make the changes in MSVS so that it works for Mono
[21:31] Guthur just need to fire up the VM
[21:32] Guthur the framework one is easy
[21:32] Guthur the other one may is stranger
[21:32] mikko how do i build with xbuild ?
[21:32] mikko xbuild /target:??,??
[21:32] Guthur not sure, never used that before
[21:33] Guthur I can investigate though
[21:33] Guthur i was using monodeveloper
[21:33] Guthur monodevelop even
[21:33] mikko i think xbuild is the build tool from that
[21:35] Guthur must be separate, I don't have it install even though i have monodevelop
[21:35] mikko comes in mono-xbuild package
[21:36] mikko xbuild is Mono's implementation of msbuild
[21:41] Guthur no probs, i've got it now
[21:41] Guthur i'll see if I can get it working
[21:41] mikko mdtool build --configuration:'POSIX_RELEASE|x86'
[21:41] mikko that builds it
[21:41] mikko ill add the build now
[21:43] Guthur Did you change the framework?
[21:43] Guthur I've just changed the framework of all the projects to 2.0
[21:44] Guthur about to push the changes
[21:45] mikko when i run this
[21:45] mikko mdtool build --configuration:'POSIX_RELEASE|x86' clrzmq.sln
[21:45] mikko it seems to output that it's building
[21:45] mikko but i can't find any build artifacts
[21:46] Guthur ok
[21:47] Guthur I will admit I have been using debug more than release
[21:48] mikko i should get a .dll out of the build process, right?
[21:48] Guthur yep
[21:48] Guthur just checking now
[21:49] mikko can you try building with either xbuild or mdtool?
[21:49] Guthur i'm using now
[21:49] Guthur it's in release folder for me
[21:49] Guthur clrzmq/bin/release
[21:50] mikko whats your mdtool line?
[21:50] Guthur I copied directly from you
[21:50] Guthur mdtool build --configuration:'POSIX_RELEASE|x86'
[21:51] mikko nothing here
[21:51] Guthur umm, let me push something first, ok
[21:52] mikko sure
[21:52] Guthur I want to change it to /bin/Debug for one thing
[21:53] Guthur it seems to always want to create that directory no matter what I set the output directory to
[21:53] Guthur so it now it ends up with /debug and /Debug, even though the output only goes to /debug
[21:55] mikko dmcs command is mono's preview implementation of framework 4.0
[21:56] mikko because the requirement is 4.0 xbuild tries to invoke it
[21:56] mikko and i don't have it installed
[22:01] Guthur clrzmq2 targets 2.0 and above
[22:01] Guthur It would be nice to have some of the sugar with 4.0 but it's probably better to support the wider install base
[22:01] mikko Guthur: sed -i s/v4.0/v2.0/ */*.csproj
[22:01] mikko and it builds
[22:02] Guthur I have change it back to 2.0
[22:02] mikko xbuild /property:Configuration=POSIX_RELEASE /property:Platform=x86
[22:02] mikko that is the xbuild line
[22:02] Guthur MSVS decided it knew best and changed it to 2.0 when I converted the solution
[22:02] Guthur 2.0/4.0
[22:03] Guthur I want to see if I can suppress the 3 warnings then I will push
[22:07] mikko in any case it's added here
[22:07] mikko it should build in 5am GMT daily build
[22:12] Guthur I'm just about to push
[22:12] Guthur mikko, one thing does mdtool, generate app.config?
[22:13] Guthur nvm, I think it is fine
[22:13] Guthur pushing
[22:15] Guthur pushed
[22:15] Guthur Sorry it wasn't as streamed lined as it could have been
[22:16] Guthur but many thanks for testing, much appreciated
[22:16] Guthur sorting out all this build issues proofs way more challenging and fiddly than the actual coding, hehe
[22:16] mikko still fails
[22:17] mikko i'll look into it in a min
[22:17] mikko need to iron a shirt for tomorrow
[22:17] Guthur no problem
[22:20] Guthur umm it throws errors yet it generates the dll
[22:22] Guthur ah i think it is something to do with the test projects
[22:23] Guthur mikko, do the test projects need to be built?
[22:24] Guthur oh I see the problem
[22:24] Guthur oops, my bad
[22:24] Guthur those app.config file were being tracked
[22:26] Guthur mikko: could you pull again, and try to build
[22:26] Guthur once you shirt is ironed of course, hehe
[22:26] Guthur your*
[22:27] mikko built
[22:27] Guthur cool
[22:27] mikko ** (local_lat/bin/Debug/local_lat.exe:2844): WARNING **: Shutting down finalizer thread timed out.
[22:27] mikko in test program
[22:28] Guthur umm
[22:28] mikko am i running the test programs correctly?
[22:28] mikko i've no idea what those bins do
[22:28] mikko (never had)
[22:28] Guthur they are not thoroughly tested to be honest
[22:28] mikko
[22:28] Guthur _thr
[22:28] Guthur was working
[22:29] Guthur I'll see if I can pin it down
[22:32] Guthur Sounds a little like the GC isn't cleaning up something
[22:33] Guthur I probably should call Dispose on Socket and Context Explicitly
[22:34] mikko am i running the test programs correctly?
[22:44] Guthur Yeah, it seems fine
[22:44] Guthur It would probably throw some error otherwise
[22:44] Guthur I think its the dispose process
[22:44] Guthur I am going to investigate
[22:45] mikko maybe socket is not disposed when it comes to disposing context?
[22:45] Guthur clrzmq2 inherited the dispose code from clrzmq and think it might be broken
[22:47] mikko i've seen this warning with clrzmq as well
[22:47] mikko this wasnt a problem before 2.1.x branch
[22:47] Guthur ok, this is worth checking out
[22:47] Guthur Give me a while to get to the bottom of it
[22:47] Guthur going to do some research on Dispose
[22:48] mikko ure, no hurry
[22:48] mikko the build is now added in any case
[22:54] Guthur ok the base code is fine, just the test programs are bogus
[22:55] Guthur they should explicitly dispose
[22:55] Guthur I'll fix those now
[22:56] mikko cool
[23:01] mikko i'm off to bed
[23:01] mikko see you tomorrow
[23:04] Guthur ok, thanks mikko