> Built in remote development support (inspired by VSCode Remote Development)
Well... This has me intrigued. This is basically the only thing that keeps me on vscode.
Well... This has me intrigued. This is basically the only thing that keeps me on vscode.
Lot of garbage about loading font config from /etc/fonts/conf.d/... and then:
memory allocation of 18446744073709551615 bytes failed
Aborted (core dumped)https://github.com/lapce/lapce/issues/9#issuecomment-9935004...
Yes.
> Is there a Rust build flag that would catch this behavior?
Runtime overflow checks (resulting in panics on over/underflow) are enabled by default in debug builds, but can also be enabled for release builds, or disabled for debug builds: https://doc.rust-lang.org/cargo/reference/profiles.html#over...
Additionally, you can use `Wrapping<T>` or `wrapping_sub` when wrapping is intentional, or `checked_sub` and explicit edge case handling when you want checks regardless of general build settings.
EDIT: that said, that's for integer overflow. Sibling comment references https://github.com/lapce/lapce/issues/9#issuecomment-9935004... which appears to:
1. Have a floating point div by zero.
2. Truncate when casting +inf floating point to integer.
Standard library & language checks won't catch either, although it'd be easy enough to roll your own checked math floating point type wrappers / conversion methods that would, or use an existing crate (e.g. using https://docs.rs/az/latest/az/fn.checked_cast.html to go from f64 -> usize instead of the `as` keyword would've caught #2. Since `as` is truncation-bait, some people prefer using the From/Into traits (infalliable, nontruncating) or TryFrom/TryInto traits (falliable, checked) as a matter of habit, avoiding the `as` keyword. However, neither of those traits cover f32 -> usize.
So maybe if you want a keypress that responds quickly you should press that key a few times, wait for the editor to respond, delete it, then press it again and you'll see how fast it really is. Seems to me this is tied in with the "lightning fast" claims here and the sneering dismissals in the comments "that doesn't mean ANYTHING"; it's a secret message which means "not heavyweight laggy Java". It's the Python-to-Java's-boilerplate, the Agile-to-Big-Design-Up-Front, the Go-single-binary-to-Python-virtualenv, a calling card rather than a specific performance claim.
[1] https://codereview.stackexchange.com/questions/152733/dijkst... (the answer is otherwise very detailed and interesting)