<daviid>str1ngs: hello! g-golf imports, automatically, all and every class (and methods, class methods, interfaces ...) that appears in the class precedence list of the class(es) your are importing/using, so yes, Gio is almost always imported, at least partially; <daviid>str1ngs: using 2.2.7, you shouldn't do anything 'specific' wrt setenv, unless you'd want to of course, but there is no need to add setenv to %gi-method-short-names-skip (and not map, for example) <daviid>str1ngs: when a guile core method is 'promoted' as a generic function, the core procedure becomes the default method (the last one in the describe list ...) - I'm assuming that is what you see whe you refer to Method #<<method> <top> 557569863b80> <daviid>str1ngs: now, both re-exporting the public interface of a module and this setenv 'problem' example (which is only an example, there are many others we could have spoted and used to fix ..) are both very related, although not triggered by the exact same piece of code - and both needs to be fixed 'outside g-golf', the problem has nothing to do with g-golf <daviid>*when a guile core procedure is 'promoted' as a generic ... (if it is a method, then it is not promoted, there is already a generic, g-golf just adds another mthod to it ...) ***apteryx is now known as Guest35916
***apteryx_ is now known as apteryx
<wingo>had a week at the beach. optimistically i took one (1) paper to read -- i read about 25% of it :P <wingo>back at work after parental leave etc <civodul>i'm good, had long holidays and read zero papers :-) <wingo>i did manage to land a guile thing tho, "case" dispatch is no longer O(n) in number of datums :) <wingo>yeah even symbol dispatch is hash-based <civodul>that happens at tree-il or cps level? <wingo>and binary search for sparse datum sets <wingo>with the recent match fixes, it means some match clauses get compiled to jump tables <wingo>need another fix to match compilation to get more cases tho <civodul>faster case/match makes us all happier <civodul>do you know what impact this had on the speed on the compiler itself or that of "case-heavy" benchmarks? <wingo>civodul: didn't have time to check; it's on my list <wingo>for the compiler itself it's neutral <wingo>because it doesn't take much time to run, but the match limitations mean that it recognizes fewer cases as optimizable <wingo>could be more of a win once the long clauses in (language cps compile-bytecode) become optimizable <civodul>i need to catch up on these match issues <wingo>i am writing a paper about it <wingo>will have a bit more time over the next month, hope to finish that writeup then <wingo>there are some interesting optimizations that we do that appear to actually be novel, and that even gcc/llvm don't do <civodul>it's definitely worth writing about it <wingo>hehe i agree, the only question is where and how ;) will see soon ***terpri__ is now known as terpri
***ftknox_ is now known as ftknox
<civodul>wingo: it seems we never incremented "serial" in guile.m4 in recent years <civodul>which encourages aclocal to ignore and keep using old copies :-) <civodul>well we can make it serial 11 this year :-) <wingo>my irrational instinct is that it sounds great to have an optional dep but not to rely on libevent <wingo>asking just because you know of more fibers uses, and also because it affects how easy it would be to add fibers to guile, if we ever wanted to do that <wingo>(i have no idea whether that's a good idea) <civodul>i'd say that if keeping the non-libevent code is "cheap", then it's ok to do so <wingo>but to your mind it should be possible to run without libevent? <wingo>my lizard brain thinks that way but i don't trust it! <civodul>you mean would it be possible to avoid libevent on macOS? <wingo>no i mean, on gnu/linux, we shouldn't require libevent <civodul>i mean the epoll code is already there anyway <civodul>so the question is whether to add a libevent backend vs. replace epoll with libevent, right? <civodul>now, the other aspect to consider here is getting the person who contributed this code on-board :-) *chrislck having parental leave too o/ <wingo>dsmith-work: weird, dunno what the deal is <str1ngs>sneek later tell daviid. I was just explaining how setenv was both related and not related to the guile 3 issue. It's still an issue for me in regards guile 2.2.7 and I will be using %gi-method-short-names-skip with setenv. The issues being I rather be explicit when it comes to setting environment variables. ***terpri__ is now known as terpri
<manumanumanu>wingo: regarding libevent on osx: Nobody likes osx kqueue. It is buggy like a dead pidgeon that has been lying in the sun for a week. Congrats, btw! First kid? <str1ngs>dsmith-work: thank you. much appreciated . <dsmith-work>manumanumanu: "buggy like a dead pidgeon that has been lying in the sun for a week" Gotta remember that one. <manumanumanu>dsmith-work: true story: I had to scoop a dead, decaying pidgeon from the rooftop outside my work window today. I mistakenly thought it would be an easy match. I got out with a shovel in one hand, a plastic bad in the other. A minor touch to the pidgeon and it rolled over, exposing decaying flesh full with flies and maggots and a smell that wasn't of this world. The comparison is, believe it or not, actually <dsmith-work>That kind of stuff has a way of reaching deep into the nostrils, grabbing something, and pulling hard. <manumanumanu>The guy overlooking the operation actually barfed, and he was standing 3 meters away. Inside looking though a window. <manumanumanu>It makes it to the top 3 most disgusting things I have ever done. When the memory fades I might reconsider the unfairness of the comparison to kqueue though, but that is mostly because of life time lost due to kqueue on mac behaving badly. <manumanumanu>A digression! Back to hacking on the most expressive looping facility syntax-rules can provide! foof-loop will pale in comparison! <manumanumanu>(it will not, but I will add some syntactic comfort to foof-loop for subloops and lazy loops) <dsmith-work>Ok. The bsd folks seem quite pleased with kqueue. Maybe that depends on who you talk to. <manumanumanu>bsd kqueue is fine. The lifetime lost was on porting a simple piece of code to mac. It just wouldn't work. I stared at it for weeks, and tried a gazillion things. I had my freebsd friend look at it telling me it was fine. In the end a mac developer told me "oh, yeah. It is broken. You need an extra select.". <manumanumanu>this is a long time ago when I actually believed I knew C.