~vtorri

Recent activity

compilation error with MinGW a month ago

From Vincent Torri to ~sircmpwn/public-inbox

Hello

scdoc does not compile with MinGW:

```
cc -std=c99 -pedantic -c -o .build/main.o -g -DVERSION='"1.11.2"'
-Wall -Wextra -Werror -Wno-unused-parameter -Iinclude src/main.c
src/main.c: In function 'parse_preamble':
src/main.c:113:40: error: unknown conversion type character 'F' in
format [-Werror=format=]
  113 |         strftime(date, sizeof(date), "%F", date_tm);
      |                                        ^

```

Re: [PATCH] Remove redundant double-setting of URL in libcurl 3 months ago

From Vincent Torri to ~lattis/muon

hello

On Thu, Aug 25, 2022 at 10:27 PM Stone Tickle <lattis@mochiro.moe> wrote:
>
> Hi, thanks for the patch!
>
> > Also, I don't think I'm experienced enough to have a go at it myself,
> > but I wonder if the libcurl code could be simplified by passing a stream
> > from open_memstream() to CURL, instead of defining our own write
> > function that does dynamic allocation? open_memstream() is in POSIX. If
> > you're not familiar with it, I've attached a libcurl example that shows
> > how you can use them together.
>
> Interesting, I didn't know about open_memstream().  There are a quite a

Re: run_cmd.c: copy_pipe() is blocking, use thread instead ? 5 months ago

From Vincent Torri to ~lattis/muon

> > copy_pipe() is using an infinite loop to read the pipe. Is it better
> > than using a thread (for the usage in muon) ?
>
> I would strongly prefer to keep muon single-threaded.  Is there not a
> nonblocking api like this on windows?

there is, but it's a bit more complicated to implement when
redirecting stdout|err|in. I need to do tests first

thank you

Vincent

run_cmd.c: copy_pipe() is blocking, use thread instead ? 5 months ago

From Vincent Torri to ~lattis/muon

hello

copy_pipe() is using an infinite loop to read the pipe. Is it better
than using a thread (for the usage in muon) ?

thank you

Vincent

Re: [PATCH] use PRIu64 instead of zu 6 months ago

From Vincent Torri to ~lattis/muon

From a3c842b586fb62030620e297a00c7c373eb21ea3 Mon Sep 17 00:00:00 2001
From: Vincent Torri <vincent.torri@gmail.com>
Date: Sun, 5 Jun 2022 12:24:45 +0200
Subject: [PATCH 3/4] use C99 PRIu64 format instead of zu

---
 src/data/darr.c           | 3 ++-
 src/platform/filesystem.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/data/darr.c b/src/data/darr.c
index c579725..b205f21 100644
--- a/src/data/darr.c
+++ b/src/data/darr.c

Re: [PATCH] use PRIu64 instead of zu 6 months ago

From Vincent Torri to ~lattis/muon

On Sun, Jun 5, 2022 at 3:10 PM John Scott <jscott@posteo.net> wrote:
>
> On Sun, 2022-06-05 at 13:10 +0200, Vincent Torri wrote:
> > +        L("index %" PRIu64 " out of bounds (%" PRIu64 ")", (unsigned
> > long long)i, (unsigned long long)da->len);
>
> In my opinion, using PRIu64 while still casting to unsigned long long
> doesn't make sense.

on 32 bits systems, size_t is not 64 bits type, right ?

> That implies that an unsigned long long is the same
> as a uint64_t, but why not just cast to uint64_t to make the format
> specifier correct?

[PATCH] add missing rpath_fixer.c on Windows 6 months ago

From Vincent Torri to ~lattis/muon

From 2d8a43ac80c28dfdcc8da4f407543155185e29a6 Mon Sep 17 00:00:00 2001
From: Vincent Torri <vincent.torri@gmail.com>
Date: Sun, 5 Jun 2022 13:05:50 +0200
Subject: [PATCH 4/4] Windows: addmissing rpath_fixer.c

---
 src/platform/windows/rpath_fixer.c | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 src/platform/windows/rpath_fixer.c

diff --git a/src/platform/windows/rpath_fixer.c
b/src/platform/windows/rpath_fixer.c
new file mode 100644
index 0000000..e3dd1c1

[PATCH] use PRIu64 instead of zu 6 months ago

From Vincent Torri to ~lattis/muon

From a3c842b586fb62030620e297a00c7c373eb21ea3 Mon Sep 17 00:00:00 2001
From: Vincent Torri <vincent.torri@gmail.com>
Date: Sun, 5 Jun 2022 12:24:45 +0200
Subject: [PATCH 3/4] use C99 PRIu64 format instead of zu

---
 src/data/darr.c           | 3 ++-
 src/platform/filesystem.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/data/darr.c b/src/data/darr.c
index c579725..b205f21 100644
--- a/src/data/darr.c
+++ b/src/data/darr.c

Re: about logging in muon on Windows 6 months ago

From Vincent Torri to ~lattis/muon

On Sat, Jun 4, 2022 at 8:06 AM Vincent Torri <vincent.torri@gmail.com> wrote:
>
> On Sat, Jun 4, 2022 at 7:47 AM Stone Tickle <lattis@mochiro.moe> wrote:
> >
> > Hello,
> >
> > Another solution would be to cast the size_t to a uint64_t and then use
> > the normal PRId64 specifier.  This would avoid most of the complexity
> > you described, and I don't think printing size_t is very common in the
> > muon codebase.
>
> That would be a solution. Would it mean that you will support muon
> usage only on 64 bits computers ?

Re: about logging in muon on Windows 6 months ago

From Vincent Torri to ~lattis/muon

On Sat, Jun 4, 2022 at 7:47 AM Stone Tickle <lattis@mochiro.moe> wrote:
>
> Hello,
>
> Another solution would be to cast the size_t to a uint64_t and then use
> the normal PRId64 specifier.  This would avoid most of the complexity
> you described, and I don't think printing size_t is very common in the
> muon codebase.

That would be a solution. Would it mean that you will support muon
usage only on 64 bits computers ?

Vincent