unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Question about an error with ports
@ 2022-03-10  1:26 Zelphir Kaltstahl
  2022-03-10 15:05 ` Olivier Dion via General Guile related discussions
  0 siblings, 1 reply; 15+ messages in thread
From: Zelphir Kaltstahl @ 2022-03-10  1:26 UTC (permalink / raw)
  To: guile-user

Hello Guile Users!

I have some code at 
https://notabug.org/ZelphirKaltstahl/guile-examples/src/63af5250aa5a45d68bc6bd2d6193d2a6fb127f24/shell/example-04-using-popen-get-out-and-error-with-ports.scm:

~~~~
(import (ice-9 popen)
         (ice-9 textual-ports)
         (ice-9 binary-ports)
         (ice-9 exceptions)
         (ice-9 receive)
         (ice-9 match))


;; Is this useful at all? Or is there a better way? Maybe
;; anything using the file descriptors directly?
(define read-from-write-to
   (lambda* (in-port out-port #:key (bytes-count 1024))
     "Read from an IN-PORT and write to OUT-PORT,
     BYTES-COUNT bytes at a time."
     (let loop ([bv (get-bytevector-n in-port bytes-count)])
       (cond
        [(eof-object? bv)
         (close-port out-port)]
        [else
         (put-bytevector out-port bv)]))))


;; Trying to allow the user to give output port and error
;; port to the function. But how to elegantly call it then?
(define run-command
   (lambda* (cmd
             #:key
             (cmd-out-port (current-output-port))
             (err-out-port (current-error-port)))
     (match-let ([(err-read . err-write) (pipe)]
                 [stderr (current-error-port)])
       (with-error-to-port err-write
         (λ ()
           (let* (;; Run the actual command. If an error
                  ;; happens, it should write to the
                  ;; err-write port. Output of the command
                  ;; should be written to an output port,
                  ;; which corresponds to the input-port,
                  ;; which is returned by open-input-pipe.
                  [in-port (open-input-pipe cmd)]
                  ;; Read in block mode.
                  [_ignored (setvbuf in-port 'block)])
             ;; Write to caller given command output port.
             (read-from-write-to in-port cmd-out-port)
             ;; Close the port, to which the child process
             ;; was to write errors, as the child process has
             ;; finished (either successfully or
             ;; unsuccessfully, but definitely
             ;; finished). Close the error output port,
             ;; before reading from the corresponding error
             ;; read port.
             (close-port err-write)
             ;; Write to caller given error output port.
             (read-from-write-to err-read err-out-port)
             ;; Get the exit code of the command.
             (close-pipe in-port)))))))

;; Why does this exit? I guess because of writing something
;; to the current error port and that means "an error happened"?
;; But why do I get an error and what does the error tell me?
(run-command "echo 'bong' 1>&2")
~~~~

I have the following questions:

(1) Is the read-from-write-to procedure useful at all, or is there a better way 
to get all stuff from an input port and output it to an output port, avoiding 
possibly large string values?

(2) Why do I get an error and what does the error mean? And why does it quit the 
REPL entirely, instead of giving me that [1] thingy, indicating, that an error 
happened, but letting me continue with the REPL session?

(3) How would I elegantly call a function, which allows to optionally specify an 
output port and an error port, specifying both?

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-10  1:26 Question about an error with ports Zelphir Kaltstahl
@ 2022-03-10 15:05 ` Olivier Dion via General Guile related discussions
  2022-03-10 22:32   ` Zelphir Kaltstahl
  0 siblings, 1 reply; 15+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-03-10 15:05 UTC (permalink / raw)
  To: Zelphir Kaltstahl, guile-user

On Thu, 10 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:

> I have the following questions:
>
> (1) Is the read-from-write-to procedure useful at all, or is there a better way 
> to get all stuff from an input port and output it to an output port, avoiding 
> possibly large string values?

On Linux, there's slice(2) for pipes that does exactly that.

Otherwise, I think this version is a better fit

(define splice
  (lambda (in-port out-port)
    "Read from an IN-PORT and write to OUT-PORT"
    (let loop ([bv (get-bytevector-some in-port)])
      (unless (eof-object? bv)
        (put-bytevector out-port bv)
        (loop (get-bytevector-some in-port))))))

you should not close OUT-PORT.  This break the REPL in my case if using
the `current-output-port`.

-- 
Olivier Dion
Polymtl



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-10 15:05 ` Olivier Dion via General Guile related discussions
@ 2022-03-10 22:32   ` Zelphir Kaltstahl
  2022-03-10 23:46     ` Olivier Dion via General Guile related discussions
  0 siblings, 1 reply; 15+ messages in thread
From: Zelphir Kaltstahl @ 2022-03-10 22:32 UTC (permalink / raw)
  To: Olivier Dion, guile-user

Hello Olivier!

On 3/10/22 16:05, Olivier Dion wrote:
> On Thu, 10 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
>
>> I have the following questions:
>>
>> (1) Is the read-from-write-to procedure useful at all, or is there a better way
>> to get all stuff from an input port and output it to an output port, avoiding
>> possibly large string values?
> On Linux, there's slice(2) for pipes that does exactly that.
>
> Otherwise, I think this version is a better fit
>
> (define splice
>    (lambda (in-port out-port)
>      "Read from an IN-PORT and write to OUT-PORT"
>      (let loop ([bv (get-bytevector-some in-port)])
>        (unless (eof-object? bv)
>          (put-bytevector out-port bv)
>          (loop (get-bytevector-some in-port))))))
>
> you should not close OUT-PORT.  This break the REPL in my case if using
> the `current-output-port`.
>
Thanks! That solves the problem. I guess a caller of the function can decide 
themselves, when they want to close the port, so no need to close it inside that 
procedure. Closing it inside the procedure would also only limit its use, 
because it could only be used with ports, which are OK to close.

When not closing the port, using (unless ...) also makes more sense than what I had.

Just one question: Why is get-bytevector-some better than get-bytevector-n and 
specifying a number of bytes?

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-10 22:32   ` Zelphir Kaltstahl
@ 2022-03-10 23:46     ` Olivier Dion via General Guile related discussions
  2022-03-11 12:05       ` Chris Vine
  2022-03-11 12:11       ` Maxime Devos
  0 siblings, 2 replies; 15+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-03-10 23:46 UTC (permalink / raw)
  To: Zelphir Kaltstahl, guile-user

On Thu, 10 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:

> Just one question: Why is get-bytevector-some better than
> get-bytevector-n and specifying a number of bytes?

I haven't check the implementation details, but I think it's just a
question of buffering.  `get-bytevector-n` will block just like
`get-bytevector-some` when the port is empty.  The former will return up
to N bytes and the latter might return more than N bytes.  The former
probably also lead to less memory allocation since N is known in
advanced, a singled allocation can be made, while the latter might do
multiple allocations.  This can be useful depending on your usage of the
port.  For example, you could make a web server that only accepts HTTP
body up to 4096 bytes (1 system page).  This is what some web server
does I think.

There's also `get-bytevector-all`, but this would lead to more memory
usage and multiple allocations.  Again, it depends on the usage.

Regards,
old

-- 
Olivier Dion
Polymtl



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-10 23:46     ` Olivier Dion via General Guile related discussions
@ 2022-03-11 12:05       ` Chris Vine
  2022-03-11 14:58         ` Olivier Dion via General Guile related discussions
  2022-03-11 12:11       ` Maxime Devos
  1 sibling, 1 reply; 15+ messages in thread
From: Chris Vine @ 2022-03-11 12:05 UTC (permalink / raw)
  To: guile-user

On Thu, 10 Mar 2022 18:46:34 -0500
Olivier Dion via General Guile related discussions <guile-user@gnu.org>
wrote:
> On Thu, 10 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
> 
> > Just one question: Why is get-bytevector-some better than
> > get-bytevector-n and specifying a number of bytes?
> 
> I haven't check the implementation details, but I think it's just a
> question of buffering.  `get-bytevector-n` will block just like
> `get-bytevector-some` when the port is empty.  The former will return up
> to N bytes and the latter might return more than N bytes.  The former
> probably also lead to less memory allocation since N is known in
> advanced, a singled allocation can be made, while the latter might do
> multiple allocations.  This can be useful depending on your usage of the
> port.  For example, you could make a web server that only accepts HTTP
> body up to 4096 bytes (1 system page).  This is what some web server
> does I think.
> 
> There's also `get-bytevector-all`, but this would lead to more memory
> usage and multiple allocations.  Again, it depends on the usage.

Avoid using get-bytevector-n!, get-bytevector-some and
get-bytevector-all if you are going to use something like fibers or
some other asynchronous i/o, as those procedures are not suspendable
(they can block).  get-bytevector-n (note the difference from
get-bytevector-n!) and get-string-all are suspendable and should
generally be preferred where suspension is required.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-10 23:46     ` Olivier Dion via General Guile related discussions
  2022-03-11 12:05       ` Chris Vine
@ 2022-03-11 12:11       ` Maxime Devos
  2022-03-11 15:06         ` Olivier Dion via General Guile related discussions
  1 sibling, 1 reply; 15+ messages in thread
From: Maxime Devos @ 2022-03-11 12:11 UTC (permalink / raw)
  To: Olivier Dion, Zelphir Kaltstahl, guile-user

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

Olivier Dion via General Guile related discussions schreef op do 10-03-
2022 om 18:46 [-0500]:
> I haven't check the implementation details, but I think it's just a
> question of buffering.  `get-bytevector-n` will block just like
> `get-bytevector-some` when the port is empty.  The former will return up
> to N bytes and the latter might return more than N bytes.

I don't think that get-bytevector-some can return more, and it could
return less:

     Return either [...] or a new bytevector containing some of the
     available bytes (at least one),

Also, gnunet-scheme depends on the behaviour of it (*) being able to
return less without blocking (in gnu/gnunet/utils/tokeniser.scm).  If
the behaviour was different, there would have been many test failures.

(*) actually, it uses the variant 'get-bytevector-some!' instead of
'get-bytevector-some'.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 12:05       ` Chris Vine
@ 2022-03-11 14:58         ` Olivier Dion via General Guile related discussions
  2022-03-11 17:26           ` Chris Vine
  0 siblings, 1 reply; 15+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-03-11 14:58 UTC (permalink / raw)
  To: Chris Vine, guile-user

On Fri, 11 Mar 2022, Chris Vine <vine24683579@gmail.com> wrote:
> On Thu, 10 Mar 2022 18:46:34 -0500
> Olivier Dion via General Guile related discussions <guile-user@gnu.org>
> wrote:
>> On Thu, 10 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
>> 
>> > Just one question: Why is get-bytevector-some better than
>> > get-bytevector-n and specifying a number of bytes?
>> 
>> I haven't check the implementation details, but I think it's just a
>> question of buffering.  `get-bytevector-n` will block just like
>> `get-bytevector-some` when the port is empty.  The former will return up
>> to N bytes and the latter might return more than N bytes.  The former
>> probably also lead to less memory allocation since N is known in
>> advanced, a singled allocation can be made, while the latter might do
>> multiple allocations.  This can be useful depending on your usage of the
>> port.  For example, you could make a web server that only accepts HTTP
>> body up to 4096 bytes (1 system page).  This is what some web server
>> does I think.
>> 
>> There's also `get-bytevector-all`, but this would lead to more memory
>> usage and multiple allocations.  Again, it depends on the usage.
>
> Avoid using get-bytevector-n!, get-bytevector-some and
> get-bytevector-all if you are going to use something like fibers or
> some other asynchronous i/o, as those procedures are not suspendable
> (they can block).  get-bytevector-n (note the difference from
> get-bytevector-n!) and get-string-all are suspendable and should
> generally be preferred where suspension is required.

I'm not sure this is related to the functions themself but instead the
underlying filedescriptor opened iwth ON_NONBLOCK?

-- 
Olivier Dion
Polymtl



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 12:11       ` Maxime Devos
@ 2022-03-11 15:06         ` Olivier Dion via General Guile related discussions
  0 siblings, 0 replies; 15+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-03-11 15:06 UTC (permalink / raw)
  To: Maxime Devos, Zelphir Kaltstahl, guile-user

On Fri, 11 Mar 2022, Maxime Devos <maximedevos@telenet.be> wrote:
> Olivier Dion via General Guile related discussions schreef op do 10-03-
> 2022 om 18:46 [-0500]:
>> I haven't check the implementation details, but I think it's just a
>> question of buffering.  `get-bytevector-n` will block just like
>> `get-bytevector-some` when the port is empty.  The former will return up
>> to N bytes and the latter might return more than N bytes.
>
> I don't think that get-bytevector-some can return more, and it could
> return less:
>
>      Return either [...] or a new bytevector containing some of the
>      available bytes (at least one),

More or less is relative to the N value compared with get-bytevector-n.
So realy the `some` value is unknown.  You just know you will have at
least a byte yes.

> Also, gnunet-scheme depends on the behaviour of it (*) being able to
> return less without blocking (in gnu/gnunet/utils/tokeniser.scm).  If
> the behaviour was different, there would have been many test failures.
>
> (*) actually, it uses the variant 'get-bytevector-some!' instead of
> 'get-bytevector-some'.

Re-using the same vector would certainly reduce memory
usage/fragmentation I suppose.  Internally, the latter use the former I
think.

Regards,
old

-- 
Olivier Dion
Polymtl



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 14:58         ` Olivier Dion via General Guile related discussions
@ 2022-03-11 17:26           ` Chris Vine
  2022-03-11 17:47             ` Olivier Dion via General Guile related discussions
  2022-03-11 18:13             ` Chris Vine
  0 siblings, 2 replies; 15+ messages in thread
From: Chris Vine @ 2022-03-11 17:26 UTC (permalink / raw)
  To: guile-user

On Fri, 11 Mar 2022 09:58:59 -0500
Olivier Dion <olivier.dion@polymtl.ca> wrote:
> On Fri, 11 Mar 2022, Chris Vine <vine24683579@gmail.com> wrote:
[snip]
> > Avoid using get-bytevector-n!, get-bytevector-some and
> > get-bytevector-all if you are going to use something like fibers or
> > some other asynchronous i/o, as those procedures are not suspendable
> > (they can block).  get-bytevector-n (note the difference from
> > get-bytevector-n!) and get-string-all are suspendable and should
> > generally be preferred where suspension is required.
> 
> I'm not sure this is related to the functions themself but instead the
> underlying filedescriptor opened iwth ON_NONBLOCK?

The problem I am referring to is different: it is that delimited
continuations cannot capture C code and ports are written in C.
Suspendable specializations, written in pure scheme, of some of guile's
i/o procedures are therefore provided in
modules/ice-9/suspendable-ports.scm, which is a file worth reading on
its own account, and which are brought into effect (by suppressing the
C-based equivalents) by applying the install-suspendable-ports!
procedure.  If your i/o steps out of this set of primitives (see in
particular the port-bindings variable in that file) then it is not
suspendable.

When suspendable ports were first introduced in guile-2.2.0, this
safe set did not include get-bytevector-n!, get-bytevector-some,
get-bytevector-some! and get-bytevector-all: I have just re-read the
code in guile-2.2.0 to confirm this.  I have also just checked with the
latest versions of guile-2.2 and guile-3.0 and it appears that
get-bytevector-n!, get-bytevector-some and get-bytevector-some! are now
supported so it looks as if at some point since version 2.2.0 they have
become OK.

With guile-2.2.0, this in turn meant that amongst other things,
http-get, http-put and so on could not normally be used in suspendable
code.  I would need to check whether that remains the case - I cannot
now remember which calls they made which were forbidden to suspendable
code.

Notable procedures which it appears remain as non-suspendable are
get-bytevector-all, get-string-n, read, write and display, but to be
sure about the first two of those I would also need to read the source
again.  A few years ago I had some test code to test which procedures
were suspendable and I will also have to see if I can find it again.

Chris



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 17:26           ` Chris Vine
@ 2022-03-11 17:47             ` Olivier Dion via General Guile related discussions
  2022-03-11 18:13             ` Chris Vine
  1 sibling, 0 replies; 15+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-03-11 17:47 UTC (permalink / raw)
  To: Chris Vine, guile-user

On Fri, 11 Mar 2022, Chris Vine <vine24683579@gmail.com> wrote:
> On Fri, 11 Mar 2022 09:58:59 -0500
> Olivier Dion <olivier.dion@polymtl.ca> wrote:
>> I'm not sure this is related to the functions themself but instead the
>> underlying filedescriptor opened iwth ON_NONBLOCK?
>
> The problem I am referring to is different: it is that delimited
> continuations cannot capture C code and ports are written in C.
> Suspendable specializations, written in pure scheme, of some of
> guile's i/o procedures are therefore provided in
> modules/ice-9/suspendable-ports.scm, which is a file worth reading on
> its own account, and which are brought into effect (by suppressing the
> C-based equivalents) by applying the install-suspendable-ports!
> procedure.  If your i/o steps out of this set of primitives (see in
> particular the port-bindings variable in that file) then it is not
> suspendable.

Oh okay!  I understand now!

-- 
Olivier Dion
Polymtl



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 17:26           ` Chris Vine
  2022-03-11 17:47             ` Olivier Dion via General Guile related discussions
@ 2022-03-11 18:13             ` Chris Vine
  2022-03-11 19:48               ` Maxime Devos
  2022-03-11 19:49               ` Maxime Devos
  1 sibling, 2 replies; 15+ messages in thread
From: Chris Vine @ 2022-03-11 18:13 UTC (permalink / raw)
  To: guile-user

On Fri, 11 Mar 2022 17:26:50 +0000
Chris Vine <vine24683579@gmail.com> wrote:
> Notable procedures which it appears remain as non-suspendable are
> get-bytevector-all, get-string-n, read, write and display, but to be
> sure about the first two of those I would also need to read the source
> again.  A few years ago I had some test code to test which procedures
> were suspendable and I will also have to see if I can find it again.

I have resurrected my old test code and I can confirm that
get-bytevector-n, get-bytevector-n!, get-bytevector-some and
get-bytevector-some! are now suspension safe in guile-2.2.6 and
guile-3.0.8, but get-bytevector-all, get-string-n and get-string-n!
remain unsafe.

Interestingly the read procedure remains unsafe in guile-2.2.6, but
seems to be safe in guile-3.0.8 even though I cannot see what in the
code has changed.  I have yet to re-equip my tests to test the write and
display procedures, or to see what effect this has on http-get,
http-put and the like.

Chris



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 18:13             ` Chris Vine
@ 2022-03-11 19:48               ` Maxime Devos
  2022-03-11 19:49               ` Maxime Devos
  1 sibling, 0 replies; 15+ messages in thread
From: Maxime Devos @ 2022-03-11 19:48 UTC (permalink / raw)
  To: Chris Vine, guile-user

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

Chris Vine schreef op vr 11-03-2022 om 18:13 [+0000]:
> Interestingly the read procedure remains unsafe in guile-2.2.6, but
> seems to be safe in guile-3.0.8 even though I cannot see what in the

This is probably due to the rewrite of the 'read' procedure in Scheme
(see module/ice-9/read.scm (cannot be imported as a module)).  There's
still a C version of the read procedure, but as I understand it it is
only for bootstrapping (and maybe performance, I dunno).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 18:13             ` Chris Vine
  2022-03-11 19:48               ` Maxime Devos
@ 2022-03-11 19:49               ` Maxime Devos
  2022-03-12  0:10                 ` Chris Vine
  1 sibling, 1 reply; 15+ messages in thread
From: Maxime Devos @ 2022-03-11 19:49 UTC (permalink / raw)
  To: Chris Vine, guile-user

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

Chris Vine schreef op vr 11-03-2022 om 18:13 [+0000]:
> code has changed.  I have yet to re-equip my tests to test the write and
> display procedures,

Those aren't rewritten in Scheme (yet?).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-11 19:49               ` Maxime Devos
@ 2022-03-12  0:10                 ` Chris Vine
  2022-03-12  0:27                   ` Chris Vine
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Vine @ 2022-03-12  0:10 UTC (permalink / raw)
  To: guile-user

On Fri, 11 Mar 2022 20:49:53 +0100
Maxime Devos <maximedevos@telenet.be> wrote:
> Chris Vine schreef op vr 11-03-2022 om 18:13 [+0000]:
> > code has changed.  I have yet to re-equip my tests to test the write and
> > display procedures,
> 
> Those aren't rewritten in Scheme (yet?).

I believe not.  Unfortunately this kind of thing is not well
documented: I think you are expected to read through the source code
yourself.  On doing so, the write and display procedures still seem to
be implemented in write.c.  Of course I could have missed something.

This leads onto your response about the read procedure.  Your
explanation seems like the right one.

Chris



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Question about an error with ports
  2022-03-12  0:10                 ` Chris Vine
@ 2022-03-12  0:27                   ` Chris Vine
  0 siblings, 0 replies; 15+ messages in thread
From: Chris Vine @ 2022-03-12  0:27 UTC (permalink / raw)
  To: guile-user

On Sat, 12 Mar 2022 00:10:36 +0000
Chris Vine <vine24683579@gmail.com> wrote:

> On Fri, 11 Mar 2022 20:49:53 +0100
> Maxime Devos <maximedevos@telenet.be> wrote:
> > Chris Vine schreef op vr 11-03-2022 om 18:13 [+0000]:
> > > code has changed.  I have yet to re-equip my tests to test the write and
> > > display procedures,
> > 
> > Those aren't rewritten in Scheme (yet?).
> 
> I believe not.  Unfortunately this kind of thing is not well
> documented: I think you are expected to read through the source code
> yourself.  On doing so, the write and display procedures still seem to
> be implemented in write.c.  Of course I could have missed something.
                    ^^^^^^^

Correction: print.c



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-03-12  0:27 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-10  1:26 Question about an error with ports Zelphir Kaltstahl
2022-03-10 15:05 ` Olivier Dion via General Guile related discussions
2022-03-10 22:32   ` Zelphir Kaltstahl
2022-03-10 23:46     ` Olivier Dion via General Guile related discussions
2022-03-11 12:05       ` Chris Vine
2022-03-11 14:58         ` Olivier Dion via General Guile related discussions
2022-03-11 17:26           ` Chris Vine
2022-03-11 17:47             ` Olivier Dion via General Guile related discussions
2022-03-11 18:13             ` Chris Vine
2022-03-11 19:48               ` Maxime Devos
2022-03-11 19:49               ` Maxime Devos
2022-03-12  0:10                 ` Chris Vine
2022-03-12  0:27                   ` Chris Vine
2022-03-11 12:11       ` Maxime Devos
2022-03-11 15:06         ` Olivier Dion via General Guile related discussions

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).