Commit cc7e11c9 authored by Rob Pike's avatar Rob Pike

doc/go1: mention that regexp has changed

Also restore alphabetical order.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5701053
parent e10dc82c
...@@ -1702,6 +1702,39 @@ Code that uses the old POSIX error values from the <code>os</code> package ...@@ -1702,6 +1702,39 @@ Code that uses the old POSIX error values from the <code>os</code> package
will fail to compile and will also need to be updated by hand. will fail to compile and will also need to be updated by hand.
</p> </p>
<h3 id="os_signal">The os/signal package</h3>
<p>
The <code>os/signal</code> package in Go 1 replaces the
<code>Incoming</code> function, which returned a channel
that received all incoming signals,
with the selective <code>Notify</code> function, which asks
for delivery of specific signals on an existing channel.
</p>
<p>
<em>Updating</em>:
Code must be updated by hand.
A literal translation of
</p>
<pre>
c := signal.Incoming()
</pre>
<p>
is
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c) // ask for all signals
</pre>
<p>
but most code should list the specific signals it wants to handle instead:
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT)
</pre>
<h3 id="path_filepath">The path/filepath package</h3> <h3 id="path_filepath">The path/filepath package</h3>
<p> <p>
...@@ -1747,38 +1780,19 @@ will need to be updated by hand. ...@@ -1747,38 +1780,19 @@ will need to be updated by hand.
The compiler will catch code using the old interface. The compiler will catch code using the old interface.
</p> </p>
<h3 id="os_signal">The os/signal package</h3> <h3 id="regexp">The regexp package</h3>
<p> <p>
The <code>os/signal</code> package in Go 1 replaces the The <a href="/pkg/regexp/"><code>regexp</code></a> package has been rewritten.
<code>Incoming</code> function, which returned a channel It has the same interface but the specification of the regular expressions
that received all incoming signals, it supports has changed from the old "egrep" form to that of
with the selective <code>Notify</code> function, which asks <a href="code.google.com/p/re2">RE2</a>.
for delivery of specific signals on an existing channel.
</p> </p>
<p> <p>
<em>Updating</em>: <em>Updating</em>:
Code must be updated by hand. Code that uses the package should have its regular expressions checked by hand.
A literal translation of
</p> </p>
<pre>
c := signal.Incoming()
</pre>
<p>
is
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c) // ask for all signals
</pre>
<p>
but most code should list the specific signals it wants to handle instead:
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT)
</pre>
<h3 id="runtime">The runtime package</h3> <h3 id="runtime">The runtime package</h3>
......
...@@ -1601,6 +1601,39 @@ Code that uses the old POSIX error values from the <code>os</code> package ...@@ -1601,6 +1601,39 @@ Code that uses the old POSIX error values from the <code>os</code> package
will fail to compile and will also need to be updated by hand. will fail to compile and will also need to be updated by hand.
</p> </p>
<h3 id="os_signal">The os/signal package</h3>
<p>
The <code>os/signal</code> package in Go 1 replaces the
<code>Incoming</code> function, which returned a channel
that received all incoming signals,
with the selective <code>Notify</code> function, which asks
for delivery of specific signals on an existing channel.
</p>
<p>
<em>Updating</em>:
Code must be updated by hand.
A literal translation of
</p>
<pre>
c := signal.Incoming()
</pre>
<p>
is
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c) // ask for all signals
</pre>
<p>
but most code should list the specific signals it wants to handle instead:
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT)
</pre>
<h3 id="path_filepath">The path/filepath package</h3> <h3 id="path_filepath">The path/filepath package</h3>
<p> <p>
...@@ -1632,38 +1665,19 @@ will need to be updated by hand. ...@@ -1632,38 +1665,19 @@ will need to be updated by hand.
The compiler will catch code using the old interface. The compiler will catch code using the old interface.
</p> </p>
<h3 id="os_signal">The os/signal package</h3> <h3 id="regexp">The regexp package</h3>
<p> <p>
The <code>os/signal</code> package in Go 1 replaces the The <a href="/pkg/regexp/"><code>regexp</code></a> package has been rewritten.
<code>Incoming</code> function, which returned a channel It has the same interface but the specification of the regular expressions
that received all incoming signals, it supports has changed from the old "egrep" form to that of
with the selective <code>Notify</code> function, which asks <a href="code.google.com/p/re2">RE2</a>.
for delivery of specific signals on an existing channel.
</p> </p>
<p> <p>
<em>Updating</em>: <em>Updating</em>:
Code must be updated by hand. Code that uses the package should have its regular expressions checked by hand.
A literal translation of
</p> </p>
<pre>
c := signal.Incoming()
</pre>
<p>
is
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c) // ask for all signals
</pre>
<p>
but most code should list the specific signals it wants to handle instead:
</p>
<pre>
c := make(chan os.Signal)
signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT)
</pre>
<h3 id="runtime">The runtime package</h3> <h3 id="runtime">The runtime package</h3>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment