gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

I've a strange problem with my branch : I'm not able to reproduce any
error with a powerful laptop. Even -s bryce is loaded fine (just a bit
slow).

I've also discovered that optimizing the "delete" will vastly improve our
performances as, when applying a filter, we first remove all tasks then
readd them. (Perhaps there's a low hanging optimization there : only remove
tasks that are not displayed anymore with the new filter)

I'm thus only able to work on it from my slow computer.


It just feels weird : it is working...


Could you please test that dethreadization branch ?


Lionel


On Sun, 26 Sep 2010 14:35:28 -0700, Luca Invernizzi
<invernizzi.l@xxxxxxxxx> wrote:
> On Sat, Sep 25, 2010 at 8:54 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>> Hello,
>>
>> I've worked on the dethreadization branch and, so far, it looks
>> relatively good.
>>
>> I've worked on the filtered tree to ensure that we have atomic state
>> change with one state_commit = one signal (it's what gtk is expecting).
>> __add_node and __delete_node have been rewritten.
>>
>> There are a few places where I cannot do that and I'm printing a
warning
>> or raising an exception. (they are related to nodes with a parent
having
>> multiple paths).
>>
>>
>> Error that can arise are fairly easy to spot in the code :
>>
>> - A commit_state is not immediately followed by a callback
>> - A callback is not immediately preceded by a commit_state  (well, I
>> want to refactorize to put the callbacks in the commit_state method)
>> - After a commit_state, we reuse some values from before the commit
>> (like the tmp_nodes, the tmp_vr or any local variable)
>>
>>
>> Doing that work, I broke a bunch of tests in test_liblarch. Still 7
>> tests are still not passing (so it's low hanging fruit for those
wanting
>> to help). Also, the whole suite is crashing but I think it's not
related
>> to my work.
>>
>> (Oh, btw, Thread_protection has to be disabled in treemodel.py to be
>> able to run the tests. I don't know why)
>>
>> I'm not able to have any issue anymore with -s standard. There are
still
>> some threads race with -s bryce, showing that, somewhere, we might
>> access the gtk.TreeView with a thread that should not.
>>
>> The error is :
>> gtg: Fatal IO error 11 (Ressource temporairement non disponible) on X
>> server :0.0.
>>
>>
>> Lionel
>>
>> PS: as soon as all the tests are passing, I plan to merge that in
trunk.
>> Do you think it's a good idea ?
> It seems that the current state is already better than trunk. Anyway,
> you're the one who best understands the situation with liblarch, so
> the decision is up to you :)
> 
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~gtg-contributors
>> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~gtg-contributors
>> More help   : https://help.launchpad.net/ListHelp
>>