On Saturday 15 June 2013 18:59, Carsten Haitzler wrote :
> On Fri, 14 Jun 2013 16:28:42 +0200 Jérémy Zurcher <jer...@asynk.ch> said:
>
> > On Friday 14 June 2013 22:16, Carsten Haitzler wrote :
> > > On Fri, 14 Jun 2013 14:54:24 +0200 Jérémy Zurcher <jer...@asynk.ch> 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. :(
yes but :
#include <stdio.h>
#include <stdlib.h>
/* Object internal */
struct Obj
{
int marked;
int n;
};
struct Obj *obj;
#define CHECK() if (!obj->marked) return 0;
int obj_get(int n)
{
obj = calloc(1, sizeof(struct Obj));
obj->n = n;
return 1;
}
struct Obj* obj_mark(int id)
{
obj->marked = 1;
return obj;
}
void obj_unmark(struct Obj* obj)
{
obj->marked = 0;
}
/* Object API */
int add(struct Obj *obj, int n)
{
CHECK()
return (obj->n += n);
}
int times(struct Obj *obj, int n)
{
CHECK()
return (obj->n *= n);
}
int print(struct Obj *obj, FILE *fout)
{
CHECK()
fprintf(fout, "Obj : %d\n", obj->n);
}
/* EO MACROS */
#define DO(_op_, ...) _op_(__obj, __VA_ARGS__ );
#define WITH(_obj_, ...) { struct Obj *__obj = obj_mark(_obj_); __VA_ARGS__
obj_unmark(__obj); }
int main()
{
int obj = obj_get(220);
WITH(obj,
DO(add, 2)
DO(times, 3)
DO(print, stdout)
);
return 0;
}
>
> > >
> > > 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) ras...@rasterman.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
--
Jérémy Zurcher
av General Guisan 49
1400 Yverdon-les-bains
+41 (0) 79 599 84 27
------------------------------------------------------------------------------
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
