<sneek>hendursaga, you have 1 message! <sneek>hendursaga, daviid says: guile also reads, if it exists, $prefix/share/guile/site/init.scm <dsmith>hendursaga: If $prefix was set to $HOME/.local at ./configure time, yes. <daviid>hendursaga: youcan verify what $prefix is bound to for your system calling pkgconfig <hendursaga>daviid: yeah I'm just going to go with ~/.guile, I use asdf-vm, so... <daviid>hendursaga: fine, $prefix/share/guile/site/init.scm is for 'multiple users' config ... <daviid>hendursaga: pkg-config guile-3.0 --variable=prefix <str1ngs>hello, I have this thing that's been bothering me with geiser and guile 3 . If I'm working on a module file and evaluate the buffer none of the bindings complete, nor do the used modules. I have to go into the modules space with ,m using the geiser guile REPL? It did not do this before with guile two? I'm assuming it's guile 3 related. It's kinda annoying. Is there a way to get it to work like it does with guile 2? <ArneBab>drakonis: it is there when I am logged in. Seems someone shadowbanned be. I’m spontaneously inclined to say something impolite (but won’t). ***Fulax` is now known as Fulax
<pflanze>Hi. Is there a form like `time` somewhere that allows me to get execution timings for an expression from the repl? <dokma>leoprikler: I've managed to fix that guile bug I was harassing you about. <dokma>leoprikler: the stop-server-and-clients! thingy <dokma>I should probably submit a bug with a fix somewhere... <leoprikler>does it require a patch or was it something else? <leoprikler>oh, yes, IIUC one of bug-guile or guile-devel accepts patches, dunno which one <dokma>The thing though is that I've started with scheme a few weeks back and I don't know if my fix is even remotely reasonable. <dokma>It's just a few lines of code. <dokma>I can explain the problem and my fix. It's rather simple. <dsmith>dokma: When/If you do decide to submit a bug report... <leoprikler>i.e. use a paste service like debpaste or gnome paste <dokma>This is the entire modified file. I will also paste a diff so you guys can see the changes. <dokma>How many lines is ok to paste directly into #guile ?đ <dokma>leoprikler, sneek, dsmith: ^^^ <dokma>The bug was caused by stop-server-and-clients! cancelling it's own thread before shutting everything else down due to the fact that it just blindly went over *open-sockets* closing everything in the order reverse to how it was opened. <dokma>So if I called stop-server-and-clients! from the last connected client it would kill it's own thread first and not close anything else. <dokma>So my solution was to simply push the thread from which the stop-server-and-clients! was called to the end so that it is canceled last. <dokma>With this patch everything is shut down as cleanly as possible. <leoprikler>okay, but surely there are simpler solutions that achieve the same result, right? <dokma>Again, I'm a noob in scheme. <dokma>And I had to learn a chunk to scribble that. <dokma>leoprikler: I had to move modification of *open-sockets* to lower level because that was the only place where I had enough context to determine if I needed to close the thread or push it back <dokma>What would you suggest here? <dokma>You have to be more explicit with me... <leoprikler>you can just simply split stop-server-and-clients! into two procedures <leoprikler>the first one claims the lock and rearranges the sockets to close, and the inner one loops over them <leoprikler>why would you want to reverse the cdr over and over again? <dokma>how will you rearrange the sockets at that level when the information which socket is from the current thread is not present there? <dokma>at least I think it is not... <leoprikler>another option would be to close the ports first and cancel the threads afterwards <dokma>still you have to make sure to cancel the controlling thread last. this way you do both. <leoprikler>i mean, you could just arrange to call the shutdown process in a dedicated thread to begin with... <dokma>just invoke stop-server-and-clients! from a new thread should work! <dokma>that way even the old code should work! <dokma>will try that with the old code <leoprikler>friendly reminder, that you should monitor those threads on the server side separately to check whether all threads really get cleaned up (including the cleanup thread)