GNU bug report logs - #21829
guix import hackage failures

Previous Next

Package: guix;

Reported by: Paul van der Walt <paul <at> denknerd.org>

Date: Wed, 4 Nov 2015 16:26:03 UTC

Severity: normal

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

Full log


Message #20 received at 21829 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Federico Beffa <beffa <at> ieee.org>
Cc: 21829 <at> debbugs.gnu.org, Paul van der Walt <paul <at> denknerd.org>
Subject: Re: guix import hackage failures
Date: Thu, 12 Nov 2015 10:07:59 +0100
[Message part 1 (text/plain, inline)]
Federico Beffa <beffa <at> ieee.org> skribis:

> On Wed, Nov 11, 2015 at 12:18 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> Federico Beffa <beffa <at> ieee.org> skribis:
>>
>>> * I do not get backtraces, but the following error:
>>
>> The backtrace thing was fixed in 5453de3d.
>>
>>> * The following packages fail because the file has DOS line endings:
>>>
>>>   happy, base-compat, base-orphans, fast-logger, generic-deriving, ObjectName,
>>>   SDL, setenv, split, StateVar, syb, transformers-base, wai, xmonad (+ 1 more
>>>   problem), zlib (+ 1 more problem).
>>>
>>>  Changing the encoding to UNIX line endings fixes the problem. This is
>>> the number 1 problem. Is there a Guile way to easily fix this?
>>
>> Could you explain how if fails exactly?
>
> The extra character '\r' screws up the parsing because it was not
> accounted for in the logic to recognize multi-line values and
> indentation based block separation.
>
> What do you think of a kind of piped filter as follows:
>
> (define (call-with-input-file-eol-crlf->lf proc port)
>   (let* ((port-pair (pipe))
>          (input-port (match port-pair ((in . out) in)))
>          (output-port (match port-pair ((in . out) out))))
>     (letpar ((transcoder
>               (let loop ((line (get-line port)))
>                 (unless (eof-object? line)
>                   (write-line (string-trim-right line #\return) output-port)
>                   (loop (get-line port)))
>                 (flush-output-port output-port)))
>              (result (proc input-port)))
>             (close-output-port output-port)
>             (close-input-port input-port)
>             result)))
>
> Then instead of calling (read-cabal port) I would call
> (call-with-input-file-eol-crlf->lf read-cabal port).

I wonder if it wouldn’t be easier to change the lexer to recognize line
feeds are white space or newlines, maybe along these lines:

[Message part 2 (text/x-patch, inline)]
diff --git a/guix/import/cabal.scm b/guix/import/cabal.scm
index 45d644a..0dd329c 100644
--- a/guix/import/cabal.scm
+++ b/guix/import/cabal.scm
@@ -259,10 +259,11 @@ otherwise return BOL (beginning-of-line)."
              (bol bol))
     (cond
      ((and (not (eof-object? c))
-           (or (char=? c #\space) (char=? c #\tab)))
+           (or (char-set-contains? char-set:whitespace c)))
       (read-char port)
       (loop (peek-char port) bol))
-     ((and (not (eof-object? c)) (char=? c #\newline))
+     ((and (not (eof-object? c))
+           (or (char=? c #\newline) (char=? c #\return)))
       (read-char port)
       (loop (peek-char port) #t))
      ((comment-line port c)
[Message part 3 (text/plain, inline)]
WDYT?

Ludo’.

This bug report was last modified 9 years and 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.