Re: Detection of unlabeled UTF-8
Adam Roach a écrit : when you look at that document, tell me what you think the parenthetical phrase after the author's name is supposed to look like -- because I can guarantee that Firefox isn't doing the right thing here. In my case it does and displays : Хизер Фланаган I have the universal charset detector activated. The simple thing Firefox could do is to interpret "text/plain" and "text/plain;charset=us-ascii" as UTF-8 by default. In the first case, handling of non ascii character is undefined, and in the second they should be illegal. So in these two cases, UTF-8 can not break anything that is supposed to work. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing Brotli - an alternative to LZMA
On Wed, Sep 11, 2013 at 06:49:58AM +0100, Jonathan Kew wrote: > However, several concerns regarding LZMA (lack of formal > specification combined with complexity of the code, making careful > security review and maintenance difficult; relatively slow > decompression) Another problem with LZMA is the amount of memory it requires for decompression. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing Brotli - an alternative to LZMA
On 2013-09-11, at 5:55 AM, Mike Hommey wrote: > On Wed, Sep 11, 2013 at 06:49:58AM +0100, Jonathan Kew wrote: >> However, several concerns regarding LZMA (lack of formal >> specification combined with complexity of the code, making careful >> security review and maintenance difficult; relatively slow >> decompression) > > Another problem with LZMA is the amount of memory it requires for > decompression. Are you sure? http://www.7-zip.org/sdk.html claims "Small memory requirements for decompression: 8-32 KB + DictionarySize " This seems similar to what Flate requires. Brotli increases the window size and thus memory requirement to 4MB which is quite a bit. It's also larger than the cache size on mobile devices which is currently around 1MB so it would be interesting to see decompression speeds on small cache devices. Brotli seems to have similar design to OodleLZHLW (http://www.radgametools.com/oodlecompressors.htm) it would of course be interesting to know how it competes. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing Brotli - an alternative to LZMA
On 11/9/13 14:12, Jeff Muizelaar wrote: Brotli increases the window size and thus memory requirement to 4MB which is quite a bit. It's also larger than the cache size on mobile devices which is currently around 1MB so it would be interesting to see decompression speeds on small cache devices. That's an interesting point, which we should certainly raise with the developers. Brotli seems to have similar design to OodleLZHLW (http://www.radgametools.com/oodlecompressors.htm) it would of course be interesting to know how it competes. It would, although that looks like a commercial product and thus not something we could adopt as part of the open Web platform, even if it appears to have particularly desirable performance. Thanks, JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing Brotli - an alternative to LZMA
On Wed, Sep 11, 2013 at 09:12:53AM -0400, Jeff Muizelaar wrote: > > On 2013-09-11, at 5:55 AM, Mike Hommey wrote: > > > On Wed, Sep 11, 2013 at 06:49:58AM +0100, Jonathan Kew wrote: > >> However, several concerns regarding LZMA (lack of formal > >> specification combined with complexity of the code, making careful > >> security review and maintenance difficult; relatively slow > >> decompression) > > > > Another problem with LZMA is the amount of memory it requires for > > decompression. > > Are you sure? http://www.7-zip.org/sdk.html claims "Small memory > requirements for decompression: 8-32 KB + DictionarySize " This seems > similar to what Flate requires. DictionarySize is usually large. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing Brotli - an alternative to LZMA
On 2013-09-11, at 9:43 AM, Jonathan Kew wrote: > On 11/9/13 14:12, Jeff Muizelaar wrote: > >> Brotli increases the window size and thus memory requirement to 4MB >> which is quite a bit. It's also larger than the cache size on mobile >> devices which is currently around 1MB so it would be interesting to >> see decompression speeds on small cache devices. > > That's an interesting point, which we should certainly raise with the > developers. > >> Brotli seems to have similar design to OodleLZHLW >> (http://www.radgametools.com/oodlecompressors.htm) it would of course >> be interesting to know how it competes. > > It would, although that looks like a commercial product and thus not > something we could adopt as part of the open Web platform, even if it appears > to have particularly desirable performance Certainly. I just mean that it's important to compare Brotli against compression schemes that are targeted at the same design space to see how well it compares against it's real competition. Another candidate for comparison is LZHAM which is basically LZMA using huffman coding instead of range coding. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New Promise Constructor
Hi all,
I just want to inform that I'm landing a patch that changes the DOM Promise
constructor.
DOM Promise is disabled by pref but I know that there are a few existing pieces
of code that already use them.
The old constructor was based the PromiseResolver object.
Now we get rid of this object and the new constructor works in this way:
callback PromiseInit = void (object resolve, object reject);
[Constructor(PromiseInit init)]
interface Promise {...}
Best Regards,
Andrea
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript Style Guide. Emacs mode line.
Thus Spoke ishikawa: > On (2013年09月10日 00:08), Scott Johnson wrote: >> Thus Spoke ishikawa: >> >> So you are suggesting something like >> step 1 - request for formatting a file indented in an arcane format, i.e., >> reformat it according to the currently adopted code. Exactly what I meant, if by "request for formatting a file.." means "create a bugzilla bug for this refactoring/restyling", mainly so that we can trace it back if need be. >> step 2 - then after the re-formating of the file is done, >>particular bug or something is fixed in the newly formatted code. Yep, exactly. Basically, what I'm getting at here is that we should separate functional changes from purely stylistic changes. >> >> I understand the merit of leaving the code as is since hg blame won't work >> nicely with such file-wide format change as in step-1. >> (Or maybe we can teach hg blame to ignore such change, etc. but maybe too >> much work: the idea would be to mark formatting change with a particular >> string [maybe tag name] and let hg blame to ignore such tag to look for a >> previous patch that touched each line. Hmm. Maybe too much work indeed) It would be really nice if we could somehow teach hg blame to ignore style changes, but I think that's probably a very involved task. ;) >> OTOH, code in a strange indentation is hard to touch: during linux >> development around 2.1.1xx, Alan Cox got tired of the spaghetti code of SCSI >> driver subsystem and introduced a revision: that revision consisted only of >> sweeping reformatting of scsi subsystem files. No change except for >> re-formatting. >> It was felt the code could not be improved upon any more without such >> re-formatting. Yes, I guess I can agree with this sentiment. I would argue, though, that refactoring (things that make the code clearer, but actually can have an effect on the underlying code and how it runs) is different from restyling (changing whitespace/indentation, or things that may change the way the code looks, but not the underlying compiled code). ~Scott ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New Promise Constructor
On 9/11/13 2:13 PM, Marcos Caceres wrote:
callback PromiseInit = void (object resolve, object reject);
[Constructor(PromiseInit init)]
interface Promise {...}
What members does PromiseInit dictionary have? ^_^
It's not a dictionary. It's a callback, like the IDL snippet above says.
So you'd do it like so in practice:
var p = new Promise(function(resolve, reject) {
// do stuff here.
});
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: New Promise Constructor
On 11/09/2013, at 6:11 PM, Andrea Marchesini wrote:
> Hi all,
>
> I just want to inform that I'm landing a patch that changes the DOM Promise
> constructor.
> DOM Promise is disabled by pref but I know that there are a few existing
> pieces of code that already use them.
>
> The old constructor was based the PromiseResolver object.
> Now we get rid of this object and the new constructor works in this way:
>
> callback PromiseInit = void (object resolve, object reject);
> [Constructor(PromiseInit init)]
> interface Promise {...}
>
What members does PromiseInit dictionary have? ^_^
> Best Regards,
> Andrea
>
>
> ___
> 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: New Promise Constructor
On 11/09/2013, at 8:18 PM, Boris Zbarsky wrote:
> On 9/11/13 2:13 PM, Marcos Caceres wrote:
>>> callback PromiseInit = void (object resolve, object reject);
>>> [Constructor(PromiseInit init)]
>>> interface Promise {...}
>>
>> What members does PromiseInit dictionary have? ^_^
>
> It's not a dictionary. It's a callback, like the IDL snippet above says.
>
> So you'd do it like so in practice:
>
> var p = new Promise(function(resolve, reject) {
>// do stuff here.
> });
Ah, right! got confused as almost everything else in the platform with *Init is
a dictionary. Maybe that should be renamed PromiseCallback.
>
> -Boris
> ___
> 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
Tegra build backlog is too big!
Earlier today the backlog on Android build jobs was on the order of 1300. It seems to be coming down a little now but for a while there I was worried it was going to grow unboundedly. Try jobs from over 10 hours ago still have pending jobs - as I'm sure you all know, having a 10-hour turnaround on try pushes is something of a productivity killer. I brought this up in #releng and one of the proposed solutions was to try to tweak the prioritization of jobs between Try and Inbound a little bit. I personally do like that Inbound jobs are prioritized above Try, but perhaps they don't need to be prioritized quite so much. However, changing this will affect a number of people, so it was suggested I bring the discussion here to get other people's comments. So, anybody have thoughts on a good way to solve this problem? Cheers, kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tegra build backlog is too big!
Do we know why it's that much backed up? I started noticing it yesterday. Is it because of lots of inbound pushes? lots of try pushes? Lots of clobbering? Lots of tests? Jim On 9/11/13 5:31 PM, Kartikaya Gupta wrote: > Earlier today the backlog on Android build jobs was on the > order of 1300. It seems to be coming down a little now but > for a while there I was worried it was going to grow > unboundedly. Try jobs from over 10 hours ago still have > pending jobs - as I'm sure you all know, having a 10-hour > turnaround on try pushes is something of a productivity killer. > > I brought this up in #releng and one of the proposed > solutions was to try to tweak the prioritization of jobs > between Try and Inbound a little bit. I personally do like > that Inbound jobs are prioritized above Try, but perhaps > they don't need to be prioritized quite so much. However, > changing this will affect a number of people, so it was > suggested I bring the discussion here to get other people's > comments. > > So, anybody have thoughts on a good way to solve this problem? > > Cheers, > kats > ___ > 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: Tegra build backlog is too big!
quite possibly we don't need all those jobs running on tegras. I don't know of a bug in the product that has broken on either the tegra or panda platform but not the other. Joel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tegra build backlog is too big!
On Wed, Sep 11, 2013 at 04:39:37PM -0700, jmaher wrote: > quite possibly we don't need all those jobs running on tegras. I > don't know of a bug in the product that has broken on either the tegra > or panda platform but not the other. Off the top of my head: - I have broken one but not the other on several occasions, involving differences in the handling of instruction and data caches, but unless you're touching the linker or the jit, it shouldn't matter. - Tegras don't have neon instructions, so wrong build flags, or wrong run time detection could trigger failures on one end and not the other. - GPUs on tegras and pandas, as well as their supporting libraries, differ, too. But unless you are touching graphics code, that shouldn't matter, unless your changes trigger some pre-existing bug.. So, while chances of breaking one and not the other are slim, they do exist. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tegra build backlog is too big!
Fixing bugs like bug 884972 would probably help quite a bit. Also posting patches with checkin info and marking the bug with checkin-needed so the work lands with other patches. I always try to do this with simple front end patches. Jim "Kartikaya Gupta" wrote in message news:... > Earlier today the backlog on Android build jobs was on the order of > 1300. It seems to be coming down a little now but for a while there I > was worried it was going to grow unboundedly. Try jobs from over 10 > hours ago still have pending jobs - as I'm sure you all know, having a > 10-hour turnaround on try pushes is something of a productivity killer. > > I brought this up in #releng and one of the proposed solutions was to > try to tweak the prioritization of jobs between Try and Inbound a little > bit. I personally do like that Inbound jobs are prioritized above Try, > but perhaps they don't need to be prioritized quite so much. However, > changing this will affect a number of people, so it was suggested I > bring the discussion here to get other people's comments. > > So, anybody have thoughts on a good way to solve this problem? > > Cheers, > kats > ___ > 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: Tegra build backlog is too big!
AFAIK an unusually high load of try pushes. On 13-09-11 17:47 , Jim Chen wrote: Do we know why it's that much backed up? I started noticing it yesterday. Is it because of lots of inbound pushes? lots of try pushes? Lots of clobbering? Lots of tests? Jim On 9/11/13 5:31 PM, Kartikaya Gupta wrote: Earlier today the backlog on Android build jobs was on the order of 1300. It seems to be coming down a little now but for a while there I was worried it was going to grow unboundedly. Try jobs from over 10 hours ago still have pending jobs - as I'm sure you all know, having a 10-hour turnaround on try pushes is something of a productivity killer. I brought this up in #releng and one of the proposed solutions was to try to tweak the prioritization of jobs between Try and Inbound a little bit. I personally do like that Inbound jobs are prioritized above Try, but perhaps they don't need to be prioritized quite so much. However, changing this will affect a number of people, so it was suggested I bring the discussion here to get other people's comments. So, anybody have thoughts on a good way to solve this problem? Cheers, kats ___ 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: Tegra build backlog is too big!
2013/9/11 Mike Hommey > On Wed, Sep 11, 2013 at 04:39:37PM -0700, jmaher wrote: > > quite possibly we don't need all those jobs running on tegras. I > > don't know of a bug in the product that has broken on either the tegra > > or panda platform but not the other. > > Off the top of my head: > > - I have broken one but not the other on several occasions, involving > differences in the handling of instruction and data caches, but unless > you're touching the linker or the jit, it shouldn't matter. > > - Tegras don't have neon instructions, so wrong build flags, or wrong run > time detection could trigger failures on one end and not the other. > > - GPUs on tegras and pandas, as well as their supporting libraries, > differ, too. But unless you are touching graphics code, that shouldn't > matter, unless your changes trigger some pre-existing bug.. > And Panda boards have 1G of RAM, which is more than the Tegra boards have, right? Surely that can help avoiding OOM problems on Pandas. At some point earlier this year, WebGL conformance tests were perma-orange on Tegras but only intermittently orange on Pandas. RAM differences were likely the cause, as WebGL tests were OOM'ing a lot. Benoit > > So, while chances of breaking one and not the other are slim, they do > exist. > > Mike > ___ > 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: Tegra build backlog is too big!
hi kats (cross-posting to dev-b2g); tl:dr; we think all is ok again, details below. To avoid this happening again this week, we're changing tryserver to reduce the number of Android-tests-run-on-tegra-by-default. If you specifically want tegra testing on tryserver, you will need to state that when pushing to try. Yes, load on try was unusually heavy today (the b2g workweek is in full force). All other platforms, including our pool of panda Android4 test boards were handling this heavy load just fine. However, our pool of tegra boards is small (hard to get boards), had more-then-usual percentage offline, and was not able to keep up. We were distracted by an unrelated 64bit windows problem, but thats no excuse, we should have detected this earlier. After this is all calm, we'll postmortem. 1) As of earlier this afternoon, 976 of the pending 1078 tegra jobs are from try. This was no single "abuse of try", this was simply an accumulation of a lot of pushes-to-try spread across the day. 2) We manually repoked every one of the offline tegras, and most are now working correctly again. As of now, our tegra pool is much healthier size again, back up to as-good-as-we-can-hope-for-with-poolsize, and quickly chewing through the remaining backlog. At this time, we are down to 240 pending jobs, and dropping fast. http://builddata.pub.build.mozilla.org/reports/pending/pending.html Details in https://bugzilla.mozilla.org/show_bug.cgi?id=915457 "Triage tegras with no completed jobs within last 24 hours" 3) We cancelled all pending tegra test jobs on try that were waiting over 6 hours (the longest was 10hours). Note: we did not cancel panda test jobs, and we did not cancel tegra test jobs on other branches. If we cancelled a tegra test job on try that you do still need run, please let us know in #releng, and we'll sort it out. Details in https://bugzilla.mozilla.org/show_bug.cgi?id=915481 "Stop try tegra jobs pending for >6 hours" 4) We are changing the default when you push to try. Until now, by default Try will generate Android builds and then run *all* unittests+talos for Android2.2 (tegras) *and* Android4 (pandas). We are now testing a change to default as follows: 4a) Android builds: no change, still built by default 4b) Android pandas tests: no change, still run unittest and talos by default 4c) Android tegras tests: unittests would not be run by default, but talos would still be run by default. Because of details in how TryServer works, talos would still be run on tegras by default, in order to keep scheduling talos on pandas also. Details in https://bugzilla.mozilla.org/show_bug.cgi?id=915465 "Pushes to try should not trigger tegra test jobs by default". Again, this is just changing the default: anyone who wants Android2.2 specific unittests run on tegras on try can still get that by specify it explicitly when pushing to try. Note: this change is for default on try *only*. There is no change to what any other (non-try) branches do for android testing on tegras, those remain as-is. As mhommey and joel discussed earlier in this thread, changing try default to test on pandas, but not also run all tests on tegras, does introduce a slim-but-non-zero risk of missing a problem that only a tegra would have caught with that try push. Note that we are still running tegra testing on non-try branches, as usual, so even if a problem like this is missed on try, it will be caught the first time it lands on any other branch that has Android coverage. After this workweek, we can revisit whether this default setting needs to be reverted. Let me know if you want any further info, ok? John. == On 9/11/13 2:31 PM, Kartikaya Gupta wrote: > Earlier today the backlog on Android build jobs was on the order of > 1300. It seems to be coming down a little now but for a while there I > was worried it was going to grow unboundedly. Try jobs from over 10 > hours ago still have pending jobs - as I'm sure you all know, having a > 10-hour turnaround on try pushes is something of a productivity killer. > > I brought this up in #releng and one of the proposed solutions was to > try to tweak the prioritization of jobs between Try and Inbound a little > bit. I personally do like that Inbound jobs are prioritized above Try, > but perhaps they don't need to be prioritized quite so much. However, > changing this will affect a number of people, so it was suggested I > bring the discussion here to get other people's comments. > > So, anybody have thoughts on a good way to solve this problem? > > Cheers, > kats > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Including just to get std::min and std::max
On Sunday, September 8, 2013 6:22:01 AM UTC+3, Benoit Jacob wrote: > Hi, > > > > It seems that we have some much-included header files including > > just to get std::min and std::max. > Is it because min/max are used at the h file? can it be delegated to cpp files? how many other files which include said h files count on them to include ? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
