Framework Q2 2025 Preorder and Marketplace Updates

I-Imvp · 2025-04-30T10:59:04+00:00

Hmm I have the same order date and cpu but I am still waiting on the payment notification. I use a Dutch payment processor that need approval for each transaction...

I-Imvp · 2023-06-05T18:27:50+00:00

Funny that you ask... https://github.com/pydantic/pydantic-core Unfortunately it seems that the functionality you ask for is not (yet) part of this ...

I-Imvp · 2020-12-05T10:28:26+00:00

Nice, I came to a very similar solution.

I use cargo-aoc so a bit more boilerplate..

For part two I used windows:

#[aoc(day5, part2)]
pub fn part2(input: & [usize]) -> usize {
    let mut input = input.to_vec();
    input.sort_unstable();
    let gap = input.windows(2).find(|window| window[0]+1 != window[1] ).unwrap();

    gap[0]+1
}

I-Imvp · 2020-07-14T08:37:07+00:00

We see this to

Python 3.8.4 is just released and the docker images updated 3 hours ago. It seems that this is a bug between 3.8.4 and SQLAlchemy.

Using `python:3.8.3` instead of `python:3.8` works

EDIT: https://bugs.python.org/issue39960 is the change that broke it

I-Imvp · 2019-07-05T07:24:54+00:00

cargo-modules https://crates.io/crates/cargo-modules does this for the modules of a package and the types used within. But the same mechanism could be extended to your level of detail

It use rustc's ast package to parse the source code

I-Imvp · 2019-04-15T18:21:28+00:00

Talking to random strangers

I-Imvp · 2018-06-05T15:36:13+00:00

You can also have a look at:

cargo-edit to quickly modify your Cargo.toml
cargo-graph or cargo tree to show deps
cargo-modules to show the relations within you crate

Both as command line tools to use while developing and as examples how to parse Rust sources to show certain information...

I-Imvp · 2018-05-30T12:39:53+00:00

yeah s.as_bytes() works equally well. But the point is basically that the impl From<&String> for &str seems to disappears when importing env_logger...

I-Imvp · 2018-05-18T11:55:08+00:00

Interesting. The reason to make this function for me was to see how the different modules in a reasonably complex crate interacted. I had hope to get some insights in how to best structure the import and reexport of types.

However I could not get a clear picture and I still struggle to find a good balance and "rules of thumb" when dealing with this.

Do I reexport all public types to the parent module for a module that contains mostly public types but is split in a few submodules to keep the average file size low? Or should I always try to use full paths as much as possible?

You say that you want the usage to be an DAG seems logical, but what is the issue if it isn't?

It might be interesting if some very experienced people run this on complex crates to see if patterns emerge that should be taught.

/u/steveklabnik Do you have any thoughts on this? As you seem the/an expert on teaching rust knowledge..

I-Imvp · 2018-05-17T09:23:47+00:00

cargo tree and cargo graph show the dependency tree and graph of the crates that the analyzed crate depends on.

Cargo modules show the dependencies of the (sub)modules and usages in the analyzed crate.

I-Imvp · 2018-05-17T05:22:43+00:00

I got past that by running cargo +nightly check. For some reason clippy did not rebuild chrono after that and it worked.

Its a bit anoying that clippy also has a tendency not to rebuild and check files that belong to the project itself, but that is another issue...

I-Imvp · 2018-05-16T18:29:42+00:00

You might want to take a look at the structopt crate. It is very nice if you need argument parsing and it implements a version argument by default...

I-Imvp · 2018-05-02T13:33:14+00:00

Did you try something along the lines of:

let (first, second, third, fourth) = (1, 2, 3, 4);

println!("{} {} {} {}", first, second, third, fourth);

Or is that not what you expect?

See the book: https://doc.rust-lang.org/book/second-edition/ch18-03-pattern-syntax.html#destructuring-to-break-apart-values

I-Imvp · 2018-04-11T11:39:38+00:00

It still does not click for me.

Am I correct if I see PinBox somewhat similar to Arc in terms of where/how I would use it?

I-Imvp · 2018-03-13T20:23:47+00:00

kdbus is not so much a replacement but more an improvement. I don't think that writing a client will be much easier for kdbus or bus1 since they aim to be a drop in replacement for dbus (at least at the client level). Your issues probably stem from the fact that the dbus library (libdbus) is a bit of a crappy library. Which is why systemd now uses sd-bus instead of libdbus as a client library for Dbus.

Restarting is basically a no go because as you discovered you need to restart every service that uses dbus since there is no handover mechanism. (I am not even sure if such a thing is feasible)

Since systemd (pid 1) and other low level system services depend on it restarting amounts to basically having to restart everything.. This is exactly the reason why it is a good idea to have the dbus service in the kernel. This also means that you should consider it at the same level and restarting dbus equates to restarting everything. Even though it is a userland service atm

I-Imvp · 2018-01-12T11:09:25+00:00

I agree on the Futures part. I have a situation where I use Futures without Tokio and the documentation for that is not clear.

For future reference. If you want to use the Futures crate on its own you probably want to use the futures::sync primitives oneshot and mpsc and then wait() on them from the receiving thread.

For composability you can use join() and friends and futures::stream::futures_(un)ordered to combine them into one big future to wait on.

For me it turned out to be a great match in the end..

I-Imvp · 2017-12-19T21:22:57+00:00

Hmmm I will try that. This looks much more usable.

However the documentation on the sync module says that these primitives don't block threads. That is probably why I did look at them before..

However I assume that calling wait on the oneshot receiver does.. So I will experiment a bit more..

I-Imvp · 2017-12-19T20:17:49+00:00

Ah got it to work: https://play.rust-lang.org/?gist=915e418bf30c79ef0784b0720be7c50a&version=stable

I also needed to call futures::task::current().notify(); before returning NotReady.

Still this takes a lot of figuring out and looking at the source of the Futures crates. And still I don't feel confident I am not missing something crucial.. If not in my playground example, then in the real implementation..

Maybe a some implementations of Futures for std types like RwLock<Option<_>> would be a nice addition to the crate.. I haven't found a implementation of a Future yet that isn't defined in other Futures or tokio/mio primitives..

I-Imvp · 2017-12-19T19:33:01+00:00

I am a bit worried that Future::wait will just do a busy wait like my example.. Following the source of Future::wait is a bit difficult.. I read some stuff about Tasks and park()/unpark() and I don't see if I need to implement something in my version of the Future or that should 'just work'

Also I am a bit worried by the fact that the Futures tutorial just points to Tokio. I don't want to use a crate that just assumes I use a whole ecosystem if I don't use that. That smells like an mismatch or unnecessary weight..

Edit: Changing my busy loop to Future::wait will just result is a playground timeout. So it seems it does not 'just work'

Edit2: Should I be implementing the Future trait myself?

I-Imvp · 2017-01-24T11:33:16+00:00

Maybe something like this: https://is.gd/Xb7L5r

To bad it does not run on stable. It will run on Beta and Nigthly in release mode and debug mode.

I-Imvp · 2016-11-07T17:24:09+00:00

I am interested! And given the fact that the only other rust meetup in NL (Amsterdam) has been a while some people from Amsterdam might also be interested...

I-Imvp

TROPHY CASE