Re: Rust required to build Gecko

2016-11-28 Thread Michael Froman
I tried the bootstrap on OS X (after a fresh pull from mozilla-central this 
morning), and I also have failures.  I’ve added the following lines to my 
.profile:
export PATH="$HOME/.cargo/bin:$PATH"
source /Users/mfroman/.cargo/env

I continue to get errors from the bootstrap process:
The details of the failure are as follows:

CalledProcessError: Command '[u'/Users/mfroman/.cargo/bin/rustc', 
u'--version']' returned non-zero exit status 1

  File 
"/Users/mfroman/mozilla/moz-central/python/mozboot/mozboot/mach_commands.py", 
line 26, in bootstrap
bootstrapper.bootstrap()
  File 
"/Users/mfroman/mozilla/moz-central/python/mozboot/mozboot/bootstrap.py", line 
232, in bootstrap
self.instance.ensure_rust_modern()
  File "/Users/mfroman/mozilla/moz-central/python/mozboot/mozboot/base.py", 
line 525, in ensure_rust_modern
modern, version = self.is_rust_modern()
  File "/Users/mfroman/mozilla/moz-central/python/mozboot/mozboot/base.py", 
line 512, in is_rust_modern
our = self._parse_version(rustc)
  File "/Users/mfroman/mozilla/moz-central/python/mozboot/mozboot/base.py", 
line 391, in _parse_version
stderr=subprocess.STDOUT)
  File "/Users/mfroman/mozilla/moz-central/python/mozboot/mozboot/base.py", 
line 320, in check_output
return fn(*args, **kwargs)
  File 
"/usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
 line 574, in check_output
raise CalledProcessError(retcode, cmd, output=output)

Any thoughts?  Further info:
mfroman-23602:moz-central mfroman$ which rustc
/Users/mfroman/.cargo/bin/rustc
mfroman-23602:moz-central mfroman$ rustc --version
error: no default toolchain configured

Thanks,
Michael.


> On Nov 25, 2016, at 9:48 AM, Andrew Halberstadt  
> wrote:
> 
> When first installing rust with ./mach bootstrap the install is
> successful, but there is a message about not being able to find the
> compiler immediately afterwards.
> 
> For anyone confused by this, the binaries are downloaded to ~/.cargo/bin
> and adding this directory to your $PATH should fix the issue. The
> bootstrapper explains this if you run it a second time, but makes no
> mention of it the first time through for some reason.
> 
> -Andrew
> 
> On 24/11/16 05:49 PM, Ralph Giles wrote:
>> tl;dr This is a heads-up that all gecko developers should install rust.
>> 
>> Next week I plan to switch our default build config to require Rust
>> when building Firefox.[1] If you compile Firefox from the C++ source,
>> please install the Rust language environment now.
>> 
>> You can install Rust by running `./mach bootstrap` which will download
>> and run the rustup installer for you.[2]
>> 
>> We recommend the installer at https://rustup.rs/ (despite being beta)
>> because it makes staying up to date and cross-compilation easy. If you
>> want more control, or to experiment with rust, you can install
>> directly from that website.
>> 
>> The main thing is to have up-to-date versions of the `rustc` and
>> `cargo` executables in the path of your build shell. Rust releases
>> every six weeks, just like Firefox, and we generally require the
>> latest stable release to compile mozilla-central. You can stay current
>> by running `rustup update`.
>> 
>> You'll still be able to build without a rust compiler by adding:
>> 
>>  ac_add_options --disable-rust
>> 
>> to your mozconfig. This is a temporary work-around; we expect to
>> remove that option and require Rust unconditionally early next year as
>> non-optional features start to depend on it.
>> 
>> Rust language in Gecko is an important part of Project Quantum. I'm
>> excited to be taking this next step toward that future. We first
>> shipped Rust code to users in Firefox 48, so it's long past time this
>> aspect of our default builds matched what we release.[3]
>> 
>> Thanks for your attention,
>> -r
>> 
>> [1] Enabling rust is https://bugzil.la/1283898
>> [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
>> [3] If you have issues with the installer or build, please file issues
>> blocking our tracking bug at https://bugzil.la/oxidation
>> 
> 
> ___
> 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: Rust required to build Gecko

2016-11-28 Thread Michael Froman
See inline.

> On Nov 28, 2016, at 11:37 AM, Ralph Giles  wrote:
> 
> On Mon, Nov 28, 2016 at 9:28 AM, Michael Froman  wrote:
> 
>> Any thoughts?  Further info:
>> mfroman-23602:moz-central mfroman$ which rustc
>> /Users/mfroman/.cargo/bin/rustc
>> mfroman-23602:moz-central mfroman$ rustc --version
>> error: no default toolchain configured
> 
> Very mysterious. This error message usually means rustup's redirect to
> the actual toolchain (in /Users/mfroman/.multirust/toolchains) is
> confused. I've seen it when the executable filename has a prefix, for
> example.
> 
> Make sure there's a toolchain installed under ~/.multirust, then maybe
> try `rustup update` and see what that says.
mfroman-23602:moz-central mfroman$ rustup update
info: no updatable toolchains installed
info: checking for self-updates

> 
> If that doesn't work, try `rustup default stable`.
mfroman-23602:moz-central mfroman$ rustup default stable
info: syncing channel updates for 'stable-x86_64-apple-darwin'
info: downloading component 'rustc'
 28.7 MiB /  28.7 MiB (100 %)   1.4 MiB/s ETA:   0 s
info: downloading component 'rust-std'
 36.1 MiB /  36.1 MiB (100 %)   1.4 MiB/s ETA:   0 s
info: downloading component 'rust-docs'
  7.5 MiB /   7.5 MiB (100 %)   1.4 MiB/s ETA:   0 s
info: downloading component 'cargo'
  2.4 MiB /   2.4 MiB (100 %)   1.5 MiB/s ETA:   0 s
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: default toolchain set to 'stable-x86_64-apple-darwin'

  stable-x86_64-apple-darwin installed - rustc 1.13.0 (2c6933acc 2016-11-07)


> 
> -r

Now, I’ve made it through the bootstrap successfully.  Thanks for the tips!  
I’m not sure exactly what happened the first time.  Possibly a network failure 
during the original download or something.

-Michael.



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


Re: Should &&/|| really be at the end of lines?

2017-02-18 Thread Michael Froman

> On Feb 17, 2017, at 6:24 PM, ISHIKAWA,chiaki  wrote:
> 
> Point 2:
> I prefer all the operators including "&&" and "||"
> at the beginning since such a format makes the tree-like structure of 
> multi-line easier to understand and edit, too.
> Adding a condition or removing a condition is much easier in this form.
> I forgot where the rational was explained well. Superficially it is covered 
> in GNU coding starnds:
> https://www.gnu.org/prep/standards/html_node/Formatting.html

If we’re considering changing the coding standard, my vote would be for all the 
operators including "&&" and "||” at the beginning for the reasons above.

-Michael.
[:mjf]

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


Re: Stylesheet wait timeout?

2017-08-31 Thread Michael Froman

> On Aug 31, 2017, at 1:08 PM, Boris Zbarsky  wrote:
> 
> The symptoms you observe sound like (A) is happening, possible from an 
> extension or our browser UI...  If you have a link to a specific url that 
> reproduces for you, especially in a clean profile, that would be pretty 
> useful.  This is usually pretty simple to debug when (A) happens: set a 
> breakpoint on when we start layout and see what the JS stack is. The hard 
> part is catching it happening.
I’ve seen this behavior too on OSX.  I did a restart with all add-ons disabled 
and could not reproduce.  Restarted with all add-ons on, and can reproduce.  I 
narrowed it down to Ghostery.  If I disable Ghostery, it no long appears to 
happen for me.  YMMV.

-Michael.

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


Re: Hiding 'new' statements - Good or Evil?

2017-11-27 Thread Michael Froman
On Nov 27, 2017, at 6:07 PM, smaug  wrote:
> 
> And auto makes code reading harder. It hides important information like 
> lifetime management.
> It happens easily with auto that one doesn't even start to think whether 
> nsCOMPtr/RefPtr should be used there.
> 
> I'm saying this all with my reviewer's hat on, after reading code which got 
> committed to m-c with proper r+
> (even from experienced engineers).
> 
+1 (especially on the review side of things)

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