<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>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> (modulo (apply f-add args) #x100000000)) <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 <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>because in the second compilation, + in the md5 module already has the new definition <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 <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? <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 :) <civodul>wingo: actually AppImage is single-executable IIRC, so we could have a backend for that <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 -