Edinburgh
Love cats, programming, philosophy, music, languages and videogames. Being kind is cool.
I worked on the Hare programming language, please check it out!
Comment by ~vladh on ~sircmpwn/hare-vec
Done: additive, subtractive and alpha blending
Comment by ~vladh on ~emersion/hut
This currently works, except that there is a bug. To set the README back to normal, i.e. to the README.md file or whatever, the API expects to receive
null
in the "readme" field. However,null
can't be sent from hut(1), because gqlclientgen will then simply omit the field altogether. The solution needs to distinguish between (1) the "readme" field being absent (2) the "readme" field beingnull
(3) the "readme" field being a string. I've looked around a bunch but haven't figured out a good solution. :([18:45:49] <vladh> gqlclientgen always adds `json:"...,omitempty"` to generated structs. this means that `null` values can't be meaningfully used. in hut(1), a repo's "readme" field should be a string to set the readme to, or `null` to set it back to normal. this behaviour is not possible so there's a bug there. not sure what the solution is, seems like a pain tbh. [20:02:41] <emersion> vladh: there are cases where null isn't desirable either [20:02:55] <emersion> for instance if you don't want to update the readme at all [20:03:11] <emersion> so we'd need a tri-state of some kind [20:32:59] <vladh> I agree, I just don't think the default JSON marshalling stuff supports that, so it feels like hut(1) might need some custom marshalling stuff...
Ticket created by ~vladh on ~sircmpwn/git.sr.ht
Making the following query to the git.sr.ht API:
query repositoriesByUser { user(username: "sircmpwn") { repositories { results { name } } } }
results in the "hare" repository being returned 4 times and the "harec" repository 3 times.
If my understanding is correct, this particular query will be handled by the following function: https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/item/api/graph/schema.resolvers.go#L1271
I have tried to investigate under what circumstances results would be duplicated, but have not managed to figure it out. I have also not managed to replicate the issue on my local instance.
The only lead I can see is that there might be a problematic join with the "access" table, especially since both of the aforementioned repositories were previously unlisted and later became public. This is, however, just a guess, and might be wrong.
Ticket created by ~vladh on ~sircmpwn/todo.sr.ht
The following code block:
#123
should read (with an actual pound sign):
♯123
but is erroneously expanded to a ticket reference. Presumably the solution is to not perform this expansion inside
<pre>
tags. There might also be other scenarios where the expansion should not be performed.Reported by a user trying to post a core dump here: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cdb8f845c-fb72-341d-a275-955935d323fa%40mailbox.org%3E
Ticket created by ~vladh on ~sircmpwn/hare
GNU ld expects a section named
.note.GNU-stack
which signals that the final object code should "not [be] marked with an executable stack unless it actually needs it" 0.qbe currently emits this section. However, the *.s files in
hare/rt/+x86_64/
andhare/rt/+linux/
do not have this section.This means that, when compiling any Hare program with GNU ld 2.39, which is the current version on Arch, one receives the following warning:
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
We should somehow fix this, because it is quite an annoyance to users, since it happens every time you run or compile any Hare program.
Potential solutions:
- Add the
.note.GNU-stack
section to all *.s files mentioned above. This solves the issues but introduces a bit of junk for people not using GNU ld.- Somehow detect whether the user is using GNU ld, and if so, add the
--no-warn-execstack
flag. Unfortunately, we cannot add this flag universally, since lld.ld errors on unknown flags.Other questions:
- Are we actually using an executable stack?
Comment by ~vladh on ~sircmpwn/hare
Please close as invalid.