~sircmpwn

Amsterdam

https://drewdevault.com

I write code.

Trackers

~sircmpwn/hare

Last active 19 hours ago

~sircmpwn/hare-ev

Last active a day ago

~sircmpwn/meta.sr.ht

Last active 5 days ago

~sircmpwn/hare-wayland

Last active 15 days ago

~sircmpwn/mercury

Last active 28 days ago

~sircmpwn/gddo

Last active a month ago

~sircmpwn/rc

Last active a month ago

~sircmpwn/lilhub

Last active 2 months ago

~sircmpwn/helios

Last active 2 months ago

~sircmpwn/writefreesoftware.org

Last active 2 months ago
View more

#10 Request cancellation 8 hours ago

Comment by ~sircmpwn on ~sircmpwn/hare-ev

REPORTED RESOLVED CLOSED

#1 Implement async DNS resolver 8 hours ago

Comment by ~sircmpwn on ~sircmpwn/hare-ev

REPORTED RESOLVED CLOSED

#13 Support multiple in-flight UDP send operations a day ago

Ticket created by ~sircmpwn on ~sircmpwn/hare-ev

#286 Move harelang.org to pages.sr.ht, add gemini version 2 days ago

Comment by ~sircmpwn on ~sircmpwn/hare

Nah.

#892 -lc: hook into libc's atfork, atexec, etc 4 days ago

Ticket created by ~sircmpwn on ~sircmpwn/hare

#199 Change of username 5 days ago

Comment by ~sircmpwn on ~sircmpwn/meta.sr.ht

Read the sidebar on the bug tracker, the part under "🛑 🛑 🛑 READ BEFORE FILING YOUR TICKET 🛑 🛑 🛑"

#199 Change of username 5 days ago

Comment by ~sircmpwn on ~sircmpwn/meta.sr.ht

REPORTED RESOLVED INVALID

#704 Consider adding @inline fn ... 9 days ago

Comment by ~sircmpwn on ~sircmpwn/hare

Perhaps, but a different solution which is not substantially more complex does not immediately suggest itself to me, and I am pleased with declaration-site inlining rather than call-site.

#704 Consider adding @inline fn ... 10 days ago

Comment by ~sircmpwn on ~sircmpwn/hare

Have thought about it but I'm not a huge fan of call-site inline, particularly considering that if any exported function can be inlined you have to stick the entire function body for all exported functions into the typedefs. And if they call any static functions... well at that point the typedefs become irrelevant and you have to do whole-module compilation every time. Or we have to implement LTO for qbe.

#88 Allow type and constant declarations in function bodies 13 days ago

Comment by ~sircmpwn on ~sircmpwn/hare

having the hash depend on the context it's declared in is pretty weird, and I feel like it's probably a bad idea.

Hashes already depend on the context it's declared in: the relevant module scope.

The hash could be hash(namespace + function name + serial number) where serial number is assigned from 0 and increments for each type defined in a given function. I don't think the spec needs to be updated for this (at least not beyond allowing types to be defined in functions) because the means of establishing the type hash is implementation defined.

I'm generally just not a fan of allowing in-scope bindings to have a type which is out of scope, and thus can't be referenced. Similar to why we require that the types of exported declarations also be exported (it simplifies the implementation ofc, but even when not taking implementation complexity into account it's still the right thing to do).

We should indeed prevent types from escaping their scope.