IRC channel logs


back to list of logs

<civodul>Hello Guix!
<mbakke>Hi civodul ! Sorry for going AWOL, I needed a break and then real life got to me. I'm back to being a friendless geek this weekend :)
<mbakke>How is core-updates doing?
<civodul>heya mbakke!
<civodul>heheh :-)
<civodul>i haven't paid a lot of attention to core-updates this week!
<civodul>i think we still need to fix the ICU-related build issues
<civodul>perhaps just by using an older version of ICU
<civodul>an example is evolution-data-server
<civodul>i think that's the main blocker
<civodul>ACTION goes for lunch
<mbakke>Alright. I'll get on it this weekend, hopefully we can merge shortly.
<wingo>guix's profile building phase is terribly slow on this old spinning-rust machine
<jlicht>hi guix!
<civodul>wingo: that's i/o intensive, so definitely slower on spinning disks :-/
<civodul>at least the man-db part is a bit faster now
<civodul>heya jlicht!
<wingo>but i am thinking it should still be faster, dunno
<wingo>well, will look into it some other time
<civodul>the man-db part you mean?
<wingo>the whole thing
<civodul>ah yes
<civodul>well yes, it should be faster, but i'm not sure how to make it faster
<civodul>the man-db thing has to traverse and uncompressed 19K files in my profile, for instance
<wingo>19k files!!!! wow
<catonano>hi jlicht !
<civodul>wingo: i guess 'man-pages' brings a lot of them, plus probably some library that has one man page per function
<civodul>it takes 10-20 seconds, depending on whether the cache is hot
<wingo>civodul: maybe packages can build a mandb when installing their man pages, then when building a profile we just have to union those sqlite databases; dunno :)
<civodul>wingo: could work, though every package would then depend on gdbm
<civodul>rekado: re sqlite, i sometimes get "database is locked" errors
<atw>Just finished booking everything for FOSDEM! I hope to see some of you there!
<civodul>atw: yay, nice!
<civodul>so you're coming on the Friday event as well?
<atw>If there's room! Sorry it's so last minute
<civodul>atw: it should be fine, you can add your name on the wiki page
<amz3>is there anything to know regarding gdb and debugging c code? I can't figure how to get the debug symbols on gnunet using this recipe
<wingo>grafting '/gnu/store/h717cbb8n2vx0b6mr8xcj60m6h7g421p-texlive-texmf-2017' -> '/gnu/store/i9vsn629aklbd4hf4m2adr9f3na41mjk-texlive-texmf-2017'... khaaaaaaaan
<bavier`>lol :)
<rekado>“Star Trek: Wrath of Khan”, Kirk marooned on a planet by Khan
<ng0>yes... but I don't see 'khan' in the graft
<rekado>Kirk listens to Khan explain his evil intentions
<rekado>Kirk gets angry
<rekado>Kirk barely holds himself together, then erupts: “Khaaaaaaaan!”
<buenouanq>let's start having #guix movie nights :3
<ng0>ahhh, right
<ng0>it's been too long for me
<rekado>I feel similar anger and frustration and helplessness when dealing with texlive-texmf.
<rekado>civodul: aha, “database is locked” is what I expected to happen.
<adfeno>Every time I see people talking about Star Trek, I am always reminded of Star Wreck and their reboot
<ng0>bring back the days of 1.38 MB tarball series
<civodul>rekado: so apparently it's ok to have several open connections within the same process
<adfeno>The first version of the Star Wreck was very funny, also a legally shareable movie. ;)
<civodul>rekado: but "database is locked" is about conflicts apparently:
<civodul>so i'm thinking about having a database fiber and serializing all db accesses
<civodul>but i'm not sure if we need to go this far
<adfeno>... I don't know about the second version, but from the screenshot that is in their blog, it seems awesome
<rekado>isn’t there a blocking wait?
<ng0>now that Disney has Star Wars, maybe we get an R2D2 movie.. watching episode IV, the '77 one, right now
<rekado>ACTION just read the explanation
<rekado>can we avoid this with transactions?
<civodul>no idea, i'm quite clueless
<civodul>what would you suggest? :-)
<rekado>I’m not in the position to suggest anything, because in the past I always “solved” this problem by switching to postgres ¯\\_(ツ)_/¯
<rekado>civodul: there’s a write-ahead-log mode:
<rekado>“writes are all sequential” and “WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.”
<civodul>what line of code do i need to write? :-)
<civodul>ACTION is pretty much in stackoverflow mode :-)
<civodul>now i can feel what it's like to be a normal programmer using mainstream software
<rekado>“PRAGMA journal_mode=WAL;”
<civodul>excellent, thanks!
<rekado>note that we might still run into SQLITE_BUSY errors in some cases.
<civodul>well, we'll see
<rekado>(section 8 on that page)
<rekado>I don’t know if we use exclusive locking mode. I guess we don’t.
<rekado>the third point is about crashes, so I want to ignore it.
<rekado>I don’t understand the second point, because I don’t know what “database” means here.
<rekado>I think it’s worth a try.
<cogrendel>When developing packages to contribute back to guix do you all configure guix to build from a local development checkout of the guix repo?
<rekado>That’s what I do. You can use “./pre-inst-env guix” to use the local checkout and otherwise use just plain “guix”.
<cogrendel>rekado: What do you mean by "./pre-inst-env guix"?
<rekado>in a configured and compiled local checkout you will find a script “pre-inst-env”, which you can use to tell Guix to prefer the modules from the local checkout.
<cogrendel>Ok, thanks rekado
***MinceR_ is now known as MinceR
<dustyweb>ACTION really needs to figure out why the guix-el interface broke for them
<civodul>how did it break?
<dustyweb>I guess only M-x guix-all-available-packages broke...
<dustyweb>I wonder
<dustyweb>if I do know why :)
<civodul>perhaps *Guix REPL* has hints?
<wigust>dustyweb: Also could you spot an error message in the 'echo area' or in <C-h e>?
<civodul>ACTION realizes there's an insane amount of RAM on
<civodul>ACTION .oO( let's keep writing brute-force code )
<wigust>dustyweb: What about *Guix Internal REPL*?
<dustyweb>wigust: like running the command it's complaining about from there?
<wigust>dustyweb: It's a buffer
<dustyweb>wigust: it wasn't showing any errors but it had a prompt
<dustyweb>it looks based on the output like it had an error in taking the output and running that regex on it
<dustyweb>guessing by the *Backtrace* output?
<dustyweb>oh weird
<dustyweb>wigust: I think here's a hint
<dustyweb>I ran guix-geiser-eval-read in edebug
<dustyweb>and it stopped in the middle of evaluating (guix-geiser-eval str repl) with a message to the minibuffer... "Stop"
<dustyweb>wigust: my guess is it took too long..
<wigust>dustyweb: Do you interrupt it?
<dustyweb>wigust: nope
<wigust>dustyweb: You could see if does it do something with evaluating in *Guix Internal REPL* the (package/output-sexps "/var/guix/profiles/per-user/cwebber/guix-profile" 'output 'all-available '() '(superseded known-status package-id id name version output installed synopsis))
<dustyweb>wigust: my guess is if I up geiser-connection-timeout
<dustyweb>it'll be fine
<wigust>dustyweb: Will blown up you Emacs though for some time
<dustyweb>wigust: yeah I tried that and it ran fine
<wigust>dustyweb: geiser-connection-timeout is interesting, let me know how it goes please :-)
<dustyweb>ACTION setq's and waits :)
<dustyweb>wigust: that fixed it!
<dustyweb>wigust: I set it to 100000 ... 100 seconds :)
<wigust>dustyweb: cool, great to know about this variable, thx
<dustyweb>wigust: so you could also supply a higher value:
<dustyweb>geiser-eval--send/wait takes a timeout value
<dustyweb>wigust: so you could possibly set something higher ;)
<dustyweb>but maybe you shouldn't :)
<dustyweb>I dunno :)
<wigust>dustyweb: Maybe for guix-all-available-packages this should be greater by default
<dustyweb>wigust: yes
<dustyweb>wigust: I'm on an old machine but I'm not sure if it's my profile making it slow
<dustyweb>or if just that guix has so many packages now..
<dustyweb>wigust: so what would happen if one of the synopsis fields had #t or #f in them? ;)
<dustyweb>would the regex replace it?
<wigust>dustyweb: ¯_(ツ)_/¯
<wigust>ACTION not that much deep into this
<dustyweb>ACTION debates the ethics of packaging emacs-magithub for guix
<civodul>dustyweb: guix-all-available-packages is also relatively slow for me!
<civodul>like 5 seconds or so
<civodul>it used to be faster
<dustyweb>civodul: I guess it was over 30 for me... default timeout was at 30s
<dustyweb>on the one hand, my new job has me using github a lot, and I'd rather not leave emacs
<civodul>actually it's even more than 10 seconds
<dustyweb>on the other hand, I'd rather not encourage others to use github necessarily
<dustyweb>I guess we have youtube-dl
<dustyweb>but I don't know if it's the same
<civodul>though whether or not this package is available won't have much impact on github usage
<civodul>and indeed, it's similar to youtube-dl
<civodul>per the FSDG there's no problem with that, i think
<civodul>wigust: any idea about the guix-all-available-packages slowness? should we discuss it with alezost?
<dustyweb>well, it's either I package it and do it locally only or I push to guix
<dustyweb>and if I don't push it to guix I guess that makes others have to reproduce that work
<dustyweb>until we get channels that is :)
<wigust>civodul: I thought it's supposed to be slow :-) But 'time env GUIX_PACKAGE_PATH= guix package -A &>/dev/null' shows otherwise.
<wigust>civodul: I don't think it's a good time to spend, but it's a good TODO someday.
<civodul>dustyweb: i guess you could submit it for Guix proper
<civodul>wigust: nothing's really supposed to be slow :-)
<civodul>we should investigate at some point
<dustyweb>civodul: Cheibriados disagrees!
<dustyweb>ACTION puts on Hat of Pondering
<dustyweb>(Dungeon Crawl Stone Soup jokes...)
<apteryx_>dustyweb: that could be caused by files being auto compiled instead of interpreted
<dustyweb> context
<apteryx_>I had that problem at some point and there was an action taken on emacs-guix side to make sure that the guile processes would use the --no-auto-compile flag (or similar)
<civodul>apteryx_: i thought it might be due to auto-compilation but no, it's slow for me as well
<civodul>things like guix-search-by-name are fast
<apteryx_>Will guix gets slower as slower as packages pile up?
<apteryx_>I wonder if Guile can compete with database software ;)
<civodul>apteryx_: heheh, that's the question! :-)
<civodul>i don't think we'll have problems in the foreseeable future