Thanks
On Sun, Dec 4, 2016 at 10:51 AM, Olaf Buddenhagen
wrote:
> Hi,
>
> On Wed, Nov 16, 2016 at 07:48:36PM +0100, Eddy Bruel wrote:
>
> > To make IPC channels usable with Tokio, we'd have to take whatever low
> > level IO primitive IPC channels use under the hood, and then reimplement
> > the
Hey everyone! It's time to make plans for 2017, so here are my thoughts
on the subject. I think we should focus on the following high-level goals:
1) track performance metrics that are relevant to users
2) address web compatibility issues, prioritized according to frequency
on real websites
3)
These seem like exactly the goals I'd come up with, as an occasional
contributor to the DOM. +1!
Patrick
On Wed, Dec 14, 2016 at 9:03 AM, Josh Matthews
wrote:
> Hey everyone! It's time to make plans for 2017, so here are my thoughts on
> the subject. I think we should focus on the following hig
The only missing piece to this is the performance work / magic dom
exploration. I am already excited for next year :)
jack.
On Wed, Dec 14, 2016 at 10:09 AM, Patrick Walton wrote:
> These seem like exactly the goals I'd come up with, as an occasional
> contributor to the DOM. +1!
>
> Patrick
>
>
So, for Firefox in 2017 we have a gross (meaning unrefined, broad) plan to
gather the many sources of data we already have in Gecko (SPS; TraceLogger;
TaskTracer; Window.performance; and on and on) into a single stream of data:
- There should be a common API to enumerate and enable/disable data
I'm thinking about splitting those parts into a separate crate because
currently servo/style component's build script is doing two different
things: 1. generate property code, 2. do bindgen. And mixing these
things may lead to many unnecessary rebuild.
In the current build-time bindgen code, all h
They used to be a different crate. I merged them so that we can do
replacements with safer wrappers and have fewer coherence issues.
Perhaps we can make triggering local build time bindgen regen more explicit?
On Dec 14, 2016 2:57 PM, "Xidorn Quan" wrote:
> I'm thinking about splitting those pa
On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote:
> They used to be a different crate. I merged them so that we can do
> replacements with safer wrappers and have fewer coherence issues.
It doesn't seem to me the safer wrappers (I suppose the ones in
gecko_bindings/sugar?) needs the bind
The sugar stuff is just helpers. The crossover happens in the bindings file
itself, where &ServoOpaqueType gets replaced with &RealType, etc.
On Dec 14, 2016 5:13 PM, "Xidorn Quan" wrote:
> On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote:
> > They used to be a different crate. I merge
On 15/12/16 02:01, Manish Goregaokar wrote:
They used to be a different crate. I merged them so that we can do
replacements with safer wrappers and have fewer coherence issues.
Could the code generated by bindgen be separated from the wrappers? That
way wrappers could be wherever impl coherenc
Yes, this could be done. I would like to have more automated checks here
however if we were to do this.
At one point I had considered letting the generated bindings be super
unsafe and then for each servo_*/gecko_* function have a safe wrapper that
is generated (or handwritten?) that forwards to i
11 matches
Mail list logo
