Simon Ser:
>On Monday, May 16th, 2022 at 17:02, Blallo <blallo@autistici.org> wrote:
>
>> The http client used for interacting with the hut instance had a
>> hardcoded 30 seconds timeout. While this might be ok in most cases, I
>> happened to hit one of the corner cases when trying to push a tarball to
>> site.ht. This commit adds a global flag to set the value, defaulting to
>> the old one.
>
>Hm. If possible, I'd prefer to do the right thing by default and set a
>longer timeout for queries involving large file uploads, without
>requiring the user to manually pass a --timeout option.

(Sorry for the late reply). I understand that it would be a great

The http client used for interacting with the hut instance had a
hardcoded 30 seconds timeout. While this might be ok in most cases, I
happened to hit one of the corner cases when trying to push a tarball to
site.ht. This commit adds a global flag to set the value, defaulting to
the old one.
---
 config.go | 18 ++++++++++++++----
 main.go   |  1 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/config.go b/config.go
index 1f9c786..fa0b8e3 100644
--- a/config.go
+++ b/config.go
[message trimmed]

Please, ignore this patch. I forgot to actually use the passed timeout
value. The correct patch is underway.

--
blallo

The http client used for interacting with the hut instance had a
hardcoded 30 seconds timeout. While this might be ok in most cases, I
happened to hit one of the corner cases when trying to push a tarball to
site.ht. This commit adds a global flag to set the value, defaulting to
the old one.
---
 config.go | 16 +++++++++++++---
 main.go   |  1 +
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/config.go b/config.go
index 1f9c786..21b3828 100644
--- a/config.go
+++ b/config.go
[message trimmed]

Никола Радојевић:
>The title pretty much sums it up

I was going to reply to your previous (personal) email with the link to
the archive of the announcement. You beat me on time :)

I have really no clear plans. As I said in the announcement, I would
first like to take some time to study the LSP (the protocol itself) and
take a look at some existing implementations (I was thinking of gopls
and rust-analyzer, as those are two languages I am proficent with).

The following step, ideally, would be to write some fist implementation
that supports the simplest use-cases: many useful existing
implementations in other languages do not yet support refactor, for

Hi *,
I approached the Hare community on the advertised IRC channel [^], and
asked if there was an already existing effort towards implementing a
language server for the Hare language. I found myself more and more
tangled in this technology as a user (i.e. as a developer using other
languages), and I belive that such thing may make easier for many (and
for myself) the day-to-day usage of this new language.

Drew DeVault suggested to advertise here my intentions, and so here I
am. Maybe, in an excessive rush, I created some _infrastructure_ for
this initiative:

  - a repo: https://git.sr.ht/~blallo/hare-lsp
  - a list: ~blallo/hare-lsp@lists.sr.ht