FAQ
Implemented in the runtime [1], reflect.typelinks() returns an array of
types known to the runtime. These include channels, maps, slices and arrays
but not functions.

What I want to do is to look up a "cooked-in" function type given its
string representation.

How could I go about this?

[1] https://github.com/golang/go/blob/027e47b7b105a71eb6fe375166ee807d5d06e40d/src/runtime/runtime1.go#L436

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Feb 9, 2015 at 6:18 pm

    On Mon, Feb 9, 2015 at 9:47 AM, thwd wrote:
    Implemented in the runtime [1], reflect.typelinks() returns an array of
    types known to the runtime. These include channels, maps, slices and arrays
    but not functions.

    What I want to do is to look up a "cooked-in" function type given its string
    representation.

    How could I go about this?
    Change cmd/gc to emit function types into reflect.typelinks. You do
    this in the switch at the bottom of dtypesym in reflect.c.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 9, 2015 at 6:30 pm

    On Monday, February 9, 2015 at 7:19:01 PM UTC+1, Ian Lance Taylor wrote:
    Change cmd/gc to emit function types into reflect.typelinks. You do
    this in the switch at the bottom of dtypesym in reflect.c.
    Thanks for this.

    Is there a way to do it without modifying the compiler? I'm hoping to make
    a go-gettable package out of my work. Including some .s files is okay for
    me too, if that makes it easier.

    Is there a way to inspect SRODATA symbols at runtime?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Feb 9, 2015 at 6:34 pm

    On Mon, Feb 9, 2015 at 10:30 AM, thwd wrote:
    On Monday, February 9, 2015 at 7:19:01 PM UTC+1, Ian Lance Taylor wrote:

    Change cmd/gc to emit function types into reflect.typelinks. You do
    this in the switch at the bottom of dtypesym in reflect.c.

    Thanks for this.

    Is there a way to do it without modifying the compiler? I'm hoping to make a
    go-gettable package out of my work. Including some .s files is okay for me
    too, if that makes it easier.
    I can't think of any way to do this without modifying the compiler.
    If it were possible, there would be no need for reflect.typelinks.

    Is there a way to inspect SRODATA symbols at runtime?
    Not a useful way, no.

    If you want to go crazy you could open the executable as an object
    file, read the symbol table, adjust the addresses and work from that.
    I guess with that approach you might be able to identify all the type
    descriptors for functions and those build your own mapping.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 9, 2015 at 9:41 pm

    On Monday, February 9, 2015 at 7:19:01 PM UTC+1, Ian Lance Taylor wrote:
    Change cmd/gc to emit function types into reflect.typelinks. You do
    this in the switch at the bottom of dtypesym in reflect.c.
    This might be a silly question but... how do you compile and install a
    modified gc?

    $ go tool dist install -v cmd/gc
    cmd/gc

    Seems to succeed but then nothing new happens if I go run -a myprogram.go

    going to src/cmd/gc and calling make && make install has no further effect,
    either.

    I even added a fatal("reached") line to reflect.c to make sure.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Feb 9, 2015 at 9:46 pm

    On Mon, Feb 9, 2015 at 1:40 PM, thwd wrote:
    This might be a silly question but... how do you compile and install a
    modified gc?

    $ go tool dist install -v cmd/gc
    cmd/gc

    Seems to succeed but then nothing new happens if I go run -a myprogram.go

    going to src/cmd/gc and calling make && make install has no further effect,
    either.
    In Go 1.4 you need to do

    go tool dist install cmd/gc
    go tool dist install cmd/6g [or 8g for GOARCH=386 or 5g for GOARCH=arm]

    This will almost certainly change in the future Go 1.5.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 11, 2015 at 9:34 am

    On Monday, February 9, 2015 at 10:47:13 PM UTC+1, Ian Lance Taylor wrote:
    In Go 1.4 you need to do

    go tool dist install cmd/gc
    go tool dist install cmd/6g [or 8g for GOARCH=386 or 5g for GOARCH=arm]
    Thank you.

    Do you know if there's a particular reason why there is no reflect.FuncOf,
    analogous to e.g. SliceOf and ChanOf?

    I have implemented this function myself (following your kind guidance) and
    even though it's not entirely as straight-forward as one would think, it's
    not hard to get right either.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sebastien Binet at Feb 11, 2015 at 9:45 am
    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    -s
    On Wed, Feb 11, 2015 at 10:34 AM, thwd wrote:
    On Monday, February 9, 2015 at 10:47:13 PM UTC+1, Ian Lance Taylor wrote:

    In Go 1.4 you need to do

    go tool dist install cmd/gc
    go tool dist install cmd/6g [or 8g for GOARCH=386 or 5g for GOARCH=arm]

    Thank you.

    Do you know if there's a particular reason why there is no reflect.FuncOf,
    analogous to e.g. SliceOf and ChanOf?

    I have implemented this function myself (following your kind guidance) and
    even though it's not entirely as straight-forward as one would think, it's
    not hard to get right either.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thomas Wilde at Feb 11, 2015 at 10:05 am

    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had known
    :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 12, 2015 at 10:43 am
    + Dave Day

    Hi Dave

    As I was telling Sebastien; watch out for typesByString because it won't
    work cleanly for func types e.g. it will miss types and you'll end up
    building them even though they are already available in SRODATA. When that
    happens assertions won't work as expected. I ran into this problem in my
    own implementation and I think it's due to func types not being added in
    string-comparison order to the typelinks array.

    Also I was gonna ask you; what's the rtype.hash field good for in the case
    of func types?

    Tom
    On Wednesday, February 11, 2015 at 11:06:04 AM UTC+1, thwd wrote:
    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had
    known :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Day at Feb 13, 2015 at 3:09 am
    Hey Tom,

    Thanks for that info about typesByString. Do you have a test case which
    exposes that? I had thought that the test at :3694 would be sufficient:
    https://go-review.googlesource.com/#/c/1996/4/src/reflect/all_test.go

    The hash is only used for quick lookup in funcLookupCache.

    Dave

    On 12 February 2015 at 21:43, thwd wrote:

    + Dave Day

    Hi Dave

    As I was telling Sebastien; watch out for typesByString because it won't
    work cleanly for func types e.g. it will miss types and you'll end up
    building them even though they are already available in SRODATA. When that
    happens assertions won't work as expected. I ran into this problem in my
    own implementation and I think it's due to func types not being added in
    string-comparison order to the typelinks array.

    Also I was gonna ask you; what's the rtype.hash field good for in the case
    of func types?

    Tom
    On Wednesday, February 11, 2015 at 11:06:04 AM UTC+1, thwd wrote:
    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had
    known :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 14, 2015 at 6:11 pm
    Hi Dave,


    here's a minimal repro: https://gist.github.com/thwd/2b965b7912fea68b93d2

    In my implementation I fixed it by using a linear search but the root cause
    of the problem is probably in the code that generates the typelinks.


    Tom
    On Friday, February 13, 2015 at 4:09:56 AM UTC+1, Dave Day wrote:

    Hey Tom,

    Thanks for that info about typesByString. Do you have a test case which
    exposes that? I had thought that the test at :3694 would be sufficient:
    https://go-review.googlesource.com/#/c/1996/4/src/reflect/all_test.go

    The hash is only used for quick lookup in funcLookupCache.

    Dave


    On 12 February 2015 at 21:43, thwd <sedevel...@gmail.com <javascript:>>
    wrote:
    + Dave Day

    Hi Dave

    As I was telling Sebastien; watch out for typesByString because it won't
    work cleanly for func types e.g. it will miss types and you'll end up
    building them even though they are already available in SRODATA. When that
    happens assertions won't work as expected. I ran into this problem in my
    own implementation and I think it's due to func types not being added in
    string-comparison order to the typelinks array.

    Also I was gonna ask you; what's the rtype.hash field good for in the
    case of func types?

    Tom
    On Wednesday, February 11, 2015 at 11:06:04 AM UTC+1, thwd wrote:
    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had
    known :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 17, 2015 at 4:52 pm
    Guys, I want to fix this.

    Currently:
      * some named types are added to .typelink, although they're not supposed
    to according to comments in cmd/gc/reflect.c
      * there's one big typelinks slice shared by runtime with reflect
    (runtime.reflect_typelinks() in runtime/runtime1.go linked as
    reflect.typelinks())
      * typesByString uses a binary search in combination with a linear one

    I propose:
      * fix code to only export unnamed (composite) types.
      * split typelinks slice into separate typelink-containers for funcs,
    channels, maps, slices, structs, and so forth.. 1 per kind
      * make each typelink-container a map[string][]*reflect.rtype
      * typesByString uses map access

    My approach would be to leave runtime.typelinks() as-is and build the
    typelink-container maps in the reflect package's init() method. Reason
    being that in the contrary case I'd have to add to cmd/gc/reflect.c and I
    believe that we're trying to get away from C in the runtime [1]. Besides,
    I'm unfamiliar with the C codebase.

    Given the big amounts of changes taking place simultaneously in the
    compiler; does this make sense to do this way?

    [1] https://talks.golang.org/2015/state-of-go.slide#10
    On Saturday, February 14, 2015 at 7:10:58 PM UTC+1, thwd wrote:

    Hi Dave,


    here's a minimal repro: https://gist.github.com/thwd/2b965b7912fea68b93d2

    In my implementation I fixed it by using a linear search but the root
    cause of the problem is probably in the code that generates the typelinks.


    Tom
    On Friday, February 13, 2015 at 4:09:56 AM UTC+1, Dave Day wrote:

    Hey Tom,

    Thanks for that info about typesByString. Do you have a test case which
    exposes that? I had thought that the test at :3694 would be sufficient:
    https://go-review.googlesource.com/#/c/1996/4/src/reflect/all_test.go

    The hash is only used for quick lookup in funcLookupCache.

    Dave

    On 12 February 2015 at 21:43, thwd wrote:

    + Dave Day

    Hi Dave

    As I was telling Sebastien; watch out for typesByString because it won't
    work cleanly for func types e.g. it will miss types and you'll end up
    building them even though they are already available in SRODATA. When that
    happens assertions won't work as expected. I ran into this problem in my
    own implementation and I think it's due to func types not being added in
    string-comparison order to the typelinks array.

    Also I was gonna ask you; what's the rtype.hash field good for in the
    case of func types?

    Tom
    On Wednesday, February 11, 2015 at 11:06:04 AM UTC+1, thwd wrote:
    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had
    known :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Feb 23, 2015 at 8:51 am
    "Awkward silences may result from a faltering conversation in which the
    participants have completed what they wanted to say. To avoid such a
    conclusion, it has been recommended that the participants actively close
    the conversation by summarising what was said and thanking the others for
    their contributions."

         -- http://en.wikipedia.org/wiki/Awkward_silence#Remediation
    On Tuesday, February 17, 2015 at 5:52:03 PM UTC+1, thwd wrote:

    Guys, I want to fix this.

    Currently:
    * some named types are added to .typelink, although they're not supposed
    to according to comments in cmd/gc/reflect.c
    * there's one big typelinks slice shared by runtime with reflect
    (runtime.reflect_typelinks() in runtime/runtime1.go linked as
    reflect.typelinks())
    * typesByString uses a binary search in combination with a linear one

    I propose:
    * fix code to only export unnamed (composite) types.
    * split typelinks slice into separate typelink-containers for funcs,
    channels, maps, slices, structs, and so forth.. 1 per kind
    * make each typelink-container a map[string][]*reflect.rtype
    * typesByString uses map access

    My approach would be to leave runtime.typelinks() as-is and build the
    typelink-container maps in the reflect package's init() method. Reason
    being that in the contrary case I'd have to add to cmd/gc/reflect.c and I
    believe that we're trying to get away from C in the runtime [1]. Besides,
    I'm unfamiliar with the C codebase.

    Given the big amounts of changes taking place simultaneously in the
    compiler; does this make sense to do this way?

    [1] https://talks.golang.org/2015/state-of-go.slide#10
    On Saturday, February 14, 2015 at 7:10:58 PM UTC+1, thwd wrote:

    Hi Dave,


    here's a minimal repro: https://gist.github.com/thwd/2b965b7912fea68b93d2

    In my implementation I fixed it by using a linear search but the root
    cause of the problem is probably in the code that generates the typelinks.


    Tom
    On Friday, February 13, 2015 at 4:09:56 AM UTC+1, Dave Day wrote:

    Hey Tom,

    Thanks for that info about typesByString. Do you have a test case which
    exposes that? I had thought that the test at :3694 would be sufficient:
    https://go-review.googlesource.com/#/c/1996/4/src/reflect/all_test.go

    The hash is only used for quick lookup in funcLookupCache.

    Dave

    On 12 February 2015 at 21:43, thwd wrote:

    + Dave Day

    Hi Dave

    As I was telling Sebastien; watch out for typesByString because it
    won't work cleanly for func types e.g. it will miss types and you'll end up
    building them even though they are already available in SRODATA. When that
    happens assertions won't work as expected. I ran into this problem in my
    own implementation and I think it's due to func types not being added in
    string-comparison order to the typelinks array.

    Also I was gonna ask you; what's the rtype.hash field good for in the
    case of func types?

    Tom
    On Wednesday, February 11, 2015 at 11:06:04 AM UTC+1, thwd wrote:
    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had
    known :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Day at Apr 1, 2015 at 3:47 am
    @rsc, I'd like your input here.

    I'm wary of making big changes to typelink without your guidance, since I'm
    not familiar with the code. At the moment, the following fails:

             checkSameType(t, Zero(FuncOf([]Type{TypeOf(int(0))}, nil,
    false)).Interface(),
    (func(int))(nil))

    However, this works:

             type T1 int
             checkSameType(t, Zero(FuncOf([]Type{TypeOf(T1(0))}, nil,
    false)).Interface(),
    (func(T1))(nil))
    On 18 February 2015 at 03:52, thwd wrote:

    Guys, I want to fix this.

    Currently:
    * some named types are added to .typelink, although they're not supposed
    to according to comments in cmd/gc/reflect.c
    * there's one big typelinks slice shared by runtime with reflect
    (runtime.reflect_typelinks() in runtime/runtime1.go linked as
    reflect.typelinks())
    * typesByString uses a binary search in combination with a linear one

    I propose:
    * fix code to only export unnamed (composite) types.
    * split typelinks slice into separate typelink-containers for funcs,
    channels, maps, slices, structs, and so forth.. 1 per kind
    * make each typelink-container a map[string][]*reflect.rtype
    * typesByString uses map access

    My approach would be to leave runtime.typelinks() as-is and build the
    typelink-container maps in the reflect package's init() method. Reason
    being that in the contrary case I'd have to add to cmd/gc/reflect.c and I
    believe that we're trying to get away from C in the runtime [1]. Besides,
    I'm unfamiliar with the C codebase.

    Given the big amounts of changes taking place simultaneously in the
    compiler; does this make sense to do this way?

    [1] https://talks.golang.org/2015/state-of-go.slide#10
    On Saturday, February 14, 2015 at 7:10:58 PM UTC+1, thwd wrote:

    Hi Dave,


    here's a minimal repro: https://gist.github.com/thwd/2b965b7912fea68b93d2

    In my implementation I fixed it by using a linear search but the root
    cause of the problem is probably in the code that generates the typelinks.


    Tom
    On Friday, February 13, 2015 at 4:09:56 AM UTC+1, Dave Day wrote:

    Hey Tom,

    Thanks for that info about typesByString. Do you have a test case which
    exposes that? I had thought that the test at :3694 would be sufficient:
    https://go-review.googlesource.com/#/c/1996/4/src/reflect/all_test.go

    The hash is only used for quick lookup in funcLookupCache.

    Dave

    On 12 February 2015 at 21:43, thwd wrote:

    + Dave Day

    Hi Dave

    As I was telling Sebastien; watch out for typesByString because it
    won't work cleanly for func types e.g. it will miss types and you'll end up
    building them even though they are already available in SRODATA. When that
    happens assertions won't work as expected. I ran into this problem in my
    own implementation and I think it's due to func types not being added in
    string-comparison order to the typelinks array.

    Also I was gonna ask you; what's the rtype.hash field good for in the
    case of func types?

    Tom
    On Wednesday, February 11, 2015 at 11:06:04 AM UTC+1, thwd wrote:
    On Wed, Feb 11, 2015 at 10:45 AM, Sebastien Binet wrote:

    it's in the pipe:
    https://go-review.googlesource.com/#/c/1996/

    (as well as, --shameless-plug-- ArrayOf:
    https://go-review.googlesource.com/#/c/4111/)

    Dude, this is exactly what I've been doing all weekend. If I only had
    known :)

    Maybe you already knew this, but heads up: the binary search used
    by typesByString will not work cleanly with func-typelinks because they are
    not added in string-comparison-order to the typelinks array like chans and
    the like. This is probably true for at least one of interfaces, arrays or
    structs as well.

    Tom

    PS: sorry for the duplicate email, I forgot to CC the list.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Apr 3, 2015 at 8:05 pm

    On Tue, Mar 31, 2015 at 8:47 PM, Dave Day wrote:
    @rsc, I'd like your input here.

    I'm wary of making big changes to typelink without your guidance, since I'm
    not familiar with the code. At the moment, the following fails:

    checkSameType(t, Zero(FuncOf([]Type{TypeOf(int(0))}, nil,
    false)).Interface(), (func(int))(nil))

    However, this works:

    type T1 int
    checkSameType(t, Zero(FuncOf([]Type{TypeOf(T1(0))}, nil,
    false)).Interface(), (func(T1))(nil))
    The typelinks approach clearly requires that the typelinks be sorted
    by reflection string. Currently, the linker sorts the typelinks (like
    all symbols) by name, and assumes that is sufficient to ensure that
    the reflection strings are sorted. The symbol name that it uses is
    generated by typelinksym in cmd/internal/gc/reflect.go. That symbol
    name is created by using the reflection string + "/" + the reflection
    string with full import paths for each package name. This approach
    should work fine provided no reflection string contains "/".

    If you drop something like this into reflect/type.go:

    func DumpTypelinks() {
      for _, t := range typelinks() {
       println(*t.string)
      }
    }

    then you can dump all the typelinks. If they are not in sorted order,
    then that is your problem.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Day at Apr 7, 2015 at 2:46 am
    If they are not in sorted order, then that is your problem.

    Yes, it looks like that is the problem. Specifically, it looks like the
    only things which are not sorted are pairs of funcs which differ only by
    the presence/absence of a return type. For example ""func(uint64)" appears
    after "func(uint64) bool". This makes sense if you also include the dropped
    "/" suffix.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Day at Apr 7, 2015 at 5:20 am

    On 7 April 2015 at 12:45, Dave Day wrote:

    If they are not in sorted order, then that is your problem.


    Yes, it looks like that is the problem. Specifically, it looks like the
    only things which are not sorted are pairs of funcs which differ only by
    the presence/absence of a return type. For example ""func(uint64)" appears
    after "func(uint64) bool". This makes sense if you also include the dropped
    "/" suffix.
    To add further info:
    – changing reflect/type.go to do a naïve, exhaustive search rather than a
    bin search fixes the reflect bug
    – changing the "/" separator to something less than " " (such as "\x1f")
    also fixes this by forcing the types to be correctly sorted. I don't know
    what the implications of that are; certainly nothing that all.bash
    complains about.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Apr 7, 2015 at 4:40 pm

    On Mon, Apr 6, 2015 at 10:19 PM, Dave Day wrote:
    On 7 April 2015 at 12:45, Dave Day wrote:

    If they are not in sorted order, then that is your problem.
    Yes, it looks like that is the problem. Specifically, it looks like the
    only things which are not sorted are pairs of funcs which differ only by the
    presence/absence of a return type. For example ""func(uint64)" appears after
    "func(uint64) bool". This makes sense if you also include the dropped "/"
    suffix.

    To add further info:
    – changing reflect/type.go to do a naïve, exhaustive search rather than a
    bin search fixes the reflect bug
    – changing the "/" separator to something less than " " (such as "\x1f")
    also fixes this by forcing the types to be correctly sorted. I don't know
    what the implications of that are; certainly nothing that all.bash complains
    about.
    What I did for a similar issue in gccgo was use a tab character. It's
    friendlier in that it can be printed. It's less friendly in that tab
    looks a lot like space. In principle these strings should never
    appear in the program (though I guess they will appear in the symbol
    names in the installed .a files). Anyhow, I would vote for using tab.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Day at Apr 7, 2015 at 11:49 pm
    Tab makes sense. I'll upload a patch with that fix now.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Apr 3, 2015 at 7:32 pm

    On Tue, Feb 17, 2015 at 8:52 AM, thwd wrote:
    * some named types are added to .typelink, although they're not supposed to
    according to comments in cmd/gc/reflect.c
    That sounds like a bug that should be fixed. There is no reason to
    put a named type into the typelinks. If possible, please file an
    issue with a reproduction. Thanks.
    * there's one big typelinks slice shared by runtime with reflect
    (runtime.reflect_typelinks() in runtime/runtime1.go linked as
    reflect.typelinks())
    * typesByString uses a binary search in combination with a linear one
    Yes, although the linear search is likely to be quite short.

    I propose:
    * fix code to only export unnamed (composite) types.
    Yes.

    * split typelinks slice into separate typelink-containers for funcs,
    channels, maps, slices, structs, and so forth.. 1 per kind
    I don't see a big advantage to doing this. Those different types are
    all automatically segregated in the typelinks slice anyhow, since they
    will be sorted separately.

    * make each typelink-container a map[string][]*reflect.rtype
    * typesByString uses map access

    My approach would be to leave runtime.typelinks() as-is and build the
    typelink-container maps in the reflect package's init() method. Reason being
    that in the contrary case I'd have to add to cmd/gc/reflect.c and I believe
    that we're trying to get away from C in the runtime [1]. Besides, I'm
    unfamiliar with the C codebase.
    We definitely don't want to do anything like this in the reflect
    package's init method. Approximately every program uses reflect.
    Approximately no program looks at typelinks. We don't want to
    penalize the startup of every program for the benefit of no program.

    The question is whether this is worth doing for the case of a program
    that actually does need the typelinks. My guess is that it is not.
    Even programs that use typelinks probably don't use it very much.
    Although approximately no program uses typelinks, should we slow down
    the programs that do use it for the benefit of programs that use it a
    lot? My intuition is that it's better to keep things simple. But if
    you have a counter-example, please present it. A counter-example
    would be a program that calls SliceOf, etc., a lot with a lot of
    different types.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 9, '15 at 5:47p
activeApr 7, '15 at 11:49p
posts21
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase