On Apr 12, 5:33 pm, Michael Brickenstein <[EMAIL PROTECTED]> wrote:
> > * unknown number of external library users: I am not away of anybody
> > external using giac as a library. From my experience with libSingular
> > I am not too optimistic that we will not run into a number of issues
> > here. Look at #2822: PolyBoRi is designed as a library to be used from
> > Python. But I spend about two days chasing down some issue that was
> > caused by the way we use the library.
Hi Michael B.,
> We appreciate all this work involved in the SAGE integration of our
> library, which resulted in a cleaner PolyBoRi.
> Just to illustrate Michaels argument:
> He has only seen the sunside of PolyBoRi, that means, when it was
> designed to be used from Python.
;)
> Before, we also had a Python-interface. But the C++-interface of CUDD
> made it impossible to have automatic resource management.
Now you are scaring me.
> So essentially I made sure in every Python script, that these
> resources where deallocated in the correct order.
> The only solution was to write our own C++ interface to CUDD.
> Michael
Hehe, it looks like there might still be clouds in the sky, at least
with our interface. Valgrinding pbori.pyx results in
==6362== 61,866,220 bytes in 59 blocks are still reachable in loss
record 13,368 of 13,369
==6362== at 0x4A1BE1B: malloc (vg_replace_malloc.c:207)
==6362== by 0x159EE986: MMalloc (safe_mem.c:62)
==6362== by 0x15A076BD: Cudd_Init (cuddInit.c:151)
==6362== by 0x159A26AE:
polybori::BoolePolyRing::BoolePolyRing(unsigned, int, bool)
(CCuddCore.h:120)
==6362== by 0x15964DEB:
__pyx_pf_4sage_5rings_10polynomial_5pbori_21BooleanPolynomialRing___init__(_object*,
_object*, _o
bject*) (ccobject.h:50)
==6362== by 0x458E90: type_call (typeobject.c:436)
==6362== by 0x415592: PyObject_Call (abstract.c:1860)
==6362== by 0x482271: PyEval_EvalFrameEx (ceval.c:3775)
==6362== by 0x48531A: PyEval_EvalCodeEx (ceval.c:2831)
==6362== by 0x4840A4: PyEval_EvalFrameEx (ceval.c:494)
==6362== by 0x48531A: PyEval_EvalCodeEx (ceval.c:2831)
==6362== by 0x483A3C: PyEval_EvalFrameEx (ceval.c:3660)
==6362==
==6362==
==6362== 494,929,760 bytes in 59 blocks are still reachable in loss
record 13,369 of 13,369
==6362== at 0x4A1BE1B: malloc (vg_replace_malloc.c:207)
==6362== by 0x159EE986: MMalloc (safe_mem.c:62)
==6362== by 0x15A2F10E: cuddInitCache (cuddCache.c:148)
==6362== by 0x15A0765F: Cudd_Init (cuddInit.c:146)
==6362== by 0x159A26AE:
polybori::BoolePolyRing::BoolePolyRing(unsigned, int, bool)
(CCuddCore.h:120)
==6362== by 0x15964DEB:
__pyx_pf_4sage_5rings_10polynomial_5pbori_21BooleanPolynomialRing___init__(_object*,
_object*, _o
bject*) (ccobject.h:50)
==6362== by 0x458E90: type_call (typeobject.c:436)
==6362== by 0x415592: PyObject_Call (abstract.c:1860)
==6362== by 0x482271: PyEval_EvalFrameEx (ceval.c:3775)
==6362== by 0x48531A: PyEval_EvalCodeEx (ceval.c:2831)
==6362== by 0x4840A4: PyEval_EvalFrameEx (ceval.c:494)
==6362== by 0x48531A: PyEval_EvalCodeEx (ceval.c:2831)
Since we are not sure yet if it is the interface's or PolyBoRi's fault
I haven't pinged you about this. Malb said that he would poke around
this weekend since we was working with PolyBoRi anyway. The above is
new in 0.3.1.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
