On 11/03/16 02:52, Jean-Philippe André wrote: > 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? >
You can't, because the EFL may be compiled with a different compiler than the user application. You have do detect it during the user compilation time because you don't want to force users to change their configure.ac just to use the efl (or worse, even have one). I'd assume as a first step that if it's GCC or CLANG it'll just work. It's been supported in both for forever. If we hit breaks, the tests are very easy to change. If you know the relevant GCC and clang versions, I'll happily include that in the checks. -- Tom ------------------------------------------------------------------------------ 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
