Re: How do I build a derivation with guix build?
Hi divoplade, As I understand it, ‘gexp->derivation’ returns a value in the store monad. I’m not sure why ‘guix build’ doesn’t know how to use it directly, but you can get at the derivation by wrapping it with ‘run-with-store’: (run-with-store (open-connection) (gexp->derivation "the-thing" build-exp)) Don’t forget to use the ‘(guix store)’ module for this. But! There’s a better way!! :) You can use the “declarative interface”. Just replace ‘gexp->derivation’ with ‘computed-file’: (computed-file "the-thing" build-exp) Now there’s no need for ‘(guix store)’. HTH! -- Tim divoplade writes: > Hello, > > I am still learning how to use gexps, and I thought that running this > would work: > > guix build -f example.scm > > with example.scm containing: > > (use-modules (gnu packages base)) > (use-modules (guix gexp)) > > (define build-exp > #~(begin > (mkdir #$output) > (chdir #$output) > (symlink (string-append #$coreutils "/bin/ls") >"list-files"))) > > (gexp->derivation "the-thing" build-exp) > > This is a copy of what's on the manual for explaining G-expressions. > > The guix build -f command should, according to the --help output: > "build the package or derivation that the code within FILE evaluates > to" > > However, I get an exception, "Wrong number of arguments to # 7f775f854f00 at guix/gexp.scm:1064:2 (state)>", after a backtrace that > does not even contains example.scm. > > What is going on? How do you build the derivation? > > Best regards, > > divoplade
How do I build a derivation with guix build?
Hello, I am still learning how to use gexps, and I thought that running this would work: guix build -f example.scm with example.scm containing: (use-modules (gnu packages base)) (use-modules (guix gexp)) (define build-exp #~(begin (mkdir #$output) (chdir #$output) (symlink (string-append #$coreutils "/bin/ls") "list-files"))) (gexp->derivation "the-thing" build-exp) This is a copy of what's on the manual for explaining G-expressions. The guix build -f command should, according to the --help output: "build the package or derivation that the code within FILE evaluates to" However, I get an exception, "Wrong number of arguments to #", after a backtrace that does not even contains example.scm. What is going on? How do you build the derivation? Best regards, divoplade
Re: Problems with McCLIM (Common Lisp)
Hi Pierre, Another approach could be not to use ASDF bundles at all, and just use the regular compilation operation of ASDF, except the fasl files would be put it "/gnu/store/..." instead of "$HOME/.cache/common-lisp/...", and our asdf-build-system would indicate to ASDF where to search for the files. Good ideas. In my opinion, the fasls (pre-built binaries) should go to their respective package outputs. That sounds good, as does getting rid of ADSF bundles. I have more or less given up on numcl, for example, which fails to compile to a bundle in recent versions but seems to work find via fasls (at least it works fine with quicklisp). Konrad.
Re: Has anyone managed to set up a SMTP server?
Hello, Le samedi 05 septembre 2020 à 07:00 -0400, Julien Lepiller a écrit : > Hi, > > Here's my server's configuration. It's divided in multiple modules, > so it might not be easy to read, but here's the mail-related > configuration: > > https://framagit.org/tyreunom/system-configuration/-/blob/master/modules/config/mail.scm > > HTH! Thank you, it will, surely. From all configuration modules, I see that you have a very full-featured server. I have a similar goal for mine (except it will also replace framagit, which is slowly closing down, unfortunately. I believe I can substitute cuirass for gitlab-ci, provided it runs on my server). divoplade > > Le 5 septembre 2020 06:38:32 GMT-04:00, divoplade a > écrit : > > Hello Guix, > > > > I am trying to set up a mail server. I had already "done" this on > > debian, where I could just set up a couple of configuration options > > and > > it would generate the HUGE template configuration file, and then > > compile it down to a still huge but unreadable configuration file > > through update-exim4.conf. > > > > Now, I cannot help but notice that no such thing exists on guix. So > > I > > have to actually configure everything from scratch, and the task is > > quite heavy. Has anyone already done that? > > > > Anyways, is it easier to do with opensmtpd? > > > > Best regards, > > > > divoplade > > > >
Re: Has anyone managed to set up a SMTP server?
Hi, Here's my server's configuration. It's divided in multiple modules, so it might not be easy to read, but here's the mail-related configuration: https://framagit.org/tyreunom/system-configuration/-/blob/master/modules/config/mail.scm HTH! Le 5 septembre 2020 06:38:32 GMT-04:00, divoplade a écrit : >Hello Guix, > >I am trying to set up a mail server. I had already "done" this on >debian, where I could just set up a couple of configuration options and >it would generate the HUGE template configuration file, and then >compile it down to a still huge but unreadable configuration file >through update-exim4.conf. > >Now, I cannot help but notice that no such thing exists on guix. So I >have to actually configure everything from scratch, and the task is >quite heavy. Has anyone already done that? > >Anyways, is it easier to do with opensmtpd? > >Best regards, > >divoplade
Has anyone managed to set up a SMTP server?
Hello Guix, I am trying to set up a mail server. I had already "done" this on debian, where I could just set up a couple of configuration options and it would generate the HUGE template configuration file, and then compile it down to a still huge but unreadable configuration file through update-exim4.conf. Now, I cannot help but notice that no such thing exists on guix. So I have to actually configure everything from scratch, and the task is quite heavy. Has anyone already done that? Anyways, is it easier to do with opensmtpd? Best regards, divoplade
Re: Problems with McCLIM (Common Lisp)
Ricardo Wurmus skribis: > Pierre Neidhardt writes: > >>> I’d like to play with McClim and all its applications to see if it would >>> be worth doing something like this for Guile :) >> >> Maybe. Have you considered using GObject Introspection to build >> full-fledged GTK apps in Guile? I've heard of 2 Guile libraries for GI: >> guile-gi and g-golf. > > That’s not the same. I really do want the Lisp Machine experience, not > just GTK apps. I added a few more McCLIM packages, which should allow you to test the examples with something like: --8<---cut here---start->8--- guix environment --ad-hoc sbcl sbcl-clim-examples cl-slime-swank -- \ sbcl --eval '(require :asdf)' \ --eval '(asdf:load-system "clim-examples")' \ --eval '(clim-demo:demodemo)' --8<---cut here---end--->8---
Re: Problems with McCLIM (Common Lisp)
Pierre Neidhardt writes: >> I’d like to play with McClim and all its applications to see if it would >> be worth doing something like this for Guile :) > > Maybe. Have you considered using GObject Introspection to build > full-fledged GTK apps in Guile? I've heard of 2 Guile libraries for GI: > guile-gi and g-golf. That’s not the same. I really do want the Lisp Machine experience, not just GTK apps. -- Ricardo
Re: Problems with McCLIM (Common Lisp)
Hi Ricardo, Ricardo Wurmus writes: > But shouldn’t it then be propagated? I had to guess that I might need > to install it. I think it should just be installed when installing > McClim. I guess so, but I've never used McClim myself. > So, is this something we need to patch in all the asd files for McClim? > Or is this something we should change in the build system? Something to change in our build system. > I’d like to play with McClim and all its applications to see if it would > be worth doing something like this for Guile :) Maybe. Have you considered using GObject Introspection to build full-fledged GTK apps in Guile? I've heard of 2 Guile libraries for GI: guile-gi and g-golf. >> The "deliver-asd" operation has been fixed in recent versions of ASDF, >> so maybe it would be possible to use it instead of our home-made >> functions to create asd files for the bundles. >> >> Another approach could be not to use ASDF bundles at all, and just use >> the regular compilation operation of ASDF, except the fasl files would >> be put it "/gnu/store/..." instead of "$HOME/.cache/common-lisp/...", >> and our asdf-build-system would indicate to ASDF where to search for the >> files. Good ideas. In my opinion, the fasls (pre-built binaries) should go to their respective package outputs. Every Common Lisp package would then have its sources in "out", the SBCL fasls in "sbcl", the ECL libs in "ecl", etc. After all, the main benefit of compiling the fasls is to make sure our package loads properly. > I don’t know enough about Common Lisp to give a valuable comment here, > but I’d very much like to be able to install Common Lisp things without > having to do additional work post installation. Using more “default” > ways to install ASDF bundles perhaps would get us closer to a default > experience. We already have this if you install the cl- packages instead of the sbcl- ones. It should provide a smooth user experience. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
