Re: December 2020 (old) bugs squashing!
Hi!
zimoun writes:
> Hi,
>
> On Sat, 05 Dec 2020 at 20:42, "Bonface M. K."
> wrote:
>
>> Just curious, how do you get debbugs to show
>> forgotten patches. I'm only beginning to use it
>> now ...
>
> Forgotten patches are just old patches. ;-)
>
>
> What I do with Emacs is: “M-x debbugs-gnu“ to have all the bugs and
> patches; with something in my config file as:
>
> (setq
>debbugs-gnu-default-packages '("guix-patches" "guix")
>gnus-summary-line-format "%I%(%[ %n%]%) %s\n"))
>
> Then I scroll down the buffer, generally M-> and I look for the state
> normal in red; which means no answer in the thread. And I pick one from
> my interest, or hitting p to move. In any case, it is worth to read all
> of them. :-) Next, I try to understand and/or to reproduce. Three
> cases:
>
> a) lacking info so reply for asking more details
> b) appear to me not-a-bug anymore so ask for status
> c) real bug so report/update what I did
>
> In addition, I have an Org-mode to track what I open and then remind me
> 3 weeks later in my agenda. If no answer, I mark it as moreinfo with
> ’M-x debbugs-gnu-send-control-message’ (C). Otherwise I add an item to
> my TODO list to work on it if I feel enough annoyed. Time to time, when
> I attend to boring meeting, I review all the moreinfo and close some if
> they are too old, ask again if I am not confident.
>
>
> Reading the bugs via Debbugs, I do ‘M-x org-capture’ (C-ctth blabla C-c
> C-c) then stash the link of the bug ’M-x my/guix-issue’ and start the
> reply ’M-x gnus-summary-wide-reply-with-original’ (R), edit, and ’M-x
> message-send-and-exit’ (C-c C-c), assuming that Emacs is configured to
> send email. :-)
>
>
> Snippet of my config:
>
> (define-key gnus-summary-mode-map "R"
> 'gnus-summary-wide-reply-with-original)
> (define-key gnus-article-mode-map "R"
> 'gnus-summary-wide-reply-with-original)
>
> (setq
>org-capture-templates
>(backquote
> (("t" "Todo")
> ("th" "Hunt" entry
> (file+headline "~/org/todo.org" "Bug Hunt")
> ,(my/org-templates-file "todo-bug.org"))
> org-capture-templates-contexts
> '(("th" ((in-mode . "gnus-summary-mode")))
> ("th" ((in-mode . "gnus-article-mode")
>
>
> where the capture is:
>
> * TODO [#C] Bug %?:hunt:
> SCHEDULED: %(org-insert-time-stamp (org-read-date nil t "+3w"))
> :LOGBOOK:
> CLOCK: %U--%U => 0:00
> :OPEN: %U
> :END:
> :PROPERTIES:
> :Open: %U
> :Subject: %:subject
> :Date: %:date
> :MessageID: %:message-id
> :END:
>
>
> and the helper is:
>
> (defmacro defun-bug->url (name url docstring)
> "Macro returning yankage #bug URL.
>
> The `interactive' function that the macro returns is then referred by NAME.
>
> Please provide a DOCSTRING."
> (let ((fun (intern (symbol-name name)))
> (doc (concat docstring "\n\n"
>(format "Yankable result: `%sNUMBER'." url
> `(defun ,fun (number)
>,doc
> (interactive
> (list
> (progn
> (when (not (boundp 'debbugs-gnu-bug-number))
> (setq debbugs-gnu-bug-number -2))
> (read-string
> (format "Bug number (%s): " debbugs-gnu-bug-number)
> nil nil debbugs-gnu-bug-number
> (let ((str (format "%s%s" ,url number)))
> (kill-new str)
> (when current-prefix-arg
> (browse-url str))
> (message (format "%s killed." str))
>
> (defun-bug->url my/guix-issues "http://issues.guix.gnu.org/issue/;
> "Add URL of bug NUMBER to `kill-ring'.")
> (defun-bug->url my/guix-debbugs
> "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=;
> "Add (old) URL of bug NUMBER to `kill-ring'.")
>
>
> Last, there is one point I do not like with the Emacs front-end of
> Debbugs is that the network is required. Well, I would prefer dump all
> the mbox and work with Emacs+Notmuch but I have not yet configured that.
> If someone has tip, please share. :-)
>
> Or maybe fetch from issues.guix.gnu.org the Mumi maildir+mu database.
>
> Hope that helps,
> simon
>
Thanks! This is very helpful and useful. I'm going
to try(with some modifications) this workflow out
:)
--
Bonface M. K. <https://www.bonfacemunyoki.com>
Humble GNU Emacs User / Bearer of scheme-y parens
Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz
GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
signature.asc
Description: PGP signature
Re: December 2020 (old) bugs squashing!
Ricardo Wurmus writes: > Bonface M. K. writes: > >> Just curious, how do you get debbugs to show >> forgotten patches. I'm only beginning to use it >> now ... > > Debbugs doesn’t have a built-in mechanism to query forgotten issues. > Mumi implements “forgotten-bug-numbers”, which has the following > docstring: > > "Return the numbers of issues that are open but haven't seen any > activity for a while. The duration is given by SECONDS-AGO, which > defaults to 30 days." Thanks for the feedback :) -- Bonface M. K. <https://www.bonfacemunyoki.com> Humble GNU Emacs User / Bearer of scheme-y parens Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: December 2020 (old) bugs squashing!
zimoun writes: > Hi, > > Let’s have an Advent calendar effort! Everybody out there who is not > familiar with this tradition of an « Advent calendar » and to avoid any > ambiguity, I am appropriating myself the concept*: all of us try to > close one or more bug per day from 1rst to 31th December, then 2021 will > start on new balls as in tennis match. :-) > > In priority let pick bugs older than #3 (~Jan. 2018). > > <http://issues.guix.gnu.org/forgotten> > > From Debbugs, I count 151 bugs or forgotten patches, almost 3 years! > Time to close them or investigate more. > Just curious, how do you get debbugs to show forgotten patches. I'm only beginning to use it now ... [...] -- Bonface M. K. <https://www.bonfacemunyoki.com> Humble GNU Emacs User / Bearer of scheme-y parens Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket packages / build system
Christopher Lemmer Webber writes: [...] >> I've considered doing this... studying raco's source and seeing how it >> actually does and sets up things. I'd rather do this than the above, >> but it would take more time and would lead to alot more boiler plate I >> think... I'm not entirely sure about how to work around the global >> state though... > > Regarding the boilerplate, not sure it needs to from a > package-definitions perspective... if the info.rkt can be read in the > general case, this could be the racket-build-system that does most of > the work (probably even by reading the very same info.rkt) rather than > it being output'ed from an importer definition. > I'll try exploring this. >> First, let's consult with the racket-devel and racket-user ML and see >> what those communities have to suggest... > > Yes, good idea. -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Bazu / Rieng ya software sare Mchochezi of: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket packages / build system
Hi racket-dev and racket-users! I'm trying to create a build system for Racket in Guix(a long-standing feature for some of us in the Guix community). It appears that Racket, vis-a-vis raco, maintains some "global" state whereby package-installs leads to the update of some files, links, search-paths and other refs(hence the statefulness) that I won't go into. There's a similar project, racket2nix(please see: https://github.com/fractalide/racket2nix) which overcomes this by generating a temporary environment(by copying most of the racket folders and the deps needed as writable folders) where it installs with raco and then tries to update racket's global state. This feels slow and hacky. To summarize, the default racket install system is quite stateful(!) and also many operations seem to try to touch files. I'm considering studying the racket2nix more and going that route as a last resort if I don't find a work-around for the aforementioned state issues. Another possibility(though I don't know how feasible that would be) would be to figure out how raco works(by studying it's source) and do the same thing in a Guix-y way. I however, don't know yet how I would overcome the state issue :( Racket-dev or racket-users, is there some important thing I'm missing? Is there some (maybe undocumented, new or WIP) way of installing racket packages without maintaining state? Any pointers/ suggestions are gladly welcome. I'm invested of having a way to package racket packages in Guix; and I believe it's a big step forward for Racket in increasing it's reach in the Guix community :) PS: Full e-mail thread here: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00298.html -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Bazu / Rieng ya software sare Mchochezi of: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket packages / build system
Christopher Lemmer Webber writes: > Dimos Dimakakos writes: > >> Bonface M. K. writes: >> >>> To simply put it, AFAIU updating a package would >>> require racket to update it's references(either >>> links, and other references that I won't go into), >>> hence creating some form of "global state"; >>> thereby if you use raco, every package updated >>> would lead to some update with racket's search >>> paths or dirs somewhere. Any ideas to overcome >>> this wall? (or anything I've got wrong somewhere?) >> >> This was one of the main problems that I also encountered when working >> on this. racket2nix solves this by generating a temporary environment >> (by coping most of the racket folders and the deps needed as writable >> folders) where it installs with raco and then tries to update the global >> state of racket. >> >> To be honest this solution is kinda hacky and also slow, but I couldn't >> think of another one at the time I tried to work on the issue. It's a >> reality that the racket install system is quite stateful and also many >> operations seem to try to touch files. Installing with raco for example >> will try to recompile the dependencies of the new package and other such >> examples. >> >> Anyway, I hope you can find a way to move this forward! > > I wonder if it would be a good idea to copy many of the points from this > email and the parent to racket-users or racket-dev and see if someone > more familiar with the structure of the system can provide guidance from > there? > This is a good idea IMHO. I'll go ahead and do this. Perhaps there's something more important we've missed or aren't seeing. > If we have to go the racket2nix route, it would be better than nothing I > guess. > Yeah. I'm considering going though this route as a last resort. I don't understand the nix DSL syntax(though it reads alot like Haskell!). > Another possible route: don't use the Racket installer tooling. > Instead, read the info.rkt file of the package to understand what raco > *probably would* do, and then do it in a more Guix way instead. > > What do you think of that route? I've considered doing this... studying raco's source and seeing how it actually does and sets up things. I'd rather do this than the above, but it would take more time and would lead to alot more boiler plate I think... I'm not entirely sure about how to work around the global state though... First, let's consult with the racket-devel and racket-user ML and see what those communities have to suggest... -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Bazu / Rieng ya software sare Mchochezi of: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket packages / build system
Christopher Lemmer Webber writes: > Bonface M. K. writes: > [...] > I have the notes that Dimos wrote up not long ago in case anyone is > interested. Dimos, do you mind if I post them to the list? > > - Chris Hi! I've been trying to hack around the racket build system(see attached) for some time now; mostly using raco... The biggest problem I've faced so far is that AFAICT, when you use raco to install packages, racket updates some files from where it's called(in guix's case store this is the store where racket is in)--- and I don't think you are allowed to do this. I've tried doing "raco install ", and also just doing "raco install" from inside the directory. The command for building: --8<---cut here---start->8--- env GUIX_PACKAGE_PATH="/home/bonface/projects/guix-bioinformatics:/home/bonface/projects/guix-past/modules" ./pre-inst-env guix build racket-hello-racket -K --8<---cut here---end--->8--- with the error: --8<---cut here---start->8--- starting phase `install' make-directory: cannot make directory path: /homeless-shelter/ system error: Permission denied; errno=13 context...: /gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/racket/file.rkt:114:0: make-directory* [repeats 1 more time] /gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/pkg/private/lock.rkt:26:0: with-pkg-lock* /gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/pkg/main.rkt:216:16 (submod "/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/pkg/main.rkt" main): [running body] temp35_0 for-loop run-module-instance! for-loop [repeats 1 more time] run-module-instance! "/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/raco/raco.rkt": [running body] temp35_0 for-loop run-module-instance! "/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/raco/main.rkt": [running body] ... Inferred package name from given `--clone' path package: source given path: /tmp/guix-build-racket-hello-racket-0.0.1.drv-0/source command "raco" "pkg" "install" "--no-cache" "--no-setup" "--ignore-checksums" "--clone" "/tmp/guix-build-racket-hello-racket-0.0.1.drv-0/source" failed with status 1 builder for `/gnu/store/filph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv' failed with exit code 1 build of /gnu/store/filph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv failed View build log at '/var/log/guix/drvs/fi/lph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv.bz2'. guix build: error: build of `/gnu/store/filph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv' failed --8<---cut here---end--->8--- And when troubleshooting: --8<---cut here---start->8--- cd /tmp/guix-build-racket-hello-racket-0.0.1.drv-0 /home/bonface/guix/pre-inst-env guix environment \ --no-grafts -C racket-hello-racket --ad-hoc strace gdb source ./environment-variables $GUIX_ENVIRONMENT/bin/raco pkg install --no-cache \ --no-setup --ignore-checksums --8<---cut here---end--->8--- Which works just fine since I'm updating files inside $GUIX_ENVIRONMENT. Right now I'm looking for ideas to experiment with to try to overcome this, and the low hanging fruit is to successfully build a hello-racket package with zero deps and no tests. To simply put it, AFAIU updating a package would require racket to update it's references(either links, and other references that I won't go into), hence creating some form of "global state"; thereby if you use raco, every package updated would lead to some update with racket's search paths or dirs somewhere. Any ideas to overcome this wall? (or anything I've got wrong somewhere?) ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2020 Bonface Munyoki Kilyungi ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; GNU Guix is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with GNU Guix. If not, se
Re: Racket packages / build system
Ludovic Courtès writes: > Hi! > > "Bonface M. K." skribis: > >> Thanks for the notes. I've skimmed through them >> and they seem sensible. I'll look at how other >> build systems are written as a first step, then >> get my hands wet. > > Would be great to see that happen! There’s also a Chicken build system > under review currently: > > https://issues.guix.gnu.org/43976 > > Also, you’ll probably want ‘guix import raco’ at some point; that may be > quite easy to implement if Racket provides a JSON API for its packages. > (take a look at the other importers). > Thanks for the share! > Ludo’. -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Bazu / Rieng ya software sare Mchochezi of: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket packages / build system
Christopher Lemmer Webber writes: [...] >> Can I volunteer on this task? There's some work in >> my team done in Racket; and it would be of great >> interest to us to have a working Racket build >> system. I can set apart some time to work on >> this. I'd ask for alot of guidance/ review on this >> though :) > > YES! Please do. Let's talk. You can ping me on IRC also, dustyweb on > freenode. > Thanks! I'm called bonz060 on FreeNode; though nowadays I've grown to be an e-mail person. [...] >> Please do share the notes! I can try to hack >> something up \m/\m/. > > I looked at the email that Dimos sent to me (also the email I had was > apparently not the most recent email that they are using, corrected in > the addressing this time), and they had asked me if they should post it > to the mailing list, so I think that's consent to post it since they > expressed consideration in doing so in our exchange... so I'm attaching > it. > [...] Thanks for the notes. I've skimmed through them and they seem sensible. I'll look at how other build systems are written as a first step, then get my hands wet. Do I open an issue for this---I can't see anything that tracks this even in archived issues--- then send patches there? Or do I send patches off the list and then submit the final drafts(if we get there) on the list later? -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Bazu / Rieng ya software sare Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket packages / build system
Christopher Lemmer Webber writes: > Bonface M. K. writes: > >> Christopher Lemmer Webber writes: >> >>> Just a heads up that right now you *can* run Racket-on-Chez, but soon >>> Racket-on-Chez will be the "default"... maybe it's a good idea to see >>> how hard it will be to make a racket-on-chez package variant. >>> >>> I'm interested in looking at that but it'll probably have to be a while >>> before I can do so... if someone does so before me, I'll be interested >>> in beta testing at least. >>> >>> But also leaving this here as a self-reminder so we aren't surprised >>> when it becomes a more important thing to deal with :) >>> >>> >> >> Also, since we are talking about Racket, what >> happened to having a racket build system? > > There's interest in it, and Dimos made interesting progress towards > figuring out some of the key problems... there's been interest beyond > that but sadly it seems like organizing the energy to work on it hasn't > happened for whatever reason yet. > Can I volunteer on this task? There's some work in my team done in Racket; and it would be of great interest to us to have a working Racket build system. I can set apart some time to work on this. I'd ask for alot of guidance/ review on this though :) > I've offered to throw money at the problem if someone's willing to take > it on btw... not much, but some money. I've talked to a couple of > people about that but it stalled in each iteration I don't think > it's impossible but I guess it's one of those tasks that for whatever > reason seems difficult to get going on because there are some > complexities around the way Racket builds "collections" that eg don't > seem to show up in Python. Anyway that's not a judgement because > despite wanting it fairly badly clearly I haven't made progress on it. > > I have the notes that Dimos wrote up not long ago in case anyone is > interested. Dimos, do you mind if I post them to the list? > Please do share the notes! I can try to hack something up \m/\m/. > - Chris -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Mchochezi / Rieng ya software sare Curator of <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket will move on top of Chez soon
Christopher Lemmer Webber writes: > Just a heads up that right now you *can* run Racket-on-Chez, but soon > Racket-on-Chez will be the "default"... maybe it's a good idea to see > how hard it will be to make a racket-on-chez package variant. > > I'm interested in looking at that but it'll probably have to be a while > before I can do so... if someone does so before me, I'll be interested > in beta testing at least. > > But also leaving this here as a self-reminder so we aren't surprised > when it becomes a more important thing to deal with :) > > Also, since we are talking about Racket, what happened to having a racket build system? -- Bonface M. K. <https://www.bonfacemunyoki.com> Chief Emacs Mchochezi / Rieng ya software sare Curator of <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Removing/replacing “Guix in action” video from the home page?
Joshua Branson writes: > I would describe my video set up as pretty simple: > > $ wf-recorder --audio > Thanks for sharing! > If you watch any of my below videos, you'll see me take breaks like, "Oh > hold on just a second, I think my landlord is knocking at my front > door. I'll be right back." I think I saw one of them a while back. I'll try watching more of them :) -- Bonface M. K. (https://www.bonfacemunyoki.com) Chief Emacs Mchochezi / Twitter: @BonfaceKilz GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Removing/replacing “Guix in action” video from the home page?
Joshua Branson writes: > I send a ton of time making videos online, so I can probably spare some > time to do this. I'll have a video posted in a day or two. > > Thanks, > > Joshua > What's your video setup look like? Moreso [free] tools that you'd use to cut, splice and clean audio. > -- > Joshua Branson > Sent from Emacs and Gnus > https://gnucode.me > https://video.hardlimit.com/accounts/joshua_branson/video-channels > "You can have whatever you want, as long as you help enough other people get > what they want." - Zig Ziglar > > -- Bonface M. K. (https://www.bonfacemunyoki.com) Chief Emacs Mchochezi / Twitter: @BonfaceKilz GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Outreachy Applicant: An Introduction
Hi! Magali Lemes writes: > Hey, > I'm using Ubuntu 20.04.1 LTS. I must say I've > never used emacs before, so > I'll try to get the hang of it. Welcome to the club(of Emacsen users)! You'll get used it to it ;). Here's a good channel that shows you some cool things that you can get done in Emacs: https://www.youtube.com/channel/UC0uTPqBCFIpZxlz_Lv1tk_g. I'd recommend the magit video; it comes in really handy IMHO. > Sharing my progress: I decided to package the > arduino IDE, but it turned out > way harder than I expected, due to its many > dependencies. I ended up not > doing it, but it was a good experience because I > could learn about some > functions in Scheme - chdir, for example -, some > of the phases of > building a package - like unpacking, configuring > and building - and I could > also interact with the community, asking for > help, via IRC, which is a > very new thing for me. > As for today, I will continue trying to package > something. I'll probably follow > your previous advice and begin with a R package. > It seems easier, so hopefully > I'll succeed. > > Cheers, > Magali. > > Em seg., 12 de out. de 2020 às 12:06, zimoun < > zimon.touto...@gmail.com> escreveu: > > Hi, > > On Mon, 12 Oct 2020 at 13:00, Magali Lemes < > magalileme...@gmail.com> wrote: > > > Guix was fairly easy to install, I used the > shell script to do that. > > Which distribution do you use? > > > I installed emacs using Guix and it worked > as expected. > > Nice! > Personally, I manage the Emacs packages with > Guix via a manifest.scm > file. And in a separate profile. My conf > [1] is far from perfect but > if you need inspiration. :-) > > 1: <https://github.com/zimoun/my-conf> > > > I'll begin by trying to package something. > So, I'll go through the links you sent > > and see how that goes. > > Cool! > Do not hesitate to ask on help-guix or #guix > if you encounter issues > on your path. And feel free to send your > progress, success or > failure. > > All the best, > simon -- Bonface M. K. (https://www.bonfacemunyoki.com) Chief Emacs Mchochezi / Twitter: @BonfaceKilz GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: emacs-lucid (was Re: Emacs closure at ~900MB?)
Pierre Neidhardt writes: > "Bonface M. K." writes: > >> Wouldn't that be redundant? If you wanted to use >> EXWM, we already have EXWM provided on MELPA, so >> you could just set that up. That's IMHO though. > > Maybe there is a misunderstanding. We provide EXWM as a Guix package > for those who don't want to use Emacs' own package manager. Without an > emacs-no-x-toolkit-exwm package, Guix+EXWM users would be forced to drag > GTK->Mesa->LLVM just to start Emacs. > Ooof! I never thought about it /that/ way. Thanks for clarifying. > Besides, MELPA can't be used to build Guix systems, images and the like. Yeah sure. In that case, it makes alot of sense to have emacs-no-x-toolkit-exwm packaged. -- Bonface M. K. (https://www.bonfacemunyoki.com) Chief Emacs Mchochezi / Twitter: @BonfaceKilz GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: emacs-lucid (was Re: Emacs closure at ~900MB?)
Pierre Neidhardt writes:
> Just tested, EXWM works with emacs-no-x-toolkit!
>
Just tested it too, and it works for me too :)
> So I suggest we add the following packages:
>
> (define-public emacs-no-x-toolkit-xelb
>(package
> (inherit emacs-xelb)
> (name "emacs-no-x-toolkit-xelb")
> (arguments
> (substitute-keyword-arguments (package-arguments emacs-xelb)
> ((#:emacs emacs) `,emacs-no-x-toolkit)
>
> (define-public emacs-no-x-toolkit-exwm
>(package
> (inherit emacs-exwm)
> (name "emacs-no-x-toolkit-exwm")
> (synopsis "Emacs X window manager (without X toolkit)")
> (propagated-inputs
> `(("emacs-no-x-toolkit-xelb" ,emacs-no-x-toolkit-xelb)))
> (arguments
> (substitute-keyword-arguments (package-arguments emacs-exwm)
> ((#:emacs emacs) `,emacs-no-x-toolkit)
>
> Thoughts?
Wouldn't that be redundant? If you wanted to use
EXWM, we already have EXWM provided on MELPA, so
you could just set that up. That's IMHO though.
--
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
signature.asc
Description: PGP signature
Re: video stream of updating newsboat to 2.20.1
Thanks for sharing! -- Bonface M. K. (https://www.bonfacemunyoki.com) One Divine Emacs To Rule Them All GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
Re: Reproducible Research Hackathon: Friday, July 3rd
Konrad Hinsen writes:
> Hi Ludo,
>
>> Apologies for the delay. What was this bug exactly?
>>
>> I know Bonface addressed an issue related to how the Python 2.4 build
>> system would capture the kernel version via ‘uname’ a build time:
>>
>>
>> https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7
>>
>> But presumably you’re referring to something else, right?
>
> Indeed. The details are here:
>
> https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1
>
> Since I won't be able to look into this before my summer vacations,
> I opened an issue as a reminder.
>
> Cheers,
> Konrad
>
That's strange. To get the right results, you'd have to do a `2L ** 64`.
When I tried `2 ** 63` I got `-9223372036854775808`. There's also an
overflow error. Here's a snippet of what fails from
Python-2.4.6/Lib/test:
```
# If this fails, probably using a strict IEEE-754 conforming libm, and x
# is +Inf afterwards. But Python wants overflows detected by default.
try:
x = math.exp(10)
except OverflowError:
pass
else:
raise TestFailed("overflowing exp() didn't trigger OverflowError")
```
Maybe there's an overflow somewhere and we'd have to tweak libm? I'm
speculating though. I'd have to investigate this later.
--
Bonface M. K. (https://www.bonfacemunyoki.com)
One Divine Emacs To Rule Them All
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
Re: Internationalization Support for the Guix Data Service Outreachy Project
Daniela Lura writes: > Hi everyone, :) > > I'm following up to give an update on how the "Improve Internationalization > Support for Guix Data Service" Outreachy project has > been going. > Translated versions of lint checkers and package synopsis and descriptions > are now present in the database and they're also > available through the Guix Data Service web interface. > They can be accessed in these pages: > Lint Warnings: > - > https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/lint-warnings > - > https://data.guix.gnu.org/compare?base_commit=ceb233bb7642b2a7efec57073bf205b62ebd8f97_commit=3123cdaf7b695f3473ed2bf8c15da911d889cca3 > Package Synopsis and Descriptions > - > https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages > - > https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package/chroma/1.17?locale=en_US.utf8 > > The addition of locale values has also been reflected in the JSON response > for the pages where translations are available. > > The availability of translated packages synopsis and descriptions for each > locale can be found here: > https://data.guix.gnu.org/revision/054153b28cea697d0439127ffdea4aadfd5c2e0a/packages-translation-availability > > Here you can find an outline of the project: > https://github.com/spf50/data-service/projects/1 > > Hopefully these changes will make your experience using Guix Data Service > better and will help prevent exclusion as much as > possible. This is really dope! Is there a plan for supporting other locales? And how are the actual translations managed? I've seen other popular projects like antennapod(https://github.com/AntennaPod/AntennaPod) use Transifex(https://www.transifex.com/antennapod/antennapod/) and run on a complete volunteer basis. > Looking forward to hearing your impressions and suggestions. > > Best Regards, > > Danjela > > On Sat, 9 May 2020 at 22:27, Daniela Lura wrote: > > Hello everyone, > > Hope you are doing well during these tough times! > > I am Danjela, the intern who will be working on "Internationalization > Support for Guix Data Service" Outreachy project > mentored by Christopher Baines. > > This email is to say ""Hi!" and introduce myself to the Guix community > because I haven't been really active on the mailing > list. > If any queries about the project arise in the future, you can contact me > by cc-ing Christopher or just participate in this > thread. > I'm really excited to start working on the project and learn more about > Guix and Guile. > > Warm regards, > > Danjela -- Bonface M. K. (https://www.bonfacemunyoki.com) One Divine Emacs To Rule Them All GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
