f58a795de7219f98d9d103cc9eabac6205987827: Automated merge with ssh://hg.mozilla.org/labs/weave/
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 20:00:59 -0700 - rev 44576
Automated merge with ssh://hg.mozilla.org/labs/weave/
4326dcdfa91aac53bf026b03cf1037ee6e2dea8f: don't sync tab entry IDs, which change with every session, to avoid generating edit commands for every tab on restart even when the tabs haven't actually changed
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 20:00:48 -0700 - rev 44575
don't sync tab entry IDs, which change with every session, to avoid generating edit commands for every tab on restart even when the tabs haven't actually changed
406a0bcda3f1c7a57fdfee1560712c857be14db7: numChanged should be the number of shared items whose data is different, not the same
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 18:47:56 -0700 - rev 44574
numChanged should be the number of shared items whose data is different, not the same
228c32faf85877d113872f281d24bf55404ce46d: async.js now keeps track of how many outstanding callbacks it has and uses this information to log warnings about coroutines that may have yielded without an outstanding callback, and coroutines that may have finished while a callback is still outstanding. These are merely 'warnings' rather than certainties because this code assumes that there is a 1:1 correspondence between accesses to self.cb and yields, and also that self.cb's are actually passed to asynchronous functions. It'd be really cool if we could actually keep track of whether a callback got garbage collected before it was called or something, though I don't know how much it'd help in the end.
Atul Varma <varmaa@toolness.com> - Wed, 11 Jun 2008 19:19:16 -0700 - rev 44573
async.js now keeps track of how many outstanding callbacks it has and uses this information to log warnings about coroutines that may have yielded without an outstanding callback, and coroutines that may have finished while a callback is still outstanding. These are merely 'warnings' rather than certainties because this code assumes that there is a 1:1 correspondence between accesses to self.cb and yields, and also that self.cb's are actually passed to asynchronous functions. It'd be really cool if we could actually keep track of whether a callback got garbage collected before it was called or something, though I don't know how much it'd help in the end.
d40c427c60f1513dac8d80025ca72a4682cb5014: Added a few log messages to hopefully make the debugging of generators easier. Also added an id component to generators, which is part of their name, to help distinguish between concurrent instances of the same generator function. The following debug output represents the new logging infomation:
Atul Varma <varmaa@toolness.com> - Wed, 11 Jun 2008 18:58:30 -0700 - rev 44572
Added a few log messages to hopefully make the debugging of generators easier. Also added an id component to generators, which is part of their name, to help distinguish between concurrent instances of the same generator function. The following debug output represents the new logging infomation: -- Async.Generator DEBUG runTestGenerator-0: self.cb generated at test_async_missing_yield.js:28 Async.Generator DEBUG secondGen-1: self.cb generated at test_async_missing_yield.js:20 Async.Generator DEBUG secondGen-1: done() called. Async.Generator DEBUG runTestGenerator-0: self.cb() called, resuming coroutine. Async.Generator DEBUG runTestGenerator-0: done() called. Async.Generator DEBUG secondGen-1: self.cb() called, resuming coroutine. Async.Generator DEBUG secondGen-1: done() called. Async.Generator ERROR Async method 'secondGen-1' is missing a 'yield' call (or called done() after being finalized) -- As you can see, I've added log messages whenever the Generator's 'cb' property is accessed--this is almost guaranteed to be very close to a 'yield' statement, and therefore provides us with a decently accurate idea of where the generator 'stopped'. We also log a message when the generator continues, and by doing so we get an idea of how the coroutines interleave. Another idea I had was to actually match calls to self.cb with calls to 'yield' to automatically detect e.g. two yields in a row (which will ordinarily result in a generator 'hanging'), a generator exiting while a self.cb still hasn't been called, but I'm not sure what kinds of reprecussions it may have.
1b5e5f6e9aaf3bdb87e4b3a6245767b4dc97bc04: Merged changes.
Atul Varma <varmaa@toolness.com> - Wed, 11 Jun 2008 18:03:11 -0700 - rev 44571
Merged changes.
609d251eceee8e288dc5e19b7ad7dc2849a670be: Added test_async_missing_yield. It's very messy right now and duplicates code from other tests, but I've got some ideas about how to write better tests for async ops that I'll commit soon.
Atul Varma <varmaa@toolness.com> - Wed, 11 Jun 2008 18:02:46 -0700 - rev 44570
Added test_async_missing_yield. It's very messy right now and duplicates code from other tests, but I've got some ideas about how to write better tests for async ops that I'll commit soon.
4ebbe413a9e834d690420d3bf9548370fd750733: bug 438033: implement a better first-run wizard process; r=myk
Maria Emerson <memerson@mozilla.com> - Wed, 11 Jun 2008 17:56:02 -0700 - rev 44569
bug 438033: implement a better first-run wizard process; r=myk
00b792db0ec4f6e74610247b81ecafdc894a5a68: Automated merge with ssh://hg.mozilla.org/labs/weave/
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 17:45:54 -0700 - rev 44568
Automated merge with ssh://hg.mozilla.org/labs/weave/
2833874d56c7cb3541eeac7032d515e1e8903fca: bug 437529: yield after starting to put the status file to the server so we don't finalize the sync until the PUT request completes
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 17:44:08 -0700 - rev 44567
bug 437529: yield after starting to put the status file to the server so we don't finalize the sync until the PUT request completes
da23583ace58f8d87a22c1cc79bebd4b54fd0862: Modified test_async_exceptions to use a fake nsiTimer.
Atul Varma <varmaa@toolness.com> - Wed, 11 Jun 2008 17:10:39 -0700 - rev 44566
Modified test_async_exceptions to use a fake nsiTimer.
d55bf6de53c0a70616653f45723d67bfc42f6000: Added a unit test for async exceptions.
Atul Varma <varmaa@toolness.com> - Wed, 11 Jun 2008 16:38:22 -0700 - rev 44565
Added a unit test for async exceptions.
e7fbf52027b674de6d66ab0458e813bc2fdddea0: resetting the score is not an asynchronous operation, so Service::_syncEngine shouldn't yield after calling it
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 15:23:54 -0700 - rev 44564
resetting the score is not an asynchronous operation, so Service::_syncEngine shouldn't yield after calling it
1d394c2f36227fb6207209927abbacb86b63aa3e: clarify wording in scheduled sync threshold debug statements
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 14:16:03 -0700 - rev 44563
clarify wording in scheduled sync threshold debug statements
7e0a190690f8cd0388744523214a76d85dce8125: fix typo in recent checkin that broke appending deltas to the deltas file on the server
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 14:14:04 -0700 - rev 44562
fix typo in recent checkin that broke appending deltas to the deltas file on the server
9b7fd90e2772c8451a5a6d65342bc1b5211610c5: once sync thresholds reach 1 (the lowest possible value), leave them there until something changes and we sync
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 13:50:47 -0700 - rev 44561
once sync thresholds reach 1 (the lowest possible value), leave them there until something changes and we sync
a7e007dec05750faa89358f85eb1c97b10d3330a: merge
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 10:41:57 -0700 - rev 44560
merge
db8921a5fc7545da7e5c7240354e8ed9888f2599: bug 430363: ignore remove commands when generating deltas for history so the deltas file on the server doesn't grow too large; r=thunder
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 10:40:24 -0700 - rev 44559
bug 430363: ignore remove commands when generating deltas for history so the deltas file on the server doesn't grow too large; r=thunder
462694ef16919155991a335f3b7daac049086f8c: bug 434816: use a decreasing threshold algorithm for the periodic scheduled sync to make sure we eventually sync even small changes to data; r=thunder
Myk Melez <myk@mozilla.org> - Wed, 11 Jun 2008 10:38:25 -0700 - rev 44558
bug 434816: use a decreasing threshold algorithm for the periodic scheduled sync to make sure we eventually sync even small changes to data; r=thunder
7fdce26f3009df1f658ce0000ba55cd4cbc86020: merge upstream changes
Dan Mills <thunder@mozilla.com> - Wed, 11 Jun 2008 23:31:28 +0900 - rev 44557
merge upstream changes
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip