On 31.07.2024 at 23:13, Rowan Tommins [IMSoP] wrote:
> On 30/07/2024 20:15, Tim Düsterhus wrote:
>
>> Part of the motivation of the deprecation (and my argument against the
>> addition of a standalone sha256() function) is simplifying the
>> documentation: Everything needs to be written down in mu
On 30/07/2024 21:57, Tim Düsterhus wrote:
Let me attempt to give an explanation. As of today users should use in
order of priority:
1. The hash function they need for interoperability: If a service
provides a SHA-1 checksum, then there is no choice and SHA-1 needs to
be used.
2. The hash fun
On 2024-07-31 13:07, Mike Schinkel wrote:
On Jul 30, 2024, at 4:26 PM, Tim Düsterhus wrote:
The problem with adding standalone functions for every algorithm is that it
would result in a combinatorial explosion of available functions.
I commented on this but as it was probably missed in a longe
On 30/07/2024 20:15, Tim Düsterhus wrote:
Part of the motivation of the deprecation (and my argument against the
addition of a standalone sha256() function) is simplifying the
documentation: Everything needs to be written down in multiple
different places, any changes to hash_file() will likely
Hi Florian!
On 31.07.2024 at 14:07, Florian Engelhardt wrote:
> in this PR[1] it got mentioned that it could be beneficial to add a
> userland function that tells you how much memory there is still available
> for you to allocate.
> I am writing to ask for your opinion on this, because technicall
Hey folks,
in this PR[1] it got mentioned that it could be beneficial to add a
userland function that tells you how much memory there is still available
for you to allocate.
I am writing to ask for your opinion on this, because technically it should
be doable with a few lines of user land code (se
