Re: [E-devel] Improving Elementary for the release
On 08/11/11 03:20, SANJEEV BA wrote: -- Insightful. -- Tom. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
On Mon, 7 Nov 2011 14:12:42 +0100 Cedric BAIL cedric.b...@free.fr said: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. yes - genlist (grid) - Elm_Gen_Item_Class, Elm_Genlist_Item_Class and Elm_Gengrid_Item_Class is mostly the culprit. we need to alloc this in elm so then elm knows its the right struct size for the version of elm running. the app knows how many members are there based on elm version so it can avoid using members if version when they were introduced. Elm_Entry_Filter_Limit_Size maybe is a candidate - but i don't think it ever needs changing, and if it did we'de provide a different callback to set other than elm_entry_filter_limit_size() Elm_Entry_Filter_Accept_Set i think is ok for the same reason as above. Elm_Web_Menu looks like it needs an allocation call from elm as well as Elm_Web_Menu_Item what's Elm_Web_Download for? it's not used anywhere? Elm_Slideshow_Item_Class is another culprit like gen*. Elm_Store_* stuff is... well interesting. i don't think this needs versioning as the mapping stuff can be extended by adding more enums for new mapping modes. we covered basic types and then extension via custom cb. so we're good here i think. the item info is alloced by elm and passed to app so thats ok. so summary: need allocators and freers, add ref count number (so genlist/grid/whatever while USING the item can keep it around if items referring to the class are around still even if app freed it): Elm_Gen_Item_Class Elm_Genlist_Item_Class Elm_Gengrid_Item_Class Elm_Web_Menu Elm_Web_Menu_Item Elm_Slideshow_Item_Class removal: Elm_Web_Download (n.b. i am basing only a need for an allocator on the assumption that if elm allocs and the struct gets bigger in future, new fields will be properly 0'd out and 0 will mean don't use or change behavior if old app doesn't touch new entires, and apps that want to handle older elm's can use elm version to know what members may not be there in older structs). The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
On Tue, 8 Nov 2011 18:31:23 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 7 Nov 2011 14:12:42 +0100 Cedric BAIL cedric.b...@free.fr said: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. yes - genlist (grid) - Elm_Gen_Item_Class, Elm_Genlist_Item_Class and Elm_Gengrid_Item_Class is mostly the culprit. we need to alloc this in elm so then elm knows its the right struct size for the version of elm running. the app knows how many members are there based on elm version so it can avoid using members if version when they were introduced. Elm_Entry_Filter_Limit_Size maybe is a candidate - but i don't think it ever needs changing, and if it did we'de provide a different callback to set other than elm_entry_filter_limit_size() Elm_Entry_Filter_Accept_Set i think is ok for the same reason as above. Elm_Web_Menu looks like it needs an allocation call from elm as well as Elm_Web_Menu_Item what's Elm_Web_Download for? it's not used anywhere? Elm_Slideshow_Item_Class is another culprit like gen*. Elm_Store_* stuff is... well interesting. i don't think this needs versioning as the mapping stuff can be extended by adding more enums for new mapping modes. we covered basic types and then extension via custom cb. so we're good here i think. the item info is alloced by elm and passed to app so thats ok. so summary: need allocators and freers, add ref count number (so genlist/grid/whatever while USING the item can keep it around if items referring to the class are around still even if app freed it): Elm_Gen_Item_Class ** Elm_Genlist_Item_Class Elm_Gengrid_Item_Class the above two will need to be removed by the time a release occurs. as it is, anyone using them is just hitting a define which maps them to Elm_Gen_Item_Class anyway. Elm_Web_Menu Elm_Web_Menu_Item Elm_Slideshow_Item_Class removal: Elm_Web_Download (n.b. i am basing only a need for an allocator on the assumption that if elm allocs and the struct gets bigger in future, new fields will be properly 0'd out and 0 will mean don't use or change behavior if old app doesn't touch new entires, and apps that want to handle older elm's can use elm version to know what members may not be there in older structs). The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
On Mon, Nov 7, 2011 at 10:40 PM, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
Ok, I checked Ecore.h and I see what you mean, but that's only useful if
you break the API, the padding is useful for not breaking the API but
keeping the .so ABI-compatible.
For example, if you only add a function to the API, you add the @since in
the docs, and all the software that was linked to your .so will still work
because the other functions are the same and their behavior is the same, so
it's not an API break, but you incremented the API with a new function that
can be used by future apps.
If that new function needs a variable in the structure, then you can just
replace one of the void * paddings and that's it, it works..
If you don't have padding and you add a new field in the struct, the
sizeof(struct whatever) will change, so anything that instanciates your
structure will be allocating wrongly sized memory and that can lead to
memory corruption (since your old API will be compiled with the new
sizeof). Thus breaks the ABI and it forces every app using your library to
get recompiled (no code change, it just needs a recompile) for it to work..
this also means that your .so version will need to change, .so.1.1 instead
of .so.1.0 for example, it basically amounts to the same as breaking the
API even though it's not necessary if you had padding.
Of course, any internal structure doesn't need that, so if you allocate a
structure using a function call and the user of the lib only sees it as an
opaque struct pointer, then you don't need padding, but if the struct
itself is defined in the .h and is public, then it would need the padding
to avoid breaking the ABI/API for compatible+incremental API changes.
This is a stupid workaround used in Gtk world. With version you can do
that and even more, you can even reorder fields, like below:
if (st-version == 1) {
Old_St *s = (Old_St *)st;
code_accessing_the_old_way(s);
} else if (st-version == 2) {
code_accessing_the_new_way(st);
}
In other words, you can know exactly what to do, and not just assume
you won't break because there is enough allocated memory to access.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
On Tue, Nov 8, 2011 at 9:18 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Nov 7, 2011 at 10:40 PM, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
Ok, I checked Ecore.h and I see what you mean, but that's only useful if
you break the API, the padding is useful for not breaking the API but
keeping the .so ABI-compatible.
For example, if you only add a function to the API, you add the @since in
the docs, and all the software that was linked to your .so will still
work
because the other functions are the same and their behavior is the same,
so
it's not an API break, but you incremented the API with a new function
that
can be used by future apps.
If that new function needs a variable in the structure, then you can just
replace one of the void * paddings and that's it, it works..
If you don't have padding and you add a new field in the struct, the
sizeof(struct whatever) will change, so anything that instanciates your
structure will be allocating wrongly sized memory and that can lead to
memory corruption (since your old API will be compiled with the new
sizeof). Thus breaks the ABI and it forces every app using your library
to
get recompiled (no code change, it just needs a recompile) for it to
work..
this also means that your .so version will need to change, .so.1.1
instead
of .so.1.0 for example, it basically amounts to the same as breaking the
API even though it's not necessary if you had padding.
Of course, any internal structure doesn't need that, so if you allocate a
structure using a function call and the user of the lib only sees it as
an
opaque struct pointer, then you don't need padding, but if the struct
itself is defined in the .h and is public, then it would need the padding
to avoid breaking the ABI/API for compatible+incremental API changes.
This is a stupid workaround used in Gtk world. With version you can do
that and even more, you can even reorder fields, like below:
yes it's a workaround in gtk world, doesn't make it stupid though.
And no, you missed my point completely, you can't do that with version.
if (st-version == 1) {
Old_St *s = (Old_St *)st;
code_accessing_the_old_way(s);
} else if (st-version == 2) {
code_accessing_the_new_way(st);
}
In other words, you can know exactly what to do, and not just assume
you won't break because there is enough allocated memory to access.
yes, that is *only* valid if you write your app after both version 1 and 2
have been released, and it means that the structure needs to be renamed
between both versions so it doesn't conflict, and mostly it means that your
version 2 breaks the API from version 1. If you read what I wrote, you'd
understand that the purpose is to release a new version without breaking
the API, without forcing every app to recompile itself or to change its
code... you cannot do that with version.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Improving Elementary for the release
Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
In my opinion, Elementary.h should be split into smaller files that it includes, kind of like what Eina.h does. If structures are made public, they should have a 'void *padding[MAX_PADDING];' added to the end, makes it easier to not break the ABI when adding new stuff. Other than that, I don't know elm enough to comment on anything else. On Mon, Nov 7, 2011 at 8:12 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
I'm strongly against padfings. Just have versioning and check it On Monday, November 7, 2011, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: In my opinion, Elementary.h should be split into smaller files that it includes, kind of like what Eina.h does. If structures are made public, they should have a 'void *padding[MAX_PADDING];' added to the end, makes it easier to not break the ABI when adding new stuff. Other than that, I don't know elm enough to comment on anything else. On Mon, Nov 7, 2011 at 8:12 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
Could you explain what you mean by versioning or give me a link to something that explains it ? padding is useful so you can change your structure (and add new APIs) without breaking the ABI and forcing every app to recompile (changed sizeof). On Mon, Nov 7, 2011 at 2:35 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm strongly against padfings. Just have versioning and check it On Monday, November 7, 2011, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: In my opinion, Elementary.h should be split into smaller files that it includes, kind of like what Eina.h does. If structures are made public, they should have a 'void *padding[MAX_PADDING];' added to the end, makes it easier to not break the ABI when adding new stuff. Other than that, I don't know elm enough to comment on anything else. On Mon, Nov 7, 2011 at 8:12 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
On Mon, Nov 7, 2011 at 22:37, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Could you explain what you mean by versioning or give me a link to something that explains it ? padding is useful so you can change your structure (and add new APIs) without breaking the ABI and forcing every app to recompile (changed sizeof). You should only need a spare (void *). -- Boris Faure -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
On Mon, 7 Nov 2011 16:37:39 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Could you explain what you mean by versioning or give me a link to something that explains it ? padding is useful so you can change your structure (and add new APIs) without breaking the ABI and forcing every app to recompile (changed sizeof). See Ecore.h, Ecore_Version. On Mon, Nov 7, 2011 at 2:35 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm strongly against padfings. Just have versioning and check it On Monday, November 7, 2011, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: In my opinion, Elementary.h should be split into smaller files that it includes, kind of like what Eina.h does. If structures are made public, they should have a 'void *padding[MAX_PADDING];' added to the end, makes it easier to not break the ABI when adding new stuff. Other than that, I don't know elm enough to comment on anything else. On Mon, Nov 7, 2011 at 8:12 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
Ok, I checked Ecore.h and I see what you mean, but that's only useful if you break the API, the padding is useful for not breaking the API but keeping the .so ABI-compatible. For example, if you only add a function to the API, you add the @since in the docs, and all the software that was linked to your .so will still work because the other functions are the same and their behavior is the same, so it's not an API break, but you incremented the API with a new function that can be used by future apps. If that new function needs a variable in the structure, then you can just replace one of the void * paddings and that's it, it works.. If you don't have padding and you add a new field in the struct, the sizeof(struct whatever) will change, so anything that instanciates your structure will be allocating wrongly sized memory and that can lead to memory corruption (since your old API will be compiled with the new sizeof). Thus breaks the ABI and it forces every app using your library to get recompiled (no code change, it just needs a recompile) for it to work.. this also means that your .so version will need to change, .so.1.1 instead of .so.1.0 for example, it basically amounts to the same as breaking the API even though it's not necessary if you had padding. Of course, any internal structure doesn't need that, so if you allocate a structure using a function call and the user of the lib only sees it as an opaque struct pointer, then you don't need padding, but if the struct itself is defined in the .h and is public, then it would need the padding to avoid breaking the ABI/API for compatible+incremental API changes. @Boris: technically, only one void * could be enough, but that means that if you need 2 new fields, you'd have to create a substructure and set that as your void *padding, and add padding in it too in case you still need to add stuff to your substructure, and it complicates everything.. usually you'd set 10 or 20 padding pointers or something so you can keep adding stuff to the struct in the future. You could also not put any padding, but just have a void *priv; at the end, then put any additional thing in this priv pointer to a private structure, but it will limit you in the sense that you won't be able to add new public fields to the struct, and any additions will have to be private. As an example, this would be impractical in the case of a MouseEvent structure, if you wanted to add a new field to it, then it probably needs to be public, not hidden in a private opaque structure. What do you think ? On Mon, Nov 7, 2011 at 4:42 PM, Boris Faure bill...@gmail.com wrote: On Mon, Nov 7, 2011 at 22:37, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Could you explain what you mean by versioning or give me a link to something that explains it ? padding is useful so you can change your structure (and add new APIs) without breaking the ABI and forcing every app to recompile (changed sizeof). You should only need a spare (void *). -- Boris Faure -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
