Re: Using #true and #false everywhere?

[jbranso]

I use "f" for followup.  That works for me.  :)

October 16, 2020 6:08 PM, "Miguel Ángel Arruga Vivas"  
wrote:

> I didn't send this to the list... I must start using S L always instead
> of R and changing the headers manually, sorry. :o)
> 
> ---
> Hi Ludo,
> 
> Ludovic Courtès  writes:
> 
>> Hello Guix!
>> 
>> As discussed on IRC recently, several of us think that using “#true” and
>> “#false” instead of “#t” and “#f” throughout or documentation and code
>> would probably make it easier for newcomers to decipher that.
>> 
>> WDYT?
> 
> I think that it could help to the reader.
> 
>> This syntax is supported since Guile 2.0. ‘write’ still uses the
>> abbreviations, but the good thing is that it means we can change all of
>> gnu/packages without triggering a single rebuild.
> 
> This is even better. :)
> 
>> As for the manual, I’m afraid it’ll make every msgid that contains
>> @code{#t} stale. So maybe now’s not a good time to make this change?
> 
> It may be a big issue with a release in one week, but on the other hand
> the msgids would break just after releasing...
> 
> Maybe other translators have a say.
> 
> Happy hacking!
> Miguel

Re: Using #true and #false everywhere?

[Danny Milosavljevic]

Hi Ludo,

On Fri, 16 Oct 2020 12:38:23 +0200
Ludovic Courtès  wrote:

> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?

Now's definitely not a good time to make this change.

I think it's a good idea to make the change eventually, but I wouldn't change
it so short before a release.


pgps7Qk_esiV2.pgp
Description: OpenPGP digital signature

Re: Using #true and #false everywhere?

[Miguel Ángel Arruga Vivas]

I didn't send this to the list... I must start using S L always instead
of R and changing the headers manually, sorry.  :o)

---
Hi Ludo,

Ludovic Courtès  writes:
> Hello Guix!
>
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?

I think that it could help to the reader.

> This syntax is supported since Guile 2.0.  ‘write’ still uses the
> abbreviations, but the good thing is that it means we can change all of
> gnu/packages without triggering a single rebuild.

This is even better. :)

> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?

It may be a big issue with a release in one week, but on the other hand
the msgids would break just after releasing...

Maybe other translators have a say.

Happy hacking!
Miguel


signature.asc
Description: PGP signature

Re: Removing/replacing “Guix in action” video from the home page?

[Luis Felipe]

‐‐‐ Original Message ‐‐‐
On Friday, October 16, 2020 8:00 PM,  wrote:

> I do share Luis' sentiments that perhaps the video should mention that the
> install commands may take some time to complete, but in the interest of 
> brevity,
> we can always cut those bits out of the video.
>
> Do you know what that means!? I get to learn video editing! SILLY SALTY
> SALAMANDERS THAT'S AWESOME! :)
>
> Do ya'll have any video editors that you'd recommend?


I heard Pitivi is good, but it is not packaged yet.

Re: Manual PDF and translation (modular texlive?)

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> zimoun  writes:
>
>> Currently it is not easy to produce the PDF of the manual.  For
>> reference, see [1].  There are 2 issues:
>>
>>  a) the ’texlive’ package.
>>  b) the fonts about Russian or Chinese.
>>
>> About the a), it is really painful to download the *big* texlive package
>> to be able to compile TeX.  Especially when we have modular texlive
>> packages.  However, it is not clear to me which packages I have to use.
>> Any help is welcome. :-)
>
> I tried this:
>
> guix environment --pure guix --ad-hoc -e '(begin (use-modules (gnu 
> packages tex))(texlive-union (list texlive-epsf texlive-fonts-ec 
> texlive-amsfonts)))'
>
> This allows me to build doc/guix.pdf, but it chokes on the French and
> German versions (at least).  Frustratingly, texi2dvi swallows all errors
> and just prints:
>
> pdftex exited with bad status, quitting.
>
> Thanks, I guess.

I can now build the French and the German manuals in this environment:

guix environment --pure guix --ad-hoc -e '(begin (use-modules (gnu packages 
tex))(texlive-union (list texlive-epsf texlive-fonts-ec texlive-amsfonts 
texlive-tex-texinfo)))'

Unfortunately, the accents and umlauts in the table of contents are
still wrong, but they are fine everywhere else.

-- 
Ricardo

Re: Removing/replacing “Guix in action” video from the home page?

[jbranso]

I do share Luis' sentiments that perhaps the video should mention that the 
install commands may take some time to complete, but in the interest of brevity,
we can always cut those bits out of the video.

Do you know what that means!?  I get to learn video editing!  SILLY SALTY 
SALAMANDERS THAT'S AWESOME!  :)

Do ya'll have any video editors that you'd recommend?

October 16, 2020 11:27 AM, "Luis Felipe"  wrote:

> ‐‐‐ Original Message ‐‐‐
> On Friday, October 16, 2020 10:36 AM, zimoun  wrote:
> 
>> Hi,
>> 
>> On Fri, 16 Oct 2020 at 12:28, Ludovic Courtès l...@gnu.org wrote:
>> 
>>> https://video.hardlimit.com/videos/watch/c0dfb36a-a84b-4363-8b1b-17aeadd4aaaf
>> 
>> Thanks! I think 7 minutes is too long; IMO we should aim for ~1mn–1.5mn
>> at most as is currently the case. Also full screen, large enough fonts,
>> no “guix pull” warnings, ‘--max-jobs=1’ on the daemon side to reduce
>> verbosity. Slick and to-the-point! :-)
>> 
>> The video is really long mainly because each command takes literally
>> ages. Well the "XDG mine" step to be precise; maybe Joshua you have
>> something misconfigured.
> 
> If the slowness at the end can be avoided by configuring something, I'd like 
> to know, because that
> slowness is always the case in my experience. For example, installing the 
> program Joshua mentioned
> earlier, wf-recorder, which is quite small, took ~7 minutes in my computer 
> (Intel® Core™ i3-8100
> CPU @ 3.60GHz × 4, 4 GiB RAM, 1 TB HDD).
> 
> Also, in my case, it is common for guix commands to take long seconds to 
> display any feedback when
> called. Actually, the current video shows guix working at a speed I've never 
> experienced myself.
> 
> So I wonder if the video should include these inconveniences, which people 
> will find once they
> install the software. I wouldn't like the video or anything in the website to 
> feel like false,
> mainstream advertising.

Re: Removing/replacing “Guix in action” video from the home page?

[jbranso]

Ahh.  Thanks for reminding me!  I forgot about those "guix pull warnings".  
I have a local guix channel.  I can disable that for the video.  I will 
also add --max=jobs=1 to the daemon side for the video.

I do agree with you that the video is too long, because the XDG mime step 
takes some time to finish.  I wonder what I have mis-configured...I'm using 
Guix system on a Librebooted T400.  ext4.   

I can always remove the audio.  :)

I'll remake said video removing the guix pull errors, and maybe the commands
will not take so long to finish.

Thanks,

Joshua

October 16, 2020 6:36 AM, "zimoun"  wrote:

> Hi,
> 
> On Fri, 16 Oct 2020 at 12:28, Ludovic Courtès  wrote:
> 
>> https://video.hardlimit.com/videos/watch/c0dfb36a-a84b-4363-8b1b-17aeadd4aaaf
>> 
>> Thanks! I think 7 minutes is too long; IMO we should aim for ~1mn–1.5mn
>> at most as is currently the case. Also full screen, large enough fonts,
>> no “guix pull” warnings, ‘--max-jobs=1’ on the daemon side to reduce
>> verbosity. Slick and to-the-point! :-)
> 
> The video is really long mainly because each command takes literally
> ages. Well the "XDG mine" step to be precise; maybe Joshua you have
> something misconfigured.
> And from my point of view, something without voice seems better.
> 
> All the best,
> simon

Re: Manual PDF and translation (modular texlive?)

[Ricardo Wurmus]

zimoun  writes:

> Currently it is not easy to produce the PDF of the manual.  For
> reference, see [1].  There are 2 issues:
>
>  a) the ’texlive’ package.
>  b) the fonts about Russian or Chinese.
>
> About the a), it is really painful to download the *big* texlive package
> to be able to compile TeX.  Especially when we have modular texlive
> packages.  However, it is not clear to me which packages I have to use.
> Any help is welcome. :-)

I tried this:

guix environment --pure guix --ad-hoc -e '(begin (use-modules (gnu packages 
tex))(texlive-union (list texlive-epsf texlive-fonts-ec texlive-amsfonts)))'

This allows me to build doc/guix.pdf, but it chokes on the French and
German versions (at least).  Frustratingly, texi2dvi swallows all errors
and just prints:

pdftex exited with bad status, quitting.

Thanks, I guess.

So I ran this in strace to see what pdftex actually complained about,
and of course it’s mangled accented characters that it cannot find in
the generated fonts.  Here’s an excerpt:

--8<---cut here---start->8---
31695 read(3, "333)x433.62, glue set 4.13036\n.@glue(@leftskip) 
86.72375\n.@texttt \"\n.@texttt /\n.@texttt d\n.@texttt e\n.etc.\n\n[177] 
l.12161: Undefined cross reference `Syst^^c3^^a8mes de fichiers-snt'. l.12161: 
Undefined cross reference `Syst^^c3^^a8mes de fichiers-snt'. l.12161: Undefined 
cross reference `Syst^^c3^^a8mes de fichiers-pg'.\nMissing character: There is 
no ^^c3 in font cmr10!\nMissing character: There is no ^^a9 in font cmr10!\n 
l.12193: Undefined cross reference `Pr^^c3^^a9parer l'installation-snt'. 
l.12193: Undefined cross reference `Pr^^c3^^a9parer l'installation-snt'. 
l.12193: Undefined cross reference `Pr^^c3^^a9parer l'installation-pg'. 
l.12206: Undefined cross reference `Syst^^c3^^a8mes de fichiers-snt'. l.12206: 
Undefined cross reference `Syst^^c3^^a8mes de fichiers-snt'. l.12206: Undefined 
cross reference `Syst^^c3^^a8mes de fichiers-pg'. [178]\nOverfull \\hbox 
(32.18782pt too wide) in paragraph at lines 12228--12228\n []   
   @texttt \"video\"   ;p^^Seriph^^Seriques r^^Seseaux comme les webc"..., 
98304) = 86500
--8<---cut here---end--->8---

I’m very bad at fixing TeX font problems and encoding problems.  You can
tell by looking at the generated output when using texlive-union,
because it seems to be generating fonts anew even though we should
already have them all.

Any help with the TeX Live stuff would be appreciated!  It really needs
some love, and I can no longer give it; we have drifted apart.

I know of some unfixed problems that just need work (essentially just
looking at the generated files in the “texlive-{font,latex,tex,generic}-*”
packages and ensuring that they contain all files they should according
to texlive.tlpdb), but then there are also some issues that I don’t
understand enough to fix.

I’ll be glad to assist any one who would like to lead the effort to fix
our modular TeX Live packages once (or twice) and for all.

-- 
Ricardo

Re: Using #true and #false everywhere?

[Vagrant Cascadian]

On 2020-10-16, Ludovic Courtès wrote:
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?

I would very much welcome this as someone relatively new to guile and
scheme. Making it explicit with "plain" words is always preferable to
having to guess or look things up.

I've since learned that particular #t/#f convention, and it wouldn't
probably make a huge difference for me now personally, but I think it
would make the learning curve to contributing Guix a little gentler for
newcomers in general, and every bit helps. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Removing/replacing “Guix in action” video from the home page?

[Luis Felipe]

‐‐‐ Original Message ‐‐‐
On Friday, October 16, 2020 10:36 AM, zimoun  wrote:

> Hi,
>
> On Fri, 16 Oct 2020 at 12:28, Ludovic Courtès l...@gnu.org wrote:
>
> > > https://video.hardlimit.com/videos/watch/c0dfb36a-a84b-4363-8b1b-17aeadd4aaaf
> >
> > Thanks! I think 7 minutes is too long; IMO we should aim for ~1mn–1.5mn
> > at most as is currently the case. Also full screen, large enough fonts,
> > no “guix pull” warnings, ‘--max-jobs=1’ on the daemon side to reduce
> > verbosity. Slick and to-the-point! :-)
>
> The video is really long mainly because each command takes literally
> ages. Well the "XDG mine" step to be precise; maybe Joshua you have
> something misconfigured.

If the slowness at the end can be avoided by configuring something, I'd like to 
know, because that slowness is always the case in my experience. For example, 
installing the program Joshua mentioned earlier, wf-recorder, which is quite 
small, took ~7 minutes in my computer (Intel® Core™ i3-8100 CPU @ 3.60GHz × 4, 
4 GiB RAM, 1 TB HDD).

Also, in my case, it is common for guix commands to take long seconds to 
display any feedback when called. Actually, the current video shows guix 
working at a speed I've never experienced myself.

So I wonder if the video should include these inconveniences, which people will 
find once they install the software. I wouldn't like the video or anything in 
the website to feel like false, mainstream advertising.

Manual PDF and translation (modular texlive?)

[zimoun]

Dear,

Currently it is not easy to produce the PDF of the manual.  For
reference, see [1].  There are 2 issues:

 a) the ’texlive’ package.
 b) the fonts about Russian or Chinese.

About the a), it is really painful to download the *big* texlive package
to be able to compile TeX.  Especially when we have modular texlive
packages.  However, it is not clear to me which packages I have to use.
Any help is welcome. :-)

About the b), I am maybe overlooking but if I read correctly, it is not
documented.  What are the packages for the correct rendering of these
both languages.


With these, it becomes easy to have a manifest file and then:

  make pdf

will work without wizard-ness.

Thank you in advance.
All the best,
simon

1: 

Re: Diverse Double-Compiling, --with-c-toolchain and trusting trust

[Ludovic Courtès]

Hi!

Nice challenge! :-)

zimoun  skribis:

> Well, the idea is to implement the procedure with Guix: step #1,
>
>   guix build tcc --with-c-toolchain=tcc=clang-toolchain
>
> but then I do not know how to use the output to complete the step #2.
> Is it possible to do it at the CLI level?  Or do I have to write some
> Scheme?

I think you’ll have to write Scheme because you really need to construct
a graph with leading to the diversely-compiled compiler.

Ludo’.

Re: Using #true and #false everywhere?

[Tobias Geerinckx-Rice]

Maxim,

Maxim Cournoyer 写道：
I'd only agree to such a change if it's already been 
standardized in the

RnRS as such


Sure, I think that's implied.  #true and #false are part of the 
R7RS-small standard.


I don't know what Guile ‘is’, but it supports that part of the 
standard.  I don't think it implements any of the RnRS completely? 
I've heard it said that Guile targets R5RS, but that was ages ago.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Using #true and #false everywhere?

[Maxim Cournoyer]

Hello Ludovic,

Ludovic Courtès  writes:

> Hello Guix!
>
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.
>
> WDYT?
>
> This syntax is supported since Guile 2.0.  ‘write’ still uses the
> abbreviations, but the good thing is that it means we can change all of
> gnu/packages without triggering a single rebuild.
>
> As for the manual, I’m afraid it’ll make every msgid that contains
> @code{#t} stale.  So maybe now’s not a good time to make this change?
>
> Thoughts?

What's the current status of #true/#false in the current Scheme
revision?  It doesn't seem to have been standardized yet, no?

I'd only agree to such a change if it's already been standardized in the
RnRS as such; #f and #t have a long history and I don't think they are
cognitively much harder to grasp than #false and #true, so the gain
seems small compared to the downsides (hurting git blame's effectiveness
across the code base, having to re-teach all contributors to use #true
and #false everywhere, augmenting the lint tools, etc.).

Maxim

Using #true and #false everywhere?

[Ludovic Courtès]

Hello Guix!

As discussed on IRC recently, several of us think that using “#true” and
“#false” instead of “#t” and “#f” throughout or documentation and code
would probably make it easier for newcomers to decipher that.

WDYT?

This syntax is supported since Guile 2.0.  ‘write’ still uses the
abbreviations, but the good thing is that it means we can change all of
gnu/packages without triggering a single rebuild.

As for the manual, I’m afraid it’ll make every msgid that contains
@code{#t} stale.  So maybe now’s not a good time to make this change?

Thoughts?

Ludo’.

Re: Removing/replacing “Guix in action” video from the home page?

[zimoun]

Hi,

On Fri, 16 Oct 2020 at 12:28, Ludovic Courtès  wrote:

> > https://video.hardlimit.com/videos/watch/c0dfb36a-a84b-4363-8b1b-17aeadd4aaaf
>
> Thanks!  I think 7 minutes is too long; IMO we should aim for ~1mn–1.5mn
> at most as is currently the case.  Also full screen, large enough fonts,
> no “guix pull” warnings, ‘--max-jobs=1’ on the daemon side to reduce
> verbosity.  Slick and to-the-point!  :-)

The video is really long mainly because each command takes literally
ages.  Well the "XDG mine" step to be precise; maybe Joshua you have
something misconfigured.
And from my point of view, something without voice seems better.

All the best,
simon

Re: File search progress: database review and question on triggers

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>>> Question: How do I hook onto =guix build=?
>>
>> You would need a build-completion hook in the daemon, which doesn’t
>> exist (yet!).  Note also that at this level we only see derivations, not
>> packages.
>
> Hmm... Can you explain me how =guix size= works with local builds?  Does
> it compute the size on demand or is it stored somewhere?

It first tries ‘query-path-info’, which succeeds if the store item is
available and contains info about its size, references, and so on.

When ‘query-path-info’ fails, it falls back to
‘query-substitutable-path-info’, which allows it to obtain the same
information for substitutes.  Thus, it doesn’t need to have the store
item available locally.

HTH!

Ludo’.

Re: Removing/replacing “Guix in action” video from the home page?

[Ludovic Courtès]

Hi,

Joshua Branson  skribis:

> Well, I've created a basic guix package management video.  It's about 7
> minutes long.  You'll notice I made it a little goofy.  Essentially
> building the XDG mime database takes a while.  So I just read from
> Stallman's essays during the downtime.
>
> If someone wants to show me how to install packages without having to
> wait so long for the xdg mime database to build, please let me know, and
> I'll re-make the video.
>
> https://video.hardlimit.com/videos/watch/c0dfb36a-a84b-4363-8b1b-17aeadd4aaaf

Thanks!  I think 7 minutes is too long; IMO we should aim for ~1mn–1.5mn
at most as is currently the case.  Also full screen, large enough fonts,
no “guix pull” warnings, ‘--max-jobs=1’ on the daemon side to reduce
verbosity.  Slick and to-the-point!  :-)

Thinking about it, there are probably tools to replay commands in a
terminal such that we could automate all this, no?

Ludo’.

Re: Reproductibility, Data Services, guix weather

[Ludovic Courtès]

Hi!

zimoun  skribis:

> (define %prefix-url
>   "https://data.guix-patches.cbaines.net/revision;)
>
> (define %suffix-url
>   "output_consistency=not-matching=none_results=on")
>
> (define %json-name "package-derivation-outputs.json")
>
>
> (define* (json-url revision
>   #:optional
>   (system (%current-system))
>   (json %json-name))
>   "Return the URL corresponding to REVISION."
>   (string-append
>%prefix-url "/" revision "/" json "?" %suffix-url"=" system))
>
> (define* (json-file revision
> #:optional
> (system (%current-system))
> (name %json-name)
> (tmp %temporary-directory))
>   "Path where the JSON is stored.
>
> By default in %TEMPORARY-DIRECTORY/REV-%JSON-NAME."
>   (let ((hash (substring revision 0 6)))
> (string-append tmp "/" hash "-" name "-" system)))
>
> (define (fetch-json revision system)
>   "Fetch the JSON file from the Data Service corresponding to REVISION.
>
> Store the result in %TEMPORARY-DIRECTORY."
>   (let* ((out (json-file revision system))
>  (url (json-url revision system)))
> (url-fetch url out)))

I think it’s a good idea.  My suggestion would be to do as for (guix
ci): make a (guix data-service-client) (?) module that contains proper
bindings to a subset of the Data Service APIs, using
‘define-json-mapping’.

Once we have that, we can consider using it in ‘guix weather’ or in new
tools such as the proposed ‘guix git log’.

Ludo’.