Re: Python 2 end-of-life?
Hi Hartmut, > I assume many of these package can be updated. (Indeed I just updated > pdfposter, which I'm maintaining.) Great. That's the kind of response I was hoping for! > bypthon2 and ptpython2 are REPLs for python2 - bypthon and ptpython are > the resp. packages for python3. There are a few other packages in my list that are part of the Python 2 universe (my own nmoldyn for example), but I see no easy way to detect them in an analysis of the package graph. Perhaps I could filter out packages whose dependencies are *all* from the Python 2 universe. > Regarding the qt packages: I updated them on staging, but still have > Python 2 in there. I will take care of these. Excellent. Lots of other packages depend on those, so that will be a big step towards Python 2 independence. LLVM/clang looks like another important building block to liberate from Python 2. I hope someone can take a look at that. Cheers, Konrad.
Re: [BLOG] rust blog post
On Tue, Nov 26, 2019 at 04:19:01PM -0800, Bengt Richter wrote: > Hi Pierre, and apologies to Efraim... > > On +2019-11-26 14:01:10 +0100, Pierre Neidhardt wrote: > > Bengt Richter writes: > > > > > be a binary. Its... both? Javascript libraries leave distro > > > > Typo: "It's". > > It's one of the ones I have a hard time with. When I remember I'm great with it. > > I noticed that too, but it's Efraim's typo, > as is the entire text: I merely reformatted Efraim's post > into a sort of rfc-style, i.e., Left-and-Right-justified. Thanks > > So, credit to Efraim for the: > > > Interesting read, thanks for sharing. > > Do you intend to publish it on Guix' blog? If so, I think the tone > > might come across as a little bit too "rantish", maybe make it a little > > more neutral / balanced. Definitely wasn't aiming for rantish, I'll see what I can do about making it better. It was more of a stream-of-consciousness typing and I figured I could go back and rework it later. > > > > I'd also elaborate the intro / conclusion to make the context a bit > > clearer and maybe explain what you think should be done. Sounds like a good idea. > > > > Cheers! > > > > -- > > Pierre Neidhardt > > https://ambrevar.xyz/ > > Efraim, thanks for your work -- I didn't mean to hijack it, honest :) > Sorry for not making it clear that I was just reformatting your post ;-/ > > Ah, perhaps Pierre merely clicked reply-all and he really was thanking you, > Efraim, > and it just appeared to be directed toward me because of the "> Bengt Richter > writes:" > heading? Likely. I normally hit reply-all for mailing list posts -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Reworking the cookbook layout
No strong opinion here, it seems to be a good idea. My only current itch with the cookbook is that it might have too deep a hierarchy. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Reworking the cookbook layout
Hi, Thank you to open the discussion about the Cookbook. The first thing is: what is the purpose of the Cookbook? I mean I am not sure we all define the same object with the same goal. Currently, it is all what cannot be included in the Reference Manual. So do we need to organize all this material with an strong hierarchy? A cookbook is a collection of recipes and it not generally well organized. I am mean the one of my Grand-Mother is not. :-) On Tue, 26 Nov 2019 at 23:12, Julien Lepiller wrote: > Today I have been reading https://www.divio.com/blog/documentation/ > which makes some good points on how to write good documentation. They > suggest to divide documentation into four categories, depending on > their purpose: I was reading similar elsewhere with the idea to prepare what we could propose for the next round of the Google Seasons of Doc [1] (if any). [1] https://developers.google.com/season-of-docs > - tutorials, written for newcomers. They should be to the point and > guide a new user through every step of using the new system. > - how-tos. They should be "goal-oriented" and allow > a user who knows what they want to do, to learn how to do it. > - explanations. They are more theoretical and should give more > knowledge on how it all works. > - reference. It should contain all the technical details of the code. To me this structure is nice but too strong. I do not see what is the difference between "how-tos" and "tutorials". And for example, the blog "Packaging" entry is in the same time: - a tutorial because it is written for newcomers - "goal-oriented" because it explains "how to package" - explicative because it provides how it all works (scheme explanations, etc.) So I feel an arbitrary boundary. Then it is some work to revamp the blog entries and we should reduce the workload because when we are revamping we are not writing other materials. > Following these principles, I propose the attached patch, that changes > the layout a bit. Instead of grouping articles by topic, I suggest > grouping them by one of the first three categories above (the guix > manual is the reference, and it's excellent, so we don't need a > reference documentation in the cookbook). I propose to group in 2 categories: - How To / Tutorial - Blog post And the both can overlap. I mean it is not an issue that a blog post entry explains Scheme for the beginners and in the time there is an entry "My first steps with Scheme" in the "How To/Tutorial". The issue is that the Blog part could not be synchronise. But let warn the reader and to me it is not an issue. The Blog part can be amended when something wrong is reported. Concerning deeper explanations (for example relationship between Docker and Guix), I consider that as a "tutorial": a method of transferring knowledge (wikipedia) or the tutor teaches/discusses particular point (Collins dic.). What do you think? All the best, simon
Re: Packaging Jami progress
Hi Jan, On Tue, 26 Nov 2019 at 20:43, Jan wrote: > P.S. I apply the patches using "patch" command, right? What do you use? If you use Emacs, you can open Debbugs with: C-u M-x debbugs-gnu then RET guix-patches n y Then M-x debbugs-gnu-bugs RET 38211 RET So far so good. Select the patch set. Then M-x shell-command-on-region RET cd /path/to/your/guix/clone && git am RET Or you can select the patch set then press the two letters O b and it will download the patches. Then inside your favorite terminal session: git am < /path/to/patches/* If you do not use Emacs, you can download the series on the web page (mbox) but I have never done without Emacs. ;-) Note that the series will not apply with a fresh "git pull" because there a conflict with the file cpp.scm. You need to rebase, as I asked to Pierre. ;-) Hope that helps. All the best, simon
Re: Reworking the cookbook layout
Le 27 novembre 2019 12:08:00 GMT+01:00, zimoun a écrit : >Hi, > >Thank you to open the discussion about the Cookbook. > >The first thing is: what is the purpose of the Cookbook? I mean I am >not sure we all define the same object with the same goal. > >Currently, it is all what cannot be included in the Reference Manual. >So do we need to organize all this material with an strong hierarchy? >A cookbook is a collection of recipes and it not generally well >organized. I am mean the one of my Grand-Mother is not. :-) So, following the structure I propose, the cookbook would only contain tutorials and how-tos. Then we would need another place for deeper explanations. > > >On Tue, 26 Nov 2019 at 23:12, Julien Lepiller >wrote: > >> Today I have been reading https://www.divio.com/blog/documentation/ >> which makes some good points on how to write good documentation. They >> suggest to divide documentation into four categories, depending on >> their purpose: > >I was reading similar elsewhere with the idea to prepare what we could >propose for the next round of the Google Seasons of Doc [1] (if any). > >[1] https://developers.google.com/season-of-docs > > >> - tutorials, written for newcomers. They should be to the point and >> guide a new user through every step of using the new system. >> - how-tos. They should be "goal-oriented" and allow >> a user who knows what they want to do, to learn how to do it. >> - explanations. They are more theoretical and should give more >> knowledge on how it all works. >> - reference. It should contain all the technical details of the code. > >To me this structure is nice but too strong. I do not see what is the >difference between "how-tos" and "tutorials". A tutorial does not have a particular goal other than giving a tour of the tools and main functionalities. So it's more a what-is than a how-to. Not how to program in scheme, but what is it like to program in scheme. > >And for example, the blog "Packaging" entry is in the same time: > > - a tutorial because it is written for newcomers > - "goal-oriented" because it explains "how to package" >- explicative because it provides how it all works (scheme >explanations, etc.) > >So I feel an arbitrary boundary. I think it's not too nice to mix all of this together: I'm already a packager, so I don't need a tutorial on packaging or scheme. I could still learn something, but I'll skip most of this document. I think it's best to split it for different readers: a tutorial, how-tos for some difficult points that can arrise and explanations of the packaging architecture for instance. > >Then it is some work to revamp the blog entries and we should reduce >the workload because when we are revamping we are not writing other >materials. Right, but we're not writing a lot either way… I think a clearer editorial policy will help us see what's needed and bring in more contributions. > > >> Following these principles, I propose the attached patch, that >changes >> the layout a bit. Instead of grouping articles by topic, I suggest >> grouping them by one of the first three categories above (the guix >> manual is the reference, and it's excellent, so we don't need a >> reference documentation in the cookbook). > >I propose to group in 2 categories: > > - How To / Tutorial > - Blog post > >And the both can overlap. I mean it is not an issue that a blog post >entry explains Scheme for the beginners and in the time there is an >entry "My first steps with Scheme" in the "How To/Tutorial". > >The issue is that the Blog part could not be synchronise. But let warn >the reader and to me it is not an issue. The Blog part can be amended >when something wrong is reported. > >Concerning deeper explanations (for example relationship between >Docker and Guix), I consider that as a "tutorial": a method of >transferring knowledge (wikipedia) or the tutor teaches/discusses >particular point (Collins dic.). Maybe the name "tutorial" is not good enough to express what I mean. It's supposed to give you some precise steps you have to follow to get more familiar with a tool when you discover it for the first time. Discussing docker doesn't give you any practice with Guix, only theoretical knowledge. It's for a different audience. > > >What do you think? > > >All the best, >simon
Re: Moving Lisp libraries to lisp-xyz.scm?
Hi, Concerning the 'wip-lisp-xyz' branch, there are some Lisp libraries as inputs for some packages in 'machine-learning.scm' and 'web-browsers.scm'. So I guess the '(gnu packages lisp-xyz)' module should replace (or be added next to) the '(gnu packages lisp)' module in these files.
Re: Reworking the cookbook layout
On Wed, 27 Nov 2019 05:21:22 -0500 Pierre Neidhardt wrote > No strong opinion here, it seems to be a good idea. > > My only current itch with the cookbook is that it might have too deep a > hierarchy. Personally, I prefer to put the @menu before the @contents because the former works as an overview and the latter is intimidating. I don't know why it is done the other way around in many GNU manuals, though.
Re: guix gc doesn't seem to clean old guix revision
Hi, On Tue, 26 Nov 2019 at 20:26, zimoun wrote: > > guix pull > Migrating profile generations to '/var/guix/profiles/default'... > --8<---cut here---end--->8--- It is similar to Bug#36785 [1]. As said, it is not a bug of "guix pull" but a bug of the configuration. Adding the root user to your Dockerfile should fix the issue you encounter. Hope that helps. simon [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36785
Recent $EMACSLOADPATH changes broke my setup: Bug or Feature?
Hey Guix, I've already asked about this on IRC, but since the people responsible for the changes didn't seem to be present I'll ask here too. I use EXWM so I've installed ‘emacs’ and ‘emacs-exwm’ in my system profile. Additionally I've installed Emacs packages (‘emacs-org’, ‘emacs-pdf-tools’, ‘emacs-emms’, etc.) in my user profile. Since the changes to the way Emacs packages are handled this no longer works, i.e. Emacs no longer knows about the packages installed in my user profile. I can work around it by installing ‘emacs’ to my user profile. But it doesn't make much sense to me that I have to install ‘emacs’ “twice” just so an environment variable is set. Is this an intended consequence of the recent changes or should this be considered a bug? Regards, Diego
Re: Reworking the cookbook layout
I break the usual rules of reply. Hope that will be ok. :-) On Wed, 27 Nov 2019 at 13:14, Julien Lepiller wrote: > Le 27 novembre 2019 12:08:00 GMT+01:00, zimoun a > écrit : > >On Tue, 26 Nov 2019 at 23:12, Julien Lepiller > >The first thing is: what is the purpose of the Cookbook? I mean I am > >not sure we all define the same object with the same goal. > > > >Currently, it is all what cannot be included in the Reference Manual. > >So do we need to organize all this material with an strong hierarchy? > >A cookbook is a collection of recipes and it not generally well > >organized. I am mean the one of my Grand-Mother is not. :-) > > So, following the structure I propose, the cookbook would only contain > tutorials and how-tos. Then we would need another place for deeper > explanations. [...] > >Then it is some work to revamp the blog entries and we should reduce > >the workload because when we are revamping we are not writing other > >materials. > > [...] I think a clearer editorial policy will help us see what's needed and > bring in more contributions. I agree that a clearer editorial policy will help us. It is what I am trying to point too. :-) However, I disagree on the structure you propose because I find it too strong, with too much boundary. > >To me this structure is nice but too strong. I do not see what is the > >difference between "how-tos" and "tutorials". > > A tutorial does not have a particular goal other than giving a tour of the > tools and main functionalities. So it's more a what-is than a how-to. Not how > to program in scheme, but what is it like to program in scheme. To me, it is too arbitrary. Non-related example, but maybe it underlines my point. Recently, I discovered that we can generate Docker images on foreign distro using "guix system docker-image". But because of the structure, I have never carefully read the section "System Configuration". I have always thought that this section was about "Guix System" and I am not currently using it. Well, I am not saying that the Reference Manual is doomed; in this case, I am too lazy to correctly search. And for sure, we have to put somewhere somestuff. My point is: what naturally makes sense to you does not necessary make sense to me, and vice-versa. And decide if this or that belongs to that or this is often arbitrary. That's why I think the structure needs only 2 levels and a good index. > >And for example, the blog "Packaging" entry is in the same time: > > > > - a tutorial because it is written for newcomers > > - "goal-oriented" because it explains "how to package" > >- explicative because it provides how it all works (scheme > >explanations, etc.) > > > >So I feel an arbitrary boundary. > > I think it's not too nice to mix all of this together: I'm already a > packager, so I don't need a tutorial on packaging or scheme. I could still > learn something, but I'll skip most of this document. I think it's best to > split it for different readers: a tutorial, how-tos for some difficult points > that can arrise and explanations of the packaging architecture for instance. In my (real) cookbook, I have 2 different recipes of the same meal (say galette [sarrasin] ;-)). And they are not written on pages close to each selfes but contrary one is on the beginning of the cookbook, the other at the end. One comes from a friend -- student time. One comes from a guest -- couch surfing or related. Now, I could write my own recipe, kind of adaptation of the two previous ones. However, my sister find easier the first one and my dad the last one. See what I mean? :-) It depends on the flavour, how you read, etc. Well, we disagree on what should be the Cookbook because it lacks a clear editorial policy. ;-) Are not we trying to define one right now? :-) To me, the cookbook is a collection of recipes. And different recipes can overlap. To me, a recipe is a story about a topic; the same explanations can be detailed twice if they are important to the story. And because they are worded differently, Alice will prefer the story 1 and Bob the 2. Some story can be short, other lengthy. One key point is a good index: an index where a "concept" that points to several entries. > > Right, but we're not writing a lot either way… Yes! I agree. Because 1. it is relatively new 2. it is hard to know what is the editorial policy (aim of the cookbook) so 3. the blog post has been revamped. For example, I have a draft (needs a lot of polishing) about "My first steps to contribute" and I do not know what to do with. I am happy that you have opened the discussion. And I think that writing a recipe should be a good way to attract new contributors. Cheers, simon
Re: Python 2 end-of-life?
Hi, On Tue, 26 Nov 2019 at 22:52, Bengt Richter wrote: > egrep -oh '^[^@;]+' py2eol.txt|sort|uniq -c|sort -h|tail > --8<---cut here---start->8--- > 1 zziplib > 2 ffmpeg > 2 ghc > 2 openimageio > 3 bedtools > 5 mozjs > 8 clang > 8 clang-runtime > 8 llvm > 18 rust > --8<---cut here---end--->8--- > > IOW, a bunch just differ by version -- I wonder how many of the > packages that drew in old versions could run fine with respective > latest versions of what they are dependent on? For example, considering rust, it is about the bootstrappability. See [1]. [1] http://guix.gnu.org/blog/2018/bootstrapping-rust/ I am interesting to know about clang/clang-runtime/llvm. Do we support 8 versions? Or version n-1 is useful to build version n? > It would be really interesting if you could tweak your py2-dependent-package > lister to show for each how many lines of py2 code are causing the py2 > dependency! It is really hard -- nor impossible. And I am not convinced that the tough work will pay off. > It would be a shame if half a dozen lines of python were pulling in > all that weight if it could have been a few lines of guile or bash instead. Do you propose to patch each time? Because I am not convinced again that upstream will change Python to Guile. > The time it takes to figure out whether/how a trivial dependency can be > eliminated is, ISTM, a major cause of gordian-knot dependency bloat -- which > IMO > in turn is a kind of RYF threat: it's effectively a free-time pay-wall. To me, one path to remove unnecessary dependencies of Python2 is to give a look package by package, try to replace the Python2 dependency by the Python3 (if exist) and see what happens. If it does not build because the package really uses Python2 features, figure out which one, patch with the Python3 equivalent and submit the patch upstream. All the best, simon
Re: Python 2 end-of-life?
Hi Konrad, On Wed, 27 Nov 2019 at 08:56, Konrad Hinsen wrote: > > IOW, a bunch just differ by version -- I wonder how many of the > > packages that drew in old versions could run fine with respective > > latest versions of what they are dependent on? > > That's a very good question! Is it not cheap to replace the python2 dependency by the python3 one and try to locally build? The snippet of code you sent helps to figure out which packages are still using Python2. As you said, some packages will not be updated to Python 3. Let document it in description for example and let provide a rationale explaining why that we put in the manual. > That's yet another question: could we patch the upstream code to replace > Python by something else that's more convenient for Guix. That may > actually be a worthwhile approach to reduce software bloat in Guix, > but it also shifts some of the maintenance burden from upstream to Guix. It does not appear to me a reasonable approach. > Guix might well contribute to a long-term improvement of everyone's > habits in this respect, by providing the bird's-eyes view of software > systems that developers and maintainers of individual packages cannot > have. What you describe is just the application of well-known ideas from > software engineering (cleaning up code before it becomes unmaintainable) > to the systems level. Which is possible because Guix turns the systems > level into just another software layer. Agree! :-) All the best, simon
Re: Python 2 end-of-life?
Hi, On Wed, 27 Nov 2019 at 09:36, Konrad Hinsen wrote: > > I assume many of these package can be updated. (Indeed I just updated > > pdfposter, which I'm maintaining.) > > Great. That's the kind of response I was hoping for! Nice! On lost time (building, boring meeting, etc.) I will pick one package from the list and try to replace/update. :-) > LLVM/clang looks like another important building block to liberate from > Python 2. I hope someone can take a look at that. Maybe ask to Mathieu or Carl? They just submitted bunch of patches about LLVM/clang. All the best, simon
Re: Python 2 end-of-life?
zimoun writes: >> It would be a shame if half a dozen lines of python were pulling in >> all that weight if it could have been a few lines of guile or bash instead. > > Do you propose to patch each time? Because I am not convinced again > that upstream will change Python to Guile. We have python-on-guile, which might just work as a replacement for trivial uses of Python 2. -- Ricardo
Re: Reworking the cookbook layout
Le 27 novembre 2019 16:26:06 GMT+01:00, zimoun a écrit : >I break the usual rules of reply. Hope that will be ok. :-) > > >On Wed, 27 Nov 2019 at 13:14, Julien Lepiller >wrote: > >> Le 27 novembre 2019 12:08:00 GMT+01:00, zimoun > a écrit : > >> >On Tue, 26 Nov 2019 at 23:12, Julien Lepiller > > >> >The first thing is: what is the purpose of the Cookbook? I mean I am >> >not sure we all define the same object with the same goal. >> > >> >Currently, it is all what cannot be included in the Reference >Manual. >> >So do we need to organize all this material with an strong >hierarchy? >> >A cookbook is a collection of recipes and it not generally well >> >organized. I am mean the one of my Grand-Mother is not. :-) >> >> So, following the structure I propose, the cookbook would only >contain tutorials and how-tos. Then we would need another place for >deeper explanations. > >[...] > >> >Then it is some work to revamp the blog entries and we should reduce >> >the workload because when we are revamping we are not writing other >> >materials. >> >> [...] I think a clearer editorial policy will help us see what's >needed and bring in more contributions. > >I agree that a clearer editorial policy will help us. > >It is what I am trying to point too. :-) > >However, I disagree on the structure you propose because I find it too >strong, with too much boundary. > > >> >To me this structure is nice but too strong. I do not see what is >the >> >difference between "how-tos" and "tutorials". >> >> A tutorial does not have a particular goal other than giving a tour >of the tools and main functionalities. So it's more a what-is than a >how-to. Not how to program in scheme, but what is it like to program in >scheme. > >To me, it is too arbitrary. > >Non-related example, but maybe it underlines my point. Recently, I >discovered that we can generate Docker images on foreign distro using >"guix system docker-image". But because of the structure, I have never >carefully read the section "System Configuration". I have always >thought that this section was about "Guix System" and I am not >currently using it. Well, I am not saying that the Reference Manual is >doomed; in this case, I am too lazy to correctly search. And for sure, >we have to put somewhere somestuff. > >My point is: what naturally makes sense to you does not necessary make >sense to me, and vice-versa. And decide if this or that belongs to >that or this is often arbitrary. That's why I think the structure >needs only 2 levels and a good index. I'd say even a search form :) > > >> >And for example, the blog "Packaging" entry is in the same time: >> > >> > - a tutorial because it is written for newcomers >> > - "goal-oriented" because it explains "how to package" >> >- explicative because it provides how it all works (scheme >> >explanations, etc.) >> > >> >So I feel an arbitrary boundary. >> >> I think it's not too nice to mix all of this together: I'm already a >packager, so I don't need a tutorial on packaging or scheme. I could >still learn something, but I'll skip most of this document. I think >it's best to split it for different readers: a tutorial, how-tos for >some difficult points that can arrise and explanations of the packaging >architecture for instance. > >In my (real) cookbook, I have 2 different recipes of the same meal >(say galette [sarrasin] ;-)). >And they are not written on pages close to each selfes but contrary >one is on the beginning of the cookbook, the other at the end. >One comes from a friend -- student time. >One comes from a guest -- couch surfing or related. >Now, I could write my own recipe, kind of adaptation of the two >previous ones. However, my sister find easier the first one and my dad >the last one. See what I mean? :-) It depends on the flavour, how you >read, etc. > >Well, we disagree on what should be the Cookbook because it lacks a >clear editorial policy. ;-) >Are not we trying to define one right now? :-) > >To me, the cookbook is a collection of recipes. And different recipes >can overlap. To me, a recipe is a story about a topic; the same >explanations can be detailed twice if they are important to the story. >And because they are worded differently, Alice will prefer the story 1 >and Bob the 2. Some story can be short, other lengthy. One key point >is a good index: an index where a "concept" that points to several >entries. So if I understand correctly, the cookbook would be an unordered collection of articles from many people. I'd say pretty intimidating. What I was proposing was to add more structure and a more logical progression, from introductory examples to more advanced use-cases. I didn't suggest that information should not be duplicated (although references to other sections are fine too). My goal is to have a document that can help people along the way from being interested in guix to becoming a contributor or an advanced user. More of a manual or a book. Maybe we need a separate document from t
Re: Moving Lisp libraries to lisp-xyz.scm?
Oops, I forgot to merge it on master! Also good catch with web-browser.scm and machine-learning.scm. I'll check for other possible module deps. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: [PATCH] WIP patches for the rust importer
Hi Efraim, > Unfortunately, this also breaks the recursive crate importer. I'm going > to continue working on it, but I could use some help getting the > recursive aspect of it working. I recently rewrote the recusive crate importer to use semantic versioning. I'll get a patch in later today. I'll see if I can get it to work with your changes as well.
Re: [PATCH] WIP patches for the rust importer
On November 27, 2019 8:06:43 PM UTC, mjbe...@riseup.net wrote: >Hi Efraim, > >> Unfortunately, this also breaks the recursive crate importer. I'm >going >> to continue working on it, but I could use some help getting the >> recursive aspect of it working. > >I recently rewrote the recusive crate importer to use semantic >versioning. >I'll get a patch in later today. I'll see if I can get it to work with >your changes as well. I'd love to see what you have so far if you want to share -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
articles on Elm and Guix
Hi guix-devel, I wrote a series of articles related to my Elm packaging for Guix: https://vllmrt.net/spam/guix-elm-1.html https://vllmrt.net/spam/guix-elm-2.html https://vllmrt.net/spam/guix-elm-3.html It covers packaging, adding a build system, and adding and deploying a service. Part 2 in particular might be interesting in case someone wants to pick up work on the Elm build system in the future. Cheers Robert
Re: articles on Elm and Guix
Robert, Robert Vollmert 写道： I wrote a series of articles related to my Elm packaging for Guix: These are great. Thank you! It's always fun to see inspiring (and independent) articles about Guix being put to good use. Kind regards, T G-R signature.asc Description: PGP signature
Re: articles on Elm and Guix
On 28. Nov 2019, at 00:37, EuAndreh wrote: > Does your blog have an Atom feed? Yes, at https://vllmrt.net/spam/atom.xml, though I neglected to link it properly previously. Should be fixed now, thanks! Cheers Robert
Re: [PATCH] WIP patches for the rust importer
> I'd love to see what you have so far if you want to share Okie Dokie, I posted it and cc'd ya. Also I took a look at your patches. 0001-import-crate-Don-t-include-optional-dependencies.patch should work just fine with my patch. But 0003-import-crate-Honor-versioned-dependencies-when-impor.patch will not work. I took a different route here with the naming. If you are interested take a look take a look at my second patch. (recusive-import-semver) only will add the version number to the name if the crate being imported is not the latest version. I thought this was more inline with the canonical names, but if always adding version number the export symbol is desirable it will simplify things. Also I added a function (find-packages-by-name*/direct) to packages.scm which will return the export symbol of a package that already exists. I use this in case there are some non-canocal export name already added.
Re: Reworking the cookbook layout
On +2019-11-27 12:08:00 +0100, zimoun wrote: > Hi, > > Thank you to open the discussion about the Cookbook. > > The first thing is: what is the purpose of the Cookbook? I mean I am > not sure we all define the same object with the same goal. > > Currently, it is all what cannot be included in the Reference Manual. > So do we need to organize all this material with an strong hierarchy? > A cookbook is a collection of recipes and it not generally well > organized. I am mean the one of my Grand-Mother is not. :-) > > > On Tue, 26 Nov 2019 at 23:12, Julien Lepiller wrote: > > > Today I have been reading https://www.divio.com/blog/documentation/ > > which makes some good points on how to write good documentation. They > > suggest to divide documentation into four categories, depending on > > their purpose: > > I was reading similar elsewhere with the idea to prepare what we could > propose for the next round of the Google Seasons of Doc [1] (if any). > > [1] https://developers.google.com/season-of-docs > > > > - tutorials, written for newcomers. They should be to the point and > > guide a new user through every step of using the new system. > > - how-tos. They should be "goal-oriented" and allow > > a user who knows what they want to do, to learn how to do it. > > - explanations. They are more theoretical and should give more > > knowledge on how it all works. > > - reference. It should contain all the technical details of the code. > > To me this structure is nice but too strong. I do not see what is the > difference between "how-tos" and "tutorials". > To my mind, it's a matter of the scope of your goal: how-to: a cache of narrowly useful knowledge, usually in a form of code snippets or step-by-step work flow guidance. I really like the example set by "info giteveryday" or "git help everyday" (the former being more navigable, the latter leads to a man page on my system) Handy one-liners that you could re-invent, but don't remember for sure, and don't want to re-debug belong in a how-to, as I see it. tutorial: a guide towards mastery of a tool _set_, not just a specific use of a specific tool. Usually starts with an introduction to basics, but can go anywhere and all over. E.g. emacs's opening page invites you to an example (and tells you how to turn that prompt off when you are ready to do without). Likewise info has a tutorial. An important aspect is being able to find and extract what you want easily and put it to use where you want to. That's not a matter of _what_ you put in how-tos or tutorials, but how easily it can be found and used. emacs is generally great at that, especially having guix and guile info in buffers that you can copy snippets from, and a shell session likewise. Though I will say communication between emacs under X and emacs in the login (non-gui) console is not smooth for me -- probably because I haven't searched enough for how others may have created a solution. Maybe "M-x archive-buffers .. to .. FILE" which console emacs could "Mx load-buffers .. from .. FILE" -- which is easier, to hack or to find? ;-/ (Actually I think we ought to have a clipboard daemon completely independent of X and any app, secure and ACL-controlled, something like IPC for QubesOS). My solution long ago was a bash script called stack, which uses dd to append anything piped to it to the end of an internal file, while logging the byte length to a metafile, or writing to stdout the last segment written if nothing is on stdin, and optionally trimming it back off if -pop option. Easy to use from either bash by piping a region to it or inserting the result of its execution ( "C-u Esc ! stack" or "C-u Esc ! stack -pop ). Why go on about seemingly off-topic tools? Well, to me, my little helper tools are important. Probably most hackers have a set of their own. My point here is that I think guix can provide a nice way to share not only how-to tips and tutorials etc, but also helper tools to enhance the hacking environment. AND: that tools and docs should be designed with their interaction in mind. E.g., delimiting things for easy extraction for various purposes. IMO it would be nice if ANY app that presents text had a way to select a region and hit a pipe key that would prompt for a shell command to pipe it to, like emacs. But why not info by itself, or man -- or less for that matter. And not dependent on X. > And for example, the blog "Packaging" entry is in the same time: > > - a tutorial because it is written for newcomers > - "goal-oriented" because it explains "how to package" > - explicative because it provides how it all works (scheme explanations, > etc.) > > So I feel an arbitrary boundary. > > Then it is some work to revamp the blog entries and we should reduce > the workload because when we are revamping we are not writing other > materials. > > > > Following these p
Re: articles on Elm and Guix
On Thu, Nov 28, 2019 at 01:06:03AM +0100, Tobias Geerinckx-Rice wrote: > Robert, > > Robert Vollmert 写道： > > I wrote a series of articles related to my Elm packaging for Guix: > > These are great. I second that. Well done.
New POWER9 machines for the Guix build farm?
Fellow Guix, The Guix sysadmins are considering buying shiny hardware for the ci.guix.gnu.org build farm, and it would be awesome if that included our first POWER9 machine(s)! However, few (if any) Guixers have any hands-on experience with this architecture, let alone buying and installing whole systems. Some remember a bad experience with a prominent vendor, and it would appear that they're not alone[0]. There's also some concern that getting these machines up and running will take significant effort. So please, share your expertise and experience in this area! Ideally, we need someone to volunteer to (help) set up any new POWER9 boxes and later take care of them when needed. It would certainly help justify the multi-thousand-euro bill. Kind regards, T G-R PS: For the shorter term, I've applied for an 8-core POWER9 LE instance (with 16 GiB of RAM) for Guix at OSUOSL[1]. Assuming that it's accepted, it should be available within a week. [0]: https://drewdevault.com/2019/09/23/RaptorCS-Blackbird-a-horror-story.html, but read https://drewdevault.com/2019/10/10/RaptorCS-redemption.html as well :-) [1]: https://osuosl.org/services/powerdev/ signature.asc Description: PGP signature
Re: articles on Elm and Guix
Thanks Robert! This is very relevant to my job. Nice write up! - John
Re: articles on Elm and Guix
Robert Vollmert writes: > Hi guix-devel, Hello! > I wrote a series of articles related to my Elm packaging for Guix: > > https://vllmrt.net/spam/guix-elm-1.html > https://vllmrt.net/spam/guix-elm-2.html > https://vllmrt.net/spam/guix-elm-3.html > > It covers packaging, adding a build system, and adding and > deploying a service. Part 2 in particular might be interesting in > case someone wants to pick up work on the Elm build system in the > future. This looks very interesting. I've opened and skimmed the articles already, I'll definitely read them. Does your blog have an Atom feed?
Re: New POWER9 machines for the Guix build farm?
Tobias Geerinckx-Rice writes: > Fellow Guix, > > The Guix sysadmins are considering buying shiny hardware for the > ci.guix.gnu.org build farm, and it would be awesome if that included > our first POWER9 machine(s)! I was curious the other day looking at multiarch compilation using the qemu-binfmt service, is there support for POWER PC? Anyways, I would love to see support for POWER9 come to Guix. I have limited experience with this architecture, but I will keep lurking in this thread. Good luck! -- Brett M. Gilio https://git.sr.ht/~brettgilio/
Re: Recent $EMACSLOADPATH changes broke my setup: Bug or Feature?
Hello Diego, Diego Nicola Barbato writes: > Hey Guix, > > I've already asked about this on IRC, but since the people responsible > for the changes didn't seem to be present I'll ask here too. > > I use EXWM so I've installed ‘emacs’ and ‘emacs-exwm’ in my system > profile. Additionally I've installed Emacs packages (‘emacs-org’, > ‘emacs-pdf-tools’, ‘emacs-emms’, etc.) in my user profile. Since the > changes to the way Emacs packages are handled this no longer works, > i.e. Emacs no longer knows about the packages installed in my user > profile. > > I can work around it by installing ‘emacs’ to my user profile. But it > doesn't make much sense to me that I have to install ‘emacs’ “twice” > just so an environment variable is set. > > Is this an intended consequence of the recent changes or should this be > considered a bug? This is bug #20255 [0], where the system and user profile environment variables are not merged at the time /etc/profile is sourced. HTH, Maxim [0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255
