On Thu, 10 Mar 2016 15:48:12 +0900
Jean-Philippe André <j...@videolan.org> wrote:
> 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) ));
You can use the vomit ascii on that too ;-)
>
>
> On 10 March 2016 at 15:46, Jean-Philippe André <j...@videolan.org>
> wrote:
>
> >
> >
> > On 10 March 2016 at 15:05, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> >> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui
> >> <daniel.za...@samsung.com> said:
> >>
> >> > On Wed, 09 Mar 2016 16:23:04 +0000
> >> > Tom Hacohen <t...@osg.samsung.com> 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é
> >
>
>
>
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
