Re: How did you handle making a GNU/Linux distribution?
On 9/12/21 11:09 PM, Christine Lemmer-Webber wrote: Philip McGrath writes: Christine Lemmer-Webber had floated the idea at some point of trying to integrate Racket and Guile. IIRC, I think what she's had in mind was trying to make a Guile backend for Racket along the lines of the Chez Scheme backend (or the BC backend, or experimental backends like Pycket). Yes that's what I had in mind :) A few stray thoughts, all with the caveat that I haven't actually tried any of this ... there are two things that have struck me as downsides: 1. Flatt et al. say in "Rebuilding Racket on Chez Scheme (Experience Report)" (§6, p. 13) that, "If our task were to compile Racket to an existing target, then we would not have achieved such a high degree of compatibility. … we have taken the liberty of modifying Chez Scheme to make it an easier target for Racket." https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf Presumably a Racket-on-Guile project would face the same trade-off, where modifications to Guild, if Racket CS is a guide, could require hard work over many years, and lesser compatibility would make the result less useful. At one point when I spoke to Matthew, he was very optimistic that the work on porting on top of Chez would open Racket to running on top of many other backends. But yes... since there have been so many "custom" modifications to Chez, it's easier to be skeptical about that these days... I think there a few possible senses for what "running on top of many other backends" could mean. My impression overall is that it has gotten easier, but may not necessarily be easy. The most clearly demonstrated is that it seems to be easier to port Chez Scheme to new architectures than to port Racket BC's VM. Racket CS supports the Apple M1 chip natively (and hopefully will support the Linux kernel on the M1 when that stabilizes), which Racket BC does not. Racket CS also fully supports some platforms (ARM in general, IIRC) on which Racket BC lacks support for futures, places, or the JIT. The most promising route to Racket on WASM also seems to be adding a WASM backend to the Chez Scheme compiler. (In fairness, there are also some architectures, like ppc64le, to which no one has ported Racket CS yet, for which Racket BC can offer at least some support via C.) More generally, the "linklet" abstraction[1] seems to provide a much more clear boundary between the responsibilities of a backend implementation and the common frontend than existed before Racket 7.0. For example, the backend doesn't have to deal with macro expansion or even shadowing of variables: it just need to have some way to instantiate linklets (likely with further backend-specific compilation) and to provide a whole bunch of primitives. I believe I've heard Sam Tobin-Hochstadt say that linklets have made it possible for Pycket (the experimental Racket implementation in Reticulated Python) to run most Racket code. [1]: https://docs.racket-lang.org/reference/linklets.html Another benefit of linklets is that they've defined a clear path for implementing parts of Racket in Racket itself, like the regexp implementation on Racket CS. This seems like it could help a lot with supplying that very large number of primitives. So I expect it would be entirely possible to implement a linklet-based Racket backend in Guile. I do suspect that getting production-quality performance and compatibility could be a lot of work. But my bigger concern is ... 2. As you probably know, Racket programs can't generally use Chez Scheme implemented libraries, because Chez Scheme effectively is the "unsafe" layer of the Racket VM. For example, not all Racket procedures are Chez Scheme procedures, and Racket's continuations wrap Chez Scheme's to implement delimited and composable control, threads, parameters, full continuation marks, etc. For Racket CS, this isn't a great loss (there aren't so many Chez-specific libraries, and portable libraries can run in Racket's R6RS language), but, for a hypothetical Racket-on-Guile, bidirectional interoperability would be a big attraction: imagine Guix, Shepherd, Mcron, syntax/parse, racket/contract, and more all working together. I don't think a Racket-on-Guile that worked like Racket-on-Chez would achieve the most interesting benefit (IMO) of bringing the two languages together: safe, bidirectional interoperability. Probably there are many ways to achieve that goal. In principle, one could write a Racket-on-Guile implementation where arbitrary Guile could run without breaking Racket's invariants, but I expect that would make the task even harder: presumably that's why Racket-on-Chez doesn't work that way. But if linklets are as good as an abstraction as they seem to be for compiling code in the presence of modules and macros---all of the complications of Scheme-
Re: I just got my pinephone.
October 1, 2021 6:56 PM, "Christine Lemmer-Webber" wrote: > I think the easiest step to first testing would be to install Guix > (userspace package manager) from Debian on Mobian. I've been meaning to > do that, haven't tried yet... WeirdlyI'm not certain that I want guix on my pinephone. Specifically I got my Pinephone, because I was tired of google's spyware. AND I wanted a life phone, which is a phone that is so boring to use, you put it down and go live a life instead. :) I've actually installed Mobian, removed the user "mobian" from the suoders list, and had my mom change the root password on my phone. So, my phone by design does not have firefox or tootle installed... If I installed guix system, I could re-install those annoying apps that drain my life away. It would be nice if guix system could create a user that is not allowed to install applications, or had only a whitelist of applications that he could install. That's my two cents. :) > > from there we can look at what's necessary to go full distro > > Kaelyn writes: > >> Hi Guix! >> >> I just received my pinephone this morning, so I'm going to be >> interested in bringing Guix to the pinephone as well. I hope to have >> the capacity to help with the efforts, even if it's just the >> occasional testing. >> >> Cheers, >> Kaelyn >> >> Sent with ProtonMail Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> >> On Wednesday, September 1st, 2021 at 12:39 PM, Joshua Branson >> wrote: >> >>> Hey Guix! >>> >>> I just got my phinephone. It's currently running postmarketOS (1). I >>> >>> usually work nights two nights a week 10pm-6am (EST) Sunday night and >>> >>> Monday night. If a guix developer would like ssh access to it during >>> >>> those times, then please let me know. If I should use Mobian instead >>> >>> to help port guix to it, then I would be willing to switch. >>> >>> I'd be happy to help out! Also jmp.chat (2) works really well with >>> >>> chatty. >>> >>> Thanks, >>> >>> Joshua >>> >>> 1. https://postmarketos.org/source-code >>> 2. https://jmp.chat
Re: I just got my pinephone.
I think the easiest step to first testing would be to install Guix (userspace package manager) from Debian on Mobian. I've been meaning to do that, haven't tried yet... from there we can look at what's necessary to go full distro Kaelyn writes: > Hi Guix! > > I just received my pinephone this morning, so I'm going to be > interested in bringing Guix to the pinephone as well. I hope to have > the capacity to help with the efforts, even if it's just the > occasional testing. > > Cheers, > Kaelyn > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, September 1st, 2021 at 12:39 PM, Joshua Branson > wrote: > >> Hey Guix! >> >> I just got my phinephone. It's currently running postmarketOS (1). I >> >> usually work nights two nights a week 10pm-6am (EST) Sunday night and >> >> Monday night. If a guix developer would like ssh access to it during >> >> those times, then please let me know. If I should use Mobian instead >> >> to help port guix to it, then I would be willing to switch. >> >> I'd be happy to help out! Also jmp.chat (2) works really well with >> >> chatty. >> >> Thanks, >> >> Joshua >> >> 1. https://postmarketos.org/source-code/ >> 2. https://jmp.chat
Guix Home nnn service
Hi Guix, I had originally proposed this idea to guix-home-manager but never got around to implementing it: https://framagit.org/tyreunom/guix-home-manager/-/issues/15 I'd like to pick it up again and try implementing it this time for guix home. Has anyone already written a nnn service for guix home? nnn is mostly configured through environment variables while default programs are managed by xdg: https://github.com/jarun/nnn/wiki/Usage#configuration I imagine this could compose nicely with the xdg service already provided by guix home. Any advice or ideas for implementation with guix home are much appreciated. all best, jgart 3B1D 7F19 E36B B60C 0F5B 2CA9 A52A A2B4 77B6 DD35
Guix Home redshift service
Hi Guix, I had originally proposed this idea to guix-home-manager but never got around to implementing it: https://framagit.org/tyreunom/guix-home-manager/-/issues/16 I'd like to pick it up again and try implementing it this time for guix home. Any advice or ideas for implementation with guix home are much appreciated. Has anyone already written a red shift service for guix home? Does it make more sense for this to be a shepherd service instead? I'm mostly on void linux with guix installed for my personal machines and I use Guix System for servers. all best, jgart 3B1D 7F19 E36B B60C 0F5B 2CA9 A52A A2B4 77B6 DD35
Re: core-updates-frozen: Planning for the last world rebuild
Hi Mathieu, I fixed the build. Also had to upgrade 389-ds-base to get around a linker error. Thanks for your support here! The ldap test is now run, but sadly there are some failures: https://ci.guix.gnu.org/build/928047/log/raw. Thanks for checking! It should be fine now. I didn’t run the test myself, but I ran most of the commands and found a few more hardcoded tool file names that referenced /sbin or /usr/bin. -- Ricardo
Re: I just got my pinephone.
Hi Guix! I just received my pinephone this morning, so I'm going to be interested in bringing Guix to the pinephone as well. I hope to have the capacity to help with the efforts, even if it's just the occasional testing. Cheers, Kaelyn Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, September 1st, 2021 at 12:39 PM, Joshua Branson wrote: > Hey Guix! > > I just got my phinephone. It's currently running postmarketOS (1). I > > usually work nights two nights a week 10pm-6am (EST) Sunday night and > > Monday night. If a guix developer would like ssh access to it during > > those times, then please let me know. If I should use Mobian instead > > to help port guix to it, then I would be willing to switch. > > I'd be happy to help out! Also jmp.chat (2) works really well with > > chatty. > > Thanks, > > Joshua > > 1. https://postmarketos.org/source-code/ > 2. https://jmp.chat
Re: guix weather -m etc/sources-manifest.scm and CI?
Hey! > Mathieu, could it have to do with the fact that the manifest is within > the ‘guix’ channel? Using the attached little reproducer, I get a more interesting backtrace: --8<---cut here---start->8--- Backtrace: In ice-9/boot-9.scm: 1752:10 11 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 10 (apply-smob/0 #) In ice-9/boot-9.scm: 724:2 9 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 8 (_ #(#(#))) In ice-9/boot-9.scm: 2835:4 7 (save-module-excursion _) 4380:12 6 (_) In gnu/ci.scm: 496:4 5 (cuirass-jobs _ _) In srfi/srfi-1.scm: 673:15 4 (append-map _ _ . _) 586:17 3 (map1 (list "x86_64-linux")) 586:17 2 (map1 (#https://www.brain-dump.org/projects…> …)) In gnu/ci.scm: 575:38 1 (_ #https://www.brain-dump.org/projects/abduco…>) In guix/packages.scm: 441:0 0 (%package-name-procedure #https://www.brain-du…>) guix/packages.scm:441:0: In procedure %package-name-procedure: In procedure package-name: Wrong type argument: #https://www.brain-dump.org/projects/abduco/abduco-0.6.tar.gz"; # () 7f84f252ec00> --8<---cut here---end--->8--- The issue is that (gnu ci) expects manifests of packages and not manifests of origins. Hence, the "job-name" procedure that calls "package-name" on an origin fails. We could maybe generalize the manifests->packages to support packages and origins. The package-job procedure would also need some adjustment to call origin->derivation instead of package-derivation. WDYT? Thanks, Mathieu cuirass.scm Description: Binary data
Re: core-updates-frozen: Planning for the last world rebuild
Hello Ricardo, > I fixed the build. Also had to upgrade 389-ds-base to get around a linker > error. Thanks for your support here! The ldap test is now run, but sadly there are some failures: https://ci.guix.gnu.org/build/928047/log/raw. Mathieu
