Re: value representation, case indexes, and dictionary indexes

[John Darrington]

On Sun, Mar 29, 2009 at 11:21:50PM -0700, Ben Pfaff wrote:
     Now I'm trying to get the PSPPIRE code working well with it.
     This is a little harder than I expected, because I'm not quite
     sure what the intended relationships are among the dictionary and
     the datasheet and the case indexes and dictionary indexes.
     
     Dictionary indexes are always from 0 through the number of
     variables in the dictionary minus 1.  That part is easy.
     
     This is what I think might make sense for the remaining
     relationships in the value-rep branch's PSPPIRE:
     
             The case index is always exactly the same as the
             dictionary index, simply because there is no reason for
             it to be different given that PSPPIRE is working with a
             datasheet, which is capable of permuting its variables
             into whatever order is most convenient for its client,
             and also given that each column in a datasheet has an
             arbitrary width in this branch.
     
     The following is what appears to actually happen:
     
             Case indexes simply continue to increase as variables are
             added, because deleting a variable from the dictionary
             does not delete any columns from the datasheet (there are
             no references to datasheet_delete_columns() from
             src/ui/gui at all, even in the master branch).
     
     So I'm thinking about, roughly, changing
     insert_variable_callback() and delete_variable_callback() to call
     dict_compact_values() on the dictionary, also about adding a call
     to datasheet_delete_columns() to delete_variable_callback().  I
     think that this will enforce the new invariant above, as well as
     garbage collecting deleted variables.
     
     Do you have comments on this?  i.e. does it sound reasonable and
     a good way to do things?  Or should I do something different?


Your suggestion makes perfect sense.  As you've discovered the
relationship between PsppireDict and PsppireDataStore is flakey and
needs to be reconsidered.  Some of this was implemented in a hurry
just before the release of 0.6.0 - it works - but as you say leaks
variables.      

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature