Closed ypoluektovich closed 3 years ago
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 anusize
integer number (was not sure what is better just an integer or someDuration
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 version0.1.1
or better accept your fix first and publish it as0.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).
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:
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 as0.2.0
.
Awesome, thanks!
For future versions I trend to use basic
i64
type instead ofDuration
:+1:
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!
https://github.com/AntonGepting/tmux-interface-rs/blob/1f8316a6355fca9f84b2c0bf9cd9e904d04ca014/src/variables/session/session.rs#L135
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.