Re: [drlvm] Doing the minimum to support Java 5 classfiles

[Alexey Varlamov]

Good news: with patches for HARMONY-677, I was able to run 1.5 classes
on DRLVM + classlib built with target=1.5.

But, I had some fun with the default javac (tried Sun jdk1.5.0_06 and
jrockit-jdk1.5.0-windows-ia32), which outwits itself in optimizing
String concatenations.
At first I got puzzled with this error message:
---
java/lang/IllegalAccessError : from java/security/Security$1 to
java/lang/AbstractStringBuilder
at java.security.AccessController.doPrivilegedImpl (: -1)
at java.security.AccessController.doPrivileged (: -1)
at java.security.Security. (Security.java: 57)
at org.apache.harmony.security.fortress.PolicyUtils$SecurityPropertyAccessor.run
(PolicyUtils.java: 148)
at org.apache.harmony.security.fortress.PolicyUtils$SecurityPropertyAccessor.run
(PolicyUtils.java: 127)
at java.security.AccessController.doPrivilegedImpl (: -1)
at java.security.AccessController.doPrivileged (: -1)
at java.security.Policy.getDefaultProvider (Policy.java: 139)
at java.security.Policy.getAccessiblePolicy (Policy.java: 190)
at java.security.Policy.getPolicy (Policy.java: 131)
at java.lang.ClassLoader. (: -1)
at java.lang.Thread. (: -1)
at java.lang.Thread. (: -1)


Indeed, looking at the bytecode of j.s.Security$1:
-
  10:   invokespecial   #4; //Method java/lang/StringBuilder."":()V
  13:   ldc #5; //String java.home
  15:   invokestatic#6; //Method
java/lang/System.getProperty:(Ljava/lang/String;)Ljava/lang/String;
  18:   invokevirtual   #7; //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
< cut off several append() >
  49:   ldc #11; //String java.security
  51:   invokevirtual   #7; //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
  54:   invokevirtual   #12; //Method
java/lang/AbstractStringBuilder.toString:()Ljava/lang/String;
--
How do you like the last instruction operand? %)
After some analysis, I figured that the reason was j.l.StringBuilder
extending j.l.AbstractStringBuilder without explicitly overriding
toString(). Interestingly, I tried to reproduce this bug manually, but
in vain...

Eclipse's ecj was smarter (or just less eager :)) and produced correct bytecode.
Neverthless, I guess we have to workaround this in j.l.StringBuilder.

Index: modules/luni/src/main/java/java/lang/StringBuilder.java

--- modules/luni/src/main/java/java/lang/StringBuilder.java (revision 417667
)
+++ modules/luni/src/main/java/java/lang/StringBuilder.java (working copy)
@@ -733,4 +733,8 @@
out.writeInt(length());
out.writeObject(getValue());
}
+
+public String toString() {
+return super.toString();
+}
}

-
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] Can't build native on winXP

[Matt Benson]

Thanks, Gregory... my embarrassed apologies for having
managed to skim those messages without retaining
anything useful!

-Matt

--- Gregory Shimansky <[EMAIL PROTECTED]> wrote:

> On Wednesday 28 June 2006 02:08 Matt Benson wrote:
> > nmake seems to choke looking for a ntwin32.mak
> file.
> > I don't care too much about the native stuff
> actually,
> > but I wanted to play with the build system, so I
> want
> > to make sure I don't break anything.  Does anyone
> have
> > any advice?
> 
> The file ntwin32.mak and win32.mak can be found in
> Microsoft Platform SDK. 
> When you install it, it will have SetEnv.Cmd script
> which sets up INCLUDE, 
> LIB and PATH variables to have necessary paths which
> nmake also uses 
> (INCLUDE) to find the necessary files such as
> ntwin32.mak.
> 
> You can also take a look at this [1] discussion, a
> very similar question was 
> asked just recently.
> 
> Unfortunately the mail-archives.apache.org have a
> very inconvenient interface 
> to read a thread of replies (is there a good way to
> do it with a web 
> interface?).
> 
> [1] 
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL
 PROTECTED]
> 
> -- 
> Gregory Shimansky, 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]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Can't build native on winXP

[Gregory Shimansky]

On Wednesday 28 June 2006 02:08 Matt Benson wrote:
> nmake seems to choke looking for a ntwin32.mak file.
> I don't care too much about the native stuff actually,
> but I wanted to play with the build system, so I want
> to make sure I don't break anything.  Does anyone have
> any advice?

The file ntwin32.mak and win32.mak can be found in Microsoft Platform SDK. 
When you install it, it will have SetEnv.Cmd script which sets up INCLUDE, 
LIB and PATH variables to have necessary paths which nmake also uses 
(INCLUDE) to find the necessary files such as ntwin32.mak.

You can also take a look at this [1] discussion, a very similar question was 
asked just recently.

Unfortunately the mail-archives.apache.org have a very inconvenient interface 
to read a thread of replies (is there a good way to do it with a web 
interface?).

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL
 PROTECTED]

-- 
Gregory Shimansky, 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]

[classlib] Timeline question

[kranga]

Hi Harmony developers,
   I checked the jdk1.4 and 1.5 comparison charts and 1.4 coverage looks 
impressive and 1.5 looks like 75%. Can anyone give me their best estimate of 
when you think you'll have a 95% + coverage of jdk 1.5?


Thanks
KR 



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib] Can't build native on winXP

[Matt Benson]

nmake seems to choke looking for a ntwin32.mak file. 
I don't care too much about the native stuff actually,
but I wanted to play with the build system, so I want
to make sure I don't break anything.  Does anyone have
any advice?

TIA,
Matt

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416477 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni: ./ src/main/java/java/net/ src/test/java/tests/api/java/net/

[Gregory Shimansky]

On Saturday 24 June 2006 21:14 Mark Hindess wrote:
> On 24 June 2006 at 20:10, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > On Saturday 24 June 2006 19:16 Geir Magnusson Jr wrote:
> > > I seem to have found a doozy :)
> > >
> > > In hysock.c / getNextNetlinkMsg() there's an assumption that anything
> > > the kernel will ever send in a netlink request is less than 1k, so when
> > > processing the receive buffer, if there still is data in the buffer and
> > > it's not a complete message, it's considered an error.
> > >
> > > This is clearly wrong, and provable by simply doubling the buffer size.
> > > This is suboptimal, of course, because there is no guarantee that 2k
> > > will be enough one all systems either.
> > >
> > > I'm going to stare at this and attempt to rewrite it this weekend if I
> > > find some time.
> > >
> > > Man, this would be easier w/ a debugger :)
> >
> > I have a question on this topic. Is there a reason why libhy*.so and
> > other classlib natives libraries are compiled without debug information?
> > Addind -g (-Zi on windows) to the options could really help sometimes.
>
> No.  At least there isn't a good reason.  We should fix this.  I've
> added it manually a couple of times which is always a sign that
> something is needs fixing.

To make it happen sooner rather than later I decided to create a JIRA 
HARMONY-681 with the changes which I've made locally some time ago already. 
It enables debug symbols info for classlib (not touching -O1 optimization 
flag so debuging may still be inaccurate at times) and full debug mode for 
drlvm by default (Geir asked about how to do it some time ago).

If I've missed something in the middle of classlib native code revamp please 
update the patch or let me know.

-- 
Gregory Shimansky, 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: [depends] mark and I were chatting

[Tim Ellison]

Gregory Shimansky wrote:

> Why does classlib require 
> its own zlib to be built from sources? Shouldn't it be another external 
> dependency provided in binary form or by the system?

Yes! absolutely, it should use the system version.

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: Using Visual Studio C++ Express to compile classlib - fails.

[Rana Dasgupta]

On 6/27/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


2006/6/27, Rana Dasgupta <[EMAIL PROTECTED]>:
>
> >
>>   I also read your interesting experiments on the other linked
>>thread. Microsoft appears to have a new tool mt.exe to embed these
>>manifests:
>> mt.exe -manifest someapp.exe.manifest -outputresource:someapp.exe;1
>> ( 1 for .exe and 2 for .dll )
>>
>> Could be added as a post-build step.

>Sure. I thought I'd have to  experiment with rc or windres utilities so I
>gave up at that stage. I didn't know they've invented a special utility
>right for the purpose of embedding manifests into executables and dlls.



That ( using a resource file )actually would be a better way, if possible.
The above directly edits the output file and potentially causes a full
recompile? It may be possible to convert the manifest  into a resource file
like:

$(MANIFEST_BASENAME).auto.res :$(MANIFEST_BASENAME).auto.rc

$(MANIFEST_BASENAME).auto.rc : $(MANIFEST_BASENAME).auto.manifest
   type <<$@
#include 
1RT_MANIFEST"$(MANIFEST_BASENAME).auto.manifest"
<< KEEP


, use rc to compile the resource, and then relink the resource
incrementally into the executable using the /incremental LDFLAGS etc.

Rana

Re: Using Visual Studio C++ Express to compile classlib - fails.

[Thorbjørn Ravn Andersen]

Gregory Shimansky skrev  den 27-06-2006 14:23:


Cool! Thanks for the pointer. This is something new. The date 
published is
June 7 2006 which is pretty recent. It happened after I've written my 
email

about MASM not available.
Thank you all for your help. I have now managed to build classlib with 
Visual Studio C++ Express (and MASM addon) plus the SDK headers, after 
removing the -WX option and that only. 

I ran the SDK setenv.bat command before running the "\Program 
Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat".


Noticed that "ant -q" only takes 2:17 and "ant" takes 3:45 on my 
machine.   Console output really is slow under XP.


Next step - dlrvm :)

--
 Thorbjørn

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jchevm] _jc_parse_classfile called twice in common case

[Archie Cobbs]

Archie Cobbs wrote:

Mark Hindess wrote:

I notice that there is a common code path that goes:

  _jc_derive_type_from_classfile which calls:
_jc_parse_classfile
_jc_derive_type_interp which calls:
  _jc_parse_classfile (with, I think, the same arguments as before)

Is this correct?  Perhaps we could avoid making the second call?


That's correct.. but we don't duplicate much work. The first call to
_jc_parse_classfile() has howmuch=1, which means "just parse the
names of the class, superclass, and superinterfaces, and then return".


Actually, we do parse the constant pool twice, which is silly.
But this is easy to fix... done in r417540.

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [depends] mark and I were chatting

[Gregory Shimansky]

Hello Geir

I am not sure if it is appropriate to write in this thread, but it is about 
external resources as well. I've recently stumbled upon a strange problem 
with libhyzlib.so. For its build this library uses zlib sources downloaded 
and unpacked directly in classlib.

The problem which I have is on SuSE 9 (gcc-3.3.3). 3 drlvm tests and specjvm98 
segfault inside of inflate code from libhyzlib.so. The bug is not easy to 
reproduce, when I changed -O1 option to -O0 the problem went away.

I've tried to investigate the problem and the general consensus in intel team 
was that it is likely to be because of symbols collison between libhyzlib.so 
and the system /lib/libz.so which drlvm is linked with. This has been proved 
by linking libhyzlib.so with -Wl,-Bsymbolic option. This option makes linker 
to attempt to resolve all internal symbol references inside of library upon 
linking as opposed to the normal way of resolving all symbols at runtime. The 
library linked with -Bsymbolic does not cause any crashes.



Symbol collisions like this may really be a problem on linux and we've 
encountered the problem several times already with drlvm. On linux it has a 
quite imperfect linking procedure between its components like vmcore and gc. 
The problem is that all libraries export all of the symbols (linked 
with -Wl,-export-dynamic).

Symbols are the same, in vmcore there is a variable, in gc library it is a 
function. When a library is first loaded into the process (e.g. vmcore), its 
symbols are considered resolved, then when gc library is loaded, only those 
symbols which names are new in the process space are resolved. Then when 
vmcore calls gc, which calls some of its functions which are named with the 
same name as a symbol in vmcore, the call goes to a variable in vmcore (it 
was first) and this causes a crash. This is avoided by using -Wl,-Bsymbolic 
which resolves all internal cross references at link it, so all internal 
calls inside of gc are resolved already before library is loaded. On windows 
this seems to be the default way.

The problem mentioned above in VM should be fixed at some point, 
using -Bsymbolic is really a crutch. Only necessary symbols should be 
exported using linking scripts or recently added gcc capabilities [1] to 
control symbols visibility at source level.



The symbols collision is possible between libhyzlib.so and system installed 
libz because libz is loaded first into the process space when vm is 
initialized.

I didn't find the exact prove that this is really symbols collosion (maybe it 
is a gcc-3.3.3 bug after all, at home classlib compiled with gcc-3.4.6 and 
gcc-4.1.0 doesn't give any segfaults) but still. Why does classlib require 
its own zlib to be built from sources? Shouldn't it be another external 
dependency provided in binary form or by the system?

[1] http://gcc.gnu.org/wiki/Visibility

On Tuesday 27 June 2006 15:00 Geir Magnusson Jr wrote:
> Just a note to get some more discussion going.
>
> Mark and I were talking about how to start refactoring out dependencies
> to a 'peer' to drlvm and classlib.  And Tim and I have discussed this
> too... I just want to capture and get the conversation out here...
>
> So, the idea is that it would be nice to have a common place for
> dependencies that parts of Harmony can point to w/ an assist in filling
> in.  (I.e - make it easy to get stuff.)
>
> Second, we also want to give each subcomponent (drlvm, jchevm, classlib)
> full freedom for dependencies via a simple property setting, so that
> people have full freedom to do what they want...
>
> So as a starting point... (names are open to change) ... something like :
>
> /deps
>   deps.properties
>   build.xml
> /build
> /external
>/ecj
> /3.2
> /3.3
>/apr
> /2.1
> /2.2
>
> etc
>
>
> where
>
> deps.properties is something like
>
> ECJJAR = ... path to 'default' verison
> APRINCLUDE = ... etc...
>
> So that people can reconfigure locally, and even override in a
> build.properties or something
>
> Big issue here is that each artifact will have different things, like
> libs and includes, jars, etc..
>
> the build.xml will be the top-level ant script that can fetch, update
> and build the deps...

-- 
Gregory Shimansky, 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: [jchevm] _jc_parse_classfile called twice in common case

[Archie Cobbs]

Mark Hindess wrote:

I notice that there is a common code path that goes:

  _jc_derive_type_from_classfile which calls:
_jc_parse_classfile
_jc_derive_type_interp which calls:
  _jc_parse_classfile (with, I think, the same arguments as before)

Is this correct?  Perhaps we could avoid making the second call?


That's correct.. but we don't duplicate much work. The first call to
_jc_parse_classfile() has howmuch=1, which means "just parse the
names of the class, superclass, and superinterfaces, and then return".

The overall class loading calling sequence is slightly less efficient than
it could be, however, a holdover from the support in JCVM for loading
classfiles from both ELF objects and/or the classpath.

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

-
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] excluding the failed tests

[Geir Magnusson Jr]

George Harley wrote:
> Hi Geir,
> 
> As you may recall, a while back I floated the idea and supplied some
> seed code to define all known test failing test methods in an XML file
> (an "exclusions list") that could be used by JUnit at test run time to
> skip over them while allowing the rest of the test methods in a class to
> run [1]. Obviously I thought about that when catching up with this
> thread but, more importantly, your comment about being reluctant to have
> more dependencies on JUnit also motivated me to go off and read some
> more about TestNG [2].
> 
> It was news to me that TestNG provides out-of-the-box support for
> excluding specific test methods as well as groups of methods (where the
> groups are declared in source file annotations or Javadoc comments).
> Even better, it can do this on existing JUnit test code provided that
> the necessary meta-data (annotations if compiling to a 1.5 target;
> Javadoc comments if targeting 1.4 like we currently are). There is a
> utility available in the TestNG download and also in the Eclipse support
> plug-in that helps migrate directories of existing JUnit tests to TestNG
> by adding in the basic meta-data (although for me the Eclipse version
> also tried to break the test class inheritance from
> junit.framework.TestCase which was definitely not what was required).
> 
> Perhaps ... just perhaps ... we should be looking at something like
> TestNG (or my wonderful "exclusions list" :-) ) to provide the
> granularity of test configuration that we need.
> 
> Just a thought.

How 'bout that ;)

geir

> 
> Best regards,
> George
> 
> [1] http://issues.apache.org/jira/browse/HARMONY-263
> [2] http://testng.org
> 
> 
> 
> Geir Magnusson Jr wrote:
>> Alexei Zakharov wrote:
>>  
>>> Hi,
>>> +1 for (3), but I think it will be better to define suite() method and
>>> enumerate passing tests there rather than to comment out the code.
>>> 
>>
>> I'm reluctant to see more dependencies on JUnit when we could control at
>> a level higher in the build system.
>>
>> Hard to explain, I guess, but if our exclusions are buried in .java, I
>> would think that reporting and tracking over time is going to be much
>> harder.
>>
>> geir
>>
>>  
>>> 2006/6/27, Richard Liang <[EMAIL PROTECTED]>:
>>>
 Hello Vladimir,

 +1 to option 3) . We shall comment the failed test cases out and add
 FIXME to remind us to diagnose the problems later. ;-)

 Vladimir Ivanov wrote:
  
> I see your point.
> But I feel that we can miss regression in non-tested code if we
> exclude
> TestCases.
> Now, for example we miss testing of
> 
 java.lang.Class/Process/Thread/String
  
> and some other classes.
>
> While we have failing tests and don't want to pay attention to these
> failures we can:
> 1) Leave things as is – do not run TestCases with failing tests.
> 2) Split passing/failing TestCase into separate "failing TestCase" and
> "passing TestCase" and exclude "failing TestCases". When test or
> implementation is fixed we move tests from failing TestCase to passing
> TestCase.
> 3) Comment failing tests in TestCases. It is better to run 58 tests
> instead
> of 0 for String.
> 4) Run all TestCases, then, compare test run results with the 'list of
> known
> failures' and see whether new failures appeared. This, I think, is
> 
 better
  
> then 1, 2 and 3, but, overhead is that we support 2 lists - list of
> 
 known
  
> failing tests and exclude list where we put crashing tests.
>
> Thanks, Vladimir
> On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
>> Mikhail Loenko wrote:
>>  
>>> Hi Vladimir,
>>>
>>> IMHO the tests are to verify that an update does not introduce any
>>> regression. So there are two options: remember which exactly
>>> 
 tests may
  
>> fail
>>  
>>> and remember that all tests must pass. I believe the latter one is
>>> 
>> a bit
>>  
>>> easier and safer.
>>> 
>> +1
>>
>> Tim
>>
>>  
>>> Thanks,
>>> Mikhail
>>>
>>> 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>>>
 Hi,
 Working with tests I noticed that we are excluding some tests just
 because
 several tests from single TestCase fail.

 For example, the TestCase 'tests.api.java.lang.StringTest' has 60
 tests and
 only 2 of them fails. But the build excludes the whole TestCase
   
>> and we
>>  
 just
 miss testing of java.lang.String implementation.

 Do we really need to exclude TestCases in 'ant test' target?

 My suggestion is: do not exclude any tests until it crash

Re: [classlib][testing] excluding the failed tests

[George Harley]

Hi Geir,

As you may recall, a while back I floated the idea and supplied some 
seed code to define all known test failing test methods in an XML file 
(an "exclusions list") that could be used by JUnit at test run time to 
skip over them while allowing the rest of the test methods in a class to 
run [1]. Obviously I thought about that when catching up with this 
thread but, more importantly, your comment about being reluctant to have 
more dependencies on JUnit also motivated me to go off and read some 
more about TestNG [2].


It was news to me that TestNG provides out-of-the-box support for 
excluding specific test methods as well as groups of methods (where the 
groups are declared in source file annotations or Javadoc comments). 
Even better, it can do this on existing JUnit test code provided that 
the necessary meta-data (annotations if compiling to a 1.5 target; 
Javadoc comments if targeting 1.4 like we currently are). There is a 
utility available in the TestNG download and also in the Eclipse support 
plug-in that helps migrate directories of existing JUnit tests to TestNG 
by adding in the basic meta-data (although for me the Eclipse version 
also tried to break the test class inheritance from 
junit.framework.TestCase which was definitely not what was required).


Perhaps ... just perhaps ... we should be looking at something like 
TestNG (or my wonderful "exclusions list" :-) ) to provide the 
granularity of test configuration that we need.


Just a thought.

Best regards,
George

[1] http://issues.apache.org/jira/browse/HARMONY-263
[2] http://testng.org



Geir Magnusson Jr wrote:

Alexei Zakharov wrote:
  

Hi,
+1 for (3), but I think it will be better to define suite() method and
enumerate passing tests there rather than to comment out the code.



I'm reluctant to see more dependencies on JUnit when we could control at
a level higher in the build system.

Hard to explain, I guess, but if our exclusions are buried in .java, I
would think that reporting and tracking over time is going to be much
harder.

geir

  

2006/6/27, Richard Liang <[EMAIL PROTECTED]>:


Hello Vladimir,

+1 to option 3) . We shall comment the failed test cases out and add
FIXME to remind us to diagnose the problems later. ;-)

Vladimir Ivanov wrote:
  

I see your point.
But I feel that we can miss regression in non-tested code if we exclude
TestCases.
Now, for example we miss testing of


java.lang.Class/Process/Thread/String
  

and some other classes.

While we have failing tests and don't want to pay attention to these
failures we can:
1) Leave things as is – do not run TestCases with failing tests.
2) Split passing/failing TestCase into separate "failing TestCase" and
"passing TestCase" and exclude "failing TestCases". When test or
implementation is fixed we move tests from failing TestCase to passing
TestCase.
3) Comment failing tests in TestCases. It is better to run 58 tests
instead
of 0 for String.
4) Run all TestCases, then, compare test run results with the 'list of
known
failures' and see whether new failures appeared. This, I think, is


better
  

then 1, 2 and 3, but, overhead is that we support 2 lists - list of


known
  

failing tests and exclude list where we put crashing tests.

Thanks, Vladimir
On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Mikhail Loenko wrote:
  

Hi Vladimir,

IMHO the tests are to verify that an update does not introduce any
regression. So there are two options: remember which exactly


tests may
  

fail
  

and remember that all tests must pass. I believe the latter one is


a bit
  

easier and safer.


+1

Tim

  

Thanks,
Mikhail

2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:


Hi,
Working with tests I noticed that we are excluding some tests just
because
several tests from single TestCase fail.

For example, the TestCase 'tests.api.java.lang.StringTest' has 60
tests and
only 2 of them fails. But the build excludes the whole TestCase
  

and we
  

just
miss testing of java.lang.String implementation.

Do we really need to exclude TestCases in 'ant test' target?

My suggestion is: do not exclude any tests until it crashes VM.
If somebody needs a list of tests that always passed a separated
target can
be added to build.

Do you think we should add target 'test-all' to the build?
 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]
  


--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe

Re: awt and swing integration issues

[Tim Ellison]

Mark Hindess wrote:
> On 27 June 2006 at 7:00, "bootjvm" <[EMAIL PROTECTED]> wrote:
>> Concerning Mark's observation lsat week on AWT/Swing
>> where only a, "couple of files" were C++ instead of C
>> source code:
>>
>> I thing it would make library maintenance easier when everything is
>> done in one single, regular manner.  If everything is C but a short
>> segment, it would make the world run better to not have exceptions to
>> the rule if they could be converted into C.  Mixed language projects
>> in a mode like this _often_ have maintenance issues in this arena.
>> Therefore, I would suggest this conversion be done.
> 
> I'm looking at the integration of the native code from the awt/swing
> 'misc' dependency right now.
> 
> I think these natives will quite likely get merged in to luni at some
> point.  At that point, it would definitely make sense to convert them
> to C to avoid adding unnecessary requirements to a core element of the
> Harmony classlib.

Yes, I had a brief look and there is similarity / overlap with some of
the functionality in o.a.h.luni.platform.  The Accessors would fit in
nicely with that crowd, and we can also extend with some direct object
manipulation code.  But that is for another thread.

Regards,
Tim


> On the other hand I'm not quite so concerned about the use of C++ for
> awt - since the requirement there (for ease of use with GDI) is justified.
> 
> Regards,
>  Mark.
> 
>> Dan Lydick
>>
>>> [Original Message]
>>> From: Geir Magnusson Jr <[EMAIL PROTECTED]>
>>> To: 
>>> Date: 6/19/06 6:49:38 AM
>>> Subject: Re: awt and swing integration issues
>>>
>>> My USD0.02...
>>>
>>> 1) If I were to write a GUI toolkit, I can't imagine why I wouldn't use
>>> C++ given relationships like "DialogBox is a Window"
>>>
>>> 2) Isn't it a reasonably safe bet that any platform that has a GUI is
>>> 'advanced' enough to have a reasonable C++ compiler for it?
>>>
>>> I understand the need to stick to the simplicity of C, but I'm not
>>> surprised w/ the C++
>>>
>>> Mark, are you suggesting we convert it back to C?
>>>
>>> geir
>>>
>>> Alexey Petrenko wrote:
 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> On 18 June 2006 at 22:16, "Alexey Petrenko"
> <[EMAIL PROTECTED]> wrote:
>> 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
>>> c) I'm also wondering about the motivation for using C++ when I
>> can't
>>> see any pressing reason to require this.
>> You mean that most of the native code is C++ but not C?
> Yes.  It seems to be a mixture of C and C++ and although I only looked
> at a couple of files I didn't see anything that really needed C++
> features.
>
> For portability I'd stick to C if C++ isn't really required.
 But C++ gives at least 2 benefits for developer:
 1. Strict type checking
 2. It is allow to write env->FindClass("java/lang/Object") instead of
 (*env)->FindClass(env, "java/lang/Object") :)

 Windows version also uses GDI+ which is class library.

 So I vote for C++...
>>> -
>>> 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/mmtk] jitrino.jet write barrier design questions

[Ivan Volosyuk]

Alex,

The patch in HARMONY-504 works fine for C-based GC, it can have some
problems in Java-based GC. I'm also interested in WB4C support in jet
for experimenting. Currently, I use
http://issues.apache.org/jira/browse/HARMONY-581 to get that support.

--
thanks,
Ivan

On 6/27/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:

Weldon,

Weldon Washburn wrote:
> It would be really nice if jitrino.jet allowed the write barrier to be
> selected at the start of jitting an individual method.   Is this
> possible?
Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
flags to instrument the jitted code.

>
> The selections would be mutually exclusive:
> 1)
> no write barrier (for the existing GCV4)
> 2)
> write barrier written in Java (for MMTk)
> 3)
> write barrier written in C  (for the yet to be determined basic
> generational GC)

VM (or ExectionManager) can signal which barrier to implement using
the flags passed to JIT_compile_method.
The current set of seems incomplete - for instance, it does not cover
array manipulations. Also, we can't signal the difference you mention -
WB4J or WB4C, but sure we can extend the set.

I have a look at the submitted patch for DRLVM (GC write barrier update
patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
seems it's only for interpreter.

If no one complains, I would like to implement the WB4J we are
discussing here in .jet.

As we currently don't have C-based GC with WB support (do we?),
for the first iteration I'm going to instrument code with WB4J in
response to OpenMethodExecutionParams:: exe_insert_write_barriers.
We can change this later then.

Though I'm not familiar with MMTk, could please give me some clues ?

AFAIR from the recent thread, to implement WB for MMTk support, I have
to emit calls of

org.mmtk.plan.PlanLocal.writeBarrier(
ObjectReference src,
Address slot, ObjectReference tgt,
Offset metaDataA, int metaDataB, int mode)
on every PUTSTATIC/PUTFIELD/AASTORE.

I can guess what 'src' is - this is the object being written, right ?
But could you please point me what all other args are ?
Can't we go without all the stuff and have only 2 args - an
object being written and the destination class/array/instance ? :-)


--
Thanks,
   Alex



>
> Allowing the "java" write barrier to be selected on a method by method
> basis would be very useful for MMTk bring up.  The concept is to
> initially run MMTK sort of like a "user mode linux".  That is, startup
> the JVM w/o barriers turned on.  Run "hello world".  Then switch on
> MMTK collector/allocator and Java write barriers and compile/run the
> following method:
>
> public class InitialMMTkBringup {
>
>public int stressTheMMTkAllocator ()  {
>   while(true) {
> Object obj = new Object();
> Object [] ia = new Object[100];
> //at a later stage, add code that causes a write barrier
> //at a later stage, add code that will randomly chain Object
> arrays together...
>  }
> }
>
> The above would be running while the underlying JVM GC is running.  If
> not careful this could cause lots of confusion.  The intention is to
> run MMTk in "user mode" only to the point where MMTk alloc,
> collection, write barrier code paths are exercised.  Provided we do
> not do anything to cause the underlying JVM GC to kick in, we should
> be OK.
>
> As a second step actually integrate MMTk into the JVM.  Note that
> basic garden variety Java debugger should work w/o modification with a
> "user mode MMTk".


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jchevm] _jc_parse_classfile called twice in common case

[Mark Hindess]

Archie,

I notice that there is a common code path that goes:

  _jc_derive_type_from_classfile which calls:
_jc_parse_classfile
_jc_derive_type_interp which calls:
  _jc_parse_classfile (with, I think, the same arguments as before)

Is this correct?  Perhaps we could avoid making the second call?

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: awt and swing integration issues

[Mark Hindess]

On 27 June 2006 at 16:49, Mark Hindess <[EMAIL PROTECTED]> wrote:
> 
> On 27 June 2006 at 7:00, "bootjvm" <[EMAIL PROTECTED]> wrote:
> > 
> > Concerning Mark's observation lsat week on AWT/Swing
> > where only a, "couple of files" were C++ instead of C
> > source code:
> >
> > I thing it would make library maintenance easier when everything is
> > done in one single, regular manner.  If everything is C but a short
> > segment, it would make the world run better to not have exceptions to
> > the rule if they could be converted into C.  Mixed language projects
> > in a mode like this _often_ have maintenance issues in this arena.
> > Therefore, I would suggest this conversion be done.
> 
> I'm looking at the integration of the native code from the awt/swing
> 'misc' dependency right now.
> 
> I think these natives will quite likely get merged in to luni at some
> point.  At that point, it would definitely make sense to convert them
> to C to avoid adding unnecessary requirements to a core element of the
> Harmony classlib.

I just remembered that the binary size was significantly less after 
converting from C++ to C (when I did the auth natives).  So that's
another reason for the simple misc dependency natives to be converted.

-Mark.

> On the other hand I'm not quite so concerned about the use of C++ for
> awt - since the requirement there (for ease of use with GDI) is justified.
> 
> Regards,
>  Mark.
> 
> > Dan Lydick
> > 
> > > [Original Message]
> > > From: Geir Magnusson Jr <[EMAIL PROTECTED]>
> > > To: 
> > > Date: 6/19/06 6:49:38 AM
> > > Subject: Re: awt and swing integration issues
> > >
> > > My USD0.02...
> > >
> > > 1) If I were to write a GUI toolkit, I can't imagine why I wouldn't use
> > > C++ given relationships like "DialogBox is a Window"
> > >
> > > 2) Isn't it a reasonably safe bet that any platform that has a GUI is
> > > 'advanced' enough to have a reasonable C++ compiler for it?
> > >
> > > I understand the need to stick to the simplicity of C, but I'm not
> > > surprised w/ the C++
> > >
> > > Mark, are you suggesting we convert it back to C?
> > >
> > > geir
> > >
> > > Alexey Petrenko wrote:
> > > > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> > > >>
> > > >> On 18 June 2006 at 22:16, "Alexey Petrenko"
> > > >> <[EMAIL PROTECTED]> wrote:
> > > >> > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> > > >> > > c) I'm also wondering about the motivation for using C++ when I
> > can't
> > > >> > > see any pressing reason to require this.
> > > >> > You mean that most of the native code is C++ but not C?
> > > >>
> > > >> Yes.  It seems to be a mixture of C and C++ and although I only looked
> > > >> at a couple of files I didn't see anything that really needed C++
> > > >> features.
> > > >>
> > > >> For portability I'd stick to C if C++ isn't really required.
> > > > But C++ gives at least 2 benefits for developer:
> > > > 1. Strict type checking
> > > > 2. It is allow to write env->FindClass("java/lang/Object") instead of
> > > > (*env)->FindClass(env, "java/lang/Object") :)
> > > > 
> > > > Windows version also uses GDI+ which is class library.
> > > > 
> > > > So I vote for C++...
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > 
> > 
> > 
> > 
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: awt and swing integration issues

[Mark Hindess]

On 27 June 2006 at 7:00, "bootjvm" <[EMAIL PROTECTED]> wrote:
> 
> Concerning Mark's observation lsat week on AWT/Swing
> where only a, "couple of files" were C++ instead of C
> source code:
>
> I thing it would make library maintenance easier when everything is
> done in one single, regular manner.  If everything is C but a short
> segment, it would make the world run better to not have exceptions to
> the rule if they could be converted into C.  Mixed language projects
> in a mode like this _often_ have maintenance issues in this arena.
> Therefore, I would suggest this conversion be done.

I'm looking at the integration of the native code from the awt/swing
'misc' dependency right now.

I think these natives will quite likely get merged in to luni at some
point.  At that point, it would definitely make sense to convert them
to C to avoid adding unnecessary requirements to a core element of the
Harmony classlib.

On the other hand I'm not quite so concerned about the use of C++ for
awt - since the requirement there (for ease of use with GDI) is justified.

Regards,
 Mark.

> Dan Lydick
> 
> > [Original Message]
> > From: Geir Magnusson Jr <[EMAIL PROTECTED]>
> > To: 
> > Date: 6/19/06 6:49:38 AM
> > Subject: Re: awt and swing integration issues
> >
> > My USD0.02...
> >
> > 1) If I were to write a GUI toolkit, I can't imagine why I wouldn't use
> > C++ given relationships like "DialogBox is a Window"
> >
> > 2) Isn't it a reasonably safe bet that any platform that has a GUI is
> > 'advanced' enough to have a reasonable C++ compiler for it?
> >
> > I understand the need to stick to the simplicity of C, but I'm not
> > surprised w/ the C++
> >
> > Mark, are you suggesting we convert it back to C?
> >
> > geir
> >
> > Alexey Petrenko wrote:
> > > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> > >>
> > >> On 18 June 2006 at 22:16, "Alexey Petrenko"
> > >> <[EMAIL PROTECTED]> wrote:
> > >> > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> > >> > > c) I'm also wondering about the motivation for using C++ when I
> can't
> > >> > > see any pressing reason to require this.
> > >> > You mean that most of the native code is C++ but not C?
> > >>
> > >> Yes.  It seems to be a mixture of C and C++ and although I only looked
> > >> at a couple of files I didn't see anything that really needed C++
> > >> features.
> > >>
> > >> For portability I'd stick to C if C++ isn't really required.
> > > But C++ gives at least 2 benefits for developer:
> > > 1. Strict type checking
> > > 2. It is allow to write env->FindClass("java/lang/Object") instead of
> > > (*env)->FindClass(env, "java/lang/Object") :)
> > > 
> > > Windows version also uses GDI+ which is class library.
> > > 
> > > So I vote for C++...
> >
> > -
> > 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: awt and swing integration issues

[Alexey Petrenko]

Let's move to C++? :)

2006/6/27, bootjvm <[EMAIL PROTECTED]>:


Concerning Mark's observation lsat week on AWT/Swing
where only a, "couple of files" were C++ instead of C
source code:

I thing it would make library maintenance easier when
everything is done in one single, regular manner.
If everything is C but a short segment, it would
make the world run better to not have exceptions
to the rule if they could be converted into C.
Mixed language projects in a mode like this _often_
have maintenance issues in this arena.  Therefore,
I would suggest this conversion be done.

Dan Lydick

> [Original Message]
> From: Geir Magnusson Jr <[EMAIL PROTECTED]>
> To: 
> Date: 6/19/06 6:49:38 AM
> Subject: Re: awt and swing integration issues
>
> My USD0.02...
>
> 1) If I were to write a GUI toolkit, I can't imagine why I wouldn't use
> C++ given relationships like "DialogBox is a Window"
>
> 2) Isn't it a reasonably safe bet that any platform that has a GUI is
> 'advanced' enough to have a reasonable C++ compiler for it?
>
> I understand the need to stick to the simplicity of C, but I'm not
> surprised w/ the C++
>
> Mark, are you suggesting we convert it back to C?
>
> geir
>
> Alexey Petrenko wrote:
> > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> >>
> >> On 18 June 2006 at 22:16, "Alexey Petrenko"
> >> <[EMAIL PROTECTED]> wrote:
> >> > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> >> > > c) I'm also wondering about the motivation for using C++ when I
can't
> >> > > see any pressing reason to require this.
> >> > You mean that most of the native code is C++ but not C?
> >>
> >> Yes.  It seems to be a mixture of C and C++ and although I only looked
> >> at a couple of files I didn't see anything that really needed C++
> >> features.
> >>
> >> For portability I'd stick to C if C++ isn't really required.
> > But C++ gives at least 2 benefits for developer:
> > 1. Strict type checking
> > 2. It is allow to write env->FindClass("java/lang/Object") instead of
> > (*env)->FindClass(env, "java/lang/Object") :)
> >
> > Windows version also uses GDI+ which is class library.
> >
> > So I vote for C++...
>
> -
> 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]





--
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: Using Visual Studio C++ Express to compile classlib - fails.

[Mark Hindess]

On 27 June 2006 at 16:23, "Gregory Shimansky" <[EMAIL PROTECTED]> wrote:
> 
> Anyway, I hope my NASM port will not be discarded because it may
> be used to compile Harmony with free as in speech Cygwin or MinGW
> toolchains.

It wont!

A while back I looked at the MinGW toolchain, but gave up since with the
flat native structure it was difficult to find an approach that wasn't
all or nothing.  (And while building some dlls with MinGW was easy, some
were quite difficult ... this was before your nasm port too which will
also make it easier now!)

Once the natives tree is split in to the modules, I intend to try
tackling a module at a time which should be much easier.

Regards,
 Mark.









-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Salikh Zakirov]

Vladimir Ivanov wrote:
> Do not you think these should be different Eclipse scenarios?:
> 1) simple scenario that run Eclipse, compile small application and runs it
> 2) simple debug scenario
> 3) scenario that runs ant-builder
> 4-N) other scenarios that emulate user work

Doing multiple scenarios indeed takes us closer to a "functional testing"
approach. This is a valid approach, but is indeed something different
from regular development.

I think that just one scenario will be sufficient for integration tests.

> Am I correct that you are going to use record and play tools?
> Or, these will be test(s) written using Eclipse API?

As far as I heard, using "record and play" tools proves unrobust,
as the test depends on the screen resolution, CPU load etc.
Eclipse API based approach seems to be more appropriate.

Below is the text of my experiment of modeling Java development in Eclipse.
The test below does the following
1. creates new project
2. inserts class Hi into the project
3. build the project
4. runs the project and checks the output stream of the process

The thing that I haven't managed to achieve is running from the command line.
-
import java.util.HashMap;

import junit.framework.TestCase;

import org.eclipse.core.commands.Command;
import org.eclipse.core.commands.ExecutionEvent;
import org.eclipse.core.resources.IncrementalProjectBuilder;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.debug.core.DebugException;
import org.eclipse.debug.core.ILaunch;
import org.eclipse.debug.core.ILaunchManager;
import org.eclipse.debug.core.Launch;
import org.eclipse.debug.core.model.IProcess;
import org.eclipse.jdt.core.IPackageFragment;
import org.eclipse.jdt.core.IType;
import org.eclipse.jdt.launching.IVMInstall;
import org.eclipse.jdt.launching.IVMRunner;
import org.eclipse.jdt.launching.JavaRuntime;
import org.eclipse.jdt.launching.VMRunnerConfiguration;
import org.eclipse.ui.IWorkbench;
import org.eclipse.ui.PlatformUI;
import org.eclipse.ui.commands.ICommandService;
import org.eclipse.ui.console.ConsolePlugin;

public class ClassCreateAndRunTest extends TestCase {

protected void setUp() throws Exception {
}

public void testHi() throws CoreException {
TestProject testProject = new TestProject();
IPackageFragment pack = testProject.createPackage("hi");
IType type = testProject.createType(pack, "Hi.java",
"public class Hi {"
+ " public static void 
main(String[] args) {"
+ " 
System.out.println(\"Hi!\");" + "   }" + "}");
testProject.getProject().build(
IncrementalProjectBuilder.INCREMENTAL_BUILD, 
null);
IVMInstall vmInstall = JavaRuntime.getVMInstall(testProject
.getJavaProject());
if (vmInstall == null)
vmInstall = JavaRuntime.getDefaultVMInstall();
if (vmInstall != null) {
IVMRunner vmRunner = 
vmInstall.getVMRunner(ILaunchManager.RUN_MODE);
if (vmRunner != null) {
String[] classPath = null;
try {
classPath = JavaRuntime

.computeDefaultRuntimeClassPath(testProject

.getJavaProject());
} catch (CoreException e) {
}
if (classPath != null) {
VMRunnerConfiguration vmConfig = new 
VMRunnerConfiguration(
"hi.Hi", classPath);
vmConfig.setWorkingDirectory("c:\\");
ILaunch launch = new Launch(null, 
ILaunchManager.RUN_MODE,
null);
vmRunner.run(vmConfig, launch, null);
IProcess[] processes = 
launch.getProcesses();
assertEquals(1, processes.length);
int timeout = 3000;
while (timeout > 0) {
try {
assertEquals("Non-0 
status code", 0, processes[0]

.getExitValue());
break;
} catch (DebugException e) {
 

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Anton Luht]

Vladimir,

Regarding what tool will be used - I don't know yet. I'm studying
Eclipse plugins right now. Seems like the situation with standard
macro recording and playback in Eclipse is not very good now [1], so
the emulation will be based on one of Eclipse plugins or will be a
hand-written thing.

I plan to start with 1) and if it succeeds - add other scenarios later.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=80140

On 6/27/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:

Do not you think these should be different Eclipse scenarios?:
1) simple scenario that run Eclipse, compile small application and runs it
2) simple debug scenario
3) scenario that runs ant-builder
4-N) other scenarios that emulate user work

Am I correct that you are going to use record and play tools?
Or, these will be test(s) written using Eclipse API?

 Thanks, Vladimir

On 6/27/06, Anton Luht <[EMAIL PROTECTED]> wrote:
>
> Good day,
>
> Anyway it seems that creating an automated Eclipse scenario as
> described by Salikh will be useful. I'll try to create the scenario,
> corresponding build target and file a JIRA issue with patch for the
> new functionality.
>
> On 6/27/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> > Seems, it is not so easy to define the proper test set...
> > Let's define target to run the integration test. It may be:
> >  1) we want to be sure that all were integrated correctly?
> >  2) or we want to guaranty the 'product quality' for build?
> >  3) some other?
> >
> > If target is 1) than we should run minimal tests set (seems, classlib
> unit
> > tests over tested VM will enough) on one platform.
> > If target is 2) than each developer should run all known/defined tests
> over
> > all platforms. Seems, is no time for development any more. Everyone will
> do
> > the release engineering (RE) work.
> >
> > So we have 2 questions here:
> > 1) the small list of integration test should be defined. It may be
> subset of
> > API unit tests collected as 1 or 2 tests from each API area just to be
> sure
> > that all things were integrated successfully.
> > 2) the RE procedure should be defined. Who is responsible to build the
> HDK
> > and place it to download page? What tests should be run before it? How
> often
> > it should be doing?
> > It is not so obvious as 1). The procedure may be defined, for example,
> as:
> >  - one of committers prepare binary form of HDK and test it on one
> platform.
> >
> >  - if all tests passed he placed it to download somewhere and
> >  - other people test it on other platform.
> >  - if all tests passed the binaries are promoted and placed to the
> > 'official' download page.
> >
> >  Thanks, Vladimir
> >
> > PS. To run some scenario tests actually not integration but functional
> > testing.
> >
> > On 6/26/06, Salikh Zakirov < [EMAIL PROTECTED]> wrote:
> > >
> > > Alexey Petrenko wrote:
> > > > Some checks before commits are defenetly good...
> > > >
> > > > 2006/6/23, Andrey Chernyshev < [EMAIL PROTECTED]>:
> > > >> We may probably also need to define the list of
> > > >> platforms/configurations covered by this procedure.
> > > > I'm not sure that I get your idea correctly.
> > > > Do you suggest to ask every developer to make some checks on
> different
> > > > platforms and software configurations?
> > > > If so... Yes, it is good for product stability.
> > > > But it will be nearly impossible because very small number of
> > > > developers have access to different platforms and software
> > > > configurations...
> > >
> > > First and foremost question is *what* to run as integration tests,
> > > rather than on what platforms. I think we need to define what use
> cases
> > > we care for in the form of integration tests.
> > > The more conveniently the integration tests are packaged, the higher
> is
> > > the probability of anyone running them.
> > > The good example is the "smoke tests" included with DRLVM: they can be
> > > built and run
> > > with a single command 'build.bat test' (' build.sh test' on Linux).
> > >
> > > Once the integration test set is defined, we can think of platform
> > > coverage.
> > > BuildBot [1] could be the way to interested parties to contribute CPU
> > > cycles
> > > to verify Harmony quality.
> > >
> > > [1] http://buildbot.sourceforge.net/
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>





--
Regards,
Anton Luht,
Intel Middleware Products Division

---

Re: Using Visual Studio C++ Express to compile classlib - fails.

[Gregory Shimansky]

2006/6/27, Rana Dasgupta <[EMAIL PROTECTED]>:


On 6/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:

> >I used to build classlib successfully on WinXP with completely free
> >environment, that is MS VS.NET  2005 Express, MS
Platform
> SDK Server 2003 R2
> >and NASM from Cygwin (there is no free MASM with license which allows
OSS
> >development, it can be found for local experiments on quite many
sites).


Gregory,
Not sure what you mean by "no free masm with license which allows OSS
development"...Version 8.0, compatible with VC++ 2005 Express is
downloadable for free from the Microsoft Download site...



http://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=en

   The clck-thru license does say something about not using it for
developing software to be commercially distributed, does that violate ?



Cool! Thanks for the pointer. This is something new. The date published is
June 7 2006 which is pretty recent. It happened after I've written my email
about MASM not available.

Anyway, I hope my NASM port will not be discarded because it may be used to
compile Harmony with free as in speech Cygwin or MinGW toolchains.


   I also read your interesting experiments on the other linked

thread. Microsoft appears to have a new tool mt.exe to embed these
manifests:
mt.exe -manifest someapp.exe.manifest -outputresource:someapp.exe;1
( 1 for .exe and 2 for .dll )

Could be added as a post-build step.

Rana




Sure. I thought I'd have to  experiment with rc or windres utilities so I
gave up at that stage. I didn't know they've invented a special utility
right for the purpose of embedding manifests into executables and dlls.

--
Gregory Shimansky, Intel Middleware Products Division

Re: [classlib]j.u.Formatter test problems on RI

[Richard Liang]

Hello All,

Here we think it's a bug of RI. I have addressed this issue in the 
comments of these test cases. You may want to refer to the spec of 
java.util.Formatter.  Do you think I shall raise a "Non-bug differences 
from RI" in JIRA? Thanks a lot.



public Formatter(Appendable a)
   Constructs a new formatter with the specified destination.
   The locale used is the default locale for this instance of the Java 
virtual machine.

   Parameters:
   *a - Destination for the formatted output. If a is null then a 
StringBuilder will be created.*



Tim Ellison wrote:

Richard is probably best placed to answer that question (so I've changed
the subject to attract his attention ;-) )

Regards,
Tim

Nathan Beyer wrote:
  

Here are the particular failures that I'm seeing. Some seem like minor
things like exception discrepancies, but others like this unexpected
exception "java.util.IllegalFormatFlagsException: Flags = '+'" seem like
flaws.

BTW: if you search for "test_", it will land on the failed test methods.

TESTROOT
tests.api.java.util.FormatterTest
test_ConstructorLjava_lang_Appendable(tests.api.java.util.FormatterTest)
java.util.FormatterClosedException
at java.util.Formatter.ensureOpen(Formatter.java:2315)
at java.util.Formatter.out(Formatter.java:2226)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_lang_Appendable(Form
atterTest.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)

test_ConstructorLjava_io_FileLjava_lang_String(tests.api.java.util.Formatter
Test)
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_io_FileLjava_lang_St
ring(FormatterTest.java:465)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)

test_formatLjava_lang_String$Ljava_lang_Object_Percent(tests.api.java.util.F
ormatterTest)
java.util.IllegalFormatFlagsException: Flags = '+'
at
java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2939)
at java.util.Formatter$FormatSpecifier.(Formatter.java:2644)
   

Re: awt and swing integration issues

[bootjvm]

Concerning Mark's observation lsat week on AWT/Swing
where only a, "couple of files" were C++ instead of C
source code:

I thing it would make library maintenance easier when
everything is done in one single, regular manner.
If everything is C but a short segment, it would
make the world run better to not have exceptions
to the rule if they could be converted into C.
Mixed language projects in a mode like this _often_
have maintenance issues in this arena.  Therefore,
I would suggest this conversion be done.

Dan Lydick

> [Original Message]
> From: Geir Magnusson Jr <[EMAIL PROTECTED]>
> To: 
> Date: 6/19/06 6:49:38 AM
> Subject: Re: awt and swing integration issues
>
> My USD0.02...
>
> 1) If I were to write a GUI toolkit, I can't imagine why I wouldn't use
> C++ given relationships like "DialogBox is a Window"
>
> 2) Isn't it a reasonably safe bet that any platform that has a GUI is
> 'advanced' enough to have a reasonable C++ compiler for it?
>
> I understand the need to stick to the simplicity of C, but I'm not
> surprised w/ the C++
>
> Mark, are you suggesting we convert it back to C?
>
> geir
>
> Alexey Petrenko wrote:
> > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> >>
> >> On 18 June 2006 at 22:16, "Alexey Petrenko"
> >> <[EMAIL PROTECTED]> wrote:
> >> > 2006/6/18, Mark Hindess <[EMAIL PROTECTED]>:
> >> > > c) I'm also wondering about the motivation for using C++ when I
can't
> >> > > see any pressing reason to require this.
> >> > You mean that most of the native code is C++ but not C?
> >>
> >> Yes.  It seems to be a mixture of C and C++ and although I only looked
> >> at a couple of files I didn't see anything that really needed C++
> >> features.
> >>
> >> For portability I'd stick to C if C++ isn't really required.
> > But C++ gives at least 2 benefits for developer:
> > 1. Strict type checking
> > 2. It is allow to write env->FindClass("java/lang/Object") instead of
> > (*env)->FindClass(env, "java/lang/Object") :)
> > 
> > Windows version also uses GDI+ which is class library.
> > 
> > So I vote for C++...
>
> -
> 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] Integration checks (was building from svn on FC5)

[Vladimir Ivanov]

Do not you think these should be different Eclipse scenarios?:
1) simple scenario that run Eclipse, compile small application and runs it
2) simple debug scenario
3) scenario that runs ant-builder
4-N) other scenarios that emulate user work

Am I correct that you are going to use record and play tools?
Or, these will be test(s) written using Eclipse API?

Thanks, Vladimir

On 6/27/06, Anton Luht <[EMAIL PROTECTED]> wrote:


Good day,

Anyway it seems that creating an automated Eclipse scenario as
described by Salikh will be useful. I'll try to create the scenario,
corresponding build target and file a JIRA issue with patch for the
new functionality.

On 6/27/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> Seems, it is not so easy to define the proper test set...
> Let's define target to run the integration test. It may be:
>  1) we want to be sure that all were integrated correctly?
>  2) or we want to guaranty the 'product quality' for build?
>  3) some other?
>
> If target is 1) than we should run minimal tests set (seems, classlib
unit
> tests over tested VM will enough) on one platform.
> If target is 2) than each developer should run all known/defined tests
over
> all platforms. Seems, is no time for development any more. Everyone will
do
> the release engineering (RE) work.
>
> So we have 2 questions here:
> 1) the small list of integration test should be defined. It may be
subset of
> API unit tests collected as 1 or 2 tests from each API area just to be
sure
> that all things were integrated successfully.
> 2) the RE procedure should be defined. Who is responsible to build the
HDK
> and place it to download page? What tests should be run before it? How
often
> it should be doing?
> It is not so obvious as 1). The procedure may be defined, for example,
as:
>  - one of committers prepare binary form of HDK and test it on one
platform.
>
>  - if all tests passed he placed it to download somewhere and
>  - other people test it on other platform.
>  - if all tests passed the binaries are promoted and placed to the
> 'official' download page.
>
>  Thanks, Vladimir
>
> PS. To run some scenario tests actually not integration but functional
> testing.
>
> On 6/26/06, Salikh Zakirov < [EMAIL PROTECTED]> wrote:
> >
> > Alexey Petrenko wrote:
> > > Some checks before commits are defenetly good...
> > >
> > > 2006/6/23, Andrey Chernyshev < [EMAIL PROTECTED]>:
> > >> We may probably also need to define the list of
> > >> platforms/configurations covered by this procedure.
> > > I'm not sure that I get your idea correctly.
> > > Do you suggest to ask every developer to make some checks on
different
> > > platforms and software configurations?
> > > If so... Yes, it is good for product stability.
> > > But it will be nearly impossible because very small number of
> > > developers have access to different platforms and software
> > > configurations...
> >
> > First and foremost question is *what* to run as integration tests,
> > rather than on what platforms. I think we need to define what use
cases
> > we care for in the form of integration tests.
> > The more conveniently the integration tests are packaged, the higher
is
> > the probability of anyone running them.
> > The good example is the "smoke tests" included with DRLVM: they can be
> > built and run
> > with a single command 'build.bat test' (' build.sh test' on Linux).
> >
> > Once the integration test set is defined, we can think of platform
> > coverage.
> > BuildBot [1] could be the way to interested parties to contribute CPU
> > cycles
> > to verify Harmony quality.
> >
> > [1] http://buildbot.sourceforge.net/
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>


--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm/mmtk] jitrino.jet write barrier design questions

[Alex Astapchuk]

Weldon,

Weldon Washburn wrote:

It would be really nice if jitrino.jet allowed the write barrier to be
selected at the start of jitting an individual method.   Is this
possible?

Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
flags to instrument the jitted code.



The selections would be mutually exclusive:
1)
no write barrier (for the existing GCV4)
2)
write barrier written in Java (for MMTk)
3)
write barrier written in C  (for the yet to be determined basic 
generational GC)


VM (or ExectionManager) can signal which barrier to implement using
the flags passed to JIT_compile_method.
The current set of seems incomplete - for instance, it does not cover
array manipulations. Also, we can't signal the difference you mention -
WB4J or WB4C, but sure we can extend the set.

I have a look at the submitted patch for DRLVM (GC write barrier update
patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
seems it's only for interpreter.

If no one complains, I would like to implement the WB4J we are
discussing here in .jet.

As we currently don't have C-based GC with WB support (do we?),
for the first iteration I'm going to instrument code with WB4J in
response to OpenMethodExecutionParams:: exe_insert_write_barriers.
We can change this later then.

Though I'm not familiar with MMTk, could please give me some clues ?

AFAIR from the recent thread, to implement WB for MMTk support, I have
to emit calls of

org.mmtk.plan.PlanLocal.writeBarrier(
ObjectReference src,
Address slot, ObjectReference tgt,
Offset metaDataA, int metaDataB, int mode)
on every PUTSTATIC/PUTFIELD/AASTORE.

I can guess what 'src' is - this is the object being written, right ?
But could you please point me what all other args are ?
Can't we go without all the stuff and have only 2 args - an
object being written and the destination class/array/instance ? :-)


--
Thanks,
  Alex





Allowing the "java" write barrier to be selected on a method by method
basis would be very useful for MMTk bring up.  The concept is to
initially run MMTK sort of like a "user mode linux".  That is, startup
the JVM w/o barriers turned on.  Run "hello world".  Then switch on
MMTK collector/allocator and Java write barriers and compile/run the
following method:

public class InitialMMTkBringup {

   public int stressTheMMTkAllocator ()  {
  while(true) {
Object obj = new Object();
Object [] ia = new Object[100];
//at a later stage, add code that causes a write barrier
//at a later stage, add code that will randomly chain Object
arrays together...
 }
}

The above would be running while the underlying JVM GC is running.  If
not careful this could cause lots of confusion.  The intention is to
run MMTk in "user mode" only to the point where MMTk alloc,
collection, write barrier code paths are exercised.  Provided we do
not do anything to cause the underlying JVM GC to kick in, we should
be OK.

As a second step actually integrate MMTk into the JVM.  Note that
basic garden variety Java debugger should work w/o modification with a
"user mode MMTk".








-
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] Integration checks (was building from svn on FC5)

[Anton Luht]

Good day,

Anyway it seems that creating an automated Eclipse scenario as
described by Salikh will be useful. I'll try to create the scenario,
corresponding build target and file a JIRA issue with patch for the
new functionality.

On 6/27/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:

Seems, it is not so easy to define the proper test set...
Let's define target to run the integration test. It may be:
 1) we want to be sure that all were integrated correctly?
 2) or we want to guaranty the 'product quality' for build?
 3) some other?

If target is 1) than we should run minimal tests set (seems, classlib unit
tests over tested VM will enough) on one platform.
If target is 2) than each developer should run all known/defined tests over
all platforms. Seems, is no time for development any more. Everyone will do
the release engineering (RE) work.

So we have 2 questions here:
1) the small list of integration test should be defined. It may be subset of
API unit tests collected as 1 or 2 tests from each API area just to be sure
that all things were integrated successfully.
2) the RE procedure should be defined. Who is responsible to build the HDK
and place it to download page? What tests should be run before it? How often
it should be doing?
It is not so obvious as 1). The procedure may be defined, for example, as:
 - one of committers prepare binary form of HDK and test it on one platform.

 - if all tests passed he placed it to download somewhere and
 - other people test it on other platform.
 - if all tests passed the binaries are promoted and placed to the
'official' download page.

 Thanks, Vladimir

PS. To run some scenario tests actually not integration but functional
testing.

On 6/26/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
>
> Alexey Petrenko wrote:
> > Some checks before commits are defenetly good...
> >
> > 2006/6/23, Andrey Chernyshev < [EMAIL PROTECTED]>:
> >> We may probably also need to define the list of
> >> platforms/configurations covered by this procedure.
> > I'm not sure that I get your idea correctly.
> > Do you suggest to ask every developer to make some checks on different
> > platforms and software configurations?
> > If so... Yes, it is good for product stability.
> > But it will be nearly impossible because very small number of
> > developers have access to different platforms and software
> > configurations...
>
> First and foremost question is *what* to run as integration tests,
> rather than on what platforms. I think we need to define what use cases
> we care for in the form of integration tests.
> The more conveniently the integration tests are packaged, the higher is
> the probability of anyone running them.
> The good example is the "smoke tests" included with DRLVM: they can be
> built and run
> with a single command 'build.bat test' ('build.sh test' on Linux).
>
> Once the integration test set is defined, we can think of platform
> coverage.
> BuildBot [1] could be the way to interested parties to contribute CPU
> cycles
> to verify Harmony quality.
>
> [1] http://buildbot.sourceforge.net/
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>





--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]

[Paulex Yang]

Alexander Kleymenov wrote:

Hello,


Paulex Yang wrote:

IIRC, Archie's suggest #3 is about select interruption, so what's your
suggestion to implement the blocking I/O interruption?


Use non-blocking calls instead of blocking ones. There are some 
approaches
to implement non-blocking I/O over the blocking (in the native code of 
course).

Although there can appear some cases where it will be impossible to do.
Our issue is not non-blocking I/O, but interruptible blocking I/O, and 
it is possible in some situation to mimic blocking I/O on non-blocking 
ones(that's my understanding of Archie's suggestion #3), but it cannot 
solve all problems, I think we have had related discussion in this thread.



And even another time, I think maybe I need to emphasize again that the
AbstractInterruptibleChannel/AbstractSelector must encapsulate the
machinery about the interruption, so that it is easy for Harmony user to
create its own interruptible channel.


Agree! Moreover, AbstractInterruptibleChannel/AbstractSelector is only
place for it.
I'm not sure, because the interrupted related words also appears in 
Thread's document. I prefer to restate it as : Harmony code (without 
Harmony user awareness) is only place for it.



I doubt that just calling of this methods will made blocking
operations interruptable. I.e. we should have interruption support in
[interruptable] blocking operation anyway.


I think what Andrew said come from Java spec? Why you think the proposal
cannot work?


I do not think it cannot work. It's fine solution and it will do all
the necessary work!
But it needs changes in VMI spec and I tried to discuss approach which 
does

not need such changes.

I see, thank you for the clarification.



Andrew Zhang wrote:


Sorry if I missed something.


Any better solution is highly appreicated, Thanks!


I can propose another way: begin() method creates new thread listening
for Thread.curentThread().isInterrupted() status and if it becomes
true, it just calls close() method, triggers the state of the channel
as ClosedByInterruptException, and exits. The end() method just stops
this additional thread (if it was not stopped after the blocked Thread
had been interrupted) and, if necessary, throws appropriate exception.
No VMI changes are needed, but there will be additional thread between
begin() - end() calls. This thread will sleep between isInterrupted() 
checks

and will not take much computational resources.
Interesting proposal,  though I'm very curious what will happen for 
stress cases, say, BitTorrent client/JMS server/HttpServer, it is true 
that sleeping thread doesn't take much computational resources, but 
hundreds of thread's lifecycle management(creation/scheduling/destroy) 
does.  And another issue is how long should the listener thread sleep? 
The duration is probably hard to judge because some trade-off is needed 
considering real-time and scalability.


I agree that any VMI modification should be very carefully considered 
and discussed, so I appreciate all of your attentions and suggestions, 
but IMHO we should not make current VMI an encumbrance by stopping 
evolving it, after all we are working on a very young project.



Thank You,
Alexander

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Paulex Yang
China Software 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]

[depends] mark and I were chatting

[Geir Magnusson Jr]

Just a note to get some more discussion going.

Mark and I were talking about how to start refactoring out dependencies
to a 'peer' to drlvm and classlib.  And Tim and I have discussed this
too... I just want to capture and get the conversation out here...

So, the idea is that it would be nice to have a common place for
dependencies that parts of Harmony can point to w/ an assist in filling
in.  (I.e - make it easy to get stuff.)

Second, we also want to give each subcomponent (drlvm, jchevm, classlib)
full freedom for dependencies via a simple property setting, so that
people have full freedom to do what they want...

So as a starting point... (names are open to change) ... something like :

/deps
  deps.properties
  build.xml
/build
/external
   /ecj
/3.2
/3.3
   /apr
/2.1
/2.2

etc


where

deps.properties is something like

ECJJAR = ... path to 'default' verison
APRINCLUDE = ... etc...

So that people can reconfigure locally, and even override in a
build.properties or something

Big issue here is that each artifact will have different things, like
libs and includes, jars, etc..

the build.xml will be the top-level ant script that can fetch, update
and build the deps...

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r417385 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: ./ make/ src/main/java/org/apache/harmony/nio/ src/main/java/org/apache/harmony/nio/internal/ src/main/native/ src/

[Geir Magnusson Jr]

Tim Ellison wrote:
> I messed up my commit by commiting at modules/ level when there were
> also changes in native-src/  -- sorry about that.

Eh.  You caught it :)

> 
> It's not been a good week already.
> 
> Regards,
> Tim
> 
> George Harley wrote:
>> Hi Tim,
>>
>> Fixed by your revision 417397 change. Looks like I just chose a bad time
>> to update from the repository.
>>
>> Thanks,
>> George
>>
>>
>>
>> George Harley wrote:
>>> Hi Tim,
>>>
>>> I have started to see test errors in my local Windows XP sandbox since
>>> this commit. In particular there are three tests in the new
>>> org.apache.harmony.tests.nio.AddressUtilTest class that throw
>>> java.lang.UnsatisfiedLinkError on account of not being able to locate
>>> the native implementation of AddressUtil.getFDAddress(FileDescriptor).
>>>
>>> Will look at this a bit closer now - maybe it's a screw up in my
>>> environment - but thought you should know sooner rather than...
>>>
>>> Best regards,
>>> George
>>>
>>>
>>>
>>> [EMAIL PROTECTED] wrote:
 Author: tellison
 Date: Tue Jun 27 02:28:15 2006
 New Revision: 417385

 URL: http://svn.apache.org/viewvc?rev=417385&view=rev
 Log:
 Apply patch HARMONY-578 ([classlib][nio] NIO should provide some
 utility classes for the JNI 1.4 enhancement)

 Added:

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java
   
 (with props)

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/libhynio.exp


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/makefile


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/
   
 (with props)

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.c
   
 (with props)

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.h


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/DirectBufferUtil.c
   
 (with props)

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/
   
 (with props)

 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.def


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.rc


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/makefile


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/nio/AddressUtilTest.java
   
 (with props)
 Modified:
 incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml

 incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml


 incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/internal/FileChannelImpl.java


 Modified:
 incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
 URL:
 http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=417385&r1=417384&r2=417385&view=diff

 ==

 --- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
 (original)
 +++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
 Tue Jun 27 02:28:15 2006
 @@ -39,12 +39,39 @@
  
  
  
 + 
 + 
 + >>> executable="${make.command}" +  
 dir="${hy.nio.src.main.native}/nio/${hy.os}">
 + 
 + 
 + + 
 + 
 + 
 + 
 + 
 + 
 + 
 +
  
  
  
  
  
  
 +
 + 
 + 
 + >>> executable="${make.command}" +  
 dir="${hy.nio.src.main.native}/nio/${hy.os}">
 + 
 + 
 + 
 + 
 +
  
  
  

 Modified:
 incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml

 URL:
 http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml?rev=417385&r1=417384&r2=417385&view=diff

 ==

 ---
 incubator/

Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]

[Tim Ellison]

Alexander Kleymenov wrote:
>> Paulex Yang wrote:
>> Any better solution is highly appreicated, Thanks!
> 
> I can propose another way: begin() method creates new thread listening
> for Thread.curentThread().isInterrupted() status and if it becomes
> true, it just calls close() method, triggers the state of the channel
> as ClosedByInterruptException, and exits. The end() method just stops
> this additional thread (if it was not stopped after the blocked Thread
> had been interrupted) and, if necessary, throws appropriate exception.
> 
> No VMI changes are needed, but there will be additional thread between
> begin() - end() calls. This thread will sleep between isInterrupted()
> checks
> and will not take much computational resources.

I disagree, creating an additional thread per socket besides the blocked
thread will be prohibitively limit IO scalability.

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: svn commit: r417385 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: ./ make/ src/main/java/org/apache/harmony/nio/ src/main/java/org/apache/harmony/nio/internal/ src/main/native/ src/

[Tim Ellison]

I messed up my commit by commiting at modules/ level when there were
also changes in native-src/  -- sorry about that.

It's not been a good week already.

Regards,
Tim

George Harley wrote:
> Hi Tim,
> 
> Fixed by your revision 417397 change. Looks like I just chose a bad time
> to update from the repository.
> 
> Thanks,
> George
> 
> 
> 
> George Harley wrote:
>> Hi Tim,
>>
>> I have started to see test errors in my local Windows XP sandbox since
>> this commit. In particular there are three tests in the new
>> org.apache.harmony.tests.nio.AddressUtilTest class that throw
>> java.lang.UnsatisfiedLinkError on account of not being able to locate
>> the native implementation of AddressUtil.getFDAddress(FileDescriptor).
>>
>> Will look at this a bit closer now - maybe it's a screw up in my
>> environment - but thought you should know sooner rather than...
>>
>> Best regards,
>> George
>>
>>
>>
>> [EMAIL PROTECTED] wrote:
>>> Author: tellison
>>> Date: Tue Jun 27 02:28:15 2006
>>> New Revision: 417385
>>>
>>> URL: http://svn.apache.org/viewvc?rev=417385&view=rev
>>> Log:
>>> Apply patch HARMONY-578 ([classlib][nio] NIO should provide some
>>> utility classes for the JNI 1.4 enhancement)
>>>
>>> Added:
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java
>>>   
>>> (with props)
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/libhynio.exp
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/makefile
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/
>>>   
>>> (with props)
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.c
>>>   
>>> (with props)
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.h
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/DirectBufferUtil.c
>>>   
>>> (with props)
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/
>>>   
>>> (with props)
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.def
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.rc
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/makefile
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/nio/AddressUtilTest.java
>>>   
>>> (with props)
>>> Modified:
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
>>>
>>>
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/internal/FileChannelImpl.java
>>>
>>>
>>> Modified:
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
>>> URL:
>>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=417385&r1=417384&r2=417385&view=diff
>>>
>>> ==
>>>
>>> --- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
>>> (original)
>>> +++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
>>> Tue Jun 27 02:28:15 2006
>>> @@ -39,12 +39,39 @@
>>>  
>>>  
>>>  
>>> + 
>>> + 
>>> + >> executable="${make.command}" +  
>>> dir="${hy.nio.src.main.native}/nio/${hy.os}">
>>> + 
>>> + 
>>> + + 
>>> + 
>>> + 
>>> + 
>>> + 
>>> + 
>>> + 
>>> +
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> +
>>> + 
>>> + 
>>> + >> executable="${make.command}" +  
>>> dir="${hy.nio.src.main.native}/nio/${hy.os}">
>>> + 
>>> + 
>>> + 
>>> + 
>>> +
>>>  
>>>  
>>>  
>>>
>>> Modified:
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
>>>
>>> URL:
>>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml?rev=417385&r1=417384&r2=417385&view=diff
>>>
>>> ==
>>>
>>> ---
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
>>> (original)
>>> +++
>>> incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
>>> Tue Jun 27 02:28:15 2006
>>> @@ -21,6 +21,7

Re: [classlib] Merging frameworks for testing serialization - first step

[Stepan Mishura]

On 6/27/06, Geir Magnusson Jr wrote:




Stepan Mishura wrote:
> On 6/27/06, Geir Magnusson Jr wrote:
>>
>> One minor thing - if you do an ant rebuild and then go into a module to
>> test something specific, it won't work because the support stuff
doesn't
>> get build.
>>
>> I don't know the right solution.  Maybe the module build.xml triggers
>> building the support test, or just a note somewhere to remind people?
>
>
> I think adding 'support.jar' to classpath will help.

Not if it's not built.  That's the issue.  There's no problem if you do
an ant test from /trunk, but if you are 'clean', and then just dive into
modules/$foo and ant test from there, you're stuck.



OK, I see what you mean. But this doesn't relate to moving SerializationTest
to support.
For example, if you are do 'ant clean' in the classlib and then 'cd
modules/security; ant test'. You will see:

Buildfile: build.xml

compile.java:
[echo] Compiling SECURITY classes
   [javac] Compiling 262 source files to
C:\Apache\Harmony\ClassLib\build\classes
   [javac] Fatal Error: Unable to find package java.lang in classpath or
bootclasspath

BUILD FAILED
C:\Apache\Harmony\ClassLib\modules\security\build.xml:62: Compile failed;
see the compiler error output for details.

Thanks,
Stepan.



Not a big deal, just figured someone might be inconvenienced, and if we
either had a fix or a note, that would be cool.

geir

>
> Thanks,
> Stepan.
>
> geir
>>
>>
>> Stepan Mishura wrote:
>> > On 6/26/06, Tim Ellison wrote:
>> >>
>> >> Stepan Mishura wrote:
>> >> > On 6/26/06, Tim Ellison wrote:
>> >> >>
>> >> >> Stepan Mishura wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I've updated framework for testing serialization page[1] - I
>> added
>> >> >> > guidelines
>> >> >> > for developing serialization tests. Also I've removed confusing
>> >> >> 'TestCase'
>> >> >> > parameter in SerializationTest.verifySelf() methods.
>> >> >> >
>> >> >> > If there are no objections I'm going in next two days to move
>> >> >> > SerializationTest.java from 'security' module to support
folder.
>> So
>> >> new
>> >> >> > location will be:
>> >> >> >
>> support/src/test/java/org/apache/harmony/testframework/serialization
>> >> >> > folder.
>> >> >> > Class name won't change.
>> >> >> >
>> >> >> > Thoughts?
>> >> >>
>> >> >> Looks good, just a couple of minor comments:
>> >> >>
>> >> >> - You might as well move them (or duplicate them) to an
>> >> >> org.apache.harmony. package while you are moving things around,
>> since
>> >> we
>> >> >> want to get rid of tests.util as a package name.
>> >> >
>> >> > 'Them' means tests, right?
>> >>
>> >> Sorry, I actually meant the testing framework itself.  The doc says
>> >>
>> >>"The testing framework provides support class
>> >> tests.util.SerializationTest  for serialization testing."
>> >>
>> >> I figured it would be easier to put them in the right place.
>> >
>> >
>> > Ops..., sorry. I thought about replacing SerializationTester and
>> > accidentally put its package name. It should say:
>> > " The testing framework provides support class
>> > org.apache.harmony.testframework.serialization.SerializationTest for
>> > serialization testing."
>> >
>> > I fixed the doc in r417196. Looks better now? :-)
>> >
>> >> - Please will you ensure that the Manifests are updated accordingly
so
>> >> >> that the world is not broken.
>> >> >
>> >> >
>> >> > Sure, I will try.
>> >> >
>> >> > - Not sure about the word 'golden' to mean 'reference' data, when
we
>> >> >> could just use reference, but whatever.
>> >> >
>> >> > In the method names or resource file name? Or both?
>> >>
>> >> Ideally both, it just seems like jargon -- but I realize that such
>> >> renaming doesn't really 'advance the cause', so whatever you think.
>> >
>> >
>> > I'm OK with 'reference' and currently 'golden' can be easily replaced
>> with
>> > it. Otherwise after we rename everything it will be not so simple.
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > Regards,
>> >> Tim
>> >>
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >>
>> >>
>>
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On 6/20/06, Stepan Mishura  wrote:
>> >> >> >>
>> >> >> >>  Hi,
>> >> >> >>
>> >> >> >> I'm going to start merging existing frameworks for testing
>> >> >> serialization.
>> >> >> >>
>> >> >> >> As first step I've updated 'security' framework. The updated
>> >> framework
>> >> >> >> searches and loads resource files according [1] and eliminates
>> >> >> >> requirement
>> >> >> >> to extend SerializationTest. Also to provide smooth frameworks
>> >> merging
>> >> >> >> I've
>> >> >> >> put stub to let the framework search resources in the 'old'
>> way (
>> >> i.e.
>> >> >> >> via
>> >> >> >> "RESOURCE_DIR" system property). The stub will be removed
after
>> >> >> >> completing
>> >> >> >> the merge.
>> >> >> >>
>> >> >> >> The updated framework suggests the following way for testing
>> >> >> >> serialization:
>> >> >>

Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test

[Tim Ellison]

My fault -- fixing it...

Apache Harmony Build wrote:
> Online report : 
> http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1457
> Build statistics:
>   State: Failed
>   Previous State: Failed
>   Started at: Tue, 27 Jun 2006 11:05:40 +0100
>   Finished at: Tue, 27 Jun 2006 11:14:48 +0100
>   Total time: 9m 7s
>   Build Trigger: Schedule
>   Exit code: 1
>   Building machine hostname: hy1
>   Operating system : Windows XP(Service Pack 2)
>   Java version : 1.5.0_06(Sun Microsystems Inc.)
> 
> Changes
> 
> classlib\modules\nio\src\test\java\org\apache\harmony\tests\java\nio\channels\FileLockTest.java
> 
> classlib\modules\nio\src\test\java\org\apache\harmony\tests\nio\AddressUtilTest.java
> classlib\modules\nio\src\main\java\java\nio\channels\FileLock.java
> 
> classlib\modules\nio\src\main\java\org\apache\harmony\nio\AddressUtil.java
> 
> classlib\modules\nio\src\main\java\org\apache\harmony\nio\internal\FileChannelImpl.java
> classlib\modules\nio\src\main\native\nio\linux\libhynio.exp
> classlib\modules\nio\src\main\native\nio\linux\makefile
> classlib\modules\nio\src\main\native\nio\shared\DirectBufferUtil.c
> classlib\modules\nio\src\main\native\nio\shared\AddressUtil.c
> classlib\modules\nio\src\main\native\nio\shared\AddressUtil.h
> classlib\modules\nio\src\main\native\nio\windows\hynio.def
> classlib\modules\nio\src\main\native\nio\windows\hynio.rc
> classlib\modules\nio\src\main\native\nio\windows\makefile
> classlib\modules\nio\make\hyproperties.xml
> classlib\modules\nio\build.xml
> 


-- 

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: svn commit: r417385 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: ./ make/ src/main/java/org/apache/harmony/nio/ src/main/java/org/apache/harmony/nio/internal/ src/main/native/ src/

[George Harley]

Hi Tim,

Fixed by your revision 417397 change. Looks like I just chose a bad time 
to update from the repository.


Thanks,
George



George Harley wrote:

Hi Tim,

I have started to see test errors in my local Windows XP sandbox since 
this commit. In particular there are three tests in the new 
org.apache.harmony.tests.nio.AddressUtilTest class that throw 
java.lang.UnsatisfiedLinkError on account of not being able to locate 
the native implementation of AddressUtil.getFDAddress(FileDescriptor).


Will look at this a bit closer now - maybe it's a screw up in my 
environment - but thought you should know sooner rather than...


Best regards,
George



[EMAIL PROTECTED] wrote:

Author: tellison
Date: Tue Jun 27 02:28:15 2006
New Revision: 417385

URL: http://svn.apache.org/viewvc?rev=417385&view=rev
Log:
Apply patch HARMONY-578 ([classlib][nio] NIO should provide some 
utility classes for the JNI 1.4 enhancement)


Added:

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java   
(with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/ 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/ 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/libhynio.exp 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/makefile 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/   
(with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.c   
(with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.h 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/DirectBufferUtil.c   
(with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/   
(with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.def 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.rc 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/makefile 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/nio/AddressUtilTest.java   
(with props)

Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml

incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml 


incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/internal/FileChannelImpl.java 



Modified: 
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=417385&r1=417384&r2=417385&view=diff 

== 

--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml 
(original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml 
Tue Jun 27 02:28:15 2006

@@ -39,12 +39,39 @@
 
 
 
+ 

+ 
+ executable="${make.command}" +   
dir="${hy.nio.src.main.native}/nio/${hy.os}">

+ 
+ 
+ + 
+ 
+ 
+ 
+ 
+ 
+ 
+
 
 
 
 
 
 
+
+ 
+ 
+ executable="${make.command}" +   
dir="${hy.nio.src.main.native}/nio/${hy.os}">

+ 
+ 
+ 
+ 
+
 
 

 

Modified: 
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml 

URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml?rev=417385&r1=417384&r2=417385&view=diff 

== 

--- 
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml 
(original)
+++ 
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml 
Tue Jun 27 02:28:15 2006

@@ -21,6 +21,7 @@
  
 
 
+
  
  
 

Added: 
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java 

URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java?rev=417385&view=auto 

== 

--- 
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java 
(added)
+++ 
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java 
Tue Jun 27 02:28

Re: Using Visual Studio C++ Express to compile classlib - fails.

[Oliver Deakin]

Thorbjørn Ravn Andersen wrote:

Mark Hindess skrev  den 26-06-2006 21:57:

What would a feasible path be from here?
  

Looks like one of the variables set in one of those "empty" included 
makefiles should be CC set to cl ?
  
I forgot to state that I somewhat arbitrarily tried doing exactly 
that, but without any success in locating the right one.   I therefore 
hoped to hear from a person who knows more about this build system.


BTW Do you know if there is any particular reason that files are 
copied over to the deploy directory instead of being read directly 
from their original location and the compiled output written to deploy?


Do you mean the header files in deploy/include? If so, the reason they 
are copied
there is so that they are in a shared location for all modules. (In fact 
it's the same
reason that libs are built into deploy/lib and makefile includes are 
copied into

deploy/build/make).

A little while ago there were a couple of threads where we discussed a 
Harmony

Development Kit (HDK) [1] which would allow a developer to build any
individual module without necessarily having the other modules present in
their workspace.
To this end we have set up the deploy directory to contain all the 
resources
required to rebuild a single module standalone - that means any shared 
header
files, any libs used to link against and any makefile includes. The 
header files

you see in deploy/include are those required to be shared between multiple
modules, and (loosely) define a native API between modules.

The idea is that eventually we will package HDKs up and make them available
as a downloadable bundle (in a similar way to the current classlib 
snapshots).

Then a developer can just download the HDK, unpack it somewhere and
rebuild any individual module against it that they are interested in 
working on.

As a consequence, they could also *only* checkout the module they are
interested in, rather than the whole of classlib/trunk, and still be 
able to rebuild

their altered code.

Regards,
Oliver

[1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html



--
  Thorbjørn



--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][testing] excluding the failed tests

[Geir Magnusson Jr]

Alexei Zakharov wrote:
> Hi,
> +1 for (3), but I think it will be better to define suite() method and
> enumerate passing tests there rather than to comment out the code.

I'm reluctant to see more dependencies on JUnit when we could control at
a level higher in the build system.

Hard to explain, I guess, but if our exclusions are buried in .java, I
would think that reporting and tracking over time is going to be much
harder.

geir

> 
> 2006/6/27, Richard Liang <[EMAIL PROTECTED]>:
>> Hello Vladimir,
>>
>> +1 to option 3) . We shall comment the failed test cases out and add
>> FIXME to remind us to diagnose the problems later. ;-)
>>
>> Vladimir Ivanov wrote:
>> > I see your point.
>> > But I feel that we can miss regression in non-tested code if we exclude
>> > TestCases.
>> > Now, for example we miss testing of
>> java.lang.Class/Process/Thread/String
>> > and some other classes.
>> >
>> > While we have failing tests and don't want to pay attention to these
>> > failures we can:
>> > 1) Leave things as is – do not run TestCases with failing tests.
>> > 2) Split passing/failing TestCase into separate "failing TestCase" and
>> > "passing TestCase" and exclude "failing TestCases". When test or
>> > implementation is fixed we move tests from failing TestCase to passing
>> > TestCase.
>> > 3) Comment failing tests in TestCases. It is better to run 58 tests
>> > instead
>> > of 0 for String.
>> > 4) Run all TestCases, then, compare test run results with the 'list of
>> > known
>> > failures' and see whether new failures appeared. This, I think, is
>> better
>> > then 1, 2 and 3, but, overhead is that we support 2 lists - list of
>> known
>> > failing tests and exclude list where we put crashing tests.
>> >
>> > Thanks, Vladimir
>> > On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Mikhail Loenko wrote:
>> >> > Hi Vladimir,
>> >> >
>> >> > IMHO the tests are to verify that an update does not introduce any
>> >> > regression. So there are two options: remember which exactly
>> tests may
>> >> fail
>> >> > and remember that all tests must pass. I believe the latter one is
>> >> a bit
>> >> > easier and safer.
>> >>
>> >> +1
>> >>
>> >> Tim
>> >>
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >> > 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> >> >> Hi,
>> >> >> Working with tests I noticed that we are excluding some tests just
>> >> >> because
>> >> >> several tests from single TestCase fail.
>> >> >>
>> >> >> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>> >> >> tests and
>> >> >> only 2 of them fails. But the build excludes the whole TestCase
>> >> and we
>> >> >> just
>> >> >> miss testing of java.lang.String implementation.
>> >> >>
>> >> >> Do we really need to exclude TestCases in 'ant test' target?
>> >> >>
>> >> >> My suggestion is: do not exclude any tests until it crashes VM.
>> >> >> If somebody needs a list of tests that always passed a separated
>> >> >> target can
>> >> >> be added to build.
>> >> >>
>> >> >> Do you think we should add target 'test-all' to the build?
>> >> >>  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]
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >> 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]
>> >>
>> >>
>> >
>>
>> -- 
>> Richard Liang
>> China Software 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]

Re: [classlib][testing] excluding the failed tests

[Geir Magnusson Jr]

Tim Ellison wrote:
> There was a submission that enabled finer control of failing tests (even
> by platform etc.)
> 
> I may be wrong but commenting out tests usually means that they never
> get fixed; 

Yes, that was my concern as well.

> even putting them into exclude clauses in the ant script is
> too hidden for me -- I prefer to see the exclusions and failures made
> available very clearly.

Well, if we did refactor into

TestFOO.java and TestFOO_Failures.java

and have an explicit include, people would clearly see the problematic
test cases and might be motivated to contribute by fixing...

geir

> 
> Regards,
> Tim
> 
> Alexei Zakharov wrote:
>> Hi,
>> +1 for (3), but I think it will be better to define suite() method and
>> enumerate passing tests there rather than to comment out the code.
>>
>> 2006/6/27, Richard Liang <[EMAIL PROTECTED]>:
>>> Hello Vladimir,
>>>
>>> +1 to option 3) . We shall comment the failed test cases out and add
>>> FIXME to remind us to diagnose the problems later. ;-)
>>>
>>> Vladimir Ivanov wrote:
 I see your point.
 But I feel that we can miss regression in non-tested code if we exclude
 TestCases.
 Now, for example we miss testing of
>>> java.lang.Class/Process/Thread/String
 and some other classes.

 While we have failing tests and don't want to pay attention to these
 failures we can:
 1) Leave things as is – do not run TestCases with failing tests.
 2) Split passing/failing TestCase into separate "failing TestCase" and
 "passing TestCase" and exclude "failing TestCases". When test or
 implementation is fixed we move tests from failing TestCase to passing
 TestCase.
 3) Comment failing tests in TestCases. It is better to run 58 tests
 instead
 of 0 for String.
 4) Run all TestCases, then, compare test run results with the 'list of
 known
 failures' and see whether new failures appeared. This, I think, is
>>> better
 then 1, 2 and 3, but, overhead is that we support 2 lists - list of
>>> known
 failing tests and exclude list where we put crashing tests.

 Thanks, Vladimir
 On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Mikhail Loenko wrote:
>> Hi Vladimir,
>>
>> IMHO the tests are to verify that an update does not introduce any
>> regression. So there are two options: remember which exactly
>>> tests may
> fail
>> and remember that all tests must pass. I believe the latter one is
> a bit
>> easier and safer.
> +1
>
> Tim
>
>> Thanks,
>> Mikhail
>>
>> 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>>> Hi,
>>> Working with tests I noticed that we are excluding some tests just
>>> because
>>> several tests from single TestCase fail.
>>>
>>> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>>> tests and
>>> only 2 of them fails. But the build excludes the whole TestCase
> and we
>>> just
>>> miss testing of java.lang.String implementation.
>>>
>>> Do we really need to exclude TestCases in 'ant test' target?
>>>
>>> My suggestion is: do not exclude any tests until it crashes VM.
>>> If somebody needs a list of tests that always passed a separated
>>> target can
>>> be added to build.
>>>
>>> Do you think we should add target 'test-all' to the build?
>>>  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]
>>
> --
>
> 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]
>
>
>>> -- 
>>> Richard Liang
>>> China Software 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]

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Vladimir Ivanov]

Seems, it is not so easy to define the proper test set...
Let's define target to run the integration test. It may be:
1) we want to be sure that all were integrated correctly?
2) or we want to guaranty the 'product quality' for build?
3) some other?

If target is 1) than we should run minimal tests set (seems, classlib unit
tests over tested VM will enough) on one platform.
If target is 2) than each developer should run all known/defined tests over
all platforms. Seems, is no time for development any more. Everyone will do
the release engineering (RE) work.

So we have 2 questions here:
1) the small list of integration test should be defined. It may be subset of
API unit tests collected as 1 or 2 tests from each API area just to be sure
that all things were integrated successfully.
2) the RE procedure should be defined. Who is responsible to build the HDK
and place it to download page? What tests should be run before it? How often
it should be doing?
It is not so obvious as 1). The procedure may be defined, for example, as:
- one of committers prepare binary form of HDK and test it on one platform.

- if all tests passed he placed it to download somewhere and
- other people test it on other platform.
- if all tests passed the binaries are promoted and placed to the
'official' download page.

Thanks, Vladimir

PS. To run some scenario tests actually not integration but functional
testing.

On 6/26/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:


Alexey Petrenko wrote:
> Some checks before commits are defenetly good...
>
> 2006/6/23, Andrey Chernyshev < [EMAIL PROTECTED]>:
>> We may probably also need to define the list of
>> platforms/configurations covered by this procedure.
> I'm not sure that I get your idea correctly.
> Do you suggest to ask every developer to make some checks on different
> platforms and software configurations?
> If so... Yes, it is good for product stability.
> But it will be nearly impossible because very small number of
> developers have access to different platforms and software
> configurations...

First and foremost question is *what* to run as integration tests,
rather than on what platforms. I think we need to define what use cases
we care for in the form of integration tests.
The more conveniently the integration tests are packaged, the higher is
the probability of anyone running them.
The good example is the "smoke tests" included with DRLVM: they can be
built and run
with a single command 'build.bat test' ('build.sh test' on Linux).

Once the integration test set is defined, we can think of platform
coverage.
BuildBot [1] could be the way to interested parties to contribute CPU
cycles
to verify Harmony quality.

[1] http://buildbot.sourceforge.net/

-
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] Merging frameworks for testing serialization - first step

[Geir Magnusson Jr]

Stepan Mishura wrote:
> On 6/27/06, Geir Magnusson Jr wrote:
>>
>> One minor thing - if you do an ant rebuild and then go into a module to
>> test something specific, it won't work because the support stuff doesn't
>> get build.
>>
>> I don't know the right solution.  Maybe the module build.xml triggers
>> building the support test, or just a note somewhere to remind people?
> 
> 
> I think adding 'support.jar' to classpath will help.

Not if it's not built.  That's the issue.  There's no problem if you do
an ant test from /trunk, but if you are 'clean', and then just dive into
 modules/$foo and ant test from there, you're stuck.

Not a big deal, just figured someone might be inconvenienced, and if we
either had a fix or a note, that would be cool.

geir

> 
> Thanks,
> Stepan.
> 
> geir
>>
>>
>> Stepan Mishura wrote:
>> > On 6/26/06, Tim Ellison wrote:
>> >>
>> >> Stepan Mishura wrote:
>> >> > On 6/26/06, Tim Ellison wrote:
>> >> >>
>> >> >> Stepan Mishura wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I've updated framework for testing serialization page[1] - I
>> added
>> >> >> > guidelines
>> >> >> > for developing serialization tests. Also I've removed confusing
>> >> >> 'TestCase'
>> >> >> > parameter in SerializationTest.verifySelf() methods.
>> >> >> >
>> >> >> > If there are no objections I'm going in next two days to move
>> >> >> > SerializationTest.java from 'security' module to support folder.
>> So
>> >> new
>> >> >> > location will be:
>> >> >> >
>> support/src/test/java/org/apache/harmony/testframework/serialization
>> >> >> > folder.
>> >> >> > Class name won't change.
>> >> >> >
>> >> >> > Thoughts?
>> >> >>
>> >> >> Looks good, just a couple of minor comments:
>> >> >>
>> >> >> - You might as well move them (or duplicate them) to an
>> >> >> org.apache.harmony. package while you are moving things around,
>> since
>> >> we
>> >> >> want to get rid of tests.util as a package name.
>> >> >
>> >> > 'Them' means tests, right?
>> >>
>> >> Sorry, I actually meant the testing framework itself.  The doc says
>> >>
>> >>"The testing framework provides support class
>> >> tests.util.SerializationTest  for serialization testing."
>> >>
>> >> I figured it would be easier to put them in the right place.
>> >
>> >
>> > Ops..., sorry. I thought about replacing SerializationTester and
>> > accidentally put its package name. It should say:
>> > " The testing framework provides support class
>> > org.apache.harmony.testframework.serialization.SerializationTest for
>> > serialization testing."
>> >
>> > I fixed the doc in r417196. Looks better now? :-)
>> >
>> >> - Please will you ensure that the Manifests are updated accordingly so
>> >> >> that the world is not broken.
>> >> >
>> >> >
>> >> > Sure, I will try.
>> >> >
>> >> > - Not sure about the word 'golden' to mean 'reference' data, when we
>> >> >> could just use reference, but whatever.
>> >> >
>> >> > In the method names or resource file name? Or both?
>> >>
>> >> Ideally both, it just seems like jargon -- but I realize that such
>> >> renaming doesn't really 'advance the cause', so whatever you think.
>> >
>> >
>> > I'm OK with 'reference' and currently 'golden' can be easily replaced
>> with
>> > it. Otherwise after we rename everything it will be not so simple.
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > Regards,
>> >> Tim
>> >>
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >>
>> >>
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On 6/20/06, Stepan Mishura  wrote:
>> >> >> >>
>> >> >> >>  Hi,
>> >> >> >>
>> >> >> >> I'm going to start merging existing frameworks for testing
>> >> >> serialization.
>> >> >> >>
>> >> >> >> As first step I've updated 'security' framework. The updated
>> >> framework
>> >> >> >> searches and loads resource files according [1] and eliminates
>> >> >> >> requirement
>> >> >> >> to extend SerializationTest. Also to provide smooth frameworks
>> >> merging
>> >> >> >> I've
>> >> >> >> put stub to let the framework search resources in the 'old'
>> way (
>> >> i.e.
>> >> >> >> via
>> >> >> >> "RESOURCE_DIR" system property). The stub will be removed after
>> >> >> >> completing
>> >> >> >> the merge.
>> >> >> >>
>> >> >> >> The updated framework suggests the following way for testing
>> >> >> >> serialization:
>> >> >> >>
>> >> >> >> a) Compatibility – 4 new static methods are introduced.
>> >> >> >> verifyGolden(TestCase, Object)
>> >> >> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> >> >> verifyGolden(TestCase, Object[])
>> >> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >> >> >>
>> >> >> >> A test should invoke one of above methods, for example,
>> >> >> >> public void testCompatibility() throws Exception {
>> >> >> >> SerializationTest.verifyGolden(this, new
>> SomeSerializableClass
>> >> >> ());
>> >> >> >> }
>> >> >> >>
>> >> >> >> b) Self-testing: the same as for compatibility – th

Re: [drlvm] build fails on Windows os

[Geir Magnusson Jr]

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Yah, I was running a full clean rebuild including the downloads and fell
>> asleep.
> 
> LOL - the best cure for insomnia :-) "ant rebuild test"

:)

I felt bad when I woke up, and then really annoyed because the hotel
network stopped working so I couldn't do anything.

The commit is in now, and I reversed mark's reversal - please verify
that all is well.

geir

> 
> Regards,
> Tim
> 
>> I'll check in now and reverse marks reversal.
>>
>> geir
>>
>>
>> Mark Hindess wrote:
>>> On 27 June 2006 at 15:09, "Vladimir Gorr" <[EMAIL PROTECTED]> wrote:
 On 6/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> On 27 June 2006 at 9:48, "Marina Goldburt" <[EMAIL PROTECTED]>
> wrote:
>> On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>>> Odd.  It was broken for me too.  What changed?
>>>
>>> I applied the patch - thanks.
>>  I think, the problem is in the log4cxx revision -
>> the old log4cxx didn't use the aprutil xml API.
> Ah ... this problem would be from my change as discussed in the recent
> "[DRLVM] building from svn on FC5" thread where I wrote:
>
> I've fixed (in r416807) the revisions for log4cxx on linux and windows
> to use r416779.  Works for me on Linux.  Can some test on windows and
> report if this causes any regression?
>
> Obviously it did cause a regression on windows but the new version is
> needed on Linux to get the build to work.
>
> I've backed out the windows part of this change in r417350.  Can someone
> check that this fixes the problem on windows?
 Mark,


 yes, the problem disappeared on Windows after your change.

 Although, I don't understand why should we use the different revisions of
 LOG4CXX on Windows and Linux?
>>> Ideally they should be running the same version if it works.
>>>
 If the patch mentioned by Marina is accepted then the problem also
 disappears.
>>> Good.  I wanted to backout the change until Geir applied the fix.  IIRC,
>>> he said in his note that he had but he's not checked it in yet.  I
>>> wasn't comfortable leaving it broken.  We can Linux and Windows back in
>>> sync when Geir has applied Marina's fix.
>>>
>>> -Mark.
>>>
>>>
>>>
>>> -
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r417385 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: ./ make/ src/main/java/org/apache/harmony/nio/ src/main/java/org/apache/harmony/nio/internal/ src/main/native/ src/

[George Harley]

Hi Tim,

I have started to see test errors in my local Windows XP sandbox since 
this commit. In particular there are three tests in the new 
org.apache.harmony.tests.nio.AddressUtilTest class that throw 
java.lang.UnsatisfiedLinkError on account of not being able to locate 
the native implementation of AddressUtil.getFDAddress(FileDescriptor).


Will look at this a bit closer now - maybe it's a screw up in my 
environment - but thought you should know sooner rather than...


Best regards,
George



[EMAIL PROTECTED] wrote:

Author: tellison
Date: Tue Jun 27 02:28:15 2006
New Revision: 417385

URL: http://svn.apache.org/viewvc?rev=417385&view=rev
Log:
Apply patch HARMONY-578 ([classlib][nio] NIO should provide some utility 
classes for the JNI 1.4 enhancement)

Added:

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java
   (with props)
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/libhynio.exp

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/linux/makefile

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/
   (with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.c
   (with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/AddressUtil.h

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/shared/DirectBufferUtil.c
   (with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/
   (with props)

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.def

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/hynio.rc

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/native/nio/windows/makefile

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/nio/AddressUtilTest.java
   (with props)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml

incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/internal/FileChannelImpl.java

Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=417385&r1=417384&r2=417385&view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml Tue Jun 27 
02:28:15 2006
@@ -39,12 +39,39 @@
 
 
 
+ 

+ 
+ 	+   executable="${make.command}" 
+   dir="${hy.nio.src.main.native}/nio/${hy.os}">

+ 
+ 
+ 
+ 	

+   
+ 
+ 
+ 
+ 
+ 
+
 
 
 
 
 
 
+
+ 
+ 
+ 	+   executable="${make.command}" 
+   dir="${hy.nio.src.main.native}/nio/${hy.os}">

+ 
+   
+ 
+ 
+
 
 

 

Modified: 
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml?rev=417385&r1=417384&r2=417385&view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml 
(original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml 
Tue Jun 27 02:28:15 2006
@@ -21,6 +21,7 @@
  
 

+   
  
  
 

Added: 
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java?rev=417385&view=auto
==
--- 
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java
 (added)
+++ 
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/org/apache/harmony/nio/AddressUtil.java
 Tue Jun 27 02:28:15 2006
@@ -0,0 +1,68 @@
+/* Copyright 2006 The Apache Software Foundation or its licensors, as 
applicable
+ * 
+ * Licensed under the Apache License, Version 2.0 (the

Re: [classlib] Merging frameworks for testing serialization - first step

[Stepan Mishura]

On 6/27/06, Geir Magnusson Jr wrote:


One minor thing - if you do an ant rebuild and then go into a module to
test something specific, it won't work because the support stuff doesn't
get build.

I don't know the right solution.  Maybe the module build.xml triggers
building the support test, or just a note somewhere to remind people?



I think adding 'support.jar' to classpath will help.

Thanks,
Stepan.

geir



Stepan Mishura wrote:
> On 6/26/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > On 6/26/06, Tim Ellison wrote:
>> >>
>> >> Stepan Mishura wrote:
>> >> > Hi,
>> >> >
>> >> > I've updated framework for testing serialization page[1] - I added
>> >> > guidelines
>> >> > for developing serialization tests. Also I've removed confusing
>> >> 'TestCase'
>> >> > parameter in SerializationTest.verifySelf() methods.
>> >> >
>> >> > If there are no objections I'm going in next two days to move
>> >> > SerializationTest.java from 'security' module to support folder.
So
>> new
>> >> > location will be:
>> >> >
support/src/test/java/org/apache/harmony/testframework/serialization
>> >> > folder.
>> >> > Class name won't change.
>> >> >
>> >> > Thoughts?
>> >>
>> >> Looks good, just a couple of minor comments:
>> >>
>> >> - You might as well move them (or duplicate them) to an
>> >> org.apache.harmony. package while you are moving things around,
since
>> we
>> >> want to get rid of tests.util as a package name.
>> >
>> > 'Them' means tests, right?
>>
>> Sorry, I actually meant the testing framework itself.  The doc says
>>
>>"The testing framework provides support class
>> tests.util.SerializationTest  for serialization testing."
>>
>> I figured it would be easier to put them in the right place.
>
>
> Ops..., sorry. I thought about replacing SerializationTester and
> accidentally put its package name. It should say:
> " The testing framework provides support class
> org.apache.harmony.testframework.serialization.SerializationTest for
> serialization testing."
>
> I fixed the doc in r417196. Looks better now? :-)
>
>> - Please will you ensure that the Manifests are updated accordingly so
>> >> that the world is not broken.
>> >
>> >
>> > Sure, I will try.
>> >
>> > - Not sure about the word 'golden' to mean 'reference' data, when we
>> >> could just use reference, but whatever.
>> >
>> > In the method names or resource file name? Or both?
>>
>> Ideally both, it just seems like jargon -- but I realize that such
>> renaming doesn't really 'advance the cause', so whatever you think.
>
>
> I'm OK with 'reference' and currently 'golden' can be easily replaced
with
> it. Otherwise after we rename everything it will be not so simple.
>
> Thanks,
> Stepan.
>
> Regards,
>> Tim
>>
>> >> >
>> >> > [1]
>> >> >
>> >>
>>
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >>
>> >> >
>> >> >
>> >> > On 6/20/06, Stepan Mishura  wrote:
>> >> >>
>> >> >>  Hi,
>> >> >>
>> >> >> I'm going to start merging existing frameworks for testing
>> >> serialization.
>> >> >>
>> >> >> As first step I've updated 'security' framework. The updated
>> framework
>> >> >> searches and loads resource files according [1] and eliminates
>> >> >> requirement
>> >> >> to extend SerializationTest. Also to provide smooth frameworks
>> merging
>> >> >> I've
>> >> >> put stub to let the framework search resources in the 'old' way (
>> i.e.
>> >> >> via
>> >> >> "RESOURCE_DIR" system property). The stub will be removed after
>> >> >> completing
>> >> >> the merge.
>> >> >>
>> >> >> The updated framework suggests the following way for testing
>> >> >> serialization:
>> >> >>
>> >> >> a) Compatibility – 4 new static methods are introduced.
>> >> >> verifyGolden(TestCase, Object)
>> >> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> >> verifyGolden(TestCase, Object[])
>> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >> >>
>> >> >> A test should invoke one of above methods, for example,
>> >> >> public void testCompatibility() throws Exception {
>> >> >> SerializationTest.verifyGolden(this, new
SomeSerializableClass
>> >> ());
>> >> >> }
>> >> >>
>> >> >> b) Self-testing: the same as for compatibility – there are 4 new
>> >> static
>> >> >> methods that should be invoked from a test:
>> >> >> verifySelf(TestCase, Object)
>> >> >> verifySelf(Object, SerializableAssert)
>> >> >> verifySelf(TestCase, Object[])
>> >> >> verifySelf(Object[], SerializableAssert)
>> >> >>
>> >> >> For example,
>> >> >> public void testSelf() throws Exception {
>> >> >> SerializationTest.verifySelf(new SomeSerializableClass(), new
>> >> >> MyComparator());
>> >> >> }
>> >> >>
>> >> >> To complete frameworks merging I'd like to suggest the next
steps:
>> >> >> 2) Reviewing the update and the suggested way for testing
>> >> >> serialization by
>> >> >> the community. Please let me know if it is acceptable and what
can
>> be
>> >> >> improved.
>> >> >> 3) Replace Serializat

Re: [drlvm] build fails on Windows os

[Tim Ellison]

Geir Magnusson Jr wrote:
> Yah, I was running a full clean rebuild including the downloads and fell
> asleep.

LOL - the best cure for insomnia :-) "ant rebuild test"

Regards,
Tim

> I'll check in now and reverse marks reversal.
> 
> geir
> 
> 
> Mark Hindess wrote:
>> On 27 June 2006 at 15:09, "Vladimir Gorr" <[EMAIL PROTECTED]> wrote:
>>> On 6/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
 On 27 June 2006 at 9:48, "Marina Goldburt" <[EMAIL PROTECTED]>
 wrote:
> On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>> Odd.  It was broken for me too.  What changed?
>>
>> I applied the patch - thanks.
>  I think, the problem is in the log4cxx revision -
> the old log4cxx didn't use the aprutil xml API.
 Ah ... this problem would be from my change as discussed in the recent
 "[DRLVM] building from svn on FC5" thread where I wrote:

 I've fixed (in r416807) the revisions for log4cxx on linux and windows
 to use r416779.  Works for me on Linux.  Can some test on windows and
 report if this causes any regression?

 Obviously it did cause a regression on windows but the new version is
 needed on Linux to get the build to work.

 I've backed out the windows part of this change in r417350.  Can someone
 check that this fixes the problem on windows?
>>> Mark,
>>>
>>>
>>> yes, the problem disappeared on Windows after your change.
>>>
>>> Although, I don't understand why should we use the different revisions of
>>> LOG4CXX on Windows and Linux?
>> Ideally they should be running the same version if it works.
>>
>>> If the patch mentioned by Marina is accepted then the problem also
>>> disappears.
>> Good.  I wanted to backout the change until Geir applied the fix.  IIRC,
>> he said in his note that he had but he's not checked it in yet.  I
>> wasn't comfortable leaving it broken.  We can Linux and Windows back in
>> sync when Geir has applied Marina's fix.
>>
>> -Mark.
>>
>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-- 

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: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test

[Tim Ellison]

I've excluded the SocketChannelTest (repo rev r417387) until it is fixed.

Regards,
Tim

Andrew Zhang wrote:
> Hi Tim,
> 
> Please do not appy this patch. The test hangs sometimes after applying this
> patch.
> 
> I'll take a deep look at the test, and suggest exclude the test at first.
> 
> Thanks!
> 
> 
> On 6/27/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>>
>>  Hi Tim,
>>
>> I took a look at the test, and found there are some problems in the test.
>>
>> The test looks like:
>> while(true){
>> count = read();
>> if(count <= 0){ // Error! For nonblocking read, returns 0 means non data
>> available currently
>> break;
>> }
>> }
>>
>> For nonblocking read, I think "count <= 0" is not the rigth condition to
>> break out. "count < 0" should be used instead. What's your opnion? I'm
>> not
>> very sure whether my patch could fix the problem thoroughly because my
>> netwrok is so good that the test never fails even with "count <= 0".
>> Thanks!
>> Here's the patch for this problem: (or shall I raise a separated JIRA ? )
>>
>> Index:
>> src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
>>
>> ===
>> ---
>> src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
>> (revision
>> 417326)
>> +++
>> src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
>> (working
>> copy)
>> @@ -2490,7 +2490,7 @@
>>  int total = 0;
>>  while (total < CAPACITY_64KB) {
>>  count = this.channel1.read(buf);
>> -if (count <= 0){
>> +if (count < 0){
>>  break;
>>  }
>>  total = total + count;
>> @@ -2509,13 +2509,13 @@
>>  count = in.read(serverRBuf);
>>  while (total < CAPACITY_64KB + 1) {
>>  count = this.channel1.read(buf);
>> -if (count <= 0){
>> +if (count < 0){
>>  break;
>>  }
>>  total = total + count;
>>  }
>>  if (total > 0) {
>> -assertEquals(total, CAPACITY_64KB);
>> +assertEquals(CAPACITY_64KB, total);
>>  for (int i = 0; i < count; i++) {
>>  assertEquals((byte) i, serverRBuf[i]);
>>  }
>>
>>
>>  On 6/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> >
>> > Apache Harmony Build wrote:
>> > > Online report :
>> >
>> http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1435
>>
>> > > Build statistics:
>> > >   State: Failed
>> > >   Previous State: Ok
>> > >   Started at: Mon, 26 Jun 2006 16:09:03 +0100
>> > >   Finished at: Mon, 26 Jun 2006 16:22:52 +0100
>> > >   Total time: 13m 48s
>> > >   Build Trigger: Schedule
>> > >   Exit code: 1
>> > >   Building machine hostname: hy1
>> > >   Operating system : Windows XP(Service Pack 2)
>> > >   Java version : 1.5.0_06(Sun Microsystems Inc.)
>> >
>> > 
>> >
>> > >  [exec] [junit] T2 not closed
>> > >  [exec] [junit] T1 not closed
>> > >  [exec] [junit] Read fail in capacity64KB,
>> > testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData not finish.
>> > >  [exec] [junit] Tests run: 80, Failures: 1, Errors: 0, Time
>> > elapsed: 15.491 sec
>> > >  [exec] [junit] TEST
>> > org.apache.harmony.tests.java.nio.channels.SocketChannelTest FAILED
>> > >  [exec] [junit] Tests run: 14, Failures: 0, Errors: 0, Time
>> > elapsed: 0.313 sec
>> > >  [exec] [junit] Tests run: 3, Failures: 0, Errors: 0, Time
>> > elapsed: 0 sec
>> > >  [exec] [junit] Tests run: 9, Failures: 0, Errors: 0, Time
>> > elapsed: 0.126 sec
>> > >  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time
>> > elapsed: 0.016 sec
>> > >  [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time
>> > elapsed: 0.094 sec
>> > >  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time
>> > elapsed: 0.016 sec
>> > >  [exec] [junit] Tests FAILED
>> >
>> >
>> > This test seems to be frequently, if intermittently, failing.
>> >
>> > expected:<7300> but was:<65536>
>> >
>> > junit.framework.AssertionFailedError: expected:<7300> but
>> was:<65536> at
>> >
>> >
>> org.apache.harmony.tests.java.nio.channels.SocketChannelTest.testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData(
>>
>> > SocketChannelTest.java:2518)
>> > at
>> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>> >
>> >
>> >
>> > 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: j.u.Formatter test problems on RI

[Geir Magnusson Jr]

could you add [classlib] in the future ? :)

geir


Tim Ellison wrote:
> Richard is probably best placed to answer that question (so I've changed
> the subject to attract his attention ;-) )
> 
> Regards,
> Tim
> 
> Nathan Beyer wrote:
>> Here are the particular failures that I'm seeing. Some seem like minor
>> things like exception discrepancies, but others like this unexpected
>> exception "java.util.IllegalFormatFlagsException: Flags = '+'" seem like
>> flaws.
>>
>> BTW: if you search for "test_", it will land on the failed test methods.
>>
>> TESTROOT
>> tests.api.java.util.FormatterTest
>> test_ConstructorLjava_lang_Appendable(tests.api.java.util.FormatterTest)
>> java.util.FormatterClosedException
>>  at java.util.Formatter.ensureOpen(Formatter.java:2315)
>>  at java.util.Formatter.out(Formatter.java:2226)
>>  at
>> tests.api.java.util.FormatterTest.test_ConstructorLjava_lang_Appendable(Form
>> atterTest.java:183)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
>> )
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
>> .java:25)
>>  at java.lang.reflect.Method.invoke(Method.java:585)
>>  at junit.framework.TestCase.runTest(TestCase.java:154)
>>  at junit.framework.TestCase.runBare(TestCase.java:127)
>>  at junit.framework.TestResult$1.protect(TestResult.java:106)
>>  at junit.framework.TestResult.runProtected(TestResult.java:124)
>>  at junit.framework.TestResult.run(TestResult.java:109)
>>  at junit.framework.TestCase.run(TestCase.java:118)
>>  at junit.framework.TestSuite.runTest(TestSuite.java:208)
>>  at junit.framework.TestSuite.run(TestSuite.java:203)
>>  at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
>> estReference.java:128)
>>  at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
>> 8)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
>> nner.java:460)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
>> nner.java:673)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
>> java:386)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
>> .java:196)
>>
>> test_ConstructorLjava_io_FileLjava_lang_String(tests.api.java.util.Formatter
>> Test)
>> junit.framework.AssertionFailedError
>>  at junit.framework.Assert.fail(Assert.java:47)
>>  at junit.framework.Assert.assertTrue(Assert.java:20)
>>  at junit.framework.Assert.assertTrue(Assert.java:27)
>>  at
>> tests.api.java.util.FormatterTest.test_ConstructorLjava_io_FileLjava_lang_St
>> ring(FormatterTest.java:465)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
>> )
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
>> .java:25)
>>  at java.lang.reflect.Method.invoke(Method.java:585)
>>  at junit.framework.TestCase.runTest(TestCase.java:154)
>>  at junit.framework.TestCase.runBare(TestCase.java:127)
>>  at junit.framework.TestResult$1.protect(TestResult.java:106)
>>  at junit.framework.TestResult.runProtected(TestResult.java:124)
>>  at junit.framework.TestResult.run(TestResult.java:109)
>>  at junit.framework.TestCase.run(TestCase.java:118)
>>  at junit.framework.TestSuite.runTest(TestSuite.java:208)
>>  at junit.framework.TestSuite.run(TestSuite.java:203)
>>  at
>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
>> estReference.java:128)
>>  at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
>> 8)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
>> nner.java:460)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
>> nner.java:673)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
>> java:386)
>>  at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
>> .java:196)
>>
>> test_formatLjava_lang_String$Ljava_lang_Object_Percent(tests.api.java.util.F
>> ormatterTest)
>> java.util.IllegalFormatFlagsException: Flags = '+'
>>  at
>> java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2939)
>>  at java.util.Formatter$FormatSpecifier.(Formatter.java:2644)
>>  at java.util.Formatter.parse(Formatter.java:2477)
>>  at java.util.Formatter.format(Formatter.java:2411)
>>  at java.util.Formatter.format(Formatter.java:2364)
>>  at
>> tests.api.java.util.FormatterTest.test_formatLjava_lang_String$Ljava_lang_Ob
>> ject_Percent(FormatterTest.java:1069)
>>  at sun.reflect.NativeMethod

Re: [classlib] mem

[Geir Magnusson Jr]

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>> This function is (deliberately) not exported from the hyprt.dll so you
>>> cannot call it directly.  You have to call it via the function pointer
>>> table ...
>> That's the missing element - it's not exported.
> 
> The idea is that code should always go via the function table so that
> your caller can control your use of these functions.

Yes - exactly.  That makes perfect sense to me.

> 
>>> Of course, you can reference that member directly if you so choose, and
>>> as written elsewhere if you are dealing with multiple tables the
>>> syntactic sugar doesn't help and you must reference it in full.
>> When would you have multiple tables?
> 
> Very rarely (Jimmy brought it up, so maybe he has an example).  It would
> be more common to modify the table before you pass it on, to include a
> function that has more debug info (like the callsite version we saw
> earlier), or allocates from a given memory pool, or limits the amount of
> resource you can have, runs on a certain processor, etc. etc.
> 
>>> I guess that the confusion is caused by the HyPortLib struct containing
>>> a member called 'mem_allocate_memory' that has the address of a function
>>> called 'hymem_allocate_memory'?
>> really it was having a macro and a function named the same, differing
>> only by a number of arguments where the macro expanded out to what has
>> the potential of being something very different than the function
>> because of the function table.  It wasn't obvious that the function
>> wasn't exported (of course).
> 
> Right.  As you see, the macro names follow a convention that matches the
> default table value function name -- once you are comfortable with that
> programming using the macros is not much different to programming direct
> to the function itself (modulo first portlib arg).

I don't mind the macros, I just think the actual function should be
named something different than the macro and have some docs to stem
confusion from other readers in the future.

Yea/nea?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][testing] excluding the failed tests

[Tim Ellison]

There was a submission that enabled finer control of failing tests (even
by platform etc.)

I may be wrong but commenting out tests usually means that they never
get fixed; even putting them into exclude clauses in the ant script is
too hidden for me -- I prefer to see the exclusions and failures made
available very clearly.

Regards,
Tim

Alexei Zakharov wrote:
> Hi,
> +1 for (3), but I think it will be better to define suite() method and
> enumerate passing tests there rather than to comment out the code.
> 
> 2006/6/27, Richard Liang <[EMAIL PROTECTED]>:
>> Hello Vladimir,
>>
>> +1 to option 3) . We shall comment the failed test cases out and add
>> FIXME to remind us to diagnose the problems later. ;-)
>>
>> Vladimir Ivanov wrote:
>> > I see your point.
>> > But I feel that we can miss regression in non-tested code if we exclude
>> > TestCases.
>> > Now, for example we miss testing of
>> java.lang.Class/Process/Thread/String
>> > and some other classes.
>> >
>> > While we have failing tests and don't want to pay attention to these
>> > failures we can:
>> > 1) Leave things as is – do not run TestCases with failing tests.
>> > 2) Split passing/failing TestCase into separate "failing TestCase" and
>> > "passing TestCase" and exclude "failing TestCases". When test or
>> > implementation is fixed we move tests from failing TestCase to passing
>> > TestCase.
>> > 3) Comment failing tests in TestCases. It is better to run 58 tests
>> > instead
>> > of 0 for String.
>> > 4) Run all TestCases, then, compare test run results with the 'list of
>> > known
>> > failures' and see whether new failures appeared. This, I think, is
>> better
>> > then 1, 2 and 3, but, overhead is that we support 2 lists - list of
>> known
>> > failing tests and exclude list where we put crashing tests.
>> >
>> > Thanks, Vladimir
>> > On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Mikhail Loenko wrote:
>> >> > Hi Vladimir,
>> >> >
>> >> > IMHO the tests are to verify that an update does not introduce any
>> >> > regression. So there are two options: remember which exactly
>> tests may
>> >> fail
>> >> > and remember that all tests must pass. I believe the latter one is
>> >> a bit
>> >> > easier and safer.
>> >>
>> >> +1
>> >>
>> >> Tim
>> >>
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >> > 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> >> >> Hi,
>> >> >> Working with tests I noticed that we are excluding some tests just
>> >> >> because
>> >> >> several tests from single TestCase fail.
>> >> >>
>> >> >> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>> >> >> tests and
>> >> >> only 2 of them fails. But the build excludes the whole TestCase
>> >> and we
>> >> >> just
>> >> >> miss testing of java.lang.String implementation.
>> >> >>
>> >> >> Do we really need to exclude TestCases in 'ant test' target?
>> >> >>
>> >> >> My suggestion is: do not exclude any tests until it crashes VM.
>> >> >> If somebody needs a list of tests that always passed a separated
>> >> >> target can
>> >> >> be added to build.
>> >> >>
>> >> >> Do you think we should add target 'test-all' to the build?
>> >> >>  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]
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >> 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]
>> >>
>> >>
>> >
>>
>> -- 
>> Richard Liang
>> China Software Development Lab, IBM
> 
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] build fails on Windows os

[Geir Magnusson Jr]

Yah, I was running a full clean rebuild including the downloads and fell
asleep.

I'll check in now and reverse marks reversal.

geir


Mark Hindess wrote:
> On 27 June 2006 at 15:09, "Vladimir Gorr" <[EMAIL PROTECTED]> wrote:
>> On 6/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>>> On 27 June 2006 at 9:48, "Marina Goldburt" <[EMAIL PROTECTED]>
>>> wrote:
 On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> Odd.  It was broken for me too.  What changed?
>
> I applied the patch - thanks.
  I think, the problem is in the log4cxx revision -
 the old log4cxx didn't use the aprutil xml API.
>>> Ah ... this problem would be from my change as discussed in the recent
>>> "[DRLVM] building from svn on FC5" thread where I wrote:
>>>
>>> I've fixed (in r416807) the revisions for log4cxx on linux and windows
>>> to use r416779.  Works for me on Linux.  Can some test on windows and
>>> report if this causes any regression?
>>>
>>> Obviously it did cause a regression on windows but the new version is
>>> needed on Linux to get the build to work.
>>>
>>> I've backed out the windows part of this change in r417350.  Can someone
>>> check that this fixes the problem on windows?
>>
>> Mark,
>>
>>
>> yes, the problem disappeared on Windows after your change.
>>
>> Although, I don't understand why should we use the different revisions of
>> LOG4CXX on Windows and Linux?
> 
> Ideally they should be running the same version if it works.
> 
>> If the patch mentioned by Marina is accepted then the problem also
>> disappears.
> 
> Good.  I wanted to backout the change until Geir applied the fix.  IIRC,
> he said in his note that he had but he's not checked it in yet.  I
> wasn't comfortable leaving it broken.  We can Linux and Windows back in
> sync when Geir has applied Marina's fix.
> 
> -Mark.
> 
> 
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]

[Alexander Kleymenov]

Hello,


Paulex Yang wrote:

IIRC, Archie's suggest #3 is about select interruption, so what's your
suggestion to implement the blocking I/O interruption?


Use non-blocking calls instead of blocking ones. There are some approaches
to implement non-blocking I/O over the blocking (in the native code of course).
Although there can appear some cases where it will be impossible to do.


And even another time, I think maybe I need to emphasize again that the
AbstractInterruptibleChannel/AbstractSelector must encapsulate the
machinery about the interruption, so that it is easy for Harmony user to
create its own interruptible channel.


Agree! Moreover, AbstractInterruptibleChannel/AbstractSelector is only
place for it.


I doubt that just calling of this methods will made blocking
operations interruptable. I.e. we should have interruption support in
[interruptable] blocking operation anyway.


I think what Andrew said come from Java spec? Why you think the proposal
cannot work?


I do not think it cannot work. It's fine solution and it will do all
the necessary work!
But it needs changes in VMI spec and I tried to discuss approach which does
not need such changes.


Andrew Zhang wrote:


Sorry if I missed something.


Any better solution is highly appreicated, Thanks!


I can propose another way: begin() method creates new thread listening
for Thread.curentThread().isInterrupted() status and if it becomes
true, it just calls close() method, triggers the state of the channel
as ClosedByInterruptException, and exits. The end() method just stops
this additional thread (if it was not stopped after the blocked Thread
had been interrupted) and, if necessary, throws appropriate exception.

No VMI changes are needed, but there will be additional thread between
begin() - end() calls. This thread will sleep between isInterrupted() checks
and will not take much computational resources.


Thank You,
Alexander

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

j.u.Formatter test problems on RI (was: Re: svn commit: r417148 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/util/Formatter.java test/java/tests/api/java/util/Forma

[Tim Ellison]

Richard is probably best placed to answer that question (so I've changed
the subject to attract his attention ;-) )

Regards,
Tim

Nathan Beyer wrote:
> Here are the particular failures that I'm seeing. Some seem like minor
> things like exception discrepancies, but others like this unexpected
> exception "java.util.IllegalFormatFlagsException: Flags = '+'" seem like
> flaws.
> 
> BTW: if you search for "test_", it will land on the failed test methods.
> 
> TESTROOT
> tests.api.java.util.FormatterTest
> test_ConstructorLjava_lang_Appendable(tests.api.java.util.FormatterTest)
> java.util.FormatterClosedException
>   at java.util.Formatter.ensureOpen(Formatter.java:2315)
>   at java.util.Formatter.out(Formatter.java:2226)
>   at
> tests.api.java.util.FormatterTest.test_ConstructorLjava_lang_Appendable(Form
> atterTest.java:183)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at junit.framework.TestCase.runTest(TestCase.java:154)
>   at junit.framework.TestCase.runBare(TestCase.java:127)
>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>   at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>   at junit.framework.TestSuite.runTest(TestSuite.java:208)
>   at junit.framework.TestSuite.run(TestSuite.java:203)
>   at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
> estReference.java:128)
>   at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
> 8)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
> nner.java:460)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
> nner.java:673)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
> java:386)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
> .java:196)
> 
> test_ConstructorLjava_io_FileLjava_lang_String(tests.api.java.util.Formatter
> Test)
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:47)
>   at junit.framework.Assert.assertTrue(Assert.java:20)
>   at junit.framework.Assert.assertTrue(Assert.java:27)
>   at
> tests.api.java.util.FormatterTest.test_ConstructorLjava_io_FileLjava_lang_St
> ring(FormatterTest.java:465)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at junit.framework.TestCase.runTest(TestCase.java:154)
>   at junit.framework.TestCase.runBare(TestCase.java:127)
>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>   at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>   at junit.framework.TestSuite.runTest(TestSuite.java:208)
>   at junit.framework.TestSuite.run(TestSuite.java:203)
>   at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
> estReference.java:128)
>   at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
> 8)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
> nner.java:460)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
> nner.java:673)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
> java:386)
>   at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
> .java:196)
> 
> test_formatLjava_lang_String$Ljava_lang_Object_Percent(tests.api.java.util.F
> ormatterTest)
> java.util.IllegalFormatFlagsException: Flags = '+'
>   at
> java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2939)
>   at java.util.Formatter$FormatSpecifier.(Formatter.java:2644)
>   at java.util.Formatter.parse(Formatter.java:2477)
>   at java.util.Formatter.format(Formatter.java:2411)
>   at java.util.Formatter.format(Formatter.java:2364)
>   at
> tests.api.java.util.FormatterTest.test_formatLjava_lang_String$Ljava_lang_Ob
> ject_Percent(FormatterTest.java:1069)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>   a

Re: [drlvm] build fails on Windows os

[Geir Magnusson Jr]

Rana Dasgupta wrote:
> On 6/26/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>>
>> >Odd.  It was broken for me too.  What changed?
>>
>> >I applied the patch - thanks.
> 
> 
> To determine this, one would have to roll back the last commit and retry
> the build + smoke tests. And  traverse back till we identify what broke it.
> We could also consider requesting the patches that came after this to be
> resubmitted. At least.

That would be the long way.  The short way would be just to look at the
svn log and make an educated guess.

> It may help to start putting in some submission citeria for patches eg., a
> successful log from the existing drlvm smoke tests etc. Patches, though not
> big, are coming in quite rapidly and it can't be easy for committers to
> verify everything on two target platforms.

That has been our criteria - make sure the tests pass on both platforms.

> Also, the existing few smoke tests will not catch all bugs. At some point,
> new tests should accompany non trivial submissions. We don't want to get
> into a situation where we have a serious breakage.

We ask that every patch we get be accompanied by a testcase, but that
isn't always possible.

>  It will be good to know how we are doing the corresponding stuff in the
> classlibs.
> 

-
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] milestones and roadmap

[Tim Ellison]

Always a good way to flush em out ;-)

Tim

Geir Magnusson Jr wrote:
> There was another. :)  I'll summarize tomorrow.
> 
> geir
> 
> Tim Ellison wrote:
>> Looks like the ideas dried up.  Are you going to track and organize?  Do
>> you want help?
>>
>> Regards,
>> Tim
>>
>> Geir Magnusson Jr wrote:
>>> I'd like to start assembling a high-level roadmap of the milestones we'd
>>> like to achieve in the next 12 months.
>>>
>>> I volunteer to track and organize, but this clearly is a community
>>> activity so lets start by just tossing out ideas.
>>>
>>> 1) By ApcheCon EU - a combined snapshot that is a pure open source VM +
>>> classlib.  Issues - I assume we'll use DRLVM.
>>>
>>> 2) Integration of Doug Lea's java.util.concurrency package.  Issues -
>>> right now, Nathan is looking at it, and we'll need support from the
>>> various VMs.
>>>
>>> 3) Build framework - I'm hoping Mark/IBM is able to get us booted on
>>> this via a contribution to /testing that makes it easy for people to do
>>> the same CI runs that he's doing
>>>
>>> 4) Incorporate the Java SE TCK into build framework.  This requires a
>>> few things, first the build framework and people interested in working
>>> on that, and second, the Java SE TCK.  I'm working on the latter in my
>>> role as the ASFs JCP rep, and I'm guessing this will take a while.
>>>
>>> 5) Switch to Java 5 - in both classlib and our VMs
>>>
>>> 6) CORBA - start looking at Yoko to see what we can reuse for Harmony,
>>> and start integrating that.
>>>
>>> 7) Test coverage - should we think about targets for test coverage ?
>>>
>>> 8) Package completion roadmap
>>>
>>> 9) JMX - right now, I believe mark has finished integrating MX4J, but we
>>> need to start enhancing that with Java 5 features.
>>>
>>> What else? :)
>>>
>>> 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]
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] build fails on Windows os

[Mark Hindess]

On 27 June 2006 at 15:09, "Vladimir Gorr" <[EMAIL PROTECTED]> wrote:
>
> On 6/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> >
> > On 27 June 2006 at 9:48, "Marina Goldburt" <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Odd.  It was broken for me too.  What changed?
> > > >
> > > > I applied the patch - thanks.
> > >
> > >  I think, the problem is in the log4cxx revision -
> > > the old log4cxx didn't use the aprutil xml API.
> >
> > Ah ... this problem would be from my change as discussed in the recent
> > "[DRLVM] building from svn on FC5" thread where I wrote:
> >
> > I've fixed (in r416807) the revisions for log4cxx on linux and windows
> > to use r416779.  Works for me on Linux.  Can some test on windows and
> > report if this causes any regression?
> >
> > Obviously it did cause a regression on windows but the new version is
> > needed on Linux to get the build to work.
> >
> > I've backed out the windows part of this change in r417350.  Can someone
> > check that this fixes the problem on windows?
> 
> 
> Mark,
> 
> 
> yes, the problem disappeared on Windows after your change.
> 
> Although, I don't understand why should we use the different revisions of
> LOG4CXX on Windows and Linux?

Ideally they should be running the same version if it works.

> If the patch mentioned by Marina is accepted then the problem also
> disappears.

Good.  I wanted to backout the change until Geir applied the fix.  IIRC,
he said in his note that he had but he's not checked it in yet.  I
wasn't comfortable leaving it broken.  We can Linux and Windows back in
sync when Geir has applied Marina's fix.

-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][testing] excluding the failed tests

[Alexei Zakharov]

Hi,
+1 for (3), but I think it will be better to define suite() method and
enumerate passing tests there rather than to comment out the code.

2006/6/27, Richard Liang <[EMAIL PROTECTED]>:

Hello Vladimir,

+1 to option 3) . We shall comment the failed test cases out and add
FIXME to remind us to diagnose the problems later. ;-)

Vladimir Ivanov wrote:
> I see your point.
> But I feel that we can miss regression in non-tested code if we exclude
> TestCases.
> Now, for example we miss testing of java.lang.Class/Process/Thread/String
> and some other classes.
>
> While we have failing tests and don't want to pay attention to these
> failures we can:
> 1) Leave things as is – do not run TestCases with failing tests.
> 2) Split passing/failing TestCase into separate "failing TestCase" and
> "passing TestCase" and exclude "failing TestCases". When test or
> implementation is fixed we move tests from failing TestCase to passing
> TestCase.
> 3) Comment failing tests in TestCases. It is better to run 58 tests
> instead
> of 0 for String.
> 4) Run all TestCases, then, compare test run results with the 'list of
> known
> failures' and see whether new failures appeared. This, I think, is better
> then 1, 2 and 3, but, overhead is that we support 2 lists - list of known
> failing tests and exclude list where we put crashing tests.
>
> Thanks, Vladimir
> On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>
>> Mikhail Loenko wrote:
>> > Hi Vladimir,
>> >
>> > IMHO the tests are to verify that an update does not introduce any
>> > regression. So there are two options: remember which exactly tests may
>> fail
>> > and remember that all tests must pass. I believe the latter one is
>> a bit
>> > easier and safer.
>>
>> +1
>>
>> Tim
>>
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> >> Hi,
>> >> Working with tests I noticed that we are excluding some tests just
>> >> because
>> >> several tests from single TestCase fail.
>> >>
>> >> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>> >> tests and
>> >> only 2 of them fails. But the build excludes the whole TestCase
>> and we
>> >> just
>> >> miss testing of java.lang.String implementation.
>> >>
>> >> Do we really need to exclude TestCases in 'ant test' target?
>> >>
>> >> My suggestion is: do not exclude any tests until it crashes VM.
>> >> If somebody needs a list of tests that always passed a separated
>> >> target can
>> >> be added to build.
>> >>
>> >> Do you think we should add target 'test-all' to the build?
>> >>  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]
>> >
>> >
>>
>> --
>>
>> 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]
>>
>>
>

--
Richard Liang
China Software Development Lab, IBM




--
Alexei Zakharov,
Intel Middleware Product Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] build fails on Windows os

[Vladimir Gorr]

On 6/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:



On 27 June 2006 at 9:48, "Marina Goldburt" <[EMAIL PROTECTED]>
wrote:
>
> On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >
> > Odd.  It was broken for me too.  What changed?
> >
> > I applied the patch - thanks.
>
>  I think, the problem is in the log4cxx revision -
> the old log4cxx didn't use the aprutil xml API.

Ah ... this problem would be from my change as discussed in the recent
"[DRLVM] building from svn on FC5" thread where I wrote:

I've fixed (in r416807) the revisions for log4cxx on linux and windows
to use r416779.  Works for me on Linux.  Can some test on windows and
report if this causes any regression?

Obviously it did cause a regression on windows but the new version is
needed on Linux to get the build to work.

I've backed out the windows part of this change in r417350.  Can someone
check that this fixes the problem on windows?



Mark,


yes, the problem disappeared on Windows after your change.

Although, I don't understand why should we use the different revisions of
LOG4CXX on Windows and Linux?

If the patch mentioned by Marina is accepted then the problem also
disappears.

I'd like to hear your opinion.



Thanks,

Vladimir.

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: [general] milestones and roadmap

[Andrey Chernyshev]

20. Modularity (?).  Perhaps it may make sense (at least for DRLVM) to
refine and document the internal interfaces and API such that one can
easily substitute the different parts of VM (e.g. GC, JIT, possibly
some other parts).


Thanks,
Andrey.


On 6/27/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:

19. Performance improvement. Optimize class libraries and VM. There
was some tips how to do better java code. Performance critical places
can be revised and reimplemented more efficiently.

--
Ivan

On 6/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Looks like the ideas dried up.  Are you going to track and organize?  Do
> you want help?
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
> > I'd like to start assembling a high-level roadmap of the milestones we'd
> > like to achieve in the next 12 months.
> >
> > I volunteer to track and organize, but this clearly is a community
> > activity so lets start by just tossing out ideas.
> >
> > 1) By ApcheCon EU - a combined snapshot that is a pure open source VM +
> > classlib.  Issues - I assume we'll use DRLVM.
> >
> > 2) Integration of Doug Lea's java.util.concurrency package.  Issues -
> > right now, Nathan is looking at it, and we'll need support from the
> > various VMs.
> >
> > 3) Build framework - I'm hoping Mark/IBM is able to get us booted on
> > this via a contribution to /testing that makes it easy for people to do
> > the same CI runs that he's doing
> >
> > 4) Incorporate the Java SE TCK into build framework.  This requires a
> > few things, first the build framework and people interested in working
> > on that, and second, the Java SE TCK.  I'm working on the latter in my
> > role as the ASFs JCP rep, and I'm guessing this will take a while.
> >
> > 5) Switch to Java 5 - in both classlib and our VMs
> >
> > 6) CORBA - start looking at Yoko to see what we can reuse for Harmony,
> > and start integrating that.
> >
> > 7) Test coverage - should we think about targets for test coverage ?
> >
> > 8) Package completion roadmap
> >
> > 9) JMX - right now, I believe mark has finished integrating MX4J, but we
> > need to start enhancing that with Java 5 features.
> >
> > What else? :)

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Andrey Chernyshev
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: [classlib] mem

[Tim Ellison]

Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> This function is (deliberately) not exported from the hyprt.dll so you
>> cannot call it directly.  You have to call it via the function pointer
>> table ...
> 
> That's the missing element - it's not exported.

The idea is that code should always go via the function table so that
your caller can control your use of these functions.

>> Of course, you can reference that member directly if you so choose, and
>> as written elsewhere if you are dealing with multiple tables the
>> syntactic sugar doesn't help and you must reference it in full.
> 
> When would you have multiple tables?

Very rarely (Jimmy brought it up, so maybe he has an example).  It would
be more common to modify the table before you pass it on, to include a
function that has more debug info (like the callsite version we saw
earlier), or allocates from a given memory pool, or limits the amount of
resource you can have, runs on a certain processor, etc. etc.

>> I guess that the confusion is caused by the HyPortLib struct containing
>> a member called 'mem_allocate_memory' that has the address of a function
>> called 'hymem_allocate_memory'?
> 
> really it was having a macro and a function named the same, differing
> only by a number of arguments where the macro expanded out to what has
> the potential of being something very different than the function
> because of the function table.  It wasn't obvious that the function
> wasn't exported (of course).

Right.  As you see, the macro names follow a convention that matches the
default table value function name -- once you are comfortable with that
programming using the macros is not much different to programming direct
to the function itself (modulo first portlib arg).

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] build fails on Windows os

[Tim Ellison]

Rana Dasgupta wrote:
> On 6/26/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>>
>> >Odd.  It was broken for me too.  What changed?
>>
>> >I applied the patch - thanks.
> 
> 
> To determine this, one would have to roll back the last commit and retry
> the build + smoke tests. And  traverse back till we identify what broke it.
> We could also consider requesting the patches that came after this to be
> resubmitted. At least.
> It may help to start putting in some submission citeria for patches eg., a
> successful log from the existing drlvm smoke tests etc. Patches, though not
> big, are coming in quite rapidly and it can't be easy for committers to
> verify everything on two target platforms.
> Also, the existing few smoke tests will not catch all bugs. At some point,
> new tests should accompany non trivial submissions. We don't want to get
> into a situation where we have a serious breakage.
>  It will be good to know how we are doing the corresponding stuff in the
> classlibs.

The short answer is: by relying on the test suite.  I agree that the
first goal is to reach a stable state, then ensure that patches come
with new tests maintaining the stable state.

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] build fails on Windows os

[Mark Hindess]

On 27 June 2006 at 9:48, "Marina Goldburt" <[EMAIL PROTECTED]> wrote:
> 
> On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >
> > Odd.  It was broken for me too.  What changed?
> >
> > I applied the patch - thanks.
>
>  I think, the problem is in the log4cxx revision -
> the old log4cxx didn't use the aprutil xml API.

Ah ... this problem would be from my change as discussed in the recent
"[DRLVM] building from svn on FC5" thread where I wrote:

  I've fixed (in r416807) the revisions for log4cxx on linux and windows
  to use r416779.  Works for me on Linux.  Can some test on windows and
  report if this causes any regression?

Obviously it did cause a regression on windows but the new version is
needed on Linux to get the build to work.

I've backed out the windows part of this change in r417350.  Can someone
check that this fixes the problem on windows?

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: svn commit: r417148 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/util/Formatter.java test/java/tests/api/java/util/FormatterTest.java

[Nathan Beyer]

Here are the particular failures that I'm seeing. Some seem like minor
things like exception discrepancies, but others like this unexpected
exception "java.util.IllegalFormatFlagsException: Flags = '+'" seem like
flaws.

BTW: if you search for "test_", it will land on the failed test methods.

TESTROOT
tests.api.java.util.FormatterTest
test_ConstructorLjava_lang_Appendable(tests.api.java.util.FormatterTest)
java.util.FormatterClosedException
at java.util.Formatter.ensureOpen(Formatter.java:2315)
at java.util.Formatter.out(Formatter.java:2226)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_lang_Appendable(Form
atterTest.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)

test_ConstructorLjava_io_FileLjava_lang_String(tests.api.java.util.Formatter
Test)
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_io_FileLjava_lang_St
ring(FormatterTest.java:465)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)

test_formatLjava_lang_String$Ljava_lang_Object_Percent(tests.api.java.util.F
ormatterTest)
java.util.IllegalFormatFlagsException: Flags = '+'
at
java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2939)
at java.util.Formatter$FormatSpecifier.(Formatter.java:2644)
at java.util.Formatter.parse(Formatter.java:2477)
at java.util.Formatter.format(Formatter.java:2411)
at java.util.Formatter.format(Formatter.java:2364)
at
tests.api.java.util.FormatterTest.test_formatLjava_lang_String$Ljava_lang_Ob
ject_Percent(FormatterTest.java:1069)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:1