<brendyyn>I just discovered that one can't nest defines inside a define-public. is there a particular reason for that? <ArneBab>(it does look a lot like Guix on the surface) ***zap1 is now known as zzappie
<lloda>why is *random-state* a global var and not a parameter? <leoprikler>probably because making it a parameter would be unsafe when considering multiple threads <leoprikler>assuming you copied the state between threads, you'd inadvertently get the same result in both threads, which could be dangerous <tohoyn>file guile-3.0-uninstalled.pc.in is not used to generate a .pc file in meta subdirectory. is there some reason for this? if not I can fix it. <tohoyn>when we are in the uninstalled environment should be have guile-3.0.pc generated from guile-3.0.uninstalled.pc.in? <lloda>leoprikler: i don't follow, if you want different results you should restart the generator on each thread. Else you should be getting the same <leoprikler>you mean constructing one truely random random-state per thread? That might work, but I wonder how costly it'd be <manumanumanu>I don't think copying the random state so that individual parts of the program have the same state is a good default for randomness. <manumanumanu>However, doing it yourself would be pretty simple with the current API <manumanumanu>Just (copy-random-state), roll your own parameter-based solution and generate the same random numbers in different threads all day :) <leoprikler>right, state as function argument allows for such things <dustyweb>wingo: I'm attempting to un-bitrot ijp's compile-to-js branch <dustyweb>the main thing that I'm unsure what to do about is <dustyweb>system/base/compile.scm:245:17: In procedure failure: <dustyweb>multiple compilers; language should supply chooser <dustyweb>;;; (compilers ((bytecode . #<procedure compile-bytecode (exp env opts)>) (js-il . #<procedure compile-js (a b c)>))) <dustyweb>but it looks like tree-il/spec.scm *does* specify a #:compiler-chooser so I'm not sure what should be done? <tohoyn>wingo: I fixed the guile code so that file guile-3.0-uninstalled.pc is generated. are you interested? <wingo>not sure! there are a few things you need to get right to be able to use guile uninstalled and be sure not to load .go files from the installed dir <tohoyn>wingo: I rebuilt Theme-D to use the uninstalled guile. It seems to work. <dustyweb>it was in the cps section that it needed the chooser <dustyweb>I merged ijp's 2017 compile-to-js branch <dustyweb>however more the amb.scm example ijp wrote out in his gsoc ending email no longer works, unfortunately <dustyweb>it appears things fall apart converting between cps and js-il.scm <dustyweb>wingo: I think I may have reached the point where I'm going to need help <dustyweb>but I posted to the mailing list about my progress, and pushed the branch as it stands *wingo gtg, happy to give more feedback tomorrow ***Noisytoot is now known as Sigyn
***Sigyn is now known as Noisytoot
*wingo going to merge cross-module inlining, la la la <taylan>BTW I faintly remember a discussion long ago about supporting the .sld file extension. is there anything new about that? I think there were concerns about performance or something (lots of additional file-name lookups) <lampilelo>taylan: i was just reading your mails to guile-devel regarding srfi-64 <lampilelo>i see this implementation has the same bug as the reference implementation had until some time ago, if a global runner wasn't installed it installs what should be a temporary one, but doesn't uninstall it after the test is complete <lampilelo>this was fixed by a patch in the reference implementation some time ago, but that one broke it the other way, it instead uninstalled a runner unconditionally after the test, even if there was a global one already <lampilelo>taylan: at least i'm assuming you are the person who proposed new implementation, judging from the nick ***rekado_ is now known as rekado
<rekado>taylan: “.sls” is already supported. I don’t know of any discussion about .sld. <taylan>lampilelo: yes, it's me. can you elaborate on how exactly that constitutes a bug? i.e. what would be the motivation of explicitly unsetting the test runner again after test-end? <lampilelo>taylan: from the srfi-64 spec: "Additionally, if the matching test-begin installed a new test-runner, then the test-end will de-install it, after reporting the accumulated test results in an implementation-defined manner." <lampilelo>although i have to say this implementation doesn't have the other bug i was thinking about fixing upstream <lampilelo>the one that makes the test suite error out on test-group if you don't have a runner installed <taylan>lampilelo: interesting catch, I guess I can implement uninstalling the default runner to be fully conformant to the spec. <lampilelo>taylan: said that, i don't have any say on what gets to be included in guile, just pointing some stuff out, your code runs my tests as expected <taylan>lampilelo: the implementation is also part of my Scheme SRFIs project so I'll implement the fix either way :) <taylan>will have to send yet another updated version of the patches, LOL <taylan>lampilelo: do you think it would be correct if test-begin stored a flag "auto-installed" in the test runner when it auto-installs it, and test-begin checks for that flag, and sets the current runner explicitly to #f if that flag is set? <taylan>I'm trying to think if there's any situation in which it would be wrong to set it to #f, like if instead I have to keep a stack of test runners or something... <taylan>but since the auto-install behavior only happens when it was #f during test-begin, I think it should be fine to set it to #f after, given that said flag was set to indicate that it was, indeed, #f before. <lampilelo>i mean maybe not break, but it would install and uninstall a runner on every test in a test group, which would be a waste <lampilelo>taylan: my fix for the srfi-64 upstream was to install a finalizer with test-runner-on-final! when creating such temporary runner, i don't know if it's the best solution but it works with their implementation <taylan>lampilelo: when a nested test starts, the runner will not be #f, so it won't install a new one... but when the group ends, it will be deinstalled and that's clearly wrong, heh. <taylan>but yeah I can do it on the same condition as when on-final is called <sneek>up 1 week, 20 hours, 16 minutes <ArneBab>flatwhatson: yes, like this — thank you! <dsmith-work>"Scheme is like a ball of snow. You can add any amount of snow to it and it still looks like a ball of snow. Moreover, snow is cleaner than mud." -- Marc Feeley