Re: [Denemo-devel] Midi shortcuts

[Richard Shann]

On Tue, 2011-05-10 at 23:39 +0200, R. Mattes wrote:
> On Tue, 10 May 2011 18:33:42 +0100, Richard Shann wrote
> > On Sun, 2011-05-08 at 11:39 +0200, R. Mattes wrote:
> > > BTW,  my code example is longer than it needs to be, there's no
> need
> > > to establish a dynamic context at all - I was fooled by the
> original
> > > code. No idea why there's  scm_dynwind_... at all. No need for it.
> > 
> > Jeremiah - Ralf is confirming my suspicions here - I think we should
> > simply be calling g_free() on the strings that we have created on
> the
> > heap. 
> 
> Yes. Guile won't free any memory you allocate in C.
> 
> > I am not sure what scm_dynwind_... is for, if it is doing anything
> > it is only saving us the effort of writing those g_free() calls 
> > before returning. 
> 
> It won't. Dynamic (un)winding has a different purpose. In a situation
> like the following:
> 
>  a_thing = alloc_new_thing();
> 
>  scm_eval_string();     <------- [1]
> 
>  free_thing(a_thing); <----- [2]
> 
> 
> The call in [1] transfers control to scheme. Now, in Scheme function
> calls might never return since it's always possible to do non-local
> exits
> (for example by call-with-current-continuation). So it's not
> guaranteed
> that [2] is ever reached. This might leak memory.
> Now scm_dynwind_ sets up an unwinding context. This is only a setup,
> you still
> need to register cleanup functions with that context. Now whenever
> scheme
> leaves this dynamic context by means of a non-local exit these
> cleanup 
> function are called (Richard, since you seem to have some Lisp
> bakground:
> this is the C equivalent of Common Lisp's unwind-protect).
> So, setting up a dynamic context without registering some sort f
> cleanup
> with it ( scm_dynwind_unwind_handler(a_thing) in my example) simply
> does 
> nothing (Hint: Guile has a very fine manual - Section 'Dynamic
> Winds'). 

Well, I found your explanation much clearer :) Thanks a lot for this -
it is the longjmp thing that I wasn't really taking on board.
Incidentally the Lisp I did was pretty simple stuff IIRC, something to
do with content-addressable image databases, nearly 20 years ago now...

Jeremiah - do you have time to pick this up again, the tidying up of the
memory leaks in view.c scheme stuff? There is clearly a completely
separate problem, I presume a memory leak in lilydirectives.c where just
enquiring about a non-existent directive gobbles memory. I'll look into
that.
Richard