I did the same thing by accident, except mine was "test", I heard murmors around about some strange message on computers in multiple schools in our district, so I fessed up immediately. Our network administrator was just mildly amused about the whole affair and no punishments were carried out.
You're thinking of a nebula. That’s the remnants of a supernova. A galaxy is an unimaginably large collection of stars. A nebula is still quite large, but several orders of magnitude smaller than a galaxy.
I didn't come across any good ones when creating this library, but if you're using VSCode, I tried my best to make the README as beginner friendly as possible. I'm open to issues and PRs if anything is unclear. I think part of the issue is that debugging is not yet very common in the Rust ecosystem, partially due to the excellent borrow checker and error messages, but partially due to immature tooling, hence I made this to promote the practice of debugging.
I can understand where you're coming from, but when programming games you generally don't want a breakpoint to be hit more than once since you are running a loop over multiple frames. So in this case the concept of ensure_once is more common, so the shorter inverse is more convenient. Asserts should be enough to get your attention and not to annoy, so orienting it this way is a deliberate choice.
Thanks, yeah I considered using the instructions directly, but I was hoping for a more cross-platform option. For my purposes, developing in the Bevy engine, nightly isn't a huge blocker. Yeah, it would be really great to just have breakpoint support in stable Rust, thanks for doing the proposal! I'll consider stable support in the meantime.
On Unix platforms, you could just raise SIGTRAP directly, it will pause the attached debugger and works regardless of architecture.
This is the macro I use for example:
#[doc(hidden)]
pub use libc as __libc;
// This is a macro instead of a function to ensure the debugger shows the breakpoint as being at
// the caller instead of this file.
#[cfg(unix)]
#[macro_export]
macro_rules! breakpoint {
() => {
unsafe {
use $crate::__libc as libc;
libc::raise(libc::SIGTRAP);
}
};
}
Interesting. Unfortunately, I'm not well versed in assembly, is there a similar trick or requirement in arm and would that include Apple silicon, or is this something specific to `int3` on x86? That may explain why it was inconsistent during my development process, I didn't think to check if the inconsistency was platform dependent.
Answering my own question, apparently `brk #1` is insufficient on Apple silicon. That results in just a trap and will prevent the debugger from continuing past the debug statement. From a bit of searching and my experiments `brk #0xF000` was the way to go instead which had the consequence of not always landing on the debug statement, the addition of a nop with `brk #0xF000 \n nop` resulted in the debugger landing on the correct statement.
I just looked through the perks on my Google One and don't see this offering. I don't see it in the premium perks either. Do you happen to have a link? Is it some kind of hidden benefit?
According to the ESA "As the orientation and direction of motion of the spacecraft triangle changes along the orbit, it will be possible to determine the direction of incoming gravitational wave sources." - From https://sci.esa.int/web/lisa/-/lisa-technology-interferometr...
https://embed.plnkr.co/mdZX6C/
It isn't just doing primes though, instead the size of the dot generated is dependent on the number of even divisors for the number at that position.