I do not like JIRA too, but sending patches by email is even worse:
1) There are a lot of opened JIRA issues. How to track them all by email?
2) New people have no access to the old email threads
3) Patches sometimes are too big to be sent by email.
On 10/4/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
Geir Magnusson Jr. wrote:
> Can you open a JIRA with this, explaining what needs to be done, and
> linking the other JIRAs as needed?
>
> Thx
>
> geir
>
> Salikh Zakirov wrote:
>> The patch turned out to be exact duplicate of HARMONY-1571.
>> Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
>>
>> The following change is needed on top of already committed HARMONY-1551
>> to make DRLVM start on Linux/x86_64.
>>
>> However, it still doesn't work properly, failing with
>> java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
>> Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
>> `!(vt() & 1)' failed.
>>
>> --- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
>> +++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
>> @@ -68,9 +68,9 @@ static void convertOperand2Opnd(
>> }
>>
>> #ifdef _IPF_
>> -static const char* get_reg_value(
>> +const char* InstructionDisassembler::get_reg_value(
>> InstructionDisassembler::Register reg,
>> - const Registers* pcontext)
>> + const Registers* pcontext) const
>> {
>> assert(0);
>> return NULL;
>> @@ -78,9 +78,9 @@ static const char* get_reg_value(
>>
>> #elif defined _EM64T_
>>
>> -static const char* get_reg_value(
>> +const char* InstructionDisassembler::get_reg_value(
>> InstructionDisassembler::Register reg,
>> - const Registers* pcontext)
>> + const Registers* pcontext) const
>> {
>> assert(0);
>> return NULL;
>>
>> Salikh Zakirov wrote:
>>> Hi gang,
>>>
>>> the below patch fixes the problem that prevents DRLVM from being
>>> compilable
>>> on Linux/x86_64.
>>>
>>> The TI itself does not work on x86_64, and the modification only fixes
>>> compiler error.
>>>
>>> diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> b/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> index d29ef32..b4180f6 100644
>>> --- a/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> +++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> @@ -502,7 +502,7 @@ #endif
>>>
>>> const InstructionDisassembler::Opnd& stub_op =
>>> stub_disasm.get_opnd(0);
>>> assert(stub_op.kind ==
InstructionDisassembler::Kind_Imm);
>>> - method = (Method *)stub_op.imm;
>>> + method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
>>> }
>>> }
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
