Re: [testing] test suite layout, testNG, and more
On 10/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: What is the status of our discussions about new test suite layout? Long ago we decided not to move existing tests until we finish with that discussion but the discussion seems to be either dead or in coma It's not dead ;-) We are waiting for the completion of j.u.concurrent so that we could run a pilot and continue our discussion. Does it make sense to continue putting the tests in order (according to the old model) and relayout them as soon as we finish the discussion? Yes, it does make sense. Before we draw any new conclusion about TestNG, I suggest we follow our existing testing conventions/guidelines. Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[testing] test suite layout, testNG, and more
What is the status of our discussions about new test suite layout? Long ago we decided not to move existing tests until we finish with that discussion but the discussion seems to be either dead or in coma Does it make sense to continue putting the tests in order (according to the old model) and relayout them as soon as we finish the discussion? Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can't get binary to work
> Yes, I am still having problems. > > Like I said, I am just trying to run the executable currently. I see the > same problem I was seeing when I built the DRLVM. > > I downloaded the Latest Linux JRE snapshot build, set the JAVA_HOME, PATH > and LD_LIBRARY_PATH environment variables and then tried to run > helloworld. Sometimes the executable will print "hello world!" and then > hang, and sometimes it will just hang. Same thing happens when I download > and try to run the Latest Linux HDK with helloworld. > > My platform is Linux Gentoo 2.6.17.8. Since I see the same exact thing when I actually build it myself, perhaps this is useful. This is what happens in gdb for the version I build: Starting program: /scratch/anavabi/Harmony/trunk/working_vm/build/lnx_ia32_gcc_debug/deploy/jr e/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1304)] [New Thread 32769 (LWP 1305)] [New Thread 16386 (LWP 1306)] [New Thread 32771 (LWP 1307)] Program received signal SIGUSR2, User defined signal 2. [Switching to Thread 16384 (LWP 1304)] 0xb7b2caab in read () from /lib/libpthread.so.0 (gdb) bt #0 0xb7b2caab in read () from /lib/libpthread.so.0 #1 0xb6fc7be0 in ?? () from /scratch/anavabi/Harmony/trunk/working_vm/build/lnx_ia32_gcc_debug/deploy/jr e/bin/default/libharmonyvm.so #2 0x in ?? () Even when it successfully prints "hello world!", it still exists this same way (Program received signal SIGUSR2, User defined signal 2) from libpthread.so. Perhaps my pthread libraries are out of date? Thanks, Armand -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, October 08, 2006 6:57 PM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work Are you still having problems Armand? Tim Armand Navabi wrote: > I have been unable to figure out why I can't get the drlvm to run > helloworld. The classlib with Intel's VM works fine. > > > > So now I thought I'd just see if I could download the binary and execute it > (JRE), but it is behaving the same way (I guess this is to be expected, but > I just wanted to make sure it wasn't something in the build process that was > causing the trouble). > > > > When I run java by itself it executes without problem, when I run "java > helloworld" it just hangs, and "java -showversion" will print version info > and then hang right after that: > > > > [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/bin $ ./java > -showversion > > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > > java version "1.5.0" > > pre-alpha : not complete or compatible > > svn = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build > > http://incubator.apache.org/harmony > > (hangs here) > > > > Here are the environment variables that I think are relevant: > > > > LD_LIBRARY_PATH > > /scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha > rmony-jre-r450941/bin/default/ > > PATH > > .:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi > n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b > in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1 > > JAVA_HOME > > /scratch/anavabi/Harmony/harmony-jre-r450941/bin > > > > I'm on Gentoo 2.6.17.8. > > Any ideas what may be going on? > > > > Thanks, > > Armand > > -- 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: Can't get binary to work
Yes, I am still having problems. Like I said, I am just trying to run the executable currently. I see the same problem I was seeing when I built the DRLVM. I downloaded the Latest Linux JRE snapshot build, set the JAVA_HOME, PATH and LD_LIBRARY_PATH environment variables and then tried to run helloworld. Sometimes the executable will print "hello world!" and then hang, and sometimes it will just hang. Same thing happens when I download and try to run the Latest Linux HDK with helloworld. My platform is Linux Gentoo 2.6.17.8. Thanks, Armand -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, October 08, 2006 6:57 PM To: harmony-dev@incubator.apache.org Subject: Re: Can't get binary to work Are you still having problems Armand? Tim Armand Navabi wrote: > I have been unable to figure out why I can't get the drlvm to run > helloworld. The classlib with Intel's VM works fine. > > > > So now I thought I'd just see if I could download the binary and execute it > (JRE), but it is behaving the same way (I guess this is to be expected, but > I just wanted to make sure it wasn't something in the build process that was > causing the trouble). > > > > When I run java by itself it executes without problem, when I run "java > helloworld" it just hangs, and "java -showversion" will print version info > and then hang right after that: > > > > [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/bin $ ./java > -showversion > > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > > java version "1.5.0" > > pre-alpha : not complete or compatible > > svn = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build > > http://incubator.apache.org/harmony > > (hangs here) > > > > Here are the environment variables that I think are relevant: > > > > LD_LIBRARY_PATH > > /scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha > rmony-jre-r450941/bin/default/ > > PATH > > .:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi > n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b > in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1 > > JAVA_HOME > > /scratch/anavabi/Harmony/harmony-jre-r450941/bin > > > > I'm on Gentoo 2.6.17.8. > > Any ideas what may be going on? > > > > Thanks, > > Armand > > -- 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: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
I put debug printing into test_ti_instrum.c and attached it to JIRA. Could you run it on your machine and send me console output. Evgueni On 10/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I keep getting a failure when running the tests - test_jthread_get_all-threads failling the assertion at test_ti_instrum.c:80 geir On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote: > While running cunit on Linux it turned out one test case fails some > time. The fix is in tests.final.2.patch. > > So the last versions to be committed: > invocation_api.final.patch > build.final.2.patch > tests.final.2.patch > > Evgueni > > > On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: >> I mahaged to resolve the problem on Linux will update >> build.final.patch with build.final.2.patch in a while >> >> On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > Oh! Ooh! I did that. I passed cunit, somke, kernel tests on >> > Windows and smoke, kernel tests on Linux. Unfortunately I failed to >> > link cunit tests on Linux so far. So I disabled cunit on Linux >> until >> > the problem is solved. I believe it is acceptable as short term >> > solution. I found several problems in cunit tests. I will come >> up with >> > my findings later (not today). >> > >> > Use latest patches from HARMONY-1582. They are marked as final. >> There >> > are three patches. One for build module, one for cunit tests and >> one >> > for VM itself. >> > >> > Thanks >> > Evgueni >> > >> > >> > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > > Nooo! LOL >> > > >> > > I'm here waiting - This will unblock a whole bunch of things :) >> > > >> > > Thanks for the effort >> > > >> > > Evgueni Brevnov wrote: >> > > > Geir, >> > > > >> > > > That's terrible. We have power outageservers are down. I >> can't >> > > > send the patches now will do it tomorrow >> > > > >> > > > Evgueni >> > > > On 10/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > > >> woo hoo! here we go... >> > > >> >> > > >> >> > > >> Andrey Chernyshev wrote: >> > > >> > Hi Evgueni, >> > > >> > >> > > >> > On 10/4/06, Evgueni Brevnov <[EMAIL PROTECTED]> >> 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 for updating the patch! I agree it it can be >> committed, at >> > > >> > least signatures look good. 5 revisions seem like more >> than enough :). >> > > >> > Anyways, I think the remaining issues can be resolved >> with additional >> > > >> > patches. Thanks again for the good work and your patience. >> > > >> > >> > > >> > Thanks, >> > > >> > Andrey. >> > > >> > >> > > >> >> >> > > >> >> 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 onl
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
Hi, Alexey: No I do not installed the developer versions of these rpms, but I have made it work...mm after struggling The same rpm has different configurations due to different providers. For examples, those from rpmfind and those redhat iteself provides. So I recommend Harmony to provide such required files if possbile. On 10/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: Have you also installed developer versions of these rpms? 2006/10/8, Leo Li <[EMAIL PROTECTED]>: > Hi, Mark: > First I downloaded and installed the rpms for openpkg, png, jpeg, tiff, > lcms because of the dependency relationship between them. > Secondly, the installed files are in /openpkg, so I then copy the .a > and .h files to /usr/lib and /usr/include. > If I can find the .a or .h file, I can add them to the /usr/lib and > /usr/include directories. But how can I find them if I do not use rpm? > Redhat itself does not provide the function to download required file from > a software center as unbuntu does. > I will try yum, thank you for your advice. > > -- 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] -- Leo Li China Software Development Lab, IBM
Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 -Stepan. On 10/3/06, 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 -- 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] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
On 10/6/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > Agreed on all three. Do we have a japi script? I have one but it's a little specific to the wrapper we use for the builds that report to the -commits list. But I can provide it if it will help. If this script requires some updates I am volunteer to implement it :) thanks, Vladimir -Mark. > > Seems, that directory 'tests' also should be created in this module to > > place non-unit tests when we will have one. > > > > > > > > thanks, Vladimir > > > > - > 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][auth]LoginContext should always invoke the LoginModules?
> Understood, some occurrences are outside our control. As you point out
> above, we shall be good citizens to the best of our ability.
Yes. LoginModule-s are out of our control.
But we can control how the LoginContext invokes them, and we can be
defensive this way.
I propose the following:
1. Leave the check that started this thread as-is:
if (already_logged) {do_nothing}
2. As this introduces a difference with RI, then document the difference
with the reason why:
the RI's behavior may introduce a resource leakage as result of
invocation LoginModule.login() on already logged modules.
3. [?] For whose who has *really strong* need in the RI's behaviour,
introduce a system property to turn it on.
Something like
-Dhy.jaas.auth.logincontext.use.unsafe.secondary.login = true/false,
false by default.
if (already_logged && !use_unsafe_secondary_login) {do_nothing}
// fall-through to process over the login()-s.
?
--
Thanks,
Alex
Tim Ellison wrote:
Alex Astapchuk wrote:
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.
Understood, some occurrences are outside our control. As you point out
above, we shall be good citizens to the best of our ability.
Regards,
Tim
[1]
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login
-
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] define pre-commit testing configs to gain the stability
Tim Ellison wrote: Rana Dasgupta wrote: We need to check both release and debug builds...the binaries and timing characteristics are too different. At this immediate stage of the project, I would suggest leaving out EM64T as part of mandatory testing( unless it is EM64T specific functionality, eg., codegen ). Too few contributors and committers have access to it. We are not yet at a stage where we can make this mandatory. If possible all submissions should be tested( by submitters ) on all the combinations identified . It is actually more urgent for submitters to do this. We should stop patches by email. Also, at this point, it is an honor system, we can't attach 6 before and after test logs to each JIRA submission. The committer could randomly check on one or more combination, ...the more the better obviously. In some cases, submissions will be platform specific ( eg., very new code like GC V5, platform specific bug fixes or a simple case of developer not having all the machines ). I would leave these to the committers' discretion. Mandating that patches are pre-tested on a wide variety of machines is not conducive to building a broad community of contributors since very few people have access to all the machines and configurations we are interested in. I'd much prefer that we work optimistically and have lots of people regularly building and testing the code to get the broadest possible coverage. We can backtrack if problems arise. Well, exactly, sorta. While I think that we can't mandate, I'd like to see if we can get a community 'meme' going where people w/ different configs try patches and just report into the JIRA that things worked... would give the committer that handles the patch a bit more confidence... geir Regards, Tim - 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][GC] first generational version of GCv5 is submitted
I would suggest to commit the change at the moment and make new patch for other improvement. (btw, I actually don't think the directory naming is confusing, since version number of GC is not necessary to be in the directory name. For example, Java1.5 doesn't have version name in java.exe. Well if we really want to have version number in directory name, we can do that later with a new patch. ) Thanks, xiaofeng On 10/8/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: Good work. This helps. Could we not change the naming for the collectors right now? Its likely to confuse folks. How about using gcv4_1 and gcv5. Also, at least for a while we need to be able to build and run gcv4. On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > I've submitted a patch to the JIRA to make DRLVM compile two GCs, one > under gc_cc/ directory (originally gc/ of gcv4.1), the other under > gc_gen/ for gcv5 subtree. The default collector is still gcv4.1 in > DRLVM. People can specify gcv5 with command line option > -Dvm.dlls=gc_gen.dll . > > In future we may put all GCs under subtrees of gc/ directory. > > Thanks, > xiaofeng > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Can you make it selectable for build? IOW > > > >sh build.sh -Dbuild.gc=5 > > > > or something... > > > > Weldon Washburn wrote: > > > Good progress. I will plug GCV5 in today or tomorrow and report what > runs. > > > Provided this code sits well w/ drlvm tree, I will go ahead an commit > to > > > vm/gcv5 > > > > > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> > > >> Xiao-Feng Li wrote: > > >> > The submitted revision is downloadable in JIRA-1428 at: > > >> > > http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip > > >> > > > >> > > >> Nice! w00t! > > >> > > >> > Attached in this email is the gc.xml file I am using that replaces > > >> > existing one for building gc. > > >> > > >> Please attach that to the JIRA as well. I can't wait to try this... > > >> > > >> 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] > > -- 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: Can't get binary to work
Are you still having problems Armand? Tim Armand Navabi wrote: > I have been unable to figure out why I can't get the drlvm to run > helloworld. The classlib with Intel's VM works fine. > > > > So now I thought I'd just see if I could download the binary and execute it > (JRE), but it is behaving the same way (I guess this is to be expected, but > I just wanted to make sure it wasn't something in the build process that was > causing the trouble). > > > > When I run java by itself it executes without problem, when I run "java > helloworld" it just hangs, and "java -showversion" will print version info > and then hang right after that: > > > > [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/bin $ ./java > -showversion > > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > > java version "1.5.0" > > pre-alpha : not complete or compatible > > svn = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build > > http://incubator.apache.org/harmony > > (hangs here) > > > > Here are the environment variables that I think are relevant: > > > > LD_LIBRARY_PATH > > /scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha > rmony-jre-r450941/bin/default/ > > PATH > > .:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi > n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b > in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1 > > JAVA_HOME > > /scratch/anavabi/Harmony/harmony-jre-r450941/bin > > > > I'm on Gentoo 2.6.17.8. > > Any ideas what may be going on? > > > > Thanks, > > Armand > > -- 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] passing extra options to vm fails on Widows XP
LOL Tim Ellison wrote: They are going to ask the Application to talk nicely to the Runtime in future. Geir Magnusson Jr. wrote: What did the application's support team say? I failed to run any application with -Xem:jet (and -Xem:opt as well) set in harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I even copied that file from Windows 2003 machine to XP machine but this did not help. "java Test" gives me the following: An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=004020DF ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress=0550 EDI= ESI=001531F0 EAX= EBX= ECX=004044F4 EDX=4C25 EIP=004020DF ESP=0013F970 EBP=0550 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe Module_base_address=0040 Offset_in_DLL=20df This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. - 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 keep getting a failure when running the tests - test_jthread_get_all-threads failling the assertion at test_ti_instrum.c:80 geir On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote: While running cunit on Linux it turned out one test case fails some time. The fix is in tests.final.2.patch. So the last versions to be committed: invocation_api.final.patch build.final.2.patch tests.final.2.patch Evgueni On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: I mahaged to resolve the problem on Linux will update build.final.patch with build.final.2.patch in a while On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > Hi, > > Oh! Ooh! I did that. I passed cunit, somke, kernel tests on > Windows and smoke, kernel tests on Linux. Unfortunately I failed to > link cunit tests on Linux so far. So I disabled cunit on Linux until > the problem is solved. I believe it is acceptable as short term > solution. I found several problems in cunit tests. I will come up with > my findings later (not today). > > Use latest patches from HARMONY-1582. They are marked as final. There > are three patches. One for build module, one for cunit tests and one > for VM itself. > > Thanks > Evgueni > > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Nooo! LOL > > > > I'm here waiting - This will unblock a whole bunch of things :) > > > > Thanks for the effort > > > > Evgueni Brevnov wrote: > > > Geir, > > > > > > That's terrible. We have power outageservers are down. I can't > > > send the patches now will do it tomorrow > > > > > > Evgueni > > > On 10/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> woo hoo! here we go... > > >> > > >> > > >> Andrey Chernyshev wrote: > > >> > Hi Evgueni, > > >> > > > >> > On 10/4/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 for updating the patch! I agree it it can be committed, at > > >> > least signatures look good. 5 revisions seem like more than enough :). > > >> > Anyways, I think the remaining issues can be resolved with additional > > >> > patches. Thanks again for the good work and your patience. > > >> > > > >> > Thanks, > > >> > Andrey. > > >> > > > >> >> > > >> >> 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 p
Re: [general] define pre-commit testing configs to gain the stability
Rana Dasgupta wrote: > We need to check both release and debug builds...the binaries and timing > characteristics are too different. At this immediate stage of the > project, I > would suggest leaving out EM64T as part of mandatory testing( unless it is > EM64T specific functionality, eg., codegen ). Too few contributors and > committers have access to it. We are not yet at a stage where we can make > this mandatory. > > If possible all submissions should be tested( by submitters ) on all the > combinations identified . It is actually more urgent for submitters to do > this. We should stop patches by email. Also, at this point, it is an honor > system, we can't attach 6 before and after test logs to each JIRA > submission. The committer could randomly check on one or more combination, > ...the more the better obviously. > > In some cases, submissions will be platform specific ( eg., very new code > like GC V5, platform specific bug fixes or a simple case of developer not > having all the machines ). I would leave these to the committers' > discretion. Mandating that patches are pre-tested on a wide variety of machines is not conducive to building a broad community of contributors since very few people have access to all the machines and configurations we are interested in. I'd much prefer that we work optimistically and have lots of people regularly building and testing the code to get the broadest possible coverage. We can backtrack if problems arise. 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: [drlvm] passing extra options to vm fails on Widows XP
They are going to ask the Application to talk nicely to the Runtime in future. Geir Magnusson Jr. wrote: > > What did the application's support team say? > > Elena Semukhina wrote: >> I failed to run any application with -Xem:jet (and -Xem:opt as well) >> set in >> harmonyvm.properties on my Windows XP while I succeeded on Windows >> 2003. I >> even copied that file from Windows 2003 machine to XP machine but this >> did >> not help. >> >> "java Test" gives me the following: >> >> An unhandled error (4) has occurred. >> HyGeneric_Signal_Number=0004 >> ExceptionCode=c005 >> ExceptionAddress=004020DF >> ContextFlags=0001003f >> Handler1=00401010 >> Handler2=11105CE0 >> InaccessibleAddress=0550 >> EDI= >> ESI=001531F0 >> EAX= >> EBX= >> ECX=004044F4 >> EDX=4C25 >> EIP=004020DF >> ESP=0013F970 >> EBP=0550 >> Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe >> Module_base_address=0040 >> Offset_in_DLL=20df >> >> This application has requested the Runtime to terminate it in an unusual >> way. >> Please contact the application's support team for more information. >> >> > > - > 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]
[classlib][test] Failure in swing test
I see a failure on IA32 Win XP tests at r454168 (after applying the TransferHandler patch). The walkback is: junit.framework.AssertionFailedError: expected:<0> but was:<7> at javax.swing.SpinnerDateModelTest.testSpinnerDateModel(SpinnerDateModelTest.java:59) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) at javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120) at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) at java.lang.Thread.run(Thread.java:872) I'll take a look later unless somebody picks it up. 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] build problem.... I'm forgetting something obvious...
Mark Hindess wrote: > Nathan, yeah that's probably it. It's caught me out a couple of times. > > Is that swing test fix ready? If not perhaps we should just exclude > it, and then I can dump the with.awt.swing property for good? I've reviewed and applied the TransferHandler fix, but I see another test failure, so just hold on for now. I'll start a new thread for the new failure. Regards, Tim > Regards, > Mark. > > On 7 October 2006 at 14:29, "Nathan Beyer" <[EMAIL PROTECTED]> wrote: >> Are you running build with "-Dwith.awt.swing=true"? I had some weird >> problems yesterday and it just seemed that I wasn't consistently using >> that property for all ant runs. >> >> -Nathan >> >> On 10/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >>> still on that new machine. >>> >>> classlib builds fine, but "ant test" results in it appearing to be very, >>> very confused when trying to compile, with the first module, >>> accessibility. >>> >>> It can't find things like "BasicSwingTestCase", although I can confirm >>> that it was build in test_support... >>> >>> I figure I forgot something obvious... >>> >>> 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] >> > > > > - > 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][GC] first generational version of GCv5 is submitted
nice. thanks Xiao-Feng Li wrote: > I've submitted a patch to the JIRA to make DRLVM compile two GCs, one > under gc_cc/ directory (originally gc/ of gcv4.1), the other under > gc_gen/ for gcv5 subtree. The default collector is still gcv4.1 in > DRLVM. People can specify gcv5 with command line option > -Dvm.dlls=gc_gen.dll . > > In future we may put all GCs under subtrees of gc/ directory. > > Thanks, > xiaofeng > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> Can you make it selectable for build? IOW >> >>sh build.sh -Dbuild.gc=5 >> >> or something... >> >> Weldon Washburn wrote: >> > Good progress. I will plug GCV5 in today or tomorrow and report >> what runs. >> > Provided this code sits well w/ drlvm tree, I will go ahead an >> commit to >> > vm/gcv5 >> > >> > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> Xiao-Feng Li wrote: >> >> > The submitted revision is downloadable in JIRA-1428 at: >> >> > >> http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip >> >> > >> >> >> >> Nice! w00t! >> >> >> >> > Attached in this email is the gc.xml file I am using that replaces >> >> > existing one for building gc. >> >> >> >> Please attach that to the JIRA as well. I can't wait to try this... >> >> >> >> 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] > > > - 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] build problem.... I'm forgetting something obvious...
nope, did that too. That was the first thing I thought of. Tried JUnit 4.x and Junit 3.8.1 Elena Semukhina wrote: > On 10/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> still on that new machine. >> >> classlib builds fine, but "ant test" results in it appearing to be very, >> very confused when trying to compile, with the first module, >> accessibility. >> >> It can't find things like "BasicSwingTestCase", although I can confirm >> that it was build in test_support... >> >> I figure I forgot something obvious... > > > Yes, you forgot to copy junit.jar to ant's lib directory. > > 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][GC] first generational version of GCv5 is submitted
I would prefer gcv41 name. I dislike underscores in names. -- Ivan On 10/8/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: Good work. This helps. Could we not change the naming for the collectors right now? Its likely to confuse folks. How about using gcv4_1 and gcv5. Also, at least for a while we need to be able to build and run gcv4. On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > I've submitted a patch to the JIRA to make DRLVM compile two GCs, one > under gc_cc/ directory (originally gc/ of gcv4.1), the other under > gc_gen/ for gcv5 subtree. The default collector is still gcv4.1 in > DRLVM. People can specify gcv5 with command line option > -Dvm.dlls=gc_gen.dll . > > In future we may put all GCs under subtrees of gc/ directory. > > Thanks, > xiaofeng > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Can you make it selectable for build? IOW > > > >sh build.sh -Dbuild.gc=5 > > > > or something... > > > > Weldon Washburn wrote: > > > Good progress. I will plug GCV5 in today or tomorrow and report what > runs. > > > Provided this code sits well w/ drlvm tree, I will go ahead an commit > to > > > vm/gcv5 > > > > > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> > > >> Xiao-Feng Li wrote: > > >> > The submitted revision is downloadable in JIRA-1428 at: > > >> > > http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip > > >> > > > >> > > >> Nice! w00t! > > >> > > >> > Attached in this email is the gc.xml file I am using that replaces > > >> > existing one for building gc. > > >> > > >> Please attach that to the JIRA as well. I can't wait to try this... > > >> > > >> 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] > > -- Weldon Washburn Intel Middleware Products Division -- 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: [DRLVM][GC] first generational version of GCv5 is submitted
Good work. This helps. Could we not change the naming for the collectors right now? Its likely to confuse folks. How about using gcv4_1 and gcv5. Also, at least for a while we need to be able to build and run gcv4. On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: I've submitted a patch to the JIRA to make DRLVM compile two GCs, one under gc_cc/ directory (originally gc/ of gcv4.1), the other under gc_gen/ for gcv5 subtree. The default collector is still gcv4.1 in DRLVM. People can specify gcv5 with command line option -Dvm.dlls=gc_gen.dll . In future we may put all GCs under subtrees of gc/ directory. Thanks, xiaofeng On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Can you make it selectable for build? IOW > >sh build.sh -Dbuild.gc=5 > > or something... > > Weldon Washburn wrote: > > Good progress. I will plug GCV5 in today or tomorrow and report what runs. > > Provided this code sits well w/ drlvm tree, I will go ahead an commit to > > vm/gcv5 > > > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> Xiao-Feng Li wrote: > >> > The submitted revision is downloadable in JIRA-1428 at: > >> > http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip > >> > > >> > >> Nice! w00t! > >> > >> > Attached in this email is the gc.xml file I am using that replaces > >> > existing one for building gc. > >> > >> Please attach that to the JIRA as well. I can't wait to try this... > >> > >> 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] -- Weldon Washburn Intel Middleware Products Division
Re: [general] Dynamic class loading
Yep, and as Nathan said, there are many examples of scripting languages based on Java that work on this principle. Is this something we want to adopt as a practice in Harmony for apps or development process? No, I think not. Regards, Tim Stefano Mazzocchi wrote: > Nathan Beyer wrote: >> I wasn't literally suggesting using JSPs, but rather the concept >> behind the technology -- dynamically loading a script with embedded >> Java, generating a complete Java source, compiling it and then loading >> the bytecodes. You can probably take the JSP engine from Tomcat and >> hack it into a more generalized launcher. > > Right. > > Take this: > > http://simile.mit.edu/repository/tools/loader/trunk/src/Loader.java > > and overload > > Class loadClass(String name, boolean resolve) > > merging it with something some code taken from > > http://tinyurl.com/r4rmf > > ship with the eclipse JDT compiler, stir up and you're done. > -- 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] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
While running cunit on Linux it turned out one test case fails some time. The fix is in tests.final.2.patch. So the last versions to be committed: invocation_api.final.patch build.final.2.patch tests.final.2.patch Evgueni On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: I mahaged to resolve the problem on Linux will update build.final.patch with build.final.2.patch in a while On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > Hi, > > Oh! Ooh! I did that. I passed cunit, somke, kernel tests on > Windows and smoke, kernel tests on Linux. Unfortunately I failed to > link cunit tests on Linux so far. So I disabled cunit on Linux until > the problem is solved. I believe it is acceptable as short term > solution. I found several problems in cunit tests. I will come up with > my findings later (not today). > > Use latest patches from HARMONY-1582. They are marked as final. There > are three patches. One for build module, one for cunit tests and one > for VM itself. > > Thanks > Evgueni > > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Nooo! LOL > > > > I'm here waiting - This will unblock a whole bunch of things :) > > > > Thanks for the effort > > > > Evgueni Brevnov wrote: > > > Geir, > > > > > > That's terrible. We have power outageservers are down. I can't > > > send the patches now will do it tomorrow > > > > > > Evgueni > > > On 10/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> woo hoo! here we go... > > >> > > >> > > >> Andrey Chernyshev wrote: > > >> > Hi Evgueni, > > >> > > > >> > On 10/4/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 for updating the patch! I agree it it can be committed, at > > >> > least signatures look good. 5 revisions seem like more than enough :). > > >> > Anyways, I think the remaining issues can be resolved with additional > > >> > patches. Thanks again for the good work and your patience. > > >> > > > >> > Thanks, > > >> > Andrey. > > >> > > > >> >> > > >> >> 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
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
Have you also installed developer versions of these rpms? 2006/10/8, Leo Li <[EMAIL PROTECTED]>: Hi, Mark: First I downloaded and installed the rpms for openpkg, png, jpeg, tiff, lcms because of the dependency relationship between them. Secondly, the installed files are in /openpkg, so I then copy the .a and .h files to /usr/lib and /usr/include. If I can find the .a or .h file, I can add them to the /usr/lib and /usr/include directories. But how can I find them if I do not use rpm? Redhat itself does not provide the function to download required file from a software center as unbuntu does. I will try yum, thank you for your advice. -- 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: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
I mahaged to resolve the problem on Linux will update build.final.patch with build.final.2.patch in a while On 10/8/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: Hi, Oh! Ooh! I did that. I passed cunit, somke, kernel tests on Windows and smoke, kernel tests on Linux. Unfortunately I failed to link cunit tests on Linux so far. So I disabled cunit on Linux until the problem is solved. I believe it is acceptable as short term solution. I found several problems in cunit tests. I will come up with my findings later (not today). Use latest patches from HARMONY-1582. They are marked as final. There are three patches. One for build module, one for cunit tests and one for VM itself. Thanks Evgueni On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Nooo! LOL > > I'm here waiting - This will unblock a whole bunch of things :) > > Thanks for the effort > > Evgueni Brevnov wrote: > > Geir, > > > > That's terrible. We have power outageservers are down. I can't > > send the patches now will do it tomorrow > > > > Evgueni > > On 10/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> woo hoo! here we go... > >> > >> > >> Andrey Chernyshev wrote: > >> > Hi Evgueni, > >> > > >> > On 10/4/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 for updating the patch! I agree it it can be committed, at > >> > least signatures look good. 5 revisions seem like more than enough :). > >> > Anyways, I think the remaining issues can be resolved with additional > >> > patches. Thanks again for the good work and your patience. > >> > > >> > Thanks, > >> > Andrey. > >> > > >> >> > >> >> 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(). > >>
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Hi, Oh! Ooh! I did that. I passed cunit, somke, kernel tests on Windows and smoke, kernel tests on Linux. Unfortunately I failed to link cunit tests on Linux so far. So I disabled cunit on Linux until the problem is solved. I believe it is acceptable as short term solution. I found several problems in cunit tests. I will come up with my findings later (not today). Use latest patches from HARMONY-1582. They are marked as final. There are three patches. One for build module, one for cunit tests and one for VM itself. Thanks Evgueni On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Nooo! LOL I'm here waiting - This will unblock a whole bunch of things :) Thanks for the effort Evgueni Brevnov wrote: > Geir, > > That's terrible. We have power outageservers are down. I can't > send the patches now will do it tomorrow > > Evgueni > On 10/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> woo hoo! here we go... >> >> >> Andrey Chernyshev wrote: >> > Hi Evgueni, >> > >> > On 10/4/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 for updating the patch! I agree it it can be committed, at >> > least signatures look good. 5 revisions seem like more than enough :). >> > Anyways, I think the remaining issues can be resolved with additional >> > patches. Thanks again for the good work and your patience. >> > >> > Thanks, >> > Andrey. >> > >> >> >> >> 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. >> >> > > > > >> >> > > > > Th
Re: [DRLVM][GC] first generational version of GCv5 is submitted
I've submitted a patch to the JIRA to make DRLVM compile two GCs, one under gc_cc/ directory (originally gc/ of gcv4.1), the other under gc_gen/ for gcv5 subtree. The default collector is still gcv4.1 in DRLVM. People can specify gcv5 with command line option -Dvm.dlls=gc_gen.dll . In future we may put all GCs under subtrees of gc/ directory. Thanks, xiaofeng On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Can you make it selectable for build? IOW sh build.sh -Dbuild.gc=5 or something... Weldon Washburn wrote: > Good progress. I will plug GCV5 in today or tomorrow and report what runs. > Provided this code sits well w/ drlvm tree, I will go ahead an commit to > vm/gcv5 > > On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> >> Xiao-Feng Li wrote: >> > The submitted revision is downloadable in JIRA-1428 at: >> > http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip >> > >> >> Nice! w00t! >> >> > Attached in this email is the gc.xml file I am using that replaces >> > existing one for building gc. >> >> Please attach that to the JIRA as well. I can't wait to try this... >> >> 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: [classlib] Recognizing lock objects
Endre Stølsvik wrote: > What about an marker interface, or common ancestor class? Just to mark it > as being of this type of usage? Would do a lot of good, I recon, to be > able to trace/track such usages..? (Re java.util.EventListener, "A tagging > interface.. ") How would that help? The goal was to make them all different so we can recognise them. 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] [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. Is it possible to send the first ~5k (so we get the report URL and change set part) and the last 10k which is more likely to show the compile error / test failure? Regards, Tim > 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
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
Hi, Mark: First I downloaded and installed the rpms for openpkg, png, jpeg, tiff, lcms because of the dependency relationship between them. Secondly, the installed files are in /openpkg, so I then copy the .a and .h files to /usr/lib and /usr/include. If I can find the .a or .h file, I can add them to the /usr/lib and /usr/include directories. But how can I find them if I do not use rpm? Redhat itself does not provide the function to download required file from a software center as unbuntu does. I will try yum, thank you for your advice.
[classlib][math]BigInteger should have an unexpected "protected clone()" method
Hi, all
I found that BigInteger have a protected clone() method while as the
spec says BigInteger itself does not implement Cloneable. The clone() method
just new an instance of itself instead of super().clone.Although it is not
public, the Clone() method might lead to side-effect if some Object extends
from it and implements Cloneable.
Here is an testcase:
public class TestCloneable extends TestCase {
public void testClone()
{
MyBigInteger myBigInteger = new MyBigInteger("12345");
myBigInteger = (MyBigInteger)myBigInteger.clone();
}
}
class MyBigInteger extends BigInteger implements Cloneable {
public MyBigInteger(String val) {
super(val);
}
public Object clone()
{
try {
return super.clone();
} catch (CloneNotSupportedException e) {
return null;
}
}
}
RI passes while Harmony fails.
Actually this method is called just in order to copy itself so as to remain
immutable in BigInteger's other methods, I recommend to rename the method
not so sensitivly as "Clone". If no one objects, I will raise a jira and
create a patch for it.
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
On 8 October 2006 at 16:39, "Leo Li" <[EMAIL PROTECTED]> wrote: > > Hi, all > Current harmony build script on linux requires liblcms.a libpng.a and > several .h files such as png.h but not installed on my redhat linux > platform. Although as the script prompts out, ubuntu can download such files > seperately, while other platform such as my redhat or suse, rpm might be the > only source to get new softwares from internet which leads to a lot of > troubles. For examples, the dependency between those rpms and the default > installation destinations of these rpms are not the places Harmony script > expects. > So, I think, it will be good if the build script can download these > required files automatically when they are absent. Can you not just use yum or whatever tools Red Hat provides? Can you document what you had to do? 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] build problem.... I'm forgetting something obvious...
On 10/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: still on that new machine. classlib builds fine, but "ant test" results in it appearing to be very, very confused when trying to compile, with the first module, accessibility. It can't find things like "BasicSwingTestCase", although I can confirm that it was build in test_support... I figure I forgot something obvious... Yes, you forgot to copy junit.jar to ant's lib directory. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena
[classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
Hi, all Current harmony build script on linux requires liblcms.a libpng.a and several .h files such as png.h but not installed on my redhat linux platform. Although as the script prompts out, ubuntu can download such files seperately, while other platform such as my redhat or suse, rpm might be the only source to get new softwares from internet which leads to a lot of troubles. For examples, the dependency between those rpms and the default installation destinations of these rpms are not the places Harmony script expects. So, I think, it will be good if the build script can download these required files automatically when they are absent. -- Leo Li China Software Development Lab, IBM
Re: [drlvm][jitrino.JET] Can we have JET write barrier implementation checked in?
That's great, thank you very much! -xiaofeng On 10/8/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: Xiao-Feng, Is it OK if I commit it tomorrow? So you have it on October09 morning ? On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > On 9/29/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > Egor, > > I think this is right suggestion to synchronize our WB and H1580 > > implementations. > > AFAIK H1580 uses old JET version and is not compatible with the latest > > compiler version. > > If it's true, our implementation for the new JET/OPT version will do the > job > > for the both subprojects. > > > > The only question I have now is a question to Geir and other commiters: > > Do I really need to create a new JIRA for WB support in Jitrino? Or is > it > > better to add my patches to H1580? > > I ask this because the last time a person added a patch to the JIRA > created > > by me was asked by Geir to use another JIRA to separate our > contributions (I > > mean Jitrino.OPT testing framework). > > > > Hi, GCv5 badly needs an implementation of write barrier in DRLVM, JET > or Jitrino. I would hope the JET write barrier implementation can be > merged AS EARLY AS POSSIBLE. Let's be flexible with the process as > long as we are doing the right thing. > > Thanks, > xiaofeng > > - > 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 - 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][jitrino.JET] Can we have JET write barrier implementation checked in?
Xiao-Feng, Is it OK if I commit it tomorrow? So you have it on October09 morning ? On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: On 9/29/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > Egor, > I think this is right suggestion to synchronize our WB and H1580 > implementations. > AFAIK H1580 uses old JET version and is not compatible with the latest > compiler version. > If it's true, our implementation for the new JET/OPT version will do the job > for the both subprojects. > > The only question I have now is a question to Geir and other commiters: > Do I really need to create a new JIRA for WB support in Jitrino? Or is it > better to add my patches to H1580? > I ask this because the last time a person added a patch to the JIRA created > by me was asked by Geir to use another JIRA to separate our contributions (I > mean Jitrino.OPT testing framework). > Hi, GCv5 badly needs an implementation of write barrier in DRLVM, JET or Jitrino. I would hope the JET write barrier implementation can be merged AS EARLY AS POSSIBLE. Let's be flexible with the process as long as we are doing the right thing. Thanks, xiaofeng - 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][jitrino.JET] "-Xem jet:" and "-Xjit jet::wb4j" don't work anymore
Ok I'll try to do it tomorrow. So you will have it on your monday's morning in JIRA On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: On 10/1/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > If h1580 is based on svn revision number that is before BBC.patch, I > recommend closing h1580 and opening a new JIRA. (I recently closed H-816 > for similar reasons.) Also, if Yu-Nan He's patch does not work with current > svn head, this patch needs updating. > > An option you may not have thought about. Open a new JIRA and ask Yu-Nan to > re-submit his patch to the new JIRA. Since Mikhail has already an implementation, I would suggest him to submit and merge it immediately. Thanks, -xiaofeng - 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
