Re: [E-devel] eina freeq?

[The Rasterman]

On Thu, 10 Nov 2016 15:14:11 + Mike Blumenkrantz
 said:

> I see that this has been pushed and is already being used despite some
> objections being raised? I guess I probably missed IRC discussions.

did you read the responses to the objections? in fact just one objection. it
was "dont like" and under valgrind frees are now asynchronous - read the code.
it was misunderstanding that this is a replacement of valgrind where it is not.
it's a stability measure for average users when valgrind is not in use by
delaying pointer re-use. it also can defer any work involved in freeing to
'when idle'. and if under valgrind the frees are done synchronously without
being queued so it catches everything as it does right now leaving it to
valgrind. so the issue was addressed if you read the code.

> The reasoning for needing this sounds like we should probably just use
> jemalloc (
> https://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919/
> ), which does more, has more people actively devoted to improving/developing
> it, and has been widely tested and benchmarked so we know it will
> definitely have the effect that we want while also reducing our
> maintenance+development overhead.

which actually is entirely orthogonal. and i've proposed a more extensive way
of having an allocator with multiple allocation domains - it could be jemalloc
WITH modifications. did you read the mail?

Subject: [E-devel] memory allocation perf

but freeq works WITHOUT pulling in jemalloc. it enforces a purgatory for
pointers put in the freeq irrespective of malloc implementation. it's simple
and easy to work with. it actually does hat people THOUGHT eina_trash should do
but doesn't. freeq enables us to debug core dumps when people dont use valgrind
- which they don't. valgrind does not even work on openbsd, so proposing it as
a solution to help debug there is pointless. and people doing Qa dont use
valgrind. they dont even know how to AND it makes things so slow that they
never would even if it was just a checkbox. yes there is MALLOC_PERTURB_ but it
as no upper limit (free 1mb of data and 1mb is filled with pattern data), so it
has a pretty hefty impact. it's also glibc only.

malloc replacement is a far deeper topic. JUST blindly using jemalloc can't be
done as it'd replace all *alloc/free funcs, so the method to do that is an
LD_PRELOAD. to use it without a preload means wrapping it in some calls and
then replacing one thing at a time with this "eina_alloc" api (memory blob by
blob). i do not want to do that with JUST a plain void * replacement. it's not
as much of a win as it could be. if we have to go replace things pointer by
pointer, let's do better. with a custom alloc impl we can:

1. have allocation domains that separate memory out like:

domain1 = eina_alloc_domain_new();
ptr = eina_alloc(domain1, size);
eina_alloc_free(domain1, ptr);

whereas having a NULL domain be like malloc/free as an implicit global:

ptr = eina_alloc(NULL, size);

this allows the back-end to be a single pool or BETTER multiple
address-separated pools meaning we can ensure the pointers for one kind of data
don't rub shoulders with another which means use-after-free within code segment
A is LESS likely to corrupt data from code segment B if the memory they use
come from different domains.

2. do small pointers. 32bit ptrs on 64bit machines halving our memory footprint
for pointers (and we use a LOT of pointers). this may actually even sped things
up as we pollute our caches less. a single 32bit domain for almost all of efl's
allocations "should be enough for everything" as if we 16 byte align we
actually have access to up to 64gb of allocated memory, and 32gb if we 8 byte
align which would be necessary anyway (probably a good call given simd
implementations can do 128bit types these days, and maybe 32byte align on
systems with 256 bit type support). i am not proposing we use 32bit ptrs for
allocating audio data or video or images - the large blobs. just "data
structures". we can then ALSO do 16bit pointers too (each domain could allocate
up to 1m of data with 16byte alignment, 512k with 8). so if we use domains
carefully we can drop pointer sizes down even more for certain special cases
(assuming the whole workload of memory use for that domain would always remain
small enough to fit inside the domain max pool of eg 512k or 1m). yes. now
access to these small ptrs requires resolving them like:

   realptr = domain->base + (ptr << 4);

likely a macro or static inline would do this. yes. it requires KNOWING the
domain the ptr comes from. we COULD have the NULL domain be a special "global
domain" like malloc/free do and so domain is a known global var
(eina_alloc_domain, eina_alloc_domain_32, eina_alloc_domain_16 - with plain
domain and 32 domain maybe being #defined to be the same thing on a 32bit
machine).

either way this requires more than just 

Re: [E-devel] eina freeq?

[Mike Blumenkrantz]

I see that this has been pushed and is already being used despite some
objections being raised? I guess I probably missed IRC discussions.

The reasoning for needing this sounds like we should probably just use
jemalloc (
https://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919/),
which does more, has more people actively devoted to improving/developing
it, and has been widely tested and benchmarked so we know it will
definitely have the effect that we want while also reducing our
maintenance+development overhead.

On Fri, Nov 4, 2016 at 10:08 AM Carsten Haitzler 
wrote:

> On Fri, 4 Nov 2016 10:18:33 -0200 Gustavo Sverzut Barbieri <
> barbi...@gmail.com>
> said:
>
> > On Thu, Nov 3, 2016 at 9:27 PM, Carsten Haitzler 
> wrote:
> > > On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri
> > >  said:
> > >
> > >> I guessed mempool and eina_trash did that
> > >
> > > nah - mempool i don't think has a "purgatory" for pointers.
> > > they are released back into the pool.
> >
> > well, it could... OTOH it's just for "empty blocks", since if it's in
> > a mempool that has memory blocks and they're still in use, it will
> > just flag as unused.
> >
> > also, it simplifies bookkeeping of the memory if they are all of the
> > same size, like you said Eina_List, it knows the size of each entry,
> > thus just need to mark each position that is usable, not try to
> > allocate based on size or similar -- much more efficient.
>
> yah. that's what mempool does... but it doesnt have 2 states for an
> allocation.
> it doesnt have "in use" "freed but not able to be reused yet" and "free and
> able to be re-used". it just has 1. in use or not.
>
> > > trash is actually a cache for storing ptrs but it never
> > > actually frees anything. it doesn't know how to. you have to manually
> clean
> > > trash yourself and call some kind of free func when you do the clean.
> trash
> > > doesn't store free funcs at all.
> >
> > I don't see why it couldn't.
>
> but it doesn't, and eina_trash is all static inlines with structs exposed
> so
> we'd break struct definition, memory layout and api to do this. if an
> eina_trash is exposed from a lib compiled against efl 1.18 against other
> code
> compiled against 1.19 - it'd break. even worse eina_trash is a single
> linked
> list so walking through it is scattered through memory thus basically
> likely a
> cache miss each time.
>
> > but I find this is trying to replace malloc's internal structures,
> > which is not so nice. As you know, malloc implementation can
> > postpone/defer actual flushes, it's not 1:1 with brk() and munmap()
> > since like our mempools the page or stack may have used bits that
> > prevents that to be given back to the kernel.
>
> i know. but it's out of our control. we can't change what and how malloc
> does
> this. we can't do smarter overwrite detection. malloc has options for
> filling
> freed memory with a pattern - but it will do it to any sized allocation. 1
> byte
> or 1 gigabyte. with a custom implementation WE can decide eg only fill in
> up to
> 256 bytes as this is what might be sued for small objects/list nodes but
> leave
> big allocations untouched or .. only fill in the FIRST N bytes of an
> allocation with a pattern. if the pattern has been overwritten between
> submission to a free queue AND when it is actually freed then we have a
> bug in
> code somewhere scribbling over freed memory. at least we know it and know
> what
> to be looking for. malloc is far more limited in this way.
>
> also we can defer freeing until when WE want. e.g. after having gone idle
> and
> we would otherwise sleep. malloc really doesnt have any way to do this
> nicely.
> it's totally non-portable, libc specific (eg glibc) etc. and even then very
> "uncontrollable". a free queue of our own is portable AND controllable.
>
> > what usually adds overhead are mutexes and the algorithms trying to
> > find an empty block... if we say freeq/trash are TLS/single-thread,
> > then we could avoid the mutex (but see malloc(3) docs on how they try
> > to minimize that contention), but adding a list of entries to look for
> > a free spot is likely worse than malloc's own tuned algorithm.
>
> no no. i'm not talking about making a CACHE of memory blocks. simply a
> fifo.
> put a ptr on the queue with a free func. it sits there for some time and
> then
> something walks this from beginning to end actually freeing. e.g. once we
> have
> reached and idle sleep state. THEN the frees really happen. once on the
> free
> queue there is no way off. you are freed. or to be freed. only a question
> of
> when.
>
> if there is buggy code that does something like:
>
> x = malloc(10);
> x[2] = 10;
> free(x);
> y = malloc(10);
> y[2] = 10;
> x[2] = 5;
>
> ... there is a very good chance y is a recycled pointer - same mem
> location as
> x. when we do x[2] = 5 we overwrite y[2] with 5 

Re: [E-devel] eina freeq?

[The Rasterman]

On Fri, 4 Nov 2016 10:18:33 -0200 Gustavo Sverzut Barbieri 
said:

> On Thu, Nov 3, 2016 at 9:27 PM, Carsten Haitzler  wrote:
> > On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri
> >  said:
> >
> >> I guessed mempool and eina_trash did that
> >
> > nah - mempool i don't think has a "purgatory" for pointers.
> > they are released back into the pool.
> 
> well, it could... OTOH it's just for "empty blocks", since if it's in
> a mempool that has memory blocks and they're still in use, it will
> just flag as unused.
> 
> also, it simplifies bookkeeping of the memory if they are all of the
> same size, like you said Eina_List, it knows the size of each entry,
> thus just need to mark each position that is usable, not try to
> allocate based on size or similar -- much more efficient.

yah. that's what mempool does... but it doesnt have 2 states for an allocation.
it doesnt have "in use" "freed but not able to be reused yet" and "free and
able to be re-used". it just has 1. in use or not.

> > trash is actually a cache for storing ptrs but it never
> > actually frees anything. it doesn't know how to. you have to manually clean
> > trash yourself and call some kind of free func when you do the clean. trash
> > doesn't store free funcs at all.
> 
> I don't see why it couldn't.

but it doesn't, and eina_trash is all static inlines with structs exposed so
we'd break struct definition, memory layout and api to do this. if an
eina_trash is exposed from a lib compiled against efl 1.18 against other code
compiled against 1.19 - it'd break. even worse eina_trash is a single linked
list so walking through it is scattered through memory thus basically likely a
cache miss each time.

> but I find this is trying to replace malloc's internal structures,
> which is not so nice. As you know, malloc implementation can
> postpone/defer actual flushes, it's not 1:1 with brk() and munmap()
> since like our mempools the page or stack may have used bits that
> prevents that to be given back to the kernel.

i know. but it's out of our control. we can't change what and how malloc does
this. we can't do smarter overwrite detection. malloc has options for filling
freed memory with a pattern - but it will do it to any sized allocation. 1 byte
or 1 gigabyte. with a custom implementation WE can decide eg only fill in up to
256 bytes as this is what might be sued for small objects/list nodes but leave
big allocations untouched or .. only fill in the FIRST N bytes of an
allocation with a pattern. if the pattern has been overwritten between
submission to a free queue AND when it is actually freed then we have a bug in
code somewhere scribbling over freed memory. at least we know it and know what
to be looking for. malloc is far more limited in this way.

also we can defer freeing until when WE want. e.g. after having gone idle and
we would otherwise sleep. malloc really doesnt have any way to do this nicely.
it's totally non-portable, libc specific (eg glibc) etc. and even then very
"uncontrollable". a free queue of our own is portable AND controllable.

> what usually adds overhead are mutexes and the algorithms trying to
> find an empty block... if we say freeq/trash are TLS/single-thread,
> then we could avoid the mutex (but see malloc(3) docs on how they try
> to minimize that contention), but adding a list of entries to look for
> a free spot is likely worse than malloc's own tuned algorithm.

no no. i'm not talking about making a CACHE of memory blocks. simply a fifo.
put a ptr on the queue with a free func. it sits there for some time and then
something walks this from beginning to end actually freeing. e.g. once we have
reached and idle sleep state. THEN the frees really happen. once on the free
queue there is no way off. you are freed. or to be freed. only a question of
when.

if there is buggy code that does something like:

x = malloc(10);
x[2] = 10;
free(x);
y = malloc(10);
y[2] = 10;
x[2] = 5;

... there is a very good chance y is a recycled pointer - same mem location as
x. when we do x[2] = 5 we overwrite y[2] with 5 even tho it now should be 10.
yes. valgrind can catch these... but you HAVE to catch them while running.
maybe it only happens in certain logic paths. yes. coverity sometimes can find
these too through static analysis. but not always. and then there are the cases
where this behaviour is split across 2 different projects. one is efl, the
other is some 3rd party app/binary that does something bad. the "y" malloc is
in efl. the c one is in an app. the app now scribbles over memory owned by efl.
this is bad. so efl now crashes with corrupt data structures and we can never
fix this at all as the app is a 3rd party project simply complaining that a
crash is happening in efl.

we can REDUCE these issues by ensuring the x pointer is not recycled so
aggressively by having a free queue. have a few hundred or a few thousand
pointers sit on that queue for a 

Re: [E-devel] eina freeq?

[Gustavo Sverzut Barbieri]

On Thu, Nov 3, 2016 at 9:27 PM, Carsten Haitzler  wrote:
> On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri 
> 
> said:
>
>> I guessed mempool and eina_trash did that
>
> nah - mempool i don't think has a "purgatory" for pointers.
> they are released back into the pool.

well, it could... OTOH it's just for "empty blocks", since if it's in
a mempool that has memory blocks and they're still in use, it will
just flag as unused.

also, it simplifies bookkeeping of the memory if they are all of the
same size, like you said Eina_List, it knows the size of each entry,
thus just need to mark each position that is usable, not try to
allocate based on size or similar -- much more efficient.


> trash is actually a cache for storing ptrs but it never
> actually frees anything. it doesn't know how to. you have to manually clean
> trash yourself and call some kind of free func when you do the clean. trash
> doesn't store free funcs at all.

I don't see why it couldn't.

but I find this is trying to replace malloc's internal structures,
which is not so nice. As you know, malloc implementation can
postpone/defer actual flushes, it's not 1:1 with brk() and munmap()
since like our mempools the page or stack may have used bits that
prevents that to be given back to the kernel.

what usually adds overhead are mutexes and the algorithms trying to
find an empty block... if we say freeq/trash are TLS/single-thread,
then we could avoid the mutex (but see malloc(3) docs on how they try
to minimize that contention), but adding a list of entries to look for
a free spot is likely worse than malloc's own tuned algorithm.


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina freeq?

[The Rasterman]

On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri 
said:

> I guessed mempool and eina_trash did that 

nah - mempool i don't think has a "purgatory" for pointers. they are released
back into the pool. trash is actually a cache for storing ptrs but it never
actually frees anything. it doesn't know how to. you have to manually clean
trash yourself and call some kind of free func when you do the clean. trash
doesn't store free funcs at all.

> --
> Gustavo Sverzut Barbieri
> 
> > Em 3 de nov de 2016, às 05:53, Carsten Haitzler (The Rasterman)
> >  escreveu:
> > 
> > On Thu, 03 Nov 2016 09:35:21 +0200 Daniel Zaoui 
> > said:
> > 
> >> Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?
> > 
> > this isn't async. it's just deferred. we already do this for evas objects
> > with delete_me. we do it for timers/animators and mark them for deletion
> > later. it's nothing new. this is just more generic/extensive
> > 
> >>> From my point of view, seems to be like a hack cause some problems (e.g
> >>> Eo) are hard to solve.
> >> 
> >> My comments below.
> >> 
> >> On Thu, 03 Nov 2016 16:11:24 +0900
> >> Carsten Haitzler  (The Rasterman) wrote:
> >> 
> >>> here's an idea. it's very very very very simple
> >>> 
> >>> create an eina_freeq(). instead of calling free() or whatever free
> >>> function on something immediately, call:
> >>> 
> >>>fq = eina_freeq_main_get();
> >>>eina_freeq_ptr_add(fq, pointer, size, free);
> >>> 
> >>> or
> >>> 
> >>>fq = eina_freeq_global_get();
> >>>eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
> >>> _eina_list_mempool_list_free);
> >>> 
> >>> etc.
> >>> 
> >>> and the free queue will "add this to the end" to be freed some time
> >>> later. the idea of size is so it could make intelligent choice like
> >>> to free very large chunks earlier than smaller allocations. the
> >>> mainloop would drive this actual freeing. or more specifically your
> >>> LOCAL loop would. need to add some kind of loop method that returns
> >>> the "free queue" FOR your loop/thread. or wherever you want it
> >>> actually freed. probably have a main free queue driven by the
> >>> mainloop (and cleared up on eina_shutdown) etc.
> >>> 
> >>> why?
> >>> 
> >>> 1. move overhead of doing actual frees out of critical code into idle
> >>> time
> >>> 2. improve stability by keeping memory eg for eo objects or eina
> >>> list nodes in a "free queue purgatory" for a while so if someone does
> >>> bad things like "use after free" the IMPACT is far smaller as they
> >>> mess with memory in the free queue not being used.
> >> 
> >> Stability has to be improved with refs and other design technics, not with
> >> delay. More, we can't use anymore Valgrind. And this will be PITA to debug.
> >> The same kind of debug with async events where the frame before is
> >> ecore_loop...
> > 
> > we can use valgrind. just have freeq free immediately. env vars can switch
> > behavior around. :) so valgrind - can work trivially.
> > 
> >> btw, the third point didn't leave your head ;-)
> > 
> > oh yeah.. it got lost on the way to the kbd. :)
> > 
> >>> 4. be able to fill memory about to be freed with patterns (eg 0x55 or
> >>> 0xaa) so after free the memory is guaranteed to have a pattern to
> >>> know it was freed (optional debug only for mem regions of size > 0
> >>> and maybe less than some max size).
> >> 
> >> meow (I think this is what you say when you don't know if it is a good
> >> feature or not :-).
> >> 
> >>> 5. optional - checksum the memory when added to free queue then check
> >>> checksum on actual free to warn of some code "being bad" and
> >>> scribbling over freed memory. at least we get warnings of lurking
> >>> bugs if we turn this on...
> >> 
> >> Valgrind does it better.
> > 
> > the problem is we have people who will NOT RUN STUFF UNDER VALGRIND.
> > 
> > 1. for example valgrind doesnt work on openbsd. at all.
> > 2. good luck with valgrind on something like an rpi ... go and make lunch
> > while you wait for your app to start. make coffee in between clicks.the bug
> > you were looking for likely disappeared because timing changed so
> > drastically you cant catch it. i've seen this happen before.
> > 3. people run/test and they do not want to slow things down to 1/50th of the
> > speed. they CAN'T, so having a pattern means its a very low cost and
> > coredumps can tell us far more information on what is going on. you cant
> > force testers in qa to "run it under valgrind". they dont even know what it
> > is, nor can they even do it. the speed impact along vetoes it. the impact
> > of memset() for smallish things (eg < 1k) is going to be MASSIVELY less.
> > 4. this doesn't replace valgrind. it augments it for when valgrind is just
> > not viable. it at least gives us a CLUE. JP just was telling me of an issue
> > where a Eina_List * ptr in an evas object is 0x1 ... it should never be

Re: [E-devel] eina freeq?

[Gustavo Sverzut Barbieri]

I guessed mempool and eina_trash did that 

--
Gustavo Sverzut Barbieri

> Em 3 de nov de 2016, às 05:53, Carsten Haitzler (The Rasterman) 
>  escreveu:
> 
> On Thu, 03 Nov 2016 09:35:21 +0200 Daniel Zaoui  
> said:
> 
>> Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?
> 
> this isn't async. it's just deferred. we already do this for evas objects with
> delete_me. we do it for timers/animators and mark them for deletion later. 
> it's
> nothing new. this is just more generic/extensive
> 
>>> From my point of view, seems to be like a hack cause some problems (e.g Eo)
>>> are hard to solve.
>> 
>> My comments below.
>> 
>> On Thu, 03 Nov 2016 16:11:24 +0900
>> Carsten Haitzler  (The Rasterman) wrote:
>> 
>>> here's an idea. it's very very very very simple
>>> 
>>> create an eina_freeq(). instead of calling free() or whatever free
>>> function on something immediately, call:
>>> 
>>>fq = eina_freeq_main_get();
>>>eina_freeq_ptr_add(fq, pointer, size, free);
>>> 
>>> or
>>> 
>>>fq = eina_freeq_global_get();
>>>eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
>>> _eina_list_mempool_list_free);
>>> 
>>> etc.
>>> 
>>> and the free queue will "add this to the end" to be freed some time
>>> later. the idea of size is so it could make intelligent choice like
>>> to free very large chunks earlier than smaller allocations. the
>>> mainloop would drive this actual freeing. or more specifically your
>>> LOCAL loop would. need to add some kind of loop method that returns
>>> the "free queue" FOR your loop/thread. or wherever you want it
>>> actually freed. probably have a main free queue driven by the
>>> mainloop (and cleared up on eina_shutdown) etc.
>>> 
>>> why?
>>> 
>>> 1. move overhead of doing actual frees out of critical code into idle
>>> time
>>> 2. improve stability by keeping memory eg for eo objects or eina
>>> list nodes in a "free queue purgatory" for a while so if someone does
>>> bad things like "use after free" the IMPACT is far smaller as they
>>> mess with memory in the free queue not being used.
>> 
>> Stability has to be improved with refs and other design technics, not with
>> delay. More, we can't use anymore Valgrind. And this will be PITA to debug.
>> The same kind of debug with async events where the frame before is
>> ecore_loop...
> 
> we can use valgrind. just have freeq free immediately. env vars can switch
> behavior around. :) so valgrind - can work trivially.
> 
>> btw, the third point didn't leave your head ;-)
> 
> oh yeah.. it got lost on the way to the kbd. :)
> 
>>> 4. be able to fill memory about to be freed with patterns (eg 0x55 or
>>> 0xaa) so after free the memory is guaranteed to have a pattern to
>>> know it was freed (optional debug only for mem regions of size > 0
>>> and maybe less than some max size).
>> 
>> meow (I think this is what you say when you don't know if it is a good
>> feature or not :-).
>> 
>>> 5. optional - checksum the memory when added to free queue then check
>>> checksum on actual free to warn of some code "being bad" and
>>> scribbling over freed memory. at least we get warnings of lurking
>>> bugs if we turn this on...
>> 
>> Valgrind does it better.
> 
> the problem is we have people who will NOT RUN STUFF UNDER VALGRIND.
> 
> 1. for example valgrind doesnt work on openbsd. at all.
> 2. good luck with valgrind on something like an rpi ... go and make lunch 
> while
> you wait for your app to start. make coffee in between clicks.the bug you were
> looking for likely disappeared because timing changed so drastically you cant
> catch it. i've seen this happen before.
> 3. people run/test and they do not want to slow things down to 1/50th of the
> speed. they CAN'T, so having a pattern means its a very low cost and coredumps
> can tell us far more information on what is going on. you cant force testers 
> in
> qa to "run it under valgrind". they dont even know what it is, nor can they
> even do it. the speed impact along vetoes it. the impact of memset() for
> smallish things (eg < 1k) is going to be MASSIVELY less.
> 4. this doesn't replace valgrind. it augments it for when valgrind is just not
> viable. it at least gives us a CLUE. JP just was telling me of an issue where 
> a
> Eina_List * ptr in an evas object is 0x1 ... it should never be 0x1. it should
> be some valid ptr value or NULL. something scribbled to this memory when it
> should not have. LIKELY something like using a ptr after free and that ptr
> HAPPENED to point to this object memory. we have no clue who did it and
> valgrind can't catch this as its not freed ... YET. but if that memory WAS
> handled by a free queue this would be far less likely to happen as the "write
> to unused memory" would be less likely to affect a live real object. you want
> things to be as robust as possible with minimal if not zero cost when you are
> NOT running under valgrind. in fact i can detect if 

Re: [E-devel] eina freeq?

[The Rasterman]

On Thu, 03 Nov 2016 09:35:21 +0200 Daniel Zaoui  said:

> Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?

this isn't async. it's just deferred. we already do this for evas objects with
delete_me. we do it for timers/animators and mark them for deletion later. it's
nothing new. this is just more generic/extensive

> >From my point of view, seems to be like a hack cause some problems (e.g Eo)
> >are hard to solve.
> 
> My comments below.
> 
> On Thu, 03 Nov 2016 16:11:24 +0900
> Carsten Haitzler  (The Rasterman) wrote:
> 
> > here's an idea. it's very very very very simple
> > 
> > create an eina_freeq(). instead of calling free() or whatever free
> > function on something immediately, call:
> > 
> > fq = eina_freeq_main_get();
> > eina_freeq_ptr_add(fq, pointer, size, free);
> > 
> > or
> > 
> > fq = eina_freeq_global_get();
> > eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
> > _eina_list_mempool_list_free);
> > 
> > etc.
> > 
> > and the free queue will "add this to the end" to be freed some time
> > later. the idea of size is so it could make intelligent choice like
> > to free very large chunks earlier than smaller allocations. the
> > mainloop would drive this actual freeing. or more specifically your
> > LOCAL loop would. need to add some kind of loop method that returns
> > the "free queue" FOR your loop/thread. or wherever you want it
> > actually freed. probably have a main free queue driven by the
> > mainloop (and cleared up on eina_shutdown) etc.
> > 
> > why?
> > 
> > 1. move overhead of doing actual frees out of critical code into idle
> > time
> > 2. improve stability by keeping memory eg for eo objects or eina
> > list nodes in a "free queue purgatory" for a while so if someone does
> > bad things like "use after free" the IMPACT is far smaller as they
> > mess with memory in the free queue not being used.
> 
> Stability has to be improved with refs and other design technics, not with
> delay. More, we can't use anymore Valgrind. And this will be PITA to debug.
> The same kind of debug with async events where the frame before is
> ecore_loop...

we can use valgrind. just have freeq free immediately. env vars can switch
behavior around. :) so valgrind - can work trivially.

> btw, the third point didn't leave your head ;-)

oh yeah.. it got lost on the way to the kbd. :)

> > 4. be able to fill memory about to be freed with patterns (eg 0x55 or
> > 0xaa) so after free the memory is guaranteed to have a pattern to
> > know it was freed (optional debug only for mem regions of size > 0
> > and maybe less than some max size).
> 
> meow (I think this is what you say when you don't know if it is a good
> feature or not :-).
> 
> > 5. optional - checksum the memory when added to free queue then check
> > checksum on actual free to warn of some code "being bad" and
> > scribbling over freed memory. at least we get warnings of lurking
> > bugs if we turn this on...
> 
> Valgrind does it better.

the problem is we have people who will NOT RUN STUFF UNDER VALGRIND.

1. for example valgrind doesnt work on openbsd. at all.
2. good luck with valgrind on something like an rpi ... go and make lunch while
you wait for your app to start. make coffee in between clicks.the bug you were
looking for likely disappeared because timing changed so drastically you cant
catch it. i've seen this happen before.
3. people run/test and they do not want to slow things down to 1/50th of the
speed. they CAN'T, so having a pattern means its a very low cost and coredumps
can tell us far more information on what is going on. you cant force testers in
qa to "run it under valgrind". they dont even know what it is, nor can they
even do it. the speed impact along vetoes it. the impact of memset() for
smallish things (eg < 1k) is going to be MASSIVELY less.
4. this doesn't replace valgrind. it augments it for when valgrind is just not
viable. it at least gives us a CLUE. JP just was telling me of an issue where a
Eina_List * ptr in an evas object is 0x1 ... it should never be 0x1. it should
be some valid ptr value or NULL. something scribbled to this memory when it
should not have. LIKELY something like using a ptr after free and that ptr
HAPPENED to point to this object memory. we have no clue who did it and
valgrind can't catch this as its not freed ... YET. but if that memory WAS
handled by a free queue this would be far less likely to happen as the "write
to unused memory" would be less likely to affect a live real object. you want
things to be as robust as possible with minimal if not zero cost when you are
NOT running under valgrind. in fact i can detect if running under valgrind and
switch behaviour to insta-free thus changing nothing when running under
valgrind vs today, but buying more debug/tracking info when not.

what if the bug is not something WE can fix? some app using efl uses a ptr
after free? the crashes happen in efl code as 

Re: [E-devel] eina freeq?

[Daniel Zaoui]

Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?

>From my point of view, seems to be like a hack cause some problems (e.g Eo) 
>are hard to solve.

My comments below.

On Thu, 03 Nov 2016 16:11:24 +0900
Carsten Haitzler  (The Rasterman) wrote:

> here's an idea. it's very very very very simple
> 
> create an eina_freeq(). instead of calling free() or whatever free
> function on something immediately, call:
> 
> fq = eina_freeq_main_get();
> eina_freeq_ptr_add(fq, pointer, size, free);
> 
> or
> 
> fq = eina_freeq_global_get();
> eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
> _eina_list_mempool_list_free);
> 
> etc.
> 
> and the free queue will "add this to the end" to be freed some time
> later. the idea of size is so it could make intelligent choice like
> to free very large chunks earlier than smaller allocations. the
> mainloop would drive this actual freeing. or more specifically your
> LOCAL loop would. need to add some kind of loop method that returns
> the "free queue" FOR your loop/thread. or wherever you want it
> actually freed. probably have a main free queue driven by the
> mainloop (and cleared up on eina_shutdown) etc.
> 
> why?
> 
> 1. move overhead of doing actual frees out of critical code into idle
> time
> 2. improve stability by keeping memory eg for eo objects or eina
> list nodes in a "free queue purgatory" for a while so if someone does
> bad things like "use after free" the IMPACT is far smaller as they
> mess with memory in the free queue not being used.

Stability has to be improved with refs and other design technics, not with 
delay.
More, we can't use anymore Valgrind. And this will be PITA to debug. The same 
kind of debug with async events where the frame before is ecore_loop...

btw, the third point didn't leave your head ;-)

> 4. be able to fill memory about to be freed with patterns (eg 0x55 or
> 0xaa) so after free the memory is guaranteed to have a pattern to
> know it was freed (optional debug only for mem regions of size > 0
> and maybe less than some max size).

meow (I think this is what you say when you don't know if it is a good feature 
or not :-).

> 5. optional - checksum the memory when added to free queue then check
> checksum on actual free to warn of some code "being bad" and
> scribbling over freed memory. at least we get warnings of lurking
> bugs if we turn this on...

Valgrind does it better.

> 
> this doesn't solve everything, but it is an improvement and it's easy
> to slide in and begin using very quickly - eg eo object data, eina
> lists and a few other things. the free queue itself would be a very
> very very low overhead buffer - not a linked list. maybe a mmaped or
> malloced buffer/array (ring buffer) with a start and end point so we
> dont do anything but write the above ptr, free ptr and maybe size to
> the next array slot and move the ring buffer next slot one down.
> 
> adding the freeq code in eina is a cakewalk. i'd spend more time
> writing docs and tests than the code itself. :( adding usage of it
> should be trivial.
> 
> any comments?
> 


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[Felipe Magno de Almeida]

On Tue, May 31, 2016 at 10:41 PM, Carsten Haitzler  wrote:
>

[snip]

> i just say - remove the void * for the job. same for timeout too - it's not
> portable and the documentation is confusing as it claims to be data where it's
> actually value... and value actually is a pointer TO the pointer you provide.

That is going to change in promises in the next few days before
the freeze period. Right now the void* value pointer is a pointer
to whatever the promise is, if it is a void*, then value is void**.
Which is awfully confusing. That was meant to allow value types
and not restrict to only pointers, however it is going to change
one way or another, i.e., or by removing the possibility of non-pointers
or by assuming pointer-types are to be used as, well, pointers.

>> --
>> Cedric BAIL

Regards,
-- 
Felipe Magno de Almeida

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[The Rasterman]

On Tue, 31 May 2016 17:01:40 -0700 Cedric BAIL  said:

> On Tue, May 31, 2016 at 4:45 PM, Carsten Haitzler 
> wrote:
> > On Tue, 31 May 2016 06:15:29 -0700 Cedric BAIL  said:
> >
> >> On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
> >> >
> >> > the api for promises seems pretty confusing. just look at this:
> >> >
> >> >   job = efl_loop_job(obj, args);
> >> >eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
> >> >
> >> > why do i need to pass in args... TWICE? well ok - this specific way of
> >> using
> >> > promises for jobs... both promises in efl_loop.eo do this, and it's
> >> confusing.
> >> > the void *data when creating the job (first args) is not used at all. the
> >> data
> >> > for the promise is passed as data to the promise callback.
> >> >
> >> > why do this? value isn't used here in the promise -actually it's the
> >> promise
> >> > ptr itself for whatever reason.
> >>
> >> They are both different. A promise deliver a value at some point in the
> >> future to multiple callback couple. The data you give when creating the
> >> promise is the one delivered in the future. The one you pass with your
> >> couple of callbacks is obviously tied to that couple of callback. They are
> >> clearly 2 different things. Obviously you don't need to pass any data at
> >> all in both case.
> >
> > ummm the void *data when creating the job never is passed as anything to
> > promise callbacks. why have it at all? it's misleading. it's useless. i sat
> > down and had to figure out what is and isn't passed because it was entirely
> > unclear what was passed or not. value is the promise. i've printfed it's
> > values trying to figure out what gets passed where. bizarre that it is but
> > whatever. but data from the job is unused. data from the eina_promise_then
> > is used and passed as data to the cb's
> 
> It is passed as the value void * pointer. The second parameter of the
> function being called by the then case. You did set it to EINA_UNUSED
> in your case.

it isn't passed to value. i printf'd value as %p, not the data * in the job.
that's my point. it's all confusing. rename it to void *value then to at least
make that obvious. make sure the docs say that. they do not. they say it's
passed as data ptr.

here is the output of this code:

static void
_efl_loop_args_job_cb(void *data, void *value,
  Eina_Promise *promise EINA_UNUSED)
{
   Efl_Loop_Args *args = data;
   Eo *obj = eo_parent_get(args);

   printf("promise cb: data = %p, value = %p, promise = %p\n", data, value,
promise); eo_event_callback_call(obj, EFL_LOOP_EVENT_ARGS, args);
   eo_unref(args); // FIXME: probably eo_del()
}

EOLIAN static void
_efl_loop_args_add(Eo *obj, Efl_Loop_Data *pd EINA_UNUSED, int argc, const char
**argv) {
   Eina_Promise *job;
   Efl_Loop_Args *args = eo_add(EFL_LOOP_ARGS_CLASS, obj);

   if (!args) return;
   efl_loop_args_set(args, argc, argv);
   job = efl_loop_job(obj, (void *)0x1);
   printf("efl_loop_job() return = %p\n", job);
   printf("data ptr for promise = %p\n", args);
   eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
}

output:

efl_loop_job() return = 0x11efcc8
data ptr for promise = 0x40020021
promise cb: data = 0x40020021, value = 0x11efd70, promise = 0x11efcc8

value is NOT the data passed into job. not at all. i passed in 0x1. the
documentation says:

@in data: const(void)* @optional; [[The data to be given when the
promise is done.]]

? the data to be given to promise. there is only one data parameter - the
first. the docs SAY it's given to the promise. that's not the case. it's not
given to value OR to data. if you mean that value POINTS to a void * containing
the value of data above.. then say that. :) but this is totally not portable.

i just say - remove the void * for the job. same for timeout too - it's not
portable and the documentation is confusing as it claims to be data where it's
actually value... and value actually is a pointer TO the pointer you provide.

> -- 
> Cedric BAIL
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[Cedric BAIL]

On Tue, May 31, 2016 at 4:45 PM, Carsten Haitzler 
wrote:
> On Tue, 31 May 2016 06:15:29 -0700 Cedric BAIL  said:
>
>> On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
>> >
>> > the api for promises seems pretty confusing. just look at this:
>> >
>> > job = efl_loop_job(obj, args);
>> > eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
>> >
>> > why do i need to pass in args... TWICE? well ok - this specific way of
>> using
>> > promises for jobs... both promises in efl_loop.eo do this, and it's
>> confusing.
>> > the void *data when creating the job (first args) is not used at all.
the
>> data
>> > for the promise is passed as data to the promise callback.
>> >
>> > why do this? value isn't used here in the promise -actually it's the
>> promise
>> > ptr itself for whatever reason.
>>
>> They are both different. A promise deliver a value at some point in the
>> future to multiple callback couple. The data you give when creating the
>> promise is the one delivered in the future. The one you pass with your
>> couple of callbacks is obviously tied to that couple of callback. They
are
>> clearly 2 different things. Obviously you don't need to pass any data at
>> all in both case.
>
> ummm the void *data when creating the job never is passed as anything to
> promise callbacks. why have it at all? it's misleading. it's useless. i
sat
> down and had to figure out what is and isn't passed because it was
entirely
> unclear what was passed or not. value is the promise. i've printfed it's
values
> trying to figure out what gets passed where. bizarre that it is but
whatever.
> but data from the job is unused. data from the eina_promise_then is used
and
> passed as data to the cb's

It is passed as the value. The second parameter of the function being
called in the then case. You did set it to EINA_UNUSED in your case. I can
call it value in the .eo if that help.
-- 
Cedric BAIL
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[Cedric BAIL]

On Tue, May 31, 2016 at 4:45 PM, Carsten Haitzler  wrote:
> On Tue, 31 May 2016 06:15:29 -0700 Cedric BAIL  said:
>
>> On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
>> >
>> > the api for promises seems pretty confusing. just look at this:
>> >
>> >   job = efl_loop_job(obj, args);
>> >eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
>> >
>> > why do i need to pass in args... TWICE? well ok - this specific way of
>> using
>> > promises for jobs... both promises in efl_loop.eo do this, and it's
>> confusing.
>> > the void *data when creating the job (first args) is not used at all. the
>> data
>> > for the promise is passed as data to the promise callback.
>> >
>> > why do this? value isn't used here in the promise -actually it's the
>> promise
>> > ptr itself for whatever reason.
>>
>> They are both different. A promise deliver a value at some point in the
>> future to multiple callback couple. The data you give when creating the
>> promise is the one delivered in the future. The one you pass with your
>> couple of callbacks is obviously tied to that couple of callback. They are
>> clearly 2 different things. Obviously you don't need to pass any data at
>> all in both case.
>
> ummm the void *data when creating the job never is passed as anything to
> promise callbacks. why have it at all? it's misleading. it's useless. i sat
> down and had to figure out what is and isn't passed because it was entirely
> unclear what was passed or not. value is the promise. i've printfed it's 
> values
> trying to figure out what gets passed where. bizarre that it is but whatever.
> but data from the job is unused. data from the eina_promise_then is used and
> passed as data to the cb's

It is passed as the value void * pointer. The second parameter of the
function being called by the then case. You did set it to EINA_UNUSED
in your case.
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[The Rasterman]

On Tue, 31 May 2016 11:48:32 -0300 Felipe Magno de Almeida
 said:

> On Tue, May 31, 2016 at 10:15 AM, Cedric BAIL  wrote:
> > On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
> >>
> >> the api for promises seems pretty confusing. just look at this:
> >>
> >>   job = efl_loop_job(obj, args);
> >>eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
> >>
> >> why do i need to pass in args... TWICE? well ok - this specific way of
> > using
> >> promises for jobs... both promises in efl_loop.eo do this, and it's
> > confusing.
> >> the void *data when creating the job (first args) is not used at all. the
> > data
> >> for the promise is passed as data to the promise callback.
> >>
> >> why do this? value isn't used here in the promise -actually it's the
> > promise
> >> ptr itself for whatever reason.
> >
> > They are both different. A promise deliver a value at some point in the
> > future to multiple callback couple. The data you give when creating the
> > promise is the one delivered in the future. The one you pass with your
> > couple of callbacks is obviously tied to that couple of callback. They are
> > clearly 2 different things. Obviously you don't need to pass any data at
> > all in both case.
> 
> Though I think cedric's idea is a good one, because it reuses the
> eina promise value for something that could be useful, I think the
> use of void* in the eolian API is not good. I don't know how to
> resolve this conflict except by removing the void* and have
> the promise be of type promise without any value.

the void * isn't even passed along from the eo api./ i sat down trying to
figure it out because it was basically impossible to know what was used where
from the docs.

> If there were "template" methods in Eolian this would be completely
> clean, but unfortunately we don't.
> 
> > Cedric
> >
> >> why?
> 
> Regards,
> -- 
> Felipe Magno de Almeida
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> 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


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[The Rasterman]

On Tue, 31 May 2016 06:15:29 -0700 Cedric BAIL  said:

> On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
> >
> > the api for promises seems pretty confusing. just look at this:
> >
> >   job = efl_loop_job(obj, args);
> >eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
> >
> > why do i need to pass in args... TWICE? well ok - this specific way of
> using
> > promises for jobs... both promises in efl_loop.eo do this, and it's
> confusing.
> > the void *data when creating the job (first args) is not used at all. the
> data
> > for the promise is passed as data to the promise callback.
> >
> > why do this? value isn't used here in the promise -actually it's the
> promise
> > ptr itself for whatever reason.
> 
> They are both different. A promise deliver a value at some point in the
> future to multiple callback couple. The data you give when creating the
> promise is the one delivered in the future. The one you pass with your
> couple of callbacks is obviously tied to that couple of callback. They are
> clearly 2 different things. Obviously you don't need to pass any data at
> all in both case.

ummm the void *data when creating the job never is passed as anything to
promise callbacks. why have it at all? it's misleading. it's useless. i sat
down and had to figure out what is and isn't passed because it was entirely
unclear what was passed or not. value is the promise. i've printfed it's values
trying to figure out what gets passed where. bizarre that it is but whatever.
but data from the job is unused. data from the eina_promise_then is used and
passed as data to the cb's

> Cedric
> 
> > why?
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> 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


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[Felipe Magno de Almeida]

On Tue, May 31, 2016 at 10:15 AM, Cedric BAIL  wrote:
> On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
>>
>> the api for promises seems pretty confusing. just look at this:
>>
>>   job = efl_loop_job(obj, args);
>>eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
>>
>> why do i need to pass in args... TWICE? well ok - this specific way of
> using
>> promises for jobs... both promises in efl_loop.eo do this, and it's
> confusing.
>> the void *data when creating the job (first args) is not used at all. the
> data
>> for the promise is passed as data to the promise callback.
>>
>> why do this? value isn't used here in the promise -actually it's the
> promise
>> ptr itself for whatever reason.
>
> They are both different. A promise deliver a value at some point in the
> future to multiple callback couple. The data you give when creating the
> promise is the one delivered in the future. The one you pass with your
> couple of callbacks is obviously tied to that couple of callback. They are
> clearly 2 different things. Obviously you don't need to pass any data at
> all in both case.

Though I think cedric's idea is a good one, because it reuses the
eina promise value for something that could be useful, I think the
use of void* in the eolian API is not good. I don't know how to
resolve this conflict except by removing the void* and have
the promise be of type promise without any value.

If there were "template" methods in Eolian this would be completely
clean, but unfortunately we don't.

> Cedric
>
>> why?

Regards,
-- 
Felipe Magno de Almeida

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina promise.... confusing

[Cedric BAIL]

On May 30, 2016 22:51, "Carsten Haitzler"  wrote:
>
> the api for promises seems pretty confusing. just look at this:
>
>   job = efl_loop_job(obj, args);
>eina_promise_then(job, _efl_loop_args_job_cb, NULL, args);
>
> why do i need to pass in args... TWICE? well ok - this specific way of
using
> promises for jobs... both promises in efl_loop.eo do this, and it's
confusing.
> the void *data when creating the job (first args) is not used at all. the
data
> for the promise is passed as data to the promise callback.
>
> why do this? value isn't used here in the promise -actually it's the
promise
> ptr itself for whatever reason.

They are both different. A promise deliver a value at some point in the
future to multiple callback couple. The data you give when creating the
promise is the one delivered in the future. The one you pass with your
couple of callbacks is obviously tied to that couple of callback. They are
clearly 2 different things. Obviously you don't need to pass any data at
all in both case.

Cedric

> why?
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
--
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Jean-Philippe André]

On 27 January 2016 at 00:03, Felipe Magno de Almeida <
felipe.m.alme...@gmail.com> wrote:

> On Tue, Jan 26, 2016 at 12:51 PM, Tom Hacohen  wrote:
> > On 26/01/16 14:42, Stefan Schmidt wrote:
> >> Hello.
>
> [snip]
>
> >> JP, Tom are you happy with Felipe's explanation? If not we need to act
> >> now as we only have 6 days left before the release and once it is in
> >> 1.17 it will stay.
> >
> > My concern was about the docs. Haven't reviewed the concept.
>
> There always were docs.
>
> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Eina__Value__Optional__Group.html
>
> It might be improved maybe with some motivation information.
> 
>

Yes, there are docs as to how, I was asking about why. And got my answer :)
The motivation can be documented as well, but it's not a release blocker.

Thanks,

-- 
Jean-Philippe André
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Stefan Schmidt]

Hello.

On 13/01/16 11:56, Tom Hacohen wrote:
> On 13/01/16 02:38, Jean-Philippe André wrote:
>> Hi Felipe,
>>
>> You added the optional type to eina value. I'm not sure what it's point is.
>> I understand an optional value can be empty (ie. void and not "nil" or 0 or
>> whatever).
>>
>> But I don't understand why this couldn't be implemented inside all standard
>> values. Add an "empty" property to them.
>>
>> Could you explain shortly why we need a special type? I'm sure you had a
>> good reason :)
>>
>> Thanks in advance,
>>
> And please also add it to the docs. I assume it's not already there
> because of this question.

JP, Tom are you happy with Felipe's explanation? If not we need to act 
now as we only have 6 days left before the release and once it is in 
1.17 it will stay.

regards
Stefan Schmidt


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Tom Hacohen]

On 26/01/16 14:42, Stefan Schmidt wrote:
> Hello.
>
> On 13/01/16 11:56, Tom Hacohen wrote:
>> On 13/01/16 02:38, Jean-Philippe André wrote:
>>> Hi Felipe,
>>>
>>> You added the optional type to eina value. I'm not sure what it's point is.
>>> I understand an optional value can be empty (ie. void and not "nil" or 0 or
>>> whatever).
>>>
>>> But I don't understand why this couldn't be implemented inside all standard
>>> values. Add an "empty" property to them.
>>>
>>> Could you explain shortly why we need a special type? I'm sure you had a
>>> good reason :)
>>>
>>> Thanks in advance,
>>>
>> And please also add it to the docs. I assume it's not already there
>> because of this question.
>
> JP, Tom are you happy with Felipe's explanation? If not we need to act
> now as we only have 6 days left before the release and once it is in
> 1.17 it will stay.

My concern was about the docs. Haven't reviewed the concept.

--
Tom.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Felipe Magno de Almeida]

On Tue, Jan 26, 2016 at 12:51 PM, Tom Hacohen  wrote:
> On 26/01/16 14:42, Stefan Schmidt wrote:
>> Hello.

[snip]

>> JP, Tom are you happy with Felipe's explanation? If not we need to act
>> now as we only have 6 days left before the release and once it is in
>> 1.17 it will stay.
>
> My concern was about the docs. Haven't reviewed the concept.

There always were docs.
https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Eina__Value__Optional__Group.html

It might be improved maybe with some motivation information.

> --
> Tom.

Regards,
-- 
Felipe Magno de Almeida

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Felipe Magno de Almeida]

Hello,

Sorry to answer myself, but complementing on what I've said before.
There's also ABI and optimization's concern on adding empty value for
all types. Since Eina_Value is defined in eina_value.h header, it is
public and needs to be backwards compatible ABI-wise, and since it can
be used by value with eina_value_setup we can't just add a field in
struct _Eina_Value. And, since Eina_Value_Union is the size of 8 bytes
in most architectures, it means we'd need an unnecessary indirection
for all except char, short and ints if we added an empty state.

Regards,

On Sun, Jan 17, 2016 at 10:51 PM, Felipe Magno de Almeida
 wrote:
> On Wed, Jan 13, 2016 at 12:38 AM, Jean-Philippe André  
> wrote:
>> Hi Felipe,
>>
>> You added the optional type to eina value. I'm not sure what it's point is.
>> I understand an optional value can be empty (ie. void and not "nil" or 0 or
>> whatever).
>>
>> But I don't understand why this couldn't be implemented inside all standard
>> values. Add an "empty" property to them.
>>
>> Could you explain shortly why we need a special type? I'm sure you had a
>> good reason :)
>
> Hello jpeg,
>
> When implementing a data model for esskyuehl we needed a way to handle
> NULL values from database for certain columns. The "empty" value is
> a specific, valid, value for that type.
>
> If we added "empty" property to all values in Eina Value, we'd be adding
> an ambigous information for each use. Is that an invalid value? An
> indication of an error? Is that a valid value? Equivalent to a NULL
> Eina_Value?
>
> The optional doesn't have this problem, it is the equivalent of
> a "T + 1" in algebraic data type, with 1 meaning "empty", which
> would be used when an empty value is possible and is a valid
> value.
>
> That way we don't need to check for emptiness for all current
> uses of integer Eina Values or some other type, for example.
> Their semantics are completely intact..
>
>> Thanks in advance,
>
> Sorry for the delay of this answer,
>
>
>> --
>> Jean-Philippe André
>
> Regards,
> --
> Felipe Magno de Almeida



-- 
Felipe Magno de Almeida

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Felipe Magno de Almeida]

On Wed, Jan 13, 2016 at 12:38 AM, Jean-Philippe André  wrote:
> Hi Felipe,
>
> You added the optional type to eina value. I'm not sure what it's point is.
> I understand an optional value can be empty (ie. void and not "nil" or 0 or
> whatever).
>
> But I don't understand why this couldn't be implemented inside all standard
> values. Add an "empty" property to them.
>
> Could you explain shortly why we need a special type? I'm sure you had a
> good reason :)

Hello jpeg,

When implementing a data model for esskyuehl we needed a way to handle
NULL values from database for certain columns. The "empty" value is
a specific, valid, value for that type.

If we added "empty" property to all values in Eina Value, we'd be adding
an ambigous information for each use. Is that an invalid value? An
indication of an error? Is that a valid value? Equivalent to a NULL
Eina_Value?

The optional doesn't have this problem, it is the equivalent of
a "T + 1" in algebraic data type, with 1 meaning "empty", which
would be used when an empty value is possible and is a valid
value.

That way we don't need to check for emptiness for all current
uses of integer Eina Values or some other type, for example.
Their semantics are completely intact..

> Thanks in advance,

Sorry for the delay of this answer,


> --
> Jean-Philippe André

Regards,
-- 
Felipe Magno de Almeida

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

[Tom Hacohen]

On 13/01/16 02:38, Jean-Philippe André wrote:
> Hi Felipe,
>
> You added the optional type to eina value. I'm not sure what it's point is.
> I understand an optional value can be empty (ie. void and not "nil" or 0 or
> whatever).
>
> But I don't understand why this couldn't be implemented inside all standard
> values. Add an "empty" property to them.
>
> Could you explain shortly why we need a special type? I'm sure you had a
> good reason :)
>
> Thanks in advance,
>

And please also add it to the docs. I assume it's not already there 
because of this question.

--
Tom.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [eina] Eina_List and Eina_Inlist eina_inlist_prepend_relative and eina_list_prepend_relative_list

[Tom Hacohen]

On 06/11/13 00:35, Felipe Magno de Almeida wrote:
 n  On Tue, Nov 5, 2013 at 7:02 PM, Tom Hacohen t...@stosb.com wrote:
 That is not going to change.

 The first and most important reason is that we are *NOT* going to break API
 no matter how right you are.

 OK. Can't really argue with that. Though I don't really see how an application
 that depends on this behavior for *prepend_relative functions to be correct
 since it just doesn't prepend relative to NULL at all.

If you really want to nit-pick, our lists and double-linked lists, so 
the NULL is on both sides which means this is actually doing exactly 
that (well, except for the fact that it replaces the NULL).

Well, applications were allowed to depend on that because it is 
explicitly written in our docs. Even if you think it's wrong. Even if it 
wasn't in the docs, it's relied upon in many places, so again, changing 
it is a no go.


 The second reason is that we also have append_relative and having two
 functions that do the same would be redundant.

 I don't see how that is related to what I said. I only want to prepend, but
 I want the relative argument to treat NULL as a valid position in the list
 (being that the post-the-end position), instead of treating that as an
 optional argument with a fallback for list prepend algorithm. We already
 treat NULL as an empty list and the list ends when next points to
 NULL, so it already is true that NULL *is* the post-the-end node.

It's related because then what would you do with the append_relative 
functions? Will they behave the same way as the prepend_relative (when 
null is past as the relative)?

 Also, using post-the-end positions is idiomatic in C and C++.
 int = 0;
 for(i = 0; i != size; ++i)
 {
// loops on all elements
 }

I disagree with this example, I don't see how this has anything to do 
with null and double-linked lists.


 The third reason is quite subjective, and maybe I'm too used to the efl
 way, but I would expect the default behaviour of prepend relative to be
 prepend. That's why I'm prepending.

 If NULL becomes a valid domain for the positional argument, then
 there isn't a default to talk about. Only prepend to relative argument
 where NULL means the position after the last element. The list
 argument already includes NULL in its value domain for eina list
 functions.

 Also, not append, nor prepend can be used to insert
 elements in all possible positions of a list. Prepend can't insert
 the element after the last element and append can't add it as
 a first element. There's no current algorithm that can be used
 as a

Again, double-linked list, NULL is in the list twice. Sure prepend and 
append can't both be used to insert everywhere in the list, that's 
annoying. As I said, the last point is subjective, maybe I was wrong 
(still not convinced I am). However that doesn't change the fact that 
it's not going to change. :)

 Anyhow, talking about it is moot as this is not going to change.

 Ok. I won't bring it up again if there's no controversy on this.

Even if there was, it's not going to change (recurring theme).

I understand developing libraries can be annoying, especially if you are 
a perfectionist (I'm one as well). However that doesn't change the fact 
that we've made a promise to our developers, and that promise is our 
API. We are not going to break that promise no matter how big the 
controversy is.

--
Tom.

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [eina] Eina_List and Eina_Inlist eina_inlist_prepend_relative and eina_list_prepend_relative_list

[Tom Hacohen]

That is not going to change.

The first and most important reason is that we are *NOT* going to break API
no matter how right you are.

The second reason is that we also have append_relative and having two
functions that do the same would be redundant.

The third reason is quite subjective, and maybe I'm too used to the efl
way, but I would expect the default behaviour of prepend relative to be
prepend. That's why I'm prepending.

Anyhow, talking about it is moot as this is not going to change.

--
Tom.


On Tue, Nov 5, 2013 at 8:23 PM, Felipe Magno de Almeida 
felipe.m.alme...@gmail.com wrote:

 Hello,

 Both eina_inlist_prepend_relative and eina_list_prepend_relative_list
 takes three arguments: list, data and relative. If relative is NULL,
 both execute the non-relative version: eina_inlist_prepend and
 eina_list_prepend.

 This means that there's no way to make eina_inlist_prepend_relative
 and eina_list_prepend_relative_list to append on the end of the list.
 I think that NULL should be considered as a past-the-end element and
 the result would be prepending relative to the past-the-end element,
 i.e., appending.

 If we consider this list:

 [a - b - c - d - NULL]

 We can see that prepending relative to /a/ means eina_list_prepend,
 relative to /b/ means inserting the element between /a/ and /b/. And
 if we consider the following empty list:

 [NULL]

 eina_list_prepend and eina_list_prepend_relative prepends before the
 past-the-end node. So:

 Eina_List* list = NULL;

 List list: [NULL]

 int i = 5;
 void* data = i;

 list = eina_list_prepend_relative(list, data, NULL);

 [i - NULL]

 The current behavior of doing normal prepend when relative is NULL
 forces some algorithms to do

 if(pos)
   list = eina_list_prepend_relative_list(list, data, pos);
 else
   list = eina_list_append(list, data);

 Which seems unnecessary. Am I missing something?

 Regards,
 --
 Felipe Magno de Almeida


 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models.
 Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [eina] Eina_List and Eina_Inlist eina_inlist_prepend_relative and eina_list_prepend_relative_list

[The Rasterman]

On Tue, 5 Nov 2013 18:23:42 -0200 Felipe Magno de Almeida
felipe.m.alme...@gmail.com said:

there is the other view that appeanding/prepending relative TO something.. if
something is NULL.. then that something does not exist, so calling these calles
with NULL as relative is silly. the behavior is being nice and functioning
anyway even if used stupidly. :)

as tom said... the discussion is moot as any change would be an api/abi break
and it's not going to happen (well not knowingly etc.).

 Hello,
 
 Both eina_inlist_prepend_relative and eina_list_prepend_relative_list
 takes three arguments: list, data and relative. If relative is NULL,
 both execute the non-relative version: eina_inlist_prepend and
 eina_list_prepend.
 
 This means that there's no way to make eina_inlist_prepend_relative
 and eina_list_prepend_relative_list to append on the end of the list.
 I think that NULL should be considered as a past-the-end element and
 the result would be prepending relative to the past-the-end element,
 i.e., appending.
 
 If we consider this list:
 
 [a - b - c - d - NULL]
 
 We can see that prepending relative to /a/ means eina_list_prepend,
 relative to /b/ means inserting the element between /a/ and /b/. And
 if we consider the following empty list:
 
 [NULL]
 
 eina_list_prepend and eina_list_prepend_relative prepends before the
 past-the-end node. So:
 
 Eina_List* list = NULL;
 
 List list: [NULL]
 
 int i = 5;
 void* data = i;
 
 list = eina_list_prepend_relative(list, data, NULL);
 
 [i - NULL]
 
 The current behavior of doing normal prepend when relative is NULL
 forces some algorithms to do
 
 if(pos)
   list = eina_list_prepend_relative_list(list, data, pos);
 else
   list = eina_list_append(list, data);
 
 Which seems unnecessary. Am I missing something?
 
 Regards,
 -- 
 Felipe Magno de Almeida
 
 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most 
 from the latest Intel processors and coprocessors. See abstracts and register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 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


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [eina] Eina_List and Eina_Inlist eina_inlist_prepend_relative and eina_list_prepend_relative_list

[Felipe Magno de Almeida]

n  On Tue, Nov 5, 2013 at 7:02 PM, Tom Hacohen t...@stosb.com wrote:
 That is not going to change.

 The first and most important reason is that we are *NOT* going to break API
 no matter how right you are.

OK. Can't really argue with that. Though I don't really see how an application
that depends on this behavior for *prepend_relative functions to be correct
since it just doesn't prepend relative to NULL at all.

 The second reason is that we also have append_relative and having two
 functions that do the same would be redundant.

I don't see how that is related to what I said. I only want to prepend, but
I want the relative argument to treat NULL as a valid position in the list
(being that the post-the-end position), instead of treating that as an
optional argument with a fallback for list prepend algorithm. We already
treat NULL as an empty list and the list ends when next points to
NULL, so it already is true that NULL *is* the post-the-end node.

Also, using post-the-end positions is idiomatic in C and C++.
int = 0;
for(i = 0; i != size; ++i)
{
  // loops on all elements
}

 The third reason is quite subjective, and maybe I'm too used to the efl
 way, but I would expect the default behaviour of prepend relative to be
 prepend. That's why I'm prepending.

If NULL becomes a valid domain for the positional argument, then
there isn't a default to talk about. Only prepend to relative argument
where NULL means the position after the last element. The list
argument already includes NULL in its value domain for eina list
functions.

Also, not append, nor prepend can be used to insert
elements in all possible positions of a list. Prepend can't insert
the element after the last element and append can't add it as
a first element. There's no current algorithm that can be used
as a

 Anyhow, talking about it is moot as this is not going to change.

Ok. I won't bring it up again if there's no controversy on this.

 --
 Tom.


 On Tue, Nov 5, 2013 at 8:23 PM, Felipe Magno de Almeida 
 felipe.m.alme...@gmail.com wrote:

 Hello,

 Both eina_inlist_prepend_relative and eina_list_prepend_relative_list
 takes three arguments: list, data and relative. If relative is NULL,
 both execute the non-relative version: eina_inlist_prepend and
 eina_list_prepend.

 This means that there's no way to make eina_inlist_prepend_relative
 and eina_list_prepend_relative_list to append on the end of the list.
 I think that NULL should be considered as a past-the-end element and
 the result would be prepending relative to the past-the-end element,
 i.e., appending.

 If we consider this list:

 [a - b - c - d - NULL]

 We can see that prepending relative to /a/ means eina_list_prepend,
 relative to /b/ means inserting the element between /a/ and /b/. And
 if we consider the following empty list:

 [NULL]

 eina_list_prepend and eina_list_prepend_relative prepends before the
 past-the-end node. So:

 Eina_List* list = NULL;

 List list: [NULL]

 int i = 5;
 void* data = i;

 list = eina_list_prepend_relative(list, data, NULL);

 [i - NULL]

 The current behavior of doing normal prepend when relative is NULL
 forces some algorithms to do

 if(pos)
   list = eina_list_prepend_relative_list(list, data, pos);
 else
   list = eina_list_append(list, data);

 Which seems unnecessary. Am I missing something?

 Regards,
 --
 Felipe Magno de Almeida


 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models.
 Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Felipe Magno de Almeida

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and 

Re: [E-devel] Eina/Evas threading support?

[Andreas Volz]

Am Wed, 13 Feb 2013 15:56:57 +0900 schrieb Carsten Haitzler (The
Rasterman):

  Could you please tell me how to disable threading support as in
  1.7.5? Maybe even by hacking build environment. I played around,
  but some of the m4 macros are really a nightmare!
 
 we removed the ability - we're threading only now. we're removing
 optional untested codepaths and reality is as we work more on things
 inside of evas and edje, we'll use threads more and more to
 parallelize things behind the scenes, so it's better to figure out
 how to make it work on bionic, than avoid it.

After going much deeper into the problem I found out that going to a
newer Android API solves the problem so far that nearly all code
compiles. There're some minor functions that I need to port later or
simply don't support.

The reason for not always taking the latest Android API is for sure to
support old devices on the market..
 
Finaly I got efl trunk compiled and running (buffer engine) after many
hacks in the build system. If my port is more complete I'll propose some
changes here on this list. Most times some additional checks which
could be done by configure if android platform is found. I hope not to
create any new configure options.

  never tried to compile with 1.7.5 (e.g. eeze or emotion) for
  Android. The NEON detected also doesn't work for me (It worked with
  1.7.5). I
 
 it will work if your CFLAGS have -mfpu=neon in them (ie u CAN compile
 neon code). :)

Thanks I'll try this. Thanks!

  liked to idea of the separate libraries. But I'm sure there were
  good reasons for the design change...
 
 years of complaints that efl is too hard to build (too many libs).
 
 too much overhead for releases (having to release 12+ libs each time
 and fix up versions/readmes/headers/whatever for each), and having to
 create layers and hoops to jump through - eg feature goes into evas -
 then we expose in ecore evas then expose again in elm - we make
 more and more apis and layers where reality is we just wanted the
 feature up in elm but it had to LIVE in evas.
 
 also this allows us to eventually inline across efl libs, gaining
 efficiency (eg make a libefl.so ... right now this is on the list of
 stuff for efl 2.0 possibilities). also now we need to be creating
 efl-wide interfaces (multiple-inheritance) and that just wouldnt fit
 into any specific lib in the old efl setup.. now with a single tree..
 it is easy as its general efl infra stuff.

This is correct. Compiling without easy_e17.sh was a pain even after
years of knowledge. So in general it was good. But I just like to point
of to the responsible developers that maybe it's a good idea to
separate at least that general purpose part from the platform
specific stuff. It was not so funny to fight against problems to get
the build system NOT to compile eeze, edbus and other stuff. That is
really not needed.

In my eyes the chain up to edje is so general purpose as graphic stack
that also projects complete independent from E17 may use it. (e.g. as I
use it for a project). Only my point. We don't need to discuss it
here...

  How ever - from some ones point who does a cross compiler platform
  port it's a torture. But I don't like to cry...
 
 right now the efl tree is in bad shape for cross-compiling and even
 for general rebuilds. it's linking out-of-tree libs for example. it's
 not in good shape and need massaging into shape, but i have no time
 right now as i already have a backlog of like 200 mails (questions,
 patches etc. - like this mail of yours), and frankly my backlog is
 not shrinking...

Sorry to bring even more work to your desk!

This was the reason why I started the port with stable 1.7.5. But after
first success I've seen that many things changed in trunk so much that
I don't like to maintain this and switched to EFL trunk.

My next big milestone is to write a software_android engine. I looked
into the sources yesterday and think this it's not so hard. But I'll
see... If problems will occur I'll ask here. Feel free to answer them
or not. :-)

regards
Andreas
-- 
Technical Blog http://andreasvolz.wordpress.com/

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina/Evas threading support?

[The Rasterman]

On Sun, 10 Feb 2013 22:52:19 +0100 Andreas Volz li...@brachttal.net said:

 Hello,
 
 In the EFL 1.7.5 I had options to disable threading support and
 everything worked as it should.

you know we stopped testing phtread off codepaths... and thats why efl now is
pthread only :) that set of bull horns is going to have to be tackled.

 The pthread version on Android misses some features from the Linux
 variant. For now I just like to disable it complete and take time for
 this task later. But it seems there's no option for it in trunk.

yup. :)

 Could you please tell me how to disable threading support as in 1.7.5?
 Maybe even by hacking build environment. I played around, but some of
 the m4 macros are really a nightmare!

we removed the ability - we're threading only now. we're removing optional
untested codepaths and reality is as we work more on things inside of evas and
edje, we'll use threads more and more to parallelize things behind the scenes,
so it's better to figure out how to make it work on bionic, than avoid it.

 My feeling is that EFL trunk isn't as flexible as 1.7.5 regarding
 configure options. I even get compilation problems in libraries that I

correct.

 never tried to compile with 1.7.5 (e.g. eeze or emotion) for Android.
 The NEON detected also doesn't work for me (It worked with 1.7.5). I

it will work if your CFLAGS have -mfpu=neon in them (ie u CAN compile neon
code). :)

 liked to idea of the separate libraries. But I'm sure there were good
 reasons for the design change...

years of complaints that efl is too hard to build (too many libs).

too much overhead for releases (having to release 12+ libs each time and fix up
versions/readmes/headers/whatever for each), and having to create layers and
hoops to jump through - eg feature goes into evas - then we expose in ecore
evas then expose again in elm - we make more and more apis and layers where
reality is we just wanted the feature up in elm but it had to LIVE in evas.

also this allows us to eventually inline across efl libs, gaining efficiency
(eg make a libefl.so ... right now this is on the list of stuff for efl 2.0
possibilities). also now we need to be creating efl-wide interfaces
(multiple-inheritance) and that just wouldnt fit into any specific lib in the
old efl setup.. now with a single tree.. it is easy as its general efl infra
stuff.

 How ever - from some ones point who does a cross compiler platform port
 it's a torture. But I don't like to cry...

right now the efl tree is in bad shape for cross-compiling and even for general
rebuilds. it's linking out-of-tree libs for example. it's not in good shape and
need massaging into shape, but i have no time right now as i already have a
backlog of like 200 mails (questions, patches etc. - like this mail of yours),
and frankly my backlog is not shrinking...

 Please help me.
 
 regards
   Andreas
 
 -- 
 Technical Blog http://andreasvolz.wordpress.com/
 
 --
 Free Next-Gen Firewall Hardware Offer
 Buy your Sophos next-gen firewall before the end March 2013 
 and get the hardware for free! Learn more.
 http://p.sf.net/sfu/sophos-d2d-feb
 ___
 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


--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Eina PATCH] Fix directory listing in eina_file_direct_ls()

[Cedric BAIL]

Cedric Bail
On Feb 5, 2013 10:47 AM, Paulo Alcantara pca...@zytor.com wrote:

 Gustavo Sverzut Barbieri barbi...@profusion.mobi writes:

  This would be a PITA. And it would be slower on FS that provide dt_type.

Actually it shouldn't,as statat is only called if d_type is unknown. Direct
is for when you may avoid the need for checking that information.

 Indeed. So I'm going to replace eina_file_direct_ls() with
 eina_file_stat_ls() in some places that depends on file type (e.g.,
 elementary_config).

 How about it ?

Indeed,would be good for me!

 --
 Paulo Alcantara,ProFUSION Embedded Systems


--
 Free Next-Gen Firewall Hardware Offer
 Buy your Sophos next-gen firewall before the end March 2013
 and get the hardware for free! Learn more.
 http://p.sf.net/sfu/sophos-d2d-feb
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Eina PATCH] Fix directory listing in eina_file_direct_ls()

[Cedric BAIL]

On Tue, Feb 5, 2013 at 12:46 AM, Paulo Alcantara pca...@zytor.com wrote:
 XFS and other filesystems that do not support d_type field in dirent
 structure will get unexpected behavior when using eina_file_direct_ls()
 - since it relies on d_type to determine file types.

 Thus, an eina_file_statat() call is required in eina_file_direct_ls()
 only if the file type had not been determined by using readdir_r().

No, this is the expected behavior. You should have used eina_file_stat_ls().

 I've just got such issue when using elementary_config to change current
 profile - but it wasn't able to list the avaiable profiles since the
 diretory entries in share/elementary/ were not recognized by
 eina_file_direct_ls() function.

This patch should not go in.
--
Cedric BAIL

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Eina PATCH] Fix directory listing in eina_file_direct_ls()

[Paulo Alcantara]

Cedric BAIL cedric.b...@free.fr writes:

 No, this is the expected behavior. You should have used eina_file_stat_ls().

eina_file_direct_ls() is called in several places - which means that all
callers won't get any file type correctly.

So, should I replace all eina_file_direct_ls() calls with
eina_file_stat_ls() ?

-- 
Paulo Alcantara,ProFUSION Embedded Systems

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Eina PATCH] Fix directory listing in eina_file_direct_ls()

[Gustavo Sverzut Barbieri]

On Monday, February 4, 2013, Paulo Alcantara wrote:

 Cedric BAIL cedric.b...@free.fr javascript:; writes:

  No, this is the expected behavior. You should have used
 eina_file_stat_ls().

 eina_file_direct_ls() is called in several places - which means that all
 callers won't get any file type correctly.

 So, should I replace all eina_file_direct_ls() calls with
 eina_file_stat_ls() ?


This would be a PITA. And it would be slower on FS that provide dt_type.




 --
 Paulo Alcantara,ProFUSION Embedded Systems


 --
 Free Next-Gen Firewall Hardware Offer
 Buy your Sophos next-gen firewall before the end March 2013
 and get the hardware for free! Learn more.
 http://p.sf.net/sfu/sophos-d2d-feb
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net javascript:;
 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
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Eina PATCH] Fix directory listing in eina_file_direct_ls()

[Paulo Alcantara]

Gustavo Sverzut Barbieri barbi...@profusion.mobi writes:

 This would be a PITA. And it would be slower on FS that provide dt_type.

Indeed. So I'm going to replace eina_file_direct_ls() with
eina_file_stat_ls() in some places that depends on file type (e.g.,
elementary_config).

How about it ?

-- 
Paulo Alcantara,ProFUSION Embedded Systems

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Magic Check Failed Segfault

[Jeff Hoogland]

OK so I've upgraded to the 1.7.5 EFL snapshot and at kuuko's advice I've
upgraded my python bindings to SVN (except for python-evas that will not
build against EFL 1.7.5).

I now get this dump log which gives a bunch of feedback from the EFLs and
the VLC backend I am using - http://paste.debian.net/222629/

Since the last line references libva.so  does that mean it is an issue with
that library instead of the EFLs? Not really sure what to make of the error.


On Mon, Jan 7, 2013 at 1:06 PM, Jeff Hoogland jeffhoogl...@linux.comwrote:

 Some of the time when this block of code is run -
 http://paste.debian.net/222589/

 My application gets a segfault with this error message -
 http://paste.debian.net/222591/

 Here is the full code in case something else might be causing this -
 http://paste.debian.net/222590

 Most of the time the chunk of code in question works without a hitch, but
 sometimes the causes a segfault. Anyone know exactly what is going wrong?
 That message is greek to me.

 I am using EFL 1.7.4 and Python binding snapshot 1.7.0

 --
 ~Jeff Hoogland http://jeffhoogland.com/
 Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog
 Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop




-- 
~Jeff Hoogland http://jeffhoogland.com/
Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog
Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina benchmark and eina_file patches

[Gustavo Lima Chaves]

* Jérémy Zurcher jer...@asynk.ch [2012-11-18 01:24:27 +0100]:

 Hi,
 
 0002-_eina_file_escape-take-care-of.patch
   takes care of '/./' and breaks loop on '/..$'
 
 0001-sanitize-eina-benchmark-compilation.patch
   cleans up and fixes 'make benchmark'
   saddly eina_bench stills segv and as I can't find any install target for
   it, and I'm not a kung-auto-foo warrior, I can't gdb it.
   could someone provide a benchmark-install target or point me to the
   direction I missed?
 
 p.s.
   fucking \t !!

Thanks muchly, Jeremy. (Tested and) applied.

-- 
Gustavo Lima Chaves
Computer Engineer @ ProFUSION Embedded Systems

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina thread create abstraction?

[Vincent Torri]

On Mon, Sep 24, 2012 at 11:56 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
 Hi all, particularly Vincent :-)

 Eina provides mutex abstraction with eina_lock, however the thread creation
 is not there as most users should be using ecore_thread. All nice, but for
 evas threaded render, we'll need to create threads that are not related to
 the main loop/ecore, then I'm wondering what to do:
   1 - leave windows out for now;
   2 - add eina_thread_create() that abstracts pthread_create() and
 CreateThread()
   3 - #ifdef inside evas

afaik, cedric wants to add such abstraction in eina, but was thinking
about how to do it. I proposed something to him, but he didn't like
it. Now, I'm waiting...

Vincent

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina thread create abstraction?

[Cedric BAIL]

On Tue, Sep 25, 2012 at 7:43 AM, Vincent Torri vincent.to...@gmail.com wrote:
 On Mon, Sep 24, 2012 at 11:56 PM, Gustavo Sverzut Barbieri
 barbi...@profusion.mobi wrote:
 Hi all, particularly Vincent :-)

 Eina provides mutex abstraction with eina_lock, however the thread creation
 is not there as most users should be using ecore_thread. All nice, but for
 evas threaded render, we'll need to create threads that are not related to
 the main loop/ecore, then I'm wondering what to do:
   1 - leave windows out for now;
   2 - add eina_thread_create() that abstracts pthread_create() and
 CreateThread()
   3 - #ifdef inside evas

 afaik, cedric wants to add such abstraction in eina, but was thinking
 about how to do it. I proposed something to him, but he didn't like
 it. Now, I'm waiting...

Yes, it's on my short term todo list. Maybe before a week or so.
-- 
Cedric BAIL

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina with --disable-safety-checks fails in compilation

[The Rasterman]

On Thu, 1 Mar 2012 09:08:46 +0100 Thanatermesis thanatermesis.e...@gmail.com
said:

unless someone fixed this... it works for me (atm) :)

 If you add the parameter --disable-safety-checks to the configure options
 of libeina, the compilation fails:
 
 $ make V=1
 make[3]: Entering directory `/mkdeb/build/libeina/libeina/src/lib'
 /bin/bash ../../libtool  --tag=CC   --mode=compile ccache gcc -std=gnu99
 -DHAVE_CONFIG_H -I. -I../..  -I../../src/include -I../../src/include
 -DPACKAGE_BIN_DIR=\/usr/bin\
 -DPACKAGE_LIB_DIR=\/usr/lib/i386-linux-gnu\
 -DPACKAGE_DATA_DIR=\/usr/share/eina\  -D_FORTIFY_SOURCE=2 -pthread -g -O2
 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
 -Werror=format-security -O2 -fvisibility=hidden -Wshadow
 -ffunction-sections -fdata-sections -ffast-math -Wall -W -Wshadow  -c -o
 libeina_la-eina_main.lo `test -f 'eina_main.c' || echo './'`eina_main.c
 libtool: compile:  ccache gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..
 -I../../src/include -I../../src/include -DPACKAGE_BIN_DIR=\/usr/bin\
 -DPACKAGE_LIB_DIR=\/usr/lib/i386-linux-gnu\
 -DPACKAGE_DATA_DIR=\/usr/share/eina\ -D_FORTIFY_SOURCE=2 -pthread -g -O2
 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
 -Werror=format-security -O2 -fvisibility=hidden -Wshadow
 -ffunction-sections -fdata-sections -ffast-math -Wall -W -Wshadow -c
 eina_main.c  -fPIC -DPIC -o .libs/libeina_la-eina_main.o
 In file included from eina_main.c:72:0:
 ../../src/include/eina_model.h:1192:64: error: nonnull argument references
 non-pointer operand (argument 1, operand 2)
 In file included from eina_main.c:72:0:
 ../../src/include/eina_model.h:1261:66: error: nonnull argument references
 non-pointer operand (argument 1, operand 2)
 make[3]: *** [libeina_la-eina_main.lo] Error 1
 make[3]: Leaving directory `/mkdeb/build/libeina/libeina/src/lib'
 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing 
 also focuses on allowing computing to be delivered as a service.
 http://www.accelacomm.com/jaw/sfnl/114/51521223/
 ___
 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


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina got broke.

[Cedric BAIL]

On Thu, Jan 19, 2012 at 2:38 PM, David Seikel onef...@gmail.com wrote:
 I'm getting lots of these while trying to compile latest SVN.

What are you doing to trigger that error ? Can you get us a valgrind backtrace ?

Thanks,

 *** glibc detected
 *** 
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2:
 corrupted double-linked list: 0x01938f40 *** === Backtrace:
 = /lib/libc.so.6(+0x775b6)[0x2b4927b6c5b6] 
 /lib/libc.so.6(+0x77a1f)[0x2b4927b6ca1f]
 /lib/libc.so.6(+0x7a460)[0x2b4927b6f460]
 /lib/libc.so.6(cfree+0x73)[0x2b4927b72e83]
 /opt/e17/lib/libeina.so.1(+0x4c7f5)[0x2b49265a37f5]
 /opt/e17/lib/libeina.so.1(+0x4caac)[0x2b49265a3aac]
 /opt/e17/lib/libeina.so.1(+0x4cc82)[0x2b49265a3c82]
 /opt/e17/lib/libeina.so.1(+0x1d51f)[0x2b492657451f]
 /opt/e17/lib/libeina.so.1(+0x1d68a)[0x2b492657468a]
 /opt/e17/lib/libeina.so.1(+0x1d764)[0x2b4926574764]
 /opt/e17/lib/libeina.so.1(eina_list_remove_list+0x16d)[0x2b4926575bf6]
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0(_elm_widget_type_clear+0x50)[0x2b4924ddbc32]
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0(elm_quicklaunch_shutdown+0x144)[0x2b4924d8a55d]
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0(elm_shutdown+0x48)[0x2b4924d89b5e]
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2[0x400e03]
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2[0x400e3b]
 /lib/libc.so.6(__libc_start_main+0xfd)[0x2b4927b13c4d]
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2[0x400bf9]
 === Memory map: 
 0040-00402000 r-xp  08:04
 4597434                            
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2
 00601000-00602000 r--p 1000 08:04
 4597434                            
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2
 00602000-00603000 rw-p 2000 08:04
 4597434                            
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2
 0193-01aba000 rw-p  00:00
 0                                  [heap] 2b4924a96000-2b4924ab6000
 r-xp  08:02 6029845                    /lib/ld-2.11.1.so
 2b4924ab6000-2b4924ab8000 rw-p  00:00 0
 2b4924cb5000-2b4924cb6000 r--p 0001f000 08:02
 6029845                    /lib/ld-2.11.1.so 2b4924cb6000-2b4924cb7000
 rw-p 0002 08:02 6029845                    /lib/ld-2.11.1.so
 2b4924cb7000-2b4924cb8000 rw-p  00:00 0
 2b4924cb8000-2b4924e47000 r-xp  08:04
 4469681                    
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
 2b4924e47000-2b4925047000 ---p 0018f000 08:04
 4469681                    
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
 2b4925047000-2b4925049000 r--p 0018f000 08:04
 4469681                    
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
 2b4925049000-2b492504e000 rw-p 00191000 08:04
 4469681                    
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
 2b492504e000-2b492504f000 rw-p  00:00 0
 2b492504f000-2b4925055000 r-xp  08:02
 262707                     /opt/e17/lib/libeweather.so.0.0.0
 2b4925055000-2b4925254000 ---p 6000 08:02
 262707                     /opt/e17/lib/libeweather.so.0.0.0
 2b4925254000-2b4925255000 r--p 5000 08:02
 262707                     /opt/e17/lib/libeweather.so.0.0.0
 2b4925255000-2b4925256000 rw-p 6000 08:02
 262707                     /opt/e17/lib/libeweather.so.0.0.0
 2b4925256000-2b4925277000 r-xp  08:02
 264371                     /opt/e17/lib/libecore_con.so.1.1.99
 2b4925277000-2b4925476000 ---p 00021000 08:02
 264371                     /opt/e17/lib/libecore_con.so.1.1.99
 2b4925476000-2b4925477000 r--p 0002 08:02
 264371                     /opt/e17/lib/libecore_con.so.1.1.99
 2b4925477000-2b4925478000 rw-p 00021000 08:02
 264371                     /opt/e17/lib/libecore_con.so.1.1.99
 2b4925478000-2b4925485000 r-xp  08:02
 264417                     /opt/e17/lib/libedbus.so.1.1.99
 2b4925485000-2b4925684000 ---p d000 08:02
 264417                     /opt/e17/lib/libedbus.so.1.1.99
 2b4925684000-2b4925685000 r--p c000 08:02
 264417                     /opt/e17/lib/libedbus.so.1.1.99
 2b4925685000-2b4925686000 rw-p d000 08:02
 264417                     /opt/e17/lib/libedbus.so.1.1.99
 2b4925686000-2b492568a000 rw-p  00:00 0
 2b49256b9000-2b49256ba000 rw-p  00:00 0
 2b49256ba000-2b49256f7000 r-xp  08:02
 6030453                    

Re: [E-devel] eina got broke.

[Sanjeev B.A.]

Just built everything in my home PC. WFM.

On Thu, Jan 19, 2012 at 10:46 PM, Cedric BAIL cedric.b...@free.fr wrote:

 On Thu, Jan 19, 2012 at 2:38 PM, David Seikel onef...@gmail.com wrote:
  I'm getting lots of these while trying to compile latest SVN.

 What are you doing to trigger that error ? Can you get us a valgrind
 backtrace ?

 Thanks,

  *** glibc detected
  ***
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2:
  corrupted double-linked list: 0x01938f40 *** === Backtrace:
  = /lib/libc.so.6(+0x775b6)[0x2b4927b6c5b6]
 /lib/libc.so.6(+0x77a1f)[0x2b4927b6ca1f]
  /lib/libc.so.6(+0x7a460)[0x2b4927b6f460]
  /lib/libc.so.6(cfree+0x73)[0x2b4927b72e83]
  /opt/e17/lib/libeina.so.1(+0x4c7f5)[0x2b49265a37f5]
  /opt/e17/lib/libeina.so.1(+0x4caac)[0x2b49265a3aac]
  /opt/e17/lib/libeina.so.1(+0x4cc82)[0x2b49265a3c82]
  /opt/e17/lib/libeina.so.1(+0x1d51f)[0x2b492657451f]
  /opt/e17/lib/libeina.so.1(+0x1d68a)[0x2b492657468a]
  /opt/e17/lib/libeina.so.1(+0x1d764)[0x2b4926574764]
  /opt/e17/lib/libeina.so.1(eina_list_remove_list+0x16d)[0x2b4926575bf6]
 
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0(_elm_widget_type_clear+0x50)[0x2b4924ddbc32]
 
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0(elm_quicklaunch_shutdown+0x144)[0x2b4924d8a55d]
 
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0(elm_shutdown+0x48)[0x2b4924d89b5e]
 
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2[0x400e03]
 
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2[0x400e3b]
  /lib/libc.so.6(__libc_start_main+0xfd)[0x2b4927b13c4d]
 
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2[0x400bf9]
  === Memory map: 
  0040-00402000 r-xp  08:04
  4597434
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2
  00601000-00602000 r--p 1000 08:04
  4597434
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2
  00602000-00603000 rw-p 2000 08:04
  4597434
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/doc/widgets/.libs/lt-widget_preview_fileselector_button2
  0193-01aba000 rw-p  00:00
  0  [heap] 2b4924a96000-2b4924ab6000
  r-xp  08:02 6029845/lib/ld-2.11.1.so
  2b4924ab6000-2b4924ab8000 rw-p  00:00 0
  2b4924cb5000-2b4924cb6000 r--p 0001f000 08:02
  6029845/lib/ld-2.11.1.so 2b4924cb6000-2b4924cb7000
  rw-p 0002 08:02 6029845/lib/ld-2.11.1.so
  2b4924cb7000-2b4924cb8000 rw-p  00:00 0
  2b4924cb8000-2b4924e47000 r-xp  08:04
  4469681
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
  2b4924e47000-2b4925047000 ---p 0018f000 08:04
  4469681
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
  2b4925047000-2b4925049000 r--p 0018f000 08:04
  4469681
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
  2b4925049000-2b492504e000 rw-p 00191000 08:04
  4469681
  
 /home/dvs1/e17_svn/SVN/trunk/elementary/src/lib/.libs/libelementary-ver-pre-svn-09.so.0.8.0
  2b492504e000-2b492504f000 rw-p  00:00 0
  2b492504f000-2b4925055000 r-xp  08:02
  262707 /opt/e17/lib/libeweather.so.0.0.0
  2b4925055000-2b4925254000 ---p 6000 08:02
  262707 /opt/e17/lib/libeweather.so.0.0.0
  2b4925254000-2b4925255000 r--p 5000 08:02
  262707 /opt/e17/lib/libeweather.so.0.0.0
  2b4925255000-2b4925256000 rw-p 6000 08:02
  262707 /opt/e17/lib/libeweather.so.0.0.0
  2b4925256000-2b4925277000 r-xp  08:02
  264371 /opt/e17/lib/libecore_con.so.1.1.99
  2b4925277000-2b4925476000 ---p 00021000 08:02
  264371 /opt/e17/lib/libecore_con.so.1.1.99
  2b4925476000-2b4925477000 r--p 0002 08:02
  264371 /opt/e17/lib/libecore_con.so.1.1.99
  2b4925477000-2b4925478000 rw-p 00021000 08:02
  264371 /opt/e17/lib/libecore_con.so.1.1.99
  2b4925478000-2b4925485000 r-xp  08:02
  264417 /opt/e17/lib/libedbus.so.1.1.99
  2b4925485000-2b4925684000 ---p d000 08:02
  264417 /opt/e17/lib/libedbus.so.1.1.99
  2b4925684000-2b4925685000 r--p c000 08:02
  264417 /opt/e17/lib/libedbus.so.1.1.99
  2b4925685000-2b4925686000 rw-p d000 08:02
  264417 /opt/e17/lib/libedbus.so.1.1.99
  2b4925686000-2b492568a000 rw-p  00:00 0
  2b49256b9000-2b49256ba000 rw-p  00:00 0
  2b49256ba000-2b49256f7000 r-xp 

Re: [E-devel] eina got broke. Or maybe elementary.

[David Seikel]

Now that I can actually investigate myself, it's happening when I run
make doc in elementary/doc

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[The Rasterman]

On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de
said:

 Hi all,
 sorry for not finding the time for doing this earlier. Attached is a
 patch that sorts out a number of smaller issues with eina on NetBSD and
 Solaris. Some are noise, some are real bugs. This brings it down to one
 compiler warning for iconv, which is expected (and messy).

ok - in svn. thanks for the explanations etc. yes - i know we grump about and
argue... but a good explanation wins. though the isspace() thing i still think
is ... weird... i'll put it in too as i can see a potential issue there -
maybe.


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[The Rasterman]

On Fri, 2 Dec 2011 08:42:43 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Fri, 2 Dec 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Fri, 2 Dec 2011 08:28:36 +0100 (CET) Vincent Torri vto...@univ-evry.fr
  said:
 
 
 
  On Fri, 2 Dec 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger
  jo...@britannica.bec.de said:
 
  this is really late... and a lot of these patches i find questionable.
  i'll question here (things not questioned seem ok):
 
  1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra
  || defined(__SUNPRO_C) and why the check for __sun should be removed?
 
  __sun : it's a sun compiler
  __SUNPRO_C : it's a sun compiler and that macro has the value of the
  compiler version
 
  so... its exactly the same check - ALL sun compilers that have __sun set
  ALSO set __SUNPRO_C ?
 
 http://developers.sun.com/sunstudio/products/faqs/cpp.html#q1

so.. the code can stay as-is then. no need to change. :)

 Vincent
 
 
  2. all the chasting and changing to unsigned char for passing into isspace
  () - isspace() actually takes an int, not unsigned char, so this just
  doesn't make sense. :( (well it does according to the manual page i have)
 
  same here, it takes an int. As isspace() is conforming to C89, i doubt it
  takes something else than an int.
 
  agreed. this looks bogus
 
  Vincent
 
  Hi all,
  sorry for not finding the time for doing this earlier. Attached is a
  patch that sorts out a number of smaller issues with eina on NetBSD and
  Solaris. Some are noise, some are real bugs. This brings it down to one
  compiler warning for iconv, which is expected (and messy).
 
  Joerg
 
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
  --
  All the data continuously generated in your IT infrastructure
  contains a definitive record of customers, application performance,
  security threats, fraudulent activity, and more. Splunk takes this
  data and makes sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-novd2d
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
  --
  All the data continuously generated in your IT infrastructure
  contains a definitive record of customers, application performance,
  security threats, fraudulent activity, and more. Splunk takes this
  data and makes sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-novd2d
  ___
  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
 
 
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Joerg Sonnenberger]

On Fri, Dec 02, 2011 at 04:00:46PM +0900, Carsten Haitzler wrote:
 On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de
 said:
 
  Hi all,
  sorry for not finding the time for doing this earlier. Attached is a
  patch that sorts out a number of smaller issues with eina on NetBSD and
  Solaris. Some are noise, some are real bugs. This brings it down to one
  compiler warning for iconv, which is expected (and messy).
 
 ooh. and the dirfd check... looks just like something that would crash! so
 that's actually not a valid check at all... well if it is run after compiling
 to check feature existence :)

It's not run. It's just supposed to compile and link correctly. Using
a global variable just prevents surprising optimisations by the compiler.
The problem is that the existing check using AC_CHECK_FUNCS won't work,
if dirfd is just available as a macro.

Joerg

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Joerg Sonnenberger]

On Fri, Dec 02, 2011 at 03:37:30PM +0900, Carsten Haitzler wrote:
 On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de
 said:
 
 this is really late... and a lot of these patches i find questionable. i'll
 question here (things not questioned seem ok):
 
 1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
 defined(__SUNPRO_C) and why the check for __sun should be removed?

I think you are reading the diff wrong. It replaces __SUNPRO_C (the
compiler specific macro) with __sun (the platform specific macro). I
don't mind using it as additional case though.

 2. all the chasting and changing to unsigned char for passing into isspace() -
 isspace() actually takes an int, not unsigned char, so this just doesn't make
 sense. :( (well it does according to the manual page i have)

Please read the manual again. ctype.h stuff takes an integer argument,
but the value must be -1..255 (for 8bit char and EOF==-1). It is
undefined behavior to pass anything else. Especially in programs using
setlocale(), the result for 0xff as input byte can make a real
difference for platforms with signed char.

Joerg

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Sachiel]

2011/12/2 Joerg Sonnenberger jo...@britannica.bec.de:
 On Fri, Dec 02, 2011 at 03:37:30PM +0900, Carsten Haitzler wrote:
 On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger 
 jo...@britannica.bec.de
 said:

 this is really late... and a lot of these patches i find questionable. i'll
 question here (things not questioned seem ok):

 1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
 defined(__SUNPRO_C) and why the check for __sun should be removed?

 I think you are reading the diff wrong. It replaces __SUNPRO_C (the
 compiler specific macro) with __sun (the platform specific macro). I
 don't mind using it as additional case though.

 2. all the chasting and changing to unsigned char for passing into isspace() 
 -
 isspace() actually takes an int, not unsigned char, so this just doesn't make
 sense. :( (well it does according to the manual page i have)

 Please read the manual again. ctype.h stuff takes an integer argument,
 but the value must be -1..255 (for 8bit char and EOF==-1). It is
 undefined behavior to pass anything else. Especially in programs using
 setlocale(), the result for 0xff as input byte can make a real
 difference for platforms with signed char.


How do you differentiate between -1 and 255 in one unsigned char?

 Joerg

 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[The Rasterman]

On Fri, 2 Dec 2011 13:39:41 +0100 Joerg Sonnenberger jo...@britannica.bec.de
said:

 On Fri, Dec 02, 2011 at 03:37:30PM +0900, Carsten Haitzler wrote:
  On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger
  jo...@britannica.bec.de said:
  
  this is really late... and a lot of these patches i find questionable. i'll
  question here (things not questioned seem ok):
  
  1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
  defined(__SUNPRO_C) and why the check for __sun should be removed?
 
 I think you are reading the diff wrong. It replaces __SUNPRO_C (the
 compiler specific macro) with __sun (the platform specific macro). I
 don't mind using it as additional case though.

aaah yes  you're right. i was reading it wrong. i guess __sun sounds more
generic.

  2. all the chasting and changing to unsigned char for passing into isspace
  () - isspace() actually takes an int, not unsigned char, so this just
  doesn't make sense. :( (well it does according to the manual page i have)
 
 Please read the manual again. ctype.h stuff takes an integer argument,
 but the value must be -1..255 (for 8bit char and EOF==-1). It is
 undefined behavior to pass anything else. Especially in programs using

no such mention in the manual page at all. no limits on range. since an integer
is the possible input, then it must handle all int values sensibly in some way
as the docs don't mention any limitations. :)

 setlocale(), the result for 0xff as input byte can make a real
 difference for platforms with signed char.

can  you point me to these docs, as the manual page i have in front of me for
linux disagrees :)

 
 Joerg
 
 --
 All the data continuously generated in your IT infrastructure 
 contains a definitive record of customers, application performance, 
 security threats, fraudulent activity, and more. Splunk takes this 
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 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


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Joerg Sonnenberger]

On Fri, Dec 02, 2011 at 09:51:12PM +0900, Carsten Haitzler wrote:
   2. all the chasting and changing to unsigned char for passing into isspace
   () - isspace() actually takes an int, not unsigned char, so this just
   doesn't make sense. :( (well it does according to the manual page i have)
  
  Please read the manual again. ctype.h stuff takes an integer argument,
  but the value must be -1..255 (for 8bit char and EOF==-1). It is
  undefined behavior to pass anything else. Especially in programs using
 
 no such mention in the manual page at all. no limits on range. since an 
 integer
 is the possible input, then it must handle all int values sensibly in some way
 as the docs don't mention any limitations. :)
 
  setlocale(), the result for 0xff as input byte can make a real
  difference for platforms with signed char.
 
 can  you point me to these docs, as the manual page i have in front of me for
 linux disagrees :)

http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html

Note the last paragraph in DESCRIPTION.

Joerg

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Vincent Torri]

On Fri, 2 Dec 2011, Joerg Sonnenberger wrote:

 On Fri, Dec 02, 2011 at 09:51:12PM +0900, Carsten Haitzler wrote:
 2. all the chasting and changing to unsigned char for passing into isspace
 () - isspace() actually takes an int, not unsigned char, so this just
 doesn't make sense. :( (well it does according to the manual page i have)

 Please read the manual again. ctype.h stuff takes an integer argument,
 but the value must be -1..255 (for 8bit char and EOF==-1). It is
 undefined behavior to pass anything else. Especially in programs using

 no such mention in the manual page at all. no limits on range. since an 
 integer
 is the possible input, then it must handle all int values sensibly in some 
 way
 as the docs don't mention any limitations. :)

 setlocale(), the result for 0xff as input byte can make a real
 difference for platforms with signed char.

 can  you point me to these docs, as the manual page i have in front of me for
 linux disagrees :)

 http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html

 Note the last paragraph in DESCRIPTION.

so why not just do a  0xff instead of casting ?

Vincent


 Joerg

 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Joerg Sonnenberger]

On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote:
 so why not just do a  0xff instead of casting ?

The cast is IMO cleaner in the intentions. It also has the theoretical
advantage of working independent of CHAR_BIT==8.

Joerg

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Sachiel]

2011/12/2 Joerg Sonnenberger jo...@britannica.bec.de:
 On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote:
 so why not just do a  0xff instead of casting ?

 The cast is IMO cleaner in the intentions. It also has the theoretical
 advantage of working independent of CHAR_BIT==8.


We are not reading from a file so there' won't really be an EOF, but I insist
on it. How does isspace() recognize EOF when you are casting to unsigned char?
Even if we don't need it now, it makes the whole deal smell to a nasty
hack covering
from some obscure bug. And if there's no bug, then what are fixing here?

 Joerg

 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Vincent Torri]

On Fri, 2 Dec 2011, Joerg Sonnenberger wrote:

 On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote:
 so why not just do a  0xff instead of casting ?

 The cast is IMO cleaner in the intentions. It also has the theoretical
 advantage of working independent of CHAR_BIT==8.

except some old Cray and some DSP, i think that all the arch have 
CHAR_BIT == 8. At least all the arch that the EFL targets

Vincent


 Joerg

 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Joerg Sonnenberger]

On Fri, Dec 02, 2011 at 07:33:15PM -0200, Iván Briano (Sachiel) wrote:
 2011/12/2 Joerg Sonnenberger jo...@britannica.bec.de:
  On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote:
  so why not just do a  0xff instead of casting ?
 
  The cast is IMO cleaner in the intentions. It also has the theoretical
  advantage of working independent of CHAR_BIT==8.
 
 
 We are not reading from a file so there' won't really be an EOF, but I insist
 on it. How does isspace() recognize EOF when you are casting to unsigned char?
 Even if we don't need it now, it makes the whole deal smell to a nasty
 hack covering
 from some obscure bug. And if there's no bug, then what are fixing here?

The input is a character stream. If you are storing EOF inside char *,
you have already done something wrong. That's why e.g. fgetc() returns
an int, so that you can distinguish them.

The problem here is that (char)-128 is sign extended to (int)-128, which is
quite different from (int)(unsigned char)-128, which is 0x80. A perfectly
valid implementation of the ctype.h functions is

#define isspace(x) (typetable[(x) + 1]  TYPE_SPACE)

Without the cast, this can access memory before the start of the table.
Some systems apply work arounds to let broken code pass. On Linux, it
duplicates the upper half of the table below and uses 128 as offset.
This doesn't penalize correct code, but implies incorrect results for
8bit clean locales. On OpenBSD, it internally compares to EOF (aka -1)
and returns 0 explicitly. Same problem with the additional cost of a
compare on platforms without unsigned char by default.

What it all boils down to is that certain parts of the C standard
libraries are interacting badly with platforms where char is signed.
That's not something that can fixed easily.

On the positive side, a macro definition like the above ensures that
many compilers will warn about the incorrect instances.

Joerg

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Sachiel]

2011/12/2 Joerg Sonnenberger jo...@britannica.bec.de:
 On Fri, Dec 02, 2011 at 07:33:15PM -0200, Iván Briano (Sachiel) wrote:
 2011/12/2 Joerg Sonnenberger jo...@britannica.bec.de:
  On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote:
  so why not just do a  0xff instead of casting ?
 
  The cast is IMO cleaner in the intentions. It also has the theoretical
  advantage of working independent of CHAR_BIT==8.
 

 We are not reading from a file so there' won't really be an EOF, but I insist
 on it. How does isspace() recognize EOF when you are casting to unsigned 
 char?
 Even if we don't need it now, it makes the whole deal smell to a nasty
 hack covering
 from some obscure bug. And if there's no bug, then what are fixing here?

 The input is a character stream. If you are storing EOF inside char *,
 you have already done something wrong. That's why e.g. fgetc() returns
 an int, so that you can distinguish them.

 The problem here is that (char)-128 is sign extended to (int)-128, which is
 quite different from (int)(unsigned char)-128, which is 0x80. A perfectly
 valid implementation of the ctype.h functions is

 #define isspace(x) (typetable[(x) + 1]  TYPE_SPACE)

 Without the cast, this can access memory before the start of the table.
 Some systems apply work arounds to let broken code pass. On Linux, it
 duplicates the upper half of the table below and uses 128 as offset.
 This doesn't penalize correct code, but implies incorrect results for
 8bit clean locales. On OpenBSD, it internally compares to EOF (aka -1)
 and returns 0 explicitly. Same problem with the additional cost of a
 compare on platforms without unsigned char by default.

 What it all boils down to is that certain parts of the C standard
 libraries are interacting badly with platforms where char is signed.
 That's not something that can fixed easily.

 On the positive side, a macro definition like the above ensures that
 many compilers will warn about the incorrect instances.


Wonderful! Now we have an actual explanation of why the patch is needed
instead of just discussing the interpretation of a man page. Thanks a lot.

 Joerg

 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[The Rasterman]

On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de
said:

this is really late... and a lot of these patches i find questionable. i'll
question here (things not questioned seem ok):

1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
defined(__SUNPRO_C) and why the check for __sun should be removed?

2. all the chasting and changing to unsigned char for passing into isspace() -
isspace() actually takes an int, not unsigned char, so this just doesn't make
sense. :( (well it does according to the manual page i have)

 Hi all,
 sorry for not finding the time for doing this earlier. Attached is a
 patch that sorts out a number of smaller issues with eina on NetBSD and
 Solaris. Some are noise, some are real bugs. This brings it down to one
 compiler warning for iconv, which is expected (and messy).
 
 Joerg


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[The Rasterman]

On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de
said:

 Hi all,
 sorry for not finding the time for doing this earlier. Attached is a
 patch that sorts out a number of smaller issues with eina on NetBSD and
 Solaris. Some are noise, some are real bugs. This brings it down to one
 compiler warning for iconv, which is expected (and messy).

ooh. and the dirfd check... looks just like something that would crash! so
that's actually not a valid check at all... well if it is run after compiling
to check feature existence :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Vincent Torri]

On Fri, 2 Dec 2011, Carsten Haitzler (The Rasterman) wrote:

 On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de
 said:

 this is really late... and a lot of these patches i find questionable. i'll
 question here (things not questioned seem ok):

 1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
 defined(__SUNPRO_C) and why the check for __sun should be removed?

__sun : it's a sun compiler
__SUNPRO_C : it's a sun compiler and that macro has the value of the 
compiler version

 2. all the chasting and changing to unsigned char for passing into isspace() -
 isspace() actually takes an int, not unsigned char, so this just doesn't make
 sense. :( (well it does according to the manual page i have)

same here, it takes an int. As isspace() is conforming to C89, i doubt it 
takes something else than an int.

Vincent

 Hi all,
 sorry for not finding the time for doing this earlier. Attached is a
 patch that sorts out a number of smaller issues with eina on NetBSD and
 Solaris. Some are noise, some are real bugs. This brings it down to one
 compiler warning for iconv, which is expected (and messy).

 Joerg


 -- 
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[The Rasterman]

On Fri, 2 Dec 2011 08:28:36 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Fri, 2 Dec 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger
  jo...@britannica.bec.de said:
 
  this is really late... and a lot of these patches i find questionable. i'll
  question here (things not questioned seem ok):
 
  1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
  defined(__SUNPRO_C) and why the check for __sun should be removed?
 
 __sun : it's a sun compiler
 __SUNPRO_C : it's a sun compiler and that macro has the value of the 
 compiler version

so... its exactly the same check - ALL sun compilers that have __sun set ALSO
set __SUNPRO_C ?

  2. all the chasting and changing to unsigned char for passing into isspace
  () - isspace() actually takes an int, not unsigned char, so this just
  doesn't make sense. :( (well it does according to the manual page i have)
 
 same here, it takes an int. As isspace() is conforming to C89, i doubt it 
 takes something else than an int.

agreed. this looks bogus

 Vincent
 
  Hi all,
  sorry for not finding the time for doing this earlier. Attached is a
  patch that sorts out a number of smaller issues with eina on NetBSD and
  Solaris. Some are noise, some are real bugs. This brings it down to one
  compiler warning for iconv, which is expected (and messy).
 
  Joerg
 
 
  -- 
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
  --
  All the data continuously generated in your IT infrastructure
  contains a definitive record of customers, application performance,
  security threats, fraudulent activity, and more. Splunk takes this
  data and makes sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-novd2d
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
 --
 All the data continuously generated in your IT infrastructure 
 contains a definitive record of customers, application performance, 
 security threats, fraudulent activity, and more. Splunk takes this 
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 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


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc

[Vincent Torri]

On Fri, 2 Dec 2011, Carsten Haitzler (The Rasterman) wrote:

 On Fri, 2 Dec 2011 08:28:36 +0100 (CET) Vincent Torri vto...@univ-evry.fr
 said:



 On Fri, 2 Dec 2011, Carsten Haitzler (The Rasterman) wrote:

 On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger
 jo...@britannica.bec.de said:

 this is really late... and a lot of these patches i find questionable. i'll
 question here (things not questioned seem ok):

 1. __SUNPRO_C instead of __sun - explain why you dont just ADD an extra ||
 defined(__SUNPRO_C) and why the check for __sun should be removed?

 __sun : it's a sun compiler
 __SUNPRO_C : it's a sun compiler and that macro has the value of the
 compiler version

 so... its exactly the same check - ALL sun compilers that have __sun set ALSO
 set __SUNPRO_C ?

http://developers.sun.com/sunstudio/products/faqs/cpp.html#q1

Vincent


 2. all the chasting and changing to unsigned char for passing into isspace
 () - isspace() actually takes an int, not unsigned char, so this just
 doesn't make sense. :( (well it does according to the manual page i have)

 same here, it takes an int. As isspace() is conforming to C89, i doubt it
 takes something else than an int.

 agreed. this looks bogus

 Vincent

 Hi all,
 sorry for not finding the time for doing this earlier. Attached is a
 patch that sorts out a number of smaller issues with eina on NetBSD and
 Solaris. Some are noise, some are real bugs. This brings it down to one
 compiler warning for iconv, which is expected (and messy).

 Joerg


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



 --
 All the data continuously generated in your IT infrastructure
 contains a definitive record of customers, application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-novd2d
 ___
 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



--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[The Rasterman]

On Tue, 17 May 2011 17:56:16 +0300 Tom Hacohen
tom.haco...@partner.samsung.com said:

eina_prefix actually is hard to test given the test harness as it relies on an
installation following a certain standard :( can't really do it given the test
setup.

 Hey,
 
 I just ran eina coverage and a lot of the code is not tested :(
 
 Mainly:
 eina_file, eina_log, eina_module, eina_object, eina_prefix,
 eina_simple_xml_parser, and eina_str.
 
 Whoever is responsible for each part, please fix.
 
 Thanks,
 Tom.
 
 
 --
 Achieve unprecedented app performance and reliability
 What every C/C++ and Fortran developer should know.
 Learn how Intel has extended the reach of its next-generation tools
 to help boost performance applications - inlcuding clusters.
 http://p.sf.net/sfu/intel-dev2devmay
 ___
 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


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[Tom Hacohen]

:( 

On Mon, 2011-05-30 at 17:59 +0900, Carsten Haitzler wrote:
 On Tue, 17 May 2011 17:56:16 +0300 Tom Hacohen
 tom.haco...@partner.samsung.com said:
 
 eina_prefix actually is hard to test given the test harness as it relies on an
 installation following a certain standard :( can't really do it given the test
 setup.
 
  Hey,
  
  I just ran eina coverage and a lot of the code is not tested :(
  
  Mainly:
  eina_file, eina_log, eina_module, eina_object, eina_prefix,
  eina_simple_xml_parser, and eina_str.
  
  Whoever is responsible for each part, please fix.
  
  Thanks,
  Tom.
  
  
  --
  Achieve unprecedented app performance and reliability
  What every C/C++ and Fortran developer should know.
  Learn how Intel has extended the reach of its next-generation tools
  to help boost performance applications - inlcuding clusters.
  http://p.sf.net/sfu/intel-dev2devmay
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[Gustavo Sverzut Barbieri]

On Mon, May 30, 2011 at 5:59 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Tue, 17 May 2011 17:56:16 +0300 Tom Hacohen
 tom.haco...@partner.samsung.com said:

 eina_prefix actually is hard to test given the test harness as it relies on an
 installation following a certain standard :( can't really do it given the test
 setup.

hard but not impossible. You can just create some directory with the
expected setup and in the test you putenv() before entering it. Then
you know what you got and what you'll have.

but it's boring... and bit time consuming :-)


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[The Rasterman]

On Mon, 30 May 2011 11:54:22 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:

 On Mon, May 30, 2011 at 5:59 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
  On Tue, 17 May 2011 17:56:16 +0300 Tom Hacohen
  tom.haco...@partner.samsung.com said:
 
  eina_prefix actually is hard to test given the test harness as it relies on
  an installation following a certain standard :( can't really do it given
  the test setup.
 
 hard but not impossible. You can just create some directory with the
 expected setup and in the test you putenv() before entering it. Then
 you know what you got and what you'll have.
 
 but it's boring... and bit time consuming :-)

well i also have to move the binary to be in a specific directory then
re-execute it from there... and then a data file is expected in another
specific dir and so on... it's not just another simple test. its a whole new
style of test all on its own that requires a specialised tree. just to test the
normal path :)


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[Gustavo Sverzut Barbieri]

On Tue, May 17, 2011 at 11:56 AM, Tom Hacohen
tom.haco...@partner.samsung.com wrote:
 Hey,

 I just ran eina coverage and a lot of the code is not tested :(

 Mainly:
 eina_file, eina_log, eina_module, eina_object, eina_prefix,
 eina_simple_xml_parser, and eina_str.

 Whoever is responsible for each part, please fix.

all the new parts! how unexpected :-D

I did a test with my initial simple_xml_parser, someone can find out
in the mail and convert it in a test?


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[Tom Hacohen]

On Tue, 2011-05-17 at 12:22 -0300, Gustavo Sverzut Barbieri wrote:
 all the new parts! how unexpected :-D
 
 I did a test with my initial simple_xml_parser, someone can find out
 in the mail and convert it in a test?

Sorry, don't have time for that.

Everyone who added new stuff but didn't add tests, go and fix your work!

--
Tom.



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[Gustavo Sverzut Barbieri]

I did not add it :)

On May 17, 2011 12:48 PM, Tom Hacohen tom.haco...@partner.samsung.com
wrote:

On Tue, 2011-05-17 at 12:22 -0300, Gustavo Sverzut Barbieri wrote:
 all the new parts! how unexpect...
Sorry, don't have time for that.

Everyone who added new stuff but didn't add tests, go and fix your work!

--
Tom.
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Coverage tests

[sangho park]

o.. sorry..
'eina_simple_xml_parse' was requested by me..
i'll add test to eina.


 Date: Tue, 17 May 2011 13:29:28 -0300
 From: Gustavo Sverzut Barbieri barbi...@profusion.mobi
 Subject: Re: [E-devel] Eina Coverage tests
 To: Tom Hacohen tom.haco...@partner.samsung.com
 Cc: enlightenment-devel enlightenment-devel@lists.sourceforge.net
 Message-ID: banlktikxfvef8erge5gomnd4ny4wcap...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8

 I did not add it :)

 On May 17, 2011 12:48 PM, Tom Hacohen tom.haco...@partner.samsung.com
 wrote:

 On Tue, 2011-05-17 at 12:22 -0300, Gustavo Sverzut Barbieri wrote:
  all the new parts! how unexpect...
 Sorry, don't have time for that.

 Everyone who added new stuff but didn't add tests, go and fix your work!

 --
 Tom.

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina: keeping .la files for mempools modules

[The Rasterman]

On Sun, 24 Apr 2011 08:13:19 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:

 
 Hey
 
 we are deleting the .la files for the mempool modules. I think that we 
 should provide them. It's the packager of the distro who has to decide 
 whether or not to delete it.
 
 What do you think ?

only for installed libraries. for modules they are of zero use to the packager
or any developer (unlike libeina.la, libedje.la, libevas.la etc. which are of
use to libtool at link time). they are not used in any way by any of efl at
runtime   for module loading (different story *IF* we used libltdl, but we
don't). so its' just useless installcruft :)


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina: keeping .la files for mempools modules

[Vincent Torri]

On Sun, 24 Apr 2011, Carsten Haitzler (The Rasterman) wrote:

 On Sun, 24 Apr 2011 08:13:19 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
 said:


 Hey

 we are deleting the .la files for the mempool modules. I think that we
 should provide them. It's the packager of the distro who has to decide
 whether or not to delete it.

 What do you think ?

 only for installed libraries. for modules they are of zero use to the packager
 or any developer (unlike libeina.la, libedje.la, libevas.la etc. which are of
 use to libtool at link time). they are not used in any way by any of efl at
 runtime   for module loading (different story *IF* we used libltdl, but we
 don't). so its' just useless installcruft :)

so I have fo fix the uninstallation : as we removed the .la file ourself, 
the uninstall rule, which is based on it, does not delete the module

Vincent

--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina: keeping .la files for mempools modules

[The Rasterman]

On Sun, 24 Apr 2011 08:29:22 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Sun, 24 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Sun, 24 Apr 2011 08:13:19 +0200 (CEST) Vincent Torri
  vto...@univ-evry.fr said:
 
 
  Hey
 
  we are deleting the .la files for the mempool modules. I think that we
  should provide them. It's the packager of the distro who has to decide
  whether or not to delete it.
 
  What do you think ?
 
  only for installed libraries. for modules they are of zero use to the
  packager or any developer (unlike libeina.la, libedje.la, libevas.la etc.
  which are of use to libtool at link time). they are not used in any way by
  any of efl at runtime   for module loading (different story *IF* we used
  libltdl, but we don't). so its' just useless installcruft :)
 
 so I have fo fix the uninstallation : as we removed the .la file ourself, 
 the uninstall rule, which is based on it, does not delete the module

that's indeed bad. if we co customising installs we end up having to write
custom uninstall rules too. :(

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina: keeping .la files for mempools modules

[Vincent Torri]

On Sun, 24 Apr 2011, Carsten Haitzler (The Rasterman) wrote:

 On Sun, 24 Apr 2011 08:29:22 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
 said:



 On Sun, 24 Apr 2011, Carsten Haitzler (The Rasterman) wrote:

 On Sun, 24 Apr 2011 08:13:19 +0200 (CEST) Vincent Torri
 vto...@univ-evry.fr said:


 Hey

 we are deleting the .la files for the mempool modules. I think that we
 should provide them. It's the packager of the distro who has to decide
 whether or not to delete it.

 What do you think ?

 only for installed libraries. for modules they are of zero use to the
 packager or any developer (unlike libeina.la, libedje.la, libevas.la etc.
 which are of use to libtool at link time). they are not used in any way by
 any of efl at runtime   for module loading (different story *IF* we used
 libltdl, but we don't). so its' just useless installcruft :)

 so I have fo fix the uninstallation : as we removed the .la file ourself,
 the uninstall rule, which is based on it, does not delete the module

 that's indeed bad. if we co customising installs we end up having to write
 custom uninstall rules too. :(

should I mention that fix in the ChangeLog ? (I think that I should)

Vincent

--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina: keeping .la files for mempools modules

[The Rasterman]

On Sun, 24 Apr 2011 08:55:14 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Sun, 24 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Sun, 24 Apr 2011 08:29:22 +0200 (CEST) Vincent Torri
  vto...@univ-evry.fr said:
 
 
 
  On Sun, 24 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Sun, 24 Apr 2011 08:13:19 +0200 (CEST) Vincent Torri
  vto...@univ-evry.fr said:
 
 
  Hey
 
  we are deleting the .la files for the mempool modules. I think that we
  should provide them. It's the packager of the distro who has to decide
  whether or not to delete it.
 
  What do you think ?
 
  only for installed libraries. for modules they are of zero use to the
  packager or any developer (unlike libeina.la, libedje.la, libevas.la etc.
  which are of use to libtool at link time). they are not used in any way by
  any of efl at runtime   for module loading (different story *IF* we used
  libltdl, but we don't). so its' just useless installcruft :)
 
  so I have fo fix the uninstallation : as we removed the .la file ourself,
  the uninstall rule, which is based on it, does not delete the module
 
  that's indeed bad. if we co customising installs we end up having to write
  custom uninstall rules too. :(
 
 should I mention that fix in the ChangeLog ? (I think that I should)

that's a good q. i guess it fixes a make uninstall bug.

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina error proposal

[Mike Blumenkrantz]

On Sat, 12 Mar 2011 14:02:15 -0500
Mike Blumenkrantz m...@zentific.com wrote:

 Is there a reason why we don't use stringshare for allocated eina_error
 messages? I am planning to add a function like eina_error_eq(Error1, Error2)
 that would be nice to use with stringshare to avoid strcmp where possible...
 
Disregard function addition, I'm dumb in the mornings. Stringshare question
still valid.

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Arg Not NULL should die

[Gustavo Sverzut Barbieri]

On Tue, Sep 7, 2010 at 4:36 AM, Brett Nash n...@nash.id.au wrote:
 Hello All,

 I'm proposing we remove all the EINA_ARG_NOTNULLs floating around in
 public headers.
 In short they may generate a warning, but they subvert any checks we
 have in the API, and can cause valid code to break.

 The not null macro expands to the GCC attribute notnull.  From the GCC
 documentation[1]:
    The compiler may also choose to make optimizations based on the
    knowledge that certain function arguments will not be null.

 This means (with optimisations on) that GCC will remove any calls of the
 form
  if (arg == NULL) return err;
 Because you have told it that arg will NEVER be NULL.

 But we don't make that guarantee at all.  Instead we say that people
 calling this function MAY get a warning if they pass a NULL pointer.

 So we cripple all our magic checks.

 Hence we really should kill the not nulls, they don't do what we want,
 they may give us a small performance boost, but at the unacceptably high
 cost of generating broken code.

First, our checks marked as NONNULL should actually not be NULL, so
although now we don't crash, people shouldn't rely on it as later on,
due optimizations we may remove these checks altogether.

However we noticed loong ago what you said, and that's why we
fixed it: when you're processing the unit with such function
definition you include eina_safety_checks.h and it will redefine such
macro to void. In that case the compiler will not know that the
function parameter may never be null and will keep the check. Actually
this is required to get the logging you see in libraries done right
(check eina itself).

In eina_safety_checks.h we have some documentation about that usage.
If it is not clear then please help fixing it.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina broken in alpha

[Vincent Torri]

On Fri, 27 Aug 2010, Michael Blumenkrantz wrote:

 Just fyi, the alpha release of eina is broken when you try to compile some of
 the modules due to the move of eina_private.h from include/ to lib/.  Whoever
 moved this should have done a test compile.

I think that now we are in alpha, before committing quickly, the committer 
should at least do a make distcheck to verify that he has not broken the 
repo

Vincent

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina - location of the .h's and .x's

[Vincent Torri]

On Tue, 17 Aug 2010, Tom Hacohen wrote:

 Hey all,

 I have heard today that in Eina, all the .h's and .x's should be located
 in the src/include dir, even if they are *not* shipped.

 That's ugly, stupid and confusing.

 There's no reason why to put headers or include files that should not be
 shipped in that directory for the following reasons (and more):
 1. It's not needed: people were smart enough to invent the file
 extensions conventions, which imply that .h are includes and .c are
 source files (and .x are included source files) there's no need for
 another layer of conventions. The include dir should mean: includes that
 are shipped, that is, includes that are visible to the user.
 2. It's confusing: because putting only shipped includes in the
 include directory is pretty much the standard (even in e btw, just not
 in eina), people will take a look there and be surprised some of the
 includes are not shipped and will send patches to fix it and we'll
 just get a bunch of internal includes shipped.

 If there's a rationale, I would really like to hear it, because ATM it
 just makes zero sense.

To be consistent with the other EFL, we would move all the content of 
src/include in src/lib. I'm not against that.

Vincent

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina array: missing guards

[Michael Blumenkrantz]

On Fri, 13 Aug 2010 19:21:12 +0200 (CEST)
Vincent Torri vto...@univ-evry.fr wrote:

 
 hey,
 
 in eina_array.c, lines 761 and 808, some threaded code is not guarded
 
 Vincent
 
 --
 This SF.net email is sponsored by 
 
 Make an app they can't live without
 Enter the BlackBerry Developer Challenge
 http://p.sf.net/sfu/RIM-dev2dev 
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
hmmm guarded how? do you mean it is not mutexed?

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina array: missing guards

[Michael Blumenkrantz]

On Fri, 13 Aug 2010 22:37:40 -0400
Michael Blumenkrantz m...@zentific.com wrote:

 On Fri, 13 Aug 2010 19:21:12 +0200 (CEST)
 Vincent Torri vto...@univ-evry.fr wrote:
 
  
  hey,
  
  in eina_array.c, lines 761 and 808, some threaded code is not guarded
  
  Vincent
  
  --
  This SF.net email is sponsored by 
  
  Make an app they can't live without
  Enter the BlackBerry Developer Challenge
  http://p.sf.net/sfu/RIM-dev2dev 
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 hmmm guarded how? do you mean it is not mutexed?
 
Nevermind, I see now.

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina convert (string to Double) and (double to string)

[Cedric BAIL]

Hi,

On Tue, Aug 10, 2010 at 10:20 AM, Issa frechdes...@gmail.com wrote:
 i have problem to use Eina convert function, i think im not understand
 how that's work.
 if someone can explain me please.

 so i have a function to make my convertion, but all the time the
 convertion failed, but i can't see why.
 maybe some on can explian what i m doing wrong, please ?

eina_convert_dtoa and eina_convert_atod are only supposed to work
together and be portable where ever you go. The string you are giving
to eina_convert_atod should come from eina_convert_dtoa.

-- 
Cedric BAIL

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina convert (string to Double) and (double to string)

[Issa]

hello,

i have take the code exemple on the documentation and i m just trying to
concatene a double to a string.
i have this 
double val = 40.56;
 char *s1 =  Mo;

and for the final i want this
40.56 MO

the code :
-
 #include stdlib.h
 #include stdio.h
 #include math.h

 #include Eina.h

 int main(void)
 {
char  tmp[128];
long long int m = 0;
long int  e = 0;
double val = 40.56;
double  r;
 char *dst;
 char *s1 =  Mo;

  size_t l; 



if (!eina_init())
{
printf (Error during the initialization of eina.\n);
return EXIT_FAILURE;
}

printf(initial value : 40.56\n);
eina_convert_dtoa(val, tmp);//Convert a double to a string
printf(result dtoa   : %s\n, tmp);

l = strlen(tmp) + 4 + 1;

dst = calloc(l, sizeof(char*)); // initiatilise le character à NULL,
evite les caractéres byzarre dans se char
  
eina_strlcat(dst, tmp, l); // add tmp to dst
eina_strlcat(dst, s1, l); // add s1 to dst

printf(DST  = %s\n,dst);


eina_shutdown();

return EXIT_SUCCESS;
 }
-



the résult :
-
i...@issa-desktop:/media/Element/programmation/EFL/program/Convertion_Eina/bin$ 
./main 
initial value : 40.56
result dtoa   : 0x1.447ae147ae148p+5
DST  = 0x1.447ae147ae148p+5 Mo
-


So i think if i succes to make this here, i can make it on my function.

do u think i m on the good road or it's not the good solution ?



thanks



Le mardi 10 août 2010 à 10:43 +0200, Cedric BAIL a écrit :
 Hi,
 
 On Tue, Aug 10, 2010 at 10:20 AM, Issa frechdes...@gmail.com wrote:
  i have problem to use Eina convert function, i think im not understand
  how that's work.
  if someone can explain me please.
 
  so i have a function to make my convertion, but all the time the
  convertion failed, but i can't see why.
  maybe some on can explian what i m doing wrong, please ?
 
 eina_convert_dtoa and eina_convert_atod are only supposed to work
 together and be portable where ever you go. The string you are giving
 to eina_convert_atod should come from eina_convert_dtoa.
 



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina convert (string to Double) and (double to string)

[Cedric BAIL]

On Tue, Aug 10, 2010 at 11:22 AM, Issa frechdes...@gmail.com wrote:
 i have take the code exemple on the documentation and i m just trying to
 concatene a double to a string.
 i have this
 double val = 40.56;
  char *s1 =  Mo;

 and for the final i want this
 40.56 MO

This is not the result you will get with eina_convert something like
0x0.8p+0, that you could concatenate with Mo. Not really what you
are looking for I think :-)

Better just do a snprintf(buf, sizeof (buf), %f Mo, val); This will
do the job you are looking for I think.
-- 
Cedric BAIL

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina convert (string to Double) and (double to string)

[Issa]

hello,

thanks :)

the good for me :
just this !!
-
 #include stdlib.h
 #include stdio.h
 #include math.h

 #include Eina.h

 int main(void)
 {
char buf[32];
double n = 40.56;

sprintf(buf, %.2f MO, n);

printf(%s\n,buf);

return EXIT_SUCCESS;
 }
-

so i can't understand what is for the 
eina_convert_dtoa(val, tmp);//Convert a double to a string
and all convert function of eina ?


thanks






Le mardi 10 août 2010 à 11:40 +0200, Cedric BAIL a écrit :
 On Tue, Aug 10, 2010 at 11:22 AM, Issa frechdes...@gmail.com wrote:
  i have take the code exemple on the documentation and i m just trying to
  concatene a double to a string.
  i have this
  double val = 40.56;
   char *s1 =  Mo;
 
  and for the final i want this
  40.56 MO
 
 This is not the result you will get with eina_convert something like
 0x0.8p+0, that you could concatenate with Mo. Not really what you
 are looking for I think :-)
 
 Better just do a snprintf(buf, sizeof (buf), %f Mo, val); This will
 do the job you are looking for I think.



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina convert (string to Double) and (double to string)

[Cedric BAIL]

On Tue, Aug 10, 2010 at 11:54 AM, Issa frechdes...@gmail.com wrote:
 so i can't understand what is for the
 eina_convert_dtoa(val, tmp);//Convert a double to a string
 and all convert function of eina ?

itoa, xtoa are fast function to convert from int to number and hexa.
Usable for human representation, but mainly used when speed matter and
we need string to represent number.

dtoa, atod, fptoa and atofp are used to convert from a common string
representation to a double and fixed pointer representation. This give
us a portable way and easy to convert to different representation a
double or fixed point number. It's mainly used when you want to
transfert/store a number in a reliable way.
-- 
Cedric BAIL

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina mempool review and descriptions?

[Vincent Torri]

On Thu, 21 Jan 2010, Gustavo Sverzut Barbieri wrote:

 Hey all,

 I'm doing ebuilds for gentoo and I want to make them use configurable
 mempools, however the names are stupidly bad and I have no idea the
 use so I enable or disable them.

 could someone (ie: cedric) document what are these, how they are
 chosen, which should be really enabled and which could be left out
 since are experiments?

added in the mempool doc. Feel free to fix spelling and grammar :-)

Vncent

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina bechmarks broken against evas and ecore

[Vincent Torri]

On Thu, 21 Jan 2010, Gustavo Sverzut Barbieri wrote:

 title says it all, we don't have native evas and ecore data anymore,
 so benchmarks cannot work. Either we remove those for 1.0 or we copy
 the old files from svn history and have in src/tests.

tell me if it's good or not, now (i moved the old data to the test 
directory)

Vincent

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina mempool review and descriptions?

[Jorge Luis Zapata Muga]

On Fri, Jan 22, 2010 at 11:14 AM, Cedric BAIL moa.blueb...@gmail.com wrote:
 On Thu, Jan 21, 2010 at 11:13 PM, Gustavo Sverzut Barbieri
 barbi...@profusion.mobi wrote:
 I'm doing ebuilds for gentoo and I want to make them use configurable
 mempools, however the names are stupidly bad and I have no idea the
 use so I enable or disable them.

 could someone (ie: cedric) document what are these, how they are
 chosen, which should be really enabled and which could be left out
 since are experiments?

 So we have :
  * buddy: Last one, from turran, I will let him describe this one.


The buddy mempool uses the buddy allocator algorithm
(http://en.wikipedia.org/wiki/Buddy_memory_allocation ), but the
eina's implementation differs in the sense that the chunk information
is not stored on the chunk itself but on another memory area. This is
useful for cases where the memory to manage might be slower to access
or limited (like video memory)

  * chained_pool: The default one, basically do big malloc and split
 the result in chunk of the required size that are pushed inside a
 stack. Then when requested it take this pointer from the stack to give
 them to whoever whant them.

  * ememoa_fixed and ememoa_unknown: Are experimental allocator, could
 be usefull when you have a fixed amount of memory.

  * fixed_bitmap: This one, malloc 32 * the required size and push the
 pool pointer in a rbtree. To find empty space in a pool, it will just
 search for the first bit set in a int (32bits). And when a pointer is
 freed, it will do a search inside the rbtree.

  * pass_through: This one just call malloc and free. It may be faster
 on some computer than using our own allocator (typical case when you
 have huge L2 cache, over 4MB).

 Yeah, I know, better docs required and perhaps add some benchmark result too.
 --
 Cedric BAIL

 --
 Throughout its 18-year history, RSA Conference consistently attracts the
 world's best and brightest in the field, creating opportunities for Conference
 attendees to learn about information security's most important issues through
 interactions with peers, luminaries and emerging and established companies.
 http://p.sf.net/sfu/rsaconf-dev2dev
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina mempool review and descriptions?

[Cedric BAIL]

On Thu, Jan 21, 2010 at 11:13 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
 I'm doing ebuilds for gentoo and I want to make them use configurable
 mempools, however the names are stupidly bad and I have no idea the
 use so I enable or disable them.

 could someone (ie: cedric) document what are these, how they are
 chosen, which should be really enabled and which could be left out
 since are experiments?

So we have :
 * buddy: Last one, from turran, I will let him describe this one.

 * chained_pool: The default one, basically do big malloc and split
the result in chunk of the required size that are pushed inside a
stack. Then when requested it take this pointer from the stack to give
them to whoever whant them.

 * ememoa_fixed and ememoa_unknown: Are experimental allocator, could
be usefull when you have a fixed amount of memory.

 * fixed_bitmap: This one, malloc 32 * the required size and push the
pool pointer in a rbtree. To find empty space in a pool, it will just
search for the first bit set in a int (32bits). And when a pointer is
freed, it will do a search inside the rbtree.

 * pass_through: This one just call malloc and free. It may be faster
on some computer than using our own allocator (typical case when you
have huge L2 cache, over 4MB).

Yeah, I know, better docs required and perhaps add some benchmark result too.
-- 
Cedric BAIL

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina bechmarks broken against evas and ecore

[Cedric BAIL]

On Thu, Jan 21, 2010 at 11:28 PM, Vincent Torri vto...@univ-evry.fr wrote:
 On Thu, 21 Jan 2010, Gustavo Sverzut Barbieri wrote:
 title says it all, we don't have native evas and ecore data anymore,
 so benchmarks cannot work. Either we remove those for 1.0 or we copy
 the old files from svn history and have in src/tests.

 I like the second one.

Just put them inside eina/src/tests should be good. It will help catch
speed regression... When we start to do some :-)
-- 
Cedric BAIL

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina mempool review and descriptions?

[Vincent Torri]

On Fri, 22 Jan 2010, Cedric BAIL wrote:

 On Thu, Jan 21, 2010 at 11:13 PM, Gustavo Sverzut Barbieri
 barbi...@profusion.mobi wrote:
 I'm doing ebuilds for gentoo and I want to make them use configurable
 mempools, however the names are stupidly bad and I have no idea the
 use so I enable or disable them.

 could someone (ie: cedric) document what are these, how they are
 chosen, which should be really enabled and which could be left out
 since are experiments?

 So we have :
 * buddy: Last one, from turran, I will let him describe this one.

 * chained_pool: The default one, basically do big malloc and split
 the result in chunk of the required size that are pushed inside a
 stack. Then when requested it take this pointer from the stack to give
 them to whoever whant them.

 * ememoa_fixed and ememoa_unknown: Are experimental allocator, could
 be usefull when you have a fixed amount of memory.

 * fixed_bitmap: This one, malloc 32 * the required size and push the
 pool pointer in a rbtree. To find empty space in a pool, it will just
 search for the first bit set in a int (32bits). And when a pointer is
 freed, it will do a search inside the rbtree.

 * pass_through: This one just call malloc and free. It may be faster
 on some computer than using our own allocator (typical case when you
 have huge L2 cache, over 4MB).

 Yeah, I know, better docs required and perhaps add some benchmark result too.

I'll add those description in eina doxy doc this evening

Vincent

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina bechmarks broken against evas and ecore

[Gustavo Sverzut Barbieri]

On Fri, Jan 22, 2010 at 8:16 AM, Cedric BAIL cedric.b...@free.fr wrote:
 On Thu, Jan 21, 2010 at 11:28 PM, Vincent Torri vto...@univ-evry.fr wrote:
 On Thu, 21 Jan 2010, Gustavo Sverzut Barbieri wrote:
 title says it all, we don't have native evas and ecore data anymore,
 so benchmarks cannot work. Either we remove those for 1.0 or we copy
 the old files from svn history and have in src/tests.

 I like the second one.

 Just put them inside eina/src/tests should be good. It will help catch
 speed regression... When we start to do some :-)

Could you do this anytime soon?

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina bechmarks broken against evas and ecore

[Vincent Torri]

On Thu, 21 Jan 2010, Gustavo Sverzut Barbieri wrote:

 title says it all, we don't have native evas and ecore data anymore,
 so benchmarks cannot work. Either we remove those for 1.0 or we copy
 the old files from svn history and have in src/tests.

I like the second one.

Vincent

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina Iterator question

[Gustavo Sverzut Barbieri]

On Fri, Dec 4, 2009 at 10:03 PM, Andreas Volz li...@brachttal.net wrote:
 Hello,

 could one tell me why there's no eina_iterator_prev() function like
 eina_iterator_next()?

because iterators are unidrectional run-once things. It's an
abstraction for foreach in C.

If you want a reverse, you return another iterator... see list and others.

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina API inconssitency

[Gustavo Sverzut Barbieri]

On Thu, Nov 12, 2009 at 9:14 AM, Vincent Torri vto...@univ-evry.fr wrote:

 Hey,

 eina_mempool_add is not a correct name : it does not add to something a
 mempool.

 The problem is that if we change the name to eina_mempool_new, the delete
 function should be named eina_mempool_free. And there is already a
 eina_mempool_free in eina_inline_mempool.x

 cedric wants to keep the API like that. His arguments are that the code
 would be less easier to read, and anyway, we add a mempool.

 i would like to rename eina_mempool_free to eina_mempool_poll_free
 (actually, adding pool_ to the 3 functions in eina_inline_mempool.x

 So i would like the opinion of other devs :)

I like your proposal, all the time I have to go to that code I get confused :-P

-- 
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 stringshare thread safe

[Atton Jonathan]

I have attached the patch.

With the help of Cedric I have made this patch.

2 mutexs are used, one for the strings with a size  4 and one for the
others.
2 macros has been updated to add the possibility to unlock a mutex if
necessary.
In this version the mutexs are activated if eina is installed with the
pthread support ( I use the same code than eina_log ). If you wish I can add
a function to manually active the mutexs.

The patch is simple, this was not a big job to do. Helgrind reports no
errors with my application and I use a lot of eina stringshare + threads
(without the patch my application segv after eina reports some invalids use
of eina stringshare). Of course I do not use all the combinations of calls.
E17 works too.


2009/10/26 Cedric BAIL cedric.b...@free.fr

 On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan
 jonathan.at...@gmail.com wrote:
  actually all eina should be thread safe. Maybe eet and ecore too. If you
 are
  not against this I will start to work on eina.

 Actually, I think we should do this really carefully. I think we
 should make stringshare thread safe, because their is no way from an
 user API point of view to use them without messing everything from
 another thread.

 So i agree we will need something like 'int
 eina_thread_safe_init(void)' and 'int
 eina_thread_safe_shutdown(void)', that track the number of time an
 user need to be safe and set one global flag that activate some mutex
 for stringshare. But I don't want to see eina_list or eina_hash, add
 some pthread lock just because the user can't do it by itself. And in
 most case, he will be able to do it much more efficiently than we
 could in eina.

  2009/10/25 Gustavo Sverzut Barbieri barbi...@profusion.mobi
  On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
  jonathan.at...@gmail.com wrote:
   hey,
  
   I talked a week  ago with cedric about making eina stringshare thread
  safe.
  
   The mutex could be activated/deactivated with a classic function and
 then
  2
   macros will be use:
  
   LOCK : if(mutex_activated) pthread_mutex_lock()
   UNLOCK : if(mutex_activated) pthread_mutex_unlock()
  
   By default the mutex can be deactivated and the developer activate it
 if
   necessary.
  
   What do you think about this idea ?
 
  The only problem with this is inconsistency. Okay, we have stringshare
  as this, but still default mempool is not so you cannot allocate list
  nodes... then you cannot add ecore idlers/timers/pollers/... from
  threads, and so on. Inconsistency is bad :-(

 The default mempool is thread safe. Definitivly, it should work safely
 if you build eina with pthread support. If not, it's a bug that should
 be fixed. For ecore, this is another matter, right now, by design we
 don't want to

  I really don't see any clear solution to this problem. Maybe we could
  have something like glib's threads init. I have this for logging,
  but i was really reluctant to add it. But if so, then we must make
  sure all types would be thread safe.

 So maybe when thread safe is required do the same trick for eina_log to.
 --
 Cedric BAIL




-- 
Regards.
Index: src/lib/eina_stringshare.c
===
--- src/lib/eina_stringshare.c  (revision 43297)
+++ src/lib/eina_stringshare.c  (working copy)
@@ -100,19 +100,23 @@
 static const char EINA_MAGIC_STRINGSHARE_NODE_STR[] = Eina Stringshare Node;
 
 
-#define EINA_MAGIC_CHECK_STRINGSHARE_HEAD(d, ...)  \
+#define EINA_MAGIC_CHECK_STRINGSHARE_HEAD(d, unlock, ...)  \
   do { \
 if (!EINA_MAGIC_CHECK((d), EINA_MAGIC_STRINGSHARE_HEAD))   \
 {  \
 EINA_MAGIC_FAIL((d), EINA_MAGIC_STRINGSHARE_HEAD); \
+unlock;\
 return __VA_ARGS__;\
 }  \
   } while (0);
 
-#define EINA_MAGIC_CHECK_STRINGSHARE_NODE(d)   \
+#define EINA_MAGIC_CHECK_STRINGSHARE_NODE(d, unlock)   \
   do { \
 if (!EINA_MAGIC_CHECK((d), EINA_MAGIC_STRINGSHARE_NODE))   \
+{  \
+  unlock;  \
   EINA_MAGIC_FAIL((d), EINA_MAGIC_STRINGSHARE_NODE);   \
+}  \
   } while (0);
 
 typedef struct _Eina_Stringshare Eina_Stringshare;
@@ -170,6 +174,48 @@
 #endif
 #define DBG(...) EINA_LOG_DOM_DBG(_eina_stringshare_log_dom, __VA_ARGS__)
 
+
+
+#ifdef EFL_HAVE_PTHREAD
+#include pthread.h
+static Eina_Bool _threads_enabled = EINA_FALSE;
+static pthread_t _main_thread;
+
+#define IS_MAIN(t)  pthread_equal(t, _main_thread)
+#define IS_OTHER(t) EINA_UNLIKELY(!IS_MAIN(t))
+#define 

Re: [E-devel] Eina Patch

[Christopher Michael]

Resend of improved patch for this.
Fixes pattern matching and does not remove/free the expression.

Thanks k-s :)

dh

Christopher Michael wrote:
Attached is a patch to allow disabling of all eina messages which are 
printed out via eina_log.


This is useful when developing applications which use eina_log so that 
you can actually see your own applications messages by silencing eina.


Typical use case would be:
EINA_LOG_LEVELS_GLOB=eina_*:0 ./myapp

Not sure if this is entirely correct as I am no eina expert so review is 
appreciated.


dh
Index: eina_log.c
===
--- eina_log.c  (revision 43323)
+++ eina_log.c  (working copy)
@@ -273,6 +273,7 @@
 #include stdio.h
 #include string.h
 #include stdlib.h
+#include fnmatch.h
 
 #ifdef HAVE_EVIL
 # include Evil.h
@@ -305,6 +306,7 @@
 #define EINA_LOG_ENV_ABORT EINA_LOG_ABORT
 #define EINA_LOG_ENV_LEVEL EINA_LOG_LEVEL
 #define EINA_LOG_ENV_LEVELS EINA_LOG_LEVELS
+#define EINA_LOG_ENV_LEVELS_GLOB EINA_LOG_LEVELS_GLOB
 #define EINA_LOG_ENV_COLOR_DISABLE EINA_LOG_COLOR_DISABLE
 #define EINA_LOG_ENV_FILE_DISABLE EINA_LOG_FILE_DISABLE
 #define EINA_LOG_ENV_FUNCTION_DISABLE EINA_LOG_FUNCTION_DISABLE
@@ -325,6 +327,7 @@
  * updates the domain levels on the first log and clears itself.
  */
 static Eina_Inlist *_pending_list = NULL;
+static Eina_Inlist *_glob_list = NULL;
 
 // Disable color flag (can be changed through the env var
 // EINA_LOG_ENV_COLOR_DISABLE).
@@ -793,6 +796,44 @@
  }
 }
 
+static void
+eina_log_domain_parse_pending_globs(void)
+{
+   const char *start;
+
+   if (!(start = getenv(EINA_LOG_ENV_LEVELS_GLOB))) return;
+
+   // name1:level1,name2:level2,name3:level3,...
+   while (1)
+ {
+   Eina_Log_Domain_Level_Pending *p;
+   char *end = NULL;
+   char *tmp = NULL;
+   long int level;
+
+   end = strchr(start, ':');
+   if (!end) break;
+
+   // Parse level, keep going if failed
+   level = strtol((char *)(end + 1), tmp, 10);
+   if (tmp == (end + 1)) goto parse_end;
+
+   // Parse name
+   p = malloc(sizeof(Eina_Log_Domain_Level_Pending) + end - start + 1);
+   if (!p) break;
+   memcpy((char *)p-name, start, end - start);
+   ((char *)p-name)[end - start] = '\0';
+   p-level = level;
+
+   _glob_list = eina_inlist_append(_glob_list, EINA_INLIST_GET(p));
+
+   parse_end:
+   start = strchr(tmp, ',');
+   if (start) start++;
+   else break;
+ }
+}
+
 /**
  * @endcond
  */
@@ -937,6 +978,9 @@
return EINA_FALSE;
  }
 
+   // Parse pending domains passed through EINA_LOG_LEVELS_GLOB
+   eina_log_domain_parse_pending_globs();
+
// Parse pending domains passed through EINA_LOG_LEVELS
eina_log_domain_parse_pendings();
 
@@ -978,6 +1022,13 @@
_log_domains_count = 0;
_log_domains_allocated = 0;
 
+   while (_glob_list) 
+ {
+tmp = _glob_list;
+_glob_list = _glob_list-next;
+free(tmp);
+ }
+
while (_pending_list)
  {
tmp = _pending_list;
@@ -1099,6 +1150,15 @@
_log_domains_count++;
 
 finish_register:
+   EINA_INLIST_FOREACH(_glob_list, pending) 
+ {
+if (!fnmatch(pending-name, name, 0)) 
+  {
+ _log_domains[i].level = pending-level;
+ break;
+  }
+ }
+
EINA_INLIST_FOREACH(_pending_list, pending)
  {
if (!strcmp(pending-name, name))
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina stringshare thread safe

[Atton Jonathan]

A new version of the patch wit eina_threads_init() and
eina_threads_shutdown(). maybe we can add a call to these functions in
ecore_thread_run () ?

2009/10/28 Atton Jonathan jonathan.at...@gmail.com


 I have attached the patch.

 With the help of Cedric I have made this patch.

 2 mutexs are used, one for the strings with a size  4 and one for the
 others.
 2 macros has been updated to add the possibility to unlock a mutex if
 necessary.
 In this version the mutexs are activated if eina is installed with the
 pthread support ( I use the same code than eina_log ). If you wish I can add
 a function to manually active the mutexs.

 The patch is simple, this was not a big job to do. Helgrind reports no
 errors with my application and I use a lot of eina stringshare + threads
 (without the patch my application segv after eina reports some invalids use
 of eina stringshare). Of course I do not use all the combinations of calls.
 E17 works too.


 2009/10/26 Cedric BAIL cedric.b...@free.fr

 On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan
 jonathan.at...@gmail.com wrote:
  actually all eina should be thread safe. Maybe eet and ecore too. If you
 are
  not against this I will start to work on eina.

 Actually, I think we should do this really carefully. I think we
 should make stringshare thread safe, because their is no way from an
 user API point of view to use them without messing everything from
 another thread.

 So i agree we will need something like 'int
 eina_thread_safe_init(void)' and 'int
 eina_thread_safe_shutdown(void)', that track the number of time an
 user need to be safe and set one global flag that activate some mutex
 for stringshare. But I don't want to see eina_list or eina_hash, add
 some pthread lock just because the user can't do it by itself. And in
 most case, he will be able to do it much more efficiently than we
 could in eina.

  2009/10/25 Gustavo Sverzut Barbieri barbi...@profusion.mobi
  On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
  jonathan.at...@gmail.com wrote:
   hey,
  
   I talked a week  ago with cedric about making eina stringshare thread
  safe.
  
   The mutex could be activated/deactivated with a classic function and
 then
  2
   macros will be use:
  
   LOCK : if(mutex_activated) pthread_mutex_lock()
   UNLOCK : if(mutex_activated) pthread_mutex_unlock()
  
   By default the mutex can be deactivated and the developer activate it
 if
   necessary.
  
   What do you think about this idea ?
 
  The only problem with this is inconsistency. Okay, we have stringshare
  as this, but still default mempool is not so you cannot allocate list
  nodes... then you cannot add ecore idlers/timers/pollers/... from
  threads, and so on. Inconsistency is bad :-(

 The default mempool is thread safe. Definitivly, it should work safely
 if you build eina with pthread support. If not, it's a bug that should
 be fixed. For ecore, this is another matter, right now, by design we
 don't want to

  I really don't see any clear solution to this problem. Maybe we could
  have something like glib's threads init. I have this for logging,
  but i was really reluctant to add it. But if so, then we must make
  sure all types would be thread safe.

 So maybe when thread safe is required do the same trick for eina_log to.
 --
 Cedric BAIL




 --
 Regards.




-- 
Regards.
Index: src/include/eina_private.h
===
--- src/include/eina_private.h  (revision 43297)
+++ src/include/eina_private.h  (working copy)
@@ -116,5 +116,10 @@
  } \
   } while(0);
 
+#ifdef EFL_HAVE_PTHREAD
+void eina_stringshare_threads_init(void);
+void eina_stringshare_threads_shutdown(void);
+#endif
+
 #endif /* EINA_PRIVATE_H_ */
 
Index: src/include/eina_main.h
===
--- src/include/eina_main.h (revision 43297)
+++ src/include/eina_main.h (working copy)
@@ -35,6 +35,10 @@
 
 EAPI int eina_shutdown(void);
 
+EAPI int eina_threads_init(void);
+
+EAPI int eina_threads_shutdown(void);
+
 /**
  * @}
  */
Index: src/lib/eina_log.c
===
--- src/lib/eina_log.c  (revision 43297)
+++ src/lib/eina_log.c  (working copy)
@@ -1391,3 +1391,4 @@
eina_log_print_unlocked(domain, level, file, fnc, line, fmt, args);
UNLOCK();
 }
+
Index: src/lib/eina_main.c
===
--- src/lib/eina_main.c (revision 43297)
+++ src/lib/eina_main.c (working copy)
@@ -48,6 +48,7 @@
  */
 
 static int _eina_main_count = 0;
+static int _eina_main_thread_count = 0;
 static int _eina_log_dom = -1;
 
 #ifdef ERR
@@ -60,6 +61,16 @@
 #endif
 #define DBG(...) EINA_LOG_DOM_DBG(_eina_log_dom, __VA_ARGS__)
 
+#ifdef EFL_HAVE_PTHREAD
+#include pthread.h
+static Eina_Bool _threads_activated = EINA_FALSE;
+static pthread_mutex_t _mutex = PTHREAD_MUTEX_INITIALIZER;

Re: [E-devel] eina stringshare thread safe

[Atton Jonathan]

actually all eina should be thread safe. Maybe eet and ecore too. If you are
not against this I will start to work on eina.

2009/10/25 Gustavo Sverzut Barbieri barbi...@profusion.mobi

 On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
 jonathan.at...@gmail.com wrote:
  hey,
 
  I talked a week  ago with cedric about making eina stringshare thread
 safe.
 
  The mutex could be activated/deactivated with a classic function and then
 2
  macros will be use:
 
  LOCK : if(mutex_activated) pthread_mutex_lock()
  UNLOCK : if(mutex_activated) pthread_mutex_unlock()
 
  By default the mutex can be deactivated and the developer activate it if
  necessary.
 
  What do you think about this idea ?

 The only problem with this is inconsistency. Okay, we have stringshare
 as this, but still default mempool is not so you cannot allocate list
 nodes... then you cannot add ecore idlers/timers/pollers/... from
 threads, and so on. Inconsistency is bad :-(

 I really don't see any clear solution to this problem. Maybe we could
 have something like glib's threads init. I have this for logging,
 but i was really reluctant to add it. But if so, then we must make
 sure all types would be thread safe.

 BR,

 --
 Gustavo Sverzut Barbieri
 http://profusion.mobi embedded systems
 --
 MSN: barbi...@gmail.com
 Skype: gsbarbieri
 Mobile: +55 (19) 9225-2202




-- 
Regards.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina stringshare thread safe

[Cedric BAIL]

On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan
jonathan.at...@gmail.com wrote:
 actually all eina should be thread safe. Maybe eet and ecore too. If you are
 not against this I will start to work on eina.

Actually, I think we should do this really carefully. I think we
should make stringshare thread safe, because their is no way from an
user API point of view to use them without messing everything from
another thread.

So i agree we will need something like 'int
eina_thread_safe_init(void)' and 'int
eina_thread_safe_shutdown(void)', that track the number of time an
user need to be safe and set one global flag that activate some mutex
for stringshare. But I don't want to see eina_list or eina_hash, add
some pthread lock just because the user can't do it by itself. And in
most case, he will be able to do it much more efficiently than we
could in eina.

 2009/10/25 Gustavo Sverzut Barbieri barbi...@profusion.mobi
 On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
 jonathan.at...@gmail.com wrote:
  hey,
 
  I talked a week  ago with cedric about making eina stringshare thread
 safe.
 
  The mutex could be activated/deactivated with a classic function and then
 2
  macros will be use:
 
  LOCK : if(mutex_activated) pthread_mutex_lock()
  UNLOCK : if(mutex_activated) pthread_mutex_unlock()
 
  By default the mutex can be deactivated and the developer activate it if
  necessary.
 
  What do you think about this idea ?

 The only problem with this is inconsistency. Okay, we have stringshare
 as this, but still default mempool is not so you cannot allocate list
 nodes... then you cannot add ecore idlers/timers/pollers/... from
 threads, and so on. Inconsistency is bad :-(

The default mempool is thread safe. Definitivly, it should work safely
if you build eina with pthread support. If not, it's a bug that should
be fixed. For ecore, this is another matter, right now, by design we
don't want to

 I really don't see any clear solution to this problem. Maybe we could
 have something like glib's threads init. I have this for logging,
 but i was really reluctant to add it. But if so, then we must make
 sure all types would be thread safe.

So maybe when thread safe is required do the same trick for eina_log to.
-- 
Cedric BAIL

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina stringshare thread safe

[Gustavo Sverzut Barbieri]

On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan
jonathan.at...@gmail.com wrote:
 hey,

 I talked a week  ago with cedric about making eina stringshare thread safe.

 The mutex could be activated/deactivated with a classic function and then 2
 macros will be use:

 LOCK : if(mutex_activated) pthread_mutex_lock()
 UNLOCK : if(mutex_activated) pthread_mutex_unlock()

 By default the mutex can be deactivated and the developer activate it if
 necessary.

 What do you think about this idea ?

The only problem with this is inconsistency. Okay, we have stringshare
as this, but still default mempool is not so you cannot allocate list
nodes... then you cannot add ecore idlers/timers/pollers/... from
threads, and so on. Inconsistency is bad :-(

I really don't see any clear solution to this problem. Maybe we could
have something like glib's threads init. I have this for logging,
but i was really reluctant to add it. But if so, then we must make
sure all types would be thread safe.

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel