Opening saved account reports

[Derek Atkins]

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?
>
> There are two issues here: 
>
> One is that pre-swig saved state is incompatible with new swig
> wrappers.  E.g. the old file had "query-compare-equal" while the
> swig-wrapped constant is "QOF-COMPARE-EQUAL".  I don't think this is
> worth solving.

*sighs*  Probably not.

> 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'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.

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available