Re: nodejs for extensions ?

[Myk Melez]

Enrico Weigelt, metux IT consult 
2017 July 28 at 21:33
Hi folks,


just curious: did anyone already try nodejs modules
for (javascript-only) extensions ?
There was some discussion of this in the dev-addons thread "Node and Web 
Extensions Experiment" 
. 
We also discussed a related idea in the firefox-dev thread "SpiderNode 
for Firefox chrome code" 
.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nodejs for extensions ?

[Enrico Weigelt, metux IT consult]

Hi folks,


just curious: did anyone already try nodejs modules
for (javascript-only) extensions ?


--mtx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

[Josh Matthews]

Since this seems to only look for setTimeout, which is a relatively rare 
construct in xpcshell tests, should we be looking for do_timeout calls 
that use a non-zero argument as well?


Cheers,
Josh

On 7/28/17 11:48 AM, Andrew Halberstadt wrote:

As part of a larger effort to reduce oranges, we are starting to lint our
tests for common causes of intermittent failures. One low-hanging fruit is
preventing setTimeout with an arbitrary value (aka non-zero) as opposed to
waiting for an appropriate event. The mochitest harness already prevents
this in the harness itself (SimpleTest.requestFlakyTimeout), so this rule
is only enabled on xpcshell tests for now.

If you need to use a flaky setTimeout for some reason, you can disable the
rule at the directory level, file level or line level:
http://eslint.org/docs/user-guide/configuring#configuring-rules

It has been disabled in the following files due to pre-existing violations:
http://searchfox.org/mozilla-central/search?q=eslint-disable+mozilla%2Fno-arbitrary-setTimeout

Let me know if you think this should be enabled on any other test suites.
-Andrew



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads up! Building Stylo in local developer builds

[Chris Peterson]

btw, there is a mach bootstrap bug on Windows if you had previously 
installed the i686 rustc toolchain instead of the x86_64 toolchain:
Bug 1385241 - ./mach bootstrap: error: component 'rust-std' for target 
'i686-pc-windows-msvc' is required for toolchain 
'stable-i686-pc-windows-msvc' and cannot be re-added

You can fix this problem by running:
rustup default stable-x86_64-pc-windows-msvc

On 2017-07-28 1:04 AM, Chris Peterson wrote:
Stylo support (pref'd off) has been built in automation builds for a 
couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo 
support (pref'd off) in local developer builds, too. You should rerun 
`mach bootstrap` to make sure you have the latest versions of the Stylo 
and Rust dependencies.


Stylo currently builds on Windows, Mac, and Linux64. Linux32 is 
temporarily blocked by some build issues. Android support will follow 
after Firefox 57. Stylo adds a lot of new Rust code, which slows down 
Firefox build times. The Firefox build peers and Rust developers are 
working on a couple different methods to improve Rust build times.


If you don't work directly on Rust code locally, the biggest speedup 
available is probably sccache, a drop-in replacement for ccache that 
also supports Rust. Ted shared instructions for installing sccache on 
dev-platform earlier this week [1]. IIUC, sccache works best on Linux. 
There are currently some sccache bugs on Mac [2] and Windows (bug 1318370).


To enable Stylo for testing, set the "layout.css.servo.enabled" pref = 
true and report problems in the #servo IRC channel.


[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5srcnP-Wj4E/Uf_2gw2NAAAJ 



[2] https://github.com/mozilla/sccache/issues/163


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

[Andrew Halberstadt]

Ah, good to know! I'll file a follow-up to enable the eslint rule on
browser/a11y/chrome. Maybe eventually we can just replace the
requestFlakyTimeout mechanism with this eslint rule. I decided to punt on
that as I'm not sure if eslint is running on 100% of mochitests yet.

On Fri, Jul 28, 2017 at 11:56 AM Felipe G  wrote:

> I'll note that requestFlakyTimeout is only enabled for mochitest-plain at
> the moment:
> http://searchfox.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/SimpleTest.js#666
> So browser-chrome / a11y / chrome tests are still able to use non-0
> timeouts.
>
> Cheers,
> Felipe
>
> On Fri, Jul 28, 2017 at 12:48 PM, Andrew Halberstadt <
> ahalberst...@mozilla.com> wrote:
>
>> As part of a larger effort to reduce oranges, we are starting to lint our
>> tests for common causes of intermittent failures. One low-hanging fruit is
>> preventing setTimeout with an arbitrary value (aka non-zero) as opposed to
>> waiting for an appropriate event. The mochitest harness already prevents
>> this in the harness itself (SimpleTest.requestFlakyTimeout), so this rule
>> is only enabled on xpcshell tests for now.
>>
>> If you need to use a flaky setTimeout for some reason, you can disable the
>> rule at the directory level, file level or line level:
>> http://eslint.org/docs/user-guide/configuring#configuring-rules
>>
>> It has been disabled in the following files due to pre-existing
>> violations:
>>
>> http://searchfox.org/mozilla-central/search?q=eslint-disable+mozilla%2Fno-arbitrary-setTimeout
>>
>> Let me know if you think this should be enabled on any other test suites.
>> -Andrew
>>
> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

[Felipe G]

I'll note that requestFlakyTimeout is only enabled for mochitest-plain at
the moment: http://searchfox.org/mozilla-central/source/testing/
mochitest/tests/SimpleTest/SimpleTest.js#666
So browser-chrome / a11y / chrome tests are still able to use non-0
timeouts.

Cheers,
Felipe

On Fri, Jul 28, 2017 at 12:48 PM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> As part of a larger effort to reduce oranges, we are starting to lint our
> tests for common causes of intermittent failures. One low-hanging fruit is
> preventing setTimeout with an arbitrary value (aka non-zero) as opposed to
> waiting for an appropriate event. The mochitest harness already prevents
> this in the harness itself (SimpleTest.requestFlakyTimeout), so this rule
> is only enabled on xpcshell tests for now.
>
> If you need to use a flaky setTimeout for some reason, you can disable the
> rule at the directory level, file level or line level:
> http://eslint.org/docs/user-guide/configuring#configuring-rules
>
> It has been disabled in the following files due to pre-existing violations:
> http://searchfox.org/mozilla-central/search?q=eslint-disable
> +mozilla%2Fno-arbitrary-setTimeout
>
> Let me know if you think this should be enabled on any other test suites.
> -Andrew
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

ESlint rule 'no-arbitrary-setTimeout' enabled on xpcshell tests

[Andrew Halberstadt]

As part of a larger effort to reduce oranges, we are starting to lint our
tests for common causes of intermittent failures. One low-hanging fruit is
preventing setTimeout with an arbitrary value (aka non-zero) as opposed to
waiting for an appropriate event. The mochitest harness already prevents
this in the harness itself (SimpleTest.requestFlakyTimeout), so this rule
is only enabled on xpcshell tests for now.

If you need to use a flaky setTimeout for some reason, you can disable the
rule at the directory level, file level or line level:
http://eslint.org/docs/user-guide/configuring#configuring-rules

It has been disabled in the following files due to pre-existing violations:
http://searchfox.org/mozilla-central/search?q=eslint-disable+mozilla%2Fno-arbitrary-setTimeout

Let me know if you think this should be enabled on any other test suites.
-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

new locking primitive: RecursiveMutex

[Nathan Froyd]

Earlier this week, bug 1347963 landed, introducing a new
mozilla::RecursiveMutex type.  A RecursiveMutex instance may be
acquired on the same thread while said thread is already holding the
lock; such behavior with mozilla::Mutex would result in deadlocks.

While we already have a recursively-acquirable lock, ReentrantMonitor,
ReentrantMonitor does too much for many scenarios: it provides
condition variable-like semantics as well as recursive locking.  This
extra functionality makes ReentrantMonitor relatively slow;
RecursiveMutex provides only the locking functionality and should be
at least 2x faster than ReentrantMonitor, in addition to being
smaller.  Bug 1347963 converted several uses of ReentrantMonitor to
RecursiveMutex; the conversions were all straightforward.

If your code already uses ReentrantMonitor solely for its recursive
locking capabilities, please see whether converting to RecursiveMutex
would be feasible.

Thanks,
-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads up! Building Stylo in local developer builds

[Mike Hommey]

On Fri, Jul 28, 2017 at 01:04:21AM -0700, Chris Peterson wrote:
> Stylo support (pref'd off) has been built in automation builds for a couple
> weeks. Ralph Giles just landed bug 1384258 to also build Stylo support
> (pref'd off) in local developer builds, too. You should rerun `mach
> bootstrap` to make sure you have the latest versions of the Stylo and Rust
> dependencies.
> 
> Stylo currently builds on Windows, Mac, and Linux64. Linux32 is temporarily
> blocked by some build issues. Android support will follow after Firefox 57.
> Stylo adds a lot of new Rust code, which slows down Firefox build times. The
> Firefox build peers and Rust developers are working on a couple different
> methods to improve Rust build times.
> 
> If you don't work directly on Rust code locally, the biggest speedup
> available is probably sccache, a drop-in replacement for ccache that also
> supports Rust. Ted shared instructions for installing sccache on
> dev-platform earlier this week [1]. IIUC, sccache works best on Linux. There
> are currently some sccache bugs on Mac [2] and Windows (bug 1318370).

Note you can still benefit from sccache despite those issues if you
limit yourself to using it for rust, which you can do by setting the
RUSTC_WRAPPER environment variable to the path to sccache.

> To enable Stylo for testing, set the "layout.css.servo.enabled" pref = true
> and report problems in the #servo IRC channel.
> 
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/5srcnP-Wj4E/Uf_2gw2NAAAJ
> 
> [2] https://github.com/mozilla/sccache/issues/163

FWIW, I'm working on fixing this and other argument parsing related
problems.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Heads up! Building Stylo in local developer builds

[Chris Peterson]

Stylo support (pref'd off) has been built in automation builds for a 
couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo 
support (pref'd off) in local developer builds, too. You should rerun 
`mach bootstrap` to make sure you have the latest versions of the Stylo 
and Rust dependencies.


Stylo currently builds on Windows, Mac, and Linux64. Linux32 is 
temporarily blocked by some build issues. Android support will follow 
after Firefox 57. Stylo adds a lot of new Rust code, which slows down 
Firefox build times. The Firefox build peers and Rust developers are 
working on a couple different methods to improve Rust build times.


If you don't work directly on Rust code locally, the biggest speedup 
available is probably sccache, a drop-in replacement for ccache that 
also supports Rust. Ted shared instructions for installing sccache on 
dev-platform earlier this week [1]. IIUC, sccache works best on Linux. 
There are currently some sccache bugs on Mac [2] and Windows (bug 1318370).


To enable Stylo for testing, set the "layout.css.servo.enabled" pref = 
true and report problems in the #servo IRC channel.


[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5srcnP-Wj4E/Uf_2gw2NAAAJ


[2] https://github.com/mozilla/sccache/issues/163
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: prerendering

[Samael Wang]

There's an experimental framework to support  behind a 
preference implemented last year [1]. We ceased to work on it after realizing 
it's unlikely to benefit users as Chromium team indicated the usage rate is low 
and Chromium was going to remove it [2].

We'll clean up the code after 57 release since we're not going to ship this 
feature. The plan is to remove prerendering-specific code but keep 
GroupedSHistory [3], a feature to build cross-process session history without 
dropping bfcache. It was for prerendering but hopefully can also benefit some 
use cases of e10s-multi in the future.

The bug to track the removal is at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1383876

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1315105
[2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0nSxuuv9bBw
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=groupedshistory

- samael
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform