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.
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
