On Wed, 29 Jan 2014 16:41:13 +0200 "daniel.za...@samsung.com"
<daniel.za...@samsung.com> said:
> Hi Raster,
>
> Don't worry, you don't have to answer this mail. I just want to share
> our thoughts.
it's on my todo list to answer. tail end of a few emails left. :)
> After thinking more about the two "include" solutions, it seems that the
> one you proposed can make issues when a same "user" file possesses
> functions of two classes or more. I mean it would be included by two
> classes and compilation will not be happy. There is at least one file in
> that case, sharing both Evas_Object and Evas functions. We could split
> the file but I don't think separating same feature functions because of
> Eolian would be wise.
>
> So for the moment, we look more at the second solution. We even don't
> have to put the "extern" token (don't ask me why I wanted it), just a
> forward declaration. In that case, we don't need to change any Makefile
> and files (except for the splitting).
>
> We thought pushing next week in efl repo an example of a splitted class,
> to let people comment and review before the big change.
i'll still get to this ... :) but i'll take this into account - i have to
context switch back to this so i am deferring it until i nuke some other todo
items that are fresher in my mind.
> JackDanielZ, alias me
>
> On 01/20/2014 03:09 PM, Carsten Haitzler (The Rasterman) wrote:
> > 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
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
