On 10/03/16 06:46, Jean-Philippe André wrote: > On 10 March 2016 at 15:05, Carsten Haitzler <[email protected]> wrote: > >> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui <[email protected]> >> said: >> >>> On Wed, 09 Mar 2016 16:23:04 +0000 >>> Tom Hacohen <[email protected]> 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)) > > wrt. 1. I wonder how the bindings will even be able to create objects and > call functions before finalize?
As you explained to the vomiting boy somewhere else in the thread, the reason why I had to switch is portability. 1. I don't know how often that will be used. 2. You can't do that unfortunately. TLS is sucky and ugly and I would have hated using it, but I would have if it was possible, which is unfortunately not. You can't even use it in a single threaded environment (that's why we had the eo stack before). To see where it breaks, just consider an object that adds a subobject in the constructor. I don't see what you mean an what's the problem... -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
