On 2/26/14 11:06 PM, Masayuki Nakano wrote:
I'd like to want some suggestions about our classes which do NOT
represent DOM classes.
I don't have terribly strong opinions on these, in general...
1. All of them which don't start with "nsDOM" are in "mozilla".
This seems fine as a general rule
On 2014/02/12 23:22, Boris Zbarsky wrote:
In general, the names for things that are standardized should just match
the standard name, in the mozilla::dom namespace. In some (rare) cases
the standard name starts with "DOM"; in those situations we should have
our name start with "DOM" as well.
I
On 2014-02-26, 4:52 AM, Neil wrote:
Ehsan Akhgari wrote:
On 2/23/14, 4:05 PM, Neil wrote:
Both ArrayLength and MOZ_ARRAY_LENGTH are typesafe when compiled as
C++, however ArrayLength has the disadvantage that it's not a
constant expression in MSVC. In unoptimised builds this is direly
slow as
>From what I have read on the web, the .maff format seems a far better way to
>save webpages than the .mht format. First, it is just a .zip file, so if
>Firefox collapses, the files will still be readable. Secondly, they are only
>about half the size. Thirdly, they can more easily contain med
Could we compress major parts of omni.ja en block? We could for example stick
all JS we load at startup into a zip with zero compression and then compress
that into an outer zip. I think we already support nested containers like that.
Assuming your math is correct even without adding LZMA2 just
On Thu, Feb 27, 2014 at 08:25:00AM +0900, Mike Hommey wrote:
> On Wed, Feb 26, 2014 at 08:56:37PM +0100, Andreas Gal wrote:
> >
> > This randomly reminds me that it might be time to review zip as our
> > compression format for omni.ja.
> >
> > ls -l omni.ja
> >
> > 7862939
> >
> > ls -l omni.t
On Wed, Feb 26, 2014 at 08:56:37PM +0100, Andreas Gal wrote:
>
> This randomly reminds me that it might be time to review zip as our
> compression format for omni.ja.
>
> ls -l omni.ja
>
> 7862939
>
> ls -l omni.tar.xz (tar and then xz -z)
>
> 4814416
>
> LZMA2 is available as a public domai
On 2014-02-26, 4:11 PM, Cameron McCormack wrote:
Ted Mielczarek wrote:
Historically we haven't updated toolchains without a pressing reason,
since there's a lot of hassle involved. Is there a specific reason
you're asking?
The two recent things I have had to work around in VS2010 were bugs in
On 2/26/14 3:58 PM, Wesley Hardman wrote:
Personally, I would prefer to have it already available.
We have several deployment targets with different tradeoffs. Broadly
speaking:
Phones: expensive data, limited storage. Want to not use up the
storage, so download lazily.
Consumer laptops
On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman wrote:
> Personally, I would prefer to have it already available. I tend to live
> by "Its better to have it and not need it than to not have it and need it."
> (or have to fetch it.) This is my opinion though.
>
It seems like it would be trivial
On 2/26/2014, 11:56 AM, Andreas Gal wrote:
This randomly reminds me that it might be time to review zip as our compression
format for omni.ja.
ls -l omni.ja
7862939
ls -l omni.tar.xz (tar and then xz -z)
4814416
LZMA2 is available as a public domain implementation. It uses a bit more memor
Ted Mielczarek wrote:
Historically we haven't updated toolchains without a pressing reason,
since there's a lot of hassle involved. Is there a specific reason
you're asking?
The two recent things I have had to work around in VS2010 were bugs in
handling sized enums > 32 bits (enum Blah : uint6
Here are a few things to think about:
1. Not everyone will have internet access. Businesses sometimes have limited
access, or access to specific site only. There was discussion on this in the
addons file registration a little while ago.
What if you are travelling without internet and working
https://bugzilla.mozilla.org/show_bug.cgi?id=977292
Assigned to nobody.
On 2/26/2014 12:49 PM, Andreas Gal wrote:
>
> This sounds like quite an opportunity to shorten download times and reduce
> CDN load. Who wants to file the bug? :)
>
> Andreas
>
> On Feb 26, 2014, at 9:44 PM, Benjamin Smed
On 26/2/14 20:49, Andreas Gal wrote:
This sounds like quite an opportunity to shorten download times and reduce CDN
load. Who wants to file the bug? :)
Re fonts, see bug 619521 and bug 648548; there's even an old
proof-of-concept patch there, but it's been stalled for a while
If we're
This sounds like quite an opportunity to shorten download times and reduce CDN
load. Who wants to file the bug? :)
Andreas
On Feb 26, 2014, at 9:44 PM, Benjamin Smedberg wrote:
> On 2/26/2014 3:21 PM, Jonathan Kew wrote:
>> On 26/2/14 19:57, Andreas Gal wrote:
>>>
>>> Lets turn this question
On 2/26/2014 3:21 PM, Jonathan Kew wrote:
On 26/2/14 19:57, Andreas Gal wrote:
Lets turn this question around. If we had an on-demand way to load
stuff like this, what else would we want to load on demand?
A few examples:
Spell-checking dictionaries
Hyphenation tables
Fonts for additional s
On 26/2/14 19:57, Andreas Gal wrote:
Lets turn this question around. If we had an on-demand way to load stuff like
this, what else would we want to load on demand?
A few examples:
Spell-checking dictionaries
Hyphenation tables
Fonts for additional scripts
JK
Andreas
On Feb 26, 2014, at
Lets turn this question around. If we had an on-demand way to load stuff like
this, what else would we want to load on demand?
Andreas
On Feb 26, 2014, at 8:53 PM, Bobby Holley wrote:
> That's still a ton for something that most of our users will not (or will
> rarely) use. I think we absolut
This randomly reminds me that it might be time to review zip as our compression
format for omni.ja.
ls -l omni.ja
7862939
ls -l omni.tar.xz (tar and then xz -z)
4814416
LZMA2 is available as a public domain implementation. It uses a bit more memory
than zip, but its still within reason (th
That's still a ton for something that most of our users will not (or will
rarely) use. I think we absolutely need to get an on-demand story for this
kind of stuff. It isn't the first time it has come up.
bholley
On Wed, Feb 26, 2014 at 11:38 AM, Brendan Dahl wrote:
> Yury Delendik worked on re
Yury Delendik worked on reformatting the files a bit and was able to get them
down to 1.1MB binary which gzips to 990KB. This seems like a reasonable size to
me and involves a lot less work than setting up a process for distributing
these files via CDN.
Brendan
On Feb 24, 2014, at 10:14 PM, Ri
Splitting the valgrind tests up and running them separately as test jobs
in TBPL is definitely something the A*Team can help with. I've filed
bug 977240 for this.
Jonathan
On 2/25/14 7:25 PM, Nicholas Nethercote wrote:
On Tue, Feb 25, 2014 at 2:32 PM, Mike Hommey wrote:
I never understood
On 2014-02-26, 8:44 AM, Nicholas Nethercote wrote:
On Tue, Feb 25, 2014 at 8:18 PM, Mike Hommey wrote:
I never understood why we need those jobs to be builds. Why not turn
--enable-valgrind on m-c builds, and run valgrind as a test job?
--disable-jemalloc is needed as well.
That shouldn't
The Web API documentation meeting is Friday at 9 AM Pacific Time.
Everyone's welcome to attend; if you're interested in ensuring that
these APIs are properly documented, we'd love your input.
We have an agenda, as well as details on how to join, here:
https://etherpad.mozilla.org/WebAPI-docs-2
On Wed, Feb 26, 2014 at 6:58 AM, Ted Mielczarek wrote:
> On 2/26/2014 2:15 AM, Cameron McCormack wrote:
> > When do we plan to drop support for Visual Studio 2010? I remember at
> > one point that it was not possible to generate builds that ran on
> > Windows XP with VS2010, but Update 1 (releas
On Tue, Feb 25, 2014 at 8:18 PM, Mike Hommey wrote:
>> >
>> > I never understood why we need those jobs to be builds. Why not turn
>> > --enable-valgrind on m-c builds, and run valgrind as a test job?
>>
>> --disable-jemalloc is needed as well.
>
> That shouldn't be needed anymore with --soname-sy
On 2/26/2014 2:15 AM, Cameron McCormack wrote:
> When do we plan to drop support for Visual Studio 2010? I remember at
> one point that it was not possible to generate builds that ran on
> Windows XP with VS2010, but Update 1 (released in November) added
> support for that.
>
There are no immediat
Ehsan Akhgari wrote:
On 2/23/14, 4:05 PM, Neil wrote:
Both ArrayLength and MOZ_ARRAY_LENGTH are typesafe when compiled as
C++, however ArrayLength has the disadvantage that it's not a
constant expression in MSVC. In unoptimised builds this is direly
slow as the templated function does not ev
29 matches
Mail list logo
