from:"Geir Magnusson Jr ."

Basically, I want to uplift my own platform to 4.x, and then work the 
kinks out of that patch.


I just want to know what X is.

If no one says anything, I'll figure it out and declare it :)

geir


Gregory Shimansky wrote:

Egor Pasko wrote:

On the 0x216 day of Apache Harmony Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

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

Hmm no I don't remember such agreement. I think GCC is mostly
backwards compatible, and anything that compiles on 4.1.1 should
compile on previous versions. So it is better to support the latest
stable.

Not many people would like to install such GCC version, but someone
like me could at least give warnings that the most recent version of
GCC doesn't compile some code.


yes, and comment JIRA accordingly (with suggested fix). This way we
can support a very wide renge of GCCs constantly. I doubt I can use
the latest GCC soon, so I cannot check patches constantly.


I think you could use 4.1.0 in Fedora Core 5. Since patch level 
shouldn't really affect the C++ compilation restrictions, the same patch 
should break on 4.1.0 as well.



Does it make sense to use something CruiseControl-ish that walks
around JIRA patches and reports statistics which of them build OK? I
thought of such a tool recently.. Not a task I would dream to
implement though.


It could be an overkill to check on all possible gcc versions on all 
possible distributions and all possible platforms... When someone who 
has some problematic platform/distribution/gcc lets us know that 
something doesn't compile, it is probably enough.

Re: svn commit: r470310 - in /incubator/harmony/standard/site: README.txt docs/contributors.html xdocs/contributors.xml




Oliver Deakin wrote:
I think you might be right - I just made a change to test, ran the Ant 
build script
without altering the css location, and it looked ok to me. Perhaps there 
are
some pages that don't generate properly that I've missed - any of the 
website

design gurus know if we still need this step?


We never did.  We made the site.css local to the content dirs. 
Suboptimal, but removed the "special step" for QA.


geir



Regards,
Oliver

Alexei Zakharov wrote:

 1) **Temporarily** update the link to the CSS so you can
preview the site in a local browser:
-1) Go to line 266 in file xdocs/stylesheets/site.vsl
+1) Go to line 250 in file xdocs/stylesheets/site.vsl
2) Edit the path to site.css.  Specify an absolute path.
   e.g. from


Shouldn't we remove point (1) at all? It seems there is no need to
update css location anymore. At least it works ok for me without any
updating.

Regards,

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

Author: odeakin
Date: Thu Nov  2 02:16:26 2006
New Revision: 470310

URL: http://svn.apache.org/viewvc?view=rev&rev=470310
Log: (empty)

Modified:
   incubator/harmony/standard/site/README.txt
   incubator/harmony/standard/site/docs/contributors.html
   incubator/harmony/standard/site/xdocs/contributors.xml

Modified: incubator/harmony/standard/site/README.txt
URL: 
http://svn.apache.org/viewvc/incubator/harmony/standard/site/README.txt?view=diff&rev=470310&r1=470309&r2=470310 

== 


--- incubator/harmony/standard/site/README.txt (original)
+++ incubator/harmony/standard/site/README.txt Thu Nov  2 02:16:26 2006
@@ -5,7 +5,7 @@

 1) **Temporarily** update the link to the CSS so you can
preview the site in a local browser:
-1) Go to line 266 in file xdocs/stylesheets/site.vsl
+1) Go to line 250 in file xdocs/stylesheets/site.vsl
2) Edit the path to site.css.  Specify an absolute path.
   e.g. from


Modified: incubator/harmony/standard/site/docs/contributors.html
URL: 
http://svn.apache.org/viewvc/incubator/harmony/standard/site/docs/contributors.html?view=diff&rev=470310&r1=470309&r2=470310 

== 


--- incubator/harmony/standard/site/docs/contributors.html (original)
+++ incubator/harmony/standard/site/docs/contributors.html Thu Nov  2 
02:16:26 2006

@@ -412,6 +412,20 @@
A


+
+
+
+Oliver Deakin
+
+rowspan="" >

+
+IBM UK
+
+rowspan="" >

+
+A
+
+


Status :

Modified: incubator/harmony/standard/site/xdocs/contributors.xml
URL: 
http://svn.apache.org/viewvc/incubator/harmony/standard/site/xdocs/contributors.xml?view=diff&rev=470310&r1=470309&r2=470310 

== 


--- incubator/harmony/standard/site/xdocs/contributors.xml (original)
+++ incubator/harmony/standard/site/xdocs/contributors.xml Thu Nov  2 
02:16:26 2006

@@ -34,6 +34,7 @@
(Paulex)Pu YangIBM CNA
Weldon WashburnIntelA
Alexey PetrenkoIntelA
+Oliver DeakinIBM UKA

Re: [general] committers list




Tim Ellison wrote:

How about we :

 - indicate who is also on the Harmony PMC, lest anyone care;


that's fine


 - drop the list of organizations, since it is irrelevant IMO;


Well, it's a common thing.  I don't care either way, but I suspect 
removing the info will just feed paranoia and anti-Harmony FUD.



 - add a photo or a short paragraph for each person to
   make it more personal (link to your blog/whatever).


No thanks :) How about making the name a link to your own personal page 
or blog, as you suggested?



geir



Just an idea.

Tim

Oliver Deakin wrote:

*Passes magic wand over repository*

done, r470339.

Regards,
Oliver

Geir Magnusson Jr. wrote:

Any chance you give your magic commit powers another spin and put the
committer list in alphabetical order, by last name (a - zed) :)

geir

Oliver Deakin wrote:

Apologies for the lack of commit message - in the excitement
of adding myself to the list of committers I clicked "ok" a little
too soon ;)

I also corrected the site.vsl line number in the website readme.

Regards,
Oliver

[EMAIL PROTECTED] wrote:

Author: odeakin
Date: Thu Nov  2 02:16:26 2006
New Revision: 470310

URL: http://svn.apache.org/viewvc?view=rev&rev=470310
Log: (empty)

Modified:
incubator/harmony/standard/site/README.txt
incubator/harmony/standard/site/docs/contributors.html
incubator/harmony/standard/site/xdocs/contributors.xml

Modified: incubator/harmony/standard/site/README.txt
URL:
http://svn.apache.org/viewvc/incubator/harmony/standard/site/README.txt?view=diff&rev=470310&r1=470309&r2=470310

==

--- incubator/harmony/standard/site/README.txt (original)
+++ incubator/harmony/standard/site/README.txt Thu Nov  2 02:16:26 2006
@@ -5,7 +5,7 @@
 
 1) **Temporarily** update the link to the CSS so you can

 preview the site in a local browser:
-1) Go to line 266 in file xdocs/stylesheets/site.vsl
+1) Go to line 250 in file xdocs/stylesheets/site.vsl
 2) Edit the path to site.css.  Specify an absolute
path. e.g. from
 


Modified: incubator/harmony/standard/site/docs/contributors.html
URL:
http://svn.apache.org/viewvc/incubator/harmony/standard/site/docs/contributors.html?view=diff&rev=470310&r1=470309&r2=470310

==

--- incubator/harmony/standard/site/docs/contributors.html (original)
+++ incubator/harmony/standard/site/docs/contributors.html Thu Nov 
2 02:16:26 2006

@@ -412,6 +412,20 @@
 A
 
 
+
+
++Oliver Deakin
+
+
++IBM UK
+
+
++A
+
+
 
 
 Status :

Modified: incubator/harmony/standard/site/xdocs/contributors.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/standard/site/xdocs/contributors.xml?view=diff&rev=470310&r1=470309&r2=470310

==

--- incubator/harmony/standard/site/xdocs/contributors.xml (original)
+++ incubator/harmony/standard/site/xdocs/contributors.xml Thu Nov 
2 02:16:26 2006

@@ -34,6 +34,7 @@
 (Paulex)Pu YangIBM CNA
 Weldon WashburnIntelA
 Alexey PetrenkoIntelA
+Oliver DeakinIBM UKA

Re: [classlib] Preprocessor - an attempt at [even more] clarity




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Tim Ellison wrote:

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?


Yes, but some transforms preserve all mark-up and are used to switch the
compilable form between different targets (these are the 'devtarget's);
and some transforms are mark-up-lossy and are used to provide the end
user compilable form (this is the 'releasetarget').


Yes, I figured that out last night when I was driving to dinner. Let me 
 see if I have it right :


  (Master)
 /   |\
/| \
   / |  \
dev1 <-> dev2 <->dev3
 |   ||
targ1   targ2   targ3

where in your case, master doesn't exist (consider it virtual), dev1/2/3 
are compilable under whatever platform they are targeted to yet contain 
all the stuff for other platforms, and targ1/2/3 are 'clean code' code 
the target platform.


There exists a transform process

   interDev(dev1, 2) -> dev2

which is really conceptually

   masterToDev(devToMaster(dev1), 2)

(if you had a master) and further

   toCleanTarget(dev1) - > targ1

('normal' code for target platform)






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.


Not in the technique that I'm talking about.  All devtargets contain all
the code (but they differ in which code is compilable and which is in
comments).


Right - because you don't have a master



Let me try using very simple example for my favourite type, assuming we
were doing CLDC and SE1.5 development simultaneously. 


[SNIP]

Thanks for the very nice example.  That example conforms w/ my picture 
of how things might work (although I suspect things could get *very* 
ugly to work with in the intermediate dev1/2/3 form, but I think that 
some real use cases will tell us that)





We then talked about how the different devtargets can be stored in
different working directories for use by Harmony developers with
file-based tools, or (thinking about it for a second now) it could be an
on the fly processing to/from canonical form on disk by the IDE editor.


Yes - that latter part is exactly what I've been advocating :

One copy (the master) on which the IDE and cmd line tooling does both 
the "file/directory" masking (dealing with the differences that aren't 
just in class files - add and remove classes, etc - the "lookaside 
table") as well as code xform.


I never thought of having that intermediate form (dev1/2/3) as being 
fundamental to the model, although it's a nice option. I can see how it 
will be nice for editing, but I'm instinctively suspicious of it being 
necessary).


Why?

Because I can imagine that as a SE programmer, I would want 1 of 2 things :

1) clean code to work on for a specific target (say SE 5)

2) a hybrid version of your dev1 that only has the glop for a subset of 
the platforms (say just Java SE 5 and Java SE 6) in it, so I can focus 
across just those two.


Maybe it's just me, but I'd probably want the distractions of other 
platforms out of the code so I can get better into the 'flow' when 
developing.


So that's why I think of dev1/2/3 as being the virtual code (not key to 
the process) that can be generated either by the tooling onto disk as a 
temp form, or by IDE virtually in situ.


Further, there aren't just N dev forms for the N distinct 
platforms/version, but rather the freedom for combinations where they 
make sense (a dev w/ SE 6 and SE 6 only)


If you want to generate a dev1 and work on that on disk, great - do it, 
you can go back to master.


If you want to just work on the single master tree, you can do that if 
the IDE has the tooling.




We also talked about how patches to the source that Mrs CLDC developer
sees can be matched back to a devtarget.


Yes, I did read it :)

Thanks for the example.  I guess the difference is that I virtualized 
the dev1/2/3 form and used tooling to just let people work on master 
directly, or let dev1/2/3 be concrete as a temporary form for 
convenience, as I noted above.


Or in simpler terms, the model differences seem to boil down to this. 
Given N possible targets:


1) Master is concrete, dev1..M (where M possibly > N) are generated 
simply for ease of use either as concrete tree on disk or virtually in IDE


2) Master

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


Have fun.  :)

But to be clear, you'd be improving the source that makes bytecodes_8h?

geir


Leviev, Ilia A wrote:

Hi,
I volunteer for improving bytecodes_8h.html in my spare time. 
Objections?


Best regards,
Ilia Leviev
Intel Java & XML Engineering



-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: [drlvm] Is it time to say goodbye to dear friend GC v4?




Nikolay Kuznetsov wrote:

Let me answer for Artem :), he is on vacation and most probably won't
answer soon.
We do occasionally use GCv4 to verify some threading issues, since
native threading resource allocation depends on "weak references".
Thus I would agree with Ivan, that sometimes it is helpful to switch
to different code base(which is handy and considered to be stable
enough), but if gcv4 won't be supported any more why don't drop it
having in mind that one can always take older revisions from SVN.

+1 for dropping GCv4


From that argument, I'm now against dropping GCv4, if you actually get 
use out of it for verification of threading or other important issues.


Yes, you can always take older revisions, but that's a pain, and if that 
is a "speedbump" that prevents you from doing those extra tests or 
verifications, I'd rather keep it around as a convenience for you. :)


Seriously - if you need it, lets keep it.

geir



Nik.

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] more self-dependent VM tasks, newbies welcome




Egor Pasko wrote:

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

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


OK, my suggestion was to put links to JIRA tasks from the page:
http://wiki.apache.org/harmony/DRLVM%20newbie%20tasks

Now I think you all agree. So I did it.


:)

Only further thought - how do I get to this page?  Maybe I'm not seeing 
it.  From front page, there is the "TODO list" for DRLVM, but there's no 
link to the 'newbie" page.


Also, maybe organize these "newbie" tasks with the other tasks, but mark 
them as "easy" or such?


geir




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]
<mailto:[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]
<mailto:[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]
<mailto:[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()"

Re: Brush up Harmony pages




Konovalova, Svetlana wrote:

Alexey,

Thanks a lot applying the patch and appreciating the pages :)


But I got two concerns about Cruise control testing description page [1]:
1. It does not have it's own title. Now the title is: "Apache Harmony
- Apache Harmony". I suggest "Apache Harmony - Build-test framework".
If no one objects I'll change the title.


+1 (I've overlooked it, sorry about that)


In the first part it says that we need all the tools for normal
Harmony build but the it requires to install only small part of them.
I think that we should remove the short list and provide a link to the
page with the all needed software.


Why not? I'm for it. 
IMHO to avoid unnecessary repetition, we can just provide a link from this page to "QH for contributors"[2]. 
Any objections?


+1



I've created another patch that includes two issues mentioned above and one more cleaned-up page [3]. Please have a look (the same JIRA = Harmony-2062). 


Thanks in advance!
 
Best regards,

Sveta

[1]http://incubator.apache.org/harmony/subcomponents/buildtest/index.html
[2]http://incubator.apache.org/harmony/quickhelp_contributors.html
[3]http://incubator.apache.org/harmony/subcomponents/classlibrary/index.html  
 
-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 03, 2006 11:46 AM

To: harmony-dev@incubator.apache.org
Subject: Re: Brush up Harmony pages

Sveta,

I've applied your patch. It really makes the pages better looking. Thanks.

But I got two concerns about Cruise control testing description page [1]:
1. It does not have it's own title. Now the title is: "Apache Harmony
- Apache Harmony". I suggest "Apache Harmony - Build-test framework".
If no one objects I'll change the title.
2. Here is the "Prerequisites" chapter of the page:
=== cut ===
Basically, you need the same tools, as for building the Apache Harmony
components, like Java, Ant, C/C++ compilers, etc. Install the
following software:

1. Java JDK v5
2. Apache Ant
3. Subversion Client
Please see the other parts of the project for information on the
necessary toolchains.
=== cut ===
In the first part it says that we need all the tools for normal
Harmony build but the it requires to install only small part of them.

I think that we should remove the short list and provide a link to the
page with the all needed software.

Thoughts?

SY, Alexey

[1] http://incubator.apache.org/harmony/subcomponents/buildtest/index.html

2006/11/3, Konovalova, Svetlana <[EMAIL PROTECTED]>:

Folks,

To make the Harmony site nice-to-look, nice-to-read and easy-to-use, I've 
brushed up certain pages [1-5] and created a new issue (HARMONY-2062), the 
patch is available.

If you have time and desire, could you please look through these pages to check 
whether they are up-to-date or not.
I'd like to draw your attention to the "Framework for Testing Serialization" page [1], 
where the "Negative Testing" section is missing. Can anybody create the necessary content 
for it, please? ☺ or maybe we don't need it at all...
Your suggestions/ideas are very welcome.

[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
  [2]http://incubator.apache.org/harmony/subcomponents/buildtest/index.html
[3]http://incubator.apache.org/harmony/documentation/build_website.html
[4]http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html
[5]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html

Thanks in advance,

Best regards,
Svetlana Konovalova

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

Leo Li wrote:

They are the total test run times and I really feel that harmony launches
slower than RI. It is the most abvious difference not only from the above
result.
I have once tested the performance about net and the result ensures me that
harmony performances almost as good as RI although the test I run cannot be
said a formal performance test.:)

Nice work. Yes, I've noticed that we do launch slower than the RI. I 
figure that's an optimization somewhere down the road...

geir

On 11/3/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:

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: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass




Rana Dasgupta wrote:

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.



I closed 1109 and 1162, but I have a different problem with 1830 on 
linux - after 160 iterations or so of the test program, I get a 
j.n.SocketException - too many open files...


geir



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: [general] version of GCC...




Salikh Zakirov wrote:

Geir Magnusson Jr. wrote:

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


I think we didn't, and I doubt we ever could.


Of course we can.  We just say "version X -> Version y"


Still, it's not a problem if the committers can agree on it.
I have recollections of Gregory saying he will check on gcc 4.1.1.
Geir, what version do you use for checking?


3.4.6




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


I suspect it was my patch that doesn't compile under gcc 4.1.
I used to use SuSe 9 with gcc 3.3.3, but I will see if I can install a newer
version.

[general] version of GCC...


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

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

Re: [classlib] Preprocessor - CHECKPOINT




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 t

Re: [classlib] Preprocessor - CHECKPOINT

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.

Re: [classlib] Preprocessor - CHECKPOINT




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
addi

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




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?

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




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: [classlib] Preprocessor - CHECKPOINT




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




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 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: [general] Transition to TLP




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

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

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] 
<mailto:[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]
<mailto:[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]
<mailto:[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 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: [drlvm] more self-dependent VM tasks, newbies welcome




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 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] 
<mailto:[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]
<mailto:[EMAIL PROTECTED]>
 > <mailto:[EMAIL PROTECTED] <mailto:[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][jvmti][testing] I want to add JVMTI tests to drlvm commit checks




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




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] 
<mailto:[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

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




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




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

[general] Transition to TLP

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.


geir

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




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




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

Re: svn commit: r470310 - in /incubator/harmony/standard/site: README.txt docs/contributors.html xdocs/contributors.xml

Any chance you give your magic commit powers another spin and put the 
committer list in alphabetical order, by last name (a - zed) :)


geir

Oliver Deakin wrote:

Apologies for the lack of commit message - in the excitement
of adding myself to the list of committers I clicked "ok" a little
too soon ;)

I also corrected the site.vsl line number in the website readme.

Regards,
Oliver

[EMAIL PROTECTED] wrote:

Author: odeakin
Date: Thu Nov  2 02:16:26 2006
New Revision: 470310

URL: http://svn.apache.org/viewvc?view=rev&rev=470310
Log: (empty)

Modified:
incubator/harmony/standard/site/README.txt
incubator/harmony/standard/site/docs/contributors.html
incubator/harmony/standard/site/xdocs/contributors.xml

Modified: incubator/harmony/standard/site/README.txt
URL: 
http://svn.apache.org/viewvc/incubator/harmony/standard/site/README.txt?view=diff&rev=470310&r1=470309&r2=470310 

== 


--- incubator/harmony/standard/site/README.txt (original)
+++ incubator/harmony/standard/site/README.txt Thu Nov  2 02:16:26 2006
@@ -5,7 +5,7 @@
 
 1) **Temporarily** update the link to the CSS so you can

 preview the site in a local browser:
-1) Go to line 266 in file xdocs/stylesheets/site.vsl
+1) Go to line 250 in file xdocs/stylesheets/site.vsl
 2) Edit the path to site.css.  Specify an absolute path. 
e.g. from
 


Modified: incubator/harmony/standard/site/docs/contributors.html
URL: 
http://svn.apache.org/viewvc/incubator/harmony/standard/site/docs/contributors.html?view=diff&rev=470310&r1=470309&r2=470310 

== 


--- incubator/harmony/standard/site/docs/contributors.html (original)
+++ incubator/harmony/standard/site/docs/contributors.html Thu Nov  2 
02:16:26 2006

@@ -412,6 +412,20 @@
 A
 
 
+
+
++Oliver Deakin
+
+rowspan="" >

++IBM UK
+
+rowspan="" >

++A
+
+
 
 
 Status :

Modified: incubator/harmony/standard/site/xdocs/contributors.xml
URL: 
http://svn.apache.org/viewvc/incubator/harmony/standard/site/xdocs/contributors.xml?view=diff&rev=470310&r1=470309&r2=470310 

== 


--- incubator/harmony/standard/site/xdocs/contributors.xml (original)
+++ incubator/harmony/standard/site/xdocs/contributors.xml Thu Nov  2 
02:16:26 2006

@@ -34,6 +34,7 @@
 (Paulex)Pu YangIBM CNA
 Weldon WashburnIntelA
 Alexey PetrenkoIntelA
+Oliver DeakinIBM UKA

Re: [classlib] Really trivial comment about exception messages

I love working with the English.  "What is the colour of the 'zed' 
before the fullstop?"



Mark Hindess wrote:

While checking and applying some of Ilya's patches for
internationalisation, I noticed that there were quite a few messages
that end with a fullstop.  Aside from the inconsistency (which
unfortunately always seems to irritate me), it occurs to me that we will
end up with stack traces that read like:

  IllegalArgumentException: position less than zero. at blah(blah.java:101)

So, unless anyone objects, can we avoid putting fullstops on the end of
exception messages.

Thanks,
 Mark.

Re: [doc]Please help to remove outdated info from the site


Nice - buy why not put the tasks in JIRA?

Morozova, Nadezhda wrote:
Thanks all who helped with the "what can we do now" page - the new page is shorter but none the less useful. 
My suggestion is to add more links to the page. It now only links to the applist. More candidates: classlib status page [1], wiki drlvm todo items [2], website & doc development [3]. What do you think?


[1] http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html 
[2] http://wiki.apache.org/harmony/TODO_List_for_DRLVM 
[3] http://wiki.apache.org/harmony/Documentation_TODO 

Thank you, 
Nadya Morozova
 


-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 01, 2006 5:31 PM

To: harmony-dev@incubator.apache.org
Subject: [doc]Please help to remove outdated info from the site 


Folks,

You might know that certain Harmony pages are out-of-date and need to be modified. 
One of such pages is http://incubator.apache.org/harmony/status.html .

Now I'm working at creating the "Build our Own Website Using Ant" section for 
this very page.
Would be great, if someone can find a chance to look at it to help me through 
away outdated info.

Thanks in advance!

Best regards,
Sveta Konovalova

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


Put them in as JIRAs

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?

Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml


added perms for gregory, oliver, richard and alexei for svn and jira



Geir Magnusson Jr. wrote:
that's because you haven't been added to the svn perms.  I'll do that in 
a bit...


Gregory Shimansky wrote:

On Tuesday 31 October 2006 18:28 Tim Ellison wrote:

Hurray!

[EMAIL PROTECTED] wrote:

Author: apetrenko
Date: Tue Oct 31 06:57:44 2006
New Revision: 469512

URL: http://svn.apache.org/viewvc?view=rev&rev=469512
Log:
I've added myself to the list of committers.


Congrants to Alexey!

I've tried to do the same but apparently cannot. I got my login today, 
logged on people.apache.org and changed my password for subversion. So 
far both for standard and enhanced modules I get the same message


Sendingsite/docs/contributors.html
Authentication realm: <https://svn.apache.org:443> ASF Committers
Password for 'gshimansky':
svn: Commit failed (details follow):
svn: CHECKOUT of 
'/repos/asf/!svn/ver/470017/incubator/harmony/standard/site/docs/contributors.html': 
403 Forbidden (https://svn.apache.org)


I wonder if it is just a very unlucky day to try the first commit 
because of some more maintenance works done to infrastructure, or 
should I just be patient?


I tried on different machines from command line svn client, eclipse 
subclipse and kdesvn with the same result.

Re: [classlib] Preprocessor - CHECKPOINT

Cool.  Any Eclipse Plugin gurus here that could create a called in eclipse speak... perspective?> that has two edit panes, one 
with the code w the preproc directives in it, and one that is the result 
of the preproc given some defines?


geir


Nathan Beyer wrote:

I've read a few articles about J2ME development using Antenna, which
has a Java preprocessor task for Ant [1]. The Mobility Pack for
NetBeans includes a Java preprocessor, which it claims is
similar/based on Antenna [2].

I still feel a little dirty about the thought of preprocessing Java
source, but I guess it's done.

-Nathan

[1] http://antenna.sourceforge.net/#preprocess
[2] http://www.netbeans.org/kb/50/quickstart-mobility.html

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



Etienne Gagnon wrote:
> Geir Magnusson Jr. wrote:
>> There's caching too, I think.  LogCache4J
>>
>> What I meant was that it didn't seem like we came to a conclusion 
on it

>> - that if we had a general pre-processing solution, we could use that
>> too for logging, rather than have two.
>>
>> The actual use-cases will help figure this out.
>
> Here two typical some use cases, and some proposed solutions:
>
> Problem
> ---
> logging, and other situations where you really don't want to put the
> "additional" source code in the main source files
>
> Solution
> 
> use aspects  (Plug: you might want to give a look at the optimizing abc
> compiler)
>
>
> Problem
> ---
> supporting a different API specifications/versions, such as j2me and
> j2se1.4, in addition to the "main" version (e.g. j2se1.5)
>
>
> Solution
> 
>

Right - these were the main hypotheticals that started this whole thread
off - I was thinking more about a definite example, like a given class C
has a different implementation of method M in Java5 than in Java6.

Even if we walk through this with a clear example simple manual process,
it will be enlightening.

> This is a trickier problem.  We can divide the problem at two main 
levels:

>
> 1- file/directory level
> 2- source-code level
>
> At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
> might include additional files (relative to the main version), and 
might

> not include some files of the main version.  In other words, j2me might
> not contain database APIs.

Yep

>
> Managing file inclusion/exclusion can be done in various ways.
>
>  a) ant based:  use distinct ant (sub-)files for each version.
>
>The problem is that IDEs (e.g. Eclipse) will most likely show some
>of the excluded files in its class/files browser.  This wouldn't be
>very elegant.  It also implies "always" compiling through ant files.
>
>Of course, one could develop Eclipse-specific configuration files to
>mimic the inclusion/exclusion of ant files, but then, this opens the
>door for discrepancies between ant vs eclipse inclusion/exclusion
>lists.  I don't like it.
>

Me neither.

>  b) custom-tool based: the custom processing tool I proposed could also
>parse inclusion/exclusion lists, and use these lists to move files
>around, in addition to processing the content of unmoved files.

I'm not sure anything needs to be moved.

>
>For example, if class X of the main version is not part of j2me,
>"process(j2me)" would move this file to a subdirectory ".streams/".
>
>If a class Y is not in the "main" version (the one used for "svn
>ci"), it resides in subdirectory ".streams" in the trunk.
>"process(j2me)" moves this file into the normal directory.
>
>As for IDEs, now you can configure them to automatically exclude
>".stream/" directories.

This would get messy.  I'd rather just have a plug-in that reads a
description file for version X and just doesn't show me what isn't part
of version X.

>
>Inclusion/exclusion could be managed in two ways:
>1- the processing tool could look for inclusion/exclusion list 
files,

>   such as "j2me.inclusion, j2me.exclusion, main.inclusion,
>   main.exclusion, etc."
>
>   This would lead to the best performance (for process(X)), yet it
>   does require much manual update of inclusion/exclusion lists, 
with

>   all the discrepancies that result from human mistakes while
>   updating these files.
>
>2- (my preferred way), directives, at the beginning of the source
>   code would indicate whether a file is included in a version or
>   not.  Depending on target, the file would be moved to the
>   appropriate directory (normal, ".streams").

Eithe

Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml

that's because you haven't been added to the svn perms.  I'll do that in 
a bit...


Gregory Shimansky wrote:

On Tuesday 31 October 2006 18:28 Tim Ellison wrote:

Hurray!

[EMAIL PROTECTED] wrote:

Author: apetrenko
Date: Tue Oct 31 06:57:44 2006
New Revision: 469512

URL: http://svn.apache.org/viewvc?view=rev&rev=469512
Log:
I've added myself to the list of committers.


Congrants to Alexey!

I've tried to do the same but apparently cannot. I got my login today, logged 
on people.apache.org and changed my password for subversion. So far both for 
standard and enhanced modules I get the same message


Sendingsite/docs/contributors.html
Authentication realm:  ASF Committers
Password for 'gshimansky':
svn: Commit failed (details follow):
svn: CHECKOUT 
of '/repos/asf/!svn/ver/470017/incubator/harmony/standard/site/docs/contributors.html': 
403 Forbidden (https://svn.apache.org)


I wonder if it is just a very unlucky day to try the first commit because of 
some more maintenance works done to infrastructure, or should I just be 
patient?


I tried on different machines from command line svn client, eclipse subclipse 
and kdesvn with the same result.

Re: [classlib][portlib] Docs?

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.

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.

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: 235 tests are missed at DRLVM test run for Windows


:)

cool

Anton Luht wrote:

Hello,

Queue appeared to be a stack :) Both requests are implemented, others
are pending.

On 11/1/06, Anton Luht <[EMAIL PROTECTED]> wrote:

Feature requests from Geir (multiple select for tags) and Alexey
(shortcut to compare two runs from the first page) are accepted and
put in the implemetation queue.

Re: [doc] "EM" minor typos are corrected


done

Konovalova, Svetlana wrote:

Folks,

Some minor typos were discovered in the "Execution Manager Component 
Description". In cooperation with Mikhail Fursov we've created a couple of necessary 
patches [http://issues.apache.org/jira/browse/HARMONY-2036].
Would be great, if someone can find a chance to look at them and apply.

Thanks in advance.

Best regards,
Svetlana Konovalova

Re: [classlib]Harmony passes 100% testcases of Tomcat5.5


Yah, that was my point.  Glad to know it was already there.

geir


Paulex Yang wrote:

Tim Ellison wrote:

Geir Magnusson Jr. wrote:
 

Great!  Does anything link to that page?  IOW, if I started at the top,
could I find the page using some reasonable path to get there?




Front Page > Application Status (in the 'Status' section)

There are a number of apps listed there as people test them.
  
Yes, and I suggest we always add links to this page when somebody 
creates a wiki page for application test, a few days ago, I just added 
several links to it(IIRC, Eclipse, Tomcat, Log4j...), because I thought 
they should be there but couldn't find...

Regards,
Tim

Re: [doc]Please help to remove outdated info from the site


Given there's no info there, I think you are on the right track :)

geir

Konovalova, Svetlana wrote:

Folks,

You might know that certain Harmony pages are out-of-date and need to be modified. 
One of such pages is http://incubator.apache.org/harmony/status.html .

Now I'm working at creating the "Build our Own Website Using Ant" section for 
this very page.
Would be great, if someone can find a chance to look at it to help me through 
away outdated info.

Thanks in advance!

Best regards,
Sveta Konovalova

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


Why not use junit?

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




Etienne Gagnon wrote:

Mikhail Fursov wrote:

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

For comfortable IDE development, one could imagine that the IDE editor
can reduce to "one-line visible" comments (or better, specially
formatted ones) so that it gives you the impression that you are really
wearing target-specific spectacles.  [I know Eclipse allows for such
things already].
...

Etienne,
What is 'comfortable IDE development' if you can't modify the Y? Am I
missing something here?


Maybe my text was wrongly formatted...  You looked at the wrong example.
 Comfortable development happens only using "development targets".  E.g.

1- process(X, devtarget) -> Z

2- edit Z in IDE using comfortable development, where you see a single
   commented line for every hidden stream code chunk, keeping you aware
   that other streams have related code there [you click on the "+" in
   Eclipse if you want to see the complete chunk].  Of course, you
   should never delete a chunk without consulting other stream
   developers first.
   So:  edit Z -> Z'


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


  $ ant -Dtarget=java5

and  what pops out is the java5 classlib jars, natives, includes, etc 
for java5.  And would use the "version definition" metadata to choose 
the fileset, and then use process() to xform the code to the target sources.


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 think it's key that our solution can work in an IDE, not just on a 
command line.



geir

Re: [classlib] Preprocessor - CHECKPOINT




Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

There's caching too, I think.  LogCache4J

What I meant was that it didn't seem like we came to a conclusion on it
- that if we had a general pre-processing solution, we could use that
too for logging, rather than have two.

The actual use-cases will help figure this out.


Here two typical some use cases, and some proposed solutions:

Problem
---
logging, and other situations where you really don't want to put the
"additional" source code in the main source files

Solution

use aspects  (Plug: you might want to give a look at the optimizing abc
compiler)


Problem
---
supporting a different API specifications/versions, such as j2me and
j2se1.4, in addition to the "main" version (e.g. j2se1.5)


Solution




Right - these were the main hypotheticals that started this whole thread 
off - I was thinking more about a definite example, like a given class C 
has a different implementation of method M in Java5 than in Java6.


Even if we walk through this with a clear example simple manual process, 
it will be enlightening.



This is a trickier problem.  We can divide the problem at two main levels:

1- file/directory level
2- source-code level

At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
might include additional files (relative to the main version), and might
not include some files of the main version.  In other words, j2me might
not contain database APIs.


Yep



Managing file inclusion/exclusion can be done in various ways.

 a) ant based:  use distinct ant (sub-)files for each version.

   The problem is that IDEs (e.g. Eclipse) will most likely show some
   of the excluded files in its class/files browser.  This wouldn't be
   very elegant.  It also implies "always" compiling through ant files.

   Of course, one could develop Eclipse-specific configuration files to
   mimic the inclusion/exclusion of ant files, but then, this opens the
   door for discrepancies between ant vs eclipse inclusion/exclusion
   lists.  I don't like it.



Me neither.


 b) custom-tool based: the custom processing tool I proposed could also
   parse inclusion/exclusion lists, and use these lists to move files
   around, in addition to processing the content of unmoved files.


I'm not sure anything needs to be moved.



   For example, if class X of the main version is not part of j2me,
   "process(j2me)" would move this file to a subdirectory ".streams/".

   If a class Y is not in the "main" version (the one used for "svn
   ci"), it resides in subdirectory ".streams" in the trunk.
   "process(j2me)" moves this file into the normal directory.

   As for IDEs, now you can configure them to automatically exclude
   ".stream/" directories.


This would get messy.  I'd rather just have a plug-in that reads a 
description file for version X and just doesn't show me what isn't part 
of version X.




   Inclusion/exclusion could be managed in two ways:
   1- the processing tool could look for inclusion/exclusion list files,
  such as "j2me.inclusion, j2me.exclusion, main.inclusion,
  main.exclusion, etc."

  This would lead to the best performance (for process(X)), yet it
  does require much manual update of inclusion/exclusion lists, with
  all the discrepancies that result from human mistakes while
  updating these files.

   2- (my preferred way), directives, at the beginning of the source
  code would indicate whether a file is included in a version or
  not.  Depending on target, the file would be moved to the
  appropriate directory (normal, ".streams").


Either one - the nice thing about #1 over #2 is that you can actually 
look at it to get a summary.  But you can generate the same info w/ a 
tree walk, I suppose.





Of course, there's also the problem of non-source files, i.e.
resources.  IMO, resources could be managed using specific
directories (".main/", ".j2me", ".j2se1.4") and a ".shared/"
directory with symbolic links in the specific directories.



This is getting messy.



As for source-level management, you would use my proposed processing
tool to view the source files with the right spectacles [as Tim said so
elegantly:-)].  For "development targets", it is important that:

 revert(process(X, target)) => X

By "development target" I mean a target that is meant for Harmony
developers in prevision of reverting "modified code" to a format
suitable for "svn ci" (i.e. revert to "main" target).

For comfortable IDE development, one could imagine that the IDE editor
can reduce to "one-line visible" comments (or better, specially
formatted ones) so that it gives you the impression that you are rea

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


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

geir

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


yay!

Ivan Volosyuk wrote:

Hi All,

DRLVM now builds and run (interpreter mode) on IPF with HARMONY-2004.
The patch should cause no changes on other architectures.
Currently, in interpreter mode everything works fine but GC. GC fails.
I'm investigating this issue.

Re: [classlib][portlib] Docs?

yeah - someone generate, and we can hang them on the website.  I'm not 
sure we'd want to check them in though...

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: 235 tests are missed at DRLVM test run for Windows




Anton Luht wrote:

Alexei,


2. If I suggested an enhancement, this would be an addition of a test
name filter for comparison results. I mean that if I'm interested in
Bidi tests comparison, I put Bidi into form field (&name=Bidi) and see a
comparison for the tests which names contain the specified substring.


Feature request accepted :)


3. When I use "Open in a new window" for a list of tags, IE opens a copy
of the initial window. When I do a left click, there is no scroll bar at
the pop up window, and the list of tags doesn't fit the window.


Thanks, scrollbars were added.



Could the tags be in a  list instead of freely typed?  Let me select 
multiple?

Re: [general] Motorola to develop ME under ALv2




Geir Magnusson Jr. wrote:
This is about Motorola and their efforts in the ME ecosystem.  The 
Apache style of open governance has shown itself to be very successful 
in creating good software, although there are other models that are 
successful as well (Eclipse Foundation, MySQL).  So seeing Motorola 
embrace that, as well as our license - which gets rid of any license 
interop for whatever they do - is just a great step forward for the 
industry as a whole.


Back to SE... :)


I re-read this, and I didn't come across right here.   It sounds like 
I'm trying to change the subject - I'm not.   This is a great thing - as 
we all think that the Apache Way (whatever that is) is the bees knees so 
more of it is better.


I don't mean "stop talking" - we can talk about whatever we want.  What 
I meant was "I'm going back to all the stuff I want to do on SE... " :)


geir




geir


Tim Ellison wrote:

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" ?


You can see the same statement as me, so it would only be speculation to
talk about 'what Motorola want' beyond what they have said already.

The cool part is that by choosing ALv2 Harmony can freely engage and
exchange with their effort.

Regards,
Tim

Re: [classlib]Harmony passes 100% testcases of Tomcat5.5

Great!  Does anything link to that page?  IOW, if I started at the top, 
could I find the page using some reasonable path to get there?


geir

Leo Li wrote:

 Yes, I have posted it on http://wiki.apache.org/harmony/Apache_Tomcat.:)

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


Nice!  Post it on the wiki?

Leo Li wrote:
 > Hi, all:
 >  Harmony now has been able to pass 100% testcases on
Tomcat5.5. I ran
 > them both on WindowsXP and Unbuntu, with J9 VM and drlvm.
 >  The detailed information about how to build and run tests
have been
 > put on http://wiki.apache.org/harmony/Apache_Tomcat.
 >
 > Note:
 >  1. Harmony launches slower than RI, so I add the interval
between the
 > launch of Tomcat Server and  tests from 8 seconds to 30 seconds
to ensure
 > the server has been running.
 >  2. Runtime.exec fails on linux with J9 vm, as discussed
on[1], so I
 > have altered the usage of fork to vfork as a workround despite of the
 > possible side-effect of the latter.
 > mailing thread
 > [1]
 >
http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html




--
Leo Li
China Software Development Lab, IBM

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




Xiao-Feng Li wrote:

Hi, I am using port_CPUs_number() for GCv5 to get the processor
number, but my desktop returns one processor with it on Windows
although my processor is dual-core. (port_CPUs_number is defined in
port_sysinfo.h).

I think we need more general form of processor number retrieval API
that can return processor information including that of core and
hyperthreading.

How do you think?


I chuckled when I first read this, as if people would disagree - "no, I 
don't think we want to have an API to return accurate information about 
hardware capability".


One thing to keep in mind is to ensure that it's extensible so that 
non-intel features can be detected as well.  Easy portability is key.


geir

Re: [drlvm][iprof] Using Profiling Utility ("iprof")

Is this tuff documented?  Wanna throw it in the wiki or a patch for the 
site?


Egor Pasko wrote:

On the 0x214 day of Apache Harmony Mikhail Fursov wrote:

+ Some usage hints:
1. You can get any stylesheet editor (like Excel), open iprof data and build
graphs from the  colums - and you will have very useful pictures.


gnuplot :)


2. The disadvantage of iprof is that it counts blocks, insts and helpers
calls and does not count time spent in helpers and blocks. You still need
VTune to get this info.


1 more disadvantage: counters are not synchronized resulting in
somewhat inaccurate data for multithreaded apps

Re: [classlib] Preprocessor - CHECKPOINT




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Nathan Beyer wrote:

What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like "externals" for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's pulled into 'enhanced' on
checkout). 

Even the authors of SVN warn people away from using externals.


Yeah, and a nightmare when trying to 'tag' code -- copying the link to
HEAD is no help.


I would propose we at least attempt to go down a path of
investigating a branching.

We should consider everything, but I'd personally rather keep as few
codelines as possible.


Agreed.


Regardless, I think we need to settle on our exact requirement first,
before spending too much time on looking for a solution. For example,
if logging is a real requirement, but everyone agrees it can be done
via instrumentation (AspectJ, java.lang.instrument, etc), then are
there any other requirements that affect the actual source files
internally? If not, then could all of the other requirements be
fulfilled by judicious SCM use?

So, I would suggest we back up a little and just layout all of the
requirements first, so we can make sure everyone's in agreement about
the needs.


Nathan is right -- this is hypothetical now, unless (for example) we
start on Java 6 development now.


Exactly - we need use cases (and it's not clear that the logging
problems have been resolved w/ aspects yet...)


You're joking, right?  I tease the aspect people that logging is the
only problem that has been solved(*) .  There are lots of references
on how to do that, eg:
  http://www.developer.com/java/other/article.php/3109831


There's caching too, I think.  LogCache4J

What I meant was that it didn't seem like we came to a conclusion on it 
- that if we had a general pre-processing solution, we could use that 
too for logging, rather than have two.


The actual use-cases will help figure this out.

geir





(*) it's not true though, there are a number of tasks that are
well-suited to using aspects.  However, I would use them judiciously.


Like caching :)  (And get your local psychic retainer to tell you what 
the code is doing... ;)



geir



Regards,
Tim

Re: [drlvm] How to debug the drlvm with gdb?

Mikhail Fursov wrote:

Thanks Rana!
If you ask me what would I like, the answer is quite simple: as a windows
developer primary (today) I would recommend to other windows developers to
use msvc build (with patch from
HARMONY-1990
).
With this patch you can almost forget about build.bat (it used only to 
fetch

external components + build Java). Most of the internal components
(vmcore,JIT,interpreter,gc_cc,encoder,em,hythread,jthread..) could be built
and debugged from within MSVC much faster than with build.bat without any
code modification with printf(..) and int3-like breakpoints.

I'll add this information to the site after H1990 is commited.

Done - please check.  I just committed.

geir

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

I created a basic debugging  page for debugging with the VS debugger on
windows.
Mikhail and others, make whatever changes you like :-)

Rana

On 10/24/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> On 24 Oct 2006 22:42:22 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >
> > > - Debugging on Windows - Mikhail has been recommended; how's that?
> >
> > the tip from Rana is also useful there. Who can start the page?
> > Mikhail? Rana?
> >
>
> I'll do it right after I finish the current task. I do not mind if
> somebody
> will pass ahead. This is just the question of tasks priorities.
>
> --
> Mikhail Fursov
>
>

Re: [general] Motorola to develop ME under ALv2

This is about Motorola and their efforts in the ME ecosystem.  The 
Apache style of open governance has shown itself to be very successful 
in creating good software, although there are other models that are 
successful as well (Eclipse Foundation, MySQL).  So seeing Motorola 
embrace that, as well as our license - which gets rid of any license 
interop for whatever they do - is just a great step forward for the 
industry as a whole.


Back to SE... :)

geir


Tim Ellison wrote:

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" ?


You can see the same statement as me, so it would only be speculation to
talk about 'what Motorola want' beyond what they have said already.

The cool part is that by choosing ALv2 Harmony can freely engage and
exchange with their effort.

Regards,
Tim

Re: [classlib]Harmony passes 100% testcases of Tomcat5.5


Nice!  Post it on the wiki?

Leo Li wrote:

Hi, all:
 Harmony now has been able to pass 100% testcases on Tomcat5.5. I ran
them both on WindowsXP and Unbuntu, with J9 VM and drlvm.
 The detailed information about how to build and run tests have been
put on http://wiki.apache.org/harmony/Apache_Tomcat.

Note:
 1. Harmony launches slower than RI, so I add the interval between the
launch of Tomcat Server and  tests from 8 seconds to 30 seconds to ensure
the server has been running.
 2. Runtime.exec fails on linux with J9 vm, as discussed on[1], so I
have altered the usage of fork to vfork as a workround despite of the
possible side-effect of the latter.
mailing thread
[1]
http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg16002.html

Re: [classlib] Preprocessor - CHECKPOINT




Etienne Gagnon wrote:

Tim Ellison wrote:

IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments.  It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.


Hmmm...  It's always possible to have a special output mode that puts
empty (or advertizing, hehe) comments, instead of other stream code
(thus, preserving line numbers).

To continue on my earlier example:

Java source => "j2se end-developer"
---


...

//  Download Harmony[tm] from
//
//  http://the.nice.harmony.url/download
//
//  :-)

  @Processor(Not in j2me!)
  int some_field =
some +
  initializing()
code;

...


Or, more likely:

Java source => "j2se end-developer"
---


...

//  Please  ignore this comment.  It has been
//  intentionally left here to preserve line numbers
//  for bug reporting purpose.
//
//  Please report bugs to http://bugs.of.harmony.url/...

  @Processor(Not in j2me!)
  int some_field =
some +
  initializing()
code;

...


So, J2ME & J2SE end-developers are kept happy.


I'm still not quite getting the importance of preserving the line 
numbers like that if we have some minimal tooling to let us work with it 
in eclipse or IDEA invisibly  users would report bug at line X, and 
we'd either look at the transformed code that they are actually using, 
and translate backwards, or have a plugin that lets us "A/B" between 
transformed and original.


The key is to play with some examples, I guess.



As a bonu$, you can al$o $tart a nice busine$$ $elling advertizing $pace
in $ource code.  ;-P


It's our idea - you run with it.  let us know how that works out.  (I 
bet if you could convince some investor that it was a web2.0 thing, you 
could get it funded)





Etienne

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Nathan Beyer wrote:

I don't know too much about ME profiles, but my opinion would be to
start by treating the target platform as a full Java SE port and then
look to add optional ME modules to the classlib. For example, port
DRLVM to Windows Mobile on Xscale or ARM.

Good lord man, bite your tongue! :)

I've worked a little bit with IBM's WebSphere Micro Environment and it
runs on the ME-type devices, like Windows Mobile, but it also runs on
Windows XP/2003. Obviously this is the opposite scenario, but the
concept is sharing the same VM with a subset class library

As for logging -- I agree with Tim, just don't do it. If we really
want logging, then just use AspectJ or the like. AspectJ can do
compile or runtime injection with the same aspects; at least it used
to a few years ago.

I think we've all agreed a long time ago that we're not going to have 
logging in production code.  The point here is to find a harmless way of 
letting people do it if they want to for classlib development ...

geir

-Nathan

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

Mikhail Fursov wrote:
>
>
> On 10/31/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> I guess that if we could get 5.0 complete, we'd could *then* 
branch for

> 6, but I don't think we'd want to serialize like that.
>
>
> I understand the dilemma. If we agree to have 1 stable, 1 'future' 
and N

> suspended (old) branches as a rule we finally will tune our process and
> will have almost no overhead to propagate changes from one branch to
> another. The hell is when you do not have any stable schema and create
> long living branches without reasons.
>
> The success of preprocessor's idea is also heavily depends how will we
> use it.
> For example, what about "old versions"? Should we someday move the code
> into separate branch or collect N-years old versions in the same 
source?

Yes, I assume that we'd branch and park 5 at some point, putting it into
maintenance, and then just if there is a bug, deal with them on case by
case back into main tree.

But that's just version of SE mainline. There also is The Logging Topic
That Will Not Die, as well as capabilities and profiles for ME (if
someone wanted to do so), but I know almost zero about how that works in
real life.

geir

>
>
>
> --
> Mikhail Fursov

Re: [general] creation of "jdktools"




Nathan Beyer wrote:

On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote:


On 31 October 2006 at 7:24, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
>
> Alexei Zakharov wrote:
> > Take me for example. I will be most likely misleaded with "build"
> > since the majority of projects I've seen in my life were using 
"build"

> > or "build." for  storing build artifacts (as Mark said). I
> > agree it is logically to call it "build". But "make" is logical too.
> > "ant" or "ant.scripts"  also sound not so bad. Why not to choose the
> > less confusing name?
>
> (I believe you meant "make" or "make.")
>
> What projects?  Java projects?

?

Apache Jakarta Commons Collections uses build/classes and build/tests
for artifacts... just like classlib does.

-Mark.


Every project that uses Maven 2 (including the Maven projects
themselves) use "target" as the general output directory,
"target/classes" as the compiled output (class files and resources)
and "target/test-classes" as the compiled test output (class files and
resources). The build instructions (script) is just placed in the root
of the project.

This is the default behavior of an minimally configured Maven 2
project, which is supposedly based on the ASF best practices. If we're
trying to converge on a common structure, I'd suggest following the
conventions of the Maven 2 system.


As you noted, the maven 2 approach came from best practices, not the 
other way around.


I felt that needed to be restated ;)

geir




-Nathan




> >
> > With best regards,
> >
> > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >> Why?  I'm really curious about this.  We "build" the project, 
using the

> >> "build.xml" file with Ant.
> >>
> >>
> >> Ilya Neverov wrote:
> >> > I would prefer to keep the current name "make" for directories 
related

> >> > to build system. For me it looks natural; at least it looks less
> >> > misleading than "build" :)
> >> >
> >> > -Ilya
> >> >
> >> > On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." 
<[EMAIL PROTECTED]>

> >> wrote:
> >> >> >
> >> >> > Ilya Neverov wrote:
> >> >> > > Hello,
> >> >> > >
> >> >> > > I want to gather opinions about structure of the "jdktools"
> >> >> component.
> >> >> > >
> >> >> > > I'm going to create scripts for moving tools' sources from
> >> classlib/
> >> >> > > to top-level directory jdktools/ and to prepare patches 
for build

> >> >> > > system for building tools from new place.
> >> >> >
> >> >> > Cool
> >> >> >
> >> >> > >
> >> >> > > I think the following structure will be appropriate for 
future

> >> >> > > evolution of the jdktools:
> >> >> > >
> >> >> > > jdktools/trunk/
> >> >> > >   build.xml
> >> >> > >   make/
> >> >> >
> >> >> > Can we stop persisting this mistake?  Please call it "build" :)
> >> >>
> >> >> And call 'build' something else like 'target'?
> >> >>
> >> >> I'm not actually sure calling it build is a good idea because 
a number
> >> >> of common projects use build to contain built artifacts.  What 
is your

> >> >> objection to 'make'?
> >> >>
> >> >> > >   doc/
> >> >> > >   modules/
> >> >> > >   jre/ #  keytool, tool 
launcher go

> >> here
> >> >> > >  build.xml #  classes go to
> >> >> jdk/jre/lib/tools.jar
> >> >> > >  make/
> >> >> > >  src/
> >> >> > >   jdk/ #  javac, jarsigner go 
here

> >> >> > >  build.xml #  classes go to
> >> jdk/lib/tools.jar
> >> >> > >  make/

Re: [classlib] Preprocessor - CHECKPOINT




Nathan Beyer wrote:

What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like "externals" for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's pulled into 'enhanced' on
checkout). 


Even the authors of SVN warn people away from using externals.


I would propose we at least attempt to go down a path of
investigating a branching.


We should consider everything, but I'd personally rather keep as few 
codelines as possible.




Regardless, I think we need to settle on our exact requirement first,
before spending too much time on looking for a solution. For example,
if logging is a real requirement, but everyone agrees it can be done
via instrumentation (AspectJ, java.lang.instrument, etc), then are
there any other requirements that affect the actual source files
internally? If not, then could all of the other requirements be
fulfilled by judicious SCM use?

So, I would suggest we back up a little and just layout all of the
requirements first, so we can make sure everyone's in agreement about
the needs.


Exactly - we need use cases (and it's not clear that the logging 
problems have been resolved w/ aspects yet...)


geir



-Nathan

On 10/31/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

Re: 235 tests are missed at DRLVM test run for Windows




Tim Ellison wrote:

Fedotov, Alexei A wrote:

4. I vote for one of the following renamings:
a) Rename ibm tag to j9
	b) Rename drl tag to intel :-). 


That looks like a strange suggestion to me.  I think the tags are fine
as they are.  What is you thinking?


Indeed...  DRL is Apache Harmony.  J9 is IBM's (maybe they'll donate it 
if we ask really nicely :)


geir

Re: [classlib] Preprocessor




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Tim Ellison wrote:

Right, but you (Mr Harmony developer) don't modify the 'processed code',
you work in the 'code w/ preprocessor statements', so you probably want
the code you are modifying to be real, compilable Java code too.

Agreed, but I was thinking though about "Mrs Java developer"


Yep, she works with the post-processed source.  Then we have the 'Men
are from Mars, ...' conversation about "the bug on line 42" ;-)


However, assuming you want the code you modify to be basically Java, you
might as well make it real Java.  It then makes sense for it to be valid
as Big Java (SE), and existing editors can be used on it without the
preprocessor as a poor-man's Harmony IDE.

Agreed this is ideal.  So what are the options?


We spoke of them already: annotations, structured comments, look-aside
tables, etc.  Pick your poison.


You sound like we came to an actual conclusion with any of these. 
Anything concrete to suggest?


geir

Re: [admin] ICLA / ACQ (Was: [drlvm][sablevm] Desing of Class Unloading Support)


ICLA should be faxed to the number on the document  ASQ can be sent scanned

Etienne Gagnon wrote:

Geir Magnusson Jr. wrote:

However, it would be great if you had an ICLA and ACQ on file to save
you the trouble of typing this in the future :)  "Better living through
paperwork!"


OK; I should have made this a while ago...  Can they be submitted by
email (where?) as "scanned" documents in PDF format?  This is usually
accepted here as much as Fax documents.  [Much better quality, actually!]

Etienne

Re: [build] Building on Eclipse - FYI

thanks for volunteering.  The only thing I'm concerned about is that you 
get the input from others about general project documentation "vision", 
rather than just re-doing things.


You're doing a good job of it out here on the -dev list.

geir


Konovalova, Svetlana wrote:

Geir,

I've checked a brief webcast for those who want to see a step-by-step
guide to configuring Eclipse, and it seems to be up-to-date.
But we still have food for thought: "Getting Started with DRLVM" is
outdated, and "Working with Classlib in Eclipse" seems misplaced. 
The first doc needs an update (see Nadya's mail: Mon 10/30/2006 6:53

PM), and can be abridged to reduce purely eclipse-oriented content. We
can reference Eclipse docs instead
[http://help.eclipse.org/help32/index.jsp]. And the second doc has been
updated (see HARMONY-2009), but only related to classlib. 
Many of the things are pretty generic, and with minimal edits can be fit

for vm as well. I suggest that we move this doc up to make it more
visible and edit it so as to apply to the whole project, rather than to
classlib only. IMHO the "Project Documentation" section is a good place
for this doc
[http://incubator.apache.org/harmony/documentation/documentation.html].

What do you say?

If you do not mind, I can try to update the doc.
 
Best regards,

Svetlana

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 31, 2006 2:18 PM

To: harmony-dev@incubator.apache.org
Subject: Re: [build] Building on Eclipse - FYI



Konovalova, Svetlana wrote:

Nadya,

AFAIU the given page is purely classlib-oriented...though I might be
wrong here. 
It provides info on how to set up Eclipse to develop Java code in

Harmony and IMHO doesn't include any tips applying to harmony code in
general.
I absolutely agree with you that we should have one page describing

how

to work with harmony code in Eclipse. It goes without saying that we
need to update info and the help from engineers' side is of great
importance here. You might know that there is a brief webcast for

those

who want to see a step-by-step guide to configuring Eclipse. On the

one

hand, it's great, but on the other hand, many screenshots can quickly
become outdated. IMHO it's rather complicated to update the video.

What

would you say? Should we keep it as it is?


Is it actually out of date?



Cheers,
Sveta

-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 30, 2006 6:45 PM

To: harmony-dev@incubator.apache.org
Subject: RE: [build] Building on Eclipse - FYI

Sveta,
I've taken a brief look at the patch, and I like most of your
corrections. The page looks neater this way, and holds important data.

One question: can't we say that some of the tips given on the page

apply

to harmony code in general, not just classlib? So a side idea would be
to have one page: how to work with harmony code in Eclipse. What do

you
say? 

Thank you, 
Nadya Morozova
 


-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 30, 2006 6:23 PM

To: harmony-dev@incubator.apache.org
Subject: RE: [build] Building on Eclipse - FYI

Sian,

Taking into consideration your comments, I've opened a new JIRA issue
[http://issues.apache.org/jira/browse/HARMONY-2009] and have created a
patch for the page "Developing Apache Harmony Class-library Code with
Eclipse". Would be great, if you find a chance to look it through. 
Hope we'll continue working at developing this aspect of

documentation.

:)

Cheers,
Sveta

-Original Message-
From: Sian January [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 27, 2006 3:34 PM

To: harmony-dev@incubator.apache.org
Subject: Re: [build] Building on Eclipse - FYI

Hi Sveta,

That sounds like a great idea.  I think the two main things you need

to

do
extra on Eclipse on Windows are as follows:

1. Make a copy of vsvars32.bat from your Visual Studio install
directory.
If you have chosen the defaults when installing you will find it in
"C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools".
Copy it
to somewhere convenient such as the desktop and add the following line
(just
below the last line that begins "@set..."):
start C:\...\eclipse\eclipse.exe -vmargs -Xmx512M
(where ... is the path to your eclipse installation).  NB. using
"-vmargs
-Xmx512M" is optional, but helpful to stop Eclipse running out of
memory.
Now just double click on this file to start Eclipse.

2. After you have started Eclipse and checked out Harmony from SVN,

copy

ecj_3.2.jar into ..\eclipse\plugins\org.apache.ant_1.6.5\lib and

change

the
Ant settings to include this jar (Window > Preferences > Ant > Runtime
then
select 'Global Entries' then 'Add External Jars' and add ecj_3.2.jar
from
the org.apache.ant_1.6.5\lib

Re: [classlib] Preprocessor




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Tim Ellison wrote:

Mikhail Fursov wrote:

Yes, the main reason I love Java is a power of tools! If you force me to
work in notepad instead of IDEA with the only reason that we need a
preprocessor I will have a doubt if the solution is reasonable.

Agreed. And that is a reason why it makes sense to have the original
source code compilable (as Etienne raised) -- so basic Java tooling can
still work on the original code even when there are no pre-processor
helpers around (though of course that would be more painful for the
developer).


But I'm confused here - I thought we talked about

   code w/ preprocessor statements -> processed code -> jar

as three separate steps, so the code would be able to work with basic
java tooling if you assembled a src.jar from the processed code.


Right, but you (Mr Harmony developer) don't modify the 'processed code',
you work in the 'code w/ preprocessor statements', so you probably want
the code you are modifying to be real, compilable Java code too.



Agreed, but I was thinking though about "Mrs Java developer"


It doesn't have to be that way of course.  If you were really nuts you
could invent your own crazy language that was pre-processed into Java
source (any analogy with early C++ preprocessors and ANSI C is purely
coincidental).


No thanks :)



However, assuming you want the code you modify to be basically Java, you
might as well make it real Java.  It then makes sense for it to be valid
as Big Java (SE), and existing editors can be used on it without the
preprocessor as a poor-man's Harmony IDE.


Agreed this is ideal.  So what are the options?

geir



Regards,
Tim

Re: [general] creation of "jdktools"


it's "build" in DRLVM, and "make" (invoked by the build.xml) in classlib.

It wouldn't be inconsistent.

geir


Ilya Neverov wrote:

My perception of 'make' and 'build' names is similar to what Alexei
described. I believe that for most people 'make' is a thing related to
making/building process while 'build' is more ambiguous.

Currently we have build system with many 'make/' dirs so it probably
bettre to postpone the move to new name to some moment of
restructuring the whole build system. I think today it's better to
keep consistency.

Thanks
-Ilya

On 10/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I see.  I'm familiar with "target" as the place for stuff that's 
created...


Alexei Zakharov wrote:
> In other words: I just wanted to say that the big number of java
> projects I've been working with was using "build[.]" as a
> place for storing generated stuff like .class and .jar files,
> generated docs and etc.
>
> Regards,
>
> 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>>
>>
>> Alexei Zakharov wrote:
>> > Take me for example. I will be most likely misleaded with "build"
>> > since the majority of projects I've seen in my life were using 
"build"

>> > or "build." for  storing build artifacts (as Mark said). I
>> > agree it is logically to call it "build". But "make" is logical too.
>> > "ant" or "ant.scripts"  also sound not so bad. Why not to choose the
>> > less confusing name?
>>
>> (I believe you meant "make" or "make.")
>>
>> What projects?  Java projects?
>>
>> >
>> > With best regards,
>> >
>> > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>> >> Why?  I'm really curious about this.  We "build" the project, using
>> the
>> >> "build.xml" file with Ant.
>> >>
>> >>
>> >> Ilya Neverov wrote:
>> >> > I would prefer to keep the current name "make" for directories
>> related
>> >> > to build system. For me it looks natural; at least it looks less
>> >> > misleading than "build" :)
>> >> >
>> >> > -Ilya
>> >> >
>> >> > On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." 
<[EMAIL PROTECTED]>

>> >> wrote:
>> >> >> >
>> >> >> > Ilya Neverov wrote:
>> >> >> > > Hello,
>> >> >> > >
>> >> >> > > I want to gather opinions about structure of the "jdktools"
>> >> >> component.
>> >> >> > >
>> >> >> > > I'm going to create scripts for moving tools' sources from
>> >> classlib/
>> >> >> > > to top-level directory jdktools/ and to prepare patches for
>> build
>> >> >> > > system for building tools from new place.
>> >> >> >
>> >> >> > Cool
>> >> >> >
>> >> >> > >
>> >> >> > > I think the following structure will be appropriate for 
future

>> >> >> > > evolution of the jdktools:
>> >> >> > >
>> >> >> > > jdktools/trunk/
>> >> >> > >   build.xml
>> >> >> > >   make/
>> >> >> >
>> >> >> > Can we stop persisting this mistake?  Please call it 
"build" :)

>> >> >>
>> >> >> And call 'build' something else like 'target'?
>> >> >>
>> >> >> I'm not actually sure calling it build is a good idea because a
>> number
>> >> >> of common projects use build to contain built artifacts.  What
>> is your
>> >> >> objection to 'make'?
>> >> >>
>> >> >> > >   doc/
>> >> >> > >   modules/
>> >> >> > >   jre/ #  keytool, tool 
launcher go

>> >> here
>> >> >> > >  build.xml #  classes go to
>> >> >> jdk/jre/lib/tools.jar
>> >>

Re: [general] creation of "jdktools"


I see.  I'm familiar with "target" as the place for stuff that's created...

Alexei Zakharov wrote:

In other words: I just wanted to say that the big number of java
projects I've been working with was using "build[.]" as a
place for storing generated stuff like .class and .jar files,
generated docs and etc.

Regards,

2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:



Alexei Zakharov wrote:
> Take me for example. I will be most likely misleaded with "build"
> since the majority of projects I've seen in my life were using "build"
> or "build." for  storing build artifacts (as Mark said). I
> agree it is logically to call it "build". But "make" is logical too.
> "ant" or "ant.scripts"  also sound not so bad. Why not to choose the
> less confusing name?

(I believe you meant "make" or "make.")

What projects?  Java projects?

>
> With best regards,
>
> 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>> Why?  I'm really curious about this.  We "build" the project, using 
the

>> "build.xml" file with Ant.
>>
>>
>> Ilya Neverov wrote:
>> > I would prefer to keep the current name "make" for directories 
related

>> > to build system. For me it looks natural; at least it looks less
>> > misleading than "build" :)
>> >
>> > -Ilya
>> >
>> > On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>> >>
>> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]>
>> wrote:
>> >> >
>> >> > Ilya Neverov wrote:
>> >> > > Hello,
>> >> > >
>> >> > > I want to gather opinions about structure of the "jdktools"
>> >> component.
>> >> > >
>> >> > > I'm going to create scripts for moving tools' sources from
>> classlib/
>> >> > > to top-level directory jdktools/ and to prepare patches for 
build

>> >> > > system for building tools from new place.
>> >> >
>> >> > Cool
>> >> >
>> >> > >
>> >> > > I think the following structure will be appropriate for future
>> >> > > evolution of the jdktools:
>> >> > >
>> >> > > jdktools/trunk/
>> >> > >   build.xml
>> >> > >   make/
>> >> >
>> >> > Can we stop persisting this mistake?  Please call it "build" :)
>> >>
>> >> And call 'build' something else like 'target'?
>> >>
>> >> I'm not actually sure calling it build is a good idea because a 
number
>> >> of common projects use build to contain built artifacts.  What 
is your

>> >> objection to 'make'?
>> >>
>> >> > >   doc/
>> >> > >   modules/
>> >> > >   jre/ #  keytool, tool launcher go
>> here
>> >> > >  build.xml #  classes go to
>> >> jdk/jre/lib/tools.jar
>> >> > >  make/
>> >> > >  src/
>> >> > >   jdk/ #  javac, jarsigner go here
>> >> > >  build.xml #  classes go to
>> jdk/lib/tools.jar
>> >> > >  make/
>> >> > >  src/
>> >> > >   jdwp/#  separate module for large
>> >> component
>> >> > >  build.xml
>> >> > >  make/
>> >> > >  src/
>> >> >
>> >> > Only comment is that we might want to pull the launcher out to 
be a

>> >> > peer.  Otherwise, I like it.
>> >>
>> >> I'd be a little tempted by that idea too.
>> >>
>> >> > >
>> >> > > Assumptions which look reasonable for jdktool's build 
subsystem:

>> >> > >
>> >> > > 1) it works in presence of built classlib (as HDK binaries 
or as a

>> >> > > result of classlib phase of overall build);
>> >> >
>> >> > yes - think of the same trick

Re: [classlib] Preprocessor - CHECKPOINT


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

Re: [classlib] Preprocessor




Mikhail Fursov wrote:

On 10/31/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


You can have pointcuts on a whole number of events, including method
invocations but also exception handling, field assignments and accesses,
etc.  But you can only add behavior, you cannot subtract from the
original code.



Thanks for your explanation. I completely forgot it because I played with
AspectJ several years ago when was a student and was interested in theory
more then in practice :)
So AspectJ could be a good candidate for logging/tracing/profiling tool, 
but

is not able to do what we expect from a preprocessor.


Right.

Re: [classlib] Preprocessor




Tim Ellison wrote:

Mikhail Fursov wrote:

Yes, the main reason I love Java is a power of tools! If you force me to
work in notepad instead of IDEA with the only reason that we need a
preprocessor I will have a doubt if the solution is reasonable.


Agreed. And that is a reason why it makes sense to have the original
source code compilable (as Etienne raised) -- so basic Java tooling can
still work on the original code even when there are no pre-processor
helpers around (though of course that would be more painful for the
developer).



But I'm confused here - I thought we talked about

   code w/ preprocessor statements -> processed code -> jar

as three separate steps, so the code would be able to work with basic 
java tooling if you assembled a src.jar from the processed code.




BTW I see from the discussion that AspectJ is considered as possible
solution. I'm not a guru in this extension of Java and AFAIK it 
allows only to add method-entry/exits code. You can't add logging

into the middle of the method. You can't change the method behaviour
with it. So the question is: what an improvement we will have with
AspectJ?


You can have pointcuts on a whole number of events, including method
invocations but also exception handling, field assignments and accesses,
etc.  But you can only add behavior, you cannot subtract from the
original code.

Regards,
Tim

Re: [general] creation of "jdktools"




Alexei Zakharov wrote:

Take me for example. I will be most likely misleaded with "build"
since the majority of projects I've seen in my life were using "build"
or "build." for  storing build artifacts (as Mark said). I
agree it is logically to call it "build". But "make" is logical too.
"ant" or "ant.scripts"  also sound not so bad. Why not to choose the
less confusing name?


(I believe you meant "make" or "make.")

What projects?  Java projects?



With best regards,

2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:

Why?  I'm really curious about this.  We "build" the project, using the
"build.xml" file with Ant.


Ilya Neverov wrote:
> I would prefer to keep the current name "make" for directories related
> to build system. For me it looks natural; at least it looks less
> misleading than "build" :)
>
> -Ilya
>
> On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>>
>> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> 
wrote:

>> >
>> > Ilya Neverov wrote:
>> > > Hello,
>> > >
>> > > I want to gather opinions about structure of the "jdktools"
>> component.
>> > >
>> > > I'm going to create scripts for moving tools' sources from 
classlib/

>> > > to top-level directory jdktools/ and to prepare patches for build
>> > > system for building tools from new place.
>> >
>> > Cool
>> >
>> > >
>> > > I think the following structure will be appropriate for future
>> > > evolution of the jdktools:
>> > >
>> > > jdktools/trunk/
>> > >   build.xml
>> > >   make/
>> >
>> > Can we stop persisting this mistake?  Please call it "build" :)
>>
>> And call 'build' something else like 'target'?
>>
>> I'm not actually sure calling it build is a good idea because a number
>> of common projects use build to contain built artifacts.  What is your
>> objection to 'make'?
>>
>> > >   doc/
>> > >   modules/
>> > >   jre/ #  keytool, tool launcher go 
here

>> > >  build.xml #  classes go to
>> jdk/jre/lib/tools.jar
>> > >  make/
>> > >  src/
>> > >   jdk/ #  javac, jarsigner go here
>> > >  build.xml #  classes go to 
jdk/lib/tools.jar

>> > >  make/
>> > >  src/
>> > >   jdwp/#  separate module for large
>> component
>> > >  build.xml
>> > >  make/
>> > >  src/
>> >
>> > Only comment is that we might want to pull the launcher out to be a
>> > peer.  Otherwise, I like it.
>>
>> I'd be a little tempted by that idea too.
>>
>> > >
>> > > Assumptions which look reasonable for jdktool's build subsystem:
>> > >
>> > > 1) it works in presence of built classlib (as HDK binaries or as a
>> > > result of classlib phase of overall build);
>> >
>> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
>> it.
>> >   I'd imagine the federated build to then have :
>> >
>> > trunk/
>> >working_classlib/
>> >working_vm/
>> >working_jdktools/
>> >
>> > > 2) the 'jre' module is always built before building 'jdk' to 
provide
>> > > generic tool launcher and the jre/lib/tools.jar. Probably it 
will be

>> > > easy to obtain these items from HDK.
>> >
>> > That's one reason why I'd pull the launcher out to it's own module
>> >
>> > >
>> > > I'm rather newbie in the Harmony build system so your thoughts
>> will be
>> > > very helpful.
>> >
>> > Ant and make will be your friends here :)  Note that you will have
>> > native issues (because of the launcher), so please track the way 
that
>> > classlib does this wrt platforms to start, and if you find things 
that

>> > work better, suggest it.  Mark and Ollie ar

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)




Mikhail Fursov wrote:



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



I guess that if we could get 5.0 complete, we'd could *then* branch for
6, but I don't think we'd want to serialize like that.


I understand the dilemma. If we agree to have 1 stable, 1 'future' and N 
suspended (old) branches as a rule we finally will tune our process and 
will have almost no overhead to propagate changes from one branch to 
another. The hell is when you do not have any stable schema and create 
long living branches without reasons.


The success of preprocessor's idea is also heavily depends how will we 
use it.
For example, what about "old versions"? Should we someday move the code 
into separate branch or collect N-years old versions in the same source?


Yes, I assume that we'd branch and park 5 at some point, putting it into 
maintenance, and then just if there is a bug, deal with them on case by 
case back into main tree.


But that's just version of SE mainline. There also is The Logging Topic 
That Will Not Die, as well as capabilities and profiles for ME (if 
someone wanted to do so), but I know almost zero about how that works in 
real life.


geir





--
Mikhail Fursov

Re: [doc][drlvm] new docs added - JIT compiler


oh, thankyou thankyou thankyou

Morozova, Nadezhda wrote:

Yeah! No problem, I was just thinking a zip would not look as
transparent and safe. I'd turn the images from the other doc issue into
an archive as well.

Thank you, 
Nadya Morozova
 


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 31, 2006 5:20 AM

To: harmony-dev@incubator.apache.org
Subject: Re: [doc][drlvm] new docs added - JIT compiler

is there any chance you could put a zip of the images into the jira, 
rather than a  dozen or so images?  That's actually what turned me off 
from one of the other doc issues - I said to myself "oh, heck, I don't 
want to download each of those separate thingies... I just want a zip or


tgz of them... easier to handle..."

So please? :)

geir

Morozova, Nadezhda wrote:
All, 


New documents have been added to HARMONY-2003. These are a description
of the Jitrino.OPT and .JET compilers, with a supplementary doc on the
pipeline management framework inside the JITs. The docs describe the
architecture, processes and usage of the components.

 


It would be great if somebody took a look, expressed an opinion, and,

if

favorable, committed to the website.

Your review or any other feedback are most welcome,

 

Thanks, 


Nadya Morozova

 


PS: this JIRA is not the only one unresolved doc issue. Find more

useful

pending patches in our database :-)

Re: [build] Building on Eclipse - FYI




Konovalova, Svetlana wrote:

Nadya,

AFAIU the given page is purely classlib-oriented...though I might be
wrong here. 
It provides info on how to set up Eclipse to develop Java code in

Harmony and IMHO doesn't include any tips applying to harmony code in
general.
I absolutely agree with you that we should have one page describing how
to work with harmony code in Eclipse. It goes without saying that we
need to update info and the help from engineers' side is of great
importance here. You might know that there is a brief webcast for those
who want to see a step-by-step guide to configuring Eclipse. On the one
hand, it's great, but on the other hand, many screenshots can quickly
become outdated. IMHO it's rather complicated to update the video. What
would you say? Should we keep it as it is?


Is it actually out of date?




Cheers,
Sveta

-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 30, 2006 6:45 PM

To: harmony-dev@incubator.apache.org
Subject: RE: [build] Building on Eclipse - FYI

Sveta,
I've taken a brief look at the patch, and I like most of your
corrections. The page looks neater this way, and holds important data.

One question: can't we say that some of the tips given on the page apply
to harmony code in general, not just classlib? So a side idea would be
to have one page: how to work with harmony code in Eclipse. What do you
say? 

Thank you, 
Nadya Morozova
 


-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 30, 2006 6:23 PM

To: harmony-dev@incubator.apache.org
Subject: RE: [build] Building on Eclipse - FYI

Sian,

Taking into consideration your comments, I've opened a new JIRA issue
[http://issues.apache.org/jira/browse/HARMONY-2009] and have created a
patch for the page "Developing Apache Harmony Class-library Code with
Eclipse". Would be great, if you find a chance to look it through. 
Hope we'll continue working at developing this aspect of documentation.

:)

Cheers,
Sveta

-Original Message-
From: Sian January [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 27, 2006 3:34 PM

To: harmony-dev@incubator.apache.org
Subject: Re: [build] Building on Eclipse - FYI

Hi Sveta,

That sounds like a great idea.  I think the two main things you need to
do
extra on Eclipse on Windows are as follows:

1. Make a copy of vsvars32.bat from your Visual Studio install
directory.
If you have chosen the defaults when installing you will find it in
"C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools".
Copy it
to somewhere convenient such as the desktop and add the following line
(just
below the last line that begins "@set..."):
start C:\...\eclipse\eclipse.exe -vmargs -Xmx512M
(where ... is the path to your eclipse installation).  NB. using
"-vmargs
-Xmx512M" is optional, but helpful to stop Eclipse running out of
memory.
Now just double click on this file to start Eclipse.

2. After you have started Eclipse and checked out Harmony from SVN, copy
ecj_3.2.jar into ..\eclipse\plugins\org.apache.ant_1.6.5\lib and change
the
Ant settings to include this jar (Window > Preferences > Ant > Runtime
then
select 'Global Entries' then 'Add External Jars' and add ecj_3.2.jar
from
the org.apache.ant_1.6.5\lib directory).

If you're happy to add that to the document that would be great.

On Linux you will also need to do 2, but I'm not sure if there's an
equivalent to 1 or not.  Has anyone else tried building in Eclipse on
Linux?

Thanks,

Sian


On 26/10/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:

Folks,

I see that we do need one more building doc describing Eclipse
specifics.
The main doc containing building instructions now is the "Getting
Started for Contributors" page.
[http://incubator.apache.org/harmony/quickhelp_contributors.html].
My suggestion is to add one more section to it describing building
instructions for Eclipse. How about that?

If you need my help, I'll be glad to manage the doc creation:)

Cheers,
Sveta

-Original Message-
From: Sian January [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 4:06 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] Building on Eclipse - FYI

Hi Nathan,

Yes - I was trying to run the enitre build in Eclipse and this is

always

my
preferred method of building.  There is at least one other extra step
apart
from the one discussed in this thread so I think some additional
documentation would be useful.

Thanks,

Sian



On 25/10/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:

Are you referring to running the build scripts via Eclipse? Just
wanted to make sure I understand.

Personally, I only import the module projects one at a time and run
the full builds outside of Eclipse, so I've never tried this.

Perhaps

some additional documentation on using Eclipse in this fashion. This
might be helpful additionally.

On 10/24/06, Sian January <[EMAIL PROTECTED]> wrote:

Hello,

I encountered a problem today building on

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)




Mikhail Fursov wrote:

Geir,
What are the reasons to exclude the most standard solution here: branching.
Do you think we need a lot of them?


Because I'm not sure how you can easily maintain fixes and  general 
coherence across branches.


Also, there are 3 use cases for pre-processor, and it sounds like we'd 
go rapidly to branch-hell.


I guess that if we could get 5.0 complete, we'd could *then* branch for 
6, but I don't think we'd want to serialize like that.




I see the following advantages to work in branches for different products:
1) Clean code
2) No side effects (no testing!) for other branches when you modify only 
one branch

3) Everyone knows how to work with branches.
4) No need to support very old versions in the same sources.

Disadvanates
1) Need to propagate a fix to all product branches we have.

?


--
Mikhail Fursov

Re: [classlib] Preprocessor




Fedotov, Alexei A wrote:

Geir,

I tried this preprocessor staff for Java in my previous life. From my
experience the maintenance effort is higher for this solution than for
Source Control.


We use SVN.  How do you propose to do it cleanly in SVN?



1. I faced first time how slow regular expressions on Java could be.
2. Perl worked fine but no one around me could understand my
pre-processing scripts and maintain them.
3. The girl from Ireland beat my clever scripts with Sun's TeamWare and
text editor.

+1 for Source Control

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


-Original Message-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 12:28 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor



Tim Ellison wrote:

Mikhail Fursov wrote:

What are the reasons to exclude the most standard solution here:

branching.

Do you think we need a lot of them?

I don't think we are excluding any option for maintaining similar

code

streams (5.0 & 6.0, SE & ME, etc.) it's just a discussion at the

moment.

Similarly, I'm not advocating the use of aspects for maintaining
different code streams; but rather I was saying that IDE support is
likely going to be a requirement for any technology (apt,

preprocessor,

post-processing, aspects, ...) that we choose to solve the problem.

I'm sure we wouldn't even want simple branching without a decent

merge

tool to keep things in sync.

Yes - that's what I'm scared of.   A branch solution sounds like it
leads to much misery and woe, because i think all the factors that make
this such an interesting problem for which a pre-processor is a valid
solution this implies the requirement of some kind of conditional merge


I agree with Geir that we should endeavour to choose a technology

that

has broad tooling support.

Regards,
Tim

Re: [general] creation of "jdktools"

Why?  I'm really curious about this.  We "build" the project, using the 
"build.xml" file with Ant.



Ilya Neverov wrote:

I would prefer to keep the current name "make" for directories related
to build system. For me it looks natural; at least it looks less
misleading than "build" :)

-Ilya

On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote:


On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> Ilya Neverov wrote:
> > Hello,
> >
> > I want to gather opinions about structure of the "jdktools" 
component.

> >
> > I'm going to create scripts for moving tools' sources from classlib/
> > to top-level directory jdktools/ and to prepare patches for build
> > system for building tools from new place.
>
> Cool
>
> >
> > I think the following structure will be appropriate for future
> > evolution of the jdktools:
> >
> > jdktools/trunk/
> >   build.xml
> >   make/
>
> Can we stop persisting this mistake?  Please call it "build" :)

And call 'build' something else like 'target'?

I'm not actually sure calling it build is a good idea because a number
of common projects use build to contain built artifacts.  What is your
objection to 'make'?

> >   doc/
> >   modules/
> >   jre/ #  keytool, tool launcher go here
> >  build.xml #  classes go to 
jdk/jre/lib/tools.jar

> >  make/
> >  src/
> >   jdk/ #  javac, jarsigner go here
> >  build.xml #  classes go to jdk/lib/tools.jar
> >  make/
> >  src/
> >   jdwp/#  separate module for large 
component

> >  build.xml
> >  make/
> >  src/
>
> Only comment is that we might want to pull the launcher out to be a
> peer.  Otherwise, I like it.

I'd be a little tempted by that idea too.

> >
> > Assumptions which look reasonable for jdktool's build subsystem:
> >
> > 1) it works in presence of built classlib (as HDK binaries or as a
> > result of classlib phase of overall build);
>
> yes - think of the same trick we do w/ DRLVM to "reach over" to find 
it.

>   I'd imagine the federated build to then have :
>
> trunk/
>working_classlib/
>working_vm/
>working_jdktools/
>
> > 2) the 'jre' module is always built before building 'jdk' to provide
> > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> > easy to obtain these items from HDK.
>
> That's one reason why I'd pull the launcher out to it's own module
>
> >
> > I'm rather newbie in the Harmony build system so your thoughts 
will be

> > very helpful.
>
> Ant and make will be your friends here :)  Note that you will have
> native issues (because of the launcher), so please track the way that
> classlib does this wrt platforms to start, and if you find things that
> work better, suggest it.  Mark and Ollie are wizards here.
>
> I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
> if you grok what I mean, and do it in a way that it will be trivial to
> add other OSs or processor architectures (IPF, for example).

> This might be a good place to figure out how this should work going
> forward for harmony, rather than experimenting in classlib.

+1

> >
> > Thank you
>
> No, thank you :)

+1

Regards,
 Mark.

> geir
>
> > -Ilya
> >
> >
> > On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote:
> >> Hi Geir,
> >>
> >> Looks like that creating the "jdktools" source tree and build was
> >> shaded by other tasks. I can help with preparing and checking 
updates
> >> in the build system. Please let me know what needs to do in this 
area

> >> (besides svn commits) to complete the task.
> >>
> >> I'm especially interested in completing the move to "jdktools"
> >> structure since there will be a home for the JDWP code, which has 
beed

> >> voted but still resides in JIRA. Working with SVN will be easier.
> >>
> >> Thanks.
> >> -Ilya
> >>
> >> On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >> > yep, that's the plan.   And o

Re: [general] creation of "jdktools"




Mark Hindess wrote:

On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:

Ilya Neverov wrote:

Hello,

I want to gather opinions about structure of the "jdktools" component.

I'm going to create scripts for moving tools' sources from classlib/
to top-level directory jdktools/ and to prepare patches for build
system for building tools from new place.

Cool


I think the following structure will be appropriate for future
evolution of the jdktools:

jdktools/trunk/
  build.xml
  make/

Can we stop persisting this mistake?  Please call it "build" :)


And call 'build' something else like 'target'?


Yes please!



I'm not actually sure calling it build is a good idea because a number
of common projects use build to contain built artifacts. 


And many use "target".


What is your
objection to 'make'?


Why not "ant"?  (joking)

Because 'make' just appears really unconventional to me.





  doc/
  modules/
  jre/ #  keytool, tool launcher go here
 build.xml #  classes go to jdk/jre/lib/tools.jar
 make/
 src/
  jdk/ #  javac, jarsigner go here
 build.xml #  classes go to jdk/lib/tools.jar
 make/
 src/
  jdwp/#  separate module for large component
 build.xml
 make/
 src/
Only comment is that we might want to pull the launcher out to be a 
peer.  Otherwise, I like it.


I'd be a little tempted by that idea too.


it works with your idea from your other post of just pulling out as-is now.




Assumptions which look reasonable for jdktool's build subsystem:

1) it works in presence of built classlib (as HDK binaries or as a
result of classlib phase of overall build);
yes - think of the same trick we do w/ DRLVM to "reach over" to find it. 
  I'd imagine the federated build to then have :


trunk/
   working_classlib/
   working_vm/
   working_jdktools/


2) the 'jre' module is always built before building 'jdk' to provide
generic tool launcher and the jre/lib/tools.jar. Probably it will be
easy to obtain these items from HDK.

That's one reason why I'd pull the launcher out to it's own module


I'm rather newbie in the Harmony build system so your thoughts will be
very helpful.
Ant and make will be your friends here :)  Note that you will have 
native issues (because of the launcher), so please track the way that 
classlib does this wrt platforms to start, and if you find things that 
work better, suggest it.  Mark and Ollie are wizards here.


I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64) 
if you grok what I mean, and do it in a way that it will be trivial to 
add other OSs or processor architectures (IPF, for example).



This might be a good place to figure out how this should work going
forward for harmony, rather than experimenting in classlib.


+1


Thank you

No, thank you :)


+1

Regards,
 Mark.


geir


-Ilya


On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote:

Hi Geir,

Looks like that creating the "jdktools" source tree and build was
shaded by other tasks. I can help with preparing and checking updates
in the build system. Please let me know what needs to do in this area
(besides svn commits) to complete the task.

I'm especially interested in completing the move to "jdktools"
structure since there will be a home for the JDWP code, which has beed
voted but still resides in JIRA. Working with SVN will be easier.

Thanks.
-Ilya

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

yep, that's the plan.   And once we have that, we can simplify the
launcher as well...

Tim Ellison wrote:

+1 for creating a jdktools directory.  The dependency on the classlib
launcher should be relatively light if we go with a simple tools
launcher that rewrites the tool invocation into a generic launcher
invocation.  You may recall the idea was discussed a while ago.

So, for example,
  jdk/bin/javac -source 1.5 -J-Xmx200M  FooBar
is rewritten to
  jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
org.apache.harmony.tools.javac.Main -source 1.5 FooBar

and so on.

Regards,
Tim

Geir Magnusson Jr. wrote:

Geir Magnusson Jr. wrote:
Now that we have javac, javah, javap (if Tim votes ;) and 

keytool, I'd

like to organize these and add them to the next snapshot.
My bad - the javap isn't being voted on yet.  I was thinking of 

the jdwp

vote... sorry

So I propose adding a new top-level directory called "jdktools" 

(and

rename "tools" to &quo

Re: [classlib] Preprocessor




Tim Ellison wrote:

Mikhail Fursov wrote:

What are the reasons to exclude the most standard solution here: branching.
Do you think we need a lot of them?


I don't think we are excluding any option for maintaining similar code
streams (5.0 & 6.0, SE & ME, etc.) it's just a discussion at the moment.

Similarly, I'm not advocating the use of aspects for maintaining
different code streams; but rather I was saying that IDE support is
likely going to be a requirement for any technology (apt, preprocessor,
post-processing, aspects, ...) that we choose to solve the problem.

I'm sure we wouldn't even want simple branching without a decent merge
tool to keep things in sync.


Yes - that's what I'm scared of.   A branch solution sounds like it 
leads to much misery and woe, because i think all the factors that make 
this such an interesting problem for which a pre-processor is a valid 
solution this implies the requirement of some kind of conditional merge




I agree with Geir that we should endeavour to choose a technology that
has broad tooling support.

Regards,
Tim

Re: [drlvm][em] Value-profiling implementation is avaible.




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

can one of you JIT nerds describe for us non-JIT-nerds what value
profiling is?  :)


Maybe calling people nerds was a disincentive ;-)



I hope not - it's a compliment. :)


Value profiling means watching the actual values of variables or
expressions in a running program, typically in order to direct
optimizations that are value-specific.

Regards,
Tim

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

Alexei Zakharov wrote:

At the same time I don't feel completely comfortable with the idea
of using preprocessor to separate J2SE sources from J2ME.

I'm not overjoyed either, but I can't think of many ways that allow
fairly clear readability without don't require tons of IDE-specific
tooling.  This is what bothers me about aspects - can you get a real
clue what's going to happen looking at the source code?


To be fair though, it's pretty hard to see what is going on in any large
software system without IDE support.  If you haven't looked at AspectJ
[1] for a while it's worth looking again -- they do a pretty cool job of
showing what is going to happen with aspects applied.


I can't find the plugins for IDEA :)

I know what you mean, but I can tend to reach for any of the main IDEs 
and work on most projects.  It's just when a project mandates an IDE 
that I get itchy.


Now, I know in our case that we may have to do that and I'm willing to 
completely go to the dark side and use Eclipse all the time (and aspectJ 
has support for more than one because of it's history... it didn't start 
at Eclipse...), but I'm hoping there are enough clever people around so 
we can get a broad set of tools...




I agree with your point that it's not going to be helpful to require
"tons of IDE-specific tooling".

[1] http://www.eclipse.org/aspectj/

Regards,
Tim

Re: [doc][drlvm] new docs added - JIT compiler

is there any chance you could put a zip of the images into the jira, 
rather than a  dozen or so images?  That's actually what turned me off 
from one of the other doc issues - I said to myself "oh, heck, I don't 
want to download each of those separate thingies... I just want a zip or 
tgz of them... easier to handle..."


So please? :)

geir

Morozova, Nadezhda wrote:
All, 


New documents have been added to HARMONY-2003. These are a description
of the Jitrino.OPT and .JET compilers, with a supplementary doc on the
pipeline management framework inside the JITs. The docs describe the
architecture, processes and usage of the components.

 


It would be great if somebody took a look, expressed an opinion, and, if
favorable, committed to the website.

Your review or any other feedback are most welcome,

 

Thanks, 


Nadya Morozova

 


PS: this JIRA is not the only one unresolved doc issue. Find more useful
pending patches in our database :-)

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




Gregory Shimansky wrote:

On Tuesday 31 October 2006 02:27 Geir Magnusson Jr. wrote:

So I should either create a new 4th category for tests with custom build
file, or extend one of the current categories which we have. The most
close to what I need is probably smoke tests category. I need to add
building native code part and add a custom command line setting
somewhere.

Or do you think I should go with completely new tests category?

New category


Hmm... I shouldn't have asked, or I wouldn't receive two different answers :)

I don't want to create a huge discussion out of it like most [testing] 
discussions become. Just want to know your arguments to create one more tests 
category.


Because the current frameworks are... wacky.  I can't turn off smoke 
tests without *recompiling* the test.  The c-unit test rig is kinda 
cool, but inappropriate.  Maybe kernel could be used.


it sounds like you just want to launch a set of conventional junit tests 
with a special invocation of java to get the agent running, right?




Now that I looked at the smoke tests build more closely and found a paths 
problem which I don't know how to fix, I am also inclined to make my own 
build script to have it separated. I would at least know how it works 
and own this secret like someone who wrote smoke build script does.


That's what I was hoping to avoid.  Something conventional.  JUnit or 
TestNG (TestNG! TestNG!), and a separate ant script invoked from main 
script.


geir

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

Gregory Shimansky wrote:

On Tuesday 31 October 2006 00:24 Fedotov, Alexei A wrote:

Gregory wrote,

I need is probably smoke tests category. I need to add building native

code

part and add a custom command line setting somewhere.

+1
I believe you need one or two test with a good coverage to check your
changes regularly. This is enough for acceptance testing.

This doesn't inhibit the separate category - it would be quite useful
for thorough testing. But from my perspective this is not the first
thing to do.

Now if I just could understand the Grand Design behind that huge tangle called
drlvm ant build... I cannot find a place to start with. I thought eclipse ant
debugging facilities may help (after I read how to build classlib from
eclipse), and spent 2 hours trying to give it properties here and there to no
avail, building drlvm from eclipse didn't work for me so far.

That's why I said "new category". Do something conventional.

Anyway, I think I've found a path bug with running smoke tests. The paths
seems to be different depending on what I run "build.sh test" or "build.sh
smoke.test".

This is what I see when I run "build.sh smoke.test"

/home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -Dvm.assert_dialog=0 -classpath /home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/vm/interpreter/_smoke.tests/classes
StackTest

If you look closely you'll see that tests are taken from
vm/interpreter/_smoke.tests/classes while the correct location which is built
when I run "build.sh test" is vm/_smoke.tests/classes. There is no
interpreter path in it. If someone knows how to fix it, I'd be grateful.

Now that I've tried it a second time after a full rebuild the path looks like
this

Funny how it works picking up seemingly a random subdirectory in
build/lnx_ia32_gcc_debug/semis.

Re: [general] creation of "jdktools"

Ilya Neverov wrote:

Hello,

I want to gather opinions about structure of the "jdktools" component.

I'm going to create scripts for moving tools' sources from classlib/
to top-level directory jdktools/ and to prepare patches for build
system for building tools from new place.

Cool

I think the following structure will be appropriate for future
evolution of the jdktools:

jdktools/trunk/
  build.xml
  make/

Can we stop persisting this mistake?  Please call it "build" :)

  doc/
  modules/
  jre/ #  keytool, tool launcher go here
 build.xml #  classes go to jdk/jre/lib/tools.jar
 make/
 src/
  jdk/ #  javac, jarsigner go here
 build.xml #  classes go to jdk/lib/tools.jar
 make/
 src/
  jdwp/#  separate module for large component
 build.xml
 make/
 src/

Only comment is that we might want to pull the launcher out to be a 
peer.  Otherwise, I like it.

Assumptions which look reasonable for jdktool's build subsystem:

1) it works in presence of built classlib (as HDK binaries or as a
result of classlib phase of overall build);

yes - think of the same trick we do w/ DRLVM to "reach over" to find it. 
 I'd imagine the federated build to then have :

   trunk/
  working_classlib/
  working_vm/
  working_jdktools/

2) the 'jre' module is always built before building 'jdk' to provide
generic tool launcher and the jre/lib/tools.jar. Probably it will be
easy to obtain these items from HDK.

That's one reason why I'd pull the launcher out to it's own module

I'm rather newbie in the Harmony build system so your thoughts will be
very helpful.

Ant and make will be your friends here :)  Note that you will have 
native issues (because of the launcher), so please track the way that 
classlib does this wrt platforms to start, and if you find things that 
work better, suggest it.  Mark and Ollie are wizards here.

I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64) 
if you grok what I mean, and do it in a way that it will be trivial to 
add other OSs or processor architectures (IPF, for example).  This might 
be a good place to figure out how this should work going forward for 
harmony, rather than experimenting in classlib.

Thank you

No, thank you :)

geir

-Ilya

On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote:

Hi Geir,

Looks like that creating the "jdktools" source tree and build was
shaded by other tasks. I can help with preparing and checking updates
in the build system. Please let me know what needs to do in this area
(besides svn commits) to complete the task.

I'm especially interested in completing the move to "jdktools"
structure since there will be a home for the JDWP code, which has beed
voted but still resides in JIRA. Working with SVN will be easier.

Thanks.
-Ilya

On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> yep, that's the plan.   And once we have that, we can simplify the
> launcher as well...
>
> Tim Ellison wrote:
> > +1 for creating a jdktools directory.  The dependency on the classlib
> > launcher should be relatively light if we go with a simple tools
> > launcher that rewrites the tool invocation into a generic launcher
> > invocation.  You may recall the idea was discussed a while ago.
> >
> > So, for example,
> >   jdk/bin/javac -source 1.5 -J-Xmx200M  FooBar
> > is rewritten to
> >   jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >
> > and so on.
> >
> > Regards,
> > Tim
> >
> > Geir Magnusson Jr. wrote:
> >> Geir Magnusson Jr. wrote:
> >>> Now that we have javac, javah, javap (if Tim votes ;) and 
keytool, I'd

> >>> like to organize these and add them to the next snapshot.
> >> My bad - the javap isn't being voted on yet.  I was thinking of 
the jdwp

> >> vote... sorry
> >>
> >>> So I propose adding a new top-level directory called "jdktools" 
(and

> >>> rename "tools" to "project_tools") and create a build target that -
> >>> with a  dependency on classlib for the launcher - creates the 
'stuff'

> >>> needed to fill into the JDK.
> >>>
> >>> Any comments?
> >>>
> >>> geir
> >>>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Thank you.
Ilya Neverov,
Intel Middleware Products Division

Re: [classlib][luni] signalis interruptus in hysock



Fedotov, Alexei A wrote:

Geir, All,

I have examined class library code. It seems that the solution we
invented (return EINTR, then loop) was always in place. :-)

Few comments on understanding:
1. EINTR (=4) is renamed to HYPORT_ERROR_SOCKET_INTERRUPTED (=-9).


Yes, I did that in one place to have it fit into the portlib error code 
set.  Someone may have done it in another.



2. The loop is coded by means of "goto select".


In code that calls the wrapper for the lowest-level select(), right?


3. The same pattern is dupdupduplicated several times.


That's another issue entirely :)



I have not examined all places, though there could be paths which do not
fit the pattern. Honestly, I have examined the only path:

pollSelectRead() ->
hysock_select_read() ->
hysock_select()

Summary:
We can keep this issue open or close  it as won't fix. Meanwhile we
should look for the real problem.


I don't understand this - what do you see as the real problem? 
Interruption from select due to signals is a fact of life under linux.


geir



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


-----Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock



Fedotov, Alexei A wrote:

Geir,

Do I understand correctly that you suggest the following?

1. hysock_select as its name says should mimic a behavior of select,

i.

e. return the error code from select without changing it. It's ok to
print a rare debug message.

Yes, that's what I had the other do (and no, I see no reason to print a
debug message, as upper layers can print if they find an EINTR)


2. The correct place for the loop is the module where hysock_select

is

called, or, let me be precise, class lib guys are to fix our

networking

code.

My plan is to fix it as fixed the other one.  It turns out that there
are several layers between java and the OS...

geir



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


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock



Weldon Washburn wrote:

It seems JIRA is down for maintenance.  If HARMONY-1904 is still

open

perhaps it makes sense to put a counter in the while (...) {

select...}

loop. And after every N loops, print a warning/diagnostic message.

For whom and to what end?  Why not just return EINTR (in hysock

speak)?

The
value for N would have to be tuned.  I don't know what the best

number

would
be. Given that 1904 patch is not the final solution, at least a

diagnostic

that hints at where the system hangs would be useful.  It might

make

sense

to even print a stack trace.   Also, I agree with Ivan below.

Signals

bugs

are very hard to debug.  And diagnostics can help us all understand

the

corner cases better.

But so far, no one has shown that the system hangs, or can hang,

simply

because we return EINTR

geir


On 10/20/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:

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

Ivan Volosyuk wrote:

Well, I think that the solution is what Geir suggests. One think

which

bothers me is following. EINTR can happen in different places

and

the

situations can be quite rare in some circumstances. It can lead

to

hard to reproduce stability bugs (race conditions).

Can you give an example?

Half a year ago, I was working on the problem. Socket operations

get

sometimes interrupted. We have found out that it occurs sometime

after

GC. It was not quite easy as the application was quite big and
situation - quite rare.

Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have

rock

solid support of EINTR handling everywhere the select(), poll()

calls

is used.

--
Ivan
Intel Enterprise Solutions Software Division


We should find a
way how to test the implementation.

+1!

:)

geir

-

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

[EMAIL PROTECTED]

For additional commands, e-mail:

[EMAIL PROTECTED]

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




Gregory Shimansky wrote:

Hello

JVMTI implementation is quite a big piece of drlvm code which doesn't have any 
tests that are ran regularly. This may create regressions in JVMTI 
implementation which won't be caught early. So I want to add several small 
tests for JVMTI which would cover most of the currently implemented 
functionality.


Yay!



The specific of such tests is that they have to have a custom command line, to 
specify -agentlib: library. They also require to build native 
code. They need to be run in default (JIT) mode and on interpreter.


Ok.  You can do that from ant



Current tests which we have for commit checks for drlvm don't have these 
features out of the box. Cunit tests build native code, but don't run java 
executable. Smoke and kernel tests don't have native code and don't have a 
custom command line.


So I should either create a new 4th category for tests with custom build file, 
or extend one of the current categories which we have. The most close to what 
I need is probably smoke tests category. I need to add building native code 
part and add a custom command line setting somewhere.


Or do you think I should go with completely new tests category?


New category

geir

Re: [build] Building on Eclipse - FYI

Sian January wrote:
My concern is that if there is too much documentation and it's not well 
structured then people won't be inclined to read any of it.

Agreed.

 If 50% 
of the "Getting Started With DRLVM" page is actually about Eclipse, my 
feeling is that it won't be as useful for people who actually want to 
get started with DRLVM than it would be if it was half the size and more 
concise.

Agreed.  It should be about IDEA anyway :)

 In general I think having Eclipse-related documentation on 
its own page (or inline where it's relevant) is a good thing, I was just 
commenting on the amount of seemingly unrelated Eclipse documentation 
that is currently included in the DRLVM page ( 
http://incubator.apache.org/harmony/subcomponents/drlvm/getting_started.html).  
Just my 2p worth...

I agree that our basic "getting started with Harmony" stuff should be 
relatively independent of any IDE, but have links with material for 
specific IDE's if people contribute the material.

What I thought I was responding to was the idea that we we should limit 
the amount of Eclipse tutorial in our *document about Eclipse*.  Sorry 
if I misunderstood.

geir

Thanks,

Sian

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

Sian January wrote:
 > I'm actually not sure if that first page is up to date or not  (
 >

http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclipse.html).
 >
 > I think it should be but I have not ever been able to get it to work
 > myself.  Can anyone else confirm whether it is still in date or not?
 >
 > Also I'm just wondering whether we really need steps 5-14 of
"Running an
 > Application in Eclipse" or any of "Debugging an Application in
Eclipse"?
 > There doesn't seem to be anything Harmony-specific in those
steps, it's
 > just
 > about using Eclipse.  I know Eclipse itself contains that kind of
 > documentation in its help system so IMHO it seems like it could
be a little
 > redundant to duplicate that on the Harmony website.
 >

I think that if we have an eclipse document, and the info is accurate, I
say why not?

We're trying to suck people into the whirling vortex that is our little
project, and if it's someone that isn't an eclipse user, but was
intrigued by our ability to run it, etc, etc, it seem to be harmless.  I
assume that it won't change often, so the maintenance is minor?

geir

 > Thanks,
 >
 > Sian
 >
 >
 > On 27/10/06, Konovalova, Svetlana <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
 >>
 >> Sian,
 >>
 >> Thanks a lot for the detailed description of what I should do. I'll
 >> follow your recommendations. :)
 >>
 >> I'll investigate what we have already written about Eclipse to
avoid
 >> redundant info and repeating pages.
 >>
 >> What I've just come across are:
 >> 1) The page describing how to set up Eclipse to develop Java code in
 >> Apache Harmony
 >> [
http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_ecli
 >> pse.html];
 >> 2) The sections "Running an Application in Eclipse" and
"Debugging an
 >> Application in Eclipse "in the Getting Started with DRL
 >>
[file:///C:/SVN-23-10/docs/subcomponents/drlvm/getting_started.html#Ecli

 >> pse_Hello_world]
 >>
 >> Would be great, if you find a chance to check whether the
aforementioned
 >> info is up-to-date :)
 >>
 >> Cheers,
 >> Sveta
 >> -Original Message-
 >> From: Sian January [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>]
 >> Sent: Friday, October 27, 2006 3:34 PM
 >> To: harmony-dev@incubator.apache.org
<mailto:harmony-dev@incubator.apache.org>
 >> Subject: Re: [build] Building on Eclipse - FYI
 >>
 >> Hi Sveta,
 >>
 >> That sounds like a great idea.  I think the two main things you
need to
 >> do
 >> extra on Eclipse on Windows are as follows:
 >>
 >> 1. Make a copy of vsvars32.bat from your Visual Studio install
 >> directory.
 >> If you have chosen the defaults when installing you will find it in
 >> "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools".
 >> Copy it
 >> to somewhere convenient such as the desktop and add the
following line
 >> (just
 >

Re: [DRLVM][GC] parallel compaction and wasted virtual space


Are IBM's and Sun's are know to work well for production loads?


Xiao-Feng Li wrote:

Weldon, the problem is, there is no well-established parallel
compaction algorithms. So far the best known work are 1. SUN's work;
2. IBM's work and 3. Compressor. No one knows which one is the best
for different workloads. We have to identify one algorithm for
implementation, and at the moment Compressor looks to be the right
choice, or we write more than one compactors.

Thanks,
xiaofeng

On 10/30/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:

Since the Compressor algorithm was published only this year, perhaps it
makes sense to consider it experimental.  Perhaps make it a compile time
switch so that that folks focused on production quality VM don't trip on
it.  Even assuming the implementation of the Compressor algorithm is bug
free, there may be unforeseen performance problems that surface with
different workloads.

On 10/29/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> On 10/29/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > Xiao Feng,
> >   I will read the reference to understand what are the compressor
> > advantages, and how the algorithm is implemented, thanks.
> >
> > Even when you have 1GB of physical memory, is there not an 
overhead of

> page
> > faults?
>
> Yes, I agree that page faults definitely will be an overhead. I guess
> the page mapping overhead in Compressor is lower than the benefits it
> achieves. But yes, we need evaluate it independently.
>
> > Is it an option to compact the heap in parts and/or to increase the
> number
> > of passes to reduce the space overhead?
>
> The key idea of Compressor is to keep the object order during parallel
> compaction. There are other algorithms like "mark-copy" which require
> less additional copy space, but can't maintain the object order. In
> order to enable the parallel compaction of multiple blocks, the
> assumption is, we have to assume the to-space in the worst case is the
> equal size as the from-space. We can use a to-space with 30% size of
> the from-space in most compaction collections without problem, but we
> need be prepared for the worst case. A possible solution is, to have a
> fall-back algorithm when the to-space is smaller than required. This
> is not a new idea, e.g., GCv4.1 employs something similar and there
> are some papers available. [1] in ISMM06 is an example.
>
> [1] http://www.cs.purdue.edu/homes/pmcgache/ismm06.pdf
>
> > Is this significantly better than doing semi-space copying at each GC
> cycle,
> > since one major advantage of compaction( other than preserving
> allocation
> > order ) over copying, was probably less space overhead?
>
> Yes. The major advantage in my opinion is less physical space
> overhead. Well it introduces the vitual space overhead. If assuming
> the same of physical space overhead as a semi-space collector, we need
> evaluate the real benefits of object locality to trade off the
> collection pause time.
>
> > Are we looking for a parallel compaction algorithm for all 
situations,

> or
> > can we think of choosing at JVM startup based on user input,
> client/server,
> > or OS feedback on execution environment?
>
> I think some adaptive choice is better. It means we need provide the
> choices at first. :-) I guess it's not a big overhead to have two
> parallel compactors.
>
> Thanks,
> xiaofeng
>
> > Sorry for all these questions before reading the book :-)
> >
> > Rana
> >
> >
> >
> >
> >
> >
> > > On 10/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi, all, the plan for GCv5 parallel compaction is to apply the 
idea

> of
> > > > Compressor [1]. But it has an issue I want to discuss with you.
> > > > Compressor needs to reserve an unmapped virtual space for
> compaction.
> > > > The size of the reserved part is the same as that of copy reserve
> > > > space in a semi-space collector. This means about that part of 
the

> > > > virtual space is unusable for the JVM. In a typical setting, the
> > > > wasted part is half size of the total compaction space. If we 
have

> 1GB
> > > > physical memory, the JVM is ok for Compressor because the virtual
> > > > space is large enough to wast half; but if the phsical memory is
> >2GB,
> > > > Compressor may have a problem in 32bit machine: some of phsical
> mapped
> > > > space might be wasted.
> > > >
> > > > Any opinion on this?
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > [1] http://www.cs.technion.ac.il/~erez/Papers/compressor-pldi.pdf
> > >
> > >
> >
> >
>



--
Weldon Washburn
Intel Enterprise Solutions Software Division

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




Etienne Gagnon wrote:

[SNIP]



I hope this is useful to both projects [drlvm][sablevm]  :-)


This was really great - I need to go back and read it carefully.  Thanks
so much!



Etienne

(C) 2006 by Etienne M. Gagnon <[EMAIL PROTECTED]>
This text is licensed under the Apache License, Version 2.0.

[You may add this document in svn;  I am willing to sign the required
Apache agreement to make it so, if you intend to use it in drlvm's
implementation].


This isn't really necessary - by the terms of this list, anything
submitted is considered a contribution under the terms of the Apache
license and ICLA, unless noted otherwise as "NOT A CONTRIBUTION".

However, it would be great if you had an ICLA and ACQ on file to save
you the trouble of typing this in the future :)  "Better living through 
paperwork!"


geir

Re: [drlvm][em] Value-profiling implementation is avaible.

can one of you JIT nerds describe for us non-JIT-nerds what value 
profiling is?  :)


geir


Yuri Kashnikoff wrote:

Hi!
I'am working on value-profiling implementation. Implementation in EM
is alredy avaible. Now I'am trying to implement and use it in JIT. I
can answer any questions about current implementation. I have used the
straigth algorithm (cacthing FIRST N values) as default and as
advanced algorithm the Top-N-Value algorithm from the B. Calder, P.
Feller "Value Profiling and Optimisation". I'll appreciate any
questions. Please review and comment.

Re: [classlib] Preprocessor




Tim Ellison wrote:

Etienne Gagnon wrote:

Chris Gray wrote:

For JavaME I think it's the only way we'd be able to maintain a single
source tree. We need to be able to "#ifdef out" references to classes
we don't have, methods we don't implement, etc..

That much being said, I don't have a recommendation for a tool to use.
Java syntax is sufficiently C-like that cpp is probably do-able, but
we'd probably stumble over a whole series of gotcha's, and cpp isn't
exactly [deity]'s gift to preprocessing anyway. Maybe one of the
aspect-oriented tools (with which I am not at all familiar) could be a
better bet?

You could always do "clean" source-to-source processing using
SableCC...:-)  Java is a nice language to parse, so you could do some
clean parsing, instead of the dumb "unstructured text" replacement of
preprocessors.

Actually, if all you need if "ifdef'ing out" undesirable references, it
could be done by "hiding" modification directives in structured
comments,  so that these comment remain "javac" invisible.  This way you
could make it such that:
1- Plain source compilation -> j2se .
2- Structured processed source compilation -> j2me .


I agree, ensuring that the original source remains compilable can be a
great benefit.

Besides in-lining #ifdef's you can also maintain look-aside files with a
description of the smaller configurations.  That helps to avoid code
clutter though of course you may prefer to be marking-up the code
in-line if it is not simply removing whole types/methods.


Yes.



The other thing to remember is that methods that appear in the smaller
configurations must only be implemented in terms of methods that appear
in the smaller configurations.  For example, you may have to rewrite
regular IO to not be implemented in terms of NIO so that it remains
viable in configurations that don't have NIO.  In Harmony we have a
common 'platform IO layer' used for both modules.

Where you do go through a source-to-source transform stage it helps of
you can collaborate with the second-stage compiler to pass through
original line number info (a la JSR45) otherwise debugging gets a bit
tiresome.


Right, except I could imagine having an IDE plugin that deals with this 
for you - you edit and debug using the processed code, which is what the 
line numbers will correspond to...




Regards,
Tim


If you need it, there are 2 or 3 Java 1.5 grammars available for SableCC
(different parsing approaches, not different syntax!).  As I said, Java
is a pleasure to parse when compared to C & C++.

It's just an idea, of course...  [I know that people can start religious
wars about pre-processing; that's why I am suggesting a clean approach,
so that j2se people don't have to pre-process].

Etienne

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Alexei Zakharov wrote:

Hi all,

Well, as an individual who has the tendency to pure Java programming I
will be happier if I can control things on the source-code level. I
can't say I don't like the idea about sophisticated JIT with the
powerful AI inside, but if we are talking about logging then IMHO a
good preprocessor is the thing that we need (but we may also continue
to JIT away stuff if we like). 

Not only that, we create a class library that places weird requirements 
on any VM that wants to use it.  No thanks.

> At the same time I don't feel

completely comfortable with the idea of using preprocessor to separate
J2SE sources from J2ME.

I'm not overjoyed either, but I can't think of many ways that allow 
fairly clear readability without don't require tons of IDE-specific 
tooling.  This is what bothers me about aspects - can you get a real 
clue what's going to happen looking at the source code?

geir

No clue about particular technology. It can be SableCC, something
custom-made, velocity or whatever.

Thanks,

2006/10/30, Fedotov, Alexei A <[EMAIL PROTECTED]>:

   Premature optimization is the root of all evil
   Donald Knuth

>Just a small idea: Let teach JIT to purge this code unless special
option
>is ON

+1

I believe a computer should adapt to my way of thinking. I prefer a
simple and readable code to an efficient one since the former one saves
the time of my life, why the latter one saves some electricity.

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

>-Original Message-
>From: Mikhail Fursov [mailto:[EMAIL PROTECTED]
>Sent: Sunday, October 29, 2006 8:56 PM
>To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
>Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code
smell -
>Thread.sleep() in ActivationGroup method)
>
>On 10/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> 1) The Logging Debate That Won't Die - we don't want to encumber our
>> "production" code with logging or even with runtime enablement checks
>> for logging i.e.
>>
>>   if (logging.isDebugEnabled())
>>
>> but it's clear that some people still want to use it for debugging.
>
>
>Just a small idea: Let teach JIT to purge this code unless special
option
>is ON
>? Doing this we solve performance issue at least .
>
>If we did this, I assume that our build becomes a two step process,
>> first pre-process the code to create  separate "buildable source",
which
>> would go into source jars and such for debugging purposes.  Then our
>> current javac/jar process.
>>
>> I'd also like to be able to work in an IDE with the pre-proc stuff
>> invisible if possible...
>
>
>This is the main problem. Backporting of your changes from the
"buildable
>source" to the "source with preprocessor" could have more overhead then
>support of a separate branch for different Java version.

Re: [general][snapshot] Windows installer