Re: [dev-servo] NCSU Team introduction

[Josh Matthews]

On 2016-11-21 5:22 PM, bban...@ncsu.edu wrote:

On Thursday, November 3, 2016 at 5:43:29 PM UTC-4, Josh Matthews wrote:

On 2016-11-03 4:05 PM, ysu...@ncsu.edu wrote:

Hi Josh,

Do we need to write test cases for what we have done so far? If yes, do we need 
to run auto test cases (e.g. unit test) or a simple HTML test page is enough? 
Since right now we only did initial steps, we have no idea how to test it. Can 
you give us some instructions?



I do not believe it is possible to create automated tests for the
changes in https://github.com/servo/servo/pull/13969 .

Cheers,
Josh


Thank you josh for your kind words and valuable suggestions.

I was thinking, since we have changed the approach for the initial steps and 
are using bitflags instead of enum, shall we change the same on project 
description hosted on github so that the new team do not get confuse while 
implementing.

Though I have explained them the whole sequence, and I am always available for 
them if they have any doubts, but still it would be great if we can update that.

Regards
Bhavya



Good point! I have revised the instructions in 
https://github.com/servo/servo/wiki/Form-validation-student-project to 
include more specific instructions that better account for the work that 
has already been accomplished. Let me know if anything is unclear!


Cheers,
Josh
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] NCSU Team introduction

[bbansal]

On Thursday, November 3, 2016 at 5:43:29 PM UTC-4, Josh Matthews wrote:
> On 2016-11-03 4:05 PM, ysu...@ncsu.edu wrote:
> > Hi Josh,
> >
> > Do we need to write test cases for what we have done so far? If yes, do we 
> > need to run auto test cases (e.g. unit test) or a simple HTML test page is 
> > enough? Since right now we only did initial steps, we have no idea how to 
> > test it. Can you give us some instructions?
> >
> 
> I do not believe it is possible to create automated tests for the 
> changes in https://github.com/servo/servo/pull/13969 .
> 
> Cheers,
> Josh

Thank you josh for your kind words and valuable suggestions.

I was thinking, since we have changed the approach for the initial steps and 
are using bitflags instead of enum, shall we change the same on project 
description hosted on github so that the new team do not get confuse while 
implementing.

Though I have explained them the whole sequence, and I am always available for 
them if they have any doubts, but still it would be great if we can update that.

Regards
Bhavya
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo embedding story & killing mozbrowser

[Myk Melez]

Till Schneidereit 
2016 November 17 at 09:22

Our focus is on creating a unified developer experience for Servo 
embedding. With the core embedding API targeting Rust, we're looking 
into building a lightweight runtime that seamlessly ties into the Rust 
ecosystem.
Ah, that makes sense. Do you have particular use cases in mind for this 
runtime?


In particular, I'm working on a Tokio[1]-based runtime that allows 
mixing of JS and Rust modules.

Interesting, any links to work in progress?

Irrespective of how that experiment turns out, SpiderNode might be 
very valuable for us. Clearly the NPM ecosystem contains a wealth of 
functionality; tapping into that would be great. It might be possible 
to do this without running the core runtime in a libuv event loop.

Right, although emulating or reimplementing libuv seems like a lot of work.

We spent some time emulating Node modules for the renderer process in 
Positron, which was doable, since Electron apps like Tofino tend to 
avoid using much Node in that process. But they do use a lot of Node in 
the main process, and we ended up running the libuv event loop there 
(via SpiderNode).


In general I'm very interested in seeing how our groups could 
collaborate. For example, we should ensure that Paul's embedding API 
is strictly more expressive than a more generic API. One way to ensure 
this would be to collaborate on an adapter layer implementing your API 
on Paul's. I'd see it as a bug in our API if that's not possible.
That'd be very helpful, although we haven't yet designed this API, so we 
can't give too much guidance at this stage.


(Though it doesn't necessarily need to be trivial - this wouldn't be 
an everyday undertaking after all.)
Indeed. It's ok if it's hard. I only want to avoid unnecessary 
duplication of effort.


And we should sync up periodically so we don't needlessly duplicate 
effort - I propose we start that with a meeting at the All Hands.

That sounds like a great plan. I'll find you there and arrange it!

-myk

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

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

[Eddy Bruel]

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