+1.

I've hit this issue a couple of times and the resulting behaviour is pretty
unpleasant to debug.

It's worth mentioning that linear types would track the lifetime/origin of
pointers, and would prohibit returning pointers on the current stack.

-- 
Hugo

On Sun, 15 Sep 2024, at 19:46, Lux Aliaga wrote:
> Hi there.
>
> The Arch Linux build image present in builds.sr.ht is currently not
> getting past the setup process. It attempts to summon `yay`, but fails
> due to a missing shared library. Here's an example of a failed build to
> prove what I mean.
>
> 	https://builds.sr.ht/~nixgoat/job/1328696
>
>

Applied, thanks.

-- 
Hugo

Thanks!

-- 
Hugo

Hi again,

I started seeing the same error as you today.
I've no idea why things worked for me before.

I've pushed a fix to quote TXT values.
Let me know if you still have any issues.

Cheers,

-- 
Hugo

Hi Drew,

For the last several weeks, godocs.io has been returning
Internal Server Error for any query.
E.g.: https://godocs.io/?q=os

Any idea what's wrong?

Thanks,

-- 
Hugo

On Sun, 1 Sep 2024, at 01:10, Tianhao Wang wrote:
> On Sun Sep 1, 2024 at 12:47 AM CEST, Gabriel wrote:
> [...]
>
> It seems that the mathjax scripts are not loaded correctly from the cdn.
> I'm not sure if it is srht.site policy. Anyways, you can solve this by
> serving mathjax files yourself, e.g. by putting the js file under
> `static` and change the script url to yours instead of using a cdn.
>

This is srht.site policy. You need to serve
all files yourself, and can’t execute scripts
from third party domains.

I agree with some of the nuances originally described here, but I also
don't like the complexity of the solution proposed.

A major annoyance right now is that `strerror` sometimes returns a
statically allocated string, and sometimes returns a heap allocated. It
is impossible for the caller to determine whether they must `free` the
returned string or not.

This will become an even more annoying problem when we have linear
types, given that the return value's "lifetime" or "origin" is not
static.

-- 
Hugo

On Wed, 14 Aug 2024, at 18:55, Gregory Anders wrote:
> The ability to use virtual lines (not just virtual text) for diagnostics 
> is something I'd like to see added as a builtin option for Neovim's 
> diagnostics. Before attempting to implement this myself, I wanted to see 
> if you'd be interested in upstreaming some form of your plugin to 
> Neovim?
>
> If so, we can have a more detailed discussion on what features exactly 
> should be included. But if you're not interested I understand, like I 
> said I just wanted to run the idea by you.
>
> Thanks!
>
> Greg

On Mon, 6 May 2024, at 11:49, Hugo Osvaldo Barrera wrote:
> When a user pipes syslog data into /dev/log, this ends up in the logs
> with the user facility, but there's no way to determine _which_ user
> logged a given line.
>
> From what I can tell, logbookd can determine the user on the other
> side of a socket connection using getsockopt(2) with SO_PEERCRED.
>

I tried to implement this and realised that you can't use getsockopt
on a socket of SOCK_DGRAM; there's no connection in this case.

I don't think that asserting the uid of the logging process if 
feasible.