Live data from Hacker News

Show HN: Unbug – Rust macros for programmatically invoking breakpoints

github.com

1–10 of 41 posts

Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#1
This project is inspired by some of the asserts in Unreal engine.

Due to reliance on core_intrinsics it is necessary to develop using nightly Rust, but there are stubs in place so a production build will not require nightly.

I recently released version 0.2 which includes no_std support and adds optional log message arguments to the ensure macro.

Show HN: Unbug – Rust macros for programmatically invoking breakpoints
github.com

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#3
post #2

What does nightly mean ? I hate that you could not know a specific version of a nightly.

The master branch of the Rust repo is built every night and distributed. That's a nightly build. Most people are on the stable release, which is updated every six weeks.

A minority use the nightly build for various reasons: a feature that hasn't reached stable yet, or because they want to help test the nightly releases and prevent bugs from reaching stable.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#5
post #3
post #2

What does nightly mean ? I hate that you could not know a specific version of a nightly.

The master branch of the Rust repo is built every night and distributed. That's a nightly build. Most people are on the stable release, which is updated every six weeks. A minority use the nightly build for various reasons: a feature that hasn't reached stable yet, or because they want to help test the nightly releases and prevent bugs from reaching stable.

Is it a minority? Are there stats posted for this?

Only recently have I had some projects switching to stable after their required features stabilized.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#6
You could potentially build on stable Rust by emitting the breakpoint instructions yourself, at least on popular platforms. For instance, `core::arch::asm!("int3")` on x86, or `core::arch::asm!("brk #1")` on ARM.

Also, this is providing motivation to want to stabilize a breakpoint mechanism, perhaps `core::arch::breakpoint()`. I'm going to propose an API Change Proposal (ACP) to the libs-api team to see if we can provide that in stable Rust.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#7
post #4
post #2

What does nightly mean ? I hate that you could not know a specific version of a nightly.

You can pin versions with the rust-toolchain.toml file you need to be using Rustup afaik. Nightly is just the daily builds.

I assume any "nightly" version would work in this context, meaning it would not refer to a version from a year ago, as it would have already been made stable by that point, right?

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#8
post #5
post #3

Earlier quoted context omitted.

The master branch of the Rust repo is built every night and distributed. That's a nightly build. Most people are on the stable release, which is updated every six weeks. A minority use the nightly build for various reasons: a feature that hasn't reached stable yet, or because they want to help test the nightly releases and prevent bugs from reaching stable.

Is it a minority? Are there stats posted for this? Only recently have I had some projects switching to stable after their required features stabilized.

https://raw.githubusercontent.com/rust-lang/surveys/main/sur...

89.4% of users surveyed use stable. 31.1% use nightly, but there's overlap there (e.g. I use nightly to try out new things but don't build things that depend on nightly). Only 11.5% of people say they use a crate that requires it.

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#9
post #4

Earlier quoted context omitted.

You can pin versions with the rust-toolchain.toml file you need to be using Rustup afaik. Nightly is just the daily builds.

I assume any "nightly" version would work in this context, meaning it would not refer to a version from a year ago, as it would have already been made stable by that point, right?

"nightly" versions also allow to use unstable features, and unstable features may remain so for a very long time (potentially forever) without breaking, so an old nightly could maybe work

Re: Show HN: Unbug – Rust macros for programmatically invoking breakpoints

#10
post #4

Earlier quoted context omitted.

You can pin versions with the rust-toolchain.toml file you need to be using Rustup afaik. Nightly is just the daily builds.

I assume any "nightly" version would work in this context, meaning it would not refer to a version from a year ago, as it would have already been made stable by that point, right?

A lot of people pin a specific nightly since the feature they're depending on could change (or ostensibly it would be in stable), so they can keep working without continuously having to track nightly changes or deal with it breaking on a different system with a different nightly version.

That obviously only works for non-library uses of nightly.

Post reply on HN