[admin] Automated Monthly Reminder
This is a monthly automated mailing to the Apache Harmony dev list. The Apache Harmony project welcomes the participation and input of anyone interested in open source Java SE, the goal of our project. For more information about the Apache Harmony project, please see the project website. http://incubator.apache.org/harmony/ The terms of use for the Harmony mail lists can be found here : http://incubator.apache.org/harmony/mailing.html and they are This forum has been created for public communication about projects of The Apache Software Foundation (the Foundation), a Delaware nonprofit corporation classified as a public charity under 501(c)(3). All communication intentionally submitted to the Foundation on this forum is considered a Contribution to the Foundation unless otherwise noted in the communication. The terms and conditions that apply to your Contributions are defined by either a contributor license agreement (CLA) signed by you and/or your employer or, if no such CLA is on file at the Foundation, by the terms and conditions of Contributions as defined by the Apache License, Version 2.0. Note : * If you do not wish your post to be a Contribution, we would prefer that you do not post it. However, in the event that you do, please mark as NOT A CONTRIBUTION at the top of the posting. * Do not post any code that is not your original work, or code that you do not have clear authorization to contribute. * Do not engage in detailed discussion of any implementation that you have been exposed to unless such implementation is available to everyone under an open source license or is your own implementation. * Under no circumstances will any committer accept code for inclusion in our SVN repository contributed on the mailing list unless it is from an Authorized Contributor, as defined here. If you have any questions, please do not hesitate to ask on either the dev list. If there are any questions that are of a private or sensitive nature, please send them to [EMAIL PROTECTED]
Re: [drlvm] How to debug the drlvm with gdb?
Thanks Rana! If you ask me what would I like, the answer is quite simple: as a windows developer primary (today) I would recommend to other windows developers to use msvc build (with patch from HARMONY-1990http://issues.apache.org/jira/browse/HARMONY-1990 ). With this patch you can almost forget about build.bat (it used only to fetch external components + build Java). Most of the internal components (vmcore,JIT,interpreter,gc_cc,encoder,em,hythread,jthread..) could be built and debugged from within MSVC much faster than with build.bat without any code modification with printf(..) and int3-like breakpoints. I'll add this information to the site after H1990 is commited. On 11/1/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I created a basic debugging page for debugging with the VS debugger on windows. Mikhail and others, make whatever changes you like :-) Rana On 10/24/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 24 Oct 2006 22:42:22 +0700, Egor Pasko [EMAIL PROTECTED] wrote: - Debugging on Windows - Mikhail has been recommended; how's that? the tip from Rana is also useful there. Who can start the page? Mikhail? Rana? I'll do it right after I finish the current task. I do not mind if somebody will pass ahead. This is just the question of tasks priorities. -- Mikhail Fursov -- Mikhail Fursov
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
I have not got the precise number. I will try it.:) On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Good news! However I never believe in 100% :) You mentioned that startup with Harmony is slower then RI. I measured Eclipse3.1.1 startup some time ago and DRLVM+classlib was ~50% slower (7 secs against 5 sec with SUN) then RI. What are your numbers? On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov -- Leo Li China Software Development Lab, IBM
Re: [drlvm][sablevm] Desing of Class Unloading Support
On 11/1/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Maybe for GC's that don't support pinning, the JIT can compare object-vtable-class for guarded devirtiualization, or even not do guarded devirtualization, sort of support the GC in downlevel mode I think this is not a long term solution for a JIT. IMO the best solutions for a JIT with unpinned vtables would be 1) Short term: turn devirtualization off (As Egor has proposed) 2) Long term: patch devirtualization calls when GC moves object (usual enumeration routine) Storing vtable in the object without additional indirection in memory is important from the performance POV. -- Mikhail Fursov
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Great news, Leo! 2006/11/1, Leo Li [EMAIL PROTECTED]: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM -- Alexey A. Petrenko Intel Middleware Products Division
RE: [classlib][swing][test] Excluded tests clean up
Thank you, Alexey. Some of them were successfully applied. Some are in indeterminate state because several tests fail on Mark's machine. I can't reproduce any of those failures on my machines :(. Therefore I can't figure out where the problem is and fix them. You can run tests which were un-excluded and report your results. Thank you in advance, Alexey. P.S. See also this message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16579/focus=16835 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 9:40 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing][test] Excluded tests clean up Alexey, I'll take a look. SY, Alexey 2006/10/20, Ivanov, Alexey A [EMAIL PROTECTED]: Hello, I am working to clean up the excluded list and to make all the tests run-able without failures. I've created several JIRA issues. https://issues.apache.org/jira/browse/HARMONY-1825 https://issues.apache.org/jira/browse/HARMONY-1866 https://issues.apache.org/jira/browse/HARMONY-1910 And https://issues.apache.org/jira/browse/HARMONY-1892 to make all Windows users happier. :) Can anyone look at them and apply patches to make creation of patches to build.xml easier and less reject-prone? Thank you in advance, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
3754ms on RI versus 5740ms on Harmony to startup Tomcat. Seems about 50% slower as well. On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: I have not got the precise number. I will try it.:) On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Good news! However I never believe in 100% :) You mentioned that startup with Harmony is slower then RI. I measured Eclipse3.1.1 startup some time ago and DRLVM+classlib was ~50% slower (7 secs against 5 sec with SUN) then RI. What are your numbers? On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov -- Leo Li China Software Development Lab, IBM -- Leo Li China Software Development Lab, IBM
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Thanks! AFAIK RI uses interpreter and could use OSR, while we do almost the same with a simple JIT without any advanced techniques. Not so bad :) + BEA must be slower than SUN in such tests. On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: 3754ms on RI versus 5740ms on Harmony to startup Tomcat. Seems about 50% slower as well. On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: I have not got the precise number. I will try it.:) On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Good news! However I never believe in 100% :) You mentioned that startup with Harmony is slower then RI. I measured Eclipse3.1.1 startup some time ago and DRLVM+classlib was ~50% slower (7 secs against 5 sec with SUN) then RI. What are your numbers? On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov -- Leo Li China Software Development Lab, IBM -- Leo Li China Software Development Lab, IBM -- Mikhail Fursov
RE: [testing][support] Where to place xxxTestCase support classes
Thank you, Nathan, for your reply. I believe these classes can be put to a support package in the module rather than java.* and javax.* correspondingly. I need to try it. At the moment they are along with the tests. But we can't help use javax.swing.* for swing tests since most of them are designed to be run on bootclasspath. See also the related message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591 Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 3:15 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes If the support classes aren't used outside of one module, then I would put them in that module. Like the beans example mentioned. As for the package name, I would prefer to avoid the java.* and javax.* package names whenever possible, so we can avoid classpath issues. -Nathan On 10/31/06, Alexei Zakharov [EMAIL PROTECTED] wrote: FYI in beans we have the following folders for this purpose: src/test/support/java/org/apache/harmony/beans/tests/support src/test/support/java/org/apache/harmony/beans/tests/support/mock Thanks, 2006/10/31, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexei Zakharov, Intel Enterprise Solutions Software Division
[general] Motorola to develop ME under ALv2
http://biz.yahoo.com/prnews/061031/cgtu074.html?.v=46 Now *that's* cool :-) For those of you that are not ME-enabled, Motorola is a major player in the ME space. They are deeply involved in advancing the spec and have a track record of developing and collaborating 'in the open'. By declaring their intent to use ALv2 and Apache-style governance we can all look forward to an open and unrestricted exchange with the good folk at Motorola. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm][iprof] Using Profiling Utility (iprof)
On the 0x213 day of Apache Harmony Armand Navabi wrote: Egor mentioned that for profiling at the machine code level there is a profiling utility (iprof). How does one use this profiling tool? Is there command line options to run with profiling and if so what are the options and how do I get to the collected information after running a profiled application? Armand, iprof is the Internal PROFiler in the IA-32 CG (Jitrino.OPT only). It is able to instrument the code in such way that per-method counters of _executed_ (not just compiled) instructions can be dumped. iprof creates the file iprof.stat (on exit) with various statistics per method (compiled by OPT). For example, number of calls executed, most executed basic block number, number of casts, etc. see the sample of iprof.cfg below. To use it you need to: * put iprof.cfg in the same dir where you are starting DRLVM * put extra options: -Djit.arg.codegen.iprof=on -XcleanupOnExit * find the iprof.stat created :) On a simple HelloWorld only 2 methods are compiled by OPT in default mode. So, the iprof.stat is short. See more details in -Xem:opt mode) we will document iprof in more detail... Nadya, is it on the way or not yet? :) --- begin iprof.cfg #Use [begin]/[end] tags for EACH counter #Don't use space character outside comments. This restriction should be removed #Config.PrintBBStats=true [begin] #for counting of all instructions you can specify any word as Mnemonic Counter.Insts.Mnemonic=Any [end] [begin] Counter.NULLPTREXCEPTION=HELPER_CALL Counter.NULLPTREXCEPTION.RuntimeInfo.HelperID=NullPtrException [end] #hardcoded counters with only parameter title ### [begin] #Size of java bytecode of a method Counter.ByteCodeSize [end] [begin] #Number of execution times of the hottest basic block of a method Counter.MaxBBExec [end] [begin] #ID nuber of the hottest basic block Counter.HottestBBNum [end] [begin] #Number of exception handlers of a method Counter.ExcHandlersNum [end] [begin] #Number of calls of a method Counter.MethodExec Counter.MethodExec.Title=Number of calls of a method [end] [begin] #Basic block execution count Counter.BBExec [end] ### #Other counters [begin] Counter.CALL.Mnemonic=CALL [end] [begin] Counter.I_HELPER_CALL=CALL Counter.I_HELPER_CALL.RuntimeInfo.Kind=InternalHelperAddress [end] [begin] Counter.HELPER_CALL=CALL Counter.HELPER_CALL.RuntimeInfo.Kind=HelperAddress #Counter.HELPER_CALL.RuntimeInfo.HelperID=LdString [end] [begin] Counter.LDSTRING=HELPER_CALL Counter.LDSTRING.RuntimeInfo.HelperID=LdString [end] [begin] Counter.NEWOBJ_USINGVTABLE=HELPER_CALL Counter.NEWOBJ_USINGVTABLE.RuntimeInfo.HelperID=NewObj_UsingVtable [end] [begin] Counter.NEWVECTOR_USINGVTABLE=HELPER_CALL Counter.NEWVECTOR_USINGVTABLE.RuntimeInfo.HelperID=NewVector_UsingVtable [end] [begin] Counter.NEWOBJ=HELPER_CALL Counter.NEWOBJ.RuntimeInfo.HelperID=NewObj [end] [begin] Counter.NEWVECTOR=HELPER_CALL Counter.NEWVECTOR.RuntimeInfo.HelperID=NewVector [end] [begin] Counter.NEWMULTIARRAY=HELPER_CALL Counter.NEWMULTIARRAY.RuntimeInfo.HelperID=NewMultiArray [end] [begin] Counter.OBJMONITORENTER=HELPER_CALL Counter.OBJMONITORENTER.RuntimeInfo.HelperID=ObjMonitorEnter [end] [begin] Counter.ObjMonitorExit=HELPER_CALL Counter.ObjMonitorExit.RuntimeInfo.HelperID=ObjMonitorExit [end] [begin] Counter.TYPEMONITORENTER=HELPER_CALL Counter.TYPEMONITORENTER.RuntimeInfo.HelperID=TypeMonitorEnter [end] [begin] Counter.TYPEMONITOREXIT=HELPER_CALL Counter.TYPEMONITOREXIT.RuntimeInfo.HelperID=TypeMonitorExit [end] [begin] Counter.THROW_KEEPSTACKTRACE=HELPER_CALL Counter.THROW_KEEPSTACKTRACE.RuntimeInfo.HelperID=Throw_KeepStackTrace [end] [begin] Counter.THROW_SETSTACKTRACE=HELPER_CALL Counter.THROW_SETSTACKTRACE.RuntimeInfo.HelperID=Throw_SetStackTrace [end] [begin] Counter.THROW_LAZY=HELPER_CALL Counter.THROW_LAZY.RuntimeInfo.HelperID=Throw_Lazy [end] [begin] Counter.ARRAYBOUNDSEXCEPTION=HELPER_CALL Counter.ARRAYBOUNDSEXCEPTION.RuntimeInfo.HelperID=ArrayBoundsException [end] [begin] Counter.ELEMTYPEEXCEPTION=HELPER_CALL Counter.ELEMTYPEEXCEPTION.RuntimeInfo.HelperID=ElemTypeException [end] [begin] Counter.DIVIDEBYZEROEXCEPTION=HELPER_CALL Counter.DIVIDEBYZEROEXCEPTION.RuntimeInfo.HelperID=DivideByZeroException [end] [begin] Counter.THROW_LINKINGEXCEPTION=HELPER_CALL Counter.THROW_LINKINGEXCEPTION.RuntimeInfo.HelperID=Throw_LinkingException [end] [begin] Counter.DIVI32=HELPER_CALL Counter.DIVI32.RuntimeInfo.HelperID=DivI32 [end] [begin] Counter.DIVU32=HELPER_CALL Counter.DIVU32.RuntimeInfo.HelperID=DivU32 [end] [begin] Counter.DIVI64=HELPER_CALL Counter.DIVI64.RuntimeInfo.HelperID=DivI64 [end] [begin] Counter.DIVU64=HELPER_CALL Counter.DIVU64.RuntimeInfo.HelperID=DivU64 [end] [begin] Counter.DIVSINGLE=HELPER_CALL Counter.DIVSINGLE.RuntimeInfo.HelperID=DivSingle [end] [begin] Counter.DIVDOUBLE=HELPER_CALL
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Mikhail Fursov wrote: Good news! However I never believe in 100% :) Leo was claiming 100% of Tomcat's test cases pass -- that's measurable. It's probably the best measure that we have so far for determining that an application 'works'. Well done -- everyone! Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
congratulation! I really like 100% ;-) On 11/1/06, Leo Li [EMAIL PROTECTED] wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM -- Tony Wu China Software Development Lab, IBM
Re: [drlvm][sablevm] Desing of Class Unloading Support
On the 0x214 day of Apache Harmony Mikhail Fursov wrote: On 11/1/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Maybe for GC's that don't support pinning, the JIT can compare object-vtable-class for guarded devirtiualization, or even not do guarded devirtualization, sort of support the GC in downlevel mode I think this is not a long term solution for a JIT. IMO the best solutions for a JIT with unpinned vtables would be 1) Short term: turn devirtualization off (As Egor has proposed) 2) Long term: patch devirtualization calls when GC moves object (usual enumeration routine) agreed. not patching .. just reporting 'golden' VTable refs to GC, am I right? Storing vtable in the object without additional indirection in memory is important from the performance POV. -- Egor Pasko, Intel Managed Runtime Division
Re: [general] Motorola to develop ME under ALv2
AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? On 11/1/06, Tim Ellison [EMAIL PROTECTED] wrote: http://biz.yahoo.com/prnews/061031/cgtu074.html?.v=46 Now *that's* cool :-) For those of you that are not ME-enabled, Motorola is a major player in the ME space. They are deeply involved in advancing the spec and have a track record of developing and collaborating 'in the open'. By declaring their intent to use ALv2 and Apache-style governance we can all look forward to an open and unrestricted exchange with the good folk at Motorola. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Mikhail Fursov
Re: [drlvm][sablevm] Desing of Class Unloading Support
On 01 Nov 2006 15:56:28 +0600, Egor Pasko [EMAIL PROTECTED] wrote: agreed. not patching .. just reporting 'golden' VTable refs to GC, am I right? Yes, and everytime we report it to GC and GC moves an object - it patches the address we report. -- Mikhail Fursov
Re: [classlib] Preprocessor - CHECKPOINT
Geir Magnusson Jr. wrote: Nathan Beyer wrote: What's the concern about just using the prescribed branching pattern for SVN? There are some other nice tricks like externals for pulling in common files into the working copies of other branches (ala the 'concurrent' code in 'standard' that's pulled into 'enhanced' on checkout). Even the authors of SVN warn people away from using externals. Yeah, and a nightmare when trying to 'tag' code -- copying the link to HEAD is no help. I would propose we at least attempt to go down a path of investigating a branching. We should consider everything, but I'd personally rather keep as few codelines as possible. Agreed. Regardless, I think we need to settle on our exact requirement first, before spending too much time on looking for a solution. For example, if logging is a real requirement, but everyone agrees it can be done via instrumentation (AspectJ, java.lang.instrument, etc), then are there any other requirements that affect the actual source files internally? If not, then could all of the other requirements be fulfilled by judicious SCM use? So, I would suggest we back up a little and just layout all of the requirements first, so we can make sure everyone's in agreement about the needs. Nathan is right -- this is hypothetical now, unless (for example) we start on Java 6 development now. Exactly - we need use cases (and it's not clear that the logging problems have been resolved w/ aspects yet...) You're joking, right? I tease the aspect people that logging is the only problem that has been solved(*) g. There are lots of references on how to do that, eg: http://www.developer.com/java/other/article.php/3109831 (*) it's not true though, there are a number of tasks that are well-suited to using aspects. However, I would use them judiciously. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm][sablevm] Desing of Class Unloading Support
On the 0x214 day of Apache Harmony Mikhail Fursov wrote: On 01 Nov 2006 15:56:28 +0600, Egor Pasko [EMAIL PROTECTED] wrote: agreed. not patching .. just reporting 'golden' VTable refs to GC, am I right? Yes, and everytime we report it to GC and GC moves an object - it patches the address we report. so, by saying patching you insist to put immediate operands into instructions? That's probably worth it, but it extends the JIT-GC interface. How about making a simple operand (reg/mem) as the first step? -- Egor Pasko, Intel Managed Runtime Division
Re: [drlvm][iprof] Using Profiling Utility (iprof)
+ Some usage hints: 1. You can get any stylesheet editor (like Excel), open iprof data and build graphs from the colums - and you will have very useful pictures. 2. The disadvantage of iprof is that it counts blocks, insts and helpers calls and does not count time spent in helpers and blocks. You still need VTune to get this info. -- Mikhail Fursov
Re: [general] Motorola to develop ME under ALv2
On the 0x214 day of Apache Harmony Mikhail Fursov wrote: AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? we like to say more free software is not a problem :) On 11/1/06, Tim Ellison [EMAIL PROTECTED] wrote: http://biz.yahoo.com/prnews/061031/cgtu074.html?.v=46 Now *that's* cool :-) For those of you that are not ME-enabled, Motorola is a major player in the ME space. They are deeply involved in advancing the spec and have a track record of developing and collaborating 'in the open'. By declaring their intent to use ALv2 and Apache-style governance we can all look forward to an open and unrestricted exchange with the good folk at Motorola. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Mikhail Fursov -- Egor Pasko, Intel Managed Runtime Division
Re: [classlib] Preprocessor - CHECKPOINT
Etienne Gagnon wrote: Tim Ellison wrote: IMO it's not ideal that the preprocessed source still contains all the streams, albeit in comments. It wouldn't make the source very 'consumable' to the Mrs. SE or ME developer. Hmmm... It's always possible to have a special output mode that puts empty (or advertizing, hehe) comments, instead of other stream code (thus, preserving line numbers). Right, but it was the presence of the comments, not the contents of the comments that I was objecting to. Using padding comments would be bad too IMO. snipped example So, J2ME J2SE end-developers are kept happy. As I said before, I like the idea to be able to flip the comments between different processor targets for the benefit of Harmony developers. So, for example, you can work with your SE spectacles on, and I can work with my ME spectacles on, then we both commit to the repository in a canonical form. However, for the end-user (Mrs Java developer) the processor would strip out the irrelevant streams' code from the canonical form to produce a clean target source code. As a bonu$, you can al$o $tart a nice busine$$ $elling advertizing $pace in $ource code. ;-P LOL -- hey, now you are talking ;-) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [testing][support] Where to place xxxTestCase support classes
Alexey thanks for question, because I'm intereseted in this too As I understand from your discession, for example suport class modules\awt\src\test\api\java\common\java\awt\geom\ShapeTestCase.java should be moved to modules\awt\src\test\support\java\org\apache\harmony\awt\geom\tests\support\ShapeTestCase.java Am I right? 2006/11/1, Ivanov, Alexey A [EMAIL PROTECTED]: Thank you, Nathan, for your reply. I believe these classes can be put to a support package in the module rather than java.* and javax.* correspondingly. I need to try it. At the moment they are along with the tests. But we can't help use javax.swing.* for swing tests since most of them are designed to be run on bootclasspath. See also the related message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591 Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 3:15 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes If the support classes aren't used outside of one module, then I would put them in that module. Like the beans example mentioned. As for the package name, I would prefer to avoid the java.* and javax.* package names whenever possible, so we can avoid classpath issues. -Nathan On 10/31/06, Alexei Zakharov [EMAIL PROTECTED] wrote: FYI in beans we have the following folders for this purpose: src/test/support/java/org/apache/harmony/beans/tests/support src/test/support/java/org/apache/harmony/beans/tests/support/mock Thanks, 2006/10/31, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexei Zakharov, Intel Enterprise Solutions Software Division -- Denis M. Kishenko Intel Middleware Products Division
Re: [drlvm][iprof] Using Profiling Utility (iprof)
On the 0x214 day of Apache Harmony Mikhail Fursov wrote: + Some usage hints: 1. You can get any stylesheet editor (like Excel), open iprof data and build graphs from the colums - and you will have very useful pictures. gnuplot :) 2. The disadvantage of iprof is that it counts blocks, insts and helpers calls and does not count time spent in helpers and blocks. You still need VTune to get this info. 1 more disadvantage: counters are not synchronized resulting in somewhat inaccurate data for multithreaded apps -- Egor Pasko, Intel Managed Runtime Division
Re: [general] Motorola to develop ME under ALv2
01 Nov 2006 16:08:28 +0600, Egor Pasko [EMAIL PROTECTED]: On the 0x214 day of Apache Harmony Mikhail Fursov wrote: AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? At least there'll be no stumbling blocks from legal POV, code can flow freely. Really cool! we like to say more free software is not a problem :) On 11/1/06, Tim Ellison [EMAIL PROTECTED] wrote: http://biz.yahoo.com/prnews/061031/cgtu074.html?.v=46 Now *that's* cool :-) For those of you that are not ME-enabled, Motorola is a major player in the ME space. They are deeply involved in advancing the spec and have a track record of developing and collaborating 'in the open'. By declaring their intent to use ALv2 and Apache-style governance we can all look forward to an open and unrestricted exchange with the good folk at Motorola. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Mikhail Fursov -- Egor Pasko, Intel Managed Runtime Division
Re: [general] Motorola to develop ME under ALv2
Mikhail Fursov wrote: AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? You can see the same statement as me, so it would only be speculation to talk about 'what Motorola want' beyond what they have said already. The cool part is that by choosing ALv2 Harmony can freely engage and exchange with their effort. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
RE: [testing][support] Where to place xxxTestCase support classes
-Original Message- From: Denis Kishenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 1:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes Alexey thanks for question, because I'm intereseted in this too As I understand from your discession, for example suport class modules\awt\src\test\api\java\common\java\awt\geom\ShapeTestCase.java should be moved to modules\awt\src\test\support\java\org\apache\harmony\awt\geom\tests\sup port \ShapeTestCase.java Am I right? Yep. Regards, Alexey. 2006/11/1, Ivanov, Alexey A [EMAIL PROTECTED]: Thank you, Nathan, for your reply. I believe these classes can be put to a support package in the module rather than java.* and javax.* correspondingly. I need to try it. At the moment they are along with the tests. But we can't help use javax.swing.* for swing tests since most of them are designed to be run on bootclasspath. See also the related message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591 Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 3:15 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes If the support classes aren't used outside of one module, then I would put them in that module. Like the beans example mentioned. As for the package name, I would prefer to avoid the java.* and javax.* package names whenever possible, so we can avoid classpath issues. -Nathan On 10/31/06, Alexei Zakharov [EMAIL PROTECTED] wrote: FYI in beans we have the following folders for this purpose: src/test/support/java/org/apache/harmony/beans/tests/support src/test/support/java/org/apache/harmony/beans/tests/support/mock Thanks, 2006/10/31, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexei Zakharov, Intel Enterprise Solutions Software Division -- Denis M. Kishenko Intel Middleware Products Division -- Alexey A. Ivanov Intel Middleware Product Division
Re: [security][testing] 2 tests failed today
Boris Kuznetsov wrote: The tests use tests.support.Support_Exec.execJava2() to perform testing on other JVM. This method uses Runtime.getRuntime().exec() to run command. You can see command (it looks like java -cp classname) in the test's System.out. It woks OK on Win, but produces NoClassDefFoundError on linux. Note, the command woks OK in linux sh also. Yes, I don't think it is the tests for HARMONY-1674 per se that are failing, but they are exposing a problem in the exec -- which is why I haven't rolled back that commit. I'll keep looking at it, let me know if you see the problem. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm][sablevm] Desing of Class Unloading Support
On 01 Nov 2006 16:05:41 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x214 day of Apache Harmony Mikhail Fursov wrote: On 01 Nov 2006 15:56:28 +0600, Egor Pasko [EMAIL PROTECTED] wrote: agreed. not patching .. just reporting 'golden' VTable refs to GC, am I right? Yes, and everytime we report it to GC and GC moves an object - it patches the address we report. so, by saying patching you insist to put immediate operands into instructions? That's probably worth it, but it extends the JIT-GC interface. How about making a simple operand (reg/mem) as the first step? Egor, I thinks this is slightly more complicated problem. If vtable object is moved we must update all devirtualization points in every method compiled before. It can require an extension of JIT-VM-GC interface. Another solution I see is to collect info about all devirtualization points in JIT (code addrs) and report these addresses as enumeration roots. This is JIT-only solution, and disadvantage is a significant (~hot methods count) increase of number of objects reported. On the other hand I see no reasons to unpin vtables in the nearest future (Let's GC guru correct me). If you use special (freelist-type ?) allocator in GC the memory fragmentation when unloading pinned vtable objects could be low. -- Mikhail Fursov
Re: [classlib][xnet] Problem connecting using SSLSocketImpl
Hi Gerald, I'm very happy to hear this issue was fixed. Thank you for your participation in its resolution! With my latest patch supplied with HARMONY-2029 JIRA report you can use Harmony VM and JSSE to work with PKCS12 stores. To adapt your client code for Harmony you should convert JKS trust store to BKS type (or generate new BKS one), and rewrite the following lines of your code: KeyManagerFactory kmf = KeyManagerFactory.getInstance( KeyManagerFactory.getDefaultAlgorithm()); . . . TrustManagerFactory tmf = TrustManagerFactory.getInstance( TrustManagerFactory.getDefaultAlgorithm()); Please feel free to ask if you have any problems with it. Thank You, Alexander Kleymenov On 10/26/06, Gerald Jerome [EMAIL PROTECTED] wrote: Hi Alexander, Great job! This latest patch appears to have fixed the connection issue with SSLSocketImpl and I have started testing renegotiation with our host. Everything appears to be working as expected with no errors. Thanks for hanging in there and getting this fixed. Regards, Gerald Jerome Vnet 262-2375
Re: [drlvm] Class unloading support - tested one approach
+1 for this approach. It will give us some kind of class unloading without much performance impact on GC. -- Ivan On 11/1/06, Robin Garner [EMAIL PROTECTED] wrote: Actually, just thinking about how I would implement this in JikesRVM, I would use the reachability based algorithm, but piggyback on the existing GC mechanisms: - Allocate a byte (or word) in each vtable for the purpose of tracking class reachability. - Periodically, at a time when no GC is running (even the most aggressive concurrent GC algorithms have these, I believe), zero this flag across all vtables. This is the beginning of a class-unloading epoch. - During each GC, when the GC is fetching the GC map for an object, *unconditionally* write a value to the class reachability byte. It may make sense for this byte to be in either the first cache-line of the vtable, or the cache line that points to the GC map - just make sure the mark operation doesn't in general fetch an additional cache line. - At a point in the sufficiently far future, when all reachable objects are known to have been traced by the GC, sweep the vtables and check the reachability of the classloaders. The features of this approach are: - Minimal additional work at GC time. The additional write will cause some additional memory traffic, but a) it's to memory that is already guaranteed to be in L1 cache, and b) it's an unconditional independent write, and c) multiple writes to common classes will be absorbed by the write buffer. - Space cost of at most 1 word per vtable. - This works whether vtables are objects or VM structures - If the relationship between a class and a vtable is not 1:1, this only need affect the periodic sweep process, which should be infrequent and small compared to a GC. - shouldn't need a stop-the-world at any point. I've implemented and tested the GC-relevant part of this in JikesRVM, and the GC time overhead appears to be just under 1% in the MMTk MarkSweep collector. cheers, Robin -- Ivan Intel Enterprise Solutions Software Division
Re: [drlvm][sablevm] Desing of Class Unloading Support
On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 01 Nov 2006 16:05:41 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x214 day of Apache Harmony Mikhail Fursov wrote: On 01 Nov 2006 15:56:28 +0600, Egor Pasko [EMAIL PROTECTED] wrote: agreed. not patching .. just reporting 'golden' VTable refs to GC, am I right? Yes, and everytime we report it to GC and GC moves an object - it patches the address we report. so, by saying patching you insist to put immediate operands into instructions? That's probably worth it, but it extends the JIT-GC interface. How about making a simple operand (reg/mem) as the first step? Egor, I thinks this is slightly more complicated problem. If vtable object is moved we must update all devirtualization points in every method compiled before. It can require an extension of JIT-VM-GC interface. Another solution I see is to collect info about all devirtualization points in JIT (code addrs) and report these addresses as enumeration roots. This is JIT-only solution, and disadvantage is a significant (~hot methods count) increase of number of objects reported. On the other hand I see no reasons to unpin vtables in the nearest future (Let's GC guru correct me). If you use special (freelist-type ?) allocator in GC the memory fragmentation when unloading pinned vtable objects could be low. Yes, vtable should never be moved except for very weird reason. And yes, to pin certain amount of objects is not a big performance issue (in both temporal and spatial wise). -xiaofeng -- Mikhail Fursov
[DRLVM][PORT] correct API to retrieve processor number
Hi, I am using port_CPUs_number() for GCv5 to get the processor number, but my desktop returns one processor with it on Windows although my processor is dual-core. (port_CPUs_number is defined in port_sysinfo.h). I think we need more general form of processor number retrieval API that can return processor information including that of core and hyperthreading. How do you think? Thanks, xiaofeng
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Nice! Post it on the wiki? Leo Li wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html
Re: [general] Motorola to develop ME under ALv2
This is about Motorola and their efforts in the ME ecosystem. The Apache style of open governance has shown itself to be very successful in creating good software, although there are other models that are successful as well (Eclipse Foundation, MySQL). So seeing Motorola embrace that, as well as our license - which gets rid of any license interop for whatever they do - is just a great step forward for the industry as a whole. Back to SE... :) geir Tim Ellison wrote: Mikhail Fursov wrote: AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? You can see the same statement as me, so it would only be speculation to talk about 'what Motorola want' beyond what they have said already. The cool part is that by choosing ALv2 Harmony can freely engage and exchange with their effort. Regards, Tim
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Yes, I have posted it on http://wiki.apache.org/harmony/Apache_Tomcat.:) On 11/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Nice! Post it on the wiki? Leo Li wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM
Re: [drlvm] How to debug the drlvm with gdb?
Mikhail Fursov wrote: Thanks Rana! If you ask me what would I like, the answer is quite simple: as a windows developer primary (today) I would recommend to other windows developers to use msvc build (with patch from HARMONY-1990http://issues.apache.org/jira/browse/HARMONY-1990 ). With this patch you can almost forget about build.bat (it used only to fetch external components + build Java). Most of the internal components (vmcore,JIT,interpreter,gc_cc,encoder,em,hythread,jthread..) could be built and debugged from within MSVC much faster than with build.bat without any code modification with printf(..) and int3-like breakpoints. I'll add this information to the site after H1990 is commited. Done - please check. I just committed. geir On 11/1/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I created a basic debugging page for debugging with the VS debugger on windows. Mikhail and others, make whatever changes you like :-) Rana On 10/24/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 24 Oct 2006 22:42:22 +0700, Egor Pasko [EMAIL PROTECTED] wrote: - Debugging on Windows - Mikhail has been recommended; how's that? the tip from Rana is also useful there. Who can start the page? Mikhail? Rana? I'll do it right after I finish the current task. I do not mind if somebody will pass ahead. This is just the question of tasks priorities. -- Mikhail Fursov
Re: [DRLVM][PORT] correct API to retrieve processor number
I've tried Runtime.getRuntime().availableProcessors() right now and it works
OK to me and reports 2. I have Prescott, 1CPU, 2 hyperthreads, WindowsXP.
JNIEXPORT jint JNICALL
Java_java_lang_VMExecutionEngine_getAvailableProcessors
(JNIEnv *, jclass)
{
return port_CPUs_number();
}
So if it's broken for you it's broken in Java too.
On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, I am using port_CPUs_number() for GCv5 to get the processor
number, but my desktop returns one processor with it on Windows
although my processor is dual-core. (port_CPUs_number is defined in
port_sysinfo.h).
I think we need more general form of processor number retrieval API
that can return processor information including that of core and
hyperthreading.
How do you think?
Thanks,
xiaofeng
--
Mikhail Fursov
Re: [classlib] Preprocessor - CHECKPOINT
Tim Ellison wrote: Geir Magnusson Jr. wrote: Nathan Beyer wrote: What's the concern about just using the prescribed branching pattern for SVN? There are some other nice tricks like externals for pulling in common files into the working copies of other branches (ala the 'concurrent' code in 'standard' that's pulled into 'enhanced' on checkout). Even the authors of SVN warn people away from using externals. Yeah, and a nightmare when trying to 'tag' code -- copying the link to HEAD is no help. I would propose we at least attempt to go down a path of investigating a branching. We should consider everything, but I'd personally rather keep as few codelines as possible. Agreed. Regardless, I think we need to settle on our exact requirement first, before spending too much time on looking for a solution. For example, if logging is a real requirement, but everyone agrees it can be done via instrumentation (AspectJ, java.lang.instrument, etc), then are there any other requirements that affect the actual source files internally? If not, then could all of the other requirements be fulfilled by judicious SCM use? So, I would suggest we back up a little and just layout all of the requirements first, so we can make sure everyone's in agreement about the needs. Nathan is right -- this is hypothetical now, unless (for example) we start on Java 6 development now. Exactly - we need use cases (and it's not clear that the logging problems have been resolved w/ aspects yet...) You're joking, right? I tease the aspect people that logging is the only problem that has been solved(*) g. There are lots of references on how to do that, eg: http://www.developer.com/java/other/article.php/3109831 There's caching too, I think. LogCache4J What I meant was that it didn't seem like we came to a conclusion on it - that if we had a general pre-processing solution, we could use that too for logging, rather than have two. The actual use-cases will help figure this out. geir (*) it's not true though, there are a number of tasks that are well-suited to using aspects. However, I would use them judiciously. Like caching :) (And get your local psychic retainer to tell you what the code is doing... ;) geir Regards, Tim
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Sigh...you must didn't read into it...;-) Leo The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat /Leo Geir Magnusson Jr. wrote: Nice! Post it on the wiki? Leo Li wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Paulex Yang China Software Development Lab IBM
Re: [drlvm][iprof] Using Profiling Utility (iprof)
Is this tuff documented? Wanna throw it in the wiki or a patch for the site? Egor Pasko wrote: On the 0x214 day of Apache Harmony Mikhail Fursov wrote: + Some usage hints: 1. You can get any stylesheet editor (like Excel), open iprof data and build graphs from the colums - and you will have very useful pictures. gnuplot :) 2. The disadvantage of iprof is that it counts blocks, insts and helpers calls and does not count time spent in helpers and blocks. You still need VTune to get this info. 1 more disadvantage: counters are not synchronized resulting in somewhat inaccurate data for multithreaded apps
Re: [DRLVM][PORT] correct API to retrieve processor number
Xiao-Feng Li wrote: Hi, I am using port_CPUs_number() for GCv5 to get the processor number, but my desktop returns one processor with it on Windows although my processor is dual-core. (port_CPUs_number is defined in port_sysinfo.h). I think we need more general form of processor number retrieval API that can return processor information including that of core and hyperthreading. How do you think? I chuckled when I first read this, as if people would disagree - no, I don't think we want to have an API to return accurate information about hardware capability. One thing to keep in mind is to ensure that it's extensible so that non-intel features can be detected as well. Easy portability is key. geir
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Great! Does anything link to that page? IOW, if I started at the top, could I find the page using some reasonable path to get there? geir Leo Li wrote: Yes, I have posted it on http://wiki.apache.org/harmony/Apache_Tomcat.:) On 11/1/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Nice! Post it on the wiki? Leo Li wrote: Hi, all: Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran them both on WindowsXP and Unbuntu, with J9 VM and drlvm. The detailed information about how to build and run tests have been put on http://wiki.apache.org/harmony/Apache_Tomcat. Note: 1. Harmony launches slower than RI, so I add the interval between the launch of Tomcat Server and tests from 8 seconds to 30 seconds to ensure the server has been running. 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I have altered the usage of fork to vfork as a workround despite of the possible side-effect of the latter. mailing thread [1] http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html -- Leo Li China Software Development Lab, IBM
Re: [DRLVM][PORT] correct API to retrieve processor number
Are you using Linux? Don't know why it doesn't work for my Pentium D.
Actually my Windows seems not show two processors at first, while the
API may depend on OS. My Linux has no problem with this.
On the other hand, even your case is undesirable for Hyperthreading
since we probably want more detailed info about processor(s) since
hyperthreading sometimes wants to be treated differently than real SMP
(or dual-core). I believe there is such kind of API available
somewhere, at least NUMA support of Linux from SGI has it.
Anyway before a more comprehensive API available, I really hope PORT
can have my Windows + PentiumD give me two processors. Maybe this
question should go to APR mailing list?
Thanks,
xiaofeng
On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
I've tried Runtime.getRuntime().availableProcessors() right now and it works
OK to me and reports 2. I have Prescott, 1CPU, 2 hyperthreads, WindowsXP.
JNIEXPORT jint JNICALL
Java_java_lang_VMExecutionEngine_getAvailableProcessors
(JNIEnv *, jclass)
{
return port_CPUs_number();
}
So if it's broken for you it's broken in Java too.
On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, I am using port_CPUs_number() for GCv5 to get the processor
number, but my desktop returns one processor with it on Windows
although my processor is dual-core. (port_CPUs_number is defined in
port_sysinfo.h).
I think we need more general form of processor number retrieval API
that can return processor information including that of core and
hyperthreading.
How do you think?
Thanks,
xiaofeng
--
Mikhail Fursov
Re: [DRLVM][PORT] correct API to retrieve processor number
On 11/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: Hi, I am using port_CPUs_number() for GCv5 to get the processor number, but my desktop returns one processor with it on Windows although my processor is dual-core. (port_CPUs_number is defined in port_sysinfo.h). I think we need more general form of processor number retrieval API that can return processor information including that of core and hyperthreading. How do you think? I chuckled when I first read this, as if people would disagree - no, I don't think we want to have an API to return accurate information about hardware capability. One thing to keep in mind is to ensure that it's extensible so that non-intel features can be detected as well. Easy portability is key. Of course, since this is only an API issue. It will cover the vendor-specific information underneath. Along with more and more multi-processor/multi-core/multi-thread platforms available from almost all major processor vendors, it is time to have a proper API for the runtime, unless we give the burden to users with command line options. Well even that, programming-wise we want an API to keep the command line options. Thanks, xiaofeng geir
Re: [DRLVM][PORT] correct API to retrieve processor number
On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Are you using Linux? Don't know why it doesn't work for my Pentium D. Actually my Windows seems not show two processors at first, while the API may depend on OS. My Linux has no problem with this. On the other hand, even your case is undesirable for Hyperthreading since we probably want more detailed info about processor(s) since hyperthreading sometimes wants to be treated differently than real SMP (or dual-core). I believe there is such kind of API available somewhere, at least NUMA support of Linux from SGI has it. I use WindowsXP and here is more detailed info about CPU: Number of processors 1 Number of cores 1 per processor Number of threads 2 (max 2) per processor Name Intel Pentium 4 660 Code Name Prescott Specification Intel(R) Pentium(R) 4 CPU 3.60GHz Package Socket 775 LGA And I see 2 CPUs in Windows Task Manager. Did you tried Runtime.getRuntime().availableProcessors() ? -- Mikhail Fursov
Re: [DRLVM][PORT] correct API to retrieve processor number
Yes, both SUN JRE and DRLVM returns 1 for me. Java API has the same problem. :-) Probably it should introduce an availableCoresPerProcessor() or something more comprehensive. Thanks, xiaofeng On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Are you using Linux? Don't know why it doesn't work for my Pentium D. Actually my Windows seems not show two processors at first, while the API may depend on OS. My Linux has no problem with this. On the other hand, even your case is undesirable for Hyperthreading since we probably want more detailed info about processor(s) since hyperthreading sometimes wants to be treated differently than real SMP (or dual-core). I believe there is such kind of API available somewhere, at least NUMA support of Linux from SGI has it. I use WindowsXP and here is more detailed info about CPU: Number of processors 1 Number of cores 1 per processor Number of threads 2 (max 2) per processor Name Intel Pentium 4 660 Code Name Prescott Specification Intel(R) Pentium(R) 4 CPU 3.60GHz Package Socket 775 LGA And I see 2 CPUs in Windows Task Manager. Did you tried Runtime.getRuntime().availableProcessors() ? -- Mikhail Fursov
Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
Cool, congratulation! BTW, shouldn't this list be ordered somehow? Looks like it will be long enough pretty soon. Or this is a kind of historical document? ;) Just worring about where to put my name when the time (i.e. login) comes. Regards, 2006/10/31, Alexey Petrenko [EMAIL PROTECTED]: Yep. Hurray! It works... finally :) SY, Alexey 2006/10/31, Tim Ellison [EMAIL PROTECTED]: Hurray! [EMAIL PROTECTED] wrote: Author: apetrenko Date: Tue Oct 31 06:57:44 2006 New Revision: 469512 URL: http://svn.apache.org/viewvc?view=revrev=469512 Log: I've added myself to the list of committers. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Geir Magnusson Jr. wrote: Great! Does anything link to that page? IOW, if I started at the top, could I find the page using some reasonable path to get there? Front Page Application Status (in the 'Status' section) There are a number of apps listed there as people test them. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [general] Motorola to develop ME under ALv2
Geir Magnusson Jr. wrote: This is about Motorola and their efforts in the ME ecosystem. The Apache style of open governance has shown itself to be very successful in creating good software, although there are other models that are successful as well (Eclipse Foundation, MySQL). So seeing Motorola embrace that, as well as our license - which gets rid of any license interop for whatever they do - is just a great step forward for the industry as a whole. Back to SE... :) I re-read this, and I didn't come across right here. It sounds like I'm trying to change the subject - I'm not. This is a great thing - as we all think that the Apache Way (whatever that is) is the bees knees so more of it is better. I don't mean stop talking - we can talk about whatever we want. What I meant was I'm going back to all the stuff I want to do on SE... :) geir geir Tim Ellison wrote: Mikhail Fursov wrote: AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? You can see the same statement as me, so it would only be speculation to talk about 'what Motorola want' beyond what they have said already. The cool part is that by choosing ALv2 Harmony can freely engage and exchange with their effort. Regards, Tim
Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
I think you should add it to the end... :) 2006/11/1, Alexei Zakharov [EMAIL PROTECTED]: Cool, congratulation! BTW, shouldn't this list be ordered somehow? Looks like it will be long enough pretty soon. Or this is a kind of historical document? ;) Just worring about where to put my name when the time (i.e. login) comes. Regards, 2006/10/31, Alexey Petrenko [EMAIL PROTECTED]: Yep. Hurray! It works... finally :) SY, Alexey 2006/10/31, Tim Ellison [EMAIL PROTECTED]: Hurray! [EMAIL PROTECTED] wrote: Author: apetrenko Date: Tue Oct 31 06:57:44 2006 New Revision: 469512 URL: http://svn.apache.org/viewvc?view=revrev=469512 Log: I've added myself to the list of committers. -- Alexei Zakharov, Intel Enterprise Solutions Software Division -- Alexey A. Petrenko Intel Middleware Products Division
RE: [drlvm][iprof] Using Profiling Utility (iprof)
I'm going to prepare documentation for iprof for a couple of days Nikolay A. Sidelnikov, SSG/MRTD/DRL/DRL JIT software engineer, Intel Corporation, Novosibirsk e-mail: [EMAIL PROTECTED] phone: +7 383 3340950 ext. 2173 -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 5:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][iprof] Using Profiling Utility (iprof) Is this tuff documented? Wanna throw it in the wiki or a patch for the site? Egor Pasko wrote: On the 0x214 day of Apache Harmony Mikhail Fursov wrote: + Some usage hints: 1. You can get any stylesheet editor (like Excel), open iprof data and build graphs from the colums - and you will have very useful pictures. gnuplot :) 2. The disadvantage of iprof is that it counts blocks, insts and helpers calls and does not count time spent in helpers and blocks. You still need VTune to get this info. 1 more disadvantage: counters are not synchronized resulting in somewhat inaccurate data for multithreaded apps
Re: [DRLVM][PORT] correct API to retrieve processor number
Just a wild guess: this may be caused by x86 emulation on em64t (x86_64). SDK docs advise to use GetNativeSystemInfo() in such case, instead of currently used GetSystemInfo(). (See vm\port\src\misc\win\sysinfo.c). 2006/11/1, Xiao-Feng Li [EMAIL PROTECTED]: Yes, both SUN JRE and DRLVM returns 1 for me. Java API has the same problem. :-) Probably it should introduce an availableCoresPerProcessor() or something more comprehensive. Thanks, xiaofeng On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Are you using Linux? Don't know why it doesn't work for my Pentium D. Actually my Windows seems not show two processors at first, while the API may depend on OS. My Linux has no problem with this. On the other hand, even your case is undesirable for Hyperthreading since we probably want more detailed info about processor(s) since hyperthreading sometimes wants to be treated differently than real SMP (or dual-core). I believe there is such kind of API available somewhere, at least NUMA support of Linux from SGI has it. I use WindowsXP and here is more detailed info about CPU: Number of processors 1 Number of cores 1 per processor Number of threads 2 (max 2) per processor Name Intel Pentium 4 660 Code Name Prescott Specification Intel(R) Pentium(R) 4 CPU 3.60GHz Package Socket 775 LGA And I see 2 CPUs in Windows Task Manager. Did you tried Runtime.getRuntime().availableProcessors() ? -- Mikhail Fursov
Re: [drlvm] Class unloading support - tested one approach
Robin Garner wrote: - Allocate a byte (or word) in each vtable for the purpose of tracking class reachability. Yep, there's no reason to keep the bits (or words, for performance) in the class loader, even in the approach I've proposed. They could be moved to the vtable. Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: 235 tests are missed at DRLVM test run for Windows
Alexei, 2. If I suggested an enhancement, this would be an addition of a test name filter for comparison results. I mean that if I'm interested in Bidi tests comparison, I put Bidi into form field (name=Bidi) and see a comparison for the tests which names contain the specified substring. Feature request accepted :) 3. When I use Open in a new window for a list of tags, IE opens a copy of the initial window. When I do a left click, there is no scroll bar at the pop up window, and the list of tags doesn't fit the window. Thanks, scrollbars were added. -- Regards, Anton Luht, Intel Java XML Engineering
Re: 235 tests are missed at DRLVM test run for Windows
Alexey, 1) allow to compare by exact id - e.g. I failed to compare #90 and #91 due to missing tags. First, you can obtain login (ask any registered user to add you) and tag runs you are interested in. Second - you can do it if you enter two result ids into URL: http://harmonytest.org/diff.do?method=viewid=id1id2=id2 2) add filtering by tags on the main page - e.g. to see only drl or only linux results. Feature request accepted - I think there will be ~20..30 latest results on the first page and 'Search' link that will allow to search by tags, other run properties (like uploader name - old request from Tony Wu) -- Regards, Anton Luht, Intel Java XML Engineering
RE: 235 tests are missed at DRLVM test run for Windows
Tim, As far as I know IBM has at least four different JVMs. This makes me think it would be more precise to name JVM exactly. If blue giant guys like current tags, let's leave the tags as is. I don't really think that any tag name would be a reason for researchers from the Jikes team not to join us in using http://harmonytest.org. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:13 AM To: harmony-dev@incubator.apache.org Subject: Re: 235 tests are missed at DRLVM test run for Windows Fedotov, Alexei A wrote: 4. I vote for one of the following renamings: a) Rename ibm tag to j9 b) Rename drl tag to intel :-). That looks like a strange suggestion to me. I think the tags are fine as they are. What is you thinking? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
RE: [classlib] Preprocessor - CHECKPOINT
Regardless, I think we need to settle on our exact requirement first, before spending too much time on looking for a solution. +1 This exactly matches my morning metro thoughts. Nathan, thanks for catching this point. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:06 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT What's the concern about just using the prescribed branching pattern for SVN? There are some other nice tricks like externals for pulling in common files into the working copies of other branches (ala the 'concurrent' code in 'standard' that's pulled into 'enhanced' on checkout). I would propose we at least attempt to go down a path of investigating a branching. Regardless, I think we need to settle on our exact requirement first, before spending too much time on looking for a solution. For example, if logging is a real requirement, but everyone agrees it can be done via instrumentation (AspectJ, java.lang.instrument, etc), then are there any other requirements that affect the actual source files internally? If not, then could all of the other requirements be fulfilled by judicious SCM use? So, I would suggest we back up a little and just layout all of the requirements first, so we can make sure everyone's in agreement about the needs. -Nathan On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So we all agree that it's not an ideal solution. Can anyone think of anything else? No one said this was going to be easy... geir
Re: 235 tests are missed at DRLVM test run for Windows
Anton Luht wrote: Alexei, 2. If I suggested an enhancement, this would be an addition of a test name filter for comparison results. I mean that if I'm interested in Bidi tests comparison, I put Bidi into form field (name=Bidi) and see a comparison for the tests which names contain the specified substring. Feature request accepted :) 3. When I use Open in a new window for a list of tags, IE opens a copy of the initial window. When I do a left click, there is no scroll bar at the pop up window, and the list of tags doesn't fit the window. Thanks, scrollbars were added. Could the tags be in a list instead of freely typed? Let me select multiple?
RE: [classlib] Preprocessor - CHECKPOINT
Etienne, The example is quite interesting. But the idea of selling comment space for advertising really rocks! :-) With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Etienne Gagnon [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:25 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT Tim Ellison wrote: IMO it's not ideal that the preprocessed source still contains all the streams, albeit in comments. It wouldn't make the source very 'consumable' to the Mrs. SE or ME developer. Hmmm... It's always possible to have a special output mode that puts empty (or advertizing, hehe) comments, instead of other stream code (thus, preserving line numbers). To continue on my earlier example: Java source = j2se end-developer --- ... // Download Harmony[tm] from // // http://the.nice.harmony.url/download // // :-) @Processor(Not in j2me!) int some_field = some + initializing() code; ... Or, more likely: Java source = j2se end-developer --- ... // Please ignore this comment. It has been // intentionally left here to preserve line numbers // for bug reporting purpose. // // Please report bugs to http://bugs.of.harmony.url/... @Processor(Not in j2me!) int some_field = some + initializing() code; ... So, J2ME J2SE end-developers are kept happy. As a bonu$, you can al$o $tart a nice busine$$ $elling advertizing $pace in $ource code. ;-P Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
Re: [drlvm] Class unloading support - tested one approach
Interesting idea! It seems the real issue is marking and sweeping the vtables. A stab at categorizing the approaches: a) Force vtables to be as similar to ordinary java objects as possible. The upside: existing GC algorithms will work unaltered. The downside is vtables of vtables of vtables... This has already been discussed at length. b) Force vtables to live and die in a unique vtable space. The big challenge seems to be building a custom GC algorithm that is simpler and less invasive than doing a) above. Most likely the performance of the custom GC algorithm will never be an issue. Vtables have some very interesting properties that may make this doable. The 4 (or 8) bytes at offset K always point to a class structure which, in turn, always has a pointer at offset Z back to the vtable. There are way fewer vtables than objects. For practical reasons, it can be assumed that vtables will always be pinned. The number of class structs/objects is no greater than the number of vtables. I guess ... the issue of where vtables and other classloader related structures lives seems to me to be simple engineering. Whether they are malloced in the C heap or 'new'ed in an immovable Java heap makes little difference. After all they are very very small compared to the rest of the heap. A half-baked scheme that might be good enough: Partition off 50 megabytes as a hard, fixed vtables space. Then do a word-by-word scan to pick up candidate pointers class structs. Then filter the candidate class struct pointers by verifying the back pointers. Occasionally there might be floating garbage with this approach but a valid, live vtable should never be accidentally freed. The filtered set are the live vtables. Next scan the live vtables looking for members that were never marked by the regular GC as mentioned below. When found, zero the vtable, link-list on a free vtable space list, mark the class struct as vtable-less. Process the vtable-less class struct, etc... This sounds a bit complicated - i'm sure it could be done by maintaining linked lists of all the classes loaded by each classloader (pointing to vtables from there) and traversing it. Traverse this once, propagating the mark bits upwards and you are done. It seems as long as part of the system is built using garbage collected java objects and part of the system is built using malloc/free C structs, the problem of releasing connected objects/C_structs will be messy and hacky. In a sense, this issue is really a motivation for re-writing the whole VM in Java... hmmm... Well in Java-in-Java you would hardly want to do a full trace operation for every vtable pointer - that would be quite costly imo, because in a full gc you do a test-and-set, then conditionally copy and/or enqueue for scanning. So there's a dependent load and conditional store, and the test to detect the gc policy for the vtable space. And you really don't want to have moveable vtables. The cost of updating the forwarding pointers alone would be a killer, let alone the engineering difficulties. There are definitely reasons to write a VM in java, but I don't believe this is one of them! As I say below I wouldn't do class unloading on top of the standard GC mechanism - I would do it in the VM, using a hook from the GC's tracing. On 10/31/06, Robin Garner [EMAIL PROTECTED] wrote: Actually, just thinking about how I would implement this in JikesRVM, I would use the reachability based algorithm, but piggyback on the existing GC mechanisms: - Allocate a byte (or word) in each vtable for the purpose of tracking class reachability. - Periodically, at a time when no GC is running (even the most aggressive concurrent GC algorithms have these, I believe), zero this flag across all vtables. This is the beginning of a class-unloading epoch. - During each GC, when the GC is fetching the GC map for an object, *unconditionally* write a value to the class reachability byte. It may make sense for this byte to be in either the first cache-line of the vtable, or the cache line that points to the GC map - just make sure the mark operation doesn't in general fetch an additional cache line. - At a point in the sufficiently far future, when all reachable objects are known to have been traced by the GC, sweep the vtables and check the reachability of the classloaders. The features of this approach are: - Minimal additional work at GC time. The additional write will cause some additional memory traffic, but a) it's to memory that is already guaranteed to be in L1 cache, and b) it's an unconditional independent write, and c) multiple writes to common classes will be absorbed by the write buffer. - Space cost of at most 1 word per vtable. - This works whether vtables are objects or VM structures - If the relationship between a class and a vtable is not 1:1, this only need affect the periodic sweep process, which should be
RE: [classlib] Preprocessor - CHECKPOINT
Sorry for spam, I bet if you could convince some investor that it was a web2.0 thing, you could get it funded I believe I know one investor - just convince G**gle to distribute AJAX modules for his code search engine which would automatically insert comments with code sensitive advertisement. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:39 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT Etienne Gagnon wrote: Tim Ellison wrote: IMO it's not ideal that the preprocessed source still contains all the streams, albeit in comments. It wouldn't make the source very 'consumable' to the Mrs. SE or ME developer. Hmmm... It's always possible to have a special output mode that puts empty (or advertizing, hehe) comments, instead of other stream code (thus, preserving line numbers). To continue on my earlier example: Java source = j2se end-developer --- ... // Download Harmony[tm] from // // http://the.nice.harmony.url/download // // :-) @Processor(Not in j2me!) int some_field = some + initializing() code; ... Or, more likely: Java source = j2se end-developer --- ... // Please ignore this comment. It has been // intentionally left here to preserve line numbers // for bug reporting purpose. // // Please report bugs to http://bugs.of.harmony.url/... @Processor(Not in j2me!) int some_field = some + initializing() code; ... So, J2ME J2SE end-developers are kept happy. I'm still not quite getting the importance of preserving the line numbers like that if we have some minimal tooling to let us work with it in eclipse or IDEA invisibly users would report bug at line X, and we'd either look at the transformed code that they are actually using, and translate backwards, or have a plugin that lets us A/B between transformed and original. The key is to play with some examples, I guess. As a bonu$, you can al$o $tart a nice busine$$ $elling advertizing $pace in $ource code. ;-P It's our idea - you run with it. let us know how that works out. (I bet if you could convince some investor that it was a web2.0 thing, you could get it funded) Etienne
[classlib][portlib] Docs?
Guys, do we have any docs on portlib? SY, Alexey -- Alexey A. Petrenko Intel Middleware Products Division
RE: [classlib][portlib] Docs?
Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib]Harmony passes 100% testcases of Tomcat5.5
Tim Ellison wrote: Geir Magnusson Jr. wrote: Great! Does anything link to that page? IOW, if I started at the top, could I find the page using some reasonable path to get there? Front Page Application Status (in the 'Status' section) There are a number of apps listed there as people test them. Yes, and I suggest we always add links to this page when somebody creates a wiki page for application test, a few days ago, I just added several links to it(IIRC, Eclipse, Tomcat, Log4j...), because I thought they should be there but couldn't find... Regards, Tim -- Paulex Yang China Software Development Lab IBM
Re: [classlib][portlib] Docs?
If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM
[doc] EM minor typos are corrected
Folks, Some minor typos were discovered in the Execution Manager Component Description. In cooperation with Mikhail Fursov we've created a couple of necessary patches [http://issues.apache.org/jira/browse/HARMONY-2036]. Would be great, if someone can find a chance to look at them and apply. Thanks in advance. Best regards, Svetlana Konovalova
Re: [doc] No Doxygen reference for code :(
Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1. Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2. Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM
Re: [classlib][portlib] Docs?
Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! The docs are generated directly from the code using Doxygen. They went away with that fateful delete of the doc subdir, but can be regenerated. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [security][testing] 2 tests failed today
Fixed in r469902. Turns out the exec was putting double quotes around the classpath argument (which might make sense if it was going to a shell) but it doesn't for an exec syscall. This resulted in classes being search for in the non-existent directory: /path/to/modules/luni/bin/test rather than: /path/to/modules/luni/bin/test Regards, Mark - confused as to why it didn't also fail on windows On 1 November 2006 at 10:37, Tim Ellison [EMAIL PROTECTED] wrote: Boris Kuznetsov wrote: The tests use tests.support.Support_Exec.execJava2() to perform testing on other JVM. This method uses Runtime.getRuntime().exec() to run command. You can see command (it looks like java -cp classname) in the test's System.out. It woks OK on Win, but produces NoClassDefFoundError on linux. Note, the command woks OK in linux sh also. Yes, I don't think it is the tests for HARMONY-1674 per se that are failing, but they are exposing a problem in the exec -- which is why I haven't rolled back that commit. I'll keep looking at it, let me know if you see the problem. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [classlib][portlib] Docs?
Having these docs on website will be really good! SY, Alexey 2006/11/1, Paulex Yang [EMAIL PROTECTED]: If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM
RE: [doc] No Doxygen reference for code :(
About your question It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? I'd say, we can place classlib docs inside standard/site/xdocs/subcomponents/classlib/Doxygen. Do you think we'll need subfolders for classlib modules inside that? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. I'd be glad to help. What kind of patch do you need? I can build the docs locally and post a JIRA with the archive. I can also fix the site to have a link to the index.html produced by Doxygen. Is that what you mean? Thank you, Nadya Morozova -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:33 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] No Doxygen reference for code :( Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1.Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2.Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM
Re: [security][testing] 2 tests failed today
2006/11/1, Tim Ellison [EMAIL PROTECTED]: Mark Hindess wrote: Fixed in r469902. Turns out the exec was putting double quotes around the classpath argument (which might make sense if it was going to a shell) but it doesn't for an exec syscall. This resulted in classes being search for in the non-existent directory: /path/to/modules/luni/bin/test rather than: /path/to/modules/luni/bin/test Regards, Mark - confused as to why it didn't also fail on windows ...but, AIUI the code worked ok on Linux with DRLVM. Can somebody confirm that? This is true - DRLVM has it's own impl of Process. I'll raise this issue in a separate thread. Tim - even more confused -- Tim Ellison ([EMAIL PROTECTED])
RE: [doc] No Doxygen reference for code :(
Nadya, Thanks for answers. You have a nice approach to the requirement engineering for the documentation build system. It would be great if you also add priorities for your requirements. Looking into your original list of requirements, I've noticed I haven't addressed the second one: 2. Ability to see docs on the website Yesterday I'd added an archive with documentation to HARMONY-2024 http://issues.apache.org/jira/browse/HARMONY-2024, so committers could now put documentation to the web site and everyone could contribute to the documentation quality. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 9:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, Thanks for meaningful and numerous questions, Alexei. I have thought of some of these, but you give it a systematic touch :) Others' opinions are welcome, mine in below - marked with [NM]. Related question: do we want to have some version of API doc on the site now? I've experimented with building docs, and could produce a working bundle. We can work to enable the build create API docs locally in parallel with that. PS: Geir, there's a specific question for you below. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 7:49 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, All, Suggestion to generate Doxygen from DRLVM code sounds very interesting. I posted a quick solution for Linux to http://issues.apache.org/jira/browse/HARMONY-2024 [NM] great news, I'll see if I can do smth similar for Windows. If you want to have this integrated into build.xml, it would be great to define a correct scope. Could you please give more details what do you expect from the documentation build file? [NM] I'd give it a try. Please don't expect me to write a design doc for you A volunteer can try doing some things important for you first, and then add new features gradually. [NM] yeah, I like the idea of a gradual step-by-step process. * Should doxygen build documentation for inter-component interfaces? [NM] sure, and I guess it's the better-documented part ;) * What are components? I assume vm, jit, gc are out of the question. Is am execution manager or an interpreter a separate component? [NM] see dev guide; we've thought components roughly match to top-level folders: EM, Interpreter, TM are all components. Not sure what to do with the three GCs now, though. * Should doxygen build documentation for each component like vm, jit, interpreter, gc? [NM] It's my dream and very convenient. Getting Doxygen to run for half-hour and get hung doesn't seem an attractive prospect. However, I guess we can get some primitive build as a start and add component-specific build targets later. For me, an ideal list of targets for Doxygen would be something like: all - all headers for DRLVM/classlib (one of two, not both in one bundle) inter-component - headers in include/ folder basically. Do we have any high-level interfaces in other places? This could show the big picture and somehow map to the arch description. component - headers for the component name specified. We might concentrate on the first two now for simplicity and smaller scope. * Should we put documentation into doc/component_doc dirs as class library code does? [NM] this is a complex issue. I know Geir has wanted to add website to the snapshot. *Geir*, could you express your view on where to place docs? I guess separating normal docs and autogenerated docs would be good, like the /doc/ folder for all files, with /doc/Doxygen/ subfolder for API reference. When we are ready to build component-specific reference, /doc/Doxygen/ can have subfolders for each. * Should we use the same formatting as a class library documentation? [NM] why not? as I've noticed, default formatting is ok, but there are many options you can enable/disable, e.g. diagram for class hierarchy. * We don't need to process .cpp files in DRLVM source tree, do we? [NM] no, I guess not. A developer that needs explanation in .cpp would rather look into the code, I guess. * Would each of these choices (inter-component documentation, component interface documentation) be a separate configuration? If yes, should we put each result into the separate directory? * Should doxygen process .java files in DRLVM source tree? * Should the doxygen documentation be integrated with class library documentation? [NM] I hope we can have two different bundles. Otherwise, it'd take our poor Doxygen a day to compile the docs :) we can cross-reference the two index.html files. Can you estimate, how often you'd want to link from a vm header description into classlib? * Do you expect to have inheritance diagrams? [NM] I don't know. From what I see, you
Re: [classlib] Preprocessor - CHECKPOINT
Geir Magnusson Jr. wrote: There's caching too, I think. LogCache4J What I meant was that it didn't seem like we came to a conclusion on it - that if we had a general pre-processing solution, we could use that too for logging, rather than have two. The actual use-cases will help figure this out. Here two typical some use cases, and some proposed solutions: Problem --- logging, and other situations where you really don't want to put the additional source code in the main source files Solution use aspects (Plug: you might want to give a look at the optimizing abc compiler) Problem --- supporting a different API specifications/versions, such as j2me and j2se1.4, in addition to the main version (e.g. j2se1.5) Solution This is a trickier problem. We can divide the problem at two main levels: 1- file/directory level 2- source-code level At the file/directory level, each version (e.g. j2me, j2se1.4, ...) might include additional files (relative to the main version), and might not include some files of the main version. In other words, j2me might not contain database APIs. Managing file inclusion/exclusion can be done in various ways. a) ant based: use distinct ant (sub-)files for each version. The problem is that IDEs (e.g. Eclipse) will most likely show some of the excluded files in its class/files browser. This wouldn't be very elegant. It also implies always compiling through ant files. Of course, one could develop Eclipse-specific configuration files to mimic the inclusion/exclusion of ant files, but then, this opens the door for discrepancies between ant vs eclipse inclusion/exclusion lists. I don't like it. b) custom-tool based: the custom processing tool I proposed could also parse inclusion/exclusion lists, and use these lists to move files around, in addition to processing the content of unmoved files. For example, if class X of the main version is not part of j2me, process(j2me) would move this file to a subdirectory .streams/. If a class Y is not in the main version (the one used for svn ci), it resides in subdirectory .streams in the trunk. process(j2me) moves this file into the normal directory. As for IDEs, now you can configure them to automatically exclude .stream/ directories. Inclusion/exclusion could be managed in two ways: 1- the processing tool could look for inclusion/exclusion list files, such as j2me.inclusion, j2me.exclusion, main.inclusion, main.exclusion, etc. This would lead to the best performance (for process(X)), yet it does require much manual update of inclusion/exclusion lists, with all the discrepancies that result from human mistakes while updating these files. 2- (my preferred way), directives, at the beginning of the source code would indicate whether a file is included in a version or not. Depending on target, the file would be moved to the appropriate directory (normal, .streams). Of course, there's also the problem of non-source files, i.e. resources. IMO, resources could be managed using specific directories (.main/, .j2me, .j2se1.4) and a .shared/ directory with symbolic links in the specific directories. As for source-level management, you would use my proposed processing tool to view the source files with the right spectacles [as Tim said so elegantly:-)]. For development targets, it is important that: revert(process(X, target)) = X By development target I mean a target that is meant for Harmony developers in prevision of reverting modified code to a format suitable for svn ci (i.e. revert to main target). For comfortable IDE development, one could imagine that the IDE editor can reduce to one-line visible comments (or better, specially formatted ones) so that it gives you the impression that you are really wearing target-specific spectacles. [I know Eclipse allows for such things already]. To release code, one would apply: process(X, release-target) = Y Now, it is important to understand that Y, in this case, is NOT suitable for doing any modification as revert(Y) = Kaboom! (The tool will simply report that it can't do it; it won't crash.) Yet, I think that it would be important that the processing tool leaves markers in Y, so that we could also have a tool to help finding the canonical source line of a reported bug: revertLine(Y, L') = L (where L' is a line reported by end-developer, and L the related line in svn). Markers would be short single lines comments, so the end-developer annoyance would be kept minimal. What do you think? I am really offering to develop this custom tool. Just help me identify various Harmony needs I might have missed! Of course, this tool is not the best solution to ALL problems, yet, so far, I think that it seems to best address the problem of supporting various API
Re: [doc] No Doxygen reference for code :(
I think that we can place the docs here: http://incubator.apache.org/harmony/subcomponents/classlibrary/index.html 2006/11/1, Paulex Yang [EMAIL PROTECTED]: Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1.Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2.Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM
Re: 235 tests are missed at DRLVM test run for Windows
2006/11/1, Anton Luht [EMAIL PROTECTED]: Alexey, 1) allow to compare by exact id - e.g. I failed to compare #90 and #91 due to missing tags. First, you can obtain login (ask any registered user to add you) and tag runs you are interested in. Still I have to do extra steps while searching, looking for latest run among other equally tagged, etc. Second - you can do it if you enter two result ids into URL: http://harmonytest.org/diff.do?method=viewid=id1id2=id2 Uhm, I'm not going to rememeber all that urls and parameters. Why not to provide extra field? Or better yet, provide such field on the main page: Compare 2 results [123 125] which accepts common separators (white spaces and comma). Thank you in advance :) 2) add filtering by tags on the main page - e.g. to see only drl or only linux results. Feature request accepted - I think there will be ~20..30 latest results on the first page and 'Search' link that will allow to search by tags, other run properties (like uploader name - old request from Tony Wu) -- Regards, Anton Luht, Intel Java XML Engineering
RE: [doc] No Doxygen reference for code :(
Alexei, One note: I'm *not* writing requirements for engineering on the doc build system. I'm just sharing my thoughts on an issue that interests me. Discussion is welcome. Please don't consider my ideas as the way it should be. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:52 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, Thanks for answers. You have a nice approach to the requirement engineering for the documentation build system. It would be great if you also add priorities for your requirements. Looking into your original list of requirements, I've noticed I haven't addressed the second one: 2. Ability to see docs on the website Yesterday I'd added an archive with documentation to HARMONY-2024 http://issues.apache.org/jira/browse/HARMONY-2024, so committers could now put documentation to the web site and everyone could contribute to the documentation quality. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 9:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, Thanks for meaningful and numerous questions, Alexei. I have thought of some of these, but you give it a systematic touch :) Others' opinions are welcome, mine in below - marked with [NM]. Related question: do we want to have some version of API doc on the site now? I've experimented with building docs, and could produce a working bundle. We can work to enable the build create API docs locally in parallel with that. PS: Geir, there's a specific question for you below. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 7:49 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, All, Suggestion to generate Doxygen from DRLVM code sounds very interesting. I posted a quick solution for Linux to http://issues.apache.org/jira/browse/HARMONY-2024 [NM] great news, I'll see if I can do smth similar for Windows. If you want to have this integrated into build.xml, it would be great to define a correct scope. Could you please give more details what do you expect from the documentation build file? [NM] I'd give it a try. Please don't expect me to write a design doc for you A volunteer can try doing some things important for you first, and then add new features gradually. [NM] yeah, I like the idea of a gradual step-by-step process. * Should doxygen build documentation for inter-component interfaces? [NM] sure, and I guess it's the better-documented part ;) * What are components? I assume vm, jit, gc are out of the question. Is am execution manager or an interpreter a separate component? [NM] see dev guide; we've thought components roughly match to top-level folders: EM, Interpreter, TM are all components. Not sure what to do with the three GCs now, though. * Should doxygen build documentation for each component like vm, jit, interpreter, gc? [NM] It's my dream and very convenient. Getting Doxygen to run for half-hour and get hung doesn't seem an attractive prospect. However, I guess we can get some primitive build as a start and add component-specific build targets later. For me, an ideal list of targets for Doxygen would be something like: all - all headers for DRLVM/classlib (one of two, not both in one bundle) inter-component - headers in include/ folder basically. Do we have any high-level interfaces in other places? This could show the big picture and somehow map to the arch description. component - headers for the component name specified. We might concentrate on the first two now for simplicity and smaller scope. * Should we put documentation into doc/component_doc dirs as class library code does? [NM] this is a complex issue. I know Geir has wanted to add website to the snapshot. *Geir*, could you express your view on where to place docs? I guess separating normal docs and autogenerated docs would be good, like the /doc/ folder for all files, with /doc/Doxygen/ subfolder for API reference. When we are ready to build component-specific reference, /doc/Doxygen/ can have subfolders for each. * Should we use the same formatting as a class library documentation? [NM] why not? as I've noticed, default formatting is ok, but there are many options you can enable/disable, e.g. diagram for class hierarchy. * We don't need to process .cpp files in DRLVM source tree, do we? [NM] no, I guess not. A developer that needs explanation in .cpp would rather look into the code, I guess. * Would each of these choices (inter-component documentation, component interface documentation) be a separate configuration? If yes, should we put each result into the separate directory? * Should doxygen
[DRLVM] ipf initial support (interpreter mode)
Hi All, DRLVM now builds and run (interpreter mode) on IPF with HARMONY-2004. The patch should cause no changes on other architectures. Currently, in interpreter mode everything works fine but GC. GC fails. I'm investigating this issue. -- Ivan Intel Enterprise Solutions Software Division
RE: [doc] No Doxygen reference for code :(
+1 my idea exactly Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:55 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] No Doxygen reference for code :( I think that we can place the docs here: http://incubator.apache.org/harmony/subcomponents/classlibrary/index.htm l 2006/11/1, Paulex Yang [EMAIL PROTECTED]: Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1.Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2.Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM
Re: [security][testing] 2 tests failed today
Mark Hindess wrote: Fixed in r469902. Turns out the exec was putting double quotes around the classpath argument (which might make sense if it was going to a shell) but it doesn't for an exec syscall. This resulted in classes being search for in the non-existent directory: /path/to/modules/luni/bin/test rather than: /path/to/modules/luni/bin/test Regards, Mark - confused as to why it didn't also fail on windows Looks like we *do* need the quotes on Windows, I get a local failure now. K0319java.lang.NoClassDefFoundError: Files\QuickTime\QTSystem\QTJava.zip;C:\Program FAILED to invoke JVM. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [classlib] Preprocessor - CHECKPOINT
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote: Problem --- supporting a different API specifications/versions, such as j2me and j2se1.4, in addition to the main version (e.g. j2se1.5) Solution This is a trickier problem. We can divide the problem at two main levels: 1- file/directory level 2- source-code level At the file/directory level, each version (e.g. j2me, j2se1.4, ...) might include additional files (relative to the main version), and might not include some files of the main version. In other words, j2me might not contain database APIs. Managing file inclusion/exclusion can be done in various ways. Just my $0.02: IMO it's unreal to support J2SE 1.4 1.5 in the same source. Too many differences in the language due to generics. This example needs branches weekly manual merges (not a big problem imho) -- Mikhail Fursov
Re: [DRLVM] ipf initial support (interpreter mode)
Great news! The time when x86 changes can affect IPF build is come :) Ivan, have you tried gcv4? On 11/1/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Hi All, DRLVM now builds and run (interpreter mode) on IPF with HARMONY-2004. The patch should cause no changes on other architectures. Currently, in interpreter mode everything works fine but GC. GC fails. I'm investigating this issue. -- Ivan Intel Enterprise Solutions Software Division -- Mikhail Fursov
[doc]Please help to remove outdated info from the site
Folks, You might know that certain Harmony pages are out-of-date and need to be modified. One of such pages is http://incubator.apache.org/harmony/status.html . Now I'm working at creating the Build our Own Website Using Ant section for this very page. Would be great, if someone can find a chance to look at it to help me through away outdated info. Thanks in advance! Best regards, Sveta Konovalova
Re: [classlib] Preprocessor - CHECKPOINT
Mikhail Fursov wrote: At the file/directory level, each version (e.g. j2me, j2se1.4, ...) ... Just my $0.02: IMO it's unreal to support J2SE 1.4 1.5 in the same source. Too many differences in the language due to generics. This example needs branches weekly manual merges (not a big problem imho) You're absolutely right! I wasn't thinking about it when I took that example. This is really a typical case (j2se 1.4) where using svn branches is the right solution. But, for j2me1.5, java for credit cards 1.5 and j2se1.6 (maybe, if they don't redesign the Java syntax, etc.), I think that a tool along the lines I was proposing would be best. Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: [classlib][portlib] Docs?
yeah - someone generate, and we can hang them on the website. I'm not sure we'd want to check them in though... I've done this before for API docs... geir Alexey Petrenko wrote: Having these docs on website will be really good! SY, Alexey 2006/11/1, Paulex Yang [EMAIL PROTECTED]: If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM
Re: [DRLVM] ipf initial support (interpreter mode)
Mikhail, Yes, I did. It fails at bootstrap on attempt to pin an object. This functionality was disabled in GCv4.1 some time ago, because of massive pin counter overflows detected on classlib/em64t. I going to check this specific problem at some time in future. It looks like some code on IPF operates with invalid pointers to java heap and it leads to heap corruption. We just need to identify such places and fix them :) -- Ivan On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Great news! The time when x86 changes can affect IPF build is come :) Ivan, have you tried gcv4? On 11/1/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Hi All, DRLVM now builds and run (interpreter mode) on IPF with HARMONY-2004. The patch should cause no changes on other architectures. Currently, in interpreter mode everything works fine but GC. GC fails. I'm investigating this issue.
Re: 235 tests are missed at DRLVM test run for Windows
Feature requests from Geir (multiple select for tags) and Alexey (shortcut to compare two runs from the first page) are accepted and put in the implemetation queue. -- Regards, Anton Luht, Intel Java XML Engineering
Re: [classlib] Preprocessor - CHECKPOINT
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote: For comfortable IDE development, one could imagine that the IDE editor can reduce to one-line visible comments (or better, specially formatted ones) so that it gives you the impression that you are really wearing target-specific spectacles. [I know Eclipse allows for such things already]. To release code, one would apply: process(X, release-target) = Y Now, it is important to understand that Y, in this case, is NOT suitable for doing any modification as revert(Y) = Kaboom! (The tool will simply report that it can't do it; it won't crash.) Etienne, What is 'comfortable IDE development' if you can't modify the Y? Am I missing something here? -- Mikhail Fursov
Re: [DRLVM][PORT] correct API to retrieve processor number
On 11/1/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Just a wild guess: this may be caused by x86 emulation on em64t (x86_64). SDK docs advise to use GetNativeSystemInfo() in such case, instead of currently used GetSystemInfo(). (See vm\port\src\misc\win\sysinfo.c). huh, I guess you are right, since my machine is X86-64bit. :-) I will try the API you pointed. Thanks, xiaofeng 2006/11/1, Xiao-Feng Li [EMAIL PROTECTED]: Yes, both SUN JRE and DRLVM returns 1 for me. Java API has the same problem. :-) Probably it should introduce an availableCoresPerProcessor() or something more comprehensive. Thanks, xiaofeng On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Are you using Linux? Don't know why it doesn't work for my Pentium D. Actually my Windows seems not show two processors at first, while the API may depend on OS. My Linux has no problem with this. On the other hand, even your case is undesirable for Hyperthreading since we probably want more detailed info about processor(s) since hyperthreading sometimes wants to be treated differently than real SMP (or dual-core). I believe there is such kind of API available somewhere, at least NUMA support of Linux from SGI has it. I use WindowsXP and here is more detailed info about CPU: Number of processors 1 Number of cores 1 per processor Number of threads 2 (max 2) per processor Name Intel Pentium 4 660 Code Name Prescott Specification Intel(R) Pentium(R) 4 CPU 3.60GHz Package Socket 775 LGA And I see 2 CPUs in Windows Task Manager. Did you tried Runtime.getRuntime().availableProcessors() ? -- Mikhail Fursov
Re: [general] Motorola to develop ME under ALv2
Fantastic! It will be very tempting to read the [JME][J2SE] blah, blah... emails on harmony-dev. But this is actually a good problem to have :) On 11/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: This is about Motorola and their efforts in the ME ecosystem. The Apache style of open governance has shown itself to be very successful in creating good software, although there are other models that are successful as well (Eclipse Foundation, MySQL). So seeing Motorola embrace that, as well as our license - which gets rid of any license interop for whatever they do - is just a great step forward for the industry as a whole. Back to SE... :) I re-read this, and I didn't come across right here. It sounds like I'm trying to change the subject - I'm not. This is a great thing - as we all think that the Apache Way (whatever that is) is the bees knees so more of it is better. I don't mean stop talking - we can talk about whatever we want. What I meant was I'm going back to all the stuff I want to do on SE... :) geir geir Tim Ellison wrote: Mikhail Fursov wrote: AFAIK ME shares a lot of core classes and packages with SE. And we have these packages implemented. And now I'm really interesting if Motorola wants to reuse our code or develop the better one ? You can see the same statement as me, so it would only be speculation to talk about 'what Motorola want' beyond what they have said already. The cool part is that by choosing ALv2 Harmony can freely engage and exchange with their effort. Regards, Tim -- Weldon Washburn Intel Enterprise Solutions Software Division
Re: [security][testing] 2 tests failed today
On 1 November 2006 at 13:39, Mark Hindess [EMAIL PROTECTED] wrote: Fixed in r469902. Turns out the exec was putting double quotes around the classpath argument (which might make sense if it was going to a shell) but it doesn't for an exec syscall. This resulted in classes being search for in the non-existent directory: /path/to/modules/luni/bin/test rather than: /path/to/modules/luni/bin/test Regards, Mark - confused as to why it didn't also fail on windows Oops. Tim mentioned that my fixed breaks things on windows. I've checked in a better fix that I hope should be more well-defined on all platforms. That is, pass the arguments to Runtime.exec as an array not a string. Aside: My tests show that the behaviour we saw with the quotes in the string being passed directly through to the execve syscall is consistent with the RI. Regards, Mark. On 1 November 2006 at 10:37, Tim Ellison [EMAIL PROTECTED] wrote: Boris Kuznetsov wrote: The tests use tests.support.Support_Exec.execJava2() to perform testing on other JVM. This method uses Runtime.getRuntime().exec() to run command. You can see command (it looks like java -cp classname) in the test's System.out. It woks OK on Win, but produces NoClassDefFoundError on linux. Note, the command woks OK in linux sh also. Yes, I don't think it is the tests for HARMONY-1674 per se that are failing, but they are exposing a problem in the exec -- which is why I haven't rolled back that commit. I'll keep looking at it, let me know if you see the problem. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [classlib] Preprocessor - CHECKPOINT
Mikhail Fursov wrote: On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote: For comfortable IDE development, one could imagine that the IDE editor can reduce to one-line visible comments (or better, specially formatted ones) so that it gives you the impression that you are really wearing target-specific spectacles. [I know Eclipse allows for such things already]. ... Etienne, What is 'comfortable IDE development' if you can't modify the Y? Am I missing something here? Maybe my text was wrongly formatted... You looked at the wrong example. Comfortable development happens only using development targets. E.g. 1- process(X, devtarget) - Z 2- edit Z in IDE using comfortable development, where you see a single commented line for every hidden stream code chunk, keeping you aware that other streams have related code there [you click on the + in Eclipse if you want to see the complete chunk]. Of course, you should never delete a chunk without consulting other stream developers first. So: edit Z - Z' 3- revert(Z') - X' this works, as long as devtarget is a stream code preserving target (a development target). 4- svn ci of X' :-) You wouldn't want to do the same with a release target. A release target is a target where you want to completely remove other streams source code from the processor output. This is so your typical J2SE end developer that looks at Harmony's source.zip code wouldn't have lots of non J2SE commented code in his face. [This was a concern expressed earlier in this thread]. The output of process(X, releasetarget) should NOT be used for development, not within, nor outside an IDE. It's only role is to give end developers clean source code to look at. :-) Etienne PS: Note how revert() does not expect a target argument. So, to switch from j2me to j2xx development, one must: process(revert(Z),j2xx) [where Z == process(X,j2me)]. This simplifies quite a few things... -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: [classlib] Preprocessor - CHECKPOINT
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote: Comfortable development happens only using development targets. E.g. 1- process(X, devtarget) - Z 2- edit Z in IDE using comfortable development, where you see a single commented line for every hidden stream code chunk, keeping you aware that other streams have related code there [you click on the + in Eclipse if you want to see the complete chunk]. Of course, you should never delete a chunk without consulting other stream developers first. So: edit Z - Z' 3- revert(Z') - X' this works, as long as devtarget is a stream code preserving target (a development target). 4- svn ci of X' :-) Etienne, thanks! Now I understand how it works. Having such a tool seems like a very promising good idea! -- Mikhail Fursov
Re: 235 tests are missed at DRLVM test run for Windows
Hello, Queue appeared to be a stack :) Both requests are implemented, others are pending. On 11/1/06, Anton Luht [EMAIL PROTECTED] wrote: Feature requests from Geir (multiple select for tags) and Alexey (shortcut to compare two runs from the first page) are accepted and put in the implemetation queue. -- Regards, Anton Luht, Intel Java XML Engineering
Re: [classlib] Preprocessor - CHECKPOINT
Etienne Gagnon wrote: Here two typical some use cases, and some proposed solutions: Problem --- logging, and other situations where you really don't want to put the additional source code in the main source files Solution use aspects (Plug: you might want to give a look at the optimizing abc compiler) +1 and/or 'intrinsic' VM-level tracing of the Java code. Problem --- supporting a different API specifications/versions, such as j2me and j2se1.4, in addition to the main version (e.g. j2se1.5) Solution This is a trickier problem. We can divide the problem at two main levels: 1- file/directory level 2- source-code level At the file/directory level, each version (e.g. j2me, j2se1.4, ...) might include additional files (relative to the main version), and might not include some files of the main version. In other words, j2me might not contain database APIs. Managing file inclusion/exclusion can be done in various ways. a) ant based: use distinct ant (sub-)files for each version. The problem is that IDEs (e.g. Eclipse) will most likely show some of the excluded files in its class/files browser. This wouldn't be very elegant. It also implies always compiling through ant files. Of course, one could develop Eclipse-specific configuration files to mimic the inclusion/exclusion of ant files, but then, this opens the door for discrepancies between ant vs eclipse inclusion/exclusion lists. I don't like it. b) custom-tool based: the custom processing tool I proposed could also parse inclusion/exclusion lists, and use these lists to move files around, in addition to processing the content of unmoved files. For example, if class X of the main version is not part of j2me, process(j2me) would move this file to a subdirectory .streams/. Why would you move the files rather than exclude them? I was assuming that the processor would generate a whole new source tree for each process() target, so that you could work on the original checked-out file in it's 'canonicalized form' for Big Java work, or process(jme) into a new location and work in the non-canonical form your Little Java spectacles on. That would prevent you accidentally checking in the Little Java code, since you would need to reverse-process the code back to replace the checked-out file (with a test to ensure you are not overwriting changes made to Big Java, or for extra credit, merging changes in the working copies). The svn check-in would then always be in the Big Java canonicalized form. This idea would loose the ability to check-in directly from the IDE though for people working with the non-canonicalized source form. If a class Y is not in the main version (the one used for svn ci), it resides in subdirectory .streams in the trunk. process(j2me) moves this file into the normal directory. As for IDEs, now you can configure them to automatically exclude .stream/ directories. Inclusion/exclusion could be managed in two ways: 1- the processing tool could look for inclusion/exclusion list files, such as j2me.inclusion, j2me.exclusion, main.inclusion, main.exclusion, etc. This would lead to the best performance (for process(X)), yet it does require much manual update of inclusion/exclusion lists, with all the discrepancies that result from human mistakes while updating these files. 2- (my preferred way), directives, at the beginning of the source code would indicate whether a file is included in a version or not. Depending on target, the file would be moved to the appropriate directory (normal, .streams). Agreed. Since we are requiring the source to be processed for any deliverable target, we might as well keep the mark-up in-line. Of course, there's also the problem of non-source files, i.e. resources. IMO, resources could be managed using specific directories (.main/, .j2me, .j2se1.4) and a .shared/ directory with symbolic links in the specific directories. As for source-level management, you would use my proposed processing tool to view the source files with the right spectacles [as Tim said so elegantly:-)]. For development targets, it is important that: revert(process(X, target)) = X By development target I mean a target that is meant for Harmony developers in prevision of reverting modified code to a format suitable for svn ci (i.e. revert to main target). For comfortable IDE development, one could imagine that the IDE editor can reduce to one-line visible comments (or better, specially formatted ones) so that it gives you the impression that you are really wearing target-specific spectacles. [I know Eclipse allows for such things already]. To release code, one would apply: process(X, release-target) = Y Now, it is important to understand that Y, in this case, is NOT
RE: [doc] No Doxygen reference for code :(
Nadya, Sorry, I supposed to say the same thing. By requirement engineering I meant a discussion of requirements. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 5:09 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, One note: I'm *not* writing requirements for engineering on the doc build system. I'm just sharing my thoughts on an issue that interests me. Discussion is welcome. Please don't consider my ideas as the way it should be. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:52 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, Thanks for answers. You have a nice approach to the requirement engineering for the documentation build system. It would be great if you also add priorities for your requirements. Looking into your original list of requirements, I've noticed I haven't addressed the second one: 2. Ability to see docs on the website Yesterday I'd added an archive with documentation to HARMONY-2024 http://issues.apache.org/jira/browse/HARMONY-2024, so committers could now put documentation to the web site and everyone could contribute to the documentation quality. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 9:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, Thanks for meaningful and numerous questions, Alexei. I have thought of some of these, but you give it a systematic touch :) Others' opinions are welcome, mine in below - marked with [NM]. Related question: do we want to have some version of API doc on the site now? I've experimented with building docs, and could produce a working bundle. We can work to enable the build create API docs locally in parallel with that. PS: Geir, there's a specific question for you below. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 7:49 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, All, Suggestion to generate Doxygen from DRLVM code sounds very interesting. I posted a quick solution for Linux to http://issues.apache.org/jira/browse/HARMONY-2024 [NM] great news, I'll see if I can do smth similar for Windows. If you want to have this integrated into build.xml, it would be great to define a correct scope. Could you please give more details what do you expect from the documentation build file? [NM] I'd give it a try. Please don't expect me to write a design doc for you A volunteer can try doing some things important for you first, and then add new features gradually. [NM] yeah, I like the idea of a gradual step-by-step process. * Should doxygen build documentation for inter-component interfaces? [NM] sure, and I guess it's the better-documented part ;) * What are components? I assume vm, jit, gc are out of the question. Is am execution manager or an interpreter a separate component? [NM] see dev guide; we've thought components roughly match to top-level folders: EM, Interpreter, TM are all components. Not sure what to do with the three GCs now, though. * Should doxygen build documentation for each component like vm, jit, interpreter, gc? [NM] It's my dream and very convenient. Getting Doxygen to run for half-hour and get hung doesn't seem an attractive prospect. However, I guess we can get some primitive build as a start and add component-specific build targets later. For me, an ideal list of targets for Doxygen would be something like: all - all headers for DRLVM/classlib (one of two, not both in one bundle) inter-component - headers in include/ folder basically. Do we have any high-level interfaces in other places? This could show the big picture and somehow map to the arch description. component - headers for the component name specified. We might concentrate on the first two now for simplicity and smaller scope. * Should we put documentation into doc/component_doc dirs as class library code does? [NM] this is a complex issue. I know Geir has wanted to add website to the snapshot. *Geir*, could you express your view on where to place docs? I guess separating normal docs and autogenerated docs would be good, like the /doc/ folder for all files, with /doc/Doxygen/ subfolder for API reference. When we are ready to build component-specific reference, /doc/Doxygen/ can have subfolders for each. * Should we use the same formatting as a class library documentation? [NM] why not? as I've noticed, default formatting is ok, but there are many options you can enable/disable, e.g. diagram for class hierarchy.
Re: [doc] No Doxygen reference for code :(
Alexey Petrenko wrote: I think that we can place the docs here: http://incubator.apache.org/harmony/subcomponents/classlibrary/index.html Yes, that's one of my candidate, another one is here: standard/site/docs/documentation/documentation.html, because I think it is also a reasonable idea for the user to go for documentation if you wanna some API explanation. How about we put the API document in each subcomponents(classlib/drlvm/jchevm), but also add their link in documentation/documentation.html? 2006/11/1, Paulex Yang [EMAIL PROTECTED]: Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1.Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2.Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
Re: [classlib][portlib] Docs?
Geir Magnusson Jr. wrote: yeah - someone generate, and we can hang them on the website. I'm not sure we'd want to check them in though... Is it possible to add documents into website but not to commit them in SVN? We removed them from classlib/trunk/doc because the SVN metadata get in the way when updating the document. I've done this before for API docs... geir Alexey Petrenko wrote: Having these docs on website will be really good! SY, Alexey 2006/11/1, Paulex Yang [EMAIL PROTECTED]: If you get Doxygen installed, you can create it by running ant doxygen-natives in classlib/trunk/doc. There were discussions to move the document to somewhere on website, but seems it is still to be done. Morozova, Nadezhda wrote: Not that I know of :( bits of things are in the devguide, maybe. But you probably won't find that of much notice. Anyone, please tell me it's not true! Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:15 PM To: harmony-dev@incubator.apache.org Subject: [classlib][portlib] Docs? Guys, do we have any docs on portlib? SY, Alexey -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
Re: [doc]Please help to remove outdated info from the site
done. Konovalova, Svetlana wrote: Folks, You might know that certain Harmony pages are out-of-date and need to be modified. One of such pages is http://incubator.apache.org/harmony/status.html . Now I'm working at creating the Build our Own Website Using Ant section for this very page. Would be great, if someone can find a chance to look at it to help me through away outdated info. Thanks in advance! Best regards, Sveta Konovalova -- Tim Ellison ([EMAIL PROTECTED])
RE: [doc] No Doxygen reference for code :(
+1 Thank you, Nadya Morozova -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 7:55 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] No Doxygen reference for code :( Alexey Petrenko wrote: I think that we can place the docs here: http://incubator.apache.org/harmony/subcomponents/classlibrary/index.htm l Yes, that's one of my candidate, another one is here: standard/site/docs/documentation/documentation.html, because I think it is also a reasonable idea for the user to go for documentation if you wanna some API explanation. How about we put the API document in each subcomponents(classlib/drlvm/jchevm), but also add their link in documentation/documentation.html? 2006/11/1, Paulex Yang [EMAIL PROTECTED]: Morozova, Nadezhda wrote: Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1.Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2.Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) It is me that removed the original document in classlib/trunk/doc as we discussed before, so seems it should be my responsibility to make the work complete:). Sorry for delaying so long. But I still have no strong feelings where to put them in standard/site, any suggestions? You can create all the API document by run ant in classlib/trunk/doc, you can get all document created, assuming Doxygen is installed. If you kindly provide the patch, I will look at it and merge it into SVN. [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mb ox/[EMAIL PROTECTED] Thanks, Nadya Morozova -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM
