[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Berkeley's db_dump is your friend. Your *best* friend.

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2001-03-03 00:19:46 CET

Karl Fogel <kfogel@galois.ch.collab.net> writes:
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > If you actually print that out without the backslashing (i.e. \0a is a
> > newline), you'll get an indented view of the skel. However, I'm
> > thinking the indentation probably isn't worth it. Wouldn't you rather
> > see
> >
> > (fulltext ((dir ()) ()))
> >
> > ?
>
> Yeah, I think that might be easier to debug, since I doubt anyone is
> going to take the trouble to translate the newlines correctly
> anyway. :-)

I think you misunderstand. The actual string stored in the database
really contains ordinary newline characters. If you print it in the
simplest, most obvious way --- like, with `puts' or `fwrite' --- you
get a nicely indented thingy. There's no translation necessary.
Instead, it's db_dump that is "going to the trouble" to print the
newlines as backslashed hex sequences.

> And personally, I usually verify s-expression boundaries by using sexp
> motion commands in my editor; the indentation would be a further clue,
> but not really necessary -- if I were debugging something, I'd
> probably be looking *very* hard at the exact sexps, independent of
> indentation.

If you were debugging syntax errors in skels, or something similar,
yes. But if your problem is at a higher level, the indentation could
be helpful. Taken at your word, the logical conclusion would be that
indentation must never be trusted when debugging, because it's not
what the parser actually cares about. But I know you don't actually
function that way.

But anyway, I'll take out the indentation.
Received on Sat Oct 21 14:36:25 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.