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. > wrt. 1. I wonder how the bindings will even be able to create objects and > call functions before finalize? lambda's as optional arg on construction. > Best regards, > > -- > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
