On Fri, 14 Jun 2013 16:28:42 +0200 Jérémy Zurcher <[email protected]> said:
> On Friday 14 June 2013 22:16, Carsten Haitzler wrote : > > On Fri, 14 Jun 2013 14:54:24 +0200 Jérémy Zurcher <[email protected]> said: > > > > > Hi, > > > > > > I'm still adding my bits to _eo_class_mro_add, > > > the end is near. > > > > > > What do you think should be done, > > > change a few, bin all , zillions or 1 phab rev, merge like a cowboy ?? > > > > actually... i'm more curious... you jumped in on eo pretty quickly after it > > hit git... what do you think about eo in general? good/bad? before we start > > building our universe around this... are there any really nasty things we > > should fix before they are set in stone to retain api/abi? what could be > > done to improve it and take it further over time to help people more? > I jumped on it cause these are the bits I really like to play with and I'm far > from beeing capable in the graphical area. I also want to have a deep > understand of it to see where to go with ffi-efl. > The eo-WIP bits are internal improvements and speed up (I hope so ;) sounds fair enough. we are most appreciative of work everywhere and anywhere - not just graphics stuff. :) > what I think about eo: > - eo is not about replacing c++ and must never be > - it's a very good tool for evas/elm API OO is good for these things > - but I dislike the usage of #define and varargs > > I would prefer your below example to be expanded into : > > { > // check eo_id + MAGIC + … + mark object and return it's pointer > obj_ptr = eo_mark_obj(obj); > // following calls just check marked bit of obj_ptr first > efl_color_set(obj_ptr, 255, 128, 0, 255), > efl_font_set(obj_ptr, "Sans", 16), > efl_text_set(obj_ptr, "This is some text"), > efl_geom_pos_set(obj_ptr, 20, 30), > efl_visible_set(obj_ptr, 1));c > // reset marked bit > eo_unmark_obj(obj_ptr); > } > > ?? it just poped into my mind ?? the problem with these is the propensity to have errors - makr then forget to unmark. do things like mark x y z if (!z) return; unmark these little things will tend to creep in. :( > > > > stage 1 is pretty much done. current efl "classes" are mapped to eo and efl > > is layered on top. stage 2 is to rebuild out classes/interfaces to make > > full use of this so objects now inherit multiple interfaces/classes based > > on their types (eg evas text objects would of course inherit basic eo > > interface plus evas object geometry interface plus font set interface plus > > color set interface plus text set interface - as a simple example (the same > > text set interface can then be used on textblock objects and edje objects, > > and most/all elm widgets etc.). > > > > so ultimately i expect to have this: > > > > eo_do(obj, > > efl_color_set(255, 128, 0, 255), > > efl_font_set("Sans", 16), > > efl_text_set("This is some text"), > > efl_geom_pos_set(20, 30), > > efl_visible_set(1)); > > > > maybe? well for sure so you don't need to now know if its evas_ or edje_ or > > elm_ or ecore_ etc. as namespace... just call something obvious on the > > object and presto. all these interfaces need to be defined based on looking > > at current efl and finding all the design patterns and turning them into > > common interface classes. > of course, to move we really have to have that discution about eo, > hope others will join, too late is … well yup. indeed. someone needs to start a ball rolling and then work on fleshing it out fully. > > keeping in mind that eo is not about replacing c++ but just bringing some of > > the convenience of classes, interfaces and inheritance and methods to c, as > > well as unifying our callback systems into a single one, making it easy to > > glue objects together and have them auto deleted as a group. and of course > > providing a safety barrier to separate apps and tools outside of efl with > > efl itself. for now the eo id / table lookup is the layer we have, with it > > being mmaped outside of normal libc malloc space so its hard to overwrite > > it. your madvise stuff you put in so quickly was awesome btw, but over time > > i'd like to see us also move more allocation for the insides of objects off > > into special memory regions to improve this safety. the eo multi-call > > varags system lets us increase this overhead with the eoid indirect lookup > > but then amortize that cost over multiple calls, thus keeping us at an > > efficient level even with the added work. > I had a few words with jackdaniels yesterday about this, > he talk to me about what seems to be using the ecore idle to compact memory > as eo_id allows to freely move the objects in memory, > I said a few about having the objects within the eo_id tables to gain object > recycling. > ??? thats one bonus of eoid... it allows for memory compaction. :) but we need to move more and more memory to be "directly controlled". we're going to need a malloc impl of our own soon (where we can directly control what memory allocations come from). that will allow us to not only isolate memory allocated by efl itself into separate memory spaces (away from possible glibc overruns but allow all sorts of safety contels - eg stringsare strings come from a region we mprotect to read-only (like your work on the eoid tables). :) as for object id recycling... we probably want to avoid aggrssive id recycling by default. this means chances of an id collission go down. we should have a "zombie pool" of id's. the size will simply determine how quickly id's get recycled. the zombie pool holds id's that have been freed, but are not to be re-used until the pop out the end of the lru list of the pool. it probably should be an array not list and i'ds are released in chunks - eg 1024 or 4096 id's at a time, and the list is really a linked list of these array chunks... :) more memory efficient like this. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
