Re: (Geiser or guile bug) Guix-daemon output is missing

[Alex Kost]

Alex Kost (2015-09-10 00:24 +0300) wrote:

> Ludovic Courtès (2015-09-09 23:11 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> As a workaround for this issue it was proposed¹ to transform
>>> ‘current-build-output-port’ into a procedure (I have checked that it
>>> solves the problem).  What do you think about it?  Perhaps to make sure
>>> that the port will be always the same define it like this:
>>>
>>> (define current-build-output-port (memoize current-error-port))
>>>
>>> Is it acceptable?
>>
>> No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
>> that callers can easily rebind it.
>>
>> However, perhaps the guix.el code could do:
>>
>>   (current-build-output-port (current-error-port))
>>
>> at startup; would that be doable?
>
> (IMO it would be so ugly, that I should say: "no")

After thinking more, I had an idea how to make a not-so-ugly workaround,
so "yes", I think I'll do a workaround on elisp side.

-- 
Alex

Re: (Geiser or guile bug) Guix-daemon output is missing

[Ludovic Courtès]

Alex Kost  skribis:

> As a workaround for this issue it was proposed¹ to transform
> ‘current-build-output-port’ into a procedure (I have checked that it
> solves the problem).  What do you think about it?  Perhaps to make sure
> that the port will be always the same define it like this:
>
> (define current-build-output-port (memoize current-error-port))
>
> Is it acceptable?

No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
that callers can easily rebind it.

However, perhaps the guix.el code could do:

  (current-build-output-port (current-error-port))

at startup; would that be doable?

Thanks,
Ludo’.

Re: (Geiser or guile bug) Guix-daemon output is missing

[Alex Kost]

Ludovic Courtès (2015-09-09 23:11 +0300) wrote:

> Alex Kost  skribis:
>
>> As a workaround for this issue it was proposed¹ to transform
>> ‘current-build-output-port’ into a procedure (I have checked that it
>> solves the problem).  What do you think about it?  Perhaps to make sure
>> that the port will be always the same define it like this:
>>
>> (define current-build-output-port (memoize current-error-port))
>>
>> Is it acceptable?
>
> No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
> that callers can easily rebind it.
>
> However, perhaps the guix.el code could do:
>
>   (current-build-output-port (current-error-port))
>
> at startup; would that be doable?

(IMO it would be so ugly, that I should say: "no")

Do you mean at startup of Guix REPL?  If you remember the point is to
add an emacs command to build the package in the current Geiser REPL
(not Guix REPL).  So to prevent this disappearing of the build output,
(current-build-output-port (current-error-port)) should be evaluated in
the *Geiser REPL*.  We can make a workaround just for ‘build-package’
procedure by putting this port assigning in it, but the only way to make
a global solution is to get rid of the top-level setting of
‘current-build-output-port’, for example by:

(define current-build-output-port (make-parameter #f))

and bind it to current-error-port in ‘process-stderr’, but I suppose
this is also undesired, right?

-- 
Alex

Re: (Geiser or guile bug) Guix-daemon output is missing

[Alex Kost]

Ludovic Courtès (2015-09-07 00:28 +0300) wrote:

> Alex Kost  skribis:
>
>> Now the bug itself:
>>
>> 1. Start Geiser (M-x run-guile)
>>
>> 2. Make a scheme buffer and evaluate (use-modules (guix scripts build))
>>there using "C-x C-e" or "C-M-x" (or any other "geiser-eval-…"
>>command).  This is important: do not ,use module in the REPL;
>>evaluate ‘use-modules’ clause in a scheme buffer!
>>
>> 3. Go to the REPL and run the following there:
>>
>>(catch 'quit (lambda () (guix-build "test-package")) (const #t)).
>>
>> You get only "The following derivation will be built: …" but there is no
>> build output from guix-daemon.
>
> Ha ha!  Try this before:
>
>   (current-build-output-port (current-error-port))
>
> The trick here is that ‘current-build-output-port’ is initialized to
> (current-error-port), but that initialization happens at the top-level,
> apparently before Geiser has rebound ‘current-error-port’, hence the
> silence.
>
> HTH!

Thanks for answering!  This helped to make a simple recipe, so I
reported it: .

-- 
Alex