AntonGepting / tmux-interface-rs

Rust language library for communication with TMUX via CLI

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Incorrect deserialization of session creation time

ypoluektovich opened this issue · comments

s.created = p.parse().ok().map(Duration::from_millis)

When deserializing session create time via SESSION_CREATED, it's treating the value as milliseconds, when in fact the value is in seconds — at least when used with tmux 3.2a.

The same would be true for activity and last_attached fields of Session (this I tested on my machine) as well as (probably, untested) for activity in Window.

Hello, thank you for using the library, for reporting this bug and fixing it in your PR.

It was changed during refactoring in developing version, you can temporary try to build with dev branch to test and see if it is acceptable for you, has no other problems or side effects for your use case:

[dependencies]
tmux_interface = {
    git = "https://github.com/AntonGepting/tmux-interface-rs.git", branch = "dev",
    features = ["tmux_latest"]
}

In dev it is returning back just an usize integer number (was not sure what is better just an integer or some Duration type of the value).

Tomorrow I’ll check it closely and think about either publishing dev as the new crate version 0.1.1 or better accept your fix first and publish it as 0.1.1.

In dev it is returning back just an usize integer number (was not sure what is better just an integer or some Duration type of the value).

Right now the code in dev is very confusing. One would need to look in the docs somewhere for the used time unit — the doc for Session.created just says "Time session created", without any information about the unit. So you'd either search elsewhere (I'm guessing nothing specifies this anywhere) or spend time and effort on making an example and testing it. I suggest either going back to Duration or at the very least specifying the time unit in the docs — no preference on my side as to which.

either publishing dev as the new crate version 0.1.1 or better accept your fix first and publish it as 0.1.1.

This is an API-breaking change, shouldn't it be 0.2.0?

Also I just noticed that there's a NOTE: u64. It does indeed sound like a good idea to make it a u64 instead of usize — or even i64 (because negative timestamps exist and time libraries like chrono would use signed values).

PR #6

accepted, merged into main, thx

This is an API-breaking change, shouldn't it be 0.2.0?

Oh, I see. Published as 0.2.0.

Right now the code in dev is very confusing.

True. Docs are almost empty too, sorry about that. Low prio. I'll try to invest some time in writing docs for future versions.

It does indeed sound like a good idea to make it a u64 instead of usize — or even i64

Just a note, basically for myself. I’ve looked into tmux sources, it seems like it uses timeval structure internally for storing the time information and uses only time_t tv_sec part of it (only seconds) for an output as a string (long long signed integer -> i64):

https://github.com/tmux/tmux/blob/bb4bc8caf4a7fa1680333a42679ca72390b60001/format.c#L3102

Sometimes it uses the second (2.) part of timeval long int tv_usec (microseconds) for logging purposes too, but it is not relevant in this case:

https://github.com/tmux/tmux/blob/6c2bf0e22119804022c8038563b9865999f5a026/log.c#L120

For future versions I trend to use basic i64 type instead of Duration at this point:

  • end user can decide how to work with it, what type or crate to use for it
  • files i/o maybe will be a bit nicer without converting it back and forth
  • Duration contains seconds u64 field and nanos field u32 unused in this case. A bit oversized.

At least I think so today.

Thank you for your contributions and explanations. I mentioned you in README.md, hope you don't mind?

accepted, merged into main
Published as 0.2.0.

Awesome, thanks!

For future versions I trend to use basic i64 type instead of Duration

👍

Thank you for your contributions and explanations. I mentioned you in README.md, hope you don't mind?

You're welcome! :)

Version 0.2 works for me, so I'm closing the issue. Thanks for prompt reaction!