<sneek>I've been running for 25 days <sneek>This system has been up 27 weeks, 9 hours, 27 minutes <dsmith>Is Tobias Geerinckx-Rice in here? <nckx>Wha's with the legal name? <dsmith>nckx: Hey, sent a patch for bug#53201 <dsmith>My silly webmail intergface probably horked it <nckx>But I'm 100% unfamiliar with the Guile code base. <dsmith>Bah. Initial whitespace is messed up. <nckx>Or what the process is to get it upstreamed. <nckx>Since the context is equally messed up it didn't register :) <dsmith>Nice relaxing bug. Hopefully the guile devs will be inspired and apply a proper fix. <rvs314>Hi - could someone help me identify if a surprising behavior is a bug or not? <rvs314>When I run a file for the first time, it runs properly, but running it a second time gives a variable not found error <rvs314>I think it's related to the cache: when I clear it or edit the file so it forces recompilation it runs properly again <dsmith>rvs314: A thing to do is try and pare things down to the smallest thing that still shows behavior. <dsmith>rvs314: Just doing that might make the problem pop out at you. <dsmith>rvs314: At least you will have what's needed for a good bug report. <rvs314>dsmith: thanks for the advice. The error seems to trigger when a module both imports and exports a GOOPS method at the same time. This makes any child of that module unable to find the given method. I'll try to write a bug report <daviid>rvs314: this is very likely not a guile bug, but a misunderstanding on your side, how the guile module system and goops work/don't work 'together', that led to a bug in your code, but to confirm this, you'd need to (tor friendly) paste a snipset so we can reproduce, look at it and propose a way to solve the problem <daviid>rvs314: and tell us what version of guile you are using as well <rvs314>I'm using guile 3.0.7 as packaged by debian <rvs314>At least on my machine, the error shows up even when using #:duplicates (merge-generics) <rvs314>Running C.scm runs correctly the first time, then fails a second time <daviid>rvs314: i can't see the paste, can you use debian or gnome, and select scheme, the cde will also nicely be rendered <rvs314>daviid: tell me if that one is better <daviid>rvs314: though in the module (c), you'd need to re-export ex-method so that you could use it in the repl... [and in other modules that would use (c) ...] <rvs314>daviid: thanks, changing the export to re-export seems to fix the issue. However, is the current behavior correct? It seems counterintuative that importing a module removes bindings provided by another module. <daviid>rvs314: i have limited time to help you, but this is a basic module/name space problem, most guilers here are able to help, i hope someone will chime in .. mean while, carefully read/study this section - 6.18.3 Creating Guile Modules - and mean while, just take it as a fact that export creates a new binding, full stop, it does not try to see if ... it just creates a new binding, and adds the symbol name to the list of the public <wingo>civodul: good morning :) got very little time today but regarding bignums/inline digits, your latest test indicates an improvement i think, relative to 3.0.7 (./pre-inst-env time -f '%U seconds\n%M KiB' /data/src/guile-3.0/meta/guile -c '(use-modules (system base compile)) (compile-file "gnu/packages/crates-io.scm" #:optimization-level 1 #:opts (list #:inlinable-exports? #f #:resolve-free-vars? #f))) <wingo>civodul: i assume your pre-inst-env was setting GUILE_INSTALL_GMP_FUNCTIONS=1 or whatever ? <wingo>i.e., just to make sure we were testing the fast 3.0.7 configuration <wingo>(will be good when that option is gone) <wingo>for guile itself i need to fix reproducibility. i think to do that i will somehow compile module/ twice, once gathering inlinable exports and once actually doing cross-module inlining (but in a way that only adds the former .go files to the load path) <wingo>so i will remove collection of inlinable exports from -O1. <wingo>not sure what the impact of resolve-free-vars is on perf, should be relatively small, but it's not very useful if we aren't collecting inlinable exports so will remove that too <wingo>civodul: at that point i think 3.0.8 should be good for guix, wdyt? <civodul>wingo: hi! good point, i was testing 3.0.7 with the defaults, so equivalent to GUILE_INSTALL_GMP_FUNCTIONS=1 i think? <civodul>reproducibility is a big issue for me <civodul>it was already an issue in some cases due to non-deterministically generated gensyms <civodul>which we work around in Guix by building Guile sequentially <civodul>GUILE_INSTALL_GMP_MEMORY_FUNCTIONS=1 ./pre-inst-env time -f '%U seconds\n%M KiB' guile -c '(use-modules (system base compile)) (compile-file "gnu/packages/crates-io.scm" #:optimization-level 1)' <civodul>./pre-inst-env time -f '%U seconds\n%M KiB' /data/src/guile-3.0/meta/guile -c '(use-modules (system base compile)) (compile-file "gnu/packages/crates-io.scm" #:optimization-level 1 #:opts (list #:inlinable-exports? #f #:resolve-free-vars? #f)) <civodul>for this file, ~half of the time is spent in the scheme->tree-il phase <civodul>i'll try to come up with a clearer report soono <wingo>civodul: if you are investigating :) might want to also try a guile compiled with lto <wingo>just to see what happens. probably minimal impact, but who knows ***roptat is now known as Guest1151
<wingo>given the huge difference in libguile binary size there may be important inlines <zap>Hey! It isn't possible to have non-optional keyword args with define* right? <civodul>zap: hi! indeed, keyword args are always optional <zap>Hm.. But what is a prefered way to make a procedure that has lets say more than 5 parameters? When args are optional you have to write checks for #f <zap>one thing I like in javascript is is natrual to pass an options object that contains a bunch of stuff. In scheme its feels strange to have options assoc list or similar. <zap>is is natrual -> is that its <lloda>you can just put an (assert kwarg) inside the function if you want your kwargs to be non optional <civodul>or perhaps you need a record to bundle some of these parameters? <lloda>sorry that's what you said. i don't think there's a better ay <lloda>i use some syntax around alists that lets me do (obj (field value) ...) and then (obj 'field) <lloda>the problem with records is that you need to define a different one every time <zap>yea records! but.. yeah wihout yastnippet I'd feel lazy to define them frequently <wingo>you can use (lambda* (#:key (foo (error "missing #:foo"))) foo) <zap>lloda: your syntax sound good <wingo>like, error in the initializer <zap>wingo: ha this is cool idea <zap>what guilers think of applicative syntax by the way? <pinoaffe>zap: it looks really nice, I've been meaning to try using it ever since I found out lloda's newra supports applicative syntax <pinoaffe>I'm a bit concerned that it might obscure what's going on every now and then, and it might make it more difficult to reason about code <zap>only one missing from error-default argument approach is when you know semantics of define* you will be propted to think by geiser that arguments are optional and they will error in runtime <zap>pinoaffe: thanks for the link i've heard of lenses but didnt know about newra <pinoaffe>oh and semi-related: I feel a bit queezy about values as splice-in-place, since it changes the meaning of code one could meaningfully write in other schemes <zap>pinoaffe: I didn't get what do you mean by splice-in-place.. <pinoaffe>zap: in the love letter you linked, they describe a feature of s7 that is somewhat incompatible with other schemes <pinoaffe>zap: `(+ 1 2 (values 3 4))` is 6 in guile but 10 in s7 (if I'm not mistaken) <pinoaffe>zap: and `(let ((a (values 3 4))) (+ 1 2 a))` should be 6 in both guile and s7 <zap>pinoaffe: oh sorry! I've red this artle a long time ago :D I didn't know that this is a term from the article <lloda>i figured since fortran uses A(i) for arrays and no one ever has complained about it, it should be ok for scheme as well <lloda>i believe C added [] because of function pointers, but i might be wrong about that <zap>pinoaffe: I wonder why s7 didnt just choose other name for values <mwette>using foo(1) to be an array ref or a function call makes the parser not context-free <pinoaffe>lloda: i personally really like the applicative syntax for matrices, partly because i defined matrices as functions in my thesis <rlb>civodul: for now I'm just adding a ./configure check that fails if it detects a guile with the problem, though that's just so it can show a friendlier message describing the problem/fix. <drakonis>does guile have a build system written in guile yet? <drakonis>i guess it already exists but its not very widely used? <dsmith-work>I think you can configure gnu make to use Guile, but Guile itself doesn't use that feature. <dsmith-work>nckx: I have a better fix, along with an extra test. Will post it tonight. <dsmith-work>nckx: Oh, and about "legal name", that's the name I saw in your email. Didn't know your nick. <lilyp>drakonis: there is guile-hall, which creates a guix.scm and autotools stuff <lilyp>but other than that, I'd argue that Guile *shouldn't* reinvent build systems and package management (beyond what Guix does :P) <dsmith-work>Just imagine the frusration of not being able to build Guile becuse you don't have a working Guile yet. <nckx>dsmith-work: I was just curious how you knew my name & not my nick. Thanks again for the fix, I know nothing of Guile. <nckx>dsmith-work: What makes sneek welcome users on each join? Botsnacks? Anything else? ***Guest1151 is now known as roptat
<daviid>stis: fwiw, 3 tiposin the 1st sentence:) oppertunity, functoins, eny <drakonis>second paragraph: differnt, fourth paragraph: commig, fifth paragraph: buggs, langauges, mutatating, distiction, ore, onle and sixth paragraph: anoying <stis>daviid: did a speöll check on it <stis>daviid: what do you suggest? <daviid>don't you have any site on savannah, sourcehut, notabug ... besides i block anything 'gaagle' made, their pdf viwere is atotal disaster :) but that is not even the point, theytrack us... whichis unacceptable