Re: Manual consistency
Ricardo Wurmus wrote:
> Dmitry Alexandrov writes:
>> @macro PS1 {prompt}
>> @inlineraw{html,}\prompt\@inlineraw{html,}
>> @end macro
>
> Oh, neat! Let’s try this.
Oops! (info "(texinfo) Defining Macros") recommends against using digits in
macro names:
| For a macro to work consistently with TeX, MACRONAME must consist entirely of
letters: no digits, hyphens, underscores, or other special characters. So, we
recommend using only letters. However, 'makeinfo' will accept anything
consisting of alphanumerics, and (except as the first character) '-'.
and rightfully so:
make non-selectable-command-prompts-mwe.pdf
‹…›
./non-selectable-command-prompts-mwe.texi:13: Undefined control
sequence.
l.13 @PS
1{$ }wget …/guix-install.sh
?
So s/PS1/prompt/g or whatever suits better.
signature.asc
Description: PGP signature
Default to the 5.7.X kernel by default
Would that be a good idea or not? Sent with [ProtonMail](https://protonmail.com) Secure Email.
Re: Manual consistency
Dmitry Alexandrov writes:
> Ricardo Wurmus wrote:
>> Dmitry Alexandrov writes:
>>>
>>>
>>> code .PS1 {
>>> -webkit-user-select: none;
>>> -moz-user-select: none; /* Not required since F***fox 69. */
>>> user-select: none;
>>> }
>>>
>>
>> The only minor problem is that with Texinfo we cannot insert conditional
>> tags within the context of an example section
>
> Dunno, I can:
>
> \input texinfo
> @setfilename non-selectable-command-prompts-mwe.info
> @documentencoding UTF-8
> @settitle Non-selectable command prompts
>
> @macro PS1 {prompt}
> @inlineraw{html,}\prompt\@inlineraw{html,}
> @end macro
>
> @node Example
>
> @example
> @PS1{$ }wget …/guix-install.sh
> @PS1{$ }su -
> @PS1{# }bash ./guix-install.sh
> @end example
>
> @bye
Oh, neat! Let’s try this.
--
Ricardo
Re: Manual consistency
Ricardo Wurmus wrote:
> Dmitry Alexandrov writes:
>>
>>
>> code .PS1 {
>> -webkit-user-select: none;
>> -moz-user-select: none; /* Not required since F***fox 69. */
>> user-select: none;
>> }
>>
>
> The only minor problem is that with Texinfo we cannot insert conditional tags
> within the context of an example section
Dunno, I can:
\input texinfo
@setfilename non-selectable-command-prompts-mwe.info
@documentencoding UTF-8
@settitle Non-selectable command prompts
@macro PS1 {prompt}
@inlineraw{html,}\prompt\@inlineraw{html,}
@end macro
@node Example
@example
@PS1{$ }wget …/guix-install.sh
@PS1{$ }su -
@PS1{# }bash ./guix-install.sh
@end example
@bye
signature.asc
Description: PGP signature
Re: A script to check an edit does not break anything
Hello Edouard,
I think you left a hardcoded package name in your script, line 29, fix
with:
s/python-websockets/$package/
Also you sometimes use $package vs ${package}
This kind of thing (maybe converted into scheme what about
`guix before-submit') should be a valuable addition to guix,
it would help beginners (like me do less mistakes) and comitters
could have more confidence in a submission if it has gone through
this. Which would in turn enable us to integrate patches quicker.
WDYT ?
--
Vincent Legoll
Re: A script to check an edit does not break anything
An now with the attachment.
#!/bin/bash
# Put this script in a subfolder (e.g. gpwc)
# of the guix source
# And install sharness in it
# https://github.com/chriscool/sharness
# Install prove as well
# https://linux.die.net/man/1/prove
# To run the tests, invoke
# prove gpwc.t
# Fill in the names of the packages you've been meddling with
# In my case it was python-prompt-toolkit
PACKAGES=(python-prompt-toolkit python-ipywidgets)
test_description="Checking my meddling with ${PACKAGES[*]} did not break anything"
. ./sharness.sh
# Check that the new packages themselves are OK
for package in "${PACKAGES[@]}"
do
test_expect_success "Build $package" "
guix environment guix --pure -- ${SHARNESS_BUILD_DIRECTORY}/pre-inst-env guix build $package
"
test_expect_success "Lint $package" "
guix environment guix --pure -- ${SHARNESS_BUILD_DIRECTORY}/pre-inst-env guix lint $package
"
test_expect_success "See if $package is reproducible" "
guix environment guix --pure -- ${SHARNESS_BUILD_DIRECTORY}/pre-inst-env guix build --rounds=2 python-websockets
"
test_expect_success "Install $package" "
guix environment guix --pure -- ${SHARNESS_BUILD_DIRECTORY}/pre-inst-env \
guix install --profile=./${package}-tmp-profile ${package}
"
done
# Check the consequences of having meddled with the new packages
dependents(){
guix environment guix --pure -- "${SHARNESS_BUILD_DIRECTORY}"/pre-inst-env \
guix graph --type=reverse-bag "$1" | \
grep @ | sed 's/.*\"\(.*\)@.*/\1/'
}
# Union of all the dependents
for package in "${PACKAGES[@]}"
do
dependents "$package"
done | sort -u > dependents.txt
for package in $(cat dependents.txt)
do
test_expect_success "Build dependent $package" "
guix environment guix --pure -- \"${SHARNESS_BUILD_DIRECTORY}\"/pre-inst-env guix build $package
"
profile="$SHARNESS_TRASH_DIRECTORY/$(echo $package | sed 's/\(.*\)@/\1'/)-tmp-profile"
test_expect_success "Install dependent $package" "
guix environment guix --pure -- ${SHARNESS_BUILD_DIRECTORY}/pre-inst-env \
guix install --profile=\"${profile}\" ${package}
"
done
test_done
Edouard Klein writes:
> Dear Guixers,
>
> I recently broke jupyter while updating python-prompt-toolkit (a mistake
> I'm still trying to fix...) despite doing my best to follow the
> instructions of the manual:
> https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches
>
> Because of the subtle consequences of editing a package are hard to keep
> track of, I wrote the attached script (you need sharness to run it, but
> with slight modification it can become a standalone script).
>
> This script goes beyond the instructions of the manual on two fronts:
> - First, it not only tries to build the packages, but also to install
> them,
> - Secondly, it does not limit itself to the dependents (as listed by
> guix refresh --list-dependents) of the packages one is meddling with,
> but to the whole reverse bags (as listed by guix graph
> --type=reverse-bag).
>
> Both these extensions are necessary to discover that my update broke the
> jupyter package:
> - jupyter builds, so if you don't try to install it you won't discover
> it's broken
> - the leafs of the dependency graph that depend on jupyter fail to build
> for reasons unrelated to python-prompt-toolkit, so by just building the
> leafs (which are what is being returned by guix refresh
> --list-dependents) you can't discover jupyter's broken status.
>
> I think an update of the manual is in order (I've added it to my own
> TODO queue, but I have no idea when I'll be able to get to it) but I
> first wanted to share my script in case it may be useful to someone
> else, and gather some feedback as to whether other developers have
> encountered these kind of errors, and the way seasoned developers make
> sure they don't push breaking changes.
>
> Cheers,
>
> Edouard.
A script to check an edit does not break anything
Dear Guixers, I recently broke jupyter while updating python-prompt-toolkit (a mistake I'm still trying to fix...) despite doing my best to follow the instructions of the manual: https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches Because of the subtle consequences of editing a package are hard to keep track of, I wrote the attached script (you need sharness to run it, but with slight modification it can become a standalone script). This script goes beyond the instructions of the manual on two fronts: - First, it not only tries to build the packages, but also to install them, - Secondly, it does not limit itself to the dependents (as listed by guix refresh --list-dependents) of the packages one is meddling with, but to the whole reverse bags (as listed by guix graph --type=reverse-bag). Both these extensions are necessary to discover that my update broke the jupyter package: - jupyter builds, so if you don't try to install it you won't discover it's broken - the leafs of the dependency graph that depend on jupyter fail to build for reasons unrelated to python-prompt-toolkit, so by just building the leafs (which are what is being returned by guix refresh --list-dependents) you can't discover jupyter's broken status. I think an update of the manual is in order (I've added it to my own TODO queue, but I have no idea when I'll be able to get to it) but I first wanted to share my script in case it may be useful to someone else, and gather some feedback as to whether other developers have encountered these kind of errors, and the way seasoned developers make sure they don't push breaking changes. Cheers, Edouard.
Re: Manual consistency
Le 11 juin 2020 04:33:56 GMT-04:00, Ricardo Wurmus a écrit
:
>
>Dmitry Alexandrov writes:
>
>> Ricardo Wurmus wrote:
>>> Ludovic Courtès writes:
Ricardo Wurmus skribis:
> Julien Lepiller writes:
>> If there is a way to mark a sentence to wrap it into a class, we
>could also do some CSS magic with :before.
What about adding some more post-processing in doc/build.scm? :-)
>>>
>>> If we’re okay with wrapping individual lines in @code{…} that won’t
>be necessary. Having each logical line of code within @code results in
>>>
>>>
>>> this line
>>> that line
>>>
>>>
>>> and that’s something we *can* style with CSS.
>>
>> May I chime in?
>>
>> Do I get it right: you are suggesting to remove prompts from .texi
>and put them back in HTML output only — leaving other formats with not
>prompts?
>>
>> And that is only to make them unselectable? I do not quite
>understand, why this is needed at all (are there multiline examples in
>the manual, that expected to be blindly copypasted to terminal?), but
>in any case no hacks like ‘::before’ are required — ‘user-select: none’
>is supported by all modern webengines (yet sometimes with prefix):
>>
>>
>> code .PS1 {
>> -webkit-user-select: none;
>> -moz-user-select: none; /* Not required since F***fox 69. */
>> user-select: none;
>> }
>>
>>
>>$ wget …/guix-install.sh
>> $ su -
>> # bash ./guix-install.sh
>>
>
>This is good.
>
>The only minor problem is that with Texinfo we cannot insert
>conditional
>tags within the context of an example section, so we would have to
>rewrite the HTML via post-processing.
Maybe that's what we want to do? If a line in satrts with "$ " or "# "
wrap with a span. That way, we can make them unselectable in html, and they
still appear in the info manual. We also keep the distinction between $ and #.
Re: Manual consistency
Dmitry Alexandrov writes:
> Ricardo Wurmus wrote:
>> Ludovic Courtès writes:
>>> Ricardo Wurmus skribis:
Julien Lepiller writes:
> If there is a way to mark a sentence to wrap it into a class, we could
> also do some CSS magic with :before.
>>>
>>> What about adding some more post-processing in doc/build.scm? :-)
>>
>> If we’re okay with wrapping individual lines in @code{…} that won’t be
>> necessary. Having each logical line of code within @code results in
>>
>>
>> this line
>> that line
>>
>>
>> and that’s something we *can* style with CSS.
>
> May I chime in?
>
> Do I get it right: you are suggesting to remove prompts from .texi and put
> them back in HTML output only — leaving other formats with not prompts?
>
> And that is only to make them unselectable? I do not quite understand, why
> this is needed at all (are there multiline examples in the manual, that
> expected to be blindly copypasted to terminal?), but in any case no hacks
> like ‘::before’ are required — ‘user-select: none’ is supported by all modern
> webengines (yet sometimes with prefix):
>
>
> code .PS1 {
> -webkit-user-select: none;
> -moz-user-select: none; /* Not required since F***fox 69. */
> user-select: none;
> }
>
>
> $ wget …/guix-install.sh
> $ su -
> # bash ./guix-install.sh
>
This is good.
The only minor problem is that with Texinfo we cannot insert conditional
tags within the context of an example section, so we would have to
rewrite the HTML via post-processing.
--
Ricardo
Re: Why does slim-service-type depend on GTK+?
Patch sent: 41798. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
