IRC channel logs


back to list of logs

***DadeBonetti1 is now known as DadeBonetti
***apteryx is now known as Guest39774
***apteryx_ is now known as apteryx
<civodul>wingo: it looks like "dynamically-created" modules like don't play well with the new re-exports
<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
<dsmith-work>Morning Greetings, Guilers
<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 ..."
<civodul>sneek: seen mark_weaver
<sneek>I think I remember mark_weaver in (here?) 3 months ago, saying: :).
<rlb>wingo: regarding re-exports, I ended up adding this to silence some warnings.
<rlb>since I couldn't re-export-and-replace in the define-module form.
<leoprikler>kaletaa: scm_current_module
<kaletaa>not sure how i missed that, my bad
<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 :-)
<dsmith-work>Yes, the SMOP..
<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.
<dsmith-work>And there you would need to handle SIGWINCH
<opfez>ft: it's just for a tiny program
<ft>Ah okay.
<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
<dsmith-work>opfez: Note that they might not be set.
<opfez>dsmith-work: hey, they were! i can at least use this temporarily and find a more portable solution later, thanks!
<opfez>gtg,thanks again
<dsmith-work>opfez: Cool. glad to help
<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.