[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch #6071] Resing/Deleting/Inserting variables in GUI

From: John Darrington
Subject: Re: [patch #6071] Resing/Deleting/Inserting variables in GUI
Date: Thu, 12 Jul 2007 11:47:28 +0800
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Jul 11, 2007 at 09:56:23AM +0800, John Darrington wrote:

     I see.  So unless we're going to somehow make the dictionary aware of
     the capabilities of the data source with which it's associated (which
     sounds like a nightmare to me) then we have to compromise.  However,
     there may other advantages to keeping the case indices monotonic with
     respect to the dict indices, and accepting the O(n) overhead of
     dict_compact_values (or dict_pad_values) with every
     I'll see if I can come up with a better patch.

The more I look at this, the more I realize how intertwined the issues
are.  Unforunately, monotonicity is not something that we cannot 
assume nor enforce.  For example, if I run the following in the GUI's
syntax window:

        /v1 v2 v3 v4 v5 v6 v7 v8 v9 v10 v11 v12 v13 
        v14 v15 v16 v17 v18 v19 v20 v21 v22 v23 v24 v25 v26 (F2.0).
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
 SAVE OUTFILE='test.sav'.
 GET FILE='test.sav' /KEEP=v24 v25 v26 all.

then I end up with a non-monotonic dictionary (and it has to stay that
way, otherwise it'll index into the wrong datasheet columns).

So I'm left thinking that my current patch ( #6071 ) is probably the
best solution (with minor cleanup).  If the dict_var_resized function
is a problem, then we could use some macro-magic to stop it being
called carelessly. We should move the header to vardict.h anyway. 


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

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]