Friday August 27, 2010

[Time] NameMessage
[03:01] andrewvc cremes, you around?
[03:03] AndrewBC Woah, hi. :D
[03:10] andrewvc we have similar names eh?
[03:21] AndrewBC Indeed
[03:27] andrewvc Quick question about pub/sub if anyone's got a moment
[03:28] andrewvc is it best practice to send the topic separately with SNDMORE, then send the rest separately? Or is that just optional. I've seen examples both using and not using that technique
[04:24] sustrik andrewvc: it's up to you
[04:24] sustrik there's no fundmantal difference between the two
[04:25] sustrik other than in the former case the "topic" is cleanly separated from the "body"
[04:36] sustrik cremes, andrew_cholakian: no, it's OK to use context from multiple threads
[04:36] sustrik just use each socket only in the thread it was created in
[04:59] CIA-20 zeromq2: 03Jon Dyte 07master * r3cb84b5 10/ (src/forwarder.cpp src/queue.cpp src/streamer.cpp): forwarder and streamer devices handle multi-part messages correctly -
[09:33] guido_g anyone experienced a problem with zmq::poll?
[09:34] guido_g _sometimes_ it doesn't sent revents correctly, as it seems
[09:34] guido_g it returns with a return value of 0, ignoring the received messages
[09:35] guido_g ØMQ version is latest from zeromq/zeromq2
[09:36] theICEBeardk Is it like this issue ?
[09:36] guido_g reading...
[09:37] guido_g we have an issue then :)
[09:37] guido_g yep, seems to be the same problem
[09:39] guido_g any ideas why this happens?
[09:39] theICEBeardk I hope the workaround in the issue can help you
[09:39] theICEBeardk None
[09:41] guido_g scary that no one seems to be interested in this issue
[09:41] guido_g it renders nearly everything useless
[09:41] theICEBeardk agreed
[09:43] theICEBeardk Maybe the devs can't verify the problem or reproduce it. What platform are you on?
[09:43] guido_g GNU/linux Debian testing w/ 2.6.35 kernel
[09:44] theICEBeardk Okay nothing too obscure then :)
[09:44] guido_g ouch...
[09:44] guido_g the problem in the issue is different
[09:45] guido_g i had a timeout of -1
[09:46] guido_g the code says that errors other then EINTR are to be ignored
[09:48] theICEBeardk hmm, if you have some test code, I have to do the unhelpful thing and suggest you raise the issue on the github.
[09:48] theICEBeardk I know it doesn't help much.
[09:49] guido_g sure
[09:55] guido_g okay... on a different machine it works
[09:56] theICEBeardk Different os or just a different machine?
[09:57] guido_g same os, a little bit older, kernel
[09:57] guido_g and older ømq lib
[09:57] guido_g from jul 15
[09:57] guido_g hmm hmm hmm
[09:58] theICEBeardk ah a release and not from github
[09:58] sustrik guido_g: what timeout do you use?
[09:58] guido_g -1
[09:58] guido_g hi sustrik btw :)
[09:58] sustrik hello :)
[09:59] sustrik hm, that should never return 0
[09:59] guido_g <- code is receiver_poll.cpp and sender.cpp
[09:59] sustrik 0 means "timeout"
[09:59] guido_g right
[10:00] sustrik that's 2.0.8 you are using?
[10:00] guido_g yes
[10:00] sustrik let me have a look...
[10:00] guido_g cloned a few hours ago
[10:01] sustrik 2.0.8 or trunk?
[10:02] sustrik the zmq_poll code have changed immediately after 2.0.8 release
[10:02] guido_g then it is trunk i fear
[10:02] sustrik ok, wait a sec
[10:03] sustrik are you using windows or something else?
[10:04] guido_g nope, GNU/linux Debain testing
[10:04] sustrik ok
[10:05] guido_g ok, now same on the other machine that worked with 2.0.7
[10:05] sustrik guido_g: ok, the new version is buggy
[10:05] guido_g so there is something wrong in zmq
[10:06] sustrik the whole zmq_poll functionality should be in loop
[10:06] sustrik and restart the loop if there are no events to return
[10:07] sustrik it was like that in the old version
[10:07] sustrik doesn't appear to be like that now...
[10:07] guido_g 2.0.8 is safe?
[10:07] sustrik yes
[10:07] sustrik mato: summon!
[10:07] pieterh guido_g: would it be easier if there was a branch "stable" for 2.0.8?
[10:07] sustrik bug in zmq_poll!
[10:07] guido_g pieterh: YES!
[10:07] guido_g :)
[10:07] pieterh ok, please harass Mato about that
[10:08] guido_g or have a brachn vor this kind of development, so that master is always tested
[10:09] pieterh hah
[10:10] pieterh master should be tested, of course
[10:10] pieterh some disagreement about whether new code goes to master or 'develop' branch
[10:10] guido_g develop, please
[10:11] guido_g 'cause this was half a day of fuzzing for me on the software that worked
[10:11] guido_g before the update
[10:11] pieterh please make your wishes known to mato
[10:11] guido_g send location pls ]:->
[10:12] pieterh via zeromq-dev list, guido_g
[10:12] guido_g oh...
[10:12] pieterh i'd suggest simply state your requirements as user of the git
[10:12] pieterh perhaps referencing practice of other projects
[10:12] sustrik yes, that's the best
[10:13] guido_g sure, going to write a mail
[10:13] sustrik the issue is not that easy as in the future there can be several stable versions etc.
[10:13] pieterh sustrik: yes, indeed
[10:13] guido_g then we should have release branches
[10:13] pieterh but only one (max two) maintained stable version, normally
[10:14] pieterh guido_g: that would seem obvious but... last time i suggested that it was not welcomed
[10:14] pieterh however i think mato is coming round to that point of view
[10:15] guido_g pieterh: i remember there was something...
[10:15] pieterh up to now releases have been tags
[10:15] guido_g ok, then
[10:15] pieterh after 2.0.8 we immediately got a patch (zmq_term)
[10:15] guido_g how do i get the 2.0.8 release out of github?
[10:15] pieterh lol
[10:15] pieterh well, it's tagged
[10:15] pieterh checkout from the tag
[10:16] pieterh it should work *obviously* for git n00bs IMO
[10:16] pieterh none of us are linux kernel hackers
[10:17] sustrik no way it could work without knowing how to check out a branch
[10:17] sustrik i had that last week
[10:17] sustrik i had a branch i wasn't able to access
[10:17] sustrik i think it's something like:
[10:18] sustrik git checkout -b name-of-the-branch remotes/origin/name-of-the-branch
[10:20] pieterh sustrik: you had an old version of Git
[10:20] pieterh actually that command was also documented in the original proposal I made
[10:21] guido_g git show v2.0.8 <- shows commit
[10:21] pieterh but with git 1.7 you no longer need to specify the remote
[10:21] guido_g git reset <commit> seems to work
[10:21] pieterh yes, the tag is just a nicer name for the commit id
[10:22] pieterh problem is that once we need to maintain a stable release, we can't use tags
[10:22] pieterh so all the commands change
[10:22] sustrik :(
[10:22] pieterh it become git checkout branchname
[10:22] pieterh not git reset tagname
[10:22] pieterh that's why i'd prefer a branch, always, for the last stable release
[10:23] pieterh so it's always "git checkout master" or "git checkout stable" or "git checkout develop"
[10:23] guido_g right
[10:23] guido_g ok, 2.0.8 works
[10:23] pieterh then we can argue about whether master is the bleeding edge, or not
[10:23] sustrik pieterh: a patch without MIT in the mailing list
[10:24] pieterh sustrik: yeah, but it's a 1-line change...
[10:24] sustrik should i ignore it?
[10:24] guido_g pieterh: wasn't that you who posted that link to
[10:24] pieterh ... i don't think copyright applies to single line fixes
[10:25] pieterh guido_g: someone else posted it, i tried it, it's great but way too complex for our needs
[10:25] guido_g ok
[10:25] sustrik if it does and if i apply the patch, project is stuck with current license forever
[10:25] pieterh sustrik: I'd much rather have patches arriving on a website/wiki/issue tracker where it says in huge letters, BY SUBMITTING A PATCH YOU ETC.ETC.
[10:25] sustrik should i proceed?
[10:26] sustrik yes/no
[10:26] pieterh i'll do the necessary, sustrik
[10:26] pieterh hang on...
[10:27] pieterh done
[10:28] pieterh sustrik: if I had to receive patches I'd set-up an issue tracker where anyone posting a patch had to register and accept terms of use that clearly stated the licensing for their contributions
[10:28] pieterh email is really suboptimal for this except that it lets everyone see the patch (do people actually review it?)
[10:28] sustrik it should be clear what the licensing is
[10:29] pieterh there should be a template for each patch
[10:29] sustrik please write an email explaining what the current contribution policy is
[10:29] pieterh it's not changed
[10:29] pieterh it is documented on the website afair
[10:30] sustrik the anouncement about a community project have confused people
[10:30] pieterh
[10:30] sustrik so make it clear that it's still not in effect
[10:30] pieterh "Please send it to the developer mailing list and explicitly state that you are licensing the patch under the MIT/X11 license."
[10:30] pieterh sustrik: if this was the cause of confusion people would be submitting patches under LGPL
[10:31] pieterh that's not the problem here IMO
[10:31] pieterh it's just that there is no automation of this
[10:31] sustrik they do
[10:31] pieterh i missed that
[10:31] sustrik patch to LGPL'd project is a derivative work thus LGPL
[10:32] pieterh not necessarily
[10:32] pieterh a patch that is not explicitly licensed under LGPL is simply unusable
[10:32] pieterh if you redistribute code with incorrect licensing you can be asked to change it
[10:33] pieterh however it's not automatic
[10:34] pieterh no matter what policy there is, the author of a patch MUST license it, or it falls under simple copyright and cannot be reused, period
[10:34] sustrik how does linux kernel process work then?
[10:34] pieterh presumably all contributors sign off somewhere along the line
[10:34] sustrik how does that work?
[10:35] pieterh i don't know how it works in the linux kernel process, martin
[10:35] sustrik what I see is just signed-of-by someone
[10:35] sustrik no mention of licensing
[10:35] pieterh however try to submit random piece of code without license, see what happens
[10:35] sustrik that's the standard
[10:36] pieterh note how it works for the site
[10:36] pieterh sorry, i need to catch a plane
[10:36] sustrik ok, cya
[10:36] pieterh the sane model is upfront agreements
[10:36] guido_g have a safe trip
[10:36] pieterh when you join a community you agree (once) about licensing your contributions
[10:36] pieterh thanks
[10:37] pieterh this is the problem with the mailing list
[10:37] pieterh you can fix it, but i'm repeating myself, by putting patches via a web site of some kind
[10:37] pieterh where you accept Terms of Use and IP Policy when you join
[10:37] pieterh cyal
[13:01] CIA-20 zeromq2: 03Martin Sustrik 07master * r56faac7 10/ src/zmq.cpp : zmq_poll returns prematurely even if infinite timeout is set - fixed -
[13:16] keffo any particular reason why the null delimiter between routinginfo and payload thinks it's size is 17?
[13:16] sustrik that's not a delimiter
[13:16] sustrik that's an identity
[13:16] sustrik if you don't set the identity yourself
[13:16] sustrik 0mq generates one
[13:16] sustrik it's an UUID (in binary form) thus 16 bytes
[13:17] sustrik +binary zero at the beginning to distinguish it from user defined identities
[13:17] sustrik summa summarum 17 bytes
[13:17] keffo ah makes sense
[13:19] mato sustrik: hmm, so a fd returned by ZMQ_FD can still become ready even if there are no events?
[13:20] sustrik well, there are events, such as "new connection established"
[13:21] sustrik but these don't map directly to pollin/pollout
[13:21] sustrik anyway, i've fixed it
[13:21] mato sure, but isn't that exposing an implementation detail to the api?
[13:22] sustrik if there was a workaround i would use it :(
[13:22] sustrik the whole ZMQ_FD thing is a hack
[13:22] sustrik 0MQ socket should be a _real_ file descriptor
[13:23] mato yes, yes, but i'm talking about the current state of affairs, not the ideal state of affairs in five years time
[13:23] sustrik well, the current state of affairs looks like this
[13:23] sustrik i think you cannot really fix it
[13:24] mato isn't this because the fd returned by ZMQ_FD is zeromq's internal signalling fd?
[13:24] sustrik yes
[13:24] mato ok, and, hypothetical question, couldn't ZMQ_FD return a fd that only responds to a subset of the events (i.e. those exported to the API)
[13:25] sustrik how would you filter out the other events
[13:25] sustrik ?
[13:25] mato well, the naive idea is that ZMQ_FD actually *registers* a 2nd signalling fd internally
[13:26] mato and the signalling stuff only signals the events exported to the user on that fd
[13:26] sustrik then you have a synchronisation problem
[13:26] sustrik how to get two signal streams into sync
[13:28] mato right, because the signalling is also used for synchronization
[13:28] sustrik exactly
[13:28] sustrik on a different thread: how is submitting patches done on LKML?
[13:28] sustrik there doesn't seem to be explicit licensing mentioned
[13:28] mato ah, yes, i saw the discussion
[13:28] mato yes there is
[13:28] mato and i wrote an email about it at least once to the ml
[13:29] sustrik which one was that?
[13:29] mato email?
[13:29] sustrik yes
[13:30] mato sustrik: see my replies to Pieter's RFC: ØMQ Contributions, Copyrights and Control thread
[13:30] sustrik on the wiki?
[13:30] mato no
[13:30] mato on email
[13:31] sustrik "Apropos contributions, to ensure we don't run afoul of any licensing
[13:31] sustrik problems I think it would be useful to institute a "Certificate of Origin"
[13:31] sustrik policy using Signed-Off-By: tags in patches or Git commits, similar to what
[13:31] sustrik is done by the Linux kernel.
[13:31] sustrik "
[13:31] sustrik that's it?
[13:31] mato i also explain in another reply i think where the Linux guys explain that
[13:32] mato
[13:32] mato see point 12) in that document
[13:32] mato basically the presence of Signed-Off-By: on a patch or Git commit indicates acceptance of the "Developer's Certificate of Origin"
[13:33] mato so, patches w/o a Signed-Off-By: cannot be applied (or discussed in fact, the sender should just be told to go read SubmittingPatches)
[13:33] mato the Signed-Off-By: tag(s) propagate from the patch into Git
[13:33] mato and are thus kept as history
[13:34] mato git also has direct support for Signed-Off-By
[13:34] sustrik how is the certificate bound to signed-off-by?
[13:34] mato by using -s on commits, or configuring your Git install/repo to automatically sign commits
[13:34] sustrik does the developer have to sign some agreement in advance?
[13:34] mato no
[13:35] mato why should they?
[13:35] mato *they* must add the Signed-Off-By
[13:35] mato if they add it, it states their agreement with the certificate
[13:35] mato i don't see the problem
[13:35] sustrik what's the legal procedure to infer that you've signed the certificate
[13:35] sustrik if you've filled up the signed-off-by?
[13:36] mato you don't "sign" the ceritifcate
[13:36] mato IANAL, but your adding of the Signed-off-by: states your intent of agreement with the ceritifcate since it's in the project policy (SubmittingPatches in this case)
[13:37] sustrik sounds pretty creaky from legal point of view
[13:37] sustrik IANAL myself
[13:37] mato well, it was explicitly introduced after the SCO affair IIRC
[13:38] mato so it must be "good enough" for Linux...
[13:38] sustrik presumably
[13:38] sustrik i just don't see the link between certificate and the signed-off-by field
[13:38] sustrik i can write a different certificate
[13:39] sustrik and say you agree with it if you fill in siged-off-by
[13:39] sustrik then i will claim linux for myself
[13:39] sustrik muahaha
[13:40] mato sustrik: well, if you're really worried, ask some of our lawyer friends for an opinion
[13:40] mato i see it as a much better alternative to the business of someone writing in email "Yes, that patch is submitted under MIT"
[13:41] mato there is of course no perfect alternative
[13:41] sustrik yes. it's much better
[13:41] mato unless you want to force people to go through silly click-through agreements (the legality of which is questionable anyway)
[13:41] sustrik but i simply don't understand how it works
[13:41] sustrik is it a contract between Linus Torvalds and the developer?
[13:42] sustrik who'e the authority to impose particular working of the certificate and accept the sing-off-by's?
[13:42] sustrik wording*
[13:43] mato
[13:44] mato there is Linus' original request for discussion from 2004
[13:44] mato sustrik: anyway, what is your worry? that it's legally unenforceable?
[13:45] sustrik nope
[13:46] sustrik i'm just wondering about what pieter said that patch for GPL'd code is not necessarily a GPL code itself
[13:46] sustrik so that when you are submitting a patch you have to explcitly state that it's GPL
[13:46] sustrik or LGPL
[13:46] sustrik or whatever
[13:47] sustrik the sign-off-by afaics is only a tracking feature
[13:47] sustrik not meant to explicitly state what license the patch is submitted under
[13:49] sustrik to my naive understanding, sending the patch to the mailing list constitutes the act of "distribution"
[13:49] mato did you read the certificate?
[13:49] mato (d) I understand and agree that this project and the contribution 319 are public and that a record of the contribution (including all 320 personal information I submit with it, including my sign-off) is 321 maintained indefinitely and may be redistributed consistent with 322 this project or the open source license(s) involved.
[13:49] sustrik and?
[13:50] sustrik what i mean it doesn't even look to be a contract
[13:50] sustrik there's only one party involved
[13:50] sustrik that's kind of strange
[13:51] mato it's a compromise to lower the overhead of contributing
[13:51] mato if you want a legal opinion, ask a lawyer
[13:51] sustrik shrug
[13:52] sustrik it's tracking system
[13:52] sustrik it's explicitly state in the preamble
[13:52] sustrik To improve tracking of who did what, ...
[13:52] mato feel free to suggest something better
[13:52] sustrik it's automatic IMO
[13:52] mato go and research how other sucessful projects do it
[13:53] sustrik patch of GPL'd work is a derivative work
[13:53] sustrik when you send it to the ML it's "distributed"
[13:53] sustrik so you are obliged to do it under the same license
[13:53] mato yes, but the point of signed-off-by is to track the original person claiming the right to distribute
[13:53] sustrik sure, that's ok
[13:54] sustrik what i was talking about was that pieter says the above reasoning doesn't apply
[13:55] mato shrug :)
[13:55] sustrik to my understanding linux relies on it and uses sign-off-by as an additional tracking measure
[13:55] mato it seems it's either that or signing over copyright explicitly
[13:56] sustrik yes
[14:17] sustrik GPLv2 says that modified versions, if released, must be “licensed … to all third parties.”
[14:22] guido_g sustrik: just tested the latest master version, poll still not working
[14:24] sustrik what happens?
[14:25] guido_g nothing on first req
[14:25] guido_g then it hangs sometimes after 2nd or 3rd message
[14:25] sustrik nothing = exits with 0
[14:25] guido_g going to put the debug output back into my test programs
[14:25] sustrik ?
[14:26] guido_g wait a second
[14:26] guido_g now poll does not return when a message has been sent
[14:27] sustrik hangs, right
[14:27] sustrik that's poll on the rep side of req/rep pair, right?
[14:28] guido_g these changes really should go into a branch
[14:28] guido_g yes, req -> xrep (with poll)
[14:28] guido_g code is
[14:29] sustrik let me try
[14:36] sustrik ok, reproduced
[14:38] guido_g ahh, good to know ,)
[14:39] cremes is there any long term plan to add some behavioral testing to 0mq so we can quickly catch regressions?
[14:40] guido_g or better a short term one?
[14:41] mato cremes, guido_g: good point, i've also been thinking about this
[14:42] guido_g mato: while you're here: how do i get the stable (not fuxxed up) 2.0.8 from github w/o typing for an hour?
[14:42] mato i'm not a fan of the various TDD methodologies, but having at least a baseline "make test" that verifies that things more or less work would be a good start
[14:42] cremes
[14:42] mato guido_g: 1) clone the repo 2) git checkout v2.0.8 :)
[14:43] guido_g you can checkout a tag?
[14:43] mato sure you can
[14:43] cremes guido_g: check the ML; i posted an answer to this 1 or 2 days ago
[14:43] mato you can't easily base work off that tag w/o turning it into a branch, but that's a different issue
[14:44] guido_g going to check this git thing now...
[14:44] cremes guido_g: here's a better answer...
[14:44] cremes
[14:44] mato and git in fact will tell you straight away that if you want a local branch it's just git checkout -b <name> at that point
[14:44] cremes mato: what are your thoughts on a set of regression tests?
[14:45] cremes aside from 'make test'
[14:45] mato cremes: well, the major hurdle is that the system we're testing is distributed
[14:45] sustrik pretty hard to write sane tests
[14:45] mato yes and no
[14:45] sustrik some basic stuff can be done though
[14:45] guido_g why the *** hell is not mentioned those books...
[14:45] guido_g *is this
[14:46] mato tests can be written to use tcp over localhost
[14:47] mato or ipc
[14:47] mato and inproc separately since that is a different code path
[14:47] sustrik yes
[14:47] mato sustrik: in fact, we can have multiple contexts in a single process
[14:47] sustrik true
[14:47] mato so a test can even use multiple contexts if you need it
[14:47] mato basically you do all the "distributed" stuff using multiple threads
[14:48] sustrik the hard part is starting individual components in synchronised manner
[14:48] mato give me an example?
[14:48] sustrik it's often like:
[14:48] sustrik start component 1
[14:48] sustrik start component 2
[14:48] sustrik press any key at 1
[14:48] guido_g mato: any chance to write the git shuffle for a version into the README?
[14:48] sustrik etc.
[14:49] mato guido_g: well, until now the assumption was if you're wanting the stable release you don't work out of git
[14:49] guido_g ah ok
[14:50] mato guido_g: also, i'm still trying to get my head around what the best way to hold patches for a stable release in git actually is
[14:50] guido_g may i say that this assumption isn't a good one?
[14:50] mato well, ultimately, we can't teach people who want to use git how they should do that
[14:50] guido_g what about a maintenance branch?
[14:51] mato guido_g: yes, the plan is for a maintenance branch of some sort, but i've been spending the last day trying to understand what the best workflow for us (i.e. sustrik and myself) is
[14:51] mato please be patient :-)
[14:52] mato guido_g: anyhow, the tags are all there, for all past 2.0.x releases
[14:52] guido_g well, you should, 'cause these people are the user base (at least a significant part of)
[14:52] mato guido_g: sure, d'you have a git expert i can talk to ? :-)
[14:52] sustrik guido_g: are you running the code from trunk in production?
[14:52] guido_g mato: if i'd have, i'd talk to him myself first
[14:53] guido_g this is one big problem: limited understanding of the tool chain
[14:53] mato of course
[14:54] mato guido_g: anyhow, *any* code you're using in real production should come out of a release tarball in my opinon
[14:54] sustrik that's what i wanted to say
[14:54] sustrik it may work using a git for a while
[14:54] sustrik but in long run it's dangerous
[14:55] guido_g problem here is: ømq is so young, that *important* fixes and updates are quite frequent
[14:55] guido_g tarballs are only available for official releases
[14:55] mato yes, which is what the maintenance branch is for, which i'm trying to define, etc etc :)
[14:55] guido_g between the two are huge gaps
[14:56] sustrik mato: have you tried talking to martin hurton
[14:56] sustrik i don't know whether he's an expert but he's definitely with git longer than we are
[14:57] mato yeah, that's a good idea... or possibly asking for help on the Git mailing list/IRC
[14:57] mato the only problem with mailing lists/IRC is figuring out if the answers are any good :-)
[14:57] sustrik ha
[14:57] guido_g :)
[14:58] sustrik well, even if you define a viable process, there's still a question of who's going to work on the maintenance branch
[14:58] cremes try asking on stack overflow
[14:58] sustrik backporting bugfixes is not much fun
[14:59] mato sustrik: the process i want to define forces the committer applying the fix to evaluate whether or not it also applies to the maint branch
[14:59] mato sustrik: it's the only viable way at the moment imo
[14:59] sustrik you mean that every contributor would have to post a diff for every maitenence branch?
[14:59] mato no
[15:00] mato the person integrating those changes is responsible
[15:00] sustrik for bakcporting?
[15:00] mato no
[15:00] mato the point is
[15:00] mato at the moment we have a bunch of changes which are common to stable and master
[15:00] mato so those changes should be merged verbatim into both
[15:01] mato now, about backporting
[15:01] mato this is entirely voluntary
[15:01] sustrik the above _is_ backporting, no?
[15:02] mato no
[15:02] sustrik "bunch of changes which are common to stable and master"
[15:02] guido_g backporting a feature should be the exception
[15:02] cremes regarding git, this may help just a little bit
[15:02] cremes
[15:02] sustrik i meant backporting the bugfixes
[15:02] mato sustrik: if the code has not diverged there is no concept of backporting
[15:02] mato sustrik: we do have a bunch of changes like that at the moment
[15:02] sustrik cremes: what's that?
[15:02] mato sustrik: e.g. the device stuff from jon dyte
[15:03] sustrik yes, it works as long as you don't get conflicts on merge
[15:03] mato if those conflicts are trivial to solve then there is no problem
[15:04] sustrik ok, i see what you mean
[15:04] sustrik sounds viable
[15:04] mato if they are not, then you are in a different situation
[15:05] guido_g i think the other way is much more important, a bug in stable has been fixed and this has to be incorporated into dev
[15:05] sustrik it's the same thing
[15:05] sustrik "bunch of changes which are common to stable and master"
[15:06] guido_g ok
[15:06] mato well, my view would be that the stable release is a volunteer effort
[15:06] guido_g elaborate
[15:07] mato what i mean by that is: if we get a fix for stable, it's our interest to merge it also into master if relevant
[15:08] mato however, i would expect most development to be concentrated on master
[15:08] mato and the backporting of fixes into stable from master to be minimal
[15:08] mato does that make sense?
[15:08] guido_g i figure you define "development" as developing new features in contrast to bug fixes
[15:09] mato no, not really
[15:09] guido_g then it doesn't make sense
[15:09] mato ok, let me put it this way
[15:10] mato the problem is that 2.1.x and 2.0.x have diverged due to large infrastructure changes
[15:10] mato 1) if a fix is applicable trivially to both, no problem, it goes in both
[15:10] guido_g ok so far
[15:10] mato 2) if not, someone has to make a decision on what effort needs to be spent
[15:11] mato sustrik would obviously want to concentrate on master
[15:11] guido_g in this case, backports shouldn't be done. stop.
[15:12] mato yes, pretty much
[15:12] mato that's what i was trying to say
[15:12] mato unless someone actually steps up to do the work, i won't stop them :)
[15:12] sustrik i think it a question of money flow
[15:12] mato (if it is a backport of a fix, obviously features don't get backported into stable. ever.)
[15:13] sustrik if support license business launches off
[15:13] sustrik it would obviously focus on stable
[15:13] sustrik not development
[15:13] guido_g mato: which is why there is a new version, so no problem
[15:13] mato guido_g: precisely
[15:14] mato sustrik: in that case a person from said business will step up to backport fixes
[15:14] sustrik exactly
[15:14] mato the point is, *anyone* can backport fixes if they want to
[15:14] sustrik and the said business is ourselves
[15:14] guido_g or adopt fixes from stable to master
[15:15] sustrik the people on this list are probably those that can be hired to maintain the stable
[15:15] guido_g anyhow, a "stable" branch should be there
[15:15] mato sustrik: you're mixing money with community, different issues
[15:15] sustrik i mean, if a business wants stable to be supported, who are they going to hire?
[15:15] sustrik you
[15:15] sustrik me
[15:15] guido_g did I hear hired? :)
[15:15] sustrik guido
[15:16] sustrik people from the community
[15:16] mato sustrik: it's still a different issue. the point is a stable branch can be there, fixes can flow into it, and releases will be made when someone has the motivation to do so
[15:16] sustrik eh, isn't that the right word?
[15:16] mato whether that motivation comes from being hired or not is irrelevant
[15:17] mato if the community (paid or not) has no interest in further stable releases of 2.0.x then there won't be any
[15:17] sustrik i'm just commenting on the fact that maintaining stable is not a fun job
[15:17] mato maintaining anything is not a fun job
[15:17] mato you can ignore all bug fixes that don't affect you
[15:17] guido_g what about the following: if dev has a fix, it is cut down and put aside as a commit into a branch, then _someone_ can get to this branch and try to apply the fixes to stable
[15:17] mato but then other people won't use your software :)
[15:17] guido_g full ack
[15:18] guido_g had a day of today and wanted to play with ømq, instead i chased a bug...
[15:18] mato sustrik: the key point is to encourage contributions, to stable or not
[15:18] mato more people = more manpower
[15:18] sustrik sure
[15:18] mato = you find more people who are trustworthy, and you delegate to them
[15:19] keffo or a crappy tasting soup!
[15:19] guido_g unfortunately: more people -> needs more structure
[15:19] sustrik so guido_g today contributes as a tester :)
[15:19] mato precisely
[15:19] guido_g sustrik: *sigh*
[15:19] guido_g btw, just installed expect and going to use it for some tests scripts
[15:20] guido_g idea is to have small programs with defined output and using expect to verify it
[15:21] sustrik aha
[15:21] sustrik yes it would be good to put a test suite together
[15:22] guido_g and for devs a dependency like expect shouldn't be to hard to meet
[15:22] sustrik does it have to be a part of the build system?
[15:23] mato why use expect at all?
[15:23] mato the test programs themselves should either assert/abort or succeed
[15:23] mato no dependency required
[15:23] guido_g ok
[15:23] guido_g i'll rewrite my experiments (which uncoverd the poll issue) into one test program
[15:24] sustrik thanks
[15:24] mato sustrik: also, brian has a bunch of poll tests in the pyzmq repo
[15:24] mato sustrik: these could be trivially rewritten into c/c++
[15:24] sustrik ack
[15:24] sustrik but right now it exceeds my resources
[15:24] guido_g this is what i had in mind :)
[15:25] mato guido_g: take a look at the poll tests in pyzmq, it's what i had in mind
[15:25] guido_g guess what i'm doing atm? :)
[15:26] mato all that's needed is then figuring out the automake stuff to make a driver that runs the tests on "make test"
[15:26] mato i can do that
[15:26] mato it's just "run all of this stuff and error if any step asserts/aborts"
[15:26] mato which is automatic since the assert/abort will get you a non-zero exit status
[15:27] guido_g ack
[15:27] guido_g let me hack a simple test progam
[15:55] mato sustrik: guido_g: ok, i've figured out the automake stuff for tests
[15:56] guido_g oh oh
[15:56] mato sure, which is why /me figured it out for you :)
[15:56] guido_g thx a lot then :)
[15:56] mato end result is, i have a tests/ directory, with a single test case in it
[15:57] mato and you can run "make check" which runs all the tests and prints a nice summary, complains which failed/passed, etc
[15:57] mato sustrik: a couple of questions
[15:57] sustrik yes?
[15:57] guido_g mato: ok
[15:57] mato sustrik: 1) the tests should be mostly C, not C++, right?
[15:57] mato sustrik: since the C API is our main deliverable
[15:58] mato sustrik: (there can of course be C++ tests in there, later)
[15:58] sustrik yes
[15:59] mato sustrik: then the only problem i have is this business of linking C against C++ runtime when --disable-shared is used
[15:59] sustrik but iirc you had a problem compiling c files anyway
[15:59] mato well, kind of
[15:59] sustrik that's why you changed the perf tests to .cpp
[15:59] mato yes
[15:59] mato this happens when you use --disable-shared
[15:59] sustrik i'm using it
[15:59] mato :)
[15:59] guido_g mato: if you would like to check the test_poll.cpp at
[16:00] sustrik ha, i thougt it is a project called "GUI dog"
[16:00] sustrik now i see it's guido_g :)
[16:00] guido_g *sigh* :)
[16:01] mato guido_g: yeah, nice, that's kind of the idea i have
[16:01] guido_g good
[16:01] guido_g going to fill in some more tests now
[16:01] mato except i'm wondering whether test cases should be using just the C api
[16:01] mato or not... not sure if it matters
[16:02] guido_g the c++ api is the native one, right?
[16:02] mato no, the C API is
[16:02] sustrik C++ is a wrapper
[16:02] mato the C++ API is just a thin wrapper in zmq.hpp
[16:02] sustrik but it's distributed with the package so i don't really see a problem
[16:02] sustrik and using C++ api is much easier
[16:02] mato yeah, i guess not
[16:02] guido_g but the software is written in c++
[16:02] sustrik the exceptions just run out of main
[16:03] sustrik and cause fault
[16:03] mato yup
[16:03] mato guido_g: one minor point; independent tests should be independent programs
[16:03] mato in other words, in your program, test_pair() is basically main()
[16:03] mato the reason for this is "make check" will run all the tests
[16:04] guido_g ok, going to change that
[16:04] mato not just stop at the 1st one
[16:04] mato it'll then give you a nice pass/fail summary
[16:04] guido_g what is the grouping attribute? socket type? access type? moon phase?
[16:05] mato grouping? of tests?
[16:05] guido_g yes, because having programs for every permuation of socket type for every way to access it plus special cases would lead to an enormous amount of programs
[16:06] guido_g i'd say lets do it like: test_pair, test_reqrep, test_pushpull or so
[16:06] guido_g as a start
[16:07] CIA-20 zeromq2: 03Dhammika Pathirana 07master * r98dc118 10/ src/zmq_decoder.cpp : assert on malformed messages -
[16:07] guido_g later we'll likely add tests for special cases
[16:07] guido_g going to rename test_poll.cpp to test_pair.cpp and see how far it goes
[16:08] sustrik i don't believe you will ever be able to devise a systematic naming for test programs
[16:08] mato i think start somewhere
[16:08] mato we can change things as we go along
[16:08] mato no big deal, they're just test programs
[16:08] mato sustrik: ok, i'm going to have to go to dinner soon
[16:08] mato what i can do
[16:09] guido_g but they have to be maintained!
[16:09] mato of course
[16:09] mato but if you don't maintain them you'll get shot pretty quickly since they'll stop working :)
[16:09] mato so, what i can do now, if you guys want to continue
[16:09] guido_g make test would make a niche pre-push hook :)
[16:10] mato guido_g: that is some way away, but yes, autobuilders and test is what we need
[16:10] mato so much to do :)
[16:10] guido_g as usual
[16:10] mato anyhow, i can push to master the framework that adds a test/ subdirectory with my one lone silly test in it (just creates and destroys a context)
[16:11] mato then you can start adding tests as you like
[16:11] mato does that sound like a plan?
[16:11] guido_g and i will move my test_*cpp into that dir on my local clone
[16:11] guido_g and see if it works
[16:11] mato yup yup
[16:11] guido_g if it does, i do what?
[16:12] mato sustrik: last question (i can choose here): should "make" build the tests or should they only be built if you also want to run them (with make check)
[16:12] mato sustrik: /me thinks 1st option is better for now
[16:12] sustrik build them immediately
[16:12] mato ok, but they'll only get run when you do "make check"
[16:13] sustrik sure
[16:13] sustrik ultimately they'll take several minutes to run
[16:13] mato guido_g: you send a patch with your contribution to the ml, stating it's under the MIT license, as usual and sustrik or myself can apply it
[16:13] sustrik so not by default please
[16:13] mato yes, but build by default
[16:13] mato ok
[16:14] guido_g may i use this nifty git email feature?
[16:14] mato indeed you may :) the only problem is how do you get the "this is under MIT license" into it?
[16:14] mato if you can do that, please do, but email to the list of course
[16:14] guido_g ok, i'll have a look then
[16:15] mato you could for now, if sustrik is happy, even just use git-email and then reply to your own email with "Patch is under the MIT license"
[16:15] mato assuming you can't figure out a way of getting git-email to do that
[16:15] guido_g otherwise i'll send the patches as attachments and state the license stuff in the main mail
[16:15] mato yup, thx
[16:16] mato the license stuff will hopefully go away soon, there's been an RFC out about dropping the MIT requiremenet, but this is for iMatix to decide
[16:41] CIA-20 zeromq2: 03Martin Lucina 07master * r35cb1fa 10/ ( tests/ tests/simple.cpp):
[16:41] CIA-20 zeromq2: Add a basic framework for a test suite
[16:41] CIA-20 zeromq2: The test suite uses the standard automake support. Tests are always built,
[16:41] CIA-20 zeromq2: but run only when you do a "make check". -
[16:41] CIA-20 zeromq2: 03Martin Lucina 07master * r0b76f23 10/ src/zmq_decoder.cpp : Merge branch 'master' of -
[16:41] mato sustrik: guido_g: ok, there you go
[16:42] mato for now all tests need to xyz.cpp even if you're using the C API
[16:42] mato to add a test, add it's source file to tests/, update tests/ (should be self-explanatory)
[16:42] mato make check runs the tests
[16:42] mato have to go now, cyl
[16:43] guido_g ok, thx
[16:43] sustrik vya
[16:43] sustrik cya
[16:45] mems hey, I'm trying to work out if zeromq can do what I need for my application
[16:46] mems I have a server which manages a list of compute jobs
[16:46] mems then a variable number of worker nodes that get jobs from it
[16:46] mems and (because I'm new to zmq) I can't work out if with zmq I would have to have a polling based situation
[16:48] sustrik mems: the works will be load-balanced among workers?
[16:48] mems I'd like each worker to request a job from the server and then perform it
[16:49] mems I'm not completely familiar with the terminology here... dunno if that's what you'd regard as "load-balanced"
[16:49] sustrik so it's worker who plays the active role?
[16:49] sustrik i.e. decides to do some work
[16:49] mems that was my plan
[16:50] sustrik then create a REQ socket at each worker
[16:50] sustrik and a REP socket at the server
[16:50] sustrik it's classic client/server scenario
[16:50] mems and when the server's job queue is empty?
[16:50] mems (but will be full in the future)
[16:50] sustrik no jobs then :)
[16:51] mems but would the clients have to repeatedly poll the server in that situation?
[16:51] sustrik no
[16:51] sustrik they can idly wait for the work
[16:52] mems hmm... it would appear that I'm not sure what a REP and REQ socket are
[16:52] mems are there some API docs?
[16:55] sustrik manual pages
[16:55] sustrik man zmq
[16:55] mems yup. just found them, thanks :)
[16:55] sustrik also online here:
[16:55] sustrik
[16:56] mems ok, so, to complicate matters, I have multiple types of worker that work on the jobs at different points in their lifetime
[16:57] mems so the request from the worker is more like "give me a job in state X"
[16:57] mems presumably this means that the server will need to be able to say "I don't have anything in that state at the moment"
[17:00] sustrik separate REP sockets in the server for separate kind of work then
[17:02] mems hmm. I'll have a play
[17:10] guido_g ha! first tests work
[17:11] sustrik :)
[17:11] guido_g now for the patch thing...
[17:13] mems is there a way of discovered from which client a message has come from?
[17:13] mems **discovering
[17:14] sustrik no unless you put that into the message itself
[17:14] ModusPwnens Hi
[17:14] sustrik hi
[17:14] ModusPwnens are you helping someone already?
[17:14] mems sustrik: this seems odd to me -- is this not a really common requirement?
[17:14] ModusPwnens mm, that answers my question
[17:14] sustrik :)
[17:15] sustrik it's the nature of the thing
[17:15] sustrik use 0mq where you want to communicate with a lot of homogenous peers
[17:16] sustrik if you want to treat each connection separately, use standard TCP sockets, that's what they are for
[17:16] mems mmm... but then one loses zmq's framing
[17:17] sustrik shrug
[17:17] mems hehe
[17:17] sustrik framing is easy
[17:17] sustrik write the size, then data
[17:18] sustrik 0mq is a scalability solution
[17:18] mems ok
[17:18] sustrik thus it makes you communicate with an unknown number of peers
[17:18] sustrik that way you can add and remove processing nodes as you wish
[17:18] sustrik without tweaking your code
[17:21] mems ok. I see what it's going for.
[17:21] mems one last question ;)
[17:21] mems if I have a bunch of sockets, can I block on getting a message from any one of them?
[17:21] mems (zmq sockets obviously)
[17:22] sustrik have a look at zmq_poll
[17:22] mems excellent
[17:23] guido_g when it works... ]:->
[17:24] ModusPwnens oh guido is here too!
[17:24] guido_g yes
[17:26] ModusPwnens ok so, i was trying to do the throughput/latency tests that zeromq has in their install package, but for some reason the remote end doesnt think the address is valid
[17:27] ModusPwnens in the example, they use eth0 for the local end, but I don't think that identifier means anything in windows
[17:28] sustrik in windows you have no sane NIC names
[17:28] sustrik use an IP address
[17:28] sustrik guido_g: i think I've found the problem
[17:28] ModusPwnens Yeah, i tried that. I used the IPv4 address of the computer that the local test was running on
[17:30] guido_g sustrik: good, because with the current master the tests fail :)
[17:31] guido_g ok, first coffee
[17:38] guido_g ahh... format-patch is nice
[17:42] keffo finally, I got the routing working across two queues :)
[17:50] ModusPwnens so does anyone know whats going on with the test suite..?
[17:51] cremes ModusPwnens: we just started chatting about it a few hours ago
[17:54] sustrik cremes: there's a testing infrastructure added to trunk
[17:54] sustrik no tests yet though
[17:55] cremes good progress for a few hours work!
[17:55] sustrik 'make check' will run them
[17:55] sustrik cremes: btw, the diagram we've made yesterday
[17:55] cremes yes?
[17:56] sustrik what about changing the terminal nodes to REQ and REP
[17:56] sustrik that way it will show how all 4 socket types work
[17:56] ModusPwnens Really? what a what were you talking about regarding the test suite?
[17:56] cremes sure
[17:57] cremes since you have the source for the graphic, make the change and i'll update the text
[17:57] sustrik ok
[17:57] sustrik ModusPwnens: that it has to be done :)
[17:57] ModusPwnens but there is a test suite for zeromq already..
[17:58] ModusPwnens well at least for latency and throughput
[17:59] sustrik that are performace tests
[17:59] sustrik we were talking about functionality tests
[17:59] ModusPwnens Oh. I think there is a misunderstanding or something then. I'm just having trouble to get the performance tests running
[18:00] sustrik cremes: done
[18:01] sustrik Modus: paste you command lines here
[18:01] ModusPwnens k
[18:02] ModusPwnens on the local computer: local_thr.exe tcp:// 1 100000
[18:02] ModusPwnens where the ipaddress used their is the ip address of that computer itself
[18:02] ModusPwnens there*
[18:03] sustrik and the remote?
[18:03] ModusPwnens well its the same thing except it uses remote_thr.exe
[18:03] sustrik what version are you using?
[18:03] ModusPwnens 2.07
[18:04] sustrik does it hang?
[18:05] ModusPwnens yeah they seem to run but not do anything..and i changed it to 10 so that i wouldn't have to wait so long
[18:06] sustrik none of the two programs exits?
[18:06] ModusPwnens Nope.
[18:07] sustrik do they or do they not?
[18:07] ModusPwnens they don't
[18:07] sustrik that's pretty strange
[18:08] sustrik the remote at least should exit after 10 seconds
[18:08] sustrik can you get the backtrace from the remote, to show where it is hanging?
[18:08] ModusPwnens maybe something else is going on. the computer i've been using has been having a slew of other problems
[18:08] ModusPwnens hmm, i will try that and get back to you
[18:19] cremes sustrik: i have a different idea
[18:20] cremes make a copy of the image as x2.png with req/rep as the terminal nodes and restore the original pic
[18:20] cremes i'll write a separate paragraph explaining the new diagram
[18:20] sustrik ok, but i already overwrote the original pic
[18:20] cremes i don't want to rewrite a bunch of the text but i have no problem adding another paragraph or two for a new config
[18:21] sustrik so x2 will be the original one
[18:21] cremes fine, then make x2.png with xreq/xrep
[18:24] sustrik cremes: there you go
[18:24] cremes thank you
[18:29] sustrik guido_g: testutil.hpp:36: error: extra ‘;’
[18:29] sustrik i'll fix it
[18:29] sustrik namespaces should not be followed by ;
[18:29] sustrik c++ syntax is plain weird
[18:30] guido_g oh the mail is through :)
[18:30] guido_g compiled here
[18:30] sustrik was that a generated email?
[18:30] guido_g no, that would have involved things via imap
[18:31] sustrik ok
[18:31] guido_g just a format-patch as attachment
[18:31] guido_g sustrik: which compiler version should one use?
[18:32] sustrik guido_g: any
[18:32] sustrik the more the better
[18:32] guido_g ok
[18:32] sustrik it even compiles on icc or xlc etc.
[18:34] guido_g c++ --version
[18:34] guido_g c++ (Debian 4.4.4-8) 4.4.5 20100728 (prerelease)
[18:35] guido_g ok, now that the process of sending patches is understood even by me, i'll produce some more
[18:35] sustrik anyway, the point is the more compilers the better so we catch all possible deviations from standard syntax
[18:35] guido_g i'll *not* try to compile ømq on my n900... no way :)
[18:36] sustrik iirc someone already did :)
[18:36] guido_g sustrik: any other remarks on the patch?
[18:36] sustrik coding style... i'll fix that
[18:36] guido_g *sigh* would be nice, but given that maemo has been killed by nokia... waste of time
[18:36] guido_g ouch yes, i tend to forget such things
[18:39] sustrik one more thing:
[18:39] sustrik when including zmq.hpp
[18:39] guido_g is there a description of the wanted coding style?
[18:39] sustrik use #include "../include/zmq.hpp"
[18:39] sustrik the headers are not yet installed
[18:39] guido_g right
[18:40] sustrik so you can end up including old headers from the previously installed version
[18:40] guido_g yup, got it
[18:40] guido_g just copied the files over from my dev dir
[18:40] sustrik
[18:42] guido_g ahh... 've been looking in the wrong place
[18:52] sustrik guido_g: i would say making the context global is not a good idea
[18:52] guido_g why?
[18:52] sustrik that way zmq_term gets called _after_ the return from main
[18:52] sustrik which is kind of strange
[18:53] guido_g ok, i'll move it into main then
[18:53] sustrik i'll do it
[18:53] sustrik just commenting
[18:53] guido_g as you wish :)
[18:53] guido_g don't do too much
[18:53] guido_g i already have more changes here
[18:54] guido_g actually making the things work and such :)
[18:54] sustrik wait a sec!
[18:54] guido_g no problem
[18:54] sustrik i am reformatting it so it'll be pain in the ass to merge it
[18:55] guido_g no merges planned
[18:55] guido_g only plain typing to get used to the coding style
[18:56] sustrik ok
[18:56] sustrik using assert without including <assert.h>
[18:56] sustrik that may fail on some platforms
[18:57] guido_g did i say that my last exposure to c++ was roughly 10 years ago?
[18:57] sustrik i'm not complaining
[18:57] guido_g i really need to re-learn a lot as it seems
[18:57] sustrik just commenting so that you are aware of it
[18:57] guido_g thx
[18:58] guido_g i completely forgot what i wanted to do today...
[18:58] sustrik :o)
[19:01] sustrik why are you including iostream?
[19:01] sustrik it doesn't look to be used anywhere
[19:01] guido_g i tested the thing using cout
[19:01] sustrik ack
[19:07] sustrik ============================================
[19:07] sustrik 2 of 3 tests failed
[19:07] sustrik Please report to
[19:07] sustrik ============================================
[19:07] sustrik woohoo!
[19:09] guido_g yeah, it's the broken poll
[19:11] sustrik guido: do you want this address attached to the patch:
[19:11] sustrik
[19:11] sustrik ?
[19:11] sustrik guido_g
[19:11] guido_g it's ok with me
[19:13] guido_g at least, i did something useful today :)
[19:14] CIA-20 zeromq2: 03Guido Goldstein 07master * r4d9b046 10/ (6 files in 2 dirs): two tests added -
[19:14] sustrik great, done
[19:14] sustrik thanks for that!
[19:14] guido_g cool, i'll pull and have a look
[19:14] guido_g you're welcome
[19:27] guido_g i'll send the fixes i have so you have some working tests
[19:27] guido_g more tests should be written once we have a working poll again
[19:27] guido_g is that ok?
[19:36] guido_g so the fixes are out
[19:41] sustrik guido_g: sure, it's ok
[19:41] sustrik thanks
[19:47] mato back for a bit
[19:47] mato guido_g: good to see the test framework is useful
[19:50] guido_g mato: it sure is
[19:50] mato i'll look at your tests over the weekend, kind of late now
[19:50] guido_g we have 2 tests for now
[19:50] mato but the general feel is good
[19:51] mato i think there will be some general guidelines we'll want to write for people contributing test cases
[19:51] guido_g they're just testing the basics of req/reqp and pair incl. poll
[19:51] mato sure, it's a start, that's good!
[19:51] guido_g ack
[19:51] guido_g i'll write more after poll is back on master
[19:57] guido_g i'm off too, good night all
[19:57] mato good night guido_g
[20:41] cremes under what circumstances should i expect to see this error? Assertion failed: false (object.cpp:342)
[20:41] cremes this is on 2.0.8
[20:42] cremes i *think* it is happening when a socket is blocked on recv and i call zmq_close() on the sockets
[20:52] cremes obviously, i am calling zmq_close on those sockets from another thread :)
[20:54] mato there you go then :-)
[21:49] tyler trying to compile with the bundled pgm (./configure --with-pgm && make) results in an error in both 2.0.7 and 2.0.8 source distributions
[21:49] tyler /usr/bin/ld: .libs/libzmq_la-txwi.o: relocation R_X86_64_PC32 against `pgm_rs_create' can not be used when making a shared object; recompile with -fPIC
[21:49] tyler /usr/bin/ld: final link failed: Bad value
[21:49] tyler any help would be appreciated
[21:54] mato tyler_: you're on redhat ?
[21:54] tyler centos 5.4
[21:54] mato thought so
[21:54] mato see this thread:
[21:54] mato
[21:55] mato specifically:
[21:55] mato Just quickly check altering this line in src/Makefile,
[21:55] mato to
[21:55] mato -DPGM_GNUC_INTERNAL= \
[21:55] mato try that, the problem should go away
[21:57] tyler that did the trick, thank you!
[21:57] mato tyler_: no problem... as far as i can see it's a redhat 5.4 issue only with their gcc