I'm getting a strange segfault when trying to read an eet file, which was
created with eet_data_write. The file itself seems absolute fine, and can be
read from the command line.
The backtrace is always this:
#0 0x75573e40 in ?? () from /lib/libc.so.6
#1 0x77bcd956 in
On Mon, 20 Sep 2010 11:59:43 +0300 Viktor Kojouharov vkojouha...@gmail.com
said:
it's odd - the fact that its getting an unknown value is a hint that something
about the eet data is corrupt as far as eet is concerned. what is it about you
that means you always have the weird problems that are not
I have no idea. This only happens on a work computer, and not on my home
laptop. But both use Ubuntu with the same versions and packages, and are
both 64bit. I've seem to have fixed it by moving from
eet_data_descriptor_stream_new (where the old one was
eet_data_descriptor_file_new), so maybe the
On Sat, Sep 18, 2010 at 11:30 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Modified: trunk/TMP/st/elementary/src/lib/Elementary.h.in
===
--- trunk/TMP/st/elementary/src/lib/Elementary.h.in 2010-09-19 02:28:09
UTC
On Sun, Sep 19, 2010 at 2:07 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
+ if (e-orientation == ETHUMB_THUMB_ORIENT_ORIGINAL)
+ {
+#ifdef HAVE_LIBEXIF
+ ExifData *exif = exif_data_new_from_file(e-src_path);
+ ExifEntry *entry = NULL;
+ ExifByteOrder
On Mon, Sep 20, 2010 at 8:11 AM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Sun, Sep 19, 2010 at 2:07 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
+ if (e-orientation == ETHUMB_THUMB_ORIENT_ORIGINAL)
+ {
+#ifdef HAVE_LIBEXIF
+ ExifData *exif =
Hello!
Lucas De Marchi lucas.demar...@profusion.mobi a écrit :
On Sun, Sep 19, 2010 at 2:07 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
+ if (e-orientation == ETHUMB_THUMB_ORIENT_ORIGINAL)
+ {
+#ifdef HAVE_LIBEXIF
+ ExifData *exif =
Hello!
Gustavo Sverzut Barbieri barbi...@profusion.mobi a écrit :
BTW, exif parser is super-simple, as we just need a single case I'd
rather have it in ethumb instead of linking with libexif. You can
freely copy and adapt my code from
Hi Folks,
on ecore_exe python bindings there is a type mismatch that breaks
signals. I mailed this patch a long time ago and never got any
response.
I've been using this patch since april, and without it there are
exceptions when stopping processes.
Cheers,
Eduardo Felipe.
Author: Eduardo
Hi Folks,
This small patch adds edje_object_part_table_child_get to python.
I needed it. Hope it's useful for someone else :)
Cheers,
Eduardo Felipe.
diff --git a/BINDINGS/python/python-edje/edje/edje.c_edje_object.pxi
b/BINDINGS/python/python-edje/edje/edje.c_edje_object.pxi
---
On Mon, Sep 20, 2010 at 11:07 AM, Eduardo Felipe
eduardofelip...@gmail.com wrote:
Hi Folks,
on ecore_exe python bindings there is a type mismatch that breaks
signals. I mailed this patch a long time ago and never got any
response.
I've been using this patch since april, and without it there
On Mon, Sep 20, 2010 at 11:07 AM, Eduardo Felipe
eduardofelip...@gmail.com wrote:
Hi Folks,
on ecore_exe python bindings there is a type mismatch that breaks
signals. I mailed this patch a long time ago and never got any
response.
I've been using this patch since april, and without it there
On 09/18/2010 01:41 PM, Enlightenment SVN wrote:
Log:
dont use tls max if it doesnt exist eh?
Author: raster
Date: 2010-09-18 04:41:15 -0700 (Sat, 18 Sep 2010)
New Revision: 52413
Modified:
trunk/ecore/src/lib/ecore_con/ecore_con_ssl.c
Modified:
This is currently an int return, it needs to be changed to Eina_Bool before
beta/release.
--
Mike Blumenkrantz
Zentific: Our boolean values are huge.
--
Start uncovering the many advantages of virtual appliances
and
On Mon, 20 Sep 2010, Michael Blumenkrantz wrote:
This is currently an int return, it needs to be changed to Eina_Bool before
beta/release.
actually, we should review all the API about such returned values (i saw
the same stuff in ecore_file for example)
Vincent
No, that's just backwards.
I contribute to multiple projects, I don't want to have to set up
multiple vim rcs just to edit e files. And I'm sure as hell not going
to convert multiple groups coding standards (if so, E loses BTW).
_IF_ moodelines were significantly different between different
On Tue, 21 Sep 2010 00:53:37 +0200 (CEST)
Vincent Torri vto...@univ-evry.fr wrote:
On Mon, 20 Sep 2010, Michael Blumenkrantz wrote:
This is currently an int return, it needs to be changed to Eina_Bool before
beta/release.
actually, we should review all the API about such returned
On Mon, Sep 20, 2010 at 10:21 PM, Brett Nash n...@nash.id.au wrote:
No, that's just backwards.
I contribute to multiple projects, I don't want to have to set up
multiple vim rcs just to edit e files. And I'm sure as hell not going
to convert multiple groups coding standards (if so, E loses
Am 21.09.2010 um 03:36 schrieb Michael Blumenkrantz m...@zentific.com:
On Tue, 21 Sep 2010 00:53:37 +0200 (CEST)
Vincent Torri vto...@univ-evry.fr wrote:
On Mon, 20 Sep 2010, Michael Blumenkrantz wrote:
This is currently an int return, it needs to be changed to
Eina_Bool before
On Mon, Sep 20, 2010 at 10:46 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Sep 20, 2010 at 10:21 PM, Brett Nash n...@nash.id.au wrote:
No, that's just backwards.
I contribute to multiple projects, I don't want to have to set up
multiple vim rcs just to edit e files.
On 09/20/2010 09:49 PM, Gustavo Sverzut Barbieri wrote:
On Mon, Sep 20, 2010 at 10:46 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Sep 20, 2010 at 10:21 PM, Brett Nashn...@nash.id.au wrote:
No, that's just backwards.
I contribute to multiple projects, I don't want
On Mon, Sep 20, 2010 at 6:06 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
fix a few segfaults that happened on a specific computer
short explanation of the error, so you can choose to change it or not,
but at least you'll know the reason:
the FILE version will know the data is
Answered in reply to your svn commit. It's due eet FILE x STREAM usage
of in-file strings (mmap x eina_stringshare), thus how it is freed and
how memory is kept around.
It would require more information on why it failed on one machine
(correct) and not the other, maybe some situation where mmap
23 matches
Mail list logo
