| [Time] Name | Message |
|
[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://127.0.0.1:6000. 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://127.0.0.1:5555" 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 ? http://pastie.org/2580386
|
|
[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?
|
