~taiite

France

http://taiite.srht.site/

Trackers

~taiite/senpai

Last active 6 days ago

~taiite/protodump

Last active a month ago

~taiite/ellidri

Last active 4 months ago

~taiite/irc-police

Last active 7 months ago

#69 Error (code 432): sircmpwn@senpai contains illegal characters 6 days ago

Comment by ~taiite on ~taiite/senpai

This error is coming from the server, senpai doesn't validate configuration values.

Related to #40

REPORTED RESOLVED NOT_OUR_BUG

#134 soju 0.2.0 on FreeBSD 13/amd64 when accessed over WireGuard (in TLS mode) with weechat/catgirl fails to connect properly 30 days ago

Comment by ~taiite on ~emersion/soju

#132 Filter out upstream JOIN for detached channels a month ago

Comment by ~taiite on ~emersion/soju

I can't reproduce. JOIN messages for detached channels should be blocked by upstreamConn.produce here: https://git.sr.ht/~emersion/soju/tree/bc83d3a3ba81f3e8c010c83160832bbf6b6bffff/item/upstream.go#L1820

#17 Don't panic on malformed input a month ago

Comment by ~taiite on ~taiite/protodump

REPORTED RESOLVED FIXED

#16 Account for (void) argument lists a month ago

Comment by ~taiite on ~taiite/protodump

REPORTED RESOLVED FIXED

#133 delivery receipts for clients that don't specify an ID are kept in the DB a month ago

Comment by ~taiite on ~emersion/soju

REPORTED RESOLVED FIXED

#133 delivery receipts for clients that don't specify an ID are kept in the DB a month ago

Ticket created by ~taiite on ~emersion/soju

they shouldn't be, since they don't provide information to soju unless the ID is specified.

Also, SQLite considers NULL to be different from NULL [0] (postgresql also does [1]), so the receipts flood the DB with junk.

[0] https://www.sqlite.org/lang_createindex.html

[1] https://www.postgresql.org/docs/current/indexes-unique.html

#67 When /JOIN ing a channel, switch to the buffer when we're joined a month ago

Comment by ~taiite on ~taiite/senpai

REPORTED RESOLVED FIXED

#17 Don't panic on malformed input a month ago

Ticket created by ~taiite on ~taiite/protodump

Right now protodump panics on malformed input, e.g. missing attributes, tags, etc. protodump should only print an error in such case.

To do: change error types from gimli::Error to anyhow::Error in src/types.rs and src/dwarf.rs and provide context when returning errors.

Should protodump also not panic on unexpected type tags? From one side this is due to protodump not supporting all types (so a panic is justified), but malformed input could point a type attribute to a tag that is not a type (so protodump should return an error).

Maybe list all types from std and panic if the tag is one of them and isn't supported by protodump , otherwise return an error.

#14 diff mode: don't trigger a change when a parameter becomes const 2 months ago

Comment by ~taiite on ~taiite/protodump

Merging this issue in #3

REPORTED RESOLVED DUPLICATE