profile
viewpoint
Daniel Johnson ComputerDruid @google United States

ComputerDruid/karel 7

Educational library used in schools to teach introductory programming

ComputerDruid/portage-overlay 3

My personal portage overlay for testing/developing ebuilds

bitbanger/golftalk 2

A yet-to-be autoparallelized Scheme variant written in Go

ComputerDruid/ai-nqueens 2

A Lab from AI

ComputerDruid/ai-othello 2

An othello AI for my AI class

ComputerDruid/ai2-edgedetection 2

An AI lab in image processing

ComputerDruid/computerdruid.github.com 2

The repo holding my github page--we'll see how it goes

ComputerDruid/IkarugaDS 2

An attempt to recreate the engine for the arcade shooter game Ikaruga on the DS.

issue commentstjepang/futures-lite

Example in `futures_lite::ready!` docs is incorrect

Nice, perfect.

ComputerDruid

comment created time in 4 days

issue commentstjepang/futures-lite

Example in `futures_lite::ready!` docs is incorrect

I'll also note that I'm generally confused about why ready! is useful for this reason; presumably it is useful because I remember seeing it in code I've read a bunch, but I haven't tried to hand-write very many futures myself.

ComputerDruid

comment created time in 5 days

issue openedstjepang/futures-lite

Example in `futures_lite::ready!` docs is incorrect

https://docs.rs/futures-lite/1.11.1/futures_lite/macro.ready.html#examples

Lists an example usage of:

use futures_lite::future::FutureExt;
use futures_lite::ready;
use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};

// Polls two futures and sums their results.
fn poll_sum(
    cx: &mut Context<'_>,
    a: Pin<&mut impl Future<Output = i32>>,
    b: Pin<&mut impl Future<Output = i32>>,
) -> Poll<i32> {
    let x = ready!(a.poll(cx));
    let y = ready!(b.poll(cx));
    Poll::Ready(x + y)
}

I'm pretty sure this is incorrect because if a.poll() returns Ready but b.poll() returns Pending, a will get poll()ed twice, which isn't allowed: https://doc.rust-lang.org/std/future/trait.Future.html#panics

created time in 5 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where         for i in (self.tuf.trusted_root().version() + 1)..latest_version {             let version = MetadataVersion::Number(i); +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.2:+            //+            //     Try downloading version N+1 of the root metadata file, up to some W number of+            //     bytes (because the size is unknown). The value for W is set by the authors of+            //     the application using TUF. For example, W may be tens of kilobytes. The filename+            //     used to download the root metadata file is of the fixed form+            //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,+            //     or we have downloaded more than Y number of root metadata files (because the+            //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set+            //     by the authors of the application using TUF. For example, Y may be 2^10.

nit: it'd be nice if instead of saying "we should consider doing X" it explains that we don't follow the spec you snippet you just inlined.

Right now it says:

// TUF-1.0.9 §5.1.2: try downloading version N+1 ...

// FIXME: Consider downloading version N+1...

If you're paying close attention you can tell that that means the whole TUF spec text snippet there doesn't describe what we're actually doing, but I think you'd be much better served by a comment that clearly says we're not following the spec. Something like:

// We don't actually follow the spec here; instead, we...
// FIXME: consider following the spec instead of that.
erickt

comment created time in 10 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where                 .update_delegation(&targets_role, delegation.role(), &raw_signed_meta)             {                 Ok(_) => {+                    /////////////////////////////////////////+                    // TUF-1.0.9 §5.2.4:+                    //+                    //     Persist timestamp metadata. The client MUST write the file to+                    //     non-volatile storage as FILENAME.EXT (e.g. timestamp.json).+

This seems like the wrong snippet? This is for timestamp, while this code is for delegated roles

erickt

comment created time in 9 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where                 return Err(Error::Programming(err_msg.into()));             } +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.7:+            //+            //     Persist root metadata. The client MUST write the file to non-volatile storage as+            //     FILENAME.EXT (e.g. root.json).++            self.store_metadata(&root_path, &MetadataVersion::None, &raw_signed_root)+                .await;++            // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+            // allows us to initialize a repository from the local metadata.

This comment is weird to have as a FIXME. If we're doing it for a reason, why would it need to be fixed?

Also, when you say "this allows us to..." can you say where that code is, to make it easier to understand what this is enabling?

erickt

comment created time in 12 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where         // Only store the metadata after we have validated it.         if fetched {             client-                .store_metadata(&root_path, &root_version, &raw_root)+                .store_metadata(&root_path, &MetadataVersion::None, &raw_root)

It seems like this could roll back the metadata version in the local store, if the keys we are initializing from correspond to an old version. Should we avoid overwriting that here?

erickt

comment created time in 12 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where             )             .await?; -        if let Some(updated_timestamp) = self.tuf.update_timestamp(&raw_signed_timestamp)? {-            let latest_version = MetadataVersion::Number(updated_timestamp.version());-            self.store_metadata(&timestamp_path, &latest_version, &raw_signed_timestamp)-                .await;+        if self.tuf.update_timestamp(&raw_signed_timestamp)?.is_some() {+            /////////////////////////////////////////+            // TUF-1.0.9 §5.2.4:+            //+            //     Persist timestamp metadata. The client MUST write the file to non-volatile+            //     storage as FILENAME.EXT (e.g. timestamp.json).++            self.store_metadata(+                &timestamp_path,+                &MetadataVersion::None,

Can you explain why this change is safe? It seems like if we were using local metadata at all this change would break that logic.

erickt

comment created time in 12 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where                 return Err(Error::Programming(err_msg.into()));             } +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.7:+            //+            //     Persist root metadata. The client MUST write the file to non-volatile storage as+            //     FILENAME.EXT (e.g. root.json).++            self.store_metadata(&root_path, &MetadataVersion::None, &raw_signed_root)+                .await;++            // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+            // allows us to initialize a repository from the local metadata.             self.store_metadata(&root_path, &version, &raw_signed_root)                 .await;++            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.8:+            //+            //     Repeat steps 5.1.1 to 5.1.8.         }          if !self.tuf.update_root(&raw_latest_root)? {             error!("{}", err_msg);             return Err(Error::Programming(err_msg.into()));         } -        let latest_version = MetadataVersion::Number(latest_version);+        /////////////////////////////////////////+        // TUF-1.0.9 §5.1.7:+        //+        //     Persist root metadata. The client MUST write the file to non-volatile storage as+        //     FILENAME.EXT (e.g. root.json). -        self.store_metadata(&root_path, &latest_version, &raw_latest_root)-            .await;         self.store_metadata(&root_path, &MetadataVersion::None, &raw_latest_root)             .await; +        // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+        // allows us to initialize a repository from the local metadata.+        self.store_metadata(+            &root_path,+            &MetadataVersion::Number(latest_version),+            &raw_latest_root,+        )+        .await;++        /////////////////////////////////////////+        // TUF-1.0.9 §5.1.9:+        //+        //     Check for a freeze attack. The latest known time MUST be lower than the expiration+        //     timestamp in the trusted root metadata file (version N). If the trusted root+        //     metadata file has expired, abort the update cycle, report the potential freeze+        //     attack. On the next update cycle, begin at step 5.0 and version N of the root+        //     metadata file.++        // FIXME: we should move this logic into TUF to make it easier to review we implement the+        // TUF spec.

huh? you cited the relevant part of the spec right above this? What do you mean?

erickt

comment created time in 12 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where         for i in (self.tuf.trusted_root().version() + 1)..latest_version {             let version = MetadataVersion::Number(i); +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.2:+            //+            //     Try downloading version N+1 of the root metadata file, up to some W number of+            //     bytes (because the size is unknown). The value for W is set by the authors of+            //     the application using TUF. For example, W may be tens of kilobytes. The filename+            //     used to download the root metadata file is of the fixed form+            //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,+            //     or we have downloaded more than Y number of root metadata files (because the+            //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set+            //     by the authors of the application using TUF. For example, Y may be 2^10.

This comment doesn't match the implementation very well, since this implementation walks until the expected version rather than until 404. There's a note about that above, but it should probably be noted boldly right next to this comment, lest the reader be confused into thinking that this comment is describing the behavior of the current implementation.

erickt

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

PR opened rust-analyzer/smol_str

Update CI badge in readme to point to Github Actions

The Travis workflow was deleted in 1150aa92ab1fa6ba489f603f1969fb7f37d1ac8d

+1 -1

0 comment

1 changed file

pr created time in 18 days

push eventComputerDruid/smol_str

Daniel Johnson

commit sha 45a50fd92978dd77d6198e54da06d7547eeeb3d0

Update CI badge in readme to point to Github Actions The Travis workflow was deleted in 1150aa92ab1fa6ba489f603f1969fb7f37d1ac8d

view details

push time in 18 days

issue openedrust-lang/async-book

Missing TODO entries break navigation

I noticed that the right arrow button doesn't work on https://rust-lang.github.io/async-book/06_multiple_futures/03_select.html , presumably because the TODO entry that would come next is 404.

Presumably could be fixed by leaving placeholder pages in the TODO slots, which would also be a good place to link to issues

created time in 19 days

startedmaterial-shell/material-shell

started time in a month

startedasciitosvg/asciitosvg

started time in a month

startedsdefresne/gerrit-monitor

started time in a month

startedKDAB/hotspot

started time in a month

startedyaahc/rfcs

started time in 2 months

pull request commentgoogle/rust_icu

bump paste version 0.1 -> 1.0

@filmil Yep, that seems to have done it! Thanks!

ComputerDruid

comment created time in 2 months

push eventComputerDruid/rust_icu

Filip Filmar

commit sha ef16907dcf30e22f050c633e6599b1325d8936d5

Use rust:1.45 as installation base

view details

Filip Filmar

commit sha 7c8a95ce0b8d73cecbabdf17baee6941a7ef6324

Start using buildenv-1.3.0 This starts using a newer nightly Rust toolchain (1.47) which, in turn, can compile paste-1.0.0 from pull request: https://github.com/google/rust_icu/pull/158

view details

Dan Johnson

commit sha 4afbf01ba82163d5e42c19fc70e961ae138c67bf

bump paste version 0.1 -> 1.0

view details

push time in 2 months

pull request commentgoogle/rust_icu

bump paste version 0.1 -> 1.0

If by buildenv you mean https://hub.docker.com/r/filipfilmar/rust_icu_testenv/ , then yeah, absolutely. Let me know if I can help with that

ComputerDruid

comment created time in 2 months

pull request commentgoogle/rust_icu

bump paste version 0.1 -> 1.0

Pretty much just because it would be nice if http://fxrev.dev/417545 didn't have to vendor 2 versions of paste.

And I don't think the docker problem is universal; I think it's specifically that it's too old to build paste 1.0.

ComputerDruid

comment created time in 2 months

pull request commentgoogle/rust_icu

bump paste version 0.1 -> 1.0

CI might not pass right now; I had some trouble with the docker flow locally. It worked with cargo test though, so I think it's probably that the docker images need to be rebuilt with rust >= 1.45

ComputerDruid

comment created time in 2 months

PR opened google/rust_icu

bump paste version 0.1 -> 1.0
+18 -18

0 comment

18 changed files

pr created time in 2 months

create barnchComputerDruid/rust_icu

branch : paste_1_0

created branch time in 2 months

fork ComputerDruid/rust_icu

rust_icu: rust bindings for ICU (International Components for Unicode) library

fork in 2 months

issue openedstjepang/async-executor

Main future gets polled with every cycle of the event loop

Example:

use futures::future;
use smol::{Task, Timer};
use std::task::Poll;
use std::time::Duration;

async fn sleep_loop() {
    for counter in 1i32.. {
        Timer::after(Duration::from_millis(100)).await;
        eprintln!(
            "beep beep, beep beep. *snooze* (alarm snoozed {} times)",
            counter
        )
    }
}

pub fn main() {
    let mut poll_count: i32 = 0;
    Task::spawn(sleep_loop()).detach();
    smol::run(future::poll_fn(|_cx| {
        poll_count += 1;
        if poll_count == 20 {
            return Poll::Ready(());
        }
        eprintln!("polled {} times", poll_count);
        Poll::Pending
    }));
}

Gives me:

polled 1 times
polled 2 times
polled 3 times
polled 4 times
beep beep, beep beep. *snooze* (alarm snoozed 1 times)
polled 5 times
polled 6 times
polled 7 times
beep beep, beep beep. *snooze* (alarm snoozed 2 times)
polled 8 times
polled 9 times
polled 10 times
beep beep, beep beep. *snooze* (alarm snoozed 3 times)
polled 11 times
polled 12 times
polled 13 times
beep beep, beep beep. *snooze* (alarm snoozed 4 times)
polled 14 times
polled 15 times
polled 16 times
beep beep, beep beep. *snooze* (alarm snoozed 5 times)
polled 17 times
polled 18 times
polled 19 times
beep beep, beep beep. *snooze* (alarm snoozed 6 times)

This came up in stjepang/smol#113, but I this is a bit more general than that, so I figured it'd give it its own issue.

While it's true that spurious polls should be handled gracefully by futures it seems wasteful to be polling the main future all the time if it hasn't been woken.

created time in 2 months

issue commentrust-lang/futures-rs

rename `mpsc::Receiver::try_next`

What about next_or_never or similar, after Future::now_or_never? That seems to be a close analog to Receiver::try_next's behavior.

It is very similar, but it isn't really _or_never since it doesn't consume the stream.

ComputerDruid

comment created time in 2 months

issue openedrust-lang/futures-rs

rename `mpsc::Receiver::try_next`

I think mpsc::Receiver::try_next should be rename, since it conflicts with TryStreamExt::try_next. Since receiver is actually a Stream itself it's definitely confusing that there's two try_next()s that could apply that do distinctly different things.

I'd argue that the Receiver one is more niche, since (docs):

Tries to receive the next message without notifying a context if empty.

It is not recommended to call this function from inside of a future, only when you've otherwise arranged to be notified when the channel is no longer empty.

This function will panic if called after try_next or poll_next has returned None.

Those caveats make it so you have to be careful in how you use it. IMO we should save the "good name" try_next for the one that returns a future, and pick a less nice name for this case.

I'm not sure what it should be called though. next_nonblock?

Also side note it might be worth checking to see if there's any cases where currently compiling code using Receiver::try_next might erroneously keep compiling after that method is renamed because TryStreamExt is still in scope.

created time in 2 months

pull request commentgoogle/argh

Kebab case

Can you publish a release to crates.io with this change?

benbrittain

comment created time in 3 months

startedgoogle/rerast

started time in 3 months

more