Changes between Version 1 and Version 2 of KhairulGSOC2010Schedule

Timestamp:

06/27/10 23:00:24 (12 years ago)

Author:

cotto

Comment:

summarize weeks, add space for status

KhairulGSOC2010Schedule

@@ -3 +3 @@
 == week 1 (May 24th - 30th) ==
 
-Prototyping of the API. There are many ways to provide for the API for the instruments to hook into, as such, this will help to test the suitability of each method. An example will be to provide the instrument API as a DynPMC, with an initialization function in the instruments calling into and registering the callbacks. Another way will be to provide an instrument object, with each instrument being a method within this object (Thanks to Andrew Whitoworth for this suggestion). The least desirable way would be to scan for callbacks within the instruments, which may lead to problems later on (this is currently done in the proof of concept). Given the various ways to implement this, it would be prudent to have a week to prototype the various ways to ascertain their usability and flexibility, given the requirement that the API will grow quite a bit as the project progresses.
+Prototype the API.
+
+Status:
 
 == week 2 (May 31st - June 6th) ==
 
-Implement the base tool. With an API in place, implementing the base tool should be a rather straightforward affair, barring any unforseen pitfalls. One week should be enough to have the basic infrastructure in place, allowing for the implementation of the full instrument API in the following week.
+Implement the base tool.
+
+Status:
 
 == week 3 (June 7th - 13th) ==
 
-Implement simple instruments. With the basic infrastructure and API design, simple instruments such as instruction counters and call traces can be implemented as the API gets implemented. These instruments can serve as test cases for checking the correctness and flexibility of the base infrastructure and API. One week should be enough to iron out any required changes to the base and API.
+Implement simple instruments.
+
+Status:
 
 == week 4 (June 14th - 20th) ==
 
-Code Review and Documentation. I would think that as I go along, the codebase will get rather hairy, especially since I anticipate that the codebase will change many times over the previous 3 weeks. Having a week to review through the code and do some housekeeping will help greatly as I go along. Furthermore, this will give me the time to document the API that has been fixed as of this point in time, and document the design decisions made before the reasons for such a design is forgotten. This week would also require tests be created so that any regressions due to changes in the coming weeks can be easily detected. If possible, I would also like to investigate the possibility of inserting hooks into the Garbage Collection subsystem here.
+Code review, tests and documentation. If possible, add GC hooks.
+
+Status:
 
 == week 5 (June 21st - 27th) ==
 
-Instrument Query API. In this week and the next, I would like to design and implement the part of the API that allows instruments to query the execution environment of the code. This would enable more advance instruments, with the ability to record and inspect the current execution context and hopefully the internals of a PMC. I estimate this might take 2 to 3 weeks, as the world of the PMCs are rather murky to me at this point.
+Instrument Query API (2-3 weeks planned).
+
+Status:
 
 == week 6 (June 28th - July 4th) ==
 
-Instrument Query API. This week will be a continuation of the previous week. Hopefully the API will be concrete at this point.
+Instrument Query API (2nd week).
 
 == week 7 (July 5th - 11th) ==
 
-Implement advanced instruments. With the instrument query API in place, instruments such as exception and register monitors can be put in place. Since some tweaking of the API is expected, a week should allow for enough time to implement the required changes and the instruments.
+Implement advanced instruments, e.g. exception and register monitors.
+
+Status:
 
 == week 8 (July 12th - 18th) ==
 
-Code Review and Documentation.Similar to week 4, this week would include the review of code added to implement the instrument query API , documenting the design decisions and create tests to cover the new code added. With the query API in place, I would also like to explore building a simple debugger on top of the instruments to test the flexibility of the tool.
+Code review and documentation. Explore building a simple debugger as a test case for existing code.
+
+Status:
 
 == week 9 (July 19th - 25th) ==
 
-Breathing Space. Having a week here to account for any overruns would be prudent. If no overruns occurs, this week can be used to explore other possible uses for this tool.
+Catchup.  If time permits, explore other uses for instrumentation.
+
+Status:
 
 == week 10 (July 26th - August 1st) ==
 
-Finalizing of all APIs. As the end of the Summer of Code approaches, it would be good to finalize the APIs here so that finalization of the set of Instruments to be provided within the deliverables can be done. There will hopefully be no more changes to the API and the base infrastructure after this week.
+Finalizing of all APIs.
+
+Status:
 
 == week 11 (August 2nd - 8th) ==
 
-Finalizing the set of Instruments/Tools. Similar to Week 10, finalization of the Instruments/Tools should be completed within this week.
+Finalizing the set of Instruments/Tools.
+
+Status:
 
 == week 12 (August 9th - 15th) ==
 
-Final code Review and Documentation. Given that this is the final week of the project, finalising of the code, documentation and tests should be done. I would like to ensure that the code submitted does match Parrot's coding style and guidelines, and the documentation comprehensive enough such that it would be a good reference for others to implement their own tools.
+Final code review and documentation. Documentation should be comprehensive enough to implement independent tools using this code as a base.
 
+Status:
+