| 00:00.44 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 03:35.59 | *** join/#storm nullie (n=ilya@87.254.139.66) |
| 05:43.31 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 08:32.15 | *** join/#storm mcella (n=mcella@ip-178-137.sn2.eutelia.it) |
| 11:05.04 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 11:06.17 | *** join/#storm niemeyer (n=niemeyer@200-138-40-171.ctame705.dsl.brasiltelecom.net.br) |
| 11:33.41 | niemeyer | Mornings! |
| 11:33.49 | niemeyer | jamesh: Nice idea on the SQlite pragma |
| 11:41.57 | jamesh | niemeyer: does the reference leak I found in cextensions sound problematic? |
| 11:42.34 | jamesh | niemeyer: in the test suite, it was only leaking references to Undef, since the only caller was Variable.copy -> Variable.set_state |
| 11:42.47 | jamesh | and the new variable had _value and _lazy_value set to Undef |
| 11:43.50 | niemeyer | jamesh: Yes, it does sound bad |
| 11:44.14 | niemeyer | jamesh: It will leak values on commit |
| 11:44.27 | niemeyer | jamesh: Because the value is replaced by AutoReload, which is lazy |
| 11:44.47 | jamesh | niemeyer: right, but is that doing set_state()? |
| 11:44.50 | niemeyer | Hmm.. or maybe not.. let me check this out more carefully |
| 11:45.30 | jamesh | a cursory look only showed Variable.copy() as being affected, but I might have missed something |
| 11:46.08 | jamesh | anyway, I think it is time to land the branch |
| 11:47.06 | niemeyer | jamesh: It seems worse than that indeed |
| 11:47.57 | niemeyer | jamesh: Oh, wait.. I guess I'm confusing with checkpoint_state |
| 11:48.09 | niemeyer | jamesh: yeah, doesn't look too bad.. |
| 11:48.29 | niemeyer | jamesh: I was just reviewing it.. I'll land it with cextensions now |
| 11:48.33 | niemeyer | jamesh: Thanks for the fixes |
| 11:54.33 | weatherman | storm/need-for-speed-revenge r259 committed by gustavo@niemeyer.net |
| 11:54.33 | weatherman | Merging fix for reference leak and C89-related changes, |
| 11:54.33 | weatherman | provided by James. |
| 11:56.52 | jamesh | niemeyer: thanks. I've updated my sqlobject-contains branch to do BoundReferenceSet.__contains__ too, so it should be mostly complete (other than not handling set expressions on sqlite and mysql) |
| 11:57.17 | niemeyer | jamesh: Btw, we've fixed a race yesterday that may cause the initialization code to blow up if a ClassInfo is initialized at the same time by two different threads |
| 11:57.31 | jamesh | okay |
| 11:58.11 | niemeyer | jamesh: Do you think it's ready for landed? We'll try to do some review rounds today and get some of the pending branches merged |
| 11:58.16 | niemeyer | s/for landed/for landing/ |
| 11:58.19 | niemeyer | jbot: Pst! |
| 12:05.25 | weatherman | storm/trunk r245 committed by gustavo@niemeyer.net |
| 12:05.25 | weatherman | Merging need-for-speed-revenge branch [a=niemeyer,jamesh,radix] |
| 12:05.25 | weatherman | [r=jamesh,therve] |
| 12:05.33 | weatherman | This branch introduces a number of fixes, optimizations, and extensions |
| 12:05.37 | weatherman | on the cextensions module, with speedup purposes. The module is now |
| 12:05.41 | weatherman | built by default, but still disabled unless the STORM_CEXTENSIONS=1 |
| 12:05.45 | weatherman | environment variable is defined. |
| 12:05.53 | weatherman | Besides these, Chris also provided a mechanism to cache ClassAliases, |
| 12:05.57 | weatherman | to prevent the cost of rebuilding the ClassInfo for each alias. |
| 12:10.17 | jkakar | YAYAYAYAY! |
| 12:12.46 | weatherman | storm/trunk r246 committed by gustavo@niemeyer.net |
| 12:12.46 | weatherman | Updated NEWS file. |
| 12:13.22 | jkakar | niemeyer: I'd like to prepare a Storm release at the end of next week, when I'm home again. |
| 12:18.46 | niemeyer | jkakar: Woot! |
| 12:18.55 | niemeyer | jkakar: We have quite a lot of stuff for that release |
| 12:19.04 | jkakar | niemeyer: Yes! |
| 12:19.21 | jkakar | niemeyer: I'd also like to provide Storm Team PPA packages as part of this release, which I'm excited about. |
| 12:20.55 | niemeyer | jkakar: Nice! I guess it will also start to make more sense now, since we have platform-specific code |
| 12:23.25 | jkakar | niemeyer: True. |
| 13:14.26 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 14:03.23 | jamesh | niemeyer: sorry, was away. I think the sqlobject-contains branch is ready to be merged |
| 14:17.14 | niemeyer | jamesh: I was just updating the branch to review it.. radix also said he'd check some of the branches out once he gets some rest from Landscape |
| 14:17.44 | jamesh | niemeyer: okay. The slots one is the other that we're running on LP currently |
| 14:18.06 | jamesh | niemeyer: if you haven't noticed, edge.launchpad.net is running on Storm |
| 14:18.51 | jamesh | the sqlobject-contains branch fixed the remaining problems |
| 14:19.51 | niemeyer | jamesh: Oh yeah, I've noticed! It's truly awesome. Thanks a lot for the great work there |
| 14:20.06 | jamesh | [this also means that a few updates to the code review pages are now live too] |
| 14:20.14 | niemeyer | jamesh: How does it compare to the old code base now? Do you have any idea? |
| 14:21.56 | jamesh | niemeyer: again, it is a bit difficult to make a judgement at this point |
| 14:22.08 | jamesh | niemeyer: we should have a better idea as OOPS reports filter in |
| 14:22.31 | jamesh | I believe Storm is a bit heavier than SQLObject on the Python side, but that may change a bit as we change our code |
| 14:22.35 | niemeyer | jamesh: I was mostly wondering about these performance tests you've done earlier, with some numbers |
| 14:23.25 | jamesh | niemeyer: I'll try and get another report similar to the spreadsheet done |
| 14:23.51 | jamesh | that should give an overall idea of the change since we switched |
| 14:24.03 | jamesh | it won't be isolated from code changes though |
| 14:25.52 | niemeyer | jamesh: Understood, thanks for taking the time |
| 14:51.17 | niemeyer | jamesh: Hey, do you have a handy pointer to that script you use over the svn2bzr result to migrate tags? |
| 14:51.53 | jamesh | niemeyer: http://people.ubuntu.com/~jamesh/add-tags.py |
| 14:52.02 | niemeyer | jamesh: Awesome, thanks! |
| 14:56.07 | jamesh | niemeyer: feel free to include it with svn2bzr if you think it is useful |
| 15:59.35 | niemeyer | jamesh: Thanks! I think it makes sense before we make svn2bzr work on itself |
| 16:07.46 | niemeyer | jamesh: Supporting ResultSet.__contains__() is truly awesome |
| 16:34.33 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 16:44.50 | radix | + # XXX 2008-06-24 jamesh: |
| 16:44.50 | radix | + # SQLite appears to not support the SQL we generate for this |
| 16:44.58 | radix | this doesn't cause a regression in sqlite support, does it? |
| 16:49.33 | niemeyer | radix: Not really.. it means that __contains__() doesn't work in some edge cases with non-postgres dbs |
| 16:49.48 | radix | niemeyer: right, but "in" would previously use __iter__, is my point |
| 16:49.58 | radix | niemeyer: is this something that would work with __iter__ but not the new __contains__? |
| 16:50.11 | niemeyer | therve: I've added a styling related comment to #233946, but it's not a blocker overall.. I think the branch is ready for merging |
| 16:51.04 | niemeyer | radix: Good point.. possibly |
| 16:51.38 | niemeyer | radix: I guess we could fallback, but it sounds a bit like a dangerous feature |
| 16:51.49 | radix | niemeyer: what sounds dangerous? |
| 16:52.04 | niemeyer | E.g. people might expect it to be a very fast operation and find out that huge requests are being made to get all rows |
| 16:52.14 | niemeyer | (which is what was happening in Launchpad for the general case) |
| 16:52.58 | radix | niemeyer: yeah, but that's already the behavior |
| 16:53.15 | radix | niemeyer: if we're going to improve it some cases, let's improve it in those cases, and avoid breaking existing applications |
| 16:53.18 | niemeyer | radix: That's the behavior now, but I'm not sure I understand your suggestion |
| 16:53.52 | radix | I haven't figured it out entirely, I just don't want to break existing applications |
| 16:53.55 | niemeyer | radix: I mean, I'd rather see it breaking than having Storm select a very large number of objects on a test for containment |
| 16:54.15 | niemeyer | radix: The edge cases are unlikely to be used at this point as well.. it's just on set expressions |
| 16:54.33 | radix | niemeyer: given that it was already a public API, I disagree strongly |
| 16:54.35 | niemeyer | radix: E.g. item in store.find(...).union(store.find(...)) |
| 16:55.08 | radix | it's really simple: something worked before. with this change (as I understand it), it'll break now in some cases, or become faster in others |
| 16:55.19 | radix | instead, we should have it maintain the existing behavior, or be faster in the cases where we can make it so |
| 16:55.57 | niemeyer | radix: Okay.. I'd consider the previous behavior as "broken" in a certain way, as we've seen in Launchpad, but I see your point |
| 16:56.34 | niemeyer | radix: Please bring the issue up in a comment on the bug, so that we can include jamesh in the loop |
| 16:56.40 | niemeyer | s/bug/merge proposal |
| 16:56.47 | radix | ok |
| 16:56.51 | jkakar | Perhaps a nice way to deal with this is to put the old functionality back in with a deprecation warning and then subsequently remove it. |
| 16:57.05 | niemeyer | jkakar: That sounds sensible |
| 16:57.10 | jkakar | (or even better, replace it with an equivalent better implementation) |
| 16:57.33 | niemeyer | jkakar: It seems to be a limitation on the engine somehow.. I haven't investigated it myself, though |
| 16:57.58 | jkakar | niemeyer: Nor have I. |
| 16:58.20 | niemeyer | (it sounds like it should be possible to use union and friends on subselects, but the gods of SQL engines move in mysterious ways) |
| 16:59.57 | jkakar | Hehehe |
| 17:05.16 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 17:09.41 | jkakar | I;m here |
| 17:09.48 | jkakar | I said 'YAY' when you said edgy was dead. |
| 17:10.24 | jkakar | 10s delay. :) |
| 17:11.00 | jkakar | Cool. |
| 17:11.49 | *** join/#storm nullguid (n=ilya@217.118.83.1) |
| 18:00.48 | weatherman | storm/resultset-groupby-2 r295 committed by thomas@canonical.com |
| 18:00.48 | weatherman | Reformat test statements using local variables. |
| 18:03.14 | *** join/#storm oubiwann (n=oubiwann@97-119-4-118.omah.qwest.net) |
| 18:04.43 | *** join/#storm thumper_laptop (n=tim@125-236-193-95.adsl.xtra.co.nz) |
| 18:32.41 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 18:55.39 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 19:06.54 | kov | niemeyer: hey, think you might have some time to take a quick look at lp#127176? |
| 19:14.42 | niemeyer | kov: Hey |
| 19:14.45 | niemeyer | kov: Sure |
| 19:16.32 | niemeyer | kov: So how does your implementation compare to the original branch? |
| 19:17.09 | niemeyer | kov: Would you be willing to take a more careful look at the existing one and build a single branch with the best ideas from either? |
| 19:17.40 | niemeyer | kov: I'm all for adding Orcale support, overall |
| 19:18.10 | kov | niemeyer: sure thing |
| 19:18.53 | kov | niemeyer: do you have any preference between DCOracle2 and cx_Oracle, btw? |
| 19:19.37 | niemeyer | kov: Not really.. I don't understand the differences or why there are two different modules, as I've never dealt with Oracle. I'd appreciate your feedback on it |
| 19:20.33 | kov | niemeyer: tell you the truth, neither do I, but since I've had some problems with cx_Oracle, I'll try DCOracle2 and if they're gone I'll stick with it, in this case |
| 19:21.02 | niemeyer | kov: Sounds like a good plan |
| 19:21.24 | niemeyer | kov: Might be interesting to discover if either of them has poor upstream support too |
| 19:21.42 | niemeyer | kov: Of course, existence of long term issues would already be one indication about it |
| 19:21.54 | kov | cool, I'll check on that |
| 19:22.01 | niemeyer | kov: Awesome, thank you! |
| 19:22.32 | kov | I know Oracle itself points python users to cx_Oracle, but I'm not sure they are aware of DCOracle2, and this later one was done to work with Zope, so it might be interesting from a Storm POV |
| 19:23.11 | kov | ok, so I'll try to have something by tomorrow, and I'll poke you to review it then =), thanks! |
| 19:30.26 | niemeyer | kov: The relationship with Zope isn't so important in this case |
| 19:31.31 | niemeyer | kov: I mean, we should pick whatever seems best.. Storm's zope support doesn't depend on the backends |
| 19:42.32 | radix | niemeyer: thanks for the comment |
| 19:42.53 | radix | niemeyer: after I finish reviews, I'll try to implement the fallback + warning stuff |
| 19:44.15 | niemeyer | radix: No problem.. it's great to have someone who is really careful about backwards compatibility on board |
| 19:45.26 | niemeyer | radix: I can see how that might bother people, specially on the tuple stuff |
| 19:45.42 | niemeyer | radix: (the other case seems a bit more unusual, even though still an issue) |
| 19:47.40 | radix | sure |
| 23:17.17 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 23:54.19 | *** join/#storm jkakar (n=jkakar@78.148.53.23) |