~sschwarzer

Trackers

~sschwarzer/ftputil

Last active 20 days ago

~sschwarzer/ticket-experiments

Last active 2 months ago

~sschwarzer/dummy-tracker

Last active 3 months ago

~sschwarzer/raco-exe-multitarget

Last active 4 months ago

~sschwarzer/sudoku-solver

Last active 11 months ago

~sschwarzer/todo-txt

Last active 1 year, 1 month ago

~sschwarzer/python_skeleton

Last active 2 years ago

~sschwarzer/vppdiff

Last active 2 years ago

#150 Invalidate cache in rename method 10 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

Released ftputil 5.0.4 with the fix.

#150 Invalidate cache in rename method 10 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

Thanks for the feedback! :-)

Changes in the recent commits:

  • Invalidate stat cache entries in FTPHost.rename.
  • In FTPHost.remove, FTPHost.rmdir, FTPHost.rmtree and FTPHost.rename: If an exception occurs during the operation, invalidate the cache for the affected file system items. The idea is that even if there was an exception, the server might have finished the operation but failed when responding.

REPORTED RESOLVED FIXED

#150 Invalidate cache in rename method 11 days ago

on ~sschwarzer/ftputil

~sschwarzer I've checked changes you made, it's working now. Thanks!

#150 Invalidate cache in rename method 19 days ago

~sschwarzer assigned ~sschwarzer to #150 on ~sschwarzer/ftputil

#150 Invalidate cache in rename method 19 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

Hello ~dolfinus, thanks for the report and the patch! I plan to work on the ticket (including test updates) next weekend.

#269 Improve usability regarding code snippets in ticket descriptions a month ago

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

This ticket refers to this thread on the sr.ht-discuss list.

Currently, displaying a ticket with a description with long code lines, as here, requires a lot of horizontal scrolling to read the code (in this case rather a stacktrace). This way, it's really difficult to comprehend the code/stacktrace.

Drew DeVault pointed out in the discussion that long logs should be put on paste.sr.ht, and I agree. But I think shorter (in lines) snippets shouldn't require a separate paste.

Ideas/suggestions:

  • To encourage the use of paste.sr.ht for longer code/stacktraces/logs, there should be a remark near the description field when entering a ticket.

  • For the remaining uses (i.e. without paste.sr.ht) change the ticket display layout so that code of "normal" widths (e.g. 100 characters) requires no or only little horizontal scrolling.

    Of course, this won't be achievable on small displays, but there's room for improvement even on "normal" monitors. The current layout doesn't use the available space even if the browser window is stretched to the maximum width. Instead, a user sees a lot of unused space left and right of the actual ticket content. An alternative to make the real ticket display wider would be to put the meta information that's currently on the right, above the ticket instead. Of course, both approaches may be combined.

#261 Attempt to delete tracker results in "502 Bad Gateway" error and the tracker isn't deleted a month ago

Comment by ~sschwarzer on ~sircmpwn/todo.sr.ht

It seems the fix for ticket #266 also fixes this bug. Deleting a tracker with 149 tickets with the web interface is fast now (taking about a second).

#266 Attempt to delete tracker via GraphQL times out and doesn't delete the tracker 2 months ago

Comment by ~sschwarzer on ~sircmpwn/todo.sr.ht

Fix confirmed. Thank you!

#261 Attempt to delete tracker results in "502 Bad Gateway" error and the tracker isn't deleted 2 months ago

Comment by ~sschwarzer on ~sircmpwn/todo.sr.ht

The above tracker that failed to delete contains 149 tickets.

I tried importing and deleting subsets of these tickets:

  • When importing the first 50 tickets, deleting them takes about 20 seconds.
  • When importing the first 60 tickets, deleting them takes about 25 seconds.
  • When importing the first 70 tickets, deleting them fails when running into the timeout after about 30 seconds.

So it seems that some timeout is set to a too small value to be able to delete larger trackers. (Although 70 tickets isn't really large in my opinion.)


To possibly get the tracker deleted, I tried a workaround of importing a tracker with fewer tickets "over" one with more tickets, but that failed. There was no error message, but I also didn't get the message about an import being in progress and deleting the tracker still failed. See also #260 .

#266 Attempt to delete tracker via GraphQL times out and doesn't delete the tracker 2 months ago

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

In the GraphQL playground [1], I use

query GetTrackers {
  me {
    id
    username
  }
  trackerByName(name: "ftputil-test3") {
    id
    name
  }
}

to get the id for one of the trackers I want to delete. The response looks ok:

{
  "data": {
    "me": {
      "id": 3776,
      "username": "sschwarzer"
    },
    "trackerByName": {
      "id": 8200,
      "name": "ftputil-test3"
    }
  }
}

Now, I use

mutation DeleteTracker {
  deleteTracker(id: 8200) {
    id
  }
}

to actually delete the tracker, but the request times out with

{
  "errors": [
    {
      "message": "pq: canceling statement due to user request",
      "path": [
        "deleteTracker"
      ]
    }
  ],
  "data": {
    "deleteTracker": null
  }
}

[1] https://todo.sr.ht/graphql