profile
viewpoint

imp/dnsmasq 94

Mirror of the upstream dnsmasq repository

imp/cargo-multi 5

Extends cargo to execute the given command on multiple crates - upstream is at

imp/chrono-humanize-rs 3

Human friendly time expressions. This is a mirror of the upstream, found at

imp/devmapper 2

Solaris device mapper

imp/cargo-info 1

Mirror of the gitlab cargo-info project. Please file issues here -

imp/dnsmasq-smf 1

Native Solaris smf(5) support for dnsmaq

imp/actix-web 0

Actix web is a small, pragmatic, and extremely fast rust web framework.

imp/artifact 0

the design doc tool made for developers

imp/atom-beautify 0

:lipstick: Beautification abstraction package for Atom editor

imp/attohttpc 0

Rust lightweight HTTP 1.1 client

push eventimp/inspector-rs

Cyril Plisko

commit sha adc8115f30ddc582aba11a86f50d9971a0a579ea

Enable more lints

view details

Cyril Plisko

commit sha b2b94193beb3293c69e7e1a9294560bfe7529c97

clippy::doc_markdown

view details

Cyril Plisko

commit sha 5380c1f762327b8b4f5d658e53913c0e309ee529

clippy::option_and_then_some

view details

Cyril Plisko

commit sha 93bb246d515f35bb2906392754e8cc870fd11216

Update justfile

view details

Cyril Plisko

commit sha 596575b396d3176958672097348432abe6f494cf

Rename feature futures to futures01

view details

Cyril Plisko

commit sha dd0fbfb098f149834854c98f228e1d28ecdc578c

Bump version to 0.1.0

view details

push time in 12 days

issue openedTeXitoi/structopt

external_subcommand triggers unused_braces lint

Taken verbatim from the example:

#[derive(Debug, StructOpt)]
enum Command {
    #[structopt(external_subcommand)]
    Other(Vec<String>),
}

upsets compiler (probably new lint)

  --> src/main.rs:81:15
   |
81 |     Other(Vec<String>),
   |               ^^^^^^ help: remove these braces
   |
note: the lint level is defined here
  --> src/main.rs:14:9
   |
14 | #![warn(unused)]
   |         ^^^^^^
   = note: `#[warn(unused_braces)]` implied by `#[warn(unused)]`

created time in a month

push eventruaze/ruaze

Cyril Plisko

commit sha 36e05e44b49516c6e58d09484d62e8cddfa3ec62

Top level Cargo.toml

view details

Cyril Plisko

commit sha e64bcd70005c6b8e6f8b98b3e1cd50a26ca059e4

Builder helper app

view details

push time in a month

push eventruaze/ruaze

Cyril Plisko

commit sha 965b43c274c3ff678e22b429075d80dc714b3e75

Disk API

view details

Cyril Plisko

commit sha 99f014d5504e93453fa39b96dc93fcbc2941ba71

Keep config files out of generated code

view details

Cyril Plisko

commit sha 538ad534410b087b73d1b310ab388605e2db3642

Update Azure specs

view details

Cyril Plisko

commit sha 66e18829a8a0c2992cde94c8d64bc495f18b70ea

Update config file location

view details

Cyril Plisko

commit sha 253ab899e978d557386a93ce770f4d7edfc41373

Another config for 'rust' backend

view details

Cyril Plisko

commit sha 4a244873c79ebe49220d3738049fb085696e818a

Update Azure specs

view details

push time in a month

issue commentOpenAPITools/openapi-generator

[Rust] Issues with client code generation.

Confirm it works now.

Although now all the *Params structures gained a (potentially) long prefix (the trait name is now added to all the structure names). Was that done due to there risk of the name conflict between different APIs? If so, perhaps it might be possible to keep the structures with simple names and rename them on use? Something like

[apis/mod.rs]

pub use self::disks_api::ListParams as DisksApiListParams;

instead of current

pub use self::disks_api::{ DisksApiListParams };

That way the consumer has the choice of importing these structures from apis.rs with longer names as well as pulling them from the inner module with shorter names if there in fact would be no name conflicts.

Just a thought.

seunlanlege

comment created time in a month

issue commentOpenAPITools/openapi-generator

[Rust] Issues with client code generation.

@wing328 Here we go:

    Checking storage v1.0.0 (/xxx/out/rust-client)
error[E0432]: unresolved import `storage::apis::ListParams`
 --> examples/disk.rs:7:5
  |
7 | use storage::apis::ListParams;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^ no `ListParams` in `apis`

error[E0603]: module `disks_api` is private
  --> examples/disk.rs:8:20
   |
8  | use storage::apis::disks_api::ListParams;
   |                    ^^^^^^^^^ private module
   |
note: the module `disks_api` is defined here
  --> /xxx/out/rust-client/src/apis/mod.rs:35:1
   |
35 | mod disks_api;
   | ^^^^^^^^^^^^^^

So the ListParams is not re-exported from storage::apis and hence cannot be used from there (line 7). And it also cannot be used from disks_api, where it is defined, since the disks_api module is private (line 8).

seunlanlege

comment created time in a month

issue commentOpenAPITools/openapi-generator

[Rust] Issues with client code generation.

Still no dice. The *Params structures are public now, however they are located in the private module and are not re-exported from there alongside the trait and API client. So still no access to them from outside of the generated crate.

seunlanlege

comment created time in a month

issue openedAzure/autorest

Please add support for generating Rust client

While AWS enjoys pretty extensive Rust support via rusoto framework, there is nothing for Azure. Having Rust client libraries automatically generated will accelerate adoption of the Azure cloud for Rust native application.

created time in 2 months

startedArnavion/k8s-openapi

started time in 2 months

push eventruaze/ruaze

Cyril Plisko

commit sha f5d9f15ef10aed3f8e86a0e0fe174497a5cec4fc

Add azure-rest-api-specs submodule

view details

Cyril Plisko

commit sha 1a027356d8dd5531f26700f6b61704cefb3b031b

Update azure-rest-api-specs

view details

push time in 2 months

issue openedrust-lang/libc

TCP_KEEPINTVL and TCP_KEEPCNT for macos

Similar to #978 TCP_KEEPINTVL and TCP_KEEPCNT are missing from src/unix/bsd/apple/mod.rs

On my Mac:

$ grep TCP_KEEP /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/netinet/tcp.h
#define TCP_KEEPALIVE           0x10    /* idle time used when SO_KEEPALIVE is enabled */
#define TCP_KEEPINTVL           0x101   /* interval between keepalives */
#define TCP_KEEPCNT             0x102   /* number of keepalives before close */

I am not sure if there is any public repository with this file available for the reference here.

created time in 2 months

issue commentOpenAPITools/openapi-generator

[Rust] Issues with client code generation.

It seems that params structures generated by #6230 are private and hence are not usable :(

seunlanlege

comment created time in 2 months

issue commentMindFlavor/AzureSDKForRust

Autogenerate SDK

Glad to hear that you have similar ideas in working! I had a really quick experiment with openapi-generator and it feels like there is a fair amount of heavy lifting that can be offloaded to it. Or perhaps it and bpb can be combined together to automate things even further?

imp

comment created time in 2 months

issue commentsbstp/attohttpc

Provide getters for RequestBuilder

How about .inspect() that return RequestInspector object? So that will be

let builder = get("...").body("xx").header("aa", "bb");
assert_eq!(builder.inspect().body(), "xx");
abreis

comment created time in 2 months

create barnchruaze/ruaze

branch : develop

created branch time in 2 months

create barnchruaze/ruaze

branch : master

created branch time in 2 months

created repositoryruaze/ruaze

Azure Rust SDK

created time in 2 months

issue openedMindFlavor/AzureSDKForRust

Autogenerate SDK

Just tossing the idea - is it possible to autogenerate the SDK for Azure services? Similar to what rusoto does - is it practical to take the specs and use codgen to build the basic building blocks for all the services. This may create a nice platform to create a higher level SDK and spend time on boring things.

created time in 2 months

issue openedseanmonstar/reqwest

impl From<http::Request> for blocking::Request is missing

There is such conversion for reqwest::Request. However, request::blocking::Request lacks such conversion. Having a straightforward conversion is very helpful for crates that implement some HTTP interaction without specifying a concrete HTTP client implementation. Such crates may build an http::Request and then hand it to the a specific HTTP client crate, such as reqwest (or some other crate using http).

created time in 3 months

issue openedsbstp/attohttpc

Add helper for converting Response into Result based on StatusCode

When Response is received it can be checked for success using is_success() method in order to decide on further processing. It may be very helpful to provide a method that will convert Response into Result<Response> based on the the StatusCode.

Other HTTP client libraries provide similar facilities and they are very handy. For example Python requests has raise_for_status and reqwest has error_for_status.

What do you think?

created time in 3 months

issue commentAmanieu/parking_lot

Cannot find macro `llvm_asm`

I am having some other (unrelated) issues with the today's nightly. What is the earliest nightly that will work?

imp

comment created time in 3 months

issue openedAmanieu/parking_lot

Cannot find macro `llvm_asm`

Since parking_lot was updated to 0.10.1 I am getting this error

error: cannot find macro `llvm_asm` in this scope
  --> /.../.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot-0.10.1/src/elision.rs:77:13
   |
77 |             llvm_asm!("xacquire; lock; cmpxchgq $2, $1"
   |             ^^^^^^^^

error: cannot find macro `llvm_asm` in this scope
   --> /.../.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot-0.10.1/src/elision.rs:108:13
    |
108 |             llvm_asm!("xrelease; lock; xaddq $2, $1"
    |             ^^^^^^^^

Perhaps there needs to be some guidance regarding the minimal Rust version where this macro is supported?

created time in 3 months

more