[Parrot-users] Use of vtable "destroy"

Sat Dec 31 07:49:47 UTC 2011

Oh whoops, sorry for the confusion. SFML is not my project; it's sort of like an SDL re-imagining:
  http://www.sfml-dev.org/

My own code that I referenced in the previous email is available here:
  https://github.com/sorlok/Dubious-Dabblings

In particular:
  https://github.com/sorlok/Dubious-Dabblings/blob/master/MapView/src/SFML_Engine.cpp
  https://github.com/sorlok/Dubious-Dabblings/blob/master/MapView/test.pir

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.

-->Seth

________________________________
 From: "Jonathan "Duke" Leto" <jonathan at leto.net>
To: S'orlok Reaves <sorlok_reaves at yahoo.com> 
Cc: "parrot-users at lists.parrot.org" <parrot-users at lists.parrot.org> 
Sent: Saturday, December 31, 2011 12:35 PM
Subject: Re: [Parrot-users] Use of vtable "destroy"

Howdy,

Great to hear about you using Parrot. Is you code (libSFML) available
online somewhere?

Duke

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

-- 
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-users/attachments/20111230/a44e578c/attachment-0001.html>