Opening saved account reports

[Chris Shoemaker]

On Fri, Oct 20, 2006 at 11:51:16AM -0400, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at COX.NET> writes:
> 
> >> Is there any way we can fix this -- at least in certain places where we
> >> stringify the enums?
> >
<snip>
> > The other issue is some saved state is now stringified with the numeric
> > constant values instead of their names.  IIRC, the way this worked
> > before was that C code in engine-helpers.c would dynamically construct
> > strings that would form the names of g-wrap generated mapping
> > functions.  Then, the string could be evaluated using
> > scm_c_eval_string() and turned into a procedure which could then be
> > called using libguile, passing the value of the constant.  The g-wrap
> > generated mapping function would return a symbol corresponding to the
> > value of the constant.  From there, I think the symbols were later
> > automatically stringified by guile's (write ...) function.
> 
> This, however, is more problematic.  Anytime we stringify here we
> really should stringify using the symbol and not the value!
> 
> > AFAIK, this technique was only used for query attributes, and only
> > those that are enums, and not even all of _those_.  Even with the old
> > g-wrap code, we were saving numeric values for some query attribute
> > enums like KvpValueType. (BTW, this code had been rotting since the
> > linas days, c.f.  "gnc_scm2KvpValueTypeype" (sic) which used to be
> > called "gnc_scm2kvp_value_type").
> 
> I'm not sure what you mean by "not even all of those".  Keep in mind
> that there were v1 and v2 queries.. Also, the KVPs were translated
> directly.  The 'kvp type' was implicit in the scheme encoding, not
> explicit.  I'd certainly like to see an example of a stringified
> query in 2.0.x that contains an enum-value instead of an enum-symbol.

I think I either mis-remembered or mis-read the code, because I can't
find any stringified numerics in the query.  ???

> > I'm sure there's some smart, maintainable way to completely serialize
> > the query while de-coupling it from the C enum definitions, but the
> > old g-wrap solution was incomplete and a huge mess.  Now it's simply
> > gone. :)
> 
> I'm not sure this is any better, tho.
> 
> > Maybe one solution is to change the guile representation of the query
> > to just use symbols internally, and then provide our own mapping from
> > enums to symbols, and vice versa.  We already have > 2k LOC (just in
> > C) dedicated to serializing and unserializing the query.  What's a few
> > hundred more, right?  :(
> 
> Well, that's sort of what it was..  But remember that the mapping has
> to be two-way; there needs to be a way to convert a C query to a SCM
> query, as well as a SCM query to a C Query.  Although perhaps what we
> really need is just a pure query serialization API and just use that
> instead of trying to read it as scheme code.

I don't know.  Did you have something particular in mind?  If we just
want to handle these enum values, we could always repeat the
ENUM_AS_STRING() pattern.  It's pretty awful stuff, but arguably less
awful than two round-trips into guile for each enum-conversion.
Honestly, I'd much rather see something like a GKeyFile or GConf
storage of report options, but that's not a 1 week project. :(

-chris