Re: You can now freely mix declarations and statements in all Mozilla C code
On Thu, Sep 10, 2015 at 7:01 AM, Eric Rescorla wrote: > >> Therefore, 16 years later, you can now mix statements and declarations >> freely in Mozilla C code. > > Note: this does not apply to NSS and NSPR, though those need separate > commit rights, so if you work on them you probably already know this. Yes, I overlooked the case where parts of the code are deliberately being kept as C89 for other reasons (i.e. external constraints). Thank you for the clarification. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
On Tuesday 2015-09-08 17:33 -0700, Tantek Çelik wrote: > Follow-up on this, since we now have two days remaining to respond to these > proposed charters. > > If you still have strong opinions about the proposed Web Platform and Timed > Media Working Groups charters, please reply within 24 hours so we have the > opportunity to integrate your opinions into Mozilla's response to these > charters. Here are the comments I have so far (Web Platform charter first, then timed media). The deadline for comments is in about 2 hours. I'll submit these tentatively, but can revise if I get feedback quickly. (Sorry for not gathering them sooner.) -David = We are very concerned that the merger of HTML work into the functional WebApps group might harm the ability of the work happening in WebApps to continue to make progress as well as it currently does. While a number of people within Mozilla think we should formally object to this merger because of the risk to work within WebApps, I am not making this a formal objection. However, I think the proper functioning of this group needs to be carefully monitored, and the consortium needs to be prepared to make changes quickly if problems occur. And I think it would be helpful if the HTML and WebApps mailing lists are *not* merged. A charter that is working on many documents that are primarily developed at the WHATWG should explicitly mention the WHATWG. It should explain how the relationship works, including satisfactorily explaining how W3C's work on specifications that are rapidly evolving at the WHATWG will not harm interoperability (presuming that the W3C work isn't just completely ignored). In particular, this concerns the following items of chartered work: * Quota Management API * Web Storage (2nd Edition) * DOM4 * HTML * HTML Canvas 2D Context * Web Sockets API * XHR Level 1 * Fetching resources * Streams API * URL * Web Workers and the following items in the specification maintenance section: * CORS * DOM specifications * HTML 5.0 * Progress Events * Server-sent Events * Web Storage * Web Messaging One possible approach to this problem would be to duplicate the technical work happening elsewhere on fewer or none of these specifications. However, given that I don't expect that to happen, the charter still needs to explain the relationship between the technical work happening at the WHATWG and the technical work (if any) happening at the W3C. The group should not be chartered to modularize the entire HTML specification. While specific documents that have value in being separated, active editorship, and implementation interest are worth separating, chartering a group to do full modularization of the HTML specification feels both like busywork and like chartering work that is too speculative and not properly incubated. It also seems like it will be harmful to interoperability since it proposes to modularize a specification whose primary source is maintained elsewhere, at the WHATWG. The charter should not include work on HTML Imports. We don't plan to implement it for the reasons described in https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ and believe that it will no longer be needed when JavaScript modules are available. The inclusion of "Robust Anchoring API" in the charter is suspicious given that we haven't heard of it before. It should probably be in an incubation process before being a chartered work item. We also don't think the working group should be chartered to work on any items related to "Widgets"; this technology is no longer used. I'm still considering between two different endings: OPTION 1: Note that while this response is not a formal objection, many of these issues are serious concerns and we hope they will be properly considered. OPTION 2: The only part of this response that constitutes a formal objection is having a reasonable explanation of the relationship between the working group and the work happening at the WHATWG (rather than ignoring the existence of the WHATWG). However, many of the other issues issues raised are serious concerns and we hope they will be properly considered. = One of the major problems in reaching interoperability for media standards has been patent licensing of lower-level standards covering many lower-level media technologies. The W3C's Patent Policy only helps with technology that the W3C develops, and not technology that it references. Given that, this group's charter should explicitly prefer referencing technology that can be implemented and used without paying royalties and without negotiating contracts for things for which licenses are not available to all. Likewise, the charter should list as a success criterion that the technology produced by the working group can be implemented and used without paying royalties and without negotiating contracts for things for which licenses are not available to all. Having the media gr
Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
On Thu, Sep 10, 2015 at 12:13 PM, Ms2ger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/10/2015 06:36 PM, Jonas Sicking wrote: > > If I am the only one that wants to put in a formal objection here, > > then I'll let it go and go with whatever everyone else think we > > should do. > > > > FWIW, I agree with Jonas that this is a terrible idea. (Even if we're > the only Member raising a formal objection, > I understand why it's not great, however, could you follow-up with specific reasons why it's "terrible"? I disagree with the characterization as "terrible", and think a formal objection based on vague fears at this point would be chicken-littling. OTOH, I think there are plenty of specific reasons why the past problems from HTMLWG are unlikely to manifest in the Web Platform WG, and I outlined those in my previous response in this thread. If you think my analyses in the reasons given are incorrect, I'm happy to be corrected. However I *do* think we should comment something like: Problems experienced in the HTMLWG may hamper the productivity of the new WG, and we suggest the chairs pay attention to, and swiftly respond to any similar misbehaviors they see in the new WG. Having such a comment on the record itself will help provide impetus to the chairs to respond swiftly if necessary. > I suspect Mike(TM) Smith would be happy to amplify the message internally.) I'm fairly certain Mike(tm) Smith would agree with the reasons I gave for why Web Platform WG is unlikely to have the same problems, based on private feedback I've received. I'm sure Mike can speak for himself if he strongly (dis)agrees one way or the other. OTOH, maybe we should just move the remaining useful specs in WebApps > to WHATWG; that'd solve the issue once and for all. > >From what I can tell, the way the Web Apps group operates, editors of existing specs have quite a bit of leeway to work in whatever fora they find the most productive. If there's specific downsides you've experienced with Web Apps WG, that's probably worth raising as comments on the charter, in the hopes that they get addressed, or at least as good heads-up signaling before deciding to take any particular spec you're working on elsewhere. Thanks, Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2015 06:36 PM, Jonas Sicking wrote: > If I am the only one that wants to put in a formal objection here, > then I'll let it go and go with whatever everyone else think we > should do. > FWIW, I agree with Jonas that this is a terrible idea. (Even if we're the only Member raising a formal objection, I suspect Mike(TM) Smith would be happy to amplify the message internally.) OTOH, maybe we should just move the remaining useful specs in WebApps to WHATWG; that'd solve the issue once and for all. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJV8dZYAAoJEOXgvIL+s8n20z0H/0Wt4sj+zvpbS/GAPdY/S+wM sF666a9pTZ9N6bdMu9o+vcVM9s1GvP3mra1DwZHe9kfCAklfrjIWrgZ0gjMmvB6e q6reK1l4cbVGyoqCm9b32IqokHCe7wdT7Mm7m8HoSg3SdNCrWyHxfYDIshkO15aw 1xTHwamLDXmlDt94KU36EUdJAmu0j0pN8mvxiVG4FELWHAToGnlJ9l2ionoviqGl /NoQeEASW0TXt1C7Prq7XArLm7mX669z/FPrMhFgHpwyGoxP11BQy0zpCcZzSdlH dsh9yNyS4iabtHjbZVAbCbUxiNGC0ZhDoOmI3l1aYLO0uWPy4iyJRecW8iJonBU= =DO5p -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [stats] Counting HTTP/2 domain names
On 9/10/15 4:55 AM, Patrick McManus wrote: no - generally we don't do origin based telemetry for privacy reasons I suppose, if one really wanted to, that this could be approximated on the client side... Have the browser track all the HTTP/2 domains it connects with, and only report the total in telemetry. If the hypothesis is that most HTTP/2 connections are from a handful of major sites, most clients will report a small number. If the clients also reported the total number of non-HTTP/2 domains, I would further expect the HTTP/2 count to stay small even for client that do lots of broad browsing. (And, conversely, if HTTP/2 is more widely deployed, you'd see numbers that are larger and correlate more with the how many total sites a user visits.) Whether this work is worth doing is a separate question. ;-) Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
If I am the only one that wants to put in a formal objection here, then I'll let it go and go with whatever everyone else think we should do. / Jonas On Wed, Sep 9, 2015 at 11:22 PM, L. David Baron wrote: > On Tuesday 2015-09-08 23:25 -0700, Jonas Sicking wrote: >> On Tue, Sep 8, 2015 at 5:33 PM, Tantek Çelik wrote: >> > On Wed, Aug 19, 2015 at 3:16 AM, Henri Sivonen >> > wrote: >> >> On Sun, Aug 9, 2015 at 9:59 PM, L. David Baron wrote: >> >> > The W3C is proposing revised charters for: >> >> > >> >> > Web Platform Working Group: >> >> > http://www.w3.org/2015/07/web-platform-wg.html >> >> > https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.html >> > >> > >> > tl;dr I think we should vote to approve these charters with changes >> > requested (but not required), based on the input in this thread to date. >> >> I absolutely think that we should only vote to approve these charters >> if they remove merging the WebApps and HTML WGs. > > My one other thought here is that even if we formally object to the > merging of the groups, I don't think we're likely to be able to win > that argument at this stage. Right now they've found chairs for the > combined group, and I'm not aware of anyone else objecting to it. > > Part of the motivation for merging the groups was that nobody seemed > to have any high-priority work to go in the HTML working group. > There are a bunch of things people want to happen with existing > HTML, but nobody seemed ready to step up to do any of it. This > means that there didn't seem to be a good motivation for chartering > a new HTML working group on its own. This also means that even if > we objected to the merger, there wouldn't be a good alternative to > the merger. > > I think it's worth expressing concern about the possibility that > this will mess up the existing WebApps community. And if bad things > happen, we should raise them quickly and at a high level. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Project Candle: an initiative to reduce power consumption
Thanks for spearheading this, Nick! On Thu, Sep 10, 2015 at 7:15 AM, Chris Mills wrote: > Nice work Nick - some really good content here. > > I’ve spent a good chunk of today reading through and giving it a copy edit. > > Chris Mills > Senior tech writer || Mozilla > developer.mozilla.org || MDN > cmi...@mozilla.com || @chrisdavidmills > > > > > On 10 Sep 2015, at 02:14, Nicholas Nethercote > wrote: > > > > Greetings, > > > > The 2015 Platform Engineering roadmap [1] > > (https://wiki.mozilla.org/Platform/Roadmap) mentioned "Candle", an > initiative > > that aims to reduce the power consumption of Firefox (desktop and > Android) and > > Firefox OS, that sits alongside other well-known initiatives like > CrashKill, > > CritSmash, and MemShrink. This is finally getting off the ground in a > > significant way. > > > > Details are on the wiki page [2]. Some highlights are as follows. > > > > - There is a new mailing list, dev-power [3]. We will initially try > using the > > mailing list for all discussion and bug triage in preference to > face-to-face > > meetings. This avoids disadvantaging anyone due to their timezone and > also > > makes it easy to follow along in a low-commitment fashion. > > > > - There is a new IRC channel, #power. > > > > - There are several new MDN documentation pages relating to power > profiling > > [4]. > > > > We hope Project Candle will extend and co-ordinate the existing > patchwork of > > efforts relating to power consumption. Although it is originating in > Platform > > Engineering, like all other cross-cutting quality initiatives it will > need > > involvement from people all over Mozilla engineering to be successful. > If you > > are at all interested in power consumption, I encourage you to do one or > more > > of the following things. > > > > - Easy (5 minutes or less): > > - Read the wiki page [2]. > > - Join the mailing list [3]. > > > > - Medium (1 hour or less): > > - Read the tools documentation on MDN [4]. (Feedback is welcome!) > > - Read through the bug lists (linked from the wiki > >page; currently the "Unprioritized" list is the only non-empty one). > > > > - Harder: > > - Work on a bug from one of the bug lists. > > - Think about Q4 goals that might involve power consumption. > > > > I will start the first bug triage thread on the mailing list early next > week. > > > > Please contact me if you have any questions or other feedback. Thank you. > > > > Nick > > > > [1] https://wiki.mozilla.org/Platform/Roadmap > > [2] https://wiki.mozilla.org/Performance/Project_Candle > > [3] https://lists.mozilla.org/listinfo/dev-power > > [4] https://developer.mozilla.org/en-US/docs/Mozilla/Performance, > > under "Power profiling" > > ___ > > dev-fxos mailing list > > dev-f...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-fxos > > ___ > 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: StructuredCloneHelper
Yes, absolutely. I'll file a bug for this. On Tue, Sep 8, 2015 at 7:11 PM, Bobby Holley wrote: > Awesome, thanks for working to unify this stuff baku! > > Can this stuff be applied to StackScopedClone (used by Cu.cloneInto etc), > which currently does this stuff manually in ExportHelpers.cpp? > > On Fri, Sep 4, 2015 at 1:12 AM, Andrea Marchesini > wrote: > >> Hi all, >> >> In these days I landed quite a few patches to replace the use of >> JSAutoStructuredCloneBuffer with something "better": >> StructuredCloneHelper. >> >> First of all, the reasons why I did it, are: >> >> 1. we had many postMessage() methods fully out of sync in terms of which >> clonable/transferable objects we were supporting. Now MessagePort, >> BroadcastChannel, window and worker and (partially) IPC share the same >> code >> base. >> >> 2. We had several regressions about memory management of >> clonable/transferrable objects. At least now we have only 1 code base to >> maintain and fix. >> >> How it works: >> >> 1. StructuredCloneHelperInternal is base class that uses >> JSAutoStructuredCloneBuffer internally and exposes the >> JSStructuredCloneCallbacks as virtual methods. >> For some custom use of JSAutoStructuredCloneBuffer (like Console API in >> workers or PromiseWorkerProxy - bug 1198814) you can use this class. >> >> 2. Probably what you really want to use is StructuredCloneHelper. In its >> CTOR you must decide if: >> a. you want to support the cloning of DOM objects (such as Blob, FileList, >> ImageData, FormData, etc...): CloningSupported/CloningNotSupported >> b. if you want to support the transferring of DOM objects (currently only >> MessagePort): TransferringSupported/TransferringNotSupported >> c. what is the most generic context where the "Read" could run. Here we >> have 3 options: SameProcessSameThread (window to window for instance), >> SameProcessDifferentThread (window to worker), DifferentProcess >> (MessagePort? ipc? all that stuff). >> >> 3. For IPC communication we have a particular class: >> StructuredCloneIPCHelper. >> >> Next steps: >> >> I'm currently (on vacation, but) working on another step: I want to remove >> JSAutoStructuredCloneBuffer, OwningSerializedStructuredCloneBuffer and >> SerializedStructuredCloneBuffer from IPC serialization. Bug: 1201806. >> Please, avoid the use of JSAutoStructuredCloneBuffer in DOM tree. And if >> you have a particular use-cases where StructuredCloneHelper doesn't work, >> let me know and we can find a solution. >> >> b >> ___ >> 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: Project Candle: an initiative to reduce power consumption
Nice work Nick - some really good content here. I’ve spent a good chunk of today reading through and giving it a copy edit. Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills > On 10 Sep 2015, at 02:14, Nicholas Nethercote wrote: > > Greetings, > > The 2015 Platform Engineering roadmap [1] > (https://wiki.mozilla.org/Platform/Roadmap) mentioned "Candle", an initiative > that aims to reduce the power consumption of Firefox (desktop and Android) and > Firefox OS, that sits alongside other well-known initiatives like CrashKill, > CritSmash, and MemShrink. This is finally getting off the ground in a > significant way. > > Details are on the wiki page [2]. Some highlights are as follows. > > - There is a new mailing list, dev-power [3]. We will initially try using the > mailing list for all discussion and bug triage in preference to face-to-face > meetings. This avoids disadvantaging anyone due to their timezone and also > makes it easy to follow along in a low-commitment fashion. > > - There is a new IRC channel, #power. > > - There are several new MDN documentation pages relating to power profiling > [4]. > > We hope Project Candle will extend and co-ordinate the existing patchwork of > efforts relating to power consumption. Although it is originating in Platform > Engineering, like all other cross-cutting quality initiatives it will need > involvement from people all over Mozilla engineering to be successful. If you > are at all interested in power consumption, I encourage you to do one or more > of the following things. > > - Easy (5 minutes or less): > - Read the wiki page [2]. > - Join the mailing list [3]. > > - Medium (1 hour or less): > - Read the tools documentation on MDN [4]. (Feedback is welcome!) > - Read through the bug lists (linked from the wiki >page; currently the "Unprioritized" list is the only non-empty one). > > - Harder: > - Work on a bug from one of the bug lists. > - Think about Q4 goals that might involve power consumption. > > I will start the first bug triage thread on the mailing list early next week. > > Please contact me if you have any questions or other feedback. Thank you. > > Nick > > [1] https://wiki.mozilla.org/Platform/Roadmap > [2] https://wiki.mozilla.org/Performance/Project_Candle > [3] https://lists.mozilla.org/listinfo/dev-power > [4] https://developer.mozilla.org/en-US/docs/Mozilla/Performance, > under "Power profiling" > ___ > dev-fxos mailing list > dev-f...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now freely mix declarations and statements in all Mozilla C code
On Wed, Sep 9, 2015 at 5:41 PM, Nicholas Nethercote wrote: > Hi, > > In C89 you can't mix declarations and statements, i.e. you have to > declare local variables at the top of a block. C99 relaxed this > annoying restriction, but MSVC did not add support for it for a long > time, so with GCC we compile with -Wdeclaration-after-statement even > though we also compile with -std=gnu99. > > Until now, that is. MSVC 2013 finally added support for this > relaxation, and https://bugzilla.mozilla.org/show_bug.cgi?id=1203005 > changed things to allow it everywhere. > > Therefore, 16 years later, you can now mix statements and declarations > freely in Mozilla C code. > Note: this does not apply to NSS and NSPR, though those need separate commit rights, so if you work on them you probably already know this. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: You can now freely mix declarations and statements in all Mozilla C code
Nicholas Nethercote wrote: Therefore, 16 years later, you can now mix statements and declarations freely in Mozilla C code. We still have Mozilla C code? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [stats] Counting HTTP/2 domain names
no - generally we don't do origin based telemetry for privacy reasons On Wed, Sep 9, 2015 at 9:51 PM, Karl Dubost wrote: > Hi, > > Do we have a way to evaluate the number of domain names (not HTTP > requests) which are communicating with Firefox using HTTP/2? > > Question triggered by the recent interesting post of Daniel > http://daniel.haxx.se/blog/2015/09/07/http2-115-days-with-the-rfc/ > > -- > Karl Dubost, Mozilla > http://www.la-grange.net/karl/moz > > ___ > 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
what is new with Talos - September 2015 edition
The last update was in late July: https://groups.google.com/forum/#!topic/mozilla.dev.platform/PaJFBtvc3Vg While we have no new tests, I would like to highlight a few changes: * talos now lives in mozilla-central: testing/talos/. Thanks to :parkouss our fearless contributor who tackled this large project. * e10s talos is now run on all pushes * you can now run e10s talos from try and select it logically from http://trychooser.pub.build.mozilla.org/ * A lot of updates are on the talos wiki: https://wiki.mozilla.org/Buildbot/Talos/Tests (and more upcoming) * Perfherder compare view doesn't show osx 10.10. We are starting to look into why that platform is an expensive random number generator in bug 1191019 * dromaeo_dom is turned off everywhere (but not for long) Upcoming work: * continue to edit the wiki: https://wiki.mozilla.org/Buildbot/Talos/Tests * investigate noisy tests in bug 1201230 and osx specific in bug 1191019 * turn dromaeo_dom on for linux in bug 1191952 * use a python webserver instead of apache for production talos: bug 1195288 * look into making |mach talos| friendlier now that we have talos in tree * alerts generated inside of perfherder (currently planned to be in parallel to graph server) * take advantage of other shared code now that we live in tree * start scheduling Android talos tests on Autophone (different system and reporting as Tier 2 or 3 in treeherder- i.e. not default view) A lot of big hurdles are behind us but there are many more big steps to take. A previous topic was discussing the 48 hour backout policy- A lot of work has been done to validate the data, we are still double checking things and will post before making it 100% live. As always, feedback is welcome! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
