Comments (10)
This makes a lot of sense. I'll look into it π
from mdsf.
A global timeout could work!
Iβll take a look at it once I have some spare time π
from mdsf.
BTW, I think I saw you refactored and now local binary are tried before using an npx version
Yes, local binaries are ran before trying npx/bunx/deno in most cases.
I have been looking into a global timeout and it is actually blocked by the multithreading implementation in #330 since Rust does not support stopping/killing native threads π
I am going to benchmark the difference between using native (std::thread) and green threads (tokio::task) to see how big a difference it makes, if any.
I am currently expecting file io performance to be worse when using Tokio (async runtime for Rust) as described in tokio-rs/tokio/issues/3664.
I do not expect the performance of difference of command spawning to have any big impact since we are dealing with such a small amount of processes. I did find the finding of Jakub BerΓ‘nek in Process spawning performance in Rust rather interesting though.
from mdsf.
The async implementation can be tested here https://github.com/hougesen/mdsf/tree/refactor/async-runtime
This is also not a good sign for the async implementation π
from mdsf.
I'm impressed by the benchmark you made β€οΈ
from mdsf.
Okay, so I have been looking into this a bit.
I cannot see an easy way to implement a timeout, without having to refactor large parts of the tool.
Currently the way the formatter works is by creating a temporary file for each code block and then invoking each formatter sequentially on the file. In the end the file is read and the markdown file is updated.
By calling sigkill on an invoked formatter mid process we risk the formatter being stopped during a write operation, which could leave the code in a broken state.
The only way I can see to make a timeout work, is by converting the formatters to instead rely on stdin/stdout (Something like cat $FILENAME | stylua -
), but that would add overhead since each codesnippet will be written to stdin/stdout multiple times. It also has the added problem of dealing with formatters that don't support stdin as input.
from mdsf.
Ouch indeed. I might be easy
What about a global timeout then? I mean not the lintee level and display error information.
But, it might be the exact way you thought about abd I didn't get it π
from mdsf.
Thanks for checking anyway
from mdsf.
Because my issue was your code npx so my VPN protected npm repository, but I wasn't on the VPN and without timeout I was waiting for nothing.
BTW, I think I saw you refactored and now local binary are tried before using an npx version
from mdsf.
It looks like the difference between native and green threads is pretty negligible. Native threads did feel a lot smoother to look at, and impacted the overall performance of my computer a lot less. For that reason I am leaning towards not switching to green threads, and putting the timeout argument on hold.
I ran both on rust-lang/rfcs which has a lot of markdown files.
Left side is native, right is green threads.
mdsf format
mdsf format --cache
with no cache
mdsf format --cache
with cache from previous operation
mdsf verify
from mdsf.
Related Issues (20)
- Feature request: add a `--dry-run` mode
- Multithread support
- [markdown] Support "autocorrect" tool HOT 1
- [Markdown] Support "misspell"
- [Go] support golines formatter
- Add support for custom file extensions
- Add --cache argument
- Use binaries from node_modules
- Add support for composer based binaries
- Shell script for installing binary
- Publish binary to npm
- Generate manpage
- Shell completions for nushell
- Shell completions for fig
- Standardjs does not work because files are in hidden folder
- Support stdin/stdout based formatters
- Allow settings extra flags to formatter
- Setup codecoverage tracking
- Vs Code extension for format on save
- Obsidian extension
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 mdsf.