Re: [blink-dev] Fwd: [Bug 441414] Treerows need a way to hold richer content

[Yonggang Luo]

在 2015年1月13日星期二 UTC+8上午12:08:24，Elliott Sprehn写道：
> On Fri, Jan 9, 2015 at 10:38 AM, Jan Varga  wrote:
> 
> > HTML5 spec used to have something like that called 
> > Here's some info:
> > https://bugs.webkit.org/show_bug.cgi?id=26545
> >
> > As a former contributor to XUL tree widget, I would love to see a similar
> > widget in HTML5.
> >
> >
> In general complex widgets like this are better built as libraries instead
> of into the platform itself.
That's depends on the if the feature can be build in libraries, at the current 
time,
I didn't see the capable to building such a feature directly in libraries
> 
> 
> > Jan
> >
> >
> > On 09/01/15 19:18, Philipp Kewisch wrote:
> >
> >> I think the question is rather if there is an interest to create a
> >> HTML5-equivalent of the XUL tree that has a similar or matching feature
> >> set.
> >>
> >> The main features required are being able to handle a datastore that has
> >> 10k+ rows by lazy loading (and unloading) the data into DOM nodes,
> >> hierarchical data view with ability to collapse levels, and columns that
> >> can be shown and hidden.
> >>
> >> I know there are a few table data libraries on the web, many of them use
> >> jquery. It would be nice to create/use something self-containing that
> >> doesn't require external libraries.
> >>
> >> The limiting factor is obviously time, but I would love to experiment
> >> with a HTML5 drop-in replacement that understands nsITreeView and friends.
> >>
> >> Philipp
> >>
> >> On 1/9/15 10:56 AM, PhistucK wrote:
> >>
> >>> XUL is explicitly not implemented at all in Chrome, so I would not count
> >>> on
> >>> it being implemented in any form.
> >>>
> >>>
> >>> ☆*PhistucK*
> >>>
> >>> On Fri, Jan 9, 2015 at 8:32 AM, 罗勇刚(Yonggang Luo)  >>> >
> >>> wrote:
> >>>
> >>>  Does anybody have the intention to implement the things like XUL:tree
>  in HTML5 with power functional.
>  Such as scroll by pixel, and each cell can be either  or 
> 
> 
> 
>  -- Forwarded message --
>  From: Bugzilla@Mozilla 
>  Date: 2015-01-09 5:34 GMT+08:00
>  Subject: [Bug 441414] Treerows need a way to hold richer content
>  To: luoyongg...@gmail.com
> 
> 
>  Do not reply to this email. You can add comments to this bug at
>  https://bugzilla.mozilla.org/show_bug.cgi?id=441414
> 
>  David Baron [:dbaron] (UTC-8) (needinfo? for questions)
>   changed:
> 
>  What|Removed |Added
> 
>  
>  
> Flags|needinfo?(dba...@dbaron.org |
>  |)   |
> 
>  --- Comment #204 from David Baron [:dbaron] (UTC-8) (needinfo? for
>  questions)  2015-01-08 13:34:46 PST ---
>  (In reply to Yonggang Luo from comment #195)
> 
> > (In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions)
> > from
> > comment #194)
> >
> >> Comment on attachment 8497672
> >> 0005-Fixes-for-bug-441414-to-add-rich-tree-support-crasht.patch
> >>
> >> As discussed in dev-platform, we don't want to take major feature
> >> improvements to XUL.
> >>
> > I didn't see any HTML5 equivalent for XUL tree element.
> > And this should not be a major feature improvements.
> >
>  This is a major feature; major features add substantial maintenance cost
>  over
>  time, and we're not interested in adding to that cost by adding
>  additional
>  XUL
>  features.
> 
>  --
>  Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email
> 
>  ---
>  Product/Component: Core :: XUL
> 
> 
> 
>  --- You are receiving this mail because: ---
>  You voted for the bug.
>  You are on the CC list for the bug.
> 
> 
> 
>  --
>    此致
>  礼
>  罗勇刚
>  Yours
>   sincerely,
>  Yonggang Luo
> 
>  To unsubscribe from this group and stop receiving emails from it, send
>  an
>  email to blink-dev+unsubscr...@chromium.org.
> 
>   ___
> >> 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: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Steve Fink]

On 01/15/2015 04:52 PM, Ehsan Akhgari wrote:
> On 2015-01-15 7:30 PM, Steve Fink wrote:
>> On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
>>> On 2015-01-14 8:37 PM, Steve Fink wrote:
 On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
>   From now on, the only supported build mode is unified
> compilation.  I
> am planning to follow-up with removing support for the
> --disable-unified-compilation configure option altogether in bug
> 1121000.

 I commented in the bug, but I guess this is probably a better forum.

 Why is the configure option being removed?
>>>
>>> Because unsupported build configurations that are *guaranteed* to not
>>> be maintained are not worth keeping around.  I am 90% sure that
>>> --disable-unified-compilation would have been broken since yesterday.
>>> :-)
>>
>> But that's not the point. I totally agree that non-unified builds will
>> get broken immediately and will stay broken most of the time. That's not
>> in question. The point is how hard it is for someone who comes along and
>> wants to fix our codebase to be valid C++, even if that fix is not
>> permanent.
>>
>> Specifically, what I imagine happening is this: we start out nowish with
>> nonunified builds working. Within a day, they're busted. After some
>> time, somebody who gains from them being correct wants to fix them, and
>> uses --disable-unified-builds to do so. Rinse, repeat. The amount of
>> breakage to fix each time is determined by the time between fixes.
>>
>> If this hypothetical person has to go through every moz.build and change
>> UNIFIED_SOURCES to SOURCES, or FILES_PER_UNIFIED_FILE to 1, then they're
>> less likely to do it, and the interval between fixes will grow, and
>> eventually the code base will be rotten enough that nobody will want to
>> deal with it. Oh, except that people will occasionally add new files and
>> uncover breakage that wasn't their fault because they shift around the
>> boundaries. Which isn't awful, because you'll only have to fix a
>> localized area, but it is guaranteed to baffle many of the people who
>> hit it until they've been educated. More overhead to contributing, more
>> "specialness" in our codebase.
>>
>> If you were saying that the --disable-unified-builds mechanism itself is
>> likely to break, then I couldn't really argue with removing it. Is there
>> a simpler way to accomplish the same thing? A
>> FORCE_MAX_FILES_PER_UNIFIED_FILE_EVERYWHERE=1 setting in the toplevel
>> moz.build or something? It doesn't need to be pretty, but it should be
>> easier than
>>
>>for f in **/moz.build; do echo "FILES_PER_UNIFIED_FILE=1" >> $f; done
>>
>> (assuming that even works, and note that you'll need zsh for the '**'
>> thing).
>
> There are many ways to force UNIFIED_SOURCES to be built in
> non-unified mode.  Reverting my patch is one of them.  Applying the
> following patch is another:
>
> diff --git a/python/mozbuild/mozbuild/backend/recursivemake.py
> b/python/mozbuild/mozbuild/backend/recursivemake.py
> index 608f6f5..de754b6 100644
> --- a/python/mozbuild/mozbuild/backend/recursivemake.py
> +++ b/python/mozbuild/mozbuild/backend/recursivemake.py
> @@ -394,7 +394,7 @@ class RecursiveMakeBackend(CommonBackend):
>  non_unified_var = var[len('UNIFIED_'):]
>
>  files_per_unification = obj.files_per_unified_file
> -do_unify = files_per_unification > 1
> +do_unify = False
>  # Sorted so output is consistent and we don't bump mtimes.
>  source_files = list(sorted(obj.files))

This is a little cryptic, but something similar to this does seem
preferable to keeping all of the code for --disable-unified-compilation.
It just needs to be discoverable by the people who would usefully
discover it.

> Part of what you're complaining about above is not about removing
> support for the configure option, it's about dropping support for
> non-unified builds on infrastructure.

No, because I agree with that decision.

>   Yes, there are definitely downsides to what we decided to do.  Our
> code is no longer "valid C++" (which honestly is a very arbitrary line
> -- our code has never been valid C++ from a puristic standpoint any
> way because of all of the compiler specific extensions that we use).  

I don't think that's really fair. I don't give a rip about sticking to
only c++0x or whatever. Our code conforms to an even stricter standard,
namely the common subset supported by a collection of different compilers.

What I'm concerned about is code that doesn't compile on any compiler if
you do it the "normal" way, one file at a time. Code that uses symbols
that are totally unknown or not in any using'd namespace. Code referring
to mysterious ALL_CAPS_SYMBOLS (that happen to be defined as macros in
headers that are not #included.) Code that depends on template
specializations from a non-included file for correctness. Unified
compilation creates dummy .cpp files that #include  and  and
force th

Re: Network Predictive Actions re-enabled on Nightly

[Patrick Cloke]

On 1/15/2015 9:03 PM, Nicholas Hurley wrote:

Patrick,

The predictor may issue dns requests or start connections (including TLS
negotiations, if necessary) entirely based on browsing history combined
with a confidence calculation (the details of which are in the code, but
intentionally left vague via email because they may change in order to
improve performance/privacy/some other concern). To be clear, we aren't
randomly guessing at what to do, and we won't do anything the user hasn't
intentionally done at least once before.


I did not think you were randomly guessing, I guess I'm not convinced 
the browser is able to tell what the user has "intentionally" done.



Also, I will note that this feature went through privacy review when it
first landed (details/results at
https://wiki.mozilla.org/Privacy/Reviews/Necko), and "passed" (if that's
the right word) with flying colors. This new landing doesn't change any of
the results of that, it's purely an implementation detail to reduce jank
and CPU usage caused by the feature.


Thanks for providing this link, it's quite interesting (and I'd suggest 
in the future including links to privacy reviews when announcing 
features whenever there might be a privacy concern!)



Beyond that, it's hard to address any perceived "privacy ramifications"
without knowing people's particular concerns. (As you noted, for the truly
privacy paranoid among us, the feature is easy to disable via about:config.)


(Call this "paranoid", if you must...) I'm not a huge fan of DNS 
requests being sent to sites unnecessarily, even if I've been there 
before. It could potentially leak information about browsing habits 
(i.e. if I'm online or what sites I'm visiting). (I'm sure the argument 
against this is that it's unlikely much private information would be 
sent this way unless someone was giving each user a separate sub-domain 
with super short TTL, but hey people do crazy things. Besides, local IPs 
don't really seem to change frequently, at least not in the US...so it 
probably isn't hard to tell track if it's me. There's also some 
techniques to fingerprint off of TLS negotiation, I'm unsure how far 
this gets in that connection, however.) These may or may not be real 
concerns, but they're what I immediately thought of when reading your post.


Even if not a large privacy concern, I doubt I'll see a beneficial 
tradeoff from reducing my connection times by 100ms. I'm sure other 
people will find this super beneficial, however. I'll probably give it a 
try before deciding what to do, see if it seems to make a difference.


Thanks for taking the time to respond!

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

Re: W3C Proposed Recommendation: Pointer Events

[L. David Baron]

On Tuesday 2015-01-06 15:14 -0800, L. David Baron wrote:
> W3C recently published the following proposed recommendation (the
> stage before W3C's final stage, Recommendation):
> 
>   http://www.w3.org/TR/pointerevents/
>   Pointer Events
> 
> There's a call for review to W3C member companies (of which Mozilla
> is one) open until January 16.
> 
> If there are comments you think Mozilla should send as part of the
> review, or if you think Mozilla should voice support or opposition
> to the specification, please say so in this thread.  (I'd note,
> however, that there have been many previous opportunities to make
> comments, so it's somewhat bad form to bring up fundamental issues
> for the first time at this stage.)

While it's not quite clear what's going to happen to this spec in
the long term given that there's some opposition to the events part
(although not 'touch-action') from Google (related to whether the
API requires certain touch operations to communicate with the main
thread when they don't want it to; a problem other implementors
including us don't seem to have), given that it seems like a better
(than Touch Events) API for developers and we've been involved in
its development, I voted in support.

-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: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Vibration API

[L. David Baron]

On Tuesday 2015-01-06 15:15 -0800, L. David Baron wrote:
> W3C recently published the following proposed recommendation (the
> stage before W3C's final stage, Recommendation):
> 
>   http://www.w3.org/TR/vibration/
>   Vibration API
> 
> There's a call for review to W3C member companies (of which Mozilla
> is one) open until January 20.

Given that we implement it, and after a brief discussion with Jonas,
I voted in support.

-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: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Network Predictive Actions re-enabled on Nightly

[Nicholas Hurley]

Patrick,

The predictor may issue dns requests or start connections (including TLS
negotiations, if necessary) entirely based on browsing history combined
with a confidence calculation (the details of which are in the code, but
intentionally left vague via email because they may change in order to
improve performance/privacy/some other concern). To be clear, we aren't
randomly guessing at what to do, and we won't do anything the user hasn't
intentionally done at least once before.

Also, I will note that this feature went through privacy review when it
first landed (details/results at
https://wiki.mozilla.org/Privacy/Reviews/Necko), and "passed" (if that's
the right word) with flying colors. This new landing doesn't change any of
the results of that, it's purely an implementation detail to reduce jank
and CPU usage caused by the feature.

Beyond that, it's hard to address any perceived "privacy ramifications"
without knowing people's particular concerns. (As you noted, for the truly
privacy paranoid among us, the feature is easy to disable via about:config.)

-Nick

On Thu, Jan 15, 2015 at 7:48 PM, Patrick Cloke  wrote:

> On 1/15/2015 12:26 PM, Nicholas Hurley wrote:
>
>> All,
>>
>> I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1009122 on
>> mozilla-inbound, which re-enables necko's predictive actions capabilities.
>> I won't go into the full explanation of it here, you can find the big
>> information (very little of which has changed in this new iteration) in my
>> original post,
>> https://groups.google.com/d/msg/mozilla.dev.platform/
>> tAnuc-J0DbY/snrGsOVW1MAJ
>>
>> The big thing to note about this landing is that data is now stored in the
>> disk cache instead of sqlite, which means the predictor (formerly "seer")
>> should not be causing jank or excessive cpu usage any more (hooray!) This
>> rewrite also keeps the improvements in page load time seen in the previous
>> iteration (see previous message linked above for details).
>>
>> This is currently enabled on desktop and android, and disabled on b2g, as
>> e10s support is not fully there in the predictor yet. To be clear - this
>> will not break anywhere e10s is enabled, it's just a no-op for now if e10s
>> is enabled. Work on e10s support is proceeding in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=959752 (feel free to follow
>> along if you wish).
>>
>> Any bugs you encounter with this feature enabled, please file a followup
>> blocking 1009122.
>>
>> -Nick
>>
>>
> Nick,
>
> I just read through your previous post and I'm underwhelmed by the detail
> in it. Can you go into more detail about how it "may" issue speculative DNS
> lookups/SSL negotiations? It seems to have some privacy ramifications that
> I think deserve a more thorough explanation.
>
> For anyone else who's curious, it seems you can disable this by setting
> "network.predictor.enabled" to false in about:config (or by using e10s it
> seems ;) ).
>
> Thanks,
> Patrick
> ___
> 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: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Ehsan Akhgari]

On 2015-01-15 7:30 PM, Steve Fink wrote:

On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:

On 2015-01-14 8:37 PM, Steve Fink wrote:

On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:

  From now on, the only supported build mode is unified compilation.  I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug
1121000.


I commented in the bug, but I guess this is probably a better forum.

Why is the configure option being removed?


Because unsupported build configurations that are *guaranteed* to not
be maintained are not worth keeping around.  I am 90% sure that
--disable-unified-compilation would have been broken since yesterday.
:-)


But that's not the point. I totally agree that non-unified builds will
get broken immediately and will stay broken most of the time. That's not
in question. The point is how hard it is for someone who comes along and
wants to fix our codebase to be valid C++, even if that fix is not
permanent.

Specifically, what I imagine happening is this: we start out nowish with
nonunified builds working. Within a day, they're busted. After some
time, somebody who gains from them being correct wants to fix them, and
uses --disable-unified-builds to do so. Rinse, repeat. The amount of
breakage to fix each time is determined by the time between fixes.

If this hypothetical person has to go through every moz.build and change
UNIFIED_SOURCES to SOURCES, or FILES_PER_UNIFIED_FILE to 1, then they're
less likely to do it, and the interval between fixes will grow, and
eventually the code base will be rotten enough that nobody will want to
deal with it. Oh, except that people will occasionally add new files and
uncover breakage that wasn't their fault because they shift around the
boundaries. Which isn't awful, because you'll only have to fix a
localized area, but it is guaranteed to baffle many of the people who
hit it until they've been educated. More overhead to contributing, more
"specialness" in our codebase.

If you were saying that the --disable-unified-builds mechanism itself is
likely to break, then I couldn't really argue with removing it. Is there
a simpler way to accomplish the same thing? A
FORCE_MAX_FILES_PER_UNIFIED_FILE_EVERYWHERE=1 setting in the toplevel
moz.build or something? It doesn't need to be pretty, but it should be
easier than

   for f in **/moz.build; do echo "FILES_PER_UNIFIED_FILE=1" >> $f; done

(assuming that even works, and note that you'll need zsh for the '**'
thing).


There are many ways to force UNIFIED_SOURCES to be built in non-unified 
mode.  Reverting my patch is one of them.  Applying the following patch 
is another:


diff --git a/python/mozbuild/mozbuild/backend/recursivemake.py 
b/python/mozbuild/mozbuild/backend/recursivemake.py

index 608f6f5..de754b6 100644
--- a/python/mozbuild/mozbuild/backend/recursivemake.py
+++ b/python/mozbuild/mozbuild/backend/recursivemake.py
@@ -394,7 +394,7 @@ class RecursiveMakeBackend(CommonBackend):
 non_unified_var = var[len('UNIFIED_'):]

 files_per_unification = obj.files_per_unified_file
-do_unify = files_per_unification > 1
+do_unify = False
 # Sorted so output is consistent and we don't bump mtimes.
 source_files = list(sorted(obj.files))


Part of what you're complaining about above is not about removing 
support for the configure option, it's about dropping support for 
non-unified builds on infrastructure.  Yes, there are definitely 
downsides to what we decided to do.  Our code is no longer "valid C++" 
(which honestly is a very arbitrary line -- our code has never been 
valid C++ from a puristic standpoint any way because of all of the 
compiler specific extensions that we use).  And yes, there will be the 
potential for breakage when you add or remove unified sources.  And that 
breakage would not be your fault, and you would need to be educated 
about what's going on, unless you have experience with another project 
that uses the same idea (which is unlikely.)


But there are upsides too.  You won't get backed out because you broke a 
build configuration that we do not ship.  We don't pay the monetary and 
human resource cost of keeping it working.  And you will get *fast* 
builds.  I'd like to remind folks that unified builds improved our build 
times by more than 2x.


So it is a trade-off.  It's completely fine if you disagree on the call 
that we made there, but I'd like to keep that conversation separate with 
the one about how to build the tree locally in non-unified mode.


For the latter conversation, there are multiple ways.  I don't think we 
should accept such patches because 1) we already have too many 
configure/etc options that break your build, and we keep problem reports 
from people who have options in their mozconfigs that are unsupported 
and cause broken builds (Please see the archives of 
.) and

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Martin Thomson]

On Thu, Jan 15, 2015 at 4:30 PM, Steve Fink  wrote:

> But that's not the point. I totally agree that non-unified builds will
> get broken immediately and will stay broken most of the time. That's not
> in question. The point is how hard it is for someone who comes along and
> wants to fix our codebase to be valid C++, even if that fix is not
> permanent.


Why would that even be a goal?  If the project builds, is that not
sufficient?  I don't see any value in some platonic "correctness".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Network Predictive Actions re-enabled on Nightly

[Patrick Cloke]

On 1/15/2015 12:26 PM, Nicholas Hurley wrote:

All,

I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1009122 on
mozilla-inbound, which re-enables necko's predictive actions capabilities.
I won't go into the full explanation of it here, you can find the big
information (very little of which has changed in this new iteration) in my
original post,
https://groups.google.com/d/msg/mozilla.dev.platform/tAnuc-J0DbY/snrGsOVW1MAJ

The big thing to note about this landing is that data is now stored in the
disk cache instead of sqlite, which means the predictor (formerly "seer")
should not be causing jank or excessive cpu usage any more (hooray!) This
rewrite also keeps the improvements in page load time seen in the previous
iteration (see previous message linked above for details).

This is currently enabled on desktop and android, and disabled on b2g, as
e10s support is not fully there in the predictor yet. To be clear - this
will not break anywhere e10s is enabled, it's just a no-op for now if e10s
is enabled. Work on e10s support is proceeding in
https://bugzilla.mozilla.org/show_bug.cgi?id=959752 (feel free to follow
along if you wish).

Any bugs you encounter with this feature enabled, please file a followup
blocking 1009122.

-Nick



Nick,

I just read through your previous post and I'm underwhelmed by the 
detail in it. Can you go into more detail about how it "may" issue 
speculative DNS lookups/SSL negotiations? It seems to have some privacy 
ramifications that I think deserve a more thorough explanation.


For anyone else who's curious, it seems you can disable this by setting 
"network.predictor.enabled" to false in about:config (or by using e10s 
it seems ;) ).


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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Steve Fink]

On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
> On 2015-01-14 8:37 PM, Steve Fink wrote:
>> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
>>>  From now on, the only supported build mode is unified compilation.  I
>>> am planning to follow-up with removing support for the
>>> --disable-unified-compilation configure option altogether in bug
>>> 1121000.
>>
>> I commented in the bug, but I guess this is probably a better forum.
>>
>> Why is the configure option being removed?
>
> Because unsupported build configurations that are *guaranteed* to not
> be maintained are not worth keeping around.  I am 90% sure that
> --disable-unified-compilation would have been broken since yesterday. 
> :-)

But that's not the point. I totally agree that non-unified builds will
get broken immediately and will stay broken most of the time. That's not
in question. The point is how hard it is for someone who comes along and
wants to fix our codebase to be valid C++, even if that fix is not
permanent.

Specifically, what I imagine happening is this: we start out nowish with
nonunified builds working. Within a day, they're busted. After some
time, somebody who gains from them being correct wants to fix them, and
uses --disable-unified-builds to do so. Rinse, repeat. The amount of
breakage to fix each time is determined by the time between fixes.

If this hypothetical person has to go through every moz.build and change
UNIFIED_SOURCES to SOURCES, or FILES_PER_UNIFIED_FILE to 1, then they're
less likely to do it, and the interval between fixes will grow, and
eventually the code base will be rotten enough that nobody will want to
deal with it. Oh, except that people will occasionally add new files and
uncover breakage that wasn't their fault because they shift around the
boundaries. Which isn't awful, because you'll only have to fix a
localized area, but it is guaranteed to baffle many of the people who
hit it until they've been educated. More overhead to contributing, more
"specialness" in our codebase.

If you were saying that the --disable-unified-builds mechanism itself is
likely to break, then I couldn't really argue with removing it. Is there
a simpler way to accomplish the same thing? A
FORCE_MAX_FILES_PER_UNIFIED_FILE_EVERYWHERE=1 setting in the toplevel
moz.build or something? It doesn't need to be pretty, but it should be
easier than

  for f in **/moz.build; do echo "FILES_PER_UNIFIED_FILE=1" >> $f; done

(assuming that even works, and note that you'll need zsh for the '**'
thing).

>
> > I understand always building
>> unified in automation, but not having a straightforward way at all to
>> see if your code is buggy seems... suboptimal. If someone wants to go
>> through occasionally and make our codebase valid C++, how should they do
>> it after this change?
>
> Switch the UNIFIED_SOURCES variable to SOURCES in the moz.build file.
> That still works.
>


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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Ehsan Akhgari]

On 2015-01-15 6:46 PM, Seth Fowler wrote:

It wouldn’t be true of, say, a mach argument specifying directories that should 
be built non-unified.

Not that it matters nearly as much now that we’ve made the decision not to 
support non-unified builds.


Yeah that's true, but that mach command would break people's builds 
constantly.  I don't see any value in supporting that, *unless* we 
actually see a flurry of patches coming in to fix non-unified builds. 
When and if that happens, I would happily change my mind.  :-)


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

Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Application Security Working Group
  http://www.w3.org/2014/12/webappsec-charter-2015.html
  https://lists.w3.org/Archives/Public/public-new-work/2014Dec/0008.html

Mozilla has the opportunity to send comments, objections, or support
through Friday January 30.

Mozilla is involved in this working group; see membership at
https://www.w3.org/2000/09/dbwg/details?group=49309&public=1&order=org .

Please reply to this thread if you think there's something else we
should say, or if you think we should support the charter.

I'd note that the charter doesn't say anything about asynchronous
decision making, which is a bit unusual.

-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: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

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


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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Seth Fowler]

It wouldn’t be true of, say, a mach argument specifying directories that should 
be built non-unified.

Not that it matters nearly as much now that we’ve made the decision not to 
support non-unified builds.

> On Jan 15, 2015, at 3:36 PM, Ehsan Akhgari  wrote:
> 
> On 2015-01-15 5:57 PM, Seth Fowler wrote:
>> What’s a bit unfortunate about these approaches is that you can accidentally 
>> qref them into your patch. I’ve managed to do so repeatedly.
> 
> That's true of any local change, right?
> 

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Ehsan Akhgari]

On 2015-01-15 5:57 PM, Seth Fowler wrote:

What’s a bit unfortunate about these approaches is that you can accidentally 
qref them into your patch. I’ve managed to do so repeatedly.


That's true of any local change, right?

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

changed OSX variable in reftest/crashtest condition sandbox

[L. David Baron]

I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1121327
on mozilla-inbound, which changes the OSX variable in the
reftest-crashtest condition sandbox.  Instead of being a float
(which doesn't work very well for 10.10, which is equal to 10.1), it
is now an integer that is major*100 + minor.

It is also now undefined (rather than 0) for non-OSX platforms,
which means that >, <, <=, and >= comparisons with OSX should now
produce sensible results (since any such comparison with undefined
is false).

This means that:

  fails-if(OSX==1006) annotates a test that fails on Mac OS X 10.6
  fails-if(OSX==1010) annotates a test that fails on Mac OS X 10.10
  fails-if(OSX<=1008) annotates a test that fails on Mac OS X 10.8
  or older (but does not fail on other
  platforms, unless separately annotated)

If you have any annotations in your local patches, you'll need to
update them to the new syntax.

-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: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Seth Fowler]

What’s a bit unfortunate about these approaches is that you can accidentally 
qref them into your patch. I’ve managed to do so repeatedly.

- Seth

> On Jan 15, 2015, at 2:52 PM, Mike Hommey  wrote:
> 
> On Thu, Jan 15, 2015 at 02:11:16PM -0500, Benjamin Kelly wrote:
>> For what its worth, you can still verify individual directories by changing
>> moz.build to use SOURCES instead of UNIFIED_SOURCES.
> 
> On Thu, Jan 15, 2015 at 02:21:25PM -0500, Ehsan Akhgari wrote:
>> Switch the UNIFIED_SOURCES variable to SOURCES in the moz.build file. That
>> still works.
> 
> Instead of that, set FILES_PER_UNIFIED_FILE to 1.
> 
> Mike
> ___
> 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: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Mike Hommey]

On Thu, Jan 15, 2015 at 02:11:16PM -0500, Benjamin Kelly wrote:
> For what its worth, you can still verify individual directories by changing
> moz.build to use SOURCES instead of UNIFIED_SOURCES.

On Thu, Jan 15, 2015 at 02:21:25PM -0500, Ehsan Akhgari wrote:
> Switch the UNIFIED_SOURCES variable to SOURCES in the moz.build file. That
> still works.

Instead of that, set FILES_PER_UNIFIED_FILE to 1.

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

Re: W3C Proposed Recommendation: longdesc

[L. David Baron]

On Wednesday 2015-01-07 12:19 +0100, Marco Zehe wrote:
> On 07.01.2015 06:09, Robert O'Callahan wrote:
> > On Wed, Jan 7, 2015 at 3:37 PM, Jet Villegas  wrote:
> >> The main downside I see is a potential "Mozilla removes features used by
> >> disabled people..." PR fiasco. I think we can avoid that with a better
> >> proposal that we do support.
> > Maybe Marco Zehe would be interested in removing it :-).
> 
> I actually am not. ;) The reason is not that I care about this feature.
> I honestly don't. But the noise that is to be expected from "interested
> parties" if we remove the feature is going to suck so much unnecessary
> energy that the cost calculation is clearly tilted towards just leaving
> it in.
> 
> Besides: It does give us a competitive advantage over other browsers in
> the academic space and whereever other space longdesc may be used, or
> start being used once it is officially sanctioned by the W3C. Remember
> in accessibility world, the W3C word weighs much more than some on this
> list might think.

It's been officially sanctioned by the W3C since 1998:
http://www.w3.org/TR/1998/REC-html40-19980424/struct/objects.html#adef-longdesc-IMG
and that hasn't led to useful content using it.

> We could have decided to support Apple's formal complaint to longdesc
> when they published it in August[1], but we didn't. I didn't care enough
> to waste energy on it, and those who now speak out against the feature
> didn't appear to care much back then, either. So TBL rejected Apple's
> complaint, and the extension moved to the state it is at now.

In hindsight, I probably should have supported it, but I didn't want
to get involved.

-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: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: e10s content processes and coordinate systems

[Robert O'Callahan]

On Fri, Jan 16, 2015 at 9:24 AM, Handyman  wrote:

> I'm working on bug 1075670 ([e10s] event.screenX and event.screenY is
> wrong), which exposes a hole in the e10s architecture.  Quickly, the issue
> is that the dom behavior in an e10s content process redefines "screen"
> coordinates to be relative to the tab contents instead of relative to the
> physical screen (actually, the tab's dimensions are considered the screen
> dimensions).  This is probably in part because the chrome dom objects don't
> exist in the content process, so the ancestors of tab content are most
> easily ignored, but it has the unfortunate consequence that screen
> coordinates in the content process aren't actual screen coordinates.  And
> sometimes, we need real screen coordinates.
>
> This setup works in general and, in places where it doesn't, e10s seems to
> have been adapted to fit (for example, mouse event coordinates are
> specially handled by EventStateManager::GetChildProcessOffset via PBrowser,
> plugins use special routines in nsPluginInstanceOwner for all OOP
> coordinate-system calculations and the compositor... I'm not sure how it
> compensates but it must use a different mechanism for Compositors and
> CrossProcessCompositors, probably at the Layer level?).  But the metaphor
> fails when the content process communicates with objects outside of the
> engine, like client JS scripts (as in the bug's test case).
>
> I have a patch in the bug that fixes the calculation for the
> event.screenX/screenY and window.mozInnerScreenX/mozInnerScreenY fields but
> it is delicate.  It performs the right calculation in the content proc when
> the fields are fetched as JS values.  Obviously, this makes it easy for
> someone to use the wrong value in a calculation and get garbage out.  But
> at least we can (fairly easily) calculate the values if we know we need
> them.
>
> So the big picture is that we have introduced a new coordinate system in
> the content process (TabCoordinates) that are exactly like screen
> coordinates but located at a different origin.  This could possibly be
> incorporated into UnitTransforms as a new space but that seems like a
> seriously heavy duty solution.  Also, its not clear how to make that useful
> -- this setup seems to have been chosen so that parent and content
> processes can share formulas but this would mean that they would target
> different coordinate systems.  On top of all that, the coordinate system
> framework doesn't seem to have been built for this sort of purpose -- it
> seems to be for tracking scaling, not general Euclidean operations (so it
> would be hard to take advantage of).
>

Yeah, we don't want this.

I thought, given bug 1002354, that we could quite easily use the correct
screen coordinates for all PuppetWidget APIs.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

e10s content processes and coordinate systems

[Handyman]

Hey all,

I'm working on bug 1075670 ([e10s] event.screenX and event.screenY is wrong), 
which exposes a hole in the e10s architecture.  Quickly, the issue is that the 
dom behavior in an e10s content process redefines "screen" coordinates to be 
relative to the tab contents instead of relative to the physical screen 
(actually, the tab's dimensions are considered the screen dimensions).  This is 
probably in part because the chrome dom objects don't exist in the content 
process, so the ancestors of tab content are most easily ignored, but it has 
the unfortunate consequence that screen coordinates in the content process 
aren't actual screen coordinates.  And sometimes, we need real screen 
coordinates.

This setup works in general and, in places where it doesn't, e10s seems to have 
been adapted to fit (for example, mouse event coordinates are specially handled 
by EventStateManager::GetChildProcessOffset via PBrowser, plugins use special 
routines in nsPluginInstanceOwner for all OOP coordinate-system calculations 
and the compositor... I'm not sure how it compensates but it must use a 
different mechanism for Compositors and CrossProcessCompositors, probably at 
the Layer level?).  But the metaphor fails when the content process 
communicates with objects outside of the engine, like client JS scripts (as in 
the bug's test case).  

I have a patch in the bug that fixes the calculation for the 
event.screenX/screenY and window.mozInnerScreenX/mozInnerScreenY fields but it 
is delicate.  It performs the right calculation in the content proc when the 
fields are fetched as JS values.  Obviously, this makes it easy for someone to 
use the wrong value in a calculation and get garbage out.  But at least we can 
(fairly easily) calculate the values if we know we need them.

So the big picture is that we have introduced a new coordinate system in the 
content process (TabCoordinates) that are exactly like screen coordinates but 
located at a different origin.  This could possibly be incorporated into 
UnitTransforms as a new space but that seems like a seriously heavy duty 
solution.  Also, its not clear how to make that useful -- this setup seems to 
have been chosen so that parent and content processes can share formulas but 
this would mean that they would target different coordinate systems.  On top of 
all that, the coordinate system framework doesn't seem to have been built for 
this sort of purpose -- it seems to be for tracking scaling, not general 
Euclidean operations (so it would be hard to take advantage of).

At the other extreme, we could try to remove the TabCoordinates idea 
altogether.  The frame hierarchy could use a placeholder frame to represent 
chrome objects.  I don't know all of the repercussions to that call but it 
would be a hefty change, seriously affecting a number of components, as 
mentioned above.

I looked for out-of-the-box solutions (like repurposing the 'justification' 
concept in Units to try to make it clear why the transformation was being 
applied or augmenting the getters to request the value in the desired 
coordinate frame) but I didn't come up with anything that was more than 
cosmetically safer.  Is there a medium-scale solution to this problem or do we 
need one of the two nuclear options (new coord sys vs. e10s dom refactor)?  And 
if so, which one (and how)?

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Ehsan Akhgari]

On 2015-01-14 8:37 PM, Steve Fink wrote:

On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:

 From now on, the only supported build mode is unified compilation.  I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug 1121000.


I commented in the bug, but I guess this is probably a better forum.

Why is the configure option being removed?


Because unsupported build configurations that are *guaranteed* to not be 
maintained are not worth keeping around.  I am 90% sure that 
--disable-unified-compilation would have been broken since yesterday.  :-)


> I understand always building

unified in automation, but not having a straightforward way at all to
see if your code is buggy seems... suboptimal. If someone wants to go
through occasionally and make our codebase valid C++, how should they do
it after this change?


Switch the UNIFIED_SOURCES variable to SOURCES in the moz.build file. 
That still works.


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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Ehsan Akhgari]

On 2015-01-15 1:49 PM, Daniel Holbert wrote:

On 01/15/2015 09:46 AM, Chris Peterson wrote:

Another small benefit of optional non-unified builds is that clang does
a better job of reporting -Wunused-variable warnings with smaller
translation units. I assume that the number of identifiers in the
unified files exceed some clang analysis limit.


(I don't think it's a number-of-identifiers thing.

In the cases I've seen, e.g. bug 1008083, clang doesn't report some
variables as "unused" in #included files because it assumes the
#included thing is a header, and the variable might be used in some
*other* translation unit that includes this header.)


Yeah, that is definitely one of the implications of unified builds.

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Benjamin Kelly]

On Wed, Jan 14, 2015 at 8:37 PM, Steve Fink  wrote:

> Why is the configure option being removed? I understand always building
> unified in automation, but not having a straightforward way at all to
> see if your code is buggy seems... suboptimal. If someone wants to go
> through occasionally and make our codebase valid C++, how should they do
> it after this change?
>

For what its worth, you can still verify individual directories by changing
moz.build to use SOURCES instead of UNIFIED_SOURCES.

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Ehsan Akhgari]

On 2015-01-15 1:50 PM, Steve Fink wrote:

On 01/15/2015 09:39 AM, Sylvestre Ledru wrote:

On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:

On 2015/01/15 10:37, Steve Fink wrote:

On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:

  From now on, the only supported build mode is unified compilation.  I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug
1121000.

I commented in the bug, but I guess this is probably a better forum.

Why is the configure option being removed? I understand always building
unified in automation, but not having a straightforward way at all to
see if your code is buggy seems... suboptimal. If someone wants to go
through occasionally and make our codebase valid C++, how should they do
it after this change?

Perhaps the previous dev-platform thread would provide enlightenment and
I ought to go back and reread it :( , but I do not offhand recall it
deciding to remove the configure option altogether.


I have an issue here, too.

Debugging using gdb will be very difficult when the unified build
creates a source file on the fly (but it is removed, correct?).

No sane compiler/debugger combination can help me do
the source level debugging if the source code that the compiler
compiled is gone by the time debugger tries to find it...

Maybe I am missing something...

I have a similar question about static analysis tools (clang analyzer,
coverity, etc).

Doing the SA on the whole unified file is going to produce some useless
results if all the files content gets merged.
But maybe I am just missing the point.

So far, that's worked out for the things I've looked at. gdb and the
hazard analysis both end up obeying the #line directives that give the
original source filename. There are occasionally problems using emacs to
jump to error messages, I can't remember why, but it hasn't been too bad.

But I don't know about the other static analyses.


Yes, clang can handle all of this very well.  So can every other 
compiler on the planet.  :-)

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Steve Fink]

On 01/15/2015 09:39 AM, Sylvestre Ledru wrote:
> On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:
>> On 2015/01/15 10:37, Steve Fink wrote:
>>> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
  From now on, the only supported build mode is unified compilation.  I
 am planning to follow-up with removing support for the
 --disable-unified-compilation configure option altogether in bug
 1121000.
>>> I commented in the bug, but I guess this is probably a better forum.
>>>
>>> Why is the configure option being removed? I understand always building
>>> unified in automation, but not having a straightforward way at all to
>>> see if your code is buggy seems... suboptimal. If someone wants to go
>>> through occasionally and make our codebase valid C++, how should they do
>>> it after this change?
>>>
>>> Perhaps the previous dev-platform thread would provide enlightenment and
>>> I ought to go back and reread it :( , but I do not offhand recall it
>>> deciding to remove the configure option altogether.
>>>
>> I have an issue here, too.
>>
>> Debugging using gdb will be very difficult when the unified build
>> creates a source file on the fly (but it is removed, correct?).
>>
>> No sane compiler/debugger combination can help me do
>> the source level debugging if the source code that the compiler
>> compiled is gone by the time debugger tries to find it...
>>
>> Maybe I am missing something...
> I have a similar question about static analysis tools (clang analyzer,
> coverity, etc).
>
> Doing the SA on the whole unified file is going to produce some useless
> results if all the files content gets merged.
> But maybe I am just missing the point.
So far, that's worked out for the things I've looked at. gdb and the
hazard analysis both end up obeying the #line directives that give the
original source filename. There are occasionally problems using emacs to
jump to error messages, I can't remember why, but it hasn't been too bad.

But I don't know about the other static analyses.

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Daniel Holbert]

On 01/15/2015 09:46 AM, Chris Peterson wrote:
> Another small benefit of optional non-unified builds is that clang does
> a better job of reporting -Wunused-variable warnings with smaller
> translation units. I assume that the number of identifiers in the
> unified files exceed some clang analysis limit.

(I don't think it's a number-of-identifiers thing.

In the cases I've seen, e.g. bug 1008083, clang doesn't report some
variables as "unused" in #included files because it assumes the
#included thing is a header, and the variable might be used in some
*other* translation unit that includes this header.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Steve Fink]

On 01/15/2015 09:31 AM, Bobby Holley wrote:
> On Wed, Jan 14, 2015 at 5:37 PM, Steve Fink  > wrote:
>
> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
> > From now on, the only supported build mode is unified
> compilation.  I
> > am planning to follow-up with removing support for the
> > --disable-unified-compilation configure option altogether in bug
> 1121000.
>
> I commented in the bug, but I guess this is probably a better forum.
>
> Why is the configure option being removed? I understand always
> building
> unified in automation, but not having a straightforward way at all to
> see if your code is buggy seems... suboptimal. If someone wants to go
> through occasionally and make our codebase valid C++, how should
> they do
> it after this change?
>
>
> IIUC, in the absence of somebody committed to doing this on a daily
> basis, we will quickly slide towards hundreds of include errors, and
> the configure option will quickly become useless.

If that is the case, then adding a file has the potential of exposing a
bunch of those include errors, if it perturbs the chunking boundaries.

But we've already had that argument, and decided in favor of always
building unified in automation. I think the question of removing the
configure option is separate. It's ok if we gradually accumulate these
errors. I just don't want to make life unnecessarily hard for the
occasional angelic figure with supernatural papercut fixing abilities
(hi cpeterson!).

And if this is actually useful to a subset of people (eg IDE users),
then perhaps the debt won't build up too much. Personally, I do
occasionally run a build, grab the compile command, change the
*unified*.cpp file to just the file I'm interested in, and rerun. But
that's a very niche use.

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Chris Peterson]

On 1/14/15 5:37 PM, Steve Fink wrote:

Why is the configure option being removed? I understand always building
unified in automation, but not having a straightforward way at all to
see if your code is buggy seems... suboptimal. If someone wants to go
through occasionally and make our codebase valid C++, how should they do
it after this change?


Another small benefit of optional non-unified builds is that clang does 
a better job of reporting -Wunused-variable warnings with smaller 
translation units. I assume that the number of identifiers in the 
unified files exceed some clang analysis limit.



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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Sylvestre Ledru]

On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:
> On 2015/01/15 10:37, Steve Fink wrote:
>> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
>>>  From now on, the only supported build mode is unified compilation.  I
>>> am planning to follow-up with removing support for the
>>> --disable-unified-compilation configure option altogether in bug
>>> 1121000.
>>
>> I commented in the bug, but I guess this is probably a better forum.
>>
>> Why is the configure option being removed? I understand always building
>> unified in automation, but not having a straightforward way at all to
>> see if your code is buggy seems... suboptimal. If someone wants to go
>> through occasionally and make our codebase valid C++, how should they do
>> it after this change?
>>
>> Perhaps the previous dev-platform thread would provide enlightenment and
>> I ought to go back and reread it :( , but I do not offhand recall it
>> deciding to remove the configure option altogether.
>>
>
> I have an issue here, too.
>
> Debugging using gdb will be very difficult when the unified build
> creates a source file on the fly (but it is removed, correct?).
>
> No sane compiler/debugger combination can help me do
> the source level debugging if the source code that the compiler
> compiled is gone by the time debugger tries to find it...
>
> Maybe I am missing something...
I have a similar question about static analysis tools (clang analyzer,
coverity, etc).

Doing the SA on the whole unified file is going to produce some useless
results if all the files content gets merged.
But maybe I am just missing the point.

Cheers,
Sylvestre

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Bobby Holley]

On Wed, Jan 14, 2015 at 5:37 PM, Steve Fink  wrote:

> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
> > From now on, the only supported build mode is unified compilation.  I
> > am planning to follow-up with removing support for the
> > --disable-unified-compilation configure option altogether in bug 1121000.
>
> I commented in the bug, but I guess this is probably a better forum.
>
> Why is the configure option being removed? I understand always building
> unified in automation, but not having a straightforward way at all to
> see if your code is buggy seems... suboptimal. If someone wants to go
> through occasionally and make our codebase valid C++, how should they do
> it after this change?
>

IIUC, in the absence of somebody committed to doing this on a daily basis,
we will quickly slide towards hundreds of include errors, and the configure
option will quickly become useless.

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

Network Predictive Actions re-enabled on Nightly

[Nicholas Hurley]

All,

I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1009122 on
mozilla-inbound, which re-enables necko's predictive actions capabilities.
I won't go into the full explanation of it here, you can find the big
information (very little of which has changed in this new iteration) in my
original post,
https://groups.google.com/d/msg/mozilla.dev.platform/tAnuc-J0DbY/snrGsOVW1MAJ

The big thing to note about this landing is that data is now stored in the
disk cache instead of sqlite, which means the predictor (formerly "seer")
should not be causing jank or excessive cpu usage any more (hooray!) This
rewrite also keeps the improvements in page load time seen in the previous
iteration (see previous message linked above for details).

This is currently enabled on desktop and android, and disabled on b2g, as
e10s support is not fully there in the predictor yet. To be clear - this
will not break anywhere e10s is enabled, it's just a no-op for now if e10s
is enabled. Work on e10s support is proceeding in
https://bugzilla.mozilla.org/show_bug.cgi?id=959752 (feel free to follow
along if you wish).

Any bugs you encounter with this feature enabled, please file a followup
blocking 1009122.

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Jonathan Kew]

On 15/1/15 15:56, ISHIKAWA,chiaki wrote:


Debugging using gdb will be very difficult when the unified build
creates a source file on the fly (but it is removed, correct?).

No sane compiler/debugger combination can help me do
the source level debugging if the source code that the compiler compiled
is gone by the time debugger tries to find it...

Maybe I am missing something...



This shouldn't be a problem. The "unified" source file simply #includes 
the real sources, and so the debugger will know the paths to those.


JK


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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[ISHIKAWA,chiaki]

On 2015/01/15 10:37, Steve Fink wrote:

On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:

 From now on, the only supported build mode is unified compilation.  I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug 1121000.


I commented in the bug, but I guess this is probably a better forum.

Why is the configure option being removed? I understand always building
unified in automation, but not having a straightforward way at all to
see if your code is buggy seems... suboptimal. If someone wants to go
through occasionally and make our codebase valid C++, how should they do
it after this change?

Perhaps the previous dev-platform thread would provide enlightenment and
I ought to go back and reread it :( , but I do not offhand recall it
deciding to remove the configure option altogether.



I have an issue here, too.

Debugging using gdb will be very difficult when the unified build 
creates a source file on the fly (but it is removed, correct?).


No sane compiler/debugger combination can help me do
the source level debugging if the source code that the compiler compiled 
is gone by the time debugger tries to find it...


Maybe I am missing something...

TIA


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