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

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

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