basic data types
Fri, Nov 1
Oct 17 2019
Oct 16 2019
Other implementation of hash usually use for their second layer a list and trigger a resize of the first array when this list start to be to big. This affect performance in visible step. Basically the current shape of our eina hash allow us to dump whatever we want even with bad hash and not have bad performance. Alternative solution like list/array for second and third layer do not have those property and may show some form of shortcoming.
It make the hash resistant to attack like the one that hit GTK, Qt and a lot of other toolkit in the past. There mitigation technic was to had a random salt to the way they generate there hash function, but this means that every run of the binary give a different result which is, I find, annoying. Our rb-tree are zero alloc, do not have the bad side effect of list (on long walk) or array (on remove). You would have to make a very good argument to replace them by an array, which I don't see here.
Oct 10 2019
Oct 9 2019
we can also increase _XOPEN_SOURCE to 700 (http://man7.org/linux/man-pages/man7/feature_test_macros.7.html)
otoh : https://lists.gnu.org/archive/html/autoconf/2010-08/msg00045.html it seems that we should not use __USE_UNIX98
@raster btw, eina_inline_posix_lock.x does:
@raster i've asked the user to export it to CPPFLAGS and issue vanished of course. I will provide a diff
eina headers have to solve this because eina_inline_lock_posix.x has the implementation and it needs to #define enough to ensure the headers it has other 3rd part apps use have everything working. so:
@bu5hm4n i would say in eina as a user should not do extra work. Eina is using some features, it should enable them, imho.
Well, my eina.pc contains -pthread and I have the same issue/errors.
This needs some solving in either your app or eina, but not in meson. eina.pc should not force you to -D_POSIX_C_SOURCE i guess. autotools also never did that.
Oct 4 2019
Sep 26 2019
I think I did implement it and @lauromoura improved the error message.
we are not ready for this class yet but it seems we need this factory for supporting multi-style item yet without factory customize?
add tag mvvm for issue tracking
are we have any stuff regarding this?
are we need efl-1.23 tagging still in here?
Sep 24 2019
Yes, it is.
Sep 23 2019
The issue was that it was unreliable iirc
Disabled in 272f32ee9f867ab852449bcd1c38f05dc9692fc9, revert works cleanly, local test run worked, running travis here now: https://travis-ci.org/Enlightenment/efl/builds/588465526
Sep 20 2019
Yes we disabled it.
Can you elaborate how this is to be reproduced ? I cannot ... (have we disabled some test and i do not remember it anymore) ?
Sep 15 2019
Sep 13 2019
Always good to have another set of eyes!