[Time] Name | Message |
[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 autogen.sh
|
[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
|
http://valokuva.org/~mikko/zeromq-2.1.0-mingw32.zip
|
[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
|
http://www.mail-archive.com/libtool-patches@gnu.org/msg02686.html
|
[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: https://gist.github.com/486c939595caf56a50e5
|
[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: https://gist.github.com/4ee2182fff0fae1b60d9 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) libzmq.so.1
|
[11:59] sustrik
|
+1
|
[11:59] sustrik
|
let people move to 2.1
|
[11:59] mato
|
ok
|
[12:23] mikko
|
mato: http://valokuva.org/~mikko/b/
|
[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/ (configure.in tests/Makefile.am):
|
[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 <mkoppanen@php.net> - http://bit.ly/9wYVtY
|
[14:15] CIA-20
|
zeromq2: 03Mikko Koppanen 07master * r9255952 10/ (acinclude.m4 configure.in):
|
[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 <mkoppanen@php.net> - http://bit.ly/bNNMmI
|
[14:15] CIA-20
|
zeromq2: 03Mikko Koppanen 07master * rb83d0a1 10/ (configure.in src/Makefile.am):
|
[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 <mkoppanen@php.net> - http://bit.ly/arqYuu
|
[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 <mkoppanen@php.net> - http://bit.ly/cik80A
|
[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
|
http://zguide.zeromq.org/chapter:all#toc42 <- 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 ./autogen.sh. 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 ./autogen.sh I get: autogen.sh: error: could not find pkg-config. pkg-config is required to run autogen.sh.
|
[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 http://valokuva.org/~mikko/zeromq-2.1.0.zip
|
[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: http://old.nabble.com/libstdc%2B%2B.dll.a%3A-No-such-file-or-directory%28gcc-4.4.0%29-td27186916.html
|
[16:41] mikko
|
similar error
|
[16:42] mikko
|
kobus: http://trac.osgeo.org/geos/ticket/282 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 configure.in.
|
[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
|
http://www.igvita.com/2010/11/17/routing-with-ruby-zeromq-devices/
|
[18:27] s0undt3ch
|
http://paste.pocoo.org/show/292687/
|
[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
|
http://paste.pocoo.org/show/292692/
|
[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
|
https://github.com/zeromq/pyzmq/downloads
|
[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
|
https://github.com/zeromq/clrzmq2
|
[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 http://build.valokuva.org/job/clrzmq2-master_ZeroMQ2-master_xbuild/
|
[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
|
http://build.valokuva.org/job/clrzmq2-master_ZeroMQ2-master_xbuild/4/console
|
[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
|