On Mon, Jul 8, 2013 at 4:58 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > forgot to git-daemon-export-ok? > http://git.enlightenment.org/devs/tasn/eo2.git = no repositories found >
You can find it on the core efl repository in devs/tasn/eo2 branch. > > On Mon, Jul 8, 2013 at 2:00 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: > >> Hey guys, >> >> The hero Jeremy Zurcher has been playing around and looking for ways to >> improve Eo and address all the issues that have been raised by everyone. >> We revisited some old ideas, tried some new ideas and changed our >> compromises and preferences to better suit our needs (followed by the >> extensive trial period). We think we made things better and we'd like to >> hear your thoughts and suggestions. >> >> The code resides in devs/tasn/eo2. The differences are not major >> usage-wise (i.e eo_do), but are major internally and class-creation-wise. >> There's an example of the usage of the new API in the eo2test directory. >> The existing code-base hasn't been changed to use the new API, so >> there's not a lot to review. >> Eo2 is not complete, we'd like to hear your thoughts before finishing >> things. >> >> Major changes: >> 1. No more va_args, good ol' normal functions instead. >> 2. Functions are resolved in eo and then called directly, creating a >> "flatter" backtrace. >> 3. We can have return values (to some extent). >> 4. Less boiler-plate. >> 5. Looks like we'll be able to get rid of some code thanks to this change. >> 6. Possibly (probably) faster on platforms that pass parameters in >> registers. >> 7. Easier to do breakpoint on a specific eo_do call, instead of an >> implementation. >> >> What we'd still like to achieve: >> 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be >> best to find a way to use the function pointers (for example) as the >> IDs, but the problem is, that because function pointers are more >> "unknown" we can do less optimisations on them which we'd like to avoid. >> 2. Reduce more boiler-plate. >> >> Haven't been implemented yet: eo_do_super (among many other things). >> >> Additional comments: >> EO_FUNC - this one creates a function that resolves and returns the >> appropriate function. The functions created using this macro should be >> used instead of the current eo macros. This one can potentially be >> improved. >> eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and >> possibly other stuff in the future). >> >> Looking forward to hearing what you have to say. >> >> -- >> Tom. >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
