That is correct, but only for the top-level build. But there are
currently several scripts the could kick things off:
1) the make/build.xml
2) the make/build-test.xml - probably this should not be called directly
3) the modules/*/make/build.xml
These were the scripts George modified. It''s not
George Harley wrote:
Mark Hindess wrote:
Why must we testing the hostname? Why not test the actual address,
127.0.0.1? That should be much more reliable and less platform
dependent.
Regards,
Mark.
Sounds good to me.
Paulex, in your view would it compromise the worth of this test if
in
On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>
> > 1) Copy the luni-kernel and security-kernel stubs and add
> > implementation rather than doing it in place. The stubs are just for
> > compilation we shouldn't add anything VM (
Oh, sorry about that. Thanks for pointing me in the right direction. I
didn't find anything logged in JIRA about this, do you mind if I log it?
-Nathan
-Original Message-
From: Stepan Mishura [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 11, 2006 10:12 PM
To: harmony-dev@incubator.apach
2006/4/12, Stepan Mishura <[EMAIL PROTECTED]>:
>
> On 4/11/06, Paulex Yang wrote:
> >
> > [SNIP]
> > >
> > > I've run tests on Linux. They fail on the same assertion:
> > > [junit] Testcase: testReceiveSend_Block_Normal(
> > > org.apache.harmony.tests.java.nio.channels.DatagramChannelTest):
> >
The best news! Let's cheer for it :)
2006/4/13, George Harley <[EMAIL PROTECTED]>:
>
> Builds OK and tests work on Debian Linux too (thanks Mark).
>
> Best regards,
> George
>
>
> George Harley wrote:
> > Hi,
> >
> > Changes applied in SVN revision 393521. Everything built OK and all
> > tests pas
2006/4/12, Geir Magnusson Jr <[EMAIL PROTECTED]>:
>
>
>
> Leo Simons wrote:
> > On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
> >> 2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
> >>> Hello, geir,
> >>> Let's consider the case you mentioned.
> >>> I totally agree that "testRequestPa
Hi:
Right, that's what I want.
Thank you for your clear and concise analysis! :)
2006/4/12, Leo Simons <[EMAIL PROTECTED]>:
>
> On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
> > 2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
> > > Hello, geir,
> > > Let's consider the case
Hi, all,
I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.
The archive with this contribution can be found at:
http://issues.apache.org/jira/browse/HARMONY-337
The Remote Method
George Harley wrote:
Builds OK and tests work on Debian Linux too (thanks Mark).
Best regards,
George
George Harley wrote:
Hi,
Changes applied in SVN revision 393521. Everything built OK and all
tests passed for me on Windows XP prior to commit. Please holler if
this change messes things u
idle curiosity... 1) why not make both 'source' and 'target' settable by
a property, and 2) educate me on ant - why couldn't this have been set
in a property in the script that kicked things off and have the value
propagate down?
[EMAIL PROTECTED] wrote:
Author: gharley
Date: Wed Apr 12 10:0
Mark,
Sorry I forgot to mention it in the last email. I did the svn diff
you suggested below. The results have been attached to Harmony-318.
On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> Weldon,
>
> Sorry, it was a mistake on my part, it should be:
>
> svn diff --diff-cmd diff -x -ubBw
On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> Weldon,
>
> Sorry, it was a mistake on my part, it should be:
>
> svn diff --diff-cmd diff -x -ubBw
>
> Anyway, I'm making some progress with the diff that you already
> provided. (Part of the problem was that in order to use the diff on
> Lin
Weldon,
Sorry, it was a mistake on my part, it should be:
svn diff --diff-cmd diff -x -ubBw
Anyway, I'm making some progress with the diff that you already
provided. (Part of the problem was that in order to use the diff on
Linux I had to remove the '\r' characters from the meta-data lines in
Mark,
Thanks for working on the diffs. I have tried to get svn to behave.
Version 1.3.0 dated Jan 15 does not recognize the "--diff-cmd" you
suggest below. It might be a cygwin issue.
Can you check-in just the kernel adapter stubs for now? This should
involve zero diffs since this is a gener
Builds OK and tests work on Debian Linux too (thanks Mark).
Best regards,
George
George Harley wrote:
Hi,
Changes applied in SVN revision 393521. Everything built OK and all
tests passed for me on Windows XP prior to commit. Please holler if
this change messes things up for you or if you sp
Hi,
Changes applied in SVN revision 393521. Everything built OK and all
tests passed for me on Windows XP prior to commit. Please holler if this
change messes things up for you or if you spot an error in my changes.
Like I have to ask ... :-)
Best regards,
George
-
Archie,
This helps a bunch! I was getting lost in the JCNI code.
Thanks
Weldon
On 4/12/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Weldon Washburn wrote:
> >> There's nothing unusual about JCHEVM's native code dispatch.
> >> However, JCHEVM constructs dynamic function calls itself
On 4/12/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
> George Harley wrote:
> > Geir Magnusson Jr wrote:
> >> so it is a top level parameter that can cascade down, right?
> >>
> >> geir
> >>
> >>
> >
> > Hi Geir,
> >
> > No, it isn't a top level parameter at the moment. A new JIRA will be
>
Weldon Washburn wrote:
There's nothing unusual about JCHEVM's native code dispatch.
However, JCHEVM constructs dynamic function calls itself (instead
of using libffi like SableVM does). So if C calling conventions under
Cygwin (which are what?) are different than Linux, you could see
misalignment
Hi Archie,
On 4/12/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Weldon Washburn wrote:
> > 4)
> > There was real difficulty lining up the native method's incoming
> > arguments. Finally I declared the native method with input arguments
> > (int a1, int a2, int a3, int a4). Then passed the chara
Geir Magnusson Jr wrote:
George Harley wrote:
Geir Magnusson Jr wrote:
so it is a top level parameter that can cascade down, right?
geir
Hi Geir,
No, it isn't a top level parameter at the moment. A new JIRA will be
opened to make it so after the initial switch-over takes place. Does
t
George Harley wrote:
Geir Magnusson Jr wrote:
so it is a top level parameter that can cascade down, right?
geir
Hi Geir,
No, it isn't a top level parameter at the moment. A new JIRA will be
opened to make it so after the initial switch-over takes place. Does
that sound reasonable ?
S
Geir Magnusson Jr wrote:
so it is a top level parameter that can cascade down, right?
geir
Hi Geir,
No, it isn't a top level parameter at the moment. A new JIRA will be
opened to make it so after the initial switch-over takes place. Does
that sound reasonable ?
Best regards,
George
G
Archie Cobbs wrote:
Weldon Washburn wrote:
I have zero problems if you put specific directories contained in JIRA
harmony-318 below harmony/enhanced/gnuclasspathadapter. The specific
directories are:
- kernel
- luni
- nio
OK, I can do it as soon as someone tells me it's OK to commit.
Leo Simons wrote:
On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
Hello, geir,
Let's consider the case you mentioned.
I totally agree that "testRequestPasswordAuthentication1" is a BAD name,
Why?
There's a whole "movement" devote
Leo Simons wrote:
On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
Hello, geir,
Let's consider the case you mentioned.
I totally agree that "testRequestPasswordAuthentication1" is a BAD name,
Why?
There's a whole "movement" devote
OK, as you like :)
BTW, should I open a JIRA issue or refer to this mail thread in the commit
comment?
Thanks,
Mikhail
2006/4/12, George Harley <[EMAIL PROTECTED]>:
> Hi Mikhail,
>
> Currently the tests for java.io.File are not enabled. I have fixed that
> locally and can see that there is a te
On 4/12/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>
> > Rules are good if you use them without fanaticism :)
> >
> > So I think that it is good to include tested method signature in test
> > name. But it is OK to make them shorter in complicated cases.
> >
> > I do not see any problem with not
Mikhail Loenko wrote:
BTW AFAIK we do not test whether manifests list all imports/exports
So if we create data from manifests then it could be insufficient and
we might have the same failures we had yesterday.
Yes... but we already have the manifests. They have to be right for OSGi.
So giv
Hi Mikhail,
Currently the tests for java.io.File are not enabled. I have fixed that
locally and can see that there is a test already for this situation but
the test itself is wrong since it expects the IOException to be thrown.
I was just about to re-enable the File tests.
I guess I am sayin
so it is a top level parameter that can cascade down, right?
geir
George Harley wrote:
Yes, in my local workspace I updated the following while establishing
proof-of-concept :
* "top level" compile target in make/build-java.xml
* compilation of test support classes in make/build-test.xml
* t
OK, I'll fix and submit a test.
2006/4/12, Mark Hindess <[EMAIL PROTECTED]>:
> Yes. That looks correct and matchs the RI behaviour for the case when
> the file exists and is a directory.
>
> -Mark.
>
>
> On 4/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > I'd replace
> > case 1:
> >
Yes. That looks correct and matchs the RI behaviour for the case when
the file exists and is a directory.
-Mark.
On 4/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> I'd replace
> case 1:
> return false;
> case 3:
> throw new
> IOException(org.apache.harmony.luni.util.Msg.ge
Weldon Washburn wrote:
1)
libtool was not behaving. So, I gave up and used raw ld.
2)
dlopen() refused to load the output of ld. Google turned up help pages
that showed dlopen() only likes files ending in *.a
3)
Once dlopen() was able to open the shared lib containing the native
method, gdb was
I'd replace
case 1:
return false;
case 3:
throw new
IOException(org.apache.harmony.luni.util.Msg.getString("K01c1"));
//$NON-NLS-1$
with
case 1:
case 3:
return false;
2006/4/12, George Harley <[EMAIL PROTECTED]>:
>
> Thanks :-)
>
> Mikhail Loenko wrote:
> > WinXP
> >
>
Thanks :-)
Mikhail Loenko wrote:
WinXP
2006/4/12, George Harley <[EMAIL PROTECTED]>:
Hi Mikhail,
What platform(s) are you seeing this on ?
Best regards,
George
Mikhail Loenko wrote:
I'm seeing test errors in the archive module. I've heard that Stepan have seen
similar ones today
WinXP
2006/4/12, George Harley <[EMAIL PROTECTED]>:
> Hi Mikhail,
>
> What platform(s) are you seeing this on ?
>
> Best regards,
> George
>
>
> Mikhail Loenko wrote:
> > I'm seeing test errors in the archive module. I've heard that Stepan have
> > seen
> > similar ones today in the morning.
> >
On 4/12/06, Leo Simons <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
> > 2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
> > > Hello, geir,
> > > Let's consider the case you mentioned.
> > > I totally agree that "testRequestPasswordAuthentication1" is a B
More of stack trace:
java.io.IOException: File is a Directory
at java.io.File.createNewFile(File.java:1035)
at java.io.File.createTempFile(File.java:1089)
at
tests.support.resource.Support_Resources.createTempFolder(Support_Resources.java:66)
at
tests.support.reso
Hi Mikhail,
What platform(s) are you seeing this on ?
Best regards,
George
Mikhail Loenko wrote:
I'm seeing test errors in the archive module. I've heard that Stepan have seen
similar ones today in the morning.
The errors are unstable: Stepan could not reproduce it and I did not see them
pre
On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
> 2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
> > Hello, geir,
> > Let's consider the case you mentioned.
> > I totally agree that "testRequestPasswordAuthentication1" is a BAD name,
>
> Why?
There's a whole "movement" devoted to an
As for me I'm looking forward seeing it in SVN :)
Then we'll see more green lines in Japi reports
Thanks,
Mikhail
2006/4/12, George Harley <[EMAIL PROTECTED]>:
> Yes, in my local workspace I updated the following while establishing
> proof-of-concept :
>
> * "top level" compile target in make/bui
I'm seeing test errors in the archive module. I've heard that Stepan have seen
similar ones today in the morning.
The errors are unstable: Stepan could not reproduce it and I did not see them
previous time. So here they are:
Class tests.api.java.util.jar.ManifestTest
all tests error with:
N/A
Well I did not suggest maintaining separate set of manifests :)
Can we somehow test validity of [existing] manifests?
Thanks,
Mikhail
2006/4/12, Mark Hindess <[EMAIL PROTECTED]>:
> Mikhail,
>
> While that is true, maintaining separate dependency information is
> just as (un)likely to be correct.
Mikhail,
While that is true, maintaining separate dependency information is
just as (un)likely to be correct. I think we should use the manifests
and fix them if they are inaccurate.
Regards,
Mark.
On 4/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> BTW AFAIK we do not test whether manife
Well, you will need to build-up dependency info anyway, right?
Therefore probably that would be a good chance to revise and update
manifests :-)?
--
Anton Avtamonov,
Intel Middleware Products Division
On 4/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> BTW AFAIK we do not test whether manifes
2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
> Hello, geir,
> Let's consider the case you mentioned.
> I totally agree that "testRequestPasswordAuthentication1" is a BAD name,
Why?
Thanks,
Mikhail
> but I don't think
> "test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_in
BTW AFAIK we do not test whether manifests list all imports/exports
So if we create data from manifests then it could be insufficient and
we might have the same failures we had yesterday.
Thanks,
Mikhail
2006/4/12, Anton Avtamonov <[EMAIL PROTECTED]>:
> On 4/12/06, Geir Magnusson Jr <[EMAIL PROT
Yes, in my local workspace I updated the following while establishing
proof-of-concept :
* "top level" compile target in make/build-java.xml
* compilation of test support classes in make/build-test.xml
* the "source.ver" property in the /build.xml
* the "build.compiler" property in the /build.xm
On 4/12/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> Why have a static file? Why not just generate from the modules
> manifests? Then the error can only be in one place - the dependent
> module... right?
If they have enough info - of course! That would be excellent.
I suppose it is a bit n
Hello, geir,
Let's consider the case you mentioned.
I totally agree that "testRequestPasswordAuthentication1" is a BAD name,
but I don't think
"test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authe
Rules are good if you use them without fanaticism :)
So I think that it is good to include tested method signature in test
name. But it is OK to make them shorter in complicated cases.
I do not see any problem with not adding full package name to the
class name when it is obvious what class are y
It isn't a top-level parameter. So each javac will need to be
annotated with source and target attributes. Of course, the values
could be taken from a top-level property - perhaps imported from
make/properties.xml.
Also, the build.compiler properties will need to be commented out in
each module/*
Why have a static file? Why not just generate from the modules
manifests? Then the error can only be in one place - the dependent
module... right?
geir
George Harley wrote:
Hi Anton,
It is a good idea if it helps developers build up a map of how the class
library modules relate to one ano
Paulex Yang wrote:
Geir Magnusson Jr wrote:
Paulex Yang wrote:
Geir Magnusson Jr wrote:
testRequestPasswordAuthentication1()
I mean, why do we want to embed all that crap in the testcase name?
Who cares? The only person that will care is someone fixing when a
testcase breaks, and they
Hi Weldon,
Weldon Washburn wrote:
> Question for SableVM/JCHEVM guys: Did I miss the documentation on
> lining up native method args? Can you point me to the correct place
> to figure out how to do this?
There is nothing specific, as far as I remember. SableVM's native
calling code takes care
WOO!
Weldon Washburn wrote:
I just uploaded a new zip file to JIRA Harmony-318 that contains the
mods to Harmony Classlib that will allow it to run on an unmodified
generic GNU Classpath JVM.
Some of the issues encountered:
1)
libtool was not behaving. So, I gave up and used raw ld.
2)
dlopen
Anton Avtamonov wrote:
On 4/12/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
Hi George,
Your example looks good for me and I think everybody agreed that we should
organize testing to avoid running all tests for each update: if you fix bug
in 'net' module you don't have to run tests say for '
Stepan Mishura wrote:
I run tests on SUSE LINUX ES 9, file /etc/hosts contains the next entry:
127.0.0.1 localhost
I wonder if we should start logging the different platforms people are
testing/working on so we get a sense of coverage
geir
-
George Harley wrote:
Hi Paulex,
Thanks for the update. Just so you know, I have been able to take the
original patch containing the 5.0 features which mandated a 5.0 compiler
and compile things successfully using the "jsr14" target that has been
previously discussed on the list. Making furt
Mark Hindess wrote:
Why must we testing the hostname? Why not test the actual address,
127.0.0.1? That should be much more reliable and less platform
dependent.
Regards,
Mark.
Sounds good to me.
Paulex, in your view would it compromise the worth of this test if
instead of doing :
-->
Top 12 winners out of 758 tests (1.6%) according to junit report
take 458 sec out of 572 (80%)
The winners are:
IdentityScopeTest 112.031
IdentityTest85.233
Inet6AddressTest57.944
NTLoginModuleTest 55.199
OutOfMemoryErrorTest30.724
SignatureTest 26.85
Why must we testing the hostname? Why not test the actual address,
127.0.0.1? That should be much more reliable and less platform
dependent.
Regards,
Mark.
On 4/12/06, LvJimmy，Jing <[EMAIL PROTECTED]> wrote:
> Hi:
>
> 2006/4/12, Stepan Mishura <[EMAIL PROTECTED]>:
> >
> > On 4/11/06, Paulex Y
Hi Anton,
It is a good idea if it helps developers build up a map of how the class
library modules relate to one another. I am not currently sure how such
a top level description file can be incorporated into the kind of scheme
I was thinking about. I will certainly look for opportunities to f
On 4/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
<
> I've fixed tests that change security manager and set of providers,
> now the fork mode for the security tests is "once", run time reduced
> by ~7 minutes.
Yippee! Thanks Mikhail. This makes testing much easier.
Regards,
Mark.
--
Mark
I've fixed tests that change security manager and set of providers,
now the fork mode for the security tests is "once", run time reduced
by ~7 minutes.
So now there are other champions, should we go through them and
reduce/exclude/move to another suite?
Thanks,
Mikhail
2006/4/11, Mark Hindess <[
Weldon, any chance you could make a diff_harmony.txt without all the
whitespace changes and attach it to the JIRA? I'm trying to update it
to work with current svn and I want to avoid going through lots of
rejects that are only whitespace changes. I think you should be able
to do this with a comm
I think the dependencies for a module belong under the module
directory not at the top level but I agree it might be nice to find a
way to pull them out of the build.xml files.
Regards,
Mark.
On 4/12/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote:
> On 4/12/06, George Harley <[EMAIL PROTECTED]> w
On 4/12/06, George Harley <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thanks for your comments.
>
> Working on the "walk first then try to run" principle, I will try to
> start adding in "run.dependants.tests" targets to individual modules'
> build.xml scripts over the next few days. Text seems like a goo
Geir Magnusson Jr wrote:
Paulex Yang wrote:
Geir Magnusson Jr wrote:
testRequestPasswordAuthentication1()
I mean, why do we want to embed all that crap in the testcase name?
Who cares? The only person that will care is someone fixing when a
testcase breaks, and they'll read the code...
Hi,
Thanks for your comments.
Working on the "walk first then try to run" principle, I will try to
start adding in "run.dependants.tests" targets to individual modules'
build.xml scripts over the next few days. Text seems like a good
candidate to start.
Best regards,
George
Anton Avtamono
Weldon,
It's good to have this discussion on the list, but would you mind
including at least some of the details about what the attached file is
in the JIRA comment when you attach a file? At the moment when you
look at the JIRA it's hard to tell what the attachments are for?
Regards,
Mark.
On
Actually I cannot right now estimate performance impact,
so we might want to find another solution
Thanks,
Mikhail
2006/4/12, Soeren Strassfeld <[EMAIL PROTECTED]>:
>
> > We can load those libraries by a dedicated class loader so that they
> > will be invisible for apps but visible for our 'bridg
George,
George Harley wrote:
Hi Paulex,
Thanks for the update. Just so you know, I have been able to take the
original patch containing the 5.0 features which mandated a 5.0
compiler and compile things successfully using the "jsr14" target that
has been previously discussed on the list. Maki
LvJimmy，Jing wrote:
Hi:
2006/4/12, Stepan Mishura <[EMAIL PROTECTED]>:
On 4/11/06, Paulex Yang wrote:
[SNIP]
I've run tests on Linux. They fail on the same assertion:
[junit] Testcase: testReceiveSend_Block_Normal(
org.apache.harmony.tests.java.nio.channels.DatagramChannelT
76 matches
Mail list logo
