Re: C++ Standards Committee meeting next week
On 10/1/2013 4:51 PM, Botond Ballo wrote: I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384 is the list of analyses we currently do in Mozilla. I know must_override has been mentioned once or twice with respect to C++ standardization, but I can't recall where. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. What is the feedback from non-Clang developers about prototyping in their compilers? Are we likely to see this implemented as soon as stable wording is finalized, or are compiler vendors likely to drag their feet and implement it in the last tranche of updates (basically, is the uptake going to be like auto or rvalue references, or will it be like generalized attributes or alignof). Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Huh. For networking, there are three proposals in the works: URIs [5], IP addresses [6], and byte order [7]. I believe URIs and IP addresses are headed towards one Technical Specification, and byte order towards another. Presumably more will follow that build on these (e.g. TCP socket communication). It's a shame that sockets come so much later, but nonetheless totally understandable. -- 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
Re: C++ Standards Committee meeting next week
I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384 is the list of analyses we currently do in Mozilla. I know must_override has been mentioned once or twice with respect to C++ standardization, but I can't recall where. Interesting. How is this static analysis implemented - a clang plugin? Does it cause compiler errors or warnings when the annotations aren't obeyed? I haven't heard any discussion of such annotations in Chicago. One attribute, [[deprecated]], was standardized, but that's it. I'll keep my eyes open and let you know if I come across any talk of them. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. What is the feedback from non-Clang developers about prototyping in their compilers? Are we likely to see this implemented as soon as stable wording is finalized, or are compiler vendors likely to drag their feet and implement it in the last tranche of updates (basically, is the uptake going to be like auto or rvalue references, or will it be like generalized attributes or alignof). I'm not aware of other compilers actively working on it at the moment. It sounded like they were waiting for clang to implement it to see if the idea is viable at all. An EDG developer present at the meeting pointed out that many of the difficulties in implementing modules are the same difficulties that are involved in implementing 'export'. EDG was the only compiler that implemented 'export', so that's not a very encouraging sign, but I also think the level of demand is much higher for modules (which most people agree will be very useful) than it was for export (which most people agreed was useless). One thing that was brought up is that clang was able to leverage its PCH (pre-compiled header) implementation, which is basically just a serialized AST, for its implementation of modules, but GCC's PCH implementation, which is just a compiler memory dump, is less suitable for this purpose. This suggests that it will require more effort for GCC to implement modules than clang. Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Huh. I'll post a follow-up email about the various Technical Specifications that are in the works, and what's likely to be in them. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds. $ time ./mach build binaries 0:01.96 /usr/bin/make -j8 -s binaries 0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m28.291s user0m8.685s sys 0m4.178s Do you have any plans to bring down the overhead? Do you know where this overhead is coming from? Thanks! Ehsan On 2013-10-01 9:17 PM, Mike Hommey wrote: Hi, If you've read the You want faster builds, don't you thread, you may know that some build improvements have recently landed. I just landed the most important part of it all, and we should now be in a much better place, but, as I'm very cautious, and as this is incremental improvements to an existing complex build system that is hard to improve all at once without some subtle breakages, this is opt-in. It also doesn't work with pymake because of bug 918652. At this point, you probably want to know what it is and how to use it. There is now a new target for incremental C/C++ rebuilds. What this means is, you build once like usual. Then after you do your C/C++ changes, instead of: - mach build or make -C objdir, which takes forever - mach build subdirectory/of/the/changes, which sometimes rebuilds toolkit/library, sometimes not, depending what you're rebuilding. - make -C objdir/subdirectory/of/the/changes make -C objdir/toolkit/library, which may actually not be enough. you can now do: - mach build binaries or - make -C objdir binaries It will rebuild your changes and everything that needs rebuilding because of them. It will also do that quickly. There are a few caveats: - it only handles C/C++ changes, including headers. It doesn't handle js modules, chrome data, etc. - it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a followup for this to happen: bug 921309. - it doesn't handle changes to nss, nspr, icu or ffi. If you do changes there, you still need to run a normal build. - it doesn't work without doing a normal build first. - while it shouldn't break your builds, it might subtly skip what you would expect it to build. If it does, please file a bug or contact me on irc. You can still use the old ways until your issues are fixed. Something else that I landed today is support to skip directories during a normal build when they're not relevant to the build. As always, I'm overcautious and this is opt-in. If you want to opt-in for this (and future experimental improvements), please add export MOZ_PSEUDO_DERECURSE=1 to your mozconfig. Except if you're using pymake, sadly. The more people test those experimental improvements, the quicker they can become the default for everyone. For those interested in the gory details, I'll post some on my blog within the next few days. Mike ___ dev-builds mailing list dev-bui...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 2013-10-02 11:38 AM, Botond Ballo wrote: I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384 is the list of analyses we currently do in Mozilla. I know must_override has been mentioned once or twice with respect to C++ standardization, but I can't recall where. Interesting. How is this static analysis implemented - a clang plugin? Does it cause compiler errors or warnings when the annotations aren't obeyed? It is implemented as a clang plugin here: http://mxr.mozilla.org/mozilla-central/source/build/clang-plugin/clang-plugin.cpp. The compiler will emit an error if it detects a violation of the annotations. Cheers, Ehsan I haven't heard any discussion of such annotations in Chicago. One attribute, [[deprecated]], was standardized, but that's it. I'll keep my eyes open and let you know if I come across any talk of them. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. What is the feedback from non-Clang developers about prototyping in their compilers? Are we likely to see this implemented as soon as stable wording is finalized, or are compiler vendors likely to drag their feet and implement it in the last tranche of updates (basically, is the uptake going to be like auto or rvalue references, or will it be like generalized attributes or alignof). I'm not aware of other compilers actively working on it at the moment. It sounded like they were waiting for clang to implement it to see if the idea is viable at all. An EDG developer present at the meeting pointed out that many of the difficulties in implementing modules are the same difficulties that are involved in implementing 'export'. EDG was the only compiler that implemented 'export', so that's not a very encouraging sign, but I also think the level of demand is much higher for modules (which most people agree will be very useful) than it was for export (which most people agreed was useless). One thing that was brought up is that clang was able to leverage its PCH (pre-compiled header) implementation, which is basically just a serialized AST, for its implementation of modules, but GCC's PCH implementation, which is just a compiler memory dump, is less suitable for this purpose. This suggests that it will require more effort for GCC to implement modules than clang. Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Huh. I'll post a follow-up email about the various Technical Specifications that are in the works, and what's likely to be in them. Botond ___ 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: C++ Standards Committee meeting next week
So, after writing about a bunch of things that _won't_ be in C++14,
let me summarize what _will_ be. Here are the highlights:
* Return type deduction
In C++11, we have decltype() and late-specified return types
(return types written after the argument list so they can
mention arguments). These were often combined to write code
like this:
auto function(A a, B b) - decltype(expr)
{
return expr;
}
Having to repeat 'expr' is rather unfortunate, and C++14
fixes that. You can now write:
auto function(A a, B b)
{
return expr;
}
It works even if the function body contains multiple
statements, control flow, etc. The only restriction is
that if there are multiple return expressions, they
must all have the same type.
* Improved lambdas
* Generic lambdas
These are lambdas with 'auto' arguments which acts as
template parameters rather than concrete types:
// This lambda can be called with arguments of any type.
[](auto a, auto b){ return a b; }
Implementation-wise, they are just local structures with
a templated call operator (while ordinary lambdas are
local structures with a non-templated call operator).
* Init-captures
These allow you to declare new variables in the capture-list
rather than just capture existing variables from the outer
scope. The new variables can be initialized in any way,
including by move, something that wasn't possible before.
std::unique_ptrFoo p = ...;
...
// No way to capture 'p' in C++11. Can't capture it by
// value because it's not copyable; don't want to capture
// it by reference because the reference could become
// dangling if the lambda is passed out of the function.
// In C++14 we can do this:
[newp = move(p)](...){...}
* Variable templates
Up until now, only functions and classes/structures could be
templates. Now, variables can be too.
* More powerful constexpr
Up until now, constexpr functions were limited to containing
a single return expression. Now they can contain multiple
statements, loops, and so on. Basically, they can now be
written in an imperative style rather than a functional
style. They still can't modify non-local state.
* Improved literals
* Binary literals: 0b00101010101
* Digit separators: int x = 1'000'000; // don't ask
* Standard user-defined literals
C++11 introduced user-defined literals. C++14 intoduces
some standard ones:
foos // std::string literal
30s // std::chrono::seconds literal
Yes, they are both 's'. C++ knows when to use which.
Other durations have them too, so you can write things
like
1h + 10min + 30s
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
8.8s here! ~1.5 is startup and checking the build backend is up to date (lots of stats) ~1.5s is processing install manifests. Rest is make processing. The fact that your machine spent ~20s doing install manifest processing tells me: a) Your directory tree wasn't cached (try running again) b) Your I/O layer is slow (I'm building with an SSD) c) Something else wonky creating slow I/O 0:00.14 /usr/bin/make -j8 binaries 0:00.53 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:00.82 make[1]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.16 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:01.45 make[2]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.56 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.56 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.57 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.68 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.72 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.86 From ./dist/include: Kept 3518 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.10 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.10 /usr/bin/make recurse_binaries On 10/2/13 5:42 PM, Ehsan Akhgari wrote: I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds. $ time ./mach build binaries 0:01.96 /usr/bin/make -j8 -s binaries 0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m28.291s user0m8.685s sys0m4.178s Do you have any plans to bring down the overhead? Do you know where this overhead is coming from? Thanks! Ehsan On 2013-10-01 9:17 PM, Mike Hommey wrote: Hi, If you've read the You want faster builds, don't you thread, you may know that some build improvements have recently landed. I just landed the most important part of it all, and we should now be in a much better place, but, as I'm very cautious, and as this is incremental improvements to an existing complex build system that is hard to improve all at once without some subtle breakages, this is opt-in. It also doesn't work with pymake because of bug 918652. At this point, you probably want to know what it is and how to use it. There is now a new target for incremental C/C++ rebuilds. What this means is, you build once like usual. Then after you do your C/C++ changes, instead of: - mach build or make -C objdir, which takes forever - mach build subdirectory/of/the/changes, which sometimes rebuilds toolkit/library, sometimes not, depending what you're rebuilding. - make -C objdir/subdirectory/of/the/changes make -C objdir/toolkit/library, which may actually not be enough. you can now do: - mach build binaries or - make -C objdir binaries It will rebuild your changes and everything that needs rebuilding because of them. It will also do that quickly. There are a few caveats: - it only handles C/C++ changes, including headers. It doesn't handle js modules, chrome data, etc. - it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a followup for this to happen: bug 921309. - it doesn't handle changes to nss, nspr, icu or ffi. If you do changes there, you still need to run a normal build. - it doesn't work without doing a normal build first. - while it shouldn't break your builds, it might subtly skip what you would expect it to build. If it does, please file a bug or contact me on irc. You can still use the old ways until your issues are fixed. Something else that I landed today is support to skip directories during a normal build when they're not relevant to the build. As always, I'm overcautious and this is opt-in. If you want to opt-in for this (and future experimental improvements), please add export MOZ_PSEUDO_DERECURSE=1 to your mozconfig. Except if you're using pymake, sadly. The more people test those experimental improvements, the quicker they can become the default for everyone. For those interested in the gory details, I'll post some on my blog within the
Re: Faster builds, now.
this works great for me.. touching network/protocol/http/nsHttpChannel.cpp and rebuilding with mach build binaries runs in 26 seconds compared to 61 with just mach build, and I see the same ~35 second savings when doing it on a total nop build (39 vs 5). awesome. -P On Tue, Oct 1, 2013 at 9:17 PM, Mike Hommey m...@glandium.org wrote: Hi, If you've read the You want faster builds, don't you thread, you may know that some build improvements have recently landed. I just landed the most important part of it all, and we should now be in a much better place, but, as I'm very cautious, and as this is incremental improvements to an existing complex build system that is hard to improve all at once without some subtle breakages, this is opt-in. It also doesn't work with pymake because of bug 918652. At this point, you probably want to know what it is and how to use it. There is now a new target for incremental C/C++ rebuilds. What this means is, you build once like usual. Then after you do your C/C++ changes, instead of: - mach build or make -C objdir, which takes forever - mach build subdirectory/of/the/changes, which sometimes rebuilds toolkit/library, sometimes not, depending what you're rebuilding. - make -C objdir/subdirectory/of/the/changes make -C objdir/toolkit/library, which may actually not be enough. you can now do: - mach build binaries or - make -C objdir binaries It will rebuild your changes and everything that needs rebuilding because of them. It will also do that quickly. There are a few caveats: - it only handles C/C++ changes, including headers. It doesn't handle js modules, chrome data, etc. - it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a followup for this to happen: bug 921309. - it doesn't handle changes to nss, nspr, icu or ffi. If you do changes there, you still need to run a normal build. - it doesn't work without doing a normal build first. - while it shouldn't break your builds, it might subtly skip what you would expect it to build. If it does, please file a bug or contact me on irc. You can still use the old ways until your issues are fixed. Something else that I landed today is support to skip directories during a normal build when they're not relevant to the build. As always, I'm overcautious and this is opt-in. If you want to opt-in for this (and future experimental improvements), please add export MOZ_PSEUDO_DERECURSE=1 to your mozconfig. Except if you're using pymake, sadly. The more people test those experimental improvements, the quicker they can become the default for everyone. For those interested in the gory details, I'll post some on my blog within the next few days. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
In addition to the C++14 standard, the Committee is working on a number of follow-up documents called Technical Specifications (TS), which carry less weight than the standard, but indicate an intention to standardize a new library or language feature in a future standard: * Concepts Lite TS (my favourite) Concepts are a mechanism for constraining template parameters. Today we often write code like this: template typename Container void sort(Container c); Our intention is that the type used as a template argument for 'Container' be a container type, but the compiler doesn't enforce this - it will accept any type there, and then give cryptic errors from deep within the template's implementation when it tries to use the argument as a container. Concepts allows us to define a concept called 'Container' which expresses what we mean by a 'container type', and then write the template like this instead: template typename C requires ContainerC void sort(C c); Or as a short form: template Container C void sort(C c); When calling this function, the compiler checks at the call site whether the template argument satisfies the Container concept, and give a much friendlier error if it doesn't. It's also possible to check the definition of a template to make sure it doesn't do anything with the template arguments that's not specified by the concepts to which they conform. A 'full' concepts feature would include both directions of checking (checking the call sites and the definitions). The committee tried standardizing full concepts for C++11, but ran into a lot of complexity. It is now resurrecting the feature in a 'lite' form that only includes checking of the call sites. The details of Concepts Lite can be found here [1]. * Array Extensions TS Support for arrays whose size isn't known at compile time. C calls these Variable-Lengths Arrays (VLAs). C++ stubbornly refuses to call them VLAs, and calls them Arrays of Runtime Bound (ARBs) instead (there are some minor differences between the two flavours, for example you can call sizeof() on a VLA (and it will be evaluated at runtime), but not on an ARB). The TS will also include a library that wraps ARBs into a nicer interface, much like how std::array wraps regular arrays into a nicer interface. These were originally going to be in C++14, but were moved into a TS because the library interface isn't fully fleshed out yet. * Library Fundamentals TS This will contain the new optional library (originally headed for C++14 but the committee felt it was safer to put it into a TS instead) and possibly some other utilities. * Networking TS There will actually be a series of Networking TS's. The first will specify URIs and IP addresses. The second will specify byte-order conversions. Future ones may deal with higher-level functionality like sockets. * Filesystem TS [2] There may also be a follow-up TS to this that provides additional features e.g. for enterprise filesystems. * Transactional Memory TS A synchronization primitive built into the language. The proposal can be found here [3]. * Parallelism Extensions TS Parallel versions of standard library algorithms. This is in a relatively early stage, but it will possibly be based on [4]. * Concurrency Extensions TS Language features that make it easier to write asynchronous/concurrent code. Also in an early stage, proposals being considered include [5] and [6]. I believe that most of these are planned for publication in 2014, though probably not the last two, nor the follow-ups to the Networking and Filesystem TS's. Botond [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf [2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3693.html [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3718.pdf [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3724.pdf [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3731.pdf [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3721.pdf ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
Finally, let me describe the process for submitting proposals to the committee for new libraries or language features. First, let me briefly describe the internal organization of the committee. The committee is subdivided into four Working Groups: Core, Evolution, Library, and Library Evolution. Evolution looks at proposals for new language features at a high-level: how well do they fit into the design of the language. Core looks at them at a lower-level: is the specific wording consistent with the wording of the rest of the standard. Library Evolution and Library are analogous to Evolution and Core, but for the standard libraries rather than for language features. In addition, some feature areas have a Study Group which looks at proposals before sending them to Evolution or Library Evolution. So, a language proposal progresses through the following stages to become standardized: * the relevant Study Group (if there is one) * Evolution * Core * vote by the full committee A library proposal progresses in a similar way but goes through Library Evolution and Library instead. (This is illustrated very nicely here [1].) If someone is interested in writing a proposal, here's what to do: * Bring up the idea on the std-proposals discussion group [2] to gauge the community's level of interest. * Write up an initial draft of the proposal, get some more feedback on it at std-proposals. This initial draft does not need to contain standard wording yet. * Formally submit the proposal. I believe this is done by emailing the committee's project editor, but I can check up on this. The proposal will get an Nxxx number and show up in committee mailing like this one [3]. * Present the proposal to the appropriate Study Group if one exists, or else to the Evolution Working Group, at a committee meeting. The committee meets 2-3 times a year, and the meetings are open for anyone to attend. If you can't attend in person, you can find someone to champion the proposal for you. * It's rare for a Study Group or Evolution to accept a proposal right away. Most often they will give you feedback on the proposal and encourage you to write an updated proposal and come back. Several iterations of this can happen before Evolution accepts the proposal. * At some point in this process, standard wording for the proposal needs to be written. Once Evolution has approved the proposal, Core will look at the wording. Sometimes they find problems and send the proposal back to Evolution. If not, the proposal is ready to be voted on in full committee. Most proposals pass in full committee after being approved by Core and Evolution. (If proposing a library feature rather than a language feature, replace 'Evolution' with 'Library Evolution' and 'Core' with 'Library' in the above). OK, that was my last long email :) Feel free to ask me any questions. Botond [1] http://isocpp.org/std/the-committee [2] https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/#mailing2013-09 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
Hmm, I'm not sure what's going on. I ran it again four times in a row and I got better results, but the timings show that there is a lot fo difference between the slow and fast cases (no idea why) $ time ./mach build binaries 0:00.81 /usr/bin/make -j8 -s binaries 0:03.90 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.90 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.95 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.02 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.13 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.32 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:06.42 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m13.277s user0m9.969s sys 0m2.929s ehsanakhgari sparky ~ moz mozilla-central include $ time ./mach build binaries 0:00.25 /usr/bin/make -j8 -s binaries 0:01.49 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.49 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.50 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.64 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.67 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.89 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.36 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m10.459s user0m11.120s sys 0m1.914s ehsanakhgari sparky ~ moz mozilla-central include $ time ./mach build binaries 0:00.26 /usr/bin/make -j8 -s binaries 0:01.53 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.54 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.54 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.67 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.80 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.93 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.37 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m9.334s user0m10.229s sys 0m1.924s ehsanakhgari sparky ~ moz mozilla-central include $ time ./mach build binaries 0:00.18 /usr/bin/make -j8 -s binaries 0:04.53 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.54 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.54 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.65 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.67 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.83 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:06.10 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m14.923s user0m9.508s sys 0m1.580s On 2013-10-02 12:20 PM, Gregory Szorc wrote: 8.8s here! ~1.5 is startup and checking the build backend is up to date (lots of stats) ~1.5s is processing install manifests. Rest is make processing. The fact that your machine spent ~20s doing install manifest processing tells me: a) Your directory tree wasn't cached (try running again) b) Your I/O layer is slow (I'm building with an SSD) c) Something else wonky creating slow I/O 0:00.14 /usr/bin/make -j8 binaries 0:00.53 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:00.82 make[1]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.16 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:01.45 make[2]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.56 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.56 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.57 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.68 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.72 From ./dist/bin: Kept 0 existing; Added/updated 0;
differentiate between plugin http requests and JS http requests
I am writing a xul application which records all the network communication happening inside a browser instance created using browser tag. I can use http-on-modify-request to track all the requests being made and modify headers accordingly but I can not differentiate which request is made by plugin like flash or its been made by JS. Is there a way I can differentiate such requests? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Poll: What do you need in MXR/DXR?
What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
This is looking awesome and I'm going to attempt to switch my mxr quick searches over to it. A couple of immediate things that you might want to think about: Right now I think mxr updates from mozilla-central faster than daily. I've used that on a number of occasions to figure out what has broken my build/patch. One of the neat things with mxr and multiple trees is that when viewing a file on say mozilla-central I can easily switch to the mozilla-aurora version to see how it looks there, this is really useful for figuring out how a bug affects different branchs. Bonus points might include a file diff between the trees. On Wed, Oct 2, 2013 at 12:33 PM, Erik Rose e...@mozilla.com wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ 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: Poll: What do you need in MXR/DXR?
- Easy access to hg annotate, as in mxr (could be better than mxr even, by integrating into the existing view instead of being a separate view). Assuming I understand you right, we've just added this last week. :-) See the Blame link at http://dxr.mozilla.org/mozilla-central/source/embedding/base/nsIDialogCreator.idl. RIght now, we're just delegating out to hgweb, but inlining is something we could do in the future. Great stuff! Keep it coming! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
DXR is looking awesome these days! I find the call graph information to be wrong some of the time, I have never been able to tell why. See this query for example: http://dxr.mozilla.org/mozilla-central/search?q=%2Bcallers%3A%22mozilla%3A%3AAudioNodeStream%3A%3ASetDoubleParameter%28uint32_t%2C+double%29%22. Do you have any idea what the source of these problems is, and if yes, is that on track to get fixed? Thanks! Ehsan On 2013-10-02 3:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ 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: Poll: What do you need in MXR/DXR?
I love DXR for mozilla-central, and would love it if the UX branch (https://mxr.mozilla.org/projects-central/source/ux/) was indexed there as well! Keep up the great work, -Mike On 02/10/2013 3:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ 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: Poll: What do you need in MXR/DXR?
I've been using DXR (at least when it has been working) since 2011. One thing I'd like to see should be simple to implement: typing a file name into the search bar should find that file rather than nothing. On 10/02/2013 12:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ 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: Poll: What do you need in MXR/DXR?
On 10/2/13 3:33 PM, Erik Rose wrote: What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) MXR things I use constantly that don't seem to have obvious dxr counterparts: * Search on the firefox tree to follow pre-hg blame. Features that are really handy at times (though the discoverability in mxr is terrible, so maybe dxr just has the same issue): * Linking to particular versions. * Marking particular lines. Things that drive me nuts about mxr when I've tried to use it: * When navigating down the directory/file tree, it keeps autofocusing the search field, which is super-annoying if you're using keyboard-only navigation (with quickfind and enter) to do the traversal. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On 02/10/13 21:33 , Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik Something that's been bothering me about MXR for many years: When I search for any file of which there is only one copy, like any of the interface definition files, or the singleton implementations thereof, it should just open the file. The extra click on the unique search result is just wasted time. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik Few things for me that I don't see an easy way to do on dxr.m.o right now at a glance. Search `file names` I might remember a file is called sut_lib for example, but unsure extension or where it is, but know I need to edit it! Search text strings within a specific filename wildcard, e.g. I might want a search for some method in any idl, but not care about the underlying implementation in C++ Further insight I can't easily provide unless http://mxr.mozilla.org/build and http://mxr.mozilla.org/comm-central/ is replicated at dxr, I can provide insight on what the req's are for both setups (since build/ is many repos, while comm-central is 2 large repos and a few small ones) - For me personally comm-central is less important for my testing since mozilla-central meets most of the needs in useability. ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On 13-10-02 2:09 PM, Gijs Kruitbosch wrote: On 02/10/13 21:33 , Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik Something that's been bothering me about MXR for many years: When I search for any file of which there is only one copy, like any of the interface definition files, or the singleton implementations thereof, it should just open the file. The extra click on the unique search result is just wasted time. For every use case, there is an equal and contradictory use case: I find DXR's jump to the only result behaviour frustrating. I have separate mxr and mxrf keywords for searching in files; if mxrf jumped to the unique result, I would be irritated (because I often just want to see what the full path to the file is, like `git ls-files | grep`). Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
Could we run with DEBUG on? We'd index strictly more code (I think) and sometimes I miss debug-only things. (One day I would love to get Windows-only stuff indexed, but I guess we have to wait for Clang to work on Windows for that). Nick On Thursday, October 3, 2013 8:33:40 AM UTC+13, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On Wed, Oct 2, 2013 at 1:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/2/13 3:33 PM, Erik Rose wrote: What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) Things that drive me nuts about mxr when I've tried to use it: * When navigating down the directory/file tree, it keeps autofocusing the search field, which is super-annoying if you're using keyboard-only navigation (with quickfind and enter) to do the traversal. Absolutely this! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
I would like better documentation about how to use dxr. I know it's pretty powerful, but it's always just easier for me to use mxr than to figure out the right query. One that would be really useful to me is to find all references to a field of a given class. If dxr's main search page had some examples of how to do searches like this one, that would be great. Someone once showed me a way to get it to pop up a little window with options like function: and type: (although I seem to have lost that dialog and I can't figure out how to get it back). However, there's no explanation of what these operators do and I can't get them to work. For example, if I search for function:JS_SetGCZeal I get no results. Why is that? -Bill - Original Message - From: Dave Townsend dtowns...@mozilla.com Cc: dev-platform@lists.mozilla.org Sent: Wednesday, October 2, 2013 2:47:19 PM Subject: Re: Poll: What do you need in MXR/DXR? On Wed, Oct 2, 2013 at 1:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/2/13 3:33 PM, Erik Rose wrote: What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
On Wed, Oct 02, 2013 at 11:42:45AM -0400, Ehsan Akhgari wrote: I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds. $ time ./mach build binaries 0:01.96 /usr/bin/make -j8 -s binaries 0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real 0m28.291s user 0m8.685s sys 0m4.178s Do you have any plans to bring down the overhead? Do you know where this overhead is coming from? Try again now that bug 921307 landed. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On Wed 02 Oct 2013 12:33:40 PM PDT, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Overall, I really like dxr. Especially the speed. But the incremental results, while cool, are done in a way that makes me feel like I'm not in control. I'm not sure when it's still thinking. It all feels a little too magic. But anyway, on to some specific items. Just one or two, ok?: * The search boxes don't work for setting up keyword searches. Er... wait, the main box actually just worked for that for the first time! It used to be missing the tree name, I guess? But it's still problematic to use any of the advanced search boxes. * Related bug: 1. Clear out all the advanced search choices 2. Enter Foo into the function-ref box 3. Right-click on the function box, add a keyword search (say it's 'dxr1') 4. Ctrl-L, enter dxr1 Bar Result: function-ref box gets filled with Foo?substring-search= Desired result: dxr1 is a valid keyword search for either function:Bar or function:Bar function-ref:Foo. I don't really care which. * Related bug 2: 1. Enter any random search at the main page to get to the results page. 2. Clear out all fields in the advanced search box 3. Add a keyword search for the function box Result: the keyword search remembers the original search, the one that you manually cleared out. * I find the Advanced Search box confusing. I'm not sure whether it's ORing or ANDing my results. (I mean, it's pretty easy to figure out if you search for known stuff.) At the very least, I would like a stronger visual indicator of which fields are being used (nonempty). The auto-updating main search bar definitely helps with this, but it's not enough for simpletons like me. Having a Clear All or Reset button would help too. * UI jumps around a lot while it's populating the incremental results. Moves the incremental functionality from cool to annoying. * The lag in the incremental results view when I switch searches feels bad. eg I have some set of results open, and I wipe out my search and replace it with a new one. For some amount of time, I see the old results, with no progress indicator telling me that they're out of date and it's refreshing. In general, it needs a better activity indicator, even when refining existing results. * Tooltips on the advanced search options! I totally have to guess what function vs function-ref means. Is function any occurrence, just declarations, just definitions, or ? Function *reference* makes me think of a C++ reference, too. I don't know what the warning search does, since its example returns no results. Do the advanced search criteria icons show up anywhere else in the UI? Right now, they seem like visual noise, but if they appeared alongside something else (results?), I might get to like them. * I don' t see a way to go from the results screen to the source code browsing, other than clicking on the icon to get back to the main screen and following the link there. Ok, maybe this is only a problem because I don't see any point in the main screen. It goes away quickly and it's not obvious how to get back to it, so why does it even exist? * I don't know what makes the Advanced Search box and Navigation boxes appear or disappear, nor how to get them back when they're not there. The thing seems to have a mind of its own -- I just switched back to it from writing this message, and it somehow had mozilla-central/AUTHORS selected. Is there some weird onBlur behavior? Eh, maybe I clicked something without meaning to. Oh! The advanced search box appears when you press enter. But there's no visible reason to ever have to press enter, so it's easy to miss. * The regexp field not only requires the /slanted brackets/, but it ignores the 1st and last characters no matter what they are. (I entered fprintf, and it showed me matches for print.) * It's been said, but the source links should have a revision in them so they're stable. I don't know how to reconcile that with having them point to dxr, since presumably dxr indexes only one version. * Does dxr have access to other static information? Eg, can I see a list of
