~xenrox


#2 Correctly handle nullable time.Time a month ago

Comment by ~xenrox on ~emersion/gqlclient

The time documentation recommends that it should typically not be passed as a pointer and that IsZero can be used to determine uninitialized times. But if there are indeed legitimate use-cases where you would use the zero value, then time should probably be removed from this case. Otherwise the backend has to check with IsZero.

#3 Support interfaces a month ago

Ticket created by ~xenrox on ~emersion/gqlclient

Some initial discussion happened in hut-dev

#2 Correctly handle nullable time.Time a month ago

Ticket created by ~xenrox on ~emersion/gqlclient

#21 SIGSEGV in "builds list" with invalid access token 4 months ago

Comment by ~xenrox on ~emersion/hut

This bug is fixed with this commit. We actually don't need an additional nil check since the query only uses non-nullable fields.

REPORTED RESOLVED FIXED

#21 SIGSEGV in "builds list" with invalid access token 5 months ago

~xenrox assigned ~xenrox to #21 on ~emersion/hut

#21 SIGSEGV in "builds list" with invalid access token 5 months ago

bug added by ~xenrox on ~emersion/hut

#21 SIGSEGV in "builds list" with invalid access token 5 months ago

Comment by ~xenrox on ~emersion/hut

Thanks for your report!

This is caused by an out-of-date core-go dependency of builds.sr.ht. I have submitted a patch to fix this and will further add a nil check in hut.

#268 submitComment fails 5 months ago

Ticket created by ~xenrox on ~sircmpwn/todo.sr.ht

The submitComment mutations fails with:

pq: missing FROM-clause entry for table ""event""

Example query

mutation {
    submitComment(trackerId: 8263, ticketId: 1, input: { text: "test" }) {
        ticket {
            subject
        }
    }
}

#16 Align output fields 6 months ago

Comment by ~xenrox on ~emersion/hut

Indeed that looks good and seems to fix my problem.

#16 Align output fields 6 months ago

Comment by ~xenrox on ~emersion/hut

I wanted to align hut todo ticket list output and noticed one problem:

tabwriter does not handle coloured output very well. It counts the length of the formatting string as if it were displayed in the terminal. I worked around it by making all format strings the same length and while that worked for hut lists patchset list, we have a varying amount of coloured labels for each ticket. Right now I see 2-3 options how we could handle this:

  1. Iterate over all tickets, check which one has the most labels and pad the rest with with "invisible" formatting strings
  2. Put labels towards the end of the output
  3. Fork tabwriter and adjust the code as necessary (it is frozen)