On Thu, 10 Mar 2016 15:05:38 +0900
Carsten Haitzler <ras...@rasterman.com> (The Rasterman) 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.

Why not just use some keyword for the object e.g THIS/EO_ME/whatever that would 
be replaced during preprocessing with eoid (that was defined in _eo_add_common)?

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


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

Reply via email to