This repository was archived by the owner on Jul 23, 2019. It is now read-only.
Conversation
618b4d5 to
d895c1a
Compare
Co-Authored-By: Nathan Sobo <nathan@github.com>
Co-Authored-By: Nathan Sobo <nathan@github.com>
This commit rearranges things a bit. We have a single Channel concept with a sender and receiver that can be constructed from the JS side. In addition, I introduce a JsSink concept, which can be constructed from JS and implements the Sink trait on the Rust side. This allows Rust functions to accept a Sink from JS and send the output of an arbitrary stream to it. From the JS side we can handle the `send` and `close` methods on the Sink trait with our own JS callbacks. This commit also adjusts the executor to avoided repeated allocations of a NotifyHandle Arc. We just allocate one Arc<NotifyHandle> per executor now.
This makes room for adding a websocket listener.
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Serializing PathBuf on a machine and deserializing it on a machine witha different operating system is unsupported because of the way each OS encodes its paths. With this commit we are introducing the cross_platform module, which exposes a basic Path and PathComponent structs that are able to encode OS-specific paths into a single data type. This type is then used in fs::Entry and other call sites to speak about paths in a platform-agnostic way. Theoretically, after this commit, the only call sites that don't use cross_platform::Path are those ones that are platform-dependent (e.g., LocalProject::resolve_path) or where platform doesn't matter (e.g., PathSearchResult::display_path). Note also that we are only currently dealing with Unix paths, but this abstraction should allow to handle Windows paths quite easily.
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
We can open the file finder, but we panic when we confirm a selection. Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
If polling a response *caused* a service to be created or destroyed, wewant to include that fact as part of the same update so we can reliablytake the created service on the client.
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
Co-Authored-By: Jason Rudolph <jason@jasonrudolph.com>
added 13 commits
April 26, 2018 22:31
Running `npm install` keeps on breaking and this is the only way to fix it. Frustrating.
It saves a bit of space but complicates the Travis build too much for the being.
I can't find a way to effectively test the new context API yet with enzyme, so we should just stick with the older version.
These random classes are impossible to write assertions against.
added 3 commits
April 26, 2018 22:49
This seems to ensure that we copy any changes from the ../xray_ui relative dependency.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds new subdirectories at the top level of the repo:
xray_browserContains a WebPack configuration and a minimal entry point that packages Xray to be rendered in a web browser. It also contains a simple development web server that proxies web socket connections to a listening instance ofxray_server.xray_wasmA web-compatible counterpart toxray_server, which is the Rust core of Xray compiled to WebAssembly. It is designed to be run byxray_browserin a WebWorker, and can be thought of as an in-browser server.xray_uiXray's common user interface elements extracted fromxray_electronto be shared betwenxray_electronandxray_browser.To do before merging: