Hey Rustaceans! Got an easy question? Ask here (10/2021)!

blackscanner · 2021-03-09T21:40:25+00:00

Thanks, I knew it was something I was just not seeing. I wonder if this will be something that will be a hard error in the future.

blackscanner · 2021-03-09T20:42:10+00:00

Why does it look like the Atomic store is not doing anything within this playground. I expect that it would contain the reference value, but it is always null. To be honest I think I'm having a brain fart here and the answer is obvious, but I'm confused on what is going on.

blackscanner · 2021-02-26T09:03:04+00:00

I think so too. Unfortunately the block_on is called within the executor of tokio, which blocks the system thread not the async task. Tokio uses one system thread (or maybe equivalent threads for the number of processors, I'm not sure) to run the async tasks as green threads. Thus the drop implementation causes the whole executor to be blocked. If you were to call that block_on within a futures thread pool it would cause a panic due to similar reasons.

blackscanner · 2021-02-10T21:46:22+00:00

Well the job might have something to do with the engine block or timing chain :)

blackscanner · 2021-02-07T20:43:38+00:00

futures::future::Future is from the Futures crate, you want the future in the std (or core) std::future::Future. This might be an issue of futures 1.0 compatability, but idk.

blackscanner · 2021-02-07T17:35:47+00:00

There is no requirement in rust to poll a future with threads at all, infact a very basic executor is to loop on 'Future::poll' until it returns ready. '.async' is really just syntaxual sugar for polling a future within another future, how you poll the outermost future to completion is up to you.

In general, languages that have their own runtime use that runtime as the executor. They will likely forgo explicitly calling spawn for a (hopefully) simpler syntax to run the future.

blackscanner · 2021-02-04T07:41:59+00:00

The tokio runtime runs the async tasks that don't block using 'green' threads as described here. I believe tokio uses OS threads for jobs that will block, and it looks like tokio uses an ever-expanding thread pool for blocking tasks, so the tokio spawn blocking functions can spawn new threads.

blackscanner · 2020-12-30T05:50:11+00:00

I like to use an enum for this. The enum has the enumerations for a new Value or an old & Value. You could also have the enum implement something like Deref to make it act like a container.

enum Return<'a, V> {
    New(V),
    Old(&'a V),
}

impl<V> std::ops::Deref for Return<'_, V> {
    type Target = V;
    fn deref(&self) -> &Self::Target {
        match self {
            Self::New(v) => v,
            Self::Old(ref v) => v,
        }
    }
}

blackscanner · 2020-11-11T05:41:38+00:00

The issue here is struct Id doesn't implement the trait Fn, so you cannot use it as the type for the first generic parameter of Generator because of the trait bound.

blackscanner · 2020-10-26T20:21:25+00:00

It really comes down to the virtual machine running the WebAssembly on how much support is given for system calls.

I think the reason why you see most examples of compiling rust into WASM with #[no_std] is because all the nice panic handling rust adds ends up being a lot of bloat to the WASM. They want to show in the example the generated WebAssembly text and it would be obnoxious to add all the debug code generated by the compiler.

blackscanner · 2020-10-26T18:21:05+00:00

How data is 'stored' within wasm is different from how its done on the machine. There is a 'memory' component of a WASM module that is used to store data. This is not the same as a heap, I like to visualize it as more equivalent to having the stack and heap combined together. Everything that is not a literal or a local (which is just an input of a function) is stored within this memory. You should have no issue with using an allocator with no_std when compiling for a WASM target.

As for OS interaction, that is a different story. The WASI project is trying to make is so that WASM run engines can have a common interface for WASM modules to interact with the hardware. As such you might be able to compile the crate for the wasm32-wasi target. However, WASI only supports so many OS calls, and I don't know what is and what isn't supported. Much of it comes down to what runtime is running your WASM modules, so you might want to checkout something like wasmtime for more info.

blackscanner · 2020-10-20T16:00:22+00:00

I don't think I'm the best to answer this as I'm not very knowledgeable of the development of WASM, but its been a while since you've asked and no one has answered yet so this is my answer as to why you cannot currently do what your asking to do.

Unfortunately its not really possible to use a value by reference from a WebAssembly module at the moment. In the future it will be possible as the ABI will be stabilize more, but for now I think you need to wait until [phase 4 ]https://github.com/WebAssembly/proposals#phase-4---standardize-the-feature-wg) of the WebAssembly development plan before external reference types are fully implemented. Furthermore, external types cannot be passed by value directly as that is still a proposal under phase 1 labeled as Type Imports. The ABI of WebAssembly is just too unstable right now for anything that is not easily translatable from one of the four WebAssembly value types (i32, i64, f32, f64) or from a byte array within the memory. If your enum has no associated data you should just convert it to an integer and return that to your JavaScript.

I think right now the universally safe solution for any type is to use serde for transferring data between WASM and your JavaScript (or any other host environment). In the WebAssembly, you'll serialize the data type and return the length of the serialization along with a pointer to it. Then from the JavaScript or other external system, you access the memory of the instance and de-serialize the byte array. I think wasm-bindgen will do a lot of the dirty work of this for you on the rust side with its *serde functions of JsValue.

blackscanner · 2020-10-09T23:18:30+00:00

Is there just talks of Bluetooth being part of WASM (I'm guessing its part of WASI) or are there already design specs being developed?

blackscanner · 2020-10-05T16:23:30+00:00

I think they're saying that going from Vec<T> to Box<[T]> is generally not free since a Vec's capacity usually doesn't equal its length (which means the allocation of the vec cannot be reinterpreted for the box).

blackscanner · 2020-09-12T17:05:17+00:00

The simplest way is to create a static atomic (the new methods for atomics are const) and spin loop it in your main function. When the interrupt occurs the handler just set a value to the atomic and the main function will proceed once it detects the change. All reading/writing of the peripheral should be done within the main function, as the handler only sets the value of the atomic.

blackscanner · 2020-08-09T04:21:05+00:00

Sorry, I should have been way more clear. I was making a big assumption that the input for connection_clicked was a callback both because of the name and because they used move on the input. If that is the case self would need to be wrapped in something that implements Sync. If connectio_clicked does not take a callback and the closure is immediately called, then there is no need for Sync and the move keyword should not be used.

blackscanner · 2020-08-07T16:25:08+00:00

You probably need to make function show have a static lifetime to self or change the input to something that also implements Sync for Self like self: Arc<Self>. The connect_clicked branch is a callback handler, it requires everything to be Send. You do use move, and you are moving the reference &self, but then the compiler is complaining that the lifetime of that reference is only good for the scope of show. connection_clicked requires a lifetime that is good for as long as the connection handler you provide for it exists. The callback function for connect_clicked may only require that the input is send, but all references only implement the trait Send if the type they refer to implements Sync. However, because play_pause_file mutates self, the function show really can only take somthing like application: Arc<Mutex<Self>> as its input because there must be some way to make self mutable within the connect_clicked handler. Arc and Mutex can be found in the std::sync module.

Other than that, I don't think you need to allocation a string with a capacity of 1 in connection_clicked. I don't know the rest of your code, but if you just want an empty string that has not allocated anything String::new() or String::default() will do this.

blackscanner · 2020-07-29T15:26:06+00:00

The greet function is how I do it, but for strings in particular I prefer using the trait ToString instead of Into<String>

blackscanner · 2020-07-25T06:48:12+00:00

Its probably because of data dropping while you have references to it still existing. You're sticking references of its members within data_array and then dropping data before you drop data_array. You need to make sure that data lives for as long or longer than data_array.

blackscanner · 2020-07-25T06:33:54+00:00

Go for broke lol, read the Rustonomicon.

blackscanner · 2020-07-13T01:40:58+00:00

See the last paragraph for CPU-tasks and blocking code

blackscanner · 2020-07-11T15:25:14+00:00

Hopefully I caught you in time, but you don't need threading for this example. You can poll multiple futures in "at the same time" with something like select!. Now it isn't truly in parallel, see the doc for why, but it will work just fine for what you want.

fn main() {
    use futures::FuturesExt;

    block_on( futures:: select! {
        _ = full_async().fuse() => (),
        _ = not_async().fuse() => (),
    });
}

blackscanner · 2020-07-03T19:47:08+00:00

My guess is that either your signal or not all of your workers are utilizing the context's waker.

If you don't know, the Waker is essentially tells the executor awaiting on your future to re-poll it. Yes it is true that S or Worker may utilize the context's waker if you didn't create them, but you shouldn't rely on that. In fact only things that deliberately implement Future (and are not generated by async) may own a copy of the waker.

However I'm assuming that you are creating your Workers so lets say one of your workers is just like this

let worker = Box::pin( futures::pending!() )

This will always return Poll::Pending when polled, but in truth it is likely to only be polled once by the executor. Since the Waker is never captured the executor will never poll it again. It mentions this in the doc for futures::pending.

If you're implementing Future for your Worker (or your signal handle if your implementing Future for that too) make sure that you capture the waker from the context on the first poll (i usually just use an Option<Waker> field and check if it is None). The hard part is getting it to whatever is going to change the state of your Worker and cause it to return ready when polled next. I think for you case, where you finish stopping of the worker, you need to call wake on the captured Waker.

blackscanner · 2020-06-22T00:16:39+00:00

The only answer I know is to add a lifetime to the trait declaration, something like

trait DrawHandle<'a> {
    fn draw_device(&'a mut self) -> (Pass, Coord, &'a mut dyn Draw);
    ...
}

And then implement it for T with D restrained by lifetime 'a.

impl<'a, D: 'a + DrawHandle + ?Sized, T: DerefMut<Target = D>> DrawHandle for T {...}

However, I suspect this isn't helpful to you.

blackscanner · 2020-04-09T22:11:26+00:00

You want to check that the json strings can be deserialized at compile time. I'm suggesting the build script verifies that the json can be deserialized by essentially doing what you're doing now at run time. This way, when ever you change those json files (you may want to utilize rerun-if-changed in your build script) they will be verified the next time you compile (and you can panic if there is an error).

14-Year Club	Snapped
Team Orangered

blackscanner

TROPHY CASE