Re: Guix Documentation Meetup
Ryan Prior writes: > Absolutely. The Guile docs are unusable and make Guile a pain to work > with. I say this as an experienced lisp & scheme user with decades of > experience now in elisp, racket, and clojure. oh good, I'm glad to hear that I'm not alone! to be honest I don't think its *so* bad, but it certainly demands a the user of suffers a bit, which makes Guix in general a more difficult sell. And Guile is a truly impressive programming language; its docs are just in need of some remodeling I think. > I've found the Guile IRC channel to be polite and encouraging, but > also very self-satisfied, which makes it hard to feel heard as a Guile > hacker who's struggling. I hesitate to tackle any kind of nontrivial I first checked it out when I began learning about guix, and it seemed quite friendly. but unfortunately since I started studying Guile I haven't had any of my questions there responded to. hopefully all is ok. > problem with Guile because I have no confidence I will find tools that > save me time; I'm proficient with a half dozen other languages, > including multiple lisps, which provide much better support. So even > though I really want to learn Guile,because of Guix, Shepherd and > other cool software written in it, I'm no more likely to choose Guile > for a software project today than I was 3 years ago when I just > started learning it. As long as it doesn't stall out into bikeshedding and the community is supportive I'm dedicated to this project of working on Guile's docs while I become acquainted with its depths. As a media artist theres really a lot it offers. But like you say, it can suck up time with little return; trying to figure out certain basic things in Guile has made C feel like Python at times. Luckily, the C interface is decently documented. > > When I talk to experienced hackers in the Guile community I get the > sense they've just accepted that yeah, the only way to get anywhere is > to cold memorize the most popular ~80 SRFIs or implement everything > you need yourself. One person I talked to was like "oh yeah Guile's > great, you just have to implement your own standard library like I > did." I'd be interested to hear any anecdotes regarding whether restructuring the docs was attempted in the past, and what problems it incurred. Considering my background in academia, writing is second nature, and this has been the only thing in Guix that has appeared to me as a serious pain point, so if I'm the only one who doesn't find writing docs insufferable, I'm happy to take on that task for the time being. But again, it depends on whether the community will grant me their confidence. > I'd love to hear your talk, if you're up to present at the Guix meetup > I'll definitely come and listen. I'm also happy to do what I can to > help drive Guile adoption, create a great learning experience around > it, and finally start to build the language community that Guile is > lacking. Awesome! Me too! It's seriously an incredible language -- it's just lacking a consistent, ergonomic presentation atm. But even without that, it's the fastest-booting lisp I've tried, and already thats enough to keep me from crawling back to Racket (which might boot fast now with CS, but I haven't checked in lately) As it currently stands, its better to ditch the docs and just browse the code base. And while for some that might be like reading email, for the vast majority thats demanding some serious overhead from users who are likely to pick up Guile for their personal, off-hours, creative work. It won't be a talk, just a 5-10min presentation of some notes where I'll try to provide a light analysis of a few problems, along with how I would go about fixing them, and then if all agree I'll get to work on it. Thanks for the encouragement! ez, b -- “In girum imus nocte et consumimur igni”
Organising Guix Days
Hi Guix! I think it's time to start organising the Guix Days, traditionally held around Fosdem. During our guix-europe assembly, we discussed some options and everyone agreed they wanted a two-day event, online just as Fosdem. I attached a proposed blog post that we should put on the website as soon as we agree on the first details. I suggest that we have these days right after Fosdem, Monday and Tuesday. This should give us just a few more days to prepare, as I think we're starting pretty late already. If you prefer to have them before fosdem, I can change the blog post of course. As for how it'll be organised. I propose to do something similar to what we need in November 2020. I'd love to get some talks from people outside the usual maintainers and commiters, to have an overview of the diversity of people and usage around Guix. Last year, we asked speakers to prepare a video in advance, and they would only have an extended Q/discussion session. I think this year we should have the same process, but ask for a short (3-5 minutes) talk at the start of the session to refresh our minds on the main points of the presentation before discussions start. Of course, one of our co-maintainers should have a session on a retrospective (what happened last year in Guix) and lead discussions on the future of Guix. We should reserve plenty of time for this session. In addition, I'd like to invite people to submit discussion ideas and be free of having to make a presentation if they prefer (BoF). I'd also like to "innovate" and have a session of lightning talks, where people would only have to give a short, live presentation on any topic related to Guix (I'm thinking short presentation of a project where you use guix, of something you're doing with guix, how you found guix, a story of your first days with guix, ...). We can also replace that with a presentation round at the beginning of the conference if we don't have enough lightning talks. The Guix Days have never been a "real" conference, and always had a lot of room for discussions that start on the spot. I'd like to emulate this by keeping a lot of time out of the talk sessions to discuss whatever comes up naturally during our discussions. Also, we need to secure a BBB instance :) WDYT? title: Announcing the second online Guix Days Conference date: 2021-12-10 00:00 author: Guix Hackers slug: online-guix-days-2022-announce-1 tags: Conference, Community --- The Guix hackers are very happy to announce the second online Guix Days Conference on **7 & 8 February 2022**. This conference is open to everyone and will be held entirely online. Want to speak? Submit your proposal! Important dates: 1. **January 21**: Deadline for talks proposal. 1. **January 28**: Deadline for releasing your pre-recorded talks. 1. **February 2**: Release of the schedule. 1. **February 7**: Conference day! 1. **February 8**: Conference day!  The agenda of these two days is: - pre-recorded talks with live question and answer sessions - birds of a feather (BoF) sessions - lightning round talks, if possible - retrospective and future of Guix - hack together Talks will be released **before** the conference day, **watch them as soon as possible**! And **no registration fee**. # Until January 21: talks proposal Propose your talks by sending them to `guix-d...@gnu.org`. Feel free to drop in `#guix` on irc.freenode.net to discuss what you would like to talk about before submitting. :) You can choose one of the following formats: - Standard talk. 15-45 minutes pre-recorded presentation and a 5 minutes lightning talk. The 5-minute presentation will be live, to refresh our minds, followed by a 30 minutes live Q - BoF (birds of a feather, for a session with a small group who wants to talk about a specific topic) with no presentation. You may prepare something live to spark conversations. - Lightning talk with a 5 minutes live presentation In addition to the format you would like to choose, please describe your session with 10 lines or more (for lightning talks, at least 1 sentence). Once you have sent your proposal, you will be notified in the coming days whether your talk be part of the Guix Day. Submit earlier to get more time to prepare your session! Even for live presentation, please prepare a back-up pre-recorded talk, so we can play it if you cannot attend or have a technical problem during the Guix days. The deadline for short presentations (5 minutes) is February 4. We welcome all kinds of topics from the community, especially your own experience with Guix, your cool projects that involve Guix in some way, infrastructure around guix (translations, continuous integration, ...), and any subject you feel should be discussed during the conference. Have a look at the topics from [the last conference](/blog/2020/online-guix-day-announce-1/) for ideas, but don't hesitate to innovate in your
Re: Guix Documentation Meetup
‐‐‐ Original Message ‐‐‐ On Friday, December 10th, 2021 at 10:40 PM, Blake Shaw wrote: > tldr: is there also room to discuss contributing -- and possibly doing a > sizeable makeover to -- the Guile documentation? Absolutely. The Guile docs are unusable and make Guile a pain to work with. I say this as an experienced lisp & scheme user with decades of experience now in elisp, racket, and clojure. After bouncing off of guile projects for years, last November I decided to do Advent of Code in Guile to force myself to finally get the hang of it & get productive. I gave up after a week, every task was unpleasant and I was reinventing basic language features because I couldn't find out where/if they were implemented in some obscure SRFI or ice-9 module. Like you wrote, the code I'd finally end up was fine, the language itself seems nice, but it's just plain inaccessible. I've found the Guile IRC channel to be polite and encouraging, but also very self-satisfied, which makes it hard to feel heard as a Guile hacker who's struggling. I hesitate to tackle any kind of nontrivial problem with Guile because I have no confidence I will find tools that save me time; I'm proficient with a half dozen other languages, including multiple lisps, which provide much better support. So even though I really want to learn Guile,because of Guix, Shepherd and other cool software written in it, I'm no more likely to choose Guile for a software project today than I was 3 years ago when I just started learning it. When I talk to experienced hackers in the Guile community I get the sense they've just accepted that yeah, the only way to get anywhere is to cold memorize the most popular ~80 SRFIs or implement everything you need yourself. One person I talked to was like "oh yeah Guile's great, you just have to implement your own standard library like I did." I'd love to hear your talk, if you're up to present at the Guix meetup I'll definitely come and listen. I'm also happy to do what I can to help drive Guile adoption, create a great learning experience around it, and finally start to build the language community that Guile is lacking. Cheers, Ryan
Re: Guix Documentation Meetup
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 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. 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. 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. 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. 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. Sorry for such a long-winded message! Personally, good documentation is absolutely essential, and I feel like I could give Guile's docs a serious makeover while I'm still at the early stage of my plunge and have a perspective on the psychology of not-understanding -- something that won't last long! ez, blake -- “In girum imus nocte et consumimur igni”
Re: cl-gsll fails to load
Could you try the attached patches and see if things work for you with
a command such as:
--8<---cut here---start->8---
guix shell -C sbcl sbcl-gsll gcc-toolchain -- ...
--8<---cut here---end--->8---
There may be a way to patch our CFFI package to fix the links to all the
GCC toolchain things, which would allow us to remove gcc-toolchain in
the command above, but it will probably not be super easy.
From 7613cc6c054bfc5dc66f657aeb2987a22c342b80 Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant
Date: Fri, 10 Dec 2021 15:56:07 +0100
Subject: [PATCH 1/2] gnu: cl-cffi: Fix some paths.
CFFI can require pkg-config and a GCC toolchain at runtime.
This patch improves the use of the source cl-cffi package from a REPL, but
it's not perfect and using cl-cffi in an environment without explicitly adding
gcc-toolchain to it might not work.
* gnu/packages/lisp-xyz.scm (sbcl-cffi)[native-inputs]: Move pkg-config to ...
[inputs]: .. here.
[arguments]: Update 'fix-paths' phase.
---
gnu/packages/lisp-xyz.scm | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/gnu/packages/lisp-xyz.scm b/gnu/packages/lisp-xyz.scm
index 635f8e48cb..9f06be28ee 100644
--- a/gnu/packages/lisp-xyz.scm
+++ b/gnu/packages/lisp-xyz.scm
@@ -2782,10 +2782,10 @@ (define-public sbcl-cffi
`(("alexandria" ,sbcl-alexandria)
("babel" ,sbcl-babel)
("libffi" ,libffi)
+ ("pkg-config" ,pkg-config)
("trivial-features" ,sbcl-trivial-features)))
(native-inputs
`(("bordeaux-threads" ,sbcl-bordeaux-threads)
- ("pkg-config" ,pkg-config)
("rt" ,sbcl-rt)))
(arguments
'(#:phases
@@ -2799,10 +2799,25 @@ (define-public sbcl-cffi
(add-after 'unpack 'fix-paths
(lambda* (#:key inputs #:allow-other-keys)
(substitute* "libffi/libffi.lisp"
- (("libffi.so.7" all) (string-append
- (assoc-ref inputs "libffi")
- "/lib/" all)))
+ (("libffi.so.7" all)
+(string-append (assoc-ref inputs "libffi") "/lib/" all)))
+ (substitute* "libffi/libffi-types.lisp"
+ (("\\(in-package #:cffi\\)" all)
+(string-append all
+ "\n #+linux (cc-flags \"-I"
+ (assoc-ref inputs "libffi")
+ "/include/\")")))
+ (substitute* "grovel/grovel.lisp"
+ (("\"pkg-config\"")
+(string-append "\"" (assoc-ref inputs "pkg-config")
+ "/bin/pkg-config\"")))
+ ;; Force use of (default-toolchain-parameters) which the fixed
+ ;; path to gcc.
(substitute* "toolchain/c-toolchain.lisp"
+ (("\\(clisp-toolchain-parameters\\)") "nil")
+ (("\\(ecl-toolchain-parameters\\)") "nil")
+ (("\\(mkcl-toolchain-parameters\\)") "nil")
+ (("\\(sbcl-toolchain-parameters\\)") "nil")
(("\"cc\"") (format #f "~S" (which "gcc"))
(add-after 'build 'install-headers
(lambda* (#:key outputs #:allow-other-keys)
--
2.34.0
From 8bdf4c2dac67a9f5baf0d0facef7bd8bef120e63 Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant
Date: Fri, 10 Dec 2021 16:22:26 +0100
Subject: [PATCH 2/2] gnu: cl-gsll: Fix more paths.
* gnu/packages/lisp-xyz.scm (sbcl-gsll)[arguments]: Update 'fix-cffi-paths'
phase.
---
gnu/packages/lisp-xyz.scm | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/lisp-xyz.scm b/gnu/packages/lisp-xyz.scm
index 9f06be28ee..58d4b889f6 100644
--- a/gnu/packages/lisp-xyz.scm
+++ b/gnu/packages/lisp-xyz.scm
@@ -7989,11 +7989,28 @@ (define-public sbcl-gsll
(substitute* "init/init.lisp"
(("libgslcblas.so" all)
(string-append
- (assoc-ref inputs "gsl") "/lib/" all)))
- (substitute* "init/init.lisp"
+ (assoc-ref inputs "gsl") "/lib/" all))
(("libgsl.so" all)
(string-append
- (assoc-ref inputs "gsl") "/lib/" all
+ (assoc-ref inputs "gsl") "/lib/" all)))
+ (substitute* '("calculus/monte-carlo-structs.lisp"
+ "data/array-structs.lisp"
+ "eigensystems/eigen-struct.lisp"
+ "init/callback-struct.lisp"
+ "init/libgsl-unix.lisp"
+ "ordinary-differential-equations/ode-struct.lisp"
+ "physical-constants/cgsm.lisp"
+ "physical-constants/mksa.lisp"
+ "physical-constants/num.lisp"
+
Re: cl-gsll fails to load
Foo Chuan Wei skribis:
> On 2021-12-07 12:27 +, Guillaume Le Vaillant wrote:
>> I think the problem comes from the fact that the build system for
>> cl-xxx packages doesn't use the custom phases added to some sbcl-xxx
>> packages (like the 'fix-cffi-paths' phase of sbcl-gsll). Instead a fixed
>> set of phases is used (see '%standard-phases/source' from
>> "guix/build/asdf-build-system.scm", used in the
>> 'sbcl-package->cl-source-package' function from
>> "guix/build-system/asdf.scm").
>
> Are you sure about this? From my observations, the cl-xxx packages do
> use the custom phases added to the sbcl-xxx packages. When I install
> cl-gsll and look into its store directory
> (~/.guix-profile/share/common-lisp/source/cl-gsll/), I do see the
> effect of sbcl-gsll's custom phase ("fix-cffi-paths").
Indeed, it looks like custom phases are taken into considerations now (I
don't remember when this got fixed).
However although cl-cffi has a custom phase to fix the path to gcc, it
still tries to run "gcc" instead of "/gnu/store.../gcc" when compiling
cl-gsll from a REPL. I'll try to find where this bare "gcc" comes from...
signature.asc
Description: PGP signature
bluetooth-service: addition config vaules
Hello, I hope this is the proper mailing list to post to, if not please redirect me. I'd like to propose extending the possible config values for the bluetooth-configuration. At the moment, only `AutoEnable' is available. But there are more, specifially: main.conf: --8<---cut here---start->8--- [General] # Default adapter name # Defaults to 'BlueZ X.YZ' Name = BlueZ # Automatically connect both A2DP and HFP/HSP profiles for incoming # connections. Some headsets that support both profiles will only connect the # other one automatically so the default setting of true is usually a good # idea. AutoConnect=true # Enables Multi Profile Specification support. This allows to specify if # system supports only Multiple Profiles Single Device (MPSD) configuration # or both Multiple Profiles Single Device (MPSD) and Multiple Profiles Multiple # Devices (MPMD) configurations. # Possible values: "off", "single", "multiple" MultiProfile = multiple --8<---cut here---end--->8--- These are the ones I find particularly important and should be make available to the service. But there are more: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf ideally, we would add all of them. If someone can explain to me how to test and submit it myself, I'll do it. But I head that it's not as easy as submitting a patch for a package. I believe a seasoned contributer could submit something way faster. In any case, Best regards / Mit freundlichen Grüßen, Demis Balbach signature.asc Description: PGP signature
