Re: Known-good clang revision?
On Fri, Nov 8, 2013 at 7:05 PM, Gregory Szorc g...@mozilla.com wrote: FWIW, our LLVM/Clang SVN HEAD compatibility has been deteriorating in recent months. Since this is the case, I edited the wiki to suggest the latest release instead of suggesting a trunk checkout. The release works for me. (It wasn't available yet when I first switched to clang.) Thanks. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On September 12, a debug clobber build on my new Linux desktop took 12.7 minutes. Just then it took 7.5 minutes. Woo! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: We could report all rejections, but I'm a bit leery of adding so much noise that people start ignoring the report altogether; a common problem in the past. Given that we report throw 42 we should also report these I think. A promise is nothing but an asynchronous variant of a function. Where a function either returns or throws, a promise either resolves or rejects. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On Wed, Nov 20, 2013 at 12:51 PM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: We could report all rejections, but I'm a bit leery of adding so much noise that people start ignoring the report altogether; a common problem in the past. Given that we report throw 42 we should also report these I think. A promise is nothing but an asynchronous variant of a function. Where a function either returns or throws, a promise either resolves or rejects. How about logging them with console.info? That seems the right logging level to me, and it's easy to turn off if it gets in the way. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On 11/20/13 6:51 AM, Anne van Kesteren wrote: On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: We could report all rejections, but I'm a bit leery of adding so much noise that people start ignoring the report altogether; a common problem in the past. Given that we report throw 42 We don't, for a DOM promise, last I checked. We report |throw new Error()| and of course actual internal things that ends up throwing actual Error instances. Again, the intent was to catch things like typos in function names in the callbacks and whatnot. We could certainly try to report everything. It would be pretty bare-bones, since for things that are not Error we don't have line/file information as to where they originated, so all we can report is that some promise somewhere was rejected with the value and the rejection was not handled. How useful do you expect that to be? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On 11/20/13 7:34 AM, Boris Zbarsky wrote: We could certainly try to report everything. It would be pretty bare-bones, since for things that are not Error we don't have line/file information as to where they originated, so all we can report is that some promise somewhere was rejected with the value and the rejection was not handled. How useful do you expect that to be? I guess no less useful than the current error console reporting for throw 42 in a function which is already pretty useless. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
17.0.11 and 24.1.1 XULRunner?
Hi, On or around November 13 2013 Firefox of versions 25.0.1, 24.1.1 ESR and 17.0.1 ESR were rereleased, along with XULRunner 25.0.1, but not for ESR versions. My question is was any incompatibilities between Fx and XULRunner introduced with these releases, and if so, did those incompatibilities affect ESR versions? If the answer is Yes, I think it would be appropriate to rerelease XULRunner for ESR versions, like it was once done for Bug 757652https://bugzilla.mozilla.org/show_bug.cgi?id=757652. Can anyone check on this? Thank you, Yuriy Look | Software Developer | Compuware APM yuriy.l...@compuware.commailto:yuriy.l...@compuware.com ... Simply Smarter APM | Compuware.com/APMhttp://www.compuware.com/en_us/application-performance-management.html?utm_source=signatureutm_medium=email | Facebookhttp://www.facebook.com/CompuwareAPM | Twitterhttp://www.twitter.com/CompuwareAPM | APMbloghttp://apmblog.compuware.com/?utm_source=signatureutm_medium=email | Google+http://gplus.to/CompuwareAPM ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plug-in feature not available in the web platform. Alternatives?
On Sat, Nov 9, 2013 at 5:13 PM, Benjamin Smedberg benja...@smedbergs.uswrote: On 11/8/2013 4:33 AM, fma spew wrote: We have a npapi-npruntime plug-in that access the Windows certificate store via CAPI to provide the end-user with its personal certificates to perform different operations. What is the use case you're solving? Are you trying to install a personal/client certificate that the user can use again in the future? Or is this a server certificate that isn't signed using normal root servers? No, neither installing nor it is such a server certificate. I will try to elaborate more. Our customers' end-users have their end-user certificates stored in the Personal logical certificate store on Windows. The rest of needed certificates, (Intermediary and/or Trusted Root Certificates) are also stored on Windows certificate stores. Our plug-in allows the end-user to choose one of those Personal certificates and create digital signatures. Our plug-in uses CAPI to get to the Personal store. Then it opens a dialog that lists the end-user certificates. The end-user selects one of the certificates and a digital signature is created from the provided data-to-be-signed. So we do not make use of NSS. The reason is customer-driven: they use the certificates for other purposes as well and the Windows certificate store is a central storage point from where other Windows applications can access those certificates. Replicating on NSS db would only need complexity to the management tasks. According to our surveys, it is simply not viable. We have found a little pointer to some CAPI related work: https://groups.google.com/forum/#!searchin/mozilla.dev.platform/windows$20certificate$20store/mozilla.dev.platform/IafIvMyuzYg/vGaH9CE2fBEJ This seems unrelated. Firefox currently manages its own set of root certificates and does not use the builtin Windows certificate system. This gives us extra control over some things like EV certificate policy, and has the property that system administrators who want to add a new root certificate (in a managed environment) have more difficulty doing so. But it doesn't seem directly related to the feature you seem to need. You are right. That's unrelated. I copied the wrong link. This is the link: http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/. But we have not checked out that code and we are not sure about what the purpose of that code is or how to use it. 3- We haven't found any indication of Mozilla about alternatives for these kind of plug-ins, meaning plug-ins that need access to, in this case, Windows stuff. Google has provided alternatives though. Can you be more specific about the alternatives in Chrome? I was referring to NaCl. We have not tested yet using CAPI to get to Personal certificates from NaCl. So we do not know yet whether this case falls into the unsafe activities that NaCl prevents (see https://developers.google.com/native-client/overview#common-use-cases). We are planning out the implementation of WebCrypto, but it's not clear from your post whether that would meet your needs or not. From the name, it sounds interesting. Can you elaborate a little what WebCrypto is about? Based on the info I've provided about the use case, I hope we can see whether it would meet our needs. 4- So, as encouraged by Benjamin Smedberg in the mentioned plugin-activation-in-firefox blog post, we post here our quesiton: Can you provide some guidance and/or advice? We feel ourselves stuck. Customers are asking for the new release and we have difficult to decide how to proceed. In the worst case, we will need to drop support for Firefox and encourage our customers to use a different browser. Can you be more specific about why this would be necessary? Plugins continue to work in Firefox as long as the user chooses to activate them, and unlike chrome we currently do not have any plans to remove NPAPI support from our desktop products. We might have wrongly interpreted Mozilla's position and plan regarding the support of NPAPI. Our perception was that even Mozilla was thinking about phasing out NPAPI in the near future (end of 2014) and that no alternative technology was present. If that's not the case, it is a welcome information. We face now a review of the plug-in roadmap and felt ourselves unsure due to the decision for Chrome and the uncertainty about how that could affect inside Mozilla. The whole thing is quite difficult to manage. Now when we had decided to ship a version of the plug-in for Chrome, they drop NPAPI support. We already have an ActiveX version. So now, it seems like we will need to support 3 different plug-in technologies for a single functionality (cert. choosing + signing) that it is served via a browser. And waiting to see how it will be for Safari... Obviously we want to give people a full webAPI solution for valid use cases, so that websites will work on platforms where plugins are not
Re: [Mozilla Enterprise] 17.0.11 and 24.1.1 XULRunner?
On 11/20/2013 8:02 AM, Look, Yuriy wrote: Hi, On or around November 13 2013 Firefox of versions 25.0.1, 24.1.1 ESR and 17.0.1 ESR were rereleased, along with XULRunner 25.0.1, but not for ESR versions. My question is was any incompatibilities between Fx and XULRunner introduced with these releases, and if so, did those incompatibilities affect ESR versions? Currently we only do XULRunner builds to produce the SDK. Since the ESR releases do not change interfaces, we don't need to rebuild the SDK for each ESR release, and so we do not produce XULRunner builds for these releases. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On Wed, Nov 20, 2013 at 12:36 PM, Boris Zbarsky bzbar...@mit.edu wrote: I guess no less useful than the current error console reporting for throw 42 in a function which is already pretty useless. When I said we report throw 42 I meant in a function context. Hence the analogy I made. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plug-in feature not available in the web platform. Alternatives?
On 11/20/2013 3:10 AM, fma spew wrote: Our customers' end-users have their end-user certificates stored in the Personal logical certificate store on Windows. The rest of needed certificates, (Intermediary and/or Trusted Root Certificates) are also stored on Windows certificate stores. Our plug-in allows the end-user to choose one of those Personal certificates and create digital signatures. ok, there are several different actions here: * get access to a personal signing certificate * sign a document with it I'm pretty sure that WebCrypto will have a way so sign a document with a certificate. It's not clear to me whether WebCrypto as currently specced also has a way to prompt the user to access personal certificates. bsmith/ekr, do you know what the capabilities are? It seems like a clear win to me for our cryptosystem to be able to access certificates in CAPI, whether or not we honor the system root certificates by default or not. This could also be used with the existing system of HTTPS client certificates, which is seldom used on the web currently primarily because the UI sucks. 3- We haven't found any indication of Mozilla about alternatives for these kind of plug-ins, meaning plug-ins that need access to, in this case, Windows stuff. Google has provided alternatives though. Can you be more specific about the alternatives in Chrome? I was referring to NaCl. We have not tested yet using CAPI to get to Personal certificates from NaCl. So we do not know yet whether this case falls into the unsafe activities that NaCl prevents (see https://developers.google.com/native-client/overview#common-use-cases). From what I know of NaCl, you won't be able to get outside the sandbox and access any system libraries, so unless Chrome makes client certificates available to you via API, it won't help this use case. We might have wrongly interpreted Mozilla's position and plan regarding the support of NPAPI. Our perception was that even Mozilla was thinking about phasing out NPAPI in the near future (end of 2014) and that no alternative technology was present. This is simply not true, it is FUD spread by Chrome developers who ought to know better. We believe NPAPI plugins are a legacy technology, and we want to build the web platform so that plugins aren't necessary. We also have security and stability issues with common plugins, and so we have designed the opt-in click to activate mechanism so that users are aware of the third-party code running in their browser. But for desktop Firefox, NPAPI is likely to be around for the predictable future (three years?). --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On 11/20/13 1:09 PM, Till Schneidereit wrote: How about logging them with console.info? That seems the right logging level to me, and it's easy to turn off if it gets in the way. Well, the problem is that of logging uncaught rejections. You can log them only if you catch them. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to reduce the time m-i is closed?
Nicholas Nethercote schrieb: It also assumes that we can backout stuff to fix the problem; we tried that to some extent with the first OOM closure -- it is the standard response to test failure, of course -- but it didn't work. Yes, in the case of those OOM issues that caused this closure, they are probably just a symptom of a larger problem. We've been having a step-by-step rise of OOM issues over quite some time now, most intensely seen as an increase of crashes with empty dumps. I alerted to that in bug 837835 but we couldn't track down a decent regression range (we mostly know in which 6-week cycle we had regressions, we can do some assumptions to narrow things a bit further down on trunk, but not nearly well enough to get to candidate checkins). Because of that, this has been lingering without any real tries to fix things, and from what I saw in data, things did even get worse recently - and that's talking of the release channel, so whatever might have increased troubles on trunk around this closure is even on top of that. As in a lot of cases we're seeing, there's apparently too little memory available for Windows to even create a minidump, we have pretty little info about those issues - but we do have our additional annotations we send along with the crash report, and those gives us some info that AFAIK gives us the assumption that in many cases we're running out of virtual memory space but not necessarily of physical memory. As I'm told, that can for example happen with VM fragmentation as well as bugs causing a mapping of the same physical page over and over into virtual memory. We're not sure if that's all on our code or if system code or (graphics?) driver code exposes issues to us there. From what I know, bsmedberg and dmajor are looking into those issues more closely, both now that we had the tree closure problem and also because it has been a lingering stability issue for months. I'm sure any help in those efforts is appreciated as those are tough issues, and it might be multiple problems that all contribute a share to the overall issue. Making us more efficient on memory sounds like a worthwhile goal overall anyhow (even though the bullet of running out of VM space can be dodged by switching to Win64 and/or e10s giving us multiple processes that all have their 32bit virtual memory space, but not sure if those should or will be our primary solutions). I think in other cases, where a clear cause to the tree-closing issues is easy to assess, a backout-based process can work better, but with those OOM issues there's not a clear patch or patch set to point to. IMHO, we should work on the overall issue cluster of OOM, though. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
On Wed, Nov 20, 2013 at 4:04 PM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 11/20/13 1:09 PM, Till Schneidereit wrote: How about logging them with console.info? That seems the right logging level to me, and it's easy to turn off if it gets in the way. Well, the problem is that of logging uncaught rejections. You can log them only if you catch them. What I meant was to let the browser do the logging, just as for `throw new Error()`, but do so with the same logging level as console.info uses. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Mozilla Enterprise] 17.0.11 and 24.1.1 XULRunner?
On 11/20/2013 11:16 AM, Wilkins, Brian wrote: That's odd because on RHEL, Xulrunner 17 ESR is in the RHEL Repo. Is this just a RHEL versioning mismatch with the official versions? I don't understand the question. Some Linux distros build Firefox on top of their XULRunner package, and so they update XR for each dot release. mozilla.org XULRunner builds are not release products and as such don't get binaries produced for ESR builds. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
I was skeptical of this work - so I need to say now that it is paying dividends bigger and faster than I thought it could. very nice! On Wed, Nov 20, 2013 at 3:38 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On September 12, a debug clobber build on my new Linux desktop took 12.7 minutes. Just then it took 7.5 minutes. Woo! Nick ___ 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: Central location for tracking known broken build configurations (with bugs)
I would favour a whiteboard tag or keyword on the bug tracking the build failure. It should be easy enough to create a query for all open bugs with this tag. Usually you want to get to the bug anyway for the latest workaround and/or info on what to back out locally. Cheers, kats On 13-11-19 18:17 , Tim Abraldes wrote: Somebody stop me if this already exists... I'm envisioning a central location, probably a wiki page at https://wiki.mozilla.org/BrokenBuilds or similar, where people can find the answers to these questions: 1. Given my current build configuration, why did my last build fail? 2. What bugs can I follow to see when this build configuration will work again? 3. What workarounds/patches can I employ to quickly get a working build? So the page would be a simple table with the following columns: Bug #, affected configurations, known workarounds e.g. Bug Affected configurationsKnown workarounds 899948 VS (all) with --disable-optimize but not --enable-debug --without-intl-api 933476 VS (all) --disable-webgl 940220 VS2012+ --without-intl-api The benefits should be obvious; no more IRC logs like the following 10:40:25 AM - developer1: is there a new build error using obscure-cc other than the one developer0 fixed yesterday? 10:41:15 AM - developer2: developer1: yes, bug 99 10:42:07 AM - developer3 has joined the room. 10:42:10 AM - developer3: my builds are failing, but it seems to be a new issue. Anyone else seeing this? Also, no more face-desking if you encounter a known issue while IRC is in a lull. If anyone has reasons *NOT* to create this wiki page, or suggestions for a better name or location for this information, please let me know! I'll create the page tomorrow if I don't hear from anyone... or maybe today if feedback is overwhelmingly positive (or positively overwhelming) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
Just a heads-up for other LLDB users... The last few days I've been driven nuts by Xcode failing to stop at some breakpoints (it just lists them as pending). I've now tracked this down to the use of UNIFIED_SOURCES. The issue is explained here: http://lldb.llvm.org/troubleshooting.html Unfortunately, setting target.inline-breakpoint-strategy to always doesn't actually seem to work with the LLDB that comes with Xcode 5.0.1, and my experience of LLDB builds that I've created myself has been that they're pretty unstable. I'm not sure how best to handle this just yet, but given this... On 19/11/2013 03:04, L. David Baron wrote: On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote: On 2013-11-17 7:50 PM, L. David Baron wrote: Could we do a static analysis to look for things whose semantics are changed by this unification, such as statics with the same name between files that are/might be unified? (And could we make the tree turn red if it failed?) That analysis is quite hard to perform if we try to catch all kinds of such leakage. I think a periodic non-unified build is a much better way of discovering such problems. I'm inclined to think it'll need to be more than periodic, actually. I expect that otherwise we'd get pretty frequent bustage with people forgetting to add #includes, and that bustage would then show up when we add or remove files, which would make it a huge pain to add or remove files. But I'm actually also worried (perhaps *more* worried) about cases where there are semantic differences but things will still compile, such as two static variables of the same name and type, in different files (e.g., static bool gInitialized). We could end up with breakage both because of code that expects such variables to be distinct, or from new code that expects such variables to be merged. I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything... Jonathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 2013-11-20 12:37 PM, Benoit Jacob wrote: Talking about ideas for further extending the impact of UNIFIED_SOURCES, it seems that the biggest limitation at the moment is that sources can't be unified between different moz.build's. Because of that, source directories that consist of many small sub-directories do not benefit much from UNIFIED_SOURCES at the moment. I would love to have the ability to declare in a moz.build that UNIFIED_SOURCES from here downwards, including subdirectories, are to be unified with each other. Does that sound reasonable? I don't think that we should do this for now. One problem with unified builds is that adding or removing files can shift things into different translation units and cause build failures. Because of this reason, I don't like the idea of unifying multiple cpp files in multiple directories into the same translation unit. But further down the road, opting into this by moving things into one moz.build file may make sense. I have experimented with this once in bug 936899. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 2013-11-20 12:09 PM, Chris Peterson wrote: It might be useful to add a files_per_unified_file parameter to mozconfig or mach build. People could benchmark different values of files_per_unified_file (trading off clobber vs incremental build times). The same parameter could also be used to disable unified builds with files_per_unified_file = 1. I agree! See bug 941097. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On Nov 20, 2013, at 9:37, Benoit Jacob jacob.benoi...@gmail.com wrote: Talking about ideas for further extending the impact of UNIFIED_SOURCES, it seems that the biggest limitation at the moment is that sources can't be unified between different moz.build's. Because of that, source directories that consist of many small sub-directories do not benefit much from UNIFIED_SOURCES at the moment. I would love to have the ability to declare in a moz.build that UNIFIED_SOURCES from here downwards, including subdirectories, are to be unified with each other. Does that sound reasonable? You can do this today by having a parent moz.build list sources in child directories. Keep in mind some moz.build/Makefile.in still customize directories on a directory-by-directory basis. I would love to see a project that consolidated data into fewer moz.build files. The recent work around how libraries are defined should have made that easier. But there are still things you can only do once per directory. Those limitations will disappear eventually. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt jw...@jwatt.org wrote: I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything... Given that new versions of XCode don't even ship with gdb anymore, I think we need to treat lldb as a supported tool, and figure something out here. I don't think it makes sense to have every developer on a new mac platform reverting all the UNIFIED_SOURCES stuff. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
Ok. What should we do in the mean time? Does anyone know if it's possible to get gdb going with XCode 5 on Mavericks? On Wed, Nov 20, 2013 at 10:30 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley bobbyhol...@gmail.comwrote: On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt jw...@jwatt.org wrote: I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything... Given that new versions of XCode don't even ship with gdb anymore, I think we need to treat lldb as a supported tool, and figure something out here. I don't think it makes sense to have every developer on a new mac platform reverting all the UNIFIED_SOURCES stuff. I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Given the fact that they can handle setting breakpoints in header files, they should be able to fix this in the general case. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On 20/11/2013 18:30, Ehsan Akhgari wrote: On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt jw...@jwatt.org wrote: I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything... Given that new versions of XCode don't even ship with gdb anymore, I think we need to treat lldb as a supported tool, and figure something out here. I don't think it makes sense to have every developer on a new mac platform reverting all the UNIFIED_SOURCES stuff. I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Given the fact that they can handle setting breakpoints in header files, they should be able to fix this in the general case. I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a heads-up though. Jonathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On 2013-11-20 1:33 PM, Jonathan Watt wrote: On 20/11/2013 18:30, Ehsan Akhgari wrote: On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt jw...@jwatt.org wrote: I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything... Given that new versions of XCode don't even ship with gdb anymore, I think we need to treat lldb as a supported tool, and figure something out here. I don't think it makes sense to have every developer on a new mac platform reverting all the UNIFIED_SOURCES stuff. I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Given the fact that they can handle setting breakpoints in header files, they should be able to fix this in the general case. I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a heads-up though. Thanks! Please keep us in the loop. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On 2013-11-20 1:34 PM, Bobby Holley wrote: Ok. What should we do in the mean time? Does anyone know if it's possible to get gdb going with XCode 5 on Mavericks? This should help in the mean time: https://bugzilla.mozilla.org/show_bug.cgi?id=939583#c3 On Wed, Nov 20, 2013 at 10:30 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley bobbyhol...@gmail.com mailto:bobbyhol...@gmail.com wrote: On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt jw...@jwatt.org mailto:jw...@jwatt.org wrote: I may end up being the guinea pig that is perpetually having his builds broken because he has to have a patch applied to revert all UNIFIED_SOURCES lines back to SOURCES lines in order to debug anything... Given that new versions of XCode don't even ship with gdb anymore, I think we need to treat lldb as a supported tool, and figure something out here. I don't think it makes sense to have every developer on a new mac platform reverting all the UNIFIED_SOURCES stuff. I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Given the fact that they can handle setting breakpoints in header files, they should be able to fix this in the general case. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Central location for tracking known broken build configurations (with bugs)
On 11/19/13, 11:06 PM, Tim Abraldes wrote: Possible compromise: have this info live in the tree as part of the in-tree docs under build/docs. You need build peer review to update those docs and they are versioned with the tree. That addresses my accuracy and versioning concerns. This sounds reasonable to me! The docs would always be up to date with the code being built, anyone experiencing an issue can look it up in a known location, anyone with knowledge about a particular issue can update the doc, and build peers don't have to spend their time keeping config rules constantly up to date! Assuming people are on board with this plan, how would we go about starting that doc? b76171a0d6ec and newer (currently inbound only) have a build/docs/supported-configurations.rst file documenting supported build configurations. I just filled it in with basics. Feel free to make obvious updates with NO BUG DONTBUILD (NPOTB) and no build peer review. Please at least get a pastebin/irc review from a build peer for anything too involved. If people have time to write patches to configure to enforce missing requirements, we'll happily review them. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
While this analysis is interesting, it doesn't measure the impact of the
unified builds project directly, so I decided that now that a good chunk
of code is being compiled in unified mode we should get some specific
numbers on the improvements.
What I did was I took inbound as of ab70db6b27c8, and did a clobber
build twice. The first time I manually converted all UNIFIED_SOURCES
variables to SOURCES using [1], and the second time I reverted that
change to build a pristine inbound. Both builds were done with a warm
cache of all of the source tree (I manually put everything into the
cache before each build.)
And here are the results:
Before:
22:12.74 Overall system resources - Wall time: 1332s; CPU: 92%; Read
bytes: 50761728; Write bytes: 7229292544; Read time: 39540; Write time:
5736192
real22m13.648s
user69m52.462s
sys5m57.270s
After:
16:07.89 Overall system resources - Wall time: 967s; CPU: 89%; Read
bytes: 10317824; Write bytes: 6860136448; Read time: 12604; Write time:
4981152
real16m8.469s
user47m39.219s
sys4m1.699s
This means that unified builds so far have made our builds around 27%
faster in terms of wall clock, and around 32% faster in terms of CPU time.
These measurements were done on Linux on a 4-core machine.
Last but not least, thanks to everybody who is helping with this project!
Cheers,
Ehsan
[1] $ find . -name moz.build | xargs grep -w UNIFIED_SOURCES | awk -F:
'{print $1}' | sort | uniq | xargs sed -i 's/UNIFIED_SOURCES/SOURCES/'
On 2013-11-19 2:15 AM, Gregory Szorc wrote:
Do builds feel like they've gotten faster in the last few weeks^hours?
It's because they have.
When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
build times on my 2013 2.6 GHz MacBook Pro were as follows:
Wall 11:13 (673)
User 69:55 (4195)
Sys6:04 (364)
Total 75:59 (4559)
I just built the tip of m-c (e4b59fdbc9c2) and times on that same
machine are now:
Wall 9:23 (563)
User 57:38 (3458)
Sys4:58 (298)
Total 62:36 (3756)
That's a 17.6% drop in CPU time required to build the tree! If the build
system were able to deliver 100% CPU utilization, my machine would be
able to build the tree in ~7:50 wall time. Not too shabby!
I can say with high confidence that unified sources are mostly
responsible for the CPU efficiency gains. When I built m-c earlier today
just after Australis landed, total CPU time was at 66:28. In between, 5
unified sources bugs landed and ~4 minutes total CPU time was shaved off.
Project unified sources: making builds insanely faster since yesterday.
I can't wait to see what tomorrow brings.
[1]
http://gregoryszorc.com/blog/2013/11/05/macbook-pro-firefox-build-times-comparison/
___
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: Central location for tracking known broken build configurations (with bugs)
Somebody stop me if this already exists... I'm envisioning a central location, probably a wiki page at https://wiki.mozilla.org/BrokenBuilds or similar, where people can find the answers to these questions: 1. Given my current build configuration, why did my last build fail? 2. What bugs can I follow to see when this build configuration will work again? 3. What workarounds/patches can I employ to quickly get a working build? Sometimes the topic field in #developers contains a link to an etherpad describing common kinds of breakage. Not at the moment, though. That's handy! If we go with the approach suggested by gps, we could move the info from the etherpad (does anyone have a link to this etherpad?) into the doc as a starting point. In the future we could have the topic of #developers explain how to find the doc. The etherpad was at https://etherpad.mozilla.org/commonissues. Since it's been out of the topic since last March, though, I don't think anything there is particularly common still. Thanks for the link! When we have a defined plan I'll update the the etherpad to point to a central doc, a bugzilla query, or whatever else we decide on. That seems to be the only follow-up necessary here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Central location for tracking known broken build configurations (with bugs)
I would favour a whiteboard tag or keyword on the bug tracking the build failure. It should be easy enough to create a query for all open bugs with this tag. Usually you want to get to the bug anyway for the latest workaround and/or info on what to back out locally. I'm not opposed to a whiteboard tag or maybe a set of whiteboard tags (so we can indicate what configurations are affected). We could even make a wiki page that uses the bugzilla plugin to show the query! This would still suffer from the the latest information doesn't match my current tree+config combination issue that gps raised; e.g. people building Aurora or Beta wouldn't find the query super useful. We could do the whiteboard tag(s) in addition to a source-controlled document, and somewhere in the document add something like don't see your issue here? Try this - bugzilla query or wiki link or here Thoughts? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Central location for tracking known broken build configurations (with bugs)
On 11/20/13, 1:15 PM, Tim Abraldes wrote: I would favour a whiteboard tag or keyword on the bug tracking the build failure. It should be easy enough to create a query for all open bugs with this tag. Usually you want to get to the bug anyway for the latest workaround and/or info on what to back out locally. I'm not opposed to a whiteboard tag or maybe a set of whiteboard tags (so we can indicate what configurations are affected). We could even make a wiki page that uses the bugzilla plugin to show the query! This would still suffer from the the latest information doesn't match my current tree+config combination issue that gps raised; e.g. people building Aurora or Beta wouldn't find the query super useful. We could do the whiteboard tag(s) in addition to a source-controlled document, and somewhere in the document add something like don't see your issue here? Try this - bugzilla query or wiki link or here I'm all for this. We could generally do better organizing the build config bugs. It's currently a mess of 1162 open bugs without much organization. We could definitely use a good triage. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Central location for tracking known broken build configurations (with bugs)
Possible compromise: have this info live in the tree as part of the in-tree docs under build/docs. You need build peer review to update those docs and they are versioned with the tree. That addresses my accuracy and versioning concerns. This sounds reasonable to me! The docs would always be up to date with the code being built, anyone experiencing an issue can look it up in a known location, anyone with knowledge about a particular issue can update the doc, and build peers don't have to spend their time keeping config rules constantly up to date! Assuming people are on board with this plan, how would we go about starting that doc? b76171a0d6ec and newer (currently inbound only) have a build/docs/supported-configurations.rst file documenting supported build configurations. I just filled it in with basics. Feel free to make obvious updates with NO BUG DONTBUILD (NPOTB) and no build peer review. Please at least get a pastebin/irc review from a build peer for anything too involved. If people have time to write patches to configure to enforce missing requirements, we'll happily review them. The doc looks great! To further solve the issue of my build broke and I'm not sure what config-option caused it or how to fix my build, we could add a section like the following to the doc: Known Issues This section documents known issues that cause builds to fail. Bug ID: 808932 Affected configs: Building B2G with --disable-optimize and --disable-jemalloc Workarounds: Bug ID: 899948 Affected configs: Building FX on VS(any) with --disable-optimize but not --enable-debug Workarounds: --without-intl-api Don't see your issue here? Try here - bugzilla query or wiki link or here I'm not in love with the format - it seems like the list will not be very readable if there are 20+ or so items in it - maybe we could split the list up by platform or something? I'm also happy to just use this as a starting point and modify the format if/when it becomes an issue. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
I just did a unified and non-unified build on my windows desktop -- non SSD. VS2012, using mozmake. Full clobber. (mozmake -s -j8) Unified: 20 min Non-Unified: 36 min This is huge! I was curious about the cost for incremental builds... touch gfx/2d/Factory.cpp (part of a unified file), rebuild using binaries target: Unified: 53s Non-Unified: 58s touch gfx/thebes/gfxPlatform.cpp (note: this dir/file is not unified), rebuild using binaries target: Unified: 56s Non-Unified: 56s (I need to rerun this on my computer with a SSD; I had a single-file binaries rebuild down to 10s there) ... and was very surprised to see no real difference, often non-unified taking slightly longer. So. Big win, thanks guys! - Vlad ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree: #ifdef MyFunction // screw you, windows.h/X.h/etc. #undef MyFunction #endif A small note about this pattern: the #ifdef wrapper is unnecessary, i.e. it is safe to write only // screw you, X.h #undef MyFunction because #undef is specified to be a silent NOP when applied to an identifier with no macro definition. I am uneasy with the entire UNIFIED_SOURCES concept; I worry that it will lead to symbol-visibility problems down the road, when A.cpp defines things that aren't meant to be accessible elsewhere, B.cpp (which comes after it in the relevant unification block) starts using them, and nobody notices until decoupling them has become a major refactoring job. But I'm not so uneasy that I'm going to get in the way of faster builds. :-) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 11/20/13, 2:02 PM, Zack Weinberg wrote: On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree: #ifdef MyFunction // screw you, windows.h/X.h/etc. #undef MyFunction #endif A small note about this pattern: the #ifdef wrapper is unnecessary, i.e. it is safe to write only // screw you, X.h #undef MyFunction because #undef is specified to be a silent NOP when applied to an identifier with no macro definition. I am uneasy with the entire UNIFIED_SOURCES concept; I worry that it will lead to symbol-visibility problems down the road, when A.cpp defines things that aren't meant to be accessible elsewhere, B.cpp (which comes after it in the relevant unification block) starts using them, and nobody notices until decoupling them has become a major refactoring job. But I'm not so uneasy that I'm going to get in the way of faster builds. Unified sources have probably saved sufficient CPU cycles across all of automation to more than offset having a non-unified build-only job. I'll defer to the Platform Team (Ehsan?) to request that from Release Engineering. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg za...@panix.com wrote: On 2013-11-20 12:37 PM, Benoit Jacob wrote: Talking about ideas for further extending the impact of UNIFIED_SOURCES, it seems that the biggest limitation at the moment is that sources can't be unified between different moz.build's. Because of that, source directories that consist of many small sub-directories do not benefit much from UNIFIED_SOURCES at the moment. I would love to have the ability to declare in a moz.build that UNIFIED_SOURCES from here downwards, including subdirectories, are to be unified with each other. Does that sound reasonable? ... Maybe this should be treated as an excuse to reduce directory nesting? We don't need an excuse! layout/xul/base/src, and pretty much everything under content/, I'm looking at you. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 2013-11-20 5:17 PM, Gregory Szorc wrote: On 11/20/13, 2:02 PM, Zack Weinberg wrote: On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree: #ifdef MyFunction // screw you, windows.h/X.h/etc. #undef MyFunction #endif A small note about this pattern: the #ifdef wrapper is unnecessary, i.e. it is safe to write only // screw you, X.h #undef MyFunction because #undef is specified to be a silent NOP when applied to an identifier with no macro definition. I am uneasy with the entire UNIFIED_SOURCES concept; I worry that it will lead to symbol-visibility problems down the road, when A.cpp defines things that aren't meant to be accessible elsewhere, B.cpp (which comes after it in the relevant unification block) starts using them, and nobody notices until decoupling them has become a major refactoring job. But I'm not so uneasy that I'm going to get in the way of faster builds. Unified sources have probably saved sufficient CPU cycles across all of automation to more than offset having a non-unified build-only job. I'll defer to the Platform Team (Ehsan?) to request that from Release Engineering. I'll try to find somebody else to own this. I am the wrong person for that task myself. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 2013-11-20 5:27 PM, Robert O'Callahan wrote: On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg za...@panix.com wrote: On 2013-11-20 12:37 PM, Benoit Jacob wrote: Talking about ideas for further extending the impact of UNIFIED_SOURCES, it seems that the biggest limitation at the moment is that sources can't be unified between different moz.build's. Because of that, source directories that consist of many small sub-directories do not benefit much from UNIFIED_SOURCES at the moment. I would love to have the ability to declare in a moz.build that UNIFIED_SOURCES from here downwards, including subdirectories, are to be unified with each other. Does that sound reasonable? ... Maybe this should be treated as an excuse to reduce directory nesting? We don't need an excuse! layout/xul/base/src, and pretty much everything under content/, I'm looking at you. How do you propose that we know which directory contains the source then? /sarcasm Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
2013/11/20 Ehsan Akhgari ehsan.akhg...@gmail.com On 2013-11-20 5:27 PM, Robert O'Callahan wrote: On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg za...@panix.com wrote: On 2013-11-20 12:37 PM, Benoit Jacob wrote: Talking about ideas for further extending the impact of UNIFIED_SOURCES, it seems that the biggest limitation at the moment is that sources can't be unified between different moz.build's. Because of that, source directories that consist of many small sub-directories do not benefit much from UNIFIED_SOURCES at the moment. I would love to have the ability to declare in a moz.build that UNIFIED_SOURCES from here downwards, including subdirectories, are to be unified with each other. Does that sound reasonable? ... Maybe this should be treated as an excuse to reduce directory nesting? We don't need an excuse! layout/xul/base/src, and pretty much everything under content/, I'm looking at you. How do you propose that we know which directory contains the source then? And I always thought that all public: methods had to go in the public/ directory! Benoit /sarcasm Ehsan ___ 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: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On 20/11/2013 18:48, Ehsan Akhgari wrote: On 2013-11-20 1:33 PM, Jonathan Watt wrote: I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a heads-up though. Thanks! Please keep us in the loop. Right now I'm seeing some weird behavior, but it seems target.inline-breakpoint-strategy can basically be made to work. When I first added the line to set target.inline-breakpoint-strategy in my ~/.lldbinit as per: http://lldb.llvm.org/troubleshooting.html it didn't work, even after restarting Xcode and starting a new debugging session. Touching the file I had the breakpoint in, rebuilding and restarting Xcode didn't help either. Some time later I pulled and rebuilt and suddenly breakpoints were working again. Since then I've run a few experiments trying to figure out what was needed to get the target.inline-breakpoint-strategy setting to work, but without any luck. For now I'm giving up, and suggest that anyone else that finds setting target.inline-breakpoint-strategy doesn't immediately work shuts Xcode and does a clobber build before reopening it...or something. I'll update the OS X Debugging wiki page. Since it seems setting target.inline-breakpoint-strategy can basically be made to work I don't plan on contacting the LLDB guys right now. Jonathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On Thursday, November 21, 2013 9:37:05 AM UTC+10, Jonathan Watt wrote: When I first added the line to set target.inline-breakpoint-strategy in my ~/.lldbinit as per: http://lldb.llvm.org/troubleshooting.html it didn't work, even after restarting Xcode and starting a new debugging session. I followed your advice. Quit Xcode, created .lldbinit, ./mach clobber ./mach build and my missing breakpoints are back. Thank you. cheers Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)
On 2013-11-20 6:37 PM, Jonathan Watt wrote: On 20/11/2013 18:48, Ehsan Akhgari wrote: On 2013-11-20 1:33 PM, Jonathan Watt wrote: I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a heads-up though. Thanks! Please keep us in the loop. Right now I'm seeing some weird behavior, but it seems target.inline-breakpoint-strategy can basically be made to work. When I first added the line to set target.inline-breakpoint-strategy in my ~/.lldbinit as per: http://lldb.llvm.org/troubleshooting.html it didn't work, even after restarting Xcode and starting a new debugging session. Touching the file I had the breakpoint in, rebuilding and restarting Xcode didn't help either. Some time later I pulled and rebuilt and suddenly breakpoints were working again. Since then I've run a few experiments trying to figure out what was needed to get the target.inline-breakpoint-strategy setting to work, but without any luck. For now I'm giving up, and suggest that anyone else that finds setting target.inline-breakpoint-strategy doesn't immediately work shuts Xcode and does a clobber build before reopening it...or something. I'll update the OS X Debugging wiki page. Since it seems setting target.inline-breakpoint-strategy can basically be made to work I don't plan on contacting the LLDB guys right now. Can we add our own lldbinit to the tree the same way that we have a gdbinit so that not everybody needs to go through this pain individually? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Can we teach the updater to download and install multiple partial updates?
It's very annoying to have to download a full update of Nightly (~40MB) if you miss one. It'd be a better experience to download two or more partial updates (usually 10MB) and have the updater install them sequentially. [NB. I'm not suggesting doing anything else in the build, unlike in bug 575317 https://bugzilla.mozilla.org/show_bug.cgi?id=575317 which created one partial update for a update of two or more versions.] Has this been discussed before? If so, what was the outcome? Are there bugs filed? I didn't find any but I don't really know what to search for. GL ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to reduce the time m-i is closed?
On 21/11/2013 00:20, Robert Kaiser wrote: As in a lot of cases we're seeing, there's apparently too little memory available for Windows to even create a minidump, we have pretty little info about those issues - but we do have our additional annotations we send along with the crash report, and those gives us some info that AFAIK gives us the assumption that in many cases we're running out of virtual memory space but not necessarily of physical memory. As I'm told, that can for example happen with VM fragmentation as well as bugs causing a mapping of the same physical page over and over into virtual memory. We're not sure if that's all on our code or if system code or (graphics?) driver code exposes issues to us there. I thought that there was a plan to pre-allocate on startup some memory for the minidump/crash reporter? KaiRo 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: Intent to replace Promise.jsm and promise.js with DOM Promises
On 20/11/2013 01:30, Boris Zbarsky wrote: On 11/19/13 12:26 PM, Anne van Kesteren wrote: On Tue, Nov 19, 2013 at 5:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: It's been the case since late August, though the behavior is a bit different: only thrown Errors or rejections with an Error are logged, not arbitrary rejections. Why are we doing it only for Error objects? The intent was to catch cases of code throwing unexpected exceptions inside a promise callback (which promises catch and turn into a rejection) and report those. We could report all rejections, but I'm a bit leery of adding so much noise that people start ignoring the report altogether; a common problem in the past. Currently, I'm getting this in the Error Console a few seconds after startup: Thu Nov 21 2013 13:23:23 Error: A promise chain failed to handle a rejection. Date: Thu Nov 21 2013 13:23:13 GMT+0800 (Malay Peninsula Standard Time) Full Message: [object StopIteration] Full Stack: JS frame :: resource://gre/modules/osfile/osfile_async_front.jsm :: withIterator :: line 1032 JS frame :: resource://gre/modules/Promise.jsm :: TOP_LEVEL :: line 767 JS frame :: resource://gre/modules/Promise.jsm :: TOP_LEVEL :: line 531 native frame :: unknown filename :: TOP_LEVEL :: line 0 This is singularly unhelpful. Can we have better error stacks? 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: Intent to replace Promise.jsm and promise.js with DOM Promises
On 11/20/2013 9:27 PM, Philip Chee wrote: Currently, I'm getting this in the Error Console a few seconds after startup: Thu Nov 21 2013 13:23:23 Error: A promise chain failed to handle a rejection. Date: Thu Nov 21 2013 13:23:13 GMT+0800 (Malay Peninsula Standard Time) Full Message: [object StopIteration] Full Stack: JS frame :: resource://gre/modules/osfile/osfile_async_front.jsm :: withIterator :: line 1032 JS frame :: resource://gre/modules/Promise.jsm :: TOP_LEVEL :: line 767 JS frame :: resource://gre/modules/Promise.jsm :: TOP_LEVEL :: line 531 native frame :: unknown filename :: TOP_LEVEL :: line 0 This is singularly unhelpful. Can we have better error stacks? This is actually a *really* useful error stack for people who know about the library in question throwing the error, and bugs have been filed about fixing it [1] [2]. The problem is that this library is widely used, and this error shows up leading consumers of the library to think they're doing something wrong when they're not. The problem essentially boils down to overloading the error/reject channel of Promises to signify the end of iteration. It's a promise that's rejected not because of an actual error, but because there's nothing more to iterate over. It will be fixed, and the error reporting did a good job of making it obvious that this needed to be fixed. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=938704 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=936530 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 11/19/2013 10:08 PM, Gregory Szorc wrote: On 11/18/13, 11:15 PM, Gregory Szorc wrote: Do builds feel like they've gotten faster in the last few weeks^hours? It's because they have. When I did my MacBook Pro comparison [1] with a changeset from Oct 28, build times on my 2013 2.6 GHz MacBook Pro were as follows: Wall 11:13 (673) User 69:55 (4195) Sys6:04 (364) Total 75:59 (4559) I just built the tip of m-c (e4b59fdbc9c2) and times on that same machine are now: Wall 9:23 (563) User 57:38 (3458) Sys4:58 (298) Total 62:36 (3756) And 24 hours later, m-c (4f993fa378eb) is getting faster: Wall 8:47 (527) User 52:41 (3161) Sys4:38 (278) Total 57:19 (3439) And 24 hours later on inbound on Mountain View's November 20'th evening: Wall 8:33 (513) User 49:48 (2988) Sys4:21 (261) Total 54:09 (3249) Only 3:20 CPU time reduction today. Is it time to start any betting pools? Between ongoing unification work and planned build system work, I think 6:30 wall time is achievable by end of year. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we teach the updater to download and install multiple partial updates?
On Thu, Nov 21, 2013 at 4:17 AM, Geoff Lankow ge...@darktrojan.net wrote: Has this been discussed before? If so, what was the outcome? Are there bugs filed? I didn't find any but I don't really know what to search for. There's also https://bugzilla.mozilla.org/show_bug.cgi?id=353804, which I think would alleviate this a bunch. Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we teach the updater to download and install multiple partial updates?
While that might makes sense to implement for nightly, aurora, and possibly beta builds it doesn't makes sense to implement for release builds where the vast majority of users are and there are many higher priority bugs to work on that affect nightly, aurora, beta, and release. On 11/20/2013 7:17 PM, Geoff Lankow wrote: It's very annoying to have to download a full update of Nightly (~40MB) if you miss one. It'd be a better experience to download two or more partial updates (usually 10MB) and have the updater install them sequentially. [NB. I'm not suggesting doing anything else in the build, unlike in bug 575317 https://bugzilla.mozilla.org/show_bug.cgi?id=575317 which created one partial update for a update of two or more versions.] Note: this would require the AUS system which is managed by the same people that created the additional partial mar files to update the AUS system to track the additional partial mars. I personally prefer just creating mar files for x number of previous builds similar to bug 575317because it moves the complexity that would primarily benefit nightly, aurora, and possibly beta users to the server side which can be automated without adding complexity to the client side which could easily break release users. Has this been discussed before? Yes If so, what was the outcome? There have always been higher priority bugs to work on as previously noted. Are there bugs filed? There are on some of the aspects of this. Look under toolkit - application update. Robert I didn't find any but I don't really know what to search for. GL ___ 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
