michael-f-bryan / adventures.michaelfbryan.com Goto Github PK

With current playground link tests cannot find word_is_palindrome function. Need to add use super::*; into test module, I added it into this playground link for convenience.

Hi.

Depending on the situation, it might make sense to take a callback argument in the Monster::take_damage() method.

Ok. But, the code in the playground doesn't seem to work.

Isn't it supposed to loop until the play has inflicted at least 100 damage?

I tried taking out that break; near the bottom, but then it just runs for a really long time. Way over 100 damage.

I'm not sure yet, but since the post is live already, I thought I would let you know.

Cheers! By the way, I am enjoying your work and engaging with it, as you can see. :)

Hello! I'm still in the process of reading your wasm as a platform for abstraction blogpost and I love it! I actually work on Wasmer and we're super impressed with the depth of your post!

The use of Ctx::data is a bit subtle; it doesn't have to be reset on every host call if you don't want it to be, and the code:

    let mut state = State { env };
    let instance = &mut self.instance;

    // point the data pointer at our temporary state.
    instance.context_mut().data = &mut state as *mut State<'_> as *mut _;
    // we can't use the old state variable any more (we'd have aliased
    // pointers) so deliberately shadow it
    #[allow(unused_variables)]
    let state = ();

Is a bit concerning because with non-lexcial lifetimes I believe it's valid for Rust to call drop on your state here and then any access to Ctx::data would be accessing freed memory.

The way I've been avoiding this when I do this is to use Box::into_raw(Box::new(...)) and then using Box::from_raw to destroy it when I want to.

I don't have a full mental model of your system yet, I'll keep reading and then edit this post if I realize I've made a mistake!

In this post, lines like

use aimc_hal::clock::{Clock, HasClock};

are rendering as

use aimc_hal:🕰:{Clock, HasClock};

because :clock: is an emoji shortcode.

I'm not sure what the best way to prevent this would be, maybe removing enableEmoji = true from config.toml?

After using include_dir in the wild for a while, we found a couple of limitations with we convert the provided string into a path.

Is probably missing a "how" or similar after "limitations with".

let account Vec<u8> = read_some_input();

Missing a colon.

let account: Vec<u8> = read_some_input();

@Michael-F-Bryan loved your blog post on Rust Closures in FFI!
I used a very similar technique about a month ago to implement Rust callbacks for Redis modules:
https://github.com/RedisLabsModules/redismodule-rs/blob/master/src/context/timer.rs

Hello, really nice article, but there is one important point!

According to Nomicon https://doc.rust-lang.org/nomicon/ffi.html#ffi-and-panics

A panic! across an FFI boundary is undefined behavior.

I don't say that article should dig so deep, but please add Note/warning that in real use all functions that are called from FFI should use catch_unwind and report errors to native code in other way.

Taking into account that it could be used with any user-provided impls of Write, that is fairly possible to encounter panics.

P.S. Rust's catch unwind is fairly cheap and creates small overhead in case no panic actually happen,

From the Iterators installment:

We actually miss the top two Fibonacci numbers using the above Iterator implementation,

I don't believe this is true: the playground emits all the Fibonacci numbers up to F₄₇, which is the greatest one less than 2³². Possibly this is a stale note left over from an earlier draft?

Nice Rust article @Michael-F-Bryan. With regards to the original goal though, is this not that thing in the lpass client?

lastpass/lastpass-cli@a4532a9

This change adds the ability to retrieve attachments for secure notes.
The lpass show command now shows attachment ids and filenames if
a secure note has attachments. The attachment id can then be passed
to lpass show acct --attach=attachid which will either print the
attachment (if non-binary) or offer the ability to save.

As others have already said, thanks for providing this tutorial. It's been very helpful.

Just a minor issue: the example cargo run commands load different libplugins_random.so builds (target/release vs. target/debug):

$ cargo run -- ../target/release/libplugins_random.so random
...

cargo run -- ../target/debug/libplugins_random.so random
...

Although I assume it doesn't make any difference in practice, the inconsistency adds potential for confusion. To remove any ambiguity, it might be worth prefacing these examples with instructions for (re)building the executable and libraries.

Very helpful article! Thanks for writing it, clarified quite a few thoughts I had in my head.

Quick list of awkward phrasing for you:

• "The trick is works because"

Something I struggled to understand as well is where ::vtable:: comes from here:

            base: FileHandle::vtable::<W>(),

It's right after, but I thought I'd call it out as it confused me for a bit.

AND! There is in fact a thin_trait_object crate! I'm using it, but it has some things that need improving.

When the post is viewed on a device with a narrow enough screen, the SVG takes up more horizontal space than the viewport has. This makes the page scrollable in the horizontal direction. Everything else scales nicely.
The SVG can be found under the "Draw pretty pictures" heading.
The following snippet fixed the issue when I inserted it with Firefox Developer Tools:

svg { max-width: 100%; }

In Dark Mode:

In Light Mode:

Hi Michael,

I really loved your post on implementing ArrayVec using const generics. Here are a few typos I noticed:

1. In the code snippet for the pop implementation, in the doc test comments, you have
   /// # use const_arrayvec::ArrayVec;. Specifically, the # seems out of place, though I suppose that could also could have some meaning in doc tests that I'm not aware of.

2. In the code snippet for the truncate implementation, there's no use core::slice; at the top of the snippet when there should be one to use slice::from_raw_parts_mut().

3. In the code snippet for the From trait implementation, the usage of mem::forget(other); doesn't work unless there is also a use core::mem::{self}; at the top.

4. The code snippet for the Drain trait isn't properly indented.

5. The impl Iterator for Drain code snippet has some typos in its comments that are not easily discernible.

6. It looks like you have the implementation for size_hint for Drain in two separate code snippets: one in the Iterator for Drain snippet and again in the ExactSizeIterator snippet.

7. The code for the Drain struct looks like it needs to be updated. There are some fields you use later on in other snippets that make use of fields on the Drain struct that you didn't have defined in the initial snippet.

8. There is no use core::iter::{DoubleEndedIterator, FusedIterator}; statement in any of the snippets when you start implementing Drain.

9. Not sure if this was intentional or an oversight, but the impl Drain code snippet at the very end is never really talked about, yet you elude to it by showcasing some of the code, but not all of it.

Anyways, sorry if this comes off as overly pedantic, but I really like this post and would like to see it in as polished a state as possible. Cheers!

Great post! I had a few minor comments, none of which are really problems, but here they are:

1. Consider IntoIterator::into_iter(0..5) instead of (0..5).into_iter(). It's minor, but emphasizes that it has to be the trait, not an inherent method nor something reachable via auto(de)ref.

2. I love the use of ? in next to handle the ending condition. There's a subtle beauty to it.

3. There are a few reasons the pointer version is good:

• It's smaller to have two pointers instead of pointer+len+index
• It's better to have two pointers instead of pointer+len because with pointer+len both need to be updated on each iteration step -- sadly this one makes the beautiful slice patterns version suboptimal.
• It's more like how C++ does slice iterators, so it's likely that more work has been put into optimizing it
  (Note also that the "real" slice iterator uses NonNull<T> to allow for niche optimization. Of course the slice versions get that automatically.)

Would it be possible to add an RSS/Atom feed to the website? I'm not familiar with Hugo, or I would look into it myself. I'm hoping it's an easy addition for someone who's already familiar.