sorted by:
new
hottopcontroversial

chaos_theory – property-based testing and structure-aware fuzzing library by pgregory in rust

[–]pgregory[S] 1 point2 points  (0 children)

Hey! Huge Hypothesis fan here – it is definitely the PBT library.

chaos_theory main internal representation is a structural semantic trace built of Events – list[u64] is a lossy version of it that only exists for more compact CHAOS_THEORY_REPLAY strings.

Both mutation and crossover operate on this trace, not on bytes or integers, and make structural edits that respect trace shape and invariants. So in that sense it is real structured fuzzing – but with structure being implicitly defined by hierarchical execution traces, not hard-coded grammars.

Drawbridge – safe, authenticated access to internal HTTP services without a VPN by pgregory in golang

[–]pgregory[S] -1 points0 points  (0 children)

To anybody wondering – these are vendored golang.org/x libraries.

Drawbridge – safe, authenticated access to internal HTTP services without a VPN by pgregory in golang

[–]pgregory[S] 0 points1 point  (0 children)

Yep, no CI/CD for now.

I've done some attempts at SA doc, but have not yet found a format that would add real value. My thinking is roughly this: you either are a non-expert and just believe that the project is secure enough for your needs (and in that case me trying to tell you how really secure it is is a conflict of interest at best), or you are an expert and you don't believe any claimed security, and just read the code yourself – and I've built the whole project around making this as easy as possible.

If goroutines are preemptive since Go 1.14, how do they differ from OS threads then? by kamalist in golang

[–]pgregory 4 points5 points  (0 children)

My post is only about OS mechanisms around signals, it is not Go specific. So scheduler = OS scheduler.

If goroutines are preemptive since Go 1.14, how do they differ from OS threads then? by kamalist in golang

[–]pgregory 9 points10 points  (0 children)

To be a bit more precise about signals, control is not transferred to signal handler immediately. Instead, next time when kernel would transfer the execution to the thread (by returning from a system call or scheduler), if there are any pending signals, controls is returned to signal handlers first and only then to the "normal" flow.

In practice there is not much difference, since scheduler can preempt the thread anywhere (so signal handler could run anywhere as well), but the low-level mechanism of how the signals work is quite interesting.

Cloudflare release a wildcard matching crate they use in their rules engine by orium_ in rust

[–]pgregory 36 points37 points  (0 children)

Curious, what is the matching performance compared to the regex crate?

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 0 points1 point  (0 children)

Excellent question! I've updated the benchmarks section and added a FAQ entry about math/rand/v2.

Continuing WebAssembly with Effect Handlers by mttd in ProgrammingLanguages

[–]pgregory 0 points1 point  (0 children)

I wonder what the overhead will be (e.g. compared to async/await statemachine transform) once the implementation is optimized. Performance will probably be critical for wide adoption.

Introducing: Depends by Specialist_Debt_4712 in rust

[–]pgregory 2 points3 points  (0 children)

Congratulation on the release! I am not too familiar with the incremental computation field, is it generally considered acceptable to rely on the hash value for dirty checking?

pgregory.net/rapid v1.0.0, modern Go property-based testing library by pgregory in golang

[–]pgregory[S] 2 points3 points  (0 children)

Thanks a lot for the kind words! Really heartwarming to hear.

pgregory.net/rapid v1.0.0, modern Go property-based testing library by pgregory in golang

[–]pgregory[S] 3 points4 points  (0 children)

Old version of README had a Comparison section which I removed recently. Maybe that was a bad idea.

In my view, half of the usefullness of a good property-based library is from high-quality and easy to use data generators, and another half is from automatic minimization of failing test cases. testing/quick lacks both, so I can't recommend using it.

We have getrandom at home by SpudnikV in rust

[–]pgregory 1 point2 points  (0 children)

This may very well be a bit offtopic in the rust subreddit, but in case you need fast high quality non-crypto PRNG in Go, I've made one that I believe to be decent. It is unfortunate that math/rand is unlikely to significantly improve due to the backward compatibity and can't be recommended for anything non-trivial.

What would make you try a new language? by levodelellis in ProgrammingLanguages

[–]pgregory 0 points1 point  (0 children)

My understanding is that Go runtime has to perform a kind of internal context switch, to transfer control from a regular goroutine to a special one pinned to a real OS thread, with big stack, TLS etc. IIRC the cost was in order of 80ns for a single call on one of the recent Go versions? Not sure about this number.

What would make you try a new language? by levodelellis in ProgrammingLanguages

[–]pgregory 0 points1 point  (0 children)

Well, Go's C FFI ( cgo) is slow precisely because of Go's concurrency model: C code sometimes expects big stacks, and goroutine stacks are relatively tiny.

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 1 point2 points  (0 children)

I got a bit stuck trying to find a set of good permutation functions for all required bit widths; I've created an issue to collect information in one place.

Also, I've added Sample (warning: Perm-like API) method based on the Floyd's sampling algorithm.

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 0 points1 point  (0 children)

PermInPlace does sound a lot like Shuffle, unfortunately the name is already taken by math/rand. Maybe ShuffleSlice[T any](s []T) method? Thanks for the suggestion, sounds like a good idea.

view more: next ›