IRC channel logs


back to list of logs

<flatwhatson>are you working on the pbr renderer for chickadee?
<brendyyn>I just discovered that one can't nest defines inside a define-public. is there a particular reason for that?
<ArneBab>Are there existing implementations of the snow r7rs repository standard?
<ArneBab>(it does look a lot like Guix on the surface)
<wingo>good morning
<manumanumanu>Good morning!
<flatwhatson>ArneBab: maybe this?
***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 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
<tohoyn>s/be have/we have/
<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>via pk I can see:
<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>wingo: ah, figured it out
<dustyweb>it was in the cps section that it needed the chooser
<dsmith-work>Hey Hi Howdy, Guilers
<manumanumanu>hi-ho, dsmith-work
<dustyweb>I merged ijp's 2017 compile-to-js branch
<dustyweb>I can now compile (+ 1 2) to js ;)
<dustyweb>however more the amb.scm example ijp wrote out in his gsoc ending email no longer works, unfortunately
<dustyweb>I think "the land of cps" changed a bit
<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
<dustyweb>wingo: look forward to talking then :)
***Noisytoot is now known as Sigyn
***Sigyn is now known as Noisytoot
<dustyweb>oh wow
<dustyweb> is cool
*wingo going to merge cross-module inlining, la la la
<taylan>very cool
<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>and that one was fixed very recently
<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>this might break if you had nested tests
<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
<lampilelo>you're right
<lampilelo>in that case i think it's a cleaner design
*taylan goes to zzz
<sneek>up 1 week, 20 hours, 16 minutes
<ArneBab>flatwhatson: yes, like this — thank you!
<dsmith-work>Does anyone use snow?
<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
<ArneBab>dsmith-work: I don’t know