On 05/08/13 06:48, daniel.za...@samsung.com wrote:
> Hi Jeremy
>
> On 08/05/2013 02:12 AM, Jérémy Zurcher wrote:
>> On Sunday 04 August 2013  10:20, daniel.za...@samsung.com wrote :
>>> Hi Jeremy,
>> Hello Daniel
>>> On 08/02/2013 05:33 PM, Jérémy Zurcher wrote:
>>>> On Friday 02 August 2013  03:42, Cedric BAIL wrote :
>>>>> Hello,
>>>>>
>>>>> On Thu, Aug 1, 2013 at 2:03 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
>>>>>> what is the purpose of these hooks again,
>>>>> Improving our tooling. Right now there is at least a few tools that
>>>>> can use them :
>>>>> - espion, that does trace every call to elementary and efl to rebuild
>>>>> a fake application without the application logic. Very useful for
>>>>> extracting only the EFL part of an application during debugging. That
>>>>> should make life easier for people that report bugs in there
>>>>> application and we don't have the mean to build them due to
>>>>> dependencies or something else.
>>> This tool is important to me, cause I want to integrate it into our
>>> GUI Builder in order to import existing apps .
>> where is that tool, is there a repo somewhere I could look at ?
> The tool is in the repo
> http://git.enlightenment.org/devs/yakov/egui.git/, branch develop
> file src/lib/espion_preload.c
>>
>>>>> - a performance tracer that will be able to tell where we loose time
>>>>> and how we spend our time from event input to the next frame on
>>>>> screen. Could also be linked with allocation statistic like memprof.
>>>>>
>>>>> - clouseau could use them to do live update of its tree.
>>>>>
>>>>> This is just a few set of idea, I am sure that people can come with
>>>>> other use of it. Maybe there is also use for them by an IDE. Right now
>>>>> those tool where using LD_PRELOAD on eo_do with some introspection
>>>>> information.
>>>> allllright
>>>>
>>>>>> these where my numbers         before            and now
>>>>>>
>>>>>> simple inc() - 99999 calls
>>>>>> calls/eo_do()  EO [ns]/call  - EO2 [ns]/call  -  EO2 [ns]/call
>>>>>> #1              20               25                29
>>>>>> #3              11               15                17
>>>>>> #5               9               13                15
>>>>>> #7               9               12                14
>>>>>>
>>>>>> overriden inc - 99999 calls
>>>>>> calls/eo_do()  EO [ns]/call  - EO2 [ns]/call  - EO2 [ns/call
>>>>>> #1              46               50                55
>>>>>> #3              38               37                42
>>>>>> #5              37               36                39
>>>>>> #7              36               34                38
>>>>> Yes, I saw the slow down. I am wondering if we need the
>>>>> eo2_hook_*do_{pre,post}. I think we could continue to have that
>>>>> feature by using LD_PRELOAD on eo2_*do_{start,end}. That should lower
>>>>> the unitary cost of eo_do.
>>>> maybe better to have the tools, but not let them impact when not needed,
>>>> LD_PRELOAD is good for that
>>> I prefer too LD_PRELOAD but we need to intercept all the Eo
>>> functions and extract the parameters. We need all the params given
>>> to Eo and walk on them like Eo does, i.e determine the opId and the
>>> parameters (a database helps us for that).
>> why would you need OP id?
>> if it't to access the func doc, you will be able to acces it from the EAPI 
>> pointer
>> the parameters are in the EAPI call, maybe you want the object and it's
>> data, for that a single hook in eo2_call_resolve_internal could be enough ??
> The OpId is not a must but we need something that will indicate us which
> function it is, like the opId or a pointer to the auto-created function.
> When the espion is launched on the executable, a database is built with
> the pointers to the functions that can be intercepted and the
> description of its parameters. So when we intercept, we just have to
> find this pointer in the db and so determine the number and types of the
> parameters.
> With the new Eo concept, I don't see how we can use LD_PRELOAD for that.
> We need hooks that can be called with pointer to the auto-created
> function and its params.

Since you need a database *anyway*, you can just create a database of 
functions to pre-load and their signatures. Automatically generate a 
library that does it, and that's it.

--
Tom.



------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to