Sunday June 5, 2011

[Time] NameMessage
[01:31] yrashk ah damn missed ianbarber again
[01:33] mikko he is on london time
[01:33] yrashk yea
[01:33] yrashk I'll be in London on Monday
[01:35] mikko i'll be in london on monday as well
[01:35] mikko well, most of the days really
[01:35] yrashk cool
[01:36] yrashk I am there primarily for the Erlang Factory
[01:37] yrashk Ian will be speaking there, afair
[01:39] mikko yeah, i think he will be there
[01:45] yrashk well that's for sure
[01:45] yrashk
[09:49] benoitc yrashk btw why are you using zeromq in erlv8 ?
[10:03] yrashk benoitc: to enable inter-thread communication
[10:03] yrashk I can tell you more in London
[10:05] benoitc ok cool
[10:21] ianbarber yrashk: quick q, is there any way of detecting multipart on active sockets in erlzmq2? can't see anything, but may be being slow
[13:41] pieter_hintjens re
[15:33] yrashk ianbarber: don't remember actualy :-( haven't touched erlzmq2 in a while
[15:34] yrashk ianbarber: can you open an issue about this at its repo?
[16:56] ianbarber yrashk: will do
[19:30] CIA-31 rbzmq: 03Brian Buchanan 07v2.1.3 * rb90b844 10/ (rbzmq.c zmq.gemspec): zmq gem v2.1.3 - Add support for ZMQ_RECOVERY_IVL_MSEC, ZMQ_RECONNECT_IVL_MAX, ZMQ_ROUTER, ZMQ_DEALER -
[19:30] CIA-31 rbzmq: 03Brian Buchanan 07master * rb90b844 10/ (rbzmq.c zmq.gemspec): zmq gem v2.1.3 - Add support for ZMQ_RECOVERY_IVL_MSEC, ZMQ_RECONNECT_IVL_MAX, ZMQ_ROUTER, ZMQ_DEALER -
[22:02] JohnNilsson Sorry if this is an RTFM question. But is it normal for zmq_term() to cause a segfault due to stack overflow? (I'm using 2.1.7)
[22:03] cremes JohnNilsson: no, not normal
[22:04] cremes why would you think the normal termination for a library should be a segfault? :)
[22:04] JohnNilsson Ok then. So then its my fault ;-) good to know. I have a trival example that triggers the error so I guessed it was a known issue with a trival workaround.
[22:06] JohnNilsson
[22:07] JohnNilsson Running this through valgrind gives me: Bad permissions for mapped region at address 0x6DC3FF8 at 0x4E48029: zmq::rep_t::xrecv(zmq_msg_t*, int) (rep.cpp:78)
[22:09] JohnNilsson oh, ignore that, it was a bad build. That is the error from my actual code...
[22:15] JohnNilsson Ok, never mind. While rearranging the code to reproduce the error with an example I found it. It was probably caused by my lack of skills in c programming. I had declared a function "void recv()", removing that declaration removed the problem.
[22:17] JohnNilsson Anyone with a little bit more C knowledge care to enlighten me how that could trigger the error?
[22:19] cremes JohnNilsson: there are no namespaces in the C language, so your method #recv() probably
[22:20] cremes overwrote another C function somewhere else with the exact same name
[22:22] JohnNilsson Ah, I guess I shod learn C then. ;-) I thought that declarations where local to the compilation unit and could not cause already compiled code to break. But I guess this happens because even if libzmq is already compiled I do put through gcc for linking, is that what happens?
[22:24] cremes perhaps, i don't know all the gory details
[22:24] cremes if the linker is trying to link up multiple functions all with the same name #recv(), then
[22:24] cremes it will probably get confused
[22:24] cremes maybe the compilation + link shouldn't even work at all...
[22:26] JohnNilsson Hmm, gcc might have some warning for that, I'll check the manual. Thanks for the help. (btw. If anyone care to experiment, I've updated the gist, this version causes an assertion error instead)
[22:59] Seta00 JohnNilsson, it's not overwriting in ZMQ, it's in the standard POSIX sockets library :P
[22:59] Seta00
[23:01] JohnNilsson ah, so when I link zmq to the program zmq gets linked to my definition instead of the posix one. But I should be able to avoid this by telling gcc not to do that, no?
[23:04] Seta00 JohnNilsson, you cannot have two global symbols with the same name
[23:04] Seta00 use my_recv or anything else
[23:05] Seta00 C++'s linking system is basically glueing stuff together :P
[23:08] JohnNilsson I guess I could also nest my functions inside main to avoid the issue. It just irks me that it's so easy to silently override library behaviour.
[23:15] JohnNilsson Or... I could declare all my helper functions static. (I really need to learn more about C... )
[23:27] Seta00 JohnNilsson, :)
[23:27] Seta00 JohnNilsson, also, nested functions are non-standard
[23:31] JohnNilsson I'm not that worried about non-standardness though. The whole reason I'm writing this in C instead of Java (or Scala) is to have the full access to kernel API:s, so this program won't be very portable in any case.
[23:35] JohnNilsson When done I'm hoping to have a "device" similar in scope to kafka ( )