On 11/03/16 20:54, David Seikel wrote: > On Fri, 11 Mar 2016 12:28:19 +0000 Tom Hacohen <t...@osg.samsung.com> > wrote: > >> On 09/03/16 16:23, Tom Hacohen 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. >>> >> >> Good news! I came up with a way to sanely support the old syntax (was >> discussed on the ML in this thread in my mail on the 10/3 at 11:52 >> UTC. >> >> I'm reverting my changes, and will be pushing everything shortly. > > So right now isn't a good time to be updating EFL from git I guess?
It doesn't matter as long as you keep elm in sync and don't use the Eo api in your pet projects. :) -- 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=278785231&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
