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? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
