Re: W3C Proposed Recommendation: CORS
On Sat, Dec 14, 2013 at 4:59 AM, L. David Baron wrote: > http://www.w3.org/TR/cors/ > Cross-Origin Resource Sharing (CORS) > > There's a call for review to W3C member companies (of which Mozilla > is one) open until January 14. > > 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 think we should indicate support and choose the "intend to implement" option. -- 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: Improvements to the Sphinx in-tree documentation generation
From what I've been able to tell from the interwebs, extracting documentation (autodoc-fashion) from JS/C++/IDL isn't possible with Sphinx. Is that correct? This makes me sad because it means I probably have to end up copy-pasting my source code documentation elsewhere either way (in which case I might as well copy/paste into MDN myself). :-( ~ Gijs On 12/12/13, 09:08 , Gregory Szorc wrote: After I announced the in-tree build docs powered by Sphinx a few months ago [1], a few people came to me and said "that's really cool - I want something like that for my module." I'm pleased to announce that as of bug 939367 landing in inbound a few hours ago, you can now deposit Sphinx docs anywhere in the tree and they will get picked up during `mach build-docs`. This feature is self-documenting and you can find the instructions in the output of `mach build-docs` or at [2]. See build/docs or services/docs in the tree for what this looks like in practice. Yes, the docs use the old MDN theme. They will use the new theme once someone updates [3]. For all I know, someone is already hard at work doing that. We also have bug 920314 tracking getting these docs published on MDN. Sphinx is extremely extensible. If you have ideas for better integrating it with anything, let me know! Please report any issues or questions you may have. Core :: Build Config for now. [1] https://groups.google.com/d/msg/mozilla.dev.platform/HQOL8YKiJmE/wlvktOlQSpIJ [2] https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.html [3] https://github.com/lmorchard/mozilla-mdn-sphinx-theme ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: CORS
On Mon, Dec 16, 2013 at 8:37 AM, Henri Sivonen wrote: > I think we should indicate support and choose the "intend to implement" > option. Except at this point http://fetch.spec.whatwg.org/ is what we should implement (not that they are different, I think). I guess we still support publishing it though for IPR reasons. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday @ 12:30 PM PST
Our weeklyesque DOM bindings meetings continue on Monday Dec 16 at 12:30 PM PST. http://arewemeetingyet.com/Los%20Angeles/Mon/12:30 /w/DOM%20Bindings%20Meeting Meeting details: * Monday, December 16, 2013, 12:30 PM PST (3:30 PM EST/9:30 PM CET) * Dial-in Info: - Vidyo room: Boris Zbarsky ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendation: Progress Events
W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): http://www.w3.org/TR/progress-events/ Progress Events There's a call for review to W3C member companies (of which Mozilla is one) open until January 17. 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.) -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
Rendering meeting, Moday 2:30pm (the "earlier" time)
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm PDT. The next meeting will take "today", Monday, December 16th at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/ 2013-December-16#Agenda San Francisco - Monday, 2:30pm Winnipeg - Monday, 4:30pm Toronto - Monday, 5:30pm GMT/UTC - Monday, 22:30 Paris - Monday, 11:30pm Taipei - Tuesday, 6:30am Auckland - Tuesday, 11:30am Video conferencing: Vidyo room Graphics (9366) https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 Phone conferencing: +1 650 903 0800 x92 Conf# 99366 +1 416 848 3114 x92 Conf# 99366 +1 800 707 2533 (pin 369) Conf# 99366 -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: CORS
On Monday 2013-12-16 12:16 +, Anne van Kesteren wrote:
> On Mon, Dec 16, 2013 at 8:37 AM, Henri Sivonen wrote:
> > I think we should indicate support and choose the "intend to implement"
> > option.
>
> Except at this point http://fetch.spec.whatwg.org/ is what we should
> implement (not that they are different, I think). I guess we still
> support publishing it though for IPR reasons.
I submitted the vote in support of publishing as REC, with all the
intend to implement boxes checked ("produces products addressed by
this specification", "expects to produce products conforming to this
specification", "expects to produce content conforming to this
specification", and "expects to use products conforming to this
specification"). It's changeable until the deadline if other
feedback comes in.
-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: Improvements to the Sphinx in-tree documentation generation
On 12/16/13, 12:58 AM, Gijs Kruitbosch wrote: From what I've been able to tell from the interwebs, extracting documentation (autodoc-fashion) from JS/C++/IDL isn't possible with Sphinx. Is that correct? It is possible. Sphinx can consume Doxygen's XML output to generate C++ docs via Breathe [1]. I experimented with this during Summit, but one of Doxygen or Sphinx was allocating 10+ GB memory trying to build the docs for all of the tree and made my laptop at the time explode. We could probably make things work by only reading part of the tree or incrementally generating docs for the entire tree. There was also some XML Unicode encoding bug in Doxygen I ran into. That's what happens when you attempt to construct XML via string concatenation rather than going through an XML API (oh, Doxygen). It would probably be pretty easy to write something against the Clang API, since Clang's AST exposes parsed Doxygen doc entities [2]. As for JS and IDL, it's all /possible/. You just need a way to feed stuff into Sphinx. If someone writes a tool that can extract JS docblocks into a machine readable format, we can integrate them into Sphinx. It's doable - I just don't think anyone has done it yet. I agree our current mechanism for JS documentation is pretty bad. We desire to document both the source and MDN for obvious reasons. But nobody wants to burdened with writing docs twice. So typically in-tree or MDN docs suffer. Neither is great for maintainability or consumers. IMO we should just write in-tree source docs and export to MDN. Goodbye syncing problem. Are there any JS doc tools that can export to a machine readable format? Does SpiderMonkey expose documentation blocks to the AST? If not, should it? [1] http://michaeljones.github.io/breathe/ [2] http://clang.llvm.org/doxygen/group__CINDEX__COMMENT.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: Progress Events
On Mon, Dec 16, 2013 at 8:11 AM, L. David Baron wrote: > W3C recently published the following proposed recommendation (the > stage before W3C's final stage, Recommendation): > > http://www.w3.org/TR/progress-events/ > Progress Events > > There's a call for review to W3C member companies (of which Mozilla > is one) open until January 17. > > 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.) > > -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 > > Should we be explicitly voting in favor of this one too? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On 16/12/13, 18:17 , Gregory Szorc wrote: Are there any JS doc tools that can export to a machine readable format? Does SpiderMonkey expose documentation blocks to the AST? If not, should it? Other parsers certainly expose comments in the AST; I don't think they explicitly have pointers from the functions/objects to their docblocks, but it shouldn't be too hard to add a post-processing step that does that. I don't know if there's agreement on building that kind of thing into SpiderMonkey. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On 12/16/2013 01:17 PM, Gregory Szorc wrote:
> Does SpiderMonkey expose documentation blocks to the AST? If not, should it?
No, and probably not. Comments are not tokens, so they're not in the AST.
Right now SpiderMonkey pretty much just throws them away (except to the extent
the comment includes a line break, in which case /*\n*/ and similar represent a
line break for semicolon-insertion rules). And it'd be really unfortunate to
have to include them -- then things like a DoWhileNode would have to be gunked
up a bunch to store information like in |do { } /* fnord */ while /* quoi */
(true);|.
Maybe there's some sort of intelligent exposure that could nonetheless be done.
But I doubt it's a good idea to build it atop a parser designed for executing
code, and not for exactly faithfully representing it.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling Mac + Linux32-bit builds/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd
I've heard no objections. I will proceed with this plan. On 13-12-12 01:35 PM, Armen Zambrano G. wrote: > +dev.b2g > > tl;dr > - we want to disable Mac + Linux32-bit build/tests for mozilla-b2g18 and > mozilla-b2g18-v1.1.0hd > > Hi Ryan, > I would be fine of taking care of it if I hear no objections by next week. > > On 13-12-12 12:12 PM, Ryan VanderMeulen wrote: >> On 12/12/2013 11:58 AM, arme...@mozilla.com wrote: >>> Hello all, >>> After disabling the Win7 tests on those b2g18 trees, I was told by the >>> sheriffs that the MacOS X testing is redundant. >>> >>> Again: >>> * these are repositories where only security fixes are being landed >>> * this is not about b2g26 >>> * we have testing coverage through Linux, Linux64, Android Noion + B2g >>> emulator test jobs >>> >>> If you have any concerns/questions/objections please raise them up in: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=949522 >>> >>> cheers, >>> Armen >>> >>> https://tbpl.mozilla.org/?tree=Mozilla-B2g18 >>> https://tbpl.mozilla.org/?tree=Mozilla-B2g18-v1.1.0hd >>> >> >> Are we getting any value from testing both Linux32 and Linux64 on b2g18* >> at this point? Linux32 in particular suffers from a good number of >> intermittents that are near perma-fail. Given the support status of the >> branch, I'm resigned to just riding them out, but killing the builds >> would take of it too. Linux64 is much better from a failure standpoint. > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On 12/16/13, 10:46 AM, Jeff Walden wrote:
On 12/16/2013 01:17 PM, Gregory Szorc wrote:
Does SpiderMonkey expose documentation blocks to the AST? If not, should it?
No, and probably not. Comments are not tokens, so they're not in the AST.
Right now SpiderMonkey pretty much just throws them away (except to the extent
the comment includes a line break, in which case /*\n*/ and similar represent a
line break for semicolon-insertion rules). And it'd be really unfortunate to
have to include them -- then things like a DoWhileNode would have to be gunked
up a bunch to store information like in |do { } /* fnord */ while /* quoi */
(true);|.
Maybe there's some sort of intelligent exposure that could nonetheless be done.
But I doubt it's a good idea to build it atop a parser designed for executing
code, and not for exactly faithfully representing it.
Perhaps Reflect.parse() could grow a new option to expose "comment"
nodes or could attach comment metadata to specific node types? This API
is SpiderMonkey proprietary (implying we can do what we want with it) right?
FWIW, someone could build a comment parser on top of Reflect.parse().
But you'd have to scan the lines before each node and parse out comment
blocks. Seems much more robust, easier (over the long run), and more
beneficial to have the forward-scanning parser in the engine just do it.
Perhaps someone should build a proof-of-concept docs parser on top of
Reflect.parse()?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On December 16, 2013 at 1:21:06 PM, Gregory Szorc (g...@mozilla.com) wrote: I agree our current mechanism for JS documentation is pretty bad. WeĀ desire to document both the source and MDN for obvious reasons. ButĀ nobody wants to burdened with writing docs twice. So typically in-treeĀ or MDN docs suffer. Neither is great for maintainability or consumers.Ā IMO we should just write in-tree source docs and export to MDN. GoodbyeĀ syncing problem.Ā We have plans to add support to MDN for allowing content to be "pushed" onto MDN from other sites using scripts or the like. There is already the beginnings of a "write" API that allows content to be injected into MDN, and with that in concert with permissions management, it would be possible to set up the JSAPI section of MDN such that it was pushed onto the wiki by a tool that interpreted in-source comments and output HTML formatted for the wiki. This could be a "best of both worlds" scenario that you guys could be quite happy with. The only reason we haven't finished implementing support for this is that no teams have stepped up to say they'd definitely use it; once one does, I think it wouldn't take all that terribly long to complete, since much of the underlying functionality is partly or even mostly implemented. --Ā Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On 12/16/2013 3:40 PM, Eric Shepherd wrote: This could be a "best of both worlds" scenario that you guys could be quite happy with. The only reason we haven't finished implementing support for this is that no teams have stepped up to say they'd definitely use it; once one does, I think it wouldn't take all that terribly long to complete, since much of the underlying functionality is partly or even mostly implemented. Is there any objection on your side to just having sphinx `mach build-docs` push directly to MDN? If not, that seems slightly preferable to posting them at https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.html --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On 12/16/13, 12:50 PM, Benjamin Smedberg wrote: On 12/16/2013 3:40 PM, Eric Shepherd wrote: This could be a "best of both worlds" scenario that you guys could be quite happy with. The only reason we haven't finished implementing support for this is that no teams have stepped up to say they'd definitely use it; once one does, I think it wouldn't take all that terribly long to complete, since much of the underlying functionality is partly or even mostly implemented. Is there any objection on your side to just having sphinx `mach build-docs` push directly to MDN? If not, that seems slightly preferable to posting them at https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.html This is what we're tracking in https://bugzilla.mozilla.org/show_bug.cgi?id=920314. I'm just waiting for someone to tell me how to publish to MDN and it will happen. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On December 16, 2013 at 3:50:13 PM, Benjamin Smedberg (benja...@smedbergs.us) wrote: Is there any objection on your side to just having sphinx `machĀ build-docs` push directly to MDN? If not, that seems slightly preferableĀ to posting them atĀ https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.htmlĀ Once we've got the feature finished? No, I can't see why, as long as we can customize the output to use the appropriate styles and the like, it should work well and look great. --Ā Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improvements to the Sphinx in-tree documentation generation
On 12/16/2013 12:57 PM, Andrew Sutherland wrote: The Esprima JS parser can already generate comment nodes. The API otherwise conforms to the same output standards as SpiderMonkey's Parser API. There's also acorn, which is an ES5 parser written in JS that's in the tree (http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/acorn). The down side to both acorn and esprima is that neither support SpiderMonkey specific extensions and syntax. Esprima supports most or all of ES6 syntax (in its harmony branch) but some of the features in SM aren't compatible with ES6 (for example, array/generator expressions have the reverse order in SM from ES6). We added acorn to the tree for devtools because we needed a tokenizer and access to comments. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
We should write memory reporters for new features as they're being developed
Hi, For over a month I've been working with a user to identify the cause of a bad memory leak (https://bugzilla.mozilla.org/show_bug.cgi?id=936784). Just today we got DMD working sufficiently well on Windows that the user was able to run it, and it pointed the finger at webaudio. Which is great progress! But if we had memory reporters for web audio, all this would have been so much easier. And (queue sad-face) we actually have a six-month old bug open for that: https://bugzilla.mozilla.org/show_bug.cgi?id=884368 So I want to propose something: if you're working on a change that will introduce significant new causes of memory consumption, you should write a memory reporter for it at the same time, rather than (maybe) doing it later, or letting someone else do it. And in this context, "significant" may be smaller than you expect. For example, we have numerous reporters for things that are typically only 100s of KBs. On B2G, 100KB per process is significant. Understanding the data structures is usually the hard part of writing a memory reporter. The actual reporter registration side isn't hard, and there are plenty of examples to refer to. So the author of the new code is typically the best person to write a reporter for it. And I'm happy to help (and review). Furthermore, memory reporters are best verified by doing a DMD run, and DMD now runs on all tier-1 platforms and is well documented (https://wiki.mozilla.org/Performance/MemShrink/DMD). So that shouldn't be an obstacle. This couldn't be a hard-and-fast rule, but I would like for it to be something that developers and reviewers keep in mind -- Does this code need a memory reporter? And have you verified it with DMD? Thoughts? Nick p.s.: The web audio bug prompted me to make this suggestion, and is a good example of the potential benefits. But I don't mean to criticize those who implemented web audio; apologies if it comes across that way. In that spirit, let's keep discussion on the general proposal as much as possible, rather than web audio. Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
