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).
This has been bugging me for some time but now we are triggering new errors internally
this is appearing to end users for problems they did not cause.
Additionally I was able to improve a couple of the errors by copying the
explanation from code comments into the error message.
Shorter error logs now too :)
efl.loop was still using legacy ecore_timer_* calls inside. of course
this is a big no-no if we are to allow multiple loops, so clean this
up and convert them to efl.loop.timers.
This commit adds the "documentation" generator, which gets the
documentation_def attribute of the given item and generates xml comments
to be exported by MCS.
For items requiring some customization of the generated comments (e.g.
functions and its parameters), the helpers to generate the preamble
(summary), body (paragraphs) and epilogue (currently just the @since
tag) were added.
Currently we do not support converting Eolian references into xmldoc
references.
As we explicitly generate Get/Set methods for properties, for now the
generator tries to get the get/set specific documentation first. If it
is not present, fallback to the common docs.
Later this could be changed to generate the common one as paragraphs of
the Get/Set.
Also some generated code like the wrappers for calling C# methods
from C can be private. This will cleanup the introspection results
and warnings when generating documentation.
Due to this visibility change, the binbuf tests had to be changed
to add redirect calls to the native methods instead of directly
calling the DllImport'd methods.
Fixes a bug introduce with c8c4572d70.
My guess is that the true intention was to query the Efl.File mixin
first, and the check the specific load_error.
Basically a call to 'efl_file_load_error_get' on an
Efl.Canvas.Image triggered this.
use real constnants and remove useless vasriables as well as fix up
formatting... so we don't get compilers complaining about non-const
values etc.
@fix
what i'm seeing is this with local unix sockets:
1. server process not cleanly shut down (kill -9 for example).
2. run server process again and bind fails due to EADDRINUSE
3. we ARE doing setsockopt() with SO_REUSEADDR set to 1 ...
this just makes no sense because setsockopt() SHOULD allow use to
re-use... the previous efreetd process for example is gone. no such
process, yet socket is not re-usable. this should just not happen due
to SO_REUSEADDR, but it does. this has nasty consequences like efreetd
maybe never running because of stale sockets. this should never have
happened, but it does. odd. so a hacky workaround:
1. try bind.
2. if bind fails with EADDRINUSE and its a socket path AND
pd->unlink_before_bind is NOT set... then try a connect to the socket.
3. if connect succeeds then fail as normal (close socket and error on
bind'ing)
if connect fails then we have a stale socket, so unlink it
forcibly. create the socket again and try bind again.
hacky but... fixes the core issue.
@fix
Davide Andreoli
Andy Williams
Jean Guyomarc'h
Carsten Haitzler
Daniel Kolesa
Amitesh Singh
Marcel Hollerbach
Felipe Magno de Almeida
Lauro Moura
Daniel Hirt
Jihoon Kim