Comments (10)
It's a good point. However, people generally require these pieces of information in a human readable format, so a String
seems more accurate in here. However, I'm not against keeping Vec
s instead, I just need to think what solution is the best.
from sysinfo.
I don't mean to be contrary, but the operating system itself really does not provide these data in a "human-readable" format. There's no guarantee that filesystem or environment entries are in any text encoding (much less UTF-8). It's convenient when the bytes in a process' name, executable name, or environment are ASCII or UTF-8, but since this library can't guarantee that condition, we should leave it up to consumers to convert to strings if they want. There are meaningful processing steps performed on paths and environments that rely on byte values (such as ASCII slashes, colons, and NULs), but these are really byte operations, not string operations.
Those of these values which are semantically paths would be reasonable to represent as PathBuf
s instead of Vec<u8>
, but the environment is really just a binary blob.
The alternative would be to have two variants of accessor functions where one returns Option<String>
, Result<String,Utf8DecodingError>
, or String
-but-maybe-panics and the other variant returns Vec<u8>
/PathBuf
, but I don't think it makes sense for every library returning binary data to also have variants of every function that attempt string conversion. It doesn't improve convenience significantly, and has the cost of roughly doubling API size and bloating the binary.
from sysinfo.
Program's name, environment variables, the program's path and the current working directory are human readable and meant to be. Based on that, which thing(s) do you think should remain a bytes array?
from sysinfo.
What text encoding can a human use to read them? Very often, UTF-8 happens to work, but the operating system does not guarantee that it will, and users of this library will run into cases where programs have non-UTF-8 filenames and environments. We can't just say "then don't do that", because non-UTF-8 filenames and environments are fully allowed by POSIX and the other relevant specifications, and used on occasion by existing programs.
Is there a reason we should not store paths as the Rust PathBuf
type and environment variables as a type with the same semantics as char*
(e.g. Vec<u8>
, or OsString
which is what libstd uses for environment vars)? Storing these as String
means the library is unable to represent some of the filenames and environments it encounters; at the moment in panics in these cases. We can add UTF-8-checked String
accessors for convenience, but will need to decide whether these should panic like the library does now or return Option
s.
from sysinfo.
Your arguments make sense. Well, then we should just provide some methods to have some conversions.
from sysinfo.
I'm currently stuck for lack of access to an OS X machine against which to develop that side of my suggested changes (I tried to get a VM working but haven't managed). I can upload a guess at working code to a fork, but I don't want to have to rely on a github-based CI service to see if my syntax in the OS X code is correct, much less my types and runtime behavior.
from sysinfo.
No problem, I can just update your code on OSX.
from sysinfo.
Sorry, really dropped the ball here, but I finally got around to this. I've made a PR which works well on Linux, but I expect type errors on the OS X side. Feel free to either accept the PR, work atop my commits first, fix the patch in review, or whatever's easiest.
from sysinfo.
I'll merge it on a temporary branch and then work on it.
from sysinfo.
Fixed by #83.
from sysinfo.
Related Issues (20)
- OpenCloudOS get cpu_usage fail HOT 3
- Calling `Components::refresh_list` multiple times on M-series Mac causes segfault HOT 15
- Possible memory leak in `Disks::refresh_list` HOT 17
- Make Windows support optional HOT 2
- `test_refresh_memory` fails on macOS HOT 1
- Global cpu usage is occasionally smaller than the sum of all process CPU usage HOT 2
- Get HW ID for each Disk HOT 3
- No temperature output for Mac M3 Pro HOT 4
- Incorrect CPU arch HOT 1
- Refreshing multiple processes on macos leads to invalid cpu usage HOT 3
- Add more hardware info: PCI devices, graphics adapters, CPU instruction sets HOT 1
- missing info from cmd of a process HOT 9
- cgroup free and available memory HOT 2
- Global CPU usage is incorrect on Mac M3 Pro HOT 2
- Process parent is `None` if the target process of `refresh_process_specifics()` is a WoW64 process HOT 1
- global cpu info HOT 3
- Add OpenBSD support HOT 3
- Typo in documentation of `Networks::new_with_refreshed_list()`
- International Money Transfer to Ghana: Key Developments and Benefits
- Does system::processes_by_exact_name() return all threads on Linux? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sysinfo.