bugPSPP - Bugs: bug #39252, Changing variable type in GUI...

 
 

bug #39252: Changing variable type in GUI clears data

Submitted by:  Ben Pfaff <blp>
Submitted on:  Fri 14 Jun 2013 06:51:29 AM UTC  
 
Category: Graphical User InterfaceSeverity: 5 - Average
Status: FixedAssigned to: None
Open/Closed: ClosedRelease: Before 0.8.0
Effort: 0.00

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 19 Oct 2014 06:50:38 PM UTC, comment #13:

Hi John, I can confirm that when changing the variable type from string to any other choice it will wipe out the data in the column. This is happening on both 32 bit and 64 bit windows versions (ver. PSPPIRE.exe 0.8.4-g607d3c )

Paul Roesler <proesler>
Sat 18 Oct 2014 06:09:07 AM UTC, comment #12:

This item was closed over a year ago. It should not happen with 0.8.4

I checked, and could not reproduce the problem with any recent version.

Are you seeing exactly the same symptoms as originally reported, or is it a different problem?

John Darrington <jmd>
Project Administrator
Fri 17 Oct 2014 11:42:52 PM UTC, comment #11:

Hi All, I have just run into this problem and I am using PSPPIRE.exe 0.8.4-g607d3c on windows 7 64 bit. Are there instructions on how to apply said patches? I am not sure if there is a work around, perhaps assigning the variable type in the sps file? Thanks in advance.

Paul Roesler <proesler>
Mon 24 Jun 2013 04:52:43 PM UTC, comment #10:

I fixed this.

Thanks Ben for the review.

John Darrington <jmd>
Project Administrator
Mon 24 Jun 2013 05:52:52 AM UTC, comment #9:

The date patches look good to me too. Thank you for finding and fixing these problems.

Ben Pfaff <blp>
Project Administrator
Mon 24 Jun 2013 05:50:29 AM UTC, comment #8:

I'm happy with the patches in mutate.tar.gz. I didn't expect you to break the original patch into so many sub-patches, but it's nice.

I'll look at the date patches now.

Ben Pfaff <blp>
Project Administrator
Sun 23 Jun 2013 10:24:54 AM UTC, comment #7:

Here's another lot of patches to fix the problems associated with converting strings to dates (and perhaps other types too).

These patches need to be applied on top of the previous ones.

I think this just needs a final review and check-in. Then this
item can be closed.

(file #28390)

John Darrington <jmd>
Project Administrator
Sat 22 Jun 2013 10:51:11 AM UTC, comment #6:

Round 2.

These patches are basically the same as before, but tidied up and incorporating Ben's comments.

If these are ok, I will push them.

I still need to findout why dates encoded as strings cannot be changed to date variables.

(file #28387)

John Darrington <jmd>
Project Administrator
Fri 21 Jun 2013 06:59:54 AM UTC, comment #5:

> I see some memory leaks: some var_set_*() functions unconditionally clone the variable but only conditionally pass it to dict_var_changed().


I thought I had checked that. I'll take another look.

> Each call to dict_var_changed() passes exactly one VAR_TRAIT_. If you don't expect that to change, then VAR_TRAIT_ does not need to be a bit-mask.


You are right. I can foresee a time when the changes could be aggregated and one signal instead of several emitted. ALTER TYPE might also benefit from being able to pass several TRAITS concurrently.

I'll rework this following your suggestions, and send it out for a second review. I'll try to do them as separate changes to make the review easier.

John Darrington <jmd>
Project Administrator
Fri 21 Jun 2013 04:46:27 AM UTC, comment #4:

Thank you for working on this. I think that this will work.

The more general var_changed() callback is nicer, I think. Good idea.

This functionality is related to the ALTER TYPE command, which is unimplemented. I don't know whether implementing ALTER TYPE would help.

I see some memory leaks: some var_set_*() functions unconditionally clone the variable but only conditionally pass it to dict_var_changed().

Each call to dict_var_changed() passes exactly one VAR_TRAIT_. If you don't expect that to change, then VAR_TRAIT_ does not need to be a bit-mask.

I think that the new version of var_clone() is a little harder to understand. It would not need to change, if one added a helper function that called var_clone() if its argument variable's dictionary had a nonnull var_changed callback and simply returns NULL otherwise, and then each var_set_*() used that instead of calling var_clone() directly.

Ben Pfaff <blp>
Project Administrator
Sun 16 Jun 2013 05:08:25 PM UTC, comment #3:

This patch does much of the job. But the changes have the potential to break other GUI functions, so it needs a good test and a review before checkin.

Tests are especially necessary for the gui functions which involve adding, deleting modifying variables using the gui.

It seems to work ok converting numeric to string, and when converting string to numeric for simple data types. However,
it seems to have a problem when converting strings to dates. I don't know why.

(file #28328)

John Darrington <jmd>
Project Administrator
Sun 16 Jun 2013 01:00:38 AM UTC, comment #2:

>I can look at this one if you like.


Of course! Please do.

Ben Pfaff <blp>
Project Administrator
Sat 15 Jun 2013 08:08:06 AM UTC, comment #1:

I can look at this one if you like.

John Darrington <jmd>
Project Administrator
Fri 14 Jun 2013 06:51:29 AM UTC, original submission:

dr soumalya ray <drsoumalya-ray@yahoo.co.in> reported on pspp-users:

> in PSPP changing the variable type from, say numeric to string or vice-versa, will delete the whole variable.
>
>
> steps:
> 1. launch psppire
> 2. create 2 variables- var1 and var2
> 3. change variable type of var2 to "string"
> 4. enter some data under var1 and var2 (say, 1,2,3,4,5 etc)
> 5. now, again go to the variable view
> 6. change the variable type from "numeric" to "string" for var1
> 7. go to the data view
> 8. all entry under var1 is deleted
> 9. for var2, variable type could be changed from "string" to "numeric" and it will result in the same thing- loss of all data under var2.
> 10. the output in the terminal - "(psppire:28002): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent."

Ben Pfaff <blp>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #28390:  date-conversion.tar.gz added by jmd (3kB - application/x-gzip)
file #28387:  mutate.tar.gz added by jmd (11kB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by proesler (Posted a comment)
  • -unavailable- added by jmd (Posted a comment)
  • -unavailable- added by blp (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 24 Jun 2013 04:52:43 PM UTCjmdStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Sun 23 Jun 2013 10:24:54 AM UTCjmdAttached File-=>Added date-conversion.tar.gz, #28390
    Sat 22 Jun 2013 10:51:11 AM UTCjmdAttached File-=>Added mutate.tar.gz, #28387
    Sun 16 Jun 2013 05:08:25 PM UTCjmdAttached File-=>Added 0001-Convert-data-to-and-from-string-values-when-the-gui-.patch, #28328
      StatusConfirmed=>In Progress
    Fri 14 Jun 2013 06:51:41 AM UTCblpReleaseNone=>Before 0.8.0

    Back to the top


    Powered by Savane 3.1-cleanup