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 [email protected] _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
