[10:49] * danilos -> lunch [12:29] bac benji danilos (gmb sick :-( ): call in 2 [12:38] g*ry: RT is 48196 [12:48] bac is fighting irc problems, he'll be unavailable on IRC while that's going on [12:50] danilos, thanks for update on bac. I need to take kids to school today, so I will be a bit late. Will 20 minutes past the hour still work for you, or should we reschedule? [12:57] gary_poster, that's fine [13:18] thanks danilos. ready any time [13:24] gary_poster, hey, still not used to non-existent notifications :) [13:24] heh [13:57] benji, when would you like a call this morning? Any time is good for me. [13:58] gary_poster: sure; how about now? [13:58] benji, a fine idea. Gimme a call! [14:02] hi danilos [14:03] danilos: the original failing test is bugs/doc/bugtask.txt at line 335. the scenario presented there is the one i've tried to recreate in the unit test. [14:12] bac, right, let me take a look at as well [14:25] bac, hum, right, I think I see the point now [14:25] ok [14:26] danilos: my understanding of conjoinedness is not deep, so i don't deny that i may have gotten them backwards but the doctest regression looks real [14:28] btw, anyone have an idea how long fsck should take on a 1TB disk? [14:34] bac, yeah, it all seems right, in this special case when a master is being created after slave, it copies stuff from slave back to master [14:36] bac, so, I think the problem is the storm validator: createTask creates a task with status set to NEW, which calls on the storm validator for status field, which changes the slave version back to the just-created master version [14:37] danilos: yes, i was looking at that...before my server died [14:39] danilos: but none of that code has changed... [14:43] bac, well, at least the column is being renamed from status to _status :) [14:44] danilos: yeah, there is that... [14:48] bac, fwiw, I can also see arbitrary SQL queries using ._status and others using .status which kind of confuses me [14:49] that could be storm vs sqlobject stuff, but just very confusing === bac`` is now known as bac [15:12] bac, so, I could confirm that the NEW status is set by the validator, and what's else validate_status is called 9 times now, whereas stable did it 7 times for the same test (your earlier one) [15:13] bac, fwiw, doctest does seem to break with all those _status usages in plain-text SQL queries (as I expected) when validator is removed, so it seems the branch was more unfinished then you hoped for :) [15:14] danilos: yeah, that's my fear. fix this blocking problem only to find a ton more [15:41] bac, ok, so the problem is that on stable, self.bug in validator is not set, yet in this branch it is [15:43] bac, basically, it seems that bug gets flushed earlier with all the changes [16:10] I'm going away now. I suspect I'll keep meditating upon the visions of Python regexes which parse Perl regexes that are swirling around in my head though. [16:26] danilos: ah, interesting [16:44] bac, I actually dislike the extension to enum columns lifeless did, I find code that mixes two different DBEnums for a single value very confusing :/ [16:44] danilos: how would you do it? [16:45] bac, usual class inheritance, like we do it everywhere else [16:47] (we can't have one class that derives from two DBEnumeratedTypes though, but we can have non-dbenum classes as base combining classes) [17:12] lunch [17:42] * danilos -> off, tty tomorrow [18:26] hi gary_poster, i think (with danilos' help) i now understand what is going on...but i need to discuss it [18:27] bac, ok, cool. now is fine, or later [18:27] gary_poster: now would be good [18:27] we can segue into our weekly call if you want [18:27] cool [18:28] call me when ready bac [18:49] gary i'll resume our call in a sec [18:50] bac ok, I'm back [18:54] me too