[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: value representation, case indexes, and dictionary indexes
From: |
John Darrington |
Subject: |
Re: value representation, case indexes, and dictionary indexes |
Date: |
Mon, 30 Mar 2009 16:09:30 +0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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