Re: [drlvm] apr_dso_load error (path address out of bounds)
On the 0x1F8 day of Apache Harmony Armand Navabi wrote: Sorry about the last email, but there is something I think I should mention. I recently checked out a clean copy and rebuilt from scratch. I did not notice BUT since then, helloworld does actually run!! It just hangs after it runs. Now the behavior is very similar to when I run ./java -showversion (i.e. prints out version information and then hangs). I plan to look into this. You mean, it hangs right before the exit? And prints OK? Then the library should load OK. But when I run gdb, I still see: apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds, pool=0x808fc78) at dso.c:139 139 os_handle = dlopen(path, flags); And.. I suppose you applied the gdb enabling patch for that? hm, I cannot believe this is a GDB problem... :( There are some modes you can try for fun: -Xem:opt -- use only agressive compiler (OPT) -Xem:jet -- use only fast JIT (JET) -Xint-- do not use compilers, use interpreter (no libjitrino.so sould be loaded in this mode) Despite this, it seems to still run fine after that point (i.e. Hello World executes after all the libraries are loaded, even though every single load seems to fail because of the address not found problem). Can you pass the library load in GDB? Does it work fine if it is not single stepped? Anyway, I'm running hello world now, and so I'm happy. not very much, though Are you collecting HelloWorlds? :) Thanks, Armand -Original Message- From: Armand Navabi [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 3:22 PM To: harmony-dev@incubator.apache.org Subject: RE: [drlvm] apr_dso_load error (path address out of bounds) I thought that perhaps a gdb backtrace may be helpful. Note: I also tried to go into dll_jit.cpp:62 and hard code the name of the dll_filename which is passed to apr_dso_load. And still when I step into apr_dso_load that second argument path=0x102 Address 0x102 out of bounds. Perhaps the stack is getting messed up somehow. Any ideas? (gdb) bt #0 apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds, pool=0x808fc78) at dso.c:139 #1 0xb6d99b61 in Dll_JIT (this=0x80a9650, dll_filename=0x80a9774 /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji trino.so) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jit/dll_jit.cpp:63 #2 0xb6e4ff4e in vm_load_jit ( file_name=0x80a9774 /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji trino.so, handle=0xbfa9e51c) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:629 #3 0xb69afa9e in DrlEMImpl::buildChains (this=0x80a9480, [EMAIL PROTECTED]) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:437 #4 0xb69af256 in DrlEMImpl::init (this=0x80a9480) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:363 #5 0xb69ad239 in DrlEMFactory::createAndInitEMInstance () at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:52 #6 0xb69c7a72 in CreateInstance (p_instance=0xb7022f88, pool=0x808dc70) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/em_intf.cpp:132 #7 0xb6d95fae in CmCreateInstance (p_instance=0xb7022f88, name=0xb6f7eac4 em) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmstart/src/compmgr/component_man ager_impl.cpp:584 #8 0xb6e4dd37 in process_properties_dlls (p_env=0xb7022de0) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:148 #9 0xb6e4f0f6 in create_vm (p_env=0xb7022de0, vm_arguments=0xbfa9e8c0) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:356 #10 0xb6dc6826 in JNI_CreateJavaVM (p_vm=0xbfa9e8b0, p_env=0xbfa9e8b4, vm_args=0xbfa9e8c0) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jni/jni.cpp:1270 #11 0x0804962c in invocation () #12 0x08048fd0 in gpProtectedMain () #13 0x0804ac4c in signalProtectedMain () #14 0xb7fb5e00 in hysig_protect () from /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/libhyprt.so #15 0x0804ad0c in main () -Original Message- From: Armand Navabi [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: [drlvm] apr_dso_load error (path address out of bounds) I am still having trouble getting hellworld to run. Currently the problem is that for some reason in dll_jit.cpp on line 62, where the call is made to apr_dso_load, the second parameter which is the path to the dll becomes address out of bounds in the apr_dso_load procedure. Egor suggested that perhaps APR configured itself incorrectly on my system. Alexey suggested I try to run the APR test. I ran the APR tests and all tests passed (in /build/lnx_ia32_gcc_debug/semis/extra/apr/src/test). Below is what happens in gdb. Also below that I have pasted what happens at the end
Re: [classlib][tools] package name for Keytool tests
Hi Anton, I think we should name tool's tests as classlib does. So for tools we will have: o.a.h.tools.toolname.tests Thanks, Stepan. On 10/4/06, Anton Rusanov [EMAIL PROTECTED] wrote: Hi, I'm going to add a test for Keytool but I don't know how to name the package for tests: org.apache.harmony.tests.tools.keytool like it is done for javac or org.apache.harmony.tools.keytool.tests like it was decided for classlib? -- Thanks, Anton -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Yes, JDWP agent uses most of JVMTI functions, and testing JDWP level indirectly checks JVMTI implementation. JDWP unit tests included into JDWP contribution do not provide exhaustive testing, but they often catch problems with basic JVMTI support related to debug functionality. However, there is a number of JVMTI functions not used in JDWP agent. They are targeted for profiling support and will not be tested with JDWP tests. But they can be tested with any Java profiler, for example new JVMTI profiler in Eclipse TPTP project [1]. Their automation testing framework can be used for testing JVMTI profiling support in Harmony JRE. Ivan. [1] http://www.eclipse.org/tptp/ On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ivan Popov wrote: --- I'd like to see JDWP unit tests included into regular tests runs, they often reveal problems with JVMTI and JNI support when JVM implementation is changed. I'm not sure that unit tests are provided with other tools and included into tests run, and this can be a separate topic for discussion. Yah, I've been noting that in JVMTI commit messages - we need a suite of JVMTI tests, and I guess we can use the agent for it? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][tools] package name for Keytool tests
+1 2006/10/4, Stepan Mishura [EMAIL PROTECTED]: Hi Anton, I think we should name tool's tests as classlib does. So for tools we will have: o.a.h.tools.toolname.tests Thanks, Stepan. On 10/4/06, Anton Rusanov [EMAIL PROTECTED] wrote: Hi, I'm going to add a test for Keytool but I don't know how to name the package for tests: org.apache.harmony.tests.tools.keytool like it is done for javac or org.apache.harmony.tools.keytool.tests like it was decided for classlib? -- Thanks, Anton -- 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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][build] deploy.canonical ant task
Dear all, Can we exclude this task from DRLVM's build.xml default task? It takes most of build time when rebuilding only several files while working with drlvm code. AFAIU, exect content of this directory exists at platform_arch_compiler_config/deploy directory. Regards, Pavel Pervov.
Re: [drlvm] DRLVM, jre/bin/default and launcher
J2SE documentation explicitely mention standard and non-standard but well-known option for 'java' tool in [1] and [2]. I think it makes sense to follow this description rather than help message, they are not equal. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html Ivan. On 10/4/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 10/4/06, Ivan Popov [EMAIL PROTECTED] wrote: J2SE documentation explicitely mention standard and non-standard but well-known option for 'java' tool in [1] and [2]. I think it makes sense to follow this description rather than help message, they are not equal. From my point of view we should support all widely used options and it should not depend on standard/non-standard definition (for example, support of '-Xmx' option is useful too). Seems, it should be discussed and store somewhere. Thanks, Vladimir [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html Ivan. On 10/4/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[j9][testing] some classlib unit tests fail
Hello, all, AFAIK, ant test should give 100% pass rate on j9 but I have 5 failures which seem to be dependent on environment. I've uploaded the results at http://harmonytest.org/testapp.do?method=showrunid=9perPage=100page=1name=result=0jira=0 There are also two JIRA issues detailing this: HARMONY-1664http://issues.apache.org/jira/browse/HARMONY-1664 and HARMONY-1674 http://issues.apache.org/jira/browse/HARMONY-1664 Can anyone help in analyzing the problem? -- Thanks, Elena
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 3 October 2006 at 8:12, Ivan Volosyuk (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments#action_ 12439536 ] Ivan Volosyuk commented on HARMONY-1676: copy these files into depends/libs/linux.x86_64 build with 'ant -Dos.arch=x86_64' I've just checked in a change to make/properties.xml (as r452774) that should add os.arch normalization for x86_64. (This basically duplicates what we did to handle the way the os.arch variables differ between reference jdks.) So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it doesn't work, can you let me know what os.arch says for the jdk you are using. Thanks, Mark. Well, I didn't download 64 bit version jdk, so I've just used the 32 bit version which works just fine on 64 bit version of linux. Jdk I use is: jrockit-jdk1.5.0-linux-ia32 (build 1.5.0-b64) -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] creation of jdktools
Tim Ellison wrote: +1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. Could anyone shed the light why launcher is considered part of classlib? As far as I understand, it depends on standard JNI Invocation API, and some Harmony-wide conventions about property names and files. I would suggest that we move launcher from classlib/ to jdktools/ as well. Sorry if I am missing something. P.S. +1 for original idea to create jdktools/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 10/2/06, Mark Hindess [EMAIL PROTECTED] wrote:
...
I think we need more than one tests.jar. In fact, I think we need
more than one tests.jar per module since some tests need to be on the
bootclasspath while others do not (and should not). At the moment
it might be necessary to have more since there isn't really a way to
distinguish api/internal tests (this might change if/when we move to
testng).
Mark, could you please look on the
*HARMONY-984*http://issues.apache.org/jira/browse/HARMONY-984?
If
accessibility.build.patchhttp://issues.apache.org/jira/secure/attachment/12342238/accessibility.build.patchis
OK I'll prepare similar updates for other modules.
Thanks, Vladimir
...Regards,
Mark.
[0] Start of build would need to do:
if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
and only deploy jdk files in to ${hy.jdk} - I think/hope this is
true already.
Re: [general] creation of jdktools
2006/10/4, Salikh Zakirov [EMAIL PROTECTED]: Tim Ellison wrote: +1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. Could anyone shed the light why launcher is considered part of classlib? As far as I understand, it depends on standard JNI Invocation API, and some Harmony-wide conventions about property names and files. I would suggest that we move launcher from classlib/ to jdktools/ as well. +1 to move launcher out of classlib. I was going to suggest this too. Sorry if I am missing something. P.S. +1 for original idea to create jdktools/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j9][testing] some classlib unit tests fail
The tests mentioned in HARMONY-1674
http://issues.apache.org/jira/browse/HARMONY-1674 depend on default
system policy file.
But if user policy file exists than, according to the spec, it is
added to system policy. It leads to the tests failures.
There are two options:
1. Rewrite the tests.
2. Use '-Djava.security.policy' to specify policy file and ignore all
others:
-Djava.security.policy==${java.home}/lib/security/java.policy
I suggest the second one.
Comments?
On 10/4/06, Elena Semukhina [EMAIL PROTECTED] wrote:
Hello, all,
AFAIK, ant test should give 100% pass rate on j9 but I have 5 failures
which seem to be dependent on environment.
I've uploaded the results at
http://harmonytest.org/testapp.do?method=showrunid=9perPage=100page=1name=result=0jira=0
There are also two JIRA issues detailing this:
HARMONY-1664http://issues.apache.org/jira/browse/HARMONY-1664 and
HARMONY-1674 http://issues.apache.org/jira/browse/HARMONY-1664
Can anyone help in analyzing the problem?
--
Thanks,
Elena
--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Hi All, I have attached updated patch to the JIRA. It should resolve remain concerns. Andrey, could you give a green light now? Thanks Evgueni On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, I see your points. I think both approaches have advantages and disadvantages. I think it is quite hard to say which approach is better until we play with one VM only. I still feel like introducing one more dependence is better than spreading code which deals with attachment among VM and TM. We really get stuck. OK, just because I want to move forward I will do required changes to remove vm_create_jthread from TM. I believe that will resolve all our disagreements and the patch will be applied soon. Thanks Evgueni. On 10/4/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Why do you think it is artificial? I would rather prefer not to throw vm_attach event from the jthread_attach() call at all than to add extra dependency. The idea of jthread layer is a Java face to hythread, it is meant to know either a little or nothing about the rest of VM. It may be logical to throw vm_attach call from the newly created thread, because there is no other way to let know VM the new thread is created. VM attach is a different case - VM already knows about new Java thread at the time of the AttachCurrentThread call. Do you think it makes sense to replace a single jthread parameter with a variety of stuff (like thread group, name)? It seems the only purpose of at these args is to be passed back to VM for vm_jthread_create(). I would suggest to change this and try doing either of: 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon. Why do you want to pass daemon to TM but
Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Tim Ellison wrote: Alex Astapchuk wrote: Hi Stepan, all, I think the spec. statement: A LoginContext should not be used to authenticate more than one Subject. was taken too strict: reusing LoginContext object to get the same set of credentials seemed odd. The decision was mostly about resources. Indeed, the spec does not specify behavior of LoginContext. However, the spec is more or less clear in what should the Login*Module*-s do in response to login/logout/etc. It states 'login() saves result ...'. It does not warn with anything like 'check previous state and clean up resources from previous successful logins'. The resource clean up is explicitly for abort() and logout(). The spec might not say so explicitly, but cleaning up the resources before attempting another login would seem like a reasonable thing to do. Oh yeah, with no doubt. It's always good to be defensive, and careful, and accurate, and etc, etc... Especially when you're warned. :-) The JAAS tutorial has a TODO-list for LoginModule.login() [1]. Nothing again about 'should check and clear'. I consider RI's behavior is more reasonable. I would say it's more dangerous. The invocation of login() on already logged LoginModule-s may easily produce a resource leak. Presuming the authentication is normally not a too frequent task, such a leak would be really hard to discover and hunt. I don't see why we would have to suffer the leak -- if the state changes are made via API then we have the opportunity to fix things first. I was talking about custom LoginModule-s, that may be plugged into an app. Imagine a developer implementing a LoginModule. Reading through the spec, s/he gets no clue s/he must free up resources in login(). I bet most of existing LoginModule-s do not expect the second call of login() after successful commit(). I did a quick and rough googling on implements LoginModule and also quick-checked JBoss srcs. Surely, in no way this may be considered as a relevant research, but from what I see - no one frees anything in login(). So again, my point is what a call of LoginModule.login() on already logged+commited LoginModule may easily introduce a resource leak when an application works with a custom LoginModules. [1] http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login -- Thanks, Alex - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
2006/10/4, Nathan Beyer [EMAIL PROTECTED]:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
Logging and printing to console essentially differ in flexible
customization offered by the first approach. An application can have
no console after all.
We develop the common class library here, not an ordinary application
- so let's not assume it will be used in some particular way.
In this concrete case, stack trace is printed every time invalid input
data is supplied - and it is normal for a unit test to cover some
negative cases.
But seeing console jammed with that rubbish is quite confusing (for me
at least). OTOH, such info would be valuable for app developer - so
why not satisfy both?
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
Because we have more priority tasks to be done. We just haven't
reached that stage of completeness, when we can afford minor refining
and polishing. Never say never, you know :)
Please, announce ahead if you do such things in future.
--
Regards,
Alexey
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test
FYI: I've changed the way our builds are reported to the -commits list. Now, the reports go to my apache.org email address where they are compressed and stored. The url in the message is then modified to point to the compressed version in my people.apache.org web space and the first 10k of the message is sent on to the -commits list. This should mean: a) all messages reach the list (no more size limit issues) b) the full logs are available via the web - at least for a week or two Currently the trimming of the logs to send to the list is very crude and usually the first 10k isn't very useful. Hopefully I'll get some time to improve the trimming shortly to, for instance, include lines which match /(error/fail/warn)/i plus a few lines of context above/below. Regards, Mark. On 4 October 2006 at 9:36, [EMAIL PROTECTED] wrote: Online report : http://people.apache.org/~hindessm/continuum/classlib/linux.i a32/2006/10/04/20061004-083606.successful.log.gz Build statistics: State: Ok Previous State: Failed Started at: Wed, 4 Oct 2006 09:03:31 +0100 Finished at: Wed, 4 Oct 2006 09:36:04 +0100 Total time: 32m 33s Build Trigger: Schedule Exit code: 0 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib/modules/auth/src/test/java/common/org/ap ache/harmony/auth/login/DefaultConfigParserTest.java classlib/modules/auth/src/test/java/common/org/apache/harmony/aut h/login/DefaultConfigurationTest.java classlib/modules/auth/src/test/resources/auth.conf classlib/make/properties.xml Output: Buildfile: build.xml build: [delete] Deleting directory /home/hybld/continuum-working-directory/6/clas slib/deploy [echo] Classlib revision is 452787 [echo] Post process: true [echo] JAPI: true [echo] Building with reference jdk/javac [exec] Buildfile: build.xml [exec] clean-java: [exec] -copy-kernel-patternsets: [exec] [mkdir] Created dir: /home/hybld/continuum-working-directory/ 6/classlib/deploy/build/patternsets [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc tory/6/classlib/deploy/build/patternsets [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc tory/6/classlib/deploy/build/patternsets [exec] -modules-clean-bin: [exec] call-modules-all: [exec] clean: [exec][delete] Deleting 30 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 15 files from /home/hybld/continuum-working- directory/6/classlib/modules/accessibility/bin/test [exec] clean: [exec][delete] Deleting 13 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec] clean: [exec][delete] Deleting 4 files from /home/hybld/continuum-working-d irectory/6/classlib/build/classes [exec][delete] Deleting 1 files from /home/hybld/continuum-working-d irectory/6/classlib/modules/applet/bin/test [exec] clean: [exec][delete] Deleting 51 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 41 files from /home/hybld/continuum-working- directory/6/classlib/modules/archive/bin/test [exec] clean-native-includes: [exec][delete] /home/hybld/continuum-working-directory/6/classlib/de ploy/include not found. [exec] clean: [exec][delete] Deleting 106 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 218 files from /home/hybld/continuum-working -directory/6/classlib/modules/auth/bin/test [exec] clean: [exec][delete] Deleting 901 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 570 files from /home/hybld/continuum-working -directory/6/classlib/modules/awt/bin/test [exec] clean: [exec][delete] Deleting 107 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 233 files from /home/hybld/continuum-working -directory/6/classlib/modules/beans/bin/test [exec] clean: [exec][delete] Deleting 122 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] /home/hybld/continuum-working-directory/6/classlib/mo dules/concurrent/bin/test not found. [exec] clean: [exec][delete] Deleting 49 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 88 files from /home/hybld/continuum-working- directory/6
Re: [classlib] Recognizing lock objects
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
--
Mikhail Fursov
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 4 October 2006 at 12:59, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 3 October 2006 at 8:12, Ivan Volosyuk (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments#act ion_ 12439536 ] Ivan Volosyuk commented on HARMONY-1676: copy these files into depends/libs/linux.x86_64 build with 'ant -Dos.arch=x86_64' I've just checked in a change to make/properties.xml (as r452774) that should add os.arch normalization for x86_64. (This basically duplicates what we did to handle the way the os.arch variables differ between reference jdks.) So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it doesn't work, can you let me know what os.arch says for the jdk you are using. Thanks, Mark. Well, I didn't download 64 bit version jdk, so I've just used the 32 bit version which works just fine on 64 bit version of linux. Jdk I use is: jrockit-jdk1.5.0-linux-ia32 (build 1.5.0-b64) And what is os.arch is set to? x86 or i386 or something? Probably not much we can do about that. Except perhaps create a user preferences file. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][build] deploy.canonical ant task
Pavel Pervov wrote: Dear all, Can we exclude this task from DRLVM's build.xml default task? It takes most of build time when rebuilding only several files while working with drlvm code. AFAIU, exect content of this directory exists at platform_arch_compiler_config/deploy directory. The HARMONY-1085 has been filed some two months ago to do just that: stop copying jre from platform-specific directory to just deploy/ directory. I have just updated patches in HARMONY-1085 to match current SVN trunk. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1607 : where is the right place to put it?
Geir, I created this package to have a common place with other MSVC users in JIRA and I did not expect you want to put it into the trunk :) But if you decided to add it I suggest adding it to the drlvm/trunk/build folder. So the resulting folder for MSVC2003 solution will be drlvm/trunk/build/custom/msvc_2003. Note:This package does not complete today and contains only jitrino/encoder/em projects. If anyone has other MSVC project files for drlvm subprojects, please speak up. Offtopic: Geir, you said before you use IDEA for Java, so I think you like to use keyboard shortcuts instead of mouse. The Visual Assist plugin for MSVC allows me to work without mouse in Visual Studio too. On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I haven't used MSVC in about 6 years, so where is the right place to put the files from 1607 so that they are easily used by an MSVC user? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
Re: [drlvm][build] deploy.canonical ant task
+1 not to copy by default, but do it by request. And the reason is not performance. The reason is that I never remember if my 'deploy' folder contains a release or debug build. So I use folders with a full name. On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Pavel Pervov wrote: Dear all, Can we exclude this task from DRLVM's build.xml default task? It takes most of build time when rebuilding only several files while working with drlvm code. AFAIU, exect content of this directory exists at platform_arch_compiler_config/deploy directory. The HARMONY-1085 has been filed some two months ago to do just that: stop copying jre from platform-specific directory to just deploy/ directory. I have just updated patches in HARMONY-1085 to match current SVN trunk. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov
[classlib][test] Site to collect classlib test statistics
Anton, I found out that you open site http://www.harmonytest.org http://www.harmonytest.org/ . As I understood it is used to collect statistics of classlib test results on different builds. Could you tell about it in more detail? 1) Who can upload test results? 2) How are you going to develop this site, structure, data base and etc.? Vera Volynets SSG, MPD/DRL division VM Development team Intern Moscow, Russia +7 495 545-3710 ext. 3906
Re: [classlib] Recognizing lock objects
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
Hello,
Maybe it's better to mark 'locking' objects with something like
//$LOCK-1$ ? New Object() can be created for many purposes - I'm not
sure what percent is used for locks - 10 or 90.
Another suggestion: use
new Object() {
public String toString() {
return something that contains some locking keyword;
}
}
On 10/4/06, Tim Ellison [EMAIL PROTECTED] wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion `!(vt() 1)'
failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op =
stub_disasm.get_opnd(0);
assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][launcher] should we get rid of one of the HyPortLibrary function tables in DRLVM?
Hi, I see the same. I looked at the problem closer. It turned out to be the problem of Microsoft debugger. Seems like debug information is damaged somehow. What I did? I set breakpoint at line 290 of modules\luni\src\main\native\launcher\shared\main.c. Printed out args-portLibrary. It is valid structure at that moment. Make one step over the line 290. Ups ... args-portLibrary become invalid but line number 290 looks like if(newPathToAdd == NULL). So it can't crash portLibrary. I played a little with commenting out the code and got the same problem in different places. That's why I think this is debugger problem. Thanks Evgueni On 10/2/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, Using windows debugger, I see native/launcher/shared/main.c::invocation() receive an incoming argument that looks to be a DRLVM version of HyPortLibrary with all the functions zeroed out. Does anyone else see this?? Passing a HyPortLibrary with the function ptrs nulled out is not the primary concern. At worst, this will cause a sigsegv and should be straight forward to debug. The big concern is accidentally using the classlib/HyPortLibrary function ptr table when DRLVM Threading Manager APIs are intended. This could cause all sorts of strange deadlocks. I have looked at the code to prove or disprove that the two HyPortLibraries are being confused. So far, no luck. There are too many layers to get to the bottom of this quickly. Does anyone know the answer to the above question? If not, should I open a JIRA on this issue? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
Stepan Mishura wrote:
On 10/4/06, Nathan Beyer wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
I don't agree. TODOs are good hint for making improvements and I'd keep
them
in source files.
Me too. I don't like cruft, but I'm not sure I see the harm in general.
geir
Thanks,
Stepan.
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of
commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Vladimir Ivanov wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? Why do we as the Harmony project care? geir thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
Anton Luht wrote:
Hello,
Maybe it's better to mark 'locking' objects with something like
//$LOCK-1$ ? New Object() can be created for many purposes - I'm not
sure what percent is used for locks - 10 or 90.
If it is just used for locking I'm changing the type, so there will no
need for the lock comment too.
Another suggestion: use
new Object() {
public String toString() {
return something that contains some locking keyword;
}
}
That doesn't help distinguish them so easily, e.g. TI-based tools.
Regards,
Tim
On 10/4/06, Tim Ellison [EMAIL PROTECTED] wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][build] deploy.canonical ant task
I'll look at the patch, and either do that, or something where it's on demand. geir Salikh Zakirov wrote: Pavel Pervov wrote: Dear all, Can we exclude this task from DRLVM's build.xml default task? It takes most of build time when rebuilding only several files while working with drlvm code. AFAIU, exect content of this directory exists at platform_arch_compiler_config/deploy directory. The HARMONY-1085 has been filed some two months ago to do just that: stop copying jre from platform-specific directory to just deploy/ directory. I have just updated patches in HARMONY-1085 to match current SVN trunk. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
I assume you intend that only the latest patch is applied? (And I assume that it would apply cleanly to SVN HEAD) geir Evgueni Brevnov wrote: Hi All, I have attached updated patch to the JIRA. It should resolve remain concerns. Andrey, could you give a green light now? Thanks Evgueni On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, I see your points. I think both approaches have advantages and disadvantages. I think it is quite hard to say which approach is better until we play with one VM only. I still feel like introducing one more dependence is better than spreading code which deals with attachment among VM and TM. We really get stuck. OK, just because I want to move forward I will do required changes to remove vm_create_jthread from TM. I believe that will resolve all our disagreements and the patch will be applied soon. Thanks Evgueni. On 10/4/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Why do you think it is artificial? I would rather prefer not to throw vm_attach event from the jthread_attach() call at all than to add extra dependency. The idea of jthread layer is a Java face to hythread, it is meant to know either a little or nothing about the rest of VM. It may be logical to throw vm_attach call from the newly created thread, because there is no other way to let know VM the new thread is created. VM attach is a different case - VM already knows about new Java thread at the time of the AttachCurrentThread call. Do you think it makes sense to replace a single jthread parameter with a variety of stuff (like thread group, name)? It seems the only purpose of at these args is to be passed back to VM for vm_jthread_create(). I would
Re: [classlib] [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test
Mark Hindess wrote: FYI: I've changed the way our builds are reported to the -commits list. Now, the reports go to my apache.org email address where they are compressed and stored. The url in the message is then modified to point to the compressed version in my people.apache.org web space and the first 10k of the message is sent on to the -commits list. This should mean: a) all messages reach the list (no more size limit issues) b) the full logs are available via the web - at least for a week or two Nice! Currently the trimming of the logs to send to the list is very crude and usually the first 10k isn't very useful. Hopefully I'll get some time to improve the trimming shortly to, for instance, include lines which match /(error/fail/warn)/i plus a few lines of context above/below. I'm hoping we can transition soon to the common CI system in build-test, so maybe the system you concocted could be adapted to that. geir Regards, Mark. On 4 October 2006 at 9:36, [EMAIL PROTECTED] wrote: Online report : http://people.apache.org/~hindessm/continuum/classlib/linux.i a32/2006/10/04/20061004-083606.successful.log.gz Build statistics: State: Ok Previous State: Failed Started at: Wed, 4 Oct 2006 09:03:31 +0100 Finished at: Wed, 4 Oct 2006 09:36:04 +0100 Total time: 32m 33s Build Trigger: Schedule Exit code: 0 Building machine hostname: hy2 Operating system : Linux(unknown) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib/modules/auth/src/test/java/common/org/ap ache/harmony/auth/login/DefaultConfigParserTest.java classlib/modules/auth/src/test/java/common/org/apache/harmony/aut h/login/DefaultConfigurationTest.java classlib/modules/auth/src/test/resources/auth.conf classlib/make/properties.xml Output: Buildfile: build.xml build: [delete] Deleting directory /home/hybld/continuum-working-directory/6/clas slib/deploy [echo] Classlib revision is 452787 [echo] Post process: true [echo] JAPI: true [echo] Building with reference jdk/javac [exec] Buildfile: build.xml [exec] clean-java: [exec] -copy-kernel-patternsets: [exec] [mkdir] Created dir: /home/hybld/continuum-working-directory/ 6/classlib/deploy/build/patternsets [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc tory/6/classlib/deploy/build/patternsets [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc tory/6/classlib/deploy/build/patternsets [exec] -modules-clean-bin: [exec] call-modules-all: [exec] clean: [exec][delete] Deleting 30 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 15 files from /home/hybld/continuum-working- directory/6/classlib/modules/accessibility/bin/test [exec] clean: [exec][delete] Deleting 13 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec] clean: [exec][delete] Deleting 4 files from /home/hybld/continuum-working-d irectory/6/classlib/build/classes [exec][delete] Deleting 1 files from /home/hybld/continuum-working-d irectory/6/classlib/modules/applet/bin/test [exec] clean: [exec][delete] Deleting 51 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete] Deleting 41 files from /home/hybld/continuum-working- directory/6/classlib/modules/archive/bin/test [exec] clean-native-includes: [exec][delete] /home/hybld/continuum-working-directory/6/classlib/de ploy/include not found. [exec] clean: [exec][delete] Deleting 106 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 218 files from /home/hybld/continuum-working -directory/6/classlib/modules/auth/bin/test [exec] clean: [exec][delete] Deleting 901 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 570 files from /home/hybld/continuum-working -directory/6/classlib/modules/awt/bin/test [exec] clean: [exec][delete] Deleting 107 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] Deleting 233 files from /home/hybld/continuum-working -directory/6/classlib/modules/beans/bin/test [exec] clean: [exec][delete] Deleting 122 files from /home/hybld/continuum-working -directory/6/classlib/build/classes [exec][delete] /home/hybld/continuum-working-directory/6/classlib/mo dules/concurrent/bin/test not found. [exec] clean: [exec][delete] Deleting 49 files from /home/hybld/continuum-working- directory/6/classlib/build/classes [exec][delete
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I assume you intend that only the latest patch is applied? Yes. invocation_api.5.patch only. (And I assume that it would apply cleanly to SVN HEAD) I believe so. Evgueni geir Evgueni Brevnov wrote: Hi All, I have attached updated patch to the JIRA. It should resolve remain concerns. Andrey, could you give a green light now? Thanks Evgueni On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, I see your points. I think both approaches have advantages and disadvantages. I think it is quite hard to say which approach is better until we play with one VM only. I still feel like introducing one more dependence is better than spreading code which deals with attachment among VM and TM. We really get stuck. OK, just because I want to move forward I will do required changes to remove vm_create_jthread from TM. I believe that will resolve all our disagreements and the patch will be applied soon. Thanks Evgueni. On 10/4/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Andrey, Just to be clear I agree with you it is more convenient if jthread_create takes JNIEnv instead of JavaVM. It reflects that current thread has been attached already. Do you think it makes sense to get rid of JNIEnv and use jthread_get_JNI_env in that case? The jthread_* layer is designed like if it were a regular JNI application which is meant to be called from the Java code, hence every function on that layer receives JNIenv. We can probably get rid of the JNEnv parameter for jthread_* functions, assuming that TM can always extract JNIenv for the current thread with jthread_get_JNI_env(). My only concern would be the performance - once the JNIenv is already known for the native part of the kernel classes impl, it must be cheaper to pass JNIEnv to TM as an extra parameter rather than extract it from the TLS again. Other than that, I see no strong advantages in keeping JNIEnv parameter. Regarding jthread_attach. I still didn't get your point Clarify it please if you think jhread_attach should be modified. Sorry for being not clear: I think for jthread_attach, we have two options: 1) Make JNIEnv input parameter - it must be new JNIEnv that VM pre-allocates for the new Java thread. jthread_attach would just associate it with the current thread. 2) Obtain JNIEnv via vm_attach() callback. In this case, if vm_attach() callback implementation needs to know for which JavaVM new JNIenv has to be allocated, then we'll need to add JavaVM as input parameter for jthread_attach(). I think both options should be fine, (1) would probably keep TM interface a bit lighter, though (2) may look more closer to the JNI invocation API idea. So I think adding JavaVM specifically for jthread_attach may make sense given the explanation you provided earlier. The concern I would have regarding the proposed jthread_attach implementation is a call to vm_create_jthread() - this call introduces an extra dependency of TM on vmcore that I'd prefer to be avoided. In the original version, jthread_attach() was taking jthread argument of the already prepared j.l.Thread. I understand your concern. Unfortunately I don't see what we can do here. Let me explain. In the beginning you have an unattached native thread. To be able to call java code (which is required for constructing j.l.Thread instance) the thread should be attached first. To be specific it should be attached to VM by calling vm_attach which will return a valid JNIEnv It is valid to use JNI from that moment. Obtained JNIEnv can be used to execute java code and create j.l.Thread instance. Since we do vm_attach in jthread_attach we need to do vm_create_jthread inside jthread_atach as well. Of course it can be an alternative to do vm_attach and vm_create_jthread outside of TM right before jthread_attach. Sure it will reduce one dependence between VM and TM. But it seems like artificial action for me just because of dependency Why do you think it is artificial? I would rather prefer not to throw vm_attach event from the jthread_attach() call at all than to add extra dependency. The idea of jthread layer is a Java face to hythread, it is meant to know either a little or nothing about the rest of VM. It may be logical to throw vm_attach call from the newly created thread, because there is no other way to let know VM the new thread is created. VM attach is a different case - VM already knows about new Java thread at the time of the AttachCurrentThread call. Do you think it makes sense to replace a
RE: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Printmodules
+1 Dan Lydick [Original Message] From: Geir Magnusson Jr. [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 10/3/06 11:34:32 AM Subject: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Printmodules BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch][drlvm] Linux/ia32 fix for Intel Compiler
Hi,
DRLVM compiled with Intel Compiler 9.0 on Linux/ia32 currently
does not work due to symbol 'clock_gettime' not being found.
A simple build file fix is needed to solve the problem.
It does not affect DRLVM built with gcc.
(Gcc build still works with this modification).
Could anyone commit this change?
Thanks a lot!
--- a/build/make/components/vm/hythr.xml
+++ b/build/make/components/vm/hythr.xml
@@ -95,6 +95,7 @@ vm.port,extra.log4cxx, extra.aprutil /
/select
select os=lnx
+syslibset libs=rt /
linkerarg value=-Wl,-init /
linkerarg value=-Wl,hythread_library_init /
linkerarg
value=-Wl,--version-script,${src}/thread/src/hythr.exp /
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][build] deploy.canonical ant task
Geir Magnusson Jr. wrote: Ok - I'm going to suggest something different that gets you what you want, namely pass a flag to do the fill up canonical rather than pass the deploy directory. That way, the build process is always the same, with an extra step if you ask for it, rather than have it slightly variable as you suggest in the patch. Make sense? Sounds acceptable to me. (Though I still believe that copying is unnecessary). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][build] deploy.canonical ant task
Salikh Zakirov wrote: Geir Magnusson Jr. wrote: Ok - I'm going to suggest something different that gets you what you want, namely pass a flag to do the fill up canonical rather than pass the deploy directory. That way, the build process is always the same, with an extra step if you ask for it, rather than have it slightly variable as you suggest in the patch. Make sense? Sounds acceptable to me. (Though I still believe that copying is unnecessary). Why? Having a well known target to find stuff is good. Having the standard build (from DRLVM POV) be standard is also good. I guess that the best way would be simply to create a link so that the caller outside DRLVM could just pick up the material that way. Anyway, since now the copying doesn't happen, why is it bad for the federated build? It's slow on windows compared to linux, but that's not surprising... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Can you open a JIRA with this, explaining what needs to be done, and
linking the other JIRAs as needed?
Thx
geir
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion `!(vt() 1)'
failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op = stub_disasm.get_opnd(0);
assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
+1
BTW, why call it RepositionLock?
Tim Ellison wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
Geir Magnusson Jr. wrote:
Can you open a JIRA with this, explaining what needs to be done, and
linking the other JIRAs as needed?
Thx
geir
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
`!(vt() 1)' failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being
compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op =
stub_disasm.get_opnd(0);
assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1607 : where is the right place to put it?
Mikhail Fursov wrote: Geir, I created this package to have a common place with other MSVC users in JIRA and I did not expect you want to put it into the trunk :) Well, I think that we should put these things in SVN if we can, rather than use JIRA as some kind of storage. I think that some docs on this for the website would be nice, as well as for Eclipse and any other environments that people use. But if you decided to add it I suggest adding it to the drlvm/trunk/build folder. So the resulting folder for MSVC2003 solution will be drlvm/trunk/build/custom/msvc_2003. Ok. You're the expert. Note:This package does not complete today and contains only jitrino/encoder/em projects. If anyone has other MSVC project files for drlvm subprojects, please speak up. Offtopic: Geir, you said before you use IDEA for Java, so I think you like to use keyboard shortcuts instead of mouse. The Visual Assist plugin for MSVC allows me to work without mouse in Visual Studio too. I used to do a lot of win32 system programming, and really did like working in MSVC - but that was years ago. I just prefer to work under Linux. I hate to admit it, I've been using Eclipse a lot lately because of the C/C++ support :) geir On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I haven't used MSVC in about 6 years, so where is the right place to put the files from 1607 so that they are easily used by an MSVC user? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Recognizing lock objects
Geir Magnusson Jr. wrote:
+1
BTW, why call it RepositionLock?
That was just an example taken from the class I was looking at, I've
called them different names depending upon the inst var name.
Tim
Tim Ellison wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Salikh Zakirov wrote:
Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
A few reasons... first, it's much easier to track where things came
from, the svn revision, etc. Second, it's a single record of all
contributions to the project from non-committers, which is important
from the perspective of our IP tracking and provenance process.
Also, counting patches makes it easy to evaluate people for
committership - it's only one element, but an easy one
geir
Geir Magnusson Jr. wrote:
Can you open a JIRA with this, explaining what needs to be done, and
linking the other JIRAs as needed?
Thx
geir
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
`!(vt() 1)' failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being
compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op =
stub_disasm.get_opnd(0);
assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
I do not like JIRA too, but sending patches by email is even worse:
1) There are a lot of opened JIRA issues. How to track them all by email?
2) New people have no access to the old email threads
3) Patches sometimes are too big to be sent by email.
On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
Geir Magnusson Jr. wrote:
Can you open a JIRA with this, explaining what needs to be done, and
linking the other JIRAs as needed?
Thx
geir
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
`!(vt() 1)' failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
Hi gang,
the below patch fixes the problem that prevents DRLVM from being
compilable
on Linux/x86_64.
The TI itself does not work on x86_64, and the modification only fixes
compiler error.
diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
b/vm/vmcore/src/jvmti/jvmti_step.cpp
index d29ef32..b4180f6 100644
--- a/vm/vmcore/src/jvmti/jvmti_step.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
@@ -502,7 +502,7 @@ #endif
const InstructionDisassembler::Opnd stub_op =
stub_disasm.get_opnd(0);
assert(stub_op.kind ==
InstructionDisassembler::Kind_Imm);
-method = (Method *)stub_op.imm;
+method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [classlib][launcher] should we get rid of one of the HyPortLibrary function tables in DRLVM?
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, I see the same. I looked at the problem closer. It turned out to be the problem of Microsoft debugger. Seems like debug information is damaged somehow. What I did? I set breakpoint at line 290 of modules\luni\src\main\native\launcher\shared\main.c. Printed out args-portLibrary. It is valid structure at that moment. Make one step over the line 290. Ups ... args-portLibrary become invalid but line number 290 looks like if(newPathToAdd == NULL). So it can't crash portLibrary. I played a little with commenting out the code and got the same problem in different places. That's why I think this is debugger problem. Good catch! Thanks. This is finally making some sense. Even the debugger is getting confused with all the macros and, DLLs. The commonality between APR and classlib/port will be a maintenance problem. Thanks Evgueni On 10/2/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, Using windows debugger, I see native/launcher/shared/main.c::invocation() receive an incoming argument that looks to be a DRLVM version of HyPortLibrary with all the functions zeroed out. Does anyone else see this?? Passing a HyPortLibrary with the function ptrs nulled out is not the primary concern. At worst, this will cause a sigsegv and should be straight forward to debug. The big concern is accidentally using the classlib/HyPortLibrary function ptr table when DRLVM Threading Manager APIs are intended. This could cause all sorts of strange deadlocks. I have looked at the code to prove or disprove that the two HyPortLibraries are being confused. So far, no luck. There are too many layers to get to the bottom of this quickly. Does anyone know the answer to the above question? If not, should I open a JIRA on this issue? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib] Recognizing lock objects
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
+1
BTW, why call it RepositionLock?
That was just an example taken from the class I was looking at, I've
called them different names depending upon the inst var name.
Oh, thanks.
It might not be a bad idea to adopt a common pattern like FOOSyncLock
- might make it easier to search for hotspots in a profiler...
geir
Tim
Tim Ellison wrote:
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][depends] missing liblcms +em64t
Working on a patch, I've just wanted to check wether it works on em64t. It is not that easy as I expected. Yesterday, I have filed HARMONY-1676 to have classlib built. Today, I have: Missing dependency. The file from: /usr/lib/liblcms.a should be linked to: depends/libs/build/lcms/liblcms.ia32 But /usr/lib/liblcms.a doesn't exist. liblcms development package not installed For Debian/Ubuntu try: apt-get install liblcms1-dev First of all, why 'ia32' prefix for em64t build? Secondly, I'm happy for debian users, but not all of the users use debian. Much informative would be to have a URL with the sources where I can get the library. -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
6/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+ mkdir dir=${awtdeps.dir} /
+ download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar destfile=${bcprov.jar} basedir=${bcprov.dir}/temp
manifest=${bcprov.dir}/temp/META-INF/MANIFEST.MF /
delete dir=${bcprov.dir}/temp /
+/target
+
+target name=-awt-tar-extract unless=awtdeps.uptodate
+echoExtracting awt dependencies/echo
+ untar src=${awtdeps.tar} dest=${awtdeps.extract.dir}
+ compression=gzip /
+echo file=${awtdeps.testfile}
+ message=${awtdeps.tar} extracted${line.separator} /
/target
macrodef name=check-one-link
-
Terms of
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 4 October 2006 at 12:59, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 3 October 2006 at 8:12, Ivan Volosyuk (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments#act ion_ 12439536 ] Ivan Volosyuk commented on HARMONY-1676: copy these files into depends/libs/linux.x86_64 build with 'ant -Dos.arch=x86_64' I've just checked in a change to make/properties.xml (as r452774) that should add os.arch normalization for x86_64. (This basically duplicates what we did to handle the way the os.arch variables differ between reference jdks.) So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it doesn't work, can you let me know what os.arch says for the jdk you are using. Thanks, Mark. Well, I didn't download 64 bit version jdk, so I've just used the 32 bit version which works just fine on 64 bit version of linux. Jdk I use is: jrockit-jdk1.5.0-linux-ia32 (build 1.5.0-b64) And what is os.arch is set to? x86 or i386 or something? Probably not much we can do about that. Except perhaps create a user preferences file. Regards, Mark. I don't know, looks like that. Well, I am happy with current state. It is often quite painful for me to have number of property files. -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
Any reason why we couldn't do the same thing for linux that we're doing
for windows in terms of having these libraries pre-compiled and easy to
drop in?
geir
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
6/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+ mkdir dir=${awtdeps.dir} /
+ download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar destfile=${bcprov.jar} basedir=${bcprov.dir}/temp
manifest=${bcprov.dir}/temp/META-INF/MANIFEST.MF /
delete dir=${bcprov.dir}/temp /
+/target
+
+target name=-awt-tar-extract unless=awtdeps.uptodate
+echoExtracting awt dependencies/echo
+ untar src=${awtdeps.tar} dest=${awtdeps.extract.dir}
+ compression=gzip /
+echo file=${awtdeps.testfile}
+ message=${awtdeps.tar} extracted${line.separator} /
/target
macrodef name=check-one-link
[classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depen
Excuse the change in subject line...
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
6/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+mkdir dir=${awtdeps.dir} /
+download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar destfile=${bcprov.jar} basedir=${bcprov.dir}/temp
manifest=${bcprov.dir}/temp/META-INF/MANIFEST.MF /
delete dir=${bcprov.dir}/temp /
+/target
+
+target name=-awt-tar-extract unless=awtdeps.uptodate
+echoExtracting awt dependencies/echo
+untar src=${awtdeps.tar} dest=${awtdeps.extract.dir}
+ compression=gzip /
+echo file=${awtdeps.testfile}
+ message=${awtdeps.tar} extracted${line.separator} /
Re: [classlib][tools] package name for Keytool tests
Stepan Mishura wrote: Hi Anton, I think we should name tool's tests as classlib does. So for tools we will have: o.a.h.tools.toolname.tests Agreed. Regards, Tim On 10/4/06, Anton Rusanov [EMAIL PROTECTED] wrote: Hi, I'm going to add a test for Keytool but I don't know how to name the package for tests: org.apache.harmony.tests.tools.keytool like it is done for javac or org.apache.harmony.tools.keytool.tests like it was decided for classlib? -- Thanks, Anton -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][tools] The java class file disassembler contribution announcement.
Cool - thanks Dimitry! Tim Dmitry M. Kononov wrote: Hi all, I have developed a tool to disassemble the java class files. Its behavior is similar to the javap tool from J2SE 1.5.0. I would like it to be included in the Harmony tools project. The contribution can be found there: http://issues.apache.org/jira/browse/HARMONY-1680 The contribution archive contains the source files, building script and several text files. One of the text files is README, which explains in detail how the tool can be built and how you can use it as a standalone application. All the code is pure Java. Please don't hesitate to contact me for more details. Thanks. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][depends] missing liblcms +em64t
On 4 October 2006 at 18:26, Ivan Volosyuk [EMAIL PROTECTED] wrote: Working on a patch, I've just wanted to check wether it works on em64t. It is not that easy as I expected. Yesterday, I have filed HARMONY-1676 to have classlib built. Today, I have: Missing dependency. The file from: /usr/lib/liblcms.a should be linked to: depends/libs/build/lcms/liblcms.ia32 But /usr/lib/liblcms.a doesn't exist. liblcms development package not installed For Debian/Ubuntu try: apt-get install liblcms1-dev First of all, why 'ia32' prefix for em64t build? What does: j9 ant properties|grep arch give you? (Aside: I mentioned that these properties might not get set correctly for everyone in a note earlier today, but they are easy to fix with the output from the above generated with a jdk for em64t.) Secondly, I'm happy for debian users, but not all of the users use debian. Much informative would be to have a URL with the sources where I can get the library. I expected that users of other distributions would be able to also have packages available for all of these things. I have asked for details of the package for other distributions in the past but I assumed everyone must use Debian since no one provided any details. Suggesting users build from source should be a last resort. Personally, I'd like to take this further and use the .so versions of the system libraries rather than the static versions. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
gin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
t-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4
03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+ mkdir dir=${awtdeps.dir} /
+ download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar
Re: [classlib] enabling AWT/Swing by default
Tim Ellison wrote:
Excuse the change in subject line...
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
That means you probably want to have a flag to not run those tests...
geir
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
6/
-
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix if=is.unix
+target name=-check-unix if=is.unix
property name=lcms.msg
value=liblcms development package not installed
@@ -214,6 +219,10 @@
download-one-file src=${msvcr71.url} dest=${msvcr71.dll}
md5=${msvcr71.md5} /
+ mkdir dir=${awtdeps.dir} /
+ download-one-file src=${awtdeps.url} dest=${awtdeps.tar}
+ md5=${awtdeps.md5} /
+
/target
macrodef name=download-one-file
@@ -298,6 +307,14 @@
jar destfile=${bcprov.jar} basedir=${bcprov.dir}/temp
manifest=${bcprov.dir}/temp/META-INF/MANIFEST.MF /
delete dir=${bcprov.dir}/temp /
+/target
+
+target name=-awt-tar-extract unless=awtdeps.uptodate
+echoExtracting awt dependencies/echo
+ untar src=${awtdeps.tar} dest=${awtdeps.extract.dir}
+ compression=gzip /
+echo file=${awtdeps.testfile}
+ message=${awtdeps.tar}
[OT] E-mail vs. JIRA WAS: [patch][drlvm] Fix compilation on Linux/x86_64
Mikhail Fursov wrote: I do not like JIRA too, but sending patches by email is even worse: 1) There are a lot of opened JIRA issues. How to track them all by email? Tracking can be done by replying to messages. And if nobody cares about the patch, JIRA will not help -- patches in JIRA rot with exactly the same rate as they do in e-mail. 2) New people have no access to the old email threads Not true. Check out http://dir.gmane.org/gmane.comp.java.harmony.devel http://news.gmane.org/gmane.comp.java.harmony.devel (by the way, I read/post using Gmane NNTP gateway, and this also gives a fair amount of older postings). 3) Patches sometimes are too big to be sent by email. Agreed. E-mail is not a silver bullet, though it comes close :) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default
Mark Hindess wrote: On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote: Excuse the change in subject line... No problem. I was just cursing myself for having forgotten to change it. Mark Hindess wrote: With this change, the awt dependencies should now be automated for windows and at least fairly trivial (installing a few packages on Linux[0]). I think it is time we removed the with.awt.swing flag. Anyone object? To the contrary, ditch it. Please test the current setup with -Dwith.awt.swing=true and report any problems. Problem 1: My machine is too slow running all these tests. Mine too. And I have wondered if the hourly builds will finish within the hour now. We really should see if we can avoid the need to fork for every test. LOL. If our tests take more than an hour, so be it... Or, do a fast test set on one machine to get the earliest warning for the most amount of code, and a slower do it all machine that acts as a safety net geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
Since most (all?) distributions provide versions of these libraries (and
maintain them - regular security fixes for example) why would we want
to maintain them ourselves? It's not a job I'd want.
Really the same is true for zlib and to an extent icu. If someone
else is doing the work maintaining them, we should use what they are a
providing not make more work for ourselves. We should also try to use
the dynamic libraries if possible.
With the exception of icu, most of these libraries change very little
over time so there should be few if any interoperability issues.
I can only really see a good argument for maintaining icu binaries since
it is changing more frequently and many distributions seem to have
rather old versions.
Regards,
Mark.
On 4 October 2006 at 10:40, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Any reason why we couldn't do the same thing for linux that we're doing
for windows in terms of having these libraries pre-compiled and easy to
drop in?
geir
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
gin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
t-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4
03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+ targetfile=${awtdeps.testfile} /
-target name=-check-unix if=with.awt.swing
-antcall target=--check-unix /
/target
-target name=--check-unix
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 4 October 2006 at 18:41, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 4 October 2006 at 12:59, Ivan Volosyuk [EMAIL PROTECTED] wrote : On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 3 October 2006 at 8:12, Ivan Volosyuk (JIRA) [EMAIL PROTECTED] wro te: [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments #act ion_ 12439536 ] Ivan Volosyuk commented on HARMONY-1676: copy these files into depends/libs/linux.x86_64 build with 'ant -Dos.arch=x86_64' I've just checked in a change to make/properties.xml (as r452774) that should add os.arch normalization for x86_64. (This basically duplicate s what we did to handle the way the os.arch variables differ between reference jdks.) So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it doesn't work, can you let me know what os.arch says for the jdk you are using. Thanks, Mark. Well, I didn't download 64 bit version jdk, so I've just used the 32 bit version which works just fine on 64 bit version of linux. Jdk I use is: jrockit-jdk1.5.0-linux-ia32 (build 1.5.0-b64) And what is os.arch is set to? x86 or i386 or something? Probably not much we can do about that. Except perhaps create a user preferences file. I don't know, looks like that. Well, I am happy with current state. It is often quite painful for me to have number of property files. I'm not sure I understand your pain, but don't worry any user properties files will be entirely optional. You could always run a x86_64 jdk? Regards, Mark. -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 10/3/06, Vladimir Ivanov wrote: On 10/2/06, Oliver Deakin wrote: ... Does this sound reasonable? Seems, that everybody thinking about separated test jar for each module (I proposed one jar as first step onlyJ). Now, we should implement this. If you need any help I'm a volunteer. This won't work for all resource files, for example, there are a number of tests for a config parser and they need a path to a config file. Thanks, Stepan. thanks, Vladimir Regards, Oliver We may also supply the build file with placeholders for user classes tests dirs that will be prepended to classpath/bootclasspath. Regards, 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If I recall, the point of the test.jar was to have a pre-built jar of tests in the HDK so that someone could setup the build-test infra using the HDK so they could run tests on their platform w/o having to build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would have to be configured to have the classlib test target use that jar. All I'm saying is that how we do this is important, as we don't want to cause pain for classlib developers who use the HDK for development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir geir Thanks, Vladimir Thanks, Vladimir geir Thanks, Vladimir On 7/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: They are at the regular place http://people.apache.org/dist/incubator/harmony/snapshots I moved all the old classlib snapshots into /old and I'll update the website accordingly. I'll be automating this. Also, lets not make much noise about this for a little while so we can test to make sure there's no major errors. Things seem good. I have a list of more things to fix, but I realized today that I was obsessing over the snapshot contents - it's not a release, and it's good enough. I'd like to ditch both /old and the remaining classlib snapshots, as 1) they are snapshots - history doesn't matter 2) the classlib is now in the HDK, so we just need to adjust the docs to match. I'll do the latter, but wanted to see if anyone has a problem w/ me removing /old and the last classlib snapshot. I'll do this if I don't hear any protest, so either positively acknowledge this action if you support it, dont' do a thing if you support or dont' care, or say why we shouldn't :) geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][depends] missing liblcms +em64t
On 4 October 2006 at 18:26, Ivan Volosyuk [EMAIL PROTECTED] wrote: Working on a patch, I've just wanted to check wether it works on em64t. It is not that easy as I expected. Yesterday, I have filed HARMONY-1676 to have classlib built. Today, I have: Missing dependency. The file from: /usr/lib/liblcms.a should be linked to: depends/libs/build/lcms/liblcms.ia32 But /usr/lib/liblcms.a doesn't exist. liblcms development package not installed For Debian/Ubuntu try: apt-get install liblcms1-dev First of all, why 'ia32' prefix for em64t build? One second look, this seems to be a different problem. It looks like I accidentally hardcode ia32 - but since that's all that we really support at the moment then I'm not that sorry. The wider issue is that for historical reasons the awt build still uses ia32 and ipf where as it should probably be fixed to use the hy.arch defines of x86 and x86_64 (and ia64 if necessary but we don't really cover that yet anyway). Patches welcome or I'll try to take a look in the next day or so. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Thanks,
Mikhail
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
gin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
t-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4
03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url}
Re: [drlvm] apr_dso_load error (path address out of bounds)
Egor Pasko wrote: On the 0x1F8 day of Apache Harmony Armand Navabi wrote: Sorry about the last email, but there is something I think I should mention. I recently checked out a clean copy and rebuilt from scratch. I did not notice BUT since then, helloworld does actually run!! It just hangs after it runs. Now the behavior is very similar to when I run ./java -showversion (i.e. prints out version information and then hangs). I plan to look into this. You mean, it hangs right before the exit? And prints OK? Then the library should load OK. Yes, for -showversion it always prints OK and then hangs. I have noticed that for helloworld, it runs successfully (i.e. prints Hello World) and then hangs half the time, and then it just hangs, never printing anything, the other half of the time. I think the libraries are loading OK. But when I run gdb, I still see: apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds, pool=0x808fc78) at dso.c:139 139 os_handle = dlopen(path, flags); And.. I suppose you applied the gdb enabling patch for that? hm, I cannot believe this is a GDB problem... :( There are some modes you can try for fun: -Xem:opt -- use only agressive compiler (OPT) -Xem:jet -- use only fast JIT (JET) -Xint-- do not use compilers, use interpreter (no libjitrino.so sould be loaded in this mode) ./java -Xem:opt helloworld: Never works (always hangs) ./java -Xem:jet helloworld: Works half the time (seems to work as often as running normally) ./java -Xint helloworld: Never works (always hangs) Despite this, it seems to still run fine after that point (i.e. Hello World executes after all the libraries are loaded, even though every single load seems to fail because of the address not found problem). Can you pass the library load in GDB? Does it work fine if it is not single stepped? I do pass the library load in GDB. If I just run helloworld in gdb it almost always will print hello world. Here is what happens whenever I just run it in GDB: (gdb) r helloworld Starting program: /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 20330)] [New Thread 32769 (LWP 20333)] [New Thread 16386 (LWP 20334)] [New Thread 32771 (LWP 20335)] Hello World! [New Thread 49156 (LWP 20336)] Program received signal SIGUSR2, User defined signal 2. [Switching to Thread 16384 (LWP 20330)] 0xb7ac8b74 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) bt #0 0xb7ac8b74 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0xb7ac82a7 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0xb7ac8928 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0 #3 0x in ?? () (gdb) This is what I've resorted to now. I just run it in GDB. Do you think the problem could have to do with GLIBC? I'm looking into this, after I found this online: http://forums.gentoo.org/viewtopic-t-388284.html Anyway, I'm running hello world now, and so I'm happy. not very much, though Are you collecting HelloWorlds? :) Yeah, I'm less happy now. I was dealing with the initial excitement at that point of finally seeing Hello World. :) Thanks, Armand Thanks, Armand -Original Message- From: Armand Navabi [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 3:22 PM To: harmony-dev@incubator.apache.org Subject: RE: [drlvm] apr_dso_load error (path address out of bounds) I thought that perhaps a gdb backtrace may be helpful. Note: I also tried to go into dll_jit.cpp:62 and hard code the name of the dll_filename which is passed to apr_dso_load. And still when I step into apr_dso_load that second argument path=0x102 Address 0x102 out of bounds. Perhaps the stack is getting messed up somehow. Any ideas? (gdb) bt #0 apr_dso_load (res_handle=0x102, path=0x102 Address 0x102 out of bounds, pool=0x808fc78) at dso.c:139 #1 0xb6d99b61 in Dll_JIT (this=0x80a9650, dll_filename=0x80a9774 /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji trino.so) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/jit/dll_jit.cpp:63 #2 0xb6e4ff4e in vm_load_jit ( file_name=0x80a9774 /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/default//libji trino.so, handle=0xbfa9e51c) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/vmcore/src/init/vm_main.cpp:629 #3 0xb69afa9e in DrlEMImpl::buildChains (this=0x80a9480, [EMAIL PROTECTED]) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:437 #4 0xb69af256 in DrlEMImpl::init (this=0x80a9480) at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:363 #5 0xb69ad239 in DrlEMFactory::createAndInitEMInstance () at /scratch/anavabi/Harmony/enhanced/drlvm/vm/em/src/DrlEMImpl.cpp:52 #6 0xb69c7a72 in CreateInstance (p_instance=0xb7022f88,
Re: [classlib][depends] missing liblcms +em64t
On 4 October 2006 at 16:10, Mark Hindess [EMAIL PROTECTED] wrote: On 4 October 2006 at 18:26, Ivan Volosyuk [EMAIL PROTECTED] wrote: Working on a patch, I've just wanted to check wether it works on em64t. It is not that easy as I expected. Yesterday, I have filed HARMONY-1676 to have classlib built. Today, I have: Missing dependency. The file from: /usr/lib/liblcms.a should be linked to: depends/libs/build/lcms/liblcms.ia32 But /usr/lib/liblcms.a doesn't exist. liblcms development package not installed For Debian/Ubuntu try: apt-get install liblcms1-dev First of all, why 'ia32' prefix for em64t build? One second look, this seems to be a different problem. It looks like I accidentally hardcode ia32 - but since that's all that we really support at the moment then I'm not that sorry. The wider issue is that for historical reasons the awt build still uses ia32 and ipf where as it should probably be fixed to use the hy.arch defines of x86 and x86_64 (and ia64 if necessary but we don't really cover that yet anyway). Patches welcome or I'll try to take a look in the next day or so. I've checked in a quick hack (r452910) that should workaround the problem until we resolve the wider issue with the inconsistent architecture variables. Let me know how you get on with the x86_64 building. (It fails for me with a compiler/binutils bug sadly.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default
2006/10/4, Geir Magnusson Jr. [EMAIL PROTECTED]: Mark Hindess wrote: On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote: Excuse the change in subject line... No problem. I was just cursing myself for having forgotten to change it. Mark Hindess wrote: With this change, the awt dependencies should now be automated for windows and at least fairly trivial (installing a few packages on Linux[0]). I think it is time we removed the with.awt.swing flag. Anyone object? To the contrary, ditch it. Please test the current setup with -Dwith.awt.swing=true and report any problems. Problem 1: My machine is too slow running all these tests. Mine too. And I have wondered if the hourly builds will finish within the hour now. We really should see if we can avoid the need to fork for every test. LOL. If our tests take more than an hour, so be it... Do you place workspace on a network? I had similar problems but once I've put everything locally the tests now run 22 minutes (with awtswing) Thanks, Mikhail Or, do a fast test set on one machine to get the earliest warning for the most amount of code, and a slower do it all machine that acts as a safety net geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
Mark Hindess wrote:
Since most (all?) distributions provide versions of these libraries (and
maintain them - regular security fixes for example) why would we want
to maintain them ourselves? It's not a job I'd want.
I'm not advocating maintenance, but simply defining the set that we
build and test with.
I'm not a fan of having certified builds be dependent on whatever random
stuff the user downloads to /usr/lib
Really the same is true for zlib and to an extent icu. If someone
else is doing the work maintaining them, we should use what they are a
providing not make more work for ourselves. We should also try to use
the dynamic libraries if possible.
Yes, on the first sentence, not so sure on the last, simply because
there's value in testing a fixed set of versions of stuff.
With the exception of icu, most of these libraries change very little
over time so there should be few if any interoperability issues.
I can only really see a good argument for maintaining icu binaries since
it is changing more frequently and many distributions seem to have
rather old versions.
Regards,
Mark.
On 4 October 2006 at 10:40, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Any reason why we couldn't do the same thing for linux that we're doing
for windows in terms of having these libraries pre-compiled and easy to
drop in?
geir
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
gin
al)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
t-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4
03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+target name=-check-win if=is.windows
+depends=-really-check-win,-awt-tar-extract /
+
+target name=-really-check-win if=is.windows
check-one-file src=${msvcr71.url} dest=${msvcr71.dll} /
-/target
+check-one-file src=${awtdeps.url} dest=${awtdeps.tar} /
+
+ uptodate property=awtdeps.uptodate
+ srcfile=${awtdeps.tar}
+
Re: [classlib][depends] missing liblcms +em64t
Mark Hindess wrote: On 4 October 2006 at 18:26, Ivan Volosyuk [EMAIL PROTECTED] wrote: Working on a patch, I've just wanted to check wether it works on em64t. It is not that easy as I expected. Yesterday, I have filed HARMONY-1676 to have classlib built. Today, I have: Missing dependency. The file from: /usr/lib/liblcms.a should be linked to: depends/libs/build/lcms/liblcms.ia32 But /usr/lib/liblcms.a doesn't exist. liblcms development package not installed For Debian/Ubuntu try: apt-get install liblcms1-dev First of all, why 'ia32' prefix for em64t build? One second look, this seems to be a different problem. It looks like I accidentally hardcode ia32 - but since that's all that we really support at the moment then I'm not that sorry. The wider issue is that for historical reasons the awt build still uses ia32 and ipf where as it should probably be fixed to use the hy.arch defines of x86 and x86_64 (and ia64 if necessary but we don't really cover that yet anyway). +1 Patches welcome or I'll try to take a look in the next day or so. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Done. HARMONY-1698. Mark, it looks like you already started looking into it, that's *real* quick. Thanks a lot! Geir Magnusson Jr. wrote: Can you open a JIRA with this, explaining what needs to be done, and linking the other JIRAs as needed? Salikh Zakirov wrote: The patch turned out to be exact duplicate of HARMONY-1571. Besides, there exist a patch with fixes for unit tests: HARMONY-1574. The following change is needed on top of already committed HARMONY-1551 to make DRLVM start on Linux/x86_64. However, it still doesn't work properly, failing with java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167: Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion `!(vt() 1)' failed. The assertion failure were caused by the leftover patch from HARMONY-1372, which didn't make it to SVN (gcv41_em64t_vm_changes.diff) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] apr_dso_load error (path address out of bounds)
Armand Navabi wrote: I do pass the library load in GDB. If I just run helloworld in gdb it almost always will print hello world. Here is what happens whenever I just run it in GDB: (gdb) r helloworld Starting program: /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 20330)] [New Thread 32769 (LWP 20333)] [New Thread 16386 (LWP 20334)] [New Thread 32771 (LWP 20335)] Hello World! [New Thread 49156 (LWP 20336)] Program received signal SIGUSR2, User defined signal 2. DRLVM uses SIGUSR2 for thread suspension, so it is convenient to put following configuration into .gdbinit: handle SIGUSR2 nostop noprint pass Though I am a little bit surprised that you see it on a HelloWorld application. Usually thread suspension is initiated by the garbage collection, and HelloWorld usually doesn't allocate as much memory as needed to trigger garbage collection. I've just double-checked, and HelloWorld completes without single SIGUSR2 on my machine (Linux SUSE 9, x86) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
+1 And the JIRA has logging properties as well. On several threads now, email patches have just caused more confusion, with participants asking if these are examples or live code. On 10/4/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I do not like JIRA too, but sending patches by email is even worse: 1) There are a lot of opened JIRA issues. How to track them all by email? 2) New people have no access to the old email threads 3) Patches sometimes are too big to be sent by email.
Re: [drlvm] HARMONY-1607 : where is the right place to put it?
MIkhail, Are you going to keep these files ( sln and projects ) updated, since they are now becoming a part of the main codebase? Thx, Rana On 10/4/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Geir, I created this package to have a common place with other MSVC users in JIRA and I did not expect you want to put it into the trunk :) But if you decided to add it I suggest adding it to the drlvm/trunk/build folder. So the resulting folder for MSVC2003 solution will be drlvm/trunk/build/custom/msvc_2003. Note:This package does not complete today and contains only jitrino/encoder/em projects. If anyone has other MSVC project files for drlvm subprojects, please speak up. Offtopic: Geir, you said before you use IDEA for Java, so I think you like to use keyboard shortcuts instead of mouse. The Visual Assist plugin for MSVC allows me to work without mouse in Visual Studio too. -- Mikhail Fursov
[classlib][swing] JUnit test failure
First time running the AWT/Swing tests for a while. On r452910 I see the following (one and only) failure on IA32 WinXP: java.lang.NullPointerException at javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75) at java.awt.EventDispatchThread.run(EventDispatchThread.java:48) Am I alone? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default
ah, just read this after posting the same note myself.
So yes, I see the same.
Regards,
Tim
Mikhail Loenko wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and
report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Thanks,
Mikhail
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified:
incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
---
incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
gin
al)
+++
incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
Oct
4 03:24:29 2006
@@ -98,3 +98,11 @@
servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
t-a
pi-2.5-6.0.0.jar
+
+people.apache.base=http://people.apache.org/~geirm/harmony/
+awtdeps.dir=${depends.dir}/libs/windows.x86
+awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
+awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
+awtdeps.extract.dir=${depends.dir}/libs/build
+awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.xml?view=diffrev=452826r1=452825r2=452826
==
===
=
--- incubator/harmony/enhanced/classlib/trunk/make/depends.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Wed Oct 4
03:
24:29 2006
@@ -72,17 +72,22 @@
/target
-target name=-check-win if=is.windows
+
Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
Alex Blewitt wrote:
I use TODOs a lot in my code to remind me to come back to that
particular piece and do the job properly. If someone else were to
remove them then they may not do the right thing as far as the code
needs ... so I'd expect at least some kind of heads-up before this
would happen :-)
I'd say leave the TODOs alone, at least until we're in a phase where
such polishing up is desired.
+1
Leave them in unless you put them in or are fixing it.
Regards,
Tim
On 04/10/06, Nathan Beyer [EMAIL PROTECTED] wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of
commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
Geir Magnusson Jr. wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance +1 -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1607 : where is the right place to put it?
On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mikhail Fursov wrote: Geir, I created this package to have a common place with other MSVC users in JIRA and I did not expect you want to put it into the trunk :) Well, I think that we should put these things in SVN if we can, rather than use JIRA as some kind of storage. I think that some docs on this for the website would be nice, as well as for Eclipse and any other environments that people use. But if you decided to add it I suggest adding it to the drlvm/trunk/build folder. So the resulting folder for MSVC2003 solution will be drlvm/trunk/build/custom/msvc_2003. Ok. You're the expert. Please take time to put an accurate directory tree in place. I looked at the zip file. From what I can see, it contains MSVC project files for only a subset of DRLVM. At a later date, someone might want to donate MSVC project files for the GC for example. Also, a readme that describes the intended use of the project files would be nice. Note:This package does not complete today and contains only jitrino/encoder/em projects. If anyone has other MSVC project files for drlvm subprojects, please speak up. Offtopic: Geir, you said before you use IDEA for Java, so I think you like to use keyboard shortcuts instead of mouse. The Visual Assist plugin for MSVC allows me to work without mouse in Visual Studio too. I used to do a lot of win32 system programming, and really did like working in MSVC - but that was years ago. I just prefer to work under Linux. I hate to admit it, I've been using Eclipse a lot lately because of the C/C++ support :) geir On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I haven't used MSVC in about 6 years, so where is the right place to put the files from 1607 so that they are easily used by an MSVC user? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm] HARMONY-1607 : where is the right place to put it?
On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mikhail Fursov wrote: Geir, I created this package to have a common place with other MSVC users in JIRA and I did not expect you want to put it into the trunk :) Well, I think that we should put these things in SVN if we can, rather than use JIRA as some kind of storage. I think that some docs on this for the website would be nice, as well as for Eclipse and any other environments that people use. But if you decided to add it I suggest adding it to the drlvm/trunk/build folder. So the resulting folder for MSVC2003 solution will be drlvm/trunk/build/custom/msvc_2003. Ok. You're the expert. Please take time to put an accurate directory tree in place. I looked at the zip file. From what I can see, it contains MSVC project files for only a subset of DRLVM. At a later date, someone might want to donate MSVC project files for the GC for example. Also, a readme that describes the intended use of the project files would be nice. There is a README, and what would you suggest I do differently at this point? oops, sorry I was looking at the wrong directory. I agree. Simply commit it as suggested. We will all have to be aware that the project files can become stale and thus cause confusion. I really couldn't care less how this goes - just wanted to get it in there in a way that's easy for others to use geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Thanks,
Mikhail
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
(props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified:
incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
---
[classlib][x86_64] libhythr.so linking problem
I get compilation problems on x86_64. It looks to me like a gcc/binutils issue: [exec] cc -shared -Wl,--version-script,libhythr.exp \ [exec] -Wl,-soname=libhythr.so -o ../libhythr.so \ [exec] ../shared/thread_copyright.o x86_64/thrhelp.o x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o thrdsup.o ../shared/thrprof.o -lpthread \ [exec] -Xlinker --start-group /home/beanz/hy/Harmony.new/deploy/lib/libhypool.a /home/beanz/hy/Harmony.new/deploy/lib/libhycommon.a -Xlinker --end-group \ [exec] -lc -lm -ldl [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/bin/ld: final link failed: Bad value [exec] collect2: ld returned 1 exit status [exec] make: *** [../libhythr.so] Error 1 Anyone any ideas? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] manifest information
Can we consider making the final manifest that goes into our jars to be created/updated dynamically? I just went through all manifests and added Specification-Version, Implementation-Version, etc and they will change, at least the last one. I know the Eclipse people depend on them, so maybe can we used ant's filtering to set the Impl-Version dynamically? Or something like that? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [r451637] - Code cleanup - ... - Remove unnecessary comments
-Original Message-
From: Alexey Varlamov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 5:13 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
2006/10/4, Nathan Beyer [EMAIL PROTECTED]:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
Logging and printing to console essentially differ in flexible
customization offered by the first approach. An application can have
no console after all.
We develop the common class library here, not an ordinary application
- so let's not assume it will be used in some particular way.
Every JRE that's I've worked with since Java SE 1.4, distributes a default
configuration with the logging level set to INFO, so logging a warning, as
the TODO indicated, would write out just as frequently as printing a stack
trace. I wasn't assuming a particular use, I was assuming the default, out
of the box use.
-Nathan
In this concrete case, stack trace is printed every time invalid input
data is supplied - and it is normal for a unit test to cover some
negative cases.
But seeing console jammed with that rubbish is quite confusing (for me
at least). OTOH, such info would be valuable for app developer - so
why not satisfy both?
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
Because we have more priority tasks to be done. We just haven't
reached that stage of completeness, when we can afford minor refining
and polishing. Never say never, you know :)
Please, announce ahead if you do such things in future.
--
Regards,
Alexey
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of
commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultCon
figurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [r451637] - Code cleanup - ... - Remove unnecessary comments
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 11:17 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
Alex Blewitt wrote:
I use TODOs a lot in my code to remind me to come back to that
particular piece and do the job properly. If someone else were to
remove them then they may not do the right thing as far as the code
needs ... so I'd expect at least some kind of heads-up before this
would happen :-)
I'd say leave the TODOs alone, at least until we're in a phase where
such polishing up is desired.
+1
Leave them in unless you put them in or are fixing it.
Regards,
Tim
I did put in a fix; I replaced the TODO with the stack trace print. It is my
OPINION that TODO comments are, in general (80%), crap, but I've only
replaced TODOs in Harmony with actual code or documentation.
-Nathan
On 04/10/06, Nathan Beyer [EMAIL PROTECTED] wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
-Nathan
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of
commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it
produces
garbage messages during AUTH testing:
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultCon
figurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}
--
WBR,
Alexey
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] Recognizing lock objects
There may be value in doing this, but what's the increase in class file
overhead? Every new class that gets created for these locks ends up as
another class file that has to be stored (takes up drive space) and has to
be loaded (takes up memory in the class loader). Ever additional class file
takes up at least 1K of space on Windows.
How many of these locks are we talking about?
-Nathan
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 6:30 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Recognizing lock objects
Mikhail Fursov wrote:
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
Yep -- I'm inclined to keep the meaningful name.
Reagrds,
Tim
On 10/3/06, Tim Ellison [EMAIL PROTECTED] wrote:
private class RepositionLock {}
private Object repositionLock = new RepositionLock();
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][logging] Best practices for logging within the Class Library?
There seem to be a number of places where logging would be useful within the class library (and Java parts of the VM), but the rules of engagement seems to be undefined, so it's not being used. Here's my super-duper high-level swipe at it. 1. Use java.util.logging for normal logging (somewhat obvious). 2. Do not use java.util.logging within luni, security and kernel modules; this is to prevent cyclical executions. 3. Use the class name for the name of the Logger; this is based on the assumption that classes will be packaged appropriately such that logging can be enabled by packages to get sub-system information. 4. Use the java.util.logging.Level javadoc [1] as a guide for the appropriate logging level for a particular message. When in doubt, be conservative and use lower levels (less than INFO). Thoughts, comments? The big question in my mind is what modules must be isolated from consuming java.util.logging (regarding 2 above). The other modules that might need isolation are archive and text, but I'm not sure about that. Any others? -Nathan [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Level.html - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? Why do we as the Harmony project care? Now we have 2 VM at Harmony and to check API behavior I use both of them. It will be more comfortable for me to have one arguments set for both VMs. So, I think about my conveniences only :) Thanks, Vladimir geir thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 10/4/06, Stepan Mishura [EMAIL PROTECTED] wrote: Seems, that everybody thinking about separated test jar for each module (I proposed one jar as first step onlyJ). Now, we should implement this. If you need any help I'm a volunteer. This won't work for all resource files, for example, there are a number of tests for a config parser and they need a path to a config file. Agree. Seems, separated 'modules.resource.jar' for each module should be created too. Tahnks, Vladimir Thanks, Stepan. thanks, Vladimir Regards, Oliver We may also supply the build file with placeholders for user classes tests dirs that will be prepended to classpath/bootclasspath. Regards, 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If I recall, the point of the test.jar was to have a pre-built jar of tests in the HDK so that someone could setup the build-test infra using the HDK so they could run tests on their platform w/o having to build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would have to be configured to have the classlib test target use that jar. All I'm saying is that how we do this is important, as we don't want to cause pain for classlib developers who use the HDK for development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir geir Thanks, Vladimir Thanks, Vladimir geir Thanks, Vladimir On 7/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: They are at the regular place http://people.apache.org/dist/incubator/harmony/snapshots I moved all the old classlib snapshots into /old and I'll update the website accordingly. I'll be automating this. Also, lets not make much noise about this for a little while so we can test to make sure there's no major errors. Things seem good. I have a list of more things to fix, but I realized today that I was obsessing over the snapshot contents - it's not a release, and it's good enough. I'd like to ditch both /old and the remaining classlib snapshots, as 1) they are snapshots - history doesn't matter 2) the classlib is now in the HDK, so we just need to adjust the docs to match. I'll do the latter, but wanted to see if anyone has a problem w/ me removing /old and the last classlib snapshot. I'll do this if I don't hear any protest, so either positively acknowledge this action if you support it, dont' do a thing if you support or dont' care, or say why we shouldn't :) geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][jit] possible ABCD bug
On Oct 4, 2006, at 12:53 AM, Egor Pasko wrote: One more to say on the patch: +//meetBest(Reduced, x) = Reduced should be: +//meetBest(Reduced, x) = Reduced (just a comment, but still...) so, could you, please, refresh the patch with my suggestions implemented? Will do, once we come to agreement above. we have it now Ok, I updated the patch. However I also added a few more changes. :-) Basically, I redefined the ProveResult enum so that the lattice True Reduced False is also true using integer arithmetic. What do you think? Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][build] build failure
Seems, that after todays update I can't build DRL VM. Can anybode else reproduce it? Thanks Vladimir ...update -r HEAD C:/harmony/drlvm1.5 At revision 453100. = ... build.native.init: [echo] ## Building native of 'vm.vmi' [mkdir] Created dir: C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\semis\vm\vmi\_bin [mkdir] Created dir: C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\semis\vm\vmi\_obj build.native.c: [cc] 0 total files to be compiled. build.native.cpp: [cc] 2 total files to be compiled. [cc] cl : Command line warning D4025 : overriding '/Ox' with '/Od' [cc] j9vmls.cpp [cc] C:\harmony\drlvm1.5\vm\vmi\src\j9vmls.cpp(21) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\harmony\drlvm1.5\vm\vmi\src\vmi.cpp(26) : fatal error C1083: Cannot open include file: 'zipsup.h': No such file or directory [cc] Generating Code... BUILD FAILED C:\harmony\drlvm1.5\build\make\build.xml:406: The following error occurred while executing this line: C:\harmony\drlvm1.5\build\make\build.xml:413: The following error occurred while executing this line: C:\harmony\drlvm1.5\build\make\build_component.xml:72: The following error occurred while executing this line: C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\semis\build\targets\build.native.xml:75: cl failed with return code 2
Re: [drlvm][build] build failure
Thanks everyone. It was fixed by rebuild the my copy of classlib module. thanks, Vladimir On 10/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: Seems, that after todays update I can't build DRL VM. Can anybode else reproduce it? Thanks Vladimir ...update -r HEAD C:/harmony/drlvm1.5 At revision 453100. = ... build.native.init: [echo] ## Building native of 'vm.vmi' [mkdir] Created dir: C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\semis\vm\vmi\_bin [mkdir] Created dir: C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\semis\vm\vmi\_obj build.native.c: [cc] 0 total files to be compiled. build.native.cpp: [cc] 2 total files to be compiled. [cc] cl : Command line warning D4025 : overriding '/Ox' with '/Od' [cc] j9vmls.cpp [cc] C:\harmony\drlvm1.5\vm\vmi\src\j9vmls.cpp(21) : fatal error C1083: Cannot open include file: ' hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\harmony\drlvm1.5\vm\vmi\src\vmi.cpp(26) : fatal error C1083: Cannot open include file: 'zipsup.h': No such file or directory [cc] Generating Code... BUILD FAILED C:\harmony\drlvm1.5\build\make\build.xml:406: The following error occurred while executing this line: C:\harmony\drlvm1.5\build\make\build.xml:413: The following error occurred while executing this line: C:\harmony\drlvm1.5\build\make\build_component.xml:72: The following error occurred while executing this line: C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\semis\build\targets\build.native.xml:75: cl failed with return code 2
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
2006/10/5, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Yes, please. When you submit a patch people will have a chance
to review and comment
Thanks,
Mikhail
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Thanks,
Mikhail
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
(props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified:
incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
