From: ludo@gnu.org (Ludovic Courtès)
To: Federico Beffa <beffa@ieee.org>
Cc: 21829@debbugs.gnu.org
Subject: bug#21829: guix import hackage failures
Date: Sun, 15 Nov 2015 21:59:37 +0100 [thread overview]
Message-ID: <87k2pjq8qu.fsf@gnu.org> (raw)
In-Reply-To: <CAKrPhPMQ7fFTURcz83XZkZ2ho4OBdQ7PHWb4EFwySOUQobkhUg@mail.gmail.com> (Federico Beffa's message of "Sat, 14 Nov 2015 15:37:35 +0100")
Federico Beffa <beffa@ieee.org> skribis:
> On Fri, Nov 13, 2015 at 10:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
[...]
>> In practice this discards LF even if it’s not following CR; that’s
>> probably a good enough approximation, but an XXX comment would be
>> welcome.
>
> This is intentional because, in my ignorance, I only know of uses of
> '\r' before or after '\n'. Do you know of any other use in text files?
ISTR that some OSes (MacOS 9 and earlier?! who cares?! :-)) use(d) a
single LF instead of a single CR.
Again that’s fine in practice I guess, but I always think it’s good to
add a note when we make an approximation so we can notice later, just in
case.
> The attached patches fix the parsing of all but two of the failures
> reported by Paul.
> Two cabal files are still not imported correctly because they are buggy:
>
> * streaming-commons: indentation changes from 4 to 2. But this is
> explicitly forbidden. From [1]: "Field names may be indented, but all
> field values in the same section must use the same indentation."
>
> * fgl: uses braces to delimit the value of a field. As far as I
> understand this is not allowed by [1]: "To continue a field value,
> indent the next line relative to the field name." and "Flags,
> conditionals, library and executable sections use layout to indicate
> structure. ... As an alternative to using layout you can also use
> explicit braces {}. ". Thus I understand that braces may be used to
> delimit sections, not field values.
Fair enough!
> Obviously the official 'cabal' program is more permissive than the
> description in the documentation.
We’re more royalist than the king! ;-)
> From d13f06383d07e0ad4096ff7eb715264463738b0c Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Wed, 11 Nov 2015 10:39:38 +0100
> Subject: [PATCH 1/6] import: hackage: Add recognition of 'true' and 'false'
> symbols.
>
> * guix/import/cabal.scm (is-true, is-false, lex-true, lex-false): New procedures.
> (lex-word): Use them.
> (make-cabal-parser): Add TRUE and FALSE tokens.
> (eval): Add entries for 'true and 'false symbols.
LGTM.
> From 445f1b6197c0e266027ac033c52629d990137171 Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Wed, 11 Nov 2015 11:22:42 +0100
> Subject: [PATCH 2/6] import: hackage: Imporve parsing of tests.
>
> * guix/import/cabal.scm (lex-word): Add support for tests with no spaces.
> (impl): Fix handling of operator "==".
LGTM, but I think it’d be great to add a test that illustrates the case
that this fixes (and to make sure it doesn’t come back later.)
> From f796d814821289a98e401a3e3df13334a2e8689b Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Wed, 11 Nov 2015 15:31:46 +0100
> Subject: [PATCH 3/6] import: hackage: Make it resilient to missing final
> newline.
>
> * guix/import/cabal.scm (peek-next-line-indent): Check for missing final
> newline.
[...]
> + (if (eof-object? (peek-char port))
> + ;; If the file is missing the #\newline on the last line, add it and act
> + ;; as if it were there. This is needed for propoer operation of
^^^^
Typo.
> + ;; indentation based block recognition.
> + (begin (unread-char #\newline port) (read-char port) 0)
Isn’t this equivalent to: 0 ?
Could you add a test for this one?
> From 225164d2355afd6f9455251d87cbd34b08f68cdb Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Wed, 11 Nov 2015 16:20:45 +0100
> Subject: [PATCH 4/6] import: hackage: Make parsing of tests and fields more
> flexible.
>
> * guix/import/cabal.scm (is-test): Allow spaces between keyword and
> parentheses.
> (is-id): Add argument 'port'. Allow spaces between keyword and column.
> (lex-word): Adjust call to 'is-id'.
LGTM, and would be perfect with a test. ;-)
> From 1b26410f4a7a920382750bffbf5381394acafdbc Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Sat, 14 Nov 2015 15:00:36 +0100
> Subject: [PATCH 5/6] utils: Add 'canonical-newline-port'.
>
> * guix/utils.scm (canonical-newline-port): New procedure.
> * tests/utils.scm ("canonical-newline-port"): New test.
[...]
> +(test-equal "canonical-newline-port"
> + "This is a journey"
> + (let ((port (open-string-input-port
> + "This is a journey\r\n")))
> + (get-line (canonical-newline-port port))))
I would rather use ‘get-string-all’ and make sure the result is exactly:
"This is a journey\n"
(Because ‘get-line’ could have been doing its own thing regardless of
the EOL style.)
A test with several lines, including lines with just \n would be nice.
> From c57be8cae9b3642beff1462acd32a0aee54ad7c6 Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa@fbengineering.ch>
> Date: Sat, 14 Nov 2015 15:15:00 +0100
> Subject: [PATCH 6/6] import: hackage: Handle CRLF end of line style.
>
> * guix/import/hackage.scm (hackage-fetch, hackage->guix-package): Do it.
Rather “Use ‘canonical-newline-port’.” instead of “Do it.”
Thanks for all the work!
Ludo’.
next prev parent reply other threads:[~2015-11-15 21:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 15:00 bug#21829: guix import hackage failures Paul van der Walt
2015-11-04 23:11 ` Ludovic Courtès
2015-11-10 16:40 ` Federico Beffa
2015-11-11 11:18 ` Ludovic Courtès
2015-11-11 21:29 ` Federico Beffa
2015-11-12 9:07 ` Ludovic Courtès
2015-11-12 16:54 ` Federico Beffa
2015-11-12 20:21 ` Ludovic Courtès
2015-11-13 17:08 ` Federico Beffa
2015-11-13 21:19 ` Ludovic Courtès
2015-11-14 14:37 ` Federico Beffa
2015-11-15 20:59 ` Ludovic Courtès [this message]
2015-11-25 16:55 ` Federico Beffa
2015-11-25 21:45 ` Ludovic Courtès
2015-11-26 8:28 ` Federico Beffa
2015-11-26 8:46 ` Ludovic Courtès
2015-11-26 17:23 ` Federico Beffa
2015-11-26 19:56 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k2pjq8qu.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=21829@debbugs.gnu.org \
--cc=beffa@ieee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.