haskell-github-trust / ulid Goto Github PK

As seen in ad-si/TaskLite#8

I'm missing a function to get the timestamp of a ulid.
Or is there a trick to get it I'm not aware of?

Could be useful for testing purposes.
E.g.

getDeterministicULID :: Seed -> ULID  
getDeterministicULIDTime :: POSIXTime -> Seed -> ULID

For getDeterministicULID the timestamp should increase with increasing seeds.

https://hackage.haskell.org/package/random-1.2.1.1/docs/System-Random.html#v:mkStdGen

Right now I can only use the 0.3.0.0 but that one has this bug about the Random instance

ulid                         > /tmp/stack-4712581ffce97e13/ulid-0.3.0.0/src/Data/ULID.hs:98:5: error:
ulid                         >     ‘randomIO’ is not a (visible) method of class ‘R.Random’
ulid                         >    |
ulid                         > 98 |     randomIO = getULID
ulid                         >    |     ^^^^^^^^

Thanks!!!

https://endtimes.dev/why-lowercase-letters-save-data/

As I understand the ULID spec, events within the same milisecond should have mostly the same random component (the prior random + 1 to be exact). This is a rather important selling point of ULID!

Just had this build failure after importing ulid-0.3.0 :

ulid > Preprocessing executable 'ulid-exe' for ulid-0.3.0.0..
ulid > Building executable 'ulid-exe' for ulid-0.3.0.0..
ulid > [1 of 1] Compiling Main
ulid >
ulid > /tmp/stack-087c00927eb5aedb/ulid-0.3.0.0/app/Main.hs:18:39: error:
ulid > parse error on input ‘-- ^ POSIX Time in milliseconds’
ulid > |
ulid > 18 | ulid2 <- getULIDTime 1469918176.385 -- ^ POSIX Time in milliseconds
ulid > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ulid >

stack Version 2.3.1, Git revision de2a7b694f07de7e6cf17f8c92338c16286b2878 (8103 commits) x86_64 hpack-0.33.0

ulidFromInteger $ toInteger (-123) makes the app freeze.

Does not build properly with Stack LTS 19, so we'll simply skip it.

I think the ULID type shouldn't be an instance of Random (or Uniform since random-1.2) by taking the trouble to use unsafePerfomIO.

The random function should be pure: if the argument g is the same value, the result of random g should be same. Breaking this rule can cause some troubles. For example, we can't reproduce the same value with the same generator (perhaps deserialized from a database). I haven't actually got troubled with such a case, but I think it'll cause some hard-to-find bug some day.

My suggestion is to drop the support for Random instance of ULID, and define the instance Random ULIDRandom instead. That makes the package safely available.

Speaking of the random package, due to the changes in random-1.2, now this package can't be built with the latest random. So how about fixing the problem and supporting random-1.2 at the same time?