This reverts commit f910ba248e.
The scheduler is meant to be used only in C, not by bindings so there isn't really
a use for it in the loop class. Now this patch was triggered due to complexity in
using future/promise, so will do a follow up patch to improve that.
This is (in my mind) meant to replace the current elua generator.
Currently the generated output is pratically identical to the elua
one, just some little difference here and there, some for thecnical
reasons and some just for my preference.
I consider this work just a starting point, extending the
templates we can now easily improve our docs. Whithout the need
to touch a single line of code.
Really I think this is a great improvements, and this are some
numbers to prove it:
Current elua implementation:
4185 lines of code in 7 lua files
generation time: ~ 7 seconds
New generator:
115 lines of python + 513 lines of templates
generation time: ~ 8 seconds (can be optimizd ALOT)
To generate the full Efl.* docs just run "./gendoc.py -v" in this folder.
...will wait for reviews (in particular from @andy and @q66)
elsewhere in efl we moved to pthread_sigmask but eina debug didn't, so
mirror the changes here too. at this point in time when we are
initting eina debug this shouldnt really matter much as we're single
threaded until this pthread_Create is called. after that tough...
we're not. signals + threads is a nightmare though... horrible
horrible...
../src/benchmarks/eina/eina_bench_sort.c: In function ‘eina_bench_sort_eina’:
../src/benchmarks/eina/eina_bench_sort.c:52:10: warning: implicit declaration of function ‘time’ [-Wimplicit-function-declaration]
srand(time(NULL));
Found due to the nice quite build output in our meson feature branch.
This is a really powerfull tool that can be used to generate anything eolian
releted just providing a template file. You can then render the template
with the wanted scope (class, namespace, enum, etc)
For example give a try at this (from the src/srcipts/pyolian folder):
./generator.py test_gen_class.template --cls Efl.Loop.Timer
or ./generator.py -h for the full help
Next step: maybe generate the new efl API doc using this tool?
@andy I think this will make your life much easier :)
This are manually written ctype bindings for eolian, that means they
run on the standard python library (nothing to install) and can run
without any build step (in fact ctypes just open the so/dll file at runtime)
Next step will be (soon) a template based generator for eolian that will
be a lot of fun :)
also eina_procmis was not threadsafe so cannto use loops in different
threads at all until this was made safe. needed to disable the old
ecore_event using code in for ecore futures and create a new efl loop
message future and handler instead ... but now a quick experiment with
multiple loops in 10 threads plus mainloop have timers at least work.
i need to test more like fd handlers etc etc. but it's a step.
stop using the legacy ecore_loop_time_get() func when it should be
coming from the loop object's loop time. also ecore_time_get should
never fall back on ecore_loop_time_get for similar reasons.
part of making the ecore/efl loop a non-global instance (allow loops
in threads)
so loop object destruction was clearing out fd handlers but those may
be later deleted by destructors of child objects. so leave legacy
fdh's and just remove them from the list
This makes sure that duplicate method/part/etc checks are done on
every database update, removing the need for clunky toplevel
checks and improving reliability. It also sacrifices some
performance but it shouldn't be too bad (if a class is already
validated, some checks are avoided to speed things up).
Stefan Schmidt
Mike Blumenkrantz
Cedric BAIL
Davide Andreoli
Andy Williams
Carsten Haitzler
Marcel Hollerbach
Xavi Artigas
Amitesh Singh
Jean Guyomarc'h
Daniel Kolesa