On 11 March 2016 at 00:51, Tom Hacohen <t...@osg.samsung.com> wrote:
> On 10/03/16 12:36, Carsten Haitzler wrote:
> > On Thu, 10 Mar 2016 15:46:19 +0900 Jean-Philippe André <
> j...@videolan.org> said:
> >
> >> 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))
> >
> > or - leave it as is. :) 2 funcs is bad too - imho worse. tls is also bad
> - you
> > have to handle nested adds and maintain a whole stack in the tls too.
>
> See my email, I have a solution to do it with just one function, where
> user applications compiled with compilers that don't support this
> extension automatically degrade to slower version that uses the stack.
> They can both be used interchangeably in the same code, same binary,
> same anything, though for all the user is concerned both are actually
> the same macro, eo_add().
> <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel>
>
I would love this.
We need to be careful about have compiler-dependent stuff in our headers,
but if we can have a clean syntax with a TLS stack for non GCC compilers I
don't think the performance impact would be too bad (it's not every eo_do
this time, only object creation).
Maybe in order to detect support we should not rely on GCC / CLANG version
flags but actually test that the code with ({ }) compiles?
--
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
