Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jean-airoldie
    @jean-airoldie
    rip sorry.
    svartalf
    @svartalf
    Do you mind if I stick with my implementation?
    jean-airoldie
    @jean-airoldie
    sure
    svartalf
    @svartalf
    Cool :) While your seems good, I think it would look better if these functions will be the Process methods
    Huh, it is interesting that std::process::id returns u32, I'm wondering what systems are returning unsigned pids
    jean-airoldie
    @jean-airoldie
    yah that what i thought too. i try_into().unwrap() just in case.
    svartalf
    @svartalf
    Oh, okay, Windows is operating with DWORD type, while unixes are working with i32
    DWORD being the u32 alias
    svartalf
    @svartalf
    Okay, merged it and I'll call it a day now
    jean-airoldie
    @jean-airoldie
    alright thx
    svartalf
    @svartalf
    Np :)
    svartalf
    @svartalf
    @jean-airoldie fyi, I merged the process::Process::memory from #121
    svartalf
    @svartalf
    Adding process::Process::net_io_counters for Linux was quite easy too, nice. #124
    As for disk IO counters, it seems to be easy too, but I'll work on it later this evening
    jean-airoldie
    @jean-airoldie
    Cool. As for the heim-metrics-proxy, it seems like I'm gonna need to write a PR because its not behaving as expected. I'm most likely gonna change the signature of the proxy fn. However I don't have time for that today.
    svartalf
    @svartalf
    You mean, a PR to metrics crate?
    jean-airoldie
    @jean-airoldie
    yes
    svartalf
    @svartalf
    Great
    Love that part when whole your work is blocked by PRs into other projects :)
    jean-airoldie
    @jean-airoldie
    yeah. i wish github had something where you can mark your PR as blocked by another PR so that when it gets closed you get notified.
    that would be super helpfull
    svartalf
    @svartalf
    True. Maybe we could write a bot and start selling it? :D
    jean-airoldie
    @jean-airoldie
    even better, we ask for read permission of private repo and we gets everyone's codebase for free
    svartalf
    @svartalf
    And sell it, right
    Btw, I'll be on vacation till the 23th August, so there will be no help from my side. I'll check this chat and email periodically though, but no github for me, time to rest for a little
    * starting tomorrow
    jean-airoldie
    @jean-airoldie
    gotcha, i'll stop spamming then
    svartalf
    @svartalf
    I think I missed that somehow
    Oh, and I will merge process disk IO counters today
    jean-airoldie
    @jean-airoldie
    cool.
    svartalf
    @svartalf
    merged #127
    svartalf
    @svartalf
    @jean-airoldie I'm back from the vacation, how the things are going? :)
    jean-airoldie
    @jean-airoldie
    @svartalf Haven't had much time to work on this I'm afraid. I will definitely have to implement this in the near future, just not right now. Probably in 1+month, if everything goes well.
    Basically I don't have any free time for a while haha.
    svartalf
    @svartalf
    @jean-airoldie yeah, I totally understand :) The good news is that there will be plenty of time to stabilize heim API, so you will not be blocked by a missing process metrics
    Stefan Lendl
    @stfl
    Hi. I am trying to build a simple search-process-by-executable function and I am trying to follow the example but the cargo fails with:
    error[E0433]: failed to resolve: use of undeclared type or module `futures_executor`
      --> src/main.rs:38:1
       |
    38 | #[heim_derive::main]
       | ^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `futures_executor`
    #[heim_derive::main]
    async fn main() -> ProcessResult<()> {
    Stefan Lendl
    @stfl
    Ok.. it builds on nightly with:
    futures-preview = { version = "=0.3.0-alpha.19", features = ["async-await"] }
    futures-executor-preview = "0.3.0-alpha.19"
    svartalf
    @svartalf
    Oh no, someone is here for reals
    @stfl well, you probably should not use heim_derive at all, as it is was intended to be used for examples only
    @stfl if you are using tokio or async-std, they are providing their own ::main attributes to be used, I strongly suggest to use them :)
    And I should mark these heim_derive::* attributes an internal somehow
    Stefan Lendl
    @stfl
    ok thanks. I will probably incorporate it into tokio at some point but for some early testing it works like that.
    svartalf
    @svartalf
    @stfl yeah, that's true, just be aware of this "issue" :)
    Stefan Lendl
    @stfl
    thanks
    svartalf
    @svartalf
    And there should be a deeper integration with tokio eventually too, but they are not finished yet with MVP, so it is kinda postponed
    Scott
    @procyclinsur

    I apologize in general due to my lack of knowledge of the issue. That being said, If I might, I would like to ask a couple of questions.

    1. I do not understand why Heim is in one repository but split into multiple crates?
    2. I am trying to implement a simple program to get the temperature from sensors, but it doesn't compile due to point 1?
      here is the code that I have.

       extern crate heim;
       use heim::common::prelude::*;
       use heim::sensors;
      
       #[heim_derive::main]
       async fn main() -> Result<()> {
           let mut snsrs = sensors::temperatures();
           while let Some(sensor) = snsrs.next().await {
               dbg!(sensor?);
           }
       }
    3. I have read the Rust manual on Attributes, and yet still do not understand what is going on the line in this LINK It doesn't seem to fit any of the 6 paradigms defined in section 7.x of the rust reference?

    All I want is a main function that prints out data from my temperature sensor.

    svartalf
    @svartalf
    @procyclinsur sub-crates are requiring different dependencies, at this point it is easier to compile it faster and enable only needed features if it is split into multiple crates
    It would be nice to have the compile error too, because so far your code looks kinda okay
    #[heim_derive::main] is creating futures executor and running the async fn main in it, but at this point I would suggest not to use anything from heim_derive crate directly and use tokio, async-std or executor from the futurescrate