profile
viewpoint
Carol (Nichols || Goulding) carols10cents Pittsburgh, PA, USA http://carol-nichols.com

carols10cents/aoc-rs-2019 18

My Advent of Code 2019 solutions (in Rust, of course). Not guaranteed to be done each day or totally completed.

carols10cents/cargo-open 15

A third-party cargo extension to allow you to open a dependent crate in your $EDITOR

carols10cents/carolshubot 10

My hubot setup

carols10cents/adventofcode-rs 3

My advent of code 2016 solutions in Rust. Tags for each day's solutions

carols10cents/book 1

The Rust Programming Language

carols10cents/capybara 1

webrat alternative which aims to support all browser simulators

carols10cents/carol-test 1

A crate I use to test publishing

carols10cents/24pullrequests 0

Giving back little gifts of code for Christmas

PR opened rust-lang/rust

Only highlight doc search results via mouseover if mouse has moved C-bug S-waiting-on-review T-rustdoc

What happens

  • Go to https://doc.rust-lang.org/stable/std/index.html
  • Put your mouse cursor somewhere in the middle where search results will appear and then don't move the mouse
  • Press 's' to focus the search box
  • Type a query that brings up enough search results to go under where your mouse cursor is
  • Press the down arrow
  • The search result that is one below where your mouse cursor is will be highlighted.

What I expected

When not currently using the mouse, I expect doing a search and then pressing the down arrow to always highlight the first search result immediately below the search box.

The fix

This feels a bit hacky to me; I'm open to other solutions. This introduces a global JS var that keeps track of whether the person searching has moved their mouse after doing a search or not, and only uses the mouse position to highlight search results if the person HAS moved the mouse AFTER doing a search.

+24 -13

0 comment

1 changed file

pr created time in a day

create barnchinteger32llc/rust

branch : docs-arrow-keys

created branch time in a day

PR opened rust-lang/rust

Don't move cursor in search box when using arrows to navigate results C-bug S-waiting-on-review T-rustdoc

What happens

  • Go to https://doc.rust-lang.org/stable/std/index.html
  • Press 's' to focus the search box
  • Type a query like 'test'
  • Press the down arrow one or more times to change which search result is highlighted
  • Press the up arrow once to go up one search result
  • Notice the cursor in the search box is now at the beginning of your query, such that if you now typed 'a' the search box would contain 'atest', when it would be expected that the cursor would have remained where it was and if you typed 'a' at this point it would result in 'testa'
  • Press the down arrow once to go down one search result
  • Now notice the cursor is at the end of your query again

What I expected

I expected that changing which search result was highlighted using the up and down arrows would have no effect on where the cursor was in the search box.

The fix

This PR prevents the default action of the up and down arrows when the custom keydown events are happening during a search.

+2 -0

0 comment

1 changed file

pr created time in a day

create barnchinteger32llc/rust

branch : prevent-default-arrows

created branch time in a day

push eventinteger32llc/cloud-storage-rs

Carol (Nichols || Goulding)

commit sha a3fbe49fd0b2878b6cbc3af76b8719692082cf5e

Implement object download

view details

Carol (Nichols || Goulding)

commit sha 69d270b354fb89183227c22fcac34f4efd4d1d41

Remove trailing whitespace

view details

Carol (Nichols || Goulding)

commit sha ff145bc8a9256322f35d9810c49ba23debc4bf0b

Cargo fmt

view details

Carol (Nichols || Goulding)

commit sha 6cadd7b215daee4425945924b8df296d7eee753d

Change delete so that you don't have to read an object first

view details

push time in a day

pull request commentrust-lang/crates.io

Add minimal_metadata route for crate

Have you benchmarked?

On Sat, May 30, 2020, 11:15 PM Folyd notifications@github.com wrote:

We actually already have a way to redirect people to a crate's repository built in https://github.com/rust-lang/crates.io/blob/de20f73138ef8a2ec93ae6bf90497e119319953b/app/routes/crate/repo.js-- if you go to [https://crates.io/crates/crate https://crates.io/crates/[crate name]/repo, it will redirect to that crate's repository (try https://crates.io/crates/rand/repo for example).

Would using that work for your search extension?

Cool, thanks @carols10cents https://github.com/carols10cents. I noticed that this is also a frontend redirection? It could be a slower redirection than my implementation though.

Can we add the redirection in the backend? Which could be the best choice I think. :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rust-lang/crates.io/pull/2538#issuecomment-636414283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABPKUT4KYDHROYL72WF7TDRUHDVHANCNFSM4NOSFPIQ .

Folyd

comment created time in 5 days

pull request commentrust-lang/crates.io

Add minimal_metadata route for crate

We actually already have a way to redirect people to a crate's repository built in-- if you go to https://crates.io/crates/[crate name]/repo, it will redirect to that crate's repository (try https://crates.io/crates/rand/repo for example).

Would using that work for your search extension?

Folyd

comment created time in 5 days

pull request commentrust-lang/book

Fix minor typo in the summary of chapter 10 about Generics

Hi, this is not a typo. https://idioms.thefreedictionary.com/in+sum

Thanks!

graemer957

comment created time in 5 days

issue closedrust-lang/book

Clarifying that Cargo's version of semver is distinct from semver.org

It was recently pointed out to me that the implementation of semver in Cargo is slightly different in an important way from the "official" semver spec, specifically around versions with a major version of "0".

I've been using Rust for quite a while (and working in Rust is my day job too!) but I did not notice this. My thinking is that if someone with my amount of experience could make this mistake, its very possible for other people to do the same, and therefore this is a perfect opportunity to make some helpful changes to the documentation.

The contributors section for this repo seemed to imply that pull requests directly changing the wording are not exactly welcome, so I will present my thoughts here. I have a few specific examples that I think could be improved. If it is appropriate to submit pull requests please let me know, I would be more than happy to submit one.

I think most importantly, in the section "Publishing a Crate to Crates.io", we can find the following section:

Publishing a New Version of an Existing Crate

When you’ve made changes to your crate and are ready to release a new version, you change the version value specified in your Cargo.toml file and republish. Use the Semantic Versioning rules to decide what an appropriate next version number is based on the kinds of changes you’ve made. Then run cargo publish to upload the new version.

In the above, the words "Semantic Versioning" link to semver.org. This paragraph is perfectly clear and well written. However, when I read this paragraph, it was so clear to me that Cargo versions were supposed to be perfectly semver. And then I never ever thought about them again. I didn't think that semver was enforced by cargo, but I did think that it is good practice for version numbers to be strictly semver, and that maybe semver was applied when you had version numbers with the just the major number like "1" or "0".

I can understand that maybe this exception isn't exactly desirable to teach extensively, and maybe the documentation wants to encourage the thought that versions are strictly semver, but I think an addition like the following would be really helpful:

Cargo varies slightly from the official semver spec in that versions with a major number of "0" are not compatible with distinct minor numbers. This is to allow for packages that have not yet hit a stable API to make breaking changes without incrementing the major number.

Similarly, I think that on this page of the cargo docs, the sentence

The string "0.1.12" is a semver (link to semver rust crate) version requirement.

should be changed to

The string "0.1.12" is a semver version requirement, which is distinct from a semver.org version requirement in a few important ways.

I think this would go a long way in clarifying version numbers for future users!

closed time in 6 days

maplant

issue commentrust-lang/book

Clarifying that Cargo's version of semver is distinct from semver.org

I think this is more appropriate to address in the cargo docs, which live in the cargo repo. Thank you for your time and thoughtfulness, though!

maplant

comment created time in 6 days

PR opened rust-lang/team

Add my discord ID and ops bot permissions

I'd like to play with Nell's awesome ops bot too!!

r? @pietroalbini

+4 -0

0 comment

1 changed file

pr created time in 8 days

push eventrust-lang/team

Carol (Nichols || Goulding)

commit sha 1c010c8fd6190f088b0eabc336332f007f1b303b

Add my discord ID and ops bot permissions

view details

push time in 8 days

create barnchrust-lang/team

branch : carol-discord-id

created branch time in 8 days

delete branch rust-lang/team

delete branch : grant-try-to-timer

delete time in 8 days

delete branch rust-lang/team

delete branch : Manishearth-patch-1

delete time in 8 days

delete branch rust-lang/team

delete branch : jtgiebel-colead

delete time in 8 days

delete branch rust-lang/team

delete branch : crates-io-rplus

delete time in 8 days

delete branch rust-lang/team

delete branch : web-presence

delete time in 8 days

delete branch rust-lang/team

delete branch : move-nicolette-to-alumni

delete time in 8 days

delete branch rust-lang/team

delete branch : sync-github-clippy

delete time in 8 days

created tagrust-lang/book

tagnostarch-2020-05-25

The Rust Programming Language

created time in 9 days

issue commentrust-lang/cargo

Changing metadata should be possible without bumping a version

If there was any progress, it would show up on this issue.

lifthrasiir

comment created time in 11 days

delete branch carols10cents/flatbuffers

delete branch : patch-1

delete time in 17 days

PR closed rust-lang/book

Update ch04-03-slices.md

fixed typo, counting from 0 instead of 1.

+1 -1

1 comment

1 changed file

imkdir

pr closed time in 18 days

pull request commentrust-lang/book

Update ch04-03-slices.md

No, this is not a typo. The intention is to count here the way most people count in human language starting from 1, which means it starts from the 7th byte. Starting from 0 as the index does gets you to 6.

imkdir

comment created time in 18 days

issue commentrust-lang/crates.io

Be able to search within a keyword or category

Any progress on this would appear on this issue, so no.

carols10cents

comment created time in 18 days

issue commentrust-lang/crates.io

Tracking issue for updating dependencies

Hooray!!!! Would we be able to and want to enable dependabot for Rust deps now?

jtgeibel

comment created time in 22 days

issue openedshepmaster/snafu

Feature request: Unused enum variant warning

What happened

I had an enum that derived Snafu, and I added a variant to it:

use snafu::Snafu;
use std::{io, path::PathBuf, sync::Arc};

#[derive(Debug, Snafu, Clone)]
enum MyError {
    UnableToRead {
        #[snafu(source(from(io::Error, Arc::new)))]
        source: Arc<io::Error>,
        path: PathBuf,
    },
}

I did not use this variant anywhere.

What I expected

Usually when I have an enum variant that's unused, Rust gives a dead_code warning about it:

use std::{io, path::PathBuf, sync::Arc};

enum MyError {
    UsingThisOne,
    UnableToRead {
        source: Arc<io::Error>,
        path: PathBuf,
    },
}

fn main() {
    let _f = MyError::UsingThisOne;
}

produces:

warning: variant is never constructed: `UnableToRead`
  --> src/main.rs:7:5
   |
7  | /     UnableToRead {
8  | |         source: Arc<io::Error>,
9  | |         path: PathBuf,
10 | |     },
   | |_____^
   |
   = note: `#[warn(dead_code)]` on by default

It'd be nice to have this warning for Snafu enum variants as well.

created time in 22 days

issue commentrust-lang/rust

Can't allow `elided_lifetimes_in_paths` inside a module that denies `rust_2018_idioms`, other lints work

Oh that's... unexpected and undocumented...

carols10cents

comment created time in 25 days

push eventrust-lang/core-team

Carol (Nichols || Goulding)

commit sha 3e59b2c7afefd9569921fd0bf798fbe86be1231d

Update meetings.md

view details

push time in a month

issue openedrust-lang/rust

Can't allow `elided_lifetimes_in_paths` inside a module that denies `rust_2018_idioms`, other lints work

What happened

This code fails to compile:

#![deny(rust_2018_idioms)]

mod blah {
    #![allow(rust_2018_idioms)]

    struct Thing<'a>(&'a i32);

    struct Bar<T>(T);

    fn foo(b: Bar<Thing>) {}
}

with the error:

error: hidden lifetime parameters in types are deprecated
  --> src/lib.rs:10:19
   |
10 |     fn foo(b: Bar<Thing>) {}
   |                   ^^^^^- help: indicate the anonymous lifetime: `<'_>`
   |
note: the lint level is defined here
  --> src/lib.rs:1:9
   |
1  | #![deny(rust_2018_idioms)]
   |         ^^^^^^^^^^^^^^^^
   = note: `#[deny(elided_lifetimes_in_paths)]` implied by `#[deny(rust_2018_idioms)]`

What's weird is that this code, with unused_variables instead of rust_2018_idioms, compiles (with other warnings) as I expect:

#![deny(unused_variables)]

mod blah {
    #![allow(unused_variables)]

    struct Thing<'a>(&'a i32);

    struct Bar<T>(T);

    fn foo(b: Bar<Thing>) {}
}

(and removing the allow causes it to not compile as I would expect)

AND this code compiles (with other warnings) as I expect:

#![deny(rust_2018_idioms)]

mod blah {
    #![allow(rust_2018_idioms)]
    extern crate rand;
    use rand::Rng;
}

so it seems to be something to do with elided_lifetimes_in_paths in particular...?

I also tried this, which I would expect to compile but does not:

#![deny(rust_2018_idioms)]

mod blah {
    #![allow(elided_lifetimes_in_paths)]

    struct Thing<'a>(&'a i32);

    struct Bar<T>(T);

    fn foo(b: Bar<Thing>) {}
}

This I would also expect to compile but does not:

#![deny(elided_lifetimes_in_paths)]

mod blah {
    #![allow(elided_lifetimes_in_paths)]

    struct Thing<'a>(&'a i32);

    struct Bar<T>(T);

    fn foo(b: Bar<Thing>) {}
}

I started thinking maybe it had something to do with allow-by-default lints, but this compiles as I would expect:

#![deny(missing_docs)]
//! hi

/// Hi
pub mod blah {
    #![allow(missing_docs)]

    pub struct Foo {
        pub field: i32,
    }
}

Sooo I don't have any real guesses without compiler internals knowledge 🤷‍♀️

It sounds related to this issue: https://github.com/rust-lang/rust/issues/70819 but I decided to file a new issue because that one appears to be about the same "scope level" and I think I'm doing different scope levels? Please close if this is a dupe!

I'm using stable 1.43; I also confirmed that 1.42 and 1.41 have the same behavior so this is not a recent regression.

I also confirmed that beta 1.44.0-beta.2 and nightly 2020-05-05 f8d394e5184fe3af761e have the same behavior.

created time in a month

PR opened google/flatbuffers

Small tutorial improvements - documentation only

I have agreed to the CLA today.

+20 -18

0 comment

1 changed file

pr created time in a month

push eventcarols10cents/flatbuffers

Carol (Nichols || Goulding)

commit sha 20accc9132999526966908302394f38c744dea2c

Minor grammar, spelling, and Markdown fixes

view details

push time in a month

push eventcarols10cents/flatbuffers

Carol (Nichols || Goulding)

commit sha fc54057a1e665c37cffca400f1c8beab834fb2a6

Use code formatting for a code snippet

view details

push time in a month

fork carols10cents/flatbuffers

FlatBuffers: Memory Efficient Serialization Library

http://google.github.io/flatbuffers/

fork in a month

pull request commentrust-lang/book

Remove an uneeded 'static lifetime

If you could stop the global pandemic, pay Steve or I to work on the book, provide childcare, or make more hours in the day, that would help.

Please be patient, your pings are not helpful.

steveklabnik

comment created time in a month

create barnchinteger32llc/rust

branch : btreemap-entry-vacant-docs

created branch time in a month

PR opened rust-lang/rust

Update btree_map::VacantEntry::insert docs to actually call insert

It looks like they were copied from the or_insert docs. This change makes the example more like the hash_map::VacantEntry::insert docs.

+5 -6

0 comment

1 changed file

pr created time in a month

issue commentrust-lang/rustfmt

[unstable option] comment_width

Not sure if this is the right place to add this comment or not; feel free to tell me to go somewhere else.

I was surprised to find out that the default value for comment_width is 80, while the default value for max_width is 100. I would have expected the defaults to be the same.

So before comment_width is stabilized, I'd like to advocate for reconsidering the default value.

Do text editors display/enforce different widths for comments vs code? I use TextMate, and it just has one wrap column setting.

Examples:

<details>

What looks "good" to me:

// This line of code is just about width 100
fn evaluate_something_test(something: &Something, number: usize) -> Result<BTreeMap, CustomError> {
    // This comment is wrapped to 100. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed 
    // do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis 
    // nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute...
    unimplemented!();
    
    // This is what I would expect. irure dolor in reprehenderit in voluptate velit esse cillum 
    // dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in 
    // culpa qui officia deserunt mollit anim id est laborum.
}

What looks "strange" to me:

// This line of code is just about width 100
fn evaluate_something_test(something: &Something, number: usize) -> Result<BTreeMap, CustomError> {
    // This comment is wrapped to 80. Lorem ipsum dolor sit amet, consectetur 
    // adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore 
    // magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation 
    // ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute...
    unimplemented!();
    
    // This looks strange to me. irure dolor in reprehenderit in voluptate 
    // velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint 
    // occaecat cupidatat non proident, sunt in culpa qui officia deserunt 
    // mollit anim id est laborum.
}

</details>

scampi

comment created time in a month

CommitCommentEvent

issue commentrust-lang/book

Absolute path for module

I'm not sure what we could do to address guesses made based on inferences from resources outside of our control? Do you have any suggestions on how we could improve the text?

oaigudmundsson

comment created time in a month

PR closed rust-lang/book

fix: typo
+1 -1

1 comment

1 changed file

unional

pr closed time in a month

pull request commentrust-lang/book

fix: typo

This is not a typo, and Rust does not require that you take more than one action, so this is correct as-is. Thanks though!

unional

comment created time in a month

PR closed rust-lang/book

Fix typo in ch19-06

Very minor typo fix: "an sql! macro" to "a sql! macro"

+1 -1

1 comment

1 changed file

linusmarco

pr closed time in a month

pull request commentrust-lang/book

Fix typo in ch19-06

Hi, this depends on how you pronounce the sql! macro. I pronounce it "ess cue ell", so "an" is correct here. Thanks though!

linusmarco

comment created time in a month

issue closedrust-lang/crates.io

<div class="_install-action shows code for lib instead of binary

I published my binary CLI to crates.io:
https://crates.io/crates/lmake_readme
On the opening page in div "install-action" it looks like it is a library:
lmake_readme = "0.5.1"
Instead it should be a binary:
cargo install lmake_readme

closed time in a month

LucianoBestia

issue commentrust-lang/crates.io

<div class="_install-action shows code for lib instead of binary

Yes, this is a duplicate of #483. Thanks!

LucianoBestia

comment created time in a month

push eventcarols10cents/narrow_down

Carol (Nichols || Goulding)

commit sha f42c3e66ab09727c1b53b8cbb1d8ba342d584640

This is markdown wtf was I doing

view details

push time in a month

issue closedrust-lang/book

bfnightly rustbook isn't updating to master

Went to fork and fix a few things up but it appears they were already fixed. On https://bfnightly.bracketproductions.com/rustbook/ it is not updating.

So that others don't end up doing extra work thinking there are mistakes only to find that they are fine, please fix this.

closed time in 2 months

mimirmim

issue commentrust-lang/book

bfnightly rustbook isn't updating to master

I have no idea what bfnightly is, and we don't have anything to do with maintaining it. Please contact its author.

mimirmim

comment created time in 2 months

issue closedrust-lang/book

Capture `@` operator is not mentioned.

6.2. The match Control Flow Operator section does not mention capture operator @, but I believe it should. This is valid, stable rust code:

fn main() {
    let a = Some(117i32);
    
    let _ = match a {
        Some(a @ 1..=99) => Some(a),
        a_opt @ Some(_) => a_opt,
        None => Some(0)
    };
}

closed time in 2 months

L117

issue commentrust-lang/book

Capture `@` operator is not mentioned.

Yes, we chose to cover that operator in Chapter 18.

L117

comment created time in 2 months

pull request commentrust-lang/crates.io

README: Remove obsolete Browserstack section

Yeah, maybe someday, for now I just use it manually :)

Turbo87

comment created time in 2 months

PR closed rust-lang/crates.io

README: Remove obsolete Browserstack section A-ember C-cleanup S-waiting-on-review

We don't currently seem to use Browserstack in this project

r? @locks

+0 -6

1 comment

2 changed files

Turbo87

pr closed time in 2 months

pull request commentrust-lang/crates.io

README: Remove obsolete Browserstack section

I occasionally use browserstack to check on browser compatibility issues; having browserstack in our readme is a term of keeping our free open source account. Please don't remove this, thanks! <3

Turbo87

comment created time in 2 months

push eventinteger32llc/tremor-runtime

Carol (Nichols || Goulding)

commit sha e3611ebbb9dbbb7d34dface6552a0fb082b6ff18

Make pre and post processor public too

view details

push time in 2 months

push eventinteger32llc/tremor-runtime

Carol (Nichols || Goulding)

commit sha 818431cbc0dc2a7162909bf88ae8c68606462a0c

Make influx and binflux compile and be accessible externally

view details

push time in 2 months

PR closed rust-lang/book

Add the missing word to the sentence (ch18-02)

expression is missing, right?

+1 -1

1 comment

1 changed file

pione30

pr closed time in 2 months

pull request commentrust-lang/book

Add the missing word to the sentence (ch18-02)

No, "conditional" can be used as a noun; here's another example. Thanks though!

pione30

comment created time in 2 months

pull request commentrust-lang/crates.io

Serve more static files from nginx

Whew! lgtm! Great work tracking this down! ❤️

@bors r+

jtgeibel

comment created time in 2 months

issue closedrust-lang/book

In appendix-01 there is a wrong link

Yesterday you merged a pull request (commit rust-lang@2a87cc0) in which you added a wrong link:

[union]: ..reference/items/unions.html

Maybe you wanted to add this link:

https://doc.rust-lang.org/reference/items/unions.html

closed time in 2 months

fededev01

issue commentrust-lang/book

In appendix-01 there is a wrong link

It is meant to be read either from local installations of Rust or from doc.rust-lang.org, but not in GitHub's rendered markdown. The relative link is needed to work in the places we want it to work. Thanks though!

fededev01

comment created time in 2 months

issue closedrust-lang/book

Change four to five. ch19, unsafe. 5 instances.

https://doc.rust-lang.org/stable/book/ch19-01-unsafe-rust.html "four" -> "five" beneath the 5 unsafe features:

To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take four actions in unsafe Rust, called unsafe superpowers, that you can’t in safe Rust. Those superpowers include the ability to:

Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static variable Implement an unsafe trait Access fields of unions It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these four features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.

In addition, unsafe does not mean the code inside the block is necessarily dangerous or that it will definitely have memory safety problems: the intent is that as the programmer, you’ll ensure the code inside an unsafe block will access memory in a valid way.

People are fallible, and mistakes will happen, but by requiring these four unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs.

To isolate unsafe code as much as possible, it’s best to enclose unsafe code within a safe abstraction and provide a safe API, which we’ll discuss later in the chapter when we examine unsafe functions and methods. Parts of the standard library are implemented as safe abstractions over unsafe code that has been audited. Wrapping unsafe code in a safe abstraction prevents uses of unsafe from leaking out into all the places that you or your users might want to use the functionality implemented with unsafe code, because using a safe abstraction is safe.

Let’s look at each of the four unsafe superpowers in turn. We’ll also look at some abstractions that provide a safe interface to unsafe code.

closed time in 2 months

thor314

issue commentrust-lang/book

Change four to five. ch19, unsafe. 5 instances.

This has been fixed on master already. The book rides the release trains, and the fix has made it to beta, so this will be fixed in the stable book with the next Rust release. Thanks!

thor314

comment created time in 2 months

pull request commentrust-lang/crates.io

Support GitHub Actions Badges

Next time I get a chance to review PRs, I'll be reviewing them in "Least Recently Updated" order. My current queue: https://github.com/rust-lang/crates.io/pulls?q=is%3Aopen+is%3Apr+assignee%3Acarols10cents+sort%3Aupdated-asc

CryZe

comment created time in 2 months

pull request commentrust-lang/crates.io

Support GitHub Actions Badges

I don't think a person asking the status of things after roughly a month of no action is rude. We fully realize that neither you nor anyone else gets paid to work on crates.io. All we were seeking was a status update, whether from you or someone else.

All status changes are made to the issue. If there is no update here, there has been no change in status. I do think it's rude.

CryZe

comment created time in 2 months

pull request commentrust-lang/crates.io

Support GitHub Actions Badges

Whether you're trying to be rude or not, you are being rude.

I'm not getting paid to work on crates.io right now, so I'm prioritizing paid work.

Also, there's a global pandemic going on. So you all need to chill.

CryZe

comment created time in 2 months

issue closedrust-lang/rust

Rust compiler should avoid mentioning private traits as solution to missing methods

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. -->

Building the following code targeting Windows:

extern crate clap;

fn main() {
    let foo = std::ffi::OsString::from("foo").as_bytes();
}

says:

error[E0599]: no method named `as_bytes` found for struct `std::ffi::OsString` in the current scope
 --> src/main.rs:4:47
  |
4 |     let foo = std::ffi::OsString::from("foo").as_bytes();
  |                                               ^^^^^^^^ method not found in `std::ffi::OsString`
  |
  = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
  |
3 | use crate::clap::osstringext::OsStrExt3;
  |

If you add the suggested use, you get:

error[E0603]: module `osstringext` is private
   --> src/main.rs:3:18
    |
3   | use crate::clap::osstringext::OsStrExt3;
    |                  ^^^^^^^^^^^ this module is private
    |
note: the module `osstringext` is defined here
   --> /home/glandium/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.33.0/src/lib.rs:568:1
    |
568 | mod osstringext;
    | ^^^^^^^^^^^^^^^^

I could get behind the suggesting if the module was local to the crate being built, but from an external crate, it's not helpful.

Meta

<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. -->

rustc --version --verbose:

rustc 1.43.0-nightly (3dbade652 2020-03-09)
binary: rustc
commit-hash: 3dbade652ed8ebac70f903e01f51cd92c4e4302c
commit-date: 2020-03-09
host: x86_64-unknown-linux-gnu
release: 1.43.0-nightly
LLVM version: 9.0

closed time in 3 months

glandium

issue commentrust-lang/rust

Rust compiler should avoid mentioning private traits as solution to missing methods

Yes, closing as duplicate.

glandium

comment created time in 3 months

issue commenttikotzky/faker-rs

Feature request: guaranteed unique values over the whole test run?

@nixpulvis I mean multiple threads agreeing to a unique value. The use case I have is in crates.io tests: crate names must be unique, all the tests use the same database, so currently we're manually assigning crate names in each test but it would be better if we didn't have to do that.

In other words in case my explanation above wasn't clear:

  • There is one test database that all the tests are inserting into from the various test threads
  • The database has a constraint that crates.name must be unique
  • Each test that inserts a crate record must have a unique crate name; currently we hardcode literal crate names usually based on what the test is doing, but contributors have to know each test needs unique crate names and can't, for example, copy-paste an existing test to create a new test
carols10cents

comment created time in 3 months

issue closedrust-lang/book

Listing 20-24 has a syntax error

Listing 20-24 of the Graceful Shutdown and Cleanup chapter has a syntax error. In the Worker implementation it invokes job.call_box() which is not a valid function. Instead it should be job() as shown in the final listing.

closed time in 3 months

joshmarinacci

issue commentrust-lang/book

Listing 20-24 has a syntax error

Yes, the book rides the Rust release trains and it will be fixed on the stable book soon. Thanks!

joshmarinacci

comment created time in 3 months

PR closed rust-lang/crates.io

Update swirl S-blocked S-waiting-on-review

The latest revisions to swirl include:

  • Concrete error types everywhere instead of Box<dyn Error>, which simplifies conversion for us.
  • Automatic handling of connection pool configuration
    • Swirl can now just take a DB url, and defaults to a connection pool with 2x the thread count connections, which is what we want
    • Jobs can take a connection as an argument, meaning we don't need to carry around a pool manually in the environment
  • Updated dependencies
+105 -115

5 comments

13 changed files

sgrif

pr closed time in 3 months

pull request commentrust-lang/crates.io

Update swirl

Closing in favor of #2269

sgrif

comment created time in 3 months

issue closedrust-lang/crates.io

Report: not rendering in MS-Edge

We got this report via email, and I haven't had time to investigate.

The site appears to not be rendering, except for the green background, in MS-Edge.

We should maybe add edge to percy if that's possible, or use browserstack.

2020-02-18

closed time in 3 months

carols10cents

issue commentrust-lang/crates.io

Report: not rendering in MS-Edge

@montao Wait, you said you're on Microsoft Edge 44.17763.831.0? The latest Edge version according to Browserstack is 80, and crates.io rendered for me using that version in Browserstack.

Could you try updating your Edge to the latest and reopen if crates.io still isn't rendering? We don't have the developers to support older versions of browsers. Thanks!

carols10cents

comment created time in 3 months

issue commentrust-lang/crates.io

Error accessing dashboard

My first thought was a browser or plugin issue, but I looked at the user agents in the logs for the status=403 crates?following=1 query and I'm seeing a pretty wide variety of user agents across mobile, OS, and browser. Ex: Chrome 80 on Android 10, Firefox 73 on macOS (High Sierra), Firefox 73 on Windows 10, Chrome 74 on Linux, Safari 13 on iOS 13.3 Apple iPhone.

dbr

comment created time in 3 months

issue closedrust-lang/crates.io

Serde's README incomplete on crates.io

If you compare https://crates.io/crates/serde with the original https://github.com/serde-rs/serde you can see that the former lacks Cargo.toml part of the usage instructions. This is unfortunate since following these broken instructions leads to unnecessary errors.

The missing part is contained inside <details>...<details> tags. Best guess is this is being stripped out by some markdown processor or something.

closed time in 3 months

mbernat

issue commentrust-lang/crates.io

Serde's README incomplete on crates.io

Crates.io uses the file specified in a crate's Cargo.toml readme metadata, and because serde is a workspace, the serde crate specifies a file named crates-io.md, which is not the same as the workspace repo's README.md and that might be intentional.

TL;DR This is an issue with serde, not crates.io.

mbernat

comment created time in 3 months

pull request commentrust-lang/crates.io

Add rustless.org to documentation blocklist

We discussed this in the meeting and agreed on it but I forgot to approve this, oops.

@bors r+

XAMPPRocky

comment created time in 3 months

issue commentrust-lang/crates.io

Serde's README incomplete on crates.io

We mostly use ammonia's defaults, which allows the details tag, so that's not the problem. I'm going to investigate more.

mbernat

comment created time in 3 months

issue closedrust-lang/book

Remove needless third party requests (fonts.googleapis.com)

Hello!

I am using the Rust Programming Language book to learn Rust and am a big fan, but I can't help but notice the needless third party request to fonts.google.com, even in the local version of the book that comes through rustup.

To me this is an easily avoidable privacy intrusion, so I would be very happy to see this changed in the future. I do not want my computer to send a request to Google every time I am learning Rust, especially if it is easy to avoid by various means such as

  1. Including the fonts with the local version of the book
  2. Serving the fonts through your own servers
  3. Simply not using them, it looks absolutely fine without them.

As it stands, Google fonts are a convenience feature that just furthers Google's omnipresence and omniscience and comes at a needless cost to user privacy and data traffic.

Thank you in advance!

closed time in 3 months

UniqueActive

issue commentrust-lang/book

Remove needless third party requests (fonts.googleapis.com)

Hi, we use mdbook, so this would need to be fixed with them. They already have an issue for this: https://github.com/rust-lang/mdBook/issues/847

Thanks!

UniqueActive

comment created time in 3 months

push eventrust-lang/core-team

Carol (Nichols || Goulding)

commit sha 88cc590457fe16466e9ccdfcc1064e2c5638cd1c

Update meetings.md

view details

push time in 3 months

more