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. -- 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
