<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 :) <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 <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 <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 <wingo>but i am thinking it should still be faster, dunno <wingo>well, will look into it some other time <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 <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>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 <wingo>grafting '/gnu/store/h717cbb8n2vx0b6mr8xcj60m6h7g421p-texlive-texmf-2017' -> '/gnu/store/i9vsn629aklbd4hf4m2adr9f3na41mjk-texlive-texmf-2017'... khaaaaaaaan <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 barely holds himself together, then erupts: “Khaaaaaaaan!” <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>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 <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? <rekado>I’m not in the position to suggest anything, because in the past I always “solved” this problem by switching to postgres ¯\\_(ツ)_/¯ <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>note that we might still run into SQLITE_BUSY errors in some cases. <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. <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. ***MinceR_ is now known as MinceR
<dustyweb>ACTION really needs to figure out why the guix-el interface broke for them <dustyweb>I guess only M-x guix-all-available-packages broke... <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 berlin.guixsd.org <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? <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>and it stopped in the middle of evaluating (guix-geiser-eval str repl) with a message to the minibuffer... "Stop" <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 <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>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 ;) <wigust>dustyweb: Maybe for guix-all-available-packages this should be greater by default <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? ;) <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! <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 <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 <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 :-) <apteryx_>dustyweb: that could be caused by files being auto compiled instead of interpreted <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