Re: Intent to implement: Early, experimental support for application/javascript+binast

[Honza Bambas]

On 2018-04-18 19:13, David Teller wrote:

No plans yet, but it's a good idea. The only reason not to do this (that
I can think of) is that we might prefer switching to the Bytecode Cache,
which would probably give us even better speed ups.

I understand that we can't use the Bytecode Cache for our chrome code
yet due to the fact that it uses a very different path in Necko, which
is the Source of Truth for the Bytecode Cache, but I may be wrong, and
it might be fixable.


ByteCode cache is implemented "natively" only for http:// urls through 
http channels talking to http cache.


There is an effort to implement the alternative-data bits of the caching 
channel interface (implemented by the http channel now) also for 
channels handling chrome: and I think resource: urls.  There is lately 
not much progress on that bug(s) to my knowledge, though.


-hb-



Cheers,
  David

On 18/04/2018 19:09, Dave Townsend wrote:

This is awesome. I understand that we already do some kind of
pre-compile for our chrome code, is there any plan/benefit to switch to
this eventually there?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform






smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Boris Zbarsky]

On 4/18/18 11:19 PM, Nika Layzell wrote:

This allows us to avoid using nsISupports to pass WebIDL objects which
don't have corresponding XPIDL interfaces through XPIDL defined methods.


This is awesome.

In particular, it means we can pass WebIDL things through XPIDL without 
adding weird "QI to the concrete type" bits to them.  This should let us 
make pretty rapid progress on 
https://bugzilla.mozilla.org/show_bug.cgi?id=1387169 and in particular 
on getting rid of things like nsIDOMNode/nsIDOMEvent/nsIDOMDocument.


Thank you for doing this,
Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Gijs Kruitbosch]

Dumb question because I don't do this very often - sorry!

I am intending to async-ify a sync JS-implemented idl-defined API (which 
currently returns an unsigned long), that has a few C++ consumers. I was 
thinking the simplest solution would be a separate method definition in 
the idl that took a separate interface (nsIFooCallback) that then got 
the long and/or any other data we needed to pass. This because returning 
a promise seems to previously have involved returning jsval and then 
things get more complicated from there. The only in-tree .idl uses I saw 
for Promise are in the wpt test idl files, which I presume don't reflect 
our ability to implement that as a return type.


If I understand correctly, with these changes I could now just use 
Promise instead. Is that correct? Can I declare it including the 
resolution result of the promise, ie can I now use:


Promise asyncGetFoo()

in xpidl? Because that would make my life considerably easier...

~ Gijs

On 19/04/2018 04:19, Nika Layzell wrote:

Yesterday, bug 1444991
 landed on inbound,
which adds support for using WebIDL defined objects directly inside of
XPIDL definition files.

This allows us to avoid using nsISupports to pass WebIDL objects which
don't have corresponding XPIDL interfaces through XPIDL defined methods.

WebIDL objects must be forward declared, like XPIDL types, in the .idl file
which uses them:

   // C++ 'nsFrameLoader', from FrameLoader.webidl
   webidl FrameLoader;

   // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
   webidl DataTransfer;

These types may then be used like XPIDL types in method and attribute
declarations. These types can be used from both C++ and JS code. They are
exposed into Rust as '*const ::libc::c_void`.

- NIka



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Andrew McCreight]

On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch 
wrote:

> Dumb question because I don't do this very often - sorry!
>
> I am intending to async-ify a sync JS-implemented idl-defined API (which
> currently returns an unsigned long), that has a few C++ consumers. I was
> thinking the simplest solution would be a separate method definition in the
> idl that took a separate interface (nsIFooCallback) that then got the long
> and/or any other data we needed to pass. This because returning a promise
> seems to previously have involved returning jsval and then things get more
> complicated from there. The only in-tree .idl uses I saw for Promise are in
> the wpt test idl files, which I presume don't reflect our ability to
> implement that as a return type.
>
> If I understand correctly, with these changes I could now just use Promise
> instead. Is that correct? Can I declare it including the resolution result
> of the promise, ie can I now use:
>
> Promise asyncGetFoo()
>
> in xpidl? Because that would make my life considerably easier...
>

Bug 1455217 by Nika is going to add a Promise type to XPIDL.  So I think
you have to wait for that.


> ~ Gijs
>
> On 19/04/2018 04:19, Nika Layzell wrote:
>
>> Yesterday, bug 1444991
>>  landed on inbound,
>> which adds support for using WebIDL defined objects directly inside of
>> XPIDL definition files.
>>
>> This allows us to avoid using nsISupports to pass WebIDL objects which
>> don't have corresponding XPIDL interfaces through XPIDL defined methods.
>>
>> WebIDL objects must be forward declared, like XPIDL types, in the .idl
>> file
>> which uses them:
>>
>>// C++ 'nsFrameLoader', from FrameLoader.webidl
>>webidl FrameLoader;
>>
>>// C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
>>webidl DataTransfer;
>>
>> These types may then be used like XPIDL types in method and attribute
>> declarations. These types can be used from both C++ and JS code. They are
>> exposed into Rust as '*const ::libc::c_void`.
>>
>> - NIka
>>
>>
> ___
> 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: Using WebIDL objects in XPIDL

[Kris Maglione]

\o/

On Wed, Apr 18, 2018 at 11:19:27PM -0400, Nika Layzell wrote:

Yesterday, bug 1444991
 landed on inbound,
which adds support for using WebIDL defined objects directly inside of
XPIDL definition files.

This allows us to avoid using nsISupports to pass WebIDL objects which
don't have corresponding XPIDL interfaces through XPIDL defined methods.

WebIDL objects must be forward declared, like XPIDL types, in the .idl file
which uses them:

 // C++ 'nsFrameLoader', from FrameLoader.webidl
 webidl FrameLoader;

 // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
 webidl DataTransfer;

These types may then be used like XPIDL types in method and attribute
declarations. These types can be used from both C++ and JS code. They are
exposed into Rust as '*const ::libc::c_void`.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Kris Maglione]

On Thu, Apr 19, 2018 at 12:58:33PM -0700, Andrew McCreight wrote:

On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch 
wrote:

If I understand correctly, with these changes I could now just use Promise
instead. Is that correct? Can I declare it including the resolution result
of the promise, ie can I now use:

Promise asyncGetFoo()

in xpidl? Because that would make my life considerably easier...



Bug 1455217 by Nika is going to add a Promise type to XPIDL.  So I think
you have to wait for that.


This actually isn't as difficult currently as you may expect. At 
least, the difference between XPIDL and WebIDL isn't. From the 
C++ consumer, you'd just have to do:


 RefPtr result(Promise::Resolve(global, cx, resultVal, rv));

Which is more or less what the WebIDL layer does.

The real problem is that you're going to have to do the coercion 
on the resolution value yourself. That problem is the same 
whether you're implementing it in WebIDL or XPIDL.


If you're just dealing with an integer value, that's pretty 
easy. Something like `result.toInt32()` should do the job.


If it's something more complicated, well, it's more complicated. 
But WebIDL dictionary types are probably by far the easiest way 
to handle it.



So, basically what I'm saying is that a callback interface is 
still probably the easiest way to handle this from the C++ side, 
but a Promise should work, and shouldn't be that much harder in 
XPIDL than it is in WebIDL.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Boris Zbarsky]

On 4/19/18 3:53 PM, Gijs Kruitbosch wrote:
If I understand correctly, with these changes I could now just use 
Promise instead.


Not yet, as Andrew said.  This just makes things declared as "interface 
Something { ... }" in .webidl files work.  Promise is not one of those 
things.


That said, I expect that bug 1455217 will land Very Soon Now.

Also, we have existing magic in XPConnect to make it possible to pass a 
Promise as nsISupports through XPConnect.  Specifically, the rules are 
as follows:


1)  When doing a C++-to-JS conversion, if the type is nsISupports (or 
Promise after Nika's patches in bug 1455217) and the C++ thing is a 
dom::Promise, it gets converted to the underlying SpiderMonkey Promise 
object.


2)  When doing a JS-to-C++ conversion, if the type is nsISupports and 
the JS thing being passed is a SpiderMonkey Promise, it gets wrapped up 
in a dom::Promise and the nsISupports* pointer to that is passed to the 
C++ code.


So today, before Nika's fix, you can write this idl:

  nsISupports doAsyncFoo();  // Implemented in JS

and call it from C++ like so:

  nsCOMPtr result;
  myThing->DoAsync(getter_AddRefs(result));

  RefPtr promise = do_QueryObject(result);
  if (!promise) {
// Callee messed up and returned a non-promise
  }
  // Work with "promise".


Is that correct? Can I declare it including the 
resolution result of the promise


Note that the resolution type is purely documentation in webidl; it 
doesn't affect any behavior.  A function could have Promise as its 
idl return type but mess up and and return a Promise resolved with a 
Node and the bindings won't stop it.


The xpconnect fix above does not add that syntax; it just adds "Promise" 
with no type parameter.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform