~whynothugo

The Netherlands

https://whynothugo.nl

~whynothugo/public-inbox

Last active a month ago

~whynothugo/lsp_lines.nvim

Last active 2 months ago

~whynothugo/superd-services

Last active 4 months ago

~whynothugo/shotman

Last active 7 months ago

~whynothugo/photostore-devel

Last active 9 months ago

~whynothugo/docker-makepkg

Last active 10 months ago

~whynothugo/vdirsyncer-devel

Last active 10 months ago
View more

Recent activity

Re: [PATCH himitsu v5] Implement remembering consent 21 days ago

From Hugo Osvaldo Barrera to ~sircmpwn/himitsu-devel

On 2024-01-31 17:54, Willow Barraco wrote:
> This add consentment remembering for some period of time.
> 
> Reference: https://todo.sr.ht/~sircmpwn/himitsu/26
> 
> This add the prompty commands and replies "remember". The prompter must
> reply with the selected remember way after prompt.
> 
> [...]

Shouldn't consent be remembered on a per-connection basis?

If I authorise one client and pick "remember for an hour", I wouldn't expect
other clients to also be authorised to read those secrets.

Re: [PATCH] Use current locale to render dates 26 days ago

From Hugo Osvaldo Barrera to ~delthas/senpai-dev

I find the five digit dates to be completely meaningless, because there’s no
clue as to which is the date and which is the month.

On low activity channels, I see 10-11 and have no idea if this was a week ago
or over a month ago.

My main intent here was to respect the user’s configured locale, but in my case
(and likely most others), that won’t fit in 5 characters.

-- 
Hugo

Re: [RFC v1] foreach a month ago

From Hugo Osvaldo Barrera to ~sircmpwn/hare-rfc

Regarding special-casing void to denote an "end of iteration".

The magpie language has a special sentinel value "done", which denotes the end
of an iteration. Its goal is to specifically allow iterators which can contain
null/void values.

The original article is here:

https://journal.stuffwithstuff.com/2013/04/17/well-done/

I'm not entirely convinced that it is a great idea; but given that it's prior
art I think it's worth mentioning.

Re: Timezones and recurring transitions 2 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/hare-dev

I don't understand why the complexity in icalendar's recurrence rules bothers
you so much.

My proposal is merely to enable implementing timezone transition logic in third
party libraries. The details of these implementations are entirely out of scope
for the stdlib. And the same API could be used to operate on tzdata in memory.

In its current form, the stdlib can't even represent existing timezones. Most
timezones have recurring transitions, but the current struct takes a [finite]
array of transitions. The current API indicates that it would read the next
transition from a database each time it needs to know the next transition,
which also doesn't sound like an ideal final solution.

> FYI there is precedent for this approach, for instance Python's

Re: Timezones and recurring transitions 2 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/hare-dev

On 2023-11-30 08:54, Drew DeVault wrote:
> I see. This, I think, comes down to a difference in how the interfaces
> and abstractions are structured to represent the same things; honestly I
> think iCal does it poorly.
> 
> An iCalendar library will generally not be well supported by any given
> standard library, since iCalendar takes it upon itself to redefine the
> world of timekeeping in its own terms. I don't really think the stdlib
> should change in any meaningful way to accomodate it.

As I said initially: I agree that representing icalendar recurrence rules in
the stdlib is likely a bad approach (too much complexity in the wrong place).

This is why I included the second approach It would enable writing custom

Re: Timezones and recurring transitions 2 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/hare-dev

On 2023-11-30 08:14, Drew DeVault wrote:
> There seems to be some persistent confusion here. I don't think
> iCalendar recurrecnce rules have anything to do with timezones.

Icalendar VTIMEZONE components are defined using recurrence rules[1]. You can't
represent icalendar timezones if you can't representing icalendar RRULES.

[1]: https://www.rfc-editor.org/rfc/rfc5545#section-3.6.5

-- 
Hugo

Re: [PATCH hare-json] remove unreachable abort 2 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/hare-dev

On 2023-11-29 18:24, Sertonix wrote:
> 
> Fixing compilation with latest hare version.
> 
> Signed-off-by: Sertonix <sertonix@posteo.net>
> ---
>  encoding/json/lex.ha | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/encoding/json/lex.ha b/encoding/json/lex.ha
> index 3545cc3..df3373e 100644
> --- a/encoding/json/lex.ha
> +++ b/encoding/json/lex.ha
> @@ -370,7 +370,6 @@ fn nextrunews(lex: *lexer) (rune | io::EOF | error) = {

Timezones and recurring transitions 2 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/hare-dev

I mentioned on IRC a few days ago that I'm trying to decode Icalendar data,
including events and their timezones.

The current time::chrono::timezone impementation has some limitations for this,
and for representing timezones. The `zones` field is an array of transitions,
but many timezones have recurring transitions every year, and many have
non-recurring exceptions.

I tried representing recurrence rules for icalendar (which are used to
represent timezone recurrances) in hare. The following example can represent
all of icalendar's recurrence rules (it can also represent cron rules, which
seem to be a subset).

// A recurrence rule.

Re: Fixing the query syntax 3 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/himitsu-devel

The strict approach sounds like it could be a problem when a helper expects
only a subset of the keys to exist.

Suppose one program queries:

  proto=smtp port=587 user=hugo

And another queries:

  proto=smtp user=hugo

Both of the above should really use the same key.

Adding expires=2024-11-19 to a key is also useful, but most integrations won't

Re: Element change of license and CLA 3 months ago

From Hugo Osvaldo Barrera to ~sircmpwn/public-inbox

On 2023-11-12 14:21, jman wrote:
> One can argument that Element is requiring the CLA to possibly close the
> source code in the future and make a proprietary product. But wasn't
> that already possible using the Apache-2.0 license?
> 

With the new licence, they are the only ones who can make a proprietary fork;
everyone else must share their changes under the AGPL.

> What is the actual difference with a CLA? Making it easier for Element
> to make a closed-source fork of a AGPLv3 project without having to ask
> all contributors? If yes, why didn't they simply used a more permissive
> license like the Apache-2.0 that already allows that?
>