Re: Intent to implement: WebMIDI
On Sun, Jun 15, 2014 at 11:00 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Jun 15, 2014 at 11:24 AM, Leman Bennett (Omega X) Redacted.For.Spam@request.contact wrote: Is that really necessary? It seems superfluous. It's necessary in that there's no other way to use this hardware from a Web app. The only question is whether it's high-enough priority to work on instead of something else. The other question is if there is a better way than adding explicit APIs for every conceivable type of hardware that you can plug in to a USB port (I'm assuming that midi ports are usually connected to computers through USB these days). It doesn't really seem like a scalable solution. A long time ago we talked about just writing a very low-level USB API, then enabling signed snippets of javascript to create page-exposed APIs on top of that. This way we wouldn't have to go through the long and expensive process of standardizing and implementing APIs for everything that can be plugged into a USB port. These signed snippets of javascripts wouldn't need to be installed by the user, but could be linked to by the page that wants to use the API. It would however need to be signed by all browser vendors that are interested in making the library work. However it's probably going to take a very long time for something like this to actually get standardized and implemented. If it'll happen at all. So if we think that WebMIDI is something that we want soon, then we definitely couldn't wait. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebMIDI
MIDI isn't just USB, though. It's a protocol that can happen over many modes of transport; some of the stage systems I mentioned use ethernet, or there's still tons of hardware with actual MIDI ports (I have 2 IN/OUTs via my DAC connected to the machine I'm typing this from, for instance). We depend on the OS to expose these as MIDI, whether it starts as class compliant USB MIDI, or otherwise. If we went with a USB API, we'd run into the same issue with MIDI that we would with HID, the fact that most operating systems have a manager for this. It seems easiest to work with that manager, not with low level USB itself, unless we want to run into a multi-platform detaching nightmare. But, this is part of the same problem that stopped us with USB the first time around: Where does the OS stop and the browser begin? BTW, the USB conversation is apparently starting back up again. There's been action on https://bugzilla.mozilla.org/show_bug.cgi?id=webusb in the past couple of weeks. - Original Message - From: Jonas Sicking jo...@sicking.cc To: Robert O'Callahan rob...@ocallahan.org Cc: dev-platform@lists.mozilla.org, Leman Bennett (Omega X) Redacted.For.Spam@request.contact Sent: Sunday, June 15, 2014 11:08:08 PM Subject: Re: Intent to implement: WebMIDI On Sun, Jun 15, 2014 at 11:00 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Jun 15, 2014 at 11:24 AM, Leman Bennett (Omega X) Redacted.For.Spam@request.contact wrote: Is that really necessary? It seems superfluous. It's necessary in that there's no other way to use this hardware from a Web app. The only question is whether it's high-enough priority to work on instead of something else. The other question is if there is a better way than adding explicit APIs for every conceivable type of hardware that you can plug in to a USB port (I'm assuming that midi ports are usually connected to computers through USB these days). It doesn't really seem like a scalable solution. A long time ago we talked about just writing a very low-level USB API, then enabling signed snippets of javascript to create page-exposed APIs on top of that. This way we wouldn't have to go through the long and expensive process of standardizing and implementing APIs for everything that can be plugged into a USB port. These signed snippets of javascripts wouldn't need to be installed by the user, but could be linked to by the page that wants to use the API. It would however need to be signed by all browser vendors that are interested in making the library work. However it's probably going to take a very long time for something like this to actually get standardized and implemented. If it'll happen at all. So if we think that WebMIDI is something that we want soon, then we definitely couldn't wait. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebMIDI
On Mon, Jun 16, 2014 at 6:08 PM, Jonas Sicking jo...@sicking.cc wrote: A long time ago we talked about just writing a very low-level USB API, then enabling signed snippets of javascript to create page-exposed APIs on top of that. This way we wouldn't have to go through the long and expensive process of standardizing and implementing APIs for everything that can be plugged into a USB port. These signed snippets of javascripts wouldn't need to be installed by the user, but could be linked to by the page that wants to use the API. It would however need to be signed by all browser vendors that are interested in making the library work. The line between this and actually standardizing an API seems thin. This approach might save time up front, but it would generate browser vendor security work vetting every USB-wrapping JS library --- and every bugfix to every such library. If there were more than a few in any given domain, it definitely wouldn't be worth it. So you'd want to minimize the number of different libraries. In fact it might be a good idea to standardize on one. Then we could ship it with the browser. Oh wait... Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebMIDI
I am developer at Yamaha, and belongs to AMEI[0] to advocate Web MIDI API, and am administrating community for who likes Web and Music named Web Music Developers JP in Japan. As you know, MIDI itself has 30 years' history, and now MIDI is an standard protocol for the music industry. Almost all of electric musical instruments support MIDI to communicate each other. As you know MIDI has IN/OUT features. From MIDI output point of view, MIDI has Show Control(MSC) specs, for example. The MSC allow users to control all types of entertainment equipments. For example, some of the show at Las Vegas, and Universal Studio are using MSC to control the show. So when Web browser supports MIDI, those console would change to Web browser. From MIDI input point of view, MIDI message has velocity, which allow users to add expression to play music, and velocity is one of the important element to create music. But since PC keyboard has only has 2 state which are On and Off, it is not possible to create without MIDI input devices(physical controller). And input feature allow users to control other devices which support MIDI from physical devices. So when Web browser supports MIDI, users can develop application which is controlled by physical devices. For example, Web Music Developers JP had a hackathon[1][2] with Google, and some developers build applications which are controlled by MIDI devices, such as VJ applications, control object in browser by MIDI controller. Even DAWs(Digital Audio Workstation) support MIDI input(also output), so that users can control parameter, such as volume, pan, filters, start/stop sequence and so on by physical controller. That is because with physical controller to control DAW(music applications) is much intuitive way than controlling from PC display. As Chris mentions, at Yamaha, we are distributing Web MIDI Applications for real product[3]. The biggest one is the gadget named Pocket Miku. This gadget sing and play music from controller on gadget and also able to control from MIDI. We have built and distribute Web Application to allow user to change configurations of the gadget. Lots of users are using this application easily without any user supports, and now developers have started creating music applications with Web MIDI API for not only for the gadget but also any MIDI devices. From these facts, we have confident that Web MIDI API has huge impact not only to music industry but also to other industries which are related to music. And I believe that it have impact to Web developers who likes music.( and I know lots of Web developers likes music:-) ) And I think that Web MIDI API would be one of the unique API that enable to connect physical controllers and browser with well defined, open specs, and lasted for 30 years. [0] Association of Musical Electronics Industry( http://amei.or.jp/ (Japanese) ) [1] http://blog.agektmr.com/2014/01/web-music-hackathon-2-report.html [2] http://miscfeeling.blogspot.jp/2014/01/web-music-hackathon-2-report.html [3] https://github.com/yamaha-webmusic/nsx1-apps/ [4] http://fumiopen.blogspot.jp/2014/06/pocket-miku.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
********: MXR now displays links to Github log blame for Gaia/Rust/Servo
MXR now links to the Github log blame pages from the view single file and free-text search result pages for the Gaia, Rust and Servo repositories (bug 1024443). This means that for cases where Github code search is inadequate (eg: filename search via bookmark keyword or custom search engine entry) or where you want to use a consistent tool - the workflow is now comparable to that of MXR+hgweb for hg based repos. eg: http://mxr.mozilla.org/gaia/source/README.md http://mxr.mozilla.org/rust/source/README.md http://mxr.mozilla.org/servo/source/README.md - Top right of page: Git Log / Git Blame Given that MXR is going to be superseded by DXR in the future, I've also filed bug 1024438 for adding gaia support to DXR. Best wishes, Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ********: MXR now displays links to Github log blame for Gaia/Rust/Servo
(Sorry about the subject prefix, that wasn't there prior to sending; time to debug the Thunderbird addons :-/) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ********: MXR now displays links to Github log blame for Gaia/Rust/Servo
On 06/16/2014 01:07 PM, Ed Morley wrote: MXR now links to the Github log blame pages from the view single file and free-text search result pages for the Gaia, Rust and Servo repositories (bug 1024443). This means that for cases where Github code search is inadequate (eg: filename search via bookmark keyword or custom search engine entry) or where you want to use a consistent tool - the workflow is now comparable to that of MXR+hgweb for hg based repos. eg: http://mxr.mozilla.org/gaia/source/README.md http://mxr.mozilla.org/rust/source/README.md http://mxr.mozilla.org/servo/source/README.md - Top right of page: Git Log / Git Blame Given that MXR is going to be superseded by DXR in the future, I've also filed bug 1024438 for adding gaia support to DXR. Best wishes, Ed This a welcome surprise! I was just grumbling yesterday about how I had to manually find the Servo files in github when I wanted history; this makes my day :) Cheers, Josh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Javascript code coverage ?
Hello, I am working on providing weekly code coverage of Firefox code. For now, I am able to do that for C/C++ code. I would like to know if anyone tried to generate code coverage recently on the Javascript code of Firefox (or Firefox OS)? I saw some b2g reports [1] talking about Coverage but I am not sure that they mean the same thing. I found this URL: https://wiki.mozilla.org/QA:CodeCoverage#Jscoverage but jscoverage looks like a dead project. And I am starting to play with: https://github.com/tntim96/JSCover Thanks Sylvestre [1] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/R4eKU8I3cxI ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Javascript code coverage ?
On 6/16/14 7:23 PM, Sylvestre Ledru wrote: Hello, I am working on providing weekly code coverage of Firefox code. For now, I am able to do that for C/C++ code. I would like to know if anyone tried to generate code coverage recently on the Javascript code of Firefox (or Firefox OS)? I saw some b2g reports [1] talking about Coverage but I am not sure that they mean the same thing. I found this URL: https://wiki.mozilla.org/QA:CodeCoverage#Jscoverage but jscoverage looks like a dead project. And I am starting to play with: https://github.com/tntim96/JSCover Thanks Sylvestre [1] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/R4eKU8I3cxI Hi Sylvestre, The old jscoverage still works with some minor modifications to jsm that is injected. I don't recall off the top of my head, but it was but a few lines of change so it should be easy to figure out. Obviously, something that is actively maintained would be better. Bonus points for getting it integrated with the build system for Desktop Firefox, so I can make use of it for a comm-central project :-) Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Icon fonts in FxOS
Hi All: We need a path forward on the deployment of Icon fonts in FxOS. The Gaia team understandably wants to squeeze every bit of performance on their apps in v1.4: https://bugzilla.mozilla.org/show_bug.cgi?id=951593 We are concerned about leaking these fonts into Open Web content, so we want to restrict it to certified Gaia apps: https://bugzilla.mozilla.org/show_bug.cgi?id=1008458 The approach we take to restrict icon fonts to certified Gaia apps is under some debate, and we've got 4 possibilities: 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) I'm afraid of the amount of code in the patch for bug 1008458 for the 1.4 release, so I'm inclined to let the Gaia team use the icon font as-is (option 1) with the promise that they won't use it in uncertified non-system apps. I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. The Gaia email app has gone privileged instead of certified just recently. I expect that most partners will want to deliver the email app with the same look and feel as the other apps that may be certified. If that means the use of the icon font, we might have some trouble. In general, I prefer solutions that do not require certified status, as I hope more apps for gaia can move to privileged and even be delivered through the Marketplace and for Android devices that can use Marketplace apps. I can appreciate there are other factors involved, just mentioning a general desire to move more to apps out of the certified embrace. For email, I will likely look for any alternatives that allow us to stay privileged instead of reverting to certified. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
Comments inline. 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) We can always host the icon fonts on github to download. Could web developers package the icon fonts in the apps itself? That way they can use the font outside of Gaia if they want, and when perhaps we can write some script that would use the system icon fonts if they are present, otherwise it would fall back to the ones packaged in the app. That way we can get the performance gain. It would be good if we can even go with 1 app to type this out for the next release, our initial plan was Settings. 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) To me feels like #2 and #4 are the cleanest, #4 being the least code intensive, especially if we’d ideally want to go pure SVG. I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) We on the visual design team would prefer SVG over Icon Font as well, clearly there are some performance limitations as you cited, so we opted for icon fonts for the system icons since they are single colour. Each release we spend weeks trying to update graphics, so the sooner we can get something in place the better. --- Patryk Adamczyk, R.G.D. Design Manager - Visual Design, Firefox OS Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Javascript code coverage ?
On 2014-06-16, 1:23 PM, Sylvestre Ledru wrote: Hello, I am working on providing weekly code coverage of Firefox code. For now, I am able to do that for C/C++ code. Awesome, where can we find those reports? Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for adding named arguments to C++
On 2014-06-14, 10:58 PM, Robert O'Callahan wrote: Looks good. A classic problem we have had is with boolean parameters, which are hard to read at call sites. We currently solve that by turning them into enum or flag parameters, but named parameters would be a lighter-weight alternative. However, it would be great to be able to ensure at the language level that certain boolean parameters are passed as named parameters. FWIW I have thought about adding a way to require the usage of names for some arguments with this specific use case in mind, but I've been ignoring it for the initial version of the proposal. It might be something that we can add in when we have a real proposal for the committee. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 16/6/14 22:09, James Burke wrote: On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive. The Gaia email app has gone privileged instead of certified just recently. I expect that most partners will want to deliver the email app with the same look and feel as the other apps that may be certified. If that means the use of the icon font, we might have some trouble. In general, I prefer solutions that do not require certified status, as I hope more apps for gaia can move to privileged and even be delivered through the Marketplace and for Android devices that can use Marketplace apps. I can appreciate there are other factors involved, just mentioning a general desire to move more to apps out of the certified embrace. For email, I will likely look for any alternatives that allow us to stay privileged instead of reverting to certified. OK, that's useful info, thanks! And it significantly changes the picture, as it means that implementing a platform-level solution targeting certified apps may be less useful than expected. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory. Icon fonts are perfect for our themeability requirements as they can easily by styled with CSS. AFAIK SVGs cannot be colored/styled with CSS alone (but I don't know that much about SVG). We've been using icon-fonts in Camera for a while now and so far it's been great. I plan to move Camera to pull its icon-font from gaia-icons so that we can begin to move to toward a central icons store. IMO SVG and icon-fonts will always serve slightly difference use cases. But for simple icons, icon-fonts have always got the job done; allowing me to focus on the more important stuff :p W. - Original Message - From: Patryk Adamczyk padamc...@mozilla.com To: Jet Villegas j...@mozilla.com Cc: John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, Cameron McCormack hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Vivien vnico...@mozilla.com, sicking sick...@mozilla.com, Robert O'Callahan rocalla...@mozilla.com, Jonathan Kew j...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Sent: Monday, June 16, 2014 10:14:19 PM Subject: Re: Icon fonts in FxOS Comments inline. 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) We can always host the icon fonts on github to download. Could web developers package the icon fonts in the apps itself? That way they can use the font outside of Gaia if they want, and when perhaps we can write some script that would use the system icon fonts if they are present, otherwise it would fall back to the ones packaged in the app. That way we can get the performance gain. It would be good if we can even go with 1 app to type this out for the next release, our initial plan was Settings. blockquote 2. The patch in bug 1008458 introduces private fonts that use the Unicode Private Use Area (PUA) for icon glyphs. 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps. 4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 ) /blockquote To me feels like #2 and #4 are the cleanest, #4 being the least code intensive, especially if we’d ideally want to go pure SVG. blockquote I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 31) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 ) /blockquote We on the visual design team would prefer SVG over Icon Font as well, clearly there are some performance limitations as you cited, so we opted for icon fonts for the system icons since they are single colour. Each release we spend weeks trying to update graphics, so the sooner we can get something in place the better. --- Patryk Adamczyk, R.G.D. Design Manager - Visual Design, Firefox OS Mozilla Corporation ___ b2g-internal mailing list b2g-inter...@mozilla.org https://mail.mozilla.org/listinfo/b2g-internal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
(2014/06/17 4:34), Jet Villegas wrote: 1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used for this purpose) Actually WingDings can NOT be used at least on desktop Firefox because it does not have a unicode cmap. Does Firefox OS have an option to relax this restriction? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Javascript code coverage ?
Inline On 6/16/2014 10:23, Sylvestre Ledru wrote: Hello, I am working on providing weekly code coverage of Firefox code. For now, I am able to do that for C/C++ code. Awesome. Where are you putting these reports? What is the workload used to generate those reports? I would like to know if anyone tried to generate code coverage recently on the Javascript code of Firefox (or Firefox OS)? There was some old work done on this by Jcranmer and decoder a while ago [1]. I don't know what ever came of it. I saw some b2g reports [1] talking about Coverage but I am not sure that they mean the same thing. No, that is the metric of coverage of the test run. These are large, mostly manual testruns that we run against devices on b2g, and the coverage metric is a metric of how much of the test run we have completed by that point. (The results come out every few days, so you can see the coverage grow as we complete more testing). Thanks, Clint [1] http://quetzalcoatal.blogspot.com/2012/06/js-code-coverage.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
Wilson: How difficult would it be to have your grunt script add a dlig table to your font? https://www.microsoft.com/typography/otspec/features_ae.htm#dlig https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 --Jet - Original Message - From: Wilson Page wilsonp...@mozilla.com We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Javascript code coverage ?
On 6/16/2014 12:23 PM, Sylvestre Ledru wrote: Hello, I am working on providing weekly code coverage of Firefox code. For now, I am able to do that for C/C++ code. I would like to know if anyone tried to generate code coverage recently on the Javascript code of Firefox (or Firefox OS)? Define recently? :-) I've done at least three different abortive attempts to do JS code coverage. The really hard part is that Mozilla uses new (and non-standard) syntax fairly aggressively in its code--when I first started poking at it, the inability to process E4X was actually a hard block for me [1]. I also tried to do some poking to figure out how to get it working on inline scripts in our XUL or XBL code. My first attempt was using jscoverage, which worked poorly even back in 2010 and 2011: it was based on an earlier version of SpiderMonkey's APIs and upgrading to newer parse APIs was a pain in the butt. I tried again at some point using the Reflect.parse APIs, but shied away from that because I didn't have the time to maintain a functional decompiler from the AST let alone a variant that added the instrumentation to that. When the SpiderMonkey PC counts API was added, I actually managed to build a working system, but then I was told that IonMonkey had broken that functionality before I could ever get it truly ready. I tried once again when the debugger API was added, but that again didn't work for some reason (I've forgotten why long ago... probably something to do with insufficiently exposing interesting globals?). Over the years, I've come to the conclusion that inserting instrumentation into the source code is not a viable path to achieving JS code coverage metrics. Maintaining a functioning decompiler for the AST that works reasonably well on several million lines of JS code, some of which uses dialects not commonly found on the web, is a difficult task by itself. Adding on top of that the insanity of how JS code must be expressed (including nasty things like you can't instrument prefs.js or the presence of inline JS) means that you have to spend more time on maintaining an engine beyond what most others would find sufficient for their uses. On top of that, there is the not-insignificant problem that there's no standard way to do I/O in JS that lets you save that information somewhere: especially daunting given the presence of XPCOM components, chrome workers, content workers, chrome and content windows, specifically sandboxed source files, and builtin JS code, to name the types I'm aware of. [1] I concern myself more with Thunderbird's code coverage than with Firefox's, and we used E4X in one place before it was removed, and Lightning used it in another place. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?
I am saying about https://github.com/mozilla/gecko-dev After that, I am also looking for comn-central git mirror. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?
On 6/16/14 7:39 PM, luoyongg...@gmail.com wrote: I am saying about https://github.com/mozilla/gecko-dev I don't understand the question. What tags are you looking for? After that, I am also looking for comn-central git mirror. https://github.com/mozilla/releases-comm-central is experimental but it exists. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?
On 2014-06-16, 10:39 PM, luoyongg...@gmail.com wrote: I am saying about https://github.com/mozilla/gecko-dev After that, I am also looking for comn-central git mirror. This may be what you are looking for: https://github.com/mozilla/releases-comm-central I don't know if it is considered canonical - I will ask - but there is a lot of activity there. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?
Thanks, I've seen that repository, but the problem is that doesn't contains all the tags. and all the branches. 在 2014年6月17日星期二UTC+8上午10时44分16秒，Aki Sasaki写道： I don't understand the question. What tags are you looking for? Those tags resident in original mozilla and comn hg repositories. After that, I am also looking for comn-central git mirror. https://github.com/mozilla/releases-comm-central is experimental but it exists. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?
Thanks, I've seen that repository, but the problem is that doesn't contains all the tags. and all the branches. 在 2014年6月17日星期二UTC+8上午10时44分16秒，Aki Sasaki写道： I don't understand the question. What tags are you looking for? Those tags resident in original mozilla and comn hg repositories. After that, I am also looking for comn-central git mirror. https://github.com/mozilla/releases-comm-central is experimental but it exists. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?
We cannot sync all the tags. Here's why. http://escapewindow.dreamwidth.org/240669.html On 6/16/14 8:21 PM, luoyongg...@gmail.com wrote: Thanks, I've seen that repository, but the problem is that doesn't contains all the tags. and all the branches. 在 2014年6月17日星期二UTC+8上午10时44分16秒，Aki Sasaki写道： I don't understand the question. What tags are you looking for? Those tags resident in original mozilla and comn hg repositories. After that, I am also looking for comn-central git mirror. https://github.com/mozilla/releases-comm-central is experimental but it exists. ___ 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
