Oh and I forgot, those changes add ~60 warnings in EFL with clang:
CC lib/evas/canvas/lib_evas_libevas_la-evas_object_line.lo
/home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c:101:5:
warning: expression result unused [-Wunused-value]
((Eo *) ( *&eo_obj =
_eo_add_internal_start("/home/jpeg/e/core/efl/src/lib/evas/canvas/evas_object_line.c",
101, evas_line_class_get(), e, ((Eina_Bool)0)), *&eo_obj =
_eo_add_end(*&eo_obj) ));
On 10 March 2016 at 15:46, Jean-Philippe André <[email protected]> wrote:
>
>
> On 10 March 2016 at 15:05, Carsten Haitzler <[email protected]> wrote:
>
>> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui <[email protected]>
>> said:
>>
>> > On Wed, 09 Mar 2016 16:23:04 +0000
>> > Tom Hacohen <[email protected]> wrote:
>> >
>> > > On 03/03/16 10:22, Tom Hacohen wrote:
>> > > > On 01/03/16 09:05, Tom Hacohen wrote:
>> > > >> Hey,
>> > > >>
>> > > >> The Eo syntax is going to be changing once more, and this time, I
>> > > >> really think/hope it'll be the last time. We plan on stabilizing
>> > > >> Eo and all of the functions on top of it in the next few months,
>> > > >> so that doesn't leave us much more time to change it again. :)
>> > > >>
>> > > >> These changes will remove the need for the eo_do family of
>> > > >> functions. Functions will now look like normal C functions (which
>> > > >> they are). There are many benefits to that, and we have many cool
>> > > >> new ideas.
>> > > >>
>> > > >> For more info: https://phab.enlightenment.org/w/eo/
>> > > >>
>> > > >> I'm sending this email as an head's up, as I'll be starting to
>> > > >> work on migrating to the new Eo syntax (and implementing it)
>> > > >> today. Felipe and I have actually already started (needed to for
>> > > >> the PoC), but I plan on pushing my changes to master soon.
>> > > >>
>> > > >> If you have any issues/suggestions/comments with the proposal,
>> > > >> please let me know, either in pm, irc or just here.
>> > > >>
>> > > >
>> > > > Changes are in! I still haven't migrated eo_add to the new syntax
>> > > > (it uses a non portable gcc extension in the meanwhile), but
>> > > > otherwise everything is in. Took me *much* less time than I thought
>> > > > it would, so yay. :P
>> > > >
>> > > > I decided to push it now instead of letting it rest in my branch
>> > > > for a while because literally every hour that passed introduced
>> > > > more merge conflicts for me, so the benefits from stabilising it
>> > > > more in my branch were diminished by the new conflicts and issues
>> > > > that could arise.
>> > > >
>> > > > If you have an application that uses the Eo api, you can use my
>> > > > script https://devs.enlightenment.org/~tasn/migrate_eo.py to
>> > > > migrate your code. When using the script you should keep two things
>> > > > in mind: 1. You are only allowed to run it *once* per source code,
>> > > > because the changes to eo_add() would otherwise accumulate and your
>> > > > code will be wrong. If you need to correct something you've done
>> > > > wrong, reset the code to the previous state and run the script
>> > > > again on the original code. 2. The migration script is not perfect.
>> > > > In particular it can't deal with some corner cases like:
>> > > > eo_do(obj, a_set(1),
>> > > > /* b_set(2),
>> > > > g_set(4), */
>> > > > c_set(2));
>> > > > Or abominations like:
>> > > > eo_do(obj, if (a_get())
>> > > > do_something());
>> > > >
>> > > > So please be aware of that and *manually* review your changes after
>> > > > the script has run.
>> > > >
>> > > > If your code does have these cases, I recommend you either get rid
>> > > > of them, or manually migrate that code before running the script
>> > > > (remove the relevant eo_do).
>> > > >
>> > > > Follow the wiki page mentioned in the previous email for more
>> > > > information about Eo and what else needs changing.
>> > > >
>> > > > Please let me know about any regressions (there shouldn't be any)
>> > > > or any issues you may face.
>> > >
>> > > I'm now pushing my changes to eo_add. I'm pushing it now for the same
>> > > reason I pushed the previous changes in.
>> > >
>> > > I created a new script that assumes the code has already been
>> > > migrated with the previous (migrate_eo.py) script. This script is
>> > > called migrate_eo_add.py and can be found at:
>> > > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
>> > >
>> > > When using the script you should keep two things in mind:
>> > > 1. You are only allowed to run it *once* per source code, because the
>> > > changes to eo_add() would otherwise accumulate and your code will be
>> > > wrong. If you need to correct something you've done wrong, reset the
>> > > code to the previous state and run the script again on the original
>> > > code. 2. The migration script is not perfect. In particular it can't
>> > > deal with cases like missing {} for if/for/while content so for
>> > > example,
>> > >
>> > > if ()
>> > > return eo_add(...)
>> > >
>> > > would break.
>> > > 3. If you are fancy and use the same variable inside eo_add and
>> > > outside, for example like:
>> > > parent = eo_add(CLASS, parent);
>> > >
>> > > your code will break. I suggest you use a temporary variable.
>> > >
>> > > So please be aware of that and *manually* review your changes after
>> > > the script has run.
>> > >
>> > > If your code does have these cases, I recommend you either get rid of
>> > > them, or manually migrate that code before running the script (remove
>> > > the relevant eo_do).
>> > >
>> > >
>> > >
>> > > Sorry, but C++ will break until the C++ guys fix it. I'm now in the
>> > > process of migrating the rest of our applications. Hopefully this
>> > > will be the last disruption of this sort.
>> > >
>> >
>> > Sorry man but the new syntax is ugly. I still don't see why this change
>> was
>> > needed. Please enlighten me. It reminds me the wonderful eo_do_ret
>> syntax :-)
>> >
>> > So yes Tom I vomit on your eo_add
>> >
>> >
>> > BBEEEUUUUUUAAAAAHHHHH...
>> >
>> > %%%%%%
>> > %%%% = =
>> > %%C >
>> > _)' _( .' ,
>> > __/ |_/\ " *. o
>> > /` \_\ \/ %`= '_ .
>> > / ) \/| .^',*. ,
>> > /' /- o/ - " % '_
>> > /\_/ < = , ^ ~ .
>> > )_o|----'| .` '
>> > ___// (_ - (\ eo_add(&obj...
>> > ///-( \' \\
>>
>> bwhahahahahha.
>
>
>> the reason was eo add methods.
>>
>> obj = eo_add(..., text_set(obj, "x"), color_set(obj, 1, 2, 3, 4));
>>
>> because eo4 changes to pass obj into every method - that means obj has to
>> be
>> filled and defined with the RIGHT eo id before the extra text_set() is
>> called
>> because it passes it in, thus you have to pass a ptr to the eiod so it
>> can be
>> filled in first so it is correct for the following calls within the
>> eo_add.
>>
>
> I know you don't like it but I can see two solutions to that:
> 1. a different macro for eo_add() that doesn't allow any function calls
> before finalize (I believe it would be used quite often)
> 2. use a tls to store the currently created obj and add a macro to get it
> in those inlined function calls, eg.
> obj = eo_add(CLASS, parent, do_something(eo_cur))
>
> wrt. 1. I wonder how the bindings will even be able to create objects and
> call functions before finalize?
>
> Best regards,
>
> --
> Jean-Philippe André
>
--
Jean-Philippe André
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
