File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type
Thank you.
How does the compiler know this when compiling jni.cpp? is there an
extern defn somewhere?
geir
Pavel Rebriy wrote:
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I renamed it something less innocuous like
global_env
vm_global_env
Something that gives the reader the hint that it's not a local var.
geir
Geir Magnusson Jr. wrote:
Thank you.
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I got it - thanks to Pavel.
There's an extern in init.h, and it's declared in vm_main.cpp.
Would anyone mind if I
Lets make a deal. If you do a fresh diff using svn diff for 1582 so I
can commit the thing, I'll wait ;)
geir
Evgueni Brevnov wrote:
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many conflicts.
Tnanks in advance.
Evgueni
On 10/6/06, Geir Magnusson Jr.
And it would only introduce a few, as far as I can tell, as only jni.cpp
and vm_main.cpp actually include init.h, and therefore are the only
files that depend on that global
geir
Evgueni Brevnov wrote:
Geir,
Please don't do that until HARMONY-1582 integration. It can introduce
many
Great news!
2006/10/6, Alex Blewitt [EMAIL PROTECTED]:
I managed to unpack a Pack200 file completely today for the first
time, so that by the end of it there were no bytes left in the queue.
Unfortunately, it wasn't a spectacularly exciting archive -- just one
interface with no methods (about
Anton,
Many thanks for exploring this area, it looks quite promising.
An idea: this service would become more valuable if presented
transparent search/comparison of results for particular tests over all
uploaded runs.
Let user enter name of a test and show in one table all known results
for this
I can't provide you with the fresh patch right now. I want to restrore
cunit tests first.
If it doesn't introduce many changes then go ahead and commit. It
should be easy to merge then.
Evgueni
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
And it would only introduce a few, as far as
;)
I'll wait - I was just teasing. I'm going to bed now...
geir
Evgueni Brevnov wrote:
I can't provide you with the fresh patch right now. I want to restrore
cunit tests first.
If it doesn't introduce many changes then go ahead and commit. It
should be easy to merge then.
Evgueni
On
On Thursday 05 October 2006 18:38, Geir Magnusson Jr. wrote:
w00t :)
Don't get too excited - it wouldn't be the first time that I've got no answer
to such a mail. But I'll follow up with a phone call on Monday if no reply by
then.
Do we need them to make a bulk contribution, or can we handle
On Thursday 05 October 2006 19:06, Tim Ellison wrote:
Apologies for drifting off-topic...
Is there a spec for the shape and behavior of headless SE and embeddable
SE etc.? I have only seen passing references to what they are and how
they act like SE.
SFAIK a headless SE is simply one for
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this out.
Geir,
To avoid possible duplication -
Alexey Varlamov wrote:
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this out.
Geir,
To
Chris Gray wrote:
On Thursday 05 October 2006 18:38, Geir Magnusson Jr. wrote:
w00t :)
Don't get too excited - it wouldn't be the first time that I've got no answer
to such a mail. But I'll follow up with a phone call on Monday if no reply by
then.
Do we need them to make a bulk
Hi committers!
Could someone look into the patch with [rmi] internationalization
HARMONY-1317?
Patch affects many source files and it would be great to apply it ASAP (if
it is OK of course:)) to avoid conflicts with another changes in the Harmony
svn.
Thanks,
Ilya.
On 10/4/06, Ilya Okomin
I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.
I just couldn't stop... no mental peace. :)
Geir
Thank you for your message - Id been round 10 times before I received it. ;)
Fedotov, Alexei A wrote:
BTW,
I really enjoyed the last item of the Quick Start section:
7. If building the DRLVM fails, read this README and follow building
instructions to the point.
A hardcore
Thanks for the fix, Alexei. I think this is a good start for updating the
README.
I've looked at the current version, and many other things are out-of-date (such
as ij as the name of our executable). Some things are also duplicated - we now
have the nice Quick Help pages for users [1] and
Oleg Khaschansky wrote:
So what happens to the patch on HARMONY-1723.
My opinion is that it is OK. Consider the following:
1. Applications bounded to the RI behavior (e.g. obtaining the
descriptors for read-only properties without construction of getter
name) won't fail.
2. Construction
seems like we got our patches in w/in 2 minutes of one another.
Take a look.
I'm going to bed.
I have a peace of mind now...
geir
Geir Magnusson Jr. wrote:
I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and
I was looking at the patch, and think we should just chuck the whole
README.txt, salvage what's good, put it on the website, and put a
pointer in the README.txt to the website.
geir
Morozova, Nadezhda wrote:
Thanks for the fix, Alexei. I think this is a good start for updating the
README.
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I have this almost done so that it uses the boot classpath generated by
not a worry - I learned a lot
Take a look at what I did and see if it's right :)
geir
Alexey Varlamov wrote:
Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.
2006/10/6,
+1
PS: we have a pointer to README, but it goes into SVN. I don't see anything
wrong with that - there should be some docs with sources.
Best regards,
Nadya Morozova
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Friday, October 06, 2006 1:18 PM
To:
On Friday 06 October 2006 09:29, Geir Magnusson Jr. wrote:
Who owns the copyright and can therefore make the donation?
Copyright in the original Wonka code belonged to Acunia, and hence now belongs
to Punch Telematix; there were also a few small contributions from outsiders
whom I'm fairly
On 10/6/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 6 October 2006 at 9:57, Tim Ellison [EMAIL PROTECTED] wrote:
Mark beat me to it, so you are in good hands.
And slightly regretting it... it's a big patch and one that's worth
being careful with ... mixing up messages would be very
Hi guys,
I obtained an assertion failure in EdgeProfiler.cpp:408 on
IA32/Windows/SPECjbb2005 with the attached config file.
Seems like not complicated bug.
Nikolay A. Sidelnikov
-
Terms of use :
On 10/5/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Ivan, could this enumeration scenario be possible?
1) JIT reports a base to GC
2) GC relocates the base and updates references.
3) JIT reports MPTR, looks for the base, founds the patched base on the
stack and the resulting offset becomes
Hi Nikolay,
The patch for this bug is in
http://issues.apache.org/jira/browse/HARMONY-1689
The current version of edge profiler can really lead to a crush in server
mode.
On 10/6/06, Sidelnikov, Nikolay A [EMAIL PROTECTED] wrote:
Hi guys,
I obtained an assertion failure in
Ivan,
the problem is described in the example in H1682, I can add it to the email
thread to invite other GC/JIT gurus to participate in the discussion.
The example:
JIT has 2 references to report. Both of them point to the same object. JIT
expects that both references are updated when GC moves
I failed to run any application with -Xem:jet (and -Xem:opt as well) set in
harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I
even copied that file from Windows 2003 machine to XP machine but this did
not help.
java Test gives me the following:
An unhandled error (4)
I'm glad I do not update classlib files more then once per day and do it
almost every hour for drlvm only.
So if you do not need the latest changes from classlib you can try to take
an older version:
This one is about 16 hour old and worked for me yesterday:
svn update -r 453209
On 10/6/06,
This is not the same. In your example, if the second reference points
to previous position of object it will be automatically updated
according to installed forwarding pointer.
We have different problem. The reported offset within object is
incorrect, as the base is taken from new location of
Alexey,
I've added both options - search by test name and list of tests that
ever failed. The second one is very big because of results you've
uploaded for DRLVM/Linux with 554 errors. Please tell me if you want
to change anything in the interface.
On 10/6/06, Alexey Varlamov [EMAIL PROTECTED]
Egor,
I've marked this bug with 'minor' priority because it didn't affect
any known application and didn't cause crash. Seems that Alexey
struggles for absence of JUnit tests failures because of DRLVM bugs,
that's why he promoted the bug.
P.S. you are promoting a low-priority bug while there
Thanks for prompt response!
Those 554 errors on interpreter are due to fork mode=once, it is a
single error affecting the whole run. Is there a way to delete an
uploaded run?
Better yet, to be able select a range of runs to include to analysis.
The appetite comes with eating :)
Criteria to
Hi Oleg,
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
Ivan,
I'm agree that the problem we have is more complicated then my example. And
I'm glad to hear that there are no problem with the scenario from my example
today.
Jitrino.OPT uses 3 interface methods to report GC root set:
1. VMEXPORT void vm_enumerate_root_reference(Managed_Object_Handle
Ok. I am testing another patch for the TransferHandler which won't affect beans.
On 10/6/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi Oleg,
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method
Hello,
Those 554 errors on interpreter are due to fork mode=once, it is a
single error affecting the whole run. Is there a way to delete an
uploaded run?
I've added a possibility to delete run for a registered user. Please
send me login/password if you want to have such possibility.
Better
Weldon, All
Here is the updated vm/vmcore/sync_bit.h header file.
That, I think, describes current state of the object header.
I olso try define rules: How to update the header correctly.
Welcome to discussion on them.
#ifndef _sync_bits_H
#define _sync_bits_H
/**
* These defines describe
Alexey,
Thank you for your response.
As I understood I'm working on the same problem,
I write scripts to run different tests(cunit, classlib, smoke, kernel,
specjvm98) and collect statistics.
I do it to track patch which was reason of failure of any test. So bug
propagation would be stopped.
The
Ok - I'll grab your -Xbootclasspath stuff...
Alexey Varlamov wrote:
(Cross-posted from JIRA):
OK, we should combine both patches. The
-Dorg.apache.harmony.vm.vmdir= of yours is logical continuation
towards multiVM-WS feature. And my patch more correctly handles
-Xbootclasspath[/ap]: options.
Chris Gray wrote:
On Friday 06 October 2006 09:29, Geir Magnusson Jr. wrote:
Who owns the copyright and can therefore make the donation?
Copyright in the original Wonka code belonged to Acunia, and hence now belongs
to Punch Telematix; there were also a few small contributions from
joke
What did the application's support team say?
/joke?
Elena Semukhina wrote:
I failed to run any application with -Xem:jet (and -Xem:opt as well) set in
harmonyvm.properties on my Windows XP while I succeeded on Windows 2003. I
even copied that file from Windows 2003 machine to XP machine
Salikh Zakirov wrote:
Currently DRLVM build system suffers from a deficiency,
which gets in the way quickly if you experiment a lot with patches.
If you apply a patch that creates a new file, and build DRLVM, and
then unapply the patch, and rebuild again,
the stale .obj file will still get
Tim,
I attached a patch which doesn't have side effects to HARMONY-1723 :)
--
Oleg
On 10/6/06, Tim Ellison [EMAIL PROTECTED] wrote:
Oleg Khaschansky wrote:
So what happens to the patch on HARMONY-1723.
My opinion is that it is OK. Consider the following:
1. Applications bounded to the RI
The submitted revision is downloadable in JIRA-1428 at:
http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip
Attached in this email is the gc.xml file I am using that replaces
existing one for building gc.
Below is the submission description:
Attached file gcv5-r0.10.zip is
I was hoping you'd take the hint and limit the patch to just solving the
stated problem. Extra refactoring just makes it harder - it can always
be done as a followup.
Anyway, looking at it now.
geir
Alexey Varlamov wrote:
I observed such problem too. The HARMONY-1376 patch fixes this for
While nobody objects :) the right place for coverage scripts is 'buildtest'
module.
Seems, that this module should be a little bit reorder: new top level
directories should be created:
- 'cc' - for cruise control script (and move current stuff to this dir);
- 'coverage' - for coverage scripts
Salikh Zakirov wrote:
Geir replied:
make?
I know you are teasing (^_-)
I'm actually not. Were there an additional 24 hours in a day There
is a whole list of reasons why I'm not a fan of the current system,
including maintainability as well as performance. (Building classlib
Xiao-Feng Li wrote:
The submitted revision is downloadable in JIRA-1428 at:
http://issues.apache.org/jira/secure/attachment/12342430/gcv5-r0.10.zip
Nice! w00t!
Attached in this email is the gc.xml file I am using that replaces
existing one for building gc.
Please attach that to the
Vladimir Ivanov wrote:
While nobody objects :) the right place for coverage scripts is 'buildtest'
module.
Seems, that this module should be a little bit reorder: new top level
directories should be created:
- 'cc' - for cruise control script (and move current stuff to this dir);
-
Good progress. I will plug GCV5 in today or tomorrow and report what runs.
Provided this code sits well w/ drlvm tree, I will go ahead an commit to
vm/gcv5
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Xiao-Feng Li wrote:
The submitted revision is downloadable in JIRA-1428 at:
Can you make it selectable for build? IOW
sh build.sh -Dbuild.gc=5
or something...
Weldon Washburn wrote:
Good progress. I will plug GCV5 in today or tomorrow and report what runs.
Provided this code sits well w/ drlvm tree, I will go ahead an commit to
vm/gcv5
On 10/6/06, Geir Magnusson
On 6 October 2006 at 9:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
While nobody objects :) the right place for coverage scripts is 'buildtest'
module.
Seems, that this module should be a little bit reorder: new top level
directories should be created:
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Can you make it selectable for build? IOW
sh build.sh -Dbuild.gc=5
or something...
Good idea. Maybe even better would be to have ALL gc's always build and
make them selectable on the command line.
Weldon Washburn wrote:
Good
On Wed, 4 Oct 2006, Geir Magnusson Jr. wrote:
|
|
| Tim Ellison wrote:
| Geir Magnusson Jr. wrote:
| +1
|
| BTW, why call it RepositionLock?
|
| That was just an example taken from the class I was looking at, I've
| called them different names depending upon the inst var name.
|
| Oh,
Thanks - maybe someone can massage that to fit with what we're building...
Mark Hindess wrote:
On 6 October 2006 at 9:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
While nobody objects :) the right place for coverage scripts is 'buildtest'
module.
Seems, that this
Geir Magnusson Jr. wrote:
make?
Salikh Zakirov wrote:
I know you are teasing (^_-)
Geir replied:
I'm actually not. Were there an additional 24 hours in a day There
is a whole list of reasons why I'm not a fan of the current system,
including maintainability as well as performance.
Dear all,
Please go to https://issues.apache.org/jira/browse/HARMONY-1631 to find a
patch for README.txt. Could you please find a chance to check whether the
information is up-to date?
(pay special attention to KNOWN ISSUES and TODO sections)
In this connection I'd like to ask you to:
1.
Weldon Washburn wrote:
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Can you make it selectable for build? IOW
sh build.sh -Dbuild.gc=5
or something...
Good idea. Maybe even better would be to have ALL gc's always build and
make them selectable on the command line.
I am happy to inform that I created a jira #1758 [1] for this task and
attached a first patch.
Also, I'd like to attract attention to several patches for the
awt/swing modules:
swing
#1536
#1533
#1509
#1475
awt
#1647
#1652
#1659
[1] http://issues.apache.org/jira/browse/HARMONY-1758
On
I have a problem with how we do eclipse meta-data in classlib, and I'm
guessing there's some cool trick everyone else knows about.
Right now, tree has lots of mods to modules/*/.settings/* and
modules/*/.classpath, resulting in pain and suffering when I try to do a
commit that spans multiple
Nadya, here is my 2 cents:
On 10/6/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote:
Dear all,
Please go to https://issues.apache.org/jira/browse/HARMONY-1631 to find a
patch for README.txt. Could you please find a chance to check whether the
information is up-to date?
(pay special attention
I'm about to commit 1376, and having tested w/ DRLVM's tests, I decided
to try J9 w/ classlib test suite.
Is JarOutputStreamTest failing for anyone else?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
Thanks. You can unzip it under gc/ directory after moving the original
src/ tree. Note it has a dependent patch in JIRA for JET write
barrier. There is also a one liner fix to in the JIRA.
Thanks,
xiaofeng
On 10/6/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Good progress. I will plug GCV5
Why don't we just add this info to the getting started pages on the
website?It's somewhat repetitive and we should just maintain in one
place.
Morozova, Nadezhda wrote:
Dear all,
Please go to https://issues.apache.org/jira/browse/HARMONY-1631 to find a
patch for README.txt. Could you
never mind - local problem w/ fork() failing...
Geir Magnusson Jr. wrote:
I'm about to commit 1376, and having tested w/ DRLVM's tests, I decided
to try J9 w/ classlib test suite.
Is JarOutputStreamTest failing for anyone else?
geir
Can we not put it in gc/? How about gcv5/ ?
Xiao-Feng Li wrote:
Thanks. You can unzip it under gc/ directory after moving the original
src/ tree. Note it has a dependent patch in JIRA for JET write
barrier. There is also a one liner fix to in the JIRA.
Thanks,
xiaofeng
On 10/6/06, Weldon
I like the README.txt file from the classlib . It helped me a lot when I
built classlib first time, so let's keep README for DRLVM too.
But classlib's README file is 2 times shorter than DRLVM's version - so it's
easier to read it.
I vote to leave in README file only info needed for a successful
There's a maintenance issue here. The point of the quickstart guides is
just that - to help someone build for the first time...
Mikhail Fursov wrote:
I like the README.txt file from the classlib . It helped me a lot when I
built classlib first time, so let's keep README for DRLVM too.
But
MMTk gurus!
I'm working on MMTk 'unboxed' package support in DRLVM. I hope I finished
the implementation, but because of the scant comments in JAVA docs (like
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/Offset.html) I feel
that I do not completely understand the semantics of some
Geir,
That's terrible. We have power outageservers are down. I can't
send the patches now will do it tomorrow
Evgueni
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
woo hoo! here we go...
Andrey Chernyshev wrote:
Hi Evgueni,
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED]
On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Ivan,
I'm agree that the problem we have is more complicated then my example. And
I'm glad to hear that there are no problem with the scenario from my example
today.
Jitrino.OPT uses 3 interface methods to report GC root set:
1. VMEXPORT
On 10/6/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
A major design concept in this revision that was not made very clear
in previous submissions is space. GC is a concept of a full (or
standalone) garbage collector design. One GC can have multiple spaces,
each of which can employ different
Nooo! LOL
I'm here waiting - This will unblock a whole bunch of things :)
Thanks for the effort
Evgueni Brevnov wrote:
Geir,
That's terrible. We have power outageservers are down. I can't
send the patches now will do it tomorrow
Evgueni
On 10/5/06, Geir Magnusson Jr. [EMAIL
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
I was hoping you'd take the hint and limit the patch to just solving the
stated problem. Extra refactoring just makes it harder - it can always
be done as a followup.
Yeah, this was miscommunicated - I thought I provided enugh
justification for
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I would like to have second variant implemented and corresponding
(method3) interface removed as unused anymore. But, I'm not sure if
this is possible. Thread stack enumeration is just a part of root set
enumeration process. Roots can be
Actually you'd only need 2 changes over my patch:
1) change the path to kernel.jar in classloader.cpp (and in build
scripts accordingly :);
2) add smth like
-Dorg.apache.harmony.vm.path=%JAVA_HOME%/bin/%VM_DIR% to
harmonyvm.properties
2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
Ok - I'll
Fine. Tell me what's wrong with mine. Why? Not because I care that
much, but because this soup of properties is a mess, and this is a good
time to clean this up.
Actually, I'll start a new thread. Please participate. :)
geir
Alexey Varlamov wrote:
Actually you'd only need 2 changes
Hello all,
This thread is about a way to improve stability in the environment of
growing patch flow in Harmony. Originally I though about DRLVM issues
but this may be helpful for classlib too.
Currenly, before committing a patch a committer checks it on his
favorite configurations (I mean
On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I would like to have second variant implemented and corresponding
(method3) interface removed as unused anymore. But, I'm not sure if
this is possible. Thread stack enumeration is just a
So one of the interesting things that jumped out of me is the number of
various library and boot classpath properties that we have floating
around, and I'd like to
1) understand this
2) get rid of all the ones that we don't need
Is there a defined set we need to support? Anyone have
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
If it is possible to get somehow valid offset within object then it is
great! I would be happy to see this solved this way. Waiting for your
patch.
Yes, before reporting all objects and mptr for a method JIT is able to
calculate offsets and
Pavel,
Your idea has sence. But... Are you sure that all the committers has
all the mentioned configurations?
SY, Alexey
2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]:
Hello all,
This thread is about a way to improve stability in the environment of
growing patch flow in Harmony. Originally I
According to the good issue resolution guideline I am forwarding
this to the dev. list.
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Oct 6, 2006 8:58 PM
Subject: [jira] Updated: (HARMONY-1763) [classlib][beans] method
2006/10/6, Anton Luht [EMAIL PROTECTED]:
Hello,
Those 554 errors on interpreter are due to fork mode=once, it is a
single error affecting the whole run. Is there a way to delete an
uploaded run?
I've added a possibility to delete run for a registered user. Please
send me login/password if
Alexey,
No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I doubt all of them have
EM64T. This is indeed the problem and I hope together we will find the
solution. For example, we may not require classlib commits to be
tested on
Oleg,
Can we write the same logic a little bit nicer?
Something like:
public boolean equals(Object object) {
-boolean result = (object != null object instanceof
PropertyDescriptor);
-if (result) {
+boolean result = false;
+
+if (object != null object
Vera,
I'm not sure I understood your intention. Do you want to monitor
regressions routinely a la CruiseControl? Or you need an automated
failure analyzer which bisects commits and finds flawed commit?
2006/10/6, Volynets, Vera [EMAIL PROTECTED]:
Alexey,
Thank you for your response.
As I
I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
On 10/6/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
Alexey,
No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I doubt all of them have
EM64T. This is
Realistically, we could probably just eliminate all of the Eclipse IDE
files, as they don't really work out of the box anyway, so I always
end up tweaking them anyway or tweaking my setup. For those who do use
Eclipse IDE, a simple script could be create to generate the
appropriate artifacts or
I'm also not sure that ALL the commiters has Windows and Linux at the
same time...
And Nathan is an example :)
SY, Alexey
2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]:
Alexey,
No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I
What would you do if you need to commit a patch to some Linux-specific
code in VM?
The commit criteria my be either as simple as a list of configs or
have also some exclusions. For example, there is no much sense to test
on Linux a patch for a source file which is not even compiled on
Windows.
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Can you make it selectable for build? IOW
sh build.sh -Dbuild.gc=5
or something...
Good idea. Maybe even better would be to have ALL gc's always
On 10/7/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
What would you do if you need to commit a patch to some Linux-specific
code in VM?
The commit criteria my be either as simple as a list of configs or
have also some exclusions. For example, there is no much sense to test
on Linux a patch for a
2006/10/6, Pavel Ozhdikhin [EMAIL PROTECTED]:
What would you do if you need to commit a patch to some Linux-specific
code in VM?
And I do not have Linux?
I will not commit this patch of course. And will ask another committer
to do this.
Pavel, again. I understand your concern and I think that
I think it would be nice if we had examples in bundle form of different
usage models.
We could drop those into SVN too,a nd people could just take them and
overlay...
geir
Nathan Beyer wrote:
Realistically, we could probably just eliminate all of the Eclipse IDE
files, as they don't
1 - 100 of 116 matches
Mail list logo
