HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/plain; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 07:04:30 GMT Content-length: 4489 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) Specific Details Read bytecode annotations and debug data from currently running code. This would effectively extend the debugger's "vocabulary" from PIR to all Parrot-supported HLL's. Add an interface for code instrumentation and introspection. This would not take very long as I may just borrow the code already present in parrot-instrument. Create an extension that would open an interpreter and be able to run code within it one opcode at a time. Implement a shell as a user interface. Will be able to able to interpret commands, display information about current location, etc. This may as simple as an NQP eval loop with a global dispatch table for user commands. Use the FileHandle PMC to make the command shell a little more friendly. We can also add command line editing, command history, and tab completion. A basic command set would include things like: Start and continue execution with the ability to add arguments if they're not specified on the command line. Creating breakpoints at a specific line or function. Watch Parrot registers (including PMC's). Stepping through code either forward or backward. Execute either a single PIR opcode or all opcodes until the next annotation line change. Changing the current working directory of the program. Backtrace using the CallContext and Exception PMC. Bytecode disassembly (possibly with pbc_dump). Scripting. For instance, interpreting a file as a set of debugger commands. There's much, much more that can be added in the future. These are just a few. Trace all open file handles. This would also mean it'd have to trace all child processes. Dynamic memory analysis. Check arguments to function calls for uninitialized or invalid values. Place a watch on all or individual PMC's to detect when it has been reclaimed by the garbage collector. Timeline: * To avoid redundancy, referring to "design" here will imply code design, unit test design, and documentation design. * At the beginning of each week, there will be a discussion with the mentor(s) to make a weekly outline and a set of goals describing what needs to be accomplished each week. Week 1 – Begin designing initial set of commands. A good starting point would be: enable/disable breakpoints, start/continue execution, stepping, print registers, source listing, help, etc. Week 2 – Begin writing unit tests for basic command set and shell. Once the unit tests are in place, begin writing code for commands. Verify that unit tests now pass. Week 3 – Begin designing backtrace command. Once the unit tests are in place, begin writing code for backtrace. Verify that unit tests now pass. Week 4 – Begin design and plan how to integrate parrot-instrument. This may mean borrowing code directly or using it as a guideline. Once the unit tests are in place, begin writing instrumentation code. Verify that unit tests now pass. Week 5 – With parrot-instrument in place, design framework for owning an interpreter for running code. Week 6 – Begin coding phase for interpreter. Once the unit tests are in place, begin writing code. Verify that unit tests now pass. Week 7 – At this point, it may be best to add a few more advanced commands. This could include: bytecode disassembly, command scripting, printing information about the interpreter, etc. This week would be spent on the design. Week 8 – Begin coding phase for new set of commands. Once the unit tests are in place, begin writing code. Verify that unit tests now pass. Week 9 – Begin design of commands for dynamic memory analysis. Week 10 – Begin coding phase for dynamic memory analysis. Once the unit tests are in place, begin writing code. Verify that unit tests now pass. This may not take too long so if things get finished early, get a head start on documentation. Week 11 – Review documentation and code examples, making any necessary improvements. At this point, it should be complete but if it's necessary, we can always include some more examples and documentation. Week 12 – Review code and units tests, making an necessary improvements. Go over it with a fine-tooth comb, so to speak. Week 13 – Reserved just in case things take a little longer.