Re: [dev-servo] custom derive for Deref/DerefMut

[Jim Blandy]

A macro_rules macro wouldn't serve here?

On Fri, Jul 14, 2017 at 5:26 PM, Bobby Holley  wrote:

> On Fri, Jul 14, 2017 at 2:24 AM, Anthony Ramine  wrote:
>
> >
> > > Le 14 juil. 2017 à 02:13, Bobby Holley  a
> écrit :
> > >
> > > There's a lot of boilerplate involved just to make a newtype [1]. Is
> this
> > > something we could add a custom derive for?
> >
> > We don't use that many newtypes to justify writing a custom derive for
> > that IMO. Often we don't even bother and just do wrapper.0.
> >
>
> Well, we all do that because writing 10 lines of boilerplate is usually
> worse than scattering some .0s around. If there were a 1-line derive we
> might use it more.
>
>
> > Remove all the unneeded where clauses for E on the type definition, and
> on
> > the Deref* impls and you have only ~10 lines of boilerplate.
> >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] DOM goals for 2017

[Jim Blandy]

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
   sources.


   - The disposition of the stream can be selected: circular buffer,
   captured on request, like Cleopatra? Log to file as JSON? protobuf on a
   socket? Send to an in-browser visualization tool?


   - Stream entries should have enough metadata to let generic tools plot
   them in some helpful way, as long as they have one of the usual shapes:
   point in time; range of time; native stack; JS stack; textual label; id
   with edges to other ids; etc.

We're aiming to compete with fprintf: it should be almost as easy for a dev
to hack in some instrumentation, recompile, and immediately see the results
in the devtools, with no devtools UI hacking required, as it would be to
fprintf it and glop it up into a Python script.

SpiderMonkey will depend on the stream, so it'll be present in Servo once
it picks up a recent enough version. It should be feasible to have Rust
APIs for contributing data to the stream, so Servo could contribute, too.

I don't know what would be entailed if we wanted to incorporate the new
Cleopatra UI ( https://github.com/mstange/cleopatra ) into Servo, or if
that's even desirable. But I don't know of any reason it would be more
difficult than incorporating any other HTML/JS - based devtool UI.




On Wed, Dec 14, 2016 at 9:42 AM, Jack Moffitt  wrote:

> 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
> >
> > 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 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) reduce barriers to contributing to the DOM code
> >>
> >> These will allow us to make more meaningful comparisons between Servo
> and
> >> other production web browsers, while continuing to provide opportunities
> >> for volunteer contributors to make an impact.
> >>
> >> Broken down, I envision the following tasks allowing us to focus our
> >> efforts:
> >>
> >> 1) track performance metrics that are relevant to users
> >> * report progressive web metrics [1]
> >>
> >> 2) address web compatibility issues, prioritized according to frequency
> on
> >> real websites
> >> * implement missing/broken features required by Google Docs
> >> * support the needs of the WebVR team
> >> * track web compatibility issues on real websites
> >> * investigate panics reported by nightly users
> >>
> >> 3) reduce barriers to contributing to the DOM code
> >> * reduce the time required to build after changing non-WebIDL/bindings
> code
> >> * create high level abstractions for common patterns
> >> * reduce the need for unsafe code
> >>
> >> We've got a good base to work from - there are still some significant
> >> pieces of the web platform that we know are holding us back right now,
> but
> >> in general it feels like there is a long tail of smaller compatibility
> >> issues that we need to address. In 2017 I want to get a handle on how
> long
> >> that tail is and start addressing it. This will require being deliberate
> >> about trying Servo on a wide variety of sites, and filing issues to
> track
> >> everything that's not working correctly.
> >>
> >> We also have a small but enthusiastic group of people who try out
> nightly
> >> builds on a regular basis, and they're really helpful! Panics reported
> from
> >> nightly builds often go uninvestigated, and I believe this is hurting
> our
> >> compatibility story.
> >>
> >> Finally, we're all aware that working in the script crate can be a
> >> frustrating experience. It's time to start dealing with the burden of
> >> technical debt - we need to look for ways to write better async code,
> less
> >> unsafe code, and address the ever-growing, monolithic script crate. I
> have
> >> ideas I want to try for each of these problems, and I encourage
> everyone to
> >> be ambitious about them.
> >>
> >> I'm going to stop here rather than breaking down those tasks any
> further.
> >> I've got a list of issues that I want to tackle that address each of
> them,
> >> and it's going to get much larger once I get results back from the Blink
> >> team about DOM API use on the top 100,000 sites. I would welcome any
> >> feedback people have about 

Re: [dev-servo] Creating a JSObject -> id map for the Debugger IPC server.

[Jim Blandy]

Those would serve, certainly. But won't they vary from run to run for
reasons outside our control? I'd be a little more comfortable keeping the
id's deterministic, if it's not a big deal.



On Tue, Dec 13, 2016 at 8:58 AM, Nick Fitzgerald <nfitzger...@mozilla.com>
wrote:

> We already have IDs for GC things that are stable across moving GCs, but
> I'm not 100% sure they are exposed in JSAPI.
>
> Aha, looks like it is exposed:
> http://searchfox.org/mozilla-central/rev/594937fec2e2fc45fa9308ba2fb964
> 816631f017/js/public/RootingAPI.h#660
>
> On Mon, Dec 12, 2016 at 9:10 PM, Jim Blandy <jbla...@mozilla.com> wrote:
>
> > Honestly, I've never liked the devtools server's practice of using
> weakmaps
> > for every little thing. They're expensive, and the Debugger itself is
> > already using weakmaps internally for the association from real debuggee
> > things to their Debugger shadows, and guarantees distinct shadows for
> each
> > (debuggee thing, Debugger) pair, explicitly to help things work this way.
> >
> > So I'm in favor of putting the ids directly on the Debugger.Foo
> instances.
> > Death to weakmaps!
> >
> >
> > On Mon, Nov 21, 2016 at 1:24 AM, Eddy Bruel <ejpbr...@mozilla.com>
> wrote:
> >
> > > For the Servo debugger, we need some kind of IPC layer:
> > >
> > > The debugger server (i.e. the thing that talks the Chrome debugging
> > > protocol) needs to live in the same process (and perhaps even the same
> > > thread) as the constellation; it needs to work closely with the
> > > constellation to figure out which script threads exists, and to route
> > > messages to individual script threads.
> > >
> > > At the other end, the debugger API (i.e. the thing we use to examine
> the
> > > execution state of the JS engine) needs to live in the same thread as
> the
> > > one it is debugging (i.e. the script thread). In multiprocess mode,
> there
> > > will be a process boundary between the constellation and the script
> > > threads. Consequently, we need an IPC layer between the debugger server
> > and
> > > the debugger API in each script thread.
> > >
> > > Since the debugger API consists of a set of shadow objects (each of
> which
> > > represents som part of the execution state, such as stack frames,
> > > environments, scripts, etc), the obvious way to implement such an IPC
> > layer
> > > is as a set of proxies to each shadow object: to serialize a shadow
> > object
> > > over ipc, we assign it a unique ID. In the other direction, any message
> > > addressed to that id will be routed to the appropriate object.
> > >
> > > To route messages addressed to a specific id to the corresponding
> object,
> > > we need to maintain some for of id -> object map. Moreover, because the
> > > same shadow object can be obtained via different API calls, we need an
> > > object -> id map; this allows us to ensure that we never create more
> than
> > > one proxy for the same shadow object.
> > >
> > > Creating an object -> id map is problematic; since a *mut JSObject does
> > not
> > > have a stable address, it cannot be used as a key in a HashMap. The
> > obvious
> > > answer here is to use a WeakMap. WeakMaps are available in JSAPI, but
> as
> > > far as I can tell, not usable with the Rust bindings for JSAPI.
> > >
> > > Adding WeakMap support to the Rust bindings for JSAPI is probably
> > > non-trivial, so I'm looking for some kind of temporary workaround. The
> > > simplest option is perhaps to store the id directly on the JSObject.
> The
> > > Debugger API is designed so that defining arbitrary properties on
> shadow
> > > objects is well-defined. Since we control how these JSObjects are used
> > > (i.e. they are not exposed to arbitrary client JS), this should not
> lead
> > to
> > > conflicts.
> > >
> > > Another option is to create a WeakMap indirectly, by doing the
> equivalent
> > > of evaluating "new WeakMap()", storing the resulting JSObject, and then
> > > providing some strongly typed Rust API on top of it. Note that this is
> > very
> > > similar to what we do for the shadow objects in the debugger API.
> > >
> > > I am currently leaning towards the first option, but perhaps someone
> has
> > a
> > > better idea?
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Creating a JSObject -> id map for the Debugger IPC server.

[Jim Blandy]

Honestly, I've never liked the devtools server's practice of using weakmaps
for every little thing. They're expensive, and the Debugger itself is
already using weakmaps internally for the association from real debuggee
things to their Debugger shadows, and guarantees distinct shadows for each
(debuggee thing, Debugger) pair, explicitly to help things work this way.

So I'm in favor of putting the ids directly on the Debugger.Foo instances.
Death to weakmaps!


On Mon, Nov 21, 2016 at 1:24 AM, Eddy Bruel  wrote:

> For the Servo debugger, we need some kind of IPC layer:
>
> The debugger server (i.e. the thing that talks the Chrome debugging
> protocol) needs to live in the same process (and perhaps even the same
> thread) as the constellation; it needs to work closely with the
> constellation to figure out which script threads exists, and to route
> messages to individual script threads.
>
> At the other end, the debugger API (i.e. the thing we use to examine the
> execution state of the JS engine) needs to live in the same thread as the
> one it is debugging (i.e. the script thread). In multiprocess mode, there
> will be a process boundary between the constellation and the script
> threads. Consequently, we need an IPC layer between the debugger server and
> the debugger API in each script thread.
>
> Since the debugger API consists of a set of shadow objects (each of which
> represents som part of the execution state, such as stack frames,
> environments, scripts, etc), the obvious way to implement such an IPC layer
> is as a set of proxies to each shadow object: to serialize a shadow object
> over ipc, we assign it a unique ID. In the other direction, any message
> addressed to that id will be routed to the appropriate object.
>
> To route messages addressed to a specific id to the corresponding object,
> we need to maintain some for of id -> object map. Moreover, because the
> same shadow object can be obtained via different API calls, we need an
> object -> id map; this allows us to ensure that we never create more than
> one proxy for the same shadow object.
>
> Creating an object -> id map is problematic; since a *mut JSObject does not
> have a stable address, it cannot be used as a key in a HashMap. The obvious
> answer here is to use a WeakMap. WeakMaps are available in JSAPI, but as
> far as I can tell, not usable with the Rust bindings for JSAPI.
>
> Adding WeakMap support to the Rust bindings for JSAPI is probably
> non-trivial, so I'm looking for some kind of temporary workaround. The
> simplest option is perhaps to store the id directly on the JSObject. The
> Debugger API is designed so that defining arbitrary properties on shadow
> objects is well-defined. Since we control how these JSObjects are used
> (i.e. they are not exposed to arbitrary client JS), this should not lead to
> conflicts.
>
> Another option is to create a WeakMap indirectly, by doing the equivalent
> of evaluating "new WeakMap()", storing the resulting JSObject, and then
> providing some strongly typed Rust API on top of it. Note that this is very
> similar to what we do for the shadow objects in the debugger API.
>
> I am currently leaning towards the first option, but perhaps someone has a
> better idea?
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Fwd: Maintaining a list of debugging targets in the debugger.

[Jim Blandy]

On Mon, Sep 19, 2016 at 10:49 AM, Jim Blandy <jbla...@mozilla.com> wrote:

> However! It turns out that Servo doesn't implement this at all right now.
> At present, the above arrangement would create three ScriptThreads, and
> `frame.contentWindow == null` in the cross-origin case.
>

In case it wasn't clear: this is something that Servo knows it will need to
change to become compatible with the web.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Blink's new layout proposal

[Jim Blandy]

Probably of interest outside Servo, too?

On Thu, Jul 21, 2016 at 5:27 AM, Josh Matthews 
wrote:

> Just posted on
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/EDczWkKR9P0
> and probably worth a look!
>
> Cheers,
> Josh
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Web console protocol support for Servo

[Jim Blandy]

Dear Servo folks,

We devtools folks are almost done converting our web console UI to pure
HTML, so we're planning our further work for Q3 and Q4. We have a few
questions for you:

Our understanding is that your plan was to take out your Firefox devtools
protocol support and start implementing the Chrome protocol, once your June
demos were done. Have you started work on this? If not, the Devtools team
has time for that in Q3-4, and people interested in doing the work. For
unrelated reasons, we want to adjust our console protocol to more closely
resemble Chrome's, but one effect of that is to make it easier to support
both protocols, so that's readily doable.

The Chrome RDP is based on WebSockets. Does Servo have a WebSocket server
implemented already that it wants to use, or does one need to be written?

Our web console UI uses some HTML/CSS features that Servo doesn't yet
support. We could file bugs for these if they would be of interest to you;
would they?

Thanks!
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo