- User Since
- Aug 24 2015, 1:00 PM (164 w, 1 d)
Thu, Oct 11
Thu, Oct 4
Update removing the comment. Somehow I forgot it when splitting the patches.
Wed, Oct 3
I've rebased the current new API work on top of yesterday (Oct 3rd) master (still in devs/lauromoura/csharp-new-classes) and it compiled without requiring any changes to the Eo files. All tests pass and a quick test showed at least elm examples are working. The generator new code requires some cleanup before pushing, though.
Update with SetIcon change from D7133
Will merge this change into D134, as it already fixes the example build system.
Thu, Sep 27
About hiding them from the tree, these are the methods either returning (->) or receiving as a parameter (between ()) a Mixin type.
Tue, Sep 25
Sep 13 2018
The Mono compiler already extracts the documentation from the generated code (eolian_mono adds them as C# comments) into a XML file that VS/MonoDevelop use. Maybe we could just add a script to transform the generated XML into the DokuWiki syntax.
Sep 12 2018
I've pushed the current code to devs/lauromoura/csharp-new-classes.
Sep 11 2018
This @ctor_param would behave just like a hint, right? So each language decides whether it should support them as explicit constructor parameters (C#) or keep it implicit through efl_added (C/C++).
Sep 10 2018
Sep 5 2018
Marked as resolved. Somehow phab didn't close it after pushing.
Sep 4 2018
Sep 3 2018
Aug 31 2018
With help of pyolian, I could find these instances where we have abstract classes inheriting from regular classes somewhere in their inheritance chain:
(Somehow I removed myself as the assignee...)
The problem seems to be eina.Value using malloc/free internally to create/delete Eina_Values while it should use eina_value_new/eina_value_free to alloc/free from the Value mempool.
Aug 30 2018
Aug 24 2018
Aug 21 2018
Another alternative would be hiding the init into the constructors/class methods, initializing the libraries lazily, at the cost of a bool check on each call for these functions.
Update with more descriptive message
Aug 20 2018
Aug 6 2018
More info: This happens as the C# wrappers are kept alive by the GC and actually deleted only after the call to efl.All.Shutdown().
Jul 23 2018
Could you check my branch devs/lauromoura/fix-csharp-life on the examples repo?
Jul 17 2018
Do you mean generated classes? The "concrete" ones are indeed sealed as they shouldn't be inherited from. For this use the classes with the Inherit suffix (e.g. efl.ui.ButtonInherit).
Jul 15 2018
Looks like we found where the value changes:
Jul 13 2018
Jul 12 2018
Just a clarification: The aforementioned commit does not actually introduce this bug, only reveals it through the efl.Loop_Timer instantiation. This may happen to other native calls from the binding.
Jun 29 2018
Mixed up revisions?
Jun 28 2018
Worked fine here, both with and without realpath.
Jun 26 2018
Jun 25 2018
Removed the call to dbus-session and it didn't seem to affect anything other than the kill errors.
Jun 21 2018
Jun 15 2018
It seems dbus-launch invocation is different from dbus-run-session and can't be used as a drop-in replacement. dbus-launch will start a new bus session and give the code to set the DBUS_SESSION_* variables to this new bus, while 'dbus-run-sesssion' takes a command and runs it on a new shell.
Jun 12 2018
May 23 2018
May 18 2018
May 17 2018
May 16 2018
May 11 2018
May 4 2018
This seems to have been fixed with ec59f8053a9a7ee7ff848a1bab1d0d980d914bc3, right?
May 3 2018
Update after Vitor explained better how these traits should behave.