'Re: [E-devel] Eo: Changes to syntax'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] Eo: Changes to syntax
From:       Tom Hacohen <tom () stosb ! com>
Date:       2016-05-22 18:49:38
Message-ID: CAEvi_o8=cmaaE3mXwTnaO6OOye46VL9riMkPvXwQNRKG2bevsQ () mail ! gmail ! com
[Download RAW message or body]

Yes. :)

Run scripts (in the order I emailed about them) until everything works...

On Sun, May 22, 2016 at 12:52 PM, David Seikel <onefang@gmail.com> wrote:

> On Fri, 11 Mar 2016 12:28:19 +0000 Tom Hacohen <tom@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.
>
> Sooooo, now that it's probably time to update my EO using code, do I
> still need to run those two scripts you wrote?  I have a whole lot of
> this sort of thing -
>
> obj = eo_add(ELM_IMAGE_CLASS, ourGlobals->win);
> ourScene.image = obj;
> eo_do(obj,
>    evas_obj_size_hint_weight_set(EVAS_HINT_EXPAND, EVAS_HINT_EXPAND),
>    elm_obj_image_fill_outside_set(EINA_TRUE),
>    efl_gfx_visible_set(EINA_TRUE),
>    temp = elm_obj_image_object_get()
> );
> eo_do(temp,
>    evas_obj_image_scene_set(ourScene.scene)
> );
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic