I have installed OCE 0.6.0, and the pythonocc current master, still the previous problem: with force_purge() it crashes with smart_purge() it leaks. Check the attached code.
On Fri, Sep 30, 2011 at 3:33 PM, Thomas Paviot <tpav...@gmail.com> wrote:
> The OCC API changed between 6.3.0 and 6.5.1. As a consequence, pythonocc
> SWIG files were updated to be consistent with the new API. You need OCC6.5.1
> or OCE-0.6.0 to be able to run pythonocc current master.
>
> Thomas
>
>
> 2011/9/30 István Csanády <istvancsan...@gmail.com>
>
>> I was going to rebulid pythonocc 0.5 with OCE 0.6.0 to try to check if the
>> code I sent does still crash or not with 0.6.0, but it misses BinLPlugin. Do
>> I have to download the latest pythonocc version to build with OCE?
>>
>> On Fri, Sep 30, 2011 at 11:13 AM, Thomas Paviot <tpav...@gmail.com>wrote:
>>
>>> 2011/9/30 D. Barbier <bou...@gmail.com>
>>>
>>>> On 2011/9/30 István Csanády wrote:
>>>> > Thanks Thomas, this solved the leaking issue. Any ideas for a
>>>> workaround for
>>>> > the MMGrOpt crash (when I don't remove gcurve.GetObject())? Or I will
>>>> have
>>>> > to wait for pyocc 0.6?
>>>>
>>>> Hello,
>>>>
>>>> Can you please check whether your crash happens with OCE 0.6.0? We
>>>> fixed a bug which looks similar, so maybe it is gone.
>>>> If it crashes, how can I reproduce it? I tried your
>>>> example_GC_istvan.py file with MMGT_OPT set to 0, but it does not
>>>> crash.
>>>>
>>>
>>> On OSX/pythonocc current master/OCE-0.6.0, crash with MMGT_OPT=0,
>>> MMGT_OPT=2 but succeed with MMGT_OPT=1.
>>>
>>>
>>>>
>>>> > Last night I have been profiling some pythonocc code and I have
>>>> noticed that
>>>> > collect_object is a quite slow even if I remove logging. Probably it
>>>> has
>>>> > some potential to increase pythonocc's performance. Since it is always
>>>> > called when an object is destructed it makes sense to remove somehow
>>>> the
>>>> > costly string compares for the Handle objects. For example if it is
>>>> possible
>>>> > in OCE in the Handle class generator (handle classes are generated
>>>> > automatically, aren't they?) can be modified that every Handle class
>>>> should
>>>> > subclass from an empty marker class (eg. class HandleMarkerClass{})
>>>> and this
>>>> > can be used in the GC by checking only
>>>> > isinstance(obj_deleted,HandleMarkerClass), removing
>>>> > the obj_deleted.__class__.__name__.startswith('Handle').
>>>>
>>>> AFAICT all handles derive from either Handle_Standard_Transient or
>>>> Handle_Standard_Persistent, so your solution can be implemented
>>>> without changes in C++ code.
>>>>
>>>> > The hasattr calls
>>>> > might also can be replaced by some tricky way but I don't know if it
>>>> worth
>>>> > it but I think it does since hasattr searches in a python dictionary
>>>> which
>>>> > is a hashmap and a single isinstance is might be less costly than a
>>>> dict
>>>> > lookup. But replacing somehow the string compare IMO would definitely
>>>> worth
>>>> > it.
>>>> > But these are only ideas I don't know OCC's structure very well.
>>>>
>>>> I guess that
>>>> hasattr(obj_deleted,"GetHandle")
>>>> can be replaced by
>>>> isinstance(deleted, OCC.Standard.Standard_Transient) or
>>>> isinstance(deleted, OCC.Standard.Standard_Persistent)
>>>>
>>>
>>> Absolutely. That's what I implemented in my previous attachment.
>>>
>>>
>>>>
>>>> Denis
>>>>
>>>
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>> _______________________________________________
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
> _______________________________________________
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
__main__.py
Description: Binary data
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
