Excellent. That allows me to further develop my lib into a dummy proof tool.
Btw, what did you think of the demo? It needs the kinks ironed out, but it does go to show what Neko can do in the desktop market. I'm also looking at wxWidgets, now, as a GUI layer for this library. I know you said you'd prefer GTK+, but wxWidgets appear far simpler to use than the GTK+ library. Lee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Cannasse Sent: 24 July 2006 13:31 To: Neko intermediate language mailing list Subject: Re: [Neko] Silly question > Ok, this might seem a little stupid. Case scenario, I'm using a lib > that allows me to create a complex object which I wrap in an abstract > and pass to the handling Neko code. Problem is, this abstract value > requires cleanup (what abstract value doesn't), so a close function will > need to be called at some point. If I, instead, specify that the > abstract value is cleaned up after using val_gc( my_abstract, close ), > then does this handle calling the close function for me on this abstract > without my needing to worry about calling it myself... ie, when the Neko > code finishes executing? val_gc means that the finalizer function will be called "at some point" after the value has been garbage-collected. That means that although there is no real-time warranty, there will not be memory leak either in the long run. In your val_gc callback, you have nothing to do since your value is no longer accessible anyway, but if the "close" function is accessible directly by the user, you can do the following to ensure that any further usage of your object will not be possible : val_kind(o) = NULL; Nicolas -- Neko : One VM to run them all (http://nekovm.org) -- Neko : One VM to run them all (http://nekovm.org)
