extremely gay and incredibly online. ze/hir pronouns.
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,
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.
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]
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.
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: 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!
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
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."
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 finish.
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: https://git.sr.ht/~boringcactus/crowbar-reference-compiler playground: https://crowbar-playground.boringcactus.com/ -π€π΅
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: https://www.boringcactus.com/2020/10/13/crowbar-2-simplifying-c-type-names.html -π€π΅