On Tue, Mar 2, 2010 at 12:47 AM, John Denker <j...@av8n.com> wrote:
> On 03/01/2010 04:13 PM, Tim Moore wrote:
>
> > I'm looking at io/sg_file.cxx in the sport branch. I see the old
> > implementation of readline inside an
> > "execrable_readline" #ifdef. I don't see any other implementation of
> > readline.
>
> > Perhaps my question would go away if I fetched your sport flightgear repo
> > too;
>
> You could fetch it into a branch of whatever you're
> already using. Gitorious makes this easy and efficient.
>
> > since I don't have a commit id for the patch where you presumably
> > changed "readline" to "getline", I haven't.
>
> In such a branch, you could do this:
> git log --oneline --author=jsd sg_file.cxx
>
Yes, I did something similar to look at your implementation of getline in
simgear. For your uses of getline in flightgear I don't know a priori in
which files they might occur in flightgear. And yes, I'm quite familiar with
"git log", having used it to pick apart changes in your private sportmodel
repo, among other things. I know how to do "git log -Sgetline sport/sport",
but that is really besides the point.
>
> It will tell you all three commit-ids. There is no need
> to "grovel through logs".
>
> I consider that groveling through logs.
> There will in general not be any such thing as "the"
> commit-id because I cannot suspend development while
> waiting for somebody to get interested in this-or-that
> bit of work I did.
>
This comment is wrong on so many levels. First off, I did identify the
commit id where you made changes to use getline: d5e6aa6235f7. There aren't
any more yet. You could have just told me that! It's not productive to make
me look at it myself when I'm taking time late at night to try to review
your changes.
Furthermore, I can't parse the "suspend development" comment. It is coming
from some alternate reality of git usage. At the start of this very thread
you sent us the commit id of a change you wished to share and have committed
to the sources. In the specific case of getline changes to flightgear, you
have so far only made one commit which uses getline. How hard is it to send
us that? More generally, no one expects you to sit around while I/we
consider your patches. If you're saying that you might make several commits
in implementing a change and can't identify a specific commit that contains
it, then you need to reconsider how you're working in light of git workflow.
Put these changes on a branch! I keep several branches going here that
contain specific features I'm working on. This makes it trivial to submit /
commit them when the time is right without dragging in the rest of the work.
>
> The track record indicates that most of the FG code I
> write eventually gets incorporated into the "official"
> repository, but it is delayed months or years.
>
> No wonder. I'm not going to look at the global state of your repo at a
point in time and tease out the changes related to some feature you'd like
merged. I'm all too familiar with the git tools that can be used to do that,
but I really have better things to do.
Anyway, back to getline. In looking at d5e6aa6235f7, it seems that there
some unrelated changes for bidirectional i/o. Is that correct?
> > But it seems to me that you
> > could easily implement the old "execrable" readline interface in terms of
> > your spiffy getline and save yourself the trouble of changing "readline"
> > calls to "getline."
>
> I don't see an easy way of reimplementing readline _per se_
> in terms of ::getline or SGFile::getline. The semantics
> are too different, especially for small buffers; getline
> might hang in cases where readline would not, and dealing
> with that would be more work than I'm being paid to do.
>
>
OK, my suggestion was probably gratuitous. I'm not sure about this
difference in getline behavior; presumably a "line too long" error is a
local problem with the protocol and not some sort of network attack. The
istream& getline (char* s, streamsize n, char delim )
version of getline might be better here.
It is probably true that any code that uses readline
> would be improved by switching to the getline semantics,
> but again, finding all uses of readline, understanding
> them, and switching them over is more work than I'm
> being paid to do.
>
> I thought you had done that, but no problem. Reviewing your patches is more
work than I'm being paid to do, BTW.
> Don't let the perfect be the enemy of the good.
>
> Ha!
Tim
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
