Re: 01/01: gnu: cmake: Delete Emacs library.

Re: 01/01: gnu: cmake: Delete Emacs library.

[Mark H Weaver]

Hi Oleg,

go.wigust@gmail.com (Oleg Pykhalov) writes:

> wigust pushed a commit to branch core-updates
> in repository guix.
>
> commit f037673c3133ae7453794f1f62eecebf9d06b092
> Author: Oleg Pykhalov <go.wigust@gmail.com>
> Date:   Tue May 22 07:41:45 2018 +0300
>
>     gnu: cmake: Delete Emacs library.
>     
>     * gnu/packages/finance.scm (cmake)[arguments]: Delete Emacs library.

According to "guix refresh -l cmake", this will require 2783 rebuilds on
x86_64, and probably similar numbers of rebuilds on other systems.

I think this is too much for core-updates right now, which has been
officially frozen since April 2.

Also, the commit log is wrong (it says that the changes were in
finance.scm), and:

> @@ -85,6 +85,12 @@
>             " --exclude-regex ^\\(" (string-join skipped-tests "\\|") "\\)$")))
>         #:phases
>         (modify-phases %standard-phases
> +         (add-after 'unpack 'split-package
> +           ;; Remove files that have been packaged in other package recipes.
> +           (lambda _
> +             (delete-file "Auxiliary/cmake-mode.el")
> +             (substitute* "Auxiliary/CMakeLists.txt"
> +               ((".*cmake-mode.el.*") ""))))

this new phase that you've added returns an unspecified value, although
it is supposed to return a boolean to indicate success or failure.
Moreover, we're currently transitioning toward always returning #t from
phases and reporting any errors using exceptions instead.

In core-updates, we've made good progress toward this goal: all phases
for all core packages, and all packages that I build on my GNOME-based
GuixSD system, have been fixed to always return #t.  It would be good to
avoid moving backwards w.r.t. to that goal.

So, I've reverted your commit on 'core-updates'.  After fixing the
commit log and return value of the new phase, how about pushing this to
'core-updates-next' instead?

What do you think?

      Mark

Re: 01/01: gnu: cmake: Delete Emacs library.

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

Hello Mark,

Mark H Weaver <mhw@netris.org> writes:

[…]

> go.wigust@gmail.com (Oleg Pykhalov) writes:
>
>> wigust pushed a commit to branch core-updates
>> in repository guix.
>>
>> commit f037673c3133ae7453794f1f62eecebf9d06b092
>> Author: Oleg Pykhalov <go.wigust@gmail.com>
>> Date:   Tue May 22 07:41:45 2018 +0300
>>
>>     gnu: cmake: Delete Emacs library.
>>     
>>     * gnu/packages/finance.scm (cmake)[arguments]: Delete Emacs library.

[…]

> Also, the commit log is wrong (it says that the changes were in
> finance.scm), and:

Ouch, I'm sorry.

>> @@ -85,6 +85,12 @@
>>             " --exclude-regex ^\\(" (string-join skipped-tests "\\|") "\\)$")))
>>         #:phases
>>         (modify-phases %standard-phases
>> +         (add-after 'unpack 'split-package
>> +           ;; Remove files that have been packaged in other package recipes.
>> +           (lambda _
>> +             (delete-file "Auxiliary/cmake-mode.el")
>> +             (substitute* "Auxiliary/CMakeLists.txt"
>> +               ((".*cmake-mode.el.*") ""))))
>
> this new phase that you've added returns an unspecified value, although
> it is supposed to return a boolean to indicate success or failure.

substitute* returns #t if it finds a file and error otherwise.  Do I
miss understand something?

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (substitute* "/tmp/test.txt" (("Hello") "foo"))
$3 = #t
scheme@(guile-user)> (substitute* "/tmp/test.txt" (("bla") "foo"))
$4 = #t
scheme@(guile-user)> (substitute* "/tmp/test.txtf" (("bla") "foo"))
ERROR: In procedure stat:
In procedure stat: No such file or directory: "/tmp/test.txtf"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
--8<---------------cut here---------------end--------------->8---

/tmp/test.txt
--8<---------------cut here---------------start------------->8---
Hello
--8<---------------cut here---------------end--------------->8---

[…]

> After fixing the commit log and return value of the new phase, how
> about pushing this to 'core-updates-next' instead?

OK, I'll do it later.

> What do you think?

core-updates-next branch should be mentioned in Guix documentation
https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html

Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: 01/01: gnu: cmake: Delete Emacs library.

[Mark H Weaver]

Hi Oleg,

Oleg Pykhalov <go.wigust@gmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> go.wigust@gmail.com (Oleg Pykhalov) writes:
>>
>>> @@ -85,6 +85,12 @@
>>>             " --exclude-regex ^\\(" (string-join skipped-tests "\\|") "\\)$")))
>>>         #:phases
>>>         (modify-phases %standard-phases
>>> +         (add-after 'unpack 'split-package
>>> +           ;; Remove files that have been packaged in other package recipes.
>>> +           (lambda _
>>> +             (delete-file "Auxiliary/cmake-mode.el")
>>> +             (substitute* "Auxiliary/CMakeLists.txt"
>>> +               ((".*cmake-mode.el.*") ""))))
>>
>> this new phase that you've added returns an unspecified value, although
>> it is supposed to return a boolean to indicate success or failure.
>
> substitute* returns #t if it finds a file and error otherwise.  Do I
> miss understand something?

Yes.  You are confusing the *specification* with the behavior of the
current implementation.  Also, you've reached a mistaken conclusion
about the behavior of the current implementation.

The specification (i.e. documentation) for 'substitute*' says nothing
about its return value.  That's what I mean when I say that its return
value is "unspecified".

> scheme@(guile-user)> (substitute* "/tmp/test.txt" (("Hello") "foo"))
> $3 = #t
> scheme@(guile-user)> (substitute* "/tmp/test.txt" (("bla") "foo"))
> $4 = #t
> scheme@(guile-user)> (substitute* "/tmp/test.txtf" (("bla") "foo"))
> ERROR: In procedure stat:
> In procedure stat: No such file or directory: "/tmp/test.txtf"

Here you've attempted to determine the specification of 'substitute*' by
experiment on a few examples, and on the basis of these results have
apparently concluded that:

  "substitute* returns #t if it finds a file and error otherwise."

In fact, this conclusion is incorrect.  Here's a counterexample:

  scheme@(guile-user)> ,use (guix build utils)
  scheme@(guile-user)> (define return-val
                         (substitute* (list "HACKING" "INSTALL")
                           (("bla") "foo")))
  scheme@(guile-user)> (list return-val)
  $1 = (#<unspecified>)

In general, it's a mistake to try to determine the specification of a
procedure or macro by experiment, or even by analyzing its current
implementation.

Suppose that you examine the current implementation of some procedure
and find that it always returns #t.  Even so, that tells you nothing
about the behavior of future implementations.  If the specification of a
procedure says nothing about its return value, then future implementors
may legitimately feel free to pay no attention to the return value, and
thereby allow the return value to be whatever happens by accident.

That's why the *specification* is what you need to know when using a
procedure or macro.  Knowledge of the current implementation is no
substitute for knowledge of the specification.

Does that make sense?

      Regards,
        Mark


PS: Note that although Guile has a special value #<unspecified> that is
    sometimes returned by expressions whose return value is unspecified,
    as in the counterexample above, in general such expressions could
    return _any_ Scheme value.

Re: 01/01: gnu: cmake: Delete Emacs library.

[Oleg Pykhalov]

[-- Attachment #1.1: Type: text/plain, Size: 218 bytes --]

Hello Mark,

Thank you for explanation of procedure and macro specifications.
I've pushed ffd526e61ab1b45c6c913ab4e139193e4d5bee9b with a fix.

Also, here is a patch to mention core-updates-next in the documentation.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: doc: Mention core-updates-next branch. --]
[-- Type: text/x-patch, Size: 611 bytes --]

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 2792fe2b2..1c33430aa 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -410,7 +410,8 @@ to be merged in @code{master} every 3 weeks or so.  Topical changes
 @item more than 1,200 dependent packages
 @code{core-updates} branch (may include major and potentially disruptive
 changes).  This branch is intended to be merged in @code{master} every
-2.5 months or so.
+2.5 months or so.  Also during official frozen period commits should go
+to @code{core-updates-next}.
 @end table
 
 All these branches are tracked by our build farm

[-- Attachment #1.3: Type: text/plain, Size: 16 bytes --]


Regards,
Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: 01/01: gnu: cmake: Delete Emacs library.

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 976 bytes --]

Oleg Pykhalov <go.wigust@gmail.com> writes:

> Hello Mark,
>
> Thank you for explanation of procedure and macro specifications.
> I've pushed ffd526e61ab1b45c6c913ab4e139193e4d5bee9b with a fix.
>
> Also, here is a patch to mention core-updates-next in the documentation.
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index 2792fe2b2..1c33430aa 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -410,7 +410,8 @@ to be merged in @code{master} every 3 weeks or so.  Topical changes
>  @item more than 1,200 dependent packages
>  @code{core-updates} branch (may include major and potentially disruptive
>  changes).  This branch is intended to be merged in @code{master} every
> -2.5 months or so.
> +2.5 months or so.  Also during official frozen period commits should go
> +to @code{core-updates-next}.
>  @end table

Good idea.  It would be good to clarify that this also applies for
'staging'.  What do you think about this instead?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Type: text/x-patch, Size: 1086 bytes --]

1 file changed, 9 insertions(+), 2 deletions(-)
doc/contributing.texi | 11 +++++++++--

modified   doc/contributing.texi
@@ -413,12 +413,19 @@ changes).  This branch is intended to be merged in @code{master} every
 2.5 months or so.
 @end table
 
-All these branches are tracked by our build farm
-and merged into @code{master} once
+All these branches are @uref{https://hydra.gnu.org/project/gnu,
+tracked by our build farm} and merged into @code{master} once
 everything has been successfully built.  This allows us to fix issues
 before they hit users, and to reduce the window during which pre-built
 binaries are not available.
 
+Generally, branches other than @code{master} are considered
+@emph{frozen} if there has been a recent evaluation, or there is a
+corresponding @code{-next} branch.  Please ask on the mailing list or
+IRC if unsure where to place a patch.
+@c TODO: It would be good with badges on the website that tracks these
+@c branches.  Or maybe even a status page.
+
 @item
 @cindex determinism, of build processes
 @cindex reproducible builds, checking

[back]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/01: gnu: cmake: Delete Emacs library.

[Ludovic Courtès]

Hello Marius & all,

Marius Bakke <mbakke@fastmail.com> skribis:

> Good idea.  It would be good to clarify that this also applies for
> 'staging'.  What do you think about this instead?
>
> 1 file changed, 9 insertions(+), 2 deletions(-)
> doc/contributing.texi | 11 +++++++++--

The patch LGTM!

> +@c TODO: It would be good with badges on the website that tracks these
> +@c branches.  Or maybe even a status page.

I agree!  I admit I sometimes have a hard time determining the current
status of every branch (for instance I’m not sure what’s up with
‘staging’ at the moment…)

Perhaps a lo-tech thing would be to have more frequent reminders on the
mailing list of the status of each branch, also as a way to solicitate
contributions on these branches.

I really think we need to have someone responsible for those rebuild
cycles, and to arrange to hand over reponsibilities to a different
person after each cycle or so.

Thanks,
Ludo’.

Re: 01/01: gnu: cmake: Delete Emacs library.

[Vincent Legoll]

Hello,

> I really think we need to have someone responsible for those rebuild
> cycles, and to arrange to hand over reponsibilities to a different
> person after each cycle or so.

First thing would be to document the tasks & responsibilities of such a
role, to ease people willing to contribute understand if they can / have
sufficient free time / etc.

-- 
Vincent Legoll

Re: 01/01: gnu: cmake: Delete Emacs library.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Marius & all,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Good idea.  It would be good to clarify that this also applies for
>> 'staging'.  What do you think about this instead?
>>
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>> doc/contributing.texi | 11 +++++++++--
>
> The patch LGTM!
>
>> +@c TODO: It would be good with badges on the website that tracks these
>> +@c branches.  Or maybe even a status page.
>
> I agree!  I admit I sometimes have a hard time determining the current
> status of every branch (for instance I’m not sure what’s up with
> ‘staging’ at the moment…)

I'm thinking we could have regular cycles (say every two weeks).  But
given the load on Hydra in general, we probably have to wait until
Cuirass provides the same functionality.

I pushed the documentation update as 38ab778fbd676fe7f7a84220d0cf7f474573dc2b.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]