Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/HISTORY
ViewVC logotype

Diff of /sml/trunk/HISTORY

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1066, Thu Feb 14 16:50:02 2002 UTC revision 1145, Fri Mar 15 02:30:53 2002 UTC
# Line 14  Line 14 
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16  Name: Matthias Blume  Name: Matthias Blume
17    Date: 2002/03/14 21:30:00 EST
18    Tag: blume-20020314-controls
19    Description:
20    
21    Controls:
22    ---------
23    
24    1. Factored out the recently-added Controls : CONTROLS stuff and put
25       it into its own library $/controls-lib.cm.  The source tree for
26       this is under src/smlnj-lib/Controls.
27    
28    2. Changed the names of types and functions in this interface, so they
29       make a bit more "sense":
30    
31          module -> registry
32          'a registry -> 'a group
33    
34    3. The interface now deals in ref cells only.  The getter/setter interface
35       is (mostly) gone.
36    
37    4. Added a function that lets one register an already-existing ref cell.
38    
39    5. Made the corresponding modifications to the rest of the code so that
40       everything compiles again.
41    
42    6. Changed the implementation of Controls.MLRISC back to something closer
43       to the original.  In particular, this module (and therefore MLRISC)
44       does not depend on Controls.  There now is some link-time code in
45       int-sys.sml that registers the MLRISC controls with the Controls
46       module.
47    
48    CM:
49    ---
50    
51      * One can now specify the lambda-split aggressiveness in init.cmi.
52    
53    ----------------------------------------------------------------------
54    Name: Allen Leung
55    Date: 2002/03/13 17:30:00 EST
56    Tag: leunga-20020313-x86-fp-unary
57    Description:
58    
59    Bug fix for:
60    
61    > leunga@weaselbane:~/Yale/tmp/sml-dist{21} bin/sml
62    > Standard ML of New Jersey v110.39.1 [FLINT v1.5], March 08, 2002
63    > - fun f(x,(y,z)) = Real.~ y;
64    > [autoloading]
65    > [autoloading done]
66    >       fchsl   (%eax), 184(%esp)
67    > Error: MLRisc bug: X86MCEmitter.emitInstr
68    >
69    > uncaught exception Error
70    >   raised at: ../MLRISC/control/mlriscErrormsg.sml:16.14-16.19
71    
72    The problem was that the code generator did not generate any fp registers
73    in this case, and the ra didn't know that it needed to run the X86FP phase to
74    translate the pseudo fp instruction.   This only happened with unary fp
75    operators in certain situations.
76    
77    ----------------------------------------------------------------------
78    Name: Matthias Blume
79    Date: 2002/03/13 14:00:00 EST
80    Tag: blume-20020313-overload-etc
81    Description:
82    
83    1. Added _overload as a synonym for overload for backward compatibility.
84       (Control.overloadKW must be true for either version to be accepted.)
85    
86    2. Fixed bug in install script that caused more things to be installed
87       than what was requested in config/targets.
88    
89    3. Made CM aware of the (_)overload construct so that autoloading
90       works.
91    
92    ----------------------------------------------------------------------
93    Name: Matthias Blume
94    Date: 2002/03/12 22:03:00 EST
95    Tag: blume-20020312-url
96    Description:
97    
98    Forgot to update BOOT and srcarchiveurl.
99    
100    ----------------------------------------------------------------------
101    Name: Matthias Blume
102    Date: 2002/03/12 17:30:00 EST
103    Tag: blume-20020312-version110392
104    Description:
105    
106    Yet another version number bump (because of small changes to the
107    binfile format).  Version number is now 110.39.2.  NEW BOOTFILES!
108    
109    Changes:
110    
111      The new pid generation scheme described a few weeks ago was overly
112      complicated.  I implemented a new mechanism that is simpler and
113      provides a bit more "stability":  Once CM has seen a compilation
114      unit, it keeps its identity constant (as long as you do not delete
115      those crucial CM/GUID/* files).  This means that when you change
116      an interface, compile, then go back to the old interface, and
117      compile again, you arrive at the original pid.
118    
119      There now also is a mechanism that instructs CM to use the plain
120      environment hash as a module's pid (effectively making its GUID
121      the empty string).  For this, "noguid" must be specified as an
122      option to the .sml file in question within its .cm file.
123      This is most useful for code that is being generated by tools such
124      as ml-nlffigen (because during development programmers tend to
125      erase the tool's entire output directory tree including CM's cached
126      GUIDs).  "noguid" is somewhat dangerous (since it can be used to locally
127      revert to the old, broken behavior of SML/NJ, but in specific cases
128      where there is no danger of interface confusion, its use is ok
129      (I think).
130    
131      ml-nlffigen by default generates "noguid" annotations.  They can be
132      turned off by specifying -guid in its command line.
133    
134    ----------------------------------------------------------------------
135    Name: Lal George
136    Date: 2002/03/12 12 14:42:36 EST
137    Tag: george-20020312-frequency-computation
138    Description:
139    
140    Integrated jump chaining and static block frequency into the
141    compiler. More details and numbers later.
142    
143    ----------------------------------------------------------------------
144    Name: Lal George
145    Date: 2002/03/11 11 22:38:53 EST
146    Tag: george-20020311-jump-chain-elim
147    Description:
148    
149    Tested the jump chain elimination on all architectures (except the
150    hppa).  This is on by default right now and is profitable for the
151    alpha and x86, however, it may not be profitable for the sparc and ppc
152    when compiling the compiler.
153    
154    The gc test will typically jump to a label at the end of the cluster,
155    where there is another jump to an external cluster containing the actual
156    code to invoke gc. This is to allow factoring of common gc invocation
157    sequences. That is to say, we generate:
158    
159            f:
160               testgc
161               ja   L1      % jump if above to L1
162    
163            L1:
164               jmp L2
165    
166    
167    After jump chain elimination the 'ja L1' instructions is converted to
168    'ja L2'. On the sparc and ppc, many of the 'ja L2' instructions may end
169    up being implemented in their long form (if L2 is far away) using:
170    
171            jbe     L3      % jump if below or equal to L3
172            jmp     L2
173         L3:
174            ...
175    
176    
177    For large compilation units L2  may be far away.
178    
179    
180    ----------------------------------------------------------------------
181    Name: Matthias Blume
182    Date: 2002/03/11 13:30:00 EST
183    Tag: blume-20020311-mltreeeval
184    Description:
185    
186    A functor parameter was missing.
187    
188    ----------------------------------------------------------------------
189    Name: Allen Leung
190    Date: 2002/03/11 10:30:00 EST
191    Tag: leunga-20020311-runtime-string0
192    Description:
193    
194       The representation of the empty string now points to a
195    legal null terminated C string instead of unit.  It is now possible
196    to convert an ML string into C string with InlineT.CharVector.getData.
197    This compiles into one single machine instruction.
198    
199    ----------------------------------------------------------------------
200    Name: Allen Leung
201    Date: 2002/03/10 23:55:00 EST
202    Tag: leunga-20020310-x86-call
203    Description:
204    
205       Added machine generation for CALL instruction (relative displacement mode)
206    
207    ----------------------------------------------------------------------
208    Name: Matthias Blume
209    Date: 2002/03/08 16:05:00
210    Tag: blume-20020308-entrypoints
211    Description:
212    
213    Version number bumped to 110.39.1.  NEW BOOTFILES!
214    
215    Entrypoints: non-zero offset into a code object where execution should begin.
216    
217    - Added the notion of an entrypoint to CodeObj.
218    - Added reading/writing of entrypoint info to Binfile.
219    - Made runtime system bootloader aware of entrypoints.
220    - Use the address of the label of the first function given to mlriscGen
221      as the entrypoint.  This address is currently always 0, but it will
222      not be 0 once we turn on block placement.
223    - Removed the linkage cluster code (which was The Other Way(tm) of dealing
224      with entry points) from mlriscGen.
225    
226    ----------------------------------------------------------------------
227    Name: Allen Leung
228    Date: 2002/03/07 20:45:00 EST
229    Tag: leunga-20020307-x86-cmov
230    Description:
231    
232       Bug fixes for CMOVcc on x86.
233    
234       1. Added machine code generation for CMOVcc
235       2. CMOVcc is now generated in preference over SETcc on PentiumPro or above.
236       3. CMOVcc cannot have an immediate operand as argument.
237    
238    ----------------------------------------------------------------------
239    Name: Matthias Blume
240    Date: 2002/03/07 16:15:00 EST
241    Tag: blume-20020307-controls
242    Description:
243    
244    This is a very large but mostly boring patch which makes (almost)
245    every tuneable compiler knob (i.e., pretty much everything under
246    Control.* plus a few other things) configurable via both the command
247    line and environment variables in the style CM did its configuration
248    until now.
249    
250    Try starting sml with '-h' (or, if you are brave, '-H')
251    
252    To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
253    implements the underlying generic mechanism.
254    
255    The interface to some of the existing such facilities has changed somewhat.
256    For example, the MLRiscControl module now provides mkFoo instead of getFoo.
257    (The getFoo interface is still there for backward-compatibility, but its
258    use is deprecated.)
259    
260    The ml-build script passes -Cxxx=yyy command-line arguments through so
261    that one can now twiddle the compiler settings when using this "batch"
262    compiler.
263    
264    TODO items:
265    
266    We should go through and throw out all controls that are no longer
267    connected to anything.  Moreover, we should go through and provide
268    meaningful (and correct!) documentation strings for those controls
269    that still are connected.
270    
271    Currently, multiple calls to Controls.new are accepted (only the first
272    has any effect).  Eventually we should make sure that every control
273    is being made (via Controls.new) exactly once.  Future access can then
274    be done using Controls.acc.
275    
276    Finally, it would probably be a good idea to use the getter-setter
277    interface to controls rather than ref cells.  For the time being, both
278    styles are provided by the Controls module, but getter-setter pairs are
279    better if thread-safety is of any concern because they can be wrapped.
280    
281    *****************************************
282    
283    One bug fix: The function blockPlacement in three of the MLRISC
284    backpatch files used to be hard-wired to one of two possibilities at
285    link time (according to the value of the placementFlag).  But (I
286    think) it should rather sense the flag every time.
287    
288    *****************************************
289    
290    Other assorted changes (by other people who did not supply a HISTORY entry):
291    
292    1. the cross-module inliner now works much better (Monnier)
293    2. representation of weights, frequencies, and probabilities in MLRISC
294       changed in preparation of using those for weighted block placement
295       (Reppy, George)
296    
297    ----------------------------------------------------------------------
298    Name: Lal George
299    Date: 2002/03/07 14:44:24 EST 2002
300    Tag: george-20020307-weighted-block-placement
301    
302    Tested the weighted block placement optimization on all architectures
303    (except the hppa) using AMPL to generate the block and edge frequencies.
304    Changes were required in the machine properties to correctly
305    categorize trap instructions. There is an MLRISC flag
306    "weighted-block-placement" that can be used to enable weighted block
307    placement, but this will be ineffective without block/edge
308    frequencies (coming soon).
309    
310    
311    ----------------------------------------------------------------------
312    Name: Lal George
313    Date: 2002/03/05 17:24:48 EST
314    Tag: george-20020305-linkage-cluster
315    
316    In order to support the block placement optimization, a new cluster
317    is generated as the very first cluster (called the linkage cluster).
318    It contains a single jump to the 'real' entry point for the compilation
319    unit. Block placement has no effect on the linkage cluster itself, but
320    all the other clusters  have full freedom in the manner in which they
321    reorder blocks or functions.
322    
323    On the x86 the typical linkage code that is generated is:
324       ----------------------
325            .align 2
326       L0:
327            addl    $L1-L0, 72(%esp)
328            jmp     L1
329    
330    
331            .align  2
332       L1:
333       ----------------------
334    
335    72(%esp) is the memory location for the stdlink register. This
336    must contain the address of the CPS function being called. In the
337    above example, it contains the address of  L0; before
338    calling L1 (the real entry point for the compilation unit), it
339    must contain the address for L1, and hence
340    
341            addl $L1-L0, 72(%esp)
342    
343    I have tested this on all architectures except the hppa.The increase
344    in code size is of course negligible
345    
346    ----------------------------------------------------------------------
347    Name: Allen Leung
348    Date: 2002/03/03 13:20:00 EST
349    Tag: leunga-20020303-mlrisc-tools
350    
351      Added #[ ... ] expressions to mlrisc tools
352    
353    ----------------------------------------------------------------------
354    Name: Matthias Blume
355    Date: 2002/02/27 12:29:00 EST
356    Tag: blume-20020227-cdebug
357    Description:
358    
359    - made types in structure C and C_Debug to be equal
360    - got rid of code duplication (c-int.sml vs. c-int-debug.sml)
361    - there no longer is a C_Int_Debug (C_Debug is directly derived from C)
362    
363    ----------------------------------------------------------------------
364    Name: Matthias Blume
365    Date: 2002/02/26 12:00:00 EST
366    Tag: blume-20020226-ffi
367    Description:
368    
369    1. Fixed a minor bug in CM's "noweb" tool:
370       If numbering is turned off, then truly don't number (i.e., do not
371       supply the -L option to noweb).  The previous behavior was to supply
372       -L'' -- which caused noweb to use the "default" line numbering scheme.
373       Thanks to Chris Richards for pointing this out (and supplying the fix).
374    
375    2. Once again, I reworked some aspects of the FFI:
376    
377       A. The incomplete/complete type business:
378    
379       - Signatures POINTER_TO_INCOMPLETE_TYPE and accompanying functors are
380         gone!
381       - ML types representing an incomplete type are now *equal* to
382         ML types representing their corresponding complete types (just like
383         in C).  This is still safe because ml-nlffigen will not generate
384         RTTI for incomplete types, nor will it generate functions that
385         require access to such RTTI.   But when ML code generated from both
386         incomplete and complete versions of the C type meet, the ML types
387         are trivially interoperable.
388    
389         NOTE:  These changes restore the full generality of the translation
390         (which was previously lost when I eliminated functorization)!
391    
392       B. Enum types:
393    
394       - Structure C now has a type constructor "enum" that is similar to
395         how the "su" constructor works.  However, "enum" is not a phantom
396         type because each "T enum" has values (and is isomorphic to
397         MLRep.Signed.int).
398       - There are generic access operations for enum objects (using
399         MLRep.Signed.int).
400       - ml-nlffigen will generate a structure E_foo for each "enum foo".
401         * The structure contains the definition of type "mlrep" (the ML-side
402         representation type of the enum).  Normally, mlrep is the same
403         as "MLRep.Signed.int", but if ml-nlffigen was invoked with "-ec",
404         then mlrep will be defined as a datatype -- thus facilitating
405         pattern matching on mlrep values.
406         ("-ec" will be suppressed if there are duplicate values in an
407          enumeration.)
408         * Constructors ("-ec") or values (no "-ec") e_xxx of type mlrep
409         will be generated for each C enum constant xxx.
410         * Conversion functions m2i and i2m convert between mlrep and
411         MLRep.Signed.int.  (Without "-ec", these functions are identities.)
412         * Coversion functions c and ml convert between mlrep and "tag enum".
413         * Access functions (get/set) fetch and store mlrep values.
414       - By default (unless ml-nlffigen was invoked with "-nocollect"), unnamed
415         enumerations are merged into one single enumeration represented by
416         structure E_'.
417    
418    ----------------------------------------------------------------------
419    Name: Allen Leung
420    Date: 2002/02/25 04:45:00 EST
421    Tag: leunga-20020225-cps-spill
422    
423    This is a new implementation of the CPS spill phase.
424    The new phase is in the new file compiler/CodeGen/cpscompile/spill-new.sml
425    In case of problems, replace it with the old file spill.sml
426    
427    The current compiler runs into some serious performance problems when
428    constructing a large record.  This can happen when we try to compile a
429    structure with many items.  Even a very simple structure like the following
430    makes the compiler slow down.
431    
432        structure Foo = struct
433           val x_1 = 0w1 : Word32.int
434           val x_2 = 0w2 : Word32.int
435           val x_3 = 0w3 : Word32.int
436           ...
437           val x_N = 0wN : Word32.int
438        end
439    
440    The following table shows the compile time, from N=1000 to N=4000,
441    with the old compiler:
442    
443    N
444    1000   CPS 100 spill                           0.04u  0.00s  0.00g
445           MLRISC ra                               0.06u  0.00s  0.05g
446              (spills = 0 reloads = 0)
447           TOTAL                                   0.63u  0.07s  0.21g
448    
449    1100   CPS 100 spill                           8.25u  0.32s  0.64g
450           MLRISC ra                               5.68u  0.59s  3.93g
451              (spills = 0 reloads = 0)
452           TOTAL                                   14.71u  0.99s  4.81g
453    
454    1500   CPS 100 spill                           58.55u  2.34s  1.74g
455           MLRISC ra                               5.54u  0.65s  3.91g
456              (spills = 543 reloads = 1082)
457           TOTAL                                   65.40u  3.13s  6.00g
458    
459    2000   CPS 100 spill                           126.69u  4.84s  3.08g
460           MLRISC ra                               0.80u  0.10s  0.55g
461              (spills = 42 reloads = 84)
462           TOTAL                                   129.42u  5.10s  4.13g
463    
464    3000   CPS 100 spill                           675.59u  19.03s  11.64g
465           MLRISC ra                               2.69u  0.27s  1.38g
466              (spills = 62 reloads = 124)
467           TOTAL                                   682.48u  19.61s  13.99g
468    
469    4000   CPS 100 spill                           2362.82u  56.28s  43.60g
470           MLRISC ra                               4.96u  0.27s  2.72g
471              (spills = 85 reloads = 170)
472           TOTAL                                   2375.26u  57.21s  48.00g
473    
474    As you can see the old cps spill module suffers from some serious
475    performance problem.  But since I cannot decipher the old code fully,
476    instead of patching the problems up, I'm reimplementing it
477    with a different algorithm.  The new code is more modular,
478    smaller when compiled, and substantially faster
479    (O(n log n) time and O(n) space).  Timing of the new spill module:
480    
481    4000  CPS 100 spill                           0.02u  0.00s  0.00g
482          MLRISC ra                               0.25u  0.02s  0.15g
483             (spills=1 reloads=3)
484          TOTAL                                   7.74u  0.34s  1.62g
485    
486    Implementation details:
487    
488    As far as I can tell, the purpose of the CPS spill module is to make sure the
489    number of live variables at any program point (the bandwidth)
490    does not exceed a certain limit, which is determined by the
491    size of the spill area.
492    
493    When the bandwidth is too large, we decrease the register pressure by
494    packing live variables into spill records.  How we achieve this is
495    completely different than what we did in the old code.
496    
497    First, there is something about the MLRiscGen code generator
498    that we should be aware of:
499    
500    o MLRiscGen performs code motion!
501    
502       In particular, it will move floating point computations and
503       address computations involving only the heap pointer to
504       their use sites (if there is only a single use).
505       What this means is that if we have a CPS record construction
506       statement
507    
508           RECORD(k,vl,w,e)
509    
510       we should never count the new record address w as live if w
511       has only one use (which is often the case).
512    
513       We should do something similar to floating point, but the transformation
514       there is much more complex, so I won't deal with that.
515    
516    Secondly, there are now two new cps primops at our disposal:
517    
518     1. rawrecord of record_kind option
519        This pure operator allocates some uninitialized storage from the heap.
520        There are two forms:
521    
522         rawrecord NONE [INT n]  allocates a tagless record of length n
523         rawrecord (SOME rk) [INT n] allocates a tagged record of length n
524                                     and initializes the tag.
525    
526     2. rawupdate of cty
527          rawupdate cty (v,i,x)
528          Assigns to x to the ith component of record v.
529          The storelist is not updated.
530    
531    We use these new primops for both spilling and increment record construction.
532    
533     1. Spilling.
534    
535        This is implemented with a linear scan algorithm (but generalized
536        to trees).  The algorithm will create a single spill record at the
537        beginning of the cps function and use rawupdate to spill to it,
538        and SELECT or SELp to reload from it.  So both spills and reloads
539        are fine-grain operations.  In contrast, in the old algorithm
540        "spills" have to be bundled together in records.
541    
542        Ideally, we should sink the spill record construction to where
543        it is needed.  We can even split the spill record into multiple ones
544        at the places where they are needed.  But CPS is not a good
545        representation for global code motion, so I'll keep it simple and
546        am not attempting this.
547    
548     2. Incremental record construction (aka record splitting).
549    
550        Long records with many component values which are simulatenously live
551        (recall that single use record addresses are not considered to
552         be live) are constructed with rawrecord and rawupdate.
553        We allocate space on the heap with rawrecord first, then gradually
554        fill it in with rawupdate.  This is the technique suggested to me
555        by Matthias.
556    
557        Some restrictions on when this is applicable:
558        1. It is not a VECTOR record.  The code generator currently does not handle
559           this case. VECTOR record uses double indirection like arrays.
560        2. All the record component values are defined in the same "basic block"
561           as the record constructor.  This is to prevent speculative
562           record construction.
563    
564    ----------------------------------------------------------------------
565    Name: Allen Leung
566    Date: 2002/02/22 01:02:00 EST
567    Tag: leunga-20020222-mlrisc-tools
568    
569    Minor bug fixes in the parser and rewriter
570    
571    ----------------------------------------------------------------------
572    Name: Allen Leung
573    Date: 2002/02/21 20:20:00 EST
574    Tag: leunga-20020221-peephole
575    
576    Regenerated the peephole files.  Some contained typos in the specification
577    and some didn't compile because of pretty printing bugs in the old version
578    of 'nowhere'.
579    
580    ----------------------------------------------------------------------
581    Name: Allen Leung
582    Date: 2002/02/19 20:20:00 EST
583    Tag: leunga-20020219-mlrisc-tools
584    Description:
585    
586       Minor bug fixes to the mlrisc-tools library:
587    
588       1.  Fixed up parsing colon suffixed keywords
589       2.  Added the ability to shut the error messages up
590       3.  Reimplemented the pretty printer and fixed up/improved
591           the pretty printing of handle and -> types.
592       4.  Fixed up generation of literal symbols in the nowhere tool.
593       5.  Added some SML keywords to to sml.sty
594    
595    ----------------------------------------------------------------------
596    Name: Matthias Blume
597    Date: 2002/02/19 16:20:00 EST
598    Tag: blume-20020219-cmffi
599    Description:
600    
601    A wild mix of changes, some minor, some major:
602    
603    * All C FFI-related libraries are now anchored under $c:
604        $/c.cm      --> $c/c.cm
605        $/c-int.cm  --> $c/internals/c-int.cm
606        $/memory.cm --> $c/memory/memory.cm
607    
608    * "make" tool (in CM) now treats its argument pathname slightly
609      differently:
610        1. If the native expansion is an absolute name, then before invoking
611           the "make" command on it, CM will apply OS.Path.mkRelative
612           (with relativeTo = OS.FileSys.getDir()) to it.
613        2. The argument will be passed through to subsequent phases of CM
614           processing without "going native".  In particular, if the argument
615           was an anchored path, then "make" will not lose track of that anchor.
616    
617    * Compiler backends now "know" their respective C calling conventions
618      instead of having to be told about it by ml-nlffigen.  This relieves
619      ml-nlffigen from one of its burdens.
620    
621    * The X86Backend has been split into X86CCallBackend and X86StdCallBackend.
622    
623    * Export C_DEBUG and C_Debug from $c/c.cm.
624    
625    * C type encoding in ml-nlffi-lib has been improved to model the conceptual
626      subtyping relationship between incomplete pointers and their complete
627      counterparts.  For this, ('t, 'c) ptr has been changed to 'o ptr --
628      with the convention of instantiating 'o with ('t, 'c) obj whenever
629      the pointer target type is complete.  In the incomplete case, 'o
630      will be instantiated with some "'c iobj" -- a type obtained by
631      using one of the functors PointerToIncompleteType or PointerToCompleteType.
632    
633      Operations that work on both incomplete and complete pointer types are
634      typed as taking an 'o ptr while operations that require the target to
635      be known are typed as taking some ('t, 'c) obj ptr.
636    
637      voidptr is now a bit "more concrete", namely "type voidptr = void ptr'"
638      where void is an eqtype without any values.  This makes it possible
639      to work on voidptr values using functions meant to operate on light
640      incomplete pointers.
641    
642    * As a result of the above, signature POINTER_TO_INCOMPLETE_TYPE has
643      been vastly simplified.
644    
645    ----------------------------------------------------------------------
646    Name: Matthias Blume
647    Date: 2002/02/19 10:48:00 EST
648    Tag: blume-20020219-pqfix
649    Description:
650    
651    Applied Chris Okasaki's bug fix for priority queues.
652    
653    ----------------------------------------------------------------------
654    Name: Matthias Blume
655    Date: 2002/02/15 17:05:00
656    Tag: Release_110_39
657    Description:
658    
659    Last-minute retagging is becoming a tradition... :-(
660    
661    This is the working release 110.39.
662    
663    ----------------------------------------------------------------------
664    Name: Matthias Blume
665    Date: 2002/02/15 16:00:00 EST
666    Tag: Release_110_39-orig
667    Description:
668    
669    Working release 110.39.  New bootfiles.
670    
671    (Update: There was a small bug in the installer so it wouldn't work
672    with all shells.  So I retagged. -Matthias)
673    
674    ----------------------------------------------------------------------
675    Name: Matthias Blume
676    Date: 2002/02/15 14:17:00 EST
677    Tag: blume-20020215-showbindings
678    Description:
679    
680    Added EnvRef.listBoundSymbols and CM.State.showBindings.  Especially
681    the latter can be useful for exploring what bindings are available at
682    the interactive prompt.  (The first function returns only the list
683    of symbols that are really bound, the second prints those but also the
684    ones that CM's autoloading mechanism knows about.)
685    
686    ----------------------------------------------------------------------
687    Name: Matthias Blume
688    Date: 2002/02/15 12:08:00 EST
689    Tag: blume-20020215-iptrs
690    Description:
691    
692    Two improvements to ml-nlffigen:
693    
694      1. Write files only if they do not exist or if their current contents
695         do not coincide with what's being written.  (That is, avoid messing
696         with the time stamps unless absolutely necessary.)
697    
698      2. Implement a "repository" mechanism for generated files related
699         to "incomplete pointer types".   See the README file for details.
700    
701    ----------------------------------------------------------------------
702    Name: Matthias Blume
703  Date: 2002/02/14 11:50:00 EST  Date: 2002/02/14 11:50:00 EST
704  Tag: blume-20020214-quote  Tag: blume-20020214-quote
705  Description:  Description:

Legend:
Removed from v.1066  
changed lines
  Added in v.1145

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0