Re: XPIDL Promises
On 30/07/2013 22.40, Andreas Gal wrote: Whats the main pain point? Whether promises are resolved immediately or from a future event loop iteration? That. The migration from core/promise.js to Promise.jsm should address consumers expecting callbacks to be called immediately. Promises.jsm conforms to Promises/A+ in guaranteeing that then returns before the callbacks it registers are invoked. It seems DOM Promises guarantee that too, so any possible migration from Promise.jsm to DOM Promises seems easier. Also, to clarify, event loop may refer to different things. We're not really going back to the operating system's event loop while there are still promises to resolve, for performance reasons (for example, when iterating over a chain of resolved promises created by Task.jsm). We have a Promise.jsm test suite that we should run on DOM Promises before migration, though subtle differences in the event loop model might still be uncaught in some edge cases. I expect this to have less impact than the current core/promise.js - Promise.jsm migration. It's still a pity that we're not putting enough resources on the migration from core/promise.js to Promise.jsm (see bug 881047 and the mentioned dependencies of bug 856878). Most code that blocks migration is just made of test cases, rather than production code. Accelerating on bug 881047 would be great, to at least reduce our implementations from three to two :-) Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
XPIDL Promises
Hi, From code I can use Cu.import(resource://gre/modules/Promise.jsm); to use promises. But is it possible to have a promise as a return type in my .idl file (b2g)? Something like Promise blah(); won't just work and I'm a bit lost :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
For that we would have to implement Promise via IDL. Definitely possible. All you need is a bit IDL and some JS that implements it. It would be a lot slower than the jsm since it wraps into C++ objects that call into JS, but in most cases that doesn't really matter. Andreas janjongb...@gmail.com wrote: Hi, From code I can use Cu.import(resource://gre/modules/Promise.jsm); to use promises. But is it possible to have a promise as a return type in my .idl file (b2g)? Something like Promise blah(); won't just work and I'm a bit lost :-) ___ 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: XPIDL Promises
On 7/30/13 7:43 AM, Boris Zbarsky wrote: On 7/30/13 7:20 AM, janjongb...@gmail.com wrote: But is it possible to have a promise as a return type in my .idl file (b2g)? Just list it as nsISupports in the .idl. XPConnect will do the right thing. Ignore the above; I thought you were talking about Gecko's Promise implementation, not a manual impl in JS. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
Yeah, I just saw that grepping through the tree. Both completely independent, too. On the upside, this might solve Jan's problem. Andreas Boris Zbarsky wrote: On 7/30/13 7:36 AM, Andreas Gal wrote: For that we would have to implement Promise via IDL. Definitely possible. All you need is a bit IDL and some JS that implements it. It would be a lot slower than the jsm since it wraps into C++ objects that call into JS, but in most cases that doesn't really matter. Wait. Why do we have multiple Promise implementations now? :( -Boris ___ 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: XPIDL Promises
On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. OK. Given that there is also a desire to be able to use the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
Maybe, but also, generally speaking we shouldn't be using .idl files for b2g any more, at least not writing new ones. We should be implementing things with WebIDL. What's the case where we need/want this here? On 7/30/2013 7:51 AM, Andreas Gal wrote: Yeah, I just saw that grepping through the tree. Both completely independent, too. On the upside, this might solve Jan's problem. Andreas Boris Zbarsky wrote: On 7/30/13 7:36 AM, Andreas Gal wrote: For that we would have to implement Promise via IDL. Definitely possible. All you need is a bit IDL and some JS that implements it. It would be a lot slower than the jsm since it wraps into C++ objects that call into JS, but in most cases that doesn't really matter. Wait. Why do we have multiple Promise implementations now? :( -Boris ___ 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 -- jst ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On Tue, Jul 30, 2013 at 11:17 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. OK. Given that there is also a desire to be able to use the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. Sounds great. We'll need to investigate whether the implementations are compatible, though - we've been going through various existing JS consumers switching them to a different promise implementation (Promise.jsm, https://bugzilla.mozilla.org/show_bug.cgi?id=856878 tracks several instances) and have been running into issues with different behavior related to promise resolution. There is a significant amount of existing chrome code using one of the two existing JS implementations (Promise.jsm and core/promise.js from the Add-on SDK), and porting them to DOM promises will take some effort. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
Whats the main pain point? Whether promises are resolved immediately or from a future event loop iteration? Andreas Gavin Sharp wrote: On Tue, Jul 30, 2013 at 11:17 AM, Boris Zbarskybzbar...@mit.edu wrote: On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. OK. Given that there is also a desire to be able to use the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. Sounds great. We'll need to investigate whether the implementations are compatible, though - we've been going through various existing JS consumers switching them to a different promise implementation (Promise.jsm, https://bugzilla.mozilla.org/show_bug.cgi?id=856878 tracks several instances) and have been running into issues with different behavior related to promise resolution. There is a significant amount of existing chrome code using one of the two existing JS implementations (Promise.jsm and core/promise.js from the Add-on SDK), and porting them to DOM promises will take some effort. Gavin ___ 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: XPIDL Promises
On 7/30/13 1:37 PM, Gavin Sharp wrote: We'll need to investigate whether the implementations are compatible, though That's fair. DOM Promises are definitely modeled after Promises/A+, but the APIs might not quite match up. :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On 7/30/2013 1:41 PM, Boris Zbarsky wrote:
On 7/30/13 1:37 PM, Gavin Sharp wrote:
We'll need to investigate whether the implementations
are compatible, though
That's fair. DOM Promises are definitely modeled after Promises/A+,
but the APIs might not quite match up. :(
They don't. With DOM Promises you might do:
function doAsync(){
return new Promise(function(resolver) {
somethingRemote(function(err, result) {
if (err) {
resolver.reject(err);
} else {
resolver.resolve(result);
}
});
});
}
With the Promise implementation used in Addon SDK and devtools (and
perhaps elsewhere), you would do:
function doAsync(){
let deferred = Promise.defer();
somethingRemote(function(err, result){
if (err) {
deferred.reject(err);
} else {
deferred.resolve(result);
}
});
return deferred.promise;
}
It's not a transformation that can be done mechanically really. On the
other hand, it's pretty trivial to wrap the DOM Promise API in an API
that would be compatible with the old Promise implementation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On 7/30/2013 1:17 PM, Boris Zbarsky wrote:
On 7/30/13 11:13 AM, Dave Townsend wrote:
The JS promise implementation came out of a desire to use promises in
add-ons and devtools amongst others. I believe the C++ implementation
came
out of the DOM spec. I'm not sure why we need both.
OK. Given that there is also a desire to be able to use the DOM
Promises in b2g (see bug 897913), how do people feel about enabling
the Promise API in at least chrome globals (and via Xrays), and
setting up Promise in things like JS component globals as well? This
shouldn't be too difficult to do... Then anyone who wants to use
Promises in Chrome code can use the DOM ones.
For what it's worth, I've pondered what it would take to give a
C++-ish API to promises. It turns out to not be extremely difficult,
except for the fact that there are a bajillion ways to represent
functions in C++, so the approach really requires std::function to work
properly, and even then, template argument deduction fails (this could
probably be remedied with more function overloading to get what you need
in common cases, or people can suck it up and manually specify the
return type for Then). An example implementation, tested with both
libstdc++ 4.8 [I'm told std::function exists as far back as 4.5, and it
looks like stlport even has it] and MSVC10, is as follows:
#include functional
#include memory
#include vector
/// Returns a promise to return something of type T
template typename T
class Promise {
public:
Promise() : mResolvers(new std::vectorstd::functionvoid(T)()) {}
void Resolve(T aValue) {
for (auto it = mResolvers-begin(); it != mResolvers-end(); ++it) {
(*it)(aValue);
}
}
template typename U
PromiseU Then(const std::functionU(T) resolve) {
ReinvokerU x(resolve);
mResolvers-push_back(x);
return *x.getPromise();
}
template typename U class Reinvoker {
std::shared_ptrPromiseU mResult;
std::functionU(T) mCallee;
public:
Reinvoker(const std::functionU(T) callee) :
mResult(new PromiseU()),
mCallee(callee) {}
std::shared_ptrPromiseU getPromise() { return mResult; }
void operator()(T x) { mResult-Resolve(mCallee(x)); }
};
private:
std::shared_ptrstd::vectorstd::functionvoid(T) mResolvers;
};
Given that this kind of thing works, I wonder if it would make sense to
use this sort of thing in C++ as well...
--
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
