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 659, Mon Jun 12 07:37:22 2000 UTC revision 670, Sun Jun 18 13:10:57 2000 UTC
# Line 13  Line 13 
13  Description:  Description:
14  ----------------------------------------------------------------------  ----------------------------------------------------------------------
15  Name: Matthias Blume  Name: Matthias Blume
16    Date: 2000/06/18 22:00:10 JST
17    Tag: blume-20000618-implicit-anchors-really-gone
18    Description:
19    
20    I updates the previous HISTORY entry where I forgot to mention that
21    implicit anchors are no longer with us.
22    
23    The current update also gets rid of the (now useless) controller
24    CM.Control.implicit_anchors.
25    
26    ----------------------------------------------------------------------
27    Name: Matthias Blume
28    Date: 2000/06/16 17:30:00 JST
29    Tag: blume-20000616-anchorenv
30    Description:
31    
32    This patch implements the long anticipated (just kidding :) "anchor
33    environment" mechanism.  In the course of doing this, I also
34    re-implemented CM's internal "SrcPath" module from scratch.  The new
35    one should be more robust in certain boundary cases.  In any case, it
36    is a lot cleaner than its predecessor (IMHO).
37    
38    This time, although there is yet another boot file format change, I
39    kept the unpickler backward-compatible.  As a result, no new bootfiles
40    are necessary and bootstrapping is straightforward.  (You cannot read
41    new bootfiles into an old system, but the other way around is no
42    problem.)
43    
44    Visible changes:
45    
46    ** 0. Implicit path anchors (without the leading $-symbol) are no
47    longer recognized at all. This means that such path names are not
48    illegal either.  For example, the name basis.cm simply refers to a
49    local file called "basis.cm" (i.e, the name is an ordinary path
50    relative to .cm-files directory).  Or, to put it differently, only
51    names that start with $ are anchored paths.
52    
53    ** 1. The $<singlearc> abbreviation for $/<singlearc> has finally
54    vanished.
55    
56    John (Reppy) had critizised this as soon as I originally proposed and
57    implemented it, but at that time I did not really deeply believe
58    him. :) Now I came full-circle because I need the $<singlearc> syntax
59    in another place where it cannot be seen as an abbreviation for
60    $/<singlearc>.  To avoid the confusion, $<singlearc> now means what it
61    seems to mean (i.e., it "expands" into the corresponding anchor
62    value).
63    
64    However, when paths are used as members in CM description files, it
65    continues to be true that there must be at least another arc after the
66    anchor.  This is now enforced separately during semantic analysis
67    (i.e., from a lexical/syntactical point of view, the notation is ok.)
68    
69    ** 2. The "cm" class now accepts an option "bind".  The option's value
70    is a sub-option list of precisely two items -- one labeled "anchor"
71    and the other one labeled "value".  As you might expect, "anchor" is
72    used to specify an anchor name to be bound, and "value" specifies what
73    the anchor is being bound to.
74    
75    The value must be a directory name and can be given in either standard
76    syntax (including the possibility that it is itself an anchored path)
77    or native syntax.
78    
79    Examples:
80    
81       foo.cm (bind:(anchor:bar value:$mystuff/bar))
82       lib.cm (bind:(anchor:a value:"H:\\x\\y\\z"))  (* only works under windows *)
83    
84    and so on.
85    
86    The meaning of this is that the .cm-file will be processed with an
87    augmented anchor environment where the given anchor(s) is/are bound to
88    the given values(s).
89    
90    The rationale for having this feature is this: Suppose you are trying
91    to use two different (already stable) libraries a.cm and b.cm (that
92    you perhaps didn't write yourself).  Further, suppose each of these
93    two libraries internally uses its own auxiliary library $aux/lib.cm.
94    Normally you would now have a problem because the anchor "lib" can not
95    be bound to more than one value globally.  Therefore, the project that
96    uses both a.cm and b.cm must locally redirect the anchor to some other
97    place:
98    
99       a.cm (bind:(anchor:lib value:/usr/lib/smlnj/a-stuff))
100       b.cm (bind:(anchor:lib value:/usr/lib/smlnj/b-stuff))
101    
102    This hard-wires $lib/aux.cm to /usr/lib/smlnj/a-stuff/aux.cm or
103    /usr/lib/smlnj/b-stuff/aux.cm, respectively.
104    
105    Hard-wiring path names is a bit inflexible (and CM will verbosely warn
106    you when you do so at the time of CM.stabilize).  Therefore, you can
107    also use an anchored path as the value:
108    
109      a.cm (bind:(anchor:lib value:$a-lib))
110      b.cm (bind:(anchor:lib value:$b-lib))
111    
112    Now you can globally configure (using the usual CM.Anchor.anchor or
113    pathconfig machinery) bindings for "a-lib" and "b-lib".  Since "lib"
114    itself is always locally bound, setting it globally is no longer
115    meaningful or necessary (but it does not hurt either).  In fact, "lib"
116    can still be used as a global anchor for separate purposes.  As a
117    matter of fact, one can locally define "lib" in terms of a global
118    "lib":
119    
120      a.cm (bind:(anchor:lib value:$lib/a))
121      b.cm (bind:(anchor:lib value:$lib/b))
122    
123    ** 3: The encoding of path names has changed.  This affects the way
124    path names are shown in CM's progress report and also the internal
125    protocol encoding used for parallel make.
126    
127    The encoding now uses one or more ':'-separated segments.  Each
128    segments corresponds to a file that has been specified relative to the
129    file given by its preceding segment.  The first segment is either
130    relative to the CWD, absolute, or anchored.  Each segment itself is
131    basically a Unix pathname; all segments but the first are relative.
132    
133    Example:
134    
135       $foo/bar/baz.cm:a/b/c.sml
136    
137    This path denotes the file bar/a/b/c.sml relative to the directory
138    denoted by anchor "foo".  Notice that the encoding also includes
139    baz.cm which is the .cm-file that listed a/b/c.sml.  As usual, such
140    paths are resolved relative to the .cm-files directory, so baz.cm must
141    be ignored to get the "real" pathname.
142    
143    To make this fact more obvious, CM puts the names of such "virtual
144    arcs" into parentheses when they appear in progress reports. (No
145    parentheses will appear in the internal protocol encoding.)  Thus,
146    what you really see is:
147    
148      $foo/bar/(baz.cm):a/b/c.sml
149    
150    I find this notation to be much more informative than before.
151    
152    Another new feature of the encoding is that special characters
153    including parentheses, colons, (back)slashes, and white space are
154    written as \ddd (where ddd is the decimal encoding of the character).
155    
156    *** The CM manual still needs to be updated.
157    
158    ----------------------------------------------------------------------
159    Name: Allen Leung
160    Date: 2000/06/15 00:38:00
161    Tag: leunga-20000615-x86-peephole
162    
163    x86 Peephole fix by Fermin.  Affects c-- and moby only.
164    
165    ----------------------------------------------------------------------
166    Name: Matthias Blume
167  Date: 2000/06/12 11:40:00  Date: 2000/06/12 11:40:00
168  Tag: blume-20000612-parmakefix  Tag: blume-20000612-parmakefix
169  Description:  Description:

Legend:
Removed from v.659  
changed lines
  Added in v.670

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