On Tue, 15 Mar 2016 12:55:33 +1000 David Seikel <onef...@gmail.com> said:
> On Tue, 15 Mar 2016 10:54:37 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Tue, 15 Mar 2016 01:41:26 +1000 David Seikel <onef...@gmail.com> > > said: > > > > > On Mon, 14 Mar 2016 10:05:42 +0000 Tom Hacohen <t...@osg.samsung.com> > > > wrote: > > > > > > > On 11/03/16 20:54, David Seikel wrote: > > > > > On Fri, 11 Mar 2016 12:28:19 +0000 Tom Hacohen > > > > > <t...@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. > > > > > > > > > > So right now isn't a good time to be updating EFL from git I > > > > > guess? > > > > > > > > It doesn't matter as long as you keep elm in sync and don't use > > > > the Eo api in your pet projects. :) > > > > > > I do use Eo API in my pet project though. :-P > > > > > > Actually, it's all experimental, which is why I'm using things like > > > Eo and Evas_3D in the first place. I did end up updating the lot > > > from git, EFL, Elm, and Enlightenment, etc. Now terminology > > > doesn't work. Oh well, I can live with some other terminal until it > > > gets fixed. > > > > what's the problem? > > ~$ terminology > CRI<17649>:terminology main.c:599 elm_main() Could not initialize key > bindings. ERR<17649>:ecore lib/ecore/ecore.c:691 _ecore_magic_fail() > *** ECORE ERROR: Ecore Magic Check Failed!!! > *** IN FUNCTION: ecore_ipc_server_del() > ERR<17649>:ecore lib/ecore/ecore.c:701 _ecore_magic_fail() Input > handle is wrong type Expected: 87786556 - <UNKNOWN> > Supplied: 01ac2770 - <UNKNOWN> > ERR<17649>:ecore lib/ecore/ecore.c:704 _ecore_magic_fail() *** NAUGHTY > PROGRAMMER!!! *** SPANK SPANK SPANK!!! > *** Now go fix your code. Tut tut tut! > CRI<17649>:eina_log lib/eet/eet_lib.c:611 eet_shutdown() unknown log > domain -1, original message was: ERR: 'Init count not greater than 0 in > shutdown.' a terminology issue of some sort with its own config - rm -rf ~/.config/terminology ... presto. > > As I mentioned, I updated the lot from git, when the last > Enlightenment was released, which is my habit these days, only update > from git when EFL or Enlightenment get released. However, this time > around there was the major changes to EFL at the time, so I'm > considering this to be a temporary aberration. Which is why I never > bothered to report it. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- 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=278785231&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
