Open vitiral opened 6 years ago
other sub-crates:
Sync
types, i.e. running threads. Included:
reqwest
, h2
, and probably some kind of json-rpc types@killercup thoughts on these?
Quick thoughts:
Thanks for the feedback! Ya I was actually thinking these exact thoughts. I'm almost done evaluating crossbeam-channel and was going to include ctrlc as the included library, with examples. (and just recommend some crates that could be used for posix only systems).
See the below issues for ergo_sync
. I have a feeling ergo_sync
will be beta for quite a while:
Can I register my interest for helping with ergo_term.
I was planning to attempt a platform abstraction library for terminals, but working as part of a team would increase the chance of my work being useful/getting finished.
My plan for the term library was as follows:
I would design it first as an API with the assumption that all capabilities are preset (color, cursor relocation, etc), and then panic on platforms/systems where they are not available, along with an API to get available terminal capabilities.
Then, we would want to implement this for a lot of different types of systems. Embedded systems with a serial cabel right through to ansi terminal in windows 10, but including support for old terminals on windows.
Prior art:
I'm not sure if this library aims to be higher-level, or not, but either way I have some knowledge of terminals on windows and posix, so hopefully I would be useful.
@derekdreery absolutely! I should mention that this is (in my opinion) one of the more challenging conglomeration crates -- but I think it is absolutely needed as well.
I opened #9 for further discussion. Thanks for your interest!
The following intial crates are targeted towards the following weeks:
lazy_static
,maplit
,failure
,itertools
,std_prelude
,ordermap
, etc.chrono
), signal handlingchan-signal
, (maybe) system libraries (libc
) and randomness (rand
).ergo_fs for files+directories. Some crates could berepopath_abs
,walkdir
,tar
toml
,serde_json
,serde_yaml
,configure
, shell variables (shellexpand
), etcSomething that the ecosystem isn't quite ready for but is probably close
tabwriter
,pretty_tables
,termstyle
, etcI'm considering not exporting
std_prelude
, and instead each crate exports the relevant traits/types in it's own prelude. I think this is the right approach.