extremely gay and incredibly online. ze/hir pronouns.


Last active 1 year, 2 months ago


Last active 2 years ago


Last active 3 years ago


Last active 3 years ago


Last active 3 years ago


Last active 3 years ago


Last active 3 years ago
View more

Recent activity

Re: unicode emojis get broken on posting 3 years ago

From boringcactus to ~boringcactus/gemifedi

Honestly I'm not sure. I hadn't thought about gemifedi for several
months before this showed up in my inbox, and I promptly forgot about
it for the subsequent month. In theory, nothing in there should be
causing emojis to not work.

On Mon, Feb 1, 2021 at 12:39 PM René Wagner <rwagner@rw-net.de> wrote:
> Hi,
> i just started to play around with gemifedi and it works quite well so far.
> Need to get used to the formatting, but that is expected due to the
> restrictions of gemtext.
> I came across a small issue with unicode characters, e.g. emojis,

Re: build docker image directly from sr.ht 3 years ago

From boringcactus to ~sircmpwn/sr.ht-discuss

On 2020-11-12 2:44 PM, Jiri Vlasak wrote:
>      $ docker build -t www https://git.sr.ht/~qeef/damn-www

Unfortunately, Docker assumes every HTTPS git URL ends with ".git", 
which Sourcehut does not support. You can use the SSH clone URL, but 
(unless this has changed recently) you'll need to be using a key that's 
authorized on your account or Sourcehut will reject the SSH clone entirely.

[PATCH gemserv] don't round-trip CGI response through UTF-8 3 years ago

From boringcactus to ~int80h/public-inbox

From: Melody Horn <melody@boringcactus.com>

this fixes sending binary files from a CGI script
Sent this directly to int80h, but it's probably wise to put it on the
mailing list as well, just in case.

 src/cgi.rs | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/cgi.rs b/src/cgi.rs
index a5dd900..1605d53 100644
--- a/src/cgi.rs
+++ b/src/cgi.rs
[message trimmed]

Re: Send help 3 years ago

From boringcactus to ~boringcactus/crowbar-lang-devel

On 2020-10-28 3:58 PM, Cole Blakley wrote:
> I think that you might consider compiling the Crowbar language directly into LLVM IR.

I thought about going with LLVM, but decided against it for two reasons:
1. It seemed complicated.
2. Everybody else is using it, and so it's too mainstream.

I've settled on using QBE <https://c9x.me/compile/> as my backend 
instead, which has its own comparison with LLVM: 

> Your blog is pretty cool btw, nice to find a coding blog that has neat projects and not dumb VC stuff.

Glad you like it!

Re: Thoughts on Crowbar 3 years ago

From boringcactus to ~boringcactus/crowbar-lang-devel

On 2020-10-21 11:02 AM, Eyal Sawady wrote:
> Oh, and another thing I just thought of: you don't need to worry about
> making sure that the runtime library exists on the host system, you
> should be statically linking everything.
Picked up on that one myself eventually, but yeah, that's the right way 
to do it.

> Non-pointer->pointer casts are required for kernels, which are an
> important use-case for C and any C replacement.

I may have to soften the memory safety guarantees into memory safety 
probably-guarantees, i.e. it's possible to tell the compiler "I know you 
can't verify that this is safe, but I want to do it anyway."

Re: Thoughts on Crowbar 3 years ago

From boringcactus to ~boringcactus/crowbar-lang-devel

On 2020-10-20 12:20 AM, Eyal Sawady wrote:
> My advice is to compile to QBE, not worry about header compatibility
> right now, and write up a tool to convert C headers to .hros when it
> becomes necessary. If you feel like it, integrate said tool into
> Crowbar's build system. Said tool should only parse a small subset of C,
> let the programmer sort things out if the header file sucks in order to
> avoid reimplementing C.

Thanks for reaching out!
After writing my blog post and sleeping on it, I had settled on 
compiling to C, but that has its own mountain of benefits and drawbacks, 
and I could probably run that cost-benefit analysis for years and not 

blog post on types in Crowbar 3 years ago

From boringcactus to ~boringcactus/crowbar-lang-devel

hey all (any?),

was working on the Crowbar spec and realized i'd accidentally come up 
with a good type syntax, so i wrote it up as a standalone blog post: 


gmnlm doesn't calls mkdirs in open_bookmarks 3 years ago

From boringcactus to ~sircmpwn/gmni-devel

Since gmnlm loads the bookmarks file at launch if no gemini URL was
passed in, as it stands running gmnlm for the first time gives this

Error opening /home/cactus/.local/share/gmni/bookmarks.gmi for
writing: No such file or directory
Assertion failed: uc == CURLUE_OK (src/gmnlm.c: do_requests: 673)

This is easily solved by users, but since the mechanism already exists
within gmnlm to create that directory itself (and is used by
save_bookmark), users shouldn't have to be the ones to fix it.
I tried writing a patch for this myself, but wound up in a sea of
other issues that I didn't fully understand.

Re: How can we make the project hub more accessible? 3 years ago

From boringcactus to ~sircmpwn/sr.ht-discuss

On September 22, 2020 11:26:11 AM MDT, Robin Krahl <robin.krahl@ireas.org> wrote:
>Part of the problem might be that there is no indication whether a Git
>repository is part of a project when visiting the repository.

This matches what I've been thinking for a bit: you can go down from a project to the repos/issues/lists it contains, but you can't go up from those back to the project unless the README etc has a link to the project root specifically added. I think it would be nice for that link to be traversable in both directions.

[PATCH] Clarify Alpine dependencies 3 years ago

From boringcactus to ~sircmpwn/sr.ht-dev

Ran into this minor gotcha; figured it'd help to clarify so nobody
else struggles in quite the same way.

 packages.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/packages.md b/packages.md
index 828b32b..80b6550 100644
--- a/packages.md
+++ b/packages.md
@@ -15,7 +15,8 @@ All of our package repositories accept patches as necessary on

This is the recommended distribution of SourceHut, and the one we use for the
[message trimmed]