Friday September 23, 2011

[Time] NameMessage
[00:02] zedas Assertion failed: rc == 0 (zmq_connecter.cpp:48) am i reading this code right that it aborts with an assert if it can't connect to a port?
[00:04] zedas yep, looks like addresses like tcp://*:6000 cause this but not say tcp:// must be a change in osx lion, but an assert with no error message? c'mon.
[02:47] khigia hi guys
[02:47] khigia I found pretty easy to first part of message for the topic in PUB/SUB sockets
[02:47] khigia to use
[02:48] khigia any reason I should not use a message part to contain the message topic?
[02:49] khigia and btw, does zeromq 3.0.1 do the filtering on the publisher side (I thought I read this somewhere)?
[03:08] vkris mm... My java code complains " java.lang.UnsatisfiedLinkError: no jzmq in java.library.path".. This generally means its not able to find the native library in this path..
[03:08] vkris what is the name of hte file it is expecting ?
[03:10] vkris usr/local/lib/libzmq* files are already present
[03:10] vkris I am on OS-X
[03:11] vkris any once face similar issues ?
[03:16] cremes khigia: yes, 3.x filters on the pub side
[03:17] khigia cremes: thanks, could not find this in code
[03:18] khigia cremes: need to do filtering on both side to handle pgm protocol problem?
[03:18] khigia cremes: I mean the pub might not know the subscriber at all with upd, so subscriber cannot register its filter
[03:18] khigia cremes: can you point in the code where this is done?
[11:43] cremes khigia: publisher side filtering does not work for pgm transport; how could it?
[11:43] cremes take a look at the xpub/xsub.cpp files; all of the base logic is found there
[13:44] calvin has anyone seen a bug with multipart messages where sometimes it only gets one of the two parts?
[14:12] cremes calvin_: no
[14:12] cremes but it would be helpful if you told us what version you are using and which bindings
[14:12] cremes along with a code example
[14:13] cremes a bug like this *could* exist in 4.0 master, but it would be exceedingly improbable for 2.1.x or 3.x to have it
[15:03] Fade I'm using the Common Lisp bindings for zeromq, and I have a situation where I'm using a context for a whole bunch of different sockets by passing the context into a function that generates some closures. when I try to bind the socket in the closure, I'm getting "Bad address" ... what normally causes this error?
[15:07] Fade the socket should be talking to a router/dealer - xrep - socket in another process.
[15:07] Fade I think it's the context, not the socket, but I'm not really sure.
[15:42] cremes Fade: what causes that is a bad transport string
[15:43] cremes make sure it is legal, e.g. "tcp://" or similar
[15:44] neale1 I just checked the Jenkins build log for s390x and notice it's been failing for several days. The most recent failures show things of the type:
[15:44] neale1 terminate called after throwing an instance of 'zmq::error_t' what(): Address already in use
[15:44] neale1 FAIL: test_pair_tcp
[15:44] neale1 lt-test_shutdown_stress: test_shutdown_stress.cpp:65: int main(int, char**): Assertion `rc == 0' failed.
[18:37] vkris I am installing jzmq on OS X, Leopard.. any thoughts about this error guys ?
[19:27] cremes vkris: not really sure... maybe it's a java5 versus java6 syntax issue?
[19:27] cremes vkris: try activating java6 and try again
[19:27] cremes oh wait, nevermind, that's completely wrong
[19:28] cremes no idea
[19:30] Zenethian When using a PUSH socket or STREAMER device, is there a reasonable way to determine how many items are queued up waiting?
[19:31] Steve-o cremes: presumably it is something changed with the Java spec though
[19:32] cremes Steve-o: sure, but i thought bindings changes would get caught by the ci run
[19:32] cremes Zenethian: no, there is no visibility into the depth of a queue
[19:32] cremes and never will be
[19:32] cremes :)
[19:33] Steve-o vkris: I'd just hack out the affected lines :D
[19:35] Zenethian Is there a way to limit the number of items in the queue before it'll block?
[19:35] Steve-o ZMQ_HWM
[19:36] Zenethian hmmmm. I wonder if that's implemented in the Python library yet.
[19:36] Steve-o a socket option
[19:36] cremes Zenethian: it's been implemented for over a year... it's in there
[19:36] Zenethian woohoo
[19:36] Zenethian makes my life way easier, thank you
[19:36] Zenethian I'll look into it
[19:36] cremes Zenethian: be sure to read the man pages for zmq_socket; it describes the specific behavior of
[19:36] cremes each socket type when it reaches HWM
[19:37] minrk do let me know if there's anything missing in the Python bindings
[19:37] cremes some block, some drop messages, etc
[19:37] minrk as far as I can tell, pyzmq supports everything in libzmq-2.1.x, 3.0, and 4.0
[19:58] vkris Steve-o -Dammit that worked :)
[19:59] Steve-o :P
[20:00] Fade cremes: thanks
[20:00] cremes Fade: you're welcome? (what did i do?)
[20:00] Fade the problem was actually caused, because I was creating a context and passing it into the closure every time it was created, because I thought from the manual that contexts were supposed to be shared, but it turns out every thread needs its own.
[20:01] Fade the connection strings were fine. :)
[20:01] cremes hmm... you should only need a single context regardless of how many threads you have
[20:02] Fade that's what I thought when I read the docs, but it doesn't work
[20:02] Fade at least with the CL bindings.
[20:02] cremes well, it might be working now but it might just be masking a problem
[20:02] cremes i use a single context for dozens of threads in ruby which also uses closures all over the place
[20:03] cremes i can't imagine why the lisp bindings would be different
[20:03] vkris mm.. on running the Java code, I get " java.lang.UnsatisfiedLinkError: /usr/local/lib/libjzmq.0.dylib: no suitable image found. Did find: /usr/local/lib/libjzmq.0.dylib: mach-o, but wrong architecture /usr/local/lib/libjzmq.0.dylib: mach-o, but wrong architecture"
[20:04] Fade I'm thinking because lisp doesn't use green threads, they're system threads.
[20:04] Fade but I'm a relative noob, so I'm not entirely sure.
[20:04] cremes nope, real threads here too
[20:05] cremes you might try asking on the ML and providing a code snippet that demonstrates the error
[20:05] minrk vkris: try `file /usr/local/lib/libjzmq.0.dylib`
[20:07] Fade I'll make a note to follow up when I'm no longer under the gun.
[20:07] Fade my current problem is getting EINTR
[20:07] vkris minrk - /usr/local/lib/libjzmq.0.dylib: Mach-O dynamically linked shared library i386
[20:08] minrk vkris: and presumably your java is 64b, then
[20:08] vkris aaah, gotcha
[20:09] minrk vkris: you either have to build jzmq as 64b, or run Java in 32b mode
[20:14] vkris minrk - tried java -d32 options, doesn't look like i'l work
[20:15] vkris minrk - you are absolutely right, planning on building jzmq as 64b
[20:24] cremes vkris: you can't run java6 on osx in 32-bit mode... it will only run the 64-bit JVM
[20:25] vkris cremes - yup, lesson learnt
[20:26] vkris I am figuring out if there is a way to say my architecture is 64b to the configure file .. Any ideas ?
[20:27] cremes vkris: what does your 'uname -a' output?
[20:27] vkris Darwin vivekrisMac.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
[20:28] Steve-o just do a CC="g++ -m64" or similar?
[20:28] cremes use --build and/or --host
[20:29] Steve-o OSX is funky you can have 64-bit apps on 32-bit kernel and similar
[20:29] cremes e.g. --build x86_64-apple-darwin10.8.0 --host x86_64-apple-darwin10.8.0
[20:32] vkris cremes - no luck :(
[20:34] cremes vkris: can you boot your mac in 64-bit mode?
[20:40] vkris mm.. I am not sure if I can do with Leopard
[20:41] vkris cremes - looks like it does, will give a shot
[20:48] Steve-o I have 64-bit Leopard server, I think you should be able to do it on the regular version, although it was Snow Leopard that had everything rebuilt for 64-bit
[20:50] mikko minrk: i added you some permissions
[20:50] mikko minrk: let me know if it still fails
[20:50] minrk mikko: thanks!
[20:51] minrk for zeromq, select arch with: CFLAGS="-arch x86_64";CXXFLAGS="x86_64";./configure
[20:52] minrk * CFLAGS="-arch x86_64";CXXFLAGS="-arch x86_64";./configure
[20:52] mikko you shouldnt need CFLAGS unless you build openpgm
[20:52] minrk not sure if the same for jzmq
[20:52] minrk I don't know why configure doesn't respect ARCHFLAGS, but that's the normal way to do it on OSX
[20:53] mikko i think that just depends on how the autoconf stuff is built
[20:53] mikko usually you just use CFLAGS/LDFLAGS/CPPFLAGS/CXXFLAGS
[20:53] mikko but a lot of autoconf packagers tend to use CFLAGS even for C++
[20:53] mikko which semantically doesn't necessarily make sense
[20:54] minrk ARCHFLAGS is a standard env variable on OSX, for specifying the architecture
[20:54] minrk added by default to build flags under most circumstances
[21:01] minrk is there a reason that libzmq3 doesn't have any builds?
[21:02] minrk There's a 'zeromq3-0-test' that was only tried once, but no real builds.
[21:04] mikko i havent added them
[21:04] mikko the build cluster hardware is getting updated at end of sept
[21:04] mikko so haven't really done much before that
[21:04] minrk ok
[21:05] mikko it should be all 64bit soon
[21:05] mikko hopefully with 32/64bit windows as well
[21:05] mikko and it;'s probably a fair migration because all VMs need to be redone as 64bit
[21:05] mikko so i'm waiting for that to happen before working more on the builds
[21:05] minrk fair enough
[21:07] minrk I should probably roll my own at some point, so I can build against all the different Pythons I supposedly support.
[21:10] mikko as soon as the new hardware arrives i can add the pythons you need
[21:10] mikko or give you access to add them
[21:10] minrk that would be great
[21:12] minrk I don't want to flood your system with pyzmq builds, though - 4 libzmq versions * 4 Python versions is a lot
[21:13] mikko it should be fine if we distribute them throughout the day
[21:13] mikko the system is idle apart from morning and evening
[21:13] minrk ok
[21:13] mikko currently it's on fairly slow 32bit hardware which is a bit of a bummer
[21:14] mikko but that is hopefully fixed soon
[21:14] minrk I might also need to roll my own anyway, so that I can control for the presence/absence of nose and numpy
[21:16] minrk IPython will need its own build system soon, given its already large and growing set of optional dependencies
[21:17] mikko what is IPython?
[21:17] minrk interactive python shell
[21:17] minrk also has remote/parallel computing capabilities
[23:09] zedas another assert: rc != -1 (kqueue.cpp:76) this is on OSX lion and not with anything fancy, and it's random.
[23:10] minrk which libzmq?