On Wed, Aug 22, 2012 at 03:56:33PM +1200, Blair McBride wrote:
> On 22/08/2012 11:36 a.m., Gregory Szorc wrote:
> >I think Lua is perfect for this (it was invented to be a configuration
> >language after all). But, I'm not sure it satisfies #1 nor #8.
>
> +1 for Lua - it seems perfect for this. Fo
We're not the bear we're the fox!
http://www.cartoonstock.com/directory/r/responsive_to_needs_gifts.asp
Join us this Thursday, 11am PT, to discuss Firefox responsiveness.
Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy
Dial-in: conference# 9534
On 22/08/2012 11:36 a.m., Gregory Szorc wrote:
I think Lua is perfect for this (it was invented to be a configuration
language after all). But, I'm not sure it satisfies #1 nor #8.
+1 for Lua - it seems perfect for this. For #1, I find it far easier to
read (and write) than Gyp, when it comes
On 8/21/2012 6:12 PM, xunxun wrote:
于 2012/8/22 7:36, Gregory Szorc 写道:
Up until now, the focus has been on making Makefile.in's themselves
generic and data-driven [1]. We would use pymake's API to parse,
load, and extract data from Makefile.in's to construct the build
definition. In the long
于 2012/8/22 7:36, Gregory Szorc 写道:
tl;dr We're proposing moving away from Makefile's as the sole source
of the build system definition. This will lead to faster build times.
Bikeshedding^wFeedback on the file format is requested.
The existing build system is defined by Makefile.in's scattered
tl;dr We're proposing moving away from Makefile's as the sole source of
the build system definition. This will lead to faster build times.
Bikeshedding^wFeedback on the file format is requested.
The existing build system is defined by Makefile.in's scattered around
the source tree (typically o
On 12-08-21 4:37 PM, Kyle Huey wrote:
On Tue, Aug 21, 2012 at 1:09 PM, Ehsan Akhgari wrote:
Any program which relies on an event loop is by definition going to suffer
from intermittent changes in behavior because of event ordering, etc. This
means that some tests will fail intermittently in any
On 8/21/12 10:32 AM, L. David Baron wrote:
On Tuesday 2012-08-21 09:43 -0700, Asa Dotzler wrote:
On 8/21/2012 6:34 AM, Gervase Markham wrote:
On 20/08/12 18:25, Asa Dotzler wrote:
Can you say more about this? Are you saying it's Mozilla's
responsibility to put Mozilla resources into solving pr
ompatible tests in at least some cases,
and are upgrading their test infrastructure to run these tests [1].
Microsoft also write testharness.js tests so I guess they must run them too
although obviously it is rather harder to tell what's going on there.
[1] http://krijnhoetmer.n
On Tue, Aug 21, 2012 at 1:09 PM, Ehsan Akhgari wrote:
> Any program which relies on an event loop is by definition going to suffer
> from intermittent changes in behavior because of event ordering, etc. This
> means that some tests will fail intermittently in any web browser even if
> the browser
On Tuesday, 21 August 2012 13:16:38 UTC-7, Ehsan Akhgari wrote:
> I suggest that the best place to develop this would be on
>
> mozilla-central, especially since most of the work involved would
>
> probably not be part of the build of any Tier 1 platform. This means
>
> that you need to get
I suggest that the best place to develop this would be on
mozilla-central, especially since most of the work involved would
probably not be part of the build of any Tier 1 platform. This means
that you need to get reviews for the parts that touch things outside of
the widget back-end layer but
On 12-08-18 9:42 AM, ja...@hoppipolla.co.uk wrote:
On Friday, 17 August 2012 23:38:22 UTC+2, Justin Dolske wrote:
I'm talking about the problem of having a large set of tests with a
small percentage that fail intermittently, which is what we have today
in m-c. Even if they all magically became
On Friday, 8 June 2012 19:02:30 UTC+1, Ed Morley wrote:
> Treestatus (http://treestatus.mozilla.org) will soon be replacing Tinderbox
> as the means to open/close and set status messages for all mozilla-* trees,
> as well as the Thunderbird parts of the comm-* trees [1]. catlee++ :-D
>
> This i
On 8/21/2012 10:32 AM, L. David Baron wrote:
On Tuesday 2012-08-21 09:43 -0700, Asa Dotzler wrote:
On 8/21/2012 6:34 AM, Gervase Markham wrote:
On 20/08/12 18:25, Asa Dotzler wrote:
Can you say more about this? Are you saying it's Mozilla's
responsibility to put Mozilla resources into solving
Hi All,
I got the Gecko SDK 15.0b5 to compile my Firefox plugin. While compiling, I a
getting following errors:
xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2001: unresolved external symbol
__imp__vfprintf
xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2001: unresolved external symbol
__imp___fdopen
x
On Tuesday 2012-08-21 09:43 -0700, Asa Dotzler wrote:
> On 8/21/2012 6:34 AM, Gervase Markham wrote:
> >On 20/08/12 18:25, Asa Dotzler wrote:
> >>Can you say more about this? Are you saying it's Mozilla's
> >>responsibility to put Mozilla resources into solving problems for Opera?
> >>I'm not sure
On 8/21/2012 6:34 AM, Gervase Markham wrote:
On 20/08/12 18:25, Asa Dotzler wrote:
Can you say more about this? Are you saying it's Mozilla's
responsibility to put Mozilla resources into solving problems for Opera?
I'm not sure I understand this assertion.
I think he's arguing that a belief in
On 20/08/12 18:25, Asa Dotzler wrote:
> Can you say more about this? Are you saying it's Mozilla's
> responsibility to put Mozilla resources into solving problems for Opera?
> I'm not sure I understand this assertion.
I think he's arguing that a belief in user choice could well translate
into doin
19 matches
Mail list logo
