Re: Introducing mozilla::Result for better error handling
On Thu, Jan 5, 2017, at 03:28 PM, Cameron McCormack wrote: > On Tue, Dec 20, 2016, at 09:46 PM, Jan de Mooij wrote: > > A few weeks ago we added mozilla::Result to MFBT [0][1]. I was > > asked > > to inform dev-platform about this, so here's a quick overview. > > mozilla::Result is based on Rust's Result type [2]. It contains > > either a success value of type V or an error value of type E. > > I want to write a function that either returns an object that has > already been AddRefed or an nsresult error. > Result, nsresult> doesn't seem to work. > Result, nsresult> would presumably work, but might > wastefully touch the object's refcount. Is there a better way? I think Result should change its constructors to support move-only things like already_AddRefed. Probably it can add a constructor which accepts T&& and Move it down the chain. I'm not sure what is the prefect way here, though. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing mozilla::Result for better error handling
On Tue, Dec 20, 2016, at 09:46 PM, Jan de Mooij wrote: > A few weeks ago we added mozilla::Result to MFBT [0][1]. I was > asked > to inform dev-platform about this, so here's a quick overview. > mozilla::Result is based on Rust's Result type [2]. It contains > either a success value of type V or an error value of type E. I want to write a function that either returns an object that has already been AddRefed or an nsresult error. Result, nsresult> doesn't seem to work. Result, nsresult> would presumably work, but might wastefully touch the object's refcount. Is there a better way? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: 'Add me to CC list (follow this bug)' checkbox in Bugzilla broken, use Follow button in modal UI
Sorry for the inconvenience this recent change caused. We have now pushed out a fix for bug 1328464 and you should no longer need to click the 'Follow' button to workaround this issue. dkl On Wed, Jan 4, 2017 at 9:28 AM, Sebastian Hengst wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=1328464 > The 'Add me to CC list (follow this bug)' checkbox in Bugzilla is broken, > use the Follow button in modal UI for CCing. > > Sebastian > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- David Lawrence d...@mozilla.com bugzilla.mozilla.org ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to vendor Servo in mozilla-central
On 04/01/17 00:35, Gregory Szorc wrote: > Over in bug 1322769, we're planning to vendor the contents of the Servo Git > repository into mozilla-central as part of Quantum efforts. > > The initial vendoring of the Servo repository is the first milestone of a > larger project that aims to "unify" workflows and automation across the two > projects, allowing both projects to have insights into the other's > automation and allowing development work spanning both projects to be > simpler. > > In this first milestone, we will vendor the history of the Servo Git > repository into mozilla-central. > > We only get one chance to vendor the history of Servo before it is forever > set in stone in the history of mozilla-central. So I'd prefer to get it > right so we don't have regrets about the approach 10 years from now. > Therefore, if you care about getting it right, your brain and eyeballs on > the proposal would be useful. > > The current plan is to rewrite Servo's history to: > > * Remove merge commits (only taking the p1 ancestry of the repo) > * Add something in commit message summary line to indicate commit comes > from Servo > * Add source repo and commit annotations to the commit message > * Reformat some GitHub-flavored markdown to something more sane for plain > text display > * Remove everything related to submodules > * Drop WPT files (there's ~135,000 of them!) > > We also tentatively plan to introduce the Servo history as a new root in > the mozilla-central repository so that bisect operations on Firefox/Gecko > don't land in the middle of thousands of Servo-only commits. (I concede > this is an ugly hack to work around limitations of the "bisect" command of > your preferred VCS.) > > Unless we prune more from history rewriting, this will add ~8,000 commits > to mozilla-central touching ~5,700 files. The on-wire clone size of the > repository will increase by ~36 MB. On-disk repo size will increase by ~50 > MB (not including inode overhead). > > Also, I anticipate the techniques and tools used to import Servo's history > and keep it "synchronized" have uses outside of Servo. Our current > mechanisms for keeping upstream/third party projects in sync with > mozilla-central are not well standardized. I'd really like the work to > support Servo to be used for other projects as well. This potentially > includes a future where certain directories in mozilla-central are > effectively developed on GitHub or are using other "non-standard" > workflows. If you think you may benefit from this future work, I'd > appreciate if you could look at the Servo vendoring effort and make sure > things like the annotations tracking the original source of the commit are > sufficient for uses outside of Servo. > > Again, it's bug 1322769 if you want to comment or follow along. > As I said before, this approach is, IMO, much too complicated; splitting the reusable parts of Servo into their own repositories, as we have done before, would be a much simpler solution. However, as it seems the decision has already been made quietly long ago, I don't see much point in continuing to fight it, as long as this frankenhistory does not affect the canonical Servo history in git. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
'Add me to CC list (follow this bug)' checkbox in Bugzilla broken, use Follow button in modal UI
https://bugzilla.mozilla.org/show_bug.cgi?id=1328464 The 'Add me to CC list (follow this bug)' checkbox in Bugzilla is broken, use the Follow button in modal UI for CCing. Sebastian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your use cases for the Touch Bar on the new MacBook Pro?
On Tuesday, January 3, 2017 at 8:38:05 PM UTC-6, Stephen A Pohl wrote: > I can see the advantage of addons exploring and iterating on this, but > making the first version of this API addon-accessible might > unnecessarily delay it. If there is enough interest in this, we might > want to start this effort in parallel and release it in a subsequent > version. > > On 1/3/17 4:31 PM, Ryan VanderMeulen wrote: > > Will this API be accessible to addons? Seems like this would be a good > > place for people to explore and iterate. > > > > On 1/3/2017 12:17 PM, Stephen A Pohl wrote: > >> We will develop[1] a solid 1.0 API around the top features to get the > >> ball rolling and will iterate on these going forward. > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform Crazy idea - we could make the touch bar only accessible through web extensions apis, no XPCOM interface or internal api would be provided. This way all development happens in a layer that is secure (webextensions will eventually run in their own process and get sandboxing) and new features can be installed and removed with little effort by our users. We have the ability to ship system addons so we can include default features with our install. This is more in line with our newer modular approach to features, and would give our users much more control.. while also helping to promote web extension development. The approach would also help cut down on code bloat and avoid technologies we are trying to move away from like XPCOM. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your use cases for the Touch Bar on the new MacBook Pro?
On 03/01/17 17:17, Stephen A Pohl wrote: > We are gathering ideas for possible use cases of the Touch Bar on the > new MacBookPro and would like to hear from you! What would improve your > workflow? What would help our users? When the developer tools are open, change the Touch Bar to give quick access to various Developer functions? I can imagine a web-developer feeling supercharged with one-touch console, or one-touch inspect, or one-touch JS toggle. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your use cases for the Touch Bar on the new MacBook Pro?
> > 1. Design a contextual experience. Make the Touch Bar relevant to the > current context on the main screen. > I wonder if focus can serve as a context too. What if DevTools is opened and has focused? The "main screen" would still be the content page of course, but if the user has focused, say, the debugger, then it might be really cool to have debugger buttons in the touch bar. A while ago, I had filed this bug to gather ideas for DevTools: https://bugzilla.mozilla.org/show_bug.cgi?id=1320043 - In the debugger, having step in/out/over, resume, pause buttons would be very useful. - In Responsive Design Mode, maybe something to resize the viewport. - In the animation inspector, a scrubber to move through animations. - In the inspector's DOM view, buttons to add, delete, edit, hide, highlight nodes. Patrick On Wed, Jan 4, 2017 at 4:01 AM, Robert Helmer wrote: > +1 on doing WebExt APIs in parallel - this can be done outside of > mozilla-central on non-release channels using WebExtension Experiments > (https://webextensions-experiments.readthedocs.io) > > Once the implementation in mozilla-central is settled down, the > experimental API can be merged. > > On Tue, Jan 3, 2017 at 6:38 PM, Stephen A Pohl wrote: > > I can see the advantage of addons exploring and iterating on this, but > > making the first version of this API addon-accessible might > > unnecessarily delay it. If there is enough interest in this, we might > > want to start this effort in parallel and release it in a subsequent > > version. > > > > On 1/3/17 4:31 PM, Ryan VanderMeulen wrote: > >> Will this API be accessible to addons? Seems like this would be a good > >> place for people to explore and iterate. > >> > >> On 1/3/2017 12:17 PM, Stephen A Pohl wrote: > >>> We will develop[1] a solid 1.0 API around the top features to get the > >>> ball rolling and will iterate on these going forward. > >> ___ > >> 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 > ___ > 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
