1 | * ehu reports on work on abcl-1.1.0 for 20120805 |
---|
2 | |
---|
3 | All in all a pretty good result for one week. However, from here on |
---|
4 | $WORK will start again which means I'll only be able to address the |
---|
5 | bigger issues in small steps. Or just the smaller issues, of |
---|
6 | course. Which is why I'm glad to have worked out the D-M-C stuff. That |
---|
7 | was a week more than full time work to completely comprehend the spec |
---|
8 | and macrology going on in our implementation. |
---|
9 | |
---|
10 | ** Work on DEFINE-METHOD-COMBINATION can be considered Done |
---|
11 | |
---|
12 | I left some todo's behind which should be relatively small in |
---|
13 | comparison to the original problem. It's now just a matter of changing |
---|
14 | the symbols in the backquote patterns. |
---|
15 | |
---|
16 | ** Autoloader rehab completed |
---|
17 | |
---|
18 | My work on the autoloader has been mostly done as far as our current |
---|
19 | infrastructure allows |
---|
20 | |
---|
21 | *** next steps: |
---|
22 | |
---|
23 | **** Clean autoload.lisp for any symbols which automatically end up in autoload-gen.lisp |
---|
24 | |
---|
25 | **** Create infrastructure for autoloading of SETF functions (ie function names not designated by a symbol) |
---|
26 | |
---|
27 | |
---|
28 | ** Crashes evaluating a form referencing an undefined function in a clean image |
---|
29 | |
---|
30 | Solved by requiring PRINT-OBJECT in the right place With respect to |
---|
31 | this point: it's possibly a good idea to do a search of the code base |
---|
32 | and find out if we're doing this everywhere PRINT-OBJECT methods are |
---|
33 | being defined |
---|
34 | |
---|
35 | ** COMPILER-UNSUPPORTED-FEATURE-ERROR derived from CONDITION |
---|
36 | |
---|
37 | solved |
---|
38 | |
---|
39 | ** Autoloader fails when *READ-xxx* variables bound to unexpected values |
---|
40 | |
---|
41 | solved |
---|
42 | |
---|
43 | ** Implement USE-FAST-CALLS properly |
---|
44 | |
---|
45 | Resolved by deleting the USE-FAST-CALLS infrastructure from the |
---|
46 | interpreter; the compiler already does the right thing |
---|
47 | |
---|
48 | ** Compiling #n# causes stack overflow |
---|
49 | |
---|
50 | Stas Boukarev reports that the case I've fixed only fixes in-memory |
---|
51 | compilation and the issue still exists in file |
---|
52 | ¯compilation. Ticket #191 should be re-opened to and should say so. |
---|