Re: [PATCH v3] .dir-locals.el: Automatically set the GEISER-GUILE-LOAD-PATH variable.
Hello, Maxim Cournoyer writes: > * .dir-locals.el: Set the GUIX-DIRECTORY and GEISER-GUILE-LOAD-PATH Emacs > variables based on the location of the .dir-locals file. > --- > .dir-locals.el | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) > > diff --git a/.dir-locals.el b/.dir-locals.el > index 19f15b3e1a..0496e41ca2 100644 > --- a/.dir-locals.el > +++ b/.dir-locals.el > @@ -8,7 +8,26 @@ > ;; For use with 'bug-reference-prog-mode'. > (bug-reference-url-format . "http://bugs.gnu.org/%s";) > (bug-reference-bug-regexp > - . ""))) > + . "") > + > + ;; Emacs-Guix > + (eval . (setq guix-directory > + (locate-dominating-file default-directory > ".dir-locals.el"))) > + > + ;; Geiser > + ;; This allows automatically setting the `geiser-guile-load-path' > + ;; variable when using various Guix checkouts (e.g., via git worktrees). > + (eval . (let* ((root-dir (expand-file-name > + (locate-dominating-file > +default-directory ".dir-locals.el"))) > +;; Workaround for bug https://issues.guix.gnu.org/43818. > +(root-dir* (directory-file-name root-dir))) > + (unless (boundp 'geiser-guile-load-path) > + (defvar geiser-guile-load-path '())) > + (make-local-variable 'geiser-guile-load-path) > + (cl-pushnew root-dir* geiser-guile-load-path > + :test #'string-equal) > + > (c-mode . ((c-file-style . "gnu"))) > (scheme-mode >. Pushed to master as 0e1b0958bd. Thank you! Maxim
Re: Update on the timeline for the release v1.2.
Hello everyone, Sorry for being late in the discussion. Ludovic Courtès writes: > zimoun skribis: > >>> > The proposed coming timeline is: >>> > >>> > - freeze starting the Oct. 26th >>> > - last round for testing all over the week >>> > - unfreeze the Oct. 29th and then create the branch >>> > - minor bug fixes and all the papeword around (NEWS, blog, etc.) >>> > - release Nov. 6th. >>> >>> Overall LGTM, but could you clarify what you mean by “freeze” on >>> Oct. 26–29? No “important” changes to ‘master’, including to the >>> manual, is that correct? >> >> Yes, no "important" changes to 'master' which means: >> - no package or service updates > > I would phrase it as no _important_ package or service updates. > Updating non-critical leaf packages or services is probably fine. That's kind of already what master is for, so to me "important" doesn't help that much in discerning what is OK to what is not :-). >> - no manual entry >> - only serious fixes under guix/ or installer(s) >> >> From my point of view, it is easier to freeze 'master' since everybody >> can "guix pull" and check that everything is fine. >> Otherwise, instead of the freeze, let create the branch and so "guix >> pull --branch=version-1.2.0". It is up to you. > Yeah we could also branch on the 26th and cherry-pick harmless changes > from ‘master’, so people can still have fun on ‘master’. > > Mathieu, Marius, Maxim, Tobias: thoughts? This sounds like a better idea to me. If something needs freezing, it's technically much easier/safer to branch. I don't think it's reasonable to expect all of our ~60 committers to have seen this email and know they shouldn't push any important updates to master between now and the 6th of November (if I followed correctly). Thank you! Maxim
New French PO file for 'guix-manual' (version 1.2.0-pre2)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/guix-manual/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: A better way to access records.
Hi Brendan, On Fri, 30 Oct 2020 21:59:59 +1100 Brendan Tildesley wrote: > No I didn't want to specify the fields at all, just have all of them > automatically defined. I think that that is a bad idea for maintenance reasons. This totally would hide variables from the enclosing context without you being able to tell that it does so from the lexical context. For example let's say you have: (define-record size) (let ((color 5)) (with-record foo color)) And later on you update (but do not change the text of the with-record usage at all), so in total you have: (define-record size color) (let ((color 5)) (with-record foo color)) Now color is a different one!! I don't even like unqualified imports for that reason: a change in a remote place can affect what this module does without this module body referring to it literally in the first place. On the other hand, when directly specifying the fields (let ((color 5)) (with-record (foo size) color)) I'm all for that. pgpBFk2lOijyG.pgp Description: OpenPGP digital signature
Re: A better way to access records.
On 30.10.2020 11:28, Brendan Tildesley wrote:
In the guix codebase, on many occasions there appear things like this:
(match-lambda
(($ agetty tty term baud-rate auto-login
login-program login-pause? eight-bits? no-reset? remote? flow-control?
host no-issue? init-string no-clear? local-line extract-baud?
skip-login? no-newline? login-options chroot hangup? keep-baud? timeout
detect-case? wait-cr? no-hints? no-hostname? long-hostname?
erase-characters kill-characters chdir delay nice extra-options)
(list
>
Wouldn't be nice if we could just step inside a record type whenever we
pleased?
The above would be like this perhaps:
(let-from-record-type
(list ...))
Usually in Scheme the concept of "lexical scope" is held in very high
regard, which means that for every identifier that is being referenced
in a piece of code, you should be able to see its verbatim definition or
binding (with 'define' or 'let') in the text, with the exception of
imports of course.
This has various advantages, like being intuitive, making name clashes
unlikely, making it easy for IDEs and other tools to find the definition
of a binding, and so on.
Of course, the disadvantage is the verbosity.
Digression: This is also the crux of the debate on whether it's a good
idea for a record definition syntax to implicitly bind procedures. For
instance would it be a blessing or a curse if I could just say
(define-record-type (make-rec foo bar) rec?)
and automatically have rec-foo, set-rec-foo!, rec-bar and set-rec-bar!
defined for me, even though none of those identifiers appear in the
definition of the record type... End digression.
As seen in your example, a record may have tons of fields. Binding them
all automatically would IMO be quite bad in some cases. In the list we
see very generic identifiers like 'term', 'host', 'timeout', 'chdir' and
'delay'. Binding these implicitly would be Very Bad(TM) because you
might have been using them for something else and happen to forget that
this record type contains them and as such the 'let-from-record-type'
overrides your bindings.
Worse yet: when the record gets more fields, your code might break
because one of the new fields happens to be an identifier that you were
using in your code!
Consider the following. Let's say the does not
yet have a field called 'chdir' and nobody has any idea that one day it
will be added. I write the following code:
(let-from-record my-agetty-config
(let ((orig-dir (get-working-dir))
(tmpdir (make-tmp-dir))
(chdir tmpdir)
(do-something-with-agetty-config)
(chdir orig-dir)))
One day, 'chdir' is added to the agetty-configuration record type...
Well I assume you see the problem. :-)
In code where the bindings to be taken from the record are listed
explicitly, such a problem cannot occur.
- Taylan
New Spanish PO file for 'guix' (version 1.2.0-pre2)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/guix/es.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New Spanish PO file for 'guix' (version 1.2.0-pre2)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/guix/es.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: A better way to access records.
Hi Brendan, On +2020-10-30 21:28:38 +1100, Brendan Tildesley wrote: > From the little bit of SICP that I've done, I recall watching the lectures > where > they put a mage hat on and talk about the power of names. One could perhaps > say > the most powerful tool in a programming language is the ability to give > something a name and then refer to those names. > > In guix/guile, record types are list of names given to some data. > For example: > > (define foo > (package > (name "bar") > (version "1.0") > ...) > > Here we the names foo, name, version, that refer to things of interest. We > can > call foo easily enough to get the record, but we cannot refer to name or > version so easily. We instead have to use accessors like (package-name > foo), > which requires us to write foo each time explicitly and have repeat package- > for each accessor. > In the guix codebase, on many occasions there appear things like this: > > (match-lambda > (($ agetty tty term baud-rate auto-login > login-program login-pause? eight-bits? no-reset? remote? > flow-control? > host no-issue? init-string no-clear? local-line extract-baud? > skip-login? no-newline? login-options chroot hangup? keep-baud? > timeout > detect-case? wait-cr? no-hints? no-hostname? long-hostname? > erase-characters kill-characters chdir delay nice extra-options) > (list > > > Here we have given some names to things, abandoned those names, and once > again > gone to the trouble of naming them again, in order, just for one local > environment. We'd have to do it again to make use of it elsewhere, and I > assume > they would have to change if the record type it self needed to be updated. > > Wouldn't be nice if we could just step inside a record type whenever we > pleased? > The above would be like this perhaps: > > (let-from-record-type > (list ...)) > > "let-from-record-type" i just made up since i dont know what it should be > called. Anyhow, it seems like we're stepping back a few centuries in > computer > science by needing to jump through these hoops. > > The list of symbols can be retreived with (record-type-fields > ), but I can't think of how one would write the above > syntax. > > Opinions? > > > info guile record may be useful :) -- Regards, Bengt Richter
Re: A better way to access records.
On 30/10/20 8:49 pm, Leo Prikler wrote: Well, the "functional" way of accessing them all in one go would be to (map (cute <> foo) (list package-name package-version package-...)) But I assume you want syntax like (let-field record field exp*) (let-fields record (field1 field2...) exp*) No I didn't want to specify the fields at all, just have all of them automatically defined. analogous to (srfi srfi-9 gnu) set-field and set-fields, am I right? Regards, Leo
Re: A better way to access records.
Well, the "functional" way of accessing them all in one go would be to (map (cute <> foo) (list package-name package-version package-...)) But I assume you want syntax like (let-field record field exp*) (let-fields record (field1 field2...) exp*) analogous to (srfi srfi-9 gnu) set-field and set-fields, am I right? Regards, Leo
A better way to access records.
From the little bit of SICP that I've done, I recall watching the lectures where they put a mage hat on and talk about the power of names. One could perhaps say the most powerful tool in a programming language is the ability to give something a name and then refer to those names. In guix/guile, record types are list of names given to some data. For example: (define foo (package (name "bar") (version "1.0") ...) Here we the names foo, name, version, that refer to things of interest. We can call foo easily enough to get the record, but we cannot refer to name or version so easily. We instead have to use accessors like (package-name foo), which requires us to write foo each time explicitly and have repeat package- for each accessor. In the guix codebase, on many occasions there appear things like this: (match-lambda (($ agetty tty term baud-rate auto-login login-program login-pause? eight-bits? no-reset? remote? flow-control? host no-issue? init-string no-clear? local-line extract-baud? skip-login? no-newline? login-options chroot hangup? keep-baud? timeout detect-case? wait-cr? no-hints? no-hostname? long-hostname? erase-characters kill-characters chdir delay nice extra-options) (list Here we have given some names to things, abandoned those names, and once again gone to the trouble of naming them again, in order, just for one local environment. We'd have to do it again to make use of it elsewhere, and I assume they would have to change if the record type it self needed to be updated. Wouldn't be nice if we could just step inside a record type whenever we pleased? The above would be like this perhaps: (let-from-record-type (list ...)) "let-from-record-type" i just made up since i dont know what it should be called. Anyhow, it seems like we're stepping back a few centuries in computer science by needing to jump through these hoops. The list of symbols can be retreived with (record-type-fields ), but I can't think of how one would write the above syntax. Opinions?
Re: Outdated avr-toolchain
Hi, On Fri, 30 Oct 2020 12:47:18 +0530 Arun Isaac wrote: > Our avr-toolchain is very old and outdated. Our version is 5.5.0, > whereas the latest seems to be 10.2.0. We also have multiple versions of > the avr-toolchain packages along with functions to produce those > multiple versions. Can we remove these functions and different versions, > and keep only one latest version of the avr-toolchain? As one of the people using avr-toolchain, +1 > I have an old patchset[1] to this effect, but I didn't want to proceed > without a discussion. I was concerned that there might be a use, for all > these different versions, that I did not comprehend. I don't think so. The AVRs are so tiny and development using them is usually done by copying library source code into your project, so I cannot see any reason to care about different gcc versions for AVR. avrdude is another matter--it's very easy to break that if you don't actually test it. pgph5juYWeinq.pgp Description: OpenPGP digital signature
Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.
Hi, > […] from my point of view, the good direction would be a “web-app frontend”, > similarly to git-annex-assistant [1]. This design is more flexible because > it could be used locally *and* could also be the front-end of some servers > (e.g., build farms). I have something like this on my todo list as well. It would probably be more of a manifest file editor though, since we use manifest files for reproducibility. Cheers, Lars signature.asc Description: PGP signature
New German PO file for 'guix-manual' (version 1.2.0-pre2)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/guix-manual/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Outdated avr-toolchain
Hi, Our avr-toolchain is very old and outdated. Our version is 5.5.0, whereas the latest seems to be 10.2.0. We also have multiple versions of the avr-toolchain packages along with functions to produce those multiple versions. Can we remove these functions and different versions, and keep only one latest version of the avr-toolchain? I have an old patchset[1] to this effect, but I didn't want to proceed without a discussion. I was concerned that there might be a use, for all these different versions, that I did not comprehend. [1]: https://issues.guix.info/issue/39918 Thanks, Arun signature.asc Description: PGP signature
