Sunday June 6, 2010

[Time] NameMessage
[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/
[03:09] postmodern once i created a symlink to, 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 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:
[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 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 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?