RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Ivanov, Alexey A]

>-Original Message-
>From: Stepan Mishura [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 03, 2006 9:43 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing] compatibility:
j.s.text.GapContent.replace()
>behaviour
>
>On 11/2/06, Ivanov, Alexey A wrote:
>>
>> Hi all,
>>
>> I've started fixing HARMONY-1809. To remove throws clause from the
>> declaration of replace method, as it was proposed by Oleg in
>> HARMONY-1975, I placed removeItems() and insertItems() calls into
>> try-catch block. This would work OK for any valid arguments.
>>

>>
>>
>> Any objections, comments, opinions?
>
>
>
>Hi Alexey,


Hi Stepan,

>I'm not quite convinced by your evaluation (I'm not an expert in Swing
API
>so I may be wrong). My experiments with GapContent showed that Harmony

Let me give a quick introduction what GapContent is then. This class
serves as the default storage for all Document implementations within
javax.swing.text. It stores text in char[] array... but with a gap in
it.
Using the default constructor the array will have length 10. And one
character will be placed into the buffer; the other 9 characters in the
array will be the gap, and they are not considered to be portion of the
content. This prevents frequent re-allocations of the underlying storage
array where text is inserted or removed. Moving the gap is cheaper than
re-allocating the array.

When an insert or remove occurs, the gap is moved so that it starts at
the position of insert or remove.


>initially created different object then RI, for example, if you create
an
>object with GapContent() constructor, Harmony will return start==0 and
>end==9 while RI will return start==1 and end==10. The next point that

It doesn't really matter where the gap is. This difference shows only
that the gap in the text buffer is located at different location. Using
content.shiftGap(0) on RI, you'll get start = 0, end = 9. Accordingly
using content.shiftGap(1) on Harmony, you'll get start = 1, end = 10.

What matters is that content.length() = 1 in both cases, and
content.getString(0, content.length()) returns "\n".

Actually, setting the gap to be at 0 is more efficient because the next
(or first) insert is likely to happen at position 0 rather than 1.
Therefore to insert text at position 0, the gap will be moved to 0 on RI
(which involves array copying and some other operations). This won't be
the case with Harmony because the gap is already at 0.


>confuses me that the spec. says about position as "logical position in
the
>storage"...and... "This is not the location in the underlying storage
>array". So negative value for position may be considered as valid.

It's all about how the text is stored in GapContent. Because there's a
gap modeled "the location in the underlying storage array" differs from
"the logical position in storage". If you look at the spec of any
methods which throw BadLocationException, you'll see that position (it's
called 'where') is to be >= 0. Since this method is used to perform
operations of insertString() and remove() in RI, negative positions are
invalid. I believe they put no checks here because validation of
parameters is performed in those methods which call replace().

Another point is that replace() in never used in Harmony implementation
- it's called from tests only.


Regards,
Alexey.


>
>Thanks,
>Stepan.
>
>Thanks,
>> Alexey.
>>
>>
>> P.S. The related JIRA issues:
>> https://issues.apache.org/jira/browse/HARMONY-1809
>> https://issues.apache.org/jira/browse/HARMONY-1975
>>
>> GapContent Javadoc:
>>
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
>> Description of GapContent.replace:
>>
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
>> #replace(int,%20int,%20java.lang.Object,%20int)
>>
>>
>> --
>> Alexey A. Ivanov
>> Intel Middleware Product Division
>>
>
>
>
>--
>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]

--
Alexey A. Ivanov
Intel Middleware Product Division

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Egor Pasko]

Alexey,

cool feature indeed! 

Some comments:

* I could not figure out what the quality criteria is in you current
  scripts :) Is it just the number of certain words? What are they? (I
  could not grok your script at the first glance, sorry)

* Old style of license header in check_doc_quality.sh

* check_doc_quality.sh is hardly readable. You use autogenerated perl
  files from a shell script. I think, the whole perl script would be
  much better readable and supportable. You also use uniq, sort, awk,
  etc. All these can be done in perl naturally.

* source file quality estimate would also be good (so I'd be happy to
  doxygise more and more files)

* feature request: output files edible by harmonytest.org? so the wole
  doc quality metric can be tracked

* just a suggestion: let's choose the best documented file and
  make it a reference, so we could document sources in a similar
  style. It should also help people, who did not use Doxygen in their
  life (like me:) to survive in this doc hunt.

On the 0x216 day of Apache Harmony Alexei Fedotov wrote:
> Nadya,
> 
> You asked good questions. Here are few answers:
> 
> 1. Grouping of results is implied by documentation grouping. Scripts
> can process any documentation bundle, so if one creates a smaller or
> specific bundle, the list will be shorter, or more specific.Creating
> several documentation bundles in different directories makes their
> comparison an easy task - I can do this comparison.
> 
> 2. Personally I like @page tags and package.html files. I appreciate
> Salikh's efforts of creating wonderful technical descriptions - I
> referred to them as masterpieces. I also remember that you asked me to
> create a narrative section for a component manager few months ago. All
> Doxygen documentation will be on the web site. Why these narrative
> sections shouldn't be evaluated?
> 
> 3. I don't think the rating of pages such as a list of functions
> should be neglected. Any .html page which can be viewed by a user
> should be readable. That is a reason why I parse .html files in the
> script, not sources.
> 
> 4. I believe establishing connection between .html files and source
> files can be automated. I don't know how to write a short script for
> that, because sometimes .html page depends from several source files,
> and vice versa.
> 
> 5. You can imagine the following pie chart from the data: 2680 pages
> of 2922 (91%) are not good and should be revised.
> 
> 6.  Today the community discussed removing GC V4. This would
> immediately decrease GC documentation size. It would also decrease a
> number of well documented pages on garbage collection, since new GCs
> don't have as much comments in their code as old GC V4.
> 
> Thank you for nice catches,
> Alexei
> 
> 
> 
> On 11/2/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> > Wow! Alexei, great start!
> > ... and so many pages marked with 0 rank. I really appreciate your
> > effort - it sets me back on earth and to work. I hope this rating would
> > also make owners of code more ambitious, and would inspire them to write
> > more/better comments to get a better rating :)
> >
> > Question on output measurement: can we rate source files or code
> > elements (structure, functions, etc) instead of html files?
> > My concerns:
> > - Many html files are autogenerated, their rating is N/A. examples:
> > todo.html, functions_vars_0x68.html (listing of links to functions in
> > alphabetical order - there are many pages like that)
> > - Some results are duplicated, because each struct/function has an
> > individual rating + rating of the file/group reference it belongs to.
> > - Some files have a high rating (see the top candidate, for example),
> > but it's generated from comments marked with @page. These don't belong
> > to specific code, but create a narrative section. Evaluating these is
> > complex, and perhaps, should not be done. My personal preference would
> > be to move such generic explanations to component docs on the website
> > and reserve Doxygen docs to API reference as much as possible (this is a
> > subject for further discussion).
> > - the listing of files is SO LONG... grouping them by
> > file/component/type or otherwise organizing the output would make the
> > whole rating more readable. I mean, from the current version, I can only
> > make out the leaders (not files even, individual bits of them), and
> > understand that the majority have 0 rating. This has its instructional
> > impact, but I cannot see the areas where we are the best - bearable -
> > worst, or see the approx distribution of powers... missing that info
> > leaves me without direction on what to do.
> >
> > Question on data presentation: do you think we can have some post
> > processing of the raw data that your script produces - to see the big
> > picture? We have some metrics: graphics, pie charts, anything. This
> > would instantly show the most important conclusions. I could do such
> > metrics and post them reg

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Alexey Varlamov]

2006/11/3, Alexey Petrenko <[EMAIL PROTECTED]>:

More and more good new from day to day :)

Thanks, Leo!

SY, Alexey

2006/11/3, Leo Li <[EMAIL PROTECTED]>:
> Hi, all
>  I have just tested JUnit4.1 on Harmony.
>  With J9 VM, harmony passes both on windows xp2 and redhat enterprise
> 4.0. While drlvm fails on linux, which fails to create new thread becauseof
> out-of-memory-error. Since it can always be reproduced, I think actually
> system doesnot lack memory at the time. So I reported it as an
> application-oriented bugs as JIRA [1].
>  Besides I have got the time used in these tests which shows there is
> space for us to improve our performance.
>
> VM
>
> Windows xp2
>
>   Redhat Enterprise4
>
> RI
>
> 0.985+0.921
>
>   0.75+0.717
>
> J9
>
> 4.25+2.61
>
>   2.888+2.897
>
> drlvm
>
> 8.437+5.359
>
> /
>
> *The former data represents the time to run junit.tests.AllTests The latter,
> junit.samples.AllTests.
> For detailed information, including how to run tests, I have posted it
> on Harmony wiki[2].
>


Looking at this times, I'd say they are mostly about startup time, not
steady performance per se. I wonder how different these numbers are
for release vs debug builds - guess Leo used debug versions.
And surely there are some tricks RI does to achieve this momentary
startup - as ClassDataSharing or resident-in-memory VM core after very
first start.
I eager to anticipate Harmony will compete strongly in this field soon enough.



>
> [1]http://issues.apache.org/jira/browse/HARMONY-2060
> [2]http://wiki.apache.org/harmony/JUnit
> --
> Leo Li
> China Software Development Lab, IBM
>
>

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Stepan Mishura]

On 11/2/06, Ivanov, Alexey A wrote:


Hi all,

I've started fixing HARMONY-1809. To remove throws clause from the
declaration of replace method, as it was proposed by Oleg in
HARMONY-1975, I placed removeItems() and insertItems() calls into
try-catch block. This would work OK for any valid arguments.

I was going to handle invalid arguments by making adjustments so that
the following removeItems() and insertItems() will not throw the
exception. After I wrote several tests, I faced strange behaviour of RI
with regards to invalid arguments to replace.

(The Javadoc say nothing about which valid ranges for replace()
parameters as well as any exceptions.)

RI accepts invalid arguments but the result differs from what I'd
expect.
For example, if the content has "text" in it, I'd expect that
content.replace(-2, 4, null, 0) would give "xt" as the result. I mean
the invalid start position is adjusted to 0, and the length of remove is
adjusted to be 2 accordingly. But this is not the case. As the result of
this call, all characters are removed leaving "" in the content.

Moreover the content object becomes unusable after that:
content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.

Similarly if number of characters to be removed is greater than the
length of the content (content.replace(2, 4, null, 0) with "text" in
it), the object will throw ArrayIndexOutOfBoundsException when doing
insertString.


Considering the fact that GapContent is pretty low-level class in text
representation model and that it is protected, I think that Harmony
implementation can silently ignore BadLocationException possible thrown
from insertItems() and removeItems(). Taking into account erroneous
behaviour of RI's replace, we can do that until an application is
broken.

As another option, we can throw an Error from catch block to make
application which depends on implementation of replace() fast-fail.


Any objections, comments, opinions?




Hi Alexey,

I'm not quite convinced by your evaluation (I'm not an expert in Swing API
so I may be wrong). My experiments with GapContent showed that Harmony
initially created different object then RI, for example, if you create an
object with GapContent() constructor, Harmony will return start==0 and
end==9 while RI will return start==1 and end==10. The next point that
confuses me that the spec. says about position as "logical position in the
storage"...and... "This is not the location in the underlying storage
array". So negative value for position may be considered as valid.

Thanks,
Stepan.

Thanks,

Alexey.


P.S. The related JIRA issues:
https://issues.apache.org/jira/browse/HARMONY-1809
https://issues.apache.org/jira/browse/HARMONY-1975

GapContent Javadoc:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
Description of GapContent.replace:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
#replace(int,%20int,%20java.lang.Object,%20int)


--
Alexey A. Ivanov
Intel Middleware Product Division





--
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] Class unloading support

[Aleksey Ignatenko]

Rana,

Aleksey, how would one test this?

FIrst of all acceptance tests should PASS. This is required because jitted
code allocation mechanism was changed.  The second: I will try to provide
one simple test on class unloading today. We can use class unloading
implementation in Harmony-2000 to pass it.


The second part is class unloading design implementation (the best
>class unloading approach is discussed now).
I did not understand, sorry:-) Which best approach?

It was evening already yersteady, so I probably did not expressed my
thoughts correctly,  :) I ment that there at least 3 proposal in Harmony dev
list on class unloading, and "the best approach" is the one accepted by
Harmony as best according to different criteria like performance, etc.

Aleksey.

On 11/2/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:


On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>
> >Hi, everyone.
>
> >I've splitted Harmony-2000 (see details:
> >http://issues.apache.org/jira/browse/HARMONY-2000) patch >with
automatic
> >class unloading implementation into 2 independent parts:
> >1. cleaning native resources (native_sources_cleanup.patch).
> >2. automatic unloading design implementation (auto_unloading.patch).
>
> >The first part is independent for all class unloading designs >and
could
> be
> >commited.


Aleksey, how would one test this?

>The second part is class unloading design implementation (the best
> >class unloading approach is discussed now).


I did not understand, sorry:-) Which best approach?

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Alexey Petrenko]

More and more good new from day to day :)

Thanks, Leo!

SY, Alexey

2006/11/3, Leo Li <[EMAIL PROTECTED]>:

Hi, all
 I have just tested JUnit4.1 on Harmony.
 With J9 VM, harmony passes both on windows xp2 and redhat enterprise
4.0. While drlvm fails on linux, which fails to create new thread becauseof
out-of-memory-error. Since it can always be reproduced, I think actually
system doesnot lack memory at the time. So I reported it as an
application-oriented bugs as JIRA [1].
 Besides I have got the time used in these tests which shows there is
space for us to improve our performance.



VM

Windows xp2

  Redhat Enterprise4

RI

0.985+0.921

  0.75+0.717

J9

4.25+2.61

  2.888+2.897

drlvm

8.437+5.359

/

*The former data represents the time to run junit.tests.AllTests The latter,
junit.samples.AllTests.
For detailed information, including how to run tests, I have posted it
on Harmony wiki[2].



[1]http://issues.apache.org/jira/browse/HARMONY-2060
[2]http://wiki.apache.org/harmony/JUnit
--
Leo Li
China Software Development Lab, IBM

[classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Leo Li]

Hi, all
I have just tested JUnit4.1 on Harmony.
With J9 VM, harmony passes both on windows xp2 and redhat enterprise
4.0. While drlvm fails on linux, which fails to create new thread becauseof
out-of-memory-error. Since it can always be reproduced, I think actually
system doesnot lack memory at the time. So I reported it as an
application-oriented bugs as JIRA [1].
Besides I have got the time used in these tests which shows there is
space for us to improve our performance.



VM

Windows xp2

 Redhat Enterprise4

RI

0.985+0.921

 0.75+0.717

J9

4.25+2.61

 2.888+2.897

drlvm

8.437+5.359

   /

*The former data represents the time to run junit.tests.AllTests The latter,
junit.samples.AllTests.
   For detailed information, including how to run tests, I have posted it
on Harmony wiki[2].



[1]http://issues.apache.org/jira/browse/HARMONY-2060
[2]http://wiki.apache.org/harmony/JUnit
--
Leo Li
China Software Development Lab, IBM

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Rana Dasgupta]

Hi,
 I did not want to start a new thread for this. Could someone please close
JIRA issues 1109, 1662, 1830? These have been fixed by recent changes in the
stack and exception handling. In any case, none of them repro. Comments on
teh JIRA.

Thanks,
Rana


On 10/25/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:


Geir
Some tests launched by command "build test" fail.
The idea of  "build test" is to run it before each commit. In this way you
can catch regressions.
In order to effectively catch regressions, i.e. tests that started to fail
after some change,
it's necessary to have 'build test' pass in a stable way. One of the ways
to achieve stable state
is to exclude failing tests or tests which show unstable behavior.
So I analysed statistics of test runs on win ia32 platform and made up a
list of tests to be excluded:
1) smoke
*** gc.LOS fails always on jitrino and interpreter, debug and release
2) kernel
*** java.lang.ClasssGenericsTest and
*** java.lang.ClassGenericsTest4 fail because of timeout, so I  increase
timeout in kernel.test.xml
*** java.lang.ObjectTest fail on interpreter with following message:
Testsuite: java.lang.ObjectTest
Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec
Testcase: testWait1(java.lang.ObjectTest): FAILED
An InterruptedException must be thrown in test thread!
   junit.framework.AssertionFailedError: An InterruptedException must be
thrown in test thread!

See HARNONY-1966 issue with attached patch.


Vera Volynets
Intel Middleware ProductsDivision

Re: [drlvm] Class unloading support - tested one approach

[Rana Dasgupta]

On 11/2/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:


>Robin, thanks for all the clarifications. Now it seems clear to me >and
>I am convinced by this proposal. :-)



Yes, this proposal is the simplest and has the least perf impact. Thanks
Robin.

[general] version of GCC...

[Geir Magnusson Jr.]

did we ever bottom out on what range of GCC we'll support?

I have a patch I want to commit that is known to not compile under 4.1.1...

geir

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

So this has been a long and exciting thread, and it's still not clear 
that we understand each other.  There are at least two different models 
here.


I'll go re-read and try and clarify the difference, and I suppose the 
next step for Etienne would be an example of how his approach works.  It 
will be fun to play with.


geir

Geir Magnusson Jr. wrote:



Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

The "communication" aspect of 2 can be quite helpful when doing
system-wide changes.  Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
syntax-based.  So, if your new indenter moves things across lines,
you're in hell.


So here's where I'm starting to believe I'm missing something
important :

Can you give me an example of the "communication" that you imagine
taking place here?  That's the part I'm just not grokking here.

How about: j2se5 developers, seeing that his planned modification to
some code will lead to utterly broken nearby j2se6 (commented) code
fragments, steps on this mailing list and asks j2se6 developers to help
him find the most harmless way to do the change (or, at least,warn them
about the problem)?

Ok - we do that now.  I thought you were saying that your tool added
somehow to communications.


I am not saying that using the tool should replace using branches for
all situations, but there are situations where it would be more
effective not to use branches when the code is mostly identical.  

I want to avoid branches at all costs.

[somewhat off-topic]  I think that we should consider tools/approaches
on their merit.  Sometimes, branches are the right solution...  You
wouldn't want to use syntax-processing instead of branches for managing
sandboxes. ;-)

I'm trying to figure out the merit here.


I believe that there will still be a role for branches, both for
sandboxes to experiment as Etienne said, and for the maintenance streams
of our releases.


Of course we aren't going to ban branches.  The context is branching for 
mainline code.  Lets stay focused...





Clearly there's some confusion here.  My goal is to

1) Avoid branches at all costs so we can share as much code, and 
get as
much benefit for collaboration between different versions, and 
different

platforms, if that happens.

Agreed.


2) make it simple to work in either the 'master' code, or the 'target'
code through tooling, including standard IDE activities like debugging

Agreed.


3) make it easy for users to report bugs based on 'target' code,
including patches and line numbers


Ah!  That's something to add to my requirements.  Fine!  I hadn't
included the "patches" thing into account.  It doesn't break what I've
exposed so far; it simply adds to it.

It has to be the case - we'll do snapshots and distributions of
"src.jar" and when a developer goes into the debugger, they need to see
normal Java SE 5 code.


Agreed -- our src.jar will be 'normal' Java code without multi-target
mark-ups.



That's neat.  I like it.  Yet, we would encourage developers to work 
and

submit patches using devtarget code, instead of releasetarget code.

I don't know this terminology.  I was using "master" being the code in
SVN, and "target", being the code Y, so the map is :

  master == devtarget
  target == releasetarget

right?  Ok.


There are multiple 'devtarget's -- each contains all the source code
marked-up for every target being developed, but each is distinct by
having different targets uncommented.  Since each devtarget contains the
entire source code it is possible to accurately transform from any one
devtarget to any other devtarget.  One of the devtargets is actually
stored in svn, and that is the canonical form of the devtarget code.


So that's 'master'. and everythign else is a transformed master, right?





I want to work in the master code w/ an IDE plugin that lets me think
I'm in target (and lets me flip back to master).  No preprocessing of
the tree is required to develop.

However, end-users - people who take our JDK and work with it, will
report bugs with stacktraces and line numbers that are from
target/releasetarget code.


Screech -- the releasetarget, by definition, does not contain the source
for all possible targets so that it is consumable by end-users.


That is correct.

The only code that contains all code is master.





So what to do with a patch?

I can either

  patch -p0 << reverse(patch.file)


I don't understand how you will ensure there is enough information in
patch.file to make the reverse() function exact?  I proposed that our
releasetarget code contains tie-points where it is out of sync with the
closest devtarget by some number of lines.


I don't understand why you'd bother.  If you know that patch P creates 
Y' from a given Y, and you can always create Y as you know everything to 
do the xform from master sourc

Re: svn commit: r470383 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java

[Mikhail Loenko]

Hi Alexey

One more suggestion:

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

Thanks,
Mikhail

2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:

Missed this.
Thanks, Tim.

SY, Alexey

2006/11/2, Tim Ellison <[EMAIL PROTECTED]>:
> This file needs an ASF block comment.
>
> Regards,
> Tim
>
> [EMAIL PROTECTED] wrote:
> > Author: apetrenko
> > Date: Thu Nov  2 07:20:33 2006
> > New Revision: 470383
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=470383
> > Log:
> > Patch from HARMONY-1509 applied
> > OceanTheme added
> >
> > Added:
> > 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
> >
> > Added: 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
> > URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java?view=auto&rev=470383
> > 
==
> > --- 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
 (added)
> > +++ 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
 Thu Nov  2 07:20:33 2006
> > @@ -0,0 +1,85 @@
> > +package javax.swing.plaf.metal;
> > +
> > +import javax.swing.UIDefaults;
> > +import javax.swing.plaf.ColorUIResource;
> > +
> > +public class OceanTheme extends DefaultMetalTheme {
> > +
> > +@Override
> > +public String getName() {
> > +return "Ocean";
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getPrimary1() {
> > +// TODO implement
> > +return super.getPrimary1();
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getPrimary2() {
> > +// TODO implement
> > +return super.getPrimary2();
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getPrimary3() {
> > +// TODO implement
> > +return super.getPrimary3();
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getSecondary1() {
> > +// TODO implement
> > +return super.getSecondary1();
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getSecondary2() {
> > +// TODO implement
> > +return super.getSecondary2();
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getSecondary3() {
> > +// TODO implement
> > +return super.getSecondary3();
> > +}
> > +
> > +@Override
> > +public void addCustomEntriesToTable(UIDefaults uiDefs) {
> > +// TODO implement
> > +super.addCustomEntriesToTable(uiDefs);
> > +}
> > +
> > +@Override
> > +protected ColorUIResource getBlack() {
> > +// TODO implement
> > +return super.getBlack();
> > +}
> > +
> > +@Override
> > +public ColorUIResource getControlTextColor() {
> > +// TODO implement
> > +return super.getControlTextColor();
> > +}
> > +
> > +@Override
> > +public ColorUIResource getDesktopColor() {
> > +// TODO implement
> > +return super.getDesktopColor();
> > +}
> > +
> > +@Override
> > +public ColorUIResource getInactiveControlTextColor() {
> > +// TODO implement
> > +return super.getInactiveControlTextColor();
> > +}
> > +
> > +@Override
> > +public ColorUIResource getMenuDisabledForeground() {
> > +// TODO implement
> > +return super.getMenuDisabledForeground();
> > +}
> > +
> > +}
> >
> >
> >
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>

Re: [drlvm] Class unloading support - tested one approach

[Xiao-Feng Li]

On 11/3/06, Robin Garner <[EMAIL PROTECTED]> wrote:

Xiao-Feng Li wrote:
> Robin, good idea.
>
> I understand the main difference between your design and Aleksey's
> proposal 1 is, the tracing in your design stops as vtable, but
> Aleksey's continues to classloader. On the other hand, your approach
> requires an extra step to sweep the vtables in order to determine the
> classloaders' reachability.

Actually there are quite a few more differences:
- This mark phase is built into the standard GC trace, like Aleksey's
automatic class unloading proposal.
- This approach requires no additional fields in headers or objects
(except maybe something to allow enumeration of vtables if this doesn't
already exist)
- The additional mark comes at an extremely low cost as discussed
previously.

The operation to sweep vtables is very cheap, and only needs to be done
when you believe there are classloaders that can be unloaded, rather
than at every GC.  You might for example trigger class unloading every
time a new classloader is loaded.

> If this is true, why not just let the tracing to continue as a
> complete step to determine the classloaders' reachability?

Because that adds a large overhead to every GC, and requires vtables and
classloader structures to be traced at every GC.  While the numbers of
vtables is not large, the number of pointers to them is.  The particular
flavour of mark in my proposal is much cheaper than the standard test
and mark operation.

> Another difference is to mark the reachability with an unconditional
> write instead of a bit mask write. I think this can be applied to
> either approach.

Not really.

If you use an unconditional mark, you lose the ability to test whether
any particular mark is the first, and therefore enqueue an object for
scanning only once, and therefore the heap trace can never complete.
You can only use unconditional marks to process 'leaf' objects in the heap.

You can always turn a bit map into a byte map and avoid synchronized
update, but you can't eliminate the dependent load in a standard trace
algorithm.  The difference in performance between a load-test-write and
a load-test-mask-write is insignificant.


Of course a separate trace of the heap is an attractive operation - in
MMTk, this is simple to build because the transitive closure code can
simply be subclassed (eg the sanity checker is ~250 lines of code).
Depending on how reusable the DRLVM heap trace code is, this may or may
not be a good option.


Robin, thanks for all the clarifications. Now it seems clear to me and
I am convinced by this proposal. :-)

Thanks,
xiaofeng


cheers,
Robin


> Thanks,
> xiaofeng
>
> On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:
>> Actually, just thinking about how I would implement this in JikesRVM, I
>> would use the reachability based algorithm, but piggyback on the
>> existing GC mechanisms:
>>
>> - Allocate a byte (or word) in each vtable for the purpose of tracking
>> class reachability.
>> - Periodically, at a time when no GC is running (even the most
>> aggressive concurrent GC algorithms have these, I believe), zero this
>> flag across all vtables.  This is the beginning of a class-unloading
>> epoch.
>> - During each GC, when the GC is fetching the GC map for an object,
>> *unconditionally* write a value to the class reachability byte.  It may
>> make sense for this byte to be in either the first cache-line of the
>> vtable, or the cache line that points to the GC map - just make sure the
>> mark operation doesn't in general fetch an additional cache line.
>> - At a point in the sufficiently far future, when all reachable objects
>> are known to have been traced by the GC, sweep the vtables and check the
>> reachability of the classloaders.
>>
>> The features of this approach are:
>>
>> - Minimal additional work at GC time.  The additional write will cause
>> some additional memory traffic, but a) it's to memory that is already
>> guaranteed to be in L1 cache, and b) it's an unconditional independent
>> write, and c) multiple writes to common classes will be absorbed by the
>> write buffer.
>>
>> - Space cost of at most 1 word per vtable.
>>
>> - This works whether vtables are objects or VM structures
>>
>> - If the relationship between a class and a vtable is not 1:1, this only
>> need affect the periodic sweep process, which should be infrequent and
>> small compared to a GC.
>>
>> - shouldn't need a stop-the-world at any point.
>>
>> I've implemented and tested the GC-relevant part of this in JikesRVM,
>> and the GC time overhead appears to be just under 1% in the MMTk
>> MarkSweep collector.
>>
>> cheers,
>> Robin
>>

Re: [DRLVM][MMTk] looking for volunteers to work on this port

[Robin Garner]

Weldon Washburn wrote:

All,

It seems committing patches to drlvm and chasing down VM stability 
issues is

taking most of my time.  I would certainly welcome volunteer(s) interested
in moving the drlvm/mmtk port forward.  What needs to be done is described
in an Oct 23 email titled, "[DRLVM][MMTk] current status and plan".



I'm enthusiastic about providing assistance to whoever takes it on, but 
don't have time to take it on myself.  Besides, I think at the present 
moment it requires someone who understands DRLVM well more than an MMTk 
hacker.


Robin

Re: [drlvm] Class unloading support - tested one approach

[Robin Garner]

Xiao-Feng Li wrote:

Robin, good idea.

I understand the main difference between your design and Aleksey's
proposal 1 is, the tracing in your design stops as vtable, but
Aleksey's continues to classloader. On the other hand, your approach
requires an extra step to sweep the vtables in order to determine the
classloaders' reachability.


Actually there are quite a few more differences:
- This mark phase is built into the standard GC trace, like Aleksey's 
automatic class unloading proposal.
- This approach requires no additional fields in headers or objects 
(except maybe something to allow enumeration of vtables if this doesn't 
already exist)
- The additional mark comes at an extremely low cost as discussed 
previously.


The operation to sweep vtables is very cheap, and only needs to be done 
when you believe there are classloaders that can be unloaded, rather 
than at every GC.  You might for example trigger class unloading every 
time a new classloader is loaded.



If this is true, why not just let the tracing to continue as a
complete step to determine the classloaders' reachability?


Because that adds a large overhead to every GC, and requires vtables and 
classloader structures to be traced at every GC.  While the numbers of 
vtables is not large, the number of pointers to them is.  The particular 
flavour of mark in my proposal is much cheaper than the standard test 
and mark operation.



Another difference is to mark the reachability with an unconditional
write instead of a bit mask write. I think this can be applied to
either approach.


Not really.

If you use an unconditional mark, you lose the ability to test whether 
any particular mark is the first, and therefore enqueue an object for 
scanning only once, and therefore the heap trace can never complete. 
You can only use unconditional marks to process 'leaf' objects in the heap.


You can always turn a bit map into a byte map and avoid synchronized 
update, but you can't eliminate the dependent load in a standard trace 
algorithm.  The difference in performance between a load-test-write and 
a load-test-mask-write is insignificant.



Of course a separate trace of the heap is an attractive operation - in 
MMTk, this is simple to build because the transitive closure code can 
simply be subclassed (eg the sanity checker is ~250 lines of code). 
Depending on how reusable the DRLVM heap trace code is, this may or may 
not be a good option.


cheers,
Robin



Thanks,
xiaofeng

On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:

Actually, just thinking about how I would implement this in JikesRVM, I
would use the reachability based algorithm, but piggyback on the
existing GC mechanisms:

- Allocate a byte (or word) in each vtable for the purpose of tracking
class reachability.
- Periodically, at a time when no GC is running (even the most
aggressive concurrent GC algorithms have these, I believe), zero this
flag across all vtables.  This is the beginning of a class-unloading 
epoch.

- During each GC, when the GC is fetching the GC map for an object,
*unconditionally* write a value to the class reachability byte.  It may
make sense for this byte to be in either the first cache-line of the
vtable, or the cache line that points to the GC map - just make sure the
mark operation doesn't in general fetch an additional cache line.
- At a point in the sufficiently far future, when all reachable objects
are known to have been traced by the GC, sweep the vtables and check the
reachability of the classloaders.

The features of this approach are:

- Minimal additional work at GC time.  The additional write will cause
some additional memory traffic, but a) it's to memory that is already
guaranteed to be in L1 cache, and b) it's an unconditional independent
write, and c) multiple writes to common classes will be absorbed by the
write buffer.

- Space cost of at most 1 word per vtable.

- This works whether vtables are objects or VM structures

- If the relationship between a class and a vtable is not 1:1, this only
need affect the periodic sweep process, which should be infrequent and
small compared to a GC.

- shouldn't need a stop-the-world at any point.

I've implemented and tested the GC-relevant part of this in JikesRVM,
and the GC time overhead appears to be just under 1% in the MMTk
MarkSweep collector.

cheers,
Robin

Re: [drlvm][sablevm] Desing of Class Unloading Support

[Ivan Volosyuk]

On 11/2/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:

On 11/2/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> Xiao-Feng Li wrote:
> > On 11/1/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> >> On 01 Nov 2006 16:05:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >> >
> >> > On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> >> > > On 01 Nov 2006 15:56:28 +0600, Egor Pasko <[EMAIL PROTECTED]>
> >> wrote:
> >> > > >
> >> > > > agreed. not patching .. just reporting 'golden' VTable refs to
> >> GC, am
> >> > > > I right?
> >> > > >
> >> > > Yes, and everytime we report it to GC and GC moves an object - it
> >> > patches
> >> > > the address we report.
> >> >
> >> > so, by saying "patching" you insist to put immediate operands into
> >> > instructions? That's probably worth it, but it extends the JIT<->GC
> >> > interface. How about making a simple operand (reg/mem) as the first
> >> step?
> >>
> >>
> >> Egor, I thinks this is slightly more complicated problem. If vtable
> >> object
> >> is moved we must update all devirtualization points in every method
> >> compiled
> >> before. It can require an extension of JIT<->VM<->GC interface.
> >> Another solution I see is to collect info about all devirtualization
> >> points
> >> in JIT (code addrs) and report these addresses as enumeration roots.
> >> This is
> >> JIT-only solution, and disadvantage is a significant (~hot methods count)
> >> increase of number of objects reported.
> >>
> >> On the other hand I see no reasons to unpin vtables in the nearest future
> >> (Let's GC guru correct me). If you use special (freelist-type ?)
> >> allocator
> >> in GC the memory fragmentation when unloading pinned vtable objects
> >> could be
> >> low.
> >
> > Yes, vtable should never be moved except for very weird reason. And
> > yes, to pin certain amount of objects is not a big performance issue
> > (in both temporal and spatial wise).
> >
> > -xiaofeng
> >
> >> --
> >> Mikhail Fursov
> >>
> >>
>
> In MMTk, this kind of 'pinning' is an allocation-time policy decision of
> the type I was advocating in the GC helpers thread.  Once a GC allows
> for the idea of supporting multiple collection policies (which
> generational GC requires in any case), then adding a non-moving space to
> a memory manager is easy.
>
> Most memory managers will have a non-moving large object space no matter
>   what the primary collection policy is.  The DRLVM collectors have this
> too, don't they ?
> Pinning an object after allocation is a harder problem, but not
> something required in this case.

Yes, I agree with all what you said. And DRLVM GCv4/v5 doesn't move
large objects at the moment.


GCv4.1 does. There is no problems to support pinned allocation here anyway.

--
Ivan
Intel Enterprise Solutions Software Division

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

The "communication" aspect of 2 can be quite helpful when doing
system-wide changes.  Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
syntax-based.  So, if your new indenter moves things across lines,
you're in hell.


So here's where I'm starting to believe I'm missing something
important :

Can you give me an example of the "communication" that you imagine
taking place here?  That's the part I'm just not grokking here.

How about: j2se5 developers, seeing that his planned modification to
some code will lead to utterly broken nearby j2se6 (commented) code
fragments, steps on this mailing list and asks j2se6 developers to help
him find the most harmless way to do the change (or, at least,warn them
about the problem)?

Ok - we do that now.  I thought you were saying that your tool added
somehow to communications.


I am not saying that using the tool should replace using branches for
all situations, but there are situations where it would be more
effective not to use branches when the code is mostly identical.  

I want to avoid branches at all costs.

[somewhat off-topic]  I think that we should consider tools/approaches
on their merit.  Sometimes, branches are the right solution...  You
wouldn't want to use syntax-processing instead of branches for managing
sandboxes. ;-)

I'm trying to figure out the merit here.


I believe that there will still be a role for branches, both for
sandboxes to experiment as Etienne said, and for the maintenance streams
of our releases.


Of course we aren't going to ban branches.  The context is branching for 
mainline code.  Lets stay focused...





Clearly there's some confusion here.  My goal is to

1) Avoid branches at all costs so we can share as much code, and get as
much benefit for collaboration between different versions, and different
platforms, if that happens.

Agreed.


2) make it simple to work in either the 'master' code, or the 'target'
code through tooling, including standard IDE activities like debugging

Agreed.


3) make it easy for users to report bugs based on 'target' code,
including patches and line numbers


Ah!  That's something to add to my requirements.  Fine!  I hadn't
included the "patches" thing into account.  It doesn't break what I've
exposed so far; it simply adds to it.

It has to be the case - we'll do snapshots and distributions of
"src.jar" and when a developer goes into the debugger, they need to see
normal Java SE 5 code.


Agreed -- our src.jar will be 'normal' Java code without multi-target
mark-ups.




That's neat.  I like it.  Yet, we would encourage developers to work and
submit patches using devtarget code, instead of releasetarget code.

I don't know this terminology.  I was using "master" being the code in
SVN, and "target", being the code Y, so the map is :

  master == devtarget
  target == releasetarget

right?  Ok.


There are multiple 'devtarget's -- each contains all the source code
marked-up for every target being developed, but each is distinct by
having different targets uncommented.  Since each devtarget contains the
entire source code it is possible to accurately transform from any one
devtarget to any other devtarget.  One of the devtargets is actually
stored in svn, and that is the canonical form of the devtarget code.


So that's 'master'. and everythign else is a transformed master, right?





I want to work in the master code w/ an IDE plugin that lets me think
I'm in target (and lets me flip back to master).  No preprocessing of
the tree is required to develop.

However, end-users - people who take our JDK and work with it, will
report bugs with stacktraces and line numbers that are from
target/releasetarget code.


Screech -- the releasetarget, by definition, does not contain the source
for all possible targets so that it is consumable by end-users.


That is correct.

The only code that contains all code is master.





So what to do with a patch?

I can either

  patch -p0 << reverse(patch.file)


I don't understand how you will ensure there is enough information in
patch.file to make the reverse() function exact?  I proposed that our
releasetarget code contains tie-points where it is out of sync with the
closest devtarget by some number of lines.


I don't understand why you'd bother.  If you know that patch P creates 
Y' from a given Y, and you can always create Y as you know everything to 
do the xform from master source and the platform name, everything is known.





on the main code or use patching facilities in an IDE to patch the
transform view

Man, this tooling is going to be fancy! :/



In other words, here's how I see the distribution(s):

 - Binary j2se5 Harmony release:  includes j2se5release src.jar for
   end-developers using debuggers to step through API code

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Alexei Fedotov]

Nadya,

You asked good questions. Here are few answers:

1. Grouping of results is implied by documentation grouping. Scripts
can process any documentation bundle, so if one creates a smaller or
specific bundle, the list will be shorter, or more specific.Creating
several documentation bundles in different directories makes their
comparison an easy task - I can do this comparison.

2. Personally I like @page tags and package.html files. I appreciate
Salikh's efforts of creating wonderful technical descriptions - I
referred to them as masterpieces. I also remember that you asked me to
create a narrative section for a component manager few months ago. All
Doxygen documentation will be on the web site. Why these narrative
sections shouldn't be evaluated?

3. I don't think the rating of pages such as a list of functions
should be neglected. Any .html page which can be viewed by a user
should be readable. That is a reason why I parse .html files in the
script, not sources.

4. I believe establishing connection between .html files and source
files can be automated. I don't know how to write a short script for
that, because sometimes .html page depends from several source files,
and vice versa.

5. You can imagine the following pie chart from the data: 2680 pages
of 2922 (91%) are not good and should be revised.

6.  Today the community discussed removing GC V4. This would
immediately decrease GC documentation size. It would also decrease a
number of well documented pages on garbage collection, since new GCs
don't have as much comments in their code as old GC V4.

Thank you for nice catches,
Alexei



On 11/2/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:

Wow! Alexei, great start!
... and so many pages marked with 0 rank. I really appreciate your
effort - it sets me back on earth and to work. I hope this rating would
also make owners of code more ambitious, and would inspire them to write
more/better comments to get a better rating :)

Question on output measurement: can we rate source files or code
elements (structure, functions, etc) instead of html files?
My concerns:
- Many html files are autogenerated, their rating is N/A. examples:
todo.html, functions_vars_0x68.html (listing of links to functions in
alphabetical order - there are many pages like that)
- Some results are duplicated, because each struct/function has an
individual rating + rating of the file/group reference it belongs to.
- Some files have a high rating (see the top candidate, for example),
but it's generated from comments marked with @page. These don't belong
to specific code, but create a narrative section. Evaluating these is
complex, and perhaps, should not be done. My personal preference would
be to move such generic explanations to component docs on the website
and reserve Doxygen docs to API reference as much as possible (this is a
subject for further discussion).
- the listing of files is SO LONG... grouping them by
file/component/type or otherwise organizing the output would make the
whole rating more readable. I mean, from the current version, I can only
make out the leaders (not files even, individual bits of them), and
understand that the majority have 0 rating. This has its instructional
impact, but I cannot see the areas where we are the best - bearable -
worst, or see the approx distribution of powers... missing that info
leaves me without direction on what to do.

Question on data presentation: do you think we can have some post
processing of the raw data that your script produces - to see the big
picture? We have some metrics: graphics, pie charts, anything. This
would instantly show the most important conclusions. I could do such
metrics and post them regularly on Wiki. If anybody says they need such
kind of info, I'd volunteer to help.

Thank you,
Nadya Morozova


-Original Message-
From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 11:33 PM
To: harmony-dev@incubator.apache.org
Subject: [doc] What should be improved in DRLVM Doxygen documentation?

Nadya, All,
I have ranked the quality of Doxygen-generated DRLVM documentation and
posted it to the following Wiki page:

   http://wiki.apache.org/harmony/DRLVM_Documentation_Quality

All are welcome to check masterpieces of our documentation. All
volunteers are welcome to improve page ranks by editing comments in
DRLVM sources.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

Re: [classlib] Preprocessor - CHECKPOINT

[Tim Ellison]

Geir Magnusson Jr. wrote:
> Etienne Gagnon wrote:
>> Geir Magnusson Jr. wrote:
 The "communication" aspect of 2 can be quite helpful when doing
 system-wide changes.  Just think about the effect of simply doing a
 system-wide reindentation of source code; this is a nightmare when
 developing using branches, as diff/merge tools are line-based, not
 syntax-based.  So, if your new indenter moves things across lines,
 you're in hell.

>>> So here's where I'm starting to believe I'm missing something
>>> important :
>>>
>>> Can you give me an example of the "communication" that you imagine
>>> taking place here?  That's the part I'm just not grokking here.
>>
>> How about: j2se5 developers, seeing that his planned modification to
>> some code will lead to utterly broken nearby j2se6 (commented) code
>> fragments, steps on this mailing list and asks j2se6 developers to help
>> him find the most harmless way to do the change (or, at least,warn them
>> about the problem)?
> 
> Ok - we do that now.  I thought you were saying that your tool added
> somehow to communications.
> 
>>
 I am not saying that using the tool should replace using branches for
 all situations, but there are situations where it would be more
 effective not to use branches when the code is mostly identical.  
>>> I want to avoid branches at all costs.
>>
>> [somewhat off-topic]  I think that we should consider tools/approaches
>> on their merit.  Sometimes, branches are the right solution...  You
>> wouldn't want to use syntax-processing instead of branches for managing
>> sandboxes. ;-)
> 
> I'm trying to figure out the merit here.

I believe that there will still be a role for branches, both for
sandboxes to experiment as Etienne said, and for the maintenance streams
of our releases.

>>> Clearly there's some confusion here.  My goal is to
>>>
>>> 1) Avoid branches at all costs so we can share as much code, and get as
>>> much benefit for collaboration between different versions, and different
>>> platforms, if that happens.
>>
>> Agreed.
>>
>>> 2) make it simple to work in either the 'master' code, or the 'target'
>>> code through tooling, including standard IDE activities like debugging
>>
>> Agreed.
>>
>>> 3) make it easy for users to report bugs based on 'target' code,
>>> including patches and line numbers
>>
>>
>> Ah!  That's something to add to my requirements.  Fine!  I hadn't
>> included the "patches" thing into account.  It doesn't break what I've
>> exposed so far; it simply adds to it.
> 
> It has to be the case - we'll do snapshots and distributions of
> "src.jar" and when a developer goes into the debugger, they need to see
> normal Java SE 5 code.

Agreed -- our src.jar will be 'normal' Java code without multi-target
mark-ups.



>> That's neat.  I like it.  Yet, we would encourage developers to work and
>> submit patches using devtarget code, instead of releasetarget code.
> 
> I don't know this terminology.  I was using "master" being the code in
> SVN, and "target", being the code Y, so the map is :
> 
>   master == devtarget
>   target == releasetarget
> 
> right?  Ok.

There are multiple 'devtarget's -- each contains all the source code
marked-up for every target being developed, but each is distinct by
having different targets uncommented.  Since each devtarget contains the
entire source code it is possible to accurately transform from any one
devtarget to any other devtarget.  One of the devtargets is actually
stored in svn, and that is the canonical form of the devtarget code.

> I want to work in the master code w/ an IDE plugin that lets me think
> I'm in target (and lets me flip back to master).  No preprocessing of
> the tree is required to develop.
> 
> However, end-users - people who take our JDK and work with it, will
> report bugs with stacktraces and line numbers that are from
> target/releasetarget code.

Screech -- the releasetarget, by definition, does not contain the source
for all possible targets so that it is consumable by end-users.

> So what to do with a patch?
> 
> I can either
> 
>   patch -p0 << reverse(patch.file)

I don't understand how you will ensure there is enough information in
patch.file to make the reverse() function exact?  I proposed that our
releasetarget code contains tie-points where it is out of sync with the
closest devtarget by some number of lines.

> on the main code or use patching facilities in an IDE to patch the
> transform view
> 
> Man, this tooling is going to be fancy! :/
> 
> 
>>
>> In other words, here's how I see the distribution(s):
>>
>>  - Binary j2se5 Harmony release:  includes j2se5release src.jar for
>>end-developers using debuggers to step through API code.
>>
>>  - Source j2se5 Harmony release: API are in j2se5dev form.  The build
>>process uses the processing tool to generate j2se5release src.jar.
>>
>>  - Binary j2se6 Harmony release:  includes j2se6release src.jar for
>>end-developers using debuggers to ste

Re: [classlib] Preprocessor - CHECKPOINT

[Tim Ellison]

Etienne Gagnon wrote:
> Geir Magnusson Jr. wrote:
>>> To release code, one would apply:
>>>
>>>  process(X, release-target) => Y
>>>
>>> Now, it is important to understand that Y, in this case, is NOT suitable
>>> for doing any modification as
>>>
>>>  revert(Y) => Kaboom!  (The tool will simply report that it can't do it;
>>> it won't crash.)
>>> ...
>> This is what I thought we were talking about all along - basically
>> starting w/ the full source, and pre-process to the "canonical" source
>> for the target version.
>>
>> However, I don't understand why I can't go backwards, modulo some manual
>> merging if needed.
>>
>> For example, if I have X and release-version, I should be able to take a
>> Y' and resolve back to X'.  There are problematic cases. [...]
> 
> It's the problematic cases I am trying to get entirely rid of "by
> design", by having an "exact" transformation process, in contrast with
> the usual branch/merge "inexact" process.

Yes, this is the key point for me, that the transforms are exactly
reversible so you loose nothing by switching back and forth.

> Of course, this means that development happens using "complete" source
> code (this is either the canonical form or a development target form,
> but not a release form).

Ack, and I agree with the comment made elsewhere that it is useful for
each processed form's developer to see their changes in the context of
all potential processed forms.

> For applying user-provided patches, then it can still be done the good
> old way, using these "little" patches made from release code, but
> applying them directly to the canonical or dev-target code, resolving
> conflicts manually.  [The smaller the patch, the easier it is to apply
> it on files with target-specific code.]

How so?  With a customized patch tool?  Because the end-user's patch
will have line numbers relative to the 'releasetarget' code.

> The idea is that manual processing is never required when coding using
> canonical and dev-target modes.  No inexact modifications, no difficult
> merges, etc.

Hurray.

> And, as a bonus, communication between parrallel target
> developers.  I know, it's an "unusual" development processing tool, but,
> hey, why shouldn't Harmony innovate? :-)

...continue to innovate ;-)

Regards,
Tim

-- 

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

Re: [classlib] Preprocessor - CHECKPOINT

[Tim Ellison]

Etienne Gagnon wrote:
> Tim Ellison wrote:
>>>   For example, if class X of the main version is not part of j2me,
>>>   "process(j2me)" would move this file to a subdirectory ".streams/".
>> Why would you move the files rather than exclude them?
>>
>> I was assuming that the processor would generate a whole new source tree
>> for each process() target, so that you could work on the original
>> checked-out file in it's 'canonicalized form' for Big Java work, or
>> process("jme") into a new location and work in the non-canonical form
>> your Little Java spectacles on.  [...]
> 
> Neat idea!
> 
> I would put the following restriction, though:  one should NOT modify
> more than one target at a time.

Fair enough -- at least for now.

> So, you would probably need some way to prevent parallel modifications
> in "spectacle views".

Perhaps we should agree to use your 'devtarget' term for this :-)

> One way to achieve this:
> 
> process(X,target, destination) =>  Xtarget in a distinct location
>  and X files are changed to read-only and some tracking file F tells us
>  about Xtarget's location.

Sure, should be simple enough if there is a well-known location for this
lock file.  As you say, then developers would work on a single devtarget
at a time in their local workspace, but potentially go back to the
canonical form and switch to another devtarget to check that before
checking in the canonical form.

> So, you would also need:
> 
> release(F)  =>  asks all kind of questions (want to lose changes? delete
> files? etc.)
> 
> Of course:
> 
> revert(F?|destination?) => makes X read-write.
> 
> 
> [Hoping this was clear enough...  It's not a very good explanation...]

Yep, I got it; and it seems quite simple with these restrictions.

>> Agreed.  It would be interesting to determine the most effective
>> location for those markers (measured by reverse mapping accuracy vs.
>> number of markers).
> 
> I am a fan of accuracy...  Yet, maybe it would be simple enough if a
> release was always based on a specific svn URL, then the mark could be
> totally exact using svn keywords... :-)

You lost me here.  I'm trying to define tie-points between the
'releasetarget' source and the canonical form.  AIUI this will require
structured comments in the 'releasetarget', right?

Regards,
Tim

-- 

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

[drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)

[Weldon Washburn]

Pavel,

I just now looked at your latest H1558 patch.  Unfortunately the patch won't
cleanly apply.   It can not be committed yet.  In any case, 1558 seems to
basically reformat the interfaces that access class specific info.  It looks
like a bunch of cosmetic changes.  No change in underlying algorithms.  Is
this correct?

Aleksey, Pavel,

Do you know if there are interdependencies between H1558 and H2000?  In any
case, I believe H1558 should be committed first.  And H2000 will have to
pick up the pieces.

Everyone,

Comments?  Suggestions?

--
Weldon Washburn
Intel Enterprise Solutions Software Division

RE: [doc] What should be improved in DRLVM Doxygen documentation?

[Morozova, Nadezhda]

Wow! Alexei, great start! 
... and so many pages marked with 0 rank. I really appreciate your
effort - it sets me back on earth and to work. I hope this rating would
also make owners of code more ambitious, and would inspire them to write
more/better comments to get a better rating :)

Question on output measurement: can we rate source files or code
elements (structure, functions, etc) instead of html files? 
My concerns:
- Many html files are autogenerated, their rating is N/A. examples:
todo.html, functions_vars_0x68.html (listing of links to functions in
alphabetical order - there are many pages like that)
- Some results are duplicated, because each struct/function has an
individual rating + rating of the file/group reference it belongs to. 
- Some files have a high rating (see the top candidate, for example),
but it's generated from comments marked with @page. These don't belong
to specific code, but create a narrative section. Evaluating these is
complex, and perhaps, should not be done. My personal preference would
be to move such generic explanations to component docs on the website
and reserve Doxygen docs to API reference as much as possible (this is a
subject for further discussion).
- the listing of files is SO LONG... grouping them by
file/component/type or otherwise organizing the output would make the
whole rating more readable. I mean, from the current version, I can only
make out the leaders (not files even, individual bits of them), and
understand that the majority have 0 rating. This has its instructional
impact, but I cannot see the areas where we are the best - bearable -
worst, or see the approx distribution of powers... missing that info
leaves me without direction on what to do.

Question on data presentation: do you think we can have some post
processing of the raw data that your script produces - to see the big
picture? We have some metrics: graphics, pie charts, anything. This
would instantly show the most important conclusions. I could do such
metrics and post them regularly on Wiki. If anybody says they need such
kind of info, I'd volunteer to help. 

Thank you, 
Nadya Morozova
 

-Original Message-
From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 02, 2006 11:33 PM
To: harmony-dev@incubator.apache.org
Subject: [doc] What should be improved in DRLVM Doxygen documentation?

Nadya, All,
I have ranked the quality of Doxygen-generated DRLVM documentation and
posted it to the following Wiki page: 

http://wiki.apache.org/harmony/DRLVM_Documentation_Quality

All are welcome to check masterpieces of our documentation. All
volunteers are welcome to improve page ranks by editing comments in
DRLVM sources. 

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

BTW, I'm more than happy if you just do a quick sketch of what you're 
thinking, and we resume the convo from there.


I just wanted to clear up some confusion I had.

geir


Geir Magnusson Jr. wrote:



Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

The "communication" aspect of 2 can be quite helpful when doing
system-wide changes.  Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
syntax-based.  So, if your new indenter moves things across lines,
you're in hell.

So here's where I'm starting to believe I'm missing something 
important :


Can you give me an example of the "communication" that you imagine
taking place here?  That's the part I'm just not grokking here.


How about: j2se5 developers, seeing that his planned modification to
some code will lead to utterly broken nearby j2se6 (commented) code
fragments, steps on this mailing list and asks j2se6 developers to help
him find the most harmless way to do the change (or, at least,warn them
about the problem)?


Ok - we do that now.  I thought you were saying that your tool added 
somehow to communications.





I am not saying that using the tool should replace using branches for
all situations, but there are situations where it would be more
effective not to use branches when the code is mostly identical.  

I want to avoid branches at all costs.


[somewhat off-topic]  I think that we should consider tools/approaches
on their merit.  Sometimes, branches are the right solution...  You
wouldn't want to use syntax-processing instead of branches for managing
sandboxes. ;-)


I'm trying to figure out the merit here.




Clearly there's some confusion here.  My goal is to

1) Avoid branches at all costs so we can share as much code, and get as
much benefit for collaboration between different versions, and different
platforms, if that happens.


Agreed.


2) make it simple to work in either the 'master' code, or the 'target'
code through tooling, including standard IDE activities like debugging


Agreed.


3) make it easy for users to report bugs based on 'target' code,
including patches and line numbers



Ah!  That's something to add to my requirements.  Fine!  I hadn't
included the "patches" thing into account.  It doesn't break what I've
exposed so far; it simply adds to it.


It has to be the case - we'll do snapshots and distributions of 
"src.jar" and when a developer goes into the debugger, they need to see 
normal Java SE 5 code.





What I've suggested is  :

  forward(X, platform) -> Y

  reverse(X, platform, Y') -> X'


OK.  I see this in *addition* to:

 forward(X, devtarget) -> Y
 reverse(Y') -> X'


I believe that

  reverse(X, palatform, Y') -> X'

is the same as

  reverse(Y') -> X'

as you need to know at least what platform Y' is, and what it came from. 
 You could always embed as metadata in the code itself in a comment, I 
suppose.  I was just being explicit.





So, to simplify the discussion, let's rewrite your proposal as:

 forward(X, releasetarget) -> Y
 reverse(Y',X,releasetarget) ~~> X' (possibly reporting
 conflicts/problems)

That's neat.  I like it.  Yet, we would encourage developers to work and
submit patches using devtarget code, instead of releasetarget code.


I don't know this terminology.  I was using "master" being the code in 
SVN, and "target", being the code Y, so the map is :


  master == devtarget
  target == releasetarget

right?  Ok.

I want to work in the master code w/ an IDE plugin that lets me think 
I'm in target (and lets me flip back to master).  No preprocessing of 
the tree is required to develop.


However, end-users - people who take our JDK and work with it, will 
report bugs with stacktraces and line numbers that are from 
target/releasetarget code.


So what to do with a patch?

I can either

  patch -p0 << reverse(patch.file)

on the main code or use patching facilities in an IDE to patch the 
transform view


Man, this tooling is going to be fancy! :/




In other words, here's how I see the distribution(s):

 - Binary j2se5 Harmony release:  includes j2se5release src.jar for
   end-developers using debuggers to step through API code.

 - Source j2se5 Harmony release: API are in j2se5dev form.  The build
   process uses the processing tool to generate j2se5release src.jar.

 - Binary j2se6 Harmony release:  includes j2se6release src.jar for
   end-developers using debuggers to step through API code.

 - Source j2se5 Harmony release: API are in j2se6dev form.  The build
   process uses the processing tool to generate j2se6release src.jar.


Yes.



Why?  Because reverse works much better with devtarget than
releasetarget code, and the communications benefit of devtarget that are
lost in releasetarget code (because of stream code erasure).  In
addition, using smart IDEs, there wouldn't be much difference for
developers betwee

RE: [classlib][portlib] Docs?

[Morozova, Nadezhda]

My two cents and food for programmer's thought:

1. Doxygen can get the version from a versioning system. Quote from
manual:
The FILE_VERSION_FILTER tag can be used to specify a program or script
that doxygen should invoke to get the current version for each file
(typically from the version control system). Doxygen will invoke the
program by executing (via popen()) the command command input-file, where
command is the value of the FILE_VERSION_FILTER tag, and input-file is
the name of an input file provided by doxygen. Whatever the program
writes to standard output is used as the file version.
Example of using a shell script as a filter for Unix: 

 FILE_VERSION_FILTER = "/bin/sh versionfilter.sh"

Example shell script for Subversion: 

#!/bin/sh
svn stat -v $1 | sed -n 's/^[ A-Z?\*|!]\{1,15\}/r/;s/ \{1,15\}/\/r/;s/
.*//p'

2. Doxygen can process a custom header/footer to display the info you
need. Quote from manual:
HTML_FOOTER 
The HTML_FOOTER tag can be used to specify a user-defined HTML footer
for each generated HTML page. To get valid HTML the footer file should
contain at least a  and a  tag. The following commands
have a special meaning inside the footer: $title, $datetime, $date,
$doxygenversion, $projectname, $projectnumber. Doxygen will replace them
by respectively the title of the page, the current date and time, only
the current date, the version number of doxygen, the project name (see
PROJECT_NAME), or the project number (see PROJECT_NUMBER).


Thank you, 
Nadya Morozova
 

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 02, 2006 4:59 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][portlib] Docs?



Paulex Yang wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Paulex Yang wrote:
>>> Geir Magnusson Jr. wrote:
 yeah - someone generate, and we can hang them on the website.  I'm 
 not sure we'd want to check them in though...
>>> Is it possible to add documents into website but not to commit them 
>>> in SVN?
>>
>> Yep.  I was thinking the same for the Doxygen docs.
>>
>> Basically, you just create locally, review, and then tar and put up
on 
>> site manually.
> +1 to go for that
>>
>> It does remove the ability for group oversight (IOW, no commit msgs),

>> but if the generation process isn't very stale (small changes to one 
>> page have repercussions all over...) then it keeps the SVN churn to a

>> minimum.
> Actually I have no idea what kind of commit msgs needed for API 
> document...they are just generated by tools from codes. I think the
most 
> important information is the svn revision number against which the 
> document is generated, any doxygen guru can help to find a way? Any 
> chance to pass a revision number to doxygen and to get it added into 
> footer of every page?

That's a very smart idea.  +1

geir

>>
>> geir
>>
>>
>>  We removed them from classlib/trunk/doc because the SVN metadata
>>> get in the way when updating the document.

 I've done this before for API docs...

 geir


 Alexey Petrenko wrote:
> Having these docs on website will be really good!
>
> SY, Alexey
>
> 2006/11/1, Paulex Yang <[EMAIL PROTECTED]>:
>> If you get Doxygen installed, you can create it by running "ant
>> doxygen-natives" in classlib/trunk/doc. There were discussions to

>> move
>> the document to somewhere on website, but seems it is still to be

>> done.
>>
>> Morozova, Nadezhda wrote:
>> > Not that I know of :( bits of things are in the devguide,
maybe. 
>> But you
>> > probably won't find that of much notice.
>> > Anyone, please tell me it's not true!
>> >
>> > Thank you,
>> > Nadya Morozova
>> >
>> >
>> > -Original Message-
>> > From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>> > Sent: Wednesday, November 01, 2006 4:15 PM
>> > To: harmony-dev@incubator.apache.org
>> > Subject: [classlib][portlib] Docs?
>> >
>> > Guys,
>> >
>> > do we have any docs on portlib?
>> >
>> > SY, Alexey
>> >
>> >
>>
>>
>> -- 
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>

>>>
>>>
>>
> 
> 

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Rana Dasgupta]

Right, it is in the default code path. So it is regularly exercised, tested,
fixed. v5 is the one in development. If gcv4 is neither being fixed, nor
developed why keep it? Sorry for the double negatives :-)

On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:





I don't grok what you mean -  gcv4.1 is our main GC right now, right?

geir

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

The "communication" aspect of 2 can be quite helpful when doing
system-wide changes.  Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
syntax-based.  So, if your new indenter moves things across lines,
you're in hell.


So here's where I'm starting to believe I'm missing something important :

Can you give me an example of the "communication" that you imagine
taking place here?  That's the part I'm just not grokking here.


How about: j2se5 developers, seeing that his planned modification to
some code will lead to utterly broken nearby j2se6 (commented) code
fragments, steps on this mailing list and asks j2se6 developers to help
him find the most harmless way to do the change (or, at least,warn them
about the problem)?


Ok - we do that now.  I thought you were saying that your tool added 
somehow to communications.





I am not saying that using the tool should replace using branches for
all situations, but there are situations where it would be more
effective not to use branches when the code is mostly identical.  

I want to avoid branches at all costs.


[somewhat off-topic]  I think that we should consider tools/approaches
on their merit.  Sometimes, branches are the right solution...  You
wouldn't want to use syntax-processing instead of branches for managing
sandboxes. ;-)


I'm trying to figure out the merit here.




Clearly there's some confusion here.  My goal is to

1) Avoid branches at all costs so we can share as much code, and get as
much benefit for collaboration between different versions, and different
platforms, if that happens.


Agreed.


2) make it simple to work in either the 'master' code, or the 'target'
code through tooling, including standard IDE activities like debugging


Agreed.


3) make it easy for users to report bugs based on 'target' code,
including patches and line numbers



Ah!  That's something to add to my requirements.  Fine!  I hadn't
included the "patches" thing into account.  It doesn't break what I've
exposed so far; it simply adds to it.


It has to be the case - we'll do snapshots and distributions of 
"src.jar" and when a developer goes into the debugger, they need to see 
normal Java SE 5 code.





What I've suggested is  :

  forward(X, platform) -> Y

  reverse(X, platform, Y') -> X'


OK.  I see this in *addition* to:

 forward(X, devtarget) -> Y
 reverse(Y') -> X'


I believe that

  reverse(X, palatform, Y') -> X'

is the same as

  reverse(Y') -> X'

as you need to know at least what platform Y' is, and what it came from. 
 You could always embed as metadata in the code itself in a comment, I 
suppose.  I was just being explicit.





So, to simplify the discussion, let's rewrite your proposal as:

 forward(X, releasetarget) -> Y
 reverse(Y',X,releasetarget) ~~> X' (possibly reporting
 conflicts/problems)

That's neat.  I like it.  Yet, we would encourage developers to work and
submit patches using devtarget code, instead of releasetarget code.


I don't know this terminology.  I was using "master" being the code in 
SVN, and "target", being the code Y, so the map is :


  master == devtarget
  target == releasetarget

right?  Ok.

I want to work in the master code w/ an IDE plugin that lets me think 
I'm in target (and lets me flip back to master).  No preprocessing of 
the tree is required to develop.


However, end-users - people who take our JDK and work with it, will 
report bugs with stacktraces and line numbers that are from 
target/releasetarget code.


So what to do with a patch?

I can either

  patch -p0 << reverse(patch.file)

on the main code or use patching facilities in an IDE to patch the 
transform view


Man, this tooling is going to be fancy! :/




In other words, here's how I see the distribution(s):

 - Binary j2se5 Harmony release:  includes j2se5release src.jar for
   end-developers using debuggers to step through API code.

 - Source j2se5 Harmony release: API are in j2se5dev form.  The build
   process uses the processing tool to generate j2se5release src.jar.

 - Binary j2se6 Harmony release:  includes j2se6release src.jar for
   end-developers using debuggers to step through API code.

 - Source j2se5 Harmony release: API are in j2se6dev form.  The build
   process uses the processing tool to generate j2se6release src.jar.


Yes.



Why?  Because reverse works much better with devtarget than
releasetarget code, and the communications benefit of devtarget that are
lost in releasetarget code (because of stream code erasure).  In
addition, using smart IDEs, there wouldn't be much difference for
developers between the "visible" formats of dev vs release code when
working on it.


I don't think it matters, as I think that most people interested in 
working on the code will just check out of SVN.





for X being

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Geir Magnusson Jr.]

Rana Dasgupta wrote:
If the code is not being exercised by day to day tests and maintained, 
or if

we are not developing it,  we can drop it I think. GCV4.1 is in the first
category, and GCV5 the second. GCV4 doesn't fit either. Dropping it doesn't
stop one from pulling it out of an old svn revision for personal use.


I don't grok what you mean -  gcv4.1 is our main GC right now, right?

geir



Thanks,
Rana

On 11/2/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:


I would like to know the opinion of Artem, Salikh and Alexey
Ignatenko. They have used the GC and may have reasons to keep it.

As for me, I occasionally use it (GCv4) and a modified version of
GCv4.1 (which can help detect heap access via lost pointers). Most of
the time I prefer second one, but sometimes it is helpful to run with
completely different code base. I didn't try GCv5 yet. If it stable I
will switch to it.

--
Ivan

On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> Is there any reason to keep this around in the main branch?

[doc] What should be improved in DRLVM Doxygen documentation?

[Fedotov, Alexei A]

Nadya, All,
I have ranked the quality of Doxygen-generated DRLVM documentation and
posted it to the following Wiki page: 

http://wiki.apache.org/harmony/DRLVM_Documentation_Quality

All are welcome to check masterpieces of our documentation. All
volunteers are welcome to improve page ranks by editing comments in
DRLVM sources. 

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Geir Magnusson Jr. wrote:
>> The "communication" aspect of 2 can be quite helpful when doing
>> system-wide changes.  Just think about the effect of simply doing a
>> system-wide reindentation of source code; this is a nightmare when
>> developing using branches, as diff/merge tools are line-based, not
>> syntax-based.  So, if your new indenter moves things across lines,
>> you're in hell.
>>
> 
> So here's where I'm starting to believe I'm missing something important :
> 
> Can you give me an example of the "communication" that you imagine
> taking place here?  That's the part I'm just not grokking here.

How about: j2se5 developers, seeing that his planned modification to
some code will lead to utterly broken nearby j2se6 (commented) code
fragments, steps on this mailing list and asks j2se6 developers to help
him find the most harmless way to do the change (or, at least,warn them
about the problem)?

>> I am not saying that using the tool should replace using branches for
>> all situations, but there are situations where it would be more
>> effective not to use branches when the code is mostly identical.  
> 
> I want to avoid branches at all costs.

[somewhat off-topic]  I think that we should consider tools/approaches
on their merit.  Sometimes, branches are the right solution...  You
wouldn't want to use syntax-processing instead of branches for managing
sandboxes. ;-)

> Clearly there's some confusion here.  My goal is to
> 
> 1) Avoid branches at all costs so we can share as much code, and get as
> much benefit for collaboration between different versions, and different
> platforms, if that happens.

Agreed.

> 2) make it simple to work in either the 'master' code, or the 'target'
> code through tooling, including standard IDE activities like debugging

Agreed.

> 
> 3) make it easy for users to report bugs based on 'target' code,
> including patches and line numbers


Ah!  That's something to add to my requirements.  Fine!  I hadn't
included the "patches" thing into account.  It doesn't break what I've
exposed so far; it simply adds to it.

> What I've suggested is  :
> 
>   forward(X, platform) -> Y
> 
>   reverse(X, platform, Y') -> X'

OK.  I see this in *addition* to:

 forward(X, devtarget) -> Y
 reverse(Y') -> X'

So, to simplify the discussion, let's rewrite your proposal as:

 forward(X, releasetarget) -> Y
 reverse(Y',X,releasetarget) ~~> X' (possibly reporting
 conflicts/problems)

That's neat.  I like it.  Yet, we would encourage developers to work and
submit patches using devtarget code, instead of releasetarget code.

In other words, here's how I see the distribution(s):

 - Binary j2se5 Harmony release:  includes j2se5release src.jar for
   end-developers using debuggers to step through API code.

 - Source j2se5 Harmony release: API are in j2se5dev form.  The build
   process uses the processing tool to generate j2se5release src.jar.

 - Binary j2se6 Harmony release:  includes j2se6release src.jar for
   end-developers using debuggers to step through API code.

 - Source j2se5 Harmony release: API are in j2se6dev form.  The build
   process uses the processing tool to generate j2se6release src.jar.

Why?  Because reverse works much better with devtarget than
releasetarget code, and the communications benefit of devtarget that are
lost in releasetarget code (because of stream code erasure).  In
addition, using smart IDEs, there wouldn't be much difference for
developers between the "visible" formats of dev vs release code when
working on it.

> for X being a single class.  To produce a complete target source base,
> walk the single source tree as defined by a 'platform descriptor' :

I don't really understand the "platform descriptor" thing, yet I think
that it is, somehow, an orthogonal issue to the discussion above.
[Remember my long message describing 2 levels of processing:
file/directory-level and source-level.]  My first prototype tool would
attack source-level processing (discussed above), to validate the approach.

Maybe you could try rephrasing your file/directory-level (right?)
proposal?  How does it differ from Tim's proposal?

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Geir Magnusson Jr.]

Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir

I actually was serious. Probably you were confused, I didn't write 
"build test", I wrote "build smoke.test". The first one works ok, the 
second doesn't.


It happens because "test" (top-level test target) is handled in a 
different way from "smoke.test" (target just for smoke test category) 
target in build.xml. The "smoke.test" target just switches default 
processing target to "smoke.test" and runs "process_components" 
(which in its turn loops over all components). The "test" special 
handling of processing components escapes me, I don't quite 
understand how it works, but it seems to work correctly, without 
looping.


I've used them both, and targetted smoke for specific use cases (opt, 
etc)


Hmm you probably know more about VM build than I do since you've been 
modifying it for quite some time already. I've just started to look into 
the whole thing.




The question I was trying to solve was, how to correctly add 
jvmti.test target to the build.xml so that it would run only jvmti 
tests but not loop over components, but when "test" target it called, 
jvmti tests category would be executed along with all other categories.


Including "jvmti.test" target into build.xml in the same way as 
"smoke.test" doesn't make me happy.


Right - I thought you'd start a revolt and do it outside of the "loop 
over test types" system we have now.


Well I am not an ant guru, and the current build system definitely 
requires some time to understand. 


That's an understatement.  Don't feel bad.  I've never seen anything 
like it before.  The idea of generating ant scripts on teh fly is very 
unconventional.



I've tried to copy most of the stuff 
from other test ant files to make my own. I think I'll file a JIRA 
before committing it to make it possible to discuss it.


In order to keep this simple, why not just have a separate test target 
for now


$ sh build.sh test.jvmti

and we can stare at that together, and figure out how to integrate... 
simplest thing would be to rename the current "test" target to 
"test_loop" or something, and then


  

:)


Hmm good idea, why didn't I think of it myself?... :)



You don't have enough cuts and bruises from working with the DRLVM build :)

geir

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Rana Dasgupta]

If the code is not being exercised by day to day tests and maintained, or if
we are not developing it,  we can drop it I think. GCV4.1 is in the first
category, and GCV5 the second. GCV4 doesn't fit either. Dropping it doesn't
stop one from pulling it out of an old svn revision for personal use.

Thanks,
Rana

On 11/2/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:


I would like to know the opinion of Artem, Salikh and Alexey
Ignatenko. They have used the GC and may have reasons to keep it.

As for me, I occasionally use it (GCv4) and a modified version of
GCv4.1 (which can help detect heap access via lost pointers). Most of
the time I prefer second one, but sometimes it is helpful to run with
completely different code base. I didn't try GCv5 yet. If it stable I
will switch to it.

--
Ivan

On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> Is there any reason to keep this around in the main branch?

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Gregory Shimansky]

Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir

I actually was serious. Probably you were confused, I didn't write 
"build test", I wrote "build smoke.test". The first one works ok, the 
second doesn't.


It happens because "test" (top-level test target) is handled in a 
different way from "smoke.test" (target just for smoke test category) 
target in build.xml. The "smoke.test" target just switches default 
processing target to "smoke.test" and runs "process_components" (which 
in its turn loops over all components). The "test" special handling of 
processing components escapes me, I don't quite understand how it 
works, but it seems to work correctly, without looping.


I've used them both, and targetted smoke for specific use cases (opt, etc)


Hmm you probably know more about VM build than I do since you've been 
modifying it for quite some time already. I've just started to look into 
the whole thing.




The question I was trying to solve was, how to correctly add 
jvmti.test target to the build.xml so that it would run only jvmti 
tests but not loop over components, but when "test" target it called, 
jvmti tests category would be executed along with all other categories.


Including "jvmti.test" target into build.xml in the same way as 
"smoke.test" doesn't make me happy.


Right - I thought you'd start a revolt and do it outside of the "loop 
over test types" system we have now.


Well I am not an ant guru, and the current build system definitely 
requires some time to understand. I've tried to copy most of the stuff 
from other test ant files to make my own. I think I'll file a JIRA 
before committing it to make it possible to discuss it.


In order to keep this simple, why not just have a separate test target 
for now


$ sh build.sh test.jvmti

and we can stare at that together, and figure out how to integrate... 
simplest thing would be to rename the current "test" target to 
"test_loop" or something, and then


  

:)


Hmm good idea, why didn't I think of it myself?... :)

--
Gregory

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Ivan Volosyuk]

I would like to know the opinion of Artem, Salikh and Alexey
Ignatenko. They have used the GC and may have reasons to keep it.

As for me, I occasionally use it (GCv4) and a modified version of
GCv4.1 (which can help detect heap access via lost pointers). Most of
the time I prefer second one, but sometimes it is helpful to run with
completely different code base. I didn't try GCv5 yet. If it stable I
will switch to it.

--
Ivan

On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:

Is there any reason to keep this around in the main branch?

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Etienne Gagnon wrote:

[SNIP]



Such changes are usually not dealt with very neatly with "svn merge".


I'm confused.  I don't think anyone has suggested that we use "svn 
merge" for this.



Now, if using the processign tool, you get at least 2 benefits over "svn
merge":
1- No need to do any "svn merge"...  The method was moved AND renamed
even for j2se6.
2- You were aware, when moving the method and changing its name that you
could possibly be making the life of j2se6 developers a little more
difficult.



Right - that's how I thought it would work.


The "communication" aspect of 2 can be quite helpful when doing
system-wide changes.  Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
syntax-based.  So, if your new indenter moves things across lines,
you're in hell.



So here's where I'm starting to believe I'm missing something important :

Can you give me an example of the "communication" that you imagine 
taking place here?  That's the part I'm just not grokking here.



Believe me; I've lived through that trying to maintain a "well indented"
GNU Classpath in SableVM's repository.

I am not saying that using the tool should replace using branches for
all situations, but there are situations where it would be more
effective not to use branches when the code is mostly identical.  


I want to avoid branches at all costs.


Using
traditional pre-processing tools, in such cases, is often the solution
adopted by some people; the problems of "simply-mided" traditiona
pre-processing has been discussed earlier in this thread.  I am
proposing, instead, to use an innovative "syntax-based, revertable
processing".  That's all.  [I guess you'll need to see it working to
make sense of it...  I'll work on a prototype.  I've just submitted the
ICLA/ACQ].


Syntax based is fine - we never settled on what kind of pre-processing 
scheme we would use, so whatever seems best, go for it.


Clearly there's some confusion here.  My goal is to

1) Avoid branches at all costs so we can share as much code, and get as 
much benefit for collaboration between different versions, and different 
platforms, if that happens.


2) make it simple to work in either the 'master' code, or the 'target' 
code through tooling, including standard IDE activities like debugging


3) make it easy for users to report bugs based on 'target' code, 
including patches and line numbers


Now, maybe I'm misunderstanding you, but it sounds like your approach is 
one-way, and coarse grained.


What I've suggested is  :

  forward(X, platform) -> Y

  reverse(X, platform, Y') -> X'

for X being a single class.  To produce a complete target source base, 
walk the single source tree as defined by a 'platform descriptor' :


  foreach(file in descriptor) {
 forward(X, platform);
  }

so for a  source tree

 master/
 dir1/
   X1
   X2
 dir2/
   X3
   X4

and a platform descriptor

 java5/
 dir1/
   X1
 dir2/
   X4

then walking the tree gets us :

  java5/
 dir1/
   Y1
 dir2/
   Y4


Does this match your model?  If not, what's different?  I admit the 
above is simple minded.  I can imagine many, many messy corner cases. 
But it's a reasonable starting point?  I'd like to setup this 'master' 
tree in the sandbox.  Can anyone suggest any good examples of diffs 
between java 5 and java 6 so we can put diffs in the classes X1-4, or 
have paltform unique classes in X1-4?


geir

Re: [classlib] Preprocessor - CHECKPOINT

[Mikhail Fursov]

On 11/3/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:


Mikhail Fursov wrote:
> Good point! I think Java1.2 classes format is a reason to move J2ME
> development into separate branch.
> The only usecase for preprocessor is left (correct me if I miss
something)
> is Java6 changes.
> ?

a) This is "class format"...  AFAIK, you can use generics for
development, but compile with -target=1.2 or something like it, no?

b) If I'm wrong in a), then what if you wanted additional branches of
harmony: j2se1.4, j2me (classformat1.2)?  Then using the proposed tool
would be IMO preferable to using completely distinct svn branches for
these.


Etienne



Yes,
it's possible to write J2ME applications using Java5 syntax with
generics and use
special compiler to compile it to Java1.2 format.
My position here is:
1) Let's ask volunteers/gurus who do JavaXYZ port what is more convenient
for them
2) The idea with Preprocessor (I mean your version with a special 2-way
tool) is very good and scalable until you do not have diffs in almost every
line.
3) Today we have a lot of changes in classlib: ~100 commits per day. Merging
of branches is almost unreal. Maybe in the future situation will change
because we will have more stable
code. Maybe not: we can have 10 times more developers! Let's wait and
will see :)




--
Mikhail Fursov

Re: [general] Transition to TLP

[Weldon Washburn]

On 11/2/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Geir Magnusson Jr. wrote:
> Anything else?  I did ponder changes to our mail list.  I think adding a
> user list is something good to do now as it's non-disruptive, but I'm
> not convinced that breaking up the dev list is something needed at this
> point - I'd rather see us minimize the changes during this transition
> and do it later once settled.  I'm also still worried about fracturing
> things - it's wonderful to see us working as one community.

I agree that we are still drawing value from all talking on the same
channel, so let's keep it that way for now.



I also agree.  Keep a single dev list for now.  Its just not worth the risk
of fracturing things.

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Geir Magnusson Jr. wrote:
>> I have nothing against this!  But, we have to make sure:
>> 1- we don't lose the "communication" aspect of telling developers about
>>  parrallel development.
> 
> I'm not sure I understand what problem you are trying to solve there. We
> do parallel development on the source base right now - no one ever does
> a blocking checkout - it's optimistic.


What tells you, when you modify method m() of class C that,in the middle
of it, there's different ways of processing something in j2se6?

e.g.

class C
{
  .../* many, many methods */

  private void m()
  {
... /* canonical j2se5 code */
...
// @Process(j2se6)
// { do something additional }
...
...
  }
}


So, if you were, for example, to move m() to become the first method,
and ALSO change its name...


class C
{
  private void m2()
  {
... /* canonical j2se5 code with modifications!! */
...
// @Process(j2se6)
// { do something additional }
...
...
  }

  .../* many, many methods */

}



Such changes are usually not dealt with very neatly with "svn merge".
Now, if using the processign tool, you get at least 2 benefits over "svn
merge":
1- No need to do any "svn merge"...  The method was moved AND renamed
even for j2se6.
2- You were aware, when moving the method and changing its name that you
could possibly be making the life of j2se6 developers a little more
difficult.

The "communication" aspect of 2 can be quite helpful when doing
system-wide changes.  Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
syntax-based.  So, if your new indenter moves things across lines,
you're in hell.

Believe me; I've lived through that trying to maintain a "well indented"
GNU Classpath in SableVM's repository.

I am not saying that using the tool should replace using branches for
all situations, but there are situations where it would be more
effective not to use branches when the code is mostly identical.  Using
traditional pre-processing tools, in such cases, is often the solution
adopted by some people; the problems of "simply-mided" traditiona
pre-processing has been discussed earlier in this thread.  I am
proposing, instead, to use an innovative "syntax-based, revertable
processing".  That's all.  [I guess you'll need to see it working to
make sense of it...  I'll work on a prototype.  I've just submitted the
ICLA/ACQ].

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Mikhail Fursov wrote:
> Good point! I think Java1.2 classes format is a reason to move J2ME
> development into separate branch.
> The only usecase for preprocessor is left (correct me if I miss something)
> is Java6 changes.
> ?

a) This is "class format"...  AFAIK, you can use generics for
development, but compile with -target=1.2 or something like it, no?

b) If I'm wrong in a), then what if you wanted additional branches of
harmony: j2se1.4, j2me (classformat1.2)?  Then using the proposed tool
would be IMO preferable to using completely distinct svn branches for these.


Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:
[...] 


See, I'm hoping for something a tad different :

1) For building : process() (and revert() for fun) for cmd line use for
the build scripts, so we just do
... 


2) For development : IDE plugin where

  a) I can tell plugin that my project def/configuration is whatever,
 it using metadata in a file, only consider the code that is
 defined (or not excluded - whatever is easier)

  b) I can tell plugin to look at X, know that I want
 "java5" and in situ, it shows me what Z would look like.
 I edit this, but I'm really editing X.  And I want to
 be sure, I push a button or have a split screen that
 shows me what X really looks like.

 I can edit in X, or in "virtual Z", or both at the same
 time, as I'm just really editing X.


I have nothing against this!  But, we have to make sure:
1- we don't lose the "communication" aspect of telling developers about
 parrallel development.


I'm not sure I understand what problem you are trying to solve there. 
We do parallel development on the source base right now - no one ever 
does a blocking checkout - it's optimistic.




2- we have a robust "language" design; this is best achieved by first
 building the command-line based tool, then extend it into a full-blown
 Eclipse plugin... :-)


Right.  The fact it's the same basic transformation code and process. 
The fact that someone embedded it in eclipse doesn't change the 
fundamental process.


geir



Etienne

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Sian January wrote:
> I may be totally off track here, but how about just having two copies of
> all
> the files that differ?  I don't believe it would be that many, and it would
> save us from having complicated source files or having to use special tools
> or special IDE plug-ins.  For me the value of having clearly readable
> source
> code and being able to use an IDE out of the box outweighs any extra effort
> there may be with this solution.

I suspect that "two copies" might eventually become "three, four, five"
copies...  Also, having parrallel copies does not help when modifying
"shared" code in these copies.  Actually, it would be even worse than
using the normal branching feature of Subversion, as you wouldn't get
neat "svn merge" help...

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

To release code, one would apply:

 process(X, release-target) => Y

Now, it is important to understand that Y, in this case, is NOT suitable
for doing any modification as

 revert(Y) => Kaboom!  (The tool will simply report that it can't do it;
it won't crash.)
...

This is what I thought we were talking about all along - basically
starting w/ the full source, and pre-process to the "canonical" source
for the target version.

However, I don't understand why I can't go backwards, modulo some manual
merging if needed.

For example, if I have X and release-version, I should be able to take a
Y' and resolve back to X'.  There are problematic cases. [...]



It's the problematic cases I am trying to get entirely rid of "by
design", by having an "exact" transformation process, in contrast with
the usual branch/merge "inexact" process.


At what cost though?  We are used to the inexact process now...



Of course, this means that development happens using "complete" source
code (this is either the canonical form or a development target form,
but not a release form).


What's the diff?



For applying user-provided patches, then it can still be done the good
old way, using these "little" patches made from release code, but
applying them directly to the canonical or dev-target code, resolving
conflicts manually.  [The smaller the patch, the easier it is to apply
it on files with target-specific code.]


In which case we have the inexact process anyway.



The idea is that manual processing is never required when coding using
canonical and dev-target modes.  No inexact modifications, no difficult
merges, etc.  And, as a bonus, communication between parrallel target
developers.  I know, it's an "unusual" development processing tool, but,
hey, why shouldn't Harmony innovate? :-)


I'm missing something then.  You just said you can't go backwards. 
There is only one file for class C in SVN.  How do I work on anything 
but that copy if there is no going backwards?


geir

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Geir Magnusson Jr. wrote:
>[...] 
> 
> See, I'm hoping for something a tad different :
> 
> 1) For building : process() (and revert() for fun) for cmd line use for
> the build scripts, so we just do
>... 
> 
> 2) For development : IDE plugin where
>
>   a) I can tell plugin that my project def/configuration is whatever,
>  it using metadata in a file, only consider the code that is
>  defined (or not excluded - whatever is easier)
> 
>   b) I can tell plugin to look at X, know that I want
>  "java5" and in situ, it shows me what Z would look like.
>  I edit this, but I'm really editing X.  And I want to
>  be sure, I push a button or have a split screen that
>  shows me what X really looks like.
> 
>  I can edit in X, or in "virtual Z", or both at the same
>  time, as I'm just really editing X.

I have nothing against this!  But, we have to make sure:
1- we don't lose the "communication" aspect of telling developers about
 parrallel development.
2- we have a robust "language" design; this is best achieved by first
 building the command-line based tool, then extend it into a full-blown
 Eclipse plugin... :-)

Etienne

-- 
Etienne M. Gagnon, Ph.D. [EMAIL PROTECTED]
President  http://www.sablevm.org/
J-Meg inc. http://www.sablecc.org/

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Geir Magnusson Jr. wrote:
>> To release code, one would apply:
>>
>>  process(X, release-target) => Y
>>
>> Now, it is important to understand that Y, in this case, is NOT suitable
>> for doing any modification as
>>
>>  revert(Y) => Kaboom!  (The tool will simply report that it can't do it;
>> it won't crash.)
>>...
> 
> This is what I thought we were talking about all along - basically
> starting w/ the full source, and pre-process to the "canonical" source
> for the target version.
> 
> However, I don't understand why I can't go backwards, modulo some manual
> merging if needed.
> 
> For example, if I have X and release-version, I should be able to take a
> Y' and resolve back to X'.  There are problematic cases. [...]


It's the problematic cases I am trying to get entirely rid of "by
design", by having an "exact" transformation process, in contrast with
the usual branch/merge "inexact" process.

Of course, this means that development happens using "complete" source
code (this is either the canonical form or a development target form,
but not a release form).

For applying user-provided patches, then it can still be done the good
old way, using these "little" patches made from release code, but
applying them directly to the canonical or dev-target code, resolving
conflicts manually.  [The smaller the patch, the easier it is to apply
it on files with target-specific code.]

The idea is that manual processing is never required when coding using
canonical and dev-target modes.  No inexact modifications, no difficult
merges, etc.  And, as a bonus, communication between parrallel target
developers.  I know, it's an "unusual" development processing tool, but,
hey, why shouldn't Harmony innovate? :-)

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [classlib] Preprocessor - CHECKPOINT

[Etienne Gagnon]

Tim Ellison wrote:
>>   For example, if class X of the main version is not part of j2me,
>>   "process(j2me)" would move this file to a subdirectory ".streams/".
> 
> Why would you move the files rather than exclude them?
> 
> I was assuming that the processor would generate a whole new source tree
> for each process() target, so that you could work on the original
> checked-out file in it's 'canonicalized form' for Big Java work, or
> process("jme") into a new location and work in the non-canonical form
> your Little Java spectacles on.  [...]

Neat idea!

I would put the following restriction, though:  one should NOT modify
more than one target at a time.

So, you would probably need some way to prevent parallel modifications
in "spectacle views".  One way to achieve this:

process(X,target, destination) =>  Xtarget in a distinct location
 and X files are changed to read-only and some tracking file F tells us
 about Xtarget's location.

So, you would also need:

release(F)  =>  asks all kind of questions (want to lose changes? delete
files? etc.)

Of course:

revert(F?|destination?) => makes X read-write.


[Hoping this was clear enough...  It's not a very good explanation...]

> Agreed.  It would be interesting to determine the most effective
> location for those markers (measured by reverse mapping accuracy vs.
> number of markers).

I am a fan of accuracy...  Yet, maybe it would be simple enough if a
release was always based on a specific svn URL, then the mark could be
totally exact using svn keywords... :-)

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [general] Transition to TLP

[Alexey Petrenko]

It really does not matter. Anyway a person who will search an archive
will hit on the end it will simply mean that he needs to search
another archieve.
And where will be this "end" at Nov 02 or Nov 30...

Moreover it will be an additional chance to remember the birthdate of
Harmony as real Apache project :)

SY, Alexey

2006/11/2, Tim Ellison <[EMAIL PROTECTED]>:

Geir Magnusson Jr. wrote:
> Should we target a month boundary (Nov30) for the mail list switch? That
> way, the archives 'split' across a natural boundary (they already are
> bucketed by month...)

I don't think it makes much of a difference -- the threads are split
across months anyway.  Why not switch it _now_ we're only a couple of
days off a month boundary.

Regards
Tim

--

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

Re: [general] Transition to TLP

[Tim Ellison]

Geir Magnusson Jr. wrote:
> Should we target a month boundary (Nov30) for the mail list switch? That
> way, the archives 'split' across a natural boundary (they already are
> bucketed by month...)

I don't think it makes much of a difference -- the threads are split
across months anyway.  Why not switch it _now_ we're only a couple of
days off a month boundary.

Regards
Tim

-- 

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

Re: [general] Transition to TLP

[Alexey Petrenko]

2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:



Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> I was going to start organizing the infrastructure transition to TLP. On
>> the list are :
>>

[SNIP]

>
> I agree that we are still drawing value from all talking on the same
> channel, so let's keep it that way for now.
>
> I can't think of any other infra issues.  We will need some minor source
> updates, such as URL's embedded in site docs, removing incubator notices
> and file markers etc. but they are not infra issues.
>
> Please lay down redirects from the old mailing lists and URLs for a
> decent period of time.
Should we target a month boundary (Nov30) for the mail list switch?
That way, the archives 'split' across a natural boundary (they already
are bucketed by month...)

Sounds reasonable.

SY, Alexey

Re: [general] Transition to TLP

[Geir Magnusson Jr.]

Tim Ellison wrote:

Geir Magnusson Jr. wrote:

I was going to start organizing the infrastructure transition to TLP. On
the list are :



[SNIP]



I agree that we are still drawing value from all talking on the same
channel, so let's keep it that way for now.

I can't think of any other infra issues.  We will need some minor source
updates, such as URL's embedded in site docs, removing incubator notices
and file markers etc. but they are not infra issues.

Please lay down redirects from the old mailing lists and URLs for a
decent period of time.



Should we target a month boundary (Nov30) for the mail list switch? 
That way, the archives 'split' across a natural boundary (they already 
are bucketed by month...)


geir

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Sian January wrote:

On 02/11/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:




Sian January wrote:
> I believe that in CVS when you make a branch there's nothing in it to
> begin with, so if you check out code from the branch it looks the same
> as code in head.  Then if a change is made in a file in head and that
> file hasn't been changed in the branch that change is reflected in the
> branch.  My understanding is that SVN is based on CVS so I think it
> should work the same way.

Nope.

There is really no such thing as a branch or tag in SVN.  It's just a
copy.  I think it's the feature I miss most from CVS.



That's very unfortunate.  I had assumed that SVN was a superset of CVS as
it's more recent, but obviously I was wrong :-(


it's a shame.  I really, really miss that feature.

geir

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Geir Magnusson Jr.]

Sure, so use wiki as a community collaboration tool, and then point to 
the JIRAs...


geir

Rana Dasgupta wrote:
 
   They serve different purposes. The Wiki is just a broad reminder to 
even a visitor to Harmony of what remains to be done. I think that the 
JIRA is more specific, maybe even more technical. The TODO page as it is 
today, with sublinks, also seems well suited to capture this info. But 
it's not a big deal.


 
On 11/2/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] 
> wrote:




Rana Dasgupta wrote:
 > No problem with them being both on the Wiki and the JIRA, I think.

Other than getting out of sync  it just makes sense to use the
"issue tracking system" for... "issue tracking" :)

geir


 >
 > On 02 Nov 2006 17:57:29 +0600, Egor Pasko < [EMAIL PROTECTED]
> wrote:
 >>
 >> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
 >> > Alexey Varlamov wrote:
 >> > > 2006/11/2, Geir Magnusson Jr. < [EMAIL PROTECTED]
>:
 >> > >> Put them in as JIRAs
 >> > > Done: HARMONY-2051, 2052, 2053.
 >> >
 >> > Thanks - that just makes it easy for people to grab them and get
 >> going...
 >>
 >> maybe, put the list of JIRAs on wiki?
 >>
 >> > >
 >> > >> Alexey Varlamov wrote:
 >> > >> > Below is a list of isolated development tasks which do
not require
 >> > >> > advanced knowledge of VM and could be a nice start for
newbies to
 >> get
 >> > >> > acquainted with the code. All items are targeted for
better code
 >> > >> > sharing.
 >> > >> >
 >> > >> > 1) Eliminate duplicate implementation of
j.l.Runtime.Process in
 >> kernel
 >> > >> > classes of DRLVM [1]. The classlib provides neat
portlib-based
 >> > >> > reference implementation [2], which should be reused. These 2
 >> impls
 >> > >> > are roughly identical, so one needs to made more scrupulous
 >> comparison
 >> > >> > and squeeze some features/fixes of [1] which may be
missing in
 >> [2],
 >> > >> > then employ [2] in j.l.Runtime of DRLVM and drop [1].
 >> > >> >
 >> > >> > 2) Improve/re-implement a parser of generic signatures in
DRLVM
 >> kernel
 >> > >> > classes [3], and move this functionality to classlib
(luni ?), so
 >> > >> > other VMs could reuse it for 1.5 support. The current impl is
 >> somewhat
 >> > >> > messy and half-baked, one need to invent more shaped and
modular
 >> API
 >> > >> > to the parser. One more possible issue is parser's
dependency on
 >> > >> > antlr, which may be considered overkill for this duty. I
think
 >> antlr
 >> > >> > has its pros, like more illustrative code with clear
 >> correlation to
 >> > >> > formal grammar [4]; unfortunately this is not the case
with the
 >> impl
 >> > >> > in question. OTOH minimizing number of dependencies for VM is
 >> always
 >> > >> > good.
 >> > >> >
 >> > >> > 3) Classlib's j.u.TimeZone expects "user.timezone"
property value
 >> > >> > initialized during VM startup (BTW I did not find explicit
 >> statement
 >> > >> > in VMI docs for that, only indirect reference in kernel
stub for
 >> > >> > j.l.System). I believe this action should be done by hyluni
 >> natives
 >> > >> > during JNI_OnLoad, no reason to burden VM with it.
Therefore I
 >> suggest
 >> > >> > to move "port_user_timezone()" function [5] from DRLVM to
classlib
 >> > >> > (luni/port), and fix DRLVM & hyluni accordingly.
 >> > >> >
 >> > >> > [1]
 >> > >>
 >>
working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
 >> > >> > +
 >> working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
 >> > >> > [2]
 >> > >> >
 >> > >>
 >>

working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*

 >>
 >> > >> >
 >> > >> > +
 >> working_classlib\modules\luni\src\main\native\luni\shared\process.c
 >> > >> > [3]
 >> > >> >
 >> > >>
 >>

working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
 >>
 >> > >> >
 >> > >> > [4]
 >> > >> >
 >> > >>
 >>
http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
 >>
 >> > >> > Para 4.4.4
 >> > >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c
 >> > >> >
 >> > >> > Comments? Should I put this somewhere on the Wiki?
 >> > >> >
 >> > >>
 >> > >
 >> >
 >>
 >> --
 >> Egor Pasko, Intel Managed Runtime Division
 >>
 >>
 >

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Geir Magnusson Jr.]

Gregory Shimansky wrote:

Geir

I actually was serious. Probably you were confused, I didn't write 
"build test", I wrote "build smoke.test". The first one works ok, the 
second doesn't.


It happens because "test" (top-level test target) is handled in a 
different way from "smoke.test" (target just for smoke test category) 
target in build.xml. The "smoke.test" target just switches default 
processing target to "smoke.test" and runs "process_components" (which 
in its turn loops over all components). The "test" special handling of 
processing components escapes me, I don't quite understand how it works, 
but it seems to work correctly, without looping.


I've used them both, and targetted smoke for specific use cases (opt, etc)



The question I was trying to solve was, how to correctly add jvmti.test 
target to the build.xml so that it would run only jvmti tests but not 
loop over components, but when "test" target it called, jvmti tests 
category would be executed along with all other categories.


Including "jvmti.test" target into build.xml in the same way as 
"smoke.test" doesn't make me happy.


Right - I thought you'd start a revolt and do it outside of the "loop 
over test types" system we have now.


In order to keep this simple, why not just have a separate test target 
for now


$ sh build.sh test.jvmti

and we can stare at that together, and figure out how to integrate... 
simplest thing would be to rename the current "test" target to 
"test_loop" or something, and then


  

:)

geir




Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

Why not use junit?


If you mean why not use junit to loop over tests, then it is not the 
case. I've used junit to do this in my work.


The loop which I wrote here is the loop over components in the 
build.xml of drlvm. If you run "build smoke.test" you'll see that the 
same tests are repeated several times (you have to be patient to see 
this).


You're joking, right?  I do this for ever patch commit I do.

This is done because build loops over all known VM components like 
vmi, vmocode, gc, interpreter, etc. It is Ok for building, and it is 
done exactly for building, but it is not Ok for testing because 
repeating tests for the whole JVM for each of its components makes no 
sense.


You're joking here too, right?  How do you know if there aren't side 
effects among components?


geir




Gregory Shimansky wrote:

On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:

Gregory,

I observed similar quirks with paths while intergrating kernel tests
into build. AFAIU the "Grand Design" is the following: there are
abstracted targets and isolated component descriptors; build system
iterates through all components and tries to apply given target to
each component. So there are various tricks to stop it running tests
multiple times a-la "recurring inclusion protection" in C headers.
I do not grok how it calculates dependencies though, but it is quite
easy to drive it mad and it starts doing wrong sequence of targets 
and

picks wrong components etc.
So I just snipped off that fanciful machinery and made simple subant
for "kernel.test" target - see its definition in 
build/make/build.xml,

and compare with nearby "smoke.test" one.


Ok I've made it though all of the interesting ant tricks and 
created my own jvmti.test target. I noticed the difference of how 
kernel.test target is included into build.xml as compared to 
smoke.test or unit.test.


AFAIU only "test" target does actually work to run only once and 
for the required number of modes (jit, interpreter). This is done 
with a special workaround for "test" target in build.xml, it has 
its own processing. But inclusion of smoke.test and unit.test in 
build.xml right now makes it run in a loop for all components for 
which tests don't have any relation to.


I am still experimenting with the build, it might be I'll find a 
solution for individual test categories so it would be possible to 
run them separately from the general "test" target.

Re: Programmer Volunteering (sorry if I should read a FAQ before)

[Paulex Yang]

Tim Ellison wrote:
I'll add my welcome (I don't see your original post?) 
I didn't see, either...the original mail's date is May 13, 2005, even 
before Harmony is created


Please don't get me wrong, just add my welcome ;-)

-- what area are
you interested in?

We have cool work in progress in VMs, Memory Management, JIT
compilation, class library development, testing, documentation, build
systems, tooling, and more that I've probably forgotten!

Regards,
Tim


Fedotov, Alexei A wrote:
  

So, you are very welcome. :-)
I enjoyed the quotes at the end of your post.

Recently Sveta and Geir updated
http://incubator.apache.org/harmony/quickhelp_contributors.html - I

Agree, that's the right place to start. And if you have planned to 
contribute, here is another link as instruction:


http://incubator.apache.org/harmony/get-involved.html

And please be kindly noted, in the near future(but I'm sure not 
tomorrow) the links will be out-dated, because we are going to 
http://harmony.apache.org! ;-)

believe it worth to take a look at.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering



-Original Message-
From: Nilseu Padilha JMiB [mailto:[EMAIL PROTECTED]
Sent: Friday, May 13, 2005 8:15 PM
To: harmony-dev@incubator.apache.org
Subject: Programmer Volunteering (sorry if I should read a FAQ before)

Greetings.

I am a cmomercial Systems Architect and would like to volunteer myself
  

as a


developer to the Harmony  Project. Sorry if I should read any FAQ
  

before,


but I like to know how I could contribute to the project.

Thank you.

Regards,


Part 1"


aka="JMiB"
jobTitle="J2EE Hardcore Architect"
jobMainAssignment="Omnipres Co-Architect - Solution for
  

Distributed


Enterprise Data"
jobOffice="Immediate Consultoria e Sistemas"
jobPhone="+55-051-3233-8495"
jobPage="http://www.immediate.com.br";
association="Association for Computing Machinery - ACM"
education="Bachelor\'s in Computer Science - ULBRA"
>

And one more thing, what you choose to call hell, he calls home.


Oganza bi sasa!


Computer science is no more about computers than astronomy is about
telescopes.


Son of Jor-el, kneel before Zod


We reject kings, presidents and voting. We believe in rough consensus
  

and


running code.


A minority of input produces the majority of results.


You\'re...You\'re despicable!


It is a painful thing
To look at your own trouble and know
That you yourself and no one else has made it.


John Connor, It is time.


One exam does not a (J2EE) architect make.

http://www.nerdtests.com/ft_nq.php?im";>
http://www.nerdtests.com/images/ft/nq.php?val=8792"; alt="I am
nerdier than 97% of all people. Are you nerdier? Click here to find
  

out!">




  


  



--
Paulex Yang
China Software Development Lab
IBM

Re: Programmer Volunteering (sorry if I should read a FAQ before)

[Alexey Petrenko]

I've not seen the original message too... Probably some mail server problems.
And I'm welcoming you too.. :)

You can find a huge number of tasks to do in Harmony JIRA [1] and
Harmony WIKI [2].

SY, Alexey

[1] http://issues.apache.org/jira/browse/HARMONY
[2] http://wiki.apache.org/harmony/FrontPage

2006/11/2, Tim Ellison <[EMAIL PROTECTED]>:

I'll add my welcome (I don't see your original post?) -- what area are
you interested in?

We have cool work in progress in VMs, Memory Management, JIT
compilation, class library development, testing, documentation, build
systems, tooling, and more that I've probably forgotten!

Regards,
Tim


Fedotov, Alexei A wrote:
> So, you are very welcome. :-)
> I enjoyed the quotes at the end of your post.
>
> Recently Sveta and Geir updated
> http://incubator.apache.org/harmony/quickhelp_contributors.html - I
> believe it worth to take a look at.
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
>> -Original Message-
>> From: Nilseu Padilha JMiB [mailto:[EMAIL PROTECTED]
>> Sent: Friday, May 13, 2005 8:15 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Programmer Volunteering (sorry if I should read a FAQ before)
>>
>> Greetings.
>>
>> I am a cmomercial Systems Architect and would like to volunteer myself
> as a
>> developer to the Harmony  Project. Sorry if I should read any FAQ
> before,
>> but I like to know how I could contribute to the project.
>>
>> Thank you.
>>
>> Regards,
>>
>> >  name="Nilseu Perside Ortiz Padilha Junior"
>>  jCert="SCEA P1 - Sun Certified Enterprise Architect for J2EE
> Part 1"
>>  aka="JMiB"
>>  jobTitle="J2EE Hardcore Architect"
>>  jobMainAssignment="Omnipres Co-Architect - Solution for
> Distributed
>> Enterprise Data"
>>  jobOffice="Immediate Consultoria e Sistemas"
>>  jobPhone="+55-051-3233-8495"
>>  jobPage="http://www.immediate.com.br";
>>  association="Association for Computing Machinery - ACM"
>>  education="Bachelor\'s in Computer Science - ULBRA"
>>  >
>> 
>> And one more thing, what you choose to call hell, he calls home.
>> 
>> 
>> Oganza bi sasa!
>> 
>> 
>> Computer science is no more about computers than astronomy is about
>> telescopes.
>> 
>> 
>> Son of Jor-el, kneel before Zod
>> 
>> 
>> We reject kings, presidents and voting. We believe in rough consensus
> and
>> running code.
>> 
>> 
>> A minority of input produces the majority of results.
>> 
>> 
>> You\'re...You\'re despicable!
>> 
>> 
>> It is a painful thing
>> To look at your own trouble and know
>> That you yourself and no one else has made it.
>> 
>> 
>> John Connor, It is time.
>> 
>> 
>> One exam does not a (J2EE) architect make.
>> 
>> http://www.nerdtests.com/ft_nq.php?im";>
>> http://www.nerdtests.com/images/ft/nq.php?val=8792"; alt="I am
>> nerdier than 97% of all people. Are you nerdier? Click here to find
> out!">
>> 
>>
>

--

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

Re: Programmer Volunteering (sorry if I should read a FAQ before)

[Tim Ellison]

I'll add my welcome (I don't see your original post?) -- what area are
you interested in?

We have cool work in progress in VMs, Memory Management, JIT
compilation, class library development, testing, documentation, build
systems, tooling, and more that I've probably forgotten!

Regards,
Tim


Fedotov, Alexei A wrote:
> So, you are very welcome. :-)
> I enjoyed the quotes at the end of your post.
> 
> Recently Sveta and Geir updated
> http://incubator.apache.org/harmony/quickhelp_contributors.html - I
> believe it worth to take a look at.
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
>> -Original Message-
>> From: Nilseu Padilha JMiB [mailto:[EMAIL PROTECTED]
>> Sent: Friday, May 13, 2005 8:15 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Programmer Volunteering (sorry if I should read a FAQ before)
>>
>> Greetings.
>>
>> I am a cmomercial Systems Architect and would like to volunteer myself
> as a
>> developer to the Harmony  Project. Sorry if I should read any FAQ
> before,
>> but I like to know how I could contribute to the project.
>>
>> Thank you.
>>
>> Regards,
>>
>> >  name="Nilseu Perside Ortiz Padilha Junior"
>>  jCert="SCEA P1 - Sun Certified Enterprise Architect for J2EE
> Part 1"
>>  aka="JMiB"
>>  jobTitle="J2EE Hardcore Architect"
>>  jobMainAssignment="Omnipres Co-Architect - Solution for
> Distributed
>> Enterprise Data"
>>  jobOffice="Immediate Consultoria e Sistemas"
>>  jobPhone="+55-051-3233-8495"
>>  jobPage="http://www.immediate.com.br";
>>  association="Association for Computing Machinery - ACM"
>>  education="Bachelor\'s in Computer Science - ULBRA"
>>  >
>> 
>> And one more thing, what you choose to call hell, he calls home.
>> 
>> 
>> Oganza bi sasa!
>> 
>> 
>> Computer science is no more about computers than astronomy is about
>> telescopes.
>> 
>> 
>> Son of Jor-el, kneel before Zod
>> 
>> 
>> We reject kings, presidents and voting. We believe in rough consensus
> and
>> running code.
>> 
>> 
>> A minority of input produces the majority of results.
>> 
>> 
>> You\'re...You\'re despicable!
>> 
>> 
>> It is a painful thing
>> To look at your own trouble and know
>> That you yourself and no one else has made it.
>> 
>> 
>> John Connor, It is time.
>> 
>> 
>> One exam does not a (J2EE) architect make.
>> 
>> http://www.nerdtests.com/ft_nq.php?im";>
>> http://www.nerdtests.com/images/ft/nq.php?val=8792"; alt="I am
>> nerdier than 97% of all people. Are you nerdier? Click here to find
> out!">
>> 
>>
> 

-- 

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

Re: [general] Motorola to develop ME under ALv2

[Dalibor Topic]

Egor Pasko  gmail.com> writes:

> 
> On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> > AFAIK ME shares a lot of core classes and packages with SE. And we have
> > these packages implemented.
> > And now I'm really interesting if Motorola wants to reuse our code or
> > develop "the better one" ?
> 
> we like to say "more free software is not a problem" :)

+1 :)

The more, the merrier.

cheers,
dalibor topic

RE: Programmer Volunteering (sorry if I should read a FAQ before)

[Fedotov, Alexei A]

So, you are very welcome. :-)
I enjoyed the quotes at the end of your post.

Recently Sveta and Geir updated
http://incubator.apache.org/harmony/quickhelp_contributors.html - I
believe it worth to take a look at.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Nilseu Padilha JMiB [mailto:[EMAIL PROTECTED]
>Sent: Friday, May 13, 2005 8:15 PM
>To: harmony-dev@incubator.apache.org
>Subject: Programmer Volunteering (sorry if I should read a FAQ before)
>
>Greetings.
>
>I am a cmomercial Systems Architect and would like to volunteer myself
as a
>developer to the Harmony  Project. Sorry if I should read any FAQ
before,
>but I like to know how I could contribute to the project.
>
>Thank you.
>
>Regards,
>
>   name="Nilseu Perside Ortiz Padilha Junior"
>   jCert="SCEA P1 - Sun Certified Enterprise Architect for J2EE
Part 1"
>   aka="JMiB"
>   jobTitle="J2EE Hardcore Architect"
>   jobMainAssignment="Omnipres Co-Architect - Solution for
Distributed
>Enterprise Data"
>   jobOffice="Immediate Consultoria e Sistemas"
>   jobPhone="+55-051-3233-8495"
>   jobPage="http://www.immediate.com.br";
>   association="Association for Computing Machinery - ACM"
>   education="Bachelor\'s in Computer Science - ULBRA"
>   >
>
>And one more thing, what you choose to call hell, he calls home.
>
>
>Oganza bi sasa!
>
>
>Computer science is no more about computers than astronomy is about
>telescopes.
>
>
>Son of Jor-el, kneel before Zod
>
>
>We reject kings, presidents and voting. We believe in rough consensus
and
>running code.
>
>
>A minority of input produces the majority of results.
>
>
>You\'re...You\'re despicable!
>
>
>It is a painful thing
>To look at your own trouble and know
>That you yourself and no one else has made it.
>
>
>John Connor, It is time.
>
>
>One exam does not a (J2EE) architect make.
>
>http://www.nerdtests.com/ft_nq.php?im";>
>http://www.nerdtests.com/images/ft/nq.php?val=8792"; alt="I am
>nerdier than 97% of all people. Are you nerdier? Click here to find
out!">
>
>

Re: [drlvm] Class unloading support

[Weldon Washburn]

Aleksey,

Excellent step forward -- breaking the patch into two pieces.   This made
the patch(es) much more readable.

I glanced at native_sources_cleanup.patch.  It looks like code for
alloc/dealloc vtables and jitted code blocks.  The original patch made
vtables into objects.  Will native_sources_cleanup need to change if vtables
are normal C structs instead?  Also, I see reference to path .../gcv4/...  I
guess this will need to change to support gc_gen and gc_cc.

Once you get native_sources_cleanup.patch in good shape, I have no problem
committing it.

If there is no other debate on class unloading design, I will call for a
vote in a seperate email.



On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:


Hi, everyone.

I've splitted Harmony-2000 (see details:
http://issues.apache.org/jira/browse/HARMONY-2000) patch with automatic
class unloading implementation into 2 independent parts:
1. cleaning native resources (native_sources_cleanup.patch).
2. automatic unloading design implementation (auto_unloading.patch).

The first part is independent for all class unloading designs and could be
commited. The second part is class unloading design implementation (the
best
class unloading approach is discussed now).

I propose to commit native_sources_cleanup.patch and continue class
unloading development with minimal requirements on drlvm.

Aleksey.


On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>
> Oops, sorry, misprinted in my suggestion:
> if (cl->IsBootstrap() *||
*env->b_VTable_trace_is_not_supported_by_GC)
>
> {
> vm_enumerate_jlc(c);
> if (c->vtable)
> vm_enumerate_root_reference((void**)&c->vtObj,
> FALSE);
> }
>
> Aleksey.
>
>  On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
> >
> > Weldon,
> >
> > >A question for all involved.  Is it possible to somehow make it
appear
> > that
> > >the new objects related to unloading  (VTable, ClassLoader, etc)  are
> > always
> > >reachable and thus never collected?  I am trying to figure out a way
to
> > make
> > >integration of class unloading independent of correct support inside
> > the GC
> > >and JIT.  This option could be a command line switch or compile time
> > option.
> >
> > I agree with Robin:
> > >Simple.  Keep a list or table of these objects as part of the root
set.
> > >Enumerate it optionally depending on a command line option.
> >
> > Details: you can see from Harmony-2000 patch, that this is done for
> > Bootstrap classes already. If you look at root_set_enum_common.cpp
(with the
> > patch applied) vm_enumerate_static_fields() function, there is line:
> > if (cl->IsBootstrap())
> > {
> > vm_enumerate_jlc(c);
> > if (c->vtable)
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > FALSE);
> > }
> > else
> > {
> > vm_enumerate_jlc(c, true/*weak*/);
> > }
> > You can see, that there are strong roots to Bootstrap j.l.Classes and
> > their VTable objects. So I suppose, that it would be very simple to
> > propogate strong roots to all other classes (not only Bootstrap),
something
> > like:
> > if (cl->IsBootstrap() *&&
> > env->b_VTable_trace_is_not_supported_by_GC*)
> > {
> > vm_enumerate_jlc(c);
> > if (c->vtable)
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > FALSE);
> > }
> > where *b_VTable_trace_is_not_supported_by_GC *is flag which is set
> > according to used GC. This will force switching off any class
unloading
> > support.
> >
> > Aleksey.
> >
> >  On 11/1/06, Robin Garner <[EMAIL PROTECTED] > wrote:
> > >
> > > Weldon Washburn wrote:
> > > > On 10/30/06, Robin Garner < [EMAIL PROTECTED] > wrote:
> > > >>
> > > >> Weldon Washburn wrote:
> > > >> > On 10/27/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote:
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> Weldon Washburn wrote:
> > > >> >> > Steve Blackburn was in Portland Oregon today.  I mentioned
the
> > > idea
> > > >> of
> > > >> >> > adding a  reference pointer from object to its
j.l.Classinstance.
> > > >> >> MMTk
> > > >> >> > was
> > > >> >> > not designed with this idea in mind.  It looks like you will
> > > need to
> > > >> >> fix
> > > >> >> > this part of MMTk and maintain it yourself.  Steve did not
> > > seem
> > > >> >> thrilled
> > > >> >> at
> > > >> >> > adding this support to MMTk code base.
> > > >>
> > > >> Actually I think the answer may have been a little garbled along
> > > the way
> > > >> here: MMTk is not a memory manager *for* Java, it is simply a
> > > memory
> > > >> manager.  We have been careful to eliminate language-specific
> > > features
> > > >> in the heap that it manages.  MMTk has been used to manage C# (in
> > > the
> > > 

Re: [drlvm] Class unloading support

[Rana Dasgupta]

On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:


>Hi, everyone.

>I've splitted Harmony-2000 (see details:
>http://issues.apache.org/jira/browse/HARMONY-2000) patch >with automatic
>class unloading implementation into 2 independent parts:
>1. cleaning native resources (native_sources_cleanup.patch).
>2. automatic unloading design implementation (auto_unloading.patch).

>The first part is independent for all class unloading designs >and could
be
>commited.



Aleksey, how would one test this?


The second part is class unloading design implementation (the best
>class unloading approach is discussed now).



I did not understand, sorry:-) Which best approach?

Re: [general] Transition to TLP

[Tim Ellison]

Geir Magnusson Jr. wrote:
> I was going to start organizing the infrastructure transition to TLP. On
> the list are :
> 
> 1) website goes to "http://harmony.apache.org/";
> 
> 2) mail lists become
> 
>  [EMAIL PROTECTED]
> 
> etc.  This will be transparent - we'll move subscribers over, and I
> suppose we forward @incubator traffic to @harmony.
> 
> 3) move SVN from it's /incubator/harmony root to just /harmony and
> associated permissioning change (all internal to our SVN permissioning
> scheme)
> 
> 4) minor tweaks like changing location of snapshots, slight mods to
> website, tweak in JIRA to change our 'group' or whatever it's called,
> touch up's here and there on the wiki
> 
> Anything else?  I did ponder changes to our mail list.  I think adding a
> user list is something good to do now as it's non-disruptive, but I'm
> not convinced that breaking up the dev list is something needed at this
> point - I'd rather see us minimize the changes during this transition
> and do it later once settled.  I'm also still worried about fracturing
> things - it's wonderful to see us working as one community.

I agree that we are still drawing value from all talking on the same
channel, so let's keep it that way for now.

I can't think of any other infra issues.  We will need some minor source
updates, such as URL's embedded in site docs, removing incubator notices
and file markers etc. but they are not infra issues.

Please lay down redirects from the old mailing lists and URLs for a
decent period of time.

Regards,
Tim

-- 

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

Re: svn commit: r470383 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java

[Alexey Petrenko]

Missed this.
Thanks, Tim.

SY, Alexey

2006/11/2, Tim Ellison <[EMAIL PROTECTED]>:

This file needs an ASF block comment.

Regards,
Tim

[EMAIL PROTECTED] wrote:
> Author: apetrenko
> Date: Thu Nov  2 07:20:33 2006
> New Revision: 470383
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=470383
> Log:
> Patch from HARMONY-1509 applied
> OceanTheme added
>
> Added:
> 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
>
> Added: 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
> URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java?view=auto&rev=470383
> ==
> --- 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
 (added)
> +++ 
incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
 Thu Nov  2 07:20:33 2006
> @@ -0,0 +1,85 @@
> +package javax.swing.plaf.metal;
> +
> +import javax.swing.UIDefaults;
> +import javax.swing.plaf.ColorUIResource;
> +
> +public class OceanTheme extends DefaultMetalTheme {
> +
> +@Override
> +public String getName() {
> +return "Ocean";
> +}
> +
> +@Override
> +protected ColorUIResource getPrimary1() {
> +// TODO implement
> +return super.getPrimary1();
> +}
> +
> +@Override
> +protected ColorUIResource getPrimary2() {
> +// TODO implement
> +return super.getPrimary2();
> +}
> +
> +@Override
> +protected ColorUIResource getPrimary3() {
> +// TODO implement
> +return super.getPrimary3();
> +}
> +
> +@Override
> +protected ColorUIResource getSecondary1() {
> +// TODO implement
> +return super.getSecondary1();
> +}
> +
> +@Override
> +protected ColorUIResource getSecondary2() {
> +// TODO implement
> +return super.getSecondary2();
> +}
> +
> +@Override
> +protected ColorUIResource getSecondary3() {
> +// TODO implement
> +return super.getSecondary3();
> +}
> +
> +@Override
> +public void addCustomEntriesToTable(UIDefaults uiDefs) {
> +// TODO implement
> +super.addCustomEntriesToTable(uiDefs);
> +}
> +
> +@Override
> +protected ColorUIResource getBlack() {
> +// TODO implement
> +return super.getBlack();
> +}
> +
> +@Override
> +public ColorUIResource getControlTextColor() {
> +// TODO implement
> +return super.getControlTextColor();
> +}
> +
> +@Override
> +public ColorUIResource getDesktopColor() {
> +// TODO implement
> +return super.getDesktopColor();
> +}
> +
> +@Override
> +public ColorUIResource getInactiveControlTextColor() {
> +// TODO implement
> +return super.getInactiveControlTextColor();
> +}
> +
> +@Override
> +public ColorUIResource getMenuDisabledForeground() {
> +// TODO implement
> +return super.getMenuDisabledForeground();
> +}
> +
> +}
>
>
>

--

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

Re: svn commit: r470383 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java

[Tim Ellison]

This file needs an ASF block comment.

Regards,
Tim

[EMAIL PROTECTED] wrote:
> Author: apetrenko
> Date: Thu Nov  2 07:20:33 2006
> New Revision: 470383
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=470383
> Log:
> Patch from HARMONY-1509 applied
> OceanTheme added
> 
> Added:
> 
> incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
> 
> Added: 
> incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
> URL: 
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java?view=auto&rev=470383
> ==
> --- 
> incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
>  (added)
> +++ 
> incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/plaf/metal/OceanTheme.java
>  Thu Nov  2 07:20:33 2006
> @@ -0,0 +1,85 @@
> +package javax.swing.plaf.metal;
> +
> +import javax.swing.UIDefaults;
> +import javax.swing.plaf.ColorUIResource;
> +
> +public class OceanTheme extends DefaultMetalTheme {
> +
> +@Override
> +public String getName() {
> +return "Ocean";
> +}
> +
> +@Override
> +protected ColorUIResource getPrimary1() {
> +// TODO implement
> +return super.getPrimary1();
> +}
> +
> +@Override
> +protected ColorUIResource getPrimary2() {
> +// TODO implement
> +return super.getPrimary2();
> +}
> +
> +@Override
> +protected ColorUIResource getPrimary3() {
> +// TODO implement
> +return super.getPrimary3();
> +}
> +
> +@Override
> +protected ColorUIResource getSecondary1() {
> +// TODO implement
> +return super.getSecondary1();
> +}
> +
> +@Override
> +protected ColorUIResource getSecondary2() {
> +// TODO implement
> +return super.getSecondary2();
> +}
> +
> +@Override
> +protected ColorUIResource getSecondary3() {
> +// TODO implement
> +return super.getSecondary3();
> +}
> +
> +@Override
> +public void addCustomEntriesToTable(UIDefaults uiDefs) {
> +// TODO implement
> +super.addCustomEntriesToTable(uiDefs);
> +}
> +
> +@Override
> +protected ColorUIResource getBlack() {
> +// TODO implement
> +return super.getBlack();
> +}
> +
> +@Override
> +public ColorUIResource getControlTextColor() {
> +// TODO implement
> +return super.getControlTextColor();
> +}
> +
> +@Override
> +public ColorUIResource getDesktopColor() {
> +// TODO implement
> +return super.getDesktopColor();
> +}
> +
> +@Override
> +public ColorUIResource getInactiveControlTextColor() {
> +// TODO implement
> +return super.getInactiveControlTextColor();
> +}
> +
> +@Override
> +public ColorUIResource getMenuDisabledForeground() {
> +// TODO implement
> +return super.getMenuDisabledForeground();
> +}
> +
> +}
> 
> 
> 

-- 

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

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Alexey Petrenko]

I agree with Rana here.

And another thing... There are people who are more interested in
"develop smth" then "fix smth". And to catch such kind of peolpe TODO
list in WIKI is much better then JIRA.

Just IMHO :)

SY, Alexey

2006/11/2, Rana Dasgupta <[EMAIL PROTECTED]>:

  They serve different purposes. The Wiki is just a broad reminder to even
a visitor to Harmony of what remains to be done. I think that the JIRA is
more specific, maybe even more technical. The TODO page as it is today, with
sublinks, also seems well suited to capture this info. But it's not a big
deal.


On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
>
> Rana Dasgupta wrote:
> > No problem with them being both on the Wiki and the JIRA, I think.
>
> Other than getting out of sync  it just makes sense to use the
> "issue tracking system" for... "issue tracking" :)
>
> geir
>
>
> >
> > On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >>
> >> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> > Alexey Varlamov wrote:
> >> > > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >> > >> Put them in as JIRAs
> >> > > Done: HARMONY-2051, 2052, 2053.
> >> >
> >> > Thanks - that just makes it easy for people to grab them and get
> >> going...
> >>
> >> maybe, put the list of JIRAs on wiki?
> >>
> >> > >
> >> > >> Alexey Varlamov wrote:
> >> > >> > Below is a list of isolated development tasks which do not
> require
> >> > >> > advanced knowledge of VM and could be a nice start for newbies
> to
> >> get
> >> > >> > acquainted with the code. All items are targeted for better code
> >> > >> > sharing.
> >> > >> >
> >> > >> > 1) Eliminate duplicate implementation of j.l.Runtime.Process in
> >> kernel
> >> > >> > classes of DRLVM [1]. The classlib provides neat portlib-based
> >> > >> > reference implementation [2], which should be reused. These 2
> >> impls
> >> > >> > are roughly identical, so one needs to made more scrupulous
> >> comparison
> >> > >> > and squeeze some features/fixes of [1] which may be missing in
> >> [2],
> >> > >> > then employ [2] in j.l.Runtime of DRLVM and drop [1].
> >> > >> >
> >> > >> > 2) Improve/re-implement a parser of generic signatures in DRLVM
> >> kernel
> >> > >> > classes [3], and move this functionality to classlib (luni ?),
> so
> >> > >> > other VMs could reuse it for 1.5 support. The current impl is
> >> somewhat
> >> > >> > messy and half-baked, one need to invent more shaped and modular
> >> API
> >> > >> > to the parser. One more possible issue is parser's dependency on
> >> > >> > antlr, which may be considered overkill for this duty. I think
> >> antlr
> >> > >> > has its pros, like more illustrative code with clear
> >> correlation to
> >> > >> > formal grammar [4]; unfortunately this is not the case with the
> >> impl
> >> > >> > in question. OTOH minimizing number of dependencies for VM is
> >> always
> >> > >> > good.
> >> > >> >
> >> > >> > 3) Classlib's j.u.TimeZone expects "user.timezone" property
> value
> >> > >> > initialized during VM startup (BTW I did not find explicit
> >> statement
> >> > >> > in VMI docs for that, only indirect reference in kernel stub for
> >> > >> > j.l.System). I believe this action should be done by hyluni
> >> natives
> >> > >> > during JNI_OnLoad, no reason to burden VM with it. Therefore I
> >> suggest
> >> > >> > to move "port_user_timezone()" function [5] from DRLVM to
> classlib
> >> > >> > (luni/port), and fix DRLVM & hyluni accordingly.
> >> > >> >
> >> > >> > [1]
> >> > >>
> >> working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
> >> > >> > +
> >> working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
> >> > >> > [2]
> >> > >> >
> >> > >>
> >>
> 
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*
> >>
> >> > >> >
> >> > >> > +
> >> working_classlib\modules\luni\src\main\native\luni\shared\process.c
> >> > >> > [3]
> >> > >> >
> >> > >>
> >>
> 
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
> >>
> >> > >> >
> >> > >> > [4]
> >> > >> >
> >> > >>
> >>
> http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
> >>
> >> > >> > Para 4.4.4
> >> > >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c
> >> > >> >
> >> > >> > Comments? Should I put this somewhere on the Wiki?
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
> >> --
> >> Egor Pasko, Intel Managed Runtime Division
> >>
> >>
> >
>

Re: [classlib] Preprocessor - CHECKPOINT

[Sian January]

On 02/11/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:




Sian January wrote:
> I believe that in CVS when you make a branch there's nothing in it to
> begin with, so if you check out code from the branch it looks the same
> as code in head.  Then if a change is made in a file in head and that
> file hasn't been changed in the branch that change is reflected in the
> branch.  My understanding is that SVN is based on CVS so I think it
> should work the same way.

Nope.

There is really no such thing as a branch or tag in SVN.  It's just a
copy.  I think it's the feature I miss most from CVS.



That's very unfortunate.  I had assumed that SVN was a superset of CVS as
it's more recent, but obviously I was wrong :-(


So my point was that if it's only a small
> number of classes that are branched then integrating fixes shouldn't be
> that problematic.  Please feel free to correct me if any of those
> assumptions are wrong.
>
> Just thinking about J2ME, I can imagine that some source files are going
> to be very different.  For example there are no Java 5 features in J2ME,
> so any generic classes will have to be almost completely different.  My
> concern is that trying to combine two quite different classes in the
> same file is going be very difficult to read and understand.

Right.  I don't know the first thing about ME.  Maybe we should come up
w/ use cases based on Java 6 (as we're going to do it at some point) and
work from there.



Yes - that seems to make much more sense.

geir


>
> Thanks,
>
> Sian
>
>
> On 02/11/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
> > wrote:
>
>
>
> Sian January wrote:
>  > I may be totally off track here, but how about just having two
copies
>  > of all the files that differ?  I don't believe it would be that
many,
>  > and it would save us from having complicated source files or
> having to
>  > use special tools or special IDE plug-ins.  For me the value of
> having
>  > clearly readable source code and being able to use an IDE out of
> the box
>  > outweighs any extra effort there may be with this solution.
>
> Because I think that still means we have separate branches, and thus
> the
> integration problem for fixes.
>
> geir
>
>  >
>  > Regards,
>  >
>  > Sian
>  >
>  >
>  >
>  > On 31/10/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
> 
>  > >> wrote:
>  >
>  > So we all agree that it's not an ideal solution.
>  >
>  > Can anyone think of anything else?  No one said this was
> going to be
>  > easy...
>  >
>  > geir
>  >
>  >
>  >
>  >
>  > --
>  > Sian January
>  >
>  > IBM Java Technology Centre, UK
>
>
>
>
> --
> Sian January
>
> IBM Java Technology Centre, UK





--
Sian January

IBM Java Technology Centre, UK

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Rana Dasgupta]

  They serve different purposes. The Wiki is just a broad reminder to even
a visitor to Harmony of what remains to be done. I think that the JIRA is
more specific, maybe even more technical. The TODO page as it is today, with
sublinks, also seems well suited to capture this info. But it's not a big
deal.


On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:




Rana Dasgupta wrote:
> No problem with them being both on the Wiki and the JIRA, I think.

Other than getting out of sync  it just makes sense to use the
"issue tracking system" for... "issue tracking" :)

geir


>
> On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
>>
>> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
>> > Alexey Varlamov wrote:
>> > > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>> > >> Put them in as JIRAs
>> > > Done: HARMONY-2051, 2052, 2053.
>> >
>> > Thanks - that just makes it easy for people to grab them and get
>> going...
>>
>> maybe, put the list of JIRAs on wiki?
>>
>> > >
>> > >> Alexey Varlamov wrote:
>> > >> > Below is a list of isolated development tasks which do not
require
>> > >> > advanced knowledge of VM and could be a nice start for newbies
to
>> get
>> > >> > acquainted with the code. All items are targeted for better code
>> > >> > sharing.
>> > >> >
>> > >> > 1) Eliminate duplicate implementation of j.l.Runtime.Process in
>> kernel
>> > >> > classes of DRLVM [1]. The classlib provides neat portlib-based
>> > >> > reference implementation [2], which should be reused. These 2
>> impls
>> > >> > are roughly identical, so one needs to made more scrupulous
>> comparison
>> > >> > and squeeze some features/fixes of [1] which may be missing in
>> [2],
>> > >> > then employ [2] in j.l.Runtime of DRLVM and drop [1].
>> > >> >
>> > >> > 2) Improve/re-implement a parser of generic signatures in DRLVM
>> kernel
>> > >> > classes [3], and move this functionality to classlib (luni ?),
so
>> > >> > other VMs could reuse it for 1.5 support. The current impl is
>> somewhat
>> > >> > messy and half-baked, one need to invent more shaped and modular
>> API
>> > >> > to the parser. One more possible issue is parser's dependency on
>> > >> > antlr, which may be considered overkill for this duty. I think
>> antlr
>> > >> > has its pros, like more illustrative code with clear
>> correlation to
>> > >> > formal grammar [4]; unfortunately this is not the case with the
>> impl
>> > >> > in question. OTOH minimizing number of dependencies for VM is
>> always
>> > >> > good.
>> > >> >
>> > >> > 3) Classlib's j.u.TimeZone expects "user.timezone" property
value
>> > >> > initialized during VM startup (BTW I did not find explicit
>> statement
>> > >> > in VMI docs for that, only indirect reference in kernel stub for
>> > >> > j.l.System). I believe this action should be done by hyluni
>> natives
>> > >> > during JNI_OnLoad, no reason to burden VM with it. Therefore I
>> suggest
>> > >> > to move "port_user_timezone()" function [5] from DRLVM to
classlib
>> > >> > (luni/port), and fix DRLVM & hyluni accordingly.
>> > >> >
>> > >> > [1]
>> > >>
>> working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
>> > >> > +
>> working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
>> > >> > [2]
>> > >> >
>> > >>
>>
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*
>>
>> > >> >
>> > >> > +
>> working_classlib\modules\luni\src\main\native\luni\shared\process.c
>> > >> > [3]
>> > >> >
>> > >>
>>
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
>>
>> > >> >
>> > >> > [4]
>> > >> >
>> > >>
>>
http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
>>
>> > >> > Para 4.4.4
>> > >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c
>> > >> >
>> > >> > Comments? Should I put this somewhere on the Wiki?
>> > >> >
>> > >>
>> > >
>> >
>>
>> --
>> Egor Pasko, Intel Managed Runtime Division
>>
>>
>

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Gregory Shimansky]

Geir

I actually was serious. Probably you were confused, I didn't write 
"build test", I wrote "build smoke.test". The first one works ok, the 
second doesn't.


It happens because "test" (top-level test target) is handled in a 
different way from "smoke.test" (target just for smoke test category) 
target in build.xml. The "smoke.test" target just switches default 
processing target to "smoke.test" and runs "process_components" (which 
in its turn loops over all components). The "test" special handling of 
processing components escapes me, I don't quite understand how it works, 
but it seems to work correctly, without looping.


The question I was trying to solve was, how to correctly add jvmti.test 
target to the build.xml so that it would run only jvmti tests but not 
loop over components, but when "test" target it called, jvmti tests 
category would be executed along with all other categories.


Including "jvmti.test" target into build.xml in the same way as 
"smoke.test" doesn't make me happy.


Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

Why not use junit?


If you mean why not use junit to loop over tests, then it is not the 
case. I've used junit to do this in my work.


The loop which I wrote here is the loop over components in the 
build.xml of drlvm. If you run "build smoke.test" you'll see that the 
same tests are repeated several times (you have to be patient to see 
this).


You're joking, right?  I do this for ever patch commit I do.

This is done because build loops over all known VM components like 
vmi, vmocode, gc, interpreter, etc. It is Ok for building, and it is 
done exactly for building, but it is not Ok for testing because 
repeating tests for the whole JVM for each of its components makes no 
sense.


You're joking here too, right?  How do you know if there aren't side 
effects among components?


geir




Gregory Shimansky wrote:

On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:

Gregory,

I observed similar quirks with paths while intergrating kernel tests
into build. AFAIU the "Grand Design" is the following: there are
abstracted targets and isolated component descriptors; build system
iterates through all components and tries to apply given target to
each component. So there are various tricks to stop it running tests
multiple times a-la "recurring inclusion protection" in C headers.
I do not grok how it calculates dependencies though, but it is quite
easy to drive it mad and it starts doing wrong sequence of targets and
picks wrong components etc.
So I just snipped off that fanciful machinery and made simple subant
for "kernel.test" target - see its definition in build/make/build.xml,
and compare with nearby "smoke.test" one.


Ok I've made it though all of the interesting ant tricks and created 
my own jvmti.test target. I noticed the difference of how 
kernel.test target is included into build.xml as compared to 
smoke.test or unit.test.


AFAIU only "test" target does actually work to run only once and for 
the required number of modes (jit, interpreter). This is done with a 
special workaround for "test" target in build.xml, it has its own 
processing. But inclusion of smoke.test and unit.test in build.xml 
right now makes it run in a loop for all components for which tests 
don't have any relation to.


I am still experimenting with the build, it might be I'll find a 
solution for individual test categories so it would be possible to 
run them separately from the general "test" target.


--
Gregory

Re: [DRLVM][PORT] correct API to retrieve processor number

[Rana Dasgupta]

Xiao Feng,
  Did GetNativeSystemInfo() work? I can write our own api if we need it,
but the best way would be to do it around cpuid, since the chip knows best.
I know the cpuid documented behaviour on Intel. On other platforms, I am not
100% sure, though AMD and Intel have somewhat similar feedback from cpuid
(except for brandname string).
 One advantage of using the OS api's is that they are already supposed to
have done this work with the platform vendors and should be uptodate.

Rana


On 11/1/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:


Very informative! Thanks, Rana.

-xiaofeng

On 11/2/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>On Windows, there is a bunch of bugs.
>
>- On W2003 SP1, Vista, XP-64 GetLogicalProcessorInformation() is the
>recommended api. It returns # of cores on AMD and # of logical procs
on
>Intel.
>- GetSystemInfo() is on XP-32 and Windows Server. It does not work in
>wow mode. I think GetNativeSystemInfo is needed.
>- For x64, the VC/VC++ the __cpuid() intrinsic returns
>wrong information
>
>   The root cause is that the incorrect versions use the cpuid
> instruction incorrectly. __cpuid() uses old style cpuid and takes input
from
> eax only instead of eax, ecx . GetSystemInfo() uses the registers in
short
> mode when doing cpuid, so I think it fails for wow. It is amazing how
> Windows works at all!
>
>
>
>
> On 11/1/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> >
> > On 11/1/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> > > Just a wild guess: this may be caused by x86 emulation on em64t
> > > (x86_64). SDK docs advise to use GetNativeSystemInfo() in such case,
> > > instead of currently used GetSystemInfo(). (See
> > > vm\port\src\misc\win\sysinfo.c).
> > >
> >
> > huh, I guess you are right, since my machine is X86-64bit. :-) I will
> > try the API you pointed.
> >
> > Thanks,
> > xiaofeng
> >
> >
>
>

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Geir Magnusson Jr.]

Rana Dasgupta wrote:

No problem with them being both on the Wiki and the JIRA, I think.


Other than getting out of sync  it just makes sense to use the 
"issue tracking system" for... "issue tracking" :)


geir




On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:


On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Alexey Varlamov wrote:
> > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >> Put them in as JIRAs
> > Done: HARMONY-2051, 2052, 2053.
>
> Thanks - that just makes it easy for people to grab them and get
going...

maybe, put the list of JIRAs on wiki?

> >
> >> Alexey Varlamov wrote:
> >> > Below is a list of isolated development tasks which do not require
> >> > advanced knowledge of VM and could be a nice start for newbies to
get
> >> > acquainted with the code. All items are targeted for better code
> >> > sharing.
> >> >
> >> > 1) Eliminate duplicate implementation of j.l.Runtime.Process in
kernel
> >> > classes of DRLVM [1]. The classlib provides neat portlib-based
> >> > reference implementation [2], which should be reused. These 2 
impls

> >> > are roughly identical, so one needs to made more scrupulous
comparison
> >> > and squeeze some features/fixes of [1] which may be missing in 
[2],

> >> > then employ [2] in j.l.Runtime of DRLVM and drop [1].
> >> >
> >> > 2) Improve/re-implement a parser of generic signatures in DRLVM
kernel
> >> > classes [3], and move this functionality to classlib (luni ?), so
> >> > other VMs could reuse it for 1.5 support. The current impl is
somewhat
> >> > messy and half-baked, one need to invent more shaped and modular
API
> >> > to the parser. One more possible issue is parser's dependency on
> >> > antlr, which may be considered overkill for this duty. I think
antlr
> >> > has its pros, like more illustrative code with clear 
correlation to

> >> > formal grammar [4]; unfortunately this is not the case with the
impl
> >> > in question. OTOH minimizing number of dependencies for VM is
always
> >> > good.
> >> >
> >> > 3) Classlib's j.u.TimeZone expects "user.timezone" property value
> >> > initialized during VM startup (BTW I did not find explicit
statement
> >> > in VMI docs for that, only indirect reference in kernel stub for
> >> > j.l.System). I believe this action should be done by hyluni 
natives

> >> > during JNI_OnLoad, no reason to burden VM with it. Therefore I
suggest
> >> > to move "port_user_timezone()" function [5] from DRLVM to classlib
> >> > (luni/port), and fix DRLVM & hyluni accordingly.
> >> >
> >> > [1]
> >>
working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
> >> > +
working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
> >> > [2]
> >> >
> >>
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\* 


> >> >
> >> > +
working_classlib\modules\luni\src\main\native\luni\shared\process.c
> >> > [3]
> >> >
> >>
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\** 


> >> >
> >> > [4]
> >> >
> >>
http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf 


> >> > Para 4.4.4
> >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c
> >> >
> >> > Comments? Should I put this somewhere on the Wiki?
> >> >
> >>
> >
>

--
Egor Pasko, Intel Managed Runtime Division

Re: [classlib] Preprocessor - CHECKPOINT

[Mikhail Fursov]

On 11/2/06, Sian January <[EMAIL PROTECTED]> wrote:


Just thinking about J2ME, I can imagine that some source files are going
to be very different.  For example there are no Java 5 features in J2ME,
so
any generic classes will have to be almost completely different.  My
concern
is that trying to combine two quite different classes in the same file is
going be very difficult to read and understand.



Good point! I think Java1.2 classes format is a reason to move J2ME
development into separate branch.
The only usecase for preprocessor is left (correct me if I miss something)
is Java6 changes.
?

--
Mikhail Fursov

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to 
begin with, so if you check out code from the branch it looks the same 
as code in head.  Then if a change is made in a file in head and that 
file hasn't been changed in the branch that change is reflected in the 
branch.  My understanding is that SVN is based on CVS so I think it 
should work the same way.  


Nope.

There is really no such thing as a branch or tag in SVN.  It's just a 
copy.  I think it's the feature I miss most from CVS.


So my point was that if it's only a small 
number of classes that are branched then integrating fixes shouldn't be 
that problematic.  Please feel free to correct me if any of those 
assumptions are wrong.
 
Just thinking about J2ME, I can imagine that some source files are going 
to be very different.  For example there are no Java 5 features in J2ME, 
so any generic classes will have to be almost completely different.  My 
concern is that trying to combine two quite different classes in the 
same file is going be very difficult to read and understand.


Right.  I don't know the first thing about ME.  Maybe we should come up 
w/ use cases based on Java 6 (as we're going to do it at some point) and 
work from there.


geir

 
Thanks,
 
Sian



On 02/11/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] 
> wrote:




Sian January wrote:
 > I may be totally off track here, but how about just having two copies
 > of all the files that differ?  I don't believe it would be that many,
 > and it would save us from having complicated source files or
having to
 > use special tools or special IDE plug-ins.  For me the value of
having
 > clearly readable source code and being able to use an IDE out of
the box
 > outweighs any extra effort there may be with this solution.

Because I think that still means we have separate branches, and thus
the
integration problem for fixes.

geir

 >
 > Regards,
 >
 > Sian
 >
 >
 >
 > On 31/10/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]

 > >> wrote:
 >
 > So we all agree that it's not an ideal solution.
 >
 > Can anyone think of anything else?  No one said this was
going to be
 > easy...
 >
 > geir
 >
 >
 >
 >
 > --
 > Sian January
 >
 > IBM Java Technology Centre, UK




--
Sian January

IBM Java Technology Centre, UK

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Rana Dasgupta]

No problem with them being both on the Wiki and the JIRA, I think.

On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:


On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Alexey Varlamov wrote:
> > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >> Put them in as JIRAs
> > Done: HARMONY-2051, 2052, 2053.
>
> Thanks - that just makes it easy for people to grab them and get
going...

maybe, put the list of JIRAs on wiki?

> >
> >> Alexey Varlamov wrote:
> >> > Below is a list of isolated development tasks which do not require
> >> > advanced knowledge of VM and could be a nice start for newbies to
get
> >> > acquainted with the code. All items are targeted for better code
> >> > sharing.
> >> >
> >> > 1) Eliminate duplicate implementation of j.l.Runtime.Process in
kernel
> >> > classes of DRLVM [1]. The classlib provides neat portlib-based
> >> > reference implementation [2], which should be reused. These 2 impls
> >> > are roughly identical, so one needs to made more scrupulous
comparison
> >> > and squeeze some features/fixes of [1] which may be missing in [2],
> >> > then employ [2] in j.l.Runtime of DRLVM and drop [1].
> >> >
> >> > 2) Improve/re-implement a parser of generic signatures in DRLVM
kernel
> >> > classes [3], and move this functionality to classlib (luni ?), so
> >> > other VMs could reuse it for 1.5 support. The current impl is
somewhat
> >> > messy and half-baked, one need to invent more shaped and modular
API
> >> > to the parser. One more possible issue is parser's dependency on
> >> > antlr, which may be considered overkill for this duty. I think
antlr
> >> > has its pros, like more illustrative code with clear correlation to
> >> > formal grammar [4]; unfortunately this is not the case with the
impl
> >> > in question. OTOH minimizing number of dependencies for VM is
always
> >> > good.
> >> >
> >> > 3) Classlib's j.u.TimeZone expects "user.timezone" property value
> >> > initialized during VM startup (BTW I did not find explicit
statement
> >> > in VMI docs for that, only indirect reference in kernel stub for
> >> > j.l.System). I believe this action should be done by hyluni natives
> >> > during JNI_OnLoad, no reason to burden VM with it. Therefore I
suggest
> >> > to move "port_user_timezone()" function [5] from DRLVM to classlib
> >> > (luni/port), and fix DRLVM & hyluni accordingly.
> >> >
> >> > [1]
> >>
working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
> >> > +
working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
> >> > [2]
> >> >
> >>
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*
> >> >
> >> > +
working_classlib\modules\luni\src\main\native\luni\shared\process.c
> >> > [3]
> >> >
> >>
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
> >> >
> >> > [4]
> >> >
> >>
http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
> >> > Para 4.4.4
> >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c
> >> >
> >> > Comments? Should I put this somewhere on the Wiki?
> >> >
> >>
> >
>

--
Egor Pasko, Intel Managed Runtime Division

RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Ivanov, Alexey A]

>-Original Message-
>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 02, 2006 5:03 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing] compatibility:
j.s.text.GapContent.replace()
>behaviour
>
>Why not?

It was decided to resolve the issue with GapContent in issue:
HARMONY-1809.

Regards,
Alexey.

>
>
>Ivanov, Alexey A wrote:
>>> -Original Message-
>>> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>>> Sent: Thursday, November 02, 2006 3:50 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib][swing] compatibility:
>> j.s.text.GapContent.replace()
>>> behaviour
>>>
>>> HARMONY-1975is already applied and closed ;)
>>
>> Yep, I know.
>> But the section with GapContent modification is *not* applied as can
be
>> seen from comments in the issue.
>>
>> Regards,
>> Alexey.
>>
>>> 2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:
 I'll take care of 1975.

 SY, Alexey

 2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:
> +1. Silently doing nothing if invalid parameters are passed seems
>> to
> me a right behavior in this case.
>
> Will someone apply changes to GapContent from the
>> harmony-1975.patch
> or we need to make a separate patch for this?
>
> On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>> 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
>>> Hi all,
>>>
>>> I've started fixing HARMONY-1809. To remove throws clause from
>> the
>>> declaration of replace method, as it was proposed by Oleg in
>>> HARMONY-1975, I placed removeItems() and insertItems() calls
>> into
>>> try-catch block. This would work OK for any valid arguments.
>>>
>>> I was going to handle invalid arguments by making adjustments
>> so
>>> that
>>> the following removeItems() and insertItems() will not throw
>> the
>>> exception. After I wrote several tests, I faced strange
>> behaviour
>>> of RI
>>> with regards to invalid arguments to replace.
>>>
>>> (The Javadoc say nothing about which valid ranges for replace()
>>> parameters as well as any exceptions.)
>>>
>>> RI accepts invalid arguments but the result differs from what
>> I'd
>>> expect.
>>> For example, if the content has "text" in it, I'd expect that
>>> content.replace(-2, 4, null, 0) would give "xt" as the result.
>> I
>>> mean
>>> the invalid start position is adjusted to 0, and the length of
>>> remove is
>>> adjusted to be 2 accordingly. But this is not the case. As the
>>> result of
>>> this call, all characters are removed leaving "" in the
>> content.
>>> Moreover the content object becomes unusable after that:
>>> content.insertString(0, "1") throws
>> ArrayIndexOutOfBoundsException.
>>> Similarly if number of characters to be removed is greater than
>> the
>>> length of the content (content.replace(2, 4, null, 0) with
>> "text"
>>> in
>>> it), the object will throw ArrayIndexOutOfBoundsException when
>>> doing
>>> insertString.
>>>
>>>
>>> Considering the fact that GapContent is pretty low-level class
>> in
>>> text
>>> representation model and that it is protected, I think that
>> Harmony
>>> implementation can silently ignore BadLocationException
>> possible
>>> thrown
>>> from insertItems() and removeItems(). Taking into account
>> erroneous
>>> behaviour of RI's replace, we can do that until an application
>> is
>>> broken.
>> +1 for this solution.
>>
>> SY, Alexey
>>
>>> As another option, we can throw an Error from catch block to
>> make
>>> application which depends on implementation of replace()
>> fast-fail.
>>>
>>> Any objections, comments, opinions?
>>>
>>> Thanks,
>>> Alexey.
>>>
>>>
>>> P.S. The related JIRA issues:
>>> https://issues.apache.org/jira/browse/HARMONY-1809
>>> https://issues.apache.org/jira/browse/HARMONY-1975
>>>
>>> GapContent Javadoc:
>>>
>>>
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm
>> l
>>> Description of GapContent.replace:
>>>
>>>
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm
>> l
>>> #replace(int,%20int,%20java.lang.Object,%20int)
>>>
>>>
>>> --
>>> Alexey A. Ivanov
>>> Intel Middleware Product Division
>>>
>>
>> --
>> Alexey A. Ivanov
>> Intel Middleware Product Division
>>


--
Alexey A. Ivanov
Intel Middleware Product Division

RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Ivanov, Alexey A]

>-Original Message-
>From: Tim Ellison [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 02, 2006 5:26 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing] compatibility:
j.s.text.GapContent.replace()
>behaviour
>
>Ivanov, Alexey A wrote:
>>> -Original Message-
>>> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>>> Sent: Thursday, November 02, 2006 3:50 PM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib][swing] compatibility:
>> j.s.text.GapContent.replace()
>>> behaviour
>>>
>>> HARMONY-1975is already applied and closed ;)
>>
>> Yep, I know. But the section with GapContent modification is *not*
>> applied as can be seen from comments in the issue.
>
>Stepan explained why, and Oleg (as issue rasier) agreed/verified the
>issue for closure.  The GapContent is covered by HARMONY-1809.
>Just let things take their course.

And I agreed with both Stepan and Oleg as well.

This discussion is part of the course to resolve HARMONY-1809.

Regards,
Alexey.

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

--
Alexey A. Ivanov
Intel Middleware Product Division

Re: [classlib] Preprocessor - CHECKPOINT

[Sian January]

I believe that in CVS when you make a branch there's nothing in it to begin
with, so if you check out code from the branch it looks the same as code in
head.  Then if a change is made in a file in head and that file hasn't been
changed in the branch that change is reflected in the branch.  My
understanding is that SVN is based on CVS so I think it should work the same
way.  So my point was that if it's only a small number of classes that
are branched then integrating fixes shouldn't be that problematic.  Please
feel free to correct me if any of those assumptions are wrong.

Just thinking about J2ME, I can imagine that some source files are going
to be very different.  For example there are no Java 5 features in J2ME, so
any generic classes will have to be almost completely different.  My concern
is that trying to combine two quite different classes in the same file is
going be very difficult to read and understand.

Thanks,

Sian


On 02/11/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:




Sian January wrote:
> I may be totally off track here, but how about just having two copies
> of all the files that differ?  I don't believe it would be that many,
> and it would save us from having complicated source files or having to
> use special tools or special IDE plug-ins.  For me the value of having
> clearly readable source code and being able to use an IDE out of the box
> outweighs any extra effort there may be with this solution.

Because I think that still means we have separate branches, and thus the
integration problem for fixes.

geir

>
> Regards,
>
> Sian
>
>
>
> On 31/10/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
> > wrote:
>
> So we all agree that it's not an ideal solution.
>
> Can anyone think of anything else?  No one said this was going to be
> easy...
>
> geir
>
>
>
>
> --
> Sian January
>
> IBM Java Technology Centre, UK





--
Sian January

IBM Java Technology Centre, UK

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Tim Ellison]

Ivanov, Alexey A wrote:
>> -Original Message-
>> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, November 02, 2006 3:50 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][swing] compatibility:
> j.s.text.GapContent.replace()
>> behaviour
>>
>> HARMONY-1975is already applied and closed ;)
> 
> Yep, I know. But the section with GapContent modification is *not*
> applied as can be seen from comments in the issue.

Stepan explained why, and Oleg (as issue rasier) agreed/verified the
issue for closure.  The GapContent is covered by HARMONY-1809.
Just let things take their course.

Regards,
Tim

-- 

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

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Geir Magnusson Jr.]

Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

Why not use junit?


If you mean why not use junit to loop over tests, then it is not the 
case. I've used junit to do this in my work.


The loop which I wrote here is the loop over components in the build.xml 
of drlvm. If you run "build smoke.test" you'll see that the same tests 
are repeated several times (you have to be patient to see this).


You're joking, right?  I do this for ever patch commit I do.

This is 
done because build loops over all known VM components like vmi, vmocode, 
gc, interpreter, etc. It is Ok for building, and it is done exactly for 
building, but it is not Ok for testing because repeating tests for the 
whole JVM for each of its components makes no sense.


You're joking here too, right?  How do you know if there aren't side 
effects among components?


geir




Gregory Shimansky wrote:

On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:

Gregory,

I observed similar quirks with paths while intergrating kernel tests
into build. AFAIU the "Grand Design" is the following: there are
abstracted targets and isolated component descriptors; build system
iterates through all components and tries to apply given target to
each component. So there are various tricks to stop it running tests
multiple times a-la "recurring inclusion protection" in C headers.
I do not grok how it calculates dependencies though, but it is quite
easy to drive it mad and it starts doing wrong sequence of targets and
picks wrong components etc.
So I just snipped off that fanciful machinery and made simple subant
for "kernel.test" target - see its definition in build/make/build.xml,
and compare with nearby "smoke.test" one.


Ok I've made it though all of the interesting ant tricks and created 
my own jvmti.test target. I noticed the difference of how kernel.test 
target is included into build.xml as compared to smoke.test or 
unit.test.


AFAIU only "test" target does actually work to run only once and for 
the required number of modes (jit, interpreter). This is done with a 
special workaround for "test" target in build.xml, it has its own 
processing. But inclusion of smoke.test and unit.test in build.xml 
right now makes it run in a loop for all components for which tests 
don't have any relation to.


I am still experimenting with the build, it might be I'll find a 
solution for individual test categories so it would be possible to 
run them separately from the general "test" target.

Re: [classlib][math]BigInteger bitwise operations

[Daniel Fridlender]

Hi Tatyana,

thank you for reporting this bug.  We have submitted a patch now to fix it.
Thanks,

Daniel

On 10/29/06, tatyana doubtsova <[EMAIL PROTECTED]> wrote:

 Hello,

I've filed http://issues.apache.org/jira/browse/HARMONY-1996 regarding
bitwise operations on negative values. Could anybody, please,  have a look
at it.

Thanks,
Tanya

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Gregory Shimansky]

Geir Magnusson Jr. wrote:

Why not use junit?


If you mean why not use junit to loop over tests, then it is not the 
case. I've used junit to do this in my work.


The loop which I wrote here is the loop over components in the build.xml 
of drlvm. If you run "build smoke.test" you'll see that the same tests 
are repeated several times (you have to be patient to see this). This is 
done because build loops over all known VM components like vmi, vmocode, 
gc, interpreter, etc. It is Ok for building, and it is done exactly for 
building, but it is not Ok for testing because repeating tests for the 
whole JVM for each of its components makes no sense.



Gregory Shimansky wrote:

On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:

Gregory,

I observed similar quirks with paths while intergrating kernel tests
into build. AFAIU the "Grand Design" is the following: there are
abstracted targets and isolated component descriptors; build system
iterates through all components and tries to apply given target to
each component. So there are various tricks to stop it running tests
multiple times a-la "recurring inclusion protection" in C headers.
I do not grok how it calculates dependencies though, but it is quite
easy to drive it mad and it starts doing wrong sequence of targets and
picks wrong components etc.
So I just snipped off that fanciful machinery and made simple subant
for "kernel.test" target - see its definition in build/make/build.xml,
and compare with nearby "smoke.test" one.


Ok I've made it though all of the interesting ant tricks and created 
my own jvmti.test target. I noticed the difference of how kernel.test 
target is included into build.xml as compared to smoke.test or unit.test.


AFAIU only "test" target does actually work to run only once and for 
the required number of modes (jit, interpreter). This is done with a 
special workaround for "test" target in build.xml, it has its own 
processing. But inclusion of smoke.test and unit.test in build.xml 
right now makes it run in a loop for all components for which tests 
don't have any relation to.


I am still experimenting with the build, it might be I'll find a 
solution for individual test categories so it would be possible to run 
them separately from the general "test" target.







--
Gregory

Re: [classlib] Preprocessor - CHECKPOINT

[Geir Magnusson Jr.]

Sian January wrote:
I may be totally off track here, but how about just having two copies 
of all the files that differ?  I don't believe it would be that many, 
and it would save us from having complicated source files or having to 
use special tools or special IDE plug-ins.  For me the value of having 
clearly readable source code and being able to use an IDE out of the box 
outweighs any extra effort there may be with this solution.


Because I think that still means we have separate branches, and thus the 
integration problem for fixes.


geir

 
Regards,


Sian
 

 
On 31/10/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] 
> wrote:


So we all agree that it's not an ideal solution.

Can anyone think of anything else?  No one said this was going to be
easy...

geir




--
Sian January

IBM Java Technology Centre, UK

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Geir Magnusson Jr.]

Why not?


Ivanov, Alexey A wrote:

-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 3:50 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][swing] compatibility:

j.s.text.GapContent.replace()

behaviour

HARMONY-1975is already applied and closed ;)


Yep, I know.
But the section with GapContent modification is *not* applied as can be
seen from comments in the issue.

Regards,
Alexey.


2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:

I'll take care of 1975.

SY, Alexey

2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:

+1. Silently doing nothing if invalid parameters are passed seems

to

me a right behavior in this case.

Will someone apply changes to GapContent from the

harmony-1975.patch

or we need to make a separate patch for this?

On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:

2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:

Hi all,

I've started fixing HARMONY-1809. To remove throws clause from

the

declaration of replace method, as it was proposed by Oleg in
HARMONY-1975, I placed removeItems() and insertItems() calls

into

try-catch block. This would work OK for any valid arguments.

I was going to handle invalid arguments by making adjustments

so

that

the following removeItems() and insertItems() will not throw

the

exception. After I wrote several tests, I faced strange

behaviour

of RI

with regards to invalid arguments to replace.

(The Javadoc say nothing about which valid ranges for replace()
parameters as well as any exceptions.)

RI accepts invalid arguments but the result differs from what

I'd

expect.
For example, if the content has "text" in it, I'd expect that
content.replace(-2, 4, null, 0) would give "xt" as the result.

I

mean

the invalid start position is adjusted to 0, and the length of

remove is

adjusted to be 2 accordingly. But this is not the case. As the

result of

this call, all characters are removed leaving "" in the

content.

Moreover the content object becomes unusable after that:
content.insertString(0, "1") throws

ArrayIndexOutOfBoundsException.

Similarly if number of characters to be removed is greater than

the

length of the content (content.replace(2, 4, null, 0) with

"text"

in

it), the object will throw ArrayIndexOutOfBoundsException when

doing

insertString.


Considering the fact that GapContent is pretty low-level class

in

text

representation model and that it is protected, I think that

Harmony

implementation can silently ignore BadLocationException

possible

thrown

from insertItems() and removeItems(). Taking into account

erroneous

behaviour of RI's replace, we can do that until an application

is

broken.

+1 for this solution.

SY, Alexey


As another option, we can throw an Error from catch block to

make

application which depends on implementation of replace()

fast-fail.


Any objections, comments, opinions?

Thanks,
Alexey.


P.S. The related JIRA issues:
https://issues.apache.org/jira/browse/HARMONY-1809
https://issues.apache.org/jira/browse/HARMONY-1975

GapContent Javadoc:


http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm

l

Description of GapContent.replace:


http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm

l

#replace(int,%20int,%20java.lang.Object,%20int)


--
Alexey A. Ivanov
Intel Middleware Product Division



--
Alexey A. Ivanov
Intel Middleware Product Division

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Geir Magnusson Jr.]

Salikh Zakirov wrote:

Geir Magnusson Jr. wrote:

Why not use junit?


 task in implicitly assumes that you can
run all tests in single JVM instance. Though it does provide
fork-mode to run tests in separate JVM processes, it still
does not allow per-test JVM args configuration.

Which is exactly what we need for JVMTI tests, as most of the
test has their own special agent to be run with.


I understand the agent is needed, but I don't see why you can't do that 
that with junit. Can't you just invoke ant w/ an exec?




Nevertheless, we could use junit task with some benefit
in creating test reports. I think this can be accomodated
in Gregory's scheme by using  task instead of  task.

The most of the ant mechanics (selecting tests and looping
over them for compilation and running) will be there
no matter what we use for test running,  or .


Right - I'm just tired of adding to the mess that is, IMO, the DRLVM 
build.  I'd rather see new things be more conventional.


geir

Re: [general] Transition to TLP

[Geir Magnusson Jr.]

Alexey Petrenko wrote:

2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:

I was going to start organizing the infrastructure transition to TLP.
On the list are :

1) website goes to "http://harmony.apache.org/";

2) mail lists become

And harmony-commits will become [EMAIL PROTECTED]


Of course.  That's what I meant by "etc", below.




 [EMAIL PROTECTED]

etc.  This will be transparent - we'll move subscribers over, and I
suppose we forward @incubator traffic to @harmony.

3) move SVN from it's /incubator/harmony root to just /harmony and
associated permissioning change (all internal to our SVN permissioning
scheme)

4) minor tweaks like changing location of snapshots, slight mods to
website, tweak in JIRA to change our 'group' or whatever it's called,
touch up's here and there on the wiki

Anything else?  I did ponder changes to our mail list.  I think adding a
user list is something good to do now as it's non-disruptive, but I'm
not convinced that breaking up the dev list is something needed at this
point - I'd rather see us minimize the changes during this transition
and do it later once settled.  I'm also still worried about fracturing
things - it's wonderful to see us working as one community.

geir

Re: [classlib] Preprocessor - CHECKPOINT

[Sian January]

I may be totally off track here, but how about just having two copies of all
the files that differ?  I don't believe it would be that many, and it would
save us from having complicated source files or having to use special tools
or special IDE plug-ins.  For me the value of having clearly readable source
code and being able to use an IDE out of the box outweighs any extra effort
there may be with this solution.

Regards,

Sian



On 31/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


So we all agree that it's not an ideal solution.

Can anyone think of anything else?  No one said this was going to be
easy...

geir





--
Sian January

IBM Java Technology Centre, UK

Re: [classlib][portlib] Docs?

[Geir Magnusson Jr.]

Paulex Yang wrote:

Geir Magnusson Jr. wrote:



Paulex Yang wrote:

Geir Magnusson Jr. wrote:
yeah - someone generate, and we can hang them on the website.  I'm 
not sure we'd want to check them in though...
Is it possible to add documents into website but not to commit them 
in SVN?


Yep.  I was thinking the same for the Doxygen docs.

Basically, you just create locally, review, and then tar and put up on 
site manually.

+1 to go for that


It does remove the ability for group oversight (IOW, no commit msgs), 
but if the generation process isn't very stale (small changes to one 
page have repercussions all over...) then it keeps the SVN churn to a 
minimum.
Actually I have no idea what kind of commit msgs needed for API 
document...they are just generated by tools from codes. I think the most 
important information is the svn revision number against which the 
document is generated, any doxygen guru can help to find a way? Any 
chance to pass a revision number to doxygen and to get it added into 
footer of every page?


That's a very smart idea.  +1

geir



geir


 We removed them from classlib/trunk/doc because the SVN metadata

get in the way when updating the document.


I've done this before for API docs...

geir


Alexey Petrenko wrote:

Having these docs on website will be really good!

SY, Alexey

2006/11/1, Paulex Yang <[EMAIL PROTECTED]>:

If you get Doxygen installed, you can create it by running "ant
doxygen-natives" in classlib/trunk/doc. There were discussions to 
move
the document to somewhere on website, but seems it is still to be 
done.


Morozova, Nadezhda wrote:
> Not that I know of :( bits of things are in the devguide, maybe. 
But you

> probably won't find that of much notice.
> Anyone, please tell me it's not true!
>
> Thank you,
> Nadya Morozova
>
>
> -Original Message-
> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 01, 2006 4:15 PM
> To: harmony-dev@incubator.apache.org
> Subject: [classlib][portlib] Docs?
>
> Guys,
>
> do we have any docs on portlib?
>
> SY, Alexey
>
>


--
Paulex Yang
China Software Development Lab
IBM

Re: Harmony passes 94% on derby tests.

[Vladimir Ivanov]

Nice work!
Thanks, Vladimir


On 11/2/06, Nina Rinskaya <[EMAIL PROTECTED]> wrote:


Hi,

I might have chosen the wrong thread for this message, but this is
about another well-known unit tests suite - Eclipse Unit Tests. I've
recently filed new JIRA issue
(https://issues.apache.org/jira/browse/HARMONY-2038) with the ant
script to run EUT on Harmony. Does it make sense to integrate it to
the buildtest module?

For a moment EUT pass rate on Harmony is ~77%. EUT runs results (on
Linux/ia32 and windows/ia32) are being updated on wiki:
http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM

A number of EUT test cases fail on Harmony because EUT uses some
hard-coded Sun/Jrockit classlibs names. In particular,
org.eclipse.jdt.core.tests.util.Util class uses specific paths to
class libraries jar files (/lib/rt.jar, for example).
org.eclipse.jdt.core.tests.runtime.*VMLauncher classes use "javaw" as
vm executable name that is missing in Harmony bundle. So what I would
like to do now is to patch EUT to invoke Harmony correctly if it is ok
with everyone here.

Best regards,
Nina

On 10/25/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> Excellent!
>
>
>
> I have one more idea: we already have buildtest module. Some time ago we
> agreed to extends it by coverage and japi scripts (I hope it happens
soon:)
> ). May be we extend it one more time and store here some scripts for
> automatic run of other-projects unit tests? Seems, in this case we can
> easily reproduce tests run and enable new platforms.
>
> Of cause, we can not cover all application but we can define some list
of
> 'most important application'.
>
> Is it OK?
>
> Leo, could you share your script for Derby?
>
> Tony, could you share your scripts for ant and log4j?
>
>
>
>  thanks, Vladimir
>
>
> PS. The directory structure may be something like that:
> builtest
> - trunk
> - cc
> - coverage
> - japi
> - application_test
> - derby
> - ant
> - etc
> - misc (some other scripts)
> On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > Nice work!
> >
> > More inline..
> >
> > Leo Li wrote:
> > > 467 Tests Run
> > > 94% Pass (443 tests passed)
> > > 6% Fail (24 tests failed)
> > > 5 Suites skipped
> > >
> > > The main progress focuses here:
> > > 1. Harmony classlib fails to load class when user-defined security
> > policy
> > > exists. It is due to the sequence of library loading of VM, which
has
> > been
> > > resolved now.
> > > 2. A new workround for derby tests which allow useprocess to run
test or
> > > else several testcases might fail due to derby lack these tests when
> > > useprocess = false.
> > > 3. Derby source code uses the version and the name of java vm to
decide
> > > what
> > > to do, while current IBM VM has the version of "1.4.2" and the name
of
> > > "j9",
> > > which has different output on the screen from that of standard RI
1.5.
> > At
> > > the same time Derby test compares the output of the iteractive test
> > scripts
> > > to that of expected. I have made some slight modification in its
source
> > > code, but I have not throughly change this odd behavior, ...,too
much:(
> >
> > Have you approached the derby community with the changes?
> >
> > >
> > > Besides, some testcase fails even on RI. I exclude
> > > a "derbynetclientmats" test suit since it will hang both RI and
Harmony.
> > > Currently all the failure is irrelevant to Harmony. Hope I can find
> > > something in the left.
> > >
> > > I have updated the wiki of derby on Hamony:
> > > http://wiki.apache.org/harmony/Apache_Derby.
> > >
> >
>
>

Re: Harmony passes 94% on derby tests.

[Nina Rinskaya]

Hi,

I might have chosen the wrong thread for this message, but this is
about another well-known unit tests suite - Eclipse Unit Tests. I've
recently filed new JIRA issue
(https://issues.apache.org/jira/browse/HARMONY-2038) with the ant
script to run EUT on Harmony. Does it make sense to integrate it to
the buildtest module?

For a moment EUT pass rate on Harmony is ~77%. EUT runs results (on
Linux/ia32 and windows/ia32) are being updated on wiki:
http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM

A number of EUT test cases fail on Harmony because EUT uses some
hard-coded Sun/Jrockit classlibs names. In particular,
org.eclipse.jdt.core.tests.util.Util class uses specific paths to
class libraries jar files (/lib/rt.jar, for example).
org.eclipse.jdt.core.tests.runtime.*VMLauncher classes use "javaw" as
vm executable name that is missing in Harmony bundle. So what I would
like to do now is to patch EUT to invoke Harmony correctly if it is ok
with everyone here.

Best regards,
Nina

On 10/25/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:

Excellent!



I have one more idea: we already have buildtest module. Some time ago we
agreed to extends it by coverage and japi scripts (I hope it happens soon:)
). May be we extend it one more time and store here some scripts for
automatic run of other-projects unit tests? Seems, in this case we can
easily reproduce tests run and enable new platforms.

Of cause, we can not cover all application but we can define some list of
'most important application'.

Is it OK?

Leo, could you share your script for Derby?

Tony, could you share your scripts for ant and log4j?



 thanks, Vladimir


PS. The directory structure may be something like that:
builtest
- trunk
- cc
- coverage
- japi
- application_test
- derby
- ant
- etc
- misc (some other scripts)
On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> Nice work!
>
> More inline..
>
> Leo Li wrote:
> > 467 Tests Run
> > 94% Pass (443 tests passed)
> > 6% Fail (24 tests failed)
> > 5 Suites skipped
> >
> > The main progress focuses here:
> > 1. Harmony classlib fails to load class when user-defined security
> policy
> > exists. It is due to the sequence of library loading of VM, which has
> been
> > resolved now.
> > 2. A new workround for derby tests which allow useprocess to run test or
> > else several testcases might fail due to derby lack these tests when
> > useprocess = false.
> > 3. Derby source code uses the version and the name of java vm to decide
> > what
> > to do, while current IBM VM has the version of "1.4.2" and the name of
> > "j9",
> > which has different output on the screen from that of standard RI 1.5.
> At
> > the same time Derby test compares the output of the iteractive test
> scripts
> > to that of expected. I have made some slight modification in its source
> > code, but I have not throughly change this odd behavior, ...,too much:(
>
> Have you approached the derby community with the changes?
>
> >
> > Besides, some testcase fails even on RI. I exclude
> > a "derbynetclientmats" test suit since it will hang both RI and Harmony.
> > Currently all the failure is irrelevant to Harmony. Hope I can find
> > something in the left.
> >
> > I have updated the wiki of derby on Hamony:
> > http://wiki.apache.org/harmony/Apache_Derby.
> >
>

Re: [DRLVM] ipf initial support (interpreter mode)

[Tim Ellison]

Ivan Volosyuk wrote:
> Fixed. Now DRLVM works on IPF in interpreter mode with gcv41.
> Started running smoke tests and its passing one by one... well, it is
> time to rest...

Well done -- sounds like you deserve it.

Regards,
Tim

-- 

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

Re: [drlvm] Class unloading support

[Aleksey Ignatenko]

Hi, everyone.

I've splitted Harmony-2000 (see details:
http://issues.apache.org/jira/browse/HARMONY-2000) patch with automatic
class unloading implementation into 2 independent parts:
1. cleaning native resources (native_sources_cleanup.patch).
2. automatic unloading design implementation (auto_unloading.patch).

The first part is independent for all class unloading designs and could be
commited. The second part is class unloading design implementation (the best
class unloading approach is discussed now).

I propose to commit native_sources_cleanup.patch and continue class
unloading development with minimal requirements on drlvm.

Aleksey.


On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:


Oops, sorry, misprinted in my suggestion:
if (cl->IsBootstrap() *|| 
*env->b_VTable_trace_is_not_supported_by_GC)

{
vm_enumerate_jlc(c);
if (c->vtable)
vm_enumerate_root_reference((void**)&c->vtObj,
FALSE);
}

Aleksey.

 On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>
> Weldon,
>
> >A question for all involved.  Is it possible to somehow make it appear
> that
> >the new objects related to unloading  (VTable, ClassLoader, etc)  are
> always
> >reachable and thus never collected?  I am trying to figure out a way to
> make
> >integration of class unloading independent of correct support inside
> the GC
> >and JIT.  This option could be a command line switch or compile time
> option.
>
> I agree with Robin:
> >Simple.  Keep a list or table of these objects as part of the root set.
> >Enumerate it optionally depending on a command line option.
>
> Details: you can see from Harmony-2000 patch, that this is done for
> Bootstrap classes already. If you look at root_set_enum_common.cpp (with the
> patch applied) vm_enumerate_static_fields() function, there is line:
> if (cl->IsBootstrap())
> {
> vm_enumerate_jlc(c);
> if (c->vtable)
> vm_enumerate_root_reference((void**)&c->vtObj,
> FALSE);
> }
> else
> {
> vm_enumerate_jlc(c, true/*weak*/);
> }
> You can see, that there are strong roots to Bootstrap j.l.Classes and
> their VTable objects. So I suppose, that it would be very simple to
> propogate strong roots to all other classes (not only Bootstrap), something
> like:
> if (cl->IsBootstrap() *&&
> env->b_VTable_trace_is_not_supported_by_GC*)
> {
> vm_enumerate_jlc(c);
> if (c->vtable)
> vm_enumerate_root_reference((void**)&c->vtObj,
> FALSE);
> }
> where *b_VTable_trace_is_not_supported_by_GC *is flag which is set
> according to used GC. This will force switching off any class unloading
> support.
>
> Aleksey.
>
>  On 11/1/06, Robin Garner <[EMAIL PROTECTED] > wrote:
> >
> > Weldon Washburn wrote:
> > > On 10/30/06, Robin Garner < [EMAIL PROTECTED] > wrote:
> > >>
> > >> Weldon Washburn wrote:
> > >> > On 10/27/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >> Weldon Washburn wrote:
> > >> >> > Steve Blackburn was in Portland Oregon today.  I mentioned the
> > idea
> > >> of
> > >> >> > adding a  reference pointer from object to its j.l.Classinstance.
> > >> >> MMTk
> > >> >> > was
> > >> >> > not designed with this idea in mind.  It looks like you will
> > need to
> > >> >> fix
> > >> >> > this part of MMTk and maintain it yourself.  Steve did not
> > seem
> > >> >> thrilled
> > >> >> at
> > >> >> > adding this support to MMTk code base.
> > >>
> > >> Actually I think the answer may have been a little garbled along
> > the way
> > >> here: MMTk is not a memory manager *for* Java, it is simply a
> > memory
> > >> manager.  We have been careful to eliminate language-specific
> > features
> > >> in the heap that it manages.  MMTk has been used to manage C# (in
> > the
> > >> Rotor VM) and was being incorporated into a Haskell runtime until I
> > ran
> > >> out of time.
> > >>
> > >> Therefore, MMTk knows nothing about the concept of class unloading,
> > or
> > >> java.lang.Class.
> > >>
> > >> >> How does MMTk support class unloading then?
> > >> >
> > >> >
> > >> > MMTk has no special support for class unloading.  This may have
> > >> > something to
> > >> > do with the entire system being written in Java thus class
> > unloading
> > >> come
> > >> > along for free.  If there needs to be a modification to support
> > special
> > >> > case
> > >> > objects in DRLVM, someone will need to fixup MMTk and provide
> > onging
> > >> > support of this patch in Harmony.  I have zero idea how big this
> > effort
> > >> > would be.   It would also be good to hear what the impact will be
> > on
> > >> GCV5.
> > >>
> > >> MMTk implements several algorithms for retaining the reachabl

RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Ivanov, Alexey A]

>-Original Message-
>From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 02, 2006 3:50 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing] compatibility:
j.s.text.GapContent.replace()
>behaviour
>
>HARMONY-1975is already applied and closed ;)

Yep, I know.
But the section with GapContent modification is *not* applied as can be
seen from comments in the issue.

Regards,
Alexey.

>
>2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:
>> I'll take care of 1975.
>>
>> SY, Alexey
>>
>> 2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:
>> > +1. Silently doing nothing if invalid parameters are passed seems
to
>> > me a right behavior in this case.
>> >
>> > Will someone apply changes to GapContent from the
harmony-1975.patch
>> > or we need to make a separate patch for this?
>> >
>> > On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>> > > 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
>> > > > Hi all,
>> > > >
>> > > > I've started fixing HARMONY-1809. To remove throws clause from
the
>> > > > declaration of replace method, as it was proposed by Oleg in
>> > > > HARMONY-1975, I placed removeItems() and insertItems() calls
into
>> > > > try-catch block. This would work OK for any valid arguments.
>> > > >
>> > > > I was going to handle invalid arguments by making adjustments
so
>that
>> > > > the following removeItems() and insertItems() will not throw
the
>> > > > exception. After I wrote several tests, I faced strange
behaviour
>of RI
>> > > > with regards to invalid arguments to replace.
>> > > >
>> > > > (The Javadoc say nothing about which valid ranges for replace()
>> > > > parameters as well as any exceptions.)
>> > > >
>> > > > RI accepts invalid arguments but the result differs from what
I'd
>> > > > expect.
>> > > > For example, if the content has "text" in it, I'd expect that
>> > > > content.replace(-2, 4, null, 0) would give "xt" as the result.
I
>mean
>> > > > the invalid start position is adjusted to 0, and the length of
>remove is
>> > > > adjusted to be 2 accordingly. But this is not the case. As the
>result of
>> > > > this call, all characters are removed leaving "" in the
content.
>> > > >
>> > > > Moreover the content object becomes unusable after that:
>> > > > content.insertString(0, "1") throws
ArrayIndexOutOfBoundsException.
>> > > >
>> > > > Similarly if number of characters to be removed is greater than
the
>> > > > length of the content (content.replace(2, 4, null, 0) with
"text"
>in
>> > > > it), the object will throw ArrayIndexOutOfBoundsException when
>doing
>> > > > insertString.
>> > > >
>> > > >
>> > > > Considering the fact that GapContent is pretty low-level class
in
>text
>> > > > representation model and that it is protected, I think that
Harmony
>> > > > implementation can silently ignore BadLocationException
possible
>thrown
>> > > > from insertItems() and removeItems(). Taking into account
erroneous
>> > > > behaviour of RI's replace, we can do that until an application
is
>> > > > broken.
>> > > +1 for this solution.
>> > >
>> > > SY, Alexey
>> > >
>> > > > As another option, we can throw an Error from catch block to
make
>> > > > application which depends on implementation of replace()
fast-fail.
>> > > >
>> > > >
>> > > > Any objections, comments, opinions?
>> > > >
>> > > > Thanks,
>> > > > Alexey.
>> > > >
>> > > >
>> > > > P.S. The related JIRA issues:
>> > > > https://issues.apache.org/jira/browse/HARMONY-1809
>> > > > https://issues.apache.org/jira/browse/HARMONY-1975
>> > > >
>> > > > GapContent Javadoc:
>> > > >
>http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm
l
>> > > > Description of GapContent.replace:
>> > > >
>http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm
l
>> > > > #replace(int,%20int,%20java.lang.Object,%20int)
>> > > >
>> > > >
>> > > > --
>> > > > Alexey A. Ivanov
>> > > > Intel Middleware Product Division
>> > > >
>> > >
>> >
>>

--
Alexey A. Ivanov
Intel Middleware Product Division

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Oleg Khaschansky]

Could you, please, look at the unit test in #1809 also?

On 11/2/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote:

Yes, but the GapContent changes were not applied.

On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> HARMONY-1975is already applied and closed ;)
>
> 2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:
> > I'll take care of 1975.
> >
> > SY, Alexey
> >
> > 2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:
> > > +1. Silently doing nothing if invalid parameters are passed seems to
> > > me a right behavior in this case.
> > >
> > > Will someone apply changes to GapContent from the harmony-1975.patch
> > > or we need to make a separate patch for this?
> > >
> > > On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> > > > 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
> > > > > Hi all,
> > > > >
> > > > > I've started fixing HARMONY-1809. To remove throws clause from the
> > > > > declaration of replace method, as it was proposed by Oleg in
> > > > > HARMONY-1975, I placed removeItems() and insertItems() calls into
> > > > > try-catch block. This would work OK for any valid arguments.
> > > > >
> > > > > I was going to handle invalid arguments by making adjustments so that
> > > > > the following removeItems() and insertItems() will not throw the
> > > > > exception. After I wrote several tests, I faced strange behaviour of 
RI
> > > > > with regards to invalid arguments to replace.
> > > > >
> > > > > (The Javadoc say nothing about which valid ranges for replace()
> > > > > parameters as well as any exceptions.)
> > > > >
> > > > > RI accepts invalid arguments but the result differs from what I'd
> > > > > expect.
> > > > > For example, if the content has "text" in it, I'd expect that
> > > > > content.replace(-2, 4, null, 0) would give "xt" as the result. I mean
> > > > > the invalid start position is adjusted to 0, and the length of remove 
is
> > > > > adjusted to be 2 accordingly. But this is not the case. As the result 
of
> > > > > this call, all characters are removed leaving "" in the content.
> > > > >
> > > > > Moreover the content object becomes unusable after that:
> > > > > content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.
> > > > >
> > > > > Similarly if number of characters to be removed is greater than the
> > > > > length of the content (content.replace(2, 4, null, 0) with "text" in
> > > > > it), the object will throw ArrayIndexOutOfBoundsException when doing
> > > > > insertString.
> > > > >
> > > > >
> > > > > Considering the fact that GapContent is pretty low-level class in text
> > > > > representation model and that it is protected, I think that Harmony
> > > > > implementation can silently ignore BadLocationException possible 
thrown
> > > > > from insertItems() and removeItems(). Taking into account erroneous
> > > > > behaviour of RI's replace, we can do that until an application is
> > > > > broken.
> > > > +1 for this solution.
> > > >
> > > > SY, Alexey
> > > >
> > > > > As another option, we can throw an Error from catch block to make
> > > > > application which depends on implementation of replace() fast-fail.
> > > > >
> > > > >
> > > > > Any objections, comments, opinions?
> > > > >
> > > > > Thanks,
> > > > > Alexey.
> > > > >
> > > > >
> > > > > P.S. The related JIRA issues:
> > > > > https://issues.apache.org/jira/browse/HARMONY-1809
> > > > > https://issues.apache.org/jira/browse/HARMONY-1975
> > > > >
> > > > > GapContent Javadoc:
> > > > > 
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > > > > Description of GapContent.replace:
> > > > > 
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > > > > #replace(int,%20int,%20java.lang.Object,%20int)
> > > > >
> > > > >
> > > > > --
> > > > > Alexey A. Ivanov
> > > > > Intel Middleware Product Division
> > > > >
> > > >
> > >
> >
>

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Oleg Khaschansky]

Yes, but the GapContent changes were not applied.

On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:

HARMONY-1975is already applied and closed ;)

2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:
> I'll take care of 1975.
>
> SY, Alexey
>
> 2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:
> > +1. Silently doing nothing if invalid parameters are passed seems to
> > me a right behavior in this case.
> >
> > Will someone apply changes to GapContent from the harmony-1975.patch
> > or we need to make a separate patch for this?
> >
> > On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> > > 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
> > > > Hi all,
> > > >
> > > > I've started fixing HARMONY-1809. To remove throws clause from the
> > > > declaration of replace method, as it was proposed by Oleg in
> > > > HARMONY-1975, I placed removeItems() and insertItems() calls into
> > > > try-catch block. This would work OK for any valid arguments.
> > > >
> > > > I was going to handle invalid arguments by making adjustments so that
> > > > the following removeItems() and insertItems() will not throw the
> > > > exception. After I wrote several tests, I faced strange behaviour of RI
> > > > with regards to invalid arguments to replace.
> > > >
> > > > (The Javadoc say nothing about which valid ranges for replace()
> > > > parameters as well as any exceptions.)
> > > >
> > > > RI accepts invalid arguments but the result differs from what I'd
> > > > expect.
> > > > For example, if the content has "text" in it, I'd expect that
> > > > content.replace(-2, 4, null, 0) would give "xt" as the result. I mean
> > > > the invalid start position is adjusted to 0, and the length of remove is
> > > > adjusted to be 2 accordingly. But this is not the case. As the result of
> > > > this call, all characters are removed leaving "" in the content.
> > > >
> > > > Moreover the content object becomes unusable after that:
> > > > content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.
> > > >
> > > > Similarly if number of characters to be removed is greater than the
> > > > length of the content (content.replace(2, 4, null, 0) with "text" in
> > > > it), the object will throw ArrayIndexOutOfBoundsException when doing
> > > > insertString.
> > > >
> > > >
> > > > Considering the fact that GapContent is pretty low-level class in text
> > > > representation model and that it is protected, I think that Harmony
> > > > implementation can silently ignore BadLocationException possible thrown
> > > > from insertItems() and removeItems(). Taking into account erroneous
> > > > behaviour of RI's replace, we can do that until an application is
> > > > broken.
> > > +1 for this solution.
> > >
> > > SY, Alexey
> > >
> > > > As another option, we can throw an Error from catch block to make
> > > > application which depends on implementation of replace() fast-fail.
> > > >
> > > >
> > > > Any objections, comments, opinions?
> > > >
> > > > Thanks,
> > > > Alexey.
> > > >
> > > >
> > > > P.S. The related JIRA issues:
> > > > https://issues.apache.org/jira/browse/HARMONY-1809
> > > > https://issues.apache.org/jira/browse/HARMONY-1975
> > > >
> > > > GapContent Javadoc:
> > > > http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > > > Description of GapContent.replace:
> > > > http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > > > #replace(int,%20int,%20java.lang.Object,%20int)
> > > >
> > > >
> > > > --
> > > > Alexey A. Ivanov
> > > > Intel Middleware Product Division
> > > >
> > >
> >
>

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Alexey Petrenko]

HARMONY-1975is already applied and closed ;)

2006/11/2, Alexey Petrenko <[EMAIL PROTECTED]>:

I'll take care of 1975.

SY, Alexey

2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:
> +1. Silently doing nothing if invalid parameters are passed seems to
> me a right behavior in this case.
>
> Will someone apply changes to GapContent from the harmony-1975.patch
> or we need to make a separate patch for this?
>
> On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> > 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
> > > Hi all,
> > >
> > > I've started fixing HARMONY-1809. To remove throws clause from the
> > > declaration of replace method, as it was proposed by Oleg in
> > > HARMONY-1975, I placed removeItems() and insertItems() calls into
> > > try-catch block. This would work OK for any valid arguments.
> > >
> > > I was going to handle invalid arguments by making adjustments so that
> > > the following removeItems() and insertItems() will not throw the
> > > exception. After I wrote several tests, I faced strange behaviour of RI
> > > with regards to invalid arguments to replace.
> > >
> > > (The Javadoc say nothing about which valid ranges for replace()
> > > parameters as well as any exceptions.)
> > >
> > > RI accepts invalid arguments but the result differs from what I'd
> > > expect.
> > > For example, if the content has "text" in it, I'd expect that
> > > content.replace(-2, 4, null, 0) would give "xt" as the result. I mean
> > > the invalid start position is adjusted to 0, and the length of remove is
> > > adjusted to be 2 accordingly. But this is not the case. As the result of
> > > this call, all characters are removed leaving "" in the content.
> > >
> > > Moreover the content object becomes unusable after that:
> > > content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.
> > >
> > > Similarly if number of characters to be removed is greater than the
> > > length of the content (content.replace(2, 4, null, 0) with "text" in
> > > it), the object will throw ArrayIndexOutOfBoundsException when doing
> > > insertString.
> > >
> > >
> > > Considering the fact that GapContent is pretty low-level class in text
> > > representation model and that it is protected, I think that Harmony
> > > implementation can silently ignore BadLocationException possible thrown
> > > from insertItems() and removeItems(). Taking into account erroneous
> > > behaviour of RI's replace, we can do that until an application is
> > > broken.
> > +1 for this solution.
> >
> > SY, Alexey
> >
> > > As another option, we can throw an Error from catch block to make
> > > application which depends on implementation of replace() fast-fail.
> > >
> > >
> > > Any objections, comments, opinions?
> > >
> > > Thanks,
> > > Alexey.
> > >
> > >
> > > P.S. The related JIRA issues:
> > > https://issues.apache.org/jira/browse/HARMONY-1809
> > > https://issues.apache.org/jira/browse/HARMONY-1975
> > >
> > > GapContent Javadoc:
> > > http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > > Description of GapContent.replace:
> > > http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > > #replace(int,%20int,%20java.lang.Object,%20int)
> > >
> > >
> > > --
> > > Alexey A. Ivanov
> > > Intel Middleware Product Division
> > >
> >
>

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Alexey Petrenko]

I'll take care of 1975.

SY, Alexey

2006/11/2, Oleg Khaschansky <[EMAIL PROTECTED]>:

+1. Silently doing nothing if invalid parameters are passed seems to
me a right behavior in this case.

Will someone apply changes to GapContent from the harmony-1975.patch
or we need to make a separate patch for this?

On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
> > Hi all,
> >
> > I've started fixing HARMONY-1809. To remove throws clause from the
> > declaration of replace method, as it was proposed by Oleg in
> > HARMONY-1975, I placed removeItems() and insertItems() calls into
> > try-catch block. This would work OK for any valid arguments.
> >
> > I was going to handle invalid arguments by making adjustments so that
> > the following removeItems() and insertItems() will not throw the
> > exception. After I wrote several tests, I faced strange behaviour of RI
> > with regards to invalid arguments to replace.
> >
> > (The Javadoc say nothing about which valid ranges for replace()
> > parameters as well as any exceptions.)
> >
> > RI accepts invalid arguments but the result differs from what I'd
> > expect.
> > For example, if the content has "text" in it, I'd expect that
> > content.replace(-2, 4, null, 0) would give "xt" as the result. I mean
> > the invalid start position is adjusted to 0, and the length of remove is
> > adjusted to be 2 accordingly. But this is not the case. As the result of
> > this call, all characters are removed leaving "" in the content.
> >
> > Moreover the content object becomes unusable after that:
> > content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.
> >
> > Similarly if number of characters to be removed is greater than the
> > length of the content (content.replace(2, 4, null, 0) with "text" in
> > it), the object will throw ArrayIndexOutOfBoundsException when doing
> > insertString.
> >
> >
> > Considering the fact that GapContent is pretty low-level class in text
> > representation model and that it is protected, I think that Harmony
> > implementation can silently ignore BadLocationException possible thrown
> > from insertItems() and removeItems(). Taking into account erroneous
> > behaviour of RI's replace, we can do that until an application is
> > broken.
> +1 for this solution.
>
> SY, Alexey
>
> > As another option, we can throw an Error from catch block to make
> > application which depends on implementation of replace() fast-fail.
> >
> >
> > Any objections, comments, opinions?
> >
> > Thanks,
> > Alexey.
> >
> >
> > P.S. The related JIRA issues:
> > https://issues.apache.org/jira/browse/HARMONY-1809
> > https://issues.apache.org/jira/browse/HARMONY-1975
> >
> > GapContent Javadoc:
> > http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > Description of GapContent.replace:
> > http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> > #replace(int,%20int,%20java.lang.Object,%20int)
> >
> >
> > --
> > Alexey A. Ivanov
> > Intel Middleware Product Division
> >
>

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Mikhail Fursov]

On 11/2/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:


Geir Magnusson Jr. wrote:
> Why not use junit?

 task in implicitly assumes that you can
run all tests in single JVM instance. Though it does provide
fork-mode to run tests in separate JVM processes, it still
does not allow per-test JVM args configuration.

Which is exactly what we need for JVMTI tests, as most of the
test has their own special agent to be run with.



Salikh, the problem you described is very similar to the problem I had to
solve in JIT internal testing framework: run every test in a separate VM.  (
http://issues.apache.org/jira/browse/HARMONY-1531)
I've created a class that runs VM, waits until the process is finished,
reads its err and out streams and returns to the junit testcase.
+ Every native JIT test has Java prototype. Do you want to create something
similar? May be we can join our solutions?



--
Mikhail Fursov

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Salikh Zakirov]

Geir Magnusson Jr. wrote:
> Why not use junit?

 task in implicitly assumes that you can
run all tests in single JVM instance. Though it does provide
fork-mode to run tests in separate JVM processes, it still
does not allow per-test JVM args configuration.

Which is exactly what we need for JVMTI tests, as most of the
test has their own special agent to be run with.

Nevertheless, we could use junit task with some benefit
in creating test reports. I think this can be accomodated
in Gregory's scheme by using  task instead of  task.

The most of the ant mechanics (selecting tests and looping
over them for compilation and running) will be there
no matter what we use for test running,  or .

Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Oleg Khaschansky]

+1. Silently doing nothing if invalid parameters are passed seems to
me a right behavior in this case.

Will someone apply changes to GapContent from the harmony-1975.patch
or we need to make a separate patch for this?

On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:

2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
> Hi all,
>
> I've started fixing HARMONY-1809. To remove throws clause from the
> declaration of replace method, as it was proposed by Oleg in
> HARMONY-1975, I placed removeItems() and insertItems() calls into
> try-catch block. This would work OK for any valid arguments.
>
> I was going to handle invalid arguments by making adjustments so that
> the following removeItems() and insertItems() will not throw the
> exception. After I wrote several tests, I faced strange behaviour of RI
> with regards to invalid arguments to replace.
>
> (The Javadoc say nothing about which valid ranges for replace()
> parameters as well as any exceptions.)
>
> RI accepts invalid arguments but the result differs from what I'd
> expect.
> For example, if the content has "text" in it, I'd expect that
> content.replace(-2, 4, null, 0) would give "xt" as the result. I mean
> the invalid start position is adjusted to 0, and the length of remove is
> adjusted to be 2 accordingly. But this is not the case. As the result of
> this call, all characters are removed leaving "" in the content.
>
> Moreover the content object becomes unusable after that:
> content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.
>
> Similarly if number of characters to be removed is greater than the
> length of the content (content.replace(2, 4, null, 0) with "text" in
> it), the object will throw ArrayIndexOutOfBoundsException when doing
> insertString.
>
>
> Considering the fact that GapContent is pretty low-level class in text
> representation model and that it is protected, I think that Harmony
> implementation can silently ignore BadLocationException possible thrown
> from insertItems() and removeItems(). Taking into account erroneous
> behaviour of RI's replace, we can do that until an application is
> broken.
+1 for this solution.

SY, Alexey

> As another option, we can throw an Error from catch block to make
> application which depends on implementation of replace() fast-fail.
>
>
> Any objections, comments, opinions?
>
> Thanks,
> Alexey.
>
>
> P.S. The related JIRA issues:
> https://issues.apache.org/jira/browse/HARMONY-1809
> https://issues.apache.org/jira/browse/HARMONY-1975
>
> GapContent Javadoc:
> http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> Description of GapContent.replace:
> http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html
> #replace(int,%20int,%20java.lang.Object,%20int)
>
>
> --
> Alexey A. Ivanov
> Intel Middleware Product Division
>

Re: [classlib][luni]clean up excluded testcases in java.net

[Alexey Petrenko]

That would be great!

2006/11/2, Tony Wu <[EMAIL PROTECTED]>:

Hi all,
I noticed that some tests of java.net were excluded due to external
server dependency. Now we have a jetty in /depends/jars, is it time to
clean up these testcases to use jetty and make them run-able? I
volunteer to do it if so.

--
Tony Wu
China Software Development Lab, IBM

Re: [security][testing] unexpected unit test failure

[Vladimir Ivanov]

Thanks, it fixed now.
Thanks, Vladimir


On 11/2/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:


Fixed at r470318. Please verify.

-Stepan.


On 11/2/06, Vladimir Ivanov wrote:
>
> Could somebody look at new unit test failure (winXP, j9):
> Test:  testGenKey_keyPair Class:
> org.apache.harmony.tools.keytool.tests.GenKeyTest
> junit.framework.AssertionFailedError: Cannot create a temporary file
> C:\DOCUME~1\vivanov1\LOCALS~1\Temp\\GenKeyTestTemporaryFile. File with
> such
> name already exists.at
> org.apache.harmony.tools.keytool.tests.GenKeyTest.testGenKey_keyPair(
> GenKeyTest.java:61)   at java.lang.reflect.AccessibleObject.invokeV(
> AccessibleObject.java:25)
> Thanks, Vladimir
>
>


--
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][em] Value-profiling implementation is avaible.

[Egor Pasko]

On the 0x215 day of Apache Harmony Yuri Kashnikoff wrote:
> Yes, this was just a test :)
> Please, check the new version. I am working on making it better =)
> Thanks for feedback.
> 
> P.S. Please check tabs and other convention stuff.

Yuri, when attaching a patch to JIRA it is reasonable to provide some
additional info:
* on which platform you ran the 'build test' so we could pick it and
  test on some other platform before commit
* some other apps ran with the patch
* revision No. you are based on

BTW, did you collect statistics with your profiler on real
applications such as Eclipse or DaCapo? (analogous to those provided
in value profiling papers)

-- 
Egor Pasko, Intel Managed Runtime Division

Re: [classlib][portlib] Docs?

[Paulex Yang]

Geir Magnusson Jr. wrote:



Paulex Yang wrote:

Geir Magnusson Jr. wrote:
yeah - someone generate, and we can hang them on the website.  I'm 
not sure we'd want to check them in though...
Is it possible to add documents into website but not to commit them 
in SVN?


Yep.  I was thinking the same for the Doxygen docs.

Basically, you just create locally, review, and then tar and put up on 
site manually.

+1 to go for that


It does remove the ability for group oversight (IOW, no commit msgs), 
but if the generation process isn't very stale (small changes to one 
page have repercussions all over...) then it keeps the SVN churn to a 
minimum.
Actually I have no idea what kind of commit msgs needed for API 
document...they are just generated by tools from codes. I think the most 
important information is the svn revision number against which the 
document is generated, any doxygen guru can help to find a way? Any 
chance to pass a revision number to doxygen and to get it added into 
footer of every page?


geir


 We removed them from classlib/trunk/doc because the SVN metadata

get in the way when updating the document.


I've done this before for API docs...

geir


Alexey Petrenko wrote:

Having these docs on website will be really good!

SY, Alexey

2006/11/1, Paulex Yang <[EMAIL PROTECTED]>:

If you get Doxygen installed, you can create it by running "ant
doxygen-natives" in classlib/trunk/doc. There were discussions to 
move
the document to somewhere on website, but seems it is still to be 
done.


Morozova, Nadezhda wrote:
> Not that I know of :( bits of things are in the devguide, maybe. 
But you

> probably won't find that of much notice.
> Anyone, please tell me it's not true!
>
> Thank you,
> Nadya Morozova
>
>
> -Original Message-
> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 01, 2006 4:15 PM
> To: harmony-dev@incubator.apache.org
> Subject: [classlib][portlib] Docs?
>
> Guys,
>
> do we have any docs on portlib?
>
> SY, Alexey
>
>


--
Paulex Yang
China Software Development Lab
IBM















--
Paulex Yang
China Software Development Lab
IBM