On 12/19/14 6:20 AM, Chris Peterson wrote:
Here is the new Gmail calendar information for the weekly Platform
Engineering meeting. If these calendar links don't work, please let me
know.
* iCal ics link:
https://www.google.com/calendar/ical/mozilla.com_p51ksu9ddgqt72f0jl21vaq76o%40group.calend
On 12/18/2014 12:13 PM, Mike Hommey wrote:
I just published initial support for pushing to mercurial from git. It's
still experimental and as such I'm looking for volunteers who would want
to try it and confirm that it doesn't break stuff.
See http://glandium.org/blog/?p=3405 for more details.
On 12/18/2014 12:13 PM, Mike Hommey wrote:
I just published initial support for pushing to mercurial from git. It's
still experimental and as such I'm looking for volunteers who would want
to try it and confirm that it doesn't break stuff.
See http://glandium.org/blog/?p=3405 for more details.
Let me try to rephrase the problem in different terms, to hopefully make
it clearer why using timers like this is a bad idea.
setTimeout(foo, 1000) may seem to suggest run foo after 1 second, but
that is *not* what that function does, at all. What it does is, run foo
after 1 second, or perhap
This looks good overall. Two questions though:
On 2014-12-18 6:47 AM, jmaher wrote:
Mozilla - 2015 Talos performance regression policy
Over the last year and a half the Talos tests have been rewritten to be more
useful and meaningful. This means we need to take them seriously and cannot
jus
On 12/19/2014 10:05 AM, Ehsan Akhgari wrote:
Acceptable outcomes:
* A promise to attempt a fix at the bug is agreed upon, the bug is
assigned to someone and put in a queue.
How do we ensure that the follow-up bug actually does get fixed and it
fixes the regression completely?
Avi/Vladan
Neil wrote:
Neil wrote:
Mike Hommey wrote:
On Wed, Dec 17, 2014 at 06:06:25PM +, Neil wrote:
I downloaded the MSVC 2013 Community Edition, but there was no sign
of an SDK, so I downloaded that separately. Is this expected? If
so, I'll update MDN.
The SDK comes with it.
So you say,
On 19/12/2014 14:56, Ehsan Akhgari wrote:
Logging sufficiently is
almost always enough to not have to use these timers, as those tests
have demonstrated in practice.
Who's working on improving the log output from tinderbox? Timestamps get
mashed [0], sometimes only the failing assertion is pri
On 12/19/14 12:25 AM, Axel Hecht wrote:
On 12/19/14 6:20 AM, Chris Peterson wrote:
Here is the new Gmail calendar information for the weekly Platform
Engineering meeting. If these calendar links don't work, please let me
know.
* iCal ics link:
https://www.google.com/calendar/ical/mozilla.com_
On Fri, Dec 19, 2014 at 11:34 AM, Gijs Kruitbosch
wrote:
>
> On 19/12/2014 14:56, Ehsan Akhgari wrote:
>
>> Logging sufficiently is
>> almost always enough to not have to use these timers, as those tests
>> have demonstrated in practice.
>>
>
> Who's working on improving the log output from tinder
Great questions folks.
:bsmedberg has answered the questions quite well, let me elaborate:
Before a bug can be marked as resolved:fixed we need to verify the regression
is actually fixed. In many cases we will fix a large portion of the regression
and accept the small remainder.
We do keep tra
So if you go to about:config and set the javascript.options.strict pref,
you'll get warnings about accessing undefined properties.
js> Math.TAU
undefined
/!\ ReferenceError: reference to undefined property Math.TAU
(It says "ReferenceError", but your code still runs normally; it reall
Some prior discussion of this feature happened in the platform thread
"Disabling
strict warnings as errors in xpcshell"[1].
A few people argued for the extra warnings to be removed, while one person
said they were useful.
No clear conclusion was reached.
[1]:
https://groups.google.com/d/topic/mo
I was the person in the previous thread who found them useful, and I still
do. Some of the extraWarnings stuff is of questionable value, but the
undefined property stuff is really useful.
I don't really know if other people use this stuff. extraWarnings are
enabled by default in debug builds, and
On 12/19/14 12:45 PM, William McCloskey wrote:
I don't really know if other people use this stuff. extraWarnings are
enabled by default in debug builds, and I think a lot of people don't
realize the difference between these "extra warnings" and normal JS errors.
Writing front-end JS code for Fir
> On Dec 19, 2014, at 6:56 AM, Ehsan Akhgari wrote:
>
> Let me try to rephrase the problem in different terms, to hopefully make it
> clearer why using timers like this is a bad idea.
>
> setTimeout(foo, 1000) may seem to suggest run foo after 1 second, but that is
> *not* what that function
I generally don't find them useful, but instead annoying, and that they
provide a lot of noise to filter out to find actual relevant errors. This
is including the undefined property errors. It is a common JS style to pass
around configuration/option objects that will be missing many properties
that
On 19/12/2014 20:45, William McCloskey wrote:
I was the person in the previous thread who found them useful, and I still
do. Some of the extraWarnings stuff is of questionable value, but the
undefined property stuff is really useful.
Can you give an example of a useful undefined property warnin
On 12/19/2014 02:19 PM, Jason Orendorff wrote:
> So if you go to about:config and set the javascript.options.strict pref,
> you'll get warnings about accessing undefined properties.
>
> Please speak up now, if you're still using it!
I find these warnings quite useful (granted, I'm the sort of per
I am going to suggest, once again, that warnings generally noise and
should be replaced by actionable errors, at least when the code is
executed in a test suite.
See
https://groups.google.com/forum/#!topic/mozilla.dev.platform/gqSIOc5b-BI
Cheers,
David
On 19/12/14 21:19, Jason Orendorff wrote:
On Fri, Dec 19, 2014 at 2:34 PM, Gijs Kruitbosch
wrote:
>
> Can you give an example of a useful undefined property warning? Because my
> experience is the same as fitzgen's in that they are basically never useful
> to me.
I can't cite any bugzilla bugs, no. They're more useful while still
develo
The bug is surprising, in that it claims that the bytecode that consumes
the value determines whether a warning is issued (SETLOCAL;CALL), rather
than the bytecode doing the fetch.
Is that the intended behavior? I can't see how that makes much sense.
On Dec 19, 2014 2:55 PM, "David Rajchenbach-Tel
On Fri, Dec 19, 2014 at 5:13 PM, Jim Blandy wrote:
> The bug is surprising, in that it claims that the bytecode that consumes
> the value determines whether a warning is issued (SETLOCAL;CALL), rather
> than the bytecode doing the fetch.
>
> Is that the intended behavior? I can't see how that mak
On 2014-12-19 4:40 PM, Nils Ohlmeier wrote:
On Dec 19, 2014, at 6:56 AM, Ehsan Akhgari wrote:
Let me try to rephrase the problem in different terms, to hopefully make it
clearer why using timers like this is a bad idea.
setTimeout(foo, 1000) may seem to suggest run foo after 1 second, but t
(2014/12/20 5:19), Jason Orendorff wrote:
So if you go to about:config and set the javascript.options.strict pref,
you'll get warnings about accessing undefined properties.
js> Math.TAU
undefined
/!\ ReferenceError: reference to undefined property Math.TAU
(It says "ReferenceErro
On Fri, Dec 19, 2014 at 2:22 PM, Nick Fitzgerald
wrote:
> I generally don't find them useful, but instead annoying, and that they
> provide a lot of noise to filter out to find actual relevant errors. This
> is including the undefined property errors. It is a common JS style to pass
> around conf
26 matches
Mail list logo
