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