IRC channel logs

2019-08-29.log

back to list of logs

<daviid>heya
<sneek>Welcome back daviid, you have 1 message.
<sneek>daviid, str1ngs says: I develop using autotool's but we try to keep a guix definition as a snapshot. so g-golf.scm is just there to be helpful for anyone using guix. I asked nly to seperate it encase at one point you wanted to snarf it for guix.scm.
<daviid>str1ngs: great!
<daviid>feel free to add a (gnu package g-golf) to guix, please don't name guile-g-golf
<nly>is there proc to tell if something is an atom/literal?
<mns>to use guile for scripting, is it possible to use #!/usr/bin/env guile -s and not have it complain about the missing !# ?
<peeterr>exit
<nly>janneke: there are some patches on new-mru
<nly>I started with fixing the mru bug, where the mru index would be out of sync with the buffer queue.
<nly>Soon, i was converting mru to functional style and then saw what broke and changed the broken piece as well.
<nly>these are very rough strokes.
<nly>i don't know when this ends lol
<nly>will guile accept a list->hook procedure?
<civodul>Guile is a nice program, we'd need to ask it :-)
<civodul>what would list->hook do?
<civodul>a hook is more like a procedure
<civodul>or a list thereof, that's what you mean?
<nly>it would compliment hook->list :)
<civodul>oh yes, that makes sense :-)
<civodul>i'd say why not!
<nly>i am decorating the local list->hook atm :)
<nly> http://nly.info.tm:9001/guile/list-to-hook.scm
<nly>proc: (list->hook <hook>)
<nly>well, it needs more work but i'll do it :) and then let's see
<nly> https://paste.debian.net/1097843/
<jcowan>There's now a draft SRFI for (unordered) hooks. I have just suggested list->hook and list->hook! on the SRFI 173 mailing list.
<nly>ah, nice
<nly>don't tell me you made it just now :)
<lloda>wingo: shouldn't disassemble-file take an optional port like disassemble-image and disassemble-program do
<wingo>sure, why not
<nly>thanks jcowan, srfi 173 will be nice
<lloda>wingo: patch is trivial, ok to push?
<wingo>plz do
<lloda>done
<civodul>wingo: in a declarative module compiled with -O2, can a global variable (not a procedure) "disappear"?
<civodul>i guess there several scenarios: if it's not set! at all in the module, and if it's set!
<wingo>civodul: in a declarative module compiled at -O2, no global "disappears"
<wingo>i.e. module-ref, @@, etc are able to access the same set of bindings
<wingo>at -O3 with the patch from yesterday, definitions that are not exported are not present in the module obarray
<wingo>in both cases if a variable is set! or otherwise multiply defined, it is not considered a declarative binding, so it still gets the box
<civodul>wingo: ok, that makes sense
<civodul>i'm usually quite disciplined, but maybe not always sufficiently for -O3 ;-)
<wingo>:)
<wingo>i think -O2 matches pretty well with current guile practice, and -O3 does not
<wingo>but contrary opinions v welcome
***karlosz_ is now known as karlosz
<daviid>1+ for autocompilation
<daviid>str1ngs: nice, more g-golf code in nomad ...
<str1ngs>daviid slowly but surely. I'm still reasoning how best to port somethings.