extremely gay and incredibly online. ze/hir pronouns.


Last active 2 months ago


Last active 1 year, 1 month ago


Last active 2 years ago


Last active 2 years ago


Last active 2 years ago


Last active 2 years ago


Last active 2 years ago
View more

Recent activity

Re: unicode emojis get broken on posting 2 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 2 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 2 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]

Caching and sizes, the explosion of responise codes (was Re: Caching and status codes) 2 years ago

From boringcactus to ~adnano/gemini

On 2020-11-08 12:49 AM, Sean Conner wrote:
>    My approach is a bit different, probably a bit harder to implement server
> side, but deals not only with the caching issue, but with repeated requests.
> I'm not sure how popular it will be, but hey, it's out there, and it only
> adds one general purpose status code (23 for now) that means:
> 	okay, request was okay, but there is no data to serve you.
You could get a similar effect with 44 SLOW DOWN as it already exists, 
and boom, now the protocol doesn't need to know about caching at all.

Re: Send help 2 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!

play with the Crowbar reference compiler (but it only technically works)! 2 years ago

From boringcactus to ~boringcactus/crowbar-lang-announce

Hey all,

I've got barely enough substance in the Crowbar reference compiler that 
it can compile and run a hello world program, and that's good enough for 
me to have updated https://crowbar-playground.boringcactus.com/ to match.

The new version is running the same code as https://godbolt.org/, just 
with only one compiler available. It's probably overkill, but it does at 
least look good.

My next steps are, in some sequence,
- keep working on the compiler so it does the right thing more often
- work on the spec so it defines the behavior the compiler is implementing
- keep trying to teach QBE how the Windows x64 fastcall ABI works so

Re: Thoughts on Crowbar 2 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 2 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 

play with the Crowbar reference compiler('s parser)! 2 years ago

From boringcactus to ~boringcactus/crowbar-lang-announce

Hey all,

I have a reference compiler for Crowbar (all it can currently do is 
parse, because all that the spec currently defines is parsing), and I 
threw together a Web-based playground for it.

reference compiler: 

playground: https://crowbar-playground.boringcactus.com/


blog post on types in Crowbar 2 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: