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,

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.

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]

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: 
https://c9x.me/compile/doc/llvm.html

> 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!

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."

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 
finish.

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: 
https://www.boringcactus.com/2020/10/13/crowbar-2-simplifying-c-type-names.html

-💤🌵

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:

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)
Aborted

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.

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.

---
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]