2009/5/29 André Loureiro <loureiro.andrew@...>:
> Hi guys,
>
> I've made the bindings for epdf library, and I would like put it
> in your svn repository, how can i do this?
> the current repository is in gitorious.org, but I think that is not
> better place.
Hi André,
Before I merge your work inside SVN I need you to fix some problems with it:
- release the GIL in functions that (possibly) take long, like
render(). See http://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-ecore/ecore/ecore.c_ecore.pyx
(Reminds me that I need to add such to evas render as well, if you
could submit a patch to improve that it would be great!)
- do not use self.Xobj, use self.obj instead, so it's consistent
among all efl. (for C object pointer)
- consistent name of classes: epdf.Page, not epdf.EPage.
- avoid creating dicts for things that do not need one, for example
in EPage.text_find(), either return a tuple, or return an evas.Rect
instead.
- watch out memory leaks! EPage.text_find() is leaking the returned
list and nodes, you need to free it. Please review the whole code in
parts that returns lists and char*.
- watch out NULL -> python. If any function can return NULL on
char*, you need to check for that and convert to None yourself,
otherwise the application will segv.
Regards,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

On Mon, 1 Jun 2009, Gustavo Sverzut Barbieri wrote:
> On Mon, Jun 1, 2009 at 5:14 AM, Vincent Torri <vtorri@...> wrote:
>>
>>
>> On Sun, 31 May 2009, Gustavo Sverzut Barbieri wrote:
>>
>>> That's really weird, we walk just part of the list, never delete nodes
>>> and compares pointers that we use before, so it should never happen.
>>> Maybe a bug somewhere else tha is now exposed? Remember that functions
>>> that would run immediatelly are now postponed, so things that were
>>> free but were untouched can now be changed...
>>>
>>> anyways, on the bus to my home now, can look into this tomorrow.
>>
>> sorry, it's my fault, i had in a configuration a -fomit-frame-pointer in my
>> flags, which corrupted the stack.
>>
>> I'm sorry for the noise
>
> Ok, but what was the problem? :-)
I have a script that compiles and install the efl, and create an installer
for Windows. I use some flags for the compilation, and
-fomit-frame-pointer was one of those flags. I don't understand why but,
when i compiled with the latest source code, there was a seg fault, the bt
of gdb being totally useless (but according to the doc, it's not
surprising that gdb is lost with that option)
Then i reverted your commit, but i didn't use the same compilation flags,
hence no error. I found that very strange as your commit is simple, with
no error (like a wrong cast, for example).
Then i did some tests with different compilation flags to test the latest
code, and, when removing -fomit-frame-pointer, everything was fine.
Vincent

On Mon, Jun 1, 2009 at 5:14 AM, Vincent Torri <vtorri@...> wrote:
>
>
> On Sun, 31 May 2009, Gustavo Sverzut Barbieri wrote:
>
>> That's really weird, we walk just part of the list, never delete nodes
>> and compares pointers that we use before, so it should never happen.
>> Maybe a bug somewhere else tha is now exposed? Remember that functions
>> that would run immediatelly are now postponed, so things that were
>> free but were untouched can now be changed...
>>
>> anyways, on the bus to my home now, can look into this tomorrow.
>
> sorry, it's my fault, i had in a configuration a -fomit-frame-pointer in my
> flags, which corrupted the stack.
>
> I'm sorry for the noise
Ok, but what was the problem? :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

On Sun, 31 May 2009, Gustavo Sverzut Barbieri wrote:
> That's really weird, we walk just part of the list, never delete nodes
> and compares pointers that we use before, so it should never happen.
> Maybe a bug somewhere else tha is now exposed? Remember that functions
> that would run immediatelly are now postponed, so things that were
> free but were untouched can now be changed...
>
> anyways, on the bus to my home now, can look into this tomorrow.
sorry, it's my fault, i had in a configuration a -fomit-frame-pointer in
my flags, which corrupted the stack.
I'm sorry for the noise
Vincent

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details