[Time] Name | Message |
[00:28] mike8901
|
Is it possible to do a read and a write simultaneously to a socket without breaking anything?
|
[00:31] mike8901
|
I am doing nonblocking reads, if that makes any difference.
|
[02:00] CIA-15
|
pyzmq: 03Brian E. Granger 07master * rb0352c8 10/ (zmq/_zmq.c zmq/_zmq.pyx):
|
[02:00] CIA-15
|
pyzmq: Fixing ctypedef of int64_t.
|
[02:00] CIA-15
|
pyzmq: Thanks to Lisandro Dalcin for the tip. - http://bit.ly/9ReFJF
|
[02:03] CIA-15
|
pyzmq: 03Fernando Perez 07master * r811389d 10/ (examples/pubsub/topics_pub.py examples/pubsub/topics_sub.py): New example for publish/subscribe sockets with multiple topics. - http://bit.ly/9nMYsJ
|
[02:12] rmancy
|
Hi, does anyone know of a c++ example using ZMQ_REP ?
|
[02:13] rmancy
|
I was able to get the ZMQ_REP/ZMQ_REQ example using C/C++ fine, but looking for a C++ example using ZMQ_REP so I can find out what I'm doing wrong
|
[02:31] mike8901
|
What's the best way to have a vector of zmq::socket_t's? Just have pointers to the vectors?
|
[02:31] mike8901
|
**pointers to the sockets
|
[02:31] mike8901
|
(or smart pointers)
|
[03:47] CIA-15
|
pyzmq: 03Brian E. Granger 07master * r792a621 10/ (zmq/_zmq.c zmq/_zmq.pyx): Added support for getsockopt and multipart messages. - http://bit.ly/cgZOqv
|
[05:42] sustrik
|
re
|
[05:43] sustrik
|
mike8901: simultaneous read & write? each socket can be used only from a single thread
|
[05:43] mike8901
|
okay
|
[05:53] sustrik
|
mike8901: as for storing zmq::socket_t's in vector
|
[05:53] sustrik
|
they actually _are_ smart pointers
|
[05:53] sustrik
|
they cannot be stored in a vector because they are not assignable
|
[05:54] sustrik
|
i.e. they have no copy constructor and assignment operator
|
[05:54] mike8901
|
yes, I figured that out
|
[05:54] sustrik
|
if you add those two, i'll accept the patch to c++ binding
|
[05:55] mike8901
|
from my understanding, smart pointers aren't _SUPPOSED_ to be stored in a vector
|
[05:55] sustrik
|
what you can do is add reference count
|
[05:55] sustrik
|
so when socket_t is copied reference count increases by 1
|
[05:55] mike8901
|
that's not my main concern
|
[05:56] mike8901
|
I ended up just storing pointers to zmq::socket_t's in the vector
|
[05:56] sustrik
|
yes, can be done that way as well
|
[05:56] sustrik
|
although you have to delete them manually afterwards
|
[05:57] mike8901
|
yes, of course
|
[05:57] mike8901
|
C++ would be so much nicer if it had -retain and -release like Obj-C
|
[05:57] sustrik
|
that's what refcounting can do
|
[05:57] mike8901
|
yeah, it would be nice if refcounting was builtin
|
[05:58] mike8901
|
btw, are there any plans to make zeromq BSD/MIT licensed?
|
[05:58] sustrik
|
well, it can at least be done for socket_t
|
[05:59] sustrik
|
in theory, once it's established enough to make sure that contributions are flowing back to the project automatically
|
[05:59] sustrik
|
at the present the fear is that people would patch it and don't contribute back
|
[06:00] sustrik
|
why do you need that?
|
[06:00] mike8901
|
I'm currently using zeromq for a project with clang(basically implementing distcc at a layer tightly coupled with the compiler)
|
[06:00] mike8901
|
I'm using zeromq because it's easy to use and I'm running up against a tight deadline
|
[06:00] mike8901
|
(plus it's fast)
|
[06:00] mike8901
|
but clang won't accept my patch if it uses an LGPL library
|
[06:00] mike8901
|
everything has to be BSD licensed
|
[06:01] sustrik
|
static linking?
|
[06:01] mike8901
|
I think they won't even allow dynamic linking
|
[06:01] mike8901
|
(I'm dynamically linking now)
|
[06:01] mike8901
|
basically, their policy is BSD only
|
[06:01] sustrik
|
there's a clause explicitly allowing for static linking in 0mq license text
|
[06:02] sustrik
|
anyway, if it's their policy, there's little to do at the moment
|
[06:02] sustrik
|
you'll have to keep the patch out of the tree
|
[06:02] mike8901
|
ok, I guess I'll stick with zmq now, and hopefully by the time to patch back to mainline comes, zmq will be licensed for the process :)
|
[06:02] mike8901
|
*licensed using BSD
|
[06:03] sustrik
|
hm, btw, what good is messaging layer in a compiler?
|
[06:05] rmancy
|
I'm sure this is a silly Q. Can I make zmq libs from the git repo? I checked it out the other day, but didn't have much luck.
|
[06:06] sustrik
|
rmancy_: what went wrong?
|
[06:06] rmancy
|
sustrik, first off I'm not too ofey with C Makefiles. It's Been a while. Well there didn't seem to be a configure script, so I just did autoconfigure. Is this right ?
|
[06:07] sustrik
|
yes
|
[06:07] sustrik
|
the script is generated so it's not stored in git
|
[06:07] sustrik
|
./autogen.sh
|
[06:07] sustrik
|
./configure
|
[06:07] sustrik
|
make
|
[06:08] rmancy
|
sustrik, excellent. Thanks so much.
|
[06:08] sustrik
|
np
|
[06:31] rmancy
|
sustrik, I've been having a problem with a very simple ZMQ_REP/ZMQ_REQ app. Can you recommend a good ZMQ_REP example in c++ (I just converted the Server example from the 0mq site that was in C) ?
|
[06:32] sustrik
|
what was the problem?
|
[06:33] rmancy
|
Well, the ZMQ_REP (server) gets the recv() and then _appears_ to send(), but the ZMQ_REQ (client) does not get the response. the client code works fine with the example written in C.
|
[06:34] sustrik
|
send the test program to the mailing list
|
[06:37] rmancy
|
sustrik, ok cheers. I'm sure it's an obvious problem to most other people. I'm brand new to C++ and it's been over 4 years since I've even done C.
|
[07:02] mike8901
|
sustrik: I'm building a distributed compiler
|
[07:02] mike8901
|
similar to distcc, but much more efficient
|
[07:10] sustrik
|
aha, interesting
|
[07:10] sustrik
|
the point is make it compile faster?
|
[07:12] sustrik
|
by running compilation of several machines at the same time?
|
[13:46] b0gg1e
|
Hi
|
[13:47] b0gg1e
|
I pushed some very early bindings for zeromq to go on github http://github.com/boggle/gozero
|
[13:49] b0gg1e
|
Currently barely works there seems to happen some weirdness between go's scheduler and zmq which I havent managed to understand yet, anyways feel free to peek or help
|
[13:52] sustrik
|
b0ggle: great, thanks
|
[13:53] sustrik
|
do you want to be referenced from zeromq.org website?
|
[13:59] b0gg1e
|
its not actually usable right now, so that doesnt seem apropriate
|
[14:00] sustrik
|
well, at least people would know about it
|
[14:00] b0gg1e
|
more looking for help actually and am a bit lost whom to ask.. go people or zeromq people :-)
|
[14:00] sustrik
|
you can place a big "EXPERIMENTAL" tag on the top of the page
|
[14:01] b0gg1e
|
more like (BROKEN, NEEDS HELP)
|
[14:01] sustrik
|
yes, sure
|
[14:01] b0gg1e
|
ill do that on github
|
[14:01] sustrik
|
as you wish
|
[14:01] b0gg1e
|
maybe put a Go (EXPERIMENTAL) on the page if you like to
|
[14:02] sustrik
|
sure
|
[14:02] sustrik
|
do you want a wiki page on zeromq.org?
|
[14:02] sustrik
|
or should i link to your page somewhere?
|
[14:04] b0gg1e
|
A wiki page on zeromq.org would be nice
|
[14:04] sustrik
|
ok, do this: open www.zeromq.org and create an account (top right of the page)
|
[14:05] sustrik
|
let me know your login then and i'll give you write access
|
[14:09] b0gg1e
|
recovering wikidot account...
|
[14:29] b0gg1e
|
account name is "splant"
|
[14:31] sustrik
|
ok, you are invited
|
[14:31] sustrik
|
i've created http://www.zeromq.org/bindings:go
|
[14:31] sustrik
|
put the python binding wiki page content there to give you some template
|
[14:31] sustrik
|
feel free to edit it as you see fit
|
[14:32] sustrik
|
b0ggle: let me know when it's ready to be linked from the front page
|
[14:38] b0gg1e
|
k thanks might take a while... the go folks are changing their gc and i might sit this out unless i have a good fast idea on how to fix things
|
[14:39] sustrik
|
b0ggle: sure, it's up to you
|
[14:41] b0gg1e
|
i cant edit the page / dont see an edit link
|
[15:22] sustrik
|
b0ggle: have you accepted the invitation?
|
[15:25] sustrik
|
it doesn't look so, i don't see you among members
|
[15:29] b0gg1e
|
ah
|
[15:29] b0gg1e
|
:-)
|
[15:29] b0gg1e
|
can edit now, thanks
|
[15:32] sustrik
|
:)
|
[15:59] b0gg1e
|
contexts are bound to the thread in which they are created. is it possible to relax that to "contexts should only ever be used from a single thread at atime"?
|
[15:59] b0gg1e
|
systems like erlang/go etc schedule lightweight processes on thread pools meaning the executing thread can change underneath you stackframe
|
[16:06] sustrik
|
b0ggle: no, context are thread-safe and can be used from any thread
|
[16:06] sustrik
|
the restricvtion you are speaking about applies to sockets
|
[16:07] sustrik
|
and if you meant sockets, then no, it cannot be relaxed
|
[16:07] b0gg1e
|
ah i ment sockets sure
|
[16:08] b0gg1e
|
hm guess that has to do with the lock-free algos. too bad, now i have to find out why go's LockOSThread isnt working ;-(
|
[16:08] b0gg1e
|
or what else is blocking.
|
[16:09] sustrik
|
yes, it's about lock-free queues
|
[16:12] b0gg1e
|
that also means one cannot move contexts between threads which might also be nice for loadbalancing purposes
|
[17:05] mike8901
|
sustrik: Yup, the idea is to preproc on the master, do everything through object code generation on slave, and link together on master.
|
[17:07] mike8901
|
(in a much more efficient manner than distcc)
|
[18:00] CIA-15
|
pyzmq: 03Brian E. Granger 07master * r1ffcf0e 10/ (zmq/_zmq.c zmq/_zmq.pyx): Removing SUBSCRIBE/UNSUBSCRIBE from the options in getsockopt. - http://bit.ly/cmNMa4
|
[19:28] sustrik
|
mike8901: aha, looks like good match for 0mq; pitty there's the licensing problem
|
[20:26] CIA-15
|
pyzmq: 03Brian E. Granger 07master * r7a9d487 10/ (zmq/_zmq.c zmq/_zmq.pyx zmq/zmq_compat.h):
|
[20:26] CIA-15
|
pyzmq: Created zmq_compat.h for a compatibility header file.
|
[20:26] CIA-15
|
pyzmq: This will hopefully fix the int64_t issue. - http://bit.ly/91UClL
|
[20:43] mike8901
|
sustrik: yeah, zmq has worked out pretty nicely so far... you're welcome to follow along at http://github.com/jhoush/dist-clang
|
[20:43] mike8901
|
comments on (mis-)use of zeromq are greatly appriciated... there are probably some ways to use it better
|
[20:44] mike8901
|
right now, we're just doing basic point-to-point communication between nodes
|
[20:45] mike8901
|
it might be better to do a multicast setup so work-stealing can be done without rebroadcasting the data(i.e. slaves maintain a cache of files sent out to other slaves so they can steal work from another slave without asking for the data to be sent out again)
|
[20:46] mike8901
|
It's a shame we have a deadline in 2.5 weeks, so we're basocally racing to finish this, and can't do too many interesting optimizations
|
[20:46] mike8901
|
*basically
|
[20:51] CIA-15
|
pyzmq: 03Brian E. Granger 07master * r6ff6da2 10/ README.rst : Edits to the README.rst. - http://bit.ly/dmPyGi
|
[21:27] mike8901
|
sustrik: I ran into an issue where error_t was being defined by one(I don't know which) of the headers included... I had to #undef error_t to use zmq.hpp.
|
[21:27] mike8901
|
Is that a known issue?
|
[21:42] bgranger
|
sustrik: I am trying out the XREP/XREQ support that you added yesterday
|