[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Chris Hines]

I believe these are fantastic choices.

I have given two presentations to Go meetups about the draft generics 
design in the last month. The second time was after the square bracket idea 
was added to the prototype and someone suggested the other parts adopted in 
item #1. In that second presentation I used the []'s syntax while walking 
through some examples and found it really helped the readability. In 
addition I was an instant fan of the [T any] syntax when it was suggested 
and I am happy to see that adopted. The rest of the tweaks are welcome as 
well, especially the addition of type switches on type parameters. I look 
forward to trying that out because I believe it plugs a hole in the design 
I had felt in my earlier experiments.

Well done and thanks to everyone who has helped provide feedback leading to 
these improvements.

Chris

On Thursday, August 20, 2020 at 8:28:23 PM UTC-4 Ian Lance Taylor wrote:

> After many discussions and reading many comments, we plan to move
> forward with some changes and clarifications to the generics design
> draft.
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list. To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint. This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets). To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
>
> The result is declarations that look like this:
>
> type Vector[T any] []T
> func Print[T any](s []T) { … }
> func Index[T comparable](s []T, e T) { … }
>
> We feel that the cost of the new predeclared identifier “any” is
> outweighed by the simplification achieved by making all parameter
> lists syntactically the same: as each regular parameter always has a
> type, each type parameter always has a constraint (its meta-type).
>
> Changing “[type T]” to “[T any]” seems about equally readable and
> saves one character. We’ll be able to streamline a lot of existing
> code in the standard library and elsewhere by replacing “interface{}”
> with “any”.
>
> 2.
>
> We’re going to simplify the rule for type list satisfaction. The type
> argument will satisfy the constraint if the type argument is identical
> to any type in the type list, or if the underlying type of the type
> argument is identical to any type in the type list. What we are
> removing here is any use of the underlying types of the types in the
> type list. This tweaked rule means that the type list can decide
> whether to accept an exact defined type, other than a predeclared
> type, or whether to accept any type with a matching underlying type.
>
> This is a subtle change that we don’t expect to affect any existing
> experimental code.
>
> We think that this definition might work if we permit interface types
> with type lists to be used outside of type constraints. Such
> interfaces would effectively act like sum types. That is not part of
> this design draft, but it’s an obvious thing to consider for the
> future.
>
> Note that a type list can mention type parameters (that is, other type
> parameters in the same type parameter list). These will be checked by
> first replacing the type parameter(s) with the corresponding type
> argument(s), and then using the rule described above.
>
> 3.
>
> We’re going to clarify that when considering the operations permitted
> for a value whose type is a type parameter, we will ignore the methods
> of any types in the type list. The general rule is that the generic
> function can use any operation permitted by every type in the type
> list. However, this will only apply to operators and predeclared
> functions (such as "len" and "cap"). It won’t apply to methods, for
> the case where the type list includes a list of types that all define
> some method. Any methods must be listed separately in the interface
> type, not inherited from the type list.
>
> This rule seems generally clear, and avoids some complex reasoning
> involving type lists that include structs with embedded type
> parameters.
>
> 4.
>
> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”. A type switch on a type
> parameter won’t be able to use the “:=” syntax anyhow, so there is no
> reason to require “.(type)”. In a type switch on a type parameter
> with a type list, every case listed must be a type that appears in the
> type list (“default” is also permitted, of course). A case will be
> chosen if it is the type matched by the type argument, although as
> discussed above it may not be the 

[go-nuts] Re: main() cannot call method in another file

[Chris Hines]

go run  works now too and pulls in all the files in the package at 
 so "go run ." is a nice shortcut that works more like the other 
subcommands of the go tool.

On Thursday, October 24, 2019 at 8:17:54 AM UTC-4, Guy Allard wrote:
>
> Use:
>
> go run *.go
>
> or
>
> go build *.go
>
>
> On Wednesday, October 23, 2019 at 1:20:26 AM UTC-4, Cam wrote:
>>
>> Hi everyone on Golang group,
>>
>> I'm having difficulty with some simple code, and appreciate if someone 
>> can point out a solution.
>>
>> There is a simple main package that looks like this:
>>
>> github.com/username/playground/
>> hello.go
>> main.go
>>
>> hello.go:
>>
>> package main
>> import "fmt"
>> func SayHello() {
>>   fmt.Println("Hello")
>> }
>>
>> main.go
>>
>> package main
>> func main() {
>>   SayHello()
>> }
>>
>> Trying to run main.go is producing an error:
>>
>> # command-line-arguments
>> go/src/github.com/username/playground/main.go:4:2: undefined: SayHello
>>
>> Why is this error happening? Is my packaging done wrong?
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2266cc30-053b-49ef-9418-fc24ecf9fe4d%40googlegroups.com.

[go-nuts] Re: trace tool showing goroutines moving between procs after LockOSThread

[Chris Hines]

I am pretty sure that a "proc" in the trace visualization output is the 
same as a "P" in the parlance of the Go runtime scheduler. In the scheduler 
an OS thread is an "M" and even when using LockOSThread the locked 
goroutine and thread need to be paired up with one of the scheduler's Ps in 
order to execute the goroutine's code. There are always GOMAXPROCS # of Ps 
in the scheduler. See the comment block starting at line 19 in this code 
for more detail. https://golang.org/src/runtime/proc.go

Hope that helps,
Chris

On Sunday, October 6, 2019 at 7:47:43 AM UTC-4, Miki Tebeka wrote:
>
> Hi,
>
> I'm trying to understand output of the "go tool trace". I'm using 
> runtime.LockOSThread, however the output of the trace tool shows goroutines 
> moving between procs (which I *think* are OS threads). What am I missing?
>
> Code:
> package main
>
> import (
> "fmt"
> "os"
> "runtime"
> "runtime/trace"
> "time"
> )
>
> func sqrt(val float64) (float64, error) {
> if val < 0.0 {
> return 0.0, fmt.Errorf("sqrt of negative number")
> }
>
> if val == 0.0 {
> return 0.0, nil // shortcut
> }
>
> guess, epsilon := 1.0, 0.1
> for i := 0; i < 1; i++ {
> diff := guess*guess - val
> if diff < 0 {
> diff = -diff
> }
> if diff <= epsilon {
> return guess, nil
> }
> guess = (val/guess + guess) / 2.0
> }
>
> return 0.0, fmt.Errorf("can't find sqrt of %f", val)
> }
>
> func worker(id int) {
> runtime.LockOSThread()
> i := float64(0)
> for {
> for n := 0; n < 100; n++ {
> i += 13.2
> _, err := sqrt(i)
> if err != nil {
> panic(err)
> }
> }
> runtime.Gosched()
> }
> }
>
> func main() {
> out, err := os.Create("trace.out")
> if err != nil {
> panic(err)
> }
> defer out.Close()
> if err := trace.Start(out); err != nil {
> panic(err)
> }
> defer trace.Stop()
>
> for i := 0; i < runtime.NumCPU(); i++ {
> go worker(i)
> }
>
> time.Sleep(3 * time.Second)
> }
>
>
> What I see in trace:
>
> [image: trace-out.png]
>
> Thanks,
> Miki
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/065a383e-9716-441b-8327-60cdf97518ec%40googlegroups.com.

[go-nuts] Re: how to create path/v2 and path/v3 and path/v4 in same repo

[Chris Hines]

You might be able to find an answer to your question in this article: 
https://github.com/go-modules-by-example/index/tree/master/016_major_version_repo_strategy

On Tuesday, August 27, 2019 at 6:31:57 AM UTC-4, Jason E. Aten wrote:
>
> With an eye towards implementing semantic import path versioning, is it 
> possible to have
>
> https://gihtub.com/me/path/v2
> https://github.com/me/path/v3
>
> point (somehow, the question is how?) to different tags within the same 
> https://github.com/me/path  repo?
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3f0902ba-3f19-4b74-99a0-969d14dc6bc7%40googlegroups.com.

[go-nuts] Re: Open Source audit of go package dependencies for security vulnerabilities?

[Chris Hines]

Have you seen: https://github.com/sonatype-nexus-community/nancy

"A tool to check for vulnerabilities in your Golang dependencies, powered 
by Sonatype OSS Index"


On Wednesday, August 14, 2019 at 1:02:03 AM UTC-4, Eric Johnson wrote:
>
> And then, it also occurs to me that perhaps I can answer my own question. 
> Taking advantage of three aspects of the ecosystem.
>
> #1) Most open source Go libraries are on GitHub
> #2) Many (most?) CVEs for open source projects will include a reference 
> back to the project, and these references can be extracted from the 
> cvelist  project.
> #3) GitHub has an API to fetch the language of a GitHub repository.
>
> Putting those three together, it might be possible to filter every CVE 
> entry that has a reference to GitHub, then every GitHub project in that 
> list that is implemented in Go, and turn that into a list of 
> vulnerabilities for packages. Then match on those packages. That might 
> generate a short list of projects that have had vulnerabilities. That far 
> more reasonable list could then be augmented by a small amount of open 
> source labor to annotate with the versions known to be vulnerable, when new 
> items appear.
>
> From a completely different direction, the CVE quality team is looking to 
> add more data to CVE entries. Seems like implementation language + package 
> management name as additional data in the CVE record itself might also help 
> address the issue. That would be generalizable to Java, Javascript. Rust, 
> Python, and Go, for starters.
>
> Before I send that idea in to the quality WG, does anyone here have a 
> better suggestion?
>
> Eric
>
> On Tuesday, August 13, 2019 at 9:50:19 PM UTC-7, Eric Johnson wrote:
>>
>> It would be great to hear of an answer to this question. I suspect there 
>> isn't one, though.
>>
>> The trouble is, one of the first hurdles is to identify Go libraries that 
>> have CVEs against them. It is very easy to find CVEs for the Go standard 
>> library, but I cannot see any easy way to scan the vulnerability databases 
>> for vulnerable projects that happen to be implemented in Go.
>>
>> On top of that, for the purposes of dependency scanning, we really only 
>> need to care about those projects implemented in Go that have non-main 
>> packages. The main packages may have vulnerabilities, but those will never 
>> show up in a dependency scan...
>>
>> If one can identify that list, then the open source tool to find any 
>> dependent libraries that might have vulnerabilities would be pretty 
>> straightforward.
>>
>> Unfortunately, identifying that list is might be really hard. Currently 
>> probably only possible for companies that have a business model that 
>> supports paying people to investigate each and every one of the 
>> vulnerabilities that shows up with a CVE
>>
>> Maybe someone on this list can think of a great way to filter the CVE 
>> list
>>
>> Eric.
>>
>> On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote:
>>>
>>> I've been introduced to https://rubysec.com/ which has a database 
>>> which easily integrates with builds to check for known security 
>>> vulnerabilities in third party libraries and was wondering whether 
>>> anything similar exists for go packages? 
>>>
>>> A quick search finds https://snyk.io/vuln?type=golang which appears 
>>> similar but is basically a pay service based on node.js. 
>>>
>>> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project 
>>> looks interesting but doesn't include go. 
>>>
>>> Does such an open source version exist for go which is written in go 
>>> and integrates easily with builds? 
>>>
>>> -- 
>>> Steve Mynott  
>>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ecc1f0e7-b371-46b7-bb88-9ab518120332%40googlegroups.com.

Re: [go-nuts] Built-in log Package

[Chris Hines]

On Thursday, August 17, 2017 at 3:14:09 AM UTC-4, Henrik Johansson wrote:
>
> Sorry to but in but what happened to the whole logging initiative that was 
> on going?
> Did I miss something about that? It seems very related to this.
>

That discussion took place in this thread: 
https://groups.google.com/forum/#!topic/golang-dev/F3l9Iz1JX4g

Some proposals were drafted (links to them are in the above thread). 
Proposal authors also had two conference calls to discuss and share ideas 
and opinions. Notes from those meetings were recorded in these two 
documents:

https://docs.google.com/document/d/1hovWbs19GvzfYDd-2RSYw4GN3h4vkbPUj_qO5cZa1uU/edit?usp=sharing
https://docs.google.com/document/d/1IOaEPwmVZrvlCg5anWI0UC9yaZmihSiMvu6-471f8KY/edit?usp=sharing

I don't know if the last two links will work for everyone because of 
permissions on the docs. I don't own the docs, so I cannot change the 
permissions. I will try to get the owner to open the permissions for 
viewing.

The general consensus (as I perceived it) was that logging use cases are 
too diverse to make a standard interface that satisfies a wide enough 
range. The group felt that persuading the community to treat logging as an 
application concern and that libraries should return errors or provide 
hooks rather than log directly. The last several slides of my talk (linked 
to earlier in the thread) was my attempt to persuade/educate along those 
lines.

Chris

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Built-in log Package

[Chris Hines]

Thanks for your thoughtful response. I agree with many of your points, 
especially the benefits of structured logging, both on the usefulness of 
the logs and the flow of the code as it builds the logging context. I have 
a few comments on some of your points:

> Of these, I lean towards the zap style because it's not significantly 
more verbose (IMHO), it's more type safe, and faster.

The price of the zap API is that any package that doesn't use the sugared 
API becomes coupled to the zap and zapcore packages. The closest thing it 
provides to a fundamental interface is zapcore.Encoder 
<https://godoc.org/go.uber.org/zap/zapcore#Encoder> which requires 
arguments of their concrete types `zapcore.Entry` and `zapcore.Field`. 
Another strike against zap, IMHO, is the sheer size of it's API. It also 
seems to me that customizing it's behavior would be a non-trivial exercise.

> I really like the way that it [zap] never combines the log line into 
something heavy like a map[string]interface{}, and that it just logs its 
fields in the order they were passed - so it's more like a traditional log 
line, just with JSON boundaries.

I agree and go-kit/log is the same as zap in this regard. It is true that 
go-kit/log currently implements JSON logging by converting to a map and 
using enconding/json to serialize the result. That is the simplest 
implementation, but it is not required by the go-kit/log.Logger interface 
and I am currently working on a new implementation that serializes to JSON 
directly from a keyvals slice. When complete, this will provide a 
significant performance improvement, bringing the speed of JSON output on 
par with the speed of logfmt output.

> It's never really appropriate to use anything other than stdlib logging 
to log with in a library, and that's the nub of the problem: it means 
libraries will pretty much always have unstructured logging.

As I explained at the end of my talk, I don't think it is appropriate for 
public libraries to log at all. My rationale is much broader than simply 
structured vs. unstructured, or stdlib vs. pick your logger. My rationale 
is that once a library chooses to log it has taken that choice away from 
the application it is eventually used by and public libraries harm their 
reusability by doing so. Logging is an application concern.

If a public library does choose to log, it should do so by a simple 
interface that isn't coupled to anything outside the package itself, the 
language, or the standard library; preferably a locally defined interface. 
Note that the go-kit/log.Logger interface meets this goal. Any package can 
copy that interface into its API and be compatible with go-kit/log style 
loggers without any external dependencies.

Non-public libraries have more leeway because, presumably, the library is 
closely related to a small set of applications that have common logging 
needs or the library is owned by an organization that has dictated a 
standard logging package. That said, designing private libraries as if they 
were public libraries could be a good idea in the long run.

Chris

On Tuesday, August 15, 2017 at 12:09:44 PM UTC-4, Sam Vilain wrote:
>
> On 8/15/17 7:14 AM, Chris Hines wrote:
>
> I would be curious what you think of github.com/go-kit/kit/log (and 
> related "sub"-packages). See my talk about it's design here: 
>
> Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw
> Slides: https://speakerdeck.com/chrishines/go-kit-log-package
>
> I can see what you're going for with that, and in a way it's demonstrating 
> some sugar issues in go.  For some reason, folk expect to be able to write 
> logging statements without an awful lot of unsightly brackets and 
> constructors :-).
>
> To quickly round them up, this module uses what I consider to be Perl 
> 5-esque "slurpy hashes":
>
> // Unstructured
> log.Printf("HTTP server listening on %s", addr)
> // Structured
> logger.Log("transport", "HTTP", "addr", addr, "msg", "listening") 
> <https://github.com/go-kit/kit/tree/master/log#usage>
>
> Whereas logrus steers you towards a map[string]interface{}:
>
> func main() {
>   log.WithFields(log.Fields{
> "animal": "walrus",
>   }).Info("A walrus appears")
> }
>
> And zap uses type-safe individual field constructors:
>
> logger.Info("failed to fetch URL",
>   // Structured context as strongly typed Field values.
>   zap.String("url", url),
>   zap.Int("attempt", 3),
>   zap.Duration("backoff", time.Second),
> )
>
> Of these, I lean towards the zap style because it's not significantly more 
> verbose (IMHO), it's more type safe, and faster.
>
> However, the syntax sugar issue has meant that zap now also have a similar

Re: [go-nuts] Built-in log Package

[Chris Hines]

I would be curious what you think of github.com/go-kit/kit/log (and related 
"sub"-packages). See my talk about it's design here:

Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw
Slides: https://speakerdeck.com/chrishines/go-kit-log-package

Chris

On Monday, August 14, 2017 at 2:15:17 PM UTC-4, Sam Vilain wrote:
>
> The main problem with the Printf-style interface is that it's not worth 
> building real applications with.  For anything with non-trivial logging 
> needs, you need:
>
> * tagging of log lines with identifiers such as PID, host, request ID, etc
> * structured for easier downstream analysis by tools like the ELK stack 
> and common commercial systems like splunk
>
> What I've had to do to achieve this is to pass an alternate writer to the 
> "standard log" interface expected by various libraries (eg, Sarama) and add 
> PID and host tagging to that.   Writing things in terms of "prefix" 
> represents a very limited view of log correlation; it worked for syslog 
> perhaps but the world has moved on.  Log levels are also mostly useless.
>
> The right API to me is probably somewhere between logrus and Uber's zap.  
> These systems are in more widespread use with a different set of 
> priorities, and it would be good to be able to plug into those (and see 
> also my context suggestion which could let these libraries automatically 
> connect with a configured logger)
>
> Sam
>
>
> On Mon, Aug 14, 2017 at 9:36 AM, dc0d  > wrote:
>
>> Some packages tried that approach, adding levels as prefixes (which I 
>> prefer to defining methods). But did not get enough attention.
>>
>> Whatever approach that may get chosen for a logging package, the logger 
>> struct should implement some Logger interface and should accept an instance 
>> of another object which also implements the Logger interface.
>>
>> This way it will be possible to not only handle the log entries at lower 
>> layers but also to have a hierarchy of loggers to the top (where logging is 
>> happening) which can behave differently based on the (conceptual) context - 
>> choosing the formatters, the destinations or notifying another system.
>>
>> And levels could be expanded to tags. A tagged entry can be processed 
>> based on its tags (including a concept like level) - but it seems (sadly) 
>> that levels are more wide-spread than just being a tag.
>>
>> That sort of interface, is what I would like to see. And you are right 
>> about that there is no conclusive agreement on what it should like.
>>
>> Another question that I failed to answer properly (by myself) is: are 
>> metrics same as logs? Or they are a higher level concept (which also can be 
>> logged)? And should logging be in charge of delivering metrics (seems it 
>> can be)?
>>
>>
>> On Monday, August 14, 2017 at 6:30:19 PM UTC+4:30, Peter Mogensen wrote:
>>>
>>>
>>>
>>> On 2017-08-14 11:04, dc0d wrote: 
>>> > That may be (still IMH-Experience in the majority of cases, this is 
>>> the 
>>> > proper default to go). 
>>> > 
>>> > But the main concern to express here is, the default logger should 
>>> > accept an interface like /Output/ instead of /io.Writer/. 
>>>
>>> I would agree, if not for the fact that there seem to be very little 
>>> consensus on exactly what such an interface should look like. 
>>>
>>> systemd support a very simple (but useful) interface for leveled 
>>> logging. Just prefix what you write to stdout or stderr with "" where 
>>> X is the syslog log-level. Systemd takes care of anything else. 
>>> Exactly this is pretty much impossible to do efficiently with many 
>>> log-packages, including the stdlib "log". 
>>>
>>> /Peter 
>>>
>> -- 
>> 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/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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Styleguide

[Chris Hines]

This discussion points out another nomenclature problem in the list. What 
the list refers to as a "Package comment" is actually a "Canonical import 
path" comment. See https://golang.org/doc/go1.4#canonicalimports

Package comments (as defined in this blog 
post: https://blog.golang.org/godoc-documenting-go-code) are for 
documenting a package, not restricting where it can be imported from.

On Tuesday, August 1, 2017 at 1:24:44 PM UTC-4, Peter Bourgon wrote:
>
> I think it's cost without much benefit. By definition, if a package 
> exists on your filesystem, you know where it came from: you put it 
> there, and you can inspect the path. 
>
> On Tue, Aug 1, 2017 at 7:19 PM, roger peppe  > wrote: 
> > On 1 August 2017 at 18:04, Peter Bourgon  > wrote: 
> >> Generally nice list. I find these items controversial i.e. shorthand 
> >> for I don't agree with them ;) 
> > [...] 
> >> - Use package comment 
> > 
> > This puzzles me. Why don't you think that having a package comment 
> > is a good idea? 
> > 
> >   rog. 
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Styleguide

[Chris Hines]

The code shown for "User decorator pattern" is more properly known as the 
"Functional options" pattern. I think this talk demonstrates the decorator 
pattern more correctly: https://www.youtube.com/watch?v=xyDkyFjzFVc

On Monday, July 31, 2017 at 12:15:18 PM UTC-4, ha...@arne.me wrote:
>
> Hey, I just released a Go Styleguide 
> , please let me know what you 
> think! 
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

[Chris Hines]

See also: https://github.com/golang/go/issues/10958

On Wednesday, June 21, 2017 at 1:12:12 AM UTC-4, Ronald wrote:
>
> I found this: https://github.com/golang/go/issues/7190.
>
> Then I replace :
>
> go func() { 
> for {
> }
> }()
>
>  With:
>  
>
> go func() {
> ct := 0
> t1 := time.Now().UnixNano()
> for {
> ct++
> if ct%6 == 0 {
> t2 := time.Now().UnixNano()
> fmt.Println("hooray", t2, t1, float64(t2-t1)/1e6)
> t1 = t2
> }
> }
> }()
>
>
> Thus the program does not stuck anymore -- *But it is thrashing *
> *and churning*! (With a time delay nearly 100-200ms based on 
> value '6' and the speed of your computer)
>
> So I 'upgrade' the code again with:
>
>
> go func() {
> ct := 0
> t1 := time.Now().UnixNano()
> for {
> ct++
> if ct%10 == 0 {
> runtime.Gosched()
> }
> if ct%6 == 0 {
> t2 := time.Now().UnixNano()
> fmt.Println("hooray", t2, t1, float64(t2-t1)/1e6)
> t1 = t2
> }
> }
> }()
>
>
> Then it looks just fine.But a pretty serious question emerged:
>
> P1:
>
> No matter how much the GOMAXPROCS is, if you run a very 
> CPU intensive go routine, your system will become definitely 
> thrashing and churning, and the time delay is depending on 
> how intensive you go code is.
>
> *Is proposition P1 is always true on golang so far*?
>
> If P1 is true, as the GOMAXPROCS is bigger than 1, can't the scheduler
> rearrange the waiting staff (including pending go routines and other core 
> business) to other idle threads when some 'indecency' goroutine is seizing 
> the several busiest threads?
>
> On Wednesday, 21 June 2017 11:45:20 UTC+8, Ronald wrote:
>>
>> PS: 
>>
>> go func() { 
>> for {
>> }
>> }()
>>
>>
>> The reason of this code above is that I want to test the channel's 
>> latency 
>> when some 'indecency' goroutine is seizing several whole OS threads. 
>>
>> On Wednesday, 21 June 2017 11:40:12 UTC+8, Ronald wrote:
>>>
>>> Hi, I found when running this code below (play 
>>> ):
>>>
>>>
>>> package main
>>> import "fmt"
>>> import "runtime"
>>> import "time"
>>> type callRet struct {
>>> ret int
>>> }
>>> type callIn struct {
>>> ret_chan chan *callRet
>>> arg1 int
>>> }
>>> func caller(call_in_c chan *callIn, arg1 int) int {
>>> ret_c := make(chan *callRet, 1)
>>> ci := callIn{ret_c, arg1}
>>> t1 := time.Now().UnixNano()
>>> call_in_c <- 
>>> ret := <-ret_c
>>> t2 := time.Now().UnixNano()
>>> _, _ = t1, t2
>>> //fmt.Println(t2, t1, float64(t2-t1)/1e6)
>>> return ret.ret
>>> }
>>> func call_srv(call_in_c chan *callIn) {
>>> //runtime.LockOSThread()
>>> ct := 0
>>> for {
>>> select {
>>> case in := <-call_in_c:
>>> ret_c := in.ret_chan
>>> ret := callRet{3 + in.arg1}
>>> ret_c <- 
>>> ct++
>>> if ct%1000 == 0 {
>>> fmt.Println(ct)
>>> }
>>> //default:
>>> // time.Sleep(1 * time.Millisecond)
>>> }
>>> }
>>> //runtime.UnlockOSThread()
>>> }
>>> func init() {
>>> //runtime.LockOSThread()
>>> }
>>> func main() {
>>> p := fmt.Println
>>> runtime.GOMAXPROCS(5)
>>> call_in_c := make(chan *callIn, 2000)
>>> fp := func(call_in_c chan *callIn) {
>>> ct := 0
>>> for ; ct < 200; ct = ct + 1 {
>>> caller(call_in_c, 1)
>>> time.Sleep(100 * time.Nanosecond)
>>> }
>>> p("done:)")
>>> }
>>> go fp(call_in_c)
>>> go fp(call_in_c)
>>> go func() {
>>> for {
>>> fmt.Println("heartbeat...")
>>> time.Sleep(10 * 1000 * time.Microsecond)
>>> }
>>> }()
>>>
>>>// after delete this little piece code, it will be ok
>>>
>>> go func() { 
>>> for {
>>> }
>>> }()
>>>
>>>// -^
>>>
>>> call_srv(call_in_c)
>>> return
>>> }
>>>
>>> It will always “stuck” in certain time after start executing (tested in 
>>> both go 1.7 , 1.8.1 and 1.8.3, 
>>> and you should run it on your own computer, not on the play because it 
>>> would cost several seconds). 
>>> I have checked the code above dozens of times at least and sure it is 
>>> all right.
>>>
>>> I tried to attach the go process with gdb when it is stuck and the `bt` 
>>> yielded this:
>>>
>>>
 (gdb) info goroutines
   1 waiting  runtime.gopark
   2 waiting  runtime.gopark
   3 waiting  runtime.gopark
   4 waiting  runtime.gopark
   5 waiting  runtime.gopark
 * 6 running  runtime.systemstack_switch
   7 waiting  runtime.gopark
 * 8 running  main.main.func3
   17 runnable runtime.exitsyscall
   33 waiting  runtime.gopark
   18 waiting  runtime.gopark
   49 waiting  runtime.gopark
   50 waiting  runtime.gopark
   51 waiting  runtime.gopark
 (gdb) goroutine 6 bt
 #0  runtime.systemstack_switch () at 
 /usr/local/go/src/runtime/asm_amd64.s:281
 #1  0x00415088 in 

Re: [go-nuts] Cross compiling from Windows to Linux produces non-working go routines

[Chris Hines]

The infinite loops in each function will busy loop and consume a core 
without allowing the runtime scheduler a chance to run other goroutines on 
that core. If your virtual machine doesn't have enough cores then some 
goroutines may starve.

Change the loops to select {} to block infinitely without busy looping and 
see if that behaves as expected.

On Wednesday, March 8, 2017 at 9:20:39 AM UTC-5, Rodrigo Pardo wrote:
>
> I've made this test program
>
>
> package main
>
> import "fmt"
>
> func func1() {
> fmt.Println("running func1")
> for {
>
> }
> }
>
> func func2() {
> fmt.Println("running func1")
> for {
>
> }
> }
>
> func func3() {
> fmt.Println("running func1")
> for {
>
> }
> }
>
> func main() {
>
> go func1()
> fmt.Println("run func1")
> go func2()
> fmt.Println("run func2")
> go func3()
> fmt.Println("run func3")
> for {
>
> }
>
> }
>
> On windows I get 
> go run test.go
>
> run func1
> running func1
> run func2
> running func1
> run func3
> running func1
>
> On Linux, cross compiled (go build -v) I get
> ./test
>
> run func1
> run func2
> run func3
>
> Now I've installed go to my linux and I'm compiling directly from there 
> (gopath set to shared folder)
> go run test.go 
>
> run func1
> run func2
> run func3
>
>
> El miércoles, 8 de marzo de 2017, 10:48:26 (UTC-3), Ayan George escribió:
>>
>>
>>
>> On 03/08/2017 08:30 AM, asc...@gmail.com wrote: 
>>
>> > In the main function I call various go routines, I've set println after 
>> > each call, so I know they are being executed. But I don't get the 
>> > printlns I've set inside of some of those routines, for the same 
>> purpose. 
>> > 
>>
>> So you are seeing some Println()s but not others or are you not seeing 
>> any Println()s at all? 
>>
>> -ayan 
>>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Can somebody explain the importance of 'select'?

[Chris Hines]

I believe the primary reason why select must be in the language is because 
it integrates tightly with goroutine scheduling to efficiently block, and 
then wake up when one of its channel operations can complete.

On Thursday, January 19, 2017 at 12:33:38 PM UTC-5, John C. wrote:
>
> On several occasions the Go designers have alluded to the fact that the 
> 'select' mechanism and the fact that it's built in to the language are very 
> important for concurrency (can't seem to find references).  While I 
> understand just fine how to use select/goroutines/channels, the overarching 
> importance of select as a built-in feature is escaping me.
>
> Can somebody help me see the big "why" picture better?
>
> Thanks,
> John C.
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: error when json unmarshaling string to type string

[Chris Hines]

You are right, my analogy was incorrect. I didn't realize that ",string" 
was a documented annotation in the json package. I've never had cause to 
use it. My apologies for the misleading comment.

The package docs it say:

The "string" option signals that a field is stored as JSON inside a 
> JSON-encoded string."


A JSON-encoded string of a string looks like this: "\"hello\"". With that 
change to the data the code does not return an error. 
https://play.golang.org/p/XmeBN4885-

Chris

On Thursday, December 15, 2016 at 10:44:39 AM UTC-5, Sathish VJ wrote:
>
> I don't think your analogy is right.  The example you gave is an error, as 
> if we wrote: var i = float64("hello")
> Whereas, the code I wrote is just being explicit when it is ok to be 
> implicit.  So, more like we wrote: 
> var i1 = 3.142
> var i2 = float64(3.142)
> i3 := float64(3.142)
>
> The float64 casting is unnecessary in the latter two cases, but it isn't 
> an error.
>
> On Thursday, 15 December 2016 21:01:11 UTC+5:30, Chris Hines wrote:
>>
>> Suppose instead of `json:"s,string"` you had typed `json:"s,omitemptyy"` 
>> when you meant to type `json:"s,omitempty"`. Would you want to be told that 
>> you had an error in your struct tag? In general Go has a fail-fast 
>> philosophy to help prevent mistakes from persisting in a system unnoticed 
>> for a long time. It is this philosophy that warrants producing an error 
>> when the encoding/json package encounters an invalid json: struct tag.
>>
>> Chris
>>
>> On Thursday, December 15, 2016 at 8:32:03 AM UTC-5, Sathish VJ wrote:
>>>
>>> I have a struct that maps json of type string to a string.  
>>> S string `json:"s,string"`
>>>
>>> When run with that, it gives me the error:
>>> Error: json: invalid use of ,string struct tag, trying to unmarshal 
>>> "hello" into string
>>>
>>> I know that it is not really required.  But does it have to error out?
>>> Is the current behavior planned so for any reason?  I was thinking that 
>>> it's quite ok to over-specify the type here and the stand library would 
>>> ignore it.
>>>
>>> Full code: https://play.golang.org/p/gepaK1GsTC 
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: error when json unmarshaling string to type string

[Chris Hines]

Suppose instead of `json:"s,string"` you had typed `json:"s,omitemptyy"` 
when you meant to type `json:"s,omitempty"`. Would you want to be told that 
you had an error in your struct tag? In general Go has a fail-fast 
philosophy to help prevent mistakes from persisting in a system unnoticed 
for a long time. It is this philosophy that warrants producing an error 
when the encoding/json package encounters an invalid json: struct tag.

Chris

On Thursday, December 15, 2016 at 8:32:03 AM UTC-5, Sathish VJ wrote:
>
> I have a struct that maps json of type string to a string.  
> S string `json:"s,string"`
>
> When run with that, it gives me the error:
> Error: json: invalid use of ,string struct tag, trying to unmarshal 
> "hello" into string
>
> I know that it is not really required.  But does it have to error out?
> Is the current behavior planned so for any reason?  I was thinking that 
> it's quite ok to over-specify the type here and the stand library would 
> ignore it.
>
> Full code: https://play.golang.org/p/gepaK1GsTC 
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

[Chris Hines]

I agree with the sentiment that putting these options in context.Context 
values is inappropriate.

Chris

On Friday, December 9, 2016 at 7:14:03 PM UTC-5, Dave Cheney wrote:
>
> I agree with this. This feels like a case of abusing the "bag of values" 
> nature of context's Value() feature to smuggle arbitrary and unstructured 
> data in and out of an interface rather than change the API.
>
>
> On Wednesday, 7 December 2016 00:48:48 UTC+9, Chandra Sekar S wrote:
>>
>> Documentation of the context package says,
>>
>> "Use context Values only for request-scoped data that transits processes 
>> and APIs, not for passing optional parameters to functions."
>>
>> sql.BeginContext introduced in 1.8, uses Context to receive options like 
>> IsolationLevel and read-only flag. These are neither request-specific nor 
>> cross-cutting. They are options that are typically specific to a type of 
>> operation, but common to all requests.
>>
>> Isn't this use in db/sql contradicting the recommendation in context's 
>> doc?
>>
>> --
>> Chandra Sekar.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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interface vs first-class function

[Chris Hines]

I tried to break down the thought process on this exact question earlier 
this year and gave a presentation at my local Go meetup. My slides are here:
 
http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide
 


TL;DR

Informed choices for dynamic behavior

Use interface values when:

   - Well known interfaces already exist, e.g. io.Reader
   - More than one behavior required
   - Typically stateful
   - Implementations non-trivial
   

Use function values when:

   - Only one behavior
   - Typically stateless
   - In-line implementations typical
   
Hope it helps.

Chris

On Sunday, November 20, 2016 at 12:22:57 AM UTC-5, Henry wrote:
>
> Hi,
>
> I am wondering from best practice point of view whether it is better to 
> use interface or first-class function, especially considering that Go 
> encourages the use of small interfaces. Here is an example:
>
> type SomethingDoer interface{
>DoSomething(data Data)
> }
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Or 
>
> type SomethingDoer func(Data)
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Is there some sort of a guideline when to use one vs the other? They seem 
> like redundant features to me.
>
> Thanks
>
> Henry
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Context cancellation

[Chris Hines]

FWIW, I'm a big fan of gopkg.in/tomb.v2. For similar functionality using 
contexts consider golang.org/x/sync/errgroup.

On Wednesday, November 2, 2016 at 7:55:59 PM UTC-4, Gustavo Niemeyer wrote:
>
> You said the function would return whether it got cancelled or not, so I 
> assumed something like err := foo.CallAPI(ctx), which would be awkward to 
> return without actually canceling.
>
> Yes, if the function is documented to return with background activity, 
> it's of course fine. That said, It's extremely helpful to be able to 
> reliably cancel such background activity and wait until it's done, for a 
> number of reasons: side effect control, testing, polite shutdowns, etc.
>
> That's mainly where gopkg.in/tomb.v2 comes from.
>
> On Nov 3, 2016 1:43 AM, "Axel Wagner"  > wrote:
>
> In a concurrent world, assuming that a call to cancel means that thing 
> actually got cancelled is dubious at best. For example, you could call 
> cancelFunc, then immediately enter a GC pause, the other goroutine finishes 
> their work in a orderly fashion, you unpause and close the underlying 
> channel.
> Very normal behavior, perfectly valid code, unpreventable situation. But 
> still, calling cancelFunc doesn't mean it actually had any real effect. 
> This is what I mean by "successful cancellation" (or not).
>
> I don't believe we actually disagree. Though there might be some phrasing 
> issue. Which is now adding more noise and confusion (sorry. I'll shut up 
> now).
>
> On Thu, Nov 3, 2016 at 12:31 AM, Gustavo Niemeyer  > wrote:
>
>>
>>
>> On Thu, Nov 3, 2016 at 1:27 AM, Axel Wagner > > wrote:
>>
>>> That is actually a great point I haven't thought about and the crux of 
>>> the matter (sorry for repeating it, but I think it's worth making very 
>>> explicit):
>>>
>>> While cancelFunc can only be called from the goroutine that created the 
>>> context, Err can be called downstack. Meaning, if I call cancelFunc, a call 
>>> *might or might not* return Cancelled as an error. It might not actually 
>>> implement cancellation or the call might have failed or succeeded 
>>> concurrently with a different (non-)error.
>>>
>>> The ctx.Err() return thus allows a "child-function" to signal back 
>>> whether a cancellation was *successful*; the creator of the context only 
>>> know that it has been *tried*.
>>>
>>
>> No, that's really not its intent. Cancel means *STOP IT!*, and any 
>> goroutines down the chain are supposed to block until they're really done, 
>> returning ASAP.
>>
>> It's a nasty bug to disrespect that, because the call site will assume 
>> that the background noise stopped once the function returned, and act 
>> accordingly thereafter.
>>
>>
>> gustavo @ http://niemeyer.net
>>
>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Will database/sql leak memory if I don't call Close() and remove references to it?

[Chris Hines]

Slight improvement:

1. Rotate usernames/passwords and call sql.Open(...) to get a new 
connection pool for future queries. (Save old pool in oldDB.)
2. Call oldDB.SetMaxIdleConns(-1), which will immediately close any unused 
connections in the old pool and cause those in use to be closed as soon as 
they are returned to the pool.
3. Start a goroutine that will poll oldDB.Stats().OpenConnections at an 
appropriate frequency, when it returns zero (or too much time has passed) 
call oldDB.Close() and exit the goroutine.

Chris

On Tuesday, November 1, 2016 at 6:59:38 PM UTC-4, Francis Chuang wrote:
>
> Just some further questions. I think the easiest way would be to combine 
> ksug and Chris' suggestions. I would prefer not having to maintain a 
> wrapper for each database as we talk to quite a few different types of 
> databases using database/sql.
>
> Does this some bullet proof?
> 1. Rotate usernames/passwords and open a new connection and get a new db 
> object. Keep the old db object around.
> 2. Wait for 1 hour or some other predetermined amount of time.
> 3. Call SetMaxConnections(-1) on the old db object. Does this flush and 
> close cached connections immediately?
> 4. Call Close() on the old db object.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Will database/sql leak memory if I don't call Close() and remove references to it?

[Chris Hines]

db.SetMaxIdleConns(-1) will flush cached connections. That leaves the 
problem that open connections still in use will not get closed until 
returned to the pool, and only if caching idle connections is still 
disabled at that time.

Changing credentials on an already open *sql.DB isn't directly supported. 
It seems possible to implement with a wrapper of driver.Driver as Tamás 
Gulácsi suggested in another response. 

On Tuesday, November 1, 2016 at 8:36:22 AM UTC-4, Daniel Theophanes wrote:
>
> I think there is a larger issue at play of how old connections are cached 
> and handled. In particular there is no way to flush cached connections or 
> update credentials in the API.
>
> Could you file an issue with how to best update credentials on an existing 
> connection pool?
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Function pointer vs interface for callback?

[Chris Hines]

If you want to dig into this topic more. I gave a presentation on this 
topic at my local Go meetup earlier this year.

The slides from my talk are 
here: 
http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide#1

Some of the code examples will not run on the public go-talks app. The 
source material is 
at https://github.com/ChrisHines/talks/tree/master/non-orthogonal-choices-in-go.

If you just want my conclusion:

*Informed choices for dynamic behavior:*

Use interface values when:

   - Well known interfaces already exist, e.g. io.Reader
   - More than one behavior required
   - Typically stateful
   - Implementations non-trivial

Use function values when:

   - Only one behavior
   - Typically stateless
   - In-line implementations typical

Based on these guidelines and the outline of your code you've provided, I 
agree with Ian that a function value is the best fit for your case.

Chris

On Wednesday, October 12, 2016 at 2:33:47 PM UTC-4, Shaun Crampton wrote:
>
> Thanks for the tips.
>
> On Wed, Oct 12, 2016 at 2:11 PM Jesse McNelis  > wrote:
>
>> On Wed, Oct 12, 2016 at 11:05 PM,   wrote:
>> >  Seems like a function
>> > pointer is more universal (I don't even need an object to be a 
>> receiver) but
>> > maybe an interface is more idiomatic?
>>
>> An interesting pattern from the http pkg is that a function type can
>> also implement an interface.
>> https://golang.org/pkg/net/http/#HandlerFunc
>>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] do packages need to be recompiled when Go is upgraded?

[Chris Hines]

I'm pretty sure that the last few versions of Go (since 1.5 maybe) are smart 
enough to do it automatically. I believe the .o files in the pkg tree have the 
compiler version embedded in their meta data for this purpose.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no " declared and not used" compile error?

[Chris Hines]

On Monday, September 12, 2016 at 8:57:15 AM UTC-4, Markus Zimmermann wrote:
>
> Hi gophers!
>
> I am wondering why we have a "declared and not used" compile error for 
> variables [https://play.golang.org/p/KLzHVO5L7q] but not for constants [
> https://play.golang.org/p/JG9dSa_VKg]? I am sure there is some rational 
> decision behind this that I have missed, but my Google-fu is just not 
> strong enough to find an answer.
>
> Cheers,
> Markus
>

It may be a stretch, but allowing unused constants may be desirable when 
we're using iota and we don't want higher constants to change when some of 
the intermediate values become unused.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] runtime.Caller ->

[Chris Hines]

There was some discussion about how to handle generated methods in stack 
traces in #11432, in particular I brought it up in this 
comment: https://github.com/golang/go/issues/11432#issuecomment-146269822. 
The discussion eventually led to the addition of the new 
runtime.CallersFrames API, but providing metadata about generated functions 
was considered orthogonal and left for possible followup work.

Chris

On Monday, August 15, 2016 at 3:13:46 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Aug 15, 2016 at 10:51 AM, Tim Hockin  > wrote: 
> > OK, is there ANY heuristic I can rely on find the "real" call frame? 
>
> I don't know.  Sorry.  As I said earlier, I don't have a good answer here. 
>
> You should open an issue for this.  For some reason it has not been a 
> problem, perhaps because most code doesn't use the wrapper methods 
> much.  One reliable approach you could take would be to not call 
> runtime.Callers(1) from a value method or from a method in a type that 
> you embed into another type.  But I understand that that is not a 
> satisfactory answer. 
>
> Ian 
>
>
> > On Mon, Aug 15, 2016 at 10:17 AM, Ian Lance Taylor  > wrote: 
> >> On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin  > wrote: 
> >>> Can I rely on "" not changing? 
> >> 
> >> I'm sorry, that's a hard question to answer, because other compilers 
> >> do not use that string. 
> >> 
> >> There are no plans to change that string for the gc toolchain. 
> >> 
> >> Ian 
> >> 
> >>> On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Taylor  > wrote: 
>  On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin  > wrote: 
> > On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor  > wrote: 
> >> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin  > wrote: 
> >>> Edit:  It looks like this has more to do with being an interface 
> >>> method than an embedded type. 
> >>> 
> >>> https://play.golang.org/p/I5XPdWR_O0 
> >> 
> >> Hmmm, you're right.  It only happens for a value method. 
> > 
> > Is this likely to change? I.e. can I hardcode "2" or should I 
> actually 
> > write the loop to climb frames?  Is there a limit to the number of 
> > frames I should inspect before I give up?  Is the string 
> > "" stable? 
>  
>  Well, unfortunately, it's different for different compilers.  I don't 
>  have a good answer here.  Except to say that you should never need 
>  more than 2 frames; it should never be the case that autogenerated 
>  code calls autogenerated code. 
>  
>  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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Shuffle Items in a Slice

[Chris Hines]

The history of this behavior is explained in the release notes for Go 
1.3: https://golang.org/doc/go1.3#map

On Friday, June 24, 2016 at 8:48:20 AM UTC-4, Val wrote:
>
> 2 implementations here : 
> http://www.programming-idioms.org/idiom/10/shuffle-a-list/1564/go
>
> As for the map iteration trick, the runtime doesn't guarantee to randomize 
> anything, although it often tries to, so developers don't rely on some 
> specific order. I've seen (in the past) some map iterations consistently 
> not randomized at all. This behaviour may have evolved, but don't rely on 
> it.
>
>
> On Friday, June 24, 2016 at 1:05:49 PM UTC+2, dc0d wrote:
>>
>> Hi;
>>
>> To shuffle items in a slice I'm doing this:
>>
>> var res []Item
>>
>> //fill res logic
>>
>> shuffle := make(map[int]*Item)
>> for k, v := range res {
>>  shuffle[k] = 
>> }
>> res = nil
>> for _, v := range shuffle {
>>  res = append(res, *v)
>> }
>>
>> Which inserts items into a map then ranges over that map. Ranging over a 
>> map in Go returns the items in random order.
>>
>> 1 - I thought it's a cool trick!
>> 2 - Is anything bad about doing this?
>>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.