On the 0x216 day of Apache Harmony Geir Magnusson, Jr. wrote: > Egor Pasko wrote: > > On the 0x216 day of Apache Harmony Geir Magnusson, Jr. wrote: > >> Sure, so use wiki as a community collaboration tool, and then point to > >> the JIRAs... > > OK, my suggestion was to put links to JIRA tasks from the page: > > http://wiki.apache.org/harmony/DRLVM%20newbie%20tasks > > Now I think you all agree. So I did it. > > :) > > Only further thought - how do I get to this page? Maybe I'm not > seeing it. From front page, there is the "TODO list" for DRLVM, but > there's no link to the 'newbie" page.
eee.. FrontPage -> TODO List For DRLVM -> Improve kernel classes/natives code sharing I was more lucky :) > Also, maybe organize these "newbie" tasks with the other tasks, but > mark them as "easy" or such? maybe. "JIT Development Tasks" are organized in this way. Or just change how the link reads? > geir > > > > >> 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 > >>> >> > >>> >> > >>> > > >>> > > > -- Egor Pasko
