Re: Poll: What do you need in MXR/DXR?

On 10/02/2013 12:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? (Apologies for the late reply; didn't really check newsgroups during the summit - bad wifi and having too much to do. Didn't about the design session in SC for the same reason.) I look up XPCOM interfaces

Re: Audit your code if you use mozilla::WeakPtr

On 10/8/13 10:32 PM, Justin Dolske wrote: Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.) You mean mozilla::WeakpPun? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Audit your code if you use mozilla::WeakPtr

On 10/8/13 6:04 PM, Ehsan Akhgari wrote: This code pattern is another problem -- you need to keep object alive if you want to do this some other way. We have an idiom for this kind of thing in fact (grep for kungFuDeathGrip!) Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.) Ju

Re: Removal of native notification systems on desktop platforms

As for libnotify not being flexible enough for the w3c spec, it is base on a fd.o spec that could be updated to cover our needs. Native notifications will always work better.. - Original Message - From: "Marco" To: "Dave Townsend" Cc: "dev-platform" Sent: Tuesday, October 8, 2013 6:14

Re: Removal of native notification systems on desktop platforms

On 10/08/2013 04:37 PM, Dave Townsend wrote: On Tue, Oct 8, 2013 at 3:30 PM, Marco > wrote: The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. For example, I think we shouldn't have removed

Re: Audit your code if you use mozilla::WeakPtr

On 2013-10-08 7:48 PM, Jeff Gilbert wrote: It would appear to me that you really need to promote this to a strong reference while you're using it. Yes, sure, if your object is refcounted somehow. Not all objects are though, so "strong pointer" is a semantic in those cases. Note that the id

Re: Audit your code if you use mozilla::WeakPtr

On 2013-10-08 7:38 PM, David Major wrote: Does it? I don't think I'm any more or less likely to omit a validity check using operator->() vs get(). Maybe it's just me. It seems like get() might actually be *more* prone to failure. Imagine: Class* object = foo.get(); if (object) { object->Met

Re: Removal of native notification systems on desktop platforms

Marco writes: > The bug has regressed a lot of things. To me it looks like the > decision to land it was a bit rushed. I can't help wondering whether the feature was needed urgently on b2g, and the people involved just didn't care enough if getting that done quickly also damaged desktop products.

Re: Audit your code if you use mozilla::WeakPtr

It would appear to me that you really need to promote this to a strong reference while you're using it. Even `if (foo) foo->bar();` could theoretically have the value of `foo` change between the branch and the deref. Also, do we at least `MOZ_ASSERT(get())` in `operator->`? Yes, it will crash i

Re: Audit your code if you use mozilla::WeakPtr

Does it? I don't think I'm any more or less likely to omit a validity check using operator->() vs get(). Maybe it's just me. It seems like get() might actually be *more* prone to failure. Imagine: Class* object = foo.get(); if (object) { object->Method(); } // ... A lot of stuff happens and th

Re: Removal of native notification systems on desktop platforms

On Tue, Oct 8, 2013 at 3:30 PM, Marco wrote: > The bug has regressed a lot of things. To me it looks like the decision > to land it was a bit rushed. For example, I think we shouldn't have removed > the Mac notification system, if it supported the necessary features for the > notifications API. S

Re: Audit your code if you use mozilla::WeakPtr

On 2013-10-08 7:10 PM, David Major wrote: Isn't it ultimately up to the developer to get it right? Someone could just as well forget to use |if (object)| from your example. Here's a sample usage from the header file: * // Test a weak pointer for validity before using it. * if (weak) {

Re: Audit your code if you use mozilla::WeakPtr

Isn't it ultimately up to the developer to get it right? Someone could just as well forget to use |if (object)| from your example. Here's a sample usage from the header file: * // Test a weak pointer for validity before using it. * if (weak) { * weak->num = 17; * weak->act(); *

Audit your code if you use mozilla::WeakPtr

I and Benoit Jacob discovered a bug in WeakPtr (bug 924658) which makes its usage unsafe by default. The issue is that WeakPtr provides convenience methods such as operator->, which mean that the consumer can directly dereference it without the required null checking first. This means that you ca

Re: Removal of native notification systems on desktop platforms

The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. For example, I think we shouldn't have removed the Mac notification system, if it supported the necessary features for the notifications API. Some people say also libnotify should support the ne

Re: Removal of native notification systems on desktop platforms

That's a pretty long bug to ask people to read over but... The original comment about posting to dev-platform seems to be simply asking that a thread be made to warn people that this change is coming, not for any discussion as such. It should have happened at the time but it's a bit late for it no

Removal of native notification systems on desktop platforms

In bug 782211, native notification systems support was removed. A lot of bugs have been filed to restore support for libnotify and Mac native notifications, because XUL notifications don't behave correctly on those systems (multi-monitor support is broken, etc.). The patch to remove this support

Re: Poll: What do you need in MXR/DXR?

> - Clicking on macros seem to lead to some results, but definitely not the one > I'd expect - > the definition of the macro. For example, if you click ROLE at http://dxr.mozilla.org/mozilla-central/source/accessible/src/base/RoleMap.h#l34, does the "Jump to definition" item from the context m

Re: Extensibility of JavaScript modules

That sounds quite sufficient for me. Do we have plans to backport Cu.import to ES6 modules? Cheers, David On 10/8/13 10:24 PM, Jason Orendorff wrote: > Here's the simplest way to monkeypatch an ES6 module: > > 1. Use System.get("x") or System.import("x", callback) to get the > Module object

Re: Extensibility of JavaScript modules

On Tue, Oct 8, 2013 at 8:24 AM, Till Schneidereit wrote: > Interesting. I wonder if the monkey patching will even still work once we > have es6 modules and use them in the platform. > > Jason and Eddy, you probably know, but I'm under the impression that monkey > patching an es6 module requires

Re: Coding style for functions called by Task.jsm tasks

On 10/8/2013 12:34 PM, Gregory Szorc wrote: Also, this JS is invalid because a generator function cannot return a value through "return." For people learning at home, a working implementation is: function add2(a, b) { return Task.spawn(function () { let sum = yield a + b; throw new T

Re: Coding style for functions called by Task.jsm tasks

On Tue, Oct 8, 2013 at 12:34 PM, Gregory Szorc wrote: > On 10/8/13 9:14 PM, Dave Townsend wrote: > >> I was asked to clarify what I meant by my two examples so here are some >> snippets of code that illustrate it. This is forcibly async but you get >> the >> point I hope. If you want to add three

Re: Coding style for functions called by Task.jsm tasks

On 10/8/13 9:14 PM, Dave Townsend wrote: I was asked to clarify what I meant by my two examples so here are some snippets of code that illustrate it. This is forcibly async but you get the point I hope. If you want to add three numbers you can define: function add3(foo, bar, baz) { return Tas

Re: Coding style for functions called by Task.jsm tasks

> I'm going to claim that the latter method of returning a new task promise > is the one we should use in general. It makes the function more easily > usable outside of a task since you're just getting a promise back. It is > also what Task.jsm does internally for generators anyway. I fully agree

Re: Coding style for functions called by Task.jsm tasks

On Tue, Oct 8, 2013 at 12:20 PM, Ted Mielczarek wrote: > On 10/8/2013 3:14 PM, Dave Townsend wrote: > > I was asked to clarify what I meant by my two examples so here are some > > snippets of code that illustrate it. This is forcibly async but you get > the > > point I hope. If you want to add th

Re: Coding style for functions called by Task.jsm tasks

On 10/8/2013 3:14 PM, Dave Townsend wrote: > I was asked to clarify what I meant by my two examples so here are some > snippets of code that illustrate it. This is forcibly async but you get the > point I hope. If you want to add three numbers you can define: > > function add3(foo, bar, baz) { >

Re: Coding style for functions called by Task.jsm tasks

I was asked to clarify what I meant by my two examples so here are some snippets of code that illustrate it. This is forcibly async but you get the point I hope. If you want to add three numbers you can define: function add3(foo, bar, baz) { return Task.spawn(() => { let sum = yield add2(foo

Re: Coding style for functions called by Task.jsm tasks

On 10/08/2013 12:00 PM, dev-platform-requ...@lists.mozilla.org wrote: Message: 7 Date: Tue, 8 Oct 2013 11:47:52 -0700 From: Dave Townsend To: dev-platform Subject: Coding style for functions called by Task.jsm tasks Message-ID: Content-Type: text/plain; charset=ISO-8859-1 As Task.jsm

Coding style for functions called by Task.jsm tasks

As Task.jsm is used more throughout our code it would be good to try to use similar sorts of patterns to avoid confusion. One difference I've spotted is in how to write asynchronous functions that are called by tasks. One way is to simply write the function as a generator, the other is to write th

Re: Poll: What do you need in MXR/DXR?

http://dxr.mozilla.org/mozilla-central shouldn't 404, but do something useful (probably redirect to either root or %source/) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Extensibility of JavaScript modules

On 10/8/13 10:09 AM, Benjamin Smedberg wrote: > On 10/8/2013 11:06 AM, Bobby Holley wrote: >> In general, I'm pretty against this kind of monkey-patching if it's made >> available to out-of-tree consumers. We should learn our lesson from XPCOM >> and recognize what a royal PITA it can be when exten

Re: Extensibility of JavaScript modules

On 10/8/2013 11:06 AM, Bobby Holley wrote: In general, I'm pretty against this kind of monkey-patching if it's made available to out-of-tree consumers. We should learn our lesson from XPCOM and recognize what a royal PITA it can be when extensions start to depend on implementation details. Allowi

Re: Extensibility of JavaScript modules

On 10/8/13 1:16 PM, David Rajchenbach-Teller wrote: A (not very) long time ago, our extension model was based on XPCOM – if you didn't like a component, you could just replace it in an add-on. These days, we have shifted to providing JavaScript modules and suggesting JavaScript add-ons. Now, by

Re: Extensibility of JavaScript modules

Frankly I wish the JSM import code didn't do what it does now, returning the entire global scope of the module to allow anyone outside to change it. Modules should be well contained and immutable, one piece of code shouldn't be able to make changes that breaks other code. If we need to allow extens

Re: Extensibility of JavaScript modules

In general, I'm pretty against this kind of monkey-patching if it's made available to out-of-tree consumers. We should learn our lesson from XPCOM and recognize what a royal PITA it can be when extensions start to depend on implementation details. Allowing something to be modified/overridden by emb

Re: Poll: What do you need in MXR/DXR?

Erik Rose wrote: What are the MXR things you use constantly? I can't seem to get the advanced search form to work at all. (It does at least tell me the prefixes that I can use in the simple search form, but it's not 100% clear what they mean.) When it does work I would like a direct link t

Re: Transparent Black, or Are all transparent colors create equal?

One kind of layer that would not have premultiplied alpha would be a CanvasLayer with a WebGL context with the {premultipliedAlpha:false} context attribute (what was passed as the 2nd argument to canvas.getContext). I did some testing and found a bug, https://bugzilla.mozilla.org/show_bug.cgi?id=9

Re: Extensibility of JavaScript modules

Interesting. I wonder if the monkey patching will even still work once we have es6 modules and use them in the platform. Jason and Eddy, you probably know, but I'm under the impression that monkey patching an es6 module requires funneling it through a custom module loader. Maybe the platform shoul

Extensibility of JavaScript modules

A (not very) long time ago, our extension model was based on XPCOM – if you didn't like a component, you could just replace it in an add-on. These days, we have shifted to providing JavaScript modules and suggesting JavaScript add-ons. Now, by default, any JavaScript module can be monkey-patched.