We've fixed a bug (https://github.com/byorgey/MonadRandom/issues/53) in the MonadRandom package (https://hackage.haskell.org/package/MonadRandom) which could have *extremely rarely* caused it to crash when choosing from a weighted distribution with certain adversarial weights. How rare, you ask? So rare that I would be flabbergasted if it has ever actually happened. Still, fixing it was the right thing to do on principle.
The fix preserves the exact same behavior in almost all cases (i.e. exactly the same sequences of random numbers will still be generated given the same starting seeds) --- except that, again, *extremely rarely* it could generate a different number than before (even in some cases where it would not have crashed).
So, should this be a minor or major version bump? Discuss!
fromListMay takes Rationals as input but uses Double for drawing a random number. This may theoretically result in errors. For example consider drawing weighted from [('a', w)] where w = let i = 55...
For Haskell packages published on Hackage, do you prefer version bounds on dependencies to be narrower or wider?
narrow ~ “We have tested that the package builds with dependencies that fall in this range”
wide ~ “Things are very likely to break if you use a version outside of this range, but we haven’t necessarily tested every version in it”
Case in point, I’m considering for agda2hs whether to bump the bound on base to only include the versions we actually test on CI, or to also include older versions that might still work but aren’t currently tested.
@feld good question!
i think we automatically package all #haskell packages from #hackage and some #stackage (18k) and all #Rpackages from #CRAN (27k)
the manually packaged python and perl libs are available for multiple versions. the supported ones are visible, older still work
check out the package sets on the left https://search.nixos.org/packages?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=*
that blows up the number! we don't have ancient, unmaintained packages found in debian, but modern ones like in #AUR
Last week I submitted a new version of my currycarbon #haskell library to #hackage (see https://archaeo.social/@ClemensSchmid/111517617941502770). I made a mistake in the setup of my golden tests, which prevented the package from building on #stackage. @alaendle observed the issue, contacted me, explained the problem and answered my questions on GitHub. It was a very kind and professional exchange (see https://github.com/nevrome/currycarbon/issues/17).
I was astonished how well this was handled and wanted to share the experience 💗
Attached: 1 image I published a new major version of currycarbon, my #Haskell library and CLI tool for simple and convenient #C14 age calibration. v0.3.0.0 allows to draw age samples for each calibration expression, supports uniform age ranges (e.g. from contextual dating beyond C14) and features various interface improvements both for the in- and the output. Some of them are unfortunately breaking changes, but I hope for the better. See the new executable and a changelog here: https://github.com/nevrome/currycarbon/releases/tag/v0.3.0.0
Recently I released my old #utility I personally was using for last few years called “place-cursor-at” written in #Haskell (built on top of #X11 #Xlib). It helps to move your mouse cursor around your screens to specific approximate positions. Generally it helps to use the keyboard more and less the mouse.
It was released on #Hackage and #Stackage. And now it’s also available in #Nix and #NixOS 20.09. Give it a try:
nix-shell -p place-cursor-at --run place-cursor-at
"In this post, I demonstrate that critical parts of the #Haskell package management system are vulnerable to the #DependencyConfusion supply chain attack." #security #cabal #hackage
https://frasertweedale.github.io/blog-fp/posts/2021-02-12-haskell-dependency-confusion.html