Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 9:49 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: I don't want everyone to always use it, it can be kept as a helper and people who wish to have an abstract data model (usually void *) and access it as a list can provide the iterator. I use it in my mvc lists, something like: model_set(void *model, eina_iterator_t *(*accessor_constructor)(void *model)) and whenever I want to iterate the whole list, I delete the old, create a new and start the loop. I think the iterator should be absolutely required to access the list contents. There have been many bugs in code that uses evas_lists simply because the API is designed to maintain references into internal structures (the list nodes). The mempool makes this even more difficult to debug since the nodes are not freed, and are often re-used as other list nodes. Even if they are not re-used, they can contain pointers within the remnants of the list and so appears valid. It's a bit different as it's an external structure, you can create as much iterators or accessors as you want and use them in different ways. What you CAN'T is modify the iterated/accessed object while it's in use. This is basically what we've been proposing for ecore_lists except for the non-modify requirement. What reason do you have for not allowing any modifications through the iterators? Nathan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 4:49 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
great!
Making eina thread safe is one of the goal. As I care about
performance, I just don't know how, but definitively on the road map.
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
I don't want everyone to always use it, it can be kept as a helper and
people who wish to have an abstract data model (usually void *) and
access it as a list can provide the iterator. I use it in my mvc
lists, something like: model_set(void *model, eina_iterator_t
*(*accessor_constructor)(void *model)) and whenever I want to iterate
the whole list, I delete the old, create a new and start the loop.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
It's a bit different as it's an external structure, you can create as
much iterators or accessors as you want and use them in different
ways. What you CAN'T is modify the iterated/accessed object while it's
in use.
Similar to eina_iterator:
typedef struct eina_accessor {
int (*get)(eina_acessor_t *accessor, int index, void **data);
void (*free)(eina_accessor_t *accessor);
} eina_acessor_t;
When you want to create an accessor for Evas_List, you extend this
with some members:
struct eina_accessor_evas_list {
eina_accessor_t base;
const Evas_List *head;
struct {
const Evas_List *node;
int index;
} last_used;
}
when you access some index you calculate: am I near to 'index' going
from head (0), tail (evas_list_count()) or last_used index? Than you
calculate the direction and how many items you have to go.
This accessor and iterator stuff sounds interresting feature to me
too. I am going to add them to eina during the week. Do people want
this also for inlist too ?
--
Cedric BAIL
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Re: [E-devel] Eina ideas and requests
On Mon, Aug 4, 2008 at 3:16 AM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Sat, Aug 2, 2008 at 9:49 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: I don't want everyone to always use it, it can be kept as a helper and people who wish to have an abstract data model (usually void *) and access it as a list can provide the iterator. I use it in my mvc lists, something like: model_set(void *model, eina_iterator_t *(*accessor_constructor)(void *model)) and whenever I want to iterate the whole list, I delete the old, create a new and start the loop. I think the iterator should be absolutely required to access the list contents. There have been many bugs in code that uses evas_lists simply because the API is designed to maintain references into internal structures (the list nodes). The mempool makes this even more difficult to debug since the nodes are not freed, and are often re-used as other list nodes. Even if they are not re-used, they can contain pointers within the remnants of the list and so appears valid. my personal experience with such is different. I see more and more people used to manipulate these lists, and if you make it clear you should not modify list while iterating, or you have to take double-care, then errors go to 0. Often I use kernel like macros to do iteration, and they even have macros to deal with lists that can change. I guess the point of direct access is to make it fast, we can make them more safe by using these macros. And the point of iterators is to make various data type access uniform, I can get the iterator for a list, array, chuncked list, hash, ... As for the mempool, AFAIK eina has changeable subsystems, we can do like others and have one subsystem that just malloc/free for ease of debug. It's a bit different as it's an external structure, you can create as much iterators or accessors as you want and use them in different ways. What you CAN'T is modify the iterated/accessed object while it's in use. This is basically what we've been proposing for ecore_lists except for the non-modify requirement. What reason do you have for not allowing any modifications through the iterators? Not a real reason, mostly due simplicity of implementation. If you want to make them modifications-proof, then just keep callbacks between created iterators and when you request some change you walk these and reset their internal pointers. It's a bit more complicated, but safer, yes. When doing such central things I often like to avoid over-engineering the common case, that is walking the objects without modifications, but trying to provide easy ways to do the others so users don't do mistakes. I think that linux kernel (include/linux/list.h) is a good example of that, it's low-overhead, well documented and safe to use. They provide list_for_each() and list_for_each_safe() (and similar) macros. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina ideas and requests
On Mon, Aug 4, 2008 at 6:28 AM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 4:49 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
great!
Making eina thread safe is one of the goal. As I care about
performance, I just don't know how, but definitively on the road map.
see, I'm talking about mempool here, not really about types being
thread safe. You can do that by either adding locks to current
implementation or choosing another algorithm (?), maybe look at how
others do (glib/gslice, pymalloc, malloc itself).
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
I don't want everyone to always use it, it can be kept as a helper and
people who wish to have an abstract data model (usually void *) and
access it as a list can provide the iterator. I use it in my mvc
lists, something like: model_set(void *model, eina_iterator_t
*(*accessor_constructor)(void *model)) and whenever I want to iterate
the whole list, I delete the old, create a new and start the loop.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
It's a bit different as it's an external structure, you can create as
much iterators or accessors as you want and use them in different
ways. What you CAN'T is modify the iterated/accessed object while it's
in use.
Similar to eina_iterator:
typedef struct eina_accessor {
int (*get)(eina_acessor_t *accessor, int index, void **data);
void (*free)(eina_accessor_t *accessor);
} eina_acessor_t;
When you want to create an accessor for Evas_List, you extend this
with some members:
struct eina_accessor_evas_list {
eina_accessor_t base;
const Evas_List *head;
struct {
const Evas_List *node;
int index;
} last_used;
}
when you access some index you calculate: am I near to 'index' going
from head (0), tail (evas_list_count()) or last_used index? Than you
calculate the direction and how many items you have to go.
This accessor and iterator stuff sounds interresting feature to me
too. I am going to add them to eina during the week. Do people want
this also for inlist too ?
I'd add them
[E-devel] Eina ideas and requests
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
great!
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
I don't want everyone to always use it, it can be kept as a helper and
people who wish to have an abstract data model (usually void *) and
access it as a list can provide the iterator. I use it in my mvc
lists, something like: model_set(void *model, eina_iterator_t
*(*accessor_constructor)(void *model)) and whenever I want to iterate
the whole list, I delete the old, create a new and start the loop.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
It's a bit different as it's an external structure, you can create as
much iterators or accessors as you want and use them in different
ways. What you CAN'T is modify the iterated/accessed object while it's
in use.
Similar to eina_iterator:
typedef struct eina_accessor {
int (*get)(eina_acessor_t *accessor, int index, void **data);
void (*free)(eina_accessor_t *accessor);
} eina_acessor_t;
When you want to create an accessor for Evas_List, you extend this
with some members:
struct eina_accessor_evas_list {
eina_accessor_t base;
const Evas_List *head;
struct {
const Evas_List *node;
int index;
} last_used;
}
when you access some index you calculate: am I near to 'index' going
from head (0), tail (evas_list_count()) or last_used index? Than you
calculate the direction and how many items you have to go.
You can build ecore api on top of this if you link to the accessor to
the model and every time model change, you fix the accessor to avoid
invalid references.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
