On 11/24/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
Andrey, I'm trying to create a documentation bundle according to your architecture.
Are you joking? :) It's only my attempt to understand and outline the current structure.
Could you please help me to understand a list proposed at http://wiki.apache.org/harmony/DRLVM_Documentation_Interfaces_Classification better? 1. What do you think about Egor's and Pavel's suggestions?
I agree with latest Nadya's and Pavel's answers on this theme.
2. I cannot find java files in your list. Does VM expose any java interfaces?
Yes, and I know that you know this. :) Almost all java classes at "vm\vmcore\src\kernel_classes\javasrc" form the interface to classlib. It is rather long list and I'm not sure that it should be presented without nesting in initial Doxygen page. I suggest pointing all these classes as one item with reference to details. What is your suggestion?
3. Why have you placed the following files into the porting layer component? vm/tests/unit/framework/testframe.h vm/tests/unit/thread/test_performance.h vm/tests/unit/thread/utils/thread_unit_test_utils.h vm/tests/unit/ulist/unit_test.h vm/tests/unit/ulist/unit_test_logger.h vm/tests/unit/ulist/unit_test_main.h
Forgot a header. Corrected. Thanks.
4. I cannot find the following files in svn. Why they are here? Do you have plans to commit them? Such non-existent files made doxygen to report an error. vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_ClassLoadingMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_CompilationMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_GarbageCollectorMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_MemoryManagerMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_MemoryMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_MemoryNotificationThread.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_MemoryNotificationThreadShutdown.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_MemoryPoolMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_RuntimeMXBeanImpl.h vmcore/src/kernel_classes/native/org_apache_harmony_lang_management_ThreadMXBeanImpl.h
I had applied patch from HARMONY-1407 in my workspace. Sorry. Corrected.
5. Have you intentionally missed the following header files? gc_gen/src/common/gc_metadata.h gc_gen/src/utils/sync_pool.h gc_gen/src/utils/sync_queue.h gc_gen/src/utils/sync_stack.h gc_gen/src/utils/vector_block.h
New files; just appeared.
include/open/thread.h
Empty, obsolete file.
include/vm_properties.h
New file; just appeared.
6. Why the following headers appear in your table twice? port/include/apr_thread_ext.h port/include/clog.h port/include/cxxlog.h port/include/lil.h port/include/lil_code_generator.h port/include/lil_code_generator_utils.h port/include/log_macro.h port/include/logger.h port/include/loggerstring.h port/include/m2n.h port/include/platform_core_natives.h port/include/port_atomic.h port/include/port_disasm.h port/include/port_dso.h port/include/port_env.h port/include/port_filepath.h port/include/port_general.h port/include/port_malloc.h port/include/port_sysinfo.h port/include/port_timer.h port/include/port_vmem.h port/include/stack_iterator.h
Copy&paste error. Corrected. I wrote that it was only the draft. Thanks anyway. Really porting set of interfaces need additional review. I think that almost all h-files are used by other components and should be moved to the intercomponent interfaces table. Thanks, Andrey
-- Thank you, Alexei On 11/20/06, Andrey Yakushev <[EMAIL PROTECTED]> wrote: > 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_Classification. > 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 <[EMAIL PROTECTED]> wrote: > > On 07 Nov 2006 21:17:45 +0600, Egor Pasko <[EMAIL PROTECTED]> 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 > > > > >
