[ANN] Guile-DSV 0.5.1 released
Hello Guilers, I'm pleased to announce Guile-DSV 0.5.1: https://github.com/artyom-poptsov/guile-dsv/releases/tag/v0.5.1 Thanks to Aleix Conchillo who came up with the idea to add Markdown table preset. Also now the "dsv" program from Guile-DSV allows to apply an arbitrary Scheme code to the table before printing it. See the full list of user-visible changes below. * What is Guile-DSV? Guile-DSV is a library that allows to parse Delimiter-Separated Values format (DSV). It supports two flavors of DSV: Unix-style[1] and RFC4180[2]. Also Guile-DSV is shipped with a program named "dsv" that allows to read and process DSV format (including delimiter change and conversion from one standard to another.) See README file for usage examples. * List of user visible changes Here's an excerpt from the NEWS file: --8<---cut here---start->8--- * Changes in version 0.5.1 (2022-02-05) ** Add Markdown table preset =dsv= now has Markdown table preset that allows to generate Markdown tables from a DSV data. ** New module: =(dsv version)= This module contains procedures that return information about the current Guile-DSV version. ** =dsv= now handles =--version= option When this option is passed to the =dsv= program it prints the version information and a short copyright note to the stdout. ** =dsv= now handles =--map-cell= option This option allows to apply an arbitrary Scheme code to each table cell before printing. ** =dsv= now handles =--filter-row= option This option allows to keep only that rows from a table for which the provided Scheme code returned #t. ** =dsv= now handles =--filter-column= option This option allows to keep only that columns from a table for which the provided Scheme code returned #t. --8<---cut here---end--->8--- Thanks and happy hacking! - Artyom [1] http://www.catb.org/~esr/writings/taoup/html/ch05s02.html#id2901882 [2] https://tools.ietf.org/html/rfc4180 -- Artyom "avp" Poptsov Home page: https://memory-heap.org/~avp/ CADR Hackerspace co-founder: https://cadrspace.ru/ GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F signature.asc Description: PGP signature
Newbie thoughts on Guile Hall + Guix
Hello! It's been a while since Guile was my main hacking environment; I've been returning to it, and one of the nicest things to change about its ecosystem is the presence of Guile Hall. I really, really like Guile Hall. A lot! I think it has room to grow but it fills a clearly missing piece of the Guile ecosystem while doing it in the best way possible: making itself explicitly compatible with Guix. I thought I'd write down some impressions while everything is fresh. - Its ability to make an autotools-compatible tarball, but without me needing to think about autotools at all, is a real delight. - Its test suite stuff is also really nice. - I found myself surprised that hall.scm is "just data", instead of taking the more guix'y approach of being code that actually builds a datastucture. I'm not sure what the goal of this is; there can be reasons to take that approach but I'm not sure what it is here? My assumption is that the main reason is so that "hall scan" can correctly read and then modify and spit out another file, but I'm not sure. - What I would actually *really* like would be for the Hall package definition structure to be a wrapper *around* the Guix package structure. Then the guix.scm would be really simple: it could just "peel off" the outer struct. If I wanted to do some smart modifications of things from there maybe I could. I dunno, something like this. - "hall scan" is really cool, but I kind of wish I didn't need to use it. I'd rather not keep track of any of this stuff at all. I'd be happy just pointing some code at a directory and say "snarf up all the .scm files you see therein!" - I'm currently writing a manual starting in a .org file that's then converted into a .texi file. I'd prefer if I could find an entrypoint to insert this into the compilation workflow: a pre-step to the docs compilation that generates the .texi file *from* my .org file. - On that note, it strikes me that Hall's integration with autotools is great because it means that existing distros don't need to be aware of Guile *or* Guix. But it also means that Hall probably has all of the information that it could do all the steps that autoconf and automake do too. That might be interesting to see that. Anyway, just some thoughts. Making Guile packages is already much less intimidating now thanks to Hall's work. Thank you for it! - Christine
Re: Newbie thoughts on Guile Hall + Guix
It would also be nice if we could have a Guile package repository. Den lör 5 feb. 2022 21:11Christine Lemmer-Webber skrev: > Hello! > > It's been a while since Guile was my main hacking environment; I've been > returning to it, and one of the nicest things to change about its > ecosystem is the presence of Guile Hall. > > I really, really like Guile Hall. A lot! I think it has room to grow > but it fills a clearly missing piece of the Guile ecosystem while doing > it in the best way possible: making itself explicitly compatible with > Guix. > > I thought I'd write down some impressions while everything is fresh. > > - Its ability to make an autotools-compatible tarball, but without me >needing to think about autotools at all, is a real delight. > > - Its test suite stuff is also really nice. > > - I found myself surprised that hall.scm is "just data", instead of >taking the more guix'y approach of being code that actually builds a >datastucture. I'm not sure what the goal of this is; there can be >reasons to take that approach but I'm not sure what it is here? >My assumption is that the main reason is so that "hall scan" can >correctly read and then modify and spit out another file, but I'm >not sure. > > - What I would actually *really* like would be for the Hall package >definition structure to be a wrapper *around* the Guix package >structure. Then the guix.scm would be really simple: it could just >"peel off" the outer struct. If I wanted to do some smart >modifications of things from there maybe I could. I dunno, something >like this. > > - "hall scan" is really cool, but I kind of wish I didn't need to use >it. I'd rather not keep track of any of this stuff at all. >I'd be happy just pointing some code at a directory and say "snarf >up all the .scm files you see therein!" > > - I'm currently writing a manual starting in a .org file that's then >converted into a .texi file. I'd prefer if I could find an >entrypoint to insert this into the compilation workflow: a pre-step >to the docs compilation that generates the .texi file *from* my >.org file. > > - On that note, it strikes me that Hall's integration with autotools >is great because it means that existing distros don't need to be >aware of Guile *or* Guix. But it also means that Hall probably has >all of the information that it could do all the steps that autoconf >and automake do too. That might be interesting to see that. > > Anyway, just some thoughts. Making Guile packages is already much less > intimidating now thanks to Hall's work. Thank you for it! > > - Christine > >
Re: Newbie thoughts on Guile Hall + Guix
Hello Christine, Hall, and the rest of Guile! Le samedi 05 février 2022 à 15:01 -0500, Christine Lemmer-Webber a écrit : > It's been a while since Guile was my main hacking environment; I've > been > returning to it, and one of the nicest things to change about its > ecosystem is the presence of Guile Hall. I’m starting to convert my project to hall as well :) > I really, really like Guile Hall. A lot! I think it has room to > grow > but it fills a clearly missing piece of the Guile ecosystem while > doing > it in the best way possible: making itself explicitly compatible with > Guix. > > I thought I'd write down some impressions while everything is fresh. Let me do the same thing. > - Its ability to make an autotools-compatible tarball, but without > me > needing to think about autotools at all, is a real delight. The automake and m4 meta-programming languages are good for what they do, but if we’re also writing scheme for the build system, it would become too much. > - Its test suite stuff is also really nice. Using the SRFI 64 API lowers the cost to add tests, which is especially good for such a dynamic and flexible language as guile. > - I found myself surprised that hall.scm is "just data", instead of > taking the more guix'y approach of being code that actually builds > a > datastucture. I'm not sure what the goal of this is; there can be > reasons to take that approach but I'm not sure what it is here? > My assumption is that the main reason is so that "hall scan" can > correctly read and then modify and spit out another file, but I'm > not sure. It was a problem for me too. I wanted to compute the version number from git describe, and it turns out I couldn’t do that in hall.scm. I had to create a bootstrap script to generate hall.scm, run hall scan and then other hall commands (and then autoreconf). This approach is more functional, because there’s less state (I consider auto-generated Makefile.am, configure.ac and similar files as state because hall and I are supposed to edit them). It means I can git-ignore most of the stuff that hall dist generates. > - What I would actually *really* like would be for the Hall package > definition structure to be a wrapper *around* the Guix package > structure. Then the guix.scm would be really simple: it could > just > "peel off" the outer struct. If I wanted to do some smart > modifications of things from there maybe I could. I dunno, > something > like this. >From what I remember, the guix package data structure is a guix record; is specific to guix. Hall would need to depend on guix (or, my preferred solution, guix would use GOOPS classes instead of guix records for more things, including packages, but we’re not there yet!). I also have a more dynamic guix.scm (I wouldn’t call it smart though). It puts the current commit in the store, runs "hall guix" there, loads the generated guix.scm file, and fixes the package it evaluates to (so as to use the current commit as a source and add hall as a native- input, for instance). Guix shell doesn’t like stuff that’s too smart in guix.scm though, because of its cache. > > - "hall scan" is really cool, but I kind of wish I didn't need to > use > it. I'd rather not keep track of any of this stuff at all. > I'd be happy just pointing some code at a directory and say "snarf > up all the .scm files you see therein!" Such a wildcard pattern was heavily discouraged in the past, because you could forget to distribute some files and there wouldn’t be a good way to know why the build would fail on someone else’s computer due to a missing file. Nowadays, we have git (and other version control systems) and continuous integration, so I don’t see a reason why what you want would be a problem. > > - I'm currently writing a manual starting in a .org file that's then > converted into a .texi file. I'd prefer if I could find an > entrypoint to insert this into the compilation workflow: a pre- > step > to the docs compilation that generates the .texi file *from* my > .org file. I think it would be easier for hall to support org->texi conversion natively, so that we could still code without automake knowledge. For instance, as you must have noticed, implementing the conversion as an automake rule means that automake will fail because it won’t know whether the generated file needs version.texi. > - On that note, it strikes me that Hall's integration with autotools > is great because it means that existing distros don't need to be > aware of Guile *or* Guix. But it also means that Hall probably > has > all of the information that it could do all the steps that > autoconf > and automake do too. That might be interesting to see that. You mean that hall could implement all of the autotools features? Even if we remove C-related features, hoping that we won’t need to write C code ever again, that’s still a lot to ask for. I’m not sure
Re: Newbie thoughts on Guile Hall + Guix
On Sat, Feb 05 2022, Mikael Djurfeldt wrote: > It would also be nice if we could have a Guile package repository. FWIW, I wish we had an alternative to Guix and autotools for pure-scheme packages, which don't need all that complication (and that i would love to see becoming the norm, with that pretty FFI of ours). Something like, say, leiningen (or elpa, raco, rebar3, cargo, gobuild, elpa, cabal...). For context: https://gitlab.com/a-sassmannshausen/guile-hall/-/issues/51 I'd call it "wile", packages would live in "the wilery" (wilery.org is free) and wile.scm would probably use a simplified dorodango syntax... and i'd even work on it. But my feeling is that the community is heavily invested in autotools and Guix as /the/ build system (and very happily so!) and i don't have the evangelising chops/time :) Cheers, jao -- Nature uses as little as possible of anything. -Johannes Kepler, astronomer (1571-1630)
Re: Newbie thoughts on Guile Hall + Guix
IMO, we have, that, and it is Guix. I'm actually quite happy about that. :) Specific-language-package-repos have caused a lot of the mess we're currently in; in an unexpected way, it's hurt user freedom a lot, because mixing these is so hard that software which might be otherwise reproducible and usable by everyone becomes only deployable by "expert" devops teams deploying ad-hoc container black boxes who are themselves very overloaded and have a hard time keeping on top of what's going on. Guix is great. I'd love Guix to become the universal package repository for all FOSS languages. :) - Christine Mikael Djurfeldt writes: > It would also be nice if we could have a Guile package repository. > > Den lör 5 feb. 2022 21:11Christine Lemmer-Webber > skrev: > > Hello! > > It's been a while since Guile was my main hacking environment; I've been > returning to it, and one of the nicest things to change about its > ecosystem is the presence of Guile Hall. > > I really, really like Guile Hall. A lot! I think it has room to grow > but it fills a clearly missing piece of the Guile ecosystem while doing > it in the best way possible: making itself explicitly compatible with > Guix. > > I thought I'd write down some impressions while everything is fresh. > > - Its ability to make an autotools-compatible tarball, but without me > needing to think about autotools at all, is a real delight. > > - Its test suite stuff is also really nice. > > - I found myself surprised that hall.scm is "just data", instead of > taking the more guix'y approach of being code that actually builds a > datastucture. I'm not sure what the goal of this is; there can be > reasons to take that approach but I'm not sure what it is here? > My assumption is that the main reason is so that "hall scan" can > correctly read and then modify and spit out another file, but I'm > not sure. > > - What I would actually *really* like would be for the Hall package > definition structure to be a wrapper *around* the Guix package > structure. Then the guix.scm would be really simple: it could just > "peel off" the outer struct. If I wanted to do some smart > modifications of things from there maybe I could. I dunno, something > like this. > > - "hall scan" is really cool, but I kind of wish I didn't need to use > it. I'd rather not keep track of any of this stuff at all. > I'd be happy just pointing some code at a directory and say "snarf > up all the .scm files you see therein!" > > - I'm currently writing a manual starting in a .org file that's then > converted into a .texi file. I'd prefer if I could find an > entrypoint to insert this into the compilation workflow: a pre-step > to the docs compilation that generates the .texi file *from* my > .org file. > > - On that note, it strikes me that Hall's integration with autotools > is great because it means that existing distros don't need to be > aware of Guile *or* Guix. But it also means that Hall probably has > all of the information that it could do all the steps that autoconf > and automake do too. That might be interesting to see that. > > Anyway, just some thoughts. Making Guile packages is already much less > intimidating now thanks to Hall's work. Thank you for it! > > - Christine
Re: Newbie thoughts on Guile Hall + Guix
On 2/5/22 21:01, Christine Lemmer-Webber wrote: Hello! It's been a while since Guile was my main hacking environment; I've been returning to it, and one of the nicest things to change about its ecosystem is the presence of Guile Hall. I really, really like Guile Hall. A lot! I think it has room to grow but it fills a clearly missing piece of the Guile ecosystem while doing it in the best way possible: making itself explicitly compatible with Guix. I thought I'd write down some impressions while everything is fresh. - Its ability to make an autotools-compatible tarball, but without me needing to think about autotools at all, is a real delight. - Its test suite stuff is also really nice. - I found myself surprised that hall.scm is "just data", instead of taking the more guix'y approach of being code that actually builds a datastucture. I'm not sure what the goal of this is; there can be reasons to take that approach but I'm not sure what it is here? My assumption is that the main reason is so that "hall scan" can correctly read and then modify and spit out another file, but I'm not sure. - What I would actually *really* like would be for the Hall package definition structure to be a wrapper *around* the Guix package structure. Then the guix.scm would be really simple: it could just "peel off" the outer struct. If I wanted to do some smart modifications of things from there maybe I could. I dunno, something like this. - "hall scan" is really cool, but I kind of wish I didn't need to use it. I'd rather not keep track of any of this stuff at all. I'd be happy just pointing some code at a directory and say "snarf up all the .scm files you see therein!" - I'm currently writing a manual starting in a .org file that's then converted into a .texi file. I'd prefer if I could find an entrypoint to insert this into the compilation workflow: a pre-step to the docs compilation that generates the .texi file *from* my .org file. - On that note, it strikes me that Hall's integration with autotools is great because it means that existing distros don't need to be aware of Guile *or* Guix. But it also means that Hall probably has all of the information that it could do all the steps that autoconf and automake do too. That might be interesting to see that. Anyway, just some thoughts. Making Guile packages is already much less intimidating now thanks to Hall's work. Thank you for it! - Christine For what it is worth: You do not need to use Hall, if you do not need to run tests, when installing via Guix or similar things. If you are fine with running tests before publishing a version of a package to Guix, then you only need Guix and a package definition. No autotools. I found all the stuff that is generated by Hall a bit worrying. Lots of autotools appearing in my repository, which I do not fully understand. Being forced to use hall scan and so on. Too much magic behind the scenes. Packaging should be so simple, that I can still easily understand all the things in my repository, without studying autotools for a week, searching for archaic variable names and what they to and how everything works. I am not a huge fan of the JS ecosystem at all, but if we look at the NPM world, there is only one file that needs to exist, the package.json, and already you have a valid package. Why can it not be the same simplicity for Guile? And if Guix really requires there to be a `make` `make check` or whatever, then where is the guide, that tells me how to hand-craft the Makefile, so that everything works and I don't need extra tooling to generate files. I want to be able to edit the guix package definition, point it to the tests directory, and be done with it. When I use Hall, then I have yet another tool in the workflow. Again more commands and things to keep in mind. I want less tools and simplicity. I don't run autotools for running my tests locally, so there is no theoretical need for that. The maximum I do it a very simple Makefile, which provides me with a `make test` to run tests or `make` to run the program. It is just that from the Guix side of things, something would have to be done to be able to invoke tests properly, without a `make test` command being available, but knowing where the tests are. They could be declared in the package definition for example. Why do I need any autotools stuff? Just make Guix call my SRFI-64 tests. This is why I decided to not use Hall for guile-fslib. I did not like the complexity of having all the autotools stuff in my repo, which I don't even fully understand, just for it becoming a package. Even if I don't need to manually touch any of those files. I can run tests on my machine before sending in a patch for a new version and that will be fine. Hall is probably a great thing, if you have a package, that is not pure Guile, s
Re: Newbie thoughts on Guile Hall + Guix
I will have to disagree on this one. Not about Guix being great :-). I believe a simple, lightweight, integrated and cross platform package manager for Guile would be fantastic. For reasons that don't matter right now I have been using macOS for the past two years and I wish I had a package manager. Since I didn't have one I created Guile Homebrew which I'm probably the only one using. However, I would love to have something like other languages have as jao and Zelphir suggest. It is true that Guix would solve the reproducibility issue, but installing Guix and having a completely separate system of libraries just to write some project is overkill, at least for me. Maybe it makes sense for some specific projects but for most of the things that people work on I would say it probably doesn't. Plus, it doesn't work on macOS but that's another story. Speaking about package managers for Guile, some might remember about Guildhall (https://github.com/ijp/guildhall), maybe it's waiting there for someone to pick it up. Aleix On Sat, Feb 5, 2022 at 4:47 PM Christine Lemmer-Webber < cweb...@dustycloud.org> wrote: > IMO, we have, that, and it is Guix. I'm actually quite happy about > that. :) > > Specific-language-package-repos have caused a lot of the mess we're > currently in; in an unexpected way, it's hurt user freedom a lot, > because mixing these is so hard that software which might be otherwise > reproducible and usable by everyone becomes only deployable by "expert" > devops teams deploying ad-hoc container black boxes who are themselves > very overloaded and have a hard time keeping on top of what's going on. > > Guix is great. I'd love Guix to become the universal package repository > for all FOSS languages. :) > > - Christine > > Mikael Djurfeldt writes: > > > It would also be nice if we could have a Guile package repository. > > > > Den lör 5 feb. 2022 21:11Christine Lemmer-Webber > skrev: > > > > Hello! > > > > It's been a while since Guile was my main hacking environment; I've been > > returning to it, and one of the nicest things to change about its > > ecosystem is the presence of Guile Hall. > > > > I really, really like Guile Hall. A lot! I think it has room to grow > > but it fills a clearly missing piece of the Guile ecosystem while doing > > it in the best way possible: making itself explicitly compatible with > > Guix. > > > > I thought I'd write down some impressions while everything is fresh. > > > > - Its ability to make an autotools-compatible tarball, but without me > > needing to think about autotools at all, is a real delight. > > > > - Its test suite stuff is also really nice. > > > > - I found myself surprised that hall.scm is "just data", instead of > > taking the more guix'y approach of being code that actually builds a > > datastucture. I'm not sure what the goal of this is; there can be > > reasons to take that approach but I'm not sure what it is here? > > My assumption is that the main reason is so that "hall scan" can > > correctly read and then modify and spit out another file, but I'm > > not sure. > > > > - What I would actually *really* like would be for the Hall package > > definition structure to be a wrapper *around* the Guix package > > structure. Then the guix.scm would be really simple: it could just > > "peel off" the outer struct. If I wanted to do some smart > > modifications of things from there maybe I could. I dunno, something > > like this. > > > > - "hall scan" is really cool, but I kind of wish I didn't need to use > > it. I'd rather not keep track of any of this stuff at all. > > I'd be happy just pointing some code at a directory and say "snarf > > up all the .scm files you see therein!" > > > > - I'm currently writing a manual starting in a .org file that's then > > converted into a .texi file. I'd prefer if I could find an > > entrypoint to insert this into the compilation workflow: a pre-step > > to the docs compilation that generates the .texi file *from* my > > .org file. > > > > - On that note, it strikes me that Hall's integration with autotools > > is great because it means that existing distros don't need to be > > aware of Guile *or* Guix. But it also means that Hall probably has > > all of the information that it could do all the steps that autoconf > > and automake do too. That might be interesting to see that. > > > > Anyway, just some thoughts. Making Guile packages is already much less > > intimidating now thanks to Hall's work. Thank you for it! > > > > - Christine > > >
