profile
viewpoint

linebender/druid 2787

A data-first Rust-native UI design toolkit.

rustwasm/gloo 755

A modular toolkit for building fast, reliable Web applications and libraries with Rust and Wasm

linebender/piet 517

An abstraction for 2D graphics.

clux/kube-rs 471

kubernetes client and futures controller runtime

robmikh/minesweeper-rs 420

A port of robmikh/Minesweeper using winrt-rs.

http-rs/async-h1 121

Asynchronous HTTP/1.1 in Rust

peterhuene/azure-functions-rs 117

Create Azure Functions with Rust!

http-rs/http-types 104

Common types for HTTP operations

JeremyLikness/blazor-wasm 73

Blazor and WebAssembly examples (part of a Blazor presentation)

rust-secure-code/mem-markers 20

Rust library for marker traits about types layout in memory

push eventrobmikh/minesweeper-rs

robmikh

commit sha 6124e707b80bb4e44d9d4acd4effd92befbb1898

run cargo fmt

view details

push time in an hour

create barnchAzure/azure-sdk-for-rust

branch : queue_methods

created branch time in 3 hours

pull request commentclux/kube-rs

Make TypeMeta impl Debug + Eq + Hash

Yeah, probably smart to have :-)

teozkr

comment created time in 10 hours

push eventclux/kube-rs

Teo Klestrup Röijezon

commit sha 0a5ee10f07f84cf59260b449e00026eb02e2d22f

Make TypeMeta impl Debug

view details

Teo Klestrup Röijezon

commit sha 89548ae2f8e9d0a522da407aeb3f4031bd2b2f1f

Also impl Eq and Hash for TypeMeta

view details

Eirik A

commit sha f49fcc4b64ca53091efe15f570e38c6ab3789567

Merge pull request #344 from teozkr/feature/typemeta-debug Make TypeMeta impl Debug + Eq + Hash

view details

push time in 10 hours

PR merged clux/kube-rs

Make TypeMeta impl Debug + Eq + Hash
+1 -1

0 comment

1 changed file

teozkr

pr closed time in 10 hours

issue commentAzure/azure-sdk-for-rust

crates release and misleading readme

Hi @MindFlavor thanks for the detailed response.

I suggest for the time being to update the readme, I find it still often is not commonly known how to reference a git repo directly without using crates. And also giving this disclaimer you just gave.

I prefer regular updates - more agile, if you will - as long as the lib is not called 1.0. To be honest I would even consider already starting where this lib is at right now with some 0.1 release on crates, cause it makes much simpler for people to work with. If I want to not get any breaking change I can pin to a specific release and the git-ref is still there as a fallback.

My current project is actually building upon this lib to access azure blob storage in production in the coming weeks and I would like to migrate to this repo as soon as possible.

extrawurst

comment created time in 12 hours

issue commentAzure/azure-sdk-for-rust

crates release and misleading readme

Hi extrawurst, sorry for the confusion. The release crates refer to the old, archived, repo (and no longer maintained as you have noticed). All the development currently happens here.

This repo is still in the "incubation" phase. We are deciding the final approach for request builders, http clients, etc... and we do not yet have a release schedule.

For the time being I suggest you to reference the repo directly. I'll leave the issue open to update you on this topic.

By the way, would you prefer a rigorous release schedule or a more relaxed one (and possibly more agile)?

extrawurst

comment created time in 13 hours

PR opened clux/kube-rs

Reviewers
Make TypeMeta impl Debug
+1 -1

0 comment

1 changed file

pr created time in 13 hours

startedrylev/DMG-01

started time in 14 hours

push eventAzure/azure-sdk-for-rust

Ryan Levick

commit sha 85e37c2a3765af88873ed9cbd7ac072e920a6127

Dedicated resources module (#99) * Clean up authorization token * Clean up permission token * Clean up Permission * Move to dedicated permissions module * Fix e2e test compilation * Run e2e tests * Make PermissionMode easier to use correctly * Fix actions config * Move resources into dedicated module * Cleanup prelude * Small cleanup * More clean up of lib.rs

view details

push time in 17 hours

PR merged Azure/azure-sdk-for-rust

Dedicated resources module

This PR moves all Cosmos resources (e.g., Users, Documents, Databases, etc.) into their own module. This makes some imports a bit longer, but we'll clean that up in the next PR.

+343 -538

0 comment

89 changed files

rylev

pr closed time in 17 hours

push eventAzure/azure-sdk-for-rust

Christian Schaible

commit sha a87b682f525319e1a106520c25594cbdd199d4b9

Expose azurite_workaround feature in storage crate and use endpoint URIs from connection string in storage KeyClient (#101) * Expose azurite_workaround feature in storage crate The azurite storage emulator requires specific configurations that are already available in the source code of the storage crate. The feature is not exposed, to be used though. * Use endpoint URIs from connection string in storage KeyClient Endpoint URIs can be specified in the storage connection string. Currently they are ignored and replaced with hard-coded default values pointing to the azure blob storage. This is relevant when using the azurite storage emulator, where the account names can be modified (since version 3). The "with_emulator" method with hard coded value is no longer sufficient if account names are customized.

view details

push time in 17 hours

PR merged Azure/azure-sdk-for-rust

Expose azurite_workaround feature in storage crate and use endpoint URIs from connection string in storage KeyClient

This PR exposes the azurite_workaround feature and recognizes enpoint URIs from the storage connection string.

The azurite storage emulator requires specific configurations that are already available in the source code of the storage crate. The feature is not exposed, to be used though.

Endpoint URIs can be specified in the storage connection string. Currently they are ignored and replaced with hard-coded default values pointing to the azure blob storage. This is relevant when using the azurite storage emulator, where the account names can be modified (since version 3). The "with_emulator" method with hard coded value is no longer sufficient if account names are customized.

+32 -12

1 comment

2 changed files

cschaible

pr closed time in 17 hours

startedrylev/rust-workshop

started time in a day

delete branch http-rs/async-h1

delete branch : new-encoder

delete time in a day

push eventhttp-rs/async-h1

Jacob Rothstein

commit sha 32b8bea1311ba1720d08576b54a8fee6fdd63116

new encoder for both client and server

view details

Jacob Rothstein

commit sha 4b6cef5c74400f3e7c20821305dde52b5290f933

use 128 bytes

view details

Jacob Rothstein

commit sha 66c84273fd9224df4da81c876973e46628cf7d02

also use a guess of 128 bytes on the server

view details

Jacob Rothstein

commit sha 0678bedfc3383b2db0a0f16cbe19dc0205c842a9

🤫

view details

Jacob Rothstein

commit sha 356847b2f3bd7d69c337dd81a7a02ca1f8e6a9c5

📎 thanks clippy 🖇

view details

Jacob Rothstein

commit sha ed6f181d9845f411579a6190089c66a99813bc0b

remove accidental double-mut

view details

Jacob Rothstein

commit sha f6a65281336569a3f458a04273f83acb68926957

Incorporate feedback from review Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>

view details

Jacob Rothstein

commit sha cdea35513d2240e88cc56d35846fc31a7ead4d5e

add a test for the critical function `max_bytes_to_read`

view details

Jacob Rothstein

commit sha 95385df32c79a4471632f9a60a997a423d7612ba

small docs update and some code golf

view details

Jacob Rothstein

commit sha 66b887df9df768f3a335956e8ea149e54eac0b10

move the Read impl higher, it's the most important thing

view details

push time in a day

PR merged http-rs/async-h1

new encoder for client and server

this is based on #157. the changes in this pr are d80934dc2d62d1729505c88febc6a55b7cb376fa

+317 -592

0 comment

12 changed files

jbr

pr closed time in a day

pull request commentAzure/azure-sdk-for-rust

Expose azurite_workaround feature in storage crate and use endpoint URIs from connection string in storage KeyClient

CLA assistant check <br/>Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.<br/><br/>:x: cschaible sign now<br/><sub>You have signed the CLA already but the status is still pending? Let us recheck it.</sub>

cschaible

comment created time in a day

PR opened Azure/azure-sdk-for-rust

Expose azurite_workaround feature in storage crate and use endpoint URIs from connection string in storage KeyClient

This PR exposes the azurite_workaround feature and recognizes enpoint URIs from the storage connection string.

The azurite storage emulator requires specific configurations that are already available in the source code of the storage crate. The feature is not exposed, to be used though.

Endpoint URIs can be specified in the storage connection string. Currently they are ignored and replaced with hard-coded default values pointing to the azure blob storage. This is relevant when using the azurite storage emulator, where the account names can be modified (since version 3). The "with_emulator" method with hard coded value is no longer sufficient if account names are customized.

+32 -12

0 comment

2 changed files

pr created time in a day

startedrylev/rust-workshop

started time in a day

pull request commenthttp-rs/http-types

Add `range` submodule

Hi @yoshuawuyts thank you very much for your review. I am pretty much in line globally.

Assume the RangeUnit is always bytes?

The RFC states that RangeUnits can be expected to be expanded in the future through RFC. Though in the past 6 years this has not happened, which makes it questionable to which degree we need to consider this. We could make the assumption that the only two types that may ever be sent are "none" and bytes.

I initially worked on a version with a RangeUnit enum, like the one you mentioned, opening the door to other range units if the RFC evolves in the future. But I realized that this is a lot of boilerplate for every day use since only bytes unite are used today in practice. So I went for a compromise with this Byte prefix thing which is not very much satisfying at the end, I agree.

Instead I would like to suggest switching it around: create a RangeUnits enum which is tagged #[non_exhaustive] and None and Bytes members, and then have Range , ContentRange, and AcceptRanges headers. This will allow us to add more range types in the future without breaking anything.

I would go for that design too, but I am not sure about having None as an enum variant: None is not a range unit type. It is a possible value for the AcceptRanges header to notify that range requests are not accepted, but it is not used otherwise for Range and ContentRange headers. We could have AcceptRanges::from_headers return Ok(None) if the Accept-Range header has the none value, without any impact client side.

However, by removing None from the enum we would have only one variant which looks strange too.

A third option would be something like:

enum RangeUnit {
    Bytes
    Other(String)
}

This allows for usage of non standard units, but not great either.

If we go for the RangeUnit design we will need to handle it with the Range and ContentRange headers too. Those type do not only returns a range unit but also a range set (ByteRanges in my current implementation) and a single Range. At the end I do not see how we can avoid several if let and match code for the end user using only bytes unit in practice. Do you have something in mind that could help here ?

suffix-length

I was reading about ranges on mdn and I'm confused about how the suffixes are exposed in our API? Do you have a good sense of how they work, and how we could implement them?

You can see them as relative seek from either start or end. So far I do not provide further helper over it, I am just exposing them with an optional value. In Tide we will have to match over them to either SeekFrom::Start or SeekFrom::End. We can extend the type with further helper functions if need be without a breaking change I believe.

Conclusion

Despite having feedback on some of the design, I think we're very well on our way to getting where we need to be! — I'm incredibly excited for this work, and how it'll enable us to implement http-rs/tide#687. Thanks so much for your work on this!

Thank you for your great feedback. This leaves us with the following choices:

  1. We provide implementation for bytes unit only, and we fully assume a breaking change will probably need to be introduced if a new unit is added to the RFC. This is a limited risk at the benefit of simple code covering 100% of usage for the last 6 years.
  2. We go for a RangeUnit enum #[non_exhaustive], at the benefit of allowing a source compatible introduction of a new unit, but at the risk to "complexify" the API for every day use.

Not an easy decision. A little daemon on my left shoulder says "come on, take the challenge and go with those damn enums, you are a rustacean or not ?", a little angel on my right shoulder says "come on, you know this is over-engineering, right ?"

Do you want me to have a try with the RangeUnit enum design to see how it goes, or you want to listen to the little angel ? In the latter case I will rename ByteRanges to Range and ByteRange to RangeItem (or any better name you might have), and simplify the API to handle bytes only.

What do you think ?

After this we need to talk about this comment which could impact the design of the If-Range header. But one discussion at a time :)

ririsoft

comment created time in a day

startedrusty-bits/OC-tool

started time in a day

issue openedmicrosoft/winrt-rs

Failure to build a project using winrt-rs in a workspace

Example repo: https://github.com/Enigmatrix/winrt_workspace_test

Building the above repo gives an error when importing any type. e.g. in the case above, image

created time in 2 days

issue commentclux/kube-rs

My cluster isn't trusted

Hello, also running into this issue while making a reqwest blocking call to several websites. I'm a relatively new rust user (4 months). Working on a bot that completes purchases on several websites. I'm getting this error when I make the request: Screen Shot 2020-11-28 at 12 25 15 AM I am working on MacOS Big Sur. I wrote my code first in python and now I'm rewriting in rust. My reqwest calls work perfectly in python, but I'm having problems in Rust. Any pointers?

garyanaplan

comment created time in 2 days

pull request commenthttp-rs/http-types

Several missing MIME type extension detections

@richardanaya default not-found handling is a known issue with serve_dir. until we add a way to configure serve_dir, you probably want something like:

#[async_std::main]
async fn main() -> Result<(), std::io::Error> {
    tide::log::start();
    let mut app = tide::new();

    app.with(tide::utils::After(|response: tide::Response| async move {
        if response.status() == tide::StatusCode::NotFound {
            Ok(tide::Response::builder(200)
                .body(tide::Body::from_file("./dist/index.html").await.unwrap())
                .build())
        } else {
            Ok(response)
        }
    }));

    app.at("/").serve_dir("./dist")?;

    app.listen("127.0.0.1:8080").await?;

    Ok(())
}
richardanaya

comment created time in 2 days

push eventmicrosoft/winrt-rs

Kenny Kerr

commit sha e99c8ec8b1a303127e57f3c017f1b9a6d53b4a6b

test

view details

push time in 2 days

push eventmicrosoft/winrt-rs

Kenny Kerr

commit sha 357e265b89134cdebb6fab9dc865ec043fb02419

test

view details

push time in 2 days

pull request commenthttp-rs/http-types

Several missing MIME type extension detections

@jbr thanks for your comments! I looked at serve_dir. I think part of me just didn't know this existed. The logic I was trying to implement fundamentally was:

  1. listen to all paths /*
  2. does this path exist realtive to a certain directory?
  3. if I didn't exist, how do I provide a fallback.

I see now how serve dir could handle 1 & 2

app.at("/*").serve_dir("dist/")?;

not yet sure about #3 :) my assumption is a fallback route exists somewhere though

richardanaya

comment created time in 2 days

push eventmicrosoft/winrt-rs

Kenny Kerr

commit sha 5ab0d458855865beacec451cba9e6e77194fd600

test

view details

push time in 2 days

push eventmicrosoft/winrt-rs

Kenny Kerr

commit sha f8e25ae91a5c8f09d9bdb53bdc6d1496ccf1aa08

factory

view details

push time in 2 days

more