IRC channel logs


back to list of logs

<chrislck>ok further adventures in warnings: previously we had lots of warnings (unbound-variables) that we've fixed by using modules appropriately. but there were also some (format #f "~d" ...) and macro warnings. these warnings have all disappeared.
***apteryx_ is now known as apteryx
<tohoyn>sneek, botsnack
<tohoyn>daviid: I get following warnings from g-golf:
<tohoyn>daviid: WARNING: (g-golf): `!direction' imported from both (g-golf hl-api gobject) and (g-golf hl-api function)
<tohoyn>daviid: WARNING: (g-golf): `delete' imported from both (srfi srfi-1) and (g-golf hl-api gobject)
<wingo>the md5 bug is fun
<wingo>the source has:
<wingo>(define f-add +)
<wingo>(define f-ash ash)
<wingo>(define (+ . args)
<wingo> (modulo (apply f-add args) #x100000000))
<wingo>(define (ash x n)
<wingo> (modulo (f-ash x n) #x100000000))
<wingo>you can't even compile the file twice, because the second time you compile it, + has the new definition :P
<wingo>cons that one onto "the top-level is hopeless" :)
<wingo>could probably write a warning pass to detect (define A B) (define B ...)
<weinholt>there is something for that in "fixing letrec"
<wingo>yeah but top-level definitions aren't currently always treated as the top-level letrec* expansion
<wingo>if we were sure to give something like the r6rs program semantics then it would be clearer
<civodul>wingo: that reminds me of
<civodul>might be the same issue?
<wingo>civodul: it's very similar!
<wingo>however even at -O0 you can't compile the file twice
<wingo>i.e. do (compile-and-load "md5.scm" #:optimization-level 0) twice in a row, then (md5-finalize (md5-init))
<wingo>it will hang
<wingo>because in the second compilation, + in the md5 module already has the new definition
<civodul>ah yes
<civodul>the approach used in that file was kinda risky in the first place :-)
<wingo>(i'm not sure precisely the mechanism for how it fails but already this error is.. not good!)
<wingo>so i think the pattern to detect would be when it can be proven that you are referencing a top-level variable which is defined later in the file
<wingo>*which has not yet been defined in the compilation unit, and which is defined later in the compilation unit
<wingo>*which does not have a top-level definition earlier in the compilation unit, and which does have one later in the compilation unit
<civodul>heh, that's a complex pattern
<wingo>not so bad
<wingo>relatedly i think weinholt is right, that there is a particular bug about referencing not-yet-initialized letrec bindings that could be caught by part of the fixing letrec translation
<wingo>which is i think why a single -O2 compilation shows buggy behavior
<wingo>whereas it takes multiple compilations for -O0 to show buggy behavior
<euandreh>Is there a way to produce a single file Guile executable?
<davexunit>euandreh: unfortunately, no.
<rekado>there’s the old self-extracting perl script approach, but it’s not pretty
<wingo>should make a guix pack option to make a single executable :)
<dsmith-work>Hey Hi Howdy, Guilers
<dsmith-work>sneek: botsnack
<civodul>wingo: actually AppImage is single-executable IIRC, so we could have a backend for that
<civodul>food for thought :-)
<ane>is it possible to get the documentation for a method?
<ane>as in via procedure-documentation
<ane>yes, if you can find the method via goops introspection
***amiloradovsky1 is now known as amiloradovsky
<leoprikler>ane: that + you can set the object-documentation for the generic function itself if you want to
<daviid>sneek: later tell tohoyn this is a sign that in the 'context' of the execution that triggers these warnings, you are not following the recommendations given in the manual wrt merging generics -
<sneek>Will do.
<daviid>sneek: later tell tohoyn I actually added a manual subsection for ths -