all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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’.

  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.