1. 20 Apr, 2011 2 commits
  2. 19 Apr, 2011 9 commits
  3. 18 Apr, 2011 11 commits
    • Russ Cox's avatar
      5c: make alignment rules match 5g, just like 6c matches 6g · b331f3cf
      Russ Cox authored
      I should have done this a year ago in:
      
              changeset:   5137:686b18098944
              user:        Russ Cox <rsc@golang.org>
              date:        Thu Mar 25 14:05:54 2010 -0700
              files:       src/cmd/8c/swt.c
              description:
              make alignment rules match 8g, just like 6c matches 6g.
      
              R=ken2
              CC=golang-dev
              https://golang.org/cl/760042
      
      R=ken2
      CC=golang-dev
      https://golang.org/cl/4437054
      b331f3cf
    • Russ Cox's avatar
      http: fix IP confusion in TestServerTimeouts · 857f17d3
      Russ Cox authored
      Don't assume that localhost == 127.0.0.1.
      It might be ::1.
      
      R=bradfitzgo
      CC=golang-dev
      https://golang.org/cl/4430055
      857f17d3
    • Russ Cox's avatar
      changes for more restricted reflect.SetValue · cded21a3
      Russ Cox authored
      R=golang-dev, r
      CC=golang-dev
      https://golang.org/cl/4423043
      cded21a3
    • Russ Cox's avatar
      reflect: more efficient; cannot Set result of NewValue anymore · 40fccbce
      Russ Cox authored
       * Reduces malloc counts during gob encoder/decoder test from 6/6 to 3/5.
      
      The current reflect uses Set to mean two subtly different things.
      
      (1) If you have a reflect.Value v, it might just represent
      itself (as in v = reflect.NewValue(42)), in which case calling
      v.Set only changed v, not any other data in the program.
      
      (2) If you have a reflect Value v derived from a pointer
      or a slice (as in x := []int{42}; v = reflect.NewValue(x).Index(0)),
      v represents the value held there.  Changing x[0] affects the
      value returned by v.Int(), and calling v.Set affects x[0].
      
      This was not really by design; it just happened that way.
      
      The motivation for the new reflect implementation was
      to remove mallocs.  The use case (1) has an implicit malloc
      inside it.  If you can do:
      
             v := reflect.NewValue(0)
             v.Set(42)
             i := v.Int()  // i = 42
      
      then that implies that v is referring to some underlying
      chunk of memory in order to remember the 42; that is,
      NewValue must have allocated some memory.
      
      Almost all the time you are using reflect the goal is to
      inspect or to change other data, not to manipulate data
      stored solely inside a reflect.Value.
      
      This CL removes use case (1), so that an assignable
      reflect.Value must always refer to some other piece of data
      in the program.  Put another way, removing this case would
      make
      
             v := reflect.NewValue(0)
             v.Set(42)
      
      as illegal as
      
             0 = 42.
      
      It would also make this illegal:
      
             x := 0
             v := reflect.NewValue(x)
             v.Set(42)
      
      for the same reason.  (Note that right now, v.Set(42) "succeeds"
      but does not change the value of x.)
      
      If you really wanted to make v refer to x, you'd start with &x
      and dereference it:
      
             x := 0
             v := reflect.NewValue(&x).Elem()  // v = *&x
             v.Set(42)
      
      It's pretty rare, except in tests, to want to use NewValue and then
      call Set to change the Value itself instead of some other piece of
      data in the program.  I haven't seen it happen once yet while
      making the tree build with this change.
      
      For the same reasons, reflect.Zero (formerly reflect.MakeZero)
      would also return an unassignable, unaddressable value.
      This invalidates the (awkward) idiom:
      
             pv := ... some Ptr Value we have ...
             v := reflect.Zero(pv.Type().Elem())
             pv.PointTo(v)
      
      which, when the API changed, turned into:
      
             pv := ... some Ptr Value we have ...
             v := reflect.Zero(pv.Type().Elem())
             pv.Set(v.Addr())
      
      In both, it is far from clear what the code is trying to do.  Now that
      it is possible, this CL adds reflect.New(Type) Value that does the
      obvious thing (same as Go's new), so this code would be replaced by:
      
             pv := ... some Ptr Value we have ...
             pv.Set(reflect.New(pv.Type().Elem()))
      
      The changes just described can be confusing to think about,
      but I believe it is because the old API was confusing - it was
      conflating two different kinds of Values - and that the new API
      by itself is pretty simple: you can only Set (or call Addr on)
      a Value if it actually addresses some real piece of data; that is,
      only if it is the result of dereferencing a Ptr or indexing a Slice.
      
      If you really want the old behavior, you'd get it by translating:
      
             v := reflect.NewValue(x)
      
      into
      
             v := reflect.New(reflect.Typeof(x)).Elem()
             v.Set(reflect.NewValue(x))
      
      Gofix will not be able to help with this, because whether
      and how to change the code depends on whether the original
      code meant use (1) or use (2), so the developer has to read
      and think about the code.
      
      You can see the effect on packages in the tree in
      https://golang.org/cl/4423043/.
      
      R=r
      CC=golang-dev
      https://golang.org/cl/4435042
      40fccbce
    • Brad Fitzpatrick's avatar
      mime: add a TODO, fix the format of an error · 6211b596
      Brad Fitzpatrick authored
      R=r, rsc1
      CC=golang-dev
      https://golang.org/cl/4440054
      6211b596
    • Brad Fitzpatrick's avatar
      mime: RFC 2231 continuation / non-ASCII support · 98176b77
      Brad Fitzpatrick authored
      Fixes #1119.
      
      R=rsc, r
      CC=golang-dev
      https://golang.org/cl/4437052
      98176b77
    • Rob Pike's avatar
      tutorial: modernize the definition and use of Open. · 23fc9c84
      Rob Pike authored
      R=golang-dev, iant
      CC=golang-dev
      https://golang.org/cl/4446053
      23fc9c84
    • Russ Cox's avatar
      gc: fix complex move again · beb64bbd
      Russ Cox authored
      R=ken2
      CC=golang-dev
      https://golang.org/cl/4443047
      beb64bbd
    • Rob Pike's avatar
      test/bench: update timings; moving to new machine. · e3634aad
      Rob Pike authored
      Interesting comparisons between old and new machine,
      and relationship between gccgo and gc.
      
      R=golang-dev, rsc1
      CC=golang-dev
      https://golang.org/cl/4430045
      e3634aad
    • Quan Yong Zhai's avatar
      net: fix dialgoogle_test.go · f80f97a3
      Quan Yong Zhai authored
      ~$ nslookup www.google.com
      Server: 8.8.8.8
      cannonical name = www-g-com-chn.l.google.com.
      
      R=adg, rsc
      CC=golang-dev
      https://golang.org/cl/4445045
      f80f97a3
    • Nigel Tao's avatar
      CONTRIBUTORS: Raph Levien (Google CLA) · 8e8edff7
      Nigel Tao authored
      R=adg
      CC=golang-dev, raph
      https://golang.org/cl/4443046
      8e8edff7
  4. 17 Apr, 2011 3 commits
  5. 16 Apr, 2011 1 commit
  6. 15 Apr, 2011 14 commits