Finland
Dealing with abstract.
Ticket created by ~miikka on ~miikka/clj-branca
encodeanddecodeoptionally take the current time as an option:now. At the moment, the value has to be an integer that represents seconds since the Unix epoch.It should be extended to allow values that satisfy the
Instprotocol. We can then callinst-mson the value to convert it into seconds.The change involves
- Adding Inst handling to
get-now- Updating the docstrings for encode and decode
- Adding unit tests with Inst now
Comment by ~miikka on ~miikka/clj-branca
Fixed by https://git.sr.ht/~miikka/clj-branca/commit/4c0ad8ea23023dfba539f15d57a27b314c8643c2, published in release 0.1.1.
REPORTED RESOLVED FIXED
Ticket created by ~miikka on ~miikka/clj-branca
cljdoc analysis is failing because it can't find
byte-streams. I believe this is because the published jar lacks the pom file, so cljdoc does not know about clj-branca's dependencies.
Comment by ~miikka on ~miikka/clj-base62
Now I've realized that the O(n) performance is (likely) not possible. Base62 encoding is essentially radix conversion from base 256 to base 62 and based on quick search, the best known bound is O(M(n) log n) where M is the bound for multiplication of two n-bit integers. Still, it would be good to do a small benchmark to check the performance against the other implementations.
(Base64 is a special case since 256 is a multiple of 64.)
Ticket created by ~miikka on ~miikka/clj-base62
I want the library to be released on Clojars. This require either setting up something that works with deps.edn - possibly deps-deploy - or migrating to Leiningen.
Ticket created by ~miikka on ~miikka/clj-base62
The current implementation is fast enough for short message, but becomes very slow for anything over 10 kB. It seems that the asymptotic performance is worse than O(n).