On Fri, Oct 20, 2006 at 11:51:16AM -0400, Derek Atkins wrote: > Chris Shoemaker <[EMAIL PROTECTED]> 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
