Re: The Shepherd on Fibers
Il giorno mar, 29/03/2022 alle 15.29 +, Attila Lendvai ha scritto: > > > Which socket file? > > > > > > (In practice ‘exec-command’ would only fail if the program cannot > > > be > > > found.) > > > > Attila Lendvai has encountered the socket file to be deleted > > before, > > this seemed to have been the cause and I have seen a few bug > > reports > > (about tor?) that might have had the same cause. I don't have a bug > > number at hand. > > my first ever service has non-trivial work to do in the start GEXP, > and unsurprisingly, it has often ended up throwing an exception while > i subled along my learning curve. it's not caught by shepherd right > around the call to the start GEXP, and reaches a handler up higher > that ends up deleting the socket (and IIRC skipping the start of rest > of the services). > > it's on my TODO to harden the error handling in shepherd once the > shepherd-for-guix patch is in, or something equivalent that shortens > the edit-compile-test cycle of shepherd. What's the shepherd-for-guix patch ? What does it bring to Shepherd ?
Re: Formalizing teams
Il giorno lun, 03/01/2022 alle 16.22 +0100, Ludovic Courtès ha scritto: > This brings a related but slightly different topic: how to let people > filter incoming patches and bug reports in general. > > How does it even work on git*.com? Do they let you subscribe to > issues/merge requests that match certain patterns or touch certain > files? I don't remember exactly about Github and Gitlab But I do remember about the Canonical issue tracking system for Ubuntu When you file a bug there, you are asked to include a list of packages/areas of the system you think your bug is about That automatically informs the right people/teams Also on Stackoverflow, you can accompany your question with some labels (tags) and every tag is "followed" by some concerned people
Re: Organising Guix Days
Il giorno gio, 30/12/2021 alle 09.53 +0700, Blake Shaw ha scritto: > > Hi folks, > > Regarding the presentation I'm putting together on the Guile > Documentation, while I have enough material right now to send out a > basic presentation that covers what I believe to be the dominant, > glaring issues of the composition and organization of the docs as > well > as how I would go about restructuring them if everyone agrees with > the > proposed edits, I'm also starting to uncover some more nuanced > issues with some of the pedagogical folly that appears throughout the > text, and so a few more weeks would probably result in a more > comprehensive study. > > So I was thinking, in that case, should I just make the presentation > for > Guix Days? That way it could also be presented at a time when other, > perhaps related projects and issues are coming to the fore. > I'd say: if it's not too much hassle for you, prepare the "reduced" version for the Guix Days In such version, you could just hint that there's more to come As for the more nuanced version, you could take your time and do it when you feel it's ready I can't wait <3 Thanks !
Re: Guix Documentation Meetup
Il giorno dom, 12/12/2021 alle 21.50 -0600, Katherine Cox-Buday ha scritto: > - In geiser, run =,a thing-i-want-to-look-for= (this is supposedly an > apropos > command that is supposed to search symbols for you). The command > returns > nothing. I realize I have to import the module implementing the > thing I'm > looking for first, thus defeating the purpose. about this, I want to report an example scheme@(guile-user)> (help tail) Did not find any object named `tail' scheme@(guile-user)> BUT scheme@(guile-user)> (help "tail") <-- notice the quotation marks ! Documentation found for: (language cps): $ktail (language tree-il): seq-tail (language tree-il): abort-tail (guile): list-tail (guile): make-struct/no-tail (srfi srfi-1): find-tail (system vm assembler): emit-tail-call-label (system vm assembler): emit-tail-call (system vm assembler): emit-tail-pointer-ref/immediate (ice-9 vlist): vlist-tail `$ktail' is an object in the (language cps) module. - Variable: $ktail `seq-tail' is a procedure in the (language tree-il) module. - Variable: seq-tail `abort-tail' is a procedure in the (language tree-il) module. - Variable: abort-tail `list-tail' is a procedure in the (guile) module. - Function: list-tail _ _ - Scheme Procedure: list-tail lst k Return the "tail" of LST beginning with its Kth element. The first element of the list is considered to be element 0. `list-tail' and `list-cdr-ref' are identical. It may help to think of `list-cdr-ref' as accessing the Kth cdr of the list, or returning the results of cdring K times down LST. `make-struct/no-tail' is a procedure in the (guile) module. - Function: make-struct/no-tail _ . _ - Scheme Procedure: make-struct/no-tail vtable . init Create a new structure. VTABLE must be a vtable structure (see Vtables). The INIT1, ... are optional arguments describing how successive fields of the structure should be initialized. Note that hidden fields (those with protection 'h') have to be manually set. If fewer optional arguments than initializable fields are supplied, fields of type 'p' get default value #f while fields of type 'u' are initialized to 0. `find-tail' is a procedure in the (srfi srfi-1) module. - Function: find-tail pred lst Return the first pair of LST whose CAR satisfies the predicate PRED, or return `#f' if no such element is found. `emit-tail-call-label' is a procedure in the (system vm assembler) module. - Function: emit-tail-call-label asm t-ff72ee5a3696d21-378b `emit-tail-call' is a procedure in the (system vm assembler) module. - Function: emit-tail-call asm `emit-tail-pointer-ref/immediate' is a procedure in the (system vm assembler) module. - Function: emit-tail-pointer-ref/immediate asm t-ff72ee5a3696d21-3ac6 t-ff72ee5a3696d21-3ac7 t-ff72ee5a3696d21-3ac8 `vlist-tail' is a procedure in the (ice-9 vlist) module. - Function: vlist-tail vlist Return the tail of VLIST. That is, help with the quotation marks reports about things even if they're in namespaces you haven't imported yet ! I'm confused about the difference between help withouth and with the quotation marks In fact scheme@(guile-user)> ,a tail (guile): list-tail # (guile): make-struct/no-tail# apropos does find at least something, but scheme@(guile-user)> (help tail) Did not find any object named `tail' help with no quotation marks finds nothing ! Why is this so ? I can't fathom that ¯\_(ツ)_/¯ And I can't even remember how I discovered this behaviour I remember I was quite puzzled when I did This is hidden and arbitrary But it IS like that ! So maybe this little trick can make your sessions a bit less frustrating ! "tail" was just a silly example I was able to come up with I'd be curious to try with some of your things :-) Bye Adriano
Re: Guix Documentation Meetup
Il giorno sab, 11/12/2021 alle 05.40 +0700, Blake Shaw ha scritto: > > hiya guix, > > @cybersyn from IRC here, I recently contributed my first package, > [notcurses] > > -- > tldr: is there also room to discuss contributing -- and possibly > doing a > sizeable makeover to -- the *Guile* documentation? If so, I could > give a > short 5 - 10 minutes presentation of what I think should be done (and > would volunteer to do). > -- I'm reading this on december 21st I suppose the documentation meetup happened already and I don't know if you gave your illustration of your notes I, for one, would LOVE to hear it Yes the Guile experience is abysmal, awful, actively rejecting beginners/newcomers I've been wandering in the Guile manual, on and off, for years now and I still can't make any sense of it If I have a curiosity I still can't find my way around to such thing in the manual, most of my discoveries have been by pure chance Often, I try to re-read the same thing a few months later and I can't find it again Everytime I attempted something in Guile I've been frustrated I myself have done a so called vlog where I show how to read a file in Guile I also have a general view of packaging and distributing Guile packages that I gained by some very hard work that lasted a couple of years but I was discouraged in doing more videos Not only previous knowledge of the GNU system is a not declared hard requirement Often, previous knowledge of other things is required too For example the new exceptions system is obscure, you're required to know the one from Common Lisp in order to undertsand the one in Guile Or,as another example, I stumbled in an example made in python of a hashmap (similar to the ones very common in Clojure) and I got that Good luck with data structured in Scheme Or, the machinery for manipulating xml (and json ?) trees is discussed in academic (!!) papers that present the code in Haskell, so you need to learn Haskell in order to read that The curse of knowledge in the Guile world is tragic > I think I can personally offer a lot in terms of contributing to > documentation. While I don't serious experience w/technical writing, > prior to the pandemic I was doing my PhD in philosophy of > mathematics, > so I come from a cross-disciplinary background that involves the > often > difficult area of communicating new, formal ideas to previously > unexposed readers. I've also made a living as a new media artist > since > 2009, working mostly in C and C++ based frameworks, so I also have > some > knowledge of the difficulties "crafters" have when learning new > development systems. That's all good. I love that you noticed the problem and are offering a fresh perspective > I don't know if this is the correct forum for it, but I personally > think > the biggest documentation obstacle in Guix at the moment isn't so > much > in Guix, but instead in Guile. Absolutely, yes > I found Guix via SICP & Racket about a > year ago, and I remained a happy Racket hacker until a couple months > ago > when I decided to devote my free time to learning Guile in hopes of > graduating to a Guix sensei one day. Not only a Guix sensei but maybe a Guile sensei Why has Guile only Guix ? Why couldn't we have more nice things made in Guile ? > While I've come to love Guile, compared to my experience with Racket > its > been quite burdensome for me to get in the hang of, something I > attribute > primarily to the structure of the docs, and not due to it being in > any > way more difficult than Racket. While with Racket I was writing > useful programs in the standard #lang within my first week, with > Guile > I often find that what should be almost trivial winds up with a lot > of > time lost just trying to navigate and understand the docs. When I do > figure things out, it turns out to be no more difficult than the > equivalent > in Racket, but a lack of consistency in the path that leads there in > the > docs cause hangups, which has made trivial scripts that should take > an hour > become weekend projects. > > I know this isn't the Guile list, but when I've written on this topic > in > the IRC I've had no response, which make me think docs could be a > bit of a bikeshedding topic in the community. But as Guile is > fundamental to Guix and theres a lot of crossover btwn the > communities, > it seems like this could be a good time to raise these suggestions. Oh I love this ! > I've jotted down some notes on several concrete examples of where the > docs > diverge from stylistic consistency, as well as some light analysis as > to > why such seemingly small inconsistencies can lead to such hangups in > the learning > process. If folks would be interested in me presenting a short 5- > 10min > presentation of these notes, I'd be happy to share. yes plase !!! > Sorry for such a long-winded message! Personally, good documentation > is > absolutely essential, and I feel like I could give Guile's docs a >
Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 16.39 +0200, raingloom ha scritto: > > I think this might be the result of that survey? > https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core yes, this is it it seems here was no progress, since then
Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 18.19 +0200, Giovanni Biscuolo ha scritto: > Hi Adriano and Ricardo, thank you for your insights
Re: issue tracking in git
Il giorno ven, 13/08/2021 alle 15.18 +0200, Ricardo Wurmus ha scritto: > > Hi Adriano, > [...] > Was it perhaps Carl Dong? yes, it was Carl Dong Thank you > > I don't remember the name of such person and I am wondering if > > amy > > progress has been achieved on that front > > I don’t think there was a decision to do issue tracking in git. Do you mean a decsion by the bitcoin community ? Or by the Guix community ? > I have no idea how well it works when there’s a lot of “traffic” > in a distributed project, e.g. when there are several comments to [...] > the same issue by different people. Having merge conflicts in the > issue tracker is a headache I’d like to avoid. > I hadn't thought about this This is a potential problem that deservses exploration I think issue tracking in git could be explored starting with smaller projects first Probably Guix is too large and entrenched to be used as a test bed for this kind of explorations I'm asking about the state of the art in this regard because I feel that server based solutions are problematic even for free software oriented organizations And should the bitcoin community explore this a bit, that would be a very interesting development, in my view
issue tracking in git
Hello some time ago, in the context of an on line conference about Guix, someone suggested me that the bitcoin community had run a survey about available solutions for issue tracking in git I don't remember the name of such person and I am wondering if amy progress has been achieved on that front So if they're reading, please, chime in I looked on line and found nothing Thanks
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno mar, 01/06/2021 alle 08.24 +0200, Leo Prikler ha scritto: > > A sexp-pack would represent the most simple build instructions to > > build a package on its own. Now, of course the current guix- > > builders > > solve that too. But, what I am proposing is to split out the actual > > build step into a package definition, so as to present something > > simpler to Guix. > I don't think this would be simpler to Guix, you'd just create even > more packages, that actually aren't usable. The output could be a collection of .tar.gz files distributed through ipfs, bittorrent, syncthing or rsync Not necessarily packages in the way Guix intends them I understand there's already some work going on to reproduce tarballs in a format convenient to Guix (maybe with proper hashes and metadata ?) for when they get erased by distributors
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto: > > The output could be a collection of .tar.gz files distributed > > through > > ipfs, bittorrent, syncthing or rsync > > > > Not necessarily packages in the way Guix intends them > > > > I understand there's already some work going on to reproduce > > tarballs > > in a format convenient to Guix (maybe with proper hashes and > > metadata > > ?) for when they get erased by distributors > Well, ideally Guix would have have ipfs-fetch, bittorrent-fetch etc. > as > methods or fallbacks, but this doesn't solve the problem that's posed > here. You can't just pull the complete source closure of e.g. > Fractal > over the ether and pretend it's just one package. Probably the Fractal package will depend on some others, so it's gonna be a collection 路️ Doesn't that happen already for traditional tarballs ? > We already drop all > vendored dependencies from tarballs, that aren't created by Rust et > al., this does the exact opposite. I'm not sure I understand This does the opposite ? How so ?
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno mar, 01/06/2021 alle 13.03 +0200, Leo Prikler ha scritto: > Am Dienstag, den 01.06.2021, 12:52 +0200 schrieb Adriano Peluso: > > Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto: > > > > The output could be a collection of .tar.gz files distributed > > > > through > > > > ipfs, bittorrent, syncthing or rsync > > > > > > > > Not necessarily packages in the way Guix intends them > > > > > > > > I understand there's already some work going on to reproduce > > > > tarballs > > > > in a format convenient to Guix (maybe with proper hashes and > > > > metadata > > > > ?) for when they get erased by distributors > > > Well, ideally Guix would have have ipfs-fetch, bittorrent-fetch > > > etc. > > > as > > > methods or fallbacks, but this doesn't solve the problem that's > > > posed > > > here. You can't just pull the complete source closure of e.g. > > > Fractal > > > over the ether and pretend it's just one package. > > > > Probably the Fractal package will depend on some others, so it's > > gonna be a collection 路️ > > > > Doesn't that happen already for traditional tarballs ? > We don't stuff tarball collections into packages. We stuff inputs > into > packages and one input equals one tarball. > > > > We already drop all > > > vendored dependencies from tarballs, that aren't created by Rust > > > et > > > al., this does the exact opposite. > > > > I'm not sure I understand > > > > This does the opposite ? > > > > How so ? > Let's assume we form this sexp-pack and use it as input to some > package. What happens? we wouldn't use a sexp-pack as an input to a guix package in the same way as, as you noticed, we don't feed tarballs as inputs to guix packages A Guix package doesn't depend on some tarballs. It depends on some other Guix packages In the same way, a Guix package wouldn't depend on a sexp-pack. You can think of sexp-pack as an alternative format to tarball With, maybe, some more metadata For example, a sexp-pack could contain a hash of itself and hashes of other _sexp-packs_ it depends on Similarly to how, for example, python packages on pypi express dependecies on other packages in pypi The difference is that, as far as I understand, python packages (those in pypi, not those in Guix) express dependencies in a somewhat loose way Guix packages are stricter sexp-packs could be stricter too, bringing part of the data reconciliation outside of Guix A Guix importer could recursively import sexp-packs the same way the python importer... I'm assuming that a Rust package can be built in a sane way, with dependencies properly sorted out. I know that's possible for javascript packages, I'm not sure about Rust Such a data/packages collection could be used by mainstream linux distributions too, as far as I understand 路️
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Il giorno lun, 31/05/2021 alle 19.47 +0200, Pjotr Prins ha scritto: > On Sun, May 30, 2021 at 09:17:20PM +0200, Konrad Hinsen wrote: > > How about pushing all the other package manager towards producing > > sexp-packs, and helping them to get there? > > I have a feeling they won't be that interested ;). > > My thoughts are that every software package simply consists of files > that need to be compiled (if not interpreted) and be copied in place. > > As Guix takes care of the first and the last - the issue centers > around building. The idea is to dress down these language specific > builders, such as cargo, so you don't have all the included > complexity. > > A sexp-pack would represent the most simple build instructions to > build a package on its own. Now, of course the current guix-builders > solve that too. But, what I am proposing is to split out the actual > build step into a package definition, so as to present something > simpler to Guix. > > I found a cargo -> ninja converter. It is that kind of idea. Guix > would use ninja with rustc instead of cargo. A stripped down cargo > could potentially work too - but cargo is a complex beast. > > A simplified build step would make it easier to troubleshoot these > packages. > > See what I mean? You mean to break the chain introducing an intermediate step With intermediate step, I mean a new kind of entity with its own format I like the idea Many times, breaking long chains makes them more understandable to me It's the old idea of composability, if you want It's like refactoring a huge procedure in several smaller ones It also resembles a sort of ETL process or some sort of "data science" task of "massaging" data for some later analisys phase In a way, doing this would in itself push language communities to think about their approach (of releasing blobs) I doubt they would start such an initiative themselves, they wouldn't have begun releasing blobs in the first place
Re: blog post about shepher user services
Il giorno sab, 22/05/2021 alle 15.49 +0200, Leo Prikler ha scritto: > Hi, > > the blog post you've linked > > https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/ > seems to neither contain mentions of XDG_CONFIG_DIR, nor mcron. > > Did you mean > https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/ > instead? yes, I pasted the wrong one, sorry > > FWIW, $XDG_CONFIG_DIR should be $XDG_CONFIG_HOME, I myself always mix > those up as well. Good to know > As far as mcron integration is concerned, it doesn't > look as though this has been done yet and I think work remains to be > done to have mcron running "as a part of shepherd" rather than as its > own daemon. You can right now already run regular cron-jobs through > mcron just how people did before systemd was a thing. You just need > to > make sure you launch mcron as a user service if you want to go with > this particular configuration style, otherwise mcron as a system > service ought to suffice as well. > > Regards, > Leo > Ok, thanks
blog post about shepher user services
There's this blog post: https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/ I have 2 observations about it 1) it mentions a XDG_CONFIG_DIR environment variable. But on my Ubuntu desktop, I find a XDG_CONFIG_DIRS (note the final S) variable. This could be confusing to someone not knowing well their way around. Was this a simple slip ? Or is there any more specific reason for this missing S ? 2) in the end it announces a second post about integrationg Shepherd with mcron to come up with something that could substitute systemd's timer funtionality. It would be interesting to read the second blog post
Gnome Boxes
Gnome Boxes is GUI app that manages virtual machines and OSs images to run in them It's a sort of Qemu for the rest of us. It offers a menu with images of OSs to download and run There are several versions of NixOs, among many others There's a recipe for Guix System by Julien Lepiller, it's here https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/guix.gnu.org/guix-1.1.xml.in In their irc channel, the Boxes people infornmed me that they filter out images that have no download url, as it seems to be the case with this recipe In fact, as you can see, the download url is commented out (on line 15) Why is this ? Was there a specific problem with the download url ? It's be nice if I could pach this and have Guix System in the Gnome Boxes menu Thanks
