Re: [PATCH] mfbt: Poison: drop obsolete OS2 support

[Jim Blandy]

Please read our documentation on submitting patches to Firefox:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch


On Mon, Jul 31, 2017 at 12:28 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  mfbt/Poison.cpp | 34 +-
>  1 file changed, 1 insertion(+), 33 deletions(-)
>
> diff --git a/mfbt/Poison.cpp b/mfbt/Poison.cpp
> index b2767011d..e9981764f 100644
> --- a/mfbt/Poison.cpp
> +++ b/mfbt/Poison.cpp
> @@ -14,7 +14,7 @@
>  #include "mozilla/Assertions.h"
>  #ifdef _WIN32
>  # include 
> -#elif !defined(__OS2__)
> +#else
>  # include 
>  # include 
>  # ifndef MAP_ANON
> @@ -76,38 +76,6 @@ GetDesiredRegionSize()
>
>  #define RESERVE_FAILED 0
>
> -#elif defined(__OS2__)
> -static void*
> -ReserveRegion(uintptr_t aRegion, uintptr_t aSize)
> -{
> -  // OS/2 doesn't support allocation at an arbitrary address,
> -  // so return an address that is known to be invalid.
> -  return (void*)0xFFFD;
> -}
> -
> -static void
> -ReleaseRegion(void* aRegion, uintptr_t aSize)
> -{
> -  return;
> -}
> -
> -static bool
> -ProbeRegion(uintptr_t aRegion, uintptr_t aSize)
> -{
> -  // There's no reliable way to probe an address in the system
> -  // arena other than by touching it and seeing if a trap occurs.
> -  return false;
> -}
> -
> -static uintptr_t
> -GetDesiredRegionSize()
> -{
> -  // Page size is fixed at 4k.
> -  return 0x1000;
> -}
> -
> -#define RESERVE_FAILED 0
> -
>  #else // Unix
>
>  #include "mozilla/TaggedAnonymousMemory.h"
> --
> 2.11.0.rc0.7.gbe5a750
>
> ___
> 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: Extensions and Gecko specific APIs

[Andrew Swan]

Sorry for the slow reply, I was half-waiting to see if anybody else would
jump in but I guess product managers don't follow dev-platform :)

I think we're mostly in sync on most of the nuts and bolts and the
unresolved topics are generally pretty high-level concerns.

On Thu, Jul 27, 2017 at 10:02 AM, Steve Fink  wrote:

> Unfortunately, there isn't anything written that explains actual criteria
> in detail (its on our radar but somewhere behind a long list of engineering
> tasks on the short-term priority list).
>
>
> And I guess the parenthetical clause is what worries me. The people
> churning through that workload should be churning through that workload,
> and it's fine that they aren't spending time and mental space on the
> theoretical concerns of future compatibility issues or addon developer
> relations. But this is kind of a big deal for Mozilla strategically, so I
> would expect someone else to be working on the strategic plan before we
> reach the foot-shooting point.
>
> Hopefully, that someone would be in close contact with the engineers doing
> the work, since they have the best context and familiarity with large parts
> of the problem space, and hence their opinions deserve a lot of weight. As
> long as the consultation doesn't get in the way of getting stuff done.
> There's a ton of weight on you people's shoulders, and we don't want to add
> more.
>
> One person can do both strategy and tactics (or implementation) just fine,
> but it's usually not a good idea to do them at the same time. Different
> mindset, different tradeoffs.
>


Again, documenting more formally specifically what it means for an
> extension API to be safe, maintainable, performant, etc. is something we
> know is needed.  Hopefully when we come up for air after 57 we can work on
> this (and complementary things like webextensions experiments).
>
>
> Yeah, that's not really what I'm talking about. In a way, that's the hard
> part. But it's unavoidable, and it's happening in practice, and I'm sure
> there'll be a lag in formalization while things are taking shape. That's
> probably a good thing, since it'll require experience to flesh these things
> out.
>
> But that's about individual APIs. I want high-level answers to the
> simultaneous questions "How are we going to expose sufficient functionality
> to provide extension authors with what they need?" and "How are we going to
> avoid shooting ourselves in the foot when we get further down the road?"
> The sort of things you read in high-level strategy documents that set down
> the goals, direction, and approach to known obstacles. (Not that I
> necessarily want such a document; they're boring and make for dull reading,
> and I'm always suspicious as to whether anyone's paying attention to them.
> But I want the thinking behind it.)
>

I think the basic principles here are pretty simple and I tried to lay them
out before.  We're drawing a line and saying that we'll only expose things
to WebExtensions that can be done in a way that is safe for users and
maintainable for us (ie the people that work on gecko/firefox).  Within
those boundaries, we're willing to provide whatever extension authors
need.  Exactly how the terms "safe for users" and "maintainable for us" are
defined is mostly an engineering decision (and occasionally a product or UX
decision) and to be frank, we're still nailing down exactly how strict we
should be (for what its worth I think we've personally been relatively
conservative thus far).

Anyway, I think the real strategy questions are about how much we will
invest in building these APIs ourselves -- every engineer who is working on
extension APIs is an engineer who is not working on performance or other
new features.  A related question is who exactly should be creating
extension APIs.  We have a dedicated team right now in the midst of a big
blitz to bootstrap (no pun intended) the whole WebExtensions platform but
in the longer term I think it makes a lot more sense for engineers who know
individual areas of the code well to be the ones creating extension APIs
that touch those areas.  On the other hand, that's adding to everybody's
already overfull workloads.  This is a fine problem for engineering
management to wrestle with while the rest of us keep busy writing code :)

For further discussion about the longer term strategy, I would suggest
following up with Kev Needham who oversees all of addons.  Also, Mike Conca
just started as the product manager for WebExtensions.  But to be fair to
him, he's now in his second full week here and if his experience is
anything like mine was, he's still just trying not to get knocked down by
the Mozilla-newcomer-firehose.

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

Re: Intent to ship:

[Dragana Damjanovic]

Sorry, that was my mistake. Of course preload has a pref:

network.preload

My apologies, I was writing e-mail in a hurry.

The pref was implemented in
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633.
The  is turn on by default and we are planning to ship it
turned on.

dragana


On Mon, Jul 31, 2017 at 7:32 PM, Michael Layzell 
wrote:

> This also seems like a feature which some users may want to disable, for
> example in order to reduce bandwidth usage on certain websites (I'm not
> sure how bad the impact would be bug *shrug*).
>
> I imagine we should add a pref if possible before shipping this feature.
>
> On Mon, Jul 31, 2017 at 1:25 PM, Josh Matthews 
> wrote:
>
> > Why is there no preference to control it? I thought that was standard
> > practice for new features to make it easier to unship them if we
> discover a
> > problem that makes it difficult to back out.
> >
> > Cheers,
> > Josh
> >
> >
> > On 7/31/17 1:14 PM, Dragana Damjanovic wrote:
> >
> >> As of Firefox 56, I intent to ship link rel=preload. The feature is
> >> developed in bug 1222633 <
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1222633>. There is no pref
> >> for
> >> this feature, so it will be shipped directly.
> >>
> >> **Bug to turn on by default**:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
> >>
> >> **Link to standard**:
> >> https://w3c.github.io/preload/ (This is still a draft)
> >>
> >> dragana
> >>
> >>
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nodejs for extensions ?

[David Teller]

Node dependency trees tend to be pretty large, so I'm a little concerned
here. Has the memory footprint be measured?

Cheers,
 David

On 31/07/17 19:45, Michael Cooper wrote:
> If you mean using modules from NPM in a browser add-on, the Shield client
> extension recently started doing this <
> https://github.com/mozilla/normandy/tree/master/recipe-client-addon>
> 
> We do this by using webpack to process the node modules, bundling the
> entire dependency tree of a library into a single file. We then add a few
> more bits to make the resulting file compatible with `Chrome.utils.import`.
> You can see the webpack config file here <
> https://github.com/mozilla/normandy/blob/master/recipe-client-addon/webpack.config.js>
> and the way we use the resulting files here <
> https://github.com/mozilla/normandy/blob/48a446cab33d3b261b87c3d509964987e044289d/recipe-client-addon/lib/FilterExpressions.jsm#L12
>>
> 
> We suspect that this approach won't be compatible with all Node libraries,
> because it is fairly naive. But it has worked well for the ones we've used
> (React, ReactDOM, ajv, and mozjexl, so far).
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nodejs for extensions ?

[Michael Cooper]

If you mean using modules from NPM in a browser add-on, the Shield client
extension recently started doing this <
https://github.com/mozilla/normandy/tree/master/recipe-client-addon>

We do this by using webpack to process the node modules, bundling the
entire dependency tree of a library into a single file. We then add a few
more bits to make the resulting file compatible with `Chrome.utils.import`.
You can see the webpack config file here <
https://github.com/mozilla/normandy/blob/master/recipe-client-addon/webpack.config.js>
and the way we use the resulting files here <
https://github.com/mozilla/normandy/blob/48a446cab33d3b261b87c3d509964987e044289d/recipe-client-addon/lib/FilterExpressions.jsm#L12
>

We suspect that this approach won't be compatible with all Node libraries,
because it is fairly naive. But it has worked well for the ones we've used
(React, ReactDOM, ajv, and mozjexl, so far).

On Fri, Jul 28, 2017 at 10:13 PM Myk Melez  wrote:

> > 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"
> <
> https://groups.google.com/forum/#!topic/firefox-dev/MWE-_1xkokk/discussion
> >.
>
> -myk
>
> ___
> 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: Intent to ship:

[Michael Layzell]

This also seems like a feature which some users may want to disable, for
example in order to reduce bandwidth usage on certain websites (I'm not
sure how bad the impact would be bug *shrug*).

I imagine we should add a pref if possible before shipping this feature.

On Mon, Jul 31, 2017 at 1:25 PM, Josh Matthews 
wrote:

> Why is there no preference to control it? I thought that was standard
> practice for new features to make it easier to unship them if we discover a
> problem that makes it difficult to back out.
>
> Cheers,
> Josh
>
>
> On 7/31/17 1:14 PM, Dragana Damjanovic wrote:
>
>> As of Firefox 56, I intent to ship link rel=preload. The feature is
>> developed in bug 1222633 <
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1222633>. There is no pref
>> for
>> this feature, so it will be shipped directly.
>>
>> **Bug to turn on by default**:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
>>
>> **Link to standard**:
>> https://w3c.github.io/preload/ (This is still a draft)
>>
>> dragana
>>
>>
> ___
> 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: Intent to ship:

[Josh Matthews]

Why is there no preference to control it? I thought that was standard 
practice for new features to make it easier to unship them if we 
discover a problem that makes it difficult to back out.


Cheers,
Josh

On 7/31/17 1:14 PM, Dragana Damjanovic wrote:

As of Firefox 56, I intent to ship link rel=preload. The feature is
developed in bug 1222633 <
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633>. There is no pref for
this feature, so it will be shipped directly.

**Bug to turn on by default**:
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633

**Link to standard**:
https://w3c.github.io/preload/ (This is still a draft)

dragana



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

Intent to ship:

[Dragana Damjanovic]

As of Firefox 56, I intent to ship link rel=preload. The feature is
developed in bug 1222633 <
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633>. There is no pref for
this feature, so it will be shipped directly.

**Bug to turn on by default**:
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633

**Link to standard**:
https://w3c.github.io/preload/ (This is still a draft)

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

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Botond Ballo]

On Mon, Jul 31, 2017 at 3:40 AM, Enrico Weigelt, metux IT consult
 wrote:
> On 31.07.2017 09:23, Cameron McCormack wrote:
>> Firefox patches should be submitted via Bugzilla, rather than by email
>> to dev-platform.  Please see:
>>
>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed
>
> Is there a way to submit via mail ? Or some git-send-email counterpart ?
>
> Always going through the web frontend manually would be pretty time
> consuming ...

I've already answered this [1]: patches can be submitted via the
command-line using "hg push review". Ralph Giles also pointed you to a
git-based equivalent [2].

Cheers,
Botond

[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/goLGqnPfAMI/wSes1D1gCAAJ
[2] 
https://groups.google.com/d/msg/mozilla.dev.platform/goLGqnPfAMI/B7ueR4tgCAAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [PATCH] old-configure: startupcache: check for zipwriter

[Gregory Szorc]

Enrico,

We generally don't accept Firefox patches via email. Please visit
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction
to learn about how to submit patches to Firefox.

On Mon, Jul 31, 2017 at 12:18 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> startupcache depends on zipwriter.
> when enabled, check that zipwriter is also enabled.
>
> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  old-configure.in | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/old-configure.in b/old-configure.in
> index daa593bfa..d76ebd547 100644
> --- a/old-configure.in
> +++ b/old-configure.in
> @@ -4662,6 +4662,10 @@ if test -n "$MOZ_B2G"; then
>  fi
>  if test -n "$MOZ_DISABLE_STARTUPCACHE"; then
>AC_DEFINE(MOZ_DISABLE_STARTUPCACHE)
> +else
> +  if test -z "$MOZ_ZIPWRITER" ; then
> +AC_ERROR([startup cache depends on --enable-zipwriter])
> +  fi
>  fi
>  AC_SUBST(MOZ_DISABLE_STARTUPCACHE)
>
> --
> 2.11.0.rc0.7.gbe5a750
>
> ___
> 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/31/2017 01:02 PM, Henri Sivonen wrote:

On Tue, Jul 18, 2017 at 7:01 AM, Jim Blandy  wrote:

BTW, speaking of training: Jason's and my book, "Programming Rust" will be
available on paper from O'Reilly on August 29th!


And already available on Safari Books Online (access available via
Service Now request subject to managerial approval).

On Mon, Jul 17, 2017 at 10:43 PM, Ted Mielczarek  wrote:

From my perspective Rust is our
single-biggest competitive advantage for shipping Firefox, and every
time we choose C++ over Rust we throw that away.


I agree.


but we are quickly
going to hit a point where "I don't feel like learning Rust" is not
going to cut it anymore.


Indeed.

On Tue, Jul 11, 2017 at 4:37 PM, smaug  wrote:

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)


Rust indeed is, at least at present, a better fit for code outside the
area of cycle-collectable DOM objects.

The performance issue you mention applies if the usage scenario is
that Rust code needs to get or set a lot of fields on a C++ object.
While we do have code that, if implemented in Rust, would have to do
performance-sensitive field access on C++ objects, we also have areas
for which that would not be a concern. For example, in the case of
encoding_rs, the data that crosses the FFI boundary is structurally
simple (mozilla::Span / Rust slices decomposing to pointer to an array
of primitives and a length for FFI crossing) and the amount of work
done on the Rust side is substantial compared to the frequency of
crossing the FFI boundary.

In the absence of the Stylo-like optimization of frequent
performance-sensitive access of fields of a foreign-language object,
the FFI story that one can expect involves three functions/methods per
logical method.

Either (for C++ caller and Rust callee)
 1) C++ method wrapping the C function to hide the unsafety and bad
ergonomics of raw C.
 2) C function declared in C++ and implemented in Rust.
 3) Rust method: the actual callee that does something useful.
Or (for Rust caller and C++ callee)
 1) Rust method wrapping the C function to hide the unsafety and bad
ergonomics of raw C.
 2) C function declared in Rust and implemented in C++.
 3) C++ method: the actual callee that does something useful.

So there's the real callee method, there's a small C function that
wraps that method in a C ABI-compatible way and then there is a
wrapper for the C function that provides the ergonomics that one would
expect in the calling language.

The caller-side wrapper around the C function is trivial to make
inline and as a matter of code size is likely harmless or even
strictly beneficial to make inline.

The compilers don't have visibility across the declaration definition
of the C function, since that's where the cross-language linkage
happens, so currently one needs to assume that the C function always
has the cost of an actual function call.

As for inlining the actual callee method of interest in the language
being called into the implementation of the C function, it may or may
not happen automatically and when it doesn't happen automatically,
forcing it to happen manually might be a problem in terms of code
size.

So when the callee that actually does the work we care about doesn't
get inlined into its C wrapper, one should approximate a call from
Rust to C++ or from C++ to Rust have the cost of two *non-virtual*
function calls instead of one. (It would be interesting to contrast
this to the cost of over-use of virtual calls due to nsIFoo
interfaces.)

- -

Ideally, both the caller-language-side wrapper around the C function
and the C function itself would get inlined so that the cross-language
call would on the machine code level look just like a normal (if not
also inlined!) call to a method of the callee language. For that to
happen, we'd need link-time inlining across object files produced by
different-language compilers.

Naïvely, one would think that it should be possible to do that with
clang producing "object files" holding LLVM IR and rustc produ

Re: Intent to remove: sensor APIs

[Anne van Kesteren]

On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren  wrote:
> Please consider the request to remove device orientation retracted for
> now. We'll still need to figure out some kind of long term plan for
> that API though. WebVR building on it through libraries that abstract
> away the browser incompatibilities will just make it harder to fix the
> underpinnings going forward. (And there's always the risk that folks
> don't use libraries and code directly against what Chrome ships. Seems
> likely even.)

Small update: we'll start by just disabling proximity. Disabling
ambient light will follow soon after, but is a little trickier as we
use the web-facing API in the Firefox for Android frontend.
(Suggestions for fixing the orientation interoperability mess are
still welcome!)


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

Re: More Rust code

[Henri Sivonen]

On Tue, Jul 18, 2017 at 7:01 AM, Jim Blandy  wrote:
> BTW, speaking of training: Jason's and my book, "Programming Rust" will be
> available on paper from O'Reilly on August 29th!

And already available on Safari Books Online (access available via
Service Now request subject to managerial approval).

On Mon, Jul 17, 2017 at 10:43 PM, Ted Mielczarek  wrote:
> From my perspective Rust is our
> single-biggest competitive advantage for shipping Firefox, and every
> time we choose C++ over Rust we throw that away.

I agree.

> but we are quickly
> going to hit a point where "I don't feel like learning Rust" is not
> going to cut it anymore.

Indeed.

On Tue, Jul 11, 2017 at 4:37 PM, smaug  wrote:
> 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)

Rust indeed is, at least at present, a better fit for code outside the
area of cycle-collectable DOM objects.

The performance issue you mention applies if the usage scenario is
that Rust code needs to get or set a lot of fields on a C++ object.
While we do have code that, if implemented in Rust, would have to do
performance-sensitive field access on C++ objects, we also have areas
for which that would not be a concern. For example, in the case of
encoding_rs, the data that crosses the FFI boundary is structurally
simple (mozilla::Span / Rust slices decomposing to pointer to an array
of primitives and a length for FFI crossing) and the amount of work
done on the Rust side is substantial compared to the frequency of
crossing the FFI boundary.

In the absence of the Stylo-like optimization of frequent
performance-sensitive access of fields of a foreign-language object,
the FFI story that one can expect involves three functions/methods per
logical method.

Either (for C++ caller and Rust callee)
 1) C++ method wrapping the C function to hide the unsafety and bad
ergonomics of raw C.
 2) C function declared in C++ and implemented in Rust.
 3) Rust method: the actual callee that does something useful.
Or (for Rust caller and C++ callee)
 1) Rust method wrapping the C function to hide the unsafety and bad
ergonomics of raw C.
 2) C function declared in Rust and implemented in C++.
 3) C++ method: the actual callee that does something useful.

So there's the real callee method, there's a small C function that
wraps that method in a C ABI-compatible way and then there is a
wrapper for the C function that provides the ergonomics that one would
expect in the calling language.

The caller-side wrapper around the C function is trivial to make
inline and as a matter of code size is likely harmless or even
strictly beneficial to make inline.

The compilers don't have visibility across the declaration definition
of the C function, since that's where the cross-language linkage
happens, so currently one needs to assume that the C function always
has the cost of an actual function call.

As for inlining the actual callee method of interest in the language
being called into the implementation of the C function, it may or may
not happen automatically and when it doesn't happen automatically,
forcing it to happen manually might be a problem in terms of code
size.

So when the callee that actually does the work we care about doesn't
get inlined into its C wrapper, one should approximate a call from
Rust to C++ or from C++ to Rust have the cost of two *non-virtual*
function calls instead of one. (It would be interesting to contrast
this to the cost of over-use of virtual calls due to nsIFoo
interfaces.)

- -

Ideally, both the caller-language-side wrapper around the C function
and the C function itself would get inlined so that the cross-language
call would on the machine code level look just like a normal (if not
also inlined!) call to a method of the callee language. For that to
happen, we'd need link-time inlining across object files produced by
different-language compilers.

Naïvely, one would think that it should be possible to do that with
clang producing "object files" holding LLVM IR and rustc prod

Re: Heads up! Building Stylo in local developer builds

[Chris Peterson]

If you now see Mac compilation errors about "stdlib.h not found", try 
running `xcode-select --install`.


Part of the Stylo build process (rust-bindgen) can get confused about 
which clang header #include paths it should use. xcode-select can fix 
this. Bug 1366564 is a feature request for mach bootstrap to run 
xcode-select automatically.



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: Only build the Gecko-dev html parser

[Henri Sivonen]

On Thu, Jul 20, 2017 at 11:00 PM,   wrote:
> Hi everyone, as title, I want to use the C/C++ to research the Gecko-dev html 
> parser.
> Is it possible to build the Gecko-dev html parser?
>
> https://github.com/mozilla/gecko-dev/tree/e9fa5c772abe4426c5e33ffe61c438f75f990aca/parser

What kind of research?

That directory as a whole can't be used outside the context of Gecko.

However, the core parts of both the HTML parser and the XML parser are
available separately.

The core of the HTML parser is written in Java (there's a translator
program the translates it into C++ for use in Gecko) and can be run
(as Java) in isolation of Gecko:
https://hg.mozilla.org/projects/htmlparser/

In theory, it would be possible to edit the translator to support a
non-Gecko translation target alongside the Gecko-coupled target, but
that hasn't happened because first I had other stuff to do and then
https://github.com/google/gumbo-parser showed up and ended the demand
for a standalone C++ translation.

The core of the XML parser is expat, which, of course, is available as
an independent piece of software.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Byron Jones]

yes - 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch 
covers this.


please read all of the document linked by cameron and this one.


-glob

Enrico Weigelt, metux IT consult wrote:

On 31.07.2017 09:23, Cameron McCormack wrote:

Hi Enrico,

Firefox patches should be submitted via Bugzilla, rather than by email
to dev-platform. Please see:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed



Is there a way to submit via mail ? Or some git-send-email counterpart ?

Always going through the web frontend manually would be pretty time
consuming ...


--mtx


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

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

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Enrico Weigelt, metux IT consult]

On 31.07.2017 09:23, Cameron McCormack wrote:

Hi Enrico,

Firefox patches should be submitted via Bugzilla, rather than by email
to dev-platform.  Please see:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed


Is there a way to submit via mail ? Or some git-send-email counterpart ?

Always going through the web frontend manually would be pretty time
consuming ...


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

[PATCH] gfx: 2d: DrawTargetCairo: drop unused surface types

[Enrico Weigelt, metux IT consult]

Signed-off-by: Enrico Weigelt, metux IT consult 
---
 gfx/2d/DrawTargetCairo.cpp | 10 --
 1 file changed, 10 deletions(-)

diff --git a/gfx/2d/DrawTargetCairo.cpp b/gfx/2d/DrawTargetCairo.cpp
index c0e4f0af2..66e3f8854 100644
--- a/gfx/2d/DrawTargetCairo.cpp
+++ b/gfx/2d/DrawTargetCairo.cpp
@@ -642,31 +642,21 @@ DrawTargetCairo::GetType() const
 case CAIRO_SURFACE_TYPE_PS:
 case CAIRO_SURFACE_TYPE_SVG:
 case CAIRO_SURFACE_TYPE_WIN32_PRINTING:
-case CAIRO_SURFACE_TYPE_XML:
   return DrawTargetType::VECTOR;
 
-case CAIRO_SURFACE_TYPE_VG:
-case CAIRO_SURFACE_TYPE_GL:
-case CAIRO_SURFACE_TYPE_GLITZ:
 case CAIRO_SURFACE_TYPE_QUARTZ:
-case CAIRO_SURFACE_TYPE_DIRECTFB:
   return DrawTargetType::HARDWARE_RASTER;
 
-case CAIRO_SURFACE_TYPE_SKIA:
 case CAIRO_SURFACE_TYPE_QT:
   MOZ_FALLTHROUGH_ASSERT("Can't determine actual DrawTargetType for 
DrawTargetCairo - assuming SOFTWARE_RASTER");
 case CAIRO_SURFACE_TYPE_IMAGE:
 case CAIRO_SURFACE_TYPE_XLIB:
 case CAIRO_SURFACE_TYPE_XCB:
 case CAIRO_SURFACE_TYPE_WIN32:
-case CAIRO_SURFACE_TYPE_BEOS:
-case CAIRO_SURFACE_TYPE_OS2:
 case CAIRO_SURFACE_TYPE_QUARTZ_IMAGE:
-case CAIRO_SURFACE_TYPE_SCRIPT:
 case CAIRO_SURFACE_TYPE_RECORDING:
 case CAIRO_SURFACE_TYPE_DRM:
 case CAIRO_SURFACE_TYPE_SUBSURFACE:
-case CAIRO_SURFACE_TYPE_TEE: // included to silence warning about 
unhandled enum value
   return DrawTargetType::SOFTWARE_RASTER;
 default:
   MOZ_CRASH("GFX: Unsupported cairo surface type");
-- 
2.11.0.rc0.7.gbe5a750

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

[PATCH] mfbt: Poison: drop obsolete OS2 support

[Enrico Weigelt, metux IT consult]

Signed-off-by: Enrico Weigelt, metux IT consult 
---
 mfbt/Poison.cpp | 34 +-
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/mfbt/Poison.cpp b/mfbt/Poison.cpp
index b2767011d..e9981764f 100644
--- a/mfbt/Poison.cpp
+++ b/mfbt/Poison.cpp
@@ -14,7 +14,7 @@
 #include "mozilla/Assertions.h"
 #ifdef _WIN32
 # include 
-#elif !defined(__OS2__)
+#else
 # include 
 # include 
 # ifndef MAP_ANON
@@ -76,38 +76,6 @@ GetDesiredRegionSize()
 
 #define RESERVE_FAILED 0
 
-#elif defined(__OS2__)
-static void*
-ReserveRegion(uintptr_t aRegion, uintptr_t aSize)
-{
-  // OS/2 doesn't support allocation at an arbitrary address,
-  // so return an address that is known to be invalid.
-  return (void*)0xFFFD;
-}
-
-static void
-ReleaseRegion(void* aRegion, uintptr_t aSize)
-{
-  return;
-}
-
-static bool
-ProbeRegion(uintptr_t aRegion, uintptr_t aSize)
-{
-  // There's no reliable way to probe an address in the system
-  // arena other than by touching it and seeing if a trap occurs.
-  return false;
-}
-
-static uintptr_t
-GetDesiredRegionSize()
-{
-  // Page size is fixed at 4k.
-  return 0x1000;
-}
-
-#define RESERVE_FAILED 0
-
 #else // Unix
 
 #include "mozilla/TaggedAnonymousMemory.h"
-- 
2.11.0.rc0.7.gbe5a750

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

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Anne van Kesteren]

Hey Enrico, patches are certainly appreciated, but please attach them
(and corresponding rationale) to bugs instead. This one should
probably go here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics.
dev-platform has a ton of subscribers and is really only meant for
more high-level discussion. Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Cameron McCormack]

Hi Enrico,

Firefox patches should be submitted via Bugzilla, rather than by email
to dev-platform.  Please see:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed

Thanks,

Cameron

On Mon, Jul 31, 2017, at 03:14 PM, Enrico Weigelt, metux IT consult
wrote:
> ...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[PATCH] old-configure: startupcache: check for zipwriter

[Enrico Weigelt, metux IT consult]

startupcache depends on zipwriter.
when enabled, check that zipwriter is also enabled.

Signed-off-by: Enrico Weigelt, metux IT consult 
---
 old-configure.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/old-configure.in b/old-configure.in
index daa593bfa..d76ebd547 100644
--- a/old-configure.in
+++ b/old-configure.in
@@ -4662,6 +4662,10 @@ if test -n "$MOZ_B2G"; then
 fi
 if test -n "$MOZ_DISABLE_STARTUPCACHE"; then
   AC_DEFINE(MOZ_DISABLE_STARTUPCACHE)
+else
+  if test -z "$MOZ_ZIPWRITER" ; then
+AC_ERROR([startup cache depends on --enable-zipwriter])
+  fi
 fi
 AC_SUBST(MOZ_DISABLE_STARTUPCACHE)
 
-- 
2.11.0.rc0.7.gbe5a750

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

[PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Enrico Weigelt, metux IT consult]

For now, our GfxSurfaceType enum (and things depending on it) is tightly
coupled to cairo_surface_type_t, which is bad for encapsulation. And we're
also tightly coupled to the current, meanwhile pretty old and customized
in-tree version of cairo.

To reduce maintenance burden and as a first step towards using future
use of external cairo, decouple these types. The overhead is minimal:
gfxASurface::GetType() now uses a small switch statement (compilers have
many ways for good optimizations), and the function doesn't seem to
be a hot path.

Note that this patch also drops values that aren't used by mozilla.
Also fix the value for invalid surface type: some sites used -1, while
others used Max.

Alternative options could be:

* directly alias it to cairo_surface_t (and also for similar enums)
  pro: less code
  con: more coupled to cairo api
  * only makes sense of we do it for other enums, too
  * consequently, we could also think about the gfx layer completely
(except some small cairo surface reference type - autoptr derivative
which calls cairo's ref/unref functions) and just add some helpers
that operate on cairo API directly - reduce even more own code
* store the gfxSurfaceType value in the gfxASurface instances (so the
  value mapping only has to be done once, on init)
* make GfxSurfaceType a class, that holds the cairo_surface_type_t along
  w/ other information (eg. like SurfaceMemoryReporterAttrs, ...) and use
  references instead of enum values.
---
 dom/plugins/ipc/PluginInstanceChild.cpp |  4 +--
 gfx/ipc/GfxMessageUtils.h   |  2 +-
 gfx/thebes/gfxASurface.cpp  | 57 +
 gfx/thebes/gfxTypes.h   | 18 +++
 4 files changed, 36 insertions(+), 45 deletions(-)

diff --git a/dom/plugins/ipc/PluginInstanceChild.cpp 
b/dom/plugins/ipc/PluginInstanceChild.cpp
index af9db9103..940687bcc 100644
--- a/dom/plugins/ipc/PluginInstanceChild.cpp
+++ b/dom/plugins/ipc/PluginInstanceChild.cpp
@@ -183,7 +183,7 @@ PluginInstanceChild::PluginInstanceChild(const 
NPPluginFuncs* aPluginIface,
 #endif
 , mAccumulatedInvalidRect(0,0,0,0)
 , mIsTransparent(false)
-, mSurfaceType(gfxSurfaceType::Max)
+, mSurfaceType(gfxSurfaceType::Invalid)
 , mPendingPluginCall(false)
 , mDoAlphaExtraction(false)
 , mHasPainted(false)
@@ -3395,7 +3395,7 @@ PluginInstanceChild::DoAsyncSetWindow(const 
gfxSurfaceType& aSurfaceType,
 bool
 PluginInstanceChild::CreateOptSurface(void)
 {
-MOZ_ASSERT(mSurfaceType != gfxSurfaceType::Max,
+MOZ_ASSERT(mSurfaceType != gfxSurfaceType::Invalid,
"Need a valid surface type here");
 NS_ASSERTION(!mCurrentSurface, "mCurrentSurfaceActor can get out of 
sync.");
 
diff --git a/gfx/ipc/GfxMessageUtils.h b/gfx/ipc/GfxMessageUtils.h
index e45aa7040..3268b36d8 100644
--- a/gfx/ipc/GfxMessageUtils.h
+++ b/gfx/ipc/GfxMessageUtils.h
@@ -202,7 +202,7 @@ template <>
 struct ParamTraits
   : public ContiguousEnumSerializer<
  gfxSurfaceType,
- gfxSurfaceType::Image,
+ gfxSurfaceType::First,
  gfxSurfaceType::Max>
 {};
 
diff --git a/gfx/thebes/gfxASurface.cpp b/gfx/thebes/gfxASurface.cpp
index 31f185596..5020d1596 100644
--- a/gfx/thebes/gfxASurface.cpp
+++ b/gfx/thebes/gfxASurface.cpp
@@ -207,9 +207,24 @@ gfxSurfaceType
 gfxASurface::GetType() const
 {
 if (!mSurfaceValid)
-return (gfxSurfaceType)-1;
+return gfxSurfaceType::Invalid;
+
+switch (cairo_surface_get_type(mSurface)) {
+case CAIRO_SURFACE_TYPE_IMAGE:  return gfxSurfaceType::Image;
+case CAIRO_SURFACE_TYPE_PDF:return gfxSurfaceType::PDF;
+case CAIRO_SURFACE_TYPE_PS: return gfxSurfaceType::PS;
+case CAIRO_SURFACE_TYPE_XLIB:   return gfxSurfaceType::Xlib;
+case CAIRO_SURFACE_TYPE_XCB:return gfxSurfaceType::Xcb;
+case CAIRO_SURFACE_TYPE_QUARTZ: return gfxSurfaceType::Quartz;
+case CAIRO_SURFACE_TYPE_WIN32:  return gfxSurfaceType::Win32;
+case CAIRO_SURFACE_TYPE_SVG:return gfxSurfaceType::SVG;
+case CAIRO_SURFACE_TYPE_WIN32_PRINTING: return 
gfxSurfaceType::Win32Printing;
+case CAIRO_SURFACE_TYPE_QT: return 
gfxSurfaceType::QPainter;
+case CAIRO_SURFACE_TYPE_RECORDING:  return 
gfxSurfaceType::Recording;
+case CAIRO_SURFACE_TYPE_SUBSURFACE: return 
gfxSurfaceType::Subsurface;
+}
 
-return (gfxSurfaceType)cairo_surface_get_type(mSurface);
+return gfxSurfaceType::Invalid;
 }
 
 gfxContentType
@@ -427,40 +442,26 @@ struct SurfaceMemoryReporterAttrs {
 };
 
 static const SurfaceMemoryReporterAttrs sSurfaceMemoryReporterAttrs[] = {
-{"gfx-surface-image", nullptr},
-{"gfx-surface-pdf", nullptr},
-{"gfx-surface-ps", nullptr},
-{"gfx-surface-xlib",
+[gfxSurfaceType::Image] = { "gfx-surface-image" },
+[gfxSurfaceType::PDF