***DadeBonetti1 is now known as DadeBonetti
***apteryx is now known as Guest39774
***apteryx_ is now known as apteryx
<wingo>there are a few bugs regarding re-exports <civodul>in this case, if you have a file that just does (use-modules (gnu)) (pk delete), it fails with "delete: unbound variable" <civodul>where 'delete' is reexported by (gnu services) <wingo>is (gnu) dynamically created? <wingo>which module is dynamically created, here? <civodul>well, it's populated by calls to module-use! at run time <civodul>and i think that's what causing troubles <civodul>the (module-use! i (resolve-interface m)) bit above <wingo>i guess this is related to daviid's issue <kaletaa>hello - is there a way to retrieve the current module on the C side? <sneek>kaletaa, you have 3 messages! <sneek>kaletaa, mark_weaver says: run "guix package -i" as your normal user, not root. <sneek>kaletaa, mark_weaver says: "guix package -i" installs the programs in the profile of whatever user ran that command <sneek>kaletaa, mark_weaver says: to install packages in the "global" environment, which is only possible in GuixSD, add them to the 'packages' field of your OS configuration and re-run "guix system reconfigure ..." <sneek>I think I remember mark_weaver in (here?) 3 months ago, saying: :). <rlb>since I couldn't re-export-and-replace in the define-module form. <rlb>wingo: I'm somewhat wondering about our current perf and/or bootstrapping expectations, i.e. there are some string functions that might be simpler (and safer) in scheme, and with utf-8, some of the perf advantages in C are gone, i.e. no *O(1)* string-set! and, we might end up needing to allocate a temp vector anyway (say in string-map). Though I suppose we still have no way (yet) to avoid/elide a lot of redundant type checking from the <rlb>scheme side, and there might still be "more" garbage generated, even with some suitably crafted helpers. <dsmith-work>I just saw an annoucement for powerpc64le-linux guix. Does the guile jit support that now? <civodul>dsmith-work: not yet, and apparently it feels slow on that platform <civodul>t'just a matter of writing the lightening backend :-) <iv-so>afaik guile does not use gnu libjit, is there any particular reason? <opfez>hey does anyone know if it's possible to get the terminal size dimensions in guile? <opfez>can't find anything in the manual on it <wingo>iv-so: dependency size and churn rate. i am sure you could get better codegen using an external jit library, but i don't have the bandwidth for the maintenance costs <wingo>also, a desire to do AOT from scheme at some point <dsmith-work>opfez: You could check to see if COLUMNS and LINES are set in the environment. <dsmith-work>the resize program can set those. (is in the Debian xterm package) <opfez>dsmith-work: oh, as shell environment variables? <dsmith-work>I think it does some cursor movement and then reads back values. <dsmith-work>opfez: Yes. Though to set the values, your shell must eval the output. <ft>If the program is long running, a resizing terminal may pose problems with that approach. <ft>In those cases, maybe guile-ncurses can help. <opfez>ft: it's just for a tiny program <opfez>the best would be a wrapper function for ioctl() so i could just get the info from there, isn't there anything like that in guile? <opfez>but i'll try the env vars first <opfez>dsmith-work: hey, they were! i can at least use this temporarily and find a more portable solution later, thanks! <dsmith-work>I very often use a serial console on some embedded device, usually from some (x)term through ser2net, and screen dimentions are always wrong. Unless I use something like resize.