IRC channel logs

2019-08-10.log

back to list of logs

<chrislck>dynamic-wind: what an odd name. is this a scheme-terminology?
<chrislck>or this has anything to do with civil engineering?
<rekado_>chrislck: I think it’s related to unwinding the stack.
<jcowan>chrislck: When you call a procedure, you do some things like pushing the return address and registers on the stack, which is called "winding up the stack", when you return from the procedure, you "unwind the stack" to undo those things. Dynamic-wind gives the programmer control of winding and unwinding in a dynamic extent of the program's execution.
<jcowan>Conventional programming languages with try-finally statements let you get a grip on unwinding, but those languages don't allow "rewinding" as Scheme does with call/cc.
<chrislck>jcowan: thank you :) not obvious from manual
<jcowan>Sure. What are elders for, especially elders who know how to persuade Google to cough up the history? :-)
<spk121>jcowan: mostly, as an old coder, I just yell "you kids, get off my lawn" or "back in my day"
<jcowan>That gets, er, old. Anyway, having an 11-year-old living with you does wonders for your emotional flexibility.
***amiloradovsky1 is now known as amiloradovsky
<chrislck> https://www.gnu.org/software/guile/manual/html_node/Control-Mechanisms.html#Control-Mechanisms sounds partly like Engineering lol... Computational Fluid Dynamics
***lispmacs` is now known as lispmacs
<lispmacs>hi
<lispmacs>I embedded guile into a C application that uses pthreads
<lispmacs>if I run scm_call_2 on an scm procedure from within the main thread, it works fine
<lispmacs>but if I try to pass to call that procedure from another thread it segfaults
<lispmacs>like, I store the scm procedure in a global variable during the main thread, and then try to scm_call_2 it from another thread
<lispmacs>is there something I've got to do prep the call for running safely in another thread?
<lispmacs>hmm, found the Multi-Threading section in the documentation, maybe Ill find the answer there
<notnotdan>lispmacs: you need to call scm_with_guile in the thread before doing anything
<notnotdan>dunno if that's the problem you are having but i got bitten by that at some point
<notnotdan>aahh i should pick up my Guile bindings to TIC-80
<lispmacs>notnotdan: with the API I'm working with, the API creates the thread, and then just runs a procedure I pass it a few thousands times a second. does it hurt anything to call scm_with_guile more than once in a thread?
<lispmacs>reference manual seems to indicate that is not a problem
<zhlyg>wouldn't it be enough to prime the stack during thread creation?
<lispmacs>zhlyg: well, I'm working with an SDR API which creates the thread, so I can't do that at thread creation, only when my procedure is called
<lispmacs>but it seems that just scm_init_guile from my procedure is working fine. according to the reference manual, if I call the function repeatedly it does nothing after the first time it is called
<lispmacs>hopefully there is no significant hidden performance penalty
<lispmacs>WHA HA HA, it's ALIVE!!!
<zhlyg>lispmacs: it should be cheap because it just pushes a GC marker on the stack and calls your function. Though I could be wrong.
<nly>hi janneke
<nly>emacsy documentation requires one to build hello-emacsy.c.x ... which further down the line requires "freeglut". guix has freeglut 3.0 where this is a non issue, but debian has a diff version as told by someone who tried to build emacsy there. workaround: Configure has a new flag "--without-examples"
<nly>and commented '@verbatim emacsy/hello-emacsy.c.x' something part in doc/emacsy.texi
<nly>is this okay?