On 22/10/2013 01:14, Ehsan Akhgari wrote:
> Note that we also use this to support 32-bit plugins, so our target
> audience is not just 10.6 users.
I thought we recently removed 32-bit plugin support on OS X.
Phil
--
Philip Chee ,
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard
On Mon, Oct 21, 2013 at 8:21 PM, Nicholas Nethercote
wrote:
> On Mon, Oct 21, 2013 at 12:00 PM, Stephen Pohl wrote:
>> We are now (finally) getting ready to turn on history swipe animations
>> (bug 860493). There have been two major changes since sending out the
>> email below earlier in the ye
On 21/10/13 07:27 PM, Mike Hommey wrote:
> AFAIK, running 10.7+ in 32-bit mode is something you have to do manually
> at boot time. I guess nobody does that except for testing purpose. Also,
> afaik 10.7+ doesn't support 32-bit-only mac hardware.
You are confusing the kernel vs the userland. If th
On 21/10/13 07:07 PM, Chris Peterson wrote:
> On 10/21/13 3:28 PM, Mike Hommey wrote:
>> Note OS X 10.6 runs in 32-bit mode*by default*, even on *64-bit
>> capable* hardware. That's the whole problem. There are only a few
>> Macbook models that aren't 64-bit capable. There are much more OSX
>> inst
On 22/10/2013 2:57 AM, Matthew Gertner wrote:
On Monday, October 21, 2013 5:45:44 PM UTC+2, Neil wrote:
Well, you could turn of that error; it's just a pref. Of course you
would then decide whether to trap all the other DOMWindowClosing events
to stop other random scripts from closing windows.
On Mon, Oct 21, 2013 at 12:00 PM, Stephen Pohl wrote:
>
> We are now (finally) getting ready to turn on history swipe animations
> (bug 860493). There have been two major changes since sending out the
> email below earlier in the year:
> 1. We will only store snapshots for the 5 most recent pages,
On Mon, Oct 21, 2013 at 04:07:33PM -0700, Chris Peterson wrote:
> On 10/21/13 3:28 PM, Mike Hommey wrote:
> >Note OS X 10.6 runs in 32-bit mode*by default*, even on *64-bit
> >capable* hardware. That's the whole problem. There are only a few
> >Macbook models that aren't 64-bit capable. There are m
On 10/21/13 3:28 PM, Mike Hommey wrote:
Note OS X 10.6 runs in 32-bit mode*by default*, even on *64-bit
capable* hardware. That's the whole problem. There are only a few
Macbook models that aren't 64-bit capable. There are much more OSX
installs that run in 32-bit mode.
But the "boat anchor" is
I managed not to send this out for review until right before the
deadline, but there's a new charter proposal for the Web Application
Security working group:
http://www.w3.org/2013/07/webappsec-charter.html
which replaces the previous charter
http://www.w3.org/2011/08/appsecwg-charter.html
and
On Mon, Oct 21, 2013 at 08:24:15AM -0700, Nathan Froyd wrote:
> How long do we intend to continue shipping a 32-bit Firefox binary on
> OS X? As I understand it, we're doing this solely for our OS X 10.6
> users, as they are the only ones potentially running OS X on
> non-64-bit capable machines.
I tend to use something like
./mach build browser/base browser/components browser/themes
browser/locales browser/devtools
(obviously including only the directories where I changed stuff)
Which is fast and works.
~ Gijs
On 21/10/13 23:47 , David Rajchenbach-Teller wrote:
Wouldn't it be inte
On the Q4 goals list. Bug 929147.
On 10/21/2013 2:47 PM, David Rajchenbach-Teller wrote:
> Wouldn't it be interesting to also have a
> ./mach build frontend
> that repackages XUL and js code?
>
>
> On 10/21/13 6:53 PM, Gregory Szorc wrote:
>>> So what's the difference between |./mach build| an
This is a friendly public service announcement about major moz.build
migrations. On mozilla-inbound, and shortly to be found on
mozilla-central barring backout, the variables FINAL_TARGET, XPI_NAME,
and DIST_SUBDIR have all been moved from Makefiles to moz.build
definitions. Due to the presence
Wouldn't it be interesting to also have a
./mach build frontend
that repackages XUL and js code?
On 10/21/13 6:53 PM, Gregory Szorc wrote:
>> So what's the difference between |./mach build| and |./mach build binaries|?
>> would such difference exist also after updating mozillabuild with the ne
On Monday, October 21, 2013 4:05:36 PM UTC+1, tric...@accusoft.com wrote:
> There is probably a good study by the EPFL from, IIRC, 2011, published at the
> SPIE, Applications of Digital Image Processing, and many many others.
>
> Outcome is more or less that JPEG 2000 and JPEG XR are on par for a
Correction: we're going to use Boris Zbarsky's room for the meeting, out of
habit, even though he won't be there.
Andrew
- Original Message -
> Our (nominally) weekly DOM bindings meetings continue on Monday Oct 21 at
> 12:30 PM PDT.
>
> Meeting details:
>
> * Monday, October 21, 2013,
Hi,
We are now (finally) getting ready to turn on history swipe animations
(bug 860493). There have been two major changes since sending out the
email below earlier in the year:
1. We will only store snapshots for the 5 most recent pages, instead of 20.
2. Bug 817700 has landed, which gives us asy
Our (nominally) weekly DOM bindings meetings continue on Monday Oct 21 at 12:30
PM PDT.
Meeting details:
* Monday, October 21, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
- Vidyo room: MTV-3V Very Good Very Mighty
I'm not sure if any of the below info is accurate or not. If
This is a friendly reminder that the next channel merge date is only 7
days away! So land those important bug fixes this week and hold your
destablizing or less important changes until next week. :)
cpeterson
___
dev-platform mailing list
dev-platfor
Note that we also use this to support 32-bit plugins, so our target
audience is not just 10.6 users.
Cheers,
Ehsan
On 2013-10-21 11:24 AM, Nathan Froyd wrote:
[Not sure if this is strictly dev-platform material; dev-planning might have
been more appropriate in some respects.]
Our Firefox bui
On 10/21/2013 9:47 AM, Avi Hal wrote:
> On Wednesday, October 16, 2013 4:43:03 PM UTC+3, Mike Hommey wrote:
> ...
>> - Build with:
>>
>> ./mach build
>>
>>
>> After you built once, you can do edit-compile-edit-compile cycles with:
>>
>> ./mach build binaries
>
>
> So what's the difference
On Wednesday, October 16, 2013 4:43:03 PM UTC+3, Mike Hommey wrote:
...
> - Build with:
>
> ./mach build
>
>
> After you built once, you can do edit-compile-edit-compile cycles with:
>
> ./mach build binaries
So what's the difference between |./mach build| and |./mach build binaries|?
On 21/10/13 17:24 , Nathan Froyd wrote:
[Not sure if this is strictly dev-platform material; dev-planning might have
been more appropriate in some respects.]
Our Firefox builds for OS X currently build a 32-bit version, a 64-bit version,
and then squash those together to produce a universal bi
On Monday, October 21, 2013 5:45:44 PM UTC+2, Neil wrote:
> Well, you could turn of that error; it's just a pref. Of course you
> would then decide whether to trap all the other DOMWindowClosing events
> to stop other random scripts from closing windows.
>
> Alternatively, you could maybe lookin
Matthew Gertner wrote:
FYI I load the content into a popup and I want it to be able to close the
popup. So the real chrome function looks like:
contentWindow.wrappedJSObject.close = function() {
chromeWindow.close();
};
But as I said, the default close() method seems to be called instead and
[Not sure if this is strictly dev-platform material; dev-planning might have
been more appropriate in some respects.]
Our Firefox builds for OS X currently build a 32-bit version, a 64-bit version,
and then squash those together to produce a universal binary that runs on
32-bit or 64-bit system
> I think it would be worthwhile to do two experiments with real people
>
> evaluating the images:
>
> 1) For a given file size with artifacts visible, which format
>
> produces the least terrible artifacts?
>
> 2) Which format gives the smallest file size with a level of
>
> artifacts that
> Are there now JPEG 2000 encoders that make images such that if you
>
> want to decode an image in quarter of the full-size in terms of number
>
> of pixels (both dimensions halved), it is sufficient to use the first
>
> quarter of the file length?
Yes, certainly. Just a matter of the progres
There are probably a couple of issues here:
> - Why didn't you include JPEG 2000?
This is the first one. However, I would also include various settings of the
codecs involved. There is quite a bit one can do. For example, the overlap
settings for XR or visual weighting for JPEG 2000, or subsamp
It's not as simple as reading n% of the bit-stream – the image needs
to be encoded using tiles so a tile-aware decoder can simply read only
the necessary levels. This is very popular in the library community
because it allows a site like e.g. http://chroniclingamerica.loc.gov/
to serve tiles for a
On Monday, October 21, 2013 4:40:08 PM UTC+2, Gijs Kruitbosch wrote:
> Uh, I hope you meant:
> > window.wrappedJSObject.close = function() { ... };
> (ie, no braces after close[()])
Sorry, yes of course. I typed that quickly but obviously the real code doesn't
have parentheses after the functio
On 21/10/13 16:19 , Matthew Gertner wrote:
I'm loading a page into a but I want the close()
method to call a function defined in chrome. I tried the obvious:
window.wrappedJSObject.close() = function() { ... };
However, the old close() method is still called (as far as I can tell). I guess
I
On Mon, Oct 21, 2013 at 4:19 PM, Matthew Gertner
wrote:
> I'm loading a page into a but I want the close()
> method to call a function defined in chrome. I tried the obvious:
>
> window.wrappedJSObject.close() = function() { ... };
>
> However, the old close() method is still called (as far as I
I'm loading a page into a but I want the close()
method to call a function defined in chrome. I tried the obvious:
window.wrappedJSObject.close() = function() { ... };
However, the old close() method is still called (as far as I can tell). I guess
I'm being thwarted by some wrapper despite mod
On Fri, Oct 18, 2013 at 5:16 PM, wrote:
> I think JP2 support could potentially be very interesting because it would
> make responsive images almost trivial without requiring separate files (i.e.
> srcset could simply specify a byte-range for each size image) but the
> toolchain support needs
On Fri, Oct 18, 2013 at 1:08 AM, wrote:
> Which leads to think that doing some blinded experiment (real people
> evaluating the images) to compare compressed images has still some value.
I think it would be worthwhile to do two experiments with real people
evaluating the images:
1) For a given
> I have a couple of fundamental issues with how you're calculating 3 of the 4
> metrics (all but RGB-SSIM, which I didn't think too much about)
You are right about it, methodology is not clear on this point.
> First, am I correct in my reading of your methodology that for all metrics,
> you en
37 matches
Mail list logo
