Re: Proposal for an inbound2 branch
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
repo are both appropriate versions of inbound and that i2 and
i2-push are the appropriate versions of inbound2 (you can create such
aliases in your .hgrc). They also assume that since inbound just closed
there is bustage on inbound that is not going to be present on inbound2
and that you have already pulled this bustage into your tree.
1) Make sure your patch-to-land is tracked by mq
2) hg qpop -a
3) hg strip roots(outgoing('i2'))
4) hg pull -u i2
5) hg qpush your patches
6) hg qfin -a hg push i2-push
Step 3 is slightly annoying because you have to quote the parens from
the shell
In any case, the upshot of the above steps is that after step 4 your
tree is effectively a clone of inbound2, and then you just push to it
normally.
If your patches are not tracked by mq and you don't want them to be thus
tracked then things are more complicated: as far as I can tell you want
to pull into the same tree from inbound2, transplant your patch on top
of the tip of inbound2, strip out the bits of inbound that shouldn't be
landing, then push.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: multiline pref value strings in user.js
On 4/27/2013 6:26 PM, al...@yahoo.com wrote: ... appear to be possible without the \ escape. In fact the \ can not be present as it does not escape the newline but becomes a part of the string. Once upon a time, prefs files were actually JS: we created a function pref and user_pref and then evaulated the file within the JS engine. This was slow, and so in 2003 we changed it to use a mostly-compatible parser that could consume the existing syntax of most pref.js files (bug 98533). The format is now whatever prefread.cpp accepts. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebAPI Meeting: Tuesday 30 April @ 10 AM Pacific [1]
Meeting Details: * Agenda: https://wiki.mozilla.org/WebAPI/2013-04-30 * WebAPI Vidyo room * Amoeba conf. room, San Francisco office (7A) * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US) * Join irc.mozilla.org #webapi for back channel Notes will be taken on etherpad: https://etherpad.mozilla.org/webapi-meetingnotes All are welcome! Andrew [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130430T10p1=224am=30 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
So there is no general 'good for performance' way of doing IO. However I think most people who need this need to write small bits of data and there is a good way to do that. Gregory Szorc wrote: I'd like to start a discussion about the state of storage in Gecko. Currently when you are writing a feature that needs to store data, you have roughly 3 choices: 1) Preferences 2) SQLite 3) Manual file I/O * How to robustly write/update small datasets? #3 above is it for small datasets. The correct way to do this is to write blobs of JSON to disk. End of discussion. Writes of data = ~64K should just be implemented as atomic whole-file read/write operations. Those are almost always single blocks on disk. Writing a whole file at once eliminates risk of data corruption. Incremental updates are what makes sqlite do the WAL/fsync/etc dance that causes much of the slowness. We invested a year worth of engineering effort into a pure-js IO library to facilitate efficient application-level IO. See OS.File docs, eg https://developer.mozilla.org/en-US/docs/JavaScript_OS.File/OS.File_for_the_main_thread As you can see from above examples, manual IO is not scary If one is into convenience APIs, one can create arbitrary json-storage abstractions in ~10lines of code. * What about writes 64K? Compression gives you 5-10x reduction of json. https://bugzilla.mozilla.org/show_bug.cgi?id=846410 Compression also means that your read-throughput is up to 5x better too. * What about fsync-less writes? Many log-type performance-sensitive data-storage operations are ok with lossy appends. By lossy I mean data will be lost if there is a power outage within a few seconds/minutes of write, consistency is still important. For this one should create a directory and write out log entries as checksummed individual files...but one should really use compression(and get checksums for free). https://bugzilla.mozilla.org/show_bug.cgi?id=846410 is about facilitating such an API. Use-cases here: telemetry saved-sessions, FHR session-statistics. * What about large datasets? These should be decided on a case-by-case basis. Universal solutions will always perform poorly in some dimension. * What about indexeddb? IDB is overkill for simple storage needs. It is a restrictive wrapper over an SQLite schema. Perhaps some large dataset (eg an addressbook) is a good fit for it. IDB supports filehandles to do raw IO, but that still requires sqlite to bootstrap, doesn't support compression, etc. IDB also makes sense as a transitional API for web due to the need to move away from DOM Local Storage... * Why isn't there a convenience API for all of the above recommendations? Because speculatively landing APIs that anticipate future consumers is risky, results in over-engineering and unpleasant surprises...So give us use-cases and we(ie Yoric) will make them efficient. Taras ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
- Original Message - On Apr 27, 9:37 am, Mounir Lamouri mou...@lamouri.fr wrote: Why? Wouldn't be the idea of such component to make sure it is usable from C++? Perhaps some day, but IndexedDB was always designed with JS in mind. To use it you pass special JS dictionaries for options, clone things to/from JS objects, etc. Using it from C++ is not a pleasant experience and requires lots of JSAPI. A WebIDL callback interface thing could probably be set up to make calling from C++ into JS less awful, if somebody has a need. Andrew We could implement a C++ API that reuses all the transactions and threading and such but so far no one has been breaking down our door asking for it. -bent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Increasing our Aurora and Nightly user populations?
(Sorry if this is not the right forum for this discussion.) To increase our testing populations, I'd like to suggest that we add a periodic channel upsell message to the about:home page (of Aurora and Beta) and the about box (of Aurora, Beta, and possibly Release). Beta and Aurora users have already opted in to a testing channel, so we know they are receptive to beta-quality software. If they have set Beta or Aurora as their default browser and/or have been using it consistently for a few weeks, we could try to upsell Beta users to Aurora and Aurora users to Nightly. We did something similar with Firefox for Android. After a certain number of browser launches, we display a one-time message suggesting they write a Google Play store review if they like Firefox or contact Firefox Support if they have problems. Similarly, users who check their browser's about box are clearly interested in version numbers or checking for the latest updates. These users might be receptive to a channel upsell message to get an even bigger version number. :) chris p. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increasing our Aurora and Nightly user populations?
What is the problem with current population size? We are not as small as Android on desktop channels :) Chris Peterson wrote: (Sorry if this is not the right forum for this discussion.) To increase our testing populations, I'd like to suggest that we add a periodic channel upsell message to the about:home page (of Aurora and Beta) and the about box (of Aurora, Beta, and possibly Release). Beta and Aurora users have already opted in to a testing channel, so we know they are receptive to beta-quality software. If they have set Beta or Aurora as their default browser and/or have been using it consistently for a few weeks, we could try to upsell Beta users to Aurora and Aurora users to Nightly. We did something similar with Firefox for Android. After a certain number of browser launches, we display a one-time message suggesting they write a Google Play store review if they like Firefox or contact Firefox Support if they have problems. Similarly, users who check their browser's about box are clearly interested in version numbers or checking for the latest updates. These users might be receptive to a channel upsell message to get an even bigger version number. :) chris p. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increasing our Aurora and Nightly user populations?
A lot of this has to do with population diversity (as opposed to size) and 3rd party plugins/add-ons only targeting Beta/Release. -Alex On Apr 29, 2013, at 12:26 PM, Kyle Huey m...@kylehuey.com wrote: On Mon, Apr 29, 2013 at 12:17 PM, Taras Glek tg...@mozilla.com wrote: What is the problem with current population size? We are not as small as Android on desktop channels :) We routinely see serious bugs first on Beta or Release ... - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increasing our Aurora and Nightly user populations?
On Apr 29, 2013, at 3:07 PM, Chris Peterson wrote: (Sorry if this is not the right forum for this discussion.) dev-planning feels right-er here - I suggest follow ups take it thattaway. J PS - original post, for dev-planning context: To increase our testing populations, I'd like to suggest that we add a periodic channel upsell message to the about:home page (of Aurora and Beta) and the about box (of Aurora, Beta, and possibly Release). Beta and Aurora users have already opted in to a testing channel, so we know they are receptive to beta-quality software. If they have set Beta or Aurora as their default browser and/or have been using it consistently for a few weeks, we could try to upsell Beta users to Aurora and Aurora users to Nightly. We did something similar with Firefox for Android. After a certain number of browser launches, we display a one-time message suggesting they write a Google Play store review if they like Firefox or contact Firefox Support if they have problems. Similarly, users who check their browser's about box are clearly interested in version numbers or checking for the latest updates. These users might be receptive to a channel upsell message to get an even bigger version number. :) --- Johnathan Nightingale VP Firefox Engineering @johnath ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DOM Bindings Meeting - Monday @ 12:30 PM PDT
On 4/29/13 11:05 AM, Kyle Huey wrote: Our (ostensibly) weekly DOM bindings meetings continue on Monday April 29th at 12:30 PM PDT. Per discussion of the meeting, here's a strawman plan for converting Window to WebIDL: https://etherpad.mozilla.org/WebIDL-Window Please add anything I missed that needs to happen there? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
Great post, Taras! Per IRC conversations, we'd like to move subsequent discussion of actions into a meeting so we can more quickly arrive at a resolution. Please meet in Gregory Szorc's Vidyo Room at 1400 PDT Tuesday, April 30. That's 2200 UTC. Apologies to the European and east coast crowds. If you'll miss it because it's too late, let me know and I'll consider moving it. https://v.mozilla.com/flex.html?roomdirect.htmlkey=yJWrGKmbSi6S On 4/29/13 10:51 AM, Taras Glek wrote: * How to robustly write/update small datasets? #3 above is it for small datasets. The correct way to do this is to write blobs of JSON to disk. End of discussion. Writes of data = ~64K should just be implemented as atomic whole-file read/write operations. Those are almost always single blocks on disk. Writing a whole file at once eliminates risk of data corruption. Incremental updates are what makes sqlite do the WAL/fsync/etc dance that causes much of the slowness. We invested a year worth of engineering effort into a pure-js IO library to facilitate efficient application-level IO. See OS.File docs, eg https://developer.mozilla.org/en-US/docs/JavaScript_OS.File/OS.File_for_the_main_thread As you can see from above examples, manual IO is not scary If one is into convenience APIs, one can create arbitrary json-storage abstractions in ~10lines of code. * What about writes 64K? Compression gives you 5-10x reduction of json. https://bugzilla.mozilla.org/show_bug.cgi?id=846410 Compression also means that your read-throughput is up to 5x better too. * What about fsync-less writes? Many log-type performance-sensitive data-storage operations are ok with lossy appends. By lossy I mean data will be lost if there is a power outage within a few seconds/minutes of write, consistency is still important. For this one should create a directory and write out log entries as checksummed individual files...but one should really use compression(and get checksums for free). https://bugzilla.mozilla.org/show_bug.cgi?id=846410 is about facilitating such an API. Use-cases here: telemetry saved-sessions, FHR session-statistics. * What about large datasets? These should be decided on a case-by-case basis. Universal solutions will always perform poorly in some dimension. * What about indexeddb? IDB is overkill for simple storage needs. It is a restrictive wrapper over an SQLite schema. Perhaps some large dataset (eg an addressbook) is a good fit for it. IDB supports filehandles to do raw IO, but that still requires sqlite to bootstrap, doesn't support compression, etc. IDB also makes sense as a transitional API for web due to the need to move away from DOM Local Storage... * Why isn't there a convenience API for all of the above recommendations? Because speculatively landing APIs that anticipate future consumers is risky, results in over-engineering and unpleasant surprises...So give us use-cases and we(ie Yoric) will make them efficient. Taras ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Increasing our Aurora and Nightly user populations?
Maybe another route to trial this would be to use our product announcements feature since it can be much more targeted. I would not be wholly comfortable at this point to use the snippet real estate (if I was reading the original request), especially for our GA audience. I also think we should think about the goal here - which I think would be to expand the volume numbers of each of these groups and not necessarily move current users to other products (although I do understand the rationale prompting this suggestion, generally around to lower friction level to try less stable software). If we are agreed on the above, perhaps it is also a discussion to get our marketing friendlies and contributor engagement folks with an objective to target and capture new users for these channels. Karen -Original Message- From: dev-planning-bounces+krudnitski=mozilla@lists.mozilla.org [mailto:dev-planning-bounces+krudnitski=mozilla@lists.mozilla.org] On Behalf Of Johnathan Nightingale Sent: 29 April 2013 15:32 To: Chris Peterson Cc: mozilla.dev.planning group; dev-platform@lists.mozilla.org Subject: Re: Increasing our Aurora and Nightly user populations? On Apr 29, 2013, at 3:07 PM, Chris Peterson wrote: (Sorry if this is not the right forum for this discussion.) dev-planning feels right-er here - I suggest follow ups take it thattaway. J PS - original post, for dev-planning context: To increase our testing populations, I'd like to suggest that we add a periodic channel upsell message to the about:home page (of Aurora and Beta) and the about box (of Aurora, Beta, and possibly Release). Beta and Aurora users have already opted in to a testing channel, so we know they are receptive to beta-quality software. If they have set Beta or Aurora as their default browser and/or have been using it consistently for a few weeks, we could try to upsell Beta users to Aurora and Aurora users to Nightly. We did something similar with Firefox for Android. After a certain number of browser launches, we display a one-time message suggesting they write a Google Play store review if they like Firefox or contact Firefox Support if they have problems. Similarly, users who check their browser's about box are clearly interested in version numbers or checking for the latest updates. These users might be receptive to a channel upsell message to get an even bigger version number. :) --- Johnathan Nightingale VP Firefox Engineering @johnath ___ dev-planning mailing list dev-plann...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fallibility of NS_DispatchTo[Current|Main]Thread
On Tue, Apr 30, 2013 at 5:32 AM, Kyle Huey m...@kylehuey.com wrote: Is it feasible to make these functions infallible? What work would need to be done? Off the top of my head, I think it probably is feasible. IIRC XPCOM event dispatch can fail for two reasons: OOM, and when the thread has been shut down. We can die on OOM. DispatchToCurrentThread obviously shouldn't happen when that thread has shut down. DispatchToMainThread shouldn't happen after the main thread has shut down either ... I suppose it could due to a bug, but we could just die. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
