Robert O'Callahan wrote:
I assume no-one's finding the Firefox libxul.dll and loading it from their own
.EXE
I assume people are finding the XULRunner libxul.dll and loading it from
their own .EXE
--
Warning: May contain traces of nuts.
___
dev-
Syd Polk wrote:
Does MSVC 2013 run on Windows XP? We still support Win XP for the browser; do
we support building on it?
You can't create a stock build on XP since the latest SDK is 7.1 and the
gamepad code needs 8.0 and the DirectX code would like it too.
--
Warning: May contain traces o
Mike Hoye wrote:
I mean, if you find somebody in their office today curled up in a
ball, rocking back and forth and muttering "mork, mork, mork" over and
over again, that person's having a bad flashback. Call for help, stay
with them. Tell them we've got sqlite now and it's going to be OK.
T
Nicholas Nethercote wrote:
I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll
leave the exact meanings of "worst" and "piece of code" unspecified...
When you get time, find someone to tell you about Morse code. (No, I
don't mean Samuel.)
--
War
Ehsan Akhgari wrote:
Speaking about code that causes correctness bugs that actually affect
our end users, the best example that I know is editor/.
Not just correctness, but the unique way it use pointers to nsCOMPtr all
over...
--
Warning: May contain traces of nuts.
___
On Fri, Oct 17, 2014 at 4:19 PM, ISHIKAWA,chiaki wrote:
> Hi,
>
> I posted the following message to mozilla.dev.builds newsgroup, but
> I wonder if there is a mozilla-wide change to nsITreeView lately?
> I noticed this while testing a patch to C-C TB locally.
>
> (Considering that COMM-CENTRAL may
Hi,
I posted the following message to mozilla.dev.builds newsgroup, but
I wonder if there is a mozilla-wide change to nsITreeView lately?
I noticed this while testing a patch to C-C TB locally.
(Considering that COMM-CENTRAL may have a slight delay in getting
M-C changes, it may be that nsITreeVi
On 09/25/2014 10:29 AM, Ehsan Akhgari wrote:
>> I don't see this temporary difference as particularly problematic,
>> particularly given that "pixelated" is primarily an upscaling feature,
>> and given that we'll match them before too long. But if others
>> disagree, I'm open to holding off on shi
On 16/10/2014 13:56, Robert O'Callahan wrote:
On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch
wrote:
There are also "interesting" height computation issues that I'm pretty sure
HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
function of the box model, considering it's not
Thank you Bobby and Josh for all your work to improve ImageLib!
I’m pushing hard on making it better still (with a lot of help from folks like
Timothy Nikkel and Michael Wu). Hopefully next time we try to decide what the
worst piece of Mozilla code is, ImageLib won’t be a candidate. =)
- Seth
On 10/17/2014 06:43 PM, Luke Wagner wrote:
I have a short summary of why caching JIT code is not necessarily a clear win
for most JS in a blog post:
http://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/#caching
We do machine code for asm.js, though (as also
David,
> Le 14 oct. 2014 à 07:29, L. David Baron a écrit :
> Here is my current draft of the comments I plan to submit in about 12
> hours (cc:ing the whole AC, I think). Sorry for not getting this out
> for people to have a look at sooner.
Good summary of our discussions. Thanks.
--
Karl Dub
I have a short summary of why caching JIT code is not necessarily a clear win
for most JS in a blog post:
http://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/#caching
We do machine code for asm.js, though (as also described in the post).
More interesting than
This question returns every so often.
If I recall correctly:
- the JIT-compiled code is much, much, much larger than the JS source
code, and just reading it from the cache may actually slow down
execution of the page;
- in many pages, JIT-compiled code actually depends on the interactions
between
Since the html pages are already cached, why not also cache the JIT
compiled javascript while leaving a page? Shouldn't use too much space
than the text content of the embedding page. Much less space than the
image files embedded in a page.
___
dev-p
On 2014-10-16, 11:09 PM, Sean Lin wrote:
Platform coverage:
Initially on Firefox OS
FWIW we're trying to keep the implementation working with a dummy
backend on other platforms too, in the interest of keeping the API
testable on other platforms, but we are not planning to turn this API on
在 2014年10月17日星期五UTC+8下午2时39分54秒，Yonggang Luo写道：
> There is a lost of falt in XUL, but still have something good, such as tree
> and the XBL binding, besides, the window elements is also important, because
> we need it to implement chromeless window, and titlebar, there is no
> equivalent in HTML
On Thu, Oct 16, 2014 at 10:20 PM, Boris Zbarsky wrote:
> I think what Bobby was actually asking for is this:
>
> If a patch lands and is green in continuous integration but then we have
> some other tests somewhere (hidden, run manually, whatever) that start
> failing because of this patch, and w
On Fri, Oct 17, 2014 at 1:03 AM, Josh Matthews
wrote:
> I'm not certain that the image/src/ code is as bad as you make out any
> more. bholley certainly is no longer the expert there; I took over a bunch
> of his work to clean it up a year or two ago, and Seth is the benevolent
> dictator now and
On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote
wrote:
> On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote
> wrote:
>>
>> I was wondering what people think is the worst piece of code in the
>> entire Mozilla codebase. I'll leave the exact meanings of "worst" and
>> "piece of code" unspec
20 matches
Mail list logo
