[Time] Name | Message |
[02:28] lestrrat
|
I assume jenkins is complaining about the perl binding because of the upcoming 3.0 changes
|
[02:28] lestrrat
|
can the tests run against the 2.1.x tree for now?
|
[02:31] mikko
|
lestrrat: yeah
|
[02:31] mikko
|
been doing a lot of changes lately
|
[02:35] mikko
|
building now
|
[08:29] mikko--
|
sustrik
|
[08:29] mikko--
|
pieterh
|
[08:29] pieter_hintjens1
|
hi mikko
|
[08:31] mikko--
|
pieterh: rpm packaging is broken
|
[08:31] mikko--
|
device manual pages
|
[08:31] mikko--
|
http://build.zero.mq/view/RPM%20packaging/
|
[08:31] mikko--
|
all branches
|
[08:31] pieter_hintjens1
|
let me take a look
|
[08:31] mikko--
|
i was up until 4 AM adding / fixing builds
|
[08:31] mikko--
|
almost everything there
|
[08:31] mikko--
|
still needs libzfl
|
[08:32] pieter_hintjens1
|
i saw it... a lot of work!
|
[08:36] pieter_hintjens1
|
OK, found the error for zmq_device, should build now
|
[08:38] pieter_hintjens1
|
for master, it's zmq_cpp, I assume that's been removed from the tree but not the zeromq.spec file
|
[08:40] mikko--
|
it's the device manual page
|
[08:40] mikko--
|
that causes the packaging error for 2-2 and 2-1
|
[08:40] pieter_hintjens1
|
I've fixed that, mikko
|
[08:40] mikko--
|
cool
|
[08:41] pieter_hintjens1
|
there's still a problem with master, due to a reference to the zmq_cpp man page
|
[08:41] pieter_hintjens1
|
I think at some point we should consider generating these files automatically
|
[08:42] pieter_hintjens1
|
the current approach breaks every time anything is added or removed
|
[08:42] sustrik
|
fixing it
|
[08:42] sustrik
|
a second
|
[08:42] sustrik
|
btw: source line is wrong
|
[08:43] sustrik
|
Source: http://www.zeromq.org/local--files/area:download/%{name}-%{version}.tar.gz
|
[08:43] pieter_hintjens1
|
hmm, indeed
|
[08:43] mikko--
|
sustrik: https://build.zero.mq/view/libzmq/job/libzmq_GCC-debian/440/cppcheckResult/source.20/?
|
[08:43] mikko--
|
see the highlighted line
|
[08:44] sustrik
|
mikko: "The page isn't redirecting properly"
|
[08:44] mikko--
|
oh, indeed
|
[08:45] mikko--
|
hmm, i wonder what happened to permissions there
|
[08:45] mikko--
|
sec
|
[08:45] mikko--
|
brbr
|
[08:46] sustrik
|
this should be probably changed as well:
|
[08:46] sustrik
|
Name: zeromq
|
[08:46] sustrik
|
should be libzmq
|
[08:46] sustrik
|
otherwise the "source" line won't expand properly
|
[08:47] pieter_hintjens1
|
sustrik__: the source line isn't going to be accurate anyhow
|
[08:48] sustrik
|
2 issues
|
[08:48] sustrik
|
the name
|
[08:48] sustrik
|
the path
|
[08:48] sustrik
|
should i try to fix it?
|
[08:48] sustrik
|
i have no idea how rpm packaging works :|
|
[08:48] pieter_hintjens1
|
presumably it's a comment rather than functional
|
[08:48] pieter_hintjens1
|
because it's been wrong for some time
|
[08:49] pieter_hintjens1
|
I'd suggest leaving the package name as zeromq, and fixing the URI to download.zeromq.org
|
[08:49] pieter_hintjens1
|
that is at least accurate
|
[08:50] pieter_hintjens1
|
http://download.zeromq.org/%{name}-%{version}.tar.gz
|
[08:56] mikko--
|
sustrik:
|
[08:56] mikko--
|
http://build.zero.mq/view/libzmq/job/libzmq_GCC-debian/440/cppcheckResult/source.20/?
|
[08:57] mikko--
|
should load now
|
[09:17] mikko_k
|
sustrik: did you get it?
|
[09:34] sustrik
|
mikko_k: yes
|
[09:34] sustrik
|
what problem does it report?
|
[09:35] sustrik
|
unnecessary cast?
|
[09:36] mikko_k
|
unused variable
|
[09:36] sustrik
|
ok, let me fix it
|
[09:37] sustrik
|
what about the rpm stuff?
|
[09:37] sustrik
|
do you have any idea how it works?
|
[09:37] mikko_k
|
yeah
|
[09:37] sustrik
|
%{name} -- what does it resolves to?
|
[09:38] mikko_k
|
Name:
|
[09:38] sustrik
|
aha
|
[09:38] sustrik
|
thus we have to change Name: to libzmq
|
[09:39] sustrik
|
or hard-wite libzmq into the source path
|
[09:39] mikko_k
|
you don't have to use %{name}
|
[09:39] mikko_k
|
it just seems to be a common convention
|
[09:40] sustrik
|
what is the name used for?
|
[09:40] mikko_k
|
usually you see %{name}-%{version}.tar.gz
|
[09:40] sustrik
|
tracking identity of tha package?
|
[09:40] sustrik
|
if so, we have to keep zeromq as name
|
[09:40] mikko_k
|
sustrik__: i guess it's just a convention
|
[09:40] mikko_k
|
you can hardcode it as well
|
[09:41] pieter_hintjens1
|
like I said, the package name will have to remain zeromq
|
[09:41] sustrik
|
i mean, if the guys at RH/CentOS are using name
|
[09:41] sustrik
|
to say "this is the same package, just a newer version"
|
[09:41] mikko_k
|
yeah
|
[09:41] mikko_k
|
makes sense
|
[09:41] pieter_hintjens1
|
unless we make separate distributions for the core library and the package
|
[09:41] sustrik
|
ok, let me hardwire the path then
|
[09:48] sustrik
|
hm, are we going to keep the name of the dist "zeromq"
|
[09:48] sustrik
|
or are we going to change it to libzmq?
|
[09:49] pieter_hintjens1
|
sustrik__: for the third time... :-) we have to keep the name of the dist as "zeromq"
|
[09:49] pieter_hintjens1
|
unless we also (which we can do) create a package specifically and only for libzmq
|
[09:49] sustrik
|
the dist is only libzmq
|
[09:49] sustrik
|
i mean
|
[09:49] sustrik
|
what you get when you type "make dist"
|
[09:50] pieter_hintjens1
|
then you can use package = libzmq in master, for sure
|
[09:50] pieter_hintjens1
|
in the dist branches it's zeromq
|
[09:50] sustrik
|
ok
|
[09:50] pieter_hintjens1
|
however unless you're uploading those .tag.gz files somewhere, they're not on any download URI
|
[09:50] Guthur
|
still naming discussions I see, hehe
|
[09:51] pieter_hintjens1
|
Guthur: well, the naming is just settling into place afaics
|
[09:51] Guthur
|
cool, I've been out of the loop somewhat, being in Hamburg
|
[09:51] pieter_hintjens1
|
sustrik__: in any case if we start including other projects into the zeromq dist the redhat packaging will change
|
[09:51] sustrik
|
BuildRequires: glib2-devel
|
[09:52] sustrik
|
the rpm file looks completely out-of-date
|
[09:52] pieter_hintjens1
|
Guthur: I've heard that Internet is coming to Hamburg in 2015...
|
[09:52] Guthur
|
pieter_hintjens1: yeah the sooner the better, getting a wifi connection was more challenging than I expected
|
[09:53] sustrik
|
why so?
|
[09:53] sustrik
|
with packaging for distros you want to have individual project be different packages
|
[09:53] Guthur
|
well there was one at the conference but the only other one I really got was at a starbucks
|
[09:53] sustrik
|
so that it works ok with package managers
|
[09:53] pieterh
|
sustrik__: you're probably right
|
[09:54] pieterh
|
but I'm not sure we *don't* want a ZeroMQ distro that includes everything sane
|
[09:55] sustrik
|
definitely on win32
|
[09:55] sustrik
|
no idea about deifferent UX-es
|
[09:55] pieterh
|
well, openpgm is a good example
|
[09:55] pieterh
|
do you want to have to go build it separately?
|
[09:56] sustrik
|
the distros are pretty clear about not wanting bundled libs
|
[09:56] pieterh
|
yes, but that's not really our problem here
|
[09:56] pieterh
|
this is not about libzmq in a distro
|
[09:56] sustrik
|
that's why mikko did the separate compile work last week
|
[09:56] sustrik
|
rpm?
|
[09:57] pieterh
|
it's about making our own packages (this RPM stuff is not RHEL)
|
[09:57] sustrik
|
well, the script is in directory called "redhat" :)
|
[09:57] pieterh
|
it's about making RPMs that can be used to install 0MQ on boxes
|
[09:57] mikko_k
|
i can provide unofficial yum repository later
|
[09:57] mikko_k
|
now that there is 64bit build capacity
|
[09:58] sustrik
|
mikko: what do you thing of the glib dep in the rpm?
|
[09:58] pieterh
|
sustrik__: it's clearly out of date but should we be maintaining the rpm spec?
|
[09:58] pieterh
|
there's an author
|
[09:58] sustrik
|
mikko?
|
[10:03] sustrik
|
mikko_k: are you there?
|
[10:03] sustrik
|
what do you thing of the glib dep in the rpm?
|
[10:04] pieterh
|
sustrik__: that's a hangover from OpenPGM, isn't it?
|
[10:04] sustrik
|
looks like
|
[10:04] pieterh
|
do we really want to be maintaining this file though?
|
[10:04] sustrik
|
where else should it go?
|
[10:05] pieterh
|
my question is whether we (you, me, Mikko) should be editing and fixing this spec file
|
[10:05] pieterh
|
there's an author who wrote it, and people who use it (probably the same person)
|
[10:05] sustrik
|
mikko is listed as an author
|
[10:06] pieterh
|
ok, git blame confirms it
|
[10:06] mikko_k
|
i can edit it
|
[10:06] mikko_k
|
when i get home
|
[10:07] sustrik
|
it's up to you
|
[10:07] sustrik
|
you are the build system maintainer
|
[10:07] sustrik
|
if you want it there, there is stays
|
[10:07] sustrik
|
if you want to remove it, do so
|
[10:08] mikko_k
|
glib dependency should go afaik
|
[10:08] sustrik
|
do you want me to fix it?
|
[10:09] sustrik
|
or would you check it yourself later on?
|
[10:09] mikko_k
|
two things at least:
|
[10:09] mikko_k
|
well, i can do it tonight
|
[10:09] mikko_k
|
i'll add option to use system openpgm to spec files
|
[10:10] mikko_k
|
so that in future RHEL/etc can easily package the two separately
|
[10:10] mikko_k
|
possibly package openpgm 5.1.115 as RPM as well
|
[10:10] mikko_k
|
and provide a yum repository for these
|
[10:10] sustrik
|
ok
|
[10:10] sustrik
|
if you want a help just ask
|
[10:11] mikko_k
|
do we have zeromq GPG key?
|
[10:11] mikko_k
|
that i can use to sign the packages
|
[10:11] mikko_k
|
or should i create one?
|
[10:12] sustrik
|
hm, mato would be right person to answer that
|
[10:12] sustrik
|
he's out of town today though
|
[10:35] mikko_k
|
sustrik: https://build.zero.mq/view/libzmq/job/libzmq_mingw32-debian/281/console
|
[10:36] pieterh
|
mikko_k: as far as I know we don't have a ZeroMQ GPG key
|
[10:36] pieterh
|
and you should create one IMO
|
[10:41] sustrik
|
mato is doing debian packaging
|
[10:41] sustrik
|
he may have one
|
[10:43] pieterh
|
I'd assume if he did anything in the name of the 0MQ community he'd share it
|
[10:44] sustrik
|
isn't the key confidential?
|
[10:44] pieterh
|
its existence shouldn't be
|
[10:44] pieterh
|
given that you and myself are the benevolent dictators here, we should have all the keys
|
[10:45] pieterh
|
that is how we have worked since the start, it's a good principle
|
[10:46] pieterh
|
I assume mato would by default work like that, and since he's not shared any keys, I assume they don't exist
|
[10:46] sustrik
|
if it's used for signing official debian distro, it does exist
|
[10:46] sustrik
|
wait till tomorrow
|
[10:47] pieterh
|
of course
|
[10:47] mikko_k
|
sustrik: did you see the new error ?
|
[10:48] sustrik
|
yes, fixing it
|
[10:48] sustrik
|
wait a sec
|
[10:51] mikko_k
|
cool, thanks
|
[10:51] sustrik
|
mikko_k: ok, done
|
[11:03] ianbarber
|
sustrik__: mato was saying that he didn't actually adding the debian packages directly as he wasn't a debian dev, so the packages may be signed by the repo
|
[11:04] sustrik
|
aha
|
[11:04] sustrik
|
then we presumably have no key
|
[11:04] sustrik
|
mikko: feel free to generate one
|
[11:05] pieterh
|
sustrik__: you sure you don't want to wait a day and ask Mato?
|
[11:05] sustrik
|
well, if he's not signing the packages
|
[11:06] mikko_k
|
sustrik: http://build.zero.mq/view/libzmq/job/libzmq_mingw32-debian/283/consoleText
|
[11:06] mikko_k
|
lunch!
|
[11:06] sustrik
|
anyway, no haste, we can discuss the key matter tomorrow
|
[11:06] sustrik
|
mikko_k: thx, giving it a look
|
[11:10] ianbarber
|
sustrik__: thanks for the reply to my router idea by the way, good point about the two distinctions. I hadn't thought about the stateful service situation much, but it is a different and tricky problem.
|
[11:13] sustrik
|
ianbarber: yes, that's why Erlang doesn't allow for any local state
|
[11:13] sustrik
|
no state => scalability & transpatrent failover
|
[11:13] sustrik
|
state => ?
|
[11:13] ianbarber
|
yeah
|
[11:21] sustrik
|
mikko: fixed
|
[11:45] mikko_k
|
pieterh: http://build.zero.mq/job/libzapi-master_libzmq_mingw32-debian/2/consoleText
|
[13:47] pieterh
|
mikko_k: fixed, should build on Win32 now but I've not had time to try that yet
|
[13:49] pieterh
|
sustrik__: did you say you could, or could not, make it to Brussels for the 10th?
|
[14:23] saurabhd
|
hi...i have problem related to zmq_device..
|
[14:23] saurabhd
|
anyone can help out?
|
[14:53] boothead
|
hi guys, i would like to close a socket with one unsent message in the buffer and then open another socket to the same endpoint as the first - would ZMQ_LINGER let me chuck the unsent messages?
|
[14:55] sustrik
|
boothead: set linger to zero
|
[14:55] sustrik
|
pieterh: no, i won't be able to come
|
[14:56] boothead
|
sustrik__, thanks, I will try that.
|
[14:59] boothead
|
does it matter if i set linger before or after connecting (like identity?)
|
[14:59] sustrik
|
it does not matter
|
[15:02] boothead
|
thanks sustrik__ works perfectly :-)
|
[16:00] pieterh
|
sustrik__: I'm going to cancel it then, not much point
|
[16:12] ianbarber
|
sustrik__: is your moscow talk going to a) be videoed b) in english?
|
[16:25] pieterh
|
sustrik__: I can look for another date in May, it was already mostly full
|
[16:31] ianbarber
|
i am still waiting to find out whether i am OK for that date from work, end of the financial year = bottom of the priority pile i suspect :)
|
[17:58] eyeris
|
If I create a push/pull pair with an explicit identity on each side, does the durability (which I assume is journaled) allow the two sides to operate in a disconnected state? (total noob here, just reading the guide)
|
[17:58] michaelgreene
|
I'm in the process of converting a system I'm using from 2.0.11 to 2.1.4 and have a few hundred automated tests that run a pyzmq test harness against my system that is implemented using the low-level C API. All the tests seem to pass still, but I see "Invalid argument (mutex.hpp:98)" printed while tearing down each test. Any ideas what this is actually telling me? It looks like that line is just a lock acquire.
|
[17:59] pieterh
|
eyeris: nope
|
[17:59] pieterh
|
the durability is not reliable, it just creates a kind of persistent network buffer
|
[18:00] pieterh
|
michaelgreene_: sounds like code is using a closed socket or somesuch
|
[18:00] eyeris
|
pieterh: OK, thanks.
|
[18:00] pieterh
|
eyeris: if you want disconnected clients / workers, check out the Majordomo pattern in Ch4
|
[18:00] pieterh
|
hmm, sorry, the Titanic pattern :-)
|
[18:11] Guthur
|
what would be the major wins for zeromq if it reaches the kernel, low latency?
|
[18:12] pieterh
|
Guthur: accessibility to any application that uses normal sockets, in theory
|
[18:15] Guthur
|
pieterh, is that what you see as the biggest win?
|
[18:16] Guthur
|
which reminds me, one of the common questions I got asked at the ELS, was 'why should I use zeromq sockets over plain TCP'
|
[18:19] pieterh
|
Guthur: you'd have to ask sustrik, kernelification is his vision
|
[18:20] pieterh
|
why use zeromq sockets over plain TCP... turns 2,000 lines of code into 20, that's all
|
[18:21] pieterh
|
it's pretty exhaustively explained in the Guide, all the difficulties you have to solve if you use TCP sockets
|
[18:22] Guthur
|
yeah, it was an easy one to answer to be fair
|
[18:34] sustrik
|
pieterh: it's more about money, i extremely short of it atm, so i am not sure i can actually afford going to bxl now
|
[18:35] sustrik
|
i you are willing to reschedule though
|
[18:35] sustrik
|
it would be nice to move it to later on
|
[18:35] sustrik
|
prepare a real program
|
[18:35] pieterh
|
unconfs don't really have programs, that's the point
|
[18:35] sustrik
|
why would anyone come then?
|
[18:36] pieterh
|
to meet other people
|
[18:36] pieterh
|
iot
|
[18:36] pieterh
|
it's basically an extended meetup
|
[18:36] sustrik
|
then pair it with some other conference or something
|
[18:37] pieterh
|
why? you don't think it's worth meeting people just for 0MQ?
|
[18:37] sustrik
|
it's unlikely that many people will travel to bxl just to have a beer
|
[18:37] pieterh
|
sigh
|
[18:37] sustrik
|
it's expensive
|
[18:37] pieterh
|
well, I'm happy to travel to London just to meet 0MQ folk
|
[18:37] sustrik
|
that's you
|
[18:37] sustrik
|
and london is quite close to bxl
|
[18:38] sustrik
|
ianbarber: no idea about video
|
[18:38] sustrik
|
i'll speak in english
|
[18:39] sustrik
|
not much help if it's not recorded though :)
|
[18:39] ianbarber
|
cool :) well, if you have slides they would be great to see
|
[18:39] ianbarber
|
on slideshare or something
|
[18:39] sustrik
|
definitely
|
[18:39] ianbarber
|
sustrik__: unconfs are quite fun, people do go to them as well - the idea is that people talk, but the schedule isn't decided up front
|
[18:40] pieterh
|
look, Brussels is central, easy to get to
|
[18:41] pieterh
|
but I'm not really stressed to make a conference now
|
[18:41] sustrik
|
sure, if there's an interest why not
|
[18:41] pieterh
|
it'd be good for 0MQ, good to spread the word
|
[18:41] Guthur
|
+1 on unconf being pretty good
|
[18:42] Guthur
|
I'm been to one before, local mind you, and I thought it was very successful
|
[18:42] ianbarber
|
i wonder if it would be an idea to have a brusels 0MQ meetup this month? just to gauge the local scene as well
|
[18:43] sustrik
|
that's what pieter is organising
|
[18:43] Guthur
|
you made cannibalism the unconf a bit, considering it's so close
|
[18:43] Guthur
|
cannibalize*
|
[18:44] sustrik
|
ah
|
[18:45] pieterh
|
it's not sensible to try to make a conventional conference, we'd not get speakers
|
[18:45] pieterh
|
nor is it sensible to try to mix with another conference, not in Brussels
|
[18:45] pieterh
|
unless you are passionate about EU farming subsidy discussions
|
[18:45] pieterh
|
sure, why not
|
[18:45] pieterh
|
I've always enjoyed the unconf model
|
[18:45] pieterh
|
they are extraordinarily hard work and expensive, since speakers expect to have their costs paid
|
[18:47] Guthur
|
i thought that's why conferences usually charge
|
[18:47] ianbarber
|
and sponsored
|
[18:47] pieterh
|
indeed
|
[18:47] pieterh
|
which is a lot of work
|
[18:47] ianbarber
|
yeah, a traditional conference is serious effort
|
[18:48] pieterh
|
when I organized 2-day conferences against software patents, it took 2-3 months *full time* per conference
|
[18:48] sustrik
|
yuck
|
[18:48] pieterh
|
you can do it in 2 weeks with a team of 10 people
|
[18:48] pieterh
|
thus, an unconf is much cooler
|
[18:49] pieterh
|
you just need a good location, and a good subject
|
[18:49] ianbarber
|
unconference is still a fair bit of work, particularly in convincing people to go. I think it would be easier to get people to go the more experts there are though, particularly pieterh sustrik__ and mato, but as many contributors as possible really.
|
[18:49] Guthur
|
+1 that
|
[18:49] pieterh
|
ianbarber: indeed, it usually takes 2-3 events for the notion to take off
|
[18:50] pieterh
|
I'd expect a fairly quite first unconf
|
[18:50] pieterh
|
but the point is that without starting, you can't build it up
|
[18:50] Guthur
|
The thing that puts me in two minds about this unconf is that there is little visibility of that expert driven content
|
[18:50] pieterh
|
sustrik__: do you remember the first AMQP conference?
|
[18:50] sustrik
|
which one was that?
|
[18:51] pieterh
|
don't know if you were there, in London
|
[18:51] pieterh
|
the one with three people in the audience
|
[18:51] sustrik
|
don't think so
|
[18:51] sustrik
|
i remember the one when you got those business types into your loft :)
|
[18:51] sustrik
|
ah, the qcon
|
[18:51] sustrik
|
i think
|
[18:51] sustrik
|
heard about it
|
[18:51] pieterh
|
sustrik__: agh, flashbacks... yes, the qcon one
|
[18:51] Guthur
|
hehe, a pile of suits in a loft
|
[18:51] pieterh
|
Guthur: we could post some topics for discussion on the wiki page
|
[18:51] Guthur
|
a pretty picture
|
[18:52] Guthur
|
pieterh, that would beneficial I think
|
[18:53] Guthur
|
would help me sell it to myself at least, hehe
|
[18:53] pieterh
|
but it's basically up to attendees to be prepared to present stuff
|
[18:53] pieterh
|
well, I can post stuff I'd talk about but that's it
|
[18:53] sustrik
|
cyl
|
[18:53] sustrik
|
well, who's going to attend?
|
[18:54] Guthur
|
if I got to 0MQ unconf that would be 3 trips in a little over a month
|
[18:54] sustrik
|
same here
|
[18:55] Guthur
|
sustrik__, where are you based?
|
[18:55] sustrik
|
Bratislava
|
[18:55] sustrik
|
Slovakia
|
[18:55] Guthur
|
ah, I always assume you where belgian as well for some reason
|
[18:56] sustrik
|
Well, if I was in bxl, I could attend an uncof there every day
|
[18:56] Guthur
|
...true
|
[18:56] sustrik
|
but travelling across half of europe just to have a beer
|
[18:56] sustrik
|
dunno
|
[18:59] ianbarber
|
would you come to the conference if it was a traditional conference (though one you weren't speaking at)?
|
[18:59] guido_g
|
would depend on the progem
|
[19:00] guido_g
|
for me the main reason to go to a conference is learn something
|
[19:00] Guthur
|
oh hi guido_g, sorry never got a chance to give you a call while in Hamburg
|
[19:00] Guthur
|
the schedule was a lot fuller than I thought
|
[19:00] jond
|
sustrik__, ianbarber: referring to earlier stuff that was a good point about the statefull servers because that's exactly the problem i have....
|
[19:00] guido_g
|
Guthur: thought so, Guthur lost in lisp :)
|
[19:01] Guthur
|
hehe, indeed, it was great to finally meet some other lispers
|
[19:01] Guthur
|
a rare breed
|
[19:01] guido_g
|
indeed
|
[19:01] guido_g
|
most of them must be quite old :)
|
[19:02] Guthur
|
there is always a chosen few who pick up the torch
|
[19:02] Guthur
|
there was actually some pretty cool stuff
|
[19:03] jond
|
guthur: what was the best presentation?
|
[19:03] Guthur
|
3 stand out ones, I need to go away for 15 mins though
|
[19:03] Guthur
|
back soon
|
[19:05] sustrik
|
ianbarber: well, i just spent 6 days on a conference that i weren't speaking at
|
[19:06] sustrik
|
it's a const/benefit thing i would guess
|
[19:06] sustrik
|
if it solves a problem, i don't object to travelling
|
[19:07] sustrik
|
jond: yes, the stateful services are a problem
|
[19:07] sustrik
|
i am not even sure there's an accepted generic solution for that
|
[19:08] sustrik
|
the most cases i've seen simply tweaked the architecture until it kind of worked
|
[19:15] WebWeasel
|
I was wondering how long 0mq has been in development?
|
[19:19] jond
|
sustrik: yes, 0mq patterns tend to assume that all workers nodes can do identical tasks, but retrieving state would not be solution as it would be too slow and as the messages are small it's quicker to route to process or thread hosting the state.
|
[19:21] jond
|
and as topic matching and subscription forwarding would be useful for that, rather than use xrep route to identity
|
[19:22] jond
|
that's why i'm always interested in that
|
[19:25] sustrik
|
WebWeasel: since Nov 2007 iirc
|
[19:26] WebWeasel
|
Thank you.
|
[19:27] sustrik
|
jond: well, the basic idea is that all the state is contained in the message itself
|
[19:28] guido_g
|
rest, the ømq way :)
|
[19:28] sustrik
|
yeah
|
[19:28] sustrik
|
the problem is that legacy apps don't work that way
|
[19:29] sustrik
|
thus porting a legacy app to 0mq may is often problematic
|
[19:29] guido_g
|
true
|
[19:30] guido_g
|
but that applies to basically everything
|
[19:30] sustrik
|
true
|
[19:33] jond
|
sustrik__: yes, i am just not sure it always possible though with ordering guarantees etc. it might need another layer of indirection, ie another set of queues in front of the pool which can perform any request.
|
[19:34] Guthur
|
jond: the standout presentations for me where, Compiling for the Common Case, Reconfigurable Computing on Steroids: Using Common Lisp to Generate Domain Specific Hardware, The Scheme Natural Language Toolkit, and Implementing huge term automata.
|
[19:34] Guthur
|
the Common Case one was not very specific to Lisp though
|
[19:34] Guthur
|
but it did promise greater benefits for dynamic languages in general
|
[19:35] Guthur
|
the talk was given by Craig Zilles, who does some R&D for intel
|
[19:36] Guthur
|
it's basically compiling highly optimized code that will be run the majority of the time, and then falling back to more general code for the edge cases
|
[19:36] Guthur
|
sounded pretty cool
|
[19:37] Guthur
|
the reconfigurable computing was also interesting, a company Novasparks which is developing FPGA based low latency computing boxes using Common Lisp to program the hardware
|
[19:38] Guthur
|
they will aim to expose a DSL to the customer for reconfiguration
|
[19:39] Guthur
|
The NLP stuff was just interesting, and the huge term automata was a little over my head but still a nice use of functional programming paradigm to solve a problem that would not otherwise be solvable
|
[19:39] Guthur
|
unless you had infinite memory of course
|
[19:40] jond
|
guthur: there was job going in london looking for people programming FPGAm didnt mention lisp though
|
[19:40] jond
|
guthur: was the NLP/ huge automata scheme?
|
[19:53] Guthur
|
jond: NLP was Scheme
|
[19:53] Guthur
|
the huge automata was CL, some graph theory stuff
|
[19:54] jond
|
guthur: cheers i'll look for papers on website, might even checkout clojure
|
[19:55] Guthur
|
I find it hard to warm to clojure
|
[19:55] Guthur
|
it breaks the nice uniformity of Lisp syntax
|
[19:55] michaelgreene
|
Continuing my port to 2.1, in some cases I end up waiting on a single socket when terminating the context out of several created by my application. One red flag in gdb is that socket.mailbox shows { w = 26, r = 27 }. Should these numbers be balanced? Is there a way to tell whether this socket is waiting on a send or just hasn't been closed? Also, is there anywhere for me to poke at the data that ZMQ is waiting on in the case of a send?
|
[19:55] Guthur
|
it uses square brackets for parameter lists and arrays I think
|
[19:56] jond
|
guthur: that was a point i made to a friend about a year ago, seemed to change things for no good reason
|
[19:56] Guthur
|
michaelgreene_, I think you may want the Linger opt
|
[19:56] jond
|
guthur: have you read kizcales mop book?
|
[19:57] Guthur
|
jond: nope, link?
|
[19:58] Guthur
|
ah AMOP
|
[19:58] michaelgreene
|
Guthur: I am aware that setting Linger could force the socket down, but that is not the behavior I want. In my case, most of the sockets close cleanly, and I want to figure out what is causing 1 socket to remain unclosed and hold up context termination. I'm just not sure how to debug it do to not being familiar enough with ZMQ's implementation structures.
|
[19:58] Guthur
|
jond, It's something I have been meaning to pick up, it's often cited as a must read
|
[19:58] realazthat
|
ahoy
|
[19:58] jond
|
guthur: old but worth a read
|
[20:00] jond
|
guthur: outta here for a while. i really ought to talk 0mq here when i get back.....
|
[20:00] Guthur
|
michaelgreene_, I'm not sure of any easy way to reflect that information
|
[20:01] Guthur
|
jond, Lisp is cool, i should start was 0MQ project in CL
|
[20:02] Guthur
|
michaelgreene_, someone more knowledgeable of 0MQ might be able to answer it
|
[20:02] Guthur
|
but I suspect it is not possible
|
[20:03] Guthur
|
the public API certainly does not provide anything
|
[20:03] michaelgreene
|
I'm not sure how it could not be possible... the data has to exist somewhere, or the reaper wouldn't have an appropriate condition triggered for it to terminate.
|
[20:03] michaelgreene
|
Oh, sure, but I'm in gdb, not the public API.
|
[20:03] Guthur
|
sustrik__, might be able to answer it
|
[20:04] michaelgreene
|
Guthur: I guess I'll have to poke around the source more to see how normal termination works. Thanks for trying.
|
[20:05] Guthur
|
hehe, it's ok I didn't have to try too hard, after the public API my knowledge kind of stops
|
[20:08] realz
|
humm, I know u guys get poor dumb idiots like me all the time asking stupid questions ...
|
[20:08] realz
|
but can 0mx be used for real-time applications over WAN?
|
[20:08] realz
|
ie. for a twitch multiplayer game etc.
|
[20:10] mikko
|
realz: good question
|
[20:11] Guthur
|
twitch games tend to use highly tuned (usually after a couple of patches, hehe) UDP connections to get the low latency required
|
[20:12] Guthur
|
but it would indeed be interesting to see if 0MQ could pull it off
|
[20:12] mikko
|
i think this would be interesting use case for udt transport
|
[20:15] Guthur
|
is UDT not more for better throughput rather than Lat
|
[20:16] Guthur
|
throughput is not so much an issue but you need to have really low latency
|
[20:18] Guthur
|
twitch game network engines tend to be very tolerant of dropped packets, as far as I understand
|
[20:23] realz
|
I am looking into UDT as well
|
[20:23] realz
|
UDT is very configurable
|
[20:24] realz
|
are you looking into using UDT for transport?
|
[20:26] mikko
|
realz: yes, we've been talking about it
|
[20:27] mikko
|
realz: in fact i have an open question with them
|
[20:27] mikko
|
the problem currently is polling
|
[20:27] realz
|
mikko: how modular is 0mq with regard to transport?
|
[20:27] mikko
|
realz: not very
|
[20:27] mikko
|
realz: http://sourceforge.net/projects/udt/forums/forum/393036/topic/4061830
|
[20:28] realz
|
ok, so lets back up a little
|
[20:29] realz
|
excuse my ignorance, but what are some use cases of zeromq?
|
[20:29] realz
|
ie. where does it shine
|
[20:31] mikko
|
a lot of things really
|
[20:31] mikko
|
the biggest things to me are:
|
[20:31] mikko
|
not having to worry about too low-level things about different platforms
|
[20:32] mikko
|
being able to work with 'messages' as a concept
|
[20:32] mikko
|
rather than streams of bytes
|
[20:32] mikko
|
the patterns
|
[20:38] realz
|
yes, I working that message concept into my project now
|
[20:38] mikko
|
also, threading
|
[20:38] mikko
|
not having to create shared data structures and all the pain that comes with it
|
[20:38] mikko
|
rather just pass messages between threads
|
[20:38] realz
|
I want to test multiple transports. currently using TCP, will try UDP, and UDT, maybe enet
|
[20:39] realz
|
true indeed
|
[20:39] realz
|
thankfully single threaded for now
|
[20:39] realz
|
at least the event system
|
[20:40] realz
|
I am using asio, so I dont know what threads it uses, but it is sync'd by the time it gets to my event listener
|
[20:40] realz
|
I am using netstrings to separate messages in TCP
|
[20:40] realz
|
I don't know how good of idea that is lol
|
[20:40] realz
|
but it would be great to have a messaging api
|
[20:41] realz
|
instead of rolling my own
|
[20:43] realz
|
I also have messages that would be nice to multicast over wan
|
[20:44] realz
|
does 0mq do anything to that effect?
|
[20:44] mikko
|
well, pub/sub might be close to what you need there
|
[20:44] mikko
|
multicast over wan sounds problematic
|
[20:45] mikko
|
some people like to compare pub-sub to radio broadcast
|
[20:45] mikko
|
all the clients will receive the message while tuned in
|
[20:45] mikko
|
and you can split your messages into different topics
|
[20:46] realz
|
thats cool i get the gist
|
[20:49] mikko
|
if udt guys add the polling of normal filehandle
|
[20:50] mikko
|
that makes it fairly easy to implement in libzmq
|
[20:50] mikko
|
which would be good
|
[21:02] d4de
|
what else might call zmq_term() or in general terminate the context aside from zmq_term() itself
|
[21:02] d4de
|
I mean without calling zmq_term() directly of course
|
[21:03] d4de
|
cause in the middle of nowhere, a call to getsockopt(), precisely in the check if (unlikely(ctx_terminated)) context is found terminated, and I'm unable to trace what might be terminating the context
|
[21:04] d4de
|
there is no way the context is terminated otherwise without the application being terminated itself
|
[21:04] d4de
|
(in my own application of course)
|
[21:07] pieterh
|
multiple threads?
|
[21:08] d4de
|
yes
|
[21:08] d4de
|
context is shared among threads ... but documentation says that its safe
|
[21:08] pieterh
|
sure, it's safe
|
[21:09] pieterh
|
but one of your threads is exiting and terminating the context
|
[21:09] pieterh
|
explicitly, by calling zmq_term
|
[21:09] d4de
|
that's the thing you see, I don't have zmq_term anywhere! (or I should just look harder)
|
[21:09] pieterh
|
print "hello" before every single instance of zmq_term called in your code
|
[21:10] d4de
|
so there is no other way a context gets terminated except by calling zmq_term?
|
[21:10] pieterh
|
what language are you using?
|
[21:10] d4de
|
C/C++
|
[21:10] pieterh
|
any external classes or APIs?
|
[21:10] d4de
|
yeah I have my own wrappers
|
[21:11] pieterh
|
so go into libzmq and edit zmq.cpp, and add 'assert (0);' in zmq_term
|
[21:11] pieterh
|
then when you get an assertion failure, check the backtrace
|
[21:12] pieterh
|
there are probably less brutal ways to isolate this
|
[21:12] d4de
|
right .. never thought of that hah. Well thanks
|
[21:12] pieterh
|
nope, there are no other ways to terminate a context except by calling zmq_term
|
[21:12] d4de
|
I at least need some method to do it
|
[21:12] d4de
|
thanks though :-)
|
[23:51] realazthat
|
humm, anyone know some sort of network-CS channel? I would love to discuss some scalability ideas
|