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 <[email protected]> wrote: > On Sat, Sep 25, 2010 at 8:54 AM, Lionel Dricot <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~gtg-contributors >> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
