<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span><br></span></div><div><span>Oh whoops, sorry for the confusion. SFML is not my project; it's sort of like an SDL re-imagining:</span></div><div><span>  </span><a href="http://www.sfml-dev.org/">http://www.sfml-dev.org/</a></div><div><br></div><div>My own code that I referenced in the previous email is available here:</div><div>  <a href="https://github.com/sorlok/Dubious-Dabblings">https://github.com/sorlok/Dubious-Dabblings</a></div><div><br></div><div>In particular:</div><div>  <a href="https://github.com/sorlok/Dubious-Dabblings/blob/master/MapView/src/SFML_Engine.cpp">https://github.com/sorlok/Dubious-Dabblings/blob/master/MapView/src/SFML_Engine.cpp</a></div><div>  <a
 href="https://github.com/sorlok/Dubious-Dabblings/blob/master/MapView/test.pir">https://github.com/sorlok/Dubious-Dabblings/blob/master/MapView/test.pir</a></div><div><br></div><div>I should probably disclaim that this is my personal git repository, so I tend to push whatever I'm working on, even if it doesn't compile/work.</div><div><br></div><div>-->Seth</div><div><span><br></span></div><div><br></div>  <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <font size="2" face="Arial"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> "Jonathan "Duke" Leto" <jonathan@leto.net><br> <b><span style="font-weight: bold;">To:</span></b> S'orlok Reaves <sorlok_reaves@yahoo.com> <br><b><span style="font-weight: bold;">Cc:</span></b> "parrot-users@lists.parrot.org" <parrot-users@lists.parrot.org>
 <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, December 31, 2011 12:35 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Parrot-users] Use of vtable "destroy"<br> </font> <br>
Howdy,<br><br>Great to hear about you using Parrot. Is you code (libSFML) available<br>online somewhere?<br><br>Duke<br><br>On Thu, Dec 29, 2011 at 1:10 PM, S'orlok Reaves <<a ymailto="mailto:sorlok_reaves@yahoo.com" href="mailto:sorlok_reaves@yahoo.com">sorlok_reaves@yahoo.com</a>> wrote:<br>><br>> Thanks for your answer; it covers everything I was curious about.<br>><br>> Let me elaborate on my use case a bit:<br>><br>> I'm interfacing to a native library (libSFML), and I admit to not being very<br>> good at NCI. So what I did was wrap each function call in the simplest way<br>> possible. An example of this is sfml::Sprite::GetColor(), which returns a<br>> Color&. I chose to duplicate the return value and wrap it in a pointer:<br>><br>> //My function<br>> sf::Color* sprite_get_color(const sf::Sprite* item)<br>> {<br>>   sf::Color* res = new sf::Color(item->GetColor());<br>>   return
 res;<br>> }<br>><br>> ...and let Pointer PMCs do the rest:<br>><br>> .sub 'SPR_GetColor'<br>>   .param pmc item<br>>   .local pmc lib, func<br>>   lib = INT_GetDLL()   #Does what you think it does<br>>   func = dlfunc lib, "sprite_get_color", "pp"<br>>   $P0 = func(item)<br>>   .return($P0)  #$P0 is now dangling<br>> .end<br>><br>> There are several places in my PIR code where I, e.g., get the Color and<br>> check its blue component, which requires me to call "game_del_color()" (my<br>> own library function) to delete the dangling pointer.<br>><br>> I was thinking of making my own class "Color", and having it delete the<br>> library resource when it itself is collected:<br>><br>> .namespace ['Color']<br>> .sub 'init' :vtable<br>>   $P0 = #Get a pointer via SPR_GetColor()<br>>   setattribute self, 'colorPtr', $P0<br>>
 .end<br>> .sub 'destroy' :vtable<br>>   $P0 = getattribute self, 'colorPtr'<br>>   game_del_color($P0)<br>> .end<br>><br>> A bit convoluted, and perhaps there is already a better option? I was<br>> reading about "managed" structs (I think?), but there was a lot more glue<br>> code required in that article. In my case, library functions are simply<br>> loaded by name, and I prefer the simplicity.<br>><br>> In terms of liveliness, I really like the sound of that "timely destruction"<br>> that you referenced. It sounds sort of like what C# does, where<br>> newly-allocated objects are checked more frequently than long-lived ones.<br>> (As a side note, I really don't want to have to delete my objects manually,<br>> because the whole reason I'm working in PIR is to get decent automatic<br>> memory management.)<br>><br>> To use an example, the following should collect not long after
 the function<br>> ends:<br>><br>> .sub 'do_nothing'<br>>   .local pmc newColor<br>>   newColor = new ['Color']<br>> .end<br>><br>> Thanks again for your help. I would repeat that, for the most part, Parrot<br>> is absolutely lovely to work with, and I really appreciate all the effort<br>> that goes into its design.<br>> -->Seth<br>><br>><br>><br>><br>><br>><br>> ________________________________<br>> From: Andrew Whitworth <<a ymailto="mailto:wknight8111@gmail.com" href="mailto:wknight8111@gmail.com">wknight8111@gmail.com</a>><br>> To: S'orlok Reaves <<a ymailto="mailto:sorlok_reaves@yahoo.com" href="mailto:sorlok_reaves@yahoo.com">sorlok_reaves@yahoo.com</a>><br>> Cc: "<a ymailto="mailto:parrot-users@lists.parrot.org" href="mailto:parrot-users@lists.parrot.org">parrot-users@lists.parrot.org</a>" <<a ymailto="mailto:parrot-users@lists.parrot.org"
 href="mailto:parrot-users@lists.parrot.org">parrot-users@lists.parrot.org</a>><br>> Sent: Thursday, December 29, 2011 9:11 PM<br>> Subject: Re: [Parrot-users] Use of vtable "destroy"<br>><br>> Great questions. This is the kind of thing we should have more<br>> documentation on in the future.<br>><br>> The destroy vtable is called when the object is collected by the<br>> garbage collector. Because it is called during a sensitive point in<br>> the interpreter execution (in the GC, as the PMC is being destroyed) I<br>> wouldn't try to do too much processing in that vtable, but that's more<br>> of a hunch than an actual rule. Honestly, the destroy vtable is not<br>> used very often.<br>><br>> We used to have a notion of "timely destruction", or PMCs which needed<br>> to be collected as quickly as possible. That doesn't really work with<br>> our newest GC algorithm.  We don't have a way to manually
 destroy a<br>> PMC at the moment, but we could possibly add that in the future if<br>> there was a demand for it. The programmer would be responsible to<br>> guarantee that the PMC only had one surviving reference and that it<br>> was never accessed again after being destroyed, of course.<br>><br>> What is your use-case? What are you trying to accomplish with this? If<br>> we know a little bit more about what you need we can help find a good<br>> solution for you.<br>><br>> --Andrew Whitworth<br>><br>><br>><br>> On Thu, Dec 29, 2011 at 5:04 AM, S'orlok Reaves <<a ymailto="mailto:sorlok_reaves@yahoo.com" href="mailto:sorlok_reaves@yahoo.com">sorlok_reaves@yahoo.com</a>><br>> wrote:<br>>> Good evening,<br>>><br>>>       I'm having a hard time finding information on this: is "destroy" the<br>>> correct method to override if I want something to be performed whenever
 an<br>>> object is deleted? I did some searching through src/pmc/object.c, and<br>>> "destroy" was the only method that seemed relevant.<br>>><br>>>      If not, then what method should I use?<br>>><br>>>      If so, then I have a follow-up question: What are the guarantees of<br>>> object deletion? Will outstanding objects be deleted when the VM exits<br>>> normally? Is there any way to force an object to be collected/deleted at<br>>> some arbitrary point in time (e.g., when a function exits)?<br>>><br>>>     I checked through the Parrot docs, but couldn't find anything on<br>>> object<br>>> deletion. If I missed an obvious source of information, I apologize.<br>>><br>>> Thanks,<br>>> -->Seth<br>>><br>>> _______________________________________________<br>>> Parrot-users mailing list<br>>> <a
 ymailto="mailto:Parrot-users@lists.parrot.org" href="mailto:Parrot-users@lists.parrot.org">Parrot-users@lists.parrot.org</a><br>>> <a href="http://lists.parrot.org/mailman/listinfo/parrot-users" target="_blank">http://lists.parrot.org/mailman/listinfo/parrot-users</a><br>>><br>><br>><br>><br>> _______________________________________________<br>> Parrot-users mailing list<br>> <a ymailto="mailto:Parrot-users@lists.parrot.org" href="mailto:Parrot-users@lists.parrot.org">Parrot-users@lists.parrot.org</a><br>> <a href="http://lists.parrot.org/mailman/listinfo/parrot-users" target="_blank">http://lists.parrot.org/mailman/listinfo/parrot-users</a><br>><br><br><br><br>-- <br>Jonathan "Duke" Leto <<a ymailto="mailto:jonathan@leto.net" href="mailto:jonathan@leto.net">jonathan@leto.net</a>><br>Leto Labs LLC<br>209.691.DUKE // <a href="http://labs.leto.net" target="_blank">http://labs.leto.net</a><br>NOTE: Personal email
 is only checked twice a day at 10am/2pm PST,<br>please call/text for time-sensitive matters.<br><br><br> </div> </div>  </div></body></html>