Re: Status of Submitted Patches

[Ricardo Wurmus <rekado@elephly.net>]

Hi Sahithi,

>>> According to the Guile manual
>>>
>>>    Ports are the way that Guile performs input and output.  Guile can
>>>    read in characters or bytes from an “input port”, or write them out
>>>    to an “output port”.
>>>
>>> Ports allow the programmer to ignore the details of input/output sources
>>> and sinks and concentrate on shuffling characters or bytes around.  We
>>> don’t need to know if the port is connected to a terminal or a file or a
>>> network socket.
>>>
>>> A programmer can implement custom ports with “make-soft-port” and a
>>> vector of up to five procedures that provide implementations of certain
>>> operations (such as writing a string to the port).  A silly example
>>> would be a custom port that reads characters from standard input and
>>> turns them to upper-case characters before passing them to whoever reads
>>> from the custom port.

> (use-modules (ice-9 binary-ports))
> (define stdout (current-output-port))
> (define stdin (current-input-port))
> (display stdin)
> (newline)
> (display stdout)
> (newline)

These definitions have no effect on the code that follows.  “stdout” and
“stdin” have no special meaning.  You are just defining variables with
these names, but you could give them any names.  Giving them names has
no meaningful effect, because you are not using the names later anyway.

> (write (char-upcase(read-char(current-input-port))))

Here you are reading a character from the current input port.  The
result is fed to “char-upcase”, which turns it into an upper-case
variant, and then you write that character to the current default output
port.

While this achieves the goal for a single character it does not
constitute a custom port.  Have you read the documentation for
“make-custom-port” in the Guile manual?

>>> With what you know about terminal escape codes and the port facility
>>> that is used in “(guix store)”, can you describe an approach to add
>>> colours to some text fragments before they are printed?  There are at
>>> least two ways this can be done; one of the two options is more
>>> complicated but might result in a clearer and more modular
>>> implementation.
>
> For this i tried using […]

Actually, I was looking for a description of the two options, not an
implementation :)

Can you think of two possible ways to add colours to text fragments, and
describe them in a few sentences?  If you can only think of one
approach, please describe only that approach.

I guess that you wanted the value of “a” to be printed in colours, but
the code says otherwise.  Here you are just displaying a string that
contains the character “a”, not the value of the variable with the name
“a”.

> (define a (char-upcase(read-char (current-input-port))))
[…]
> (define b (colorize-string a '(GREEN)))
> (display b)
[…]
> 4058: 2 [#<procedure 560e4a6de9c0 at ice-9/boot-9.scm:4051:3 ()>]
> In /home/sripathroy/Documents/GNUGuix/experiments/sam.scm:
>  17: 1 [#<procedure 560e4ab74920 ()>]
> In unknown file:
>  ?: 0 [string-append "\x1b[32m" #\S "\x1b[0m"]
>
> ERROR: In procedure string-append:
> ERROR: In procedure string-append: Wrong type (expecting string): #\S

What type is the value in the variable with name “a”?  “read-char” takes
a port and returns a single character from it, “char-upcase” takes a
character and returns a different character, so “a” holds a character.
As you know, the implementation of “colorize-string” internally glues a
bunch of strings together: a terminal escape sequence to set the colour,
the string to be coloured, and a terminal escape sequence to disable the
colour.  You gave a character to the procedure, but it expects a string.

You can convert strings to characters, but this is not what should be
done here.  If you did that for the string “hello” you would enable
colours, print an “h”, disable colours, enable colours, print an “e”,
disable colours, etc.  That’s rather wasteful because you really want to
only enable colours once, print the string, and then disable colours
again.

But we’re getting ahead of ourselves.  Getting back to the original
problem: can you think of and shortly describe two possible ways to
alter, filter or augment the output that is sent to the
“current-build-output-port” in “(guix store)”?  Try to describe this at
a higher level, ignoring a concrete implementation.  (Bits are for
computers, ideas are for humans.)

--
Ricardo