Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce an inprocess feature #82

Merged
merged 3 commits into from Jul 8, 2016
Merged

Introduce an inprocess feature #82

merged 3 commits into from Jul 8, 2016

Conversation

@nox
Copy link
Member

nox commented Jun 29, 2016

No description provided.

This means we don't need to import all types by hand for each platform
in platform/mod.rs.
@nox nox force-pushed the nox:stabler branch 4 times, most recently from 2a63e9f to b02a91c Jun 29, 2016
@jdm
Copy link
Member

jdm commented Jun 29, 2016

Note that appveyor was introduced to build the in-process code, so please ensure that that continues to be the case.

nox added 2 commits Jun 29, 2016
This is used to enable the fake IPC implementation using inprocess channels.
The feature has to be manually enabled on platforms that aren't supported
by the crate, i.e. Windows and Android.
@nox nox force-pushed the nox:stabler branch from b02a91c to 4868e99 Jun 29, 2016
mod inprocess;
pub use self::os::{OsIpcChannel, OsIpcOneShotServer, OsIpcReceiver, OsIpcReceiverSet};
pub use self::os::{OsIpcSelectionResult, OsIpcSender, OsIpcSharedMemory};
pub use self::os::{OsOpaqueIpcChannel, channel};

This comment has been minimized.

@antrik

antrik Jun 29, 2016

Contributor

I guess that's a matter of taste -- but I strongly dislike the arbitrary split of the use statements... Is there any kind of style guide regarding this?

This comment has been minimized.

@nox

nox Jun 29, 2016

Author Member

That's just the exact same split as we use in Servo, keeping lines not too long and not doing multiline use statements.

This comment has been minimized.

@antrik

antrik Jun 29, 2016

Contributor

I'm not sure what's wrong with multiline use statements... But I can live with that I guess.

Still, I think it would be vastly preferable to group the types in some logical manner. As it is, it is (subjectively) confusing, and (objectively) a PITA if another entry ever needs to be added...

I guess that's bikeshedding though -- feel free to disregard :-)

This comment has been minimized.

@nox

nox Jun 29, 2016

Author Member

There is no "logical manner" that fits all of us, so we chose alphabetical order.

@metajack
Copy link

metajack commented Jul 6, 2016

@pcwalton
Copy link
Collaborator

pcwalton commented Jul 8, 2016

@bors-servo: r+

Nice! This is a great cleanup.

@bors-servo
Copy link
Contributor

bors-servo commented Jul 8, 2016

📌 Commit 4868e99 has been approved by pcwalton

@bors-servo
Copy link
Contributor

bors-servo commented Jul 8, 2016

Testing commit 4868e99 with merge 7a58bb0...

bors-servo added a commit that referenced this pull request Jul 8, 2016
Introduce an inprocess feature
@bors-servo
Copy link
Contributor

bors-servo commented Jul 8, 2016

☀️ Test successful - status-appveyor, travis

@bors-servo bors-servo merged commit 4868e99 into servo:master Jul 8, 2016
3 checks passed
3 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.