harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morozova, Nadezhda" <nadezhda.moroz...@intel.com>
Subject RE: Re: [doc] What should be improved in DRLVM Doxygen documentation?
Date Tue, 21 Nov 2006 09:44:45 GMT

>-----Original Message-----
>From: news [mailto:news@sea.gmane.org] On Behalf Of Egor Pasko
>Sent: Tuesday, November 21, 2006 7:42 AM
>To: dev@harmony.apache.org
>Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?
>
>On the 0x227 day of Apache Harmony Nadezhda Morozova wrote:
>> That's a great start. Yes, if we have such a table as the front page
for
>> Doxygen interfaces, it would be great. If you wish, I can prepare the
>> patch with the nice-looking version of it all.
>>
>> Questions:
>> - When building Doxygen, can we have a target for inter-component
>> interfaces and for each component?
>> - if yes, should the files inside the include/ subfolder be built
with
>> the component they belong to?
>> - For VM core and jit: any ideas on how to group files further? The
>> current list of files belonging to vm core interfaces is *so* long...
>> - Should we prepare docs for gcv4?
>
>IMO, the list of headers for Jitrino is too verbose. For
>inter-component picture I suggest the following subset:
>vm/jitrino/src/dynopt/EdgeProfiler.h
>vm/jitrino/src/dynopt/StaticProfiler.h
>vm/jitrino/src/jet/jet.h
>vm/jitrino/src/main/Jitrino.h
>vm/jitrino/src/vm/drl/DrlEMInterface.h
>vm/jitrino/src/vm/drl/DrlVMInterface.h
>vm/jitrino/src/vm/EMInterface.h
>vm/jitrino/src/vm/VMInterface.h
>
>other headers are internal for Jitrino. So, the suggestion is: to
>document the mapping between *relevant* h-files and the structure in
>the DevGuide
[Nadya] 
I think we're mixing two different header groups. The first type is
*inter-component*, listed at the top of page on wiki. The devguide shows
these interfaces in VM arch figure. As I understand, these are the
interfaces that any jit must export:

   Execution engine 
   JIT_VM 
      vm/include/internal_jit_intf.h 
       vm/include/open/ee_em_intf.h
Not sure how these are related to files jitrino/src/vm/*Interface.h.

The other group is *Interfaces inside the components*. Here I think all
interfaces between internal parts of a component can go. I agree JIT and
VM core seem to have too many headers, but they are all in the dir tree.
Don't you think we need to document them? 

My suggestion would be to add subgrouping for jit header files - and
possibly assign priorities to different groups. What do you say?

>
>>
>> Thank you,
>> Nadya Morozova
>>
>>
>> >-----Original Message-----
>> >From: Andrey Yakushev [mailto:andrey.yakushev@gmail.com]
>> >Sent: Monday, November 20, 2006 3:47 PM
>> >To: harmony-dev@incubator.apache.org
>> >Subject: Re: [doc] What should be improved in DRLVM Doxygen
>> documentation?
>> >
>> >In order to understand the mapping between h-files and structure
>> >described in the Developers guide I have tried to prepare some
initial
>> >classification. I put draft at
>>
>http://wiki.apache.org/harmony/DRLVM_Documentation_Interfaces_Classific
>> atio
>> >n.
>> >Probably such tables could be added to Doxygen doc; of course after
>> >verification and rewriting it in more user friendly manner.
>> >
>> >Is this helpful?
>> >
>> >Thanks,
>> >Andrey
>> >
>> >
>> >
>> >On 11/7/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>> >> On 07 Nov 2006 21:17:45 +0600, Egor Pasko <egor.pasko@gmail.com>
>> wrote:
>> >>
>> >> > Do we feel that it is time to set responsibilities on
documenting
>> >> > vm/include/* ?
>> >>
>> >>
>> >> +1 To start working on intercomponent interfaces. Going to commit
a
>> >couple
>> >> of EM interface files with documentation tomorrow. I do not
believe
>> that
>> >> someday we will have all component's local code documented (-1 to
>> make
>> >such
>> >> policy for patches), but intercomponent documentation is something
we
>> >must
>> >> have (actually we must not only document but clean the code too)
>> >>
>> >> --
>> >> Mikhail Fursov
>> >>
>> >>
>>
>
>--
>Egor Pasko

Mime
View raw message