profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ErwanDL/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Erwan de Lépinau ErwanDL @streamroot Paris Code is cool

ErwanDL/music-genre-classification 3

Automatic Music Genre Classification using Machine Learning

ErwanDL/cpp-raytracer 2

Implementation of a raytracing renderer in C++

ErwanDL/YATDA 2

Yet Another To-Do App

DeciusAntiochus/ad-covia 1

Ce projet a pour but d'établir des autodiagnostics du Covid-19 par intelligence artificielle.

ErwanDL/hls-relay 1

HLS (HTTP Live Streaming) relay server

Salto-Alto/vuourt 1

An application that allows you to easily sue your friends !

ErwanDL/aiohttp 0

Asynchronous HTTP client/server framework for asyncio and Python

ErwanDL/aoc2019 0

My solutions for the 2019 Advent of Code

ErwanDL/aoc2020 0

My solutions for the 2020 Advent of Code

ErwanDL/chai 0

Sequence-to-Sequence Learning for End-to-End Program Repair. Open-science repo.

issue commentrouterify/routerify

Websocket crate incompatible with version 2

Sounds good, I will update the docs to refer to hyper-tungstenite and create a PR then.

Oh okay, I had not understood that the idea was to remove completely the query middleware and just put its functionality in RequestExt/PartsExt, but that sounds like a good idea. I'll work on this as well, I guess I'll create a PR this weekend or next week.

mrene

comment created time in 11 days

issue commentrouterify/routerify

Websocket crate incompatible with version 2

Hello @rousan @gsserge @seanpianka, are these two topics (one being moving routerify-query in the routerify repo and making it available via a feature flag, the other being deprecating routerify-websocket in favor of hyper-tungstenite) still on the agenda ? I am willing to help with these and create PRs.

I had started working on porting routerify-websocket to version 2 here https://github.com/routerify/routerify-websocket/pull/4, but seeing the discussion here about sunsetting the project I now understand why it did not raise much interest. I was thinking of updating the README/docs and maybe (it may not even be necessary, if hyper-tungstenite really is easy to work with) adding an example using hyper-tungstenite, so that users of routerify v2 are not mislead into using routerify-websocket anymore, what do you think ?

mrene

comment created time in 11 days

PR opened routerify/routerify

Remove X-POWERED-BY header

This removes the X-POWERED-BY header middleware altogether, as discussed in https://github.com/routerify/routerify/issues/90, mainly for improved security.

+1 -22

0 comment

3 changed files

pr created time in 14 days

push eventErwanDL/routerify

Sergey Glushchenko

commit sha cef06513233daabc11c4ed5b2cfaa7c5772dd492

Merge branch 'release/v2.1.0' into develop

view details

Erwan de Lépinau

commit sha ca826226c7c35e644495077c3e37ff9c9121536d

remove X-POWERED-BY header middleware

view details

push time in 14 days

create barnchErwanDL/routerify

branch : remove-x-powered-by

created branch time in 14 days

fork ErwanDL/routerify

A lightweight, idiomatic, composable and modular router implementation with middleware support for the Rust HTTP library hyper.rs

https://docs.rs/routerify

fork in 14 days

pull request commentrouterify/stream-body

Add appropriate tokio features to Cargo.toml

@gsserge I agree, that PR was just really a temporary fix while I was working on updating to tokio v1. However, I have tried to do the update to tokio v1 on this branch, but I am somewhat stuck at the moment as async-pipe's API has changed, due to tokio's AsyncRead's API changing in v1 (prepare_uninitialized_buffer has disappeared). Given that I'm not too familiar with stream-body's code, I'm having a hard time figuring out the correct fix to accomodate these changes 😕

ErwanDL

comment created time in 19 days

issue commentmicrosoft/vscode-python

Add Profiling (code performance analysis) capability

@luabud Would you guys be interested in a Proof-of-concept work ? I can't guarantee that I can do it in the very near future, but if that is something that would help the team refine the scope or have an idea of what the feature could look like, it's something I would consider !

ErwanDL

comment created time in a month

issue commentrouterify/routerify-cors

Release 2.0 to crates.io

That's so cool ! Thanks @gsserge and @rousan. BTW, I started some work to update routerify-websocket to v2.0 here (https://github.com/routerify/routerify-websocket/pull/4), but was stuck because stream-body isn't 2.0-compatible yet (causing one example to fail).

ErwanDL

comment created time in a month

issue commentrouterify/routerify-cors

Release 2.0 to crates.io

Hello @rousan, is this doable in the near future ? The work on getting this project to 2.0 seems to have already been done, it would be a shame to not publish it :(

ErwanDL

comment created time in a month

push eventErwanDL/routerify-websocket

Rousan Ali

commit sha cedd142da3b2590a4ead353953f57ecd9d1cbd4e

Merge branch 'release/v1.0.0' into develop

view details

Erwan de Lépinau

commit sha 348ff5605757b7264975c121d3b392aea8744e31

upgrade to toko 1/hyper 0.14, stream-body must be upgraded

view details

push time in a month

PR opened routerify/routerify-websocket

Update Tokio to 1.x, hyper to 0.14

This is the PR associated with #3. The main issue left is that stream-body needs to be updated as well (I am doing some work on this in https://github.com/ErwanDL/stream-body/tree/update-dependencies/src, but first we will need https://github.com/routerify/async-pipe-rs/pull/8 to be merged and deployed), or we should remove the stream-body example, which will not compile as is. Which solution is best according to you ?

+27 -28

0 comment

6 changed files

pr created time in a month

push eventErwanDL/stream-body

Erwan de Lépinau

commit sha 5fe18dd8ecc3e7de9d7d200700fd67d37f17712c

WIP updating to tokio 1.0

view details

push time in a month

push eventErwanDL/routerify-websocket

Erwan de Lépinau

commit sha 89b26cab20f13404ac8bdb72e1158b787faa37fa

upgrade to toko 1/hyper 0.14, stream-body must be upgraded

view details

push time in a month

startedrouterify/routerify

started time in a month

issue commenthyperium/hyper

`Graceful` struct is not accessible

I've experimented a bit with generics in place of Graceful, and it is not terribly satisfying. In my use case, I need to store the server instance in a struct (called Runtime in this example), along with other objects and metadata. Here is the problem when I try to use generics:

#[tokio::main]
async fn main() {
    let runtime = Runtime::new(); // ERROR: type inside `async` block must be known in this context. cannot infer type for type parameter `T`.
    let graceful = runtime.graceful_server;
    println!("Server running on localhost:{}", runtime.addr);

    match graceful.await {
        Ok(()) => println!("Gracefully shutting down."),
        Err(e) => println!("Server error: {}", e),
    }
}

pub struct Runtime<T: Future<Output = hyper::Result<()>>> {
    pub graceful_server: T,
    pub addr: SocketAddr,
}

impl<T: Future<Output = hyper::Result<()>>> Runtime<T> {
    pub fn new() -> Runtime<impl Future<Output = hyper::Result<()>>> {
        let addr = SocketAddr::from(([127, 0, 0, 1], 0));
        let make_svc = make_service_fn(|_conn| async { Ok::<_, Infallible>(service_fn(handle)) });
        let server = Server::bind(&addr).serve(make_svc);
        let addr = server.local_addr();

        let graceful = server.with_graceful_shutdown(shutdown_signal());

        Runtime {
            graceful_server: graceful,
            addr,
        }
    }
}

Rust cannot infer the type of T at the call site, thus cannot properly monomorphize the Runtime::new function. This could be solved if we were able to specify the type using Runtime::<Graceful>::new(), but Graceful being private disallows this.

There are two possible workarounds:

  • Store the graceful as a Box<dyn Future<Output = hyper::Result<()>>>, removing the need for a generic, but complexifying the typing (if you are multithreading, you even need to change the type to Pin<Box<dyn Future<Output = hyper::Result<()>> + Send>>), and losing static dispatch.
pub struct Runtime {
    pub graceful_server: Pin<Box<dyn Future<Output = hyper::Result<()>> + Send>>,
    pub addr: SocketAddr,
}

impl Runtime {
    pub fn new() -> Runtime {
        let addr = SocketAddr::from(([127, 0, 0, 1], 0));
        let make_svc = make_service_fn(|_conn| async { Ok::<_, Infallible>(service_fn(handle)) });
        let server = Server::bind(&addr).serve(make_svc);
        let addr = server.local_addr();

        let graceful = server.with_graceful_shutdown(shutdown_signal());

        Runtime {
            graceful_server: Box::pin(graceful),
            addr,
        }
    }
}
  • Moving the factory function out of the impl block, but that changes the interface of my code:
pub struct Runtime<T: Future<Output = hyper::Result<()>>> {
    pub graceful_server: T,
    pub addr: SocketAddr,
}

pub fn new_runtime() -> Runtime<impl Future<Output = hyper::Result<()>>> {
    let addr = SocketAddr::from(([127, 0, 0, 1], 0));
    let make_svc = make_service_fn(|_conn| async { Ok::<_, Infallible>(service_fn(handle)) });
    let server = Server::bind(&addr).serve(make_svc);
    let addr = server.local_addr();

    let graceful = server.with_graceful_shutdown(shutdown_signal());

    Runtime {
        graceful_server: graceful,
        addr,
    }
}

Both of these options technically work, but feel like ugly hacks to circumvent the fact that Graceful is private. I don't doubt there must be good reasons to this, but I would love if you could elaborate a bit more on that choice ?

ErwanDL

comment created time in a month

issue commenthyperium/hyper

`Graceful` struct is not accessible

Thank you for the answer. I am curious as to what the reasoning behind that choice is, what are the reasons to keep the type private if its instances are publicly accessible ? I am under the impression that many Rust users, like me, are disconcerted by such a pattern (https://www.reddit.com/r/rust/comments/g6pkxn/private_types_in_public_interface/, https://internals.rust-lang.org/t/private-struct-returned-by-public-fn/8448), and some even think this should be considered a bug by the compiler.

This is my use case (simplified), in which I need to access information of the underlying Server object, for example the local address:

fn create_server() -> Graceful {
    // binding to port 0 lets the OS find a random unused port for me,
    // which I can then only retrieve using `server.local_addr()`
    let server = Server::bind(SocketAddr::from(([127, 0, 0, 1], 0))).serve(make_svc);
   
    // other setup stuff

    // this consumes server
    let graceful = server.with_graceful_shutdown(shutdown_signal());
    graceful
}


#[tokio::main]
async fn main() {
    let graceful = create_server();    

    // This doesn't compile, but I need to retrieve the port the server is running on,
    // which is why I would like to be able to do something along those lines
    println!("Server is running on {}", graceful.server.local_addr());

    if let Err(e) = graceful.await {
        eprintln!("server error: {}", e);
    }
}

I know I could theoretically extract the local address before creating the Graceful, and return it alongside the Graceful object, but it sounds convoluted. Is there a better way ?

ErwanDL

comment created time in a month

issue openedhyperium/hyper

`Graceful` struct is not accessible

Hello, I believe I have found a bug/inconsistency between the Server::with_graceful_shutdown function and the Graceful struct : the former is exposed as part of the public API, and returns a Graceful object, although the latter is not publicly accessible (as it is part of the shutdown private module).

This causes problems when trying to use the graceful shutdown capabilities and passing a Graceful object across functions, as an argument or return value of type Graceful in a custom function cannot be properly typed.

created time in a month

issue openedclap-rs/clap

`cargo test` flags should not result in an error for integration tests

Please complete the following tasks

  • [X] I have searched the discussions
  • [X] I have searched the existing issues

Rust Version

1.52.1

Clap Version

2.33.3

Minimal reproducible code

Have any integration test (those in the tests/ folder, as opposed to regular tests in src/) that uses clap, for instance by accessing options parsed by structopt.

Steps to reproduce the bug with the above code

Run the test suite with additional flags, for example --nocapture so that all tests output their logs :

cargo test -- --nocapture

Actual Behaviour

Unit tests will run as expected, but integration tests fail to run, as clap (called by structopt) errors out because it tries to parse the --nocapture flag:

error: Found argument '--nocapture' which wasn't expected, or isn't valid in this context

Expected Behaviour

clap should try and treat integration tests as regular unit tests, which do not exhibit the same behaviour, and continue executing normally when passed --nocapture.

Additional Context

No response

Debug Output

No response

created time in 2 months

issue openedhyperium/hyper

Manually creating Upgraded for testing purposes

Hello, does the current upgrade API allow for manually creating an Upgraded object by any means ? I am trying to test a Websocket application using tokio-tungstenite + hyper, and can't seem to find a way to create an Upgraded object from a Request without having to spin up a full-fledged Hyper server (which is very cumbersome for unit testing).

Here is my attempt (which panics because the upgrade::on(req) call returns a NoUpgrade error):

async fn create_ws() -> WebSocketStream<Upgraded> {
    let req = Request::builder()
        .header(header::UPGRADE, "websocket")
        .header(header::CONNECTION, "upgrade")
        .header(header::SEC_WEBSOCKET_VERSION, "13")
        .header(header::SEC_WEBSOCKET_KEY, "dGhlIHNhbXBsZSBub25jZQ==")
        .body(Body::empty())
        .unwrap();

    let ws = WebSocketStream::from_raw_socket(
        upgrade::on(req).await.unwrap(),
        protocol::Role::Server,
        None,
    ).await;
    ws
}

What is the recommended approach to doing this ?

PS: Thank you for the great work on hyper.

created time in 2 months

push eventErwanDL/stream-body

Erwan de Lépinau

commit sha 2fd607bea2c16b781770cd785f4f0eba7be24abe

Add proper tokio features to Cargo.toml "rt-core" is required by `tokio::spawn`, "io-util" is required by `tokio::io::copy`

view details

push time in 2 months

fork ErwanDL/stream-body

An HttpBody implementation with efficient streaming support for the Rust HTTP library hyper

fork in 2 months

issue openedrouterify/routerify-query

Release 2.0 version to crates.io

Hello @rousan, I see that this crate has been updated to version 2.0 (to work with routerify v2), but it seems like that version has not been published to crates.io yet. Would it be possible to publish that update, so that we don't have to rely on a git ref to use version 2 of routerify-query ? Thank you.

created time in 2 months

create barnchErwanDL/routerify-websocket

branch : update-deps

created branch time in 2 months

fork ErwanDL/routerify-websocket

The WebSocket support for the Routerify library

fork in 2 months

issue commentrouterify/routerify-websocket

Updating to latest hyper/tokio versions

Sounds good, I will start working on it this week. I also have a somewhat unrelated question : is there a way to access State from a websocket handler (like we would with a regular handler by doing req.data::<State>()) ? And similarly, is there a way to access additional metadata (additional headers, authentication token, query params...) that the client may have passed in the handshake request ?

I haven't found a way to do that yet, but if the handler function provided to upgrade_ws could accept a second argument of type Request, both of these could be solved. Do you think this would be technically doable ? If so, can you point me to what changes would be required, and I could also try to help with that ?

ErwanDL

comment created time in 2 months

issue openedrouterify/routerify-websocket

Updating to latest hyper/tokio versions

Hello @rousan, I am planning to use this plugin for a production Hyper-based websocket application. Would you be interested in help updating the plugin to use the latest hyper (0.14) and tokio (1.x) versions, and ensuring the best compatibility with routerify 2.1 ? I could help with a PR if you're interested.

created time in 2 months

issue commentSergioBenitez/Rocket

Upgrading connection to WebSocket (perhaps using underlying hyper::Request ?)

Thank you for the answer. I'll be watching closely the evolution of the implementation on #1639. Unfortunately I cannot use SSE as this is an in-production project which already uses Websockets. I think I will stick with a Hyper-only solution for now, but I am looking forward to see this being released in Rocket. Keep up the great work !

ErwanDL

comment created time in 2 months

issue openedSergioBenitez/Rocket

Upgrading connection to WebSocket (perhaps using underlying hyper::Request ?)

Hello, and first of all thank you for the great work on Rocket.

I've been following the discussion about native support for WebSockets on #90, and as far as I understood support for WebSockets has not been integrated into the Rocket API yet (I'm using v0.5-rc1). Is there any "hack" or manual solution that you know of for upgrading an opening handshake to an actual WebSocket connection in Rocket ?

While looking for a solution, I noticed that hyper supports upgrading an HTTP connection via the hyper::upgrade API (in hyper v0.14, this is done using the upgrade::on function). But in order to use that API, I believe I need access to a hyper::Request object to call upgrade::on() on. Is there any way to access the underlying hyper::Request object in a Rocket handler, or to convert a rocket::Request to a hyper::Request by any means ?

created time in 2 months

create barnchErwanDL/oxide

branch : master

created branch time in 2 months