On Mon, 11 Feb 2002, Greg Stein wrote:
> On Tue, Feb 12, 2002 at 12:34:28AM -0500, Daniel Berlin wrote:
> >...
> > > I'm guessing it is to make it easier to substitute different parsers in
> > > there. Lucas Bruand just made some change in the ViewCVS repository that
> > > might help with parser substitution (although I haven't reviewed what he has
> > > done yet).
> >
> > It won't help.
> > See, he's using istdiostream, which only exists in GCC 2.95 (it's non
> > standard).
> > There is no easy replacement in 3.0 or any other compiler, so we can't
> > do it that way.
>
> Huh? There isn't a way to take a FILE* and create a C++ stream?
Nope.
Well, no *standard* way.
basic_filebuf in libstdc++-v3 generally takes a FILE * as its first
argument
But it's not pretty, or guaranteed, just luck.
Look in the "added members and types" section of libstdc++-v3 faq.
> That just
> seems weird; like it is a total disregard of interfacing with existing
> software(!).
Don't look so surprised. iostreams = good, stdio = bad, remember?
One of the largest complaints you'll always hear from C++ people is that
books on C++ don't teach iostreams, they use C stdio.
>
> How about wrapping a stream around a file descriptor? We can get a file
> descriptor from (most) Python file objects.
Nope. The suggestion in the libstdc++-v3 docs is to fdopen it and abuse
basic_filebuf.
>
> > So I changed rcsparse and friends to just pass the filename, and removed
> > supporting passing in fileobjects from tparse.
>
> Hmm. Well, if we can't portably convert a FILE* or file descriptor into a
> stream, then we can certainly remove that capability. I'd like to keep the
> general ability of passing a file object.
So would I.
In fact, this completely took me by surprise when i tried to compile
tparse with g++ 3.
Attempts to find a solution have been generally met with "Just use
ifstreams". E
>
> In any case, it sounds like *some* kind of patch is required for tparse.
>
> > > The above code is all gone now. Rather than once per file, at the end of the
> > > commit processing, I call a new function (get_metadata) to fetch the author,
> > > log message, and formatted date. At the moment, there is no caching, but we
> > > can add it to that one method.
> >
> > I had already done the same, but the comment in the checked in version
> > is plain wrong the log message isn't always the same for every cvs
> > revision in a commit. Nor is the author, for that matter.
>
> Huh? If there are different authors, then how could it possibly be the same
> commit?
By abusing the way you digest.
(Sorry, that just sounds funny to me.)
>
> And how do you manage to give different log messages in one commit?
>
> Even if both of those are possible in CVS, we don't have the equivalent in
> SVN. Those would need to be partitioned (as appropriate) into multiple SVN
> commits.
>
> > Think what happens when we wind up with the case of two
> > revisions to the same file in one commit.
>
> Huh? That shouldn't happen. It does now because we don't have enough smarts
> in there right now.
>
> Oh. Hmm... does this happen if you commit to multiple branches at one time?
Yes.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006