On Tue, 15 Mar 2016 14:47:14 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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. Not quite presto, I still had to try to remember how I had it configured two years ago, the last time I touched my terminology config. Still, it's broken if it can't read the config it has been using for years, and crashes instead of giving some sort of meaningful error message. As the error message says "NAUGHTY PROGRAMMER!!! *** SPANK SPANK SPANK!!! *** Now go fix your code. Tut tut tut!". While on the subject of terminology, when will --maximized ever actually get implemented? It's been a broken option for years, can't be that hard. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
