From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#21829: guix import hackage failures Date: Thu, 12 Nov 2015 10:07:59 +0100 Message-ID: <87vb971t74.fsf@gnu.org> References: <87d1vghjhk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwnsR-0006Nj-Po for bug-guix@gnu.org; Thu, 12 Nov 2015 04:09:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwnsN-0002gD-0c for bug-guix@gnu.org; Thu, 12 Nov 2015 04:09:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:43314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwnsM-0002g9-Ta for bug-guix@gnu.org; Thu, 12 Nov 2015 04:09:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZwnsM-0000bG-Fr for bug-guix@gnu.org; Thu, 12 Nov 2015 04:09:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (Federico Beffa's message of "Wed, 11 Nov 2015 22:29:20 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Federico Beffa Cc: 21829@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Federico Beffa skribis: > On Wed, Nov 11, 2015 at 12:18 PM, Ludovic Court=C3=A8s wro= te: >> Federico Beffa 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, Obje= ctName, >>> 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-po= rt) > (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=E2=80=99t be easier to change the lexer to recognize = line feeds are white space or newlines, maybe along these lines: --=-=-= Content-Type: text/x-patch Content-Disposition: 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) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQpXRFlUPw0KDQpMdWRv4oCZLg0K --=-=-=--