[E-devel] [eina] about amalgamation
Hey, CFLAGS: -O3 LDFLAGS: -Wl,-s with amalgamation, the size of the .so is 141316 without, it is 142216 is it normal ? Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : > Is the following appropriate? > > - > > Subject: Add autogen.sh to dist tarball > > autogen.sh is used by the debian packaging so it seems > appropriate to include it in the dist tarball Either you're packaging from SVN and therefore don't need it to be part of the dist tarball, or you're packaging from the snapshots at download.enlightenment.org (or snapshots you generated) and then your packaging should be fixed to use directly ./configure instead of configure.sh. Is there an actual use case I'm missing, for which this change would be required? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eina] about amalgamation
On Wed, 9 Sep 2009, Vincent Torri wrote: > > Hey, > > CFLAGS: -O3 > LDFLAGS: -Wl,-s > > with amalgamation, the size of the .so is 141316 > without, it is 142216 > > is it normal ? I mean, such a small difference in size Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Wed, 9 Sep 2009, Albin Tonnerre wrote: > On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : >> Is the following appropriate? >> >> - >> >> Subject: Add autogen.sh to dist tarball >> >> autogen.sh is used by the debian packaging so it seems >> appropriate to include it in the dist tarball > > Either you're packaging from SVN and therefore don't need it to be part of the > dist tarball, or you're packaging from the snapshots at > download.enlightenment.org (or snapshots you generated) and then your > packaging > should be fixed to use directly ./configure instead of configure.sh. > Is there an actual use case I'm missing, for which this change would be > required? i needed it once for libpng (no repository) for the windows ce port. But usually, autoreconf is called if you modify configure.ac in the EFL, autogen.sh is usually added to the tarball. But i think that it can be removed from it. Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Tue, Sep 08, 2009 at 08:52:39PM -0300, Gustavo Sverzut Barbieri wrote: >- ultra-dirty hack to remove extra pointer. The hack bases on the > fact that we just use ->last from the first node, that always have the > ->prev == NULL. So we could have the first ->prev == ->last, but how > to know it's the first then, you might ask? Easy! Just use the fact > that valid addresses are multiple of sizeof(word) and you're done, no > supported platform uses less than 4 bytes, so ->prev = ->last | 1; > would work, and checks for ->last & 1 would tell you if it's the case > or not. Please don't. Unless you can demonstrate a use case where the impact is large enough to really, really matter. Joerg -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eina] about amalgamation
On Wed, Sep 9, 2009 at 4:34 AM, Vincent Torri wrote: > > > On Wed, 9 Sep 2009, Vincent Torri wrote: > >> >> Hey, >> >> CFLAGS: -O3 >> LDFLAGS: -Wl,-s >> >> with amalgamation, the size of the .so is 141316 >> without, it is 142216 >> >> is it normal ? > > I mean, such a small difference in size i'm using couple of static mempool here and total size after strip -s goes from 128 to 124k, so 4k saving. Not that much, but for such an easy saving, it may matter for embedded systems, specially those where there is no -fvisibility=hidden... thinking of it, for these cases we could have an EAPI-like macro to say EINTERNAL, these would be converted to 'static' if amalgamation or attribute "visibility=hidden" for newer GCC and not amalgamation. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eina] about amalgamation
On Wed, Sep 9, 2009 at 11:01 AM, Peter Wehrfritz wrote: > Gustavo Sverzut Barbieri schrieb: >> >> On Wed, Sep 9, 2009 at 4:34 AM, Vincent Torri wrote: >> >>> >>> On Wed, 9 Sep 2009, Vincent Torri wrote: >>> >>> Hey, CFLAGS: -O3 LDFLAGS: -Wl,-s with amalgamation, the size of the .so is 141316 without, it is 142216 is it normal ? >>> >>> I mean, such a small difference in size >>> >> >> i'm using couple of static mempool here and total size after strip -s >> goes from 128 to 124k, so 4k saving. Not that much, but for such an >> easy saving, it may matter for embedded systems, specially those where >> there is no -fvisibility=hidden... thinking of it, for these cases we >> could have an EAPI-like macro to say EINTERNA > > Not that the name is very important, but wouldn't IAPI more consistent. I > think the E in EAPI stands for external, so EINTERNA would be somewhat odd. Sorry, I missed the final L, it's EINTERNAL, and E is the prefix/namespace, so API is what to be changed... it could be EINTERNAL, EINTERN, ELOCAL or whatever you like. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eina] about amalgamation
Gustavo Sverzut Barbieri schrieb: > On Wed, Sep 9, 2009 at 4:34 AM, Vincent Torri wrote: > >> On Wed, 9 Sep 2009, Vincent Torri wrote: >> >> >>> Hey, >>> >>> CFLAGS: -O3 >>> LDFLAGS: -Wl,-s >>> >>> with amalgamation, the size of the .so is 141316 >>> without, it is 142216 >>> >>> is it normal ? >>> >> I mean, such a small difference in size >> > > i'm using couple of static mempool here and total size after strip -s > goes from 128 to 124k, so 4k saving. Not that much, but for such an > easy saving, it may matter for embedded systems, specially those where > there is no -fvisibility=hidden... thinking of it, for these cases we > could have an EAPI-like macro to say EINTERNA Not that the name is very important, but wouldn't IAPI more consistent. I think the E in EAPI stands for external, so EINTERNA would be somewhat odd. Peter -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: sachiel IN trunk/eina/src: include tests
On Wed, 9 Sep 2009, Enlightenment SVN wrote:
Modified: trunk/eina/src/include/eina_inlist.h
===
--- trunk/eina/src/include/eina_inlist.h2009-09-09 10:44:25 UTC (rev
42365)
+++ trunk/eina/src/include/eina_inlist.h2009-09-09 14:05:31 UTC (rev
42366)
@@ -52,7 +52,7 @@
#define EINA_INLIST Eina_Inlist __in_list
#define EINA_INLIST_GET(Inlist) (&((Inlist)->__in_list))
-#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((Eina_Inlist *) ptr -
offsetof(type, __in_list)))
+#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((char *) ptr -
offsetof(type, __in_list)))
Iirc, i have already said that offsetof does not exist on Windows CE
Also, I don't know if it is important or not, but on OpenSolaris with
suncc, char is a signed type (-128...127)
Vincent
EAPI Eina_Inlist * eina_inlist_append(Eina_Inlist *in_list, Eina_Inlist
*in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT;
EAPI Eina_Inlist * eina_inlist_prepend(Eina_Inlist *in_list, Eina_Inlist
*in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT;
@@ -67,9 +67,14 @@
EAPI Eina_Iterator *eina_inlist_iterator_new(const Eina_Inlist *in_list)
EINA_MALLOC EINA_WARN_UNUSED_RESULT;
EAPI Eina_Accessor *eina_inlist_accessor_new(const Eina_Inlist *in_list)
EINA_MALLOC EINA_WARN_UNUSED_RESULT;
-#define EINA_INLIST_FOREACH(list, l) for (l = (void*)list; l; l =
(void*)(l->__in_list.next))
-#define EINA_INLIST_REVERSE_FOREACH(list, l) for (l = (list ? (void*)(list->last)
: NULL); l; l = (void*)(l->__in_list.prev))
+/* This two macros are helpers for the _FOREACH ones, don't use them */
+#define INLIST_OFFSET(ref) ((char*)&(ref)->__in_list - (char*)(ref))
+#define INLIST_CONTAINER(ref, ptr) (void*)((char*)(ptr) - INLIST_OFFSET(ref))
+#define EINA_INLIST_FOREACH(list, l) for (l = (list ? INLIST_CONTAINER(l, list) :
NULL); l; l = (EINA_INLIST_GET(l)->next ? INLIST_CONTAINER(l,
EINA_INLIST_GET(l)->next) : NULL))
+#define EINA_INLIST_REVERSE_FOREACH(list, l) for (l = (list ? INLIST_CONTAINER(l,
list->last) : NULL); l; l = (EINA_INLIST_GET(l)->prev ? INLIST_CONTAINER(l,
EINA_INLIST_GET(l)->prev) : NULL))
+
+
/**
* @}
*/
Modified: trunk/eina/src/tests/eina_test_inlist.c
===
--- trunk/eina/src/tests/eina_test_inlist.c 2009-09-09 10:44:25 UTC (rev
42365)
+++ trunk/eina/src/tests/eina_test_inlist.c 2009-09-09 14:05:31 UTC (rev
42366)
@@ -30,8 +30,8 @@
typedef struct _Eina_Test_Inlist Eina_Test_Inlist;
struct _Eina_Test_Inlist
{
+ int i;
EINA_INLIST;
- int i;
};
static Eina_Test_Inlist*
@@ -63,13 +63,13 @@
tmp = _eina_test_inlist_build(1664);
lst = eina_inlist_append_relative(lst, EINA_INLIST_GET(tmp), lst);
fail_if(!lst);
- fail_if(((Eina_Test_Inlist*)lst)->i != 42);
+ fail_if(EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist)->i != 42);
prev = tmp;
tmp = _eina_test_inlist_build(3227);
lst = eina_inlist_prepend_relative(lst, EINA_INLIST_GET(tmp),
EINA_INLIST_GET(prev));
fail_if(!lst);
- fail_if(((Eina_Test_Inlist*)lst)->i != 42);
+ fail_if(EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist)->i != 42);
lst = eina_inlist_remove(lst, EINA_INLIST_GET(tmp));
@@ -111,16 +111,17 @@
fail_if(eina_error_get() != EINA_ERROR_SAFETY_FAILED);
#endif
- tmp = (Eina_Test_Inlist*) lst;
+ tmp = EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist);
lst = eina_inlist_demote(lst, lst);
- fail_if(lst == (Eina_Inlist*) tmp);
+ fail_if(EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist) == tmp);
lst = eina_inlist_promote(lst, EINA_INLIST_GET(tmp));
- fail_if(lst != (Eina_Inlist*) tmp);
+ fail_if(lst != EINA_INLIST_GET(tmp));
- tmp = (Eina_Test_Inlist*) eina_inlist_find(lst, EINA_INLIST_GET(prev));
+ tmp = EINA_INLIST_CONTAINER_GET(eina_inlist_find(lst,
EINA_INLIST_GET(prev)), Eina_Test_Inlist);
lst = eina_inlist_remove(lst, EINA_INLIST_GET(tmp));
- tmp = (Eina_Test_Inlist*) eina_inlist_find(lst, EINA_INLIST_GET(tmp));
+ prev = eina_inlist_find(lst, EINA_INLIST_GET(tmp));
+ tmp = prev ? EINA_INLIST_CONTAINER_GET(prev, Eina_Test_Inlist) : NULL;
fail_if(tmp != NULL);
while (lst)
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
Message délivré par le serveur de messagerie de l'Université d'Evry.
-
Re: [E-devel] E SVN: sachiel IN trunk/eina/src: include tests
On Wed, 9 Sep 2009, Ivan Briano wrote: On Wed, Sep 9, 2009 at 11:13 AM, Vincent Torri wrote: On Wed, 9 Sep 2009, Enlightenment SVN wrote: Modified: trunk/eina/src/include/eina_inlist.h === --- trunk/eina/src/include/eina_inlist.h 2009-09-09 10:44:25 UTC (rev 42365) +++ trunk/eina/src/include/eina_inlist.h 2009-09-09 14:05:31 UTC (rev 42366) @@ -52,7 +52,7 @@ #define EINA_INLIST Eina_Inlist __in_list #define EINA_INLIST_GET(Inlist) (&((Inlist)->__in_list)) -#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((Eina_Inlist *) ptr - offsetof(type, __in_list))) +#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((char *) ptr - offsetof(type, __in_list))) Iirc, i have already said that offsetof does not exist on Windows CE That macro was already there, I just fixed the cast to get the right address. I don't think it's used anywhere so it can be replaced by the macros below. yes. That makes me think that i'm wondering why someone asked me if that function exists or not on win ce. Also, I don't know if it is important or not, but on OpenSolaris with suncc, char is a signed type (-128...127) And char *? it's a signed pointer of course ! :) kidding. Forget my remark, there is no dereferencement Vincent-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: sachiel IN trunk/eina/src: include tests
On Wed, Sep 9, 2009 at 11:13 AM, Vincent Torri wrote:
>
>
> On Wed, 9 Sep 2009, Enlightenment SVN wrote:
>>
>> Modified: trunk/eina/src/include/eina_inlist.h
>> ===
>> --- trunk/eina/src/include/eina_inlist.h 2009-09-09 10:44:25 UTC
>> (rev 42365)
>> +++ trunk/eina/src/include/eina_inlist.h 2009-09-09 14:05:31 UTC
>> (rev 42366)
>> @@ -52,7 +52,7 @@
>>
>> #define EINA_INLIST Eina_Inlist __in_list
>> #define EINA_INLIST_GET(Inlist) (&((Inlist)->__in_list))
>> -#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((Eina_Inlist *)
>> ptr - offsetof(type, __in_list)))
>> +#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((char *) ptr -
>> offsetof(type, __in_list)))
>
> Iirc, i have already said that offsetof does not exist on Windows CE
>
That macro was already there, I just fixed the cast to get the right address.
I don't think it's used anywhere so it can be replaced by the macros below.
> Also, I don't know if it is important or not, but on OpenSolaris with suncc,
> char is a signed type (-128...127)
>
And char *?
> Vincent
>
>>
>> EAPI Eina_Inlist * eina_inlist_append(Eina_Inlist *in_list, Eina_Inlist
>> *in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT;
>> EAPI Eina_Inlist * eina_inlist_prepend(Eina_Inlist *in_list, Eina_Inlist
>> *in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT;
>> @@ -67,9 +67,14 @@
>> EAPI Eina_Iterator *eina_inlist_iterator_new(const Eina_Inlist *in_list)
>> EINA_MALLOC EINA_WARN_UNUSED_RESULT;
>> EAPI Eina_Accessor *eina_inlist_accessor_new(const Eina_Inlist *in_list)
>> EINA_MALLOC EINA_WARN_UNUSED_RESULT;
>>
>> -#define EINA_INLIST_FOREACH(list, l) for (l = (void*)list; l; l =
>> (void*)(l->__in_list.next))
>> -#define EINA_INLIST_REVERSE_FOREACH(list, l) for (l = (list ?
>> (void*)(list->last) : NULL); l; l = (void*)(l->__in_list.prev))
>> +/* This two macros are helpers for the _FOREACH ones, don't use them */
>> +#define INLIST_OFFSET(ref) ((char*)&(ref)->__in_list - (char*)(ref))
>> +#define INLIST_CONTAINER(ref, ptr) (void*)((char*)(ptr) -
>> INLIST_OFFSET(ref))
>>
>> +#define EINA_INLIST_FOREACH(list, l) for (l = (list ? INLIST_CONTAINER(l,
>> list) : NULL); l; l = (EINA_INLIST_GET(l)->next ? INLIST_CONTAINER(l,
>> EINA_INLIST_GET(l)->next) : NULL))
>> +#define EINA_INLIST_REVERSE_FOREACH(list, l) for (l = (list ?
>> INLIST_CONTAINER(l, list->last) : NULL); l; l = (EINA_INLIST_GET(l)->prev ?
>> INLIST_CONTAINER(l, EINA_INLIST_GET(l)->prev) : NULL))
>> +
>> +
>> /**
>> * @}
>> */
>>
>> Modified: trunk/eina/src/tests/eina_test_inlist.c
>> ===
>> --- trunk/eina/src/tests/eina_test_inlist.c 2009-09-09 10:44:25 UTC
>> (rev 42365)
>> +++ trunk/eina/src/tests/eina_test_inlist.c 2009-09-09 14:05:31 UTC
>> (rev 42366)
>> @@ -30,8 +30,8 @@
>> typedef struct _Eina_Test_Inlist Eina_Test_Inlist;
>> struct _Eina_Test_Inlist
>> {
>> + int i;
>> EINA_INLIST;
>> - int i;
>> };
>>
>> static Eina_Test_Inlist*
>> @@ -63,13 +63,13 @@
>> tmp = _eina_test_inlist_build(1664);
>> lst = eina_inlist_append_relative(lst, EINA_INLIST_GET(tmp), lst);
>> fail_if(!lst);
>> - fail_if(((Eina_Test_Inlist*)lst)->i != 42);
>> + fail_if(EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist)->i != 42);
>>
>> prev = tmp;
>> tmp = _eina_test_inlist_build(3227);
>> lst = eina_inlist_prepend_relative(lst, EINA_INLIST_GET(tmp),
>> EINA_INLIST_GET(prev));
>> fail_if(!lst);
>> - fail_if(((Eina_Test_Inlist*)lst)->i != 42);
>> + fail_if(EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist)->i != 42);
>>
>> lst = eina_inlist_remove(lst, EINA_INLIST_GET(tmp));
>>
>> @@ -111,16 +111,17 @@
>> fail_if(eina_error_get() != EINA_ERROR_SAFETY_FAILED);
>> #endif
>>
>> - tmp = (Eina_Test_Inlist*) lst;
>> + tmp = EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist);
>> lst = eina_inlist_demote(lst, lst);
>> - fail_if(lst == (Eina_Inlist*) tmp);
>> + fail_if(EINA_INLIST_CONTAINER_GET(lst, Eina_Test_Inlist) == tmp);
>>
>> lst = eina_inlist_promote(lst, EINA_INLIST_GET(tmp));
>> - fail_if(lst != (Eina_Inlist*) tmp);
>> + fail_if(lst != EINA_INLIST_GET(tmp));
>>
>> - tmp = (Eina_Test_Inlist*) eina_inlist_find(lst,
>> EINA_INLIST_GET(prev));
>> + tmp = EINA_INLIST_CONTAINER_GET(eina_inlist_find(lst,
>> EINA_INLIST_GET(prev)), Eina_Test_Inlist);
>> lst = eina_inlist_remove(lst, EINA_INLIST_GET(tmp));
>> - tmp = (Eina_Test_Inlist*) eina_inlist_find(lst, EINA_INLIST_GET(tmp));
>> + prev = eina_inlist_find(lst, EINA_INLIST_GET(tmp));
>> + tmp = prev ? EINA_INLIST_CONTAINER_GET(prev, Eina_Test_Inlist) : NULL;
>> fail_if(tmp != NULL);
>>
>> while (lst)
>>
>>
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, c
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Wed, Sep 09, 2009 at 09:30:24AM +0200, Albin Tonnerre wrote: > On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : > > Is the following appropriate? > > > > - > > > > Subject: Add autogen.sh to dist tarball > > > > autogen.sh is used by the debian packaging so it seems > > appropriate to include it in the dist tarball > > Either you're packaging from SVN and therefore don't need it to be part of the > dist tarball, or you're packaging from the snapshots at > download.enlightenment.org (or snapshots you generated) and then your > packaging > should be fixed to use directly ./configure instead of configure.sh. > Is there an actual use case I'm missing, for which this change would be > required? Thanks for filling me in on the expected usage. I was thinking of the case where you want to test what is in SVN by: 1) creating a tarball 2) building a debian package from that tarball after unpacking is and manually copying over the debian/ directory from SVN. But if thats not valid, I'll stop doing it. When you say fixed to use ./configure directly, when and how does that occur? I agree that calling ./configure is preferable when building Debian packages. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Thu, 10 Sep 2009 09:50:04 +1000 Simon Horman said: > On Wed, Sep 09, 2009 at 09:30:24AM +0200, Albin Tonnerre wrote: > > On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : > > > Is the following appropriate? > > > > > > - > > > > > > Subject: Add autogen.sh to dist tarball > > > > > > autogen.sh is used by the debian packaging so it seems > > > appropriate to include it in the dist tarball > > > > Either you're packaging from SVN and therefore don't need it to be part of > > the dist tarball, or you're packaging from the snapshots at > > download.enlightenment.org (or snapshots you generated) and then your > > packaging should be fixed to use directly ./configure instead of > > configure.sh. Is there an actual use case I'm missing, for which this > > change would be required? > > Thanks for filling me in on the expected usage. actually. alibin is wrong (sorry!) autogen's do get packaged. look at existing efl. we put it in so if u get a tarball u CAN easily modify the configure.ac, Makefile.am's etc. and re-generate the autofoo. the script will be there with all the magic. not everyone will want or need to do this from a tarball dist - but it dos happen. people patching packages are often the ones using it. so it's not valid. it's an omission in the esmart build foo. :) (even if albin was right - eet, evas, elementary, edje, ... etc. all include autogen.sh in their EXTRA_DIST, so it'd go in for consistency sake. it's goo to have everything in svn have consistent autofoo files and work the same way. it makes everything hav the same bug o everything is right. not some things buggy, some not, in terms of autofoo usage/structure, so if u do find a bug/issue - u can know that fixing it everywhere else is trivial) > I was thinking of the case where you want to test what is > in SVN by: > > 1) creating a tarball > 2) building a debian package from that tarball after unpacking is >and manually copying over the debian/ directory from SVN. > > But if thats not valid, I'll stop doing it. > > When you say fixed to use ./configure directly, when and how does that occur? > I agree that calling ./configure is preferable when building Debian packages. > > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Tue, 8 Sep 2009 20:52:39 -0300 Gustavo Sverzut Barbieri said: you've already put my word in on this. i go the accounting way. 1. it is consistent with eina_list. 2. can be extended beyond last and include count and many other things. 3. doesn't change inlist struct size to be bigger (tho we dont win on it being smaller). 4. doesnt play evil games. (using low-order bits in pointers is wrong imho. i've sen this game played before (using high order bits) and then it com crashing down on peoples heads when suddenly those used bits become relevant. using those bits will also require instruction overhead of masking them out always before use. so you lose on the code simplicity and speed side, just to save 4 bytes (or 8 on 64bit) per inlist instance. it's not worth it. it is possible also in future allocations no longer are limited to word boundaries and allocs do use those bits, thus removing them from our use and requiring another solution. in the end. it's safer, easier, faster, more consistent and more portable and robust to use the accounting pointer method > Hello all, but specially Cedric and Jorge as one of you did initial > eina_inlist and we're about to release eina as 1.0 so we need to know > if things need/could be changed to improve things before that. > > Today eina_inlist does not keep an accounting member as its eina_list > counterpart, instead it keeps a pointer to "last" that is just valid > on the head member (as we'll not walk the list updating all ->last as > we append stuff). That leaves us with a sizeof(pointer) lost in every > member but the first. > > Two options with that: >- add accounting: suggested by raster, it does make sense as it > would make eina_inlist_count() O(1) and behavior similar to eina_list, > better use of that pointer. >- ultra-dirty hack to remove extra pointer. The hack bases on the > fact that we just use ->last from the first node, that always have the > ->prev == NULL. So we could have the first ->prev == ->last, but how > to know it's the first then, you might ask? Easy! Just use the fact > that valid addresses are multiple of sizeof(word) and you're done, no > supported platform uses less than 4 bytes, so ->prev = ->last | 1; > would work, and checks for ->last & 1 would tell you if it's the case > or not. > > The ultra dirty hack could be used to save the extra ->accounting from > eina_list as well, and instead of adding last as said in the previous > example, we could store accounting there. Dirty but useful, if people > are using macros then we've almost no porting to do. As this uses > ->prev (a not so used pointer in outer world) we don't have much work > to do, just introduce EINA_LIST_FIRST_IS() and EINA_LIST_LAST_IS() > (the last would still check for NULL, but just to make further changes > easier). > > What do you think? Should we change eina_inlist to have an accounting > and still use 3 pointers per node? Should we move to the said trick? > Also for eina_list? SAY IT SOON OR LIVE WITH THAT :-D > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Thu, Sep 10, 2009 at 10:46:54AM +1000, Carsten Haitzler wrote: > On Thu, 10 Sep 2009 09:50:04 +1000 Simon Horman said: > > > On Wed, Sep 09, 2009 at 09:30:24AM +0200, Albin Tonnerre wrote: > > > On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : > > > > Is the following appropriate? > > > > > > > > - > > > > > > > > Subject: Add autogen.sh to dist tarball > > > > > > > > autogen.sh is used by the debian packaging so it seems > > > > appropriate to include it in the dist tarball > > > > > > Either you're packaging from SVN and therefore don't need it to be part of > > > the dist tarball, or you're packaging from the snapshots at > > > download.enlightenment.org (or snapshots you generated) and then your > > > packaging should be fixed to use directly ./configure instead of > > > configure.sh. Is there an actual use case I'm missing, for which this > > > change would be required? > > > > Thanks for filling me in on the expected usage. > > actually. alibin is wrong (sorry!) autogen's do get packaged. look at existing > efl. we put it in so if u get a tarball u CAN easily modify the configure.ac, > Makefile.am's etc. and re-generate the autofoo. the script will be there with > all the magic. not everyone will want or need to do this from a tarball dist - > but it dos happen. people patching packages are often the ones using it. so > it's not valid. it's an omission in the esmart build foo. :) (even if albin > was > right - eet, evas, elementary, edje, ... etc. all include autogen.sh in their > EXTRA_DIST, so it'd go in for consistency sake. it's goo to have everything in > svn have consistent autofoo files and work the same way. it makes everything > hav the same bug o everything is right. not some things buggy, some not, in > terms of autofoo usage/structure, so if u do find a bug/issue - u can know > that > fixing it everywhere else is trivial) Ok, I should have pointed out in the beginning that I really just wanted to make things consistent. With that in mind I'll commit my change. It can always be changed if in the future it is decided to consistently do something else. [snip] -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enlightenment_remote segfaults
On Sat, 5 Sep 2009 20:46:53 -0400 P Purkayastha said: you won't like this but e_remote and e's ipc are scheduled for death (removal). 1. we have a dbu api already for e, 2. this includes the core set of ops needed, 3. it's expandable by modules. the maintenance of ipc_handlers is painful. i want to nuke it. so... since it's scheduled for death... this will be a "wontfix" :) > Hi, > enlightenment_remote is giving segfaults every time it is run. This has > been happening since at least September 3. This is an example output: > ~> which er > er: aliased to enlightenment_remote > ~> er -module-list > REPLY <- BEGIN > REPLY: "gadman" ENABLED 1 > zsh: segmentation fault enlightenment_remote -module-list > ~ [139] > er -default-profile-get > REPLY <- BEGIN > REPLY: "composite-eco" > zsh: segmentation fault enlightenment_remote -default-profile-get > ~ [139] > > > Just wanted to bring it to your attention. > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Thu, 10 Sep 2009 10:54:01 +1000 Simon Horman said: > > actually. alibin is wrong (sorry!) autogen's do get packaged. look at > > existing efl. we put it in so if u get a tarball u CAN easily modify the > > configure.ac, Makefile.am's etc. and re-generate the autofoo. the script > > will be there with all the magic. not everyone will want or need to do this > > from a tarball dist - but it dos happen. people patching packages are often > > the ones using it. so it's not valid. it's an omission in the esmart build > > foo. :) (even if albin was right - eet, evas, elementary, edje, ... etc. > > all include autogen.sh in their EXTRA_DIST, so it'd go in for consistency > > sake. it's goo to have everything in svn have consistent autofoo files and > > work the same way. it makes everything hav the same bug o everything is > > right. not some things buggy, some not, in terms of autofoo > > usage/structure, so if u do find a bug/issue - u can know that fixing it > > everywhere else is trivial) > > Ok, I should have pointed out in the beginning that I really just wanted > to make things consistent. With that in mind I'll commit my change. It can > always be changed if in the future it is decided to consistently do > something else. no need. i already added it :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Thu, Sep 10, 2009 at 10:53:17AM +1000, Carsten Haitzler wrote: > On Tue, 8 Sep 2009 20:52:39 -0300 Gustavo Sverzut Barbieri > said: > > you've already put my word in on this. i go the accounting way. 1. it is > consistent with eina_list. 2. can be extended beyond last and include count > and > many other things. 3. doesn't change inlist struct size to be bigger (tho we > dont win on it being smaller). 4. doesnt play evil games. (using low-order > bits > in pointers is wrong imho. i've sen this game played before (using high order > bits) and then it com crashing down on peoples heads when suddenly those used > bits become relevant. using those bits will also require instruction overhead > of masking them out always before use. so you lose on the code simplicity and > speed side, just to save 4 bytes (or 8 on 64bit) per inlist instance. it's not > worth it. it is possible also in future allocations no longer are limited to > word boundaries and allocs do use those bits, thus removing them from our use > and requiring another solution. Does anyone know if the issues related to using the lower bits of pointers architecture-specific, libc-specific or both? I was pondering this recently in relation to a different project. I know that they use this technique in the Linux kernel. But obviously they have quite a lot of control over what their memory addresses look like in terms of alignment and thus unused bits. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Thu, 10 Sep 2009 11:19:53 +1000 Simon Horman said: > On Thu, Sep 10, 2009 at 10:53:17AM +1000, Carsten Haitzler wrote: > > On Tue, 8 Sep 2009 20:52:39 -0300 Gustavo Sverzut Barbieri > > said: > > > > you've already put my word in on this. i go the accounting way. 1. it is > > consistent with eina_list. 2. can be extended beyond last and include count > > and many other things. 3. doesn't change inlist struct size to be bigger > > (tho we dont win on it being smaller). 4. doesnt play evil games. (using > > low-order bits in pointers is wrong imho. i've sen this game played before > > (using high order bits) and then it com crashing down on peoples heads when > > suddenly those used bits become relevant. using those bits will also > > require instruction overhead of masking them out always before use. so you > > lose on the code simplicity and speed side, just to save 4 bytes (or 8 on > > 64bit) per inlist instance. it's not worth it. it is possible also in > > future allocations no longer are limited to word boundaries and allocs do > > use those bits, thus removing them from our use and requiring another > > solution. > > Does anyone know if the issues related to using the lower bits of pointers > architecture-specific, libc-specific or both? > > I was pondering this recently in relation to a different project. I know > that they use this technique in the Linux kernel. But obviously they have > quite a lot of control over what their memory addresses look like in terms > of alignment and thus unused bits. well a combo of both. 1. libc "guarantees" that allocations will be on the largest arch-specific alignment boundary. ie the largest "primitive" the processor uses (most often 32bits, or 64bits). this is so any structure you allocate - if it uses the largest primitive type, will have its first member always aligned, meaning any compiler alignment for struct members will work too. 2. most arches will actually raise processor exceptions for access of non-aligned data. x86 does not but there is a small performance penalty to accessing unaligned data. so align your data if u ant it faster, but there isnt a big pain level for not doing so. for arm (for example) you literally get a processor exception (sigbus) if you access non-aligned mmory (eg read 32bit words at a non 32bit boundary). some arm kernels are compiled to do a fixup, access the mem anyway in a non-exception raising way in the kernel when the exception is raised from a "bad" userspace app, then flip back to userspace and log the pain. your accesses work - but are slow-as-windows. other kernels simply issue a sigbus that nicely terminates your process. it is in theory possible to have an architecture where accesses on byte boundaries is always possible and has no penalty. in theory here allocations would never need to be aligned (but may be for simplicity sake). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enlightenment_remote segfaults
On Wednesday 09 September 2009 21:15:25 Carsten Haitzler wrote: > On Sat, 5 Sep 2009 20:46:53 -0400 P Purkayastha said: > > you won't like this but e_remote and e's ipc are scheduled for death > (removal). 1. we have a dbu api already for e, 2. this includes the core > set of ops needed, 3. it's expandable by modules. the maintenance of > ipc_handlers is painful. i want to nuke it. so... since it's scheduled for > death... this will be a "wontfix" :) My scripts just got more complex then :( (and my e17 config backup scripts have stopped working) Also, I can't seem to get a list of modules which are currently enabled. qdbusviewer shows me that there is a Method:List. So I gave the following command: ~> qdbus org.enlightenment.wm.service /org/enlightenment/wm/RemoteObject org.enlightenment.wm.Module.List qdbus: I don't know how to display an argument of type 'a(si)' The other commands seem to work. Perhaps it is a work in progress? Anyway, thanks for the clarification regarding the status of enlightenment_remote. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enlightenment_remote segfaults
On Wed, 9 Sep 2009 22:04:35 -0400 P Purkayastha said: > On Wednesday 09 September 2009 21:15:25 Carsten Haitzler wrote: > > On Sat, 5 Sep 2009 20:46:53 -0400 P Purkayastha said: > > > > you won't like this but e_remote and e's ipc are scheduled for death > > (removal). 1. we have a dbu api already for e, 2. this includes the core > > set of ops needed, 3. it's expandable by modules. the maintenance of > > ipc_handlers is painful. i want to nuke it. so... since it's scheduled for > > death... this will be a "wontfix" :) > > My scripts just got more complex then :( > (and my e17 config backup scripts have stopped working) e_remote doesnt expose all of e's config anyay. it has not been expanded to include new config for years. just copy the config files if u want to back up. hell - e backs up its own config these days. look at the file.1.cfg, file.2, .3, .4 etc. - each one is a successive backup - up to 9 previous versions are kept and e will fall back to previous versions if the new(er) ones are empty/corrupt. technically this also allows for config rollback if u made a booboo. no ui provided atm, but someone could brewup something in a module etc.. > Also, I can't seem to get a list of modules which are currently enabled. > qdbusviewer shows me that there is a Method:List. So I gave the following > command: > > ~> qdbus org.enlightenment.wm.service /org/enlightenment/wm/RemoteObject > org.enlightenment.wm.Module.List > qdbus: I don't know how to display an argument of type 'a(si)' dunno. sounds like your tools are inadequate. i've used d-feet myself if u want a ui to play with the dbus api's. :) > The other commands seem to work. Perhaps it is a work in progress? Anyway, > thanks for the clarification regarding the status of enlightenment_remote. no. not a work in progress. has worked for many moons now. many many many moons. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enlightenment_remote segfaults
On Wednesday 09 September 2009 22:17:48 you wrote:
> On Wed, 9 Sep 2009 22:04:35 -0400 P Purkayastha said:
> > On Wednesday 09 September 2009 21:15:25 Carsten Haitzler wrote:
> > > On Sat, 5 Sep 2009 20:46:53 -0400 P Purkayastha
> > > said:
> > >
> > > you won't like this but e_remote and e's ipc are scheduled for
> > > death (removal). 1. we have a dbu api already for e, 2. this includes
> > > the core set of ops needed, 3. it's expandable by modules. the
> > > maintenance of ipc_handlers is painful. i want to nuke it. so... since
> > > it's scheduled for death... this will be a "wontfix" :)
> >
> > My scripts just got more complex then :(
> > (and my e17 config backup scripts have stopped working)
>
> e_remote doesnt expose all of e's config anyay. it has not
> been expanded to include new config for years. just copy the config files
> if u want to back up. hell - e backs up its own config these days. look at
> the file.1.cfg, file.2, .3, .4 etc. - each one is a successive backup - up
> to 9 previous versions are kept and e will fall back to previous versions
> if the new(er) ones are empty/corrupt. technically this also allows for
> config rollback if u made a booboo. no ui provided atm, but someone could
> brewup something in a module etc..
Oh. So, *that's* what those numbered config files are! I have always wondered!
> > Also, I can't seem to get a list of modules which are currently enabled.
> > qdbusviewer shows me that there is a Method:List. So I gave the following
> > command:
> >
> > ~> qdbus org.enlightenment.wm.service /org/enlightenment/wm/RemoteObject
> > org.enlightenment.wm.Module.List
> > qdbus: I don't know how to display an argument of type 'a(si)'
>
> dunno. sounds like your tools are inadequate. i've used d-feet myself if u
> want a ui to play with the dbus api's. :)
>
qdbus and qdbusviewer are provided by qt-dbus. qdbusviewer, a GUI, can show
most but not all the output,- that is, it shows all the Methods available but
it is unable to show the output for some Methods. Following your hint, I tried
the dbus-send command itself, which comes with the dbus installation. It works
fine:
~> dbus-send --print-reply=literal --dest=org.enlightenment.wm.service
/org/enlightenment/wm/RemoteObject org.enlightenment.wm.Module.List
array [
struct {
gadman int32 1
}
struct {
systray int32 1
.
So, it was a bug in qdbus,- there goes another easy to use command :'( (dbus-
send is a horror of a command).
> > The other commands seem to work. Perhaps it is a work in progress?
> > Anyway, thanks for the clarification regarding the status of
> > enlightenment_remote.
>
> no. not a work in progress. has worked for many moons now. many many many
> moons. :)
Yes, it does work. Mainly some "core commands" as you pointed out :P
Thanks!
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Thu, 10 Sep 2009 10:53:17 +1000 Carsten Haitzler (The Rasterman) wrote: > i've sen this game played before (using high order bits) and then it > com crashing down on peoples heads when suddenly those used bits > become relevant. Microsoft BASIC for the Amiga I'll bet. lol signature.asc Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Thu, 10 Sep 2009 14:02:19 +1000 David Seikel said: > On Thu, 10 Sep 2009 10:53:17 +1000 Carsten Haitzler (The Rasterman) > wrote: > > > i've sen this game played before (using high order bits) and then it > > com crashing down on peoples heads when suddenly those used bits > > become relevant. > > Microsoft BASIC for the Amiga I'll bet. lol how did you know! :P -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Thu, 10 Sep 2009, Carsten Haitzler (The Rasterman) wrote: > On Thu, 10 Sep 2009 09:50:04 +1000 Simon Horman said: > >> On Wed, Sep 09, 2009 at 09:30:24AM +0200, Albin Tonnerre wrote: >>> On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : Is the following appropriate? - Subject: Add autogen.sh to dist tarball autogen.sh is used by the debian packaging so it seems appropriate to include it in the dist tarball >>> >>> Either you're packaging from SVN and therefore don't need it to be part of >>> the dist tarball, or you're packaging from the snapshots at >>> download.enlightenment.org (or snapshots you generated) and then your >>> packaging should be fixed to use directly ./configure instead of >>> configure.sh. Is there an actual use case I'm missing, for which this >>> change would be required? >> >> Thanks for filling me in on the expected usage. > > actually. alibin is wrong (sorry!) autogen's do get packaged. look at existing > efl. we put it in so if u get a tarball u CAN easily modify the configure.ac, > Makefile.am's etc. and re-generate the autofoo. the script will be there with > all the magic. not everyone will want or need to do this from a tarball dist - > but it dos happen. people patching packages are often the ones using it. so > it's not valid. it's an omission in the esmart build foo. :) (even if albin > was > right - eet, evas, elementary, edje, ... etc. all include autogen.sh in their > EXTRA_DIST, so it'd go in for consistency sake. it's goo to have everything in > svn have consistent autofoo files and work the same way. it makes everything > hav the same bug o everything is right. not some things buggy, some not, in > terms of autofoo usage/structure, so if u do find a bug/issue - u can know > that > fixing it everywhere else is trivial) get a source, modify configure.ac, run make. The autotools commands will be re-launched. Sometimes, when the modifications are too big, you need autogen.sh (i had that problem), or use autoreconf. Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] resolve eet build failure
As reported in track ticket 377 (amongst other things), eet seems to fail to build (on Debian). # svn checkout FOO/eet # cd eet # ./autogen.sh # make [snip] libtool: link: gcc -std=gnu99 -Wall -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o .libs/eet eet-eet_main.o ../../src/lib/.libs/libeet.so ../../src/lib/.libs/libeet.so: undefined reference to `clock_gettime' ../../src/lib/.libs/libeet.so: undefined reference to `dlsym' ../../src/lib/.libs/libeet.so: undefined reference to `dlerror' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_lock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_unlock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_init' ../../src/lib/.libs/libeet.so: undefined reference to `dladdr' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_destroy' ../../src/lib/.libs/libeet.so: undefined reference to `dlopen' ../../src/lib/.libs/libeet.so: undefined reference to `dlclose' collect2: ld returned 1 exit status make[3]: *** [eet] Error 1 make[3]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/horms/projects/e/svn/trunk/eet' make: *** [all] Error 2 A simple solution seems to be to link libeet against ldl and lrt as follows. Is this acceptable? --- eet.orig/src/lib/Makefile.am2009-09-10 15:40:32.0 +1000 +++ eet/src/lib/Makefile.am 2009-09-10 15:42:13.0 +1000 @@ -30,7 +30,7 @@ eet_node.c \ eet_utils.c libeet_la_CFLAGS = @EET_CFLAGS@ @DEBUG_CFLAGS@ -libeet_la_LIBADD = @GNUTLS_LIBS@ @OPENSSL_LIBS@ @EFL_COVERAGE_LIBS@ @EET_LIBS@ @EINA_LIBS@ @EVIL_LIBS@ -lz -ljpeg -lm +libeet_la_LIBADD = @GNUTLS_LIBS@ @OPENSSL_LIBS@ @EFL_COVERAGE_LIBS@ @EET_LIBS@ @EINA_LIBS@ @EVIL_LIBS@ -lz -ljpeg -lm -ldl -lrt libeet_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ @release_info@ EXTRA_DIST = Eet_private.h -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
