[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts
From: |
R. Mattes |
Subject: |
Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts |
Date: |
Wed, 11 May 2011 19:56:51 +0200 |
On Wed, 11 May 2011 17:30:24 +0100, Richard Shann wrote
> > > More importantly the scm_take_from... need to revert to scm_from...
> > > in all cases. In the cases where the string being passed is freshly
> > > allocated (ie g_malloc'd) then call g_free() on it having created
> > > the scm_from... SCM structure.
> >
> > And dont' forget to register it with the dynamic context! ;-)
>
> it = the return SCM??? see above - do we need to do something to say
> that the SCM returned by our C primitive procedure (gsubr...) should
> be freed?
No, SCM values are taken care of by guile's garbage colector.
You only need to take care of heap-allocated resources not-SCM.
BTW, if you allocate something with g_malloc the corresponding context
registering should look like:
a_blob *my_thomething = g_malloc(sizeof(a_blob));
scm_dynwind_unwind_handler (g_free, a_blob, SCM_F_WIND_EXPLICITLY);
> >
> > > We can't exploit scm_take_from... (as
> > > I previously suggested) because it calls free() and glib is using
> > > its own memory allocator (so g_free() doesn't call free()). (So,
> > > another wild goose chase started by me I'm afraid :(
> >
> > Ah, good to know. Anyway, looking at scm_take_from... in Guile 2 there will
> > be no benefit performance-wise anyway.
> >
> > > It is only not crashing at the moment, because it seems scheme is not
> > > collecting its garbage...
> >
> > Have you tested with manual gc?
> No, I'm afraid I haven't done any coding for a couple of days, but I
> have realized as a result of all this that my treatment of the Undo
> stack in the case of a script throwing an error is unnecessarily
> elaborate, and I was just going to remove that and to deactivate the
> scm_take_ calls because someone could potentially download the source
> and compile on a system where guile would garbage collect with
> disastrous results.
I agree, scm_take_... sounds like more hazzle than it's worth.
RalfD
> > Cheers, RalfD
--
R. Mattes -
Hochschule fuer Musik Freiburg
address@hidden
- Re: [Denemo-devel] Midi shortcuts, (continued)
- Re: [Denemo-devel] Midi shortcuts, Richard Shann, 2011/05/11
- Re: [Denemo-devel] Midi shortcuts, Jeremiah Benham, 2011/05/11
- [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, R. Mattes, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, Richard Shann, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, R. Mattes, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, Richard Shann, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts,
R. Mattes <=
- [Denemo-devel] Patchset: denemo-specific guile load path, R. Mattes, 2011/05/14
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/15
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, R. Mattes, 2011/05/15
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/15
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/17
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/18
- Re: [Denemo-devel] Midi shortcuts, Nils Gey, 2011/05/07