FAQ
Making the assumption that the reflect.MakeSlice function implemented this
behavior, I implemented my solution to be disappointed by:

panic("reflect.MakeSlice of non-slice type")


The signature is:

reflect.MakeSlice( typ reflect.Type, len, cap int ) reflect.Value


Is anyone aware of a solution to my problem? I have been over the reflect
package a few times without seeing a way to accomplish my goal.

Thanks.


--
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/groups/opt_out.

Search Discussions

  • Rémy Oudompheng at Mar 16, 2013 at 8:43 pm

    On 2013/3/16 wrote:
    Making the assumption that the reflect.MakeSlice function implemented this
    behavior, I implemented my solution to be disappointed by:

    panic("reflect.MakeSlice of non-slice type")


    The signature is:

    reflect.MakeSlice( typ reflect.Type, len, cap int ) reflect.Value


    Is anyone aware of a solution to my problem? I have been over the reflect
    package a few times without seeing a way to accomplish my goal.
    It is not possible to generate a slice type dynamically given the
    element type. However, in Go 1.1 it is planned that it becomes
    possible, but for the moment the implementation is not complete.

    Can you give backgroound on why you need it?

    Rémy.

    --
    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/groups/opt_out.
  • Chrismiddle10 at Mar 16, 2013 at 9:15 pm
    There have been two cases where I would like to have this functionality.

    The first case was: to abstractly convert a map to a slice. So I would need
    to be able to discover the map element type and then create the slice from
    it. Originally, the function was written under the impression that
    reflect.MakeSlice would handle it. It was an unpleasant surprise to receive
    the panic.

    The second case that came up today is related to the previous one. Once the
    slice was created, I was going to sort the slice based on its corresponding
    map key. So sorting using reflection data is the case. Abstractly sorting
    may still be completely achievable through reflect.Interface, but I have
    not tried this yet. The one thing that I do not want to do is implement a
    bunch of different versions of reflect.Interface.


    --
    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/groups/opt_out.
  • Carlos Castillo at Mar 17, 2013 at 1:21 am
    Since you know the map type, you can pass in a pointer to a slice to be
    filled (using reflect.Append). This way you don't need to construct the
    types (works in go1). If the types don't match you get a runtime panic.
    Here are examples for getting a slice of keys, a slice of values, and a
    slice of key,value structures.

    http://play.golang.org/p/Hn7kLc_Qm6
    On Saturday, March 16, 2013 2:15:33 PM UTC-7, chrism...@gmail.com wrote:

    There have been two cases where I would like to have this functionality.

    The first case was: to abstractly convert a map to a slice. So I would
    need to be able to discover the map element type and then create the slice
    from it. Originally, the function was written under the impression that
    reflect.MakeSlice would handle it. It was an unpleasant surprise to receive
    the panic.

    The second case that came up today is related to the previous one. Once
    the slice was created, I was going to sort the slice based on its
    corresponding map key. So sorting using reflection data is the case.
    Abstractly sorting may still be completely achievable through
    reflect.Interface, but I have not tried this yet. The one thing that I do
    not want to do is implement a bunch of different versions of
    reflect.Interface.

    --
    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/groups/opt_out.
  • Ugorji Nwoke at Mar 16, 2013 at 9:19 pm
    I think it is possible in Go 1.1.

    i.e.
    tInt := reflect.TypeOf(int(0))
    tIntSlice := reflect.SliceOf(tInt)
    rv := reflect.MakeSlice(tIntSlice, 0, 4)

    // Russ (I believe) added support for SliceOf, MapOf, ChanOf some time back.
    On Saturday, March 16, 2013 4:43:32 PM UTC-4, Rémy Oudompheng wrote:
    On 2013/3/16 <chrism...@gmail.com <javascript:>> wrote:
    Making the assumption that the reflect.MakeSlice function implemented this
    behavior, I implemented my solution to be disappointed by:

    panic("reflect.MakeSlice of non-slice type")


    The signature is:

    reflect.MakeSlice( typ reflect.Type, len, cap int ) reflect.Value


    Is anyone aware of a solution to my problem? I have been over the reflect
    package a few times without seeing a way to accomplish my goal.
    It is not possible to generate a slice type dynamically given the
    element type. However, in Go 1.1 it is planned that it becomes
    possible, but for the moment the implementation is not complete.

    Can you give backgroound on why you need it?

    Rémy.
    --
    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/groups/opt_out.
  • Rob Pike at Mar 16, 2013 at 10:07 pm
    I don't believe it's possible to sort a reflect.Value holding a slice
    unless you know the static element type or do something irresponsible
    such as convert the elements to strings and sort them. You need to be
    able to implement Less.

    -rob

    --
    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/groups/opt_out.
  • Rob Pike at Mar 16, 2013 at 11:44 pm
    I had to try it, stupid and expensive and inflexible though it is, it
    was a fun exercise.

    http://play.golang.org/p/A6TqPhC9Zp

    -rob

    --
    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/groups/opt_out.
  • Dan Kortschak at Mar 16, 2013 at 11:52 pm
    Dr Frankenstein, a monster is at the door to see you.

    http://play.golang.org/p/OrzYd27MSq

    --
    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/groups/opt_out.
  • Torben Weis at Mar 16, 2013 at 11:52 pm
    Works nice for numbers between 0 and 9, otherwise ....

    [2 2 2 3 6 7 9]
    [2 2 25 3 6 7 9]

    http://play.golang.org/p/4Ifb4lGB0X

    ... sorting this way is irresponsible, as you said :-)

    Torben

    2013/3/17 Rob Pike <r@golang.org>:
    I had to try it, stupid and expensive and inflexible though it is, it
    was a fun exercise.

    http://play.golang.org/p/A6TqPhC9Zp

    -rob

    --
    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/groups/opt_out.
    --
    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/groups/opt_out.
  • Rob Pike at Mar 17, 2013 at 1:50 am
    Wait, you thought this was a robust implementation?

    -rob

    --
    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/groups/opt_out.
  • Kevin Gillette at Mar 17, 2013 at 3:47 am
    Agreed. I catch glimpses of Murphy in every type assertion/switch of an empty interface that can't usefully handle the general case, or that doesn't fall on an output boundary. Certainly doing so is no less safe than a dynamically typed language, but that's still well below the quality of what you'd really want to put in the core of any go algorithm.

    Besides which, the notion of ”sorting” an assemblage of arbitrarily typed values is subjective to an application: some may want to sort a []byte with string semantics, while others may only need to sort by the binary representation of the slice header.

    Even in these cases, sort.Interface is the most succinct and clean approach for sorting. I've yet to come across any case where making a reflect-based generic utilitarian converter to handle otherwise static types actually saved any reasonable amount of app code, and more importantly, didn't feel ”unclean”

    --
    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/groups/opt_out.
  • Kevin Gillette at Mar 17, 2013 at 3:49 am
    Agreed. I catch glimpses of Murphy in every type assertion/switch of an empty interface that can't usefully handle the general case, or that doesn't fall on an output boundary. Certainly doing so is no less safe than a dynamically typed language, but that's still well below the quality of what you'd really want to put in the core of any go algorithm.

    Besides which, the notion of ”sorting” an assemblage of arbitrarily typed values is subjective to an application: some may want to sort a []byte with string semantics, while others may only need to sort by the binary representation of the slice header.

    Even in these cases, sort.Interface is the most succinct and clean approach for sorting. I've yet to come across any case where making a reflect-based generic utilitarian converter to handle otherwise static types actually saved any reasonable amount of app code, and more importantly, didn't feel ”unclean”

    --
    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/groups/opt_out.
  • Torben Weis at Mar 17, 2013 at 12:31 pm

    2013/3/17 Rob Pike <r@golang.org>:
    Wait, you thought this was a robust implementation?
    No, just could not resist pointing it out.

    Torben
    -rob
    --
    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/groups/opt_out.
  • Vova Niki at Mar 17, 2013 at 1:29 pm
    http://play.golang.org/p/62uhKwFh1Z
    On Sunday, March 17, 2013 1:52:40 AM UTC+2, Torben wrote:

    Works nice for numbers between 0 and 9, otherwise ....

    [2 2 2 3 6 7 9]
    [2 2 25 3 6 7 9]

    http://play.golang.org/p/4Ifb4lGB0X

    ... sorting this way is irresponsible, as you said :-)

    Torben

    2013/3/17 Rob Pike <r...@golang.org <javascript:>>:
    I had to try it, stupid and expensive and inflexible though it is, it
    was a fun exercise.

    http://play.golang.org/p/A6TqPhC9Zp

    -rob

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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/groups/opt_out.
  • Jan Mercl at Mar 17, 2013 at 1:57 pm

    On Sun, Mar 17, 2013 at 2:29 PM, Vova Niki wrote:
    http://play.golang.org/p/62uhKwFh1Z
    I think a reflection based dynamic Go interpreter is just behind the corner.

    -j

    --
    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/groups/opt_out.
  • Kevin Gillette at Mar 17, 2013 at 5:37 pm
    @Jan: please elaborate or add context. Can't tell if that's tongue-in-cheek about this thread, or a prediction about go itself

    --
    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/groups/opt_out.
  • Jan Mercl at Mar 17, 2013 at 6:53 pm

    On Sun, Mar 17, 2013 at 6:37 PM, Kevin Gillette wrote:
    @Jan: please elaborate or add context. Can't tell if that's tongue-in-cheek about this thread, or a prediction about go itself
    Sad, reflective sarcasm, of course. Sorry for the noise.

    -j

    --
    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/groups/opt_out.
  • Dan Kortschak at Mar 17, 2013 at 8:02 pm
    Worse, I think we have the basis for a php implementation... oh right.
    On 18/03/2013, at 12:27 AM, "Jan Mercl" wrote:

    I think a reflection based dynamic Go interpreter is just behind the corner.
    --
    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/groups/opt_out.
  • Jan Mercl at Mar 27, 2013 at 10:59 am

    On Sun, Mar 17, 2013 at 2:57 PM, Jan Mercl wrote:
    On Sun, Mar 17, 2013 at 2:29 PM, Vova Niki wrote:
    http://play.golang.org/p/62uhKwFh1Z
    I think a reflection based dynamic Go interpreter is just behind the corner.
    https://groups.google.com/d/msg/golang-nuts/nqljw9P9KWU/UZ4IAgYnty8J

    -j

    --
    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/groups/opt_out.
  • Sebastien Binet at Mar 27, 2013 at 11:57 am
    Jan,
    On Wed, Mar 27, 2013 at 11:59 AM, Jan Mercl wrote:
    On Sun, Mar 17, 2013 at 2:57 PM, Jan Mercl wrote:
    On Sun, Mar 17, 2013 at 2:29 PM, Vova Niki wrote:
    http://play.golang.org/p/62uhKwFh1Z
    I think a reflection based dynamic Go interpreter is just behind the corner.
    https://groups.google.com/d/msg/golang-nuts/nqljw9P9KWU/UZ4IAgYnty8J
    yes, is that a bad thing ? :)
    the playground is great.
    go run is great.
    the various go-repls which compile+run on-the-fly are great.

    ...but, for some kind of work, a real interpreter is just better.

    -s

    --
    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/groups/opt_out.
  • Jan Mercl at Mar 27, 2013 at 12:49 pm

    On Wed, Mar 27, 2013 at 12:57 PM, Sebastien Binet wrote:
    yes, is that a bad thing ? :)
    Well, IMO yes ;-)
    the playground is great.
    Yes. And it's not an interpreter.
    go run is great.
    go run is a handy tool. It is heavily abused for things completely
    different than what is was intended for.
    the various go-repls which compile+run on-the-fly are great.
    I know one C REPL. I know zero people which ever used it. Both C and
    Go are statically type checked
    compiled-to-machine-code-for-great-performance languages. No serious
    developer is probably developing anything substantially more complex
    than hello_world.c in a C REPL. Why should be Go any different?

    Frankly, I consider the idea of simulating (to some extent) Go REPL by
    "compile+run on-the-fly" even uglier than a proper REPL per se.
    ...but, for some kind of work, a real interpreter is just better.
    Sure. I guess there might be legitimate use cases for it. Cannot
    imagine any single one ATM, though.

    -j

    PS: It doesn't matter what do I think about it. It will appear sooner
    or later anyway, probably.

    --
    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/groups/opt_out.
  • Sebastien Binet at Mar 27, 2013 at 1:14 pm
    Jan,
    On Wed, Mar 27, 2013 at 1:49 PM, Jan Mercl wrote:
    On Wed, Mar 27, 2013 at 12:57 PM, Sebastien Binet wrote:
    yes, is that a bad thing ? :)
    Well, IMO yes ;-)
    the playground is great.
    Yes. And it's not an interpreter.
    go run is great.
    go run is a handy tool. It is heavily abused for things completely
    different than what is was intended for.
    the various go-repls which compile+run on-the-fly are great.
    I know one C REPL. I know zero people which ever used it. Both C and
    Go are statically type checked
    compiled-to-machine-code-for-great-performance languages. No serious
    developer is probably developing anything substantially more complex
    than hello_world.c in a C REPL. Why should be Go any different?
    high energy physics people would beg to differ.
    CERN has a long history of developing interpreters (COMIS for FORTRAN,
    CINT for C/C++ and more recently (and less buggy) CLing for C/C++
    (based on LLVM/CLang))
    interpreters have been the "bread and butter" of scientific investigatory work.
    you somehow load your data file, write little functions to inspect,
    iteratively refine and plot data, or create new analysis algorithms to
    extract information(s) out of the TB of data: that's best done in an
    interpreter where you can iteratively inspect and modify the state of
    your program.
    (of course, theoretically, one could save/dump the state of a serie of
    programs, analysis-step-00-to-01, -01-to-02,... saving the interesting
    data for later re-use, and the reflect+json/gob/whatever do make this
    job easy, but that's a lot of scaffolding you get for (almost) free
    with an interpreter)

    usually, the little functions end up being PhD theses and eventually
    also end up in the physics experiment's official code (which, for
    obvious reasons of performances, has to be compiled)
    not having to write your prototyping code in one language and then the
    production-ready one in another one is just plainly nice (physicists
    usually can't be bothered to learn one programming language, so, 2 ?!)

    to be completely honest, it is true that thanks to completely
    effortless way of compiling 3rd-party packages provided by go get and
    the Go ecosystem in general, the tediousness of the compile-run-edit
    cycle one is familiar with in C/C++ does not hold in Go (and so is a
    rather enjoyable experience, IMHO)
    Frankly, I consider the idea of simulating (to some extent) Go REPL by
    "compile+run on-the-fly" even uglier than a proper REPL per se.
    I can't say I disagree.

    -s

    --
    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/groups/opt_out.
  • Jan Mercl at Mar 27, 2013 at 1:32 pm

    On Wed, Mar 27, 2013 at 2:13 PM, Sebastien Binet wrote:
    high energy physics people would beg to differ.
    CERN has a long history of developing interpreters (COMIS for FORTRAN,
    CINT for C/C++ and more recently (and less buggy) CLing for C/C++
    (based on LLVM/CLang))
    interpreters have been the "bread and butter" of scientific investigatory work.
    you somehow load your data file, write little functions to inspect,
    iteratively refine and plot data, or create new analysis algorithms to
    extract information(s) out of the TB of data: that's best done in an
    interpreter where you can iteratively inspect and modify the state of
    your program.
    (of course, theoretically, one could save/dump the state of a serie of
    programs, analysis-step-00-to-01, -01-to-02,... saving the interesting
    data for later re-use, and the reflect+json/gob/whatever do make this
    job easy, but that's a lot of scaffolding you get for (almost) free
    with an interpreter)
    Usage cases for _interpreted_ languages are legitimate, of course. If
    one needs to write a simple script, there are so many scripting
    languages available out there. What's the advantage of scripting in
    FORTRAN or C/C++?
    usually, the little functions end up being PhD theses and eventually
    also end up in the physics experiment's official code (which, for
    obvious reasons of performances, has to be compiled)
    not having to write your prototyping code in one language and then the
    production-ready one in another one is just plainly nice (physicists
    usually can't be bothered to learn one programming language, so, 2 ?!)
    Ah, so here's is the reason. A particularly bad one, IMHO. Debugging
    statically typed compiled languages by an interpreter is IMO a pretty
    non standard approach. Sometimes simply unusable (too slow program
    progress).

    And last but no least: Debugging in Go is particularly easy compared
    to anything I ever coded in. I used to use clewn (a gdb wrapper) few
    times while Go hacking, but it didn't yet happened to me this year at
    all.

    Everyone is totally free to find and use tools which make things done
    for him. It's just IMO this specific (interpreter middle ware)
    approach get things done later than the common (compiler, debug prints
    and/or gdb) way.
    to be completely honest, it is true that thanks to completely
    effortless way of compiling 3rd-party packages provided by go get and
    the Go ecosystem in general, the tediousness of the compile-run-edit
    cycle one is familiar with in C/C++ does not hold in Go (and so is a
    rather enjoyable experience, IMHO)
    Yep, that's what I observe here as well ;-)

    -j

    --
    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/groups/opt_out.
  • Nico at Mar 27, 2013 at 1:59 pm
    I think one of most important reasons why some would like to see an REPL
    is to explore the use of well documented libraries, the same way people
    do with python.

    Up to certain extend, the playground has covered this need. though not
    fully.


    Nico

    --
    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/groups/opt_out.
  • Atomly at Mar 28, 2013 at 12:03 am
    Are you really trying to argue that debug prints are better than a REPL?

    Also, a REPL can be immensely useful for things that have nothing to do
    with debugging code that you're writing. They are great for testing out
    ideas, composing objects in new and interesting ways, etc.

    They are also incredibly useful for doing things like interacting with a
    data store. Let's say you have a DAO layer that lets you save a user
    object. You can fire up your REPL and use this to create all the necessary
    data in your DB instead of trying to do a bunch of inserts by hand. Or you
    can use a REPL to, for example, clear stale data out of your cache.

    I wouldn't say that a REPL is 100% necessary to a language, but I find that
    it will often save a lot of time and prove incredibly useful in myriad
    situations.

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Wed, Mar 27, 2013 at 9:31 AM, Jan Mercl wrote:
    On Wed, Mar 27, 2013 at 2:13 PM, Sebastien Binet wrote:
    high energy physics people would beg to differ.
    CERN has a long history of developing interpreters (COMIS for FORTRAN,
    CINT for C/C++ and more recently (and less buggy) CLing for C/C++
    (based on LLVM/CLang))
    interpreters have been the "bread and butter" of scientific
    investigatory work.
    you somehow load your data file, write little functions to inspect,
    iteratively refine and plot data, or create new analysis algorithms to
    extract information(s) out of the TB of data: that's best done in an
    interpreter where you can iteratively inspect and modify the state of
    your program.
    (of course, theoretically, one could save/dump the state of a serie of
    programs, analysis-step-00-to-01, -01-to-02,... saving the interesting
    data for later re-use, and the reflect+json/gob/whatever do make this
    job easy, but that's a lot of scaffolding you get for (almost) free
    with an interpreter)
    Usage cases for _interpreted_ languages are legitimate, of course. If
    one needs to write a simple script, there are so many scripting
    languages available out there. What's the advantage of scripting in
    FORTRAN or C/C++?
    usually, the little functions end up being PhD theses and eventually
    also end up in the physics experiment's official code (which, for
    obvious reasons of performances, has to be compiled)
    not having to write your prototyping code in one language and then the
    production-ready one in another one is just plainly nice (physicists
    usually can't be bothered to learn one programming language, so, 2 ?!)
    Ah, so here's is the reason. A particularly bad one, IMHO. Debugging
    statically typed compiled languages by an interpreter is IMO a pretty
    non standard approach. Sometimes simply unusable (too slow program
    progress).

    And last but no least: Debugging in Go is particularly easy compared
    to anything I ever coded in. I used to use clewn (a gdb wrapper) few
    times while Go hacking, but it didn't yet happened to me this year at
    all.

    Everyone is totally free to find and use tools which make things done
    for him. It's just IMO this specific (interpreter middle ware)
    approach get things done later than the common (compiler, debug prints
    and/or gdb) way.
    to be completely honest, it is true that thanks to completely
    effortless way of compiling 3rd-party packages provided by go get and
    the Go ecosystem in general, the tediousness of the compile-run-edit
    cycle one is familiar with in C/C++ does not hold in Go (and so is a
    rather enjoyable experience, IMHO)
    Yep, that's what I observe here as well ;-)

    -j

    --
    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/groups/opt_out.

    --
    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/groups/opt_out.
  • Jan Mercl at Mar 30, 2013 at 6:55 pm

    On Mar 28, 2013 1:03 AM, "atomly" wrote:
    Are you really trying to argue that debug prints are better than a REPL?
    Are you really trying to argue that using CINT is better than GDB? ;-)

    -j

    --
    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/groups/opt_out.
  • Sebastien Binet at Mar 30, 2013 at 7:20 pm

    On Sat, Mar 30, 2013 at 7:55 PM, Jan Mercl wrote:
    On Mar 28, 2013 1:03 AM, "atomly" wrote:

    Are you really trying to argue that debug prints are better than a REPL?
    Are you really trying to argue that using CINT is better than GDB? ;-)
    having suffered from using CINT during my PhD (before python became a
    tool blessed by the community) I can say that nobody should never ever
    say that :P
    besides, you always have to have GDB around to debug CINT...

    -s

    --
    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/groups/opt_out.
  • Rob Pike at Mar 17, 2013 at 3:58 pm
    Now try adding a struct. Or a pointer to a struct.
    On Sun, Mar 17, 2013 at 6:29 AM, Vova Niki wrote:
    http://play.golang.org/p/62uhKwFh1Z
    On Sunday, March 17, 2013 1:52:40 AM UTC+2, Torben wrote:

    Works nice for numbers between 0 and 9, otherwise ....

    [2 2 2 3 6 7 9]
    [2 2 25 3 6 7 9]

    http://play.golang.org/p/4Ifb4lGB0X

    ... sorting this way is irresponsible, as you said :-)

    Torben

    2013/3/17 Rob Pike <r...@golang.org>:
    I had to try it, stupid and expensive and inflexible though it is, it
    was a fun exercise.

    http://play.golang.org/p/A6TqPhC9Zp

    -rob

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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/groups/opt_out.
    --
    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/groups/opt_out.
  • Clbanning at Mar 17, 2013 at 7:23 pm
    Back to original question: generalized sorting of maps with unknown key
    type. You do have to define the rules for 'sort.Less'; but if you load the
    map into an array, []map[interface{}]interface{}, you can sort all types of
    keys.

    An example: http://play.golang.org/p/h6RPAFA2js
    On Saturday, March 16, 2013 2:31:58 PM UTC-5, chrism...@gmail.com wrote:

    Making the assumption that the reflect.MakeSlice function implemented this
    behavior, I implemented my solution to be disappointed by:

    panic("reflect.MakeSlice of non-slice type")


    The signature is:

    reflect.MakeSlice( typ reflect.Type, len, cap int ) reflect.Value


    Is anyone aware of a solution to my problem? I have been over the reflect
    package a few times without seeing a way to accomplish my goal.

    Thanks.

    --
    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/groups/opt_out.
  • Rob Pike at Mar 17, 2013 at 7:51 pm
    No, not all sorts, only some sorts.

    -rob

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 16, '13 at 8:36p
activeMar 30, '13 at 7:20p
posts30
users14
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase