Re: Is this a bug in guix refresh with respect to Common Lisp packages?
Im not sure it really makes sense to refresh an ecl- package.
Re: Should Guix support writing CLI Common Lisp scripts? (Think Roswell)
Hello. I have done scripts exactly as John describe before. I think this way is fine for making common lisp scripts on guix; that command line you shared can be put in a file and run as a shell script, or even put into a package. I think what Jgart is asking for is a program that may or may not be a part of gnu guix, but certainly depends on it. This program will be able to run roswell scripts with 100% compatibility using guix instead of roswell for loading systems. I'm not too sure how roswell knows which system to load or which common lisp implementation to use for a given script. The purpose of this program would be to use guix's common lisp implementations and systems for roswell scripts. As I understand it, running roswell on a guix system will result in roswell downloading and installing it's own common lisp implementation and loading systems from quicklisp. Original Message On Dec 27, 2022, 12:25 PM, John Kehayias < john.kehay...@protonmail.com> wrote: > > Hi Guixers/Lispers, On Tue, Dec 27, 2022 at 06:14 PM, jgart wrote: > Hi > Guixers, > > Should Guix support writing CLI Common Lisp scripts? (Think > Roswell) > >> Although Roswell is a unified interface to Common Lisp > implementations, it also >> encourages writing scripts with it. >> A "Roswell > script" is an implementation-independent script which can be invoked from a > >> shell command line, launched by > Roswell and run under standard CL > environment. > > Just insert "Guix" wherever you see Roswell mentioned in the > above quote. > >> * A roswell script can be distributed using quicklisp's > infrastructure > > Just insert "Guix" wherever you see quicklisp is mentioned > in the above quote. > >> If you're the author of the library, then consider > adding the ros file to the repository >> and automatically providing a > roswell-installable command-line interface to it. > > Same above, insert > Guix. > > I think we should make it easier for Lispers to write CLI scripts > with Guix. > > WDYT > > I'm not sure what you mean if it is something beyond > what we can do already with 'guix shell.' Do you mean using a particular > hashbang as well? I haven't done that but my simplistic usage is quick and > easy for me. For example, I like to have some CL scripts I use for file > processing that lives as a single .lisp file. To run it I just do: guix shell > sbcl sbcl-cl-csv unoconv -- sbcl --load myscript.lisp ~/Downloads/*.xlsx > where I can include the compiler/interpreters sbcl, needed library, and an > external tool that is called by the script for pre-processing. Works great, > and of course instantly after the first caching. This could be combined with > a manifest, version/channel pinning, making my script a package in a channel, > guix.scm file, and so on, to make it more reproducible. But for me this is > already super handy and easy, just one line. John
Re: Package Argument #:asd-systems Missing & Guix Provides
> The "xxx/a" and "xxx/b" systems will get compiled > automatically by ASDF as they are depencencies of the "xxx" system, but > they won't appear in the 'asd-systems' list. I forgot about that. Perhaps it would work to assume that everything before the first slash is the base system. Thus: $ guix provides --asdf-system xxx/a sbcl-xxx ecl-xxx cl-xxx Also for completeness: guix package with asdf-build-system and no #:asd-systems get the system name from the package-name. I have already accounted for this.
Package Argument #:asd-systems Missing & Guix Provides
Hello Guix Developers. More specifically, the #:asd-systems package-argument is missing from lisp libraries using the asdf-build-system/source (packages like cl-alexandria). I understand that it is removed on line 205 of guix/build-system/asdf.scm along with other package-arguments. (strip-keyword-arguments '(#:tests? #:lisp #:asd-systems #:asd-test-systems #:asd-operation) (package-arguments pkg)) The reason is clear: asdf-build-system/source doesn't actually build anyting, so it doesn't need any build arguments. Would it hurt to leave the package-arguments there even though they are unused? Full Context: I am trying to make a guix-provides script that would take some artifact (name of asd-system) as input and give the packages that create those artifacts. Examples: Find by asdf-system $ guix provides --asdf-system com.inuoe.jzon sbcl-jzon ecl-jzon cl-jzon Find by binary. I think it will take significant changes to get this one to work. $ guix provides as binutils I'm working on the --asdf-system version as a proof of concept because I like lisp, and it seems doable with minimal changes. The one problem I'm running into is not having access to the #:asd-systems package argument for packages with asdf-build-system/source. I agin ask: Would it be possible to leave the package-arguments (at least the #:asd-systems) in tact for asdf-build-system/source packages? - Charles
Re: minification R: build-system
I think what would be ideal is packaging the Javascript dependencies separately, then including them as inputs. I wouldn't be suprised if someone has tried this, but I don't know the history. ‐‐‐ Original Message ‐‐‐ On Monday, September 27th, 2021 at 12:28 PM, zimoun wrote: > Hi, > > Recently, the switch from uglify-js to uglifyjs raises a question if > > this minification should be part of the r-build-system; as suggested > > by Ricardo: > > http://logs.guix.gnu.org/guix-hpc/2021-09-22.log#160424 > > What people think to this move? Because, currently the replacement of > > the minifier means grep and replace all by hand, i.e., prone-error. > > It should be nice to add a step for the R packages. WDYT? > > All the best, > > simon
Question about compile packages
Dear, How can I modify the flags that any program is compiled with within guix? That is, I can allow in the gnu-build-system to modify it globally so that I can add the build flags to any package, for example, add the flags -O2 -march=native -mtune=native so global as I already mentioned, so that these are added to each package at the time of compilation, this would not be within the guix development environment, because what I want is that this compilation is natively for my pc. As a second question, how could I set the --no-susbtitutes option when installing the guix system from ISO, since I would like all installed packages to be compiled natively first? I really appreciate your kind time and I look forward to your responses. Sincerely, ~ Abraham Huerta
Re: [Nix-dev] FOSDEM: any plans for Saturday evening?
Cillian de Róiste writes: > It looks like we have 4-6 people interested. That's great! I guess we don't > really need to make a reservation, just go to a part of town with a lot of > restaurants, but if anyone has a suggestion for a restaurant or bar all the > better. > > The talks should be finished by 19:00 so why don't we meet up at the main > infodesk shortly afterwards and take it from there?: > https://fosdem.org/2014/practical/transportation/ That sounds sensible. The NixOS talk is on Saturday at 17:00, so I imagine a few of us will be going (I'll certainly be there). - ocharles
Re: [Nix-dev] FOSDEM: any plans for Saturday evening?
Cillian de Róiste writes: > Hi, > > Since there will be quite a few NixOS and Guix folks at FOSDEM it would be > great to meet up. Is there some interest in arranging dinner / drinks on > Saturday evening? I'd love this! Just out of interest, which of us will be going? - ocharles
