Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
One reason would be is that I don't know ant well enough to redesign
the whole stuff all together. I used the existing setup and init
targets which take care of including ancontrip and cctask jars.
If you ask me,
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
One reason would be is that I don't know ant well enough to redesign
the whole stuff all together. I used the existing setup and init
targets which take care of including ancontrip and cctask jars.
If you ask me, I'd prefer make in the
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote:
Ok I think I've come up with a reasonable compromise. I still used the
whole system of converting XML and all the stuff. It does quite a lot of
things in setup and init targets and using select is convenient. I
don't know how to
Gregory Shimansky wrote:
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote:
Ok I think I've come up with a reasonable compromise. I still used the
whole system of converting XML and all the stuff. It does quite a lot of
things in setup and init targets and using select is convenient.
Gregory,
I have checked the patch. I like it. Here are few notes.
* When I used ant there were no for tag [1]. I used autogenerated
ant files to run something in a loop. Solution with for takes less
place and is more readable.
* From my perspective 3 min timeout for a smoke test should be
Gregory Shimansky wrote:
On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote:
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.
.
You don't have enough cuts and bruises
On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote:
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.
.
You don't have enough cuts and bruises from working with the DRLVM
Geir Magnusson Jr. wrote:
Why not use junit?
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
On 11/2/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
Why not use junit?
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
Salikh Zakirov wrote:
Geir Magnusson Jr. wrote:
Why not use junit?
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
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
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
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)
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
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
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
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
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
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
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
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
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
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
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
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
24 matches
Mail list logo
