IRC channel logs
2023-06-10.log
back to list of logs
<mirai>the kwarg naming can be improved, yes (strictly speaking it's not really kwargs since you can pass optional arguments or the “rest” argument) <mirai>the multiple fields together can be performed with a "customized" base-transducer <mirai>it's not the full integrated SRFI-171 originally proposed in $THREAD but it's a step in the right direction <lilyp>for your sheep, you have Emma, Franz and Mary either in the stable or on the ranch doing things (you decide what things) <mirai>regarding the test for generic-ini <mirai>the second value returned from a (with store …) <mirai>do I need to do anything about it? <mirai>or can I just ignore it and move on with the first value only <lilyp>mirai: I assume it will be garbage collected if you leave it alone, but do grep for similar code <mekeor>adding these parameters to the invokation of emacs works as a dirty hack work-around: "--directory" (search-input-directory inputs "/share/emacs/site-lisp/compat-29.1.4.1") <mekeor>it seems like emacs has problems finding the compat library because it's in a nested directory. <mekeor>i also tried adding "-f" "guix-emacs-autoload-packages" but it did not work <mekeor>anyway, i'm gonna try to make it work with ugly hacks first <mekeor>(this is my first slightly advanced package declaration) <lilyp>strange, can you print out EMACSLOADPATH after expand-load-path? <lilyp>it might be that unpack is too soon a phase, try another before build <mekeor>oh yes, i didn't think about that, thanks :) <attila_lendvai>sneek: later tell civodul: respawn-service in shepherd doesn't seem to check whether the service is disabled or not. i got into a state where my service was stopped according to `herd status`, i also issued a `herd disable`, but the process is still running, and whenever i terminate it with a kill -TERM, shepherd keeps respawning it. <ryan77627>Hey all, for those experiences with making package declarations, I have a question. I am attempting to build xdg-desktop-portal-hyprland so I can use it in place of wlr <ryan77627>...wlr's portal, however after the main build phase, i need to build a secondary component. Is there a way I can `cd` using guile in the build environment? I'm already making a new build phase after the default one to build this secondary component and am planning on using a lambda, but would just running "cd" in it as well work? Not too sure the "proper" way of accomplishing this <ryan77627>jackhill: Wow, you had that on lock and ready to go. Thanks, I'll take a look! <jackhill>ryan77627: haha, I've had need of it as well :) <jpoiret>ryan77627: doesn't wlr support hyprland as well? <matto->newbie question: is there an example how to setup your .emacs-file, while using emacs-packages through the package manager, like guix install emacs-smartparens, and so on? On other systems I use (use-package ..), should I do that on Guix too? <zamfofex>ryan77627: I was trying to package Hyprland the other way, but it seemed difficult, because it required some foundational Wayland and general GUI packages, and it seemed to need to rebuild a lot of stuff. <zamfofex>Eventually I settled for bspwm and the “animations” fork of Picom, since those were straight‐forward enough to set up. 🙂 <mekeor>matto-: it depends on whether you want to use-package.el's :ensure feature, i guess <mekeor>matto-: one approach is to just make sure that you have installed needed packages with guix. that's just fine. <mekeor>personally, i don't use use-package.el anymore. i just start emacs, then use emacsclient. so, the performance benefits from use-package don't matter for me. <matto->mekeor: thanks ! and in your .emacs, you still have your config for those packages? with (require ...) or something? <jlicht>sneek: later tell csepp: Can you try clearing "./guile" in your guix checkout dir? I may have more cargo cult tips if that does not work :) <ChocolettePalett>Btw, how should GNU/Guix users turn off their PC? Via halt or shutdown? Maybe poweroff? <janneke>ChocolettePalett: there's no poweroff on my system? as to whether to shutdown or halt: <janneke>/gnu/store/nl0948z46yndpx3kihhi540l5c422wv4-shepherd-0.10.0/sbin/halt <janneke>i guess you can safely choose any ;) <ChocolettePalett>Ah, okay then, this sounds much less controversial than those opinions from the Internet <mekeor[m]>ChocolettePalette: i use "loginctl poweroff", iirc <jpoiret>csepp: did you update your system and user profiles as well? <jpoiret>we never managed to get to the bottom of this specific issue, most of the time upgrading all profiles would solve it. I think one library isn't in the shell and gets picked up from the system-wide profile, which is linked with an older libc <Parnikkapore_m>I might be trying to package something that requires downloading two separate source tarballs. How do I do that? <mekeor>Parnikkapore_m: wildly guessing, write a package for one source, and use it as dependency in the other package :D <attila_lendvai>Parnikkapore_m, i think i've seen somewhere an origin entry in the inputs <mekeor>it'd be nice if there was something like ripgrep for s-expressions <janneke>Parnikkapore_m: with gexps this has become easier, grep for '#$(origin' <Parnikkapore_m>I knew there's gotta be a really easy way to do it with gexps haha, thank you so much! <f3n1x>hi guixers ! ... newbie here. I work with hugo web framework. I've downloaded it as a binary. Placed it into '/opt '. The /opt/ folder is in my $PATH by means of ~/.config/guix-home/.bashrc . When i run 'hugo' it doesn't work though . What am i missing ? <cbaines>f3n1x, normally this is because the binary has a hardcoded linker, which doesn't exist <f3n1x>Oh... ah. Dunno what a hardcoded linker is... On the other hand, this setup is working in another machine, here at home. By the way, if i run '$whereis hugo' i get <f3n1x>'hugo: /opt/hugo/bin/hugo /opt/hugo' <f3n1x>Any hint is more than welcomed ! <HiltonChain[m]>f3n1x: As a temporary solution, you can build hugo locally and it would work. <cbaines>f3n1x, you can see (and change the interpreter) with patchelf, e.g. patchelf --print-interpreter $(type -p guile) <f3n1x>ACTION is gonna try to build hugo locally ! <cbaines>HiltonChain[m], ok, the linker shouldn't be a problem then <HiltonChain[m]>Oh, I made a mistake! Hugo has an extended builfd tag which requires CGO_ENABLED=1, variant with this tag is dynamically linked. <zamfofex>Conversely, you can invoke the linker yourself! <lw>How do I build `vterm` in Emacs, with guix? <lw>-- The C compiler identification is GNU 4.3.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed <lw>I get a compiler error <lw>I'm trying to spawn vterm inside emacs. It asks me to build it <lw>I was not successeful using the guix install emacs-vterm. I seem unable to use it inside Emacs <lw>i don't know if it's a bug. I'm uncertain of how I should use `emacs-vterm`. Currently, I'm using (package! vterm) to install it inside doom emacsen <jlicht>lw: What does `guix shell --container emacs emacs-vterm', and then `TERM=xterm emacs' in that shell, do? Can you M-x vterm in that emacs? <jlicht>ACTION is too slow at typing again :) <lw>`guix shell emacs emacs-vterm -- emacs` works fine <lw>will I have to run that commands everytime I'm opening emacs? <lw>just `build` it, and works afterword <lw>How your emacs builds looks like? Do you have a one-liner which install everything you use? <lw>What do you mean buy guix "home"? <johnabs[m]>Hi all, I asked here recently about an issue with building xmonad and ld not being able to find librt due to an update in glibc (I think) and the subsequent gcc-toolchains. Has anyone else managed to find a way to deal with this, per chance? <pkill9_>im running guix on fedora, and when i run quasselclient from guix it doesn't use a dark theme whereas native fedora one does, i'm wondering what might be causing it not to do so, anyone know why this might be? <pkill9_>oh, it needs qt5 style plugins i think, which appear not to be packaged in guix <HiltonChain[m]><johnabs[m]> "Hi all, I asked here recently..." <- The packaged xmonad has substitute atm. Do you mean another one? <lw>HiltonChain[m]: No problem :) <lw>How can I get the complete guix documentation inside emacs? <johnabs[m]><HiltonChain[m]> "The packaged xmonad has substitu..." <- It's possible I'm using the incorrect terminology: I have the xmonad substitute installed; however, I need to run xmonad --recompile to get my configuration working every time an update is installed. For this, it requires both xmonad, (and xmonad-contrib), but also gcc-toolchain to build the new file that is run when xmonad is called. For right now it is "working" but none of my <johnabs[m]>configuration settings are reproducible, and when I try to rebuild my config, I get the error from ld that -lrt is missing. I hope that clarifies things, and that it makes sense :) <HiltonChain[m]>librt is from glibc, can you try again with this package in you profile? <lilyp>Is there a magic trick in guix graph to cut the graph at a certain point? <foxfromabyss>hey :) i have managed to install emacs 30.0.50 with tree-sitter on one of my devices with GuixSD. But I can't manage to reproduce the installation on either of the devices for `emacs-next-tree-sitter` and end up getting 29.0.91. Am i missing something? <lilyp>30.0.50 was tailing the master branch when emacs-next had version 29.0.90 <lilyp>They got unified for 29.0.91 <lilyp>Note that it ought to have tree-sitter still :) <lispmacs[work]>does anybody want to push my awesome new package patch I uploaded a few days ago? <lispmacs[work]>I marked it as severity "normal" but I meant to select "top priority drop everything else you are doing" <mirai>lispmacs[work]: unless this is some encoding trickery, you have @@url <mirai>in the description, it should be @uref{…} (or @url{…}) <lilyp>I don't think we need to link to the wikipedia article on HTTP, an @acronym would work <lilyp>You are free to revise descriptions <lispmacs[work]>lilyp: is "@acronym" a form of some kind, or you mean just use the acronym <lilyp>@acronym is IIRC the correct texinfo markup for acronyms <lilyp>I do confuse it for @abbrev all the time tho, so make sure to watch the log from make :) <civodul>sneek: later tell attila_lendvai re disabled Shepherd services, could you please email bug-guix stating how to reproduce the problem? i'm happy to take a look afterwards, time permitting! <mirai>lilyp: @abbr is for things like Mr <mirai>re serializer-kwargs, is serializer-options really the way to go? It is used as (apply serializer field-name value serializer-kwargs) <mirai>options seems to imply either some sort of "global state" <lilyp>at the very least, the kw is misleading <wheref>I'm getting a remounting permissions error <lilyp>I personally also prefer actual nouns over abbreviations where possible (args) <lilyp>perhaps "serializer-details" is a better name? <civodul>wheref: hi! the guix-install.sh script, if you fetched it today, installed the SELinux policy <wheref>civodul: ah-hah thank you. any lead at all is great <mirai>lilyp: yeah, kw wasn't the best choice here <mirai>in theory serializer-rest / -rest-args would perhaps be truer though I think it sounds cryptic <mirai>to a newcomer perhaps, no idea for “seasoned” schemers <lilyp>see my point regardig abbreviations <lilyp>those are fine for saving space in a paper or describing mathematical workings, but neither applies to the name of a field <wheref>civodul: nice thanks! that does it <lilyp>use a proper word that signals purpose <mirai>I wasn't sure if serializer-rest-arguments would have been refused on grounds of length but ok <johnabs[m]><HiltonChain[m]> "librt is from glibc, can you..." <- Right, so what happened was that librt was merged into glibc, and now LD can't find the librt.so.1 files (I think, jpoiret and I discussed this a bit) but the problem is that now all gcc-toolchain versions available rely on glibc 2.5 (I think) so even if I install the new version, would gcc-toolchain be able to see that correctly? <lilyp>mirai: again, the point is not to write out "arguments" but to give it a quick and snappy name that needs no abbreviation <lilyp>both "options" and "details" would serve that purpose and are no harder to write than kwargs <mirai>lilyp: what do you think about -rest-arguments? <lilyp>hi, scheme implementation sitting on Java, how verbose are you? <lilyp>how about -last-argument-to-apply? <lilyp>now that's both verbose *and* cryptic :) <lilyp>sorry for the snark, I tend to get salty when I feel that folks don't read what I'm writing <mirai>I was thinking on what other shorter names would best express -rest-arguments but wasn't having much success <mirai>between details and options I prefer options though <lilyp>what is even expressed in "rest-arguments", though? <lilyp>imho, "argument" has no meaning, whereas "option" or "detail" does <csepp>jlicht: i did a clean rebuild of it with make -B guile, it didn't change anything, trying jpoiret 's suggestion to upgrade everything <sneek>Welcome back csepp, you have 1 message! <sneek>csepp, jlicht says: Can you try clearing "./guile" in your guix checkout dir? I may have more cargo cult tips if that does not work :) <csepp>jpoiret: oh i forgot, i can't upgrade because of that libffi version conflict that i made a bug report about that no one replied to :/ <csepp>propagated glib fricking everywhere <csepp>okay, what the hell, it says i have two different version of eog, but display the same version twice with the conflict being tracked to libffi????! <csepp>so there are a few things wrong here <mirai>lilyp: I've finished applying changes based on your feedback, thanks for the speedy review <mirai>I've also went ahead and patched the jami-service to reflect the newer changes <mirai>not yet, running a final "make clean + check" to ensure that things are really properly working <csepp>okay, libffi thing solved, somehow guix upgrade was picking the wrong versions, i figured it out by exporting a manifest, editing out the versions, and installing that manifest <apteryx>mirai: if the jami tests are good, then it's probably OK :-) <jpoiret>csepp: nice! do you know if that solved your issue? <ngz>I only briefly tested new updater behaviour, which is to also update inputs, but for the time being I am under the impression that it somehow gets in the way. <ngz>But I may have been unlucky about the packages I tried to update. <rekado>ngz: you can control the behavior with new package properties <rekado>the idea is to improve the importers to a point where they only need minor to no hints to do the right thing <rekado>I used the new updater behavior for my recent mass update of CRAN packages and it worked pretty well <ngz>There are glitches, tho. For example, it turned (inputs (list bash)) into (inputs (list)). <rekado>yes, that’s because it cannot remove the whole field. <rekado>(I had the same issue and asked civodul about it) <johnabs[m]>Hi all, any ideas on how to make librt accessible to ld for an xmonad recompile process? I just want to make sure my prior questions didn't get lost as I'm completely stuck 😅 <apteryx>mirai: be sure to test the jami-provisioning-partial test <apteryx>the jami service does something not too common which is to lower the record objects into the builder and working with these there, including the unset values <cwebber>got a pinetab2 and didn't realize we were ordering something so *brand new*! I wonder how hard it will be to get guix running on it... I'd definitely love to run Guix on it if I can. I'm not sure if the pine64-image-type works with the quartz64 <cwebber>I guess I'll give it a shot and see what happens <davidl_>when is the wip-postfix branch gonna land in master? <davidl_>or, rather what remains for it to be merged? <mirai>apteryx: ah, I only did tested with "make check" <lilyp>mirai: don't forget to update the test for "kwarg-config" accordingly. I'd do one function with an #:optional argument and another with a keyword <Guest28>if I have an custom channel, how can I test it quickly without committing to it and running guix pull= <mirai>lilyp: the test happened to be really a keyword test so I didn't change it <mirai>is there really a need for an #:optional argument test though? <mirai>the macro doesn't really care what you put within the list, since it ends up being used within an apply <lilyp>that's the point, though, it shouldn't be limited to keywords only and optional arguments ought to be received faithfully <lilyp>you could do a mix of optional and keyword arguments too <mirai>the serializing procedure could take 3 or 99 mandatory arguments and as long the list is of adequate length it will work as well <lilyp>you probably ought to test those once with a provided and once with a skipped optional now that I think about it <mirai>won't that be a test on what (apply …) does though? <lilyp>not sure whether mandatory arguments would be helpful, but you might want to think about the error that occurs when applying an empty list <lilyp>surely that ought to be a configuration error caught earlier, no? <mirai>I feel such tests would be whether guile's (apply …) works as intended or not <lilyp>though for now we can leave mandatory args as UB and do with optionals/keywords <VesselWave>Guest28: use `-L ~/path/to/channel` to guix install, shell, build etc. <lilyp>I'm not sure whether I can share that sentiment <cwebber>lilyp: I... don't think I've ever run into this somehow. <mirai>I'm thrown off by it as well <mirai>certainly not what I'd expect from whatever I've read on it <Guest28>VesselWave thanks, now it says that "no code for module (my-channel packages test) <mirai>(apply (lambda (x) x) '()) is treating '() as if it were end of arguments? <VesselWave>Guest28: You should have a path relative to what you specify in -L. So if your file is ~/dir/dir2/dir3/file.scm and -L is `~/dir/dir2`, you should have (define-module (dir3 file) on top of the file <mirai>though I don't see why it would be relevant since apply is guaranteed to receive 2 mandatory arguments <mirai>that is, field-name and value <mirai>the serializer-options is the last argument to appear within the (apply …) call <lilyp>(apply (lambda (field val i-really-need-this-value-tho) ...) "hello" "world" '()) <mirai>I guess you could creatively devise serialize-<type> procedures that take one or none arguments if you tweak the transducers <VesselWave>Guest28: I guess you should just put (packages test), without my-channel <mirai>that would raise an exception since the serializer doesn't get what it wants <lilyp>true, but it'd also be a case of bad serializer design as opposed to optionals or keywords is my point <graywolf>Hi, just reporting that I got duplicite item in RSS feed of Guix blog. It seems entries were updated and now end with // (...for-gnu-guix//) instead of / (...for-gnu-guix/). Not sure if it was intentional. <lilyp>if you have a serializer with a mandatory third argument, you basically always have to provide that argument with next to no real indicator that you can do wrong at compile time <mirai>perhaps I'm misunderstanding but what scenario should be covered with a test as well? <lilyp>Test 1: (lambda (field value #:optional something) ...) <lilyp>Test 2: (lambda (field value #:key something) ...) <lilyp>Test 3: (lambda (field value #:optional something #:key some-other-thing) ...) <lilyp>for instance, section specifiers in ini fields could easily be #:optional <mirai>What is to be tested here and where will this take place? <lilyp>whereas quoting styles and other fluff could be #:key (there are different ini formats out there) <lilyp>"What is to be tested here" serializer-options? <lilyp>"Where will this take place" In exactly the same file that has the kwarg test right now, but using consistent vocabulary <mirai>Won't the test boil down to whether (apply serializer name value '("foo")) and (apply serializer name value '(#:section "foo")) are working as intended? <lilyp>isn't that what the current test does in a limited form? :) <mirai>by limited you mean the presence of #:section? <Guest28>VesselWave hmm, now it says it can't find the value and I should import the module I already imported <mirai>it's just a symbol like any other (I think), it could have been @loofus or *:strange-thing:* (provided the serialize-type procedure has the right signature) <lilyp>by limited I mean that it only checks the keyword case <lilyp>I argue that for INI sections #:optional with a default would be a better pattern <mirai>if a (define-config foo …) were to provide unexpected data like (serializer-options '(#:section "foo" "what is this")) ? <lilyp>are you deliberately missing the point? <lilyp>Test 1: (lambda (field value #:optional something) ...) <lilyp>Test 2: (lambda (field value #:key something) ...) <lilyp>Test 3: (lambda (field value #:optional something #:key some-other-thing) ...)