#6 Blending/compositing 7 months ago

Comment by ~vladh on ~sircmpwn/hare-vec

Done: additive, subtractive and alpha blending

#27 git: add subcommand for setting custom README 8 months ago

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 being null (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...

#366 GraphQL API returns duplicated records 1 year, 1 month ago

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.

#277 Strings such as #123 should not be treated as a ticket reference inside a <pre> 1 year, 1 month ago

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

#97 Highlight only on word boundaries 1 year, 1 month ago

Comment by ~vladh on ~taiite/senpai

Fixed in https://lists.sr.ht/~delthas/senpai-dev/patches/34781

#748 Resolve .note.GNU-stack warning emitted by GNU ld 1 year, 1 month ago

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/ and hare/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?

#731 tuple unpack segfault 1 year, 3 months ago

on ~sircmpwn/hare

#712 harec: disallow tuples of size 1 1 year, 4 months ago

Comment by ~vladh on ~sircmpwn/hare

Please close as invalid.

#712 harec: disallow tuples of size 1 1 year, 4 months ago

Ticket created by ~vladh on ~sircmpwn/hare

This should not be allowed, but currently is:

let x = (1);

#710 regex: add replace() 1 year, 4 months ago

Ticket created by ~vladh on ~sircmpwn/hare