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
