Re: Modifying Element.prototype for all globals
I'm sure this is a dumb question, but why not modify the actual implementation of innerHTML in the core DOM if you're doing a modified try-run anyway? ~ Gijs On 18/06/2015 13:37, Frederik Braun wrote: Hi, I am planning to do a little analysis of FxOS Gaia to identify instances of innerHTML assignments at runtime[1]. I am hoping this gives me a more precise number about hot paths (in contrast to just looking at the source code). In an ideal world I would write a script along the lines of `Object.defineProperty(Element.prototype, 'innerHTML', …)` and inject this into every app, or at best run it somewhere so that every Element's prototype chains back to mine. I know that I can not modify/inherit prototypes across origins, so I am wondering if there is something I could do with chrome privileges - maybe patching shell.js (https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js), as it is the main entrypoint from Gecko into Gaia. Does this sound feasible? Are there any previous experiments that I could refer to? Thanks! Freddy [1] I intend to run the full test suite, not in production or anything. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: WebRTC Working Group
The W3C is proposing a revised charter for: WebRTC Working Group http://www.w3.org/2015/06/webrtc-charter.html https://lists.w3.org/Archives/Public/public-new-work/2015Jun/0009.html Mozilla has the opportunity to send comments or objections through Sunday, July 19. Please reply to this thread if you think there's something we should say as part of this charter review. (This is a second review of a new charter; it's been revised since the first review.) (Really this time! Sorry for the incorrect subject line when I sent out the Web Performance charter.) -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
Modifying Element.prototype for all globals
Hi, I am planning to do a little analysis of FxOS Gaia to identify instances of innerHTML assignments at runtime[1]. I am hoping this gives me a more precise number about hot paths (in contrast to just looking at the source code). In an ideal world I would write a script along the lines of `Object.defineProperty(Element.prototype, 'innerHTML', …)` and inject this into every app, or at best run it somewhere so that every Element's prototype chains back to mine. I know that I can not modify/inherit prototypes across origins, so I am wondering if there is something I could do with chrome privileges - maybe patching shell.js (https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js), as it is the main entrypoint from Gecko into Gaia. Does this sound feasible? Are there any previous experiments that I could refer to? Thanks! Freddy [1] I intend to run the full test suite, not in production or anything. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Modifying Element.prototype for all globals
On 18.06.2015 14:56, Gijs Kruitbosch wrote: I'm sure this is a dumb question, but why not modify the actual implementation of innerHTML in the core DOM if you're doing a modified try-run anyway? This is actually a very good question. Unfortunately, I'm not that great at C/C++ and was hoping for a JS solution. (In the beginning of writing previous email, I was hoping for a solution that could live completely in Gaia, thus saving me compile time and enabling me to use try for running my test. But I dont think I can run try for both a custom b2g as well as a custom gaia) ~ Gijs On 18/06/2015 13:37, Frederik Braun wrote: Hi, I am planning to do a little analysis of FxOS Gaia to identify instances of innerHTML assignments at runtime[1]. I am hoping this gives me a more precise number about hot paths (in contrast to just looking at the source code). In an ideal world I would write a script along the lines of `Object.defineProperty(Element.prototype, 'innerHTML', …)` and inject this into every app, or at best run it somewhere so that every Element's prototype chains back to mine. I know that I can not modify/inherit prototypes across origins, so I am wondering if there is something I could do with chrome privileges - maybe patching shell.js (https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js), as it is the main entrypoint from Gecko into Gaia. Does this sound feasible? Are there any previous experiments that I could refer to? Thanks! Freddy [1] I intend to run the full test suite, not in production or anything. ___ 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
Intent to Ship: Cache API
Next week I plan to enable the Cache API by default. It has been developed behind the dom.caches.enabled pref. This pref has been enabled by default on nightly and aurora since FF39. Next week I plan to remove the pref completely so the feature will ride the trains to release. The Cache API is currently shipping in Chrome. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1110144 Standard: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-objects MDN docs: https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage Please let me know if there are any questions or concerns. Thank you. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Modifying Element.prototype for all globals
On 18.06.2015 15:51, smaug wrote: On 06/18/2015 03:37 PM, Frederik Braun wrote: Hi, I am planning to do a little analysis of FxOS Gaia to identify instances of innerHTML assignments at runtime[1]. I am hoping this gives me a more precise number about hot paths (in contrast to just looking at the source code). What kind of information would you like to get out from the analysis? And before even spending too much time with innerHTML, are you sure the possible performance issues are about it, and not about creating/reflowing layout objects for the new elements? (innerHTML implementation is in common cases quite well optimized.) Thanks for the pointers! Ha, I sould have been more expressive. I am not interested in performance: I have written an eslint plugin to identify and disallow future patches that contain assignments of innerHTML which do not use our XSS sanitizer (https://developer.mozilla.org/en-US/Firefox_OS/Security/Security_Automation). Now I want to look at existing issues and identify those that should be fixed first. I hope that an instrumentation (and stack traces) can give me a better idea of what different code paths lead to these sinks. (On the side, I was also hoping to learn something new :)) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Modifying Element.prototype for all globals
On 06/18/2015 03:37 PM, Frederik Braun wrote: Hi, I am planning to do a little analysis of FxOS Gaia to identify instances of innerHTML assignments at runtime[1]. I am hoping this gives me a more precise number about hot paths (in contrast to just looking at the source code). What kind of information would you like to get out from the analysis? And before even spending too much time with innerHTML, are you sure the possible performance issues are about it, and not about creating/reflowing layout objects for the new elements? (innerHTML implementation is in common cases quite well optimized.) If you end up hacking C++ side of innerHTML, the relevant code lives in http://hg.mozilla.org/mozilla-central/annotate/a3f280b6f8d5/dom/base/FragmentOrElement.cpp#l2769 (except for style, HTMLStyleElement.cpp, and script, HTMLScriptElement.cpp, elements which have different innerHTML behavior.) In an ideal world I would write a script along the lines of `Object.defineProperty(Element.prototype, 'innerHTML', …)` and inject this into every app, or at best run it somewhere so that every Element's prototype chains back to mine. I know that I can not modify/inherit prototypes across origins, so I am wondering if there is something I could do with chrome privileges - maybe patching shell.js (https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js), as it is the main entrypoint from Gecko into Gaia. Does this sound feasible? Are there any previous experiments that I could refer to? Well, there is always profiling. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler But this all depends on what kind of data you want to get. -Olli Thanks! Freddy [1] I intend to run the full test suite, not in production or anything. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On Wednesday, June 17, 2015 at 9:57:12 PM UTC-4, Gregory Szorc wrote: First thing is first: what are the blockers to mass rewriting mozilla-central with clang-format's output? For the record I'm in favour of auto-clang-formatting the codebase, but the last time I tried running clang-format on the APZ code [1] there were at least two issues: 1) Comments that exceed the 80-char limit get wrapped blindly, rather than being rewrapped properly. This results in comment blocks that look like this: // This is a comment that was previously just over the eighty // character // limit but got rewrapped by clang-format just blindly // inserting // linebreaks willy-nilly and requires manual fixup. I think this is an issue that should be fixed in clang-format. However, to work around this incrementally I have been manually rewrapping comment blocks in the APZ code if I'm touching them anyway. 2) MOZ_BEGIN_NESTED_ENUM_CLASS seems to trip up the formatter and it misformats the code after that. Cheers, kats [1] https://bugzilla.mozilla.org/show_bug.cgi?id=971970 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Modifying Element.prototype for all globals
You can add a listener for DOMWindowCreated on the iframe, or content-document-global-created from the XPCOM preferences service in order to get notifications when globals are being created. On Thu, Jun 18, 2015 at 7:07 AM, Frederik Braun fbr...@mozilla.com wrote: On 18.06.2015 15:51, smaug wrote: On 06/18/2015 03:37 PM, Frederik Braun wrote: Hi, I am planning to do a little analysis of FxOS Gaia to identify instances of innerHTML assignments at runtime[1]. I am hoping this gives me a more precise number about hot paths (in contrast to just looking at the source code). What kind of information would you like to get out from the analysis? And before even spending too much time with innerHTML, are you sure the possible performance issues are about it, and not about creating/reflowing layout objects for the new elements? (innerHTML implementation is in common cases quite well optimized.) Thanks for the pointers! Ha, I sould have been more expressive. I am not interested in performance: I have written an eslint plugin to identify and disallow future patches that contain assignments of innerHTML which do not use our XSS sanitizer ( https://developer.mozilla.org/en-US/Firefox_OS/Security/Security_Automation ). Now I want to look at existing issues and identify those that should be fixed first. I hope that an instrumentation (and stack traces) can give me a better idea of what different code paths lead to these sinks. (On the side, I was also hoping to learn something new :)) ___ 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
In http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/larch-win64/latest/
The graphene-41.0a1.en-US.win64.zip Doesn't package with icu dlls -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On Thursday, June 18, 2015 at 7:28:44 AM UTC-7, kgu...@mozilla.com wrote: 1) Comments that exceed the 80-char limit get wrapped blindly, rather than being rewrapped properly. This results in comment blocks that look like this: // This is a comment that was previously just over the eighty // character // limit but got rewrapped by clang-format just blindly // inserting // linebreaks willy-nilly and requires manual fixup. I think this is an issue that should be fixed in clang-format. However, to work around this incrementally I have been manually rewrapping comment blocks in the APZ code if I'm touching them anyway. Can we sidestep this by punting on enforcing a line length restriction with clang-format? I think it would be reasonably uncontroversial to just do the following initially: - spacing - indentation - bracing 2) MOZ_BEGIN_NESTED_ENUM_CLASS seems to trip up the formatter and it misformats the code after that. AFAICT there's no such thing as MOZ_BEGIN_NESTED_ENUM_CLASS -e ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with building Xulrunner windows 64 bit.
On Wednesday, June 17, 2015 at 10:29:24 PM UTC+5:30, Adrian Kalla wrote: W dniu 06/17/2015 o 06:33 PM, Abhay Kumar Somani pisze: Hi, I am working in a company and we are using XULRunner to deploy our app. Now we have decided to upgrade our app to 64bit. While upgrading we got to know that Mozilla doesn't provides 64bitXULRunner for windows. However, while searching in the net, I found a website that provides 64bit binaries for windows but it is unofficial, and no source code is available there, so don't know whether it is safe to consume them as per our security concerns. So, if anybody could help me with building a 64bit XULRunner for windows or if Mozilla team plan to provide 64bit Windows build anytime soon, it will of great help. Otherwise if someone can kindly help with building 64bit binaries. Thanks in advance. Hi, building XULRunner is not different from building Firefox. When already deploying an own app, I expect you know the basics of how to compile an application ;) You should start with this three links: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites https://developer.mozilla.org/en-US/docs/Simple_Firefox_build https://developer.mozilla.org/en-US/docs/Configuring_Build_Options There also are official Win64 builds, but only for central, aurora and the beta stage, e.g.: https://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/latest-beta/runtimes/xulrunner-39.0b6.en-US.win64.zip Best regards FYI: I'm not sure if you are aware of this, but XULRunner is in the process of a slow and painful death, as no-one seems to care about it anymore. So I'm not so sure, if it is a good idea to depend on it... Thanks Adrian for your help. And also thanks for the information about XULRunner in the process of end, I didn't knew that. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag
This landed as the mach try command. For more details run |./mach help try| (excerpted below) and see the discussion in bug 1149670. The highlights here are partly automated try syntax generation for testing changes relevant to tests in certain directories, and pushing try syntax to the try server without the benefit of mq. Chris Pushes the specified tests to try. The simplest way to specify tests is by using the -u argument, which will behave as usual for try syntax. This command also provides a mechanism to select test jobs and tests within a job by path based on tests present in the tree under that path. Mochitests, xpcshell tests, and reftests are eligible for selection by this mechanism. Selected tests will be run in a single chunk of the relevant suite, at this time in chunk 1. Specifying platforms is still required with the -p argument (a default is taken from the AUTOTRY_PLATFORM_HINT environment variable if set). Tests may be further filtered by passing one or more --tag to the command. To run suites in addition to those determined from the tree, they can be passed to the --extra arguent. The command requires either its own mercurial extension (push-to-try, installable from mach mercurial-setup) or a git repo using git-cinnabar (available at https://github.com/glandium/git-cinnabar). Global Arguments: -v, --verbose Print verbose output. -l FILENAME, --log-file FILENAME Filename to write log data to. --log-intervalPrefix log line with interval from last message rather than relative time. Note that this is NOT execution time if there are parallel operations. --log-no-timesDo not prefix log lines with times. By default, mach will prefix each output line with the time since command start. -h, --helpShow this help message. --debug-command Start a Python debugger when command is dispatched. Command Arguments: pathsPaths to search for tests to run on try. -n Print detailed information about the resulting test selection and commands performed. -p PLATFORMS Platforms to run. (required if not found in the environment) -u TESTS Test jobs to run. These will be used in place of suites determined by test paths, if any. --extra EXTRA_TESTS Additional tests to run. These will be added to suites determined by test paths, if any. -b BUILDSBuild types to run (d for debug, o for optimized) --tag TAGS Restrict tests to the given tag (may be specified multiple times) --no-pushDo not push to try as a result of running this command (if specified this command will only print calculated try syntax and selection info). On Tue, Mar 31, 2015 at 10:57 AM, Christopher Manchester chmanches...@gmail.com wrote: I filed bug 1149670 for the mach try feature. On Tue, Mar 31, 2015 at 10:39 AM, Andrew Halberstadt ahalberst...@mozilla.com wrote: It's technically already possible by modifying the in-tree mozharness configs here: https://dxr.mozilla.org/mozilla-central/source/testing/config/mozharness However it's not easy to figure out what needs to be modified to get the desired results. Some sort of |mach try| like command is going to be worked on in Q2 to make pushing various test configurations to try easier, I'm not 100% sure how it will be implemented yet though. In the meantime, if you get stuck trying to modify the mozharness configs, let me know and I can come up with an example patch. -Andrew On 31/03/15 01:06 PM, Bobby Holley wrote: This sounds awesome! Is there an estimate of when we'll be able to use it for try pushes? On Tue, Mar 31, 2015 at 9:30 AM, Andrew Halberstadt ahalberst...@mozilla.com mailto:ahalberst...@mozilla.com wrote: As of bug 987360, you can now run all tests with a given tag for mochitest (and variants), xpcshell and marionette based harnesses. Tags can be applied to either individual tests, or the DEFAULT section in manifests. Tests can have multiple tags, in which case they should be comma delimited. To run all tests with a given tag, pass in --tag tag name to the mach command. For example, let's say we want to group all mochitest-plain tests related to canvas together. First we'd add a 'canvas' tag to the DEFAULT section in https://dxr.mozilla.org/mozilla-central/source/dom/ canvas/test/mochitest.ini [DEFAULT] tags = canvas We notice there is also a canvas related test under dom/media, namely: https://dxr.mozilla.org/mozilla-central/source/dom/ media/test/mochitest.ini#541 Let's pretend it is already tagged with the 'media' tag, but that's ok,
Re: Revisiting modelines in source files
On Thu, Jun 18, 2015 at 8:36 PM, Eric Rahm er...@mozilla.com wrote: 2) MOZ_BEGIN_NESTED_ENUM_CLASS seems to trip up the formatter and it misformats the code after that. AFAICT there's no such thing as MOZ_BEGIN_NESTED_ENUM_CLASS It was removed in bug 290. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DXR 2.0 And Beyond: A Whistler Session
Dear friends with large codebases— You are heartily invited to a DXR 2.0 pony show and design session next Friday in Whistler, where we'll demonstrate the new abilities of this near-rewrite, answer questions, and figure out what goes next on the roadmap. For those not familiar with it, DXR is a code search and browsing tool that indexes not only the text of your program but its structure as well, using data exfiltrated from compiler or parsers. It's also one of the few engines out there that will let you run arbitrary regexes across a large codebase in tenths of a second. We'll demo… * Improved C/C++ analysis * Multi-language support—Python and Rust, for starters * Generic identifier search * Image browsing * Zero slow queries * Independent, parallel tree indexing. (This will help us get all the trees currently under MXR indexed.) * Permalinks to old revisions * A new plugin architecture so we can add new languages, query types, and cross references easily (https://dxr.readthedocs.org/en/es/development.html#writing-plugins) Now that the infrastructure is solid, we can strike out in many interesting directions. Come and campaign for what you want! Just a few ideas: * Cross-project search * Arbitrary boolean queries * Search by color * JS support * IDL support * Useful visualizations Add it to your Whistler schedule: http://sched.co/3gWR Cheers, Erik Rose DXR Project Lead ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info
It sounds like there are three use cases for WEBGL_debug_renderer_info: 1. Correlating GPU info with bug reports (e.g. YouTube). 2. Web content workarounds for GPU bugs. 3. Fingerprinting for user tracking. To get #1, some of #2, and none of #3, can we just whitelist WEBGL_debug_renderer_info for youtube.com or a couple of A-tier sites? For #1 to benefit Mozilla, we need large video sites that are already gathering this information and willing to share it with us. YouTube is. I don't know about other sites. To reduce the threat of #3, we could restrict the whitelist to https://youtube.com, excluding HTTP and youtube-nocookie.com. On 6/16/15 3:51 PM, Jeff Gilbert wrote: Yes, perpetual workarounds are an issue, but we can't handle this sort of debugging at scale. Further, this would have been even faster (particularly for less-common hardware) if the reporter could tell us exactly which hardware an issue is present on. Historically, it has been difficult to reproduce many reported bugs, and playing telephone between gecko-dev/website-dev/user-with-issue is excruciating, and means that some bugs will literally go unfixed anyway. We also *cannot* ship most workarounds with our driver blacklist info, since they usually require new code. Site-local workarounds are a strong desire for A-tier sites because we simply *cannot* respond fast enough, particularly on the Release branch. (or even late Beta) Ideally, we'll eventually have enough of a handle on the long tail of driver bugs that we can look at sunsetting this. We could include an entry in the blacklist download to force problematic hardware to expose this info (once we identify them as such!), while leaving believed-good hardware masked off. We could start putting this together already, though I don't know if we're confident enough in having any driver on the whitelist yet. On Tue, Jun 16, 2015 at 7:25 AM, Jeff Muizelaar jmuizel...@mozilla.com wrote: A concrete example of this kind of thing occurred a little while ago with Google Maps. They reported that users on G41 class hardware were getting distortion when zoomed out in earth mode. This was because of our switch to D3D11 ANGLE. When we got this report we were able to reproduce the problem and block D3D11 ANGLE on that hardware. Google Maps blacklists this hardware when it can detect it using WEBGL_debug_renderer_info and if we had been exposing WEBGL_debug_renderer_info we would not have found this problem as quickly as we did. We would've been able to find this problem even faster if we had a better way for users to get this information to websites. The current process with Google Maps seems to require users to complain on their forum, for Google to ask them for the output of dxdiag and for them to manually see a pattern in the output. This is obviously a process with very low success and it seems like we could do something to make it better. -Jeff On Mon, Jun 15, 2015 at 9:18 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: I'm concerned this will discourage websites from reporting WebGL issues because it will be easier just to block whatever device has the problem they're running in to. This creates an additional burden on the web developer and essentially creates the user agent problem all over again, but at much worse scale because of the wide range of possible devices. This may be manageable for very large developers like Google but I don't think it scales across web developers. We are typically in a better position to control and update any WebGL blacklist. I've suggested that creating an easy way to rely diagnostic information to a website in the event of a problem is a better solution for improving the overall quality of our WebGL implementation and sharing that benefit with all websites instead of just benefiting large properties like Google's. -Jeff On Mon, Jun 15, 2015 at 7:16 PM, Jeff Gilbert jgilb...@mozilla.com wrote: Summary: The WEBGL_debug_renderer_info extension allows for querying which driver (and commonly GPU) a WebGL context is running on. Specifically, it allows querying the RENDERER and VENDOR strings of the underlying OpenGL driver. By default, RENDERER and VENDOR queries in WebGL yield safe but useless values. (For example, Gecko returns Mozilla/Mozilla for RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the underlying graphics driver. These values are combined to form the WebGL Renderer field in about:support. On my system, these are: * UNMASKED_RENDERER_WEBGL: ANGLE (NVIDIA GeForce GT 750M Direct3D11 vs_5_0 ps_5_0) * UNMASKED_VENDOR_WEBGL: Google Inc. [1] Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1171228 Link To Standard: https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/ Do other browser engines implement this: Chrome and IE implement this; Safari does not. Platform Coverage: All platforms. Current Target Release: Firefox 41
Treeherder Hacking Sessions @ Whistler
The Treeherder devs will be on-hand for a hacking session in Whistler Thursday next week. If you've curious to get your hands into the Treeherder code, or have a workflow you'd like to improve, please stop by. This session will be two-track: One for the Treeherder UI, the other aimed at data retrieval and submission. We'd love to see you there! http://juneworkweekwhistler2015.sched.org/event/8ec839a82359e1687665afb5460ecba4#.VYM62KLqnBI Note that this event had originally been scheduled for Wednesday, but has been moved to allow people time to attend a developer productivity workshop which was scheduled at the same time. For more information on Treeherder, see: https://wiki.mozilla.org/Auto-tools/Projects/Treeherder Detailed info on the two tracks follows. -- Track 1: Treeherder UI The Treeherder UI is written in AngularJS and Bootstrap with some JQuery sprinkled in. Some ideas of things you could hack on: * Good first bugs: http://www.joshmatthews.net/bugsahoy/?reporting=1unowned=1 * Support retriggering multiple jobs from the Pinboard Panel: http://bugzil.la/1121998 * Rework the Job Exclusion editor: http://bugzil.la/1175215 * Make filters more discoverable. Branch in progress: https://github.com/mozilla/treeherder/pull/633 * Bring your own idea. :) If you're interested in JavaScript (and possibly AngularJS) and want to help improve the Treeherder UI workflows for yourself or others, we'd love to hack with you. Track 2: Treeherder Data Mining Treeherder provides a rich JSON REST API from which you can get detailed information on all the builds and tests that our infrastructure performs, but the details on how to do so have not been well documented up to this point. We're going to attempt to address this in a data mining hackfest: writing up detailed documentation both on the REST API and building up our new python client to treeherder, which will make getting the information you're interested in a snap. If you think you might be able to use Treeherder's data in a project you have in mind, this hackfest is for you. Will ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On 18/06/2015 12:15, ISHIKAWA,chiaki wrote:
Unfortunately, it does not handle the particular coding style of
#if,#else,#endif in JavaScript source files since
use of C-style macro preprocessor is not quite standard.
Nobody seems to have written a emacs mode for this C-style macro use in
JavaScript code. Correct me if I am wrong on this point.
(When I tried to indent some broken JavaScript source files
it could not handle #if,#else,#endif, etc. very well.)
I wonder if there is an automatic formatter for JavaScript
that handles this particular issue of non-standard C-preprocessor usage.
If not, we may be forced to rewrite such macro usage into
BEFORE:
#if defined(WIN32)
blabla
#else
gazonk-foobar
#endif
AFTER
if(C.system_win32) {
blabla
} else {
gazonk-foobar
}
or something like that (modulo the correct positioning of {, },
else) by introducing system-wide constant that defines
system types. Run-time overhead should be minimal given the modern JS
interpreter and optimizing JIT compiler.
Just a thought.
You can convert pre-processor directives to normal JavaScript using
AppConstants.jsm
Phil
--
Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 18-06-15 11:31, smaug wrote: One common auto usage I've seen is for storing the result of a static_cast. In this scenario, it lets you avoid repeating yourself and makes for more concise code. It still hurts readability. Whenever a variable is declared using auto as type, it forces reader to read the part after '='. So, when reading code below some auto foo = ..., in order to check again the type of foo, one needs to read the = ... part. I disagree it hurts readability. Repeating the exact same thing twice does not make things more readable IMHO. In your example you're forced to read the part right of = but that's 1) *instead of* reading the more complicated LHS 2) likely what you had to do anyway. FWIW: https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#auto -- GCP ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 06/02/2015 11:56 PM, Daniel Holbert wrote: On 06/02/2015 12:58 PM, smaug wrote: So, I'd like to understand why people think 'auto' is a good thing to use. (bz mentioned it having some use inside bindings' codegenerator, and sure, I can see that being rather valid case.) One common auto usage I've seen is for storing the result of a static_cast. In this scenario, it lets you avoid repeating yourself and makes for more concise code. It still hurts readability. Whenever a variable is declared using auto as type, it forces reader to read the part after '='. So, when reading code below some auto foo = ..., in order to check again the type of foo, one needs to read the = ... part. I don't think there's much danger of fragility in this scenario (unlike your refcounting example), nor is there any need for a reviewer/code-skimmer to do research to find out the type -- it's still right there in front of you. (it's just not repeated twice) For example: auto concretePtr = static_castReallyLongTypeName*(abstractPtr); Nice concise (particularly if the type name is namespaced or otherwise really long). Though it perhaps takes a little getting used to. (I agree that mixing auto with smart pointers sounds like a recipe for fragility disaster.) ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 06/02/2015 11:56 PM, Daniel Holbert wrote: On 06/02/2015 12:58 PM, smaug wrote: So, I'd like to understand why people think 'auto' is a good thing to use. (bz mentioned it having some use inside bindings' codegenerator, and sure, I can see that being rather valid case.) One common auto usage I've seen is for storing the result of a static_cast. In this scenario, it lets you avoid repeating yourself and makes for more concise code. It still hurts readability. Whenever a variable is declared using auto as type, it forces reader to read the part after '='. So, when reading code below some auto foo = ..., in order to check again the type of foo, one needs to read the = ... part. I don't think there's much danger of fragility in this scenario (unlike your refcounting example), nor is there any need for a reviewer/code-skimmer to do research to find out the type -- it's still right there in front of you. (it's just not repeated twice) For example: auto concretePtr = static_castReallyLongTypeName*(abstractPtr); Nice concise (particularly if the type name is namespaced or otherwise really long). Though it perhaps takes a little getting used to. (I agree that mixing auto with smart pointers sounds like a recipe for fragility disaster.) ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
