(udev registered it as fake)... and in the process i found that we
probably double free as sensor is calloced in the module and AGAIN in
eeze sensor core... oh and symbols probably might lak from modules..
so static them up yo.
Because of the way eo is dispatching method calls of objects the usual
error log you get if you mix up objects or try to call non-existent
methods is:
ERR<12404>:eo lib/eo/eo.c:362 _eo_dov_internal() Can't find func for op
0x24 (ecore_audio_obj_in:ECORE_AUDIO_OBJ_IN_SUB_ID_SPEED_GET) for class
'ecore_audio_obj_out_pulse'. Aborting.
Of course the problem is not really in lib/eo/eo.c, but in the function
calling eo_do()
Now the macros pass source file and line number on to the _internal
functions so we can log where the error originally happened:
ERR<1938>:eo lib/eo/eo.c:362 _eo_dov_internal() in
lib/ecore_audio/ecore_audio_obj_out_pulse.c:119: Can't find func for op
0x24 (ecore_audio_obj_in:ECORE_AUDIO_OBJ_IN_SUB_ID_SPEED_GET) for class
'ecore_audio_obj_out_pulse'. Aborting.
This makes debugging with eo a lot easier.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
Eina value type does not support pointer so I used int as of now.
This needs to be converted into hexa later.
By using Clouseau, one can see this Clipper information.
- re-enabling split BiDi cursor tests, disabled in 0d68ffbe;
ligatures tests are still disabled;
- change "fail_if" to "ck_assert_int_*",
because it prints error message with values;
- fixing usage of embedding LTR/RTL codes in tests;
Signed-off-by: Yakov Goldberg <yakov.g@samsung.com>
Switch from absolut microseconds since epoch to a monotonic clock with
realtive values. Switch from unsigned long long to double.
This aligns it with how we present time in efl. ecore_time_get is used
when possible. For the tizen modules we convert the the epoch timestamp
we get into a double. This is still a working monotone clock source.
As this will be released the first time with 1.8 we don't have any API
break here.
If you install the efl to a different path than the one gdb was installed to
either set gdb's data dir, or just symlink the file to the other prefix.
You can still use the old method of just loading the module.
Together with eeze_sensor_module_register/unregister these are the functions
that are irrelevant for developer when they just want to use the eeze_sensor
API.
Still all three need to be marked with EAPI as they are used in the backend
modules and due to our visibility hidden usage the module loading would fail
if we remove EAPI from them.
Moving them into the private header should give an indication that these are
not meant for pure API users.
These functions let you pass an array of callbacks instead of just one.
It's more memory efficient to use this if you just add a bulk of events
on the same object.
This commits breaks ABI, and breaks API of the EO_EV_CALLBACK_ADD/DEL
signals (the event info passed).