IRC channel logs

2021-05-03.log

back to list of logs

<daviid>wingo: my appologies, commit 19f38a3 fully fixes bug#47084 - i mistakenly thought it didn't, because in my wip-3.0 branch, I forgot to revert my own temporary patch for the re-export-public-interface macro - and the good news is ... G-Golf now works with 3.0!
<daviid>wingo: this said, it triggers 'new' warnings - like WARNING: (guile-user): imported module (g-golf) overrides core binding `map', for-each' and `connect', i am not sure how to best deal with this problem - hints welcome
<daviid>so, wrt these 'new warnings' - no such warnings when using guile 2.2 - related to module-use! (you need guile >= 3.0.6.1-19f38a to try) that replace core binding(s), I don't see any possibility to 'prevent' them, and the only way to silent those is to call default-duplicate-binding-handler and remove warn-override-core and warn from the list
<daviid>here is an example, will paste in a min
<daviid> https://paste.debian.net/1196087/
<wingo>daviid: glad things are working for you :) regarding the warnings, see "Add #:re-export-and-replace argument to `define-module'" in NEWS
***apteryx is now known as Guest15199
***apteryx_ is now known as apteryx
<meo>any reason why I shouldn't override a constructor generated by sfri-9 define-record-type?
<meo>i have a record of foo bar baz cat, but baz and cat during initialization depend entirely on foo and bar
<rekado>meo: you can override them. What I normally do, though, is to leave the plain constructor be, don’t export it, and export a ‘smart’ constructor that wraps the plain constructor.
*wingo does the same
<meo>makes sense
<meo>is it the convention that record accessor names must mention full record type name?
<leoprikler>Indeed, that is the convention.
<leoprikler>but if you have a different convention there is nothing keeping you from using that instead
<meo>and how does one generally deal with deeply nested structures? my guess would be macros?
<rekado>for nested structures you may find guile-lens to be of interest
<rekado> https://gitlab.com/a-sassmannshausen/guile-lens
<meo>thanks!
<abralek>Hi, I am trying to test an actor I wrote with 8sync. I created another probe actor to send messages to the main one. A problem I am having is that when I want send a *cleanup* to the main actor (server) from the probe, I am getting a backtrace from 8sync/agenda.scm with (select (#<closed: file 7fac07ff6460>) () () #f #f)
<abralek>Here is a snippet I wrote https://paste.debian.net/1196108/
<abralek>And here the backtrace https://paste.debian.net/1196109/
<abralek>Am I doing something wrong here or it's a bug? I kinda see that we not suppose to give closed files to select.
<abralek>How I could or should properly initiate a graceful shutdown?
<lampilelo>since streams can be infinite why do they cache all computed values? wouldn't it fill the memory eventually?
<lampilelo>in the spec there's only one period between words "infinite" and "cached"
<lampilelo>am i doing doing it wrong if i run into corner cases every time i try something new?
<leoprikler>lampilelo streams can still be infinite if you discard (and gc) the heads
<lampilelo>right, what a brainfart
<davexunit>it would be cool to see a stream implementation that kept the api the same but did some magic under the hood to avoid boxing every single value. too much overhead and garbage.
<leoprikler>don't you have that boxing as a part of delay/force though?
<leoprikler>or "pseudo-delay"/"pseudo-force"
<davexunit>yeah I dunno how to do it but as-is streams are mostly a fun toy that can't be used for anything that needs to perform well
<davexunit>I bet if you compared them to generators in other languages they wouldn't stack up too well
<dsmith-work>{appropriate time} Greetings, Guilers
<dustyweb>hi
<dustyweb>did (compile ...) disappear from the standard environment?
<dustyweb>where do I access it from these days?
<dustyweb>(compile '(+ 1 2) #:from 'scheme #:to 'tree-il)
<dustyweb>not workin'
<dustyweb>in 3.0.5
<dustyweb>hm, found it through a source grep
<dustyweb>(use-modules (system base compile))
<leoprikler>davexunit: come to think about it, how do they perform compared to generators in Guile? :P
<lampilelo>test-out-of-memory fails for me on guile 3.0.6, what's up with that?
<davexunit>dustyweb: try importing (system base compile) ?
<daviid>wingo: ok, thanks, I was aware of #:re-export-and-replace, but didn't think i had to use it in a module that calls module-use! (my mistake) ... but if i do that in foo, that module-use! (srfi srfi-1) - as an example - and say re==export-and-replace for-each, then a module or a file bar.scm that import foo and calls for-each 'stops' triggering the warning indeed
<daviid>wingo: the question is how to keep these modules def so users may either use 2.0, 2.2 or 3.0 ...
<dustyweb>davexunit: yeah, for whatever reason I thought it was in the default environment
<dustyweb>seems I was wrong ;P
<davexunit>dustyweb: it may have been. never used it.
<civodul>lampilelo: hi! test-out-of-memory fails in a non-deterministic fashion it seems
<civodul>we skip it in Guix for that reason
<lampilelo>civodul: yeah, it complained it can't finalize a thread or something because it has no memory so i disabled it too to check the rest
<lampilelo>i guess it's tricky to test memory limits because there's no memory for the test to recover
<civodul>lampilelo: yes, exactly
<civodul>well i didn't investigate much, but i suppose that's what happens
<lampilelo>thanks for confirming i'm not the only one having this issue
<civodul>wingo: you'll love that one: https://sourceware.org/pipermail/gdb-patches/2021-May/178438.html :-)
<civodul>wingo: and this one too https://issues.guix.gnu.org/48114#4 (unrelated)
<civodul>libunistring being too smart
<dsmith-work>Hey. Where'd the bot go.
<dsmith-work>Can anyone give me a time when the bot left?
<dsmith-work>(I don't have join/leave in my scrollback)
<pkill9>what's the name of the bot?
<lampilelo>sneek
<dsmith-work>Ah, sorry. Have a habit of saying "the bot" instead of the "sneek". So the bot doesn't mistake my command for a command.
<dsmith-work>s/instead of the/instead of the nick/