Re: [classlib][auth]LoginContext should always invoke the LoginModules?

[Stepan Mishura]

On 10/14/06, Tim Ellison wrote:


Stepan Mishura wrote:
 So we have following suggestions:

 1) leave the check and document the difference with RI
 2) follow RI and put a warning

What warning did you have in mind?  And don't say j.u.logging 'cos I can
find out where you live you know :-)




I meant adding a warning to javadoc for login() method.

Thanks,
Stepan.

Regards,

Tim

 3) do LogingContext.logout() before the second login()
 4) introduce a system property to follow RI

 Should we vote?

 Thanks,
 Stepan.


 On 9/29/06, Paulex Yang wrote:

 Hi, all

 I'm not a security expert, so please correct me if I miss something. I
 found some different behavior of Harmony and RI on
 javax.security.auth.login.LoginContext, the testcase[1] shows the
 difference.

 Actually I tried to create the event sequence like below:
 1. create LoginContext with some Subject
 2. LoginContext.login() and return successfully
 3. Modify Subject's content to make it invalid(one Principal's name
 here, maybe passwd/username/servername in more general case)
 4. LoginContext.login() again

 In RI, the second login() invocation really tried to invoke the
relative
 LoginModule.login() and then failed to login with the modified Subject,
 but in Harmony, both invocations succeed. I consider RI's behavior is
 more reasonable.

 After a rough look of LoginContext implementation, I found the cause
may
 be the Ln. 275

private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}

}

 Seems Harmony won't invoke the LoginModule.login() again only if the
 login ever succeeds. If I comment out these lines, the test below
passes
 happily. Any ideas on this issue?


 [1]
 public class LoginContextTest extends TestCase {
private static final String VALID_NAME = name1;
private static final String INVALID_NAME = name2;

public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new
 HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext(moduleName, sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail(Should throw LoginException);
}catch(LoginException e){

}
}
static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
 AppConfigurationEntry[]{new
 AppConfigurationEntry(MyModule.class.getName(),
 LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
 name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
 MapString, ? arg2, MapString, ? arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
 Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
 }



 --
 Paulex Yang
 China Software Development Lab
 IBM


--

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





--
Stepan Mishura
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][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Egor Pasko]

On the 0x202 day of Apache Harmony Geir Magnusson, Jr. wrote:
 Egor Pasko wrote:
  Harmoniers,
  Thanks to Mikhail Fursov, George Timoshenko, Nikolay Sidelnikov (and
  me, of course:) all critical bugs (as in [1]) in Jitrino.OPT have
  their fixing patches and I like them. I think, it is a good step
  forward to enabling the self-hosting environment.
  Here are the champions:
  + HARMONY-1774 (fixes also HARMONY-1773,  HARMONY-1775)
 
 Applied.  IMO, doesn't fix 1775

Greater thanks, Geir! I should have checked this. Today I observe the
same. RCE=off passes the test as in older times. I'll take a look.

  + HARMONY-1802 (no more crash in HARMONY-1688, but a hang:)
 
 Applied. 1688 still crashes for me

I have no crash, only ... printed and a CPU-eating infinite loop

  + HARMONY-1796
 
 Applied.
 
  + HARMONY-1781
 
 Applied
 
  + HARMONY-1682 (fixes also HARMONY-1695)
 
 Applied
 
  I tried them all: * Linux (SUSE 9, gcc-3.3.3)
+ Smoke, cunit, kernel. And only the ThreadTest failed, which is
  normal :)
  * windows
+ cunit OK, kernel tests fail with Process fork failed, which is
  my configuration problem. BTW, anybody seen this?
  [1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
 
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 

-- 
Egor Pasko, Intel Managed Runtime Division


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

Re: [general] JIRA - port-platform categories for JIRA?

[Alexey Varlamov]

Both ways make sense to me, tagging for ease of primary filtering
emails/JIRAs etc, and explicit component for advanced search in JIRA.
As for the name, I don't care - port-XXX or platform-XXX...

2006/10/16, Geir Magnusson Jr. [EMAIL PROTECTED]:



Mikhail Fursov wrote:
 It looks like I really do not understand your proposal about JIRA naming.
 I do not know what category is. I see the list of independent components
 here: http://issues.apache.org/jira/browse/HARMONY

yes, that's it.

 and when I create a new issue I can choose only one of the components.

No, you can choose more than one. Try using shift-click or something.

 Do you mean that IPF could be a subcomponent of DRLVM?  The first
 subcomponent in the our JIRA? If yes I think it's a good solution and it is
 not mutually exclusive with the subject prefixes approach.

I didn't know JIRA could deal with subcomponents.  I still don't think
that would work, as we want really to be able to tag things, as both
DRLVM issues and classlib issues can be port specific...

geir


 On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 You missed my point, which was about the naming.

 Being able to use the category tags is much more foolproof than subject
 lines, since you can use more than one at a time, and it's cleanly
 organized...  you can look  at different combinations.

 Do you see what I mean?  In JIRA, we can then choose DRLVM and IPF
 at the same time, so you can look at all DRLVM issues, or just a subset,
 those for IPF, or all IPF issues, or just classlib issues for IPF, etc...

 geir

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





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




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

Re: [classlib][concurrent] Implementation of the CopyOnWriteArrayList class.

[Stepan Mishura]

On 10/13/06, Oleg Khaschansky wrote:

Could you, please, send the compiler output for these errors?


The output of eclipse compiler is quite big (over 1M). I've just extracted
some error messages:

   [javac] 292. ERROR in
C:\Apache\Harmony\ClassLib\modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java
   [javac]  (at line 32)
   [javac]  import java.util.concurrent.locks.ReentrantLock;
   [javac] ^^
   [javac] The import java.util.concurrent.locks cannot be resolved
   [javac] --
   [javac] 293. ERROR in
C:\Apache\Harmony\ClassLib\modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java
   [javac]  (at line 43)
   [javac]  private final transient ReentrantLock lock = new
ReentrantLock();
   [javac]  ^
   [javac] ReentrantLock cannot be resolved to a type
   [javac] --
   [javac] 294. ERROR in
C:\Apache\Harmony\ClassLib\modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java
   [javac]  (at line 43)
   [javac]  private final transient ReentrantLock lock = new
ReentrantLock();
   [javac]   ^
   [javac] ReentrantLock cannot be resolved to a type
   [javac] --

Thanks,
Stepan.




On 10/13/06, Stepan Mishura wrote:
 BTW, I stumbled over this class when I tried to build Classlib with
Harmony
 snapshot - it doesn't compile.

 I did the following:
 1) set JAVA_HOME=C:\Apache\Harmony\snapshot\harmony-hdk-r450941\jdk\jre
 2) ant -Dhy.javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter

 The build fails with compile errors. And if I revert Tim's commit back
 everything goes fine:
 $ svn up -r462578

modules/concurrent/src/main/java/java/util/concurrent/CopyOnWriteArrayList.java
 U

modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java
 Updated to revision 462578.

 Did anyone try this?

 Thanks,
 Stepan.


 On 10/10/06, Oleg Khaschansky wrote:
 
  I uploaded a patch which implements CopyOnWriteArrayList class.
  Committers, please, take a look at [1]. I also ensured that
  CopyOnWriteArrayListTest passes with this implementation.
 
  [1] http://issues.apache.org/jira/browse/HARMONY-1805
 



--
Stepan Mishura
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][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Alexey Varlamov]

[snip]

  + HARMONY-1802 (no more crash in HARMONY-1688, but a hang:)

 Applied. 1688 still crashes for me

I have no crash, only ... printed and a CPU-eating infinite loop


This is expected behaviour for now, waiting for classloading fix +
the test should be fixed, patch is available.

[snip]

--
Alexey

-
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] IPF functionality

[Alexey Varlamov]

2006/10/16, Mikhail Loenko [EMAIL PROTECTED]:

2006/10/14, Tim Ellison [EMAIL PROTECTED]:
 Just to add my 2p -- I also agree with doing the work in the trunk.  Of
 course the minimum cost of working there is that you do no harm to the
 other platforms.  That is the zeroth level of integration.

 The first level of integration would then be to modify the build system
 to build the IPF code, and of course it has to compile, know it's
 dependencies, etc. etc.

 Until the code can run some useful tests it is probably worth going on
 to run only a restricted set of the tests we have and then take on more.

 We can be bringing a number of new platforms on line simultaneously this
 way, with each potentially being at a different level of
 integration/maturity within the project.

When we bring new platforms how will we make sure that a patch for some
rare platform would not break another one?


Supposed we can charge CC on all supported platforms:

while (!passed.on.available platforms) {
  defer patch  discuss;
}
do commit;
if (some.platform.CC.failed) {
  rollback or fix ASAP;
}




Thanks,
Mikhail


 Regards,
 Tim

 Rana Dasgupta wrote:
  On 10/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 
 
  
This is just one more argument for doing IPF porting in a separate
   branch,
at least since some point.
   
I admit that maintaining quality and checking for regressions on new
platforms is a separate big problem but I believe we could try to
   avoid it
during incubation of new platforms.
   
Overall I agree we could wait with branch creation until real
  problems
appear.
   
  
   Great
 
 
  OK, we can then continue as is until the IPF port matures and is ready for
  running non trivial applications or performance tests. At that point we can
  decide whether to treat it as a primary platform, in which case, we will
  need to test on it before committing submissions to the main branch. Or
  secondary, in which case we branch it and let the IPF submitters control
  their own destiny.
 
  Thanks for the good comments.
 
  Rana
 
 
 
 
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --

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


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



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




-
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] HARMONY-1505 and HARMONY-1608 - cleanup of JNI function names

[Mark Hindess]

On 15 October 2006 at 18:40, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 Does anyone have an objection to those two JIRAs?

I don't.

-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] version of gcc and other tools

[Tim Ellison]

Geir Magnusson Jr. wrote:
 I suppose that as a temporary solution, we can just get people to drop
 ECJ into ant/lib...

Yes, that would be my preferred solution too, until Ant support comes along.

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: [general] define pre-commit testing configs to gain the stability

[Tim Ellison]

Ivan Volosyuk wrote:
 What an interesting discussion! I have just read this out. :)
 
 IMHO, all of the discussion is focused on the scalability of
 bazar-like development as it exists here in harmony incubator:
 
 If something wrong is commited, then everyone has broken build or
 something doesn't work. - This is bad. System is badly scalable. What
 can we do here?
 
 If build is broken, then the cause might be found by someone and
 posted on harmony-dev. - This is good. And it has good scalability :)

Exactly -- we don't expect committers to be infallible or have every
type of machine and OS version that we intend to 'support' (i.e. keep
running), so we cannot have a model that requires such extensive
pre-commit testing.  Of course, we therefore need full community
approval to declare some revision of code stable, but our bazaar-like
diversity is truly an asset.

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]

[classlib][luni]Runtime.exec fails on Linux

[Leo Li]

Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:

public class Exec {
   public static void main(String[] args) throws Exception {

  Runtime.getRuntime().exec(ls);}
}

   I have tried it on RedHat Enterprise 4 and Unbuntu, both get ENOMEM in
native code.

   After digging into it, I found it fails in procimpl.c, line 135:

   grdpid = fork ();

   If the call to fork is changed to vfork, the testcase will pass but
still get exitcode = 1 which indicates that some error has happened. The
difference between fork and vfork is just whether page tables is copied to
child process or not. But I do not think it is the main cause. Besides,
vfork has become outdated since it main usage is supplied by fork with
copy-on-write function implemented in modern linux kernel. Furthermore,
vfork is also not so safe as fork. So I do not think it is the accepted way
to solve the problem.

  I will try whether it can be reproduced on drlvm of linux since I am not
sure whether it is relevent to VM or classlib. If any drlvm man can tell me
the result, it can avoid my trouble to build it on linux. :)







--
Leo Li
China Software Development Lab, IBM

Re: [classlib][luni]Runtime.exec fails on Linux

[Alexey Varlamov]

Both DRLVM and J9 works for me (SUSE9).

--
Alexey

2006/10/16, Leo Li [EMAIL PROTECTED]:

Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:

public class Exec {
   public static void main(String[] args) throws Exception {

  Runtime.getRuntime().exec(ls);}
}

   I have tried it on RedHat Enterprise 4 and Unbuntu, both get ENOMEM in
native code.

   After digging into it, I found it fails in procimpl.c, line 135:

   grdpid = fork ();

   If the call to fork is changed to vfork, the testcase will pass but
still get exitcode = 1 which indicates that some error has happened. The
difference between fork and vfork is just whether page tables is copied to
child process or not. But I do not think it is the main cause. Besides,
vfork has become outdated since it main usage is supplied by fork with
copy-on-write function implemented in modern linux kernel. Furthermore,
vfork is also not so safe as fork. So I do not think it is the accepted way
to solve the problem.

  I will try whether it can be reproduced on drlvm of linux since I am not
sure whether it is relevent to VM or classlib. If any drlvm man can tell me
the result, it can avoid my trouble to build it on linux. :)







--
Leo Li
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: [general] version of gcc and other tools

[Konovalova, Svetlana]

Gier,

AFAIS work goes continually to test various combinations of environment
and tools, and because combinations that are stable today might get
broken tomorrow, we can keep this info on Wiki for easier editing. 
IMHO we can create a Wiki page, let's say SureToRunConfigurations and
add a link from Quick Help to this page. To begin with, we can use the
info from the harmony discussion to create the page. What do you think
about it?

Cheers,
Sveta Konovalova

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 10, 2006 8:11 PM
To: harmony-dev@incubator.apache.org
Subject: [general] version of gcc and other tools

I'm so sick of this gcc problem.

Lets decide on the versions for GCC and other tools that will work.  I

feel the same way that mark does re that being able to build on multiple

versions gives a better feeling of goodness and harmony in the universe 
and I encourage people to work on other versions (I will), but it's 
gotta be the case that we have a reference toolchain - that no matter 
what, it will work on there, and probably a list of tested versions

So, what tools and what versions are people working with ?   here's a 
partial list of mine :

1) WinXP : Visual Studio .NET 2003

2) Linux x86 :
 GCC : 3.4.6
 g++ : 3.4.6
 make : 3.81b4

What are you using?  what other tools should we list?

I recently setup a new machine (linux) and now have the complete list of

stuff that has to be installed (starting from fresh ubuntu6) and will 
post that on the getting started document on teh website.


geir

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

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

Re: [classlib][awt] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)

[Denis Kishenko]

This issue has been filed and patched three weeks ago but wasn't
applied yet (as many others). See
http://issues.apache.org/jira/browse/HARMONY-1585

2006/10/15, Andrew Zhang [EMAIL PROTECTED]:

PolePosition(actually JFreeChat) throws IllegalPathStateException when
generating test report.The error message looks like (I added a sysout(shape)
in CommonGraphics2D#fill method):

java.awt.geom.Rectangle2D$Double[x=0.0,y=0.0,width=750.0,height=500.0]
[EMAIL PROTECTED]
java.awt.geom.IllegalPathStateException: First segment should be SEG_MOVETO
type
 at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:24)
 at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260)
 at java.awt.geom.GeneralPath.append(GeneralPath.java:296)
 at java.awt.geom.AffineTransform.createTransformedShape(
AffineTransform.java:535)
 at org.apache.harmony.awt.gl.CommonGraphics2D.fill(CommonGraphics2D.java
:723)
 at org.jfree.chart.StandardLegend.drawLegendBox(StandardLegend.java:875)
 at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757)
 at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578)


On 10/15/06, Andrew Zhang [EMAIL PROTECTED] wrote:

 I simplified  test scenario in PolePosition. Now it throws unexpected
 exception when generating test report:
 java.awt.geom.IllegalPathStateException: First segment should be
 SEG_MOVETO type
  at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:204)
  at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260)
  at java.awt.geom.GeneralPath.append(GeneralPath.java:296)
  at java.awt.geom.AffineTransform.createTransformedShape(
 AffineTransform.java:535)
  at org.apache.harmony.awt.gl.CommonGraphics2D.fill(CommonGraphics2D.java:722)

  at org.jfree.chart.StandardLegend.drawLegendBox(StandardLegend.java:875)
  at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757)
  at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578)
  at org.jfree.chart.JFreeChart.draw(JFreeChart.java:966)
  at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1157)
  at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1136)
  at org.jfree.chart.JFreeChart.createBufferedImage (JFreeChart.java:1121)
  at org.polepos.reporters.HTMLReporter.renderLapGraph(HTMLReporter.java
 :121)
  at org.polepos.reporters.HTMLReporter.report(HTMLReporter.java:58)
  at org.polepos.reporters.GraphReporter.endSeason (GraphReporter.java:13)
  at org.polepos.framework.Racer.run(Racer.java:114)
  at org.polepos.framework.Racer.init(Racer.java:44)
  at org.polepos.RunSeason.main(RunSeason.java:93)


  On 10/14/06, Andrew Zhang [EMAIL PROTECTED] wrote:
 
  PolePosition is a benchmark test suite to compare database engines and
  object-relational mapping technology. ( http://www.polepos.org/). I
  tried to run PolePosition on Harmony(lastest build), but unfortunately vm
  crashed during the execution.
 
  The DRLVM crashes at the very early stage, while IBM VME crashes after a
  while. No error message is printed out from DRLVM, while IBM VME gives
  following message [1]. Any comments about jclclear_23.dll and the extra
  info 0012FB7C ?
 
  [1] IBM VME error message:
  Unhandled exception
  Type=Segmentation error vmState=0x0004
  J9Generic_Signal_Number=0004 ExceptionCode=c005
  ExceptionAddress=7F96A8EC ContextFlags=0001003f
  Handler1=7FE50390 Handler2=7FD074F0 InaccessibleAddress=0137D580
  EDI=0074BB40 ESI=0081F100 EAX=11761268 EBX=0137D568
  ECX=000C EDX=0004
  EIP=7F96A8EC ESP=0012F81C EBP=001D5500
  Module=D:\Harmony\deploy\jdk\jre\bin\default\jclclear_23.dll
  Module_base_address=7F95 Offset_in_DLL=0001a8ec
  Target=2_30_20060727_07300_lHdSMR (Windows XP 5.1 build 2600 Service
  Pack 2)
  CPU=x86 (1 logical CPUs) (0x1f77c000 RAM)
  ...
  _org.apache.harmony.vmi.portlib (extra info: 0012FB7C)
  -Xjcl:jclclear_23
  _j2se_j9=136448
 
  --
  Best regards,
  Andrew Zhang
 



 --
 Best regards,
 Andrew Zhang




--
Best regards,
Andrew Zhang





--
Denis M. Kishenko
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][awt] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)

[Andrew Zhang]

On 10/16/06, Denis Kishenko [EMAIL PROTECTED] wrote:


This issue has been filed and patched three weeks ago but wasn't
applied yet (as many others).



Thanks Denis! Look forward to committers. :-)

See

http://issues.apache.org/jira/browse/HARMONY-1585

2006/10/15, Andrew Zhang [EMAIL PROTECTED]:
 PolePosition(actually JFreeChat) throws IllegalPathStateException when
 generating test report.The error message looks like (I added a
sysout(shape)
 in CommonGraphics2D#fill method):

 java.awt.geom.Rectangle2D$Double[x=0.0,y=0.0,width=750.0,height=500.0]
 [EMAIL PROTECTED]
 java.awt.geom.IllegalPathStateException: First segment should be
SEG_MOVETO
 type
  at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:24)
  at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260)
  at java.awt.geom.GeneralPath.append(GeneralPath.java:296)
  at java.awt.geom.AffineTransform.createTransformedShape(
 AffineTransform.java:535)
  at org.apache.harmony.awt.gl.CommonGraphics2D.fill(
CommonGraphics2D.java
 :723)
  at org.jfree.chart.StandardLegend.drawLegendBox(StandardLegend.java
:875)
  at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757)
  at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578)


 On 10/15/06, Andrew Zhang [EMAIL PROTECTED] wrote:
 
  I simplified  test scenario in PolePosition. Now it throws unexpected
  exception when generating test report:
  java.awt.geom.IllegalPathStateException: First segment should be
  SEG_MOVETO type
   at java.awt.geom.GeneralPath.checkBuf(GeneralPath.java:204)
   at java.awt.geom.GeneralPath.closePath(GeneralPath.java:260)
   at java.awt.geom.GeneralPath.append(GeneralPath.java:296)
   at java.awt.geom.AffineTransform.createTransformedShape(
  AffineTransform.java:535)
   at org.apache.harmony.awt.gl.CommonGraphics2D.fill(
CommonGraphics2D.java:722)
 
   at org.jfree.chart.StandardLegend.drawLegendBox(StandardLegend.java
:875)
   at org.jfree.chart.StandardLegend.draw(StandardLegend.java:757)
   at org.jfree.chart.StandardLegend.draw(StandardLegend.java:578)
   at org.jfree.chart.JFreeChart.draw(JFreeChart.java:966)
   at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java
:1157)
   at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java
:1136)
   at org.jfree.chart.JFreeChart.createBufferedImage (JFreeChart.java
:1121)
   at org.polepos.reporters.HTMLReporter.renderLapGraph(
HTMLReporter.java
  :121)
   at org.polepos.reporters.HTMLReporter.report(HTMLReporter.java:58)
   at org.polepos.reporters.GraphReporter.endSeason (GraphReporter.java
:13)
   at org.polepos.framework.Racer.run(Racer.java:114)
   at org.polepos.framework.Racer.init(Racer.java:44)
   at org.polepos.RunSeason.main(RunSeason.java:93)
 
 
   On 10/14/06, Andrew Zhang [EMAIL PROTECTED] wrote:
  
   PolePosition is a benchmark test suite to compare database engines
and
   object-relational mapping technology. ( http://www.polepos.org/). I
   tried to run PolePosition on Harmony(lastest build), but
unfortunately vm
   crashed during the execution.
  
   The DRLVM crashes at the very early stage, while IBM VME crashes
after a
   while. No error message is printed out from DRLVM, while IBM VME
gives
   following message [1]. Any comments about jclclear_23.dll and the
extra
   info 0012FB7C ?
  
   [1] IBM VME error message:
   Unhandled exception
   Type=Segmentation error vmState=0x0004
   J9Generic_Signal_Number=0004 ExceptionCode=c005
   ExceptionAddress=7F96A8EC ContextFlags=0001003f
   Handler1=7FE50390 Handler2=7FD074F0 InaccessibleAddress=0137D580
   EDI=0074BB40 ESI=0081F100 EAX=11761268 EBX=0137D568
   ECX=000C EDX=0004
   EIP=7F96A8EC ESP=0012F81C EBP=001D5500
   Module=D:\Harmony\deploy\jdk\jre\bin\default\jclclear_23.dll
   Module_base_address=7F95 Offset_in_DLL=0001a8ec
   Target=2_30_20060727_07300_lHdSMR (Windows XP 5.1 build 2600 Service
   Pack 2)
   CPU=x86 (1 logical CPUs) (0x1f77c000 RAM)
   ...
   _org.apache.harmony.vmi.portlib (extra info: 0012FB7C)
   -Xjcl:jclclear_23
   _j2se_j9=136448
  
   --
   Best regards,
   Andrew Zhang
  
 
 
 
  --
  Best regards,
  Andrew Zhang




 --
 Best regards,
 Andrew Zhang




--
Denis M. Kishenko
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]





--
Best regards,
Andrew Zhang

Re: [general] JIRA - port-platform categories for JIRA?

[Mikhail Fursov]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


 and when I create a new issue I can choose only one of the components.

No, you can choose more than one. Try using shift-click or something.



Thanks Geir, now I understand why JIRA does not need subcomponents.

So according to your proposal DRLVM, Classlib, Port-IPF are allowed to share
issues. That is Port-IPF will contain bugs from Classlib and IPF and any
other components that have IPF problems. Sounds good.

BTW is there any way to specify a component (or multiple components
intersection) in JIRA search (I can't find it)? The browsing by components
is OK only when we have a rather small amount of issues. If one day we  have
thousands of opened issues the only way to browse it will be the search. May
be we can add more categories like Q42006, Q12007 to browse only issues
that are planned to be fixed in the specified period?




--
Mikhail Fursov

Re: [classlib] quicker reporting of test failures/errors (was Re: svn commit: r463824 - /incubator/harmony/enhanced/classlib/trunk/make/build-test.xml)

[Spark Shen]

Mark Hindess 写道:

Frustrated with the time that gen-report takes to produce a report
(which mainly consists of pages and pages of information about test
passes that I'll never read), I implemented a short report mode on
Friday.  So now, running:

  ant -Dshort.report=true test

will produce a report that only contains information about tests that
have failures or errors.  Unless you've broken something really badly
it will run in a tiny fraction of the time that the full report takes -
15minutes for me if I run all the classlib tests!

  

Great work! Thanks.

Best regards

Regards,
 Mark.

On 13 October 2006 at 20:58, [EMAIL PROTECTED] wrote:
  

Author: hindessm
Date: Fri Oct 13 13:58:51 2006
New Revision: 463824

URL: http://svn.apache.org/viewvc?view=revrev=463824
Log:
Generating the test report takes ten minutes on my thinkpad so I've added
a short report mode that only reports on tests that have either errors or
failures.  It takes only a few seconds assuming most tests are passing.
Activate it with command line argument -Dshort.report=true.  


Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-test.xml

Modified: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/build-test.xml?view=diffrev=463824r1=463823r2=463824
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/build-test.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Fri Oct 13 
13:58:51 2006

@@ -52,7 +52,9 @@
 call-modules target=test /
 /target
 
-target name=gen-report

+target name=gen-report depends=full-report,short-report /
+
+target name=full-report unless=short.report 
 junitreport todir=${tests.output}
 fileset dir=${tests.output}
 include name=TEST*-*.xml/
@@ -63,6 +65,20 @@
 !-- use this property just to get the slashes to display right in t
he echo --
 property name=display-location location=${tests.output}/html/ind
ex.html/
 echo message=The test report is in ${display-location}/
+/target
+
+target name=short-report if=short.report 
+junitreport todir=${tests.output}
+fileset dir=${tests.output} includes=TEST*-*.xml
+containsregexp expression='(errors|failures)=[1-9]' /
+exclude name=TESTS-TestSuites.xml /
+/fileset
+report format=frames todir=${tests.output}/html/
+/junitreport
+
+!-- use this property just to get the slashes to display right in t
he echo --
+property name=display-location location=${tests.output}/html/ind
ex.html/
+echo message=The short test report is in ${display-location}/
 /target
 
 target name=support-jar depends=compile-support







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


  



--
Spark Shen
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]Self-host of Derby

[Alex Luo]

Hello:
   I have build derby successfully on RI.  But when I tried to run 
the following derby's test  on Harmony, it failed.
*java -Dframework=DerbyNetClient 
org.apache.derbyTesting.functionTests.harness.RunTest lang/supersimple.sql *

Btw, this test passed on RI.

(1) If  the VM is  J9vm, at first the test can't even be launched. After 
applying the Sian's patch, this error seems to be fixed.
But the test still failed because of a strange reason, the error report  
is described as following:


*java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedDriver
  at java.lang.Class.forName(Class.java:129)
  at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source)
  at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
  at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
  at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source)
  at org.apache.derby.impl.tools.ij.utilMain.init(Unknown Source)
  at org.apache.derby.impl.tools.ij.utilMain14.init(Unknown Source)
  at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source)
  at org.apache.derby.impl.tools.ij.Main.init(Unknown Source)
  at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source)
  at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
  at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
  at org.apache.derby.tools.ij.main(Unknown Source)
  at 
org.apache.derbyTesting.functionTests.harness.RunIJ.run(RunIJ.java:45)

  at java.lang.Thread.run(Thread.java:872)
ij version 10.1
ij -- by default, holdability of ResultSet objects created using this 
Connection object is true. Following will set it to false for this 
connection.

NoHoldForConnection;
IJ ERROR: Unable to establish connection
ij create table a (a int);
IJ ERROR: Unable to establish connection *

I find that the class *org.apache.derby.jdbc.EmbeddedDriver * exists, 
and I have included this class in ClassPath.

I write a simple test to load this class,  it works.


(2) If the VM is  DRLVM,  the test can't be launched, I paste the error 
report in command line here:


*Failure to open JIT dll 
D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\

jre\bin/default/\jitrino.dll-1073021795
apr code: Unknown error

An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=006FC875
ContextFlags=0001003f
Handler1=00401010
Handler2=11105CE0
InaccessibleAddress=CDCDCDD1
EDI=0013F178
ESI=0013F0CC
EAX=01301794
EBX=0002
ECX=CDCDCDCD
EDX=CDCDCDCD
EIP=006FC875
ESP=0013F0C8
EBP=0013F0D4
Module=D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\default\h 


armonyvm.dll
Module_base_address=0051
Offset_in_DLL=001ec875

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information. *

Has anybody ever met the same problem?


Leo Li wrote:

Hi, all:
I now plan to make the self-host of Derby on Harmony.
Is there anyone interested in this topic?

Here is what I encountered in the process. Hope it will be helpful to
anybody who is interested in it.

At first, the testcases even fails on RI both on windows and 
ubuntu and

the result are different.???
After some struggiling, I have successfully passed the provided
testcases on RI after I rebuild the source on my machine.
But there still remains a problem:
The derby team kindly rewrite the launcher for testcases in order to
treat J9 vm differently if the property java.vm.name starts with j9. 
But

the j9 vm used in Harmony has been customized thus is different from
traditional j9 vm that is expected by derby. This leads to failure to 
launch

tests.
I will talk on Derby's mailing list to find a solution.




-
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]Self-host of Derby

[Spark Shen]

Alex Luo 写道:

Hello:
I have build derby successfully on RI. But when I tried to run the 
following derby's test on Harmony, it failed.
*java -Dframework=DerbyNetClient 
org.apache.derbyTesting.functionTests.harness.RunTest 
lang/supersimple.sql *

Btw, this test passed on RI.

Would you try eliminate -Dframework=DerbyNetClient?

Best regards


(1) If the VM is J9vm, at first the test can't even be launched. After 
applying the Sian's patch, this error seems to be fixed.
But the test still failed because of a strange reason, the error 
report is described as following:


*java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedDriver
at java.lang.Class.forName(Class.java:129)
at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source)
at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.init(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain14.init(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.init(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
at org.apache.derbyTesting.functionTests.harness.RunIJ.run(RunIJ.java:45)
at java.lang.Thread.run(Thread.java:872)
ij version 10.1
ij -- by default, holdability of ResultSet objects created using this 
Connection object is true. Following will set it to false for this 
connection.

NoHoldForConnection;
IJ ERROR: Unable to establish connection
ij create table a (a int);
IJ ERROR: Unable to establish connection *

I find that the class *org.apache.derby.jdbc.EmbeddedDriver * exists, 
and I have included this class in ClassPath.

I write a simple test to load this class, it works.


(2) If the VM is DRLVM, the test can't be launched, I paste the error 
report in command line here:


*Failure to open JIT dll 
D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\

jre\bin/default/\jitrino.dll-1073021795
apr code: Unknown error

An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=006FC875
ContextFlags=0001003f
Handler1=00401010
Handler2=11105CE0
InaccessibleAddress=CDCDCDD1
EDI=0013F178
ESI=0013F0CC
EAX=01301794
EBX=0002
ECX=CDCDCDCD
EDX=CDCDCDCD
EIP=006FC875
ESP=0013F0C8
EBP=0013F0D4
Module=D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\default\h 


armonyvm.dll
Module_base_address=0051
Offset_in_DLL=001ec875

This application has requested the Runtime to terminate it in an 
unusual way.

Please contact the application's support team for more information. *

Has anybody ever met the same problem?


Leo Li wrote:

Hi, all:
I now plan to make the self-host of Derby on Harmony.
Is there anyone interested in this topic?

Here is what I encountered in the process. Hope it will be helpful to
anybody who is interested in it.

At first, the testcases even fails on RI both on windows and ubuntu and
the result are different.???
After some struggiling, I have successfully passed the provided
testcases on RI after I rebuild the source on my machine.
But there still remains a problem:
The derby team kindly rewrite the launcher for testcases in order to
treat J9 vm differently if the property java.vm.name starts with 
j9. But

the j9 vm used in Harmony has been customized thus is different from
traditional j9 vm that is expected by derby. This leads to failure to 
launch

tests.
I will talk on Derby's mailing list to find a solution.




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





--
Spark Shen
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] IPF functionality

[Tim Ellison]

Mikhail Loenko wrote:
 When we bring new platforms how will we make sure that a patch for some
 rare platform would not break another one?

Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do is to test it on the platforms he or she has available.
 After that we rely on the diversity of the community building and
testing the code to catch any problems; i.e. the change doesn't
necessarily end with the commit, it may still have to be backed out.

There is no guarantee of the stability of HEAD, we only get that by
taking a snapshot and everyone testing it with all platforms (c.f. say
Eclipse that does have a centralized build system).

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] IPF functionality

[Mikhail Loenko]

2006/10/16, Tim Ellison [EMAIL PROTECTED]:

Mikhail Loenko wrote:
 When we bring new platforms how will we make sure that a patch for some
 rare platform would not break another one?

Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do is to test it on the platforms he or she has available.
 After that we rely on the diversity of the community building and
testing the code to catch any problems; i.e. the change doesn't
necessarily end with the commit, it may still have to be backed out.


How will we define which changes should be backed out?
Do you mean that we first define list of supported platforms
and then we will roll back all the changes that reportedly break
build on one of that platform?

What would be the procedure to add a new platform to the list of
supported ones? (Well I assume it's a vote, but what are the criteria
to be used in that vote?)

Thanks,
Mikhail



There is no guarantee of the stability of HEAD, we only get that by
taking a snapshot and everyone testing it with all platforms (c.f. say
Eclipse that does have a centralized build system).

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]




-
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] IPF functionality

[Geir Magnusson Jr.]

Mikhail Loenko wrote:

2006/10/16, Tim Ellison [EMAIL PROTECTED]:

Mikhail Loenko wrote:
 When we bring new platforms how will we make sure that a patch for some
 rare platform would not break another one?

Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do is to test it on the platforms he or she has available.
 After that we rely on the diversity of the community building and
testing the code to catch any problems; i.e. the change doesn't
necessarily end with the commit, it may still have to be backed out.




And the hope is that we'll have the project's CI system running on lots 
of places.



How will we define which changes should be backed out?
Do you mean that we first define list of supported platforms
and then we will roll back all the changes that reportedly break
build on one of that platform?


Yes - I think that we'll eventually get to that state formally, and 
we're there now informally.  I suspect that a change to support IPF that 
broke x86 would be backed out w/o a complaint :)




What would be the procedure to add a new platform to the list of
supported ones? (Well I assume it's a vote, but what are the criteria
to be used in that vote?)


I think that having criteria for use in a vote misses the point - 
because otherwise we'd determine based on the criteria and not need to vote.


I think that it will be based on having people interested in working on 
it and size of user population.  If we decide that we're going to 
support a platform, it's a lot of work we're taking on


geir




Thanks,
Mikhail



There is no guarantee of the stability of HEAD, we only get that by
taking a snapshot and everyone testing it with all platforms (c.f. say
Eclipse that does have a centralized build system).

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]




-
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][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Geir Magnusson Jr.]

Egor Pasko wrote:

On the 0x202 day of Apache Harmony Geir Magnusson, Jr. wrote:

Egor Pasko wrote:

Harmoniers,
Thanks to Mikhail Fursov, George Timoshenko, Nikolay Sidelnikov (and
me, of course:) all critical bugs (as in [1]) in Jitrino.OPT have
their fixing patches and I like them. I think, it is a good step
forward to enabling the self-hosting environment.
Here are the champions:
+ HARMONY-1774 (fixes also HARMONY-1773,  HARMONY-1775)

Applied.  IMO, doesn't fix 1775


Greater thanks, Geir! I should have checked this. Today I observe the
same. RCE=off passes the test as in older times. I'll take a look.


+ HARMONY-1802 (no more crash in HARMONY-1688, but a hang:)

Applied. 1688 still crashes for me


I have no crash, only ... printed and a CPU-eating infinite loop


Excuse me :) You're right.  It's the much-dreaded CPU-eating infinite 
loop of doom (which is worse than a crash as it wastes CPU resource ;)





+ HARMONY-1796

Applied.


+ HARMONY-1781

Applied


+ HARMONY-1682 (fixes also HARMONY-1695)

Applied


I tried them all: * Linux (SUSE 9, gcc-3.3.3)
  + Smoke, cunit, kernel. And only the ThreadTest failed, which is
normal :)
* windows
  + cunit OK, kernel tests fail with Process fork failed, which is
my configuration problem. BTW, anybody seen this?
[1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM


-
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][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Geir Magnusson Jr.]

Alexey Varlamov wrote:

[snip]

  + HARMONY-1802 (no more crash in HARMONY-1688, but a hang:)

 Applied. 1688 still crashes for me

I have no crash, only ... printed and a CPU-eating infinite loop


This is expected behaviour for now, waiting for classloading fix +
the test should be fixed, patch is available.


You do realize that if we tell people that we expect that our VM loops 
infinitely, we're not going to get too many users :)


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][luni]Runtime.exec fails on Linux

[Geir Magnusson Jr.]

Alexey Varlamov wrote:
 2006/10/16, Spark Shen [EMAIL PROTECTED]:
 Alexey Varlamov 写道:
  Both DRLVM and J9 works for me (SUSE9).
 Not sure whether SUSE9 env. is identical to our RedHat Enterprise 4 and
 Unbuntu.
 BTW, is there off-the-peg DRLVM for download on popular platform?
 
 Other than JRE snapshots, no.

What else would you want?  They will become JDK Real Soon Now, but still
- what else would you want?

geir

 

 Best regards
 
  --
  Alexey
 
  2006/10/16, Leo Li [EMAIL PROTECTED]:
  Hi, all:
  The harmony Runtime.exec fails on Linux with ENOMEM.
  Here is the testcase:
 
  public class Exec {
  public static void main(String[] args) throws Exception {
 
  Runtime.getRuntime().exec(ls); }
  }
 
  I have tried it on RedHat Enterprise 4 and Unbuntu, both get ENOMEM in
  native code.
 
  After digging into it, I found it fails in procimpl.c, line 135:
 
  grdpid = fork ();
 
  If the call to fork is changed to vfork, the testcase will pass but
  still get exitcode = 1 which indicates that some error has 
 happened. The
  difference between fork and vfork is just whether page tables is
  copied to
  child process or not. But I do not think it is the main cause. 
 Besides,
  vfork has become outdated since it main usage is supplied by fork with
  copy-on-write function implemented in modern linux kernel. 
 Furthermore,
  vfork is also not so safe as fork. So I do not think it is the
  accepted way
  to solve the problem.
 
  I will try whether it can be reproduced on drlvm of linux since I 
 am not
  sure whether it is relevent to VM or classlib. If any drlvm man can
  tell me
  the result, it can avoid my trouble to build it on linux. :)
 
 
 
 
 
 
 
  --
  Leo Li
  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]
 
 


 -- 
 Spark Shen
 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]


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

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

Re: [classlib][luni]Runtime.exec fails on Linux

[Geir Magnusson Jr.]

I'm confused.  Didn't you just report this on Ubuntu?

I have had similar forking problems on Ubuntu 6 (I once found a bug in 
classlib related to forking...).


I never figured out why Unbuntu does this, but it seemed that under 
memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and run 
the test again...


geir


Leo Li wrote:

Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!


On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:


Both DRLVM and J9 works for me (SUSE9).

--
Alexey

2006/10/16, Leo Li [EMAIL PROTECTED]:
 Hi, all:
 The harmony Runtime.exec fails on Linux with ENOMEM.
 Here is the testcase:

 public class Exec {
public static void main(String[] args) throws Exception {

   Runtime.getRuntime().exec(ls);}
 }

I have tried it on RedHat Enterprise 4 and Unbuntu, both get ENOMEM
in
 native code.

After digging into it, I found it fails in procimpl.c, line 135:

grdpid = fork ();

If the call to fork is changed to vfork, the testcase will pass but
 still get exitcode = 1 which indicates that some error has happened. 
The

 difference between fork and vfork is just whether page tables is copied
to
 child process or not. But I do not think it is the main cause. Besides,
 vfork has become outdated since it main usage is supplied by fork with
 copy-on-write function implemented in modern linux kernel. Furthermore,
 vfork is also not so safe as fork. So I do not think it is the accepted
way
 to solve the problem.

   I will try whether it can be reproduced on drlvm of linux since I am
not
 sure whether it is relevent to VM or classlib. If any drlvm man can 
tell

me
 the result, it can avoid my trouble to build it on linux. :)







 --
 Leo Li
 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]







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

Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Ivan Volosyuk]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Weldon Washburn wrote:
 I have zero problem with the commit as long as it does not imply a
 change to
 the interface between JIT/GC/VM.  I suspect Xiao Feng will find no problems
 with the commit.  Xiao Feng, please comment.

If there is a change, what is it and why is it bad?


IMHO, Weldon doesn't want to spend time understanding the change and
just wants to keep existing interfaces. GC v4.1 has additional
requirement from VM/JIT in order to support collection during
enumeration. Other existing DRLVM's GCs doesn't has such requirement
and will work just fine either way. There is no interface changes for
them.

--
Ivan
Intel Enterprise Solutions Software Division

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

Re: [general] version of gcc and other tools

[Geir Magnusson Jr.]

Konovalova, Svetlana wrote:

Gier,

AFAIS work goes continually to test various combinations of environment
and tools, and because combinations that are stable today might get
broken tomorrow, we can keep this info on Wiki for easier editing. 
IMHO we can create a Wiki page, let's say SureToRunConfigurations and

add a link from Quick Help to this page. To begin with, we can use the
info from the harmony discussion to create the page. What do you think
about it?


Fine by me, but I still am interested in harvesting this info onto the 
website periodically because I want to start including the site in our 
builds so people have docs included with what we give them.  The biggest 
problem with Wiki's is that if you aren't online, they don't exist :)


So if you're interested in summarizing to teh wiki, please do - we can 
then get the data from there for the website.


geir



Cheers,
Sveta Konovalova

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 10, 2006 8:11 PM

To: harmony-dev@incubator.apache.org
Subject: [general] version of gcc and other tools

I'm so sick of this gcc problem.

Lets decide on the versions for GCC and other tools that will work.  I

feel the same way that mark does re that being able to build on multiple

versions gives a better feeling of goodness and harmony in the universe 
and I encourage people to work on other versions (I will), but it's 
gotta be the case that we have a reference toolchain - that no matter 
what, it will work on there, and probably a list of tested versions


So, what tools and what versions are people working with ?   here's a 
partial list of mine :


1) WinXP : Visual Studio .NET 2003

2) Linux x86 :
 GCC : 3.4.6
 g++ : 3.4.6
 make : 3.81b4

What are you using?  what other tools should we list?

I recently setup a new machine (linux) and now have the complete list of

stuff that has to be installed (starting from fresh ubuntu6) and will 
post that on the getting started document on teh website.



geir

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

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



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

Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Mikhail Fursov]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


 I have zero problem with the commit as long as it does not imply a
 change to
 the interface between JIT/GC/VM.  I suspect Xiao Feng will find no
problems
 with the commit.  Xiao Feng, please comment.

If there is a change, what is it and why is it bad?



We agreed to remove enumerate(mptr,base) method from the GC-JIT interface
and use enumerate(mptr,offset) only for mptrs.
I replaced all of the usages of the first one with the second one in JIT. GC
part was not affected because that was the time when Weldon was merging
GCv5. Now I think we can clean GC interfaces too (or to be more precise the
VM part of JIT-GC interfaces) and remove the method 'enumerate(mptr,
base)'

--
Mikhail Fursov

Re: [general] JIRA - port-platform categories for JIRA?

[Geir Magnusson Jr.]

Mikhail Fursov wrote:

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


 and when I create a new issue I can choose only one of the components.

No, you can choose more than one. Try using shift-click or something.



Thanks Geir, now I understand why JIRA does not need subcomponents.


Explain it to me then :)  I still think subcomponents would be cool, 
since it would allow some structuring...




So according to your proposal DRLVM, Classlib, Port-IPF are allowed to 
share

issues. That is Port-IPF will contain bugs from Classlib and IPF and any
other components that have IPF problems. Sounds good.


We already do that, I think.  For example, I'll set App-Oriented Bug 
and DRLVM if I think DRLVM is the culprit, although the bug could be 
classlib, or both...




BTW is there any way to specify a component (or multiple components
intersection) in JIRA search (I can't find it)? 


Yes - you can.   If you go click on Find Issue on the 'menu bar' 
(below the feather) after being in the Harmony project page in JIRA, you 
 can choose components in the Find Issues screen.  You can create 
those searches and save them...


FWIW, I've been trying to get the patch available field in our default 
searches to work, but it usually results in me screaming and rocking 
back and forth in the corner...


I know it can be done - Geronimo is configured that way - so I'll ask 
someone there how they did it, or as Atlassian directly.  I tried 
following their docs, but... see above re screaming and corner...


geir



The browsing by components
is OK only when we have a rather small amount of issues. If one day we  
have
thousands of opened issues the only way to browse it will be the search. 
May

be we can add more categories like Q42006, Q12007 to browse only issues
that are planned to be fixed in the specified period?






-
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] quicker reporting of test failures/errors (was Re: svn commit: r463824 - /incubator/harmony/enhanced/classlib/trunk/make/build-test.xml)

[Geir Magnusson Jr.]

Nice!  is there any chance this could be documented - even in the 
build.xml file - for those of us that are recall-challenged?


geir

Mark Hindess wrote:

Frustrated with the time that gen-report takes to produce a report
(which mainly consists of pages and pages of information about test
passes that I'll never read), I implemented a short report mode on
Friday.  So now, running:

  ant -Dshort.report=true test

will produce a report that only contains information about tests that
have failures or errors.  Unless you've broken something really badly
it will run in a tiny fraction of the time that the full report takes -
15minutes for me if I run all the classlib tests!

Regards,
 Mark.

On 13 October 2006 at 20:58, [EMAIL PROTECTED] wrote:

Author: hindessm
Date: Fri Oct 13 13:58:51 2006
New Revision: 463824

URL: http://svn.apache.org/viewvc?view=revrev=463824
Log:
Generating the test report takes ten minutes on my thinkpad so I've added
a short report mode that only reports on tests that have either errors or
failures.  It takes only a few seconds assuming most tests are passing.
Activate it with command line argument -Dshort.report=true.  


Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-test.xml

Modified: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/build-test.xml?view=diffrev=463824r1=463823r2=463824
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/build-test.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Fri Oct 13 
13:58:51 2006

@@ -52,7 +52,9 @@
 call-modules target=test /
 /target
 
-target name=gen-report

+target name=gen-report depends=full-report,short-report /
+
+target name=full-report unless=short.report 
 junitreport todir=${tests.output}
 fileset dir=${tests.output}
 include name=TEST*-*.xml/
@@ -63,6 +65,20 @@
 !-- use this property just to get the slashes to display right in t
he echo --
 property name=display-location location=${tests.output}/html/ind
ex.html/
 echo message=The test report is in ${display-location}/
+/target
+
+target name=short-report if=short.report 
+junitreport todir=${tests.output}
+fileset dir=${tests.output} includes=TEST*-*.xml
+containsregexp expression='(errors|failures)=[1-9]' /
+exclude name=TESTS-TestSuites.xml /
+/fileset
+report format=frames todir=${tests.output}/html/
+/junitreport
+
+!-- use this property just to get the slashes to display right in t
he echo --
+property name=display-location location=${tests.output}/html/ind
ex.html/
+echo message=The short test report is in ${display-location}/
 /target
 
 target name=support-jar depends=compile-support






-
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][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Ivan Volosyuk]

On 10/16/06, Mikhail Fursov [EMAIL PROTECTED] wrote:

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

  I have zero problem with the commit as long as it does not imply a
  change to
  the interface between JIT/GC/VM.  I suspect Xiao Feng will find no
 problems
  with the commit.  Xiao Feng, please comment.

 If there is a change, what is it and why is it bad?


We agreed to remove enumerate(mptr,base) method from the GC-JIT interface
and use enumerate(mptr,offset) only for mptrs.
I replaced all of the usages of the first one with the second one in JIT. GC
part was not affected because that was the time when Weldon was merging
GCv5. Now I think we can clean GC interfaces too (or to be more precise the
VM part of JIT-GC interfaces) and remove the method 'enumerate(mptr,
base)'


Well, I would formulate it other way. The change will only affect
VMJIT interfaces.

The only GC interface function exists:
 void gc_add_root_set_entry_interior_pointer (void **slot, int
offset, Boolean is_pinned);
and it will stay unchanged.

--
Ivan
Intel Enterprise Solutions Software 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][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Geir Magnusson Jr.]

Ivan Volosyuk wrote:

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Weldon Washburn wrote:
 I have zero problem with the commit as long as it does not imply a
 change to
 the interface between JIT/GC/VM.  I suspect Xiao Feng will find no 
problems

 with the commit.  Xiao Feng, please comment.

If there is a change, what is it and why is it bad?


IMHO, Weldon doesn't want to spend time understanding the change and
just wants to keep existing interfaces. 


That kind of statement has no place here - I'm not sure how you can 
objectively determine something like that, unless Weldon said I don't 
want to spend time understanding this..., don't say it.


Lets keep this technical.


GC v4.1 has additional
requirement from VM/JIT in order to support collection during
enumeration. Other existing DRLVM's GCs doesn't has such requirement
and will work just fine either way. There is no interface changes for
them.



So when we switch to v5, this goes away?

geir

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

Re: [drlvm] “java.compiler” property

[Geir Magnusson Jr.]

since it's apparently undefined by spec, then putting something 
informational like none or interpreter-only would do no harm?


geir


Tim Ellison wrote:

FWIW in the IBM VM we set to java.compiler= if the JIT is disabled.

and the Sun 1.5.0_06 build doesn't set it at all!

Regards,
Tim





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

Re: [drlvm][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Egor Pasko]

On the 0x204 day of Apache Harmony Geir Magnusson, Jr. wrote:
 Alexey Varlamov wrote:
  [snip]
+ HARMONY-1802 (no more crash in HARMONY-1688, but a hang:)
  
   Applied. 1688 still crashes for me
 
  I have no crash, only ... printed and a CPU-eating infinite loop
  This is expected behaviour for now, waiting for classloading fix +
  the test should be fixed, patch is available.
 
 You do realize that if we tell people that we expect that our VM loops
 infinitely, we're not going to get too many users :)

sometimes users are happy when their ticks are spent on GIMPS. Integrate?))

-- 
Egor Pasko, Intel Managed Runtime Division


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

Re: [general] JIRA - port-platform categories for JIRA?

[Mikhail Fursov]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


 Thanks Geir, now I understand why JIRA does not need subcomponents.

Explain it to me then :)  I still think subcomponents would be cool,
since it would allow some structuring...



If you want to see all issues from the virtual DRLVM-IPF subcomponent all
you need is to find intersection (logical AND) for issues that are in DRLVM
and IPF categories.
The question is how to do such a search?



 BTW is there any way to specify a component (or multiple components
 intersection) in JIRA search (I can't find it)?

Yes - you can.   If you go click on Find Issue on the 'menu bar'
(below the feather) after being in the Harmony project page in JIRA, you
  can choose components in the Find Issues screen.  You can create
those searches and save them...



Ok, I've found it. To make this option to appear you should select harmony
project from the Project list and reload the page.
The only problem left is that the form to select components does only
union operation
(logical OR).
Is it possible to ask JIRA developers to add logical operations for the
components list?


--
Mikhail Fursov

Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Ivan Volosyuk]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Ivan Volosyuk wrote:
 GC v4.1 has additional
 requirement from VM/JIT in order to support collection during
 enumeration. Other existing DRLVM's GCs doesn't has such requirement
 and will work just fine either way. There is no interface changes for
 them.


So when we switch to v5, this goes away?

geir


Yes. GC v5 doesn't have this requirement for now.

--
Ivan
Intel Enterprise Solutions Software Division

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

Re: [general] JIRA - port-platform categories for JIRA?

[Geir Magnusson Jr.]

Mikhail Fursov wrote:

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


 Thanks Geir, now I understand why JIRA does not need subcomponents.

Explain it to me then :)  I still think subcomponents would be cool,
since it would allow some structuring...



If you want to see all issues from the virtual DRLVM-IPF subcomponent all
you need is to find intersection (logical AND) for issues that are in DRLVM
and IPF categories.
The question is how to do such a search?



 BTW is there any way to specify a component (or multiple components
 intersection) in JIRA search (I can't find it)?

Yes - you can.   If you go click on Find Issue on the 'menu bar'
(below the feather) after being in the Harmony project page in JIRA, you
  can choose components in the Find Issues screen.  You can create
those searches and save them...



Ok, I've found it. To make this option to appear you should select harmony
project from the Project list and reload the page.
The only problem left is that the form to select components does only
union operation
(logical OR).


You sure?  I can do a 'cmd-click' in Firefox on Mac and it selects 
multiple individual categories, and it seems to work in the search.


geir


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

Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Ivan Volosyuk]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

That kind of statement has no place here - I'm not sure how you can
objectively determine something like that, unless Weldon said I don't
want to spend time understanding this..., don't say it.

Lets keep this technical.


Sorry for that. I have terrible headache and may be too agressive now.
I will take a break.

--
Ivan
Intel Enterprise Solutions Software 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][beans] RI inconsistency in EventHandler

[Alexei Zakharov]

Hi Tim,

-- persuasion starts here

Let me cite the spec describing design patterns for properties,
JavaBeans spec v1.01-A (Aug 8, 1997), page 55:

---
8.3 Design Patterns for Properties

8.3.1 Simple properties
By default, we use design patterns to locate properties by looking for
methods of the form:

public PropertyType getPropertyName();
public void setPropertyName(PropertyType a);

8.3.2 Boolean properties
In addition, for boolean properties, we allow a

public boolean isPropertyName();

8.3.3 Indexed properties
If we find a property whose type is an array PropertyElement[],
then we also look for methods of the form:

public PropertyElement getPropertyName(int a);
public void setPropertyName(int a, PropertyElement b);
---

So we have only three design patterns specified for properties. That's
all. I didn't found any mentioning about any extra design patterns and
I've never heard anything about setDefaults() or smth. like it.

On the other hand, if I understand things correctly the Introspector
class should be the decision-making center for such type of things.
I.e. if Introspector says there is no properties then there should be
no properties. RI doesn't seem to be using Introspector in the example
I've described ealier. Thus I still think it looks like RI bug.

-- end of persuasion

Thanks and regards,

2006/10/14, Tim Ellison [EMAIL PROTECTED]:

That is strange behavior, since as you point out it does not set a
parametrized value, however, I wonder if there is some assumption that
the setFoo() method may be a mutator anyway, e.g. setDefaults() or
something like that?  Just guessing.

In this case it may be safer to follow the RI -- but I'm open to persuasion.

Regards,
Tim

Alexei Zakharov wrote:
 Hi all,

 Let me disturb you with another boring RI inconsistency in beans
 –type of message. :) It seems I found a bug in RI.  In
 java.beans.EventHandler. I think RI incorrectly determines properties
 here. According to spec, common sense and even the RI's implementation
 of java.beans.Introspector the following bean should not contain any
 properties:

public static class MyBean {
public void setProp1() {}
}

 because setProp1() is not a valid setter method – it does not
 contain a new value to set.
 However, the following test fails on RI:

 ---
 import java.beans.*;

 public class TestBeanInfo1 {
public static class MyBean {
public void setProp1() {}
}

public static void main(String argv[]) throws Exception {
MyBean bean = new MyBean();
// prop1 is neither the name of writeable property nor the
 name of any public method
Object proxy = EventHandler.create(
PropertyChangeListener.class, bean, prop1);

// just to show that Introspector doesn't see the property
 with name prop1
PropertyDescriptor[] pds = Introspector.getBeanInfo(MyBean.class,
Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
for (int i = 0; i  pds.length; i++) {
System.out.println(Property found:  + pds[i].getName());
}

// should throw exception
try {
((PropertyChangeListener) proxy).propertyChange(
new PropertyChangeEvent(bean, prop1, 1, 2));
System.out.println(FAIL);
} catch (Throwable t) {
System.out.println(PASS);
}
}
 }
 ---

 So it determines prop1 as a valid property. IMHO this behavior is
 inconsistent and we should not follow RI. But I like to hear opinions
 from the rest of the community.

 Thanks,



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

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

Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration

[Geir Magnusson Jr.]

Ivan Volosyuk wrote:

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

That kind of statement has no place here - I'm not sure how you can
objectively determine something like that, unless Weldon said I don't
want to spend time understanding this..., don't say it.

Lets keep this technical.


Sorry for that. I have terrible headache and may be too agressive now.
I will take a break.



thanks

-
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] quicker reporting of test failures/errors (was Re: svn commit: r463824 - /incubator/harmony/enhanced/classlib/trunk/make/build-test.xml)

[Oliver Deakin]

Thanks Mark - gen-report would absolutely kill my machine everytime. It was
taking longer than the actual tests to run!

Regards,
Oliver

Mark Hindess wrote:

Frustrated with the time that gen-report takes to produce a report
(which mainly consists of pages and pages of information about test
passes that I'll never read), I implemented a short report mode on
Friday.  So now, running:

  ant -Dshort.report=true test

will produce a report that only contains information about tests that
have failures or errors.  Unless you've broken something really badly
it will run in a tiny fraction of the time that the full report takes -
15minutes for me if I run all the classlib tests!

Regards,
 Mark.

On 13 October 2006 at 20:58, [EMAIL PROTECTED] wrote:
  

Author: hindessm
Date: Fri Oct 13 13:58:51 2006
New Revision: 463824

URL: http://svn.apache.org/viewvc?view=revrev=463824
Log:
Generating the test report takes ten minutes on my thinkpad so I've added
a short report mode that only reports on tests that have either errors or
failures.  It takes only a few seconds assuming most tests are passing.
Activate it with command line argument -Dshort.report=true.  


Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-test.xml

Modified: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
ake/build-test.xml?view=diffrev=463824r1=463823r2=463824
=
=
--- incubator/harmony/enhanced/classlib/trunk/make/build-test.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Fri Oct 13 
13:58:51 2006

@@ -52,7 +52,9 @@
 call-modules target=test /
 /target
 
-target name=gen-report

+target name=gen-report depends=full-report,short-report /
+
+target name=full-report unless=short.report 
 junitreport todir=${tests.output}
 fileset dir=${tests.output}
 include name=TEST*-*.xml/
@@ -63,6 +65,20 @@
 !-- use this property just to get the slashes to display right in t
he echo --
 property name=display-location location=${tests.output}/html/ind
ex.html/
 echo message=The test report is in ${display-location}/
+/target
+
+target name=short-report if=short.report 
+junitreport todir=${tests.output}
+fileset dir=${tests.output} includes=TEST*-*.xml
+containsregexp expression='(errors|failures)=[1-9]' /
+exclude name=TESTS-TestSuites.xml /
+/fileset
+report format=frames todir=${tests.output}/html/
+/junitreport
+
+!-- use this property just to get the slashes to display right in t
he echo --
+property name=display-location location=${tests.output}/html/ind
ex.html/
+echo message=The short test report is in ${display-location}/
 /target
 
 target name=support-jar depends=compile-support







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


  


--
Oliver Deakin
IBM United Kingdom Limited


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

Re: [general] JIRA - port-platform categories for JIRA?

[Mikhail Fursov]

Multiple selection does only logical OR operation on components selected.
E.g. if I select DRLVM component only get 239 issues. If I select
Contributions component I get 48 issues. If I select both of them I get
285 issues...(is it a bug?)

If we had a logical AND operation support for components selected,
subcomponents would become unneeded..


On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:




Mikhail Fursov wrote:
 On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

  Thanks Geir, now I understand why JIRA does not need subcomponents.

 Explain it to me then :)  I still think subcomponents would be cool,
 since it would allow some structuring...


 If you want to see all issues from the virtual DRLVM-IPF subcomponent
all
 you need is to find intersection (logical AND) for issues that are in
DRLVM
 and IPF categories.
 The question is how to do such a search?


  BTW is there any way to specify a component (or multiple components
  intersection) in JIRA search (I can't find it)?

 Yes - you can.   If you go click on Find Issue on the 'menu bar'
 (below the feather) after being in the Harmony project page in JIRA,
you
   can choose components in the Find Issues screen.  You can create
 those searches and save them...


 Ok, I've found it. To make this option to appear you should select
harmony
 project from the Project list and reload the page.
 The only problem left is that the form to select components does only
 union operation
 (logical OR).

You sure?  I can do a 'cmd-click' in Firefox on Mac and it selects
multiple individual categories, and it seems to work in the search.

geir


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





--
Mikhail Fursov

Re: [drlvm][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Egor Pasko]

On the 0x202 day of Apache Harmony Geir Magnusson, Jr. wrote:
 Egor Pasko wrote:
  Harmoniers,
  Thanks to Mikhail Fursov, George Timoshenko, Nikolay Sidelnikov (and
  me, of course:) all critical bugs (as in [1]) in Jitrino.OPT have
  their fixing patches and I like them. I think, it is a good step
  forward to enabling the self-hosting environment.
  Here are the champions:
  + HARMONY-1774 (fixes also HARMONY-1773,  HARMONY-1775)
 
 Applied.  IMO, doesn't fix 1775

Now the fix is available for 1775, see JIRA for more details..

[snip]

-- 
Egor Pasko, Intel Managed Runtime 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] “java.compiler” property

[Alexei Zakharov]

Moreover, the spec obliges us to do so. The real question is: is it RI
bug or bug in spec? Personally I am for returning non-null values in
all cases.

Regards,

2006/10/16, Geir Magnusson Jr. [EMAIL PROTECTED]:

since it's apparently undefined by spec, then putting something
informational like none or interpreter-only would do no harm?

geir


Tim Ellison wrote:
 FWIW in the IBM VM we set to java.compiler= if the JIT is disabled.

 and the Sun 1.5.0_06 build doesn't set it at all!

 Regards,
 Tim


--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

-
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] JIRA - port-platform categories for JIRA?

[Geir Magnusson Jr.]

Mikhail Fursov wrote:

Multiple selection does only logical OR operation on components selected.
E.g. if I select DRLVM component only get 239 issues. If I select
Contributions component I get 48 issues. If I select both of them I get
285 issues...(is it a bug?)

If we had a logical AND operation support for components selected,
subcomponents would become unneeded..



Oh.  Sorry.  I misread. Yes, we need an AND.

geir



On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:




Mikhail Fursov wrote:
 On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

  Thanks Geir, now I understand why JIRA does not need subcomponents.

 Explain it to me then :)  I still think subcomponents would be cool,
 since it would allow some structuring...


 If you want to see all issues from the virtual DRLVM-IPF subcomponent
all
 you need is to find intersection (logical AND) for issues that are in
DRLVM
 and IPF categories.
 The question is how to do such a search?


  BTW is there any way to specify a component (or multiple components
  intersection) in JIRA search (I can't find it)?

 Yes - you can.   If you go click on Find Issue on the 'menu bar'
 (below the feather) after being in the Harmony project page in JIRA,
you
   can choose components in the Find Issues screen.  You can create
 those searches and save them...


 Ok, I've found it. To make this option to appear you should select
harmony
 project from the Project list and reload the page.
 The only problem left is that the form to select components does only
 union operation
 (logical OR).

You sure?  I can do a 'cmd-click' in Firefox on Mac and it selects
multiple individual categories, and it seems to work in the search.

geir


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







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

Re: [drlvm] “java.compiler” property

[Mikhail Fursov]

On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote:


Moreover, the spec obliges us to do so. The real question is: is it RI
bug or bug in spec? Personally I am for returning non-null values in
all cases.



I agree. Just tell me and I will commit the patch for EM(interpreter) and
JIT modes.
BTW I think that we should create interpreter.emconf file and place all VM
properties needed for interpreter into this file.
So, in future, when we need to add more interpreter-mode option, we will not
affect the EM C++ code.


--
Mikhail Fursov

Re: [general] JIRA - port-platform categories for JIRA?

[Mikhail Fursov]

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


Yes, we need an AND.



Is it possible for us to get it from JIRA developers?

--
Mikhail Fursov

Re: [classlib][luni]Runtime.exec fails on Linux

[Paulex Yang]

Geir Magnusson Jr. wrote:

I'm confused.  Didn't you just report this on Ubuntu?
Let Leo speak for himself, but I thought Leo meant IBM VME + Harmony 
classlib failed on Ubuntu and Redhat, but Alexey just reported that both 
(VME and DRLVM) works on SUSE, that's why it seems interesting.


I have had similar forking problems on Ubuntu 6 (I once found a bug in 
classlib related to forking...).


I never figured out why Unbuntu does this, but it seemed that under 
memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and 
run the test again...

geir


Leo Li wrote:

Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!


On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:


Both DRLVM and J9 works for me (SUSE9).

--
Alexey

2006/10/16, Leo Li [EMAIL PROTECTED]:
 Hi, all:
 The harmony Runtime.exec fails on Linux with ENOMEM.
 Here is the testcase:

 public class Exec {
public static void main(String[] args) throws Exception {

   Runtime.getRuntime().exec(ls);}
 }

I have tried it on RedHat Enterprise 4 and Unbuntu, both get 
ENOMEM

in
 native code.

After digging into it, I found it fails in procimpl.c, line 135:

grdpid = fork ();

If the call to fork is changed to vfork, the testcase will pass 
but
 still get exitcode = 1 which indicates that some error has 
happened. The
 difference between fork and vfork is just whether page tables is 
copied

to
 child process or not. But I do not think it is the main cause. 
Besides,
 vfork has become outdated since it main usage is supplied by fork 
with
 copy-on-write function implemented in modern linux kernel. 
Furthermore,
 vfork is also not so safe as fork. So I do not think it is the 
accepted

way
 to solve the problem.

   I will try whether it can be reproduced on drlvm of linux since 
I am

not
 sure whether it is relevent to VM or classlib. If any drlvm man 
can tell

me
 the result, it can avoid my trouble to build it on linux. :)







 --
 Leo Li
 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]







-
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]

Re: [drlvm] “java.compiler” property

[Tim Ellison]

Alexei Zakharov wrote:
 Moreover, the spec obliges us to do so. The real question is: is it RI
 bug or bug in spec? Personally I am for returning non-null values in
 all cases.

Sure, and I don't think anyone cares too much what value you choose.

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][classlib] thread library - let there be one!

[Tim Ellison]

First step (moving out of luni) looks good to me.

I'd like some more discussion around the second step (picking up drlvm
version) before you do a wholesale replacement.

Regards,
Tim

Weldon Washburn wrote:
 Artem,
 Thanks.  I will take a look.
 
 
 On 10/12/06, Artem Aliev [EMAIL PROTECTED] wrote:

 Guys,


  1.  Make classlib/modules/portlib directory (or portlib in the root?)
  and move hyprt, hysig and hythread code into it. Update build to work
  with new directory.
 
   [Andrey]-  pull out hythread from classlib, make it a shared
 component
 

 The first step is done in JIRA HARMONY-1843.

 I move common, pool, port, thread, sig from luni to new component
 portlib.
 The first idea was to move only port, thread, sig, but they depend on
 common and pool libs. It looks natural to do not produce cyclic
 dependencies among components, so I move these two also to portlib.

 Unfortunately, this does not fully solve two stage luni building
 process (build-native-core and build-native-secondary), but this is
 another problem.

 So If we are still committed on these reorganization, please review
 and apply the patch.

 A move_to_portlib.sh script create portlib directory structure and
 move appropriate files from luni to portlib (by svn move).
 A portlib_files.patch update build to works with new structure.

 Thanks
 Artem




 On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote:
  Guys,
 
  Let me try to make this changes.
 
  Here is my understanding of  the steps I need to do.
 
  1.  Make classlib/modules/portlib directory (or portlib in the root?)
  and move hyprt, hysig and hythread code into it. Update build to work
  with new directory.
 
   [Andrey]-  pull out hythread from classlib, make it a shared
 component
 
  2. Move DRLVM hythread to classlib and update drlvm build for it. So
  both classlib and drlvm will work on the drlvm hythread.
 
   -  split hythread, refine the bottom layer (thrdsup.h and mutex.h)
 and
   upper layer (hythead_xxx)
   -  migrate classlib code to the bottom layer (1) of hythread
  I do not think it is necessary because the hythread will be shared
 library.
  This make sense only in case we move only layer(1) into the shared
 directory.
 
  3. merge hythreads into one library getting bast code from both
 sources.
migrate DRLVM's thread manager to (1) from APR
  Will be done on this stage.
 
  4. merge classlib and drlvm signal handling code.
 
  5. merge port libs code.
 
  6. 
 
  Thanks
  Artem
 
  On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  
   On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
  
On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
   
On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
   
 +1 on the below.

 I am assuming Andrey and his team will do this work.  (Andrey,
 when
 will you
 start?)
   
We have to start first by pulling hythread out, but where?  After
thinking about it for 5 more seconds, putting it on the top level
   
   enhanced/something
   
is IMO a bad idea.  There's nothing worse than going to a
 project's
SVN and finding tons of confusing things.
   
I agree making thread a standalone component at the level of
enhanced/something probably isn't worth doing. What may make a
 sense
is to consider thread a part of the portlib and make the portlib a
separate component at that level. Portlib is the only piece
 which is
shared between VM and classlib, this could justify it's appearance
 at
the high level.
   
   
Is there any downside to keeping it somewhere under
 /classlib/trunk
   
My only guess would be the inability to build VM independently from
the classlib.
  
   Sure, you'll still need either to build the /portlib or the /classlib
  
   
and simply make it a module by itself?
   
If we can not have a portlib as a high level component (like
 classlib
or drlvm), then at least having it as a separate module within
classlib would be nice.
  
   This is one of those things where doing the small step (do it in
   classlib) and then consider the large step (do it as a peer) seems to
   be reasonable, but i don't feel too strongly...
  
   geir
  
   
Thanks,
Andrey.
   
   

 Hopefully we can clean up how drlvm handles the classlib portlib
 function
 table at the same time.  Currently two versions of this table
 are
 created
 during startup.  Portlib function table - let there be one!
 Seriously,
 this is incredibly difficult code to maintain.


 On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote:

 Yes, exactly.

 Regards,
 Tim

 Andrey Chernyshev wrote:
  On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
 
   Weldon, I agree with your comments and observations below.
 Let's
 take
   baby steps to get fully unified.  I'm sure we all want to
 keep 

Re: [drlvm] IPF functionality

[Tim Ellison]

Geir Magnusson Jr. wrote:
 Mikhail Loenko wrote:
 2006/10/16, Tim Ellison [EMAIL PROTECTED]:
 Mikhail Loenko wrote:
  When we bring new platforms how will we make sure that a patch for
 some
  rare platform would not break another one?

 Beyond sniffing the patch to ensure it looks reasonable, the best a
 committer can do is to test it on the platforms he or she has available.
  After that we rely on the diversity of the community building and
 testing the code to catch any problems; i.e. the change doesn't
 necessarily end with the commit, it may still have to be backed out.

 
 And the hope is that we'll have the project's CI system running on lots
 of places.
 
 How will we define which changes should be backed out?
 Do you mean that we first define list of supported platforms
 and then we will roll back all the changes that reportedly break
 build on one of that platform?
 
 Yes - I think that we'll eventually get to that state formally, and
 we're there now informally.  I suspect that a change to support IPF that
 broke x86 would be backed out w/o a complaint :)

Yes, and we've seen that working in practice.

 What would be the procedure to add a new platform to the list of
 supported ones? (Well I assume it's a vote, but what are the criteria
 to be used in that vote?)
 
 I think that having criteria for use in a vote misses the point -
 because otherwise we'd determine based on the criteria and not need to
 vote.
 
 I think that it will be based on having people interested in working on
 it and size of user population.  If we decide that we're going to
 support a platform, it's a lot of work we're taking on

Exactly.  Even for esoteric platforms if we can make it work we should
do so -- i.e. it would always be preferable to move forward by fixing
the code for all platforms than backing out.

This is a problem we don't have at the moment, so I'm not convinced it
is worth hypothesizing a solution.

Regards,
Tim

-- 

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

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

Re: [classlib][luni]Runtime.exec fails on Linux

[Leo Li]

Ya.
What I found is that harmony and IBM VM fails when running Runtime.exec both
on RedHat and Unbuntu. But drlvm seems passes. I have not tried suse.


On 10/16/06, Paulex Yang [EMAIL PROTECTED] wrote:


Geir Magnusson Jr. wrote:
 I'm confused.  Didn't you just report this on Ubuntu?
Let Leo speak for himself, but I thought Leo meant IBM VME + Harmony
classlib failed on Ubuntu and Redhat, but Alexey just reported that both
(VME and DRLVM) works on SUSE, that's why it seems interesting.

 I have had similar forking problems on Ubuntu 6 (I once found a bug in
 classlib related to forking...).

 I never figured out why Unbuntu does this, but it seemed that under
 memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and
 run the test again...
 geir


 Leo Li wrote:
 Thank you.
 I have just run it on drlvm of unbuntu, it works.
 What a qurious problem!


 On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 Both DRLVM and J9 works for me (SUSE9).

 --
 Alexey

 2006/10/16, Leo Li [EMAIL PROTECTED]:
  Hi, all:
  The harmony Runtime.exec fails on Linux with ENOMEM.
  Here is the testcase:
 
  public class Exec {
 public static void main(String[] args) throws Exception {
 
Runtime.getRuntime().exec(ls);}
  }
 
 I have tried it on RedHat Enterprise 4 and Unbuntu, both get
 ENOMEM
 in
  native code.
 
 After digging into it, I found it fails in procimpl.c, line 135:
 
 grdpid = fork ();
 
 If the call to fork is changed to vfork, the testcase will pass
 but
  still get exitcode = 1 which indicates that some error has
 happened. The
  difference between fork and vfork is just whether page tables is
 copied
 to
  child process or not. But I do not think it is the main cause.
 Besides,
  vfork has become outdated since it main usage is supplied by fork
 with
  copy-on-write function implemented in modern linux kernel.
 Furthermore,
  vfork is also not so safe as fork. So I do not think it is the
 accepted
 way
  to solve the problem.
 
I will try whether it can be reproduced on drlvm of linux since
 I am
 not
  sure whether it is relevent to VM or classlib. If any drlvm man
 can tell
 me
  the result, it can avoid my trouble to build it on linux. :)
 
 
 
 
 
 
 
  --
  Leo Li
  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]





 -
 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]





--
Leo Li
China Software Development Lab, IBM

Re: [classlib][luni]Runtime.exec fails on Linux

[Leo Li]

It seems not quite related to actual memory stress although the reported
error is ENOMEM.
I have run it both in eclipse and console. And there are enough memory
available.

Furthermore, the case can be repeated even though in the same time a C
program runs well when using fork().

I suspect that it is related with VM since it can be only reproduced by VM
calling it. I am not sure whether vm does something behind me, but I have
not thought out of a way that a user-space program have such effect.:)


On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


I'm confused.  Didn't you just report this on Ubuntu?

I have had similar forking problems on Ubuntu 6 (I once found a bug in
classlib related to forking...).

I never figured out why Unbuntu does this, but it seemed that under
memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and run
the test again...

geir


Leo Li wrote:
 Thank you.
 I have just run it on drlvm of unbuntu, it works.
 What a qurious problem!


 On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 Both DRLVM and J9 works for me (SUSE9).

 --
 Alexey

 2006/10/16, Leo Li [EMAIL PROTECTED]:
  Hi, all:
  The harmony Runtime.exec fails on Linux with ENOMEM.
  Here is the testcase:
 
  public class Exec {
 public static void main(String[] args) throws Exception {
 
Runtime.getRuntime().exec(ls);}
  }
 
 I have tried it on RedHat Enterprise 4 and Unbuntu, both get
ENOMEM
 in
  native code.
 
 After digging into it, I found it fails in procimpl.c, line 135:
 
 grdpid = fork ();
 
 If the call to fork is changed to vfork, the testcase will pass
but
  still get exitcode = 1 which indicates that some error has happened.
 The
  difference between fork and vfork is just whether page tables is
copied
 to
  child process or not. But I do not think it is the main cause.
Besides,
  vfork has become outdated since it main usage is supplied by fork
with
  copy-on-write function implemented in modern linux kernel.
Furthermore,
  vfork is also not so safe as fork. So I do not think it is the
accepted
 way
  to solve the problem.
 
I will try whether it can be reproduced on drlvm of linux since I
am
 not
  sure whether it is relevent to VM or classlib. If any drlvm man can
 tell
 me
  the result, it can avoid my trouble to build it on linux. :)
 
 
 
 
 
 
 
  --
  Leo Li
  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]





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





--
Leo Li
China Software Development Lab, IBM

Re: [classlib]Self-host of Derby

[Leo Li]

1. Pls see if the command-line has security management on. Current Harmony
seems not compatible with such option.

2. Pls try this stand-alone java program if it runs to set aside the
environment of Derby test:

public class testConnection {
private static final String dbURL =jdbc:derby:MyDbTest;
private static Connection conn = null;

public static void main(String[] args) throws Exception{

 Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance();
 conn = DriverManager.getConnection(dbURL+;create=true);
 System.out.println(DB created);
  conn.close();
  }

}

*add the classes you built to the classpath



On 10/16/06, Spark Shen [EMAIL PROTECTED] wrote:


Alex Luo 写道:
 Hello:
 I have build derby successfully on RI. But when I tried to run the
 following derby's test on Harmony, it failed.
 *java -Dframework=DerbyNetClient
 org.apache.derbyTesting.functionTests.harness.RunTest
 lang/supersimple.sql *
 Btw, this test passed on RI.
Would you try eliminate -Dframework=DerbyNetClient?

Best regards

 (1) If the VM is J9vm, at first the test can't even be launched. After
 applying the Sian's patch, this error seems to be fixed.
 But the test still failed because of a strange reason, the error
 report is described as following:

 *java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedDriver
 at java.lang.Class.forName(Class.java:129)
 at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source)
 at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
 at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
 at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source)
 at org.apache.derby.impl.tools.ij.utilMain.init(Unknown Source)
 at org.apache.derby.impl.tools.ij.utilMain14.init(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.init(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
 at org.apache.derby.tools.ij.main(Unknown Source)
 at org.apache.derbyTesting.functionTests.harness.RunIJ.run(RunIJ.java
:45)
 at java.lang.Thread.run(Thread.java:872)
 ij version 10.1
 ij -- by default, holdability of ResultSet objects created using this
 Connection object is true. Following will set it to false for this
 connection.
 NoHoldForConnection;
 IJ ERROR: Unable to establish connection
 ij create table a (a int);
 IJ ERROR: Unable to establish connection *

 I find that the class *org.apache.derby.jdbc.EmbeddedDriver * exists,
 and I have included this class in ClassPath.
 I write a simple test to load this class, it works.


 (2) If the VM is DRLVM, the test can't be launched, I paste the error
 report in command line here:

 *Failure to open JIT dll
 D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\
 jre\bin/default/\jitrino.dll-1073021795
 apr code: Unknown error

 An unhandled error (4) has occurred.
 HyGeneric_Signal_Number=0004
 ExceptionCode=c005
 ExceptionAddress=006FC875
 ContextFlags=0001003f
 Handler1=00401010
 Handler2=11105CE0
 InaccessibleAddress=CDCDCDD1
 EDI=0013F178
 ESI=0013F0CC
 EAX=01301794
 EBX=0002
 ECX=CDCDCDCD
 EDX=CDCDCDCD
 EIP=006FC875
 ESP=0013F0C8
 EBP=0013F0D4

Module=D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\default\h

 armonyvm.dll
 Module_base_address=0051
 Offset_in_DLL=001ec875

 This application has requested the Runtime to terminate it in an
 unusual way.
 Please contact the application's support team for more information. *

 Has anybody ever met the same problem?


 Leo Li wrote:
 Hi, all:
 I now plan to make the self-host of Derby on Harmony.
 Is there anyone interested in this topic?

 Here is what I encountered in the process. Hope it will be helpful to
 anybody who is interested in it.

 At first, the testcases even fails on RI both on windows and ubuntu and
 the result are different.???
 After some struggiling, I have successfully passed the provided
 testcases on RI after I rebuild the source on my machine.
 But there still remains a problem:
 The derby team kindly rewrite the launcher for testcases in order to
 treat J9 vm differently if the property java.vm.name starts with
 j9. But
 the j9 vm used in Harmony has been customized thus is different from
 traditional j9 vm that is expected by derby. This leads to failure to
 launch
 tests.
 I will talk on Derby's mailing list to find a solution.



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




--
Spark Shen
China Software Development Lab, IBM


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

Re: [drlvm][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Geir Magnusson Jr.]

Egor Pasko wrote:

On the 0x202 day of Apache Harmony Geir Magnusson, Jr. wrote:

Egor Pasko wrote:

Harmoniers,
Thanks to Mikhail Fursov, George Timoshenko, Nikolay Sidelnikov (and
me, of course:) all critical bugs (as in [1]) in Jitrino.OPT have
their fixing patches and I like them. I think, it is a good step
forward to enabling the self-hosting environment.
Here are the champions:
+ HARMONY-1774 (fixes also HARMONY-1773,  HARMONY-1775)

Applied.  IMO, doesn't fix 1775


Now the fix is available for 1775, see JIRA for more details..


I'm testing it, but jitrino finalizer smoke test consistently fails 
now... testing...



[snip]



-
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] “java.compiler” property

[Geir Magnusson Jr.]

+1

Mikhail Fursov wrote:

On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote:


Moreover, the spec obliges us to do so. The real question is: is it RI
bug or bug in spec? Personally I am for returning non-null values in
all cases.



I agree. Just tell me and I will commit the patch for EM(interpreter) and
JIT modes.
BTW I think that we should create interpreter.emconf file and place all VM
properties needed for interpreter into this file.
So, in future, when we need to add more interpreter-mode option, we will 
not

affect the EM C++ code.




-
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][luni]Runtime.exec fails on Linux

[Geir Magnusson Jr.]

Paulex Yang wrote:

Geir Magnusson Jr. wrote:

I'm confused.  Didn't you just report this on Ubuntu?
Let Leo speak for himself, but I thought Leo meant IBM VME + Harmony 
classlib failed on Ubuntu and Redhat, but Alexey just reported that both 
(VME and DRLVM) works on SUSE, that's why it seems interesting.


I understand that based on my experience with fork() and ubuntu under 
memory load...


geir



I have had similar forking problems on Ubuntu 6 (I once found a bug in 
classlib related to forking...).


I never figured out why Unbuntu does this, but it seemed that under 
memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and 
run the test again...

geir


Leo Li wrote:

Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!


On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:


Both DRLVM and J9 works for me (SUSE9).

--
Alexey

2006/10/16, Leo Li [EMAIL PROTECTED]:
 Hi, all:
 The harmony Runtime.exec fails on Linux with ENOMEM.
 Here is the testcase:

 public class Exec {
public static void main(String[] args) throws Exception {

   Runtime.getRuntime().exec(ls);}
 }

I have tried it on RedHat Enterprise 4 and Unbuntu, both get 
ENOMEM

in
 native code.

After digging into it, I found it fails in procimpl.c, line 135:

grdpid = fork ();

If the call to fork is changed to vfork, the testcase will pass 
but
 still get exitcode = 1 which indicates that some error has 
happened. The
 difference between fork and vfork is just whether page tables is 
copied

to
 child process or not. But I do not think it is the main cause. 
Besides,
 vfork has become outdated since it main usage is supplied by fork 
with
 copy-on-write function implemented in modern linux kernel. 
Furthermore,
 vfork is also not so safe as fork. So I do not think it is the 
accepted

way
 to solve the problem.

   I will try whether it can be reproduced on drlvm of linux since 
I am

not
 sure whether it is relevent to VM or classlib. If any drlvm man 
can tell

me
 the result, it can avoid my trouble to build it on linux. :)







 --
 Leo Li
 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]







-
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][classlib] thread library - let there be one!

[Geir Magnusson Jr.]

Tim Ellison wrote:

First step (moving out of luni) looks good to me.

I'd like some more discussion around the second step (picking up drlvm
version) before you do a wholesale replacement.


Yes please.  Lets do small, reversible steps.

geir



Regards,
Tim

Weldon Washburn wrote:

Artem,
Thanks.  I will take a look.


On 10/12/06, Artem Aliev [EMAIL PROTECTED] wrote:

Guys,



1.  Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.


[Andrey]-  pull out hythread from classlib, make it a shared

component
The first step is done in JIRA HARMONY-1843.

I move common, pool, port, thread, sig from luni to new component
portlib.
The first idea was to move only port, thread, sig, but they depend on
common and pool libs. It looks natural to do not produce cyclic
dependencies among components, so I move these two also to portlib.

Unfortunately, this does not fully solve two stage luni building
process (build-native-core and build-native-secondary), but this is
another problem.

So If we are still committed on these reorganization, please review
and apply the patch.

A move_to_portlib.sh script create portlib directory structure and
move appropriate files from luni to portlib (by svn move).
A portlib_files.patch update build to works with new structure.

Thanks
Artem




On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote:

Guys,

Let me try to make this changes.

Here is my understanding of  the steps I need to do.

1.  Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.


[Andrey]-  pull out hythread from classlib, make it a shared

component

2. Move DRLVM hythread to classlib and update drlvm build for it. So
both classlib and drlvm will work on the drlvm hythread.


-  split hythread, refine the bottom layer (thrdsup.h and mutex.h)

and

upper layer (hythead_xxx)
-  migrate classlib code to the bottom layer (1) of hythread

I do not think it is necessary because the hythread will be shared

library.

This make sense only in case we move only layer(1) into the shared

directory.

3. merge hythreads into one library getting bast code from both

sources.

 migrate DRLVM's thread manager to (1) from APR

Will be done on this stage.

4. merge classlib and drlvm signal handling code.

5. merge port libs code.

6. 

Thanks
Artem

On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:


On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:


+1 on the below.

I am assuming Andrey and his team will do this work.  (Andrey,

when

will you
start?)

We have to start first by pulling hythread out, but where?  After
thinking about it for 5 more seconds, putting it on the top level

   enhanced/something

is IMO a bad idea.  There's nothing worse than going to a

project's

SVN and finding tons of confusing things.

I agree making thread a standalone component at the level of
enhanced/something probably isn't worth doing. What may make a

sense

is to consider thread a part of the portlib and make the portlib a
separate component at that level. Portlib is the only piece

which is

shared between VM and classlib, this could justify it's appearance

at

the high level.


Is there any downside to keeping it somewhere under

/classlib/trunk

My only guess would be the inability to build VM independently from
the classlib.

Sure, you'll still need either to build the /portlib or the /classlib


and simply make it a module by itself?

If we can not have a portlib as a high level component (like

classlib

or drlvm), then at least having it as a separate module within
classlib would be nice.

This is one of those things where doing the small step (do it in
classlib) and then consider the large step (do it as a peer) seems to
be reasonable, but i don't feel too strongly...

geir


Thanks,
Andrey.


Hopefully we can clean up how drlvm handles the classlib portlib
function
table at the same time.  Currently two versions of this table

are

created
during startup.  Portlib function table - let there be one!
Seriously,
this is incredibly difficult code to maintain.


On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote:

Yes, exactly.

Regards,
Tim

Andrey Chernyshev wrote:

On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:


Weldon, I agree with your comments and observations below.

Let's
take

baby steps to get fully unified.  I'm sure we all want to

keep things

working throughout.

So what's the first stop?  Move hythread as-is out of

classlib

to a

peer in the tree?

I can suggest the following steps:
-  pull out hythread from classlib, make it a shared

component

-  split hythread, refine the bottom layer (thrdsup.h and

mutex.h) and

upper layer 

Re: [classlib][luni]Runtime.exec fails on Linux

[Geir Magnusson Jr.]

Leo Li wrote:

It seems not quite related to actual memory stress although the reported
error is ENOMEM.
I have run it both in eclipse and console. And there are enough memory
available.

Furthermore, the case can be repeated even though in the same time a C
program runs well when using fork().

I suspect that it is related with VM since it can be only reproduced by VM
calling it. I am not sure whether vm does something behind me, but I have
not thought out of a way that a user-space program have such effect.:)


I used to be able to consistently reproduce a similar bug (fork() 
failing...) by just having eclipse running at the same time.


IOW, with no other programs running, the fork() worked.  With Eclipse 
running, it failed.


The only thing I could think of was that there was some problem with 
ulimit that I never could figure out...


geir




On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


I'm confused.  Didn't you just report this on Ubuntu?

I have had similar forking problems on Ubuntu 6 (I once found a bug in
classlib related to forking...).

I never figured out why Unbuntu does this, but it seemed that under
memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and run
the test again...

geir


Leo Li wrote:
 Thank you.
 I have just run it on drlvm of unbuntu, it works.
 What a qurious problem!


 On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 Both DRLVM and J9 works for me (SUSE9).

 --
 Alexey

 2006/10/16, Leo Li [EMAIL PROTECTED]:
  Hi, all:
  The harmony Runtime.exec fails on Linux with ENOMEM.
  Here is the testcase:
 
  public class Exec {
 public static void main(String[] args) throws Exception {
 
Runtime.getRuntime().exec(ls);}
  }
 
 I have tried it on RedHat Enterprise 4 and Unbuntu, both get
ENOMEM
 in
  native code.
 
 After digging into it, I found it fails in procimpl.c, line 135:
 
 grdpid = fork ();
 
 If the call to fork is changed to vfork, the testcase will pass
but
  still get exitcode = 1 which indicates that some error has happened.
 The
  difference between fork and vfork is just whether page tables is
copied
 to
  child process or not. But I do not think it is the main cause.
Besides,
  vfork has become outdated since it main usage is supplied by fork
with
  copy-on-write function implemented in modern linux kernel.
Furthermore,
  vfork is also not so safe as fork. So I do not think it is the
accepted
 way
  to solve the problem.
 
I will try whether it can be reproduced on drlvm of linux since I
am
 not
  sure whether it is relevent to VM or classlib. If any drlvm man can
 tell
 me
  the result, it can avoid my trouble to build it on linux. :)
 
 
 
 
 
 
 
  --
  Leo Li
  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]





-
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] IPF functionality

[Mikhail Loenko]

2006/10/16, Geir Magnusson Jr. [EMAIL PROTECTED]:



Mikhail Loenko wrote:
 2006/10/16, Tim Ellison [EMAIL PROTECTED]:
 Mikhail Loenko wrote:
  When we bring new platforms how will we make sure that a patch for some
  rare platform would not break another one?

 Beyond sniffing the patch to ensure it looks reasonable, the best a
 committer can do is to test it on the platforms he or she has available.
  After that we rely on the diversity of the community building and
 testing the code to catch any problems; i.e. the change doesn't
 necessarily end with the commit, it may still have to be backed out.


And the hope is that we'll have the project's CI system running on lots
of places.

 How will we define which changes should be backed out?
 Do you mean that we first define list of supported platforms
 and then we will roll back all the changes that reportedly break
 build on one of that platform?

Yes - I think that we'll eventually get to that state formally, and
we're there now informally.  I suspect that a change to support IPF that
broke x86 would be backed out w/o a complaint :)


 What would be the procedure to add a new platform to the list of
 supported ones? (Well I assume it's a vote, but what are the criteria
 to be used in that vote?)

I think that having criteria for use in a vote misses the point -
because otherwise we'd determine based on the criteria and not need to vote.


So, you mean that criteria is judgement? ;)
Somehow it works...

Thanks,
Mikhail




I think that it will be based on having people interested in working on
it and size of user population.  If we decide that we're going to
support a platform, it's a lot of work we're taking on

geir



 Thanks,
 Mikhail


 There is no guarantee of the stability of HEAD, we only get that by
 taking a snapshot and everyone testing it with all platforms (c.f. say
 Eclipse that does have a centralized build system).

 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]



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


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




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

Re: [drlvm][classlib] thread library - let there be one!

[Artem Aliev]

Tim,

Reading through discussion, I find two option for the second step.
Let's discuss them.

1.

-  split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
upper layer (hythead_xxx)
-  migrate classlib code to the bottom layer (1) of hythread

Then move the rest of hythread to VM.

In this case we will move all VM releated functionality out of a classlib.
The classlib will use tls, mutex and thread_create from *.h files.
VM will be free to implement threading in any way.

2. Move hythread out from the drlvm to a portlib.
In this case  classlib will contains a lot of only VM releated code.
So we will meet the same problems with an new VM.  But we will have
common place for all synchronization primitives and could control
them.

Thanks
Artem





On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:



Tim Ellison wrote:
 First step (moving out of luni) looks good to me.

 I'd like some more discussion around the second step (picking up drlvm
 version) before you do a wholesale replacement.

Yes please.  Lets do small, reversible steps.

geir


 Regards,
 Tim

 Weldon Washburn wrote:
 Artem,
 Thanks.  I will take a look.


 On 10/12/06, Artem Aliev [EMAIL PROTECTED] wrote:
 Guys,


 1.  Make classlib/modules/portlib directory (or portlib in the root?)
 and move hyprt, hysig and hythread code into it. Update build to work
 with new directory.

 [Andrey]-  pull out hythread from classlib, make it a shared
 component
 The first step is done in JIRA HARMONY-1843.

 I move common, pool, port, thread, sig from luni to new component
 portlib.
 The first idea was to move only port, thread, sig, but they depend on
 common and pool libs. It looks natural to do not produce cyclic
 dependencies among components, so I move these two also to portlib.

 Unfortunately, this does not fully solve two stage luni building
 process (build-native-core and build-native-secondary), but this is
 another problem.

 So If we are still committed on these reorganization, please review
 and apply the patch.

 A move_to_portlib.sh script create portlib directory structure and
 move appropriate files from luni to portlib (by svn move).
 A portlib_files.patch update build to works with new structure.

 Thanks
 Artem




 On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote:
 Guys,

 Let me try to make this changes.

 Here is my understanding of  the steps I need to do.

 1.  Make classlib/modules/portlib directory (or portlib in the root?)
 and move hyprt, hysig and hythread code into it. Update build to work
 with new directory.

 [Andrey]-  pull out hythread from classlib, make it a shared
 component
 2. Move DRLVM hythread to classlib and update drlvm build for it. So
 both classlib and drlvm will work on the drlvm hythread.

 -  split hythread, refine the bottom layer (thrdsup.h and mutex.h)
 and
 upper layer (hythead_xxx)
 -  migrate classlib code to the bottom layer (1) of hythread
 I do not think it is necessary because the hythread will be shared
 library.
 This make sense only in case we move only layer(1) into the shared
 directory.
 3. merge hythreads into one library getting bast code from both
 sources.
  migrate DRLVM's thread manager to (1) from APR
 Will be done on this stage.

 4. merge classlib and drlvm signal handling code.

 5. merge port libs code.

 6. 

 Thanks
 Artem

 On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:

 On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:

 +1 on the below.

 I am assuming Andrey and his team will do this work.  (Andrey,
 when
 will you
 start?)
 We have to start first by pulling hythread out, but where?  After
 thinking about it for 5 more seconds, putting it on the top level

enhanced/something

 is IMO a bad idea.  There's nothing worse than going to a
 project's
 SVN and finding tons of confusing things.
 I agree making thread a standalone component at the level of
 enhanced/something probably isn't worth doing. What may make a
 sense
 is to consider thread a part of the portlib and make the portlib a
 separate component at that level. Portlib is the only piece
 which is
 shared between VM and classlib, this could justify it's appearance
 at
 the high level.

 Is there any downside to keeping it somewhere under
 /classlib/trunk
 My only guess would be the inability to build VM independently from
 the classlib.
 Sure, you'll still need either to build the /portlib or the /classlib

 and simply make it a module by itself?
 If we can not have a portlib as a high level component (like
 classlib
 or drlvm), then at least having it as a separate module within
 classlib would be nice.
 This is one of those things where doing the small step (do it in
 classlib) and then consider the large step (do it as a peer) seems to
 be reasonable, but i don't feel too strongly...

 geir

 Thanks,
 Andrey.

 Hopefully we can clean up how drlvm handles the 

Re: [drlvm] IPF functionality

[Mikhail Loenko]

2006/10/16, Tim Ellison [EMAIL PROTECTED]:

Geir Magnusson Jr. wrote:
 Mikhail Loenko wrote:
 2006/10/16, Tim Ellison [EMAIL PROTECTED]:
 Mikhail Loenko wrote:
  When we bring new platforms how will we make sure that a patch for
 some
  rare platform would not break another one?

 Beyond sniffing the patch to ensure it looks reasonable, the best a
 committer can do is to test it on the platforms he or she has available.
  After that we rely on the diversity of the community building and
 testing the code to catch any problems; i.e. the change doesn't
 necessarily end with the commit, it may still have to be backed out.


 And the hope is that we'll have the project's CI system running on lots
 of places.

 How will we define which changes should be backed out?
 Do you mean that we first define list of supported platforms
 and then we will roll back all the changes that reportedly break
 build on one of that platform?

 Yes - I think that we'll eventually get to that state formally, and
 we're there now informally.  I suspect that a change to support IPF that
 broke x86 would be backed out w/o a complaint :)

Yes, and we've seen that working in practice.

 What would be the procedure to add a new platform to the list of
 supported ones? (Well I assume it's a vote, but what are the criteria
 to be used in that vote?)

 I think that having criteria for use in a vote misses the point -
 because otherwise we'd determine based on the criteria and not need to
 vote.

 I think that it will be based on having people interested in working on
 it and size of user population.  If we decide that we're going to
 support a platform, it's a lot of work we're taking on

Exactly.  Even for esoteric platforms if we can make it work we should
do so -- i.e. it would always be preferable to move forward by fixing
the code for all platforms than backing out.

This is a problem we don't have at the moment, so I'm not convinced it
is worth hypothesizing a solution.


Isn't it time to define the official set of supported platforms? ;)

Thanks,
Mikhail



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]




-
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][threading] Possible race condition in implementation of conditional variables?

[Artem Aliev]

Weldon,

Ok, I'll try to do something like you describe.
But it is not very easy to do, I think.

Thanks
Artem

On 10/15/06, Weldon Washburn [EMAIL PROTECTED] wrote:

After thinking about it a while, how about the following course of action:

1)
First phase is to modify hysem_wait() and any other hy blocking
functions to test if, in fact, the thread is in suspend enabled mode.  If
the thread is not,  do something like a printf(WARNING: root set
enumeration is unstable, hytsem.cpp line #285\n);  Then do a
non-destructive stack unwind and printf a stack trace

An even better idea would be to log the printf's out to a file that can
later be retrieved.

2)
Second phase.  Analyze the code paths that lead to the enable/disable
problems.  Are there fundamental design flaws?  Implementation flaws?

3)
Third phase.  Assume the above turns up easy to fix bugs and minor
architectural issues.  And that these issues are settled.  Then commit a mod
to svn that will cause the system to do an assert(0); in debug mode and exit
w/ stack trace in release mode.

Artem,
Does it make sense for you to create a patch that does the above??


On 10/13/06, Artem Aliev [EMAIL PROTECTED] wrote:

 A classloader and some other components assume that semaphores and
 latches does not reset suspend disable count and some time ago latches
 and semaphores work this way.
 A java monitor ,in reverse, resets the suspend disable status in
 monitorEnter and monitor_wait command, and DRLVM takes care about it.
 It looks like someone changed the behavior of semaphores to be
 compatible with the monitors.

 I agree with Xiao-Feng: the sleeping thread should be in suspend_enable
 mode.
 So I vote for leaving the current threading code as is but checking
 DRLVM for a code that not ready for the new behavior.

 For example by putting assert(gc enabled ==  true() and checking failed
 places.

 Thanks
 Artem


 On 10/13/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
  GC should be enabled in waiting state. In case that a GC can happen,
  the code should do bookkeeping to guarantee the correctness.
 
  Thanks,
  xiaofeng
 
  On 10/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
   Hi,
  
   I do the following:
  
   hythread_suspend_disable();
   do unsafe actions
   hysem_wait(semaphore);
   do unsafe actions
   hythread_suspend_enable();
  
   By saying hythread_suspend_disable(); I expect the thread can't be
   suspended until hythread_suspend_enable() is called. But hysem_wait()
   resets disabled mode and enables thread suspension. As a result GC can
   happen when it must not. hysem_wait is based on conditional variables
   so the same can happen when conditional variables is used.
  
   Do you see the problem here? Or I miss something?
  
   Thanks
   Evgueni
  
   -
   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]




--
Weldon Washburn
Intel Middleware Products Division




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

Hot to Write GC requires improvement

[Konovalova, Svetlana]

Folks,

I took a close look at Hot to Write GC [1] and created a patch for this doc 
[JIRA 1881]. I fixed formatting, brushed up the code, removed out-dated tags 
etc.
It would be great if someone can find a chance to look at the patch. 

Thanks in advance!

 [1] http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html 
 [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881


Cheers,
Sveta Konovalova 

-
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] IPF functionality

[Mikhail Fursov]

On 10/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:



Isn't it time to define the official set of supported platforms? ;)



After reading the neighbour threads about hardware available for commiters
and precommit criteria I think that we have no officially supported
platforms today (and IMO this is wrong).

What is the difference in your vision between official supported and
official not supported platforms?


--
Mikhail Fursov

Re: [classlib][beans] RI inconsistency in EventHandler

[Tim Ellison]

I'm fine with marking it as a non-bug difference, with the option to fix
it if we find some compelling application that relies on this non-spec
behavior.  Is that weasely enough?

Regards,
Tim

Alexei Zakharov wrote:
 Hi Tim,
 
 -- persuasion starts here
 
 Let me cite the spec describing design patterns for properties,
 JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
 
 ---
 8.3 Design Patterns for Properties
 
 8.3.1 Simple properties
 By default, we use design patterns to locate properties by looking for
 methods of the form:
 
 public PropertyType getPropertyName();
 public void setPropertyName(PropertyType a);
 
 8.3.2 Boolean properties
 In addition, for boolean properties, we allow a
 
 public boolean isPropertyName();
 
 8.3.3 Indexed properties
 If we find a property whose type is an array PropertyElement[],
 then we also look for methods of the form:
 
 public PropertyElement getPropertyName(int a);
 public void setPropertyName(int a, PropertyElement b);
 ---
 
 So we have only three design patterns specified for properties. That's
 all. I didn't found any mentioning about any extra design patterns and
 I've never heard anything about setDefaults() or smth. like it.
 
 On the other hand, if I understand things correctly the Introspector
 class should be the decision-making center for such type of things.
 I.e. if Introspector says there is no properties then there should be
 no properties. RI doesn't seem to be using Introspector in the example
 I've described ealier. Thus I still think it looks like RI bug.
 
 -- end of persuasion
 
 Thanks and regards,
 
 2006/10/14, Tim Ellison [EMAIL PROTECTED]:
 That is strange behavior, since as you point out it does not set a
 parametrized value, however, I wonder if there is some assumption that
 the setFoo() method may be a mutator anyway, e.g. setDefaults() or
 something like that?  Just guessing.

 In this case it may be safer to follow the RI -- but I'm open to
 persuasion.

 Regards,
 Tim

 Alexei Zakharov wrote:
  Hi all,
 
  Let me disturb you with another boring RI inconsistency in beans
  –type of message. :) It seems I found a bug in RI.  In
  java.beans.EventHandler. I think RI incorrectly determines properties
  here. According to spec, common sense and even the RI's implementation
  of java.beans.Introspector the following bean should not contain any
  properties:
 
 public static class MyBean {
 public void setProp1() {}
 }
 
  because setProp1() is not a valid setter method – it does not
  contain a new value to set.
  However, the following test fails on RI:
 
  ---
  import java.beans.*;
 
  public class TestBeanInfo1 {
 public static class MyBean {
 public void setProp1() {}
 }
 
 public static void main(String argv[]) throws Exception {
 MyBean bean = new MyBean();
 // prop1 is neither the name of writeable property nor the
  name of any public method
 Object proxy = EventHandler.create(
 PropertyChangeListener.class, bean, prop1);
 
 // just to show that Introspector doesn't see the property
  with name prop1
 PropertyDescriptor[] pds =
 Introspector.getBeanInfo(MyBean.class,
 Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
 for (int i = 0; i  pds.length; i++) {
 System.out.println(Property found:  + pds[i].getName());
 }
 
 // should throw exception
 try {
 ((PropertyChangeListener) proxy).propertyChange(
 new PropertyChangeEvent(bean, prop1, 1, 2));
 System.out.println(FAIL);
 } catch (Throwable t) {
 System.out.println(PASS);
 }
 }
  }
  ---
 
  So it determines prop1 as a valid property. IMHO this behavior is
  inconsistent and we should not follow RI. But I like to hear opinions
  from the rest of the community.
 
  Thanks,
 
 

-- 

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

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

Re: [drlvm] “java.compiler” property

[Alexei Zakharov]

I agree. Just tell me and I will commit the patch for EM(interpreter) and
JIT modes.


I agree it will be better if you do this since I'm not very familiar
with DRLVM code yet. So +1 for you to go ahead.

Regards,

2006/10/16, Mikhail Fursov [EMAIL PROTECTED]:

On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote:

 Moreover, the spec obliges us to do so. The real question is: is it RI
 bug or bug in spec? Personally I am for returning non-null values in
 all cases.


I agree. Just tell me and I will commit the patch for EM(interpreter) and
JIT modes.
BTW I think that we should create interpreter.emconf file and place all VM
properties needed for interpreter into this file.
So, in future, when we need to add more interpreter-mode option, we will not
affect the EM C++ code.



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

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

Re: [classlib][auth]LoginContext should always invoke the LoginModules?

[Tim Ellison]

Stepan Mishura wrote:
 On 10/14/06, Tim Ellison wrote:
 Stepan Mishura wrote:
  So we have following suggestions:
 
  1) leave the check and document the difference with RI
  2) follow RI and put a warning

 What warning did you have in mind?  And don't say j.u.logging 'cos I can
 find out where you live you know :-)
 
 I meant adding a warning to javadoc for login() method.

Phew g.  I think #2 is the right answer, it maintains compatibility.

Regards,
Tim

-- 

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

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

Re: [classlib]Self-host of Derby

[Alex Luo]

Spark Shen wrote:

Alex Luo 写道:

Hello:
I have build derby successfully on RI. But when I tried to run the 
following derby's test on Harmony, it failed.
*java -Dframework=DerbyNetClient 
org.apache.derbyTesting.functionTests.harness.RunTest 
lang/supersimple.sql *

Btw, this test passed on RI.

Would you try eliminate -Dframework=DerbyNetClient?

Best regards

Yes, I did. But the result is the same as before.


(1) If the VM is J9vm, at first the test can't even be launched. 
After applying the Sian's patch, this error seems to be fixed.
But the test still failed because of a strange reason, the error 
report is described as following:


*java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedDriver
at java.lang.Class.forName(Class.java:129)
at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source)
at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.init(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain14.init(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.init(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
at 
org.apache.derbyTesting.functionTests.harness.RunIJ.run(RunIJ.java:45)

at java.lang.Thread.run(Thread.java:872)
ij version 10.1
ij -- by default, holdability of ResultSet objects created using 
this Connection object is true. Following will set it to false for 
this connection.

NoHoldForConnection;
IJ ERROR: Unable to establish connection
ij create table a (a int);
IJ ERROR: Unable to establish connection *

I find that the class *org.apache.derby.jdbc.EmbeddedDriver * exists, 
and I have included this class in ClassPath.

I write a simple test to load this class, it works.


(2) If the VM is DRLVM, the test can't be launched, I paste the error 
report in command line here:


*Failure to open JIT dll 
D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\

jre\bin/default/\jitrino.dll-1073021795
apr code: Unknown error

An unhandled error (4) has occurred.
HyGeneric_Signal_Number=0004
ExceptionCode=c005
ExceptionAddress=006FC875
ContextFlags=0001003f
Handler1=00401010
Handler2=11105CE0
InaccessibleAddress=CDCDCDD1
EDI=0013F178
ESI=0013F0CC
EAX=01301794
EBX=0002
ECX=CDCDCDCD
EDX=CDCDCDCD
EIP=006FC875
ESP=0013F0C8
EBP=0013F0D4
Module=D:\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\default\h 


armonyvm.dll
Module_base_address=0051
Offset_in_DLL=001ec875

This application has requested the Runtime to terminate it in an 
unusual way.

Please contact the application's support team for more information. *

Has anybody ever met the same problem?


Leo Li wrote:

Hi, all:
I now plan to make the self-host of Derby on Harmony.
Is there anyone interested in this topic?

Here is what I encountered in the process. Hope it will be helpful to
anybody who is interested in it.

At first, the testcases even fails on RI both on windows and ubuntu and
the result are different.???
After some struggiling, I have successfully passed the provided
testcases on RI after I rebuild the source on my machine.
But there still remains a problem:
The derby team kindly rewrite the launcher for testcases in order to
treat J9 vm differently if the property java.vm.name starts with 
j9. But

the j9 vm used in Harmony has been customized thus is different from
traditional j9 vm that is expected by derby. This leads to failure 
to launch

tests.
I will talk on Derby's mailing list to find a solution.




-
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] “java.compiler” property

[Mikhail Fursov]

Ok, if nobody minds I take this task and will provide the patch in a day or
two.

On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote:


 I agree. Just tell me and I will commit the patch for EM(interpreter)
and
 JIT modes.

I agree it will be better if you do this since I'm not very familiar
with DRLVM code yet. So +1 for you to go ahead.

Regards,

2006/10/16, Mikhail Fursov [EMAIL PROTECTED]:
 On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
 
  Moreover, the spec obliges us to do so. The real question is: is it RI
  bug or bug in spec? Personally I am for returning non-null values in
  all cases.


 I agree. Just tell me and I will commit the patch for EM(interpreter)
and
 JIT modes.
 BTW I think that we should create interpreter.emconf file and place all
VM
 properties needed for interpreter into this file.
 So, in future, when we need to add more interpreter-mode option, we will
not
 affect the EM C++ code.


--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

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





--
Mikhail Fursov

Re: [drlvm] IPF functionality

[Mikhail Loenko]

2006/10/16, Mikhail Fursov [EMAIL PROTECTED]:

On 10/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:


 Isn't it time to define the official set of supported platforms? ;)


After reading the neighbour threads about hardware available for commiters
and precommit criteria I think that we have no officially supported
platforms today (and IMO this is wrong).

What is the difference in your vision between official supported and
official not supported platforms?


IMHO the difference is we back commit if it breaks officially supported
platform and not necessarily do if it breaks unsupported one

Thanks,
Mikhail




--
Mikhail Fursov




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

Re: [classlib][beans] RI inconsistency in EventHandler

[Alexei Zakharov]

I am ok with this. :) Will file a JIRA soon.

Regards,

2006/10/16, Tim Ellison [EMAIL PROTECTED]:

I'm fine with marking it as a non-bug difference, with the option to fix
it if we find some compelling application that relies on this non-spec
behavior.  Is that weasely enough?

Regards,
Tim

Alexei Zakharov wrote:
 Hi Tim,

 -- persuasion starts here

 Let me cite the spec describing design patterns for properties,
 JavaBeans spec v1.01-A (Aug 8, 1997), page 55:

 ---
 8.3 Design Patterns for Properties

 8.3.1 Simple properties
 By default, we use design patterns to locate properties by looking for
 methods of the form:

 public PropertyType getPropertyName();
 public void setPropertyName(PropertyType a);

 8.3.2 Boolean properties
 In addition, for boolean properties, we allow a

 public boolean isPropertyName();

 8.3.3 Indexed properties
 If we find a property whose type is an array PropertyElement[],
 then we also look for methods of the form:

 public PropertyElement getPropertyName(int a);
 public void setPropertyName(int a, PropertyElement b);
 ---

 So we have only three design patterns specified for properties. That's
 all. I didn't found any mentioning about any extra design patterns and
 I've never heard anything about setDefaults() or smth. like it.

 On the other hand, if I understand things correctly the Introspector
 class should be the decision-making center for such type of things.
 I.e. if Introspector says there is no properties then there should be
 no properties. RI doesn't seem to be using Introspector in the example
 I've described ealier. Thus I still think it looks like RI bug.

 -- end of persuasion

 Thanks and regards,

 2006/10/14, Tim Ellison [EMAIL PROTECTED]:
 That is strange behavior, since as you point out it does not set a
 parametrized value, however, I wonder if there is some assumption that
 the setFoo() method may be a mutator anyway, e.g. setDefaults() or
 something like that?  Just guessing.

 In this case it may be safer to follow the RI -- but I'm open to
 persuasion.

 Regards,
 Tim

 Alexei Zakharov wrote:
  Hi all,
 
  Let me disturb you with another boring RI inconsistency in beans
  –type of message. :) It seems I found a bug in RI.  In
  java.beans.EventHandler. I think RI incorrectly determines properties
  here. According to spec, common sense and even the RI's implementation
  of java.beans.Introspector the following bean should not contain any
  properties:
 
 public static class MyBean {
 public void setProp1() {}
 }
 
  because setProp1() is not a valid setter method – it does not
  contain a new value to set.
  However, the following test fails on RI:
 
  ---
  import java.beans.*;
 
  public class TestBeanInfo1 {
 public static class MyBean {
 public void setProp1() {}
 }
 
 public static void main(String argv[]) throws Exception {
 MyBean bean = new MyBean();
 // prop1 is neither the name of writeable property nor the
  name of any public method
 Object proxy = EventHandler.create(
 PropertyChangeListener.class, bean, prop1);
 
 // just to show that Introspector doesn't see the property
  with name prop1
 PropertyDescriptor[] pds =
 Introspector.getBeanInfo(MyBean.class,
 Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
 for (int i = 0; i  pds.length; i++) {
 System.out.println(Property found:  + pds[i].getName());
 }
 
 // should throw exception
 try {
 ((PropertyChangeListener) proxy).propertyChange(
 new PropertyChangeEvent(bean, prop1, 1, 2));
 System.out.println(FAIL);
 } catch (Throwable t) {
 System.out.println(PASS);
 }
 }
  }
  ---
 
  So it determines prop1 as a valid property. IMHO this behavior is
  inconsistent and we should not follow RI. But I like to hear opinions
  from the rest of the community.
 
  Thanks,



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

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

Re: [general] define pre-commit testing configs to gain the stability

[Pavel Ozhdikhin]

Bazaar is a funny concept. :) I think it'll work assuming we have a
bazaar police - something constantly checking integrity of our code on
some target platforms. These may be the community members reporting
failures or a tool constantly testing  some target platforms. But this
tool is another topic for discussion.

Thanks,
Pavel


On 10/16/06, Tim Ellison [EMAIL PROTECTED] wrote:

Ivan Volosyuk wrote:
 What an interesting discussion! I have just read this out. :)

 IMHO, all of the discussion is focused on the scalability of
 bazar-like development as it exists here in harmony incubator:

 If something wrong is commited, then everyone has broken build or
 something doesn't work. - This is bad. System is badly scalable. What
 can we do here?

 If build is broken, then the cause might be found by someone and
 posted on harmony-dev. - This is good. And it has good scalability :)

Exactly -- we don't expect committers to be infallible or have every
type of machine and OS version that we intend to 'support' (i.e. keep
running), so we cannot have a model that requires such extensive
pre-commit testing.  Of course, we therefore need full community
approval to declare some revision of code stable, but our bazaar-like
diversity is truly an asset.

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]




-
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] IPF functionality

[Geir Magnusson Jr.]

Mikhail Loenko wrote:

2006/10/16, Mikhail Fursov [EMAIL PROTECTED]:

On 10/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:


 Isn't it time to define the official set of supported platforms? ;)


After reading the neighbour threads about hardware available for 
commiters

and precommit criteria I think that we have no officially supported
platforms today (and IMO this is wrong).

What is the difference in your vision between official supported and
official not supported platforms?


IMHO the difference is we back commit if it breaks officially supported
platform and not necessarily do if it breaks unsupported one


If pressed, I would assert that we officially* support Windows XP x86 
and Linux** x86.


* = I say officially with the caveat that we are all volunteers here, 
and support for a platform will only remain as long as people are 
willing to volunteer to support it.


** = We should define to be a set of popular platforms.  I'll start a 
new thread so we can put this to bed and get back to work ;)


geir



Thanks,
Mikhail




--
Mikhail Fursov




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



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

[general] POLL : supported platforms

[Geir Magnusson Jr.]

We're a volunteer project, so supported is based on interest in 
community.  Lets be clear by writing down a set of platforms that we as 
a community commit to support.


I think we can define support as - one or more people in the 
community tests on that platform on a regular basis, there are users 
that use that platform, and we have people volunteering to find and fix 
bugs that specifically affect that platform


Just throw things out there and we'll gather the results and see what's 
popular.  We'll summarize in 3 days.  Please be clear in indicating what 
you think should be reported.  Don't vote against anything. To start, 
using a broad brush :



Windows
===
Windows XP x86

Linux
=
Ubuntu 6 x86
Ubuntu 5 x86
RHEL  (version ?) x86
FC (version ?) x86
SUSE (verion ?) x86

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

Re: [general] POLL : supported platforms

[Justin Zheng]

Why only x86? How about x64  MIPS?

Thanks.

Best Regards,

Justinz


On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


We're a volunteer project, so supported is based on interest in
community.  Lets be clear by writing down a set of platforms that we as
a community commit to support.

I think we can define support as - one or more people in the
community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform

Just throw things out there and we'll gather the results and see what's
popular.  We'll summarize in 3 days.  Please be clear in indicating what
you think should be reported.  Don't vote against anything. To start,
using a broad brush :


Windows
===
Windows XP x86

Linux
=
Ubuntu 6 x86
Ubuntu 5 x86
RHEL  (version ?) x86
FC (version ?) x86
SUSE (verion ?) x86

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

Re: [general] POLL : supported platforms

[Mikhail Fursov]

My 2 cents:

1. The OS is not enough. Some bugs are reproducable on multicore systems
only. + We do actually support only platforms with SSE instructions set now.
So Pentium2 and older are not supported.

2. We can review the list of the supported platforms
every periodically. So the current list is just for the next N months.


On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


We're a volunteer project, so supported is based on interest in
community.  Lets be clear by writing down a set of platforms that we as
a community commit to support.

I think we can define support as - one or more people in the
community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform

Just throw things out there and we'll gather the results and see what's
popular.  We'll summarize in 3 days.  Please be clear in indicating what
you think should be reported.  Don't vote against anything. To start,
using a broad brush :


Windows
===
Windows XP x86

Linux
=
Ubuntu 6 x86
Ubuntu 5 x86
RHEL  (version ?) x86
FC (version ?) x86
SUSE (verion ?) x86

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





--
Mikhail Fursov

Re: Ant get error

[Justin Zheng]

Finally, I built Harmony sucessfully. :) However the test suite has a lot of
failures. Is that expected?

And when I type Java -version, the result is:

Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundatio
n or its licensors, as applicable.
JVMJ9VM007E 无法识别命令行选项(unable to read command line option)：-version
HMYEXEL062E 内部 VM 错误：未能创建 (internal VM error, cannot create ) Java VM
FAILED to invoke JVM.

which is different with quickhelp document.

Is that my configuration error?

Thanks.

Best Regards,

Justinz

On 10/15/06, Alexey Petrenko [EMAIL PROTECTED] wrote:


2006/10/14, Paulex Yang [EMAIL PROTECTED]:
 Alexey Petrenko wrote:
  This error simply means that ant can not finad a compiler. Because
  Harmony does not have a compiler.. yet...
  Somewhere (in the READMEs or on the Harmony site) was an instruction
  on using Eclipse compiler for Harmony build.
 
  You should look for this info.
 The other solution is, if you have JDK installed, point your JAVA_HOME
 to that directory.
Looks like Justin is trying to build Harmony using Harmony


  2006/10/14, Justin Zheng [EMAIL PROTECTED]:
  Thanks for your help. Ant get issue had been resolved and solution
  had been
  updated to the wiki page, please help to check.
 
  However, another issue occoured.
 
  I received this error when I executed build.bat after the update:
 
  BUILD FAILED
  C:\Harmony\trunk\working_vm\build\make\build.xml:406: The following
  error
  occurr
  ed while executing this line:
  C:\Harmony\trunk\working_vm\build\make\build.xml:413: The following
  error
  occurr
  ed while executing this line:
  C:\Harmony\trunk\working_vm\build\make\build_component.xml:72: The
  following
  err
  or occurred while executing this line:
 
C:\Harmony\trunk\working_vm\build\win_ia32_msvc_debug\semis\build\targets\build.
 
  java.xml:10: Unable to find a javac compiler;
  com.sun.tools.javac.Main is not on the classpath.
  Perhaps JAVA_HOME does not point to the JDK
 
  Some System Variables setting:
 
  ANT_HOME=C:\Downloads\apache-ant-1.6.5-bin\apache-ant-1.6.5
  JAVA_HOME=C:\Harmony\trunk\working_classlib\deploy\jdk\jre
 
  Can any one help?
 
  Thanks a lot!
 
  Best Regards,
 
  Justinz
 
 
  On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
  
   Paulex Yang [EMAIL PROTECTED] wrote:
Can you access
  http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip in
browser?
  
   Justin Zheng wrote:
 I do cannot access that url. How can I get the access
permission?
  
   The site is one of public Apache mirrors, so it must be some
network
   availability problem that you cannot access it.
   I've just tried and file is accessible.
   Could you please check your internet connection is okay?
  
   Meanwhile, you can try using some other Apache mirror, for example,
  the
   main one,
   by making the following change and running 'build.bat update'
again.
  
   --- build/make/win.properties
   +++ build/make/win.properties
   @@ -50,7 +50,7 @@ CLASSLIB_HOME=../../../classlib/trunk/
  
   # Apache Portable Runtime, version 1.1 or above
   # http://apr.apache.org/download.cgi
  
  -
remote.APR.archive=http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip
   +remote.APR.archive=http://www.apache.org/dist/apr/apr-1.2.6.zip
  
   # APR-util, version 1.2.2 or above
   # http://apr.apache.org/download.cgi
  
  
  
-
   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]




--
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: [general] supported platforms

[Salikh Zakirov]

Geir Magnusson Jr. wrote:
 I think we can define support as - one or more people in the
^^^

I think in place of people should be _committer_.

 community tests on that platform on a regular basis, there are users
 that use that platform, and we have people volunteering to find and fix
 bugs that specifically affect that platform

As a person who tried to fix Linux/x86_64 problems several times,
I can say that the fixes by themselves are not the only thing that
matters. The platform can't be considered supported, if at any 
given moment of time is likely to be broken, and the fixes are likely
to be floating somewhere in JIRA.

Certainly, Linux/x86_64 can not be considered supported now,
despite of the fact that *there are* people regularly running it
and sending patches.

As of the future, when we hopefully will have more committers, I think
we can *observe* the increase in number of supported platforms.
Each committer will have to decide for himself, which platforms s/he
will check before each commit, and what to watch for in JIRA.
If the committer is doing job well, then and only then we can declare the 
platform supported.
And the platform will stay supported only as long as committer is keeping it 
running.

Anyway, my point is that supported platform is not something that we 
non-committers
can decide on.

P.S. As of the poll, the platforms I have access to and checking occasionally 
are

Windows/i686 XP
Linux/i686 SUSE 9 (planning upgrade to SUSE10 soon)
Linux/x86_64 SUSE 9 (planning upgrade to SUSE10 soon)


-
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] POLL : supported platforms

[Geir Magnusson Jr.]

Throw it out there!  It's a poll!

Justin Zheng wrote:

Why only x86? How about x64  MIPS?

Thanks.

Best Regards,

Justinz


On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


We're a volunteer project, so supported is based on interest in
community.  Lets be clear by writing down a set of platforms that we as
a community commit to support.

I think we can define support as - one or more people in the
community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform

Just throw things out there and we'll gather the results and see what's
popular.  We'll summarize in 3 days.  Please be clear in indicating what
you think should be reported.  Don't vote against anything. To start,
using a broad brush :


Windows
===
Windows XP x86

Linux
=
Ubuntu 6 x86
Ubuntu 5 x86
RHEL  (version ?) x86
FC (version ?) x86
SUSE (verion ?) x86

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






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

Re: [general] POLL : supported platforms

[Geir Magnusson Jr.]

Great!  Write that down with your votes.  (Note, I was just kicking this 
off, not being comprehensive...)


Mikhail Fursov wrote:

My 2 cents:

1. The OS is not enough. Some bugs are reproducable on multicore systems
only. + We do actually support only platforms with SSE instructions set 
now.

So Pentium2 and older are not supported.

2. We can review the list of the supported platforms
every periodically. So the current list is just for the next N months.


On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


We're a volunteer project, so supported is based on interest in
community.  Lets be clear by writing down a set of platforms that we as
a community commit to support.

I think we can define support as - one or more people in the
community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform

Just throw things out there and we'll gather the results and see what's
popular.  We'll summarize in 3 days.  Please be clear in indicating what
you think should be reported.  Don't vote against anything. To start,
using a broad brush :


Windows
===
Windows XP x86

Linux
=
Ubuntu 6 x86
Ubuntu 5 x86
RHEL  (version ?) x86
FC (version ?) x86
SUSE (verion ?) x86

-
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: Ant get error

[Geir Magnusson Jr.]

Justin Zheng wrote:
 Finally, I built Harmony sucessfully. :) However the test suite has a 
 lot of
 failures. Is that expected?
 
 And when I type Java -version, the result is:
 
 Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
 Foundatio
 n or its licensors, as applicable.
 JVMJ9VM007E 无法识别命令行选项(unable to read command line option)：- 
 version
 HMYEXEL062E 内部 VM 错误：未能创建 (internal VM error, cannot create ) 
 Java VM
 FAILED to invoke JVM.
 
 which is different with quickhelp document.

Sure, because you are sing IBM J9 :) which doesn't support -version as
we have the launcher pass it through.

We'll fix this ASAP.

 
 Is that my configuration error?

Try running a HellowWorld with -showversion

 
 Thanks.
 
 Best Regards,
 
 Justinz
 
 On 10/15/06, Alexey Petrenko [EMAIL PROTECTED] wrote:

 2006/10/14, Paulex Yang [EMAIL PROTECTED]:
  Alexey Petrenko wrote:
   This error simply means that ant can not finad a compiler. Because
   Harmony does not have a compiler.. yet...
   Somewhere (in the READMEs or on the Harmony site) was an instruction
   on using Eclipse compiler for Harmony build.
  
   You should look for this info.
  The other solution is, if you have JDK installed, point your JAVA_HOME
  to that directory.
 Looks like Justin is trying to build Harmony using Harmony


   2006/10/14, Justin Zheng [EMAIL PROTECTED]:
   Thanks for your help. Ant get issue had been resolved and solution
   had been
   updated to the wiki page, please help to check.
  
   However, another issue occoured.
  
   I received this error when I executed build.bat after the update:
  
   BUILD FAILED
   C:\Harmony\trunk\working_vm\build\make\build.xml:406: The following
   error
   occurr
   ed while executing this line:
   C:\Harmony\trunk\working_vm\build\make\build.xml:413: The following
   error
   occurr
   ed while executing this line:
   C:\Harmony\trunk\working_vm\build\make\build_component.xml:72: The
   following
   err
   or occurred while executing this line:
  
 C:\Harmony\trunk\working_vm\build\win_ia32_msvc_debug\semis\build\targets\build.
  

  
   java.xml:10: Unable to find a javac compiler;
   com.sun.tools.javac.Main is not on the classpath.
   Perhaps JAVA_HOME does not point to the JDK
  
   Some System Variables setting:
  
   ANT_HOME=C:\Downloads\apache-ant-1.6.5-bin\apache-ant-1.6.5
   JAVA_HOME=C:\Harmony\trunk\working_classlib\deploy\jdk\jre
  
   Can any one help?
  
   Thanks a lot!
  
   Best Regards,
  
   Justinz
  
  
   On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
   
Paulex Yang [EMAIL PROTECTED] wrote:
 Can you access
   http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip in
 browser?
   
Justin Zheng wrote:
  I do cannot access that url. How can I get the access
 permission?
   
The site is one of public Apache mirrors, so it must be some
 network
availability problem that you cannot access it.
I've just tried and file is accessible.
Could you please check your internet connection is okay?
   
Meanwhile, you can try using some other Apache mirror, for 
 example,
   the
main one,
by making the following change and running 'build.bat update'
 again.
   
--- build/make/win.properties
+++ build/make/win.properties
@@ -50,7 +50,7 @@ CLASSLIB_HOME=../../../classlib/trunk/
   
# Apache Portable Runtime, version 1.1 or above
# http://apr.apache.org/download.cgi
   
   -
 remote.APR.archive=http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip
+remote.APR.archive=http://www.apache.org/dist/apr/apr-1.2.6.zip
   
# APR-util, version 1.2.2 or above
# http://apr.apache.org/download.cgi
   
   
   
 -
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]
 
 


 -- 
 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]



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

Re: Ant get error

[Sergey Soldatov]

It's a know feature that J9 doesn't show version. Nevermind, just try to run
a simple application like HelloWorld

On 10/16/06, Justin Zheng [EMAIL PROTECTED] wrote:


Finally, I built Harmony sucessfully. :) However the test suite has a lot
of
failures. Is that expected?

And when I type Java -version, the result is:

Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundatio
n or its licensors, as applicable.
JVMJ9VM007E 无法识别命令行选项(unable to read command line option)：-version
HMYEXEL062E 内部 VM 错误：未能创建 (internal VM error, cannot create ) Java VM
FAILED to invoke JVM.

which is different with quickhelp document.

Is that my configuration error?

Thanks.

Best Regards,

Justinz

On 10/15/06, Alexey Petrenko [EMAIL PROTECTED] wrote:

 2006/10/14, Paulex Yang [EMAIL PROTECTED]:
  Alexey Petrenko wrote:
   This error simply means that ant can not finad a compiler. Because
   Harmony does not have a compiler.. yet...
   Somewhere (in the READMEs or on the Harmony site) was an instruction
   on using Eclipse compiler for Harmony build.
  
   You should look for this info.
  The other solution is, if you have JDK installed, point your JAVA_HOME
  to that directory.
 Looks like Justin is trying to build Harmony using Harmony


   2006/10/14, Justin Zheng [EMAIL PROTECTED]:
   Thanks for your help. Ant get issue had been resolved and solution
   had been
   updated to the wiki page, please help to check.
  
   However, another issue occoured.
  
   I received this error when I executed build.bat after the update:
  
   BUILD FAILED
   C:\Harmony\trunk\working_vm\build\make\build.xml:406: The following
   error
   occurr
   ed while executing this line:
   C:\Harmony\trunk\working_vm\build\make\build.xml:413: The following
   error
   occurr
   ed while executing this line:
   C:\Harmony\trunk\working_vm\build\make\build_component.xml:72: The
   following
   err
   or occurred while executing this line:
  

C:\Harmony\trunk\working_vm\build\win_ia32_msvc_debug\semis\build\targets\build.
  
   java.xml:10: Unable to find a javac compiler;
   com.sun.tools.javac.Main is not on the classpath.
   Perhaps JAVA_HOME does not point to the JDK
  
   Some System Variables setting:
  
   ANT_HOME=C:\Downloads\apache-ant-1.6.5-bin\apache-ant-1.6.5
   JAVA_HOME=C:\Harmony\trunk\working_classlib\deploy\jdk\jre
  
   Can any one help?
  
   Thanks a lot!
  
   Best Regards,
  
   Justinz
  
  
   On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
   
Paulex Yang [EMAIL PROTECTED] wrote:
 Can you access
   http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip in
 browser?
   
Justin Zheng wrote:
  I do cannot access that url. How can I get the access
 permission?
   
The site is one of public Apache mirrors, so it must be some
 network
availability problem that you cannot access it.
I've just tried and file is accessible.
Could you please check your internet connection is okay?
   
Meanwhile, you can try using some other Apache mirror, for
example,
   the
main one,
by making the following change and running 'build.bat update'
 again.
   
--- build/make/win.properties
+++ build/make/win.properties
@@ -50,7 +50,7 @@ CLASSLIB_HOME=../../../classlib/trunk/
   
# Apache Portable Runtime, version 1.1 or above
# http://apr.apache.org/download.cgi
   
   -
 remote.APR.archive=http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip
+remote.APR.archive=http://www.apache.org/dist/apr/apr-1.2.6.zip
   
# APR-util, version 1.2.2 or above
# http://apr.apache.org/download.cgi
   
   
   
 -
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]
 
 


 --
 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]







--
Sergey Soldatov
Intel Middleware Products Division

Re: [general] supported platforms

[Geir Magnusson Jr.]

Salikh Zakirov wrote:

Geir Magnusson Jr. wrote:

I think we can define support as - one or more people in the

^^^

I think in place of people should be _committer_.


community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform


As a person who tried to fix Linux/x86_64 problems several times,
I can say that the fixes by themselves are not the only thing that
matters. The platform can't be considered supported, if at any 
given moment of time is likely to be broken, and the fixes are likely

to be floating somewhere in JIRA.

Certainly, Linux/x86_64 can not be considered supported now,
despite of the fact that *there are* people regularly running it
and sending patches.

As of the future, when we hopefully will have more committers, I think
we can *observe* the increase in number of supported platforms.
Each committer will have to decide for himself, which platforms s/he
will check before each commit, and what to watch for in JIRA.
If the committer is doing job well, then and only then we can declare the platform 
supported.
And the platform will stay supported only as long as committer is keeping it 
running.

Anyway, my point is that supported platform is not something that we 
non-committers
can decide on.


I don't agree. people that support platforms become committers that 
support platforms, and the opinions of non-committers is always 
important.  A project that exists for the pleasure of it's committers 
only is not really our goal in an Apache project.




P.S. As of the poll, the platforms I have access to and checking occasionally 
are

Windows/i686 XP
Linux/i686 SUSE 9 (planning upgrade to SUSE10 soon)
Linux/x86_64 SUSE 9 (planning upgrade to SUSE10 soon)


Thanks.  We need a clear set of defn's.  What is i686 to you?

geir


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

Re: [drlvm] “java.compiler” property

[Pavel Pervov]

Mikhail,

EM, as I see it, is interchangeable component. Should we require defining 
java.compiler for interpreted mode from all EMs?
My idea is to initialize java.compiler to some default value (none?) in
VM, and then overwrite it with actual value wherever actual information is
available (in EM in our case).

And one question follows: what if we have three different JITs defined in EM
configuration file? :) What value java.compiler will contain in this case?

Regards,
   Pavel.
On 10/16/06, Mikhail Fursov [EMAIL PROTECTED] wrote:


On 10/16/06, Alexei Zakharov [EMAIL PROTECTED] wrote:

 Moreover, the spec obliges us to do so. The real question is: is it RI
 bug or bug in spec? Personally I am for returning non-null values in
 all cases.


I agree. Just tell me and I will commit the patch for EM(interpreter) and
JIT modes.
BTW I think that we should create interpreter.emconf file and place all VM
properties needed for interpreter into this file.
So, in future, when we need to add more interpreter-mode option, we will
not
affect the EM C++ code.


--
Mikhail Fursov

Re: [general] supported platforms

[Salikh Zakirov]

 Anyway, my point is that supported platform is not something that we
 non-committers
 can decide on.
 
 I don't agree. people that support platforms become committers that
 support platforms, and the opinions of non-committers is always
 important.  A project that exists for the pleasure of it's committers
 only is not really our goal in an Apache project.

I think you misunderstood me. I agree with importance of non-committers
contribution to the project.
My point is we can't say that the platform is supported until there
exist committer who regularly checks and promptly commits fixes for that 
platform.

That's why it is useless to make the list of platforms that someone wants
to be supported.

It is only actual participation that counts.
If someone wants to have a platform X supported, then it will take that person
to constantly submit fixes for that platform, earn committership,
and keep the platform X running by fixing breakages promptly.
And only then we will be able to say that platform X is supported.

 P.S. As of the poll, the platforms I have access to and checking
 occasionally are

 Windows/i686 XP
 Linux/i686 SUSE 9 (planning upgrade to SUSE10 soon)
 Linux/x86_64 SUSE 9 (planning upgrade to SUSE10 soon)
 
 Thanks.  We need a clear set of defn's.  What is i686 to you?

Pentium M or Pentium 4 or anything newer.
It is officially called Intel Architecture or ia32 here,
but 'uname -m' returns i686.


-
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] supported platforms

[Geir Magnusson Jr.]

Salikh Zakirov wrote:

Anyway, my point is that supported platform is not something that we
non-committers
can decide on.

I don't agree. people that support platforms become committers that
support platforms, and the opinions of non-committers is always
important.  A project that exists for the pleasure of it's committers
only is not really our goal in an Apache project.


I think you misunderstood me. I agree with importance of non-committers
contribution to the project.
My point is we can't say that the platform is supported until there
exist committer who regularly checks and promptly commits fixes for that 
platform.

That's why it is useless to make the list of platforms that someone wants
to be supported.


Fine!  lets get something working on some platform to begin :)



It is only actual participation that counts.
If someone wants to have a platform X supported, then it will take that person
to constantly submit fixes for that platform, earn committership,
and keep the platform X running by fixing breakages promptly.
And only then we will be able to say that platform X is supported.


Yep




P.S. As of the poll, the platforms I have access to and checking
occasionally are

Windows/i686 XP
Linux/i686 SUSE 9 (planning upgrade to SUSE10 soon)
Linux/x86_64 SUSE 9 (planning upgrade to SUSE10 soon)

Thanks.  We need a clear set of defn's.  What is i686 to you?


Pentium M or Pentium 4 or anything newer.
It is officially called Intel Architecture or ia32 here,
but 'uname -m' returns i686.


great - precise is good here




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



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

[drlvm] gc.Finalizer smoke test fails more often than not

[Geir Magnusson Jr]

Usually with this :


java: 
/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:551:
 void ClassLoader::SuccessLoadingClass(const String*): Assertion `lc' failed.
SIGABRT in VM code.
Stack trace:
addr2line: '[vdso]': No such file
1: ?? (�U��h���יڶ:-1)
2: abort (??:-1)
3: __assert_fail (??:-1)
4: ClassLoader::SuccessLoadingClass(String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:552)
5: ClassLoader::DefineClass(Global_Env*, char const*, unsigned char*, 
unsigned int, unsigned int, String const**) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:346)
6: BootstrapClassLoader::LoadFromJarFile(JarFile*, char const*, String 
const*, bool*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2008)
7: BootstrapClassLoader::LoadFromFile(String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1911)
8: BootstrapClassLoader::LoadClass(Global_Env*, String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1702)
9: ClassLoader::LoadVerifyAndPrepareClass(Global_Env*, String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:385)
10: _resolve_class 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:157)
11: _resolve_class_new(Global_Env*, Class*, unsigned int) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:221)
12: resolve_class_new 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:902)
13: vm_resolve_class_new 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:903)
14: Jitrino::Jet::Compiler::gen_magic() (??:-1)


-
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][beans] RI inconsistency in EventHandler

[Alexei Zakharov]

HARMONY-1884 was created.

Thanks,

2006/10/16, Alexei Zakharov [EMAIL PROTECTED]:

I am ok with this. :) Will file a JIRA soon.

Regards,

2006/10/16, Tim Ellison [EMAIL PROTECTED]:
 I'm fine with marking it as a non-bug difference, with the option to fix
 it if we find some compelling application that relies on this non-spec
 behavior.  Is that weasely enough?

 Regards,
 Tim

 Alexei Zakharov wrote:
  Hi Tim,
 
  -- persuasion starts here
 
  Let me cite the spec describing design patterns for properties,
  JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
 
  ---
  8.3 Design Patterns for Properties
 
  8.3.1 Simple properties
  By default, we use design patterns to locate properties by looking for
  methods of the form:
 
  public PropertyType getPropertyName();
  public void setPropertyName(PropertyType a);
 
  8.3.2 Boolean properties
  In addition, for boolean properties, we allow a
 
  public boolean isPropertyName();
 
  8.3.3 Indexed properties
  If we find a property whose type is an array PropertyElement[],
  then we also look for methods of the form:
 
  public PropertyElement getPropertyName(int a);
  public void setPropertyName(int a, PropertyElement b);
  ---
 
  So we have only three design patterns specified for properties. That's
  all. I didn't found any mentioning about any extra design patterns and
  I've never heard anything about setDefaults() or smth. like it.
 
  On the other hand, if I understand things correctly the Introspector
  class should be the decision-making center for such type of things.
  I.e. if Introspector says there is no properties then there should be
  no properties. RI doesn't seem to be using Introspector in the example
  I've described ealier. Thus I still think it looks like RI bug.
 
  -- end of persuasion
 
  Thanks and regards,
 
  2006/10/14, Tim Ellison [EMAIL PROTECTED]:
  That is strange behavior, since as you point out it does not set a
  parametrized value, however, I wonder if there is some assumption that
  the setFoo() method may be a mutator anyway, e.g. setDefaults() or
  something like that?  Just guessing.
 
  In this case it may be safer to follow the RI -- but I'm open to
  persuasion.
 
  Regards,
  Tim
 
  Alexei Zakharov wrote:
   Hi all,
  
   Let me disturb you with another boring RI inconsistency in beans
   –type of message. :) It seems I found a bug in RI.  In
   java.beans.EventHandler. I think RI incorrectly determines properties
   here. According to spec, common sense and even the RI's implementation
   of java.beans.Introspector the following bean should not contain any
   properties:
  
  public static class MyBean {
  public void setProp1() {}
  }
  
   because setProp1() is not a valid setter method – it does not
   contain a new value to set.
   However, the following test fails on RI:
  
   ---
   import java.beans.*;
  
   public class TestBeanInfo1 {
  public static class MyBean {
  public void setProp1() {}
  }
  
  public static void main(String argv[]) throws Exception {
  MyBean bean = new MyBean();
  // prop1 is neither the name of writeable property nor the
   name of any public method
  Object proxy = EventHandler.create(
  PropertyChangeListener.class, bean, prop1);
  
  // just to show that Introspector doesn't see the property
   with name prop1
  PropertyDescriptor[] pds =
  Introspector.getBeanInfo(MyBean.class,
  Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
  for (int i = 0; i  pds.length; i++) {
  System.out.println(Property found:  + pds[i].getName());
  }
  
  // should throw exception
  try {
  ((PropertyChangeListener) proxy).propertyChange(
  new PropertyChangeEvent(bean, prop1, 1, 2));
  System.out.println(FAIL);
  } catch (Throwable t) {
  System.out.println(PASS);
  }
  }
   }
   ---
  
   So it determines prop1 as a valid property. IMHO this behavior is
   inconsistent and we should not follow RI. But I like to hear opinions
   from the rest of the community.
  
   Thanks,


--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia




--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

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

Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target

[Gregory Shimansky]

On Saturday 14 October 2006 09:56 Tim Ellison wrote:
 Gregory Shimansky wrote:
  As to rpm packages, send me a email directly, please write which version
  of redhat you have installed. I am sure I can help you with installing
  the necessary packages.

 Why won't you do that publicly, i.e. on the website ?  or is the offer
 open to everyone to mail you directly g

I didn't think it is a big deal to discuss where to get lcms devel for redhat. 
It's a matter of package manager specific to the distribution official 
repository.

-- 
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: [drlvm] gc.Finalizer smoke test fails more often than not

[Ivan Volosyuk]

I have created a JIRA issue for this problem some time ago.
 https://issues.apache.org/jira/browse/HARMONY-1556

It contains the description of what is going on.

--
Ivan

On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:

Usually with this :

 java: 
/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:551:
 void ClassLoader::SuccessLoadingClass(const String*): Assertion `lc' failed.
 SIGABRT in VM code.
 Stack trace:
 addr2line: '[vdso]': No such file
 1: ?? (�U��h���יڶ:-1)
 2: abort (??:-1)
 3: __assert_fail (??:-1)
 4: ClassLoader::SuccessLoadingClass(String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:552)
 5: ClassLoader::DefineClass(Global_Env*, char const*, unsigned char*, 
unsigned int, unsigned int, String const**) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:346)
 6: BootstrapClassLoader::LoadFromJarFile(JarFile*, char const*, 
String const*, bool*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2008)
 7: BootstrapClassLoader::LoadFromFile(String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1911)
 8: BootstrapClassLoader::LoadClass(Global_Env*, String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1702)
 9: ClassLoader::LoadVerifyAndPrepareClass(Global_Env*, String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:385)
 10: _resolve_class 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:157)
 11: _resolve_class_new(Global_Env*, Class*, unsigned int) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:221)
 12: resolve_class_new 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:902)
 13: vm_resolve_class_new 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:903)
 14: Jitrino::Jet::Compiler::gen_magic() (??:-1)

Re: [drlvm] gc.Finalizer smoke test fails more often than not

[Geir Magnusson Jr.]

Well, it just seems to have gotten worse lately

Anyone working on a fix?

geir


Ivan Volosyuk wrote:

I have created a JIRA issue for this problem some time ago.
 https://issues.apache.org/jira/browse/HARMONY-1556

It contains the description of what is going on.

--
Ivan

On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:

Usually with this :

 java: 
/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:551: 
void ClassLoader::SuccessLoadingClass(const String*): Assertion `lc' 
failed.

 SIGABRT in VM code.
 Stack trace:
 addr2line: '[vdso]': No such file
 1: ?? (�U��h���יڶ:-1)
 2: abort (??:-1)
 3: __assert_fail (??:-1)
 4: ClassLoader::SuccessLoadingClass(String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:552) 

 5: ClassLoader::DefineClass(Global_Env*, char const*, 
unsigned char*, unsigned int, unsigned int, String const**) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:346) 

 6: BootstrapClassLoader::LoadFromJarFile(JarFile*, char 
const*, String const*, bool*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2008) 

 7: BootstrapClassLoader::LoadFromFile(String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1911) 

 8: BootstrapClassLoader::LoadClass(Global_Env*, String 
const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1702) 

 9: ClassLoader::LoadVerifyAndPrepareClass(Global_Env*, 
String const*) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:385) 

 10: _resolve_class 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:157) 

 11: _resolve_class_new(Global_Env*, Class*, unsigned int) 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:221) 

 12: resolve_class_new 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:902) 

 13: vm_resolve_class_new 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:903) 


 14: Jitrino::Jet::Compiler::gen_magic() (??:-1)



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

Re: [drlvm] gc.Finalizer smoke test fails more often than not

[Ivan Volosyuk]

AFAIK, nobody does.

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Well, it just seems to have gotten worse lately

Anyone working on a fix?

geir


Ivan Volosyuk wrote:
 I have created a JIRA issue for this problem some time ago.
  https://issues.apache.org/jira/browse/HARMONY-1556

 It contains the description of what is going on.

 --
 Ivan

 On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
 Usually with this :

  java:
 
/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:551:
 void ClassLoader::SuccessLoadingClass(const String*): Assertion `lc'
 failed.
  SIGABRT in VM code.
  Stack trace:
  addr2line: '[vdso]': No such file
  1: ?? (�U��h���יڶ:-1)
  2: abort (??:-1)
  3: __assert_fail (??:-1)
  4: ClassLoader::SuccessLoadingClass(String const*)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:552)

  5: ClassLoader::DefineClass(Global_Env*, char const*,
 unsigned char*, unsigned int, unsigned int, String const**)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:346)

  6: BootstrapClassLoader::LoadFromJarFile(JarFile*, char
 const*, String const*, bool*)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2008)

  7: BootstrapClassLoader::LoadFromFile(String const*)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1911)

  8: BootstrapClassLoader::LoadClass(Global_Env*, String
 const*)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1702)

  9: ClassLoader::LoadVerifyAndPrepareClass(Global_Env*,
 String const*)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:385)

  10: _resolve_class
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:157)

  11: _resolve_class_new(Global_Env*, Class*, unsigned int)
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:221)

  12: resolve_class_new
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:902)

  13: vm_resolve_class_new
 
(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:903)

  14: Jitrino::Jet::Compiler::gen_magic() (??:-1)




--
Ivan
Intel Enterprise Solutions Software Division

Re: [general] POLL : supported platforms

[Nathan Beyer]

My primary votes would go for -
Windows XP, Server 2003, Vista on ia32 and ia64 platforms

Secondary votes -
Ubuntu, RHEL/FC, SUSE on ia32 and ia64 platforms

Tertiary votes -
MacOSX, ia32 and ia64 platforms - this would give me a reason to buy a
MacBook Pro :)

-Nathan

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

We're a volunteer project, so supported is based on interest in
community.  Lets be clear by writing down a set of platforms that we as
a community commit to support.

I think we can define support as - one or more people in the
community tests on that platform on a regular basis, there are users
that use that platform, and we have people volunteering to find and fix
bugs that specifically affect that platform

Just throw things out there and we'll gather the results and see what's
popular.  We'll summarize in 3 days.  Please be clear in indicating what
you think should be reported.  Don't vote against anything. To start,
using a broad brush :


Windows
===
Windows XP x86

Linux
=
Ubuntu 6 x86
Ubuntu 5 x86
RHEL  (version ?) x86
FC (version ?) x86
SUSE (verion ?) x86

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




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

Re: [drlvm] gc.Finalizer smoke test fails more often than not

[Pavel Afremov]

I' m going look into this.

Pavel Afremov.

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


Well, it just seems to have gotten worse lately

Anyone working on a fix?

geir


Ivan Volosyuk wrote:
 I have created a JIRA issue for this problem some time ago.
  https://issues.apache.org/jira/browse/HARMONY-1556

 It contains the description of what is going on.

 --
 Ivan

 On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
 Usually with this :

  java:

/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:551:
 void ClassLoader::SuccessLoadingClass(const String*): Assertion `lc'
 failed.
  SIGABRT in VM code.
  Stack trace:
  addr2line: '[vdso]': No such file
  1: ?? (�U��h���יڶ:-1)
  2: abort (??:-1)
  3: __assert_fail (??:-1)
  4: ClassLoader::SuccessLoadingClass(String const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:552)

  5: ClassLoader::DefineClass(Global_Env*, char const*,
 unsigned char*, unsigned int, unsigned int, String const**)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:346)

  6: BootstrapClassLoader::LoadFromJarFile(JarFile*, char
 const*, String const*, bool*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2008)

  7: BootstrapClassLoader::LoadFromFile(String const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1911)

  8: BootstrapClassLoader::LoadClass(Global_Env*, String
 const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1702)

  9: ClassLoader::LoadVerifyAndPrepareClass(Global_Env*,
 String const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:385)

  10: _resolve_class

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:157)

  11: _resolve_class_new(Global_Env*, Class*, unsigned int)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:221)

  12: resolve_class_new

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:902)

  13: vm_resolve_class_new

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:903)

  14: Jitrino::Jet::Compiler::gen_magic() (??:-1)


-
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] version of gcc and other tools

[Nathan Beyer]

On 10/15/06, Tim Ellison [EMAIL PROTECTED] wrote:

Geir Magnusson Jr. wrote:
 I suppose that as a temporary solution, we can just get people to drop
 ECJ into ant/lib...

Yes, that would be my preferred solution too, until Ant support comes along.



Any objections to setting the harmony default compiler (in the build
scripts) to Eclipse then? The 'fetch-depends' already downloads the
necessary JAR, so copying it over should be a trivial task for now.

-Nathan

-
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] HARMONY-1505 and HARMONY-1608 - cleanup of JNI function names

[Nathan Beyer]

I do like clean code; go for it.

On 10/16/06, Mark Hindess [EMAIL PROTECTED] wrote:


On 15 October 2006 at 18:40, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 Does anyone have an objection to those two JIRAs?

I don't.

-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: [drlvm] gc.Finalizer smoke test fails more often than not

[Geir Magnusson Jr.]

ok - so should we disable Finalizer and PhantomReferenceQueue test since 
they aren't trustworthy until the fix is done?


Pavel Afremov wrote:

I' m going look into this.

Pavel Afremov.

On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


Well, it just seems to have gotten worse lately

Anyone working on a fix?

geir


Ivan Volosyuk wrote:
 I have created a JIRA issue for this problem some time ago.
  https://issues.apache.org/jira/browse/HARMONY-1556

 It contains the description of what is going on.

 --
 Ivan

 On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
 Usually with this :

  java:

/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:551: 


 void ClassLoader::SuccessLoadingClass(const String*): Assertion `lc'
 failed.
  SIGABRT in VM code.
  Stack trace:
  addr2line: '[vdso]': No such file
  1: ?? (�U��h���יڶ:-1)
  2: abort (??:-1)
  3: __assert_fail (??:-1)
  4: ClassLoader::SuccessLoadingClass(String const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:552) 



  5: ClassLoader::DefineClass(Global_Env*, char const*,
 unsigned char*, unsigned int, unsigned int, String const**)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:346) 



  6: BootstrapClassLoader::LoadFromJarFile(JarFile*, char
 const*, String const*, bool*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2008) 



  7: BootstrapClassLoader::LoadFromFile(String const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1911) 



  8: BootstrapClassLoader::LoadClass(Global_Env*, String
 const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1702) 



  9: ClassLoader::LoadVerifyAndPrepareClass(Global_Env*,
 String const*)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:385) 



  10: _resolve_class

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:157) 



  11: _resolve_class_new(Global_Env*, Class*, unsigned int)

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:221) 



  12: resolve_class_new

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/Resolve.cpp:902) 



  13: vm_resolve_class_new

(/home/geir/dev/apache/harmony/enhanced/trunk/working_vm/vm/vmcore/src/class_support/C_Interface.cpp:903) 



  14: Jitrino::Jet::Compiler::gen_magic() (??:-1)


-
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: [buildtest] odd classlib build failure

[Nathan Beyer]

Can this be automated in the setup target in anyway?

On 10/15/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:

it is easy to fix (readme.txt was updated in the jira 995):
copy the 'apache-ant-1.6.5\lib\ant-apache-regexp.jar' to the 'cc\lib\ant-
apache-regexp.jar' and add the string
set CRUISE_PATH=%CRUISE_PATH%;%LIBDIR%\ant-apache-regexp.jar
to the cruisecontrol.bat file.
 thanks, Vladimir



On 10/16/06, Nathan Beyer [EMAIL PROTECTED] wrote:

 I'm trying to setup the Build-Test stuff on a Windows XP machine and
 I'm running to a weird script failure for the 'classlib' build. I can
 run the build perfectly outside of CruiseControl, but this is the
 error I'm getting when the build is run by CruiseControl.

 console
 compile-java:
 [echo] Compiling ACCESSIBILITY classes

 copy-resources:

 svn-info:

 BUILD FAILED
 C:\dev\buildtest\trunk\cc\projects\classlib\trunk\build.xml:108: The
 following e
 rror occurred while executing this line:
 C:\dev\buildtest\trunk\cc\projects\classlib\trunk\make\build-java.xml:183:
 The f
 ollowing error occurred while executing this line:
 C:\dev\buildtest\trunk\cc\projects\classlib\trunk\make\properties.xml:249:
 The f
 ollowing error occurred while executing this line:
 C:\dev\buildtest\trunk\cc\projects\classlib\trunk\make\properties.xml:259:
 The f
 ollowing error occurred while executing this line:
 C:\dev\buildtest\trunk\cc\projects\classlib\trunk\make\properties.xml:223:
 No su
 pported regular expression matcher found
 /console

 Any thoughts?

 BTW - The classlib's fetch-depends failed on download of the
 MSVCR71.dll. I had to manually download it.

 -Nathan

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






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

Re: [general] version of gcc and other tools

[Geir Magnusson Jr.]

None from me, but please also add some useful message for people if not 
found like ECJ not found. Please copy useful info to useful info...




Nathan Beyer wrote:

On 10/15/06, Tim Ellison [EMAIL PROTECTED] wrote:

Geir Magnusson Jr. wrote:
 I suppose that as a temporary solution, we can just get people to drop
 ECJ into ant/lib...

Yes, that would be my preferred solution too, until Ant support comes 
along.




Any objections to setting the harmony default compiler (in the build
scripts) to Eclipse then? The 'fetch-depends' already downloads the
necessary JAR, so copying it over should be a trivial task for now.

-Nathan

-
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]