On Mon, 20 Jan 2014 14:25:01 +0200 "daniel.za...@samsung.com"
<daniel.za...@samsung.com> said:
currently i'm going through phab backlog. :( reviews and then task tickets.
i'll roll around to my email box after that.
> Hi Raster,
>
> I know it is a long time we didn't speak about that but I would like to
> reopen it to decide the interaction between files.
> As I explained before, we have at least two files by class:
> - the eolian-generated file that contains all the legacy/Eo functions
> - the "user" file that contains the logic part of the functions. There
> can be more than one file of this type
>
> The question is: who is supposed to include who?
> - you suggested that the auto-generated file will include the user
> files. That can be done by replacing in the makefile these files by the
> new one and by giving to Eolian command line the different files to include
> - we suggested (more began like that) that one "user" file will include
> the auto-generated. We let the makefile as is but we must add into the
> auto-generated file externs to the user functions that will no more be
> static.
>
> I think yours is cleaner but I would like to be sure it is ok (i.e we
> thought about all the consequences) before beginning changing the generator.
>
> Thank you, boss
> JackDanielZ, alias Daniel the 3rd.
>
> On 01/01/2014 02:18 PM, daniel.za...@samsung.com wrote:
> > On 12/31/2013 10:03 AM, Carsten Haitzler (The Rasterman) wrote:
> >> On Thu, 12 Dec 2013 16:14:34 +0200 "daniel.za...@samsung.com"
> >> <daniel.za...@samsung.com> said:
> >>
> >>> Hi all,
> >>>
> >>> As you maybe know, we are developing a tool (Eolian) that will help
> >>> people to add functions to the Eo classes and to generate automatically
> >>> bindings. We spoke a lot about the .eo format to describe the classes
> >>> but we never spoke about the generator. So is the time.
> >>>
> >>> The solution chosen to generate C code is to have two files:
> >>> - the first one is fully auto-generated by Eolian and contains EAPI
> >>> legacy functions and Eo code
> >>> EAPI Eo_Op... = EO_NOOP;
> >>> ...
> >>> EAPI void
> >>> evas_object_image_mmap_set(Evas_Object *eo_obj, const Eina_File *f,
> >>> const char *key)
> >>> {
> >>> eo_do(eo_obj, evas_obj_image_mmap_set(f, key));
> >>> }
> >>>
> >>> static void
> >>> _eo_evas_object_image_mmap_set(Eo *eo_obj, void *_pd, va_list *list)
> >>> {
> >>> const Eina_File *f = va_arg(*list, const Eina_File *);
> >>> const char *key = va_arg(*list, const char*);
> >>> _mmap_set(obj, f, key); *// User function located in the second C
> >>> file* }
> >>> ...
> >>> static void
> >>> _class_constructor(Eo_Class *klass)
> >>> {
> >>> const Eo_Op_Func_Description func_desc[] = {
> >>> EO_OP_FUNC(EO_BASE_ID(EO_BASE_SUB_ID_CONSTRUCTOR),
> >>> _constructor), EO_OP_FUNC(EVAS_OBJ_IMAGE_ID
> >>> (EVAS_OBJ_IMAGE_SUB_ID_MMAP_SET), _eo_evas_object_image_mmap_set),
> >>> ...
> >>> }
> >>> ...
> >>>
> >>> - the second file contains the user code. It is not touched by Eolian.
> >> so the "user" edits the generated file above to fill in
> >> _eo_evas_object_image_mmap_set() for example (eolian generates that
> >> function stub with just enough boilerplate to get them going) right? so it
> >> doesnt fully generate but it also has to update/edit/merge in changes from
> >> the eo file. this generated file #includes the totally "custom user code
> >> never touched by eolian" right? or this eo generated file is NEVER edited
> >> by the user and the user has to write the _mmap_set() func by hand? or
> >> does eolian generate these empty stubs for the user (or update them if
> >> params change)? it'd be nice if it could generate them when they get added
> >> to the class with an empty function the "user" then has to fill. which one
> >> is it? i would definitely vote for eolian generating at least empty stub
> >> functions so things compile (and likely dont work or do anything useful).
> > The "user" edits its own file and implements the functions that are
> > expected by the generated file.
> > Creating stub functions implies that we need to parse C code and that's
> > what we want to prevent.
> > If you want to create stubs, you have to know a destination file. For
> > most of the cases, it is easy because all the functions of the class are
> > defined in a same file. But we have classes (Evas Object, Edje iirc...)
> > whose user functions are splitted into many files. It would mean you
> > have to indicate which function you want to create in a certain file.
> > Imo, it is preferable that things don't compile so that you will not
> > forget to implement it.
> >> for the func name - static so they dont leak out, ensure the "user" file is
> >> #included into the eolian generated file so we keep all symbols local and
> >> #i'd
> >> say start with _ and add _eoimpl_ (eo implementation) just to ensure it
> >> wont clash with anything else.
> >>
> >> static void
> >> _eoimpl_mmap_set(Eo *obj, Eina_File *f, const char *key)
> >> {
> >> }
> > For the moment, the "user" file includes the generated file. In this
> > way, we don't change the makefiles (I know, bad reason).
> > If we do as you suggested, we have to include many files in the case of
> > scattered functions and put the generated files into the makefiles. The
> > issue here is how we can know which files have to be included. Maybe as
> > parameter of Eolian.
> > With our solution, only one "user" file includes the generated file but
> > we will have to set the user functions as extern into the generated file
> > and to remove the static and that's bad. Except if the main "user" file
> > of the class (e.g evas_object_main.c) includes the other "user" files of
> > the class and the generated file. And so we will just have to remove
> > them from the makefiles.
> > The solution you suggest seems better. Well, I am your minion, so I must
> > agree with you ;-). Seriously I don't know which way to choose for the
> > moment.
> >
> > Concerning the naming conventions, we use for example
> > _eo_obj_load_dpi_get into the generated file and
> > _evas_image_load_dpi_get into the "user" file.
> >>
> >>
> >>> This separation facilitates the generation for the C files. In the
> >>> future, when Eo2 is operational, we will be able to switch fast by
> >>> invoking Eolian to generate legacy and Eo2.
> >>>
> >>> I think this is the best time to speak about the changes we can make in
> >>> the current code to set code conventions:
> >>> - Eolian-generated Eo functions have to call user functions. Which
> >>> convention for the function name? We decided for the moment to go on the
> >>> operation only (_mmap_set).
> >>> - Prototypes of user constructor and destructor. Since we are not
> >>> supposed to see neither va_list nor parameters (except custom
> >>> constructors), we chose to give only the object: static void
> >>> _constructor(Eo *obj)...
> >>> - Data names are for the moment not following the same style. We have
> >>> Evas_Object_Image and Elm_Button_Smart_Data. Since "Smart" comes from
> >>> Evas_Object_Smart inheritance, I think it can be removed. On the other
> >>> way, Evas_Object_Image is imo not enough specific. We could change these
> >>> names to Evas_Image_Data and Elm_Button_Data. Maybe we can change too
> >>> Evas_Object_Protected_Data to Evas_Object_Data, since I don't see for
> >>> the moment the utility of a possible public/protected/private data type.
> >>>
> >>> I hope that next week, we will show how it will look like on a simple
> >>> and little example like ... evas_object_image.c ;-)
> >>>
> >>> JackDanielZ, alias Daniel the 3rd
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Rapidly troubleshoot problems before they affect your business. Most IT
> >>> organizations don't have a clear picture of how application performance
> >>> affects their revenue. With AppDynamics, you get 100% visibility into your
> >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> >>> Pro!
> >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> >>> _______________________________________________ enlightenment-devel
> >>> mailing list enlightenment-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>>
> >
> > ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> > Pro!
> > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > _______________________________________________ enlightenment-devel mailing
> > list enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
