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 )
|
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?
|
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.
|
Mon 24 Jun 2013 04:52:43 PM UTC, comment #10:
I fixed this.
Thanks Ben for the review.
|
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.
|
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.
|
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)
|
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)
|
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.
|
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.
|
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)
|
Sun 16 Jun 2013 01:00:38 AM UTC, comment #2:
>I can look at this one if you like.
Of course! Please do.
|
Sat 15 Jun 2013 08:08:06 AM UTC, comment #1:
I can look at this one if you like.
|
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."
|