From Jose Lombera to ~sircmpwn/hare-users
On Sun Aug 14, 2022 at 4:15 PM CDT, Vlad-Stefan Harbuz wrote: > On Sun Aug 14, 2022 at 7:17 PM BST, Jose Lombera wrote: > > ld: warning: fenv.o: missing .note.GNU-stack section implies executable stack > > ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > > Already being tracked in https://todo.sr.ht/~sircmpwn/hare/748 Thanks!
From Jose Lombera to ~sircmpwn/hare-users
OS: Debian testing (bookworm) BFD version: GNU ld (GNU Binutils for Debian) 2.38.90.20220713 Building hare using BFD linker complains about linker section: $ make [...] LD .bin/hare ld: warning: fenv.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker HARE .bin/harec2 ld: warning: temp.rt.9.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker HARE .bin/haredoc
From Jose Lombera to ~rjarry/aerc-devel
Cleanup existing PartSwitcher before recreating a new one when command
:toggle-headers is executed, ensuring existing part pagers are cleaned
up. This fixes a leak in pager processes when :toggle-headers is
executed repeatedly without closing the message.
Signed-off-by: Jose Lombera <jose@lombera.dev>
---
I'm not familiar with the codebase, not sure this is the most
appropriate solution.
To reproduce the issue, in aerc:
1. Open a message.
2. Call :toggle-headers several times. Every call leaks pager
[message trimmed]
From Jose Lombera to ~sircmpwn/sr.ht-discuss
On Thu Jul 14, 2022 at 8:27 PM CDT, Caleb Heuer wrote: > > some mail clients use different heuristics for "threading" messages > > when displaying them. > > I'm sure you're correct. Aerc doesn't show threads, so I was > basing that on Migadu's webmail and the Samsung mail app on my > smartphone. FYI, threading is supported by aerc since v0.7.0. See option threading-enabled in aerc-config(5).
From Jose Lombera to ~rjarry/aerc-devel
Ensure abbreviated commit SHA1 of fixed length in computed version regardless of user's configuration. Choose length 12 as safe value. Link: https://github.com/git/git/commit/dce96489162b05ae3463741f7f0365ff56f0de36 Signed-off-by: Jose Lombera <jose@lombera.dev> --- V1 -> V2: increase length to 12 (from 8). Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 9d43e9b7ad19..66dc1563d032 100644 [message trimmed]
From Jose Lombera to ~rjarry/aerc-devel
On Thu Jul 14, 2022 at 4:11 PM CDT, Robin Jarry wrote: > Hi there, this is a nice addition. > > Since you are not using the default --abbrev=7 value, why not go all the > way and force it to 12? > > https://github.com/git/git/commit/dce96489162b05ae3463741f7f0365ff56f0de36 Fine by me. No particular reason I chose 8, but thought some people might find 12 excessive :). I'll send patch V2.
From Jose Lombera to ~rjarry/aerc-devel
Ensure abbreviated commit SHA1 of fixed length in computed version
regardless of user's configuration.
Signed-off-by: Jose Lombera <jose@lombera.dev>
---
I was hit by this when doing
$ make
$ sudo make install
Since I have core.abbrev=12 in my global git config, the version
generated in the first command (using my user's config) and the second
one (using root's config) was different, triggering the build of aerc
all over again by the second command. This meant go dependencies were
[message trimmed]
From Jose Lombera to ~sircmpwn/hare-users
On Mon Jul 11, 2022 at 11:07 PM CDT, wrote: > Hello, > > First off, thanks for creating such a fun language! > > I was working on a project in Hare on and off. Whenever starting again I would pull > and rebuild harec and the stdlib every time before I started working (don't wanna > get left behind!). > > Of course, after one pull I started getting some harec crash: > > $ hare run test.ha > harec: src/types.c:448: const struct type *tagged_select_subtype(const struct type *, const struct type *): Assertion `tagged->storage == STORAGE_TAGGED' failed. > Error: harec: exited with signal 6
From Jose Lombera to ~sircmpwn/hare-dev
On Fri Jul 1, 2022 at 2:24 AM CDT, Drew DeVault wrote: > On Mon Jun 20, 2022 at 7:33 AM CEST, Jose Lombera wrote: > > So I was thinking what would be the correct way to fix this. The first > > idea that comes to mind is to add additional cases for each one of the > > members of errors::error, similarly than is already done for > > errors::opaque. This is the most straightforward (and probably correct) > > solution. However, it basically means duplicating the implementation of > > errors::strerror() inside exec::strerror(). So I tried the following > > Can we not just add a match case on errors::error? WE can ditch the > opaque branch as well. Yeah, sorry, I was not quite familiar yet with match expression rules when I wrote the email. It was clearer to me later when I read the
From Jose Lombera to ~sircmpwn/sr.ht-discuss
On Thu Jun 30, 2022 at 11:50 AM CDT, Przemysław Kamiński wrote: > Yes, attachments are forbidden (I got a suggestion to use plaintext mail > actually). > > Here is the screenshot: > https://filen.io/d/01cd9002-6655-4115-987f-f88fd64cca68#!7hVaTMq5l1v3K7WEe1JMIRKjEI2VJtYx > I'm only guessing, but maybe you have to choose one of Public/Unlisted/Private. It would still be a bug in paste.sr.ht for not handling this correctly, though. - Lombera