IRC channel logs


back to list of logs

***kmic is now known as kmicu
<_amz3_>héllo guix
<_amz3_>nobody had the time to look at my pathc :/
<_amz3_>at least it's not lost :)
<ewemoa>_amz3_: i looked at the interactive output :)
<ewemoa>the force layout was nice and bouncy
<ewemoa>installing graphviz now so i can try the patch
<ewemoa>looking at the dependencies of qsynth...makes me think twice about installing it :)
<ewemoa>but i guess i should try with other packages to get a relative sense
<_amz3_>yes the force layout is fun
<_amz3_>the output only list package inputs, not native inputs. I think that ruby is missing from the graph for instance, it only installed for building but still
<_amz3_>The problem is pulling Qt, which is IMO badly packaged. It embeds all webkit which itself embeds some other stuf
<_amz3_>packaged upstream
<_amz3_>I'm not even use qsynth use webkit but you still need to download it
<_amz3_>s/I'm not even use/I'm not sure that/
<_amz3_>the force directed layout requires tuning. It open the page and now the graph holds still, there plenty of space, but nodes are regrouped so that it's not possible read or know how much nodes are grouped together
<rekado>_amz3_: iyzsong suggested on the mailing list to split Qt into packages for each of its modules. I quite like the idea.
<rekado>_amz3_: I'm pretty sure qsynth does *not* use webkit, nor pulseaudio.
<rekado>it's just a GUI for fluidsynth, which does the audio work.
<_amz3_>btw rekado what do you think about my diagram, do you think about a way to move it to guix or guix-web, so that it's helpful?
<rekado>_amz3_: I had difficulties seeing labels in the diagrams.
<rekado>I think an advantage of js-based diagrams is that the "root" could be variable.
<rekado>In my dream dependency graph I could fade details in and out and re-root the graph around any component I choose to click on.
<rekado>currently, I think the graphviz graph thingie is sufficient and I don't yet see any advantage of the js-implementation over the former.
<_amz3_>I need to improve the js output, because right now it's readable
<ewemoa>my screen is not wide enough to comfortably look at the results for icecat :)
<_amz3_>I was thinking about a ascii output, I'm not sure whether it can helpful be made helpful
<_amz3_>the dot output is rather large
<_amz3_>ewemoa: use some png2ascii program ;)
<ewemoa>_amz3_: heh...i don't read braille ;)
<iyzsong>I use 'connect-to-guile' in Emacs to get a Guile REPL, but type a simple expr (eg: just '1') will give many levels backtraces (',error' report "Unbound variable: ge:get-warnings", "Wrong type to apply: "/run/.../guile", etc.). Is this normal?
<ewemoa>iyzsong: i started guile at the command line like: guile --listen then from emacs i did M-x connect-to-guile and was able to enter 1 without any errors
<iyzsong>ewemoa: I did the same, but get "$4 = 1" with [5] levels backtraces :-(
<iyzsong>And log form 'geiser-show-logs':
<iyzsong>oops, our geiser package have scheme files in '/share/geiser/guile/geiser'. not in my load-path
<ewemoa>iyzsong: hmmm...i also get $4 = 1 w/ [5] in my prompt but i thought that was ok -- oops :)
<iyzsong>ok, so we does add it to 'geiser-guile-load-path' in '/etc/emacs/site-start.el', but this only work for Guile spawn by geiser.
<iyzsong>alezost: hi! I sent a patch for symlink geiser's guile modules to guilesitedir, though I now find that the 'geiser-scheme-dir' should do the right thing. But it doen't! My Emacs report it as '/run/current-system/profile/share/emacs/scheme'.
<iyzsong>I think the right value should be '"/gnu/store/...-geiser-0.7/share/geiser"?
<alezost>iyzsong: hi, I think that it's intended for 'geiser-scheme-dir' to point to that 'scheme' dir
<alezost>it is based on 'geiser-elisp-dir', no?
<iyzsong>but this directory doesn't exist, and in 'geiser-install.el' it was set to '/gnu/store/...'. I wan confused :-
<iyzsong>This make the manually started Guile REPL server (eg: by 'guile --listen' in xterm) failed to work with geiser.
<_amz3_>I don't use connect to guile except with sly
<alezost>iyzsong: sorry, I don't use geiser from guix, so it's hard for me to tell what it should be, but I think now I see what you mean: "geiser-install" sets 'geiser-scheme-dir' to the proper "/gnu/store/..." value, and "geiser.el" sets it to improper value
<alezost>iyzsong: I think the problem is that "geiser.el" defines 'geiser-scheme-dir' as a constant, so the proper value set by 'geiser-install' is overrided
<iyzsong>alezost: yes, I now just add '(require 'guile-install), it works now.. thanks!
<alezost>iyzsong: perhaps "site-start.el" should be adjusted to (require 'geiser-install nil t) instead of (require 'geiser-guile nil t)
<alezost>I'm not sure though as I don't use "site-start.el"
<iyzsong>I think the same, will post to ML.
<_amz3_>totem works like a charm :)
<_amz3_>rekado: your article about guix is nice (
<_amz3_>I like it :)
***hopses is now known as hospes
***nully_ is now known as nully
***hopses is now known as hospes
<civodul>Hello Guix!
<mark_weaver>hi civodul!
<mark_weaver>we're quite close to being able to merge core-updates now, I think.
<civodul>anything specific we need to fix before that?
<mark_weaver>in fact, we could probably do it right now
<civodul>let's go then! ;-)
<civodul>mark_weaver: can you do it?
<mark_weaver>the problem with nettle will have to wait until the next cycle, obviously
<mark_weaver>will do
<mark_weaver>I had just merged master into core-updates, and there weren't any new commits to master in the meantime, so evaluation 104998 of core-updates is now at the same commit as current master.
<mark_weaver>here are the remaining issues:
<mark_weaver>8 newly failing jobs, and 13 newly succeeding jobs
<civodul>not so bad!