This API is what could be used by all EFL library for their exposed
type (Evas_Object, Ecore_Timer, Ecore_Animator, Eio_File, ...). The
purpose of Eina_Object is to provide an "obscure" pointer that is
infact an ID with a generation count that will never be dereferenced
directly.
This provide the benefit of always accessing a living object
with 1/256 chance to being the expected generation of it, that will
always be of the right type.
It also provide asynchronous repacking ability (still highly
inefficient, but not really hard to improve), simple inheritance
with constructor/destructor and link between object.
All this implementation is highly open for comment, idea, review,
fix and change. I didn't got the time to write a sample test right
now. Maybe will come tomorrow. Same for docs.
SVN revision: 58562
TODO: fix docs (but today, eina doc need some love again)
use iconv and handle encoding (can get entity-to-utf8 from evas)
description of what to do at :
http://marc.info/?l=enlightenment-devel&m=129975452006699&w=3
NOTE: this mean this API is not stable yet and will be broken soon.
SVN revision: 58387
NOTE: to prevent ABI break, I added the old symbol in eina_abi.c.
So binary/library using eina_array_clean should continue to work
without any problem.
SVN revision: 55068
This function is useful for libraries like ecore and evas that have to
set some worker threads. The first thing these threads should do is to
call this function, so the main thread might continue running without
the worker threads interrupting it too much.
SVN revision: 52651
code formatting still (headers specifically). bring doc building
in-line with other efl libs. README is useful now. Changelog waiting
to be filled in for 1.0.0
SVN revision: 51154
Also modified Eina_Stringshare to share most of the code with the two above.
Added Magics for Eina_UStrbuf as well as for UStringshare/Binshare.
SVN revision: 50533
This will concatenate all source files in the hope compiler will do a
better job. On my test with static/built in mempools it saves me 4k, I
guess some intra module calls can be saved.
SVN revision: 42315
Sparse Matrix was implemented and tested by Rafael Antognolli and
myself in order to implement optimized large sparse matrix walk in
some products, one of them WebKit-EFL optimizations.
We have done extensive tests, with good code coverage. Similar to
lists/inlists, we keep pointer to last known element and similar to
iterators we keep reference to last accessed row and cell inside
rows. This allows fast sequential access (for i... for j... m[i,j]),
that is our most common usage case.
Rows are kept in a list, with cells inside that row as another
list. It's not similar to most book implementations where cells keep
reference to their sibling cells in other rows as well, we opted to
not do that to save some pointers and make algorithms simpler, still
do great for our use case.
This code was developed on behalf of our client, that wants to remain
unnamed so far. Thanks client ;-)
SVN revision: 42243
All these individual init functions are getting messy, some modules
lack them and it's easy to get inconsistent. Safety check needs error
and log, but these need safety checks as well, some modules (lalloc,
rbtree and others) use safety checks but provide no _init().
I want to know if we really gain something to init individual
modules. It should not be that expensive as init should not allocate
heavy resources and the recommendation is to call eina_init() so most
users will do that anyway.
If people agree I'll unmark all *_init() as EAPI and make them private
to eina lib.
SVN revision: 42214
* eina_error might be kept for error messages and codes, but it's logging API
will be deprecated. For now, it's been kept for not breaking others code and
for a smoother transition.
* Added test for new logging API, also demonstrates usage.
SVN revision: 41960
<dieb_> weird, undefined refernce to eina_cpu_count
<raster> you have no cpus!
<dieb_> dammit!
<Sachiel> try eina_hamster_count
<dieb_> lo
<raster> oh god
<raster> now u did it
<raster> i have to add that
<dieb_> heheheh
SVN revision: 41727
* Allow to pass 'static' to configure memory pools
* Add fixed_bitmap in the possible statically linked memory pools
For example:
./configure --enable-chained-pool=static --disable-fixed-bitmap
SVN revision: 41119