On Thu, Jul 18, 2013 at 9:37 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Wed, 17 Jul 2013 15:10:45 +0100 Tom Hacohen <tom.haco...@samsung.com> said: >> On 17/07/13 15:04, Stefan Schmidt wrote: >> > On 07/17/2013 02:07 PM, Tom Hacohen wrote: >> >> On 16/07/13 09:02, Cedric BAIL wrote: >> >>> On Tue, Jul 16, 2013 at 4:35 PM, Stefan Schmidt <s.schm...@samsung.com> >> >> wrote: >> >>>> >> >>>> Before the efl merge and the git move Daniel and myself played around >> >>>> with what we already had in svn and made it work again. Should be >> >>>> somewhere in SCRIPTS. >> >>> >> >>> If we can use coccinelle for that task it would be way better ! >> >> >> >> As I said, I'm not sure we can, as the changes are "weirder", converting >> >> va_args to normal args. >> > >> > And instead of finding out by trying it you just want to drop the idea >> > which is way better in line with what you planned anyway. :) >> >> That was the plan, but I'm willing to reconsider, as your points are valid. > > how about.. you take some sample snippets of existing eo api.. and try first > and convert it? then you'll know. > > if we were back at our original eo start point and this was proposed - it'd be > a very viable candidate. it has its downsides though (as i mentioned already) > and upsides too. but the one BIG BIG BIG killer of eo2 is - time. to move to > it, it would need to firstly be complete enough to replace current eo *AND* > all > existing eo api suers have to convert over. conversion is the nasty part and > that will be by far the biggest time-sink. right now if we had to do it all by > hand i smell several months of work here. if you can find an automated way to > do maybe 90% of the conversion... or all of it even, then there is only > "complete eo2" which frankly is enough work anyway. > > either way i am not willing to hold up efl 1.8 for this. if we change, we'd > have to change AND then leave a few months of testing to check we didnt miss > stuff/do it wrong... that assumes the change all happened today. > > eo2 seems nice... but your timing is pretty crappy :)
I have been thinking the same to. I came to the conclusion that the best things to do is to mark Eo.h API itself as beta and require user of it to explicitly turn it on to use it. This means I think we can just make it a not API/ABI supported library for the moment. This will give us enough time to handle a better API for it as it seems eo2 is going into interesting proposal and it wont hold back 1.8 for another semester. In general if we go to a time based release I guess this kind of situation will happen much more often. So marking some API as beta and not supported yet, seems reasonable to move forward. Have fun, -- Cedric BAIL ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
