On 01/22/2011 08:50 PM, Gerd Lorscheid wrote: > Hello, > > you are right, what I did is the same as a dentist will do when you come at > the weekend. This is what I did and what I solved, because there was my > actual pain: > >>> Now if you do the following: >>> * open two bases with trees >>> * create a new game in one base, insert moves but do not save >>> * switch to the other base and back. >>> Your entered game is lost. > I think it is easy to reproduce, what happened before and after my patch. > > What your dentist will do when he has time and you have money I have > described also below.
I resign. Joost. > Gerd > > > > > -----Ursprüngliche Nachricht----- > Von: Joost 't Hart [mailto:joost.t.h...@planet.nl] > Gesendet: Samstag, 22. Januar 2011 20:25 > An: Gerd Lorscheid > Cc: 'Scid Users List' > Betreff: Re: AW: AW: [Scid-users] Potential data loss using trees > > On 01/22/2011 07:33 PM, Gerd Lorscheid wrote: > > Hi! > >> Hi, >> >> as I said. This is most probably not the only place where an unsaved game > is >> overwritten. > Please do understand that this /is/ the place where my game is > overwritten, but that your protection mechanism (based on > sc_game_number() !=0&& sc_game_altered() == false ) does not work in my > case. In my case, the observer functions simply do not refer to the > actual state of affairs! > > And that I do not understand either why it works for you. Did you maybe > "alter" the running game in /both/ dBases? > > I am not unwilling at all to commit your patch (believe me), but I am > afraid that it may hide the real problem - which will consequently be > harder to track down in ~some~ future. > > Cheers, > Joost. > >> But in the use case I described when I submitted this fix this >> location did overwrite an unsaved game. So I prevented it. >> Basically there should be a routine in tcl to switch a game and this > should >> be used whenever the game is changed to ensure that nothing get lost. If >> there is no problem then this will not change anything except make it 0.05 >> seconds slower. But if there is a problem the user has a chance to save > his >> work or prevent the switch. The call "sc_game load" is called more than 20 >> times in the tcl code, so volunteers are searched to have a look for each > of >> them and then the problem is gone. >> >> Gerd >> >> >> -----Ursprüngliche Nachricht----- >> Von: Joost 't Hart [mailto:joost.t.h...@planet.nl] >> Gesendet: Samstag, 22. Januar 2011 19:15 >> An: Gerd Lorscheid >> Cc: 'Scid Users List' >> Betreff: Re: AW: [Scid-users] Potential data loss using trees >> >> On 01/22/2011 04:36 PM, Gerd Lorscheid wrote: >>> Hello, >>> >>> I cannot solve all problems with one small fix. >> Probably true, but I do not think that anybody was expecting this. >> >>> The location, which I fixed >>> did overwrite an unsaved game without warning. This is what I prevented >> and >>> there is no alternative. >> Hm. >> >> Can you explain why your patch works? The sc_game * operations /should/ >> operate on a different game than the running game in the running base >> after you temporarily sc_base switch-ed to the tree base. Right? >> >> That is why I think there is a threading problem at hand. >> >> I analyzed a bit further. In my scenario I create a new game _after_ the >> tree base has been opened, but before the tree refresh is completed for >> the first time. Surprisingly the sc_game operations do not refer to my >> new game at all. The thread doing the tree refreshing seems to be >> unaware that I did create this new game. >> If I create the new game before opening the base-as-tree, the problem >> does not show... >> >> Cheers, >> Joost. >> >>> There may be other locations doing the same. It may >>> be worth to check every place where the game is changed (to the first of >> the >>> filter) without warning. If any feature has a problem with my small fix, >> its >>> implementation has to be fixed because then its built on wrong >> assumptions. >>> Gerd >>> >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Joost 't Hart [mailto:joost.t.h...@planet.nl] >>> Gesendet: Samstag, 22. Januar 2011 12:35 >>> An: Gerd Lorscheid >>> Cc: 'Scid Users List' >>> Betreff: Re: [Scid-users] Potential data loss using trees >>> >>> Hi, >>> >>> I suggest we analyze this issue a bit further... >>> >>> On 10/08/2010 06:20 PM, Joost 't Hart wrote: >>>> Hi! >>>> >>>> [Linux, CVS] >>>> >>>> 1a) Open a dbase in which you want to add a new game >>>> 2a) Open-as-tree some big reference database (~4M games, dunno if size >>>> matters here) >>>> >>>> Do NOT wait for (2a) - which is concluded by the complete tree list of >>>> statistics - to complete >>>> >>>> 1b) Start a new game (hit Ctrl-X) >>>> 2b) Make a few moves on the board >>>> 3b) Wait for (2a) to complete. >>>> >>>> Kaboom! Running game is destroyed, board returns to game#1 of your > dbase. >>>> Cheers, >>>> Joost. >>> Gerd, your suggestion does not resolve the problem above. >>> >>> After tree completion I am still sent back at game#1 of dBase. >>> >>> But there /is/ a change: >>> >>> When I exit Scid at this point, Scid produces an "unsaved game warning" >>> and it appears that my new game is not entirely lost (as it was), but >>> added as a new game to the tree base. >>> >>> Hm... >>> >>> Cheers, >>> Joost. >>> >>> >>> On 01/19/2011 09:03 PM, Gerd Lorscheid wrote: >>>> Hello, >>>> >>>> at the end of ::tree::dorefresh you find the following code: >>>> >>>> >>>> # if the Tree base is not the current one, updates the Tree base to >> the >>>> first game in filter : that way it is possible to >>>> # directly generate an opening report for example >>>> if {$baseNumber != [sc_base current] } { >>>> set current [sc_base current] >>>> sc_base switch $baseNumber >>>> if { [sc_filter first] != 0 } { >>>> sc_game load [sc_filter first] >>>> } >>>> sc_base switch $current >>>> >>>> >>>> Now if you do the following: >>>> * open two bases with trees >>>> * create a new game in one base, insert moves but do not save >>>> * switch to the other base and back. >>>> Your entered game is lost. >>>> >>>> The following replacement should prevent this. >>>> >>>> >>>> # if the Tree base is not the current one, updates the Tree base to >> the >>>> first game in filter : that way it is possible to >>>> # directly generate an opening report for example >>>> if {$baseNumber != [sc_base current] } { >>>> set current [sc_base current] >>>> sc_base switch $baseNumber >>>> if { [sc_filter first] != 0 } { >>>> if { [sc_game number] != 0 } { >>>> if { [sc_game altered] == 0 } { >>>> sc_game load [sc_filter first] >>>> } >>>> } >>>> } >>>> sc_base switch $current >>>> >>>> >>>> Somebody should check it and check it in. >>>> >>>> Gerd >>>> >>>> >>>> >>>> > ---------------------------------------------------------------------------- >>> -- >>>> Protect Your Site and Customers from Malware Attacks >>>> Learn about various malware tactics and how to avoid them. Understand >>>> malware threats, the impact they can have on your business, and how you >>>> can protect your company and customers by using code signing. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Scid-users mailing list >>>> Scid-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/scid-users >>>> >> > > ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
