Re: GNU Mes 0.21 released
Congrats! On Tue, Nov 26, 2019, 11:11 Brett Gilio wrote: > Jan Nieuwenhuizen writes: > > > We are pleased to announce the release of GNU Mes 0.21, representing > > 54 commits over 10 weeks. > > > > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap > > a GNU/Linux system without binary GNU toolchain or equivalent). See > > https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ > > > > This release supports a Scheme-only bootstrap: Mes can now be built with > > Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU > > Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and > > GNU Tar. Also, the Mes C Library now supports bootstrapping those. > > Finally, this release brings Mes as a package to Debian GNU/Linux. > > > > We are excited that the Nlnet Foundation[12] is now sponsoring this > > work! > > > > Next targets: > > > > - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian, > >Gentoo, ...?) > > - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove > >awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the > >Guix bootstrap binaries > > - ARM support > > - Full Source Bootstrap: compile Mes.c using M2-Planet > > - Reduced Binary Seed bootstrap for ARM > > - the Hurd > > > > Packages are available in Guix master. > > > > * About > > > > GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]. > > This bootstrap has halved the size of opaque, uninspectable binaries > > that were needed to bootstrap Guix. The final goal is to help create > > a full source bootstrap as part of the bootstrappable builds[3] effort > > for any interested UNIX-like operating system. > > > > It consists of a mutual self-hosting Scheme interpreter written in > > ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. > > This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. > > > > The Scheme interpreter has a Garbage Collector, a library of loadable > > Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS > > [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] > > --and test suite just enough to support a REPL and a C99 compiler: > > MesCC. > > > > Mes+MesCC can compile an only lightly patched TinyCC[9] that is > > self-hosting. Using this tcc and the Mes C library we now have a > > Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, > > binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for > > i686-linux and x86_64-linux. > > > > Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- > John > > McCarthy page 13, GNU Guix's source/binary packaging transparency and > > Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. > > > > * Download > > > > git clone git://git.savannah.gnu.org/mes.git > > > > Here are the compressed sources and a GPG detached signature[*]: > > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz > > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig > > > > Use a mirror for higher download bandwidth: > > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz > > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig > > > > Here are the MD5 and SHA1 checksums: > > > > dea43529d2d84fb4b9d81bdd9efcc715 mes-0.21.tar.gz > > 35721a81feeab6e0d5913b8bf78f18951edbb964 mes-0.21.tar.gz > > > > [*] Use a .sig file to verify that the corresponding file (without the > > .sig suffix) is intact. First, be sure to download both the .sig file > > and the corresponding tarball. Then, run a command like this: > > > > gpg --verify mes-0.21.tar.gz.sig > > > > If that command fails because you don't have the required public key, > > then run this command to import it: > > > > gpg --keyserver keys.gnupg.net --recv-keys > 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 > > > > and rerun the 'gpg --verify' command. > > > > * Get informed, get involved > > > > See https://bootstrappable.org > > Join #bootstrappable on irc.freenode.net. > > > > * Changes in 0.21 since 0.20 > > ** Core > > *** Mes can now be bootstrapped with Gash and Gash Core Utils. > > *** Mes now supports a Scheme-only bootstrap. > > *** Mes now supports -c EXPR. > > ** MesCC > > *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU > SED, and GNU Tar. > > *** Mes C Library now has limited float support in vfprintf, vsnprintf, > vsscanf. > > 7 new functions > > abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod, > > symlink. > > 5 new stubs > > getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent. > > ** Noteworthy bug fixes > > *** A bug with `mes -c EXPR' has been fixed. > > *** The REPL now works again on x86_64. > > *** --with-system-libc now works again. > > > > Greetings, > > janneke and Danny. > > > > [0] https://www.gnu.org/software/mes > > [1]
Re: GNU Mes 0.21 released
Jan Nieuwenhuizen writes: > We are pleased to announce the release of GNU Mes 0.21, representing > 54 commits over 10 weeks. > > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap > a GNU/Linux system without binary GNU toolchain or equivalent). See > https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ > > This release supports a Scheme-only bootstrap: Mes can now be built with > Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU > Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and > GNU Tar. Also, the Mes C Library now supports bootstrapping those. > Finally, this release brings Mes as a package to Debian GNU/Linux. > > We are excited that the Nlnet Foundation[12] is now sponsoring this > work! > > Next targets: > > - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian, >Gentoo, ...?) > - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove >awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the >Guix bootstrap binaries > - ARM support > - Full Source Bootstrap: compile Mes.c using M2-Planet > - Reduced Binary Seed bootstrap for ARM > - the Hurd > > Packages are available in Guix master. > > * About > > GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]. > This bootstrap has halved the size of opaque, uninspectable binaries > that were needed to bootstrap Guix. The final goal is to help create > a full source bootstrap as part of the bootstrappable builds[3] effort > for any interested UNIX-like operating system. > > It consists of a mutual self-hosting Scheme interpreter written in > ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. > This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. > > The Scheme interpreter has a Garbage Collector, a library of loadable > Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS > [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] > --and test suite just enough to support a REPL and a C99 compiler: > MesCC. > > Mes+MesCC can compile an only lightly patched TinyCC[9] that is > self-hosting. Using this tcc and the Mes C library we now have a > Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, > binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for > i686-linux and x86_64-linux. > > Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John > McCarthy page 13, GNU Guix's source/binary packaging transparency and > Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. > > * Download > > git clone git://git.savannah.gnu.org/mes.git > > Here are the compressed sources and a GPG detached signature[*]: > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig > > Use a mirror for higher download bandwidth: > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig > > Here are the MD5 and SHA1 checksums: > > dea43529d2d84fb4b9d81bdd9efcc715 mes-0.21.tar.gz > 35721a81feeab6e0d5913b8bf78f18951edbb964 mes-0.21.tar.gz > > [*] Use a .sig file to verify that the corresponding file (without the > .sig suffix) is intact. First, be sure to download both the .sig file > and the corresponding tarball. Then, run a command like this: > > gpg --verify mes-0.21.tar.gz.sig > > If that command fails because you don't have the required public key, > then run this command to import it: > > gpg --keyserver keys.gnupg.net --recv-keys > 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 > > and rerun the 'gpg --verify' command. > > * Get informed, get involved > > See https://bootstrappable.org > Join #bootstrappable on irc.freenode.net. > > * Changes in 0.21 since 0.20 > ** Core > *** Mes can now be bootstrapped with Gash and Gash Core Utils. > *** Mes now supports a Scheme-only bootstrap. > *** Mes now supports -c EXPR. > ** MesCC > *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU SED, and > GNU Tar. > *** Mes C Library now has limited float support in vfprintf, vsnprintf, > vsscanf. > 7 new functions > abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod, > symlink. > 5 new stubs > getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent. > ** Noteworthy bug fixes > *** A bug with `mes -c EXPR' has been fixed. > *** The REPL now works again on x86_64. > *** --with-system-libc now works again. > > Greetings, > janneke and Danny. > > [0] https://www.gnu.org/software/mes > [1] https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ > [2] https://www.gnu.org/software/guix > [3] https://bootstrappable.org > [4] https://github.com/oriansj/mes-m2 > [5] https://github.com/oriansj/m2-planet > [6] https://github.com/schemeway/lalr-scm > [7]
Re: Guix and FSDG
Hi, On Sat, 23 Nov 2019 at 19:00, Ludovic Courtès wrote: > Clément Lassieur skribis: > > > Indeed 'guix build --source' returns the freed source. However, the > > original archive does end up in /gnu/store, and its path in displayed > > during the build. > > (Only if you build from source, without substitutes, etc.) If I read correctly, Clément just points out inaccuracies of the David's answer [0]: [0] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00376.html << The most important part of this process is that the original source archive is *never* accessible to the Guix user via any Guix tools. >> Correct, even if Guix tools is vague. Is "guix repl" a Guix tools? :-) << The original archive is discarded and does not end up in the canonical location for Guix data: /gnu/store. >> Incorrect, as Clément shows. And it is not a bug of the very particular zpaq package, but a general feature of how Guix works. << Therefore, Guix has taken sufficient technical measures to avoid steering its user towards nonfree software and thus Guix is compliant with the FSDG. >> > The spirit of the FSDG is that the distro must not provide, recommend, or > link to non-free code, and I think Guix is following that to the letter. We all agree on that. I guess. In the initial Raghav's message, it seems that the argument is: because Guix downloads non-free code in order to install free software, then Guix does not follow the FSDG. This argument misreads the current FSDG. For example, any GNU/linux distribution needs to download non-free blobs and then removes them. Even, the FSDG webpage [1] points to scripts [2] that remove these non-free blobs. The keyword in the FSDG is "installable" and nothing is said about "download", from my understanding. [1] https://www.gnu.org/distros/free-system-distribution-guidelines.html [2] http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/ > For the record, this issue was discussed in the early days of Guix and I > don’t think anything has changed since then. The current behavior of > ‘guix build --source’ stems from those discussions (that was ca. 2015, > but I can’t find the links now). I have not found neither. However, from my perspective, all this seems more a troll than a real issue. :-) All the best, simon
Re: Guix in Docker for automated CD/CI of complex software
Hi, On Fri, 22 Nov 2019 at 19:57, Vicente Eduardo wrote: > [...] I want to run guix inside docker in order to have a portable > installation of guix for common ci/cd enviroments. I was suggesting that maybe you can use Guix to create this image. :-) --8<---cut here---start->8--- $ guix describe Generation 57 Nov 25 2019 14:26:15(current) guix b5d4d5b repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: b5d4d5b9bcf267fddd02fcc14b88eac0bebf979f --8<---cut here---end--->8--- --8<---cut here---start->8--- $ guix pack\ -f docker \ -C none \ -S /bin=bin \ -S /lib=lib \ -S /share=share \ -S /etc=etc \ guix $ docker load < /gnu/store/8vrdpas5s9alpczixc8bw83x9sxc8if5-docker-pack.tar --8<---cut here---end--->8--- --8<---cut here---start->8--- $ docker run -ti guix guix --version --8<---cut here---end--->8--- Obviously, it needs some love (dameon) to fit your use case. And I do not know if it make sense but I would try to replace this Dockerfile [1] by a manifest and "guix pack". Or maybe as a first step using Dockerfile based on Guix instead of Alpine. [1] https://github.com/metacall/guix/blob/master/Dockerfile And even, instead of the raw instruction, I would use the installation script [2]. [2] https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh > Here's the metacall schema: > https://github.com/metacall/distributable/blob/53caad582cd097c5e92798bf0ec16660bfc4030c/source/metacall.scm > > My idea is to generate a zip with all libraries self contained, rather than a > Docker image. The "guix pack" should fit your need. But I am not sure because it is a simple cmake-build-system with few (guix) dependencies, i.e., it "relies a lot in CMake features like ExternalProject". All the best, simon
Re: Packaging Jami progress
Hi again, Sorry for being impatient, but is it normal for patches to be merged that long? Is there something stopping the commits? I need those merged in order to continue working on Jami. Jan Wielkiewicz
Re: $out/lib/libexec?
I would leave it as it is, some applications require this layout, I can only speak for what I work on - as it behaves this way - gnunet, which would require too much to adjust to some arbitrary layout choice.
$out/lib/libexec?
Hi, I just discovered that some packages store programs in $out/lib/libexec instead of $out/libexec. In my store, only KDE packages are effected. Is it worth investigating? Or shall we just leave as it i? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
GNU Mes 0.21 released
We are pleased to announce the release of GNU Mes 0.21, representing 54 commits over 10 weeks. Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap a GNU/Linux system without binary GNU toolchain or equivalent). See https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ This release supports a Scheme-only bootstrap: Mes can now be built with Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and GNU Tar. Also, the Mes C Library now supports bootstrapping those. Finally, this release brings Mes as a package to Debian GNU/Linux. We are excited that the Nlnet Foundation[12] is now sponsoring this work! Next targets: - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian, Gentoo, ...?) - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the Guix bootstrap binaries - ARM support - Full Source Bootstrap: compile Mes.c using M2-Planet - Reduced Binary Seed bootstrap for ARM - the Hurd Packages are available in Guix master. * About GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]. This bootstrap has halved the size of opaque, uninspectable binaries that were needed to bootstrap Guix. The final goal is to help create a full source bootstrap as part of the bootstrappable builds[3] effort for any interested UNIX-like operating system. It consists of a mutual self-hosting Scheme interpreter written in ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. The Scheme interpreter has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] --and test suite just enough to support a REPL and a C99 compiler: MesCC. Mes+MesCC can compile an only lightly patched TinyCC[9] that is self-hosting. Using this tcc and the Mes C library we now have a Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for i686-linux and x86_64-linux. Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. * Download git clone git://git.savannah.gnu.org/mes.git Here are the compressed sources and a GPG detached signature[*]: https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig Use a mirror for higher download bandwidth: https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig Here are the MD5 and SHA1 checksums: dea43529d2d84fb4b9d81bdd9efcc715 mes-0.21.tar.gz 35721a81feeab6e0d5913b8bf78f18951edbb964 mes-0.21.tar.gz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify mes-0.21.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 and rerun the 'gpg --verify' command. * Get informed, get involved See https://bootstrappable.org Join #bootstrappable on irc.freenode.net. * Changes in 0.21 since 0.20 ** Core *** Mes can now be bootstrapped with Gash and Gash Core Utils. *** Mes now supports a Scheme-only bootstrap. *** Mes now supports -c EXPR. ** MesCC *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU SED, and GNU Tar. *** Mes C Library now has limited float support in vfprintf, vsnprintf, vsscanf. 7 new functions abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod, symlink. 5 new stubs getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent. ** Noteworthy bug fixes *** A bug with `mes -c EXPR' has been fixed. *** The REPL now works again on x86_64. *** --with-system-libc now works again. Greetings, janneke and Danny. [0] https://www.gnu.org/software/mes [1] https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ [2] https://www.gnu.org/software/guix [3] https://bootstrappable.org [4] https://github.com/oriansj/mes-m2 [5] https://github.com/oriansj/m2-planet [6] https://github.com/schemeway/lalr-scm [7] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html [8] https://www.nongnu.org/nyacc [9] https://gitlab.com/janneke/tinycc [10] http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf [11] https://savannah.nongnu.org/projects/stage0 [12]
Re: Guile-Git & delayed ‘dynamic-link’ calls
> Does anywone understands what's going on here? Found it! It's the #:return-errno passed to pointer->procedure that makes every call to libgit2->procedure return two values. The second one (the errno) was silently ignored. I'll propose a patch soon. Mathieu
Re: Relationship between Docker and Guix
Hi, Thank you Ricardo for the detailed explanations. I do not know if my analogy below is correct and/or useful. The relationship between Docker and GNU Guix is container and the LXC [1] technology. They use both but differently: - Docker is rooted in mutable/imperative and tries to go to more functional; - Guix is rooted in immutable/functional. Everything starts with a configuration file: Dockerfile versus manifest.scm. - Dockerfile depends on the state of the distribution that one will use -- say Debian -- and each time "RUN apt-get update" and/or "RUN apt-get install" is called then no one can know in advance what the resulting disk image will *exactly* contain; - the manifest.scm depends on the state of the channel trees, other said, on commit hashes -- manifest.scm acts as a pure function: same inputs, same outputs -- so one obtain exactly the same container. We cannot guarantee that the manifest.scm file which one runs today will generate the same bit-to-bit disk image in the future. Mainly because it has not been tested yet on the long run. :-) However, Guix provides the tools to detect that something is not as expected. For example, we can imagine that today one says: this is the manifest to build the disk image and the hashes of the store are that (the same way one provides the MD5 of files when downloading); then in the future, building again the disk image, we can compare. Currently, it is impossible with Docker because all the distro are doomed (mutable). ;-) So what people are currently doing is to store all the Docker disk images. Docker motto: build once and run anywhere. Guix motto(*): build anytime and run everywhere. To me the relationship(**) is: guix pack -f docker -m stuff.scm docker load < /gnu/store/-fancy-name.tar docker push Hope that helps. All the best, simon [1] https://en.wikipedia.org/wiki/LXC (*) it is not official and my personal view ;-) (**) again my personal view.
Re: ARM VM with networking support?
Hey Marius, > Do you know roughly what's needed to support cross-compiling in > meson-build-system, apart from creating a '--cross-file'[0]? Never looked into it, but it seems that nix has proper cross compilation support for meson (using cross-file.conf as you mentionned), see: nixpkgs/pkgs/development/tools/build-managers/meson/default.nix Sadly there are other build-systems where cross-compiling isn't supported: * scons.scm * haskell.scm * python.scm * ruby.scm * perl.scm * meson.scm * r.scm * android-ndk.scm * go.scm * waf.scm * emacs.scm * asdf.scm * ocaml.scm * node.scm * julia.scm * dune.scm * dub.scm * ant.scm * linux-module.scm * rakudo.scm * cargo.scm * glib-or-gtk.scm As I think that using --system is not viable (horribly slow, hard to find native hardware to cook substitutes), extending cross-compilation support is very important IMO. Thanks, Mathieu
Re: ARM VM with networking support?
Mathieu Othacehe writes: > I tried to cross-compile your system file, but it depends on glib which > uses meson-build-system, that does not support cross-compilation. Do you know roughly what's needed to support cross-compiling in meson-build-system, apart from creating a '--cross-file'[0]? [0] https://mesonbuild.com/Cross-compilation.html signature.asc Description: PGP signature
Re: FSFE seeking talks for 36C3
Hi, >> https://fsfe.org/news/2019/news-20191102-01.en.html > I don’t plan to be there. It’d be great if you or anyone interested > could talk about Guix! I did not make it writing a proposal. Sorry. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Profiles/manifests-related command line interface enhancements
Hi Ludo, I'll start from the end: > What do we disagree on, actually? :-) This: >> 2. Power users will always write code in powerful languages that exceed >>what less advanced users can deal with. And since power users are not >>necessarily benevolent, this creates a trust issue for the less >>advanced ones. > > Good point. I tend to (naively?) view it the other way around: that it > gives people an incentive to try and write actual code rather than mere > declarations. I'd say we should encourage people to write declarations as much as possible and resort to executable code only when declarations become too messy. As a corollary, we should support most configuration-style use cases with suitable declarative forms, much like these: > The goal for Guix was to have the ‘package’ and ‘operating-system’ > forms, for instance, look exactly like what you’d write in JSON etc., > only with a different syntax. For better illustration, I'll try to rewrite my own manifests in the way I'd like to be able to write them. That's probably more useful than theory (a tough statement to make for a theoretician ;-) The main reason why I want to see more declarative style is: >> The problem with powerful formal languages (read: Turing-complete) is >> not writing, but (1) debugging and (2) reading. > > Yes and no. Guile has a debugger, whereas XML/JSON/YAML don’t. As for > reading, it’s subjective, but I don’t think a full-blown language is > necessarily harder to read. It's harder to read because you need to understand the language's execution model if there is one. YAML etc. don't, there is nothing but literals. Which is also why they don't need a debugger. > (define lst (list 1 2 3)) > > lst = [1, 2, 3] Fine. But then a power user comes along and writes (define lst (cons* 1 2 '(3))) That may be bad style, but as a reader I have to be able to deal with it nevertheless. And bad style may in fact serve to obfuscate evil intentions. > Interesting! The conclusion you seem to draw is that embedded DSLs as > found in Racket fit the bill, and to me, that’s pretty much what we’ve > been trying to do with Guix as well, no? Indeed, just not enough for my taste! Cheers, Konrad.
[BLOG] rust blog post
There's one or two FIXMEs and the like in the blog post but I figured I'd send it off anyway. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted It's easy to think of Rust as a new programming language but it has already been around for five years. Rust has made it past it's 1.0 release and the compiler is written in Rust. We even have mrustc to act as a secondary method to bootstrap new Rust releases without falling back to downloading precompiled tarballs. So how is the state of Rust in Guix today? Truthfully, Rust in Guix could be better. The developer story for Rust is pretty straightforward: write your program, declare your dependencies in a Cargo.toml file, and ```cargo foo``` will figure out your dependency chain. ```cargo build``` will download any missing dependencies, even using a cache directory to reduce downloads, and compile the bits of the dependencies that are needed. But what about for distro maintainers? Obviously we can't download dependencies at build time, they need to be packaged ahead of time. So we package those dependencies. But wait, those dependencies have dependencies that are needed, and those ones too. It's dependencies all the way down, hidden in 5 years of iterative development that we're late to the party to, trying to capture snapshots in time where specific versions of libraries built using previous generations. All this all the way back to the beginning, whenever that is. Obviously humans are prone to errors, so to work around this while packaging Rust crates Guix has effectively two importers for crates, one that will import a specific version and list it's dependencies, and one that can take a crate and recursively import all the packages that it depends on. Currently some work is needed to allow the recursive importer to interpret version numbers, but for now it works quite well. Taking a break from Rust for a moment, let's look at some of the other languages that are packaged. Packages written in C/C++, processed with autotools or cmake or meson, are the easiest. Dependencies are declared, source code is provided, and there's a clear distinction between source code and compiled binary; source code is for hacking on, binaries are for executing. The closest to a middle ground are libraries which allow programs to use features from other programs. In order to use a package, all of its dependencies must be packaged and the libraries linked. Taking a look at the other end we have Javascript. Javascript is source code, it's ready to be read and hacked on. Javascript is already ready to be run, therefor it must be a binary. Its... both? Javascript libraries leave distro maintainers in a difficult position. Building Javascript ends up in the same problem as we saw with Rust, recursive dependencies all the way down, iterative versions depending on previous ones, and a misty past from whence everything sprang forth, which must be recreated in order to bring us back to the present day. But there's more difficulty, often even after a 'build' phase has been run and tests have been run on Javascript we're left with unchanged code. Except now it's no longer source, it's a binary... or something. So just what did we build and test? We can worry about Javascript another time, Rust has a clear boundary between source code and binaries. So how about python? Python is a scripting language and can be run without being compiled, but it also can be compiled (pre-interpreted?) to bytecode and installed either locally or globally. That leaves us with source code which can double as a binary, and a bytecode which is clearly a binary. Given these two states, we declare the uncompiled version as source code, ignore that it can be run as a script except when testing the code, and we never return to second-guess ourselves. How about Go? Go is another language that defies packaging efforts, primarily because build instructions often make use of the HEAD of other git branches, not tagged and released versions. That the names of the libraries are long and cumbersome is mostly a secondary issue. On the developer side a binary is a ```go build``` away. Go will download missing source and compile libraries as needed. On a packager side the libraries are carefully gathered one by one, precompiled, and placed carefully in a directory hierarchy for use in future builds. What could be a long build of a program is replaced by an intermediate series of packages where libraries are pre-compiled, and at each stage only the new code has to be compiled. For all except the distro maintainer, the similarities are strong between Rust and Go. In both cases dependencies are downloaded as part of the build process, there's a cache for the downloaded sources and the compiled libraries, and build artifacts can be reused between different
Re: Relationship between Docker and Guix
Hi Ricardo! Thank you sooo much for taking your time for the explanation :) I will probably come back to this when I prepare that part of the presentation about it. Regards :) Laura
