Re: Phabricator Update, July 2017

[Martin Thomson]

On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones  wrote:
> instead of disabling splinter for phabricator backed products, we could make
> it a read-only patch viewer.

Given the number of bugs that exist with patches attached, that would
be greatly appreciated.  I would also assume that attaching patches
won't stop completely either.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Byron Jones]

To answer the other part of your question, MozReview will be disabled for
active use across the board, but it is currently used by a small number of
projects.  Splinter will be disabled on a per-product basis, as there may be
some projects that can't, won't, or shouldn't be migrated to Phabricator.


Splinter is still a nice UI to look at patches already attached to bugs.
Please don't disable it.


excellent point; thanks for that feedback.

instead of disabling splinter for phabricator backed products, we could 
make it a read-only patch viewer.




--
glob — engineering productivity — moz://a

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

Re: Bulk Closing Intermittents

[Karl Tomlinson]

I assume this was integrated with OrangeFactor?

That is the only way I know to determine whether an intermittent
failure has occurred, because failures are not necessarily
reported to bugzilla.

Is there a mechanism for tracking a failure that we intend to
addresss, even when it does not fail every 21 days?

Would that be filing another bug without the intermittent-failure
keyword?

Emma Humphries writes:

> This was the first time we bulk closed these bugs, and there will be some
> glitches. I don't consider this to be a blocker on continuing this work.
>
> Next time we do this, it won't be 5,000+ bugs. OrangeBot runs on Sundays,
> so we can do the cleanup on Monday.
>
> The long term goal is to stop using Bugzilla to record every intermittent
> test failure and only use it for test failures we intend to address.
>
> -- Emma
>
> On Mon, Jul 10, 2017 at 5:29 AM, Kartikaya Gupta  wrote:
>
>> It might be a good idea to integrate this process with the
>> OrangeFactor Robot, to avoid race conditions like what happened on bug
>> 1328486 (it was bulk-closed, and then a couple of hours later the OF
>> robot reported that there were two failures this week - but the bug
>> remained closed).
>>
>> Cheers,
>> kats
>>
>> On Fri, Jul 7, 2017 at 10:35 PM, Emma Humphries  wrote:
>> > As discussed earlier, Joel and I have kicked off a process to close
>> > intermittent test failures in Bugzilla.
>> >
>> > If a test associated with a bug does not fail in 21 days, we'll close the
>> > bug as RESOLVED:INCOMPLETE.
>> >
>> > The first batch of intermittent bugs to close has 5,130 tickets. I have a
>> > script to close these, but to close these without bug spam requires DBA
>> > intervention.
>> >
>> > I'd like to run the closures over the weekend but that's going to create a
>> > non-trivial amount of bug spam for some of you.
>> >
>> > There is a way to get rid of the bug spam!
>> >
>> > Every bug we close will have the keyword `bulk-close-intermittents` added
>> > to it.
>> >
>> > If you search for messages from `bugzilla-dae...@mozilla.org` containing
>> > `bulk-close-intermittents` you can isolate, review, and remove those
>> > messages.
>> >
>> > Thank you for your patience while we all work to get the noise out of
>> > Bugzilla so we can find the strong signals on what we must focus on to
>> > deliver Firefox 57 in November.
>> >
>> > -- Emma
>> > ___
>> > 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: Phabricator Update, July 2017

[Mike Hommey]

On Tue, Jul 11, 2017 at 09:59:57PM -0400, Mark Côté wrote:
> On 2017-07-11 9:51 PM, Martin Thomson wrote:
> > On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté  wrote:
> > > * MozReview and Splinter turned off in early December.
> > 
> > Is this bugzilla-wide?  I know that other project use splinter still.
> > Will those projects be able to use phabricator for their projects?
> >
> > For instance, NSS uses a separate instance of phabricator, but not all
> > the developers are using it already.  I don't think that we have NSPR
> > setup yet.
> >
> 
> Yes, we welcome other Mozilla-related projects to use the new Phabricator
> cluster.  In fact, we're looking for projects outside of
> Firefox/mozilla-central to be part of our pre-release period, which will
> help us validate the Bugzilla integration.  Migrating NSS over to the main
> instance is one candidate, and NSPR sounds like a possibility too.
> 
> To answer the other part of your question, MozReview will be disabled for
> active use across the board, but it is currently used by a small number of
> projects.  Splinter will be disabled on a per-product basis, as there may be
> some projects that can't, won't, or shouldn't be migrated to Phabricator.

Splinter is still a nice UI to look at patches already attached to bugs.
Please don't disable it.

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

Re: Phabricator Update, July 2017

[Mark Côté]

On 2017-07-11 9:51 PM, Martin Thomson wrote:

On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté  wrote:

* MozReview and Splinter turned off in early December.


Is this bugzilla-wide?  I know that other project use splinter still.
Will those projects be able to use phabricator for their projects?

>
> For instance, NSS uses a separate instance of phabricator, but not all
> the developers are using it already.  I don't think that we have NSPR
> setup yet.
>

Yes, we welcome other Mozilla-related projects to use the new 
Phabricator cluster.  In fact, we're looking for projects outside of 
Firefox/mozilla-central to be part of our pre-release period, which will 
help us validate the Bugzilla integration.  Migrating NSS over to the 
main instance is one candidate, and NSPR sounds like a possibility too.


To answer the other part of your question, MozReview will be disabled 
for active use across the board, but it is currently used by a small 
number of projects.  Splinter will be disabled on a per-product basis, 
as there may be some projects that can't, won't, or shouldn't be 
migrated to Phabricator.


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

Re: Phabricator Update, July 2017

[Martin Thomson]

On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté  wrote:
> * MozReview and Splinter turned off in early December.

Is this bugzilla-wide?  I know that other project use splinter still.
Will those projects be able to use phabricator for their projects?

For instance, NSS uses a separate instance of phabricator, but not all
the developers are using it already.  I don't think that we have NSPR
setup yet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Mark Côté]

We're currently trying to figure that out.  It's unlikely that it will 
be available for the initial launch of Phabricator, but we hope to have 
it not too long after.  I'll have an update in a couple weeks.


Mark


On 2017-07-11 7:32 PM, Chris Pearce wrote:

What is the status of push-to-review support?

Chris.




On Wednesday, July 12, 2017 at 8:42:06 AM UTC+12, Mark Côté wrote:

Hi all, here's a brief update on the project to deploy and integrate
Phabricator at Mozilla:

* Development Phabricator instance is up at
https://mozphab.dev.mozaws.net/, authenticated via
bugzilla-dev.allizom.org.

* Development, read-only UI for Lando (the new automatic-landing
service) has been deployed.

* Work is proceeding on matching viewing restrictions on Phabricator
revisions (review requests) to associated confidential bugs.

* Work is proceeding on the internals of Lando to land Phabricator
revisions to the autoland Mercurial branch.

* Pre-release of Phabricator, without Lando, targeted for mid-August.

* General release of Phabricator and Lando targeted for late September
or early October.

* MozReview and Splinter turned off in early December.

I have a blog post up with many more details:
https://mrcote.info/blog/2017/07/11/phabricator-update/

More to come!

Mark


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

Re: Phabricator Update, July 2017

[Chris Pearce]

What is the status of push-to-review support?

Chris.




On Wednesday, July 12, 2017 at 8:42:06 AM UTC+12, Mark Côté wrote:
> Hi all, here's a brief update on the project to deploy and integrate 
> Phabricator at Mozilla:
> 
> * Development Phabricator instance is up at
> https://mozphab.dev.mozaws.net/, authenticated via
> bugzilla-dev.allizom.org.
> 
> * Development, read-only UI for Lando (the new automatic-landing
> service) has been deployed.
> 
> * Work is proceeding on matching viewing restrictions on Phabricator
> revisions (review requests) to associated confidential bugs.
> 
> * Work is proceeding on the internals of Lando to land Phabricator
> revisions to the autoland Mercurial branch.
> 
> * Pre-release of Phabricator, without Lando, targeted for mid-August.
> 
> * General release of Phabricator and Lando targeted for late September 
> or early October.
> 
> * MozReview and Splinter turned off in early December.
> 
> I have a blog post up with many more details: 
> https://mrcote.info/blog/2017/07/11/phabricator-update/
> 
> More to come!
> 
> Mark
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Mike Hommey]

On Wed, Jul 12, 2017 at 08:05:05AM +0900, Brian Birtles wrote:
> On Tue, Jul 11, 2017 at 11:34 PM, Jim Mathies  wrote:
> 
> > What's the debugging situation look like for Windows developers? I've heard
> > it's pretty painful. Can we step through rust code using common tools
> > (WinDBG/Visual Studio)?
> >
> 
> You can set breakpoints and step through rust code using Visual Studio.
> Sometimes you can make sense of values in the Locals/Auto/Watch panels too.
> (Perhaps someone has worked out how to write autoexp.dat-like debug
> visualizers for rust?) Then again, unoptimized rust code is very slow so
> you'll probably find you're building with optimizations on making most of
> those values useless.
> 
> The biggest problem I find is that even with RUST_BACKTRACE=1 I rarely get
> call stacks when rust code panics. I normally have to rebuild without the
> panic="abort" configuration[1] and then attach a debugger in order to see
> the failing call stack. I suspect this only applies to rust code called
> from C++ (and not, e.g., when debugging Servo), and at least once I have
> actually seen a call stack from a panic dumped to the console, so I'm not
> sure what's going on there.

This sounds like bug 1373881.

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

Re: More Rust code

[Brian Birtles]

On Tue, Jul 11, 2017 at 11:34 PM, Jim Mathies  wrote:

> What's the debugging situation look like for Windows developers? I've heard
> it's pretty painful. Can we step through rust code using common tools
> (WinDBG/Visual Studio)?
>

You can set breakpoints and step through rust code using Visual Studio.
Sometimes you can make sense of values in the Locals/Auto/Watch panels too.
(Perhaps someone has worked out how to write autoexp.dat-like debug
visualizers for rust?) Then again, unoptimized rust code is very slow so
you'll probably find you're building with optimizations on making most of
those values useless.

The biggest problem I find is that even with RUST_BACKTRACE=1 I rarely get
call stacks when rust code panics. I normally have to rebuild without the
panic="abort" configuration[1] and then attach a debugger in order to see
the failing call stack. I suspect this only applies to rust code called
from C++ (and not, e.g., when debugging Servo), and at least once I have
actually seen a call stack from a panic dumped to the console, so I'm not
sure what's going on there.

Then there's the incredibly long build/link times.

[1] https://pastebin.mozilla.org/9026883
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[L. David Baron]

On Wednesday 2017-07-05 20:58 -0700, Marcos Caceres wrote:
> On July 6, 2017 at 1:40:13 PM, L. David Baron (dba...@dbaron.org) wrote:
> > I've taken what you (Tantek) wrote and made minor changes to yield
> > the following Formal Objection to the Web Platform WG charter.
> 
> I support the updated formal objection. Thanks Tantek for drafting it.
> 
> I've raised these issues also here:
> https://github.com/w3c/charter-html/issues/145
> 
> Where Domenic also pointed out that the following are being copy/pasted:
> 
> * Web Sockets API
> * Web Workers
> * HTML Canvas 2D Context
> 
> And the WG should cease to publish any errata for "specs under
> maintenance" (as those are all WHATWG, I think), except for
> "view-mode", which we should maybe consider asking them to obsolete.

To follow up here:  the deadline for this review was extended to
July 14 (Friday).  Thus I was able to update the objection, and it
now consists of the text below.  It could be further updated between
now and Friday if further changes are needed.

-David

=

We request that the charter drop all REC track specifications that
the WHATWG has demonstrated good maintenance of (as shown by active
implementer participation and implementation, including by Mozilla
in Firefox).

We would optionally like to see W3C republish the current versions
as a terminal NOTE, citing the WHATWG version as normative at the
top of the NOTE in large text as we would for any other abandoned
document for which better, more recent, or more accurate versions
exist elsewhere.

Particular specifications that we request WPWG drop from REC track
deliverables:

 * HTML5.2: at this point we are not aware of *any implementer*
   (people actually committing code to browsers) paying any
   practical (in that it affects code) attention to HTML5.2,
   especially to any differences between HTML5.2 and WHATWG HTML,
   despite having editors from Microsoft and Google.

 * microdata: as previously noted, WHATWG maintains microdata, and
   there is no need for any W3C time spent on this.

 * DOM 4 / DOM 4.1: likewise, the WHATWG maintains the DOM
   specification, and there is no need for W3C to duplicate that
   work.

 * Web Sockets API: likewise

 * Web Workers: likewise

 * HTML Canvas 2D Context: likewise

Likewise, we request that the maintenance of errata for these
specifications listed under "Specification Maintenance": 
DOM specifications
Progress Events
Server-sent Events
Web Storage
Web Messaging
be left to the WHATWG, which I believe is maintaining them.

Such duplication work by W3C WPWG is actively harmful in a number of
ways.

* It harms the relationship between W3C and WHATWG, both of which a
  number of organizations including Mozilla actively participate in.

* This active relationship harm provides unnecessary friction,
  discourages collaboration, and demonstrates either
  neglect or outright passive ill-will from one or more of
  chair(s)/staff of Web Platform WG toward WHATWG, which is
  unacceptable behavior (and counter to W3C PWE).

* Press and developers are continuing to be misled by the illusion
  that HTML5.2 is providing any kind of meaningful update to HTML,
  when meaningful updates (i.e., things that are implemented or
  fixed in browsers that web developers can then depend on) are only
  based on WHATWG HTML at this point.

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Phabricator Update, July 2017

[Mark Côté]

Hi all, here's a brief update on the project to deploy and integrate 
Phabricator at Mozilla:


* Development Phabricator instance is up at
https://mozphab.dev.mozaws.net/, authenticated via
bugzilla-dev.allizom.org.

* Development, read-only UI for Lando (the new automatic-landing
service) has been deployed.

* Work is proceeding on matching viewing restrictions on Phabricator
revisions (review requests) to associated confidential bugs.

* Work is proceeding on the internals of Lando to land Phabricator
revisions to the autoland Mercurial branch.

* Pre-release of Phabricator, without Lando, targeted for mid-August.

* General release of Phabricator and Lando targeted for late September 
or early October.


* MozReview and Splinter turned off in early December.

I have a blog post up with many more details: 
https://mrcote.info/blog/2017/07/11/phabricator-update/


More to come!

Mark

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

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[Ben Kelly]

We have implementation close to review for one-shot sync.  I don't know of
any browser that has implemented and shipped periodic sync yet.

On Tue, Jul 11, 2017 at 2:49 PM, L. David Baron  wrote:

> On Tuesday 2017-07-11 11:38 -0700, L. David Baron wrote:
> > On Wednesday 2017-07-05 11:02 -0700, L. David Baron wrote:
> > > On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
> > > > The W3C gave advance notice that 2 new charters are under
> > > > development:
> > > >
> > > >   https://lists.w3.org/Archives/Public/public-new-work/
> 2017May/0006.html
> > > >   (which contains brief descriptions of what has changed)
> > > >
> > > >   Web Platform Working Group
> > > >   http://w3c.github.io/charter-html/webplat-wg.html
> > > >   https://github.com/w3c/charter-html/
> > > >
> > > >   Service Workers Working Group
> > > >   http://w3c.github.io/charter-drafts/sw-charter.html
> > > >   https://github.com/w3c/charter-drafts/
> > > >
> > > > Comments on these charters can be made in their respective github
> > > > repositories, or, if necessary, I can make comments that should be
> > > > made as statements "from Mozilla" on the Advisory Committee mailing
> > > > list.
> > >
> > > I realize I didn't repost when the official review started, but
> > > these charters are under a formal review whose deadline is today, as
> > > sent out in
> > > https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0002.html
> > > https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0003.html
> >
> > Also, for what it's worth, given offline feedback, I plan to support
> > the Service Workers WG charter.  Apparently much of the discussion
> > about service workers happens in WHATWG forums, but it still seems
> > valuable to have the work happening in W3C, and it seems to be
> > functioning reasonably.
>
> Though I think it may be worth looking a little bit more into
> Background Sync, which is a new addition to the Service Workers.
> Are we already involved in that work?  Is it something we support?
> (I'm particularly curious about periodicSync, which appears to add
> pretty substantial capability to run in the background, based on my
> reading of
> https://github.com/WICG/BackgroundSync/blob/master/explainer.md .)
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> 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: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[L. David Baron]

On Tuesday 2017-07-11 11:38 -0700, L. David Baron wrote:
> On Wednesday 2017-07-05 11:02 -0700, L. David Baron wrote:
> > On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
> > > The W3C gave advance notice that 2 new charters are under
> > > development:
> > > 
> > >   https://lists.w3.org/Archives/Public/public-new-work/2017May/0006.html
> > >   (which contains brief descriptions of what has changed)
> > > 
> > >   Web Platform Working Group
> > >   http://w3c.github.io/charter-html/webplat-wg.html
> > >   https://github.com/w3c/charter-html/
> > > 
> > >   Service Workers Working Group
> > >   http://w3c.github.io/charter-drafts/sw-charter.html
> > >   https://github.com/w3c/charter-drafts/
> > > 
> > > Comments on these charters can be made in their respective github
> > > repositories, or, if necessary, I can make comments that should be
> > > made as statements "from Mozilla" on the Advisory Committee mailing
> > > list.
> > 
> > I realize I didn't repost when the official review started, but
> > these charters are under a formal review whose deadline is today, as
> > sent out in
> > https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0002.html
> > https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0003.html
> 
> Also, for what it's worth, given offline feedback, I plan to support
> the Service Workers WG charter.  Apparently much of the discussion
> about service workers happens in WHATWG forums, but it still seems
> valuable to have the work happening in W3C, and it seems to be
> functioning reasonably.

Though I think it may be worth looking a little bit more into
Background Sync, which is a new addition to the Service Workers.
Are we already involved in that work?  Is it something we support?
(I'm particularly curious about periodicSync, which appears to add
pretty substantial capability to run in the background, based on my
reading of
https://github.com/WICG/BackgroundSync/blob/master/explainer.md .)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[L. David Baron]

On Wednesday 2017-07-05 11:02 -0700, L. David Baron wrote:
> On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
> > The W3C gave advance notice that 2 new charters are under
> > development:
> > 
> >   https://lists.w3.org/Archives/Public/public-new-work/2017May/0006.html
> >   (which contains brief descriptions of what has changed)
> > 
> >   Web Platform Working Group
> >   http://w3c.github.io/charter-html/webplat-wg.html
> >   https://github.com/w3c/charter-html/
> > 
> >   Service Workers Working Group
> >   http://w3c.github.io/charter-drafts/sw-charter.html
> >   https://github.com/w3c/charter-drafts/
> > 
> > Comments on these charters can be made in their respective github
> > repositories, or, if necessary, I can make comments that should be
> > made as statements "from Mozilla" on the Advisory Committee mailing
> > list.
> 
> I realize I didn't repost when the official review started, but
> these charters are under a formal review whose deadline is today, as
> sent out in
> https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0002.html
> https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0003.html

Also, for what it's worth, given offline feedback, I plan to support
the Service Workers WG charter.  Apparently much of the discussion
about service workers happens in WHATWG forums, but it still seems
valuable to have the work happening in W3C, and it seems to be
functioning reasonably.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: WebVR Working Group

[L. David Baron]

The W3C is proposing a new charter for:

  WebVR Working Group
  https://www.w3.org/2017/07/vr-wg-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2017Jul/0002.html

Mozilla has the opportunity to send support, comments, or objections
through Friday, August 18.  If this is work that we want to see
happen at W3C, we should explicitly support it; if there are things
we think should be different about the charter, this is the time to
say so.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Nicolas B. Pierron]

On 07/11/2017 03:46 PM, Nicolas B. Pierron wrote:
(Answering privately until I get more manager intent to get this project as 
part of any long term roadmap)


Or not so privately after all … :(

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

RE: More Rust code

[Jim Mathies]

What's the debugging situation look like for Windows developers? I've heard
it's pretty painful. Can we step through rust code using common tools
(WinDBG/Visual Studio)?

Jim

-Original Message-
From: dev-platform
[mailto:dev-platform-bounces+jmathies=mozilla@lists.mozilla.org] On
Behalf Of Nicholas Nethercote
Sent: Monday, July 10, 2017 5:30 AM
To: dev-platform ; firefox-dev

Subject: More Rust code

Hi,

Firefox now has multiple Rust components, and it's on track to get a bunch
more. See https://wiki.mozilla.org/Oxidation for details.

I think this is an excellent trend, and I've been thinking about how to
accelerate it. Here's a provocative goal worth considering: "when writing a
new compiled-code component, or majorly rewriting an existing one, Rust
should be considered / preferred / mandated."

What are the obstacles? Here are some that I've heard.

- Lack of Rust expertise for both writing and reviewing code. We have some
pockets of expertise, but these need to be expanded greatly. I've heard
that there has been some Rust training in the Paris and Toronto offices.
Would training in other offices (esp. MV and SF, given their size) be a
good idea? What about remoties?

- ARM/Android is not yet a Tier-1 platform for Rust. See
https://forge.rust-lang.org/platform-support.html and
https://internals.rust-lang.org/t/arm-android-to-tier-1/5227 for some
details.

- Interop with existing components can be difficult. IPDL codegen rust
bindings could be a big help.

- Compile times are high, especially for optimized builds.

Anything else?

Nick
___
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: More Rust code

[smaug]

On 07/11/2017 04:27 PM, Ben Kelly wrote:

On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote 
wrote:


If I were the owner of that module I would consider implementing a policy

something like the following:

"When a person writes a new compiled-code component, or majorly rewrites
an existing one, they should strongly consider writing it in Rust

instead

of C or C++. Such a decision will depend on the nature of the component.
Components that are relatively standalone and have simple interfaces to
other components are good candidates to be written in Rust, as are
components such as parsers that process untrusted input."



I think this is pretty uncontroversial. The high-level strategic decision
to bet on Rust has already been made, and the cost of depending on the
language is already sunk. Now that we're past that point, I haven't heard
anyone arguing why we shouldn't opt for memory safety when writing new
standalone code. If there are people out there who disagree and think

they

have the arguments/clout/allies to make the case, please speak up.



As Gibson said: "The future is already here — it's just not very evenly
distributed."

The paragraph you wrote is obvious to you, but I suspect it's not obvious
to everyone -- Mozilla has a lot of contributors. There may still be some
Firefox developers who think that Rust something that other people do, and
that isn't relevant to them or their component(s). There may be some
Firefox developers who are interested in Rust, but feel intimidated or
uncertain about using it. There may be some developers who are keen to use
Rust, but haven't realized that we are past the experimental stage.



(Picking a somewhat random response to reply here...)

It would be really nice to have IPDL codegen support for rust.  I
considered using rust for my current task, but decided not to since I
would've had to build even more boilerplate to work with IPC c++ actors.  I
would've ended up with more glue code than actual functional code.

Another advantage of building rust IPDL codegen targets would be that we
could build service oriented code in the parent process in rust.  This
would be an incremental improvement that could offer additional safety in
the parent process without having to tackle webidle, cycle collection,
etc.  In particular, PBackground parent actors already cannot interface
with xpcom since they are OMT and would be a good candidate here.


OMT doesn't mean no XPCOM. You're thinking xpconnect.




Anyway, I think fixing these kinds of integration pain points would
accelerate our ability to use rust in gecko.  I would hesitate to make any
kind of mandates until these issues are addressed.

Thanks.

Ben



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

Re: More Rust code

[Alexis Beingessner]

I'm currently trying to improve the C++ <-> Rust FFI story a bit. I just
posted a draft proposal to add a mode to rustc that has it output the ABI
details of all public types:
https://internals.rust-lang.org/t/stabilizing-a-machine-readable-zprint-type-sizes/5525

This would theoretically reduce our maintenance/conversion burden at the
FFI boundary.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[smaug]

On 07/10/2017 01:29 PM, Nicholas Nethercote wrote:

Hi,

Firefox now has multiple Rust components, and it's on track to get a bunch
more. See https://wiki.mozilla.org/Oxidation for details.

I think this is an excellent trend, and I've been thinking about how to
accelerate it. Here's a provocative goal worth considering: "when writing a
new compiled-code component, or majorly rewriting an existing one, Rust
should be considered / preferred / mandated."

What are the obstacles? Here are some that I've heard.

- Lack of Rust expertise for both writing and reviewing code. We have some
pockets of expertise, but these need to be expanded greatly. I've heard
that there has been some Rust training in the Paris and Toronto offices.
Would training in other offices (esp. MV and SF, given their size) be a
good idea? What about remoties?

- ARM/Android is not yet a Tier-1 platform for Rust. See
https://forge.rust-lang.org/platform-support.html and
https://internals.rust-lang.org/t/arm-android-to-tier-1/5227 for some
details.

- Interop with existing components can be difficult. IPDL codegen rust
bindings could be a big help.

- Compile times are high, especially for optimized builds.

Anything else?



How is the performance when crossing Rust <-> C++ boundary? We need to make 
everything faster, not slower.
If I understood emilio's explanation on IRC correctly having the performance of 
an inlined (C++) function requires
handwritten rust bindings to access member variables of some C++ object.
That doesn't sound too good - hard to maintain and possibly easy to forget to 
optimize.

I don't claim to understand anything about the current setup, but
has anyone written down what would be needed to have fast and easy to maintain Rust 
<-> C++ boundary in
such way that also memory handling is easy to manage (aka, how to deal with 
CC/GC).
I think it would be better to sort out this kind of low level issues rather 
soon before we have too much
Rust code in tree, or perhaps we won't see much Rust usage before those issues 
are sorted out.

(I'm looking this all from DOM point of view, where pretty much all the objects need to be cycle collectable JS holders, but perhaps Rust would fit 
better in code outside DOM)

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

Re: More Rust code

[Ben Kelly]

On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote  wrote:

> On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley 
> wrote:
>
> > If I were the owner of that module I would consider implementing a policy
> >> something like the following:
> >>
> >> "When a person writes a new compiled-code component, or majorly rewrites
> >> an existing one, they should strongly consider writing it in Rust
> instead
> >> of C or C++. Such a decision will depend on the nature of the component.
> >> Components that are relatively standalone and have simple interfaces to
> >> other components are good candidates to be written in Rust, as are
> >> components such as parsers that process untrusted input."
> >>
> >
> > I think this is pretty uncontroversial. The high-level strategic decision
> > to bet on Rust has already been made, and the cost of depending on the
> > language is already sunk. Now that we're past that point, I haven't heard
> > anyone arguing why we shouldn't opt for memory safety when writing new
> > standalone code. If there are people out there who disagree and think
> they
> > have the arguments/clout/allies to make the case, please speak up.
> >
>
> As Gibson said: "The future is already here — it's just not very evenly
> distributed."
>
> The paragraph you wrote is obvious to you, but I suspect it's not obvious
> to everyone -- Mozilla has a lot of contributors. There may still be some
> Firefox developers who think that Rust something that other people do, and
> that isn't relevant to them or their component(s). There may be some
> Firefox developers who are interested in Rust, but feel intimidated or
> uncertain about using it. There may be some developers who are keen to use
> Rust, but haven't realized that we are past the experimental stage.
>

(Picking a somewhat random response to reply here...)

It would be really nice to have IPDL codegen support for rust.  I
considered using rust for my current task, but decided not to since I
would've had to build even more boilerplate to work with IPC c++ actors.  I
would've ended up with more glue code than actual functional code.

Another advantage of building rust IPDL codegen targets would be that we
could build service oriented code in the parent process in rust.  This
would be an incremental improvement that could offer additional safety in
the parent process without having to tackle webidle, cycle collection,
etc.  In particular, PBackground parent actors already cannot interface
with xpcom since they are OMT and would be a good candidate here.

Anyway, I think fixing these kinds of integration pain points would
accelerate our ability to use rust in gecko.  I would hesitate to make any
kind of mandates until these issues are addressed.

Thanks.

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

Re: More Rust code

[Joshua Cranmer ]

On 7/10/17 5:29 AM, Nicholas Nethercote wrote:

- Interop with existing components can be difficult. IPDL codegen rust
bindings could be a big help.


Rust's C++ interop story is absolutely atrocious. The FFI basically runs 
on C ABI, even though Rust and C++ have some similar concepts that could 
be exposed more cleanly (e.g., this parameters, even mapping  or 
&[T] to appropriate semantics) without forcing such a step. Bindgen 
works a little, but really only for calling C++ from Rust, and only if 
the C++ code is simple enough--if the code includes headers of 
complexity doom (hi, std::string!), it really ends up being a game of 
"how can I force bindgen to ignore enough that I get access to what I need."


XPIDL and WebIDL express only a subset of functionality, so they're 
theoretically easier to support than "generic C++17." However, XPIDL is 
profoundly unnatural in C++ code (the array syntax is horrendous, 
particularly if you want to start passing string arrays), as well as 
being limited in some of its vocabulary. WebIDL is more generic, but the 
bindings produces source code, which means that the ABI isn't exactly 
standardized for easy cross-language calling.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: More Rust code

[Gabor Krizsanits]

On Mon, Jul 10, 2017 at 7:51 PM, Kris Maglione 
wrote:

> Combined with the fact that I would have needed to find and dig through
> various scattered mailing list posts and wiki pages, and then pester a
> bunch of people by email or IRC just to get started, I've always given up
> the idea pretty quickly.
>
>
This is by far the biggest obstacle for me. I guess the right approach here
is to take the time to walk someone through from the very beginning and
document the areas where it was not trivial how to progress (talking about
gecko development in Rust not general Rust). And iterate that a few times.
The lack of experience in the area and the sub-optimal tooling will result
a huge overhead in developer time for anyone new in this area especially
for remote contributors. Trying to minimize that overhead is important.
Convincing managers to encourage developers to pay that overhead is also a
requirement (tight deadlines will not help there).

I have been flooded with work for a while, and it has been difficult to
find more time for improving my Rust skills in general. Encouraging people
to pick up Rust related goals and make it a priority to learn more Rust
would be also important.

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

Re: More Rust code

[Nicholas Nethercote]

On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley 
wrote:

> If I were the owner of that module I would consider implementing a policy
>> something like the following:
>>
>> "When a person writes a new compiled-code component, or majorly rewrites
>> an existing one, they should strongly consider writing it in Rust instead
>> of C or C++. Such a decision will depend on the nature of the component.
>> Components that are relatively standalone and have simple interfaces to
>> other components are good candidates to be written in Rust, as are
>> components such as parsers that process untrusted input."
>>
>
> I think this is pretty uncontroversial. The high-level strategic decision
> to bet on Rust has already been made, and the cost of depending on the
> language is already sunk. Now that we're past that point, I haven't heard
> anyone arguing why we shouldn't opt for memory safety when writing new
> standalone code. If there are people out there who disagree and think they
> have the arguments/clout/allies to make the case, please speak up.
>

As Gibson said: "The future is already here — it's just not very evenly
distributed."

The paragraph you wrote is obvious to you, but I suspect it's not obvious
to everyone -- Mozilla has a lot of contributors. There may still be some
Firefox developers who think that Rust something that other people do, and
that isn't relevant to them or their component(s). There may be some
Firefox developers who are interested in Rust, but feel intimidated or
uncertain about using it. There may be some developers who are keen to use
Rust, but haven't realized that we are past the experimental stage.

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

Re: More Rust code

[Julien Cristau]

On Tue, Jul 11, 2017 at 3:04 AM, Chris Peterson 
wrote:

> On 7/10/17 4:48 PM, Xidorn Quan wrote:
>
>> The first thing comes to my mind is crash reports. It currently doesn't
>> always include useful panic message from Rust, see for example [1] and [2].
>> Also for Stylo, we generate lots of code (including using bindgen and mako
>> template system, bindgen is usually fine, but the code generated from
>> template can contain lots of code logic), and when the crash happens inside
>> generated code, it is pretty hard to understand what's going wrong, because
>> there is no useful source link, see for example [3].
>> There are also issues from Rust side. I've always been using an optimized
>> debug build locally (because that runs faster), and sometimes use Visual
>> Studio to investigate issues. C++ code works fine with this configuration,
>> but in Rust code, I cannot see any variable information. Stack backtrace
>> seems to work fine to me, though.
>> [1]https://crash-stats.mozilla.com/report/index/2abff06f-
>> d969-4ba5-845b-a98410170708[2]https://crash-stats.mozilla.
>> com/report/index/03718a9c-9d98-4832-b8a6-026220170706[3]
>> https://crash-stats.mozilla.com/report/index/6b7d1d78-
>> 8418-47ef-bee9-f49c20170710
>>
>
> Looking at those crash reports' signatures, we should probably add
> `core::option::expect_failed` and `core::str::slice_error_fail` to
> Socorro's list of function names to ignore [1]. Should Socorro ignore all
> Rust core::* or std::* function names when searching the backtrace for a
> useful signature?
>

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1379089 last week for
core::option::expect_failed.

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

Re: Proposed W3C Charter: WebAssembly Working Group

[Anne van Kesteren]

On Tue, Jul 11, 2017 at 3:29 AM, L. David Baron  wrote:
> The standard sentence:
>   "Most WebAssembly Working Group teleconferences will focus on
>   discussion of particular specifications, and will be conducted on an
>   as-needed basis."
> doesn't seem to make sense for a working group that basically has one
> specification.  Perhaps it should be reworded for something that is more
> appropriate here.

I think they'll have to produce multiple eventually. I can think of at
least WebAssembly, a JavaScript API for compiling and executing
WebAssembly modules, and IDL bindings for WebAssembly.


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