[Time] Name | Message |
[03:09] postmodern
|
im having trouble compiling zeromq 2.0.7 on Fedora13
|
[03:09] postmodern
|
mainly it cannot find libuuid
|
[03:09] postmodern
|
since fedora installs it to /lib/libuuid.so.1
|
[03:09] postmodern
|
once i created a libuuid.so symlink to libuuid.so.1, it worked
|
[03:10] postmodern
|
fedora13 is apparently using libuuid 2.17.2
|
[03:10] postmodern
|
also there's no uuid/uuid.h only /usr/include/uuid.h
|
[06:53] postmodern
|
when did the prototype for zmq_init change
|
[06:53] postmodern
|
it used to take 3 arguments, now it only takes 1
|
[21:10] zedas
|
sustrik: hey, 2.0.7 had some sudden changes that has completely broken the python module
|
[21:10] zedas
|
sustrik: actually, probably all of them except C and C++. did you talk with anyone before just rolling that out?
|
[21:17] zedas
|
sustrik: well i'm attempting to fix the python driver, but if you're going to make API changes at the last minute before releases then that's seriously uncool.
|
[21:17] sustrik
|
zedas:hi
|
[21:18] sustrik
|
any better idea?
|
[21:18] zedas
|
make the change and then wait until all the maintainers catch up
|
[21:19] zedas
|
i mean you must have made this change last week right before release because i was trakcing your git and the pyzmq git
|
[21:19] sustrik
|
yes, it was made immediately before release
|
[21:20] zedas
|
instead, 2.0.7 should have had the old api, and then 2.0.8 could have the new one.
|
[21:20] sustrik
|
the problem is with sync of 0mq core and bindings
|
[21:20] sustrik
|
bindings are independent projects
|
[21:21] sustrik
|
how would you sync in such an environment?
|
[21:21] sustrik
|
the real solution is to make bindings make numbered releases
|
[21:21] zedas
|
do you have a mailing list?
|
[21:21] sustrik
|
go on, propose a solution
|
[21:21] zedas
|
you definitely don't sync by just changing the base zmq_init api in a release.
|
[21:22] sustrik
|
so?
|
[21:22] zedas
|
well that breaks everything. it's fundamental to many dependencies
|
[21:22] sustrik
|
i know, i have no solution though
|
[21:22] zedas
|
i suggest this: point releases never change base APIs. people cna rely on 2.0.7 and 2.0.8 being compilation compatible.
|
[21:23] zedas
|
next, if you want to change the API, then you make the decision to boost the 2nd number and people know it.
|
[21:23] zedas
|
then, right before you make the API change, release a final point release with the old api, and start on the new one.
|
[21:24] zedas
|
that way, i can get the important bug fixes and changes just before the API change, and I can keep working while you can advance the API.
|
[21:24] sustrik
|
so you propose maintaining 2 codebases, old compatibility one and a development one?
|
[21:24] zedas
|
nope no need for that, since you got git.
|
[21:24] zedas
|
if i need 2.0.7 i grab that revision
|
[21:24] sustrik
|
backporting of bug fixes?
|
[21:25] zedas
|
i'm saying you have a release policy. dont change the API without doing a point release and then bump the 2nd version number
|
[21:25] zedas
|
if someone needs to then they will, but with git backports are way easier
|
[21:25] sustrik
|
actually beckward incompatible change should bump the major revision
|
[21:26] zedas
|
it's really just a communication policy. you're saying "you can base your software on point releases"
|
[21:26] sustrik
|
so far we've tried to avoid insane version like 27.0.0
|
[21:26] sustrik
|
so we've just tagged it as "beta"
|
[21:26] sustrik
|
but maybe it's time to freeze the api
|
[21:27] zedas
|
yeah but changing zmq_init jsut breaks everything
|
[21:27] zedas
|
so when people go to use it, or when i advocate it, people think it's unstable and get turned off
|
[21:27] sustrik
|
sure, i am aware of the problem
|
[21:27] sustrik
|
what's needed is stable distro
|
[21:27] sustrik
|
plus a dev branch
|
[21:28] zedas
|
well let me ask, what was the reasoning for changing init?
|
[21:28] sustrik
|
the args are no more needed, so it's API cleanup
|
[21:29] sustrik
|
basically, it's a tension between trying to keep API clean and a need to support existing users
|
[21:29] zedas
|
you can do both, plenty of projects do
|
[21:29] versificateur
|
sustrik: have you try to compile the java bindings (jzmq) with new 2.0.7 ??
|
[21:30] sustrik
|
versificateur: yes
|
[21:30] sustrik
|
it worked for me
|
[21:30] versificateur
|
sustrik: it seems that test classes (local_thr...) are broken..
|
[21:30] sustrik
|
what's the problem?
|
[21:31] sustrik
|
zedas: please, do start the discussion of the release policy on the mailing list
|
[21:33] zedas
|
hehe whew, hacking generated python C code sucks.
|
[21:33] versificateur
|
local_lat.java:36 context(init,int,int) in org.zeromq.ZMQ cannot be applied to (int)
|
[21:33] sustrik
|
verisificateur: do you have the latest version?
|
[21:33] versificateur
|
ZMQ.Context ctx = ZMQ.context(1);
|
[21:34] sustrik
|
hm, have you rebuilt and reinstalled it?
|
[21:34] versificateur
|
yes
|
[21:34] zedas
|
sustrik versificateur probably the same zmq_init change?
|
[21:35] sustrik
|
no stray old version of jzmq somewhere on your paths?
|
[21:35] sustrik
|
yes, it's the same thing
|
[21:35] sustrik
|
i've changed the jzmq though
|
[21:35] versificateur
|
i'll check my paths...
|
[21:36] sustrik
|
back to the release policy: i think there should simply be two codebases, the stable one and the experimental one
|
[21:38] zedas
|
well i'm screwed.
|
[21:38] zedas
|
i'll have to contact the pyzmq author and find out what version of pyrex he's using.
|
[21:38] sustrik
|
zedas: sorry about that
|
[21:38] zedas
|
hacking the output C code doesn't work at all.
|
[21:38] sustrik
|
please do complain about it
|
[21:38] sustrik
|
it should be solved in some way
|
[21:39] zedas
|
anyway, I *did* manage to merge 0mq into libtask: http://swtch.com/libtask/
|
[21:39] zedas
|
so you get coroutines that can process 0mq messages and file/socket I/O off an abstraction from zmq_poll
|
[21:40] sustrik
|
what's the project?
|
[21:40] sustrik
|
a portability lib?
|
[21:40] zedas
|
it's a portable abstraction on coroutines in C
|
[21:41] zedas
|
super duper fast, but it used plain old poll
|
[21:41] zedas
|
so with my little update it uses 0mq poll and then i can use the same abstraction for sockets, files, or 0mq
|
[21:41] zedas
|
and it took a tiny bit of changes to work.
|
[21:41] sustrik
|
ah, i see
|
[21:42] zedas
|
mostly just to see if it'd work :-)
|
[21:42] sustrik
|
well, my long term goal is to expose 0MQ via BSD socket API, that would achieve the same goal
|
[21:43] sustrik
|
but again, such a thing would break backward compatibility :(
|
[21:43] versificateur
|
I didn't found something noticeable in my paths..
|
[21:43] versificateur
|
so should i remove all 2.0.6 files
|
[21:44] versificateur
|
and reinstall??
|
[21:44] sustrik
|
versificateur: let me try myself
|
[21:47] sustrik
|
versificateur: hm, it builds ok for me
|
[21:47] sustrik
|
maybe you have old 0MQ core still
|
[21:48] sustrik
|
have you installed 0MQ/2.0.7?
|
[21:48] versificateur
|
yes probably
|
[21:49] sustrik
|
were does the context(init,int,int) come from?
|
[21:49] sustrik
|
can you check where is it defined?
|
[21:51] versificateur
|
yes i'll try
|
[21:51] cremes
|
zedas: the ruby ffi bindings are compatible with the 2.0.7 release if you want to dip your toe back into ruby waters... ;)
|
[21:52] cremes
|
(or will be when i push 0.5.0 in about 30 minutes)
|
[21:55] sustrik
|
let _me_ start the discussion of the stable versions on the mailing list :|
|
[21:59] versificateur
|
okay i fix it
|
[22:00] sustrik
|
versificatuer: no, do not fix it, just find where it's coming from
|
[22:00] versificateur
|
It was my ZMQ.java file
|
[22:01] sustrik
|
the one from github?
|
[22:01] versificateur
|
I've modifications on the 2.0.6 version
|
[22:01] sustrik
|
ah, ok, that explains it
|
[22:02] versificateur
|
but now with the 2.0.7 what does the ZMQ.Context(1) mean?
|
[22:02] versificateur
|
application? thread?...
|
[22:02] cremes
|
versificateur: io threads
|
[22:03] versificateur
|
so it's the first arg of the old implementation??
|
[22:04] sustrik
|
it's second arg of the old implementation
|
[22:04] sustrik
|
api_threads is not needed as you can use 0mq from as many threads as you want now
|
[22:06] sustrik
|
zedas: ok, done, i've started the discussion
|
[22:06] sustrik
|
let's see what happens
|
[22:06] versificateur
|
so taking the multithreaded example i'll have (1) instead of (11,1,0)
|
[22:07] sustrik
|
yes
|
[22:12] versificateur
|
I made the Device port to jzmq
|
[22:13] sustrik
|
great
|
[22:13] versificateur
|
i'll test it and ask you for a pull request
|
[22:13] sustrik
|
thanks!
|
[22:32] zedas
|
sweet, 0mq works great with libtask
|
[22:33] zedas
|
i'm able to slam the hell out of it with 0mq req/rep messages and also do full socket hits and serve files.
|
[22:38] zedas
|
http://dpaste.de/o5xx/ here's the end result
|
[22:38] zedas
|
very nice.
|
[22:48] foysavas
|
zedas: coroutines? but event-driven is all the fad right now :P
|
[22:49] foysavas
|
actually coroutines make a lot of sense for a web server, under what conditions would you have a task reschedule itself?
|
[22:50] zedas
|
foysavas: well it's event-driven, just done with coroutines :-)
|
[22:51] foysavas
|
ah, true, you're just saw that you're using zmq_poll
|
[23:02] foysavas
|
sustrik: btw, if you make two branches, one stable, one dev, make stable 'master'
|
[23:03] foysavas
|
not sure why it's so popular to do otherwise
|
[23:20] foysavas
|
sustrik: also, i just wrote up some D bindings for zmq. any chance of linking to them from the zeromq site, once i put them up on github?
|