IRC channel logs

2020-11-02.log

back to list of logs

***catonano_ is now known as catonano
***apteryx is now known as Guest85966
***apteryx_ is now known as apteryx
***civodul` is now known as civodul
<lloda>what would cause the Guile REPL do do filename completion instead of the normal command/identifier completion?
<mwette>lloda: Do you have an ~/.inputrc file? maybe a readline option
***hugh_marera_ is now known as hugh_marera
<lampilelo>TIL guile uses longjmp for non-local exits, so c++ destructors aren't being be called
<lloda>I don't mwette
<lloda>it's bizarre because it only happens from the embedded REPL, in plain Guile i get the normal completion
<lloda>i've wished before to have filename completion and now i have it when i don't want it :-(
<leoprikler>so, how did you end up getting filename completion?
<mwette>(ice-9 readline) does export make-completion-function. Is there something in ~/.guile ?
<wingo>lampilelo: yeah. i feel like we should document that better.
<wingo>i.e. for c++ embeddings, either don't have data with destructors on the stack if guile can throw, or otherwise you need a kind of DynamicWind<> template or so that will call the scm_dynwind functions to ensure the destructor runs
<dsmith-work>Monday Greetings, Guilers
<prussian_blue>oh what's this about destructors? I feel like I should investigate this ..
<leoprikler>That makes some kind of sense for unwind, but I feel like one would be hopelessly lost in the rewind case.
<leoprikler>IOW I feel as if scm_dynwind_unwind_handler (MyObj::~MyObj, myobj, 0); is the only meaningful interaction for C++ code, which could probably be abstracted into scm_dynwind_destructor<T>(T obj);
<leoprikler>Well, T& obj actually
<lampilelo>wingo: i made a custom unwind handler that calls destructors on non-local exits and just install them like other handlers
<lampilelo>it*
<wingo>leoprikler: you can prohibit rewinds
<wingo>i think that's probably what you want to do
<wingo>rewinding through c++ is probably a bug farm. from guile's POV it doesn't matter of course, but from POV of what C++ programmers expect, it's... unexpected!
<lampilelo>when you call scm_dynwind_begin with 0 flag it should prohibit rewinds
<wingo>yep
<leoprikler>wingo: Reminds me of that one talk about exception handling with optionals. "You can't expect the unexpected."
<lloda>leoprikler: I don't know how it happened. I didn't do anything. I had to kill gnome for some reason and then it was like this :-(
***jonsger1 is now known as jonsger
<str1ngs>daviid: Hello. I mailed some patches to guix to upgrade the nomad stack, this includes g-golf. Pending review guix g-golf declaration will be at 0.1.0-839.ef83010
<daviid>str1ngs: great, tx
<manumanumanu>ArneBab: regarding foof-loop: I am pushing something to a repo tonight. foof-loop is already plenty fast. What I have written is a very modified foof-loop with support for subloops, and with added restrictions that that adds.
<manumanumanu>I also removed the while and until clauses and added when and unless
<manumanumanu>and added break clauses.
<manumanumanu>The problems have been the following: accumulating clauses needed to be distinguished from regular for clauses to play well with subloops. That also means that regular for- and with-bindings are _not_ visible in the final expr. Since a loop with a subloop can exit in the outermost loop, the bindings in the innermost loops are not visible there. Thus, this is restricted for regular for clauses, but not
<manumanumanu>accumulating clauses.
<manumanumanu>Almost all of this in syntax-rules. ultra-oof.
<manumanumanu>ArneBab: I am currently thinking about one thing... Currently I want to distinguish between accumulating and driving clauses (loop ((:for driving-clause (in-list lst)) (:acc accumulating-clause (listing (+ 1 driving-clause))) => accumulating-clause). Distinguishing them means I could add finalizers for for-clauses, but I am not sure I think it is a good idea. The only thing I see that could use in is a
<manumanumanu>potential (in-file ...), but I am not planning to implement any support for controlling non-local exits using dynamic-wind, so I am not sure I want to.
<manumanumanu>so there are two major regressions compared to foof-loops: only accumulators are visible in the final expressions, which in turn means: no way to finalize regular for-clauses. in-file is thus not possible.
***V is now known as ^
***^ is now known as V
<manumanumanu>ArneBab: https://git.sr.ht/~bjoli/goof-loop
<manumanumanu>Lots of bugs still. Maximum subloops depth is 2, and named update is buggy. Small changes.
<leoprikler>inb4 hoof-loop