You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Zakirov, Salikh" <sa...@intel.com> on 2006/08/14 20:22:45 UTC
[drlvm] src/test side-by-side with vm and build?
Hi,
in the below commit Geir has added several dozens files
under
drlvm/trunk/src/test
Since we have two directories on the top-level, build with build
system, and vm with everything else (sources, tests, documentation),
it seems very confusing to have 'src' directory at the top level.
Some time ago DRLVM team had very hot debates on directory structure,
and we ended up with following structure:
drlvm/trunk
+ vm
+ vmcore
+ jitrino
+ ... (other components)
+ doc (documentation)
+ tests (tests)
+ include (header files)
+ build (build system)
The tests that are now checked into src/test look like they are put to a
wrong place.
More correct place would be something like
vm/tests/verifier
Pavel, could you suggest a convenient place for your verifier tests?
--
Salikh Zakirov, Intel Middleware Products Division
-----Original Message-----
From: geirm@apache.org [mailto:geirm@apache.org]
Sent: Wednesday, August 02, 2006 8:31 PM
To: harmony-commits@incubator.apache.org
Subject: svn commit: r428043 - in
/incubator/harmony/enhanced/drlvm/trunk: src/test/verifier_aastore/
src/test/verifier_aastore/src/ src/test/verifier_empty_init/
src/test/verifier_empty_init/src/ vm/vmcore/src/verifier/
Author: geirm
Date: Wed Aug 2 09:30:51 2006
New Revision: 428043
URL: http://svn.apache.org/viewvc?rev=428043&view=rev
Log:
HARMONY-973
Add check for empty init method
Also added both test sets included in JIRA to
src/test for further integration
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore2.j
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tInterface.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/HowT
o.txt (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
Test.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
TestEmptyInit.j
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_datafl
ow.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_utils.
cpp
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/HowTo.txt?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt Wed Aug 2 09:30:51 2006
@@ -0,0 +1,14 @@
+How to compile and run test:
+
+1) To compile you need to have a Jasmin version 1.1.
+This can be downloaded from http://jasmin.sourceforge.net
+
+2) The Jasmin distribution contains a jasmin.jar file holding the
Jasmin assembler.
+To compile sources execute the following commands:
+
+$ java -jar <path to Jasmin 1.1>/jasmin.jar src/*.j
+$ javac -d . src/*.java
+
+3) To run test execute the following command:
+
+$ java Test
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt
------------------------------------------------------------------------
------
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/src/Test.java?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java Wed Aug 2 09:30:51 2006
@@ -0,0 +1,14 @@
+public class Test {
+ public static void main(String[] args) {
+ // verify aastore instruction
+ try {
+ new TestAastore().test();
+ System.out.println("TestAastore: failed");
+ } catch (LinkageError e) {
+ System.out.println("TestAastore: passed: " + e);
+ } catch (Throwable e) {
+ System.out.println("TestAastore: failed: unexpected error "
+ e);
+ e.printStackTrace();
+ }
+ }
+}
\ No newline at end of file
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java
------------------------------------------------------------------------
------
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/src/TestAastore.java?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore.java (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore.java Wed Aug 2 09:30:51 2006
@@ -0,0 +1,11 @@
+public class TestAastore implements TestInterface {
+ public void test() {
+ TestAastore2 inst = new TestAastore2();
+ TestAastore[] array = new TestAastore[1];
+ inst.testField = array;
+ inst.test();
+ }
+ public void InterfaceMethod() {
+ return;
+ }
+}
\ No newline at end of file
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore.java
------------------------------------------------------------------------
------
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore2.j
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/src/TestAastore2.j?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore2.j (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore2.j Wed Aug 2 09:30:51 2006
@@ -0,0 +1,30 @@
+.class public TestAastore2
+.super java/lang/Object
+.field public testField [LTestInterface;
+
+.method public <init>()V
+ aload_0
+ invokespecial java/lang/Object/<init>()V
+ return
+.end method
+
+.method public test()V
+ .limit stack 3
+ .limit locals 2
+
+ aload_0
+ getfield TestAastore2/testField [LTestInterface;
+ astore_1
+
+ sipush 1
+ sipush 1
+ multianewarray [[LTestAastore; 2
+ sipush 0
+
+ ; target of a aastore instruction not assignment compatible
+ ; with the class type specified in the instruction
+ aload_1
+ aastore
+
+ return
+.end method
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tInterface.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/src/TestInterface.java?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tInterface.java (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tInterface.java Wed Aug 2 09:30:51 2006
@@ -0,0 +1,3 @@
+public interface TestInterface {
+ public void InterfaceMethod();
+}
\ No newline at end of file
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tInterface.java
------------------------------------------------------------------------
------
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/HowT
o.txt
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_empty_init/HowTo.txt?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/HowT
o.txt (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/HowT
o.txt Wed Aug 2 09:30:51 2006
@@ -0,0 +1,14 @@
+How to compile and run test:
+
+1) To compile you need to have a Jasmin version 1.1.
+This can be downloaded from http://jasmin.sourceforge.net
+
+2) The Jasmin distribution contains a jasmin.jar file holding the
Jasmin assembler.
+To compile sources execute the following commands:
+
+$ java -jar <path to Jasmin 1.1>/jasmin.jar src/*.j
+$ javac -d . src/Test.java
+
+3) To run test execute the following command:
+
+$ java Test
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/HowT
o.txt
------------------------------------------------------------------------
------
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
Test.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_empty_init/src/Test.java?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
Test.java (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
Test.java Wed Aug 2 09:30:51 2006
@@ -0,0 +1,14 @@
+public class Test {
+ public static void main(String [] argv) {
+ // check empty init method
+ try {
+ Class cl = Class.forName("TestEmptyInit");
+ System.out.println("TestEmptyInit: Fails");
+ } catch (LinkageError e) {
+ System.out.println("TestEmptyInit: Passes: " + e);
+ } catch (Throwable e) {
+ System.out.println("TestEmptyInit: Failed, caught
unexpected exception");
+ e.printStackTrace(System.out);
+ }
+ }
+}
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
Test.java
------------------------------------------------------------------------
------
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
TestEmptyInit.j
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_empty_init/src/TestEmptyInit.j?rev=428043&view=auto
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
TestEmptyInit.j (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
TestEmptyInit.j Wed Aug 2 09:30:51 2006
@@ -0,0 +1,7 @@
+.class public TestEmptyInit
+.super java/lang/Object
+
+.method public <init>()V
+ ; empty init method w/o invokation to othe init method
+ return
+.end method
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_datafl
ow.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/v
mcore/src/verifier/ver_dataflow.cpp?rev=428043&r1=428042&r2=428043&view=
diff
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_datafl
ow.cpp (original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_datafl
ow.cpp Wed Aug 2 09:30:51 2006
@@ -1115,6 +1115,19 @@
return VER_OK;
}
+ // check <init> method
+ if( !memcmp( method_get_name( ctex->m_method ), "<init>", 7 )
+ && ctex->m_vtype.m_class != ctex->m_vtype.m_object )
+ {
+ if( invector->m_local->m_type == SM_UNINITIALIZED ) {
+ VERIFY_REPORT( ctex, "(class: " << class_get_name(
ctex->m_class )
+ << ", method: " << method_get_name( ctex->m_method )
+ << method_get_descriptor( ctex->m_method )
+ << ") Constructor must be invoked" );
+ return VER_ErrorDataFlow;
+ }
+ }
+
// get first instruction
vf_Code_t *instr = &ctex->m_code[ctex->m_graph->GetNodeFirstInstr(
node_num )];
@@ -1336,7 +1349,7 @@
// fill "this" entry
const char *name = class_get_name( ctex->m_class );
vf_ValidType_t *type = vf_create_class_valid_type( name, ctex
);
- if( !strcmp( method_get_name( ctex->m_method ), "<init>" ) ) {
+ if( !memcmp( method_get_name( ctex->m_method ), "<init>", 7 ) )
{
vector->m_local->m_type = SM_UNINITIALIZED;
} else {
vector->m_local->m_type = SM_REF;
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_utils.
cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/v
mcore/src/verifier/ver_utils.cpp?rev=428043&r1=428042&r2=428043&view=dif
f
========================================================================
======
---
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_utils.
cpp (original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_utils.
cpp Wed Aug 2 09:30:51 2006
@@ -344,6 +344,7 @@
{
*out << "CONSTRAINT: have \""
<< constraint->source << "\" need \"" << constraint->target
<< "\" for method "
+ << class_get_name( method_get_class( m_method ) ) << "."
<< method_get_name( m_method ) << method_get_descriptor(
m_method ) << endl;
}
return;
@@ -411,10 +412,12 @@
VERIFY_TRACE( "constraint", "CONSTRAINT: for class \""
<< class_get_name( method_get_class( m_method ) ) << "\" CP
index #" << index
<< " check access: have \"" << source << "\" need \"" <<
target << "\" for method "
+ << class_get_name( method_get_class( m_method ) ) << "."
<< method_get_name( m_method ) << method_get_descriptor(
m_method ) );
} else {
VERIFY_TRACE( "constraint", "CONSTRAINT: have \""
<< source << "\" need \"" << target << "\" for method "
+ << class_get_name( method_get_class( m_method ) ) << "."
<< method_get_name( m_method ) << method_get_descriptor(
m_method ) );
}
return;
@@ -1222,7 +1225,7 @@
VERIFY_DEBUG( "verifying class " << class_get_name(
ctex->m_class )
<< " (method " << method_get_name( ctex->m_method )
<< method_get_descriptor( ctex->m_method )
- << ") couldn't resolve field by constant pool index #"
<< index );
+ << ") couldn't resolve field with constant pool index
#" << index );
return VER_OK;
}
if( field_is_protected( field ) ) {
@@ -1235,7 +1238,7 @@
VERIFY_DEBUG( "verifying class " << class_get_name(
ctex->m_class )
<< " (method " << method_get_name( ctex->m_method )
<< method_get_descriptor( ctex->m_method )
- << ") couldn't resolve method by constant pool index #"
<< index );
+ << ") couldn't resolve method with constant pool index
#" << index );
return VER_OK;
}
if( method_is_protected( method ) ) {
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] src/test side-by-side with vm and build?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Salikh Zakirov wrote:
> Geir Magnusson Jr wrote:
>> Yep - I just wanted to park them somewhere as I wanted to close the
>> JIRAs that they came in. I thought that putting them in a conventional
>> place like 'src/test' would cause a violent allergic reaction in people
>> used to the unique innovation that is the DRLVM layout :)
>
> Okay, so here you are :)
>
>> Actually, we need to come up with a real test framework for these, and
>> hopefully pull the other tests out to join them.
>
> I agree.
> Concerning the test framework, we already have at least 3 on hands:
> 1) classic junit
> 2) smoke test runner (1 VM process per test), parse output stream
> for pass/fail, check the return status.
> Ant-based runner is in build system, and shell-based one just as easy to do
> 3) smoke test runner in 1 VM process, tests/smoke/Check.java,
> with the same semanics for pass/fail
>
> Generally, I think we should accept any tests, provided that the tests
> can be run as easy as 'build test' (or 'make check' or whatever that
> can be started by one button press).
Well, yes - in which case we need a framework for the new tests in src/
as they didn't slot in to anything.
>
>> While we're talking about it, should we consider a fresh layout for
>> DRLVM?
>
> Remembering the flamewars when deciding on current one, I would suggest
> that we find a good reason first. A poor peace is better than a good war...
That wasn't our flamewar... :) That was your flamewar....
>
>> Maybe we can switch to a make-based build at the same time...
>
> As far as I can tell from my experience, it is utterly unwise to
> do a build system change and directory layout change at the same time.
>
> A better approach would be start playing with a new build system
> while majority of the developers stay on the current one.
> And once the new system is in reasonable shape, plan a flag day
> to phase out the old system.
I actually agree, but so we don't have a repeat visit to this little
circle of hell, we should at least consider the build when designing the
layout?
>
>> right now, the layout w/in vm/ is somewhat arbitrary :
>
> In fact, you just have identified most of the cornerstones of the layout.
ROTFL!
>
>> 1) There is an include directory in parallel with the modules
>>
>> vm/include/*.h
>
> This is intentional. These are VM-wide internal interfaces that are
> used to communicate between pluggable VM components (VM Core, GC, JIT).
> This is mostly defines interfaces between DLLs.
I understand that, but it shouldn't be peer with the architectural
modules of the system. If it's a module, then it's a peer. if it's a
resource, than make it clear.
>> 2) Some modules have their own include directories (vm/vmcore/include)
>
> VM Core module is rather big, so it is split into several subcomponents.
> The vmcore/include directory is for internal interfaces of VM Core, such
> as exceptions. Note, that these interfaces are not exposed to DLL level.
>
>> 3) Some don't (vm/em)
>
> Small modules do not require dividing into smaller subcomponents,
> thus do not have any module-wide include directories.
But that would make life so much clearer - you want the module includes,
go into
$module/include
Patterns and convention are you friends...
>
>> 4) Some modules have src near the top :
>>
>> vm/em/src
>
> In fact, *all* modules are supposed to have src/ subdirectory.
>
>> 5) Some don't
>>
>> vm/tests/smoke/
>
> This is just tests, which are not considered as a module.
Yet a peer to the modules (and the includes...) Patterns and convention ...
>> 6) Some modules have strange branches by language deep in the path :
>>
>> vm/vmcore/src/kernel_classes
>> /javasrc
>> /native
>
> Again, this is intentional. It is used for separating java sources from c/c++
> sources for modules that have both. Pure-language modules omit it.
Crikey - how can you have anything standardized in the build then? it's
just arbitrary, so there can be no shared code for each module? With
patterns, then it's easy to do things, like group includes, sources, etc.
>
>> What do you think?
>
> While I do not personally agree with some of the decisions, I think we have
> better things to do than to revise this structure without a good reason.
I can come up with a good reason for everything I've mentioned.
>
> I think it would be much better to describe the decisions behind the current structure
> somewhere on the web or wiki. I could do it in a few days if someone else doesn't
> volunteer to do it before.
That would be a good starting point, but I think it's the reason the
build is so complicated. Laying things out in common patterns has
tremendous upside - it's easy to understand where to find things in
module B if you understand module A, for example.
>
> P.S. If it was up to me, I would put all sources of each module (DLL) into one directory,
> just like
>
> drlvm/trunk
> + vm
> + *.cpp *.c *.java
> + gc
> + *.cpp
> + jit
> + *.cpp
> + Makefile
> + doc
> + *.html *.txt
>
> P.P.S: do not take it seriously, it is a provocation :)
I'm hard to provoke :) I'd suggest, w/o thinking much :
trunk/
build.xml
build/ (where the makefiles/build.xml live)
target/ (where the generated stuff goes0
modules/
vm/
src/
main/
java/
native/
test/
java/
native/
resource/
gc/
src/
...
em/
src/
...
common/ (or maybe src)?
include/
Dunno :) It's late at night...
geir
>
> --
> Salikh
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] src/test side-by-side with vm and build?
Posted by Salikh Zakirov <Sa...@Intel.com>.
Geir Magnusson Jr wrote:
> Yep - I just wanted to park them somewhere as I wanted to close the
> JIRAs that they came in. I thought that putting them in a conventional
> place like 'src/test' would cause a violent allergic reaction in people
> used to the unique innovation that is the DRLVM layout :)
Okay, so here you are :)
> Actually, we need to come up with a real test framework for these, and
> hopefully pull the other tests out to join them.
I agree.
Concerning the test framework, we already have at least 3 on hands:
1) classic junit
2) smoke test runner (1 VM process per test), parse output stream
for pass/fail, check the return status.
Ant-based runner is in build system, and shell-based one just as easy to do
3) smoke test runner in 1 VM process, tests/smoke/Check.java,
with the same semanics for pass/fail
Generally, I think we should accept any tests, provided that the tests
can be run as easy as 'build test' (or 'make check' or whatever that
can be started by one button press).
> While we're talking about it, should we consider a fresh layout for
> DRLVM?
Remembering the flamewars when deciding on current one, I would suggest
that we find a good reason first. A poor peace is better than a good war...
> Maybe we can switch to a make-based build at the same time...
As far as I can tell from my experience, it is utterly unwise to
do a build system change and directory layout change at the same time.
A better approach would be start playing with a new build system
while majority of the developers stay on the current one.
And once the new system is in reasonable shape, plan a flag day
to phase out the old system.
> right now, the layout w/in vm/ is somewhat arbitrary :
In fact, you just have identified most of the cornerstones of the layout.
> 1) There is an include directory in parallel with the modules
>
> vm/include/*.h
This is intentional. These are VM-wide internal interfaces that are
used to communicate between pluggable VM components (VM Core, GC, JIT).
This is mostly defines interfaces between DLLs.
>
> 2) Some modules have their own include directories (vm/vmcore/include)
VM Core module is rather big, so it is split into several subcomponents.
The vmcore/include directory is for internal interfaces of VM Core, such
as exceptions. Note, that these interfaces are not exposed to DLL level.
> 3) Some don't (vm/em)
Small modules do not require dividing into smaller subcomponents,
thus do not have any module-wide include directories.
> 4) Some modules have src near the top :
>
> vm/em/src
In fact, *all* modules are supposed to have src/ subdirectory.
> 5) Some don't
>
> vm/tests/smoke/
This is just tests, which are not considered as a module.
>
> 6) Some modules have strange branches by language deep in the path :
>
> vm/vmcore/src/kernel_classes
> /javasrc
> /native
Again, this is intentional. It is used for separating java sources from c/c++
sources for modules that have both. Pure-language modules omit it.
> What do you think?
While I do not personally agree with some of the decisions, I think we have
better things to do than to revise this structure without a good reason.
I think it would be much better to describe the decisions behind the current structure
somewhere on the web or wiki. I could do it in a few days if someone else doesn't
volunteer to do it before.
P.S. If it was up to me, I would put all sources of each module (DLL) into one directory,
just like
drlvm/trunk
+ vm
+ *.cpp *.c *.java
+ gc
+ *.cpp
+ jit
+ *.cpp
+ Makefile
+ doc
+ *.html *.txt
P.P.S: do not take it seriously, it is a provocation :)
--
Salikh
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] src/test side-by-side with vm and build?
Posted by Salikh Zakirov <Sa...@Intel.com>.
Nathan Beyer wrote:
> We definitely need to do something. I spent the last few hours trying to
> build/add a "smoke test" for a patch [1] and have gotten absolutely no
> where. I had to change the "smoke.test.xml" file to compile against the JRE
> being built, so I could get it to compile, but after that I couldn't get it
> to PASS. I've given up for the moment. How do these tests work?
After you add the test into tests/smoke, you can just run
'build.bat test', and tests are compiled and run.
Some tests are skipped based on @keyword grepping, with
exclusion keywords being XXX, X_ia32, X_win etc.
> Can't I just create a JUnit TestCase, drop it into a test folder and have it
> run against the JRE that was built? The smoke tests just seem like an ad hoc
> JUnit framework. Do we need that?
I agree that we can replace smoke tests with junit tests now.
Smoke tests were very important at the initial stage of DRLVM development, because
- each test is a stand-alone program
- each test runs in a separate VM process
and thus they provided a environment
However, since DRLVM is now reasonably stable,
JUnit tests will serve just as well.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] src/test side-by-side with vm and build?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Beyer wrote:
> We definitely need to do something. I spent the last few hours trying to
> build/add a "smoke test" for a patch [1] and have gotten absolutely no
> where. I had to change the "smoke.test.xml" file to compile against the JRE
> being built, so I could get it to compile, but after that I couldn't get it
> to PASS. I've given up for the moment. How do these tests work?
Um - that's odd. I've just dropped tests in there and they just worked.
>
> Can't I just create a JUnit TestCase, drop it into a test folder and have it
> run against the JRE that was built? The smoke tests just seem like an ad hoc
> JUnit framework. Do we need that?
Well, how about this - can you start a JUnit based framework in the src/
directory for now, and we can join things at some point?
geir
>
> -Nathan
>
> [1] http://issues.apache.org/jira/browse/HARMONY-1144
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Monday, August 14, 2006 10:31 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [drlvm] src/test side-by-side with vm and build?
>>
>> No. Please. But keep in mind the stuff in src/ - how to build and wrap
>> those in JUnit / TestNG....
>>
>> geir
>>
>>
>> Nathan Beyer wrote:
>>> So, I presume there wouldn't be a huge problem with suggestions for
>>> adjusting the layout and using JUnit for the "smoke" tests.
>>>
>>> -Nathan
>>>
>>>> -----Original Message-----
>>>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>>>> Sent: Monday, August 14, 2006 1:46 PM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [drlvm] src/test side-by-side with vm and build?
>>>>
>>>>
>>>>
>>>> Zakirov, Salikh wrote:
>>>>> Hi,
>>>>>
>>>>> in the below commit Geir has added several dozens files
>>>>> under
>>>>>
>>>>> drlvm/trunk/src/test
>>>>>
>>>>> Since we have two directories on the top-level, build with build
>>>>> system, and vm with everything else (sources, tests, documentation),
>>>>> it seems very confusing to have 'src' directory at the top level.
>>>>>
>>>> Yep - I just wanted to park them somewhere as I wanted to close the
>>>> JIRAs that they came in. I thought that putting them in a conventional
>>>> place like 'src/test' would cause a violent allergic reaction in people
>>>> used to the unique innovation that is the DRLVM layout :)
>>>>
>>>>> Some time ago DRLVM team had very hot debates on directory structure,
>>>>> and we ended up with following structure:
>>>>>
>>>>> drlvm/trunk
>>>>> + vm
>>>>> + vmcore
>>>>> + jitrino
>>>>> + ... (other components)
>>>>> + doc (documentation)
>>>>> + tests (tests)
>>>>> + include (header files)
>>>>> + build (build system)
>>>>>
>>>>> The tests that are now checked into src/test look like they are put to
>> a
>>>>> wrong place.
>>>>> More correct place would be something like
>>>>>
>>>>> vm/tests/verifier
>>>>>
>>>>> Pavel, could you suggest a convenient place for your verifier tests?
>>>> Actually, we need to come up with a real test framework for these, and
>>>> hopefully pull the other tests out to join them. I thought I brought
>>>> this up in a JIRA or note to the dev list.
>>>>
>>>> While we're talking about it, should we consider a fresh layout for
>>>> DRLVM? Maybe we can switch to a make-based build at the same time...
>>>> right now, the layout w/in vm/ is somewhat arbitrary :
>>>>
>>>> 1) There is an include directory in parallel with the modules
>>>>
>>>> vm/include/*.h
>>>>
>>>> 2) Some modules have their own include directories (vm/vmcore/include)
>>>>
>>>> 3) Some don't (vm/em)
>>>>
>>>> 4) Some modules have src near the top :
>>>>
>>>> vm/em/src
>>>>
>>>> 5) Some don't
>>>>
>>>> vm/tests/smoke/
>>>>
>>>> 6) Some modules have strange branches by language deep in the path :
>>>>
>>>> vm/vmcore/src/kernel_classes
>>>> /javasrc
>>>> /native
>>>>
>>>> What do you think?
>>>>
>>>> geir
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [drlvm] src/test side-by-side with vm and build?
Posted by Nathan Beyer <nb...@kc.rr.com>.
We definitely need to do something. I spent the last few hours trying to
build/add a "smoke test" for a patch [1] and have gotten absolutely no
where. I had to change the "smoke.test.xml" file to compile against the JRE
being built, so I could get it to compile, but after that I couldn't get it
to PASS. I've given up for the moment. How do these tests work?
Can't I just create a JUnit TestCase, drop it into a test folder and have it
run against the JRE that was built? The smoke tests just seem like an ad hoc
JUnit framework. Do we need that?
-Nathan
[1] http://issues.apache.org/jira/browse/HARMONY-1144
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Monday, August 14, 2006 10:31 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [drlvm] src/test side-by-side with vm and build?
>
> No. Please. But keep in mind the stuff in src/ - how to build and wrap
> those in JUnit / TestNG....
>
> geir
>
>
> Nathan Beyer wrote:
> > So, I presume there wouldn't be a huge problem with suggestions for
> > adjusting the layout and using JUnit for the "smoke" tests.
> >
> > -Nathan
> >
> >> -----Original Message-----
> >> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> >> Sent: Monday, August 14, 2006 1:46 PM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: Re: [drlvm] src/test side-by-side with vm and build?
> >>
> >>
> >>
> >> Zakirov, Salikh wrote:
> >>> Hi,
> >>>
> >>> in the below commit Geir has added several dozens files
> >>> under
> >>>
> >>> drlvm/trunk/src/test
> >>>
> >>> Since we have two directories on the top-level, build with build
> >>> system, and vm with everything else (sources, tests, documentation),
> >>> it seems very confusing to have 'src' directory at the top level.
> >>>
> >> Yep - I just wanted to park them somewhere as I wanted to close the
> >> JIRAs that they came in. I thought that putting them in a conventional
> >> place like 'src/test' would cause a violent allergic reaction in people
> >> used to the unique innovation that is the DRLVM layout :)
> >>
> >>> Some time ago DRLVM team had very hot debates on directory structure,
> >>> and we ended up with following structure:
> >>>
> >>> drlvm/trunk
> >>> + vm
> >>> + vmcore
> >>> + jitrino
> >>> + ... (other components)
> >>> + doc (documentation)
> >>> + tests (tests)
> >>> + include (header files)
> >>> + build (build system)
> >>>
> >>> The tests that are now checked into src/test look like they are put to
> a
> >>> wrong place.
> >>> More correct place would be something like
> >>>
> >>> vm/tests/verifier
> >>>
> >>> Pavel, could you suggest a convenient place for your verifier tests?
> >> Actually, we need to come up with a real test framework for these, and
> >> hopefully pull the other tests out to join them. I thought I brought
> >> this up in a JIRA or note to the dev list.
> >>
> >> While we're talking about it, should we consider a fresh layout for
> >> DRLVM? Maybe we can switch to a make-based build at the same time...
> >> right now, the layout w/in vm/ is somewhat arbitrary :
> >>
> >> 1) There is an include directory in parallel with the modules
> >>
> >> vm/include/*.h
> >>
> >> 2) Some modules have their own include directories (vm/vmcore/include)
> >>
> >> 3) Some don't (vm/em)
> >>
> >> 4) Some modules have src near the top :
> >>
> >> vm/em/src
> >>
> >> 5) Some don't
> >>
> >> vm/tests/smoke/
> >>
> >> 6) Some modules have strange branches by language deep in the path :
> >>
> >> vm/vmcore/src/kernel_classes
> >> /javasrc
> >> /native
> >>
> >> What do you think?
> >>
> >> geir
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] src/test side-by-side with vm and build?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
No. Please. But keep in mind the stuff in src/ - how to build and wrap
those in JUnit / TestNG....
geir
Nathan Beyer wrote:
> So, I presume there wouldn't be a huge problem with suggestions for
> adjusting the layout and using JUnit for the "smoke" tests.
>
> -Nathan
>
>> -----Original Message-----
>> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>> Sent: Monday, August 14, 2006 1:46 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [drlvm] src/test side-by-side with vm and build?
>>
>>
>>
>> Zakirov, Salikh wrote:
>>> Hi,
>>>
>>> in the below commit Geir has added several dozens files
>>> under
>>>
>>> drlvm/trunk/src/test
>>>
>>> Since we have two directories on the top-level, build with build
>>> system, and vm with everything else (sources, tests, documentation),
>>> it seems very confusing to have 'src' directory at the top level.
>>>
>> Yep - I just wanted to park them somewhere as I wanted to close the
>> JIRAs that they came in. I thought that putting them in a conventional
>> place like 'src/test' would cause a violent allergic reaction in people
>> used to the unique innovation that is the DRLVM layout :)
>>
>>> Some time ago DRLVM team had very hot debates on directory structure,
>>> and we ended up with following structure:
>>>
>>> drlvm/trunk
>>> + vm
>>> + vmcore
>>> + jitrino
>>> + ... (other components)
>>> + doc (documentation)
>>> + tests (tests)
>>> + include (header files)
>>> + build (build system)
>>>
>>> The tests that are now checked into src/test look like they are put to a
>>> wrong place.
>>> More correct place would be something like
>>>
>>> vm/tests/verifier
>>>
>>> Pavel, could you suggest a convenient place for your verifier tests?
>> Actually, we need to come up with a real test framework for these, and
>> hopefully pull the other tests out to join them. I thought I brought
>> this up in a JIRA or note to the dev list.
>>
>> While we're talking about it, should we consider a fresh layout for
>> DRLVM? Maybe we can switch to a make-based build at the same time...
>> right now, the layout w/in vm/ is somewhat arbitrary :
>>
>> 1) There is an include directory in parallel with the modules
>>
>> vm/include/*.h
>>
>> 2) Some modules have their own include directories (vm/vmcore/include)
>>
>> 3) Some don't (vm/em)
>>
>> 4) Some modules have src near the top :
>>
>> vm/em/src
>>
>> 5) Some don't
>>
>> vm/tests/smoke/
>>
>> 6) Some modules have strange branches by language deep in the path :
>>
>> vm/vmcore/src/kernel_classes
>> /javasrc
>> /native
>>
>> What do you think?
>>
>> geir
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [drlvm] src/test side-by-side with vm and build?
Posted by Nathan Beyer <nb...@kc.rr.com>.
So, I presume there wouldn't be a huge problem with suggestions for
adjusting the layout and using JUnit for the "smoke" tests.
-Nathan
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Monday, August 14, 2006 1:46 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [drlvm] src/test side-by-side with vm and build?
>
>
>
> Zakirov, Salikh wrote:
> > Hi,
> >
> > in the below commit Geir has added several dozens files
> > under
> >
> > drlvm/trunk/src/test
> >
> > Since we have two directories on the top-level, build with build
> > system, and vm with everything else (sources, tests, documentation),
> > it seems very confusing to have 'src' directory at the top level.
> >
>
> Yep - I just wanted to park them somewhere as I wanted to close the
> JIRAs that they came in. I thought that putting them in a conventional
> place like 'src/test' would cause a violent allergic reaction in people
> used to the unique innovation that is the DRLVM layout :)
>
> > Some time ago DRLVM team had very hot debates on directory structure,
> > and we ended up with following structure:
> >
> > drlvm/trunk
> > + vm
> > + vmcore
> > + jitrino
> > + ... (other components)
> > + doc (documentation)
> > + tests (tests)
> > + include (header files)
> > + build (build system)
> >
> > The tests that are now checked into src/test look like they are put to a
> > wrong place.
> > More correct place would be something like
> >
> > vm/tests/verifier
> >
> > Pavel, could you suggest a convenient place for your verifier tests?
>
> Actually, we need to come up with a real test framework for these, and
> hopefully pull the other tests out to join them. I thought I brought
> this up in a JIRA or note to the dev list.
>
> While we're talking about it, should we consider a fresh layout for
> DRLVM? Maybe we can switch to a make-based build at the same time...
> right now, the layout w/in vm/ is somewhat arbitrary :
>
> 1) There is an include directory in parallel with the modules
>
> vm/include/*.h
>
> 2) Some modules have their own include directories (vm/vmcore/include)
>
> 3) Some don't (vm/em)
>
> 4) Some modules have src near the top :
>
> vm/em/src
>
> 5) Some don't
>
> vm/tests/smoke/
>
> 6) Some modules have strange branches by language deep in the path :
>
> vm/vmcore/src/kernel_classes
> /javasrc
> /native
>
> What do you think?
>
> geir
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] src/test side-by-side with vm and build?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Zakirov, Salikh wrote:
> Hi,
>
> in the below commit Geir has added several dozens files
> under
>
> drlvm/trunk/src/test
>
> Since we have two directories on the top-level, build with build
> system, and vm with everything else (sources, tests, documentation),
> it seems very confusing to have 'src' directory at the top level.
>
Yep - I just wanted to park them somewhere as I wanted to close the
JIRAs that they came in. I thought that putting them in a conventional
place like 'src/test' would cause a violent allergic reaction in people
used to the unique innovation that is the DRLVM layout :)
> Some time ago DRLVM team had very hot debates on directory structure,
> and we ended up with following structure:
>
> drlvm/trunk
> + vm
> + vmcore
> + jitrino
> + ... (other components)
> + doc (documentation)
> + tests (tests)
> + include (header files)
> + build (build system)
>
> The tests that are now checked into src/test look like they are put to a
> wrong place.
> More correct place would be something like
>
> vm/tests/verifier
>
> Pavel, could you suggest a convenient place for your verifier tests?
Actually, we need to come up with a real test framework for these, and
hopefully pull the other tests out to join them. I thought I brought
this up in a JIRA or note to the dev list.
While we're talking about it, should we consider a fresh layout for
DRLVM? Maybe we can switch to a make-based build at the same time...
right now, the layout w/in vm/ is somewhat arbitrary :
1) There is an include directory in parallel with the modules
vm/include/*.h
2) Some modules have their own include directories (vm/vmcore/include)
3) Some don't (vm/em)
4) Some modules have src near the top :
vm/em/src
5) Some don't
vm/tests/smoke/
6) Some modules have strange branches by language deep in the path :
vm/vmcore/src/kernel_classes
/javasrc
/native
What do you think?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org