On Wed, Dec 27, 2017 at 2:23 PM, Emilio Cobos Álvarez
wrote:
> What's the point of disabling it at compile time instead of at runtime?
>
> Supporting different build configurations is more painful than a runtime
> check, requires more work, and breaks more easily / often.
>
For what it's worth,
On Fri, Oct 20, 2017 at 7:45 PM, Simon Sapin wrote:
> However the cafile parameter of urllib2.urlopen() is new in 2.7.9 and I
> don’t know how to feature-test that without making a call and catching some
> exceptions, but that seems fragile. We’re not using the ssl module directly.
>
Could try s
On Tue, Sep 27, 2016 at 3:13 AM, Lars Bergstrom wrote:
>> As a spare time outside contributor, it has become pretty much
>> impossible for me to stay informed of what's happening in Servo land,
>> since the meetings (and thus the meeting notes) have been cancelled;
>> while few things are going ov
On Mon, Sep 12, 2016 at 1:45 PM, Eddy Bruel wrote:
> 3. I found another websocket library for Rust, called "ws". Unlike
> rust-websocket, ws seems to have a proper shutdown story (one can call a
> shutdown() method on a Sender, which can be cloned between threads). It
> also seems to be a bit more
On Mon, Sep 12, 2016 at 1:14 PM, Eddy Bruel wrote:
> The way I see it, we have two options. Personally, I'm leaning towards
> option two, but I wanted to get your opinion:
>
> 1. Ignore the problem for now. Most debugger clients for the Chrome
> Debugging Protocol can attach to a WebSocket URL dir
On Wed, Sep 7, 2016 at 12:41 AM, Diane Hosfelt wrote:
> I 100% understand the desire to use a pure Rust TLS library for Servo, but
> I think we need to not ignore the fact that there isn't one right now. Ring
> implements the crypto primitives, not the protocols. Rustls is promising,
> but it's br
On Thu, Sep 1, 2016 at 10:43 PM, Jack Moffitt wrote:
> One reason I would like to see the NSS bindings is that other projects
> in the Rust ecosystem may need more confidence in the crypto bits or
> functionality not yet implemented. Not every project in Rust is as
> pre-production as Servo. NSS b
Hi Diane,
Thank you for bringing this discussion into the open.
On Fri, Aug 26, 2016 at 2:13 AM, Diane Hosfelt wrote:
> This is our current solution. While trying to distribute nightlies, the
> team discovered that the Rust bindings for OpenSSL need some work1.
> Additionally, many projects are
On Thu, Jun 2, 2016 at 11:20 AM, Manish Goregaokar
wrote:
> It seems like it's still checking the git repo for the feature. Might be
> worth landing your devices changes and proceeding from there.
I've filed a Cargo bug:
https://github.com/rust-lang/cargo/issues/2762
And created a devices PR:
On Wed, Jun 1, 2016 at 10:53 AM, Manish Goregaokar
wrote:
> It should be net/device/bluetooth. For some reason the crate is imported as
> "device" instead of "devices" in net
I'm somehow still running into trouble. Can someone spot the mistake?
djc@dochtman-dev servo $ cat ~/.cargo/config
paths
On Tue, May 31, 2016 at 4:51 PM, Simon Sapin wrote:
>> It is possible currently to do `cargo build --features
>> net/devices/nameoffeature` without polluting cargo.tomls,
>
> I think we can have something like this in components/servo/Cargo.toml :
>
> [features]
> no-bluetooth = ["net/devi
Hi all,
I'm investigating building a Servo-based headless browser (i.e. get
input events through the network, send PNGs out to the network).
Ideally, I'd like to get it to work on CentOS 6-based servers. Trying
to build server on one of these machines, I quickly ran into a problem
with the dbus cr
12 matches
Mail list logo
