Changes between Version 5 and Version 6 of PIRCDevelopment

Show
Ignore:
Timestamp:
08/05/09 18:19:57 (12 years ago)
Author:
kjs
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PIRCDevelopment

    v5 v6  
    55= PIRC Status = 
    66 
    7 PIRC is not complete yet. All stages are implemented (lexer, parser, bytecode generator), but all of them need some additional work to complete them. 
    8  
     7PIRC is not complete yet. All stages are implemented (lexer, parser, bytecode generator), but all of them need some additional work to complete them. See the section below for the specific items that need to be fixed. Once these are fixed, PIRC will be done about 98%.  
    98 
    109= PIRC Development Tasks = 
    … …  
    1312 
    1413 * ticket #43: autoheaderize all PIRC sources.  
     14 
     15 * ticekt #55: decorate all function arguments with ARGIN macros etc. 
     16 
     17 * write tests for the generated output. 
    1518 
    1619== Hardcore hacking tasks == 
    … …  
    2326 * Convert all C strings in PIRC into STRINGs. All identifiers and strings that are scanned should be stored as STRING objects, not C strings. 
    2427 
    25  * Fix bug #198. It seems that when there is a sequence of more than one instruction dealing with STRINGs or NUMs, the resulting bytecode segfaults. Apparently, PIRC is emitting the wrong bytecode. Bug #186 is related to this issue. 
     28 * Fix ticket #198. It seems that when there is a sequence of more than one instruction dealing with STRINGs or NUMs, the resulting bytecode segfaults. Apparently, PIRC is emitting the wrong bytecode. Bug #186 is related to this issue. 
    2629 
    27  * Fix bug #173. Lexicals are not stored correctly in the generated bytecode. The code for storing the lexicals is taken from IMCC, and therefore it doesn't come as a complete surprise it's not working. However, I don't see what's wrong. 
     30 * Fix ticket #173. Lexicals are not stored correctly in the generated bytecode. The code for storing the lexicals is taken from IMCC, and therefore it doesn't come as a complete surprise it's not working. However, I don't see what's wrong. 
    2831 
    29  * Fix bug #14. Braced arguments to macros are not handled correctly. Nested macro expansion isn't correctly handled yet. 
     32 * Fix ticket #14. Braced arguments to macros are not handled correctly. Nested macro expansion isn't correctly handled yet. 
    3033 
     34 * Fix ticket #163. Keyed multi types must be implemented