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

[adonovan via golang-nuts]

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

> We’re going to settle on square brackets for the generics syntax.


FWIW, the same square-bracket syntax was used by Barbara Liskov's CLU in 
the mid-1970s, and was, as far as I can tell, the first syntax used for 
parametric polymorphism in an ALGOL-like language. The Greek prefix 
notation (e.g. *α *list) used by its contemporary, ML, appears to have 
originated in Christopher Strachey's 1968 lecture notes. C++'s 
angle-bracket templates didn't appear until the 1980s, along with ADAs, 
which used ordinary parens, as in your earlier proposal.





-- 
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/d8091421-4c9e-4f86-b883-1d0744d08480o%40googlegroups.com.

[go-nuts] Re: Adding a timeout to a script interpreter (without leaking a goroutine)

[adonovan via golang-nuts]

On Tuesday, 21 May 2019 01:18:34 UTC-4, Ben Hoyt wrote:
>
> I'm looking at adding a timeout option to my GoAWK script interpreter...
> Are there better / more performant ways to handle this?
>
 

Hi Ben, imposing resource bounds is a tricky problem. It's possible to do 
it in an interpreter implemented in C++, but it requires careful discipline 
throughout the implementation. It is essentially impossible to do in a 
target language whose variables are recycled by the garbage collector of 
the host language. Turing incompleteness of the target language (bounded 
recursion only) seems like it ought to help but in fact does not; a bounded 
program can still use all your memory and take ~forever.

The only reliable way to impose bounds is to use the operating system. Put 
the untrusted code in a different process, impose a limit on its maximum 
memory size, and kill it if it hasn't finished by your deadline.
 

-- 
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/b4182f6d-8a3c-41a2-9cb0-e9d3c7fb1780%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Announcing: Skylark in Go

[adonovan via golang-nuts]

Starlark is the new name for the Skylark configuration language. (The old 
name was the code name for a subproject of Bazel and was not suitable for a 
project in its own right.)

The Starlark in Go implementation has moved. The code is now hosted at

https://github.com/google/starlark-go

but the import path you should use in Go programs and go get commands is 

go.starlark.net

For example:

   $ go get go.starlark.net/cmd/starlark

To avoid breaking existing programs, the old repository will continue to 
exist but will no longer be updated. Please update your programs to use the 
new import path.

>

-- 
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: Announcing: Skylark in Go

[adonovan via golang-nuts]

On Saturday, 4 November 2017 11:52:05 UTC-4, Keith Brown wrote:
>
> Are there any native golang tools simar to this which work on 
> Windows/Linux/OSX? 
>

The Skylark interpreter doesn't make any particular assumptions about the 
CPU or OS, so it should be highly portable.  Please file an issue if you 
find otherwise.


On Thursday, November 2, 2017 at 9:42:27 PM UTC-4, Ben Hoyt wrote:
>>
>> I'm very curious how the performance of Skylark in Go compares to Skylark 
>> in Java (and CPython 3.6 for that matter) -- any benchmarks on that?
>>
>
I don't have any rigorous comparisons, but my informal testing on a number 
of small benchmarks suggests that CPython is about 2x faster than Skylark 
in Go (in a single thread), and that Skylark in Go is about 10x faster than 
Skylark in Java.

>

-- 
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/types#Check is not resolving external package source positions.

[adonovan via golang-nuts]

Glad you got things working. A few quick remarks:

1) You don't need to call ParseDir or CreateFromFiles. The loader will 
figure out what files you need to load for each package; just call 
config.Import(packagename).

2) The go/types tutorial says that export data doesn't contain position 
information. That used to be true, but we have since extended the export 
data format to include it.  I'll update it.

3) That said, I did once notice a bug whereby the position of the package 
declaration was reported instead of the correct location. If you are able 
to reproduce that bug, please report it.

cheers
alan

 

> On Sun, Oct 29, 2017 at 5:00 PM, Keynan Pratt  > wrote:
>
>> Can confirm the following works as expected:
>>
>>
>> package main
>>
>> import (
>> "fmt"
>> "go/parser"
>> "go/token"
>> "go/ast"
>> sourceLoader "golang.org/x/tools/go/loader"
>> )
>>
>> func main() {
>> pkgPath := "bitbucket.org/.../test_package"
>> dir := "../..//test_package"
>>
>> fset := token.NewFileSet()
>> packages, err := parser.ParseDir(fset, dir, nil, parser.AllErrors)
>> if err != nil {
>> fmt.Println(err)
>> return
>> }
>>
>> for _, p := range packages {
>> files := make([]*ast.File, 0, 8)
>> for _, file := range p.Files {
>> files = append(files, file)
>> }
>>
>> loader := sourceLoader.Config{Fset: fset}
>> loader.CreateFromFiles(pkgPath, files...)
>> prgm, err := loader.Load()
>> if err != nil {
>> fmt.Errorf(err.Error())
>> }
>>
>> info := prgm.Created[0].Info
>> fmt.Println("\tUsages from ", pkgPath)
>> for use := range info.Uses {
>> obj := info.Uses[use]
>>
>> pkgOfUse := obj.Pkg()
>> nameOfUse := obj.Name()
>> declPos := prgm.Fset.Position(obj.Pos())
>> if pkgOfUse == nil {
>>
>> fmt.Println("Package was nil for obj.id [ ", obj.Id(), " ]")
>> continue
>> }
>> fmt.Printf(
>> "\tUsage of %s # %s declared at %s:%d:%d\n",
>> pkgOfUse.Path(),
>> nameOfUse,
>> declPos.Filename, declPos.Line, declPos.Column)
>> }
>> }
>> }
>>
>>
 

-- 
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: Constructor return advice

[adonovan via golang-nuts]

On Friday, 21 April 2017 12:28:25 UTC-4, st ov wrote:
>
> In general, is it advisable to return pointers to newly constructed 
> instances when using constructors?
>
> Would it matter more for types that don't have members of composite types 
> slice and maps? 
> So in the following example, https://play.golang.org/p/sWTWkHfZfB
>
> Bar is made up of mostly strings, so should return a pointer as those 
> strings could be long.
> While Foo is constructed of a slice and map, which are just references. So 
> the constructor can return Foo as a value with little overhead.
> And Qux has both a string and slice, but should return a pointer since the 
> string can be large.
> For interface Baz, returning a value is acceptable as its just a reference 
> to Foo, Bar and Qux.
>
> Is that all correct? Or should I just always return a pointer? Any other 
> advise?
>

 
Let the receiver declarations of the type's methods guide you.  If the 
methods of a type T have T as a receiver, you should generally pass values 
of type T by copying them, either because the values are immutable (such as 
a string, int, or perhaps a struct made up of immutable values) or because 
T is or contains a reference such as a map or slice.  But if the type's 
methods are associated with *T, then you should not copy values of type T 
because this can violate the aliasing invariants of the type.  For example, 
internally, a bytes.Buffer variable contains a pointer to itself, so 
copying a value of type bytes.Buffer results in a new buffer that is 
entangled with the original one.

I usually suggest the name NewT for a function that returns a pointer to a 
variable of type T, but MakeT for a function that returns a value of type 
T, for consistency with the 'new' and 'make' built-in functions.

-- 
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 Compiler Intermediate Representation

[adonovan via golang-nuts]

On Tuesday, 21 February 2017 12:23:44 UTC-5, Arpit Aggarwal wrote:
>
> I am doing a project in which I need Go compiler's intermediate 
> representation(IR) (which is semantics preserving and I can get all all 
> info like line number and data type and other features) (human readable) to 
> convert to another IR of a tool.
>

The most convenient way to access the semantics of a Go program is to use 
the golang.org/x/tools/go/ssa package, which builds a high-level SSA-based 
intermediate representation.

$ cat fib.go
package fib

func fib(x int) int {
if x < 2 {
return x
}
return fib(x-2) + fib(x-1)
}

$ go build golang.org/x/tools/cmd/ssadump
$ ./ssadump -build=F fib.go
# Name: fib.fib
# Package: fib
# Location: fib.go:3:6
func fib(x int) int:
0:entry P:0 
S:2
t0 = x < 2:int 
bool
if t0 goto 1 else 2
1:  if.then P:1 
S:0
return x
2:  if.done P:1 
S:0
t1 = x - 2:int 
 int
t2 = fib(t1)   
 int
t3 = x - 1:int 
 int
t4 = fib(t3)   
 int
t5 = t2 + t4   
 int
return t5

# Name: fib.init
# Package: fib
# Synthetic: package initializer
func init():
0:entry P:0 
S:2
t0 = *init$guard   
bool
if t0 goto 2 else 1
1:   init.start P:1 
S:1
*init$guard = true:bool
jump 2
2:init.done P:2 
S:0
return

-- 
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: howto programatically resolve an import path ?

[adonovan via golang-nuts]

On Friday, 23 December 2016 14:01:15 UTC-5, mhh...@gmail.com wrote:
>
> Hi,
>
> i m looking for the right way to load and parse an ast.ImportSpec 
> referenced into an ast.File object.
>
> Its mostly about the path resolution, I can t find a method like
>
> parse(baseDir string, pkgPath string)...
>
> where baseDir (is not necessarily the same as the ast.File path, in my 
> understanding) would be the directory which may contain the vendor folder, 
> and pkgPath something like `go/ast`.
>
> Or maybe its ok to just test that the directory exists at,
> - baseDir / vendor / pkgPath
> - goroot / src / pkgPath
> ?
>
> Seems to me its a bit more complex than that.
>

Indeed it is. The interpretation of an import path string depends on the 
build tool.  Most open-source Go projects use the 'go build' command and 
its conventions for workspace layout. The core of this tool is exposed as a 
library in the standard "go/build" package.  Its build.Context type 
abstracts a workspace, and most applications use the default value 
build.Default to find packages relative to the directories specified by the 
GOROOT and GOPATH environment variables.  The (*Context).Import function 
locates a package given its import path:

https://golang.org/pkg/go/build/#Context.Import

This function returns a build.Package, from which you can find the set of 
source files that make up the package.

Most applications must either recursively process source code for imported 
packages, or load type information from export data files (.a) written by 
the compiler.  For source, use the golang.org/x/tools/go/loader package. 
 For export data, use golang.org/x/tools/go/gcexportdata.  See the examples 
in each package for details.  There is a also a tutorial for the type 
checker at htps://github.com/golang/example/tree/master/gotypes.





-- 
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] Modern Garbage Collection Article

[adonovan via golang-nuts]

On Tuesday, 20 December 2016 00:31:52 UTC-5, Ian Lance Taylor wrote:
>
> [Go] is designed to let you control when and 
> how memory is allocated, giving you control over when memory is 
> allocated.  The effect is that in Go you can adjust your program to 
> reduce GC overhead, rather than tuning the GC.  This is far more true 
> in Go than in Java, since Java has no stack variables or structs.
>

Regarding stack variables, Java and Go may be more similar than they first 
appear. Although Java's virtual machine places only primitive values and 
object references on the stack, and objects themselves on the heap, in 
practice, with similar escape analysis algorithms, Java compilers and Go 
compilers place the same set of objects on the stack. Structs/classes are 
where the real difference lies: Go lets you avoid unnecessary indirection 
(and its principal data types use fewer indirections: compare 1 pointer in 
Go's string to 3 in java.lang.String), and it is much harder for a compiler 
to do the analogous optimization to eliminate unnecessary references to 
indirect struct fields.

-- 
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: are functions garbage collected?

[adonovan via golang-nuts]

On Monday, 19 December 2016 06:52:40 UTC-5, Jason E. Aten wrote:
>
> In the context of having a REPL for Go (and the new plugin support!) where 
> we would generate functions at runtime, I'm curious if the garbage 
> collector could be made to scan (perhaps on cue) some designated sub-space 
> for unreachable functions?  Is my assumption correct that functions are not 
> currently garbage collected?
>

The main obstacle to building a complete Go REPL in Go---one that allows 
users to define new types whose methods satisfy existing interfaces, and 
that uses the host garbage collector to determine variable lifetimes---is a 
mechanism for defining new named types and attaching methods to them.  See 
https://github.com/golang/go/issues/16522.

-- 
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] [ANN] browse

[adonovan via golang-nuts]

On Friday, 16 December 2016 06:22:47 UTC-5, Jan Mercl wrote:
>
> > but I am curious: why the need for internal/gc, "a Go compiler front 
> end. Work in progess" ?
> > it seems to be very much alike to go/types (or, rather, a mix of 
> go/types and go/ast).
>
> For example (not completely fair comparison but you get the idea):
>
> jnml@r550:~/src/github.com/cznic/browse$ go install -tags 
> debug.browse && browse
> main.go:162: loaded+xref0: 65 packages in 486.248926ms
> jnml@r550:~/src/github.com/cznic/browse$ time ssadump .
> 
> real 0m2.218s
> user 0m6.588s
> sys 0m0.628s
>

ssadump is loading, cgo-preprocessing, parsing, and type-checking the 
entire transitive closure of source files required by the current package, 
then building its SSA representation in a second pass, so these 
measurements are not at all comparable.  Two other data points:

1) If you modify ssadump to skip cgo preprocessing, type-checking of 
imported function bodies, and SSA construction:

conf.TypeChecker.FakeImportC = true 
conf.TypeCheckFuncBodies = func(path string) bool {
return path == "github.com/cznic/browse"
}
... = conf.Load(...)
return

then it loads that package and its dependencies from source in under 700ms.

2) The golang.org/x/tools/cmd/gotype tool, which loads only a single 
package from source, and loads export data for all imports, can process 
that package in under 100ms.

The go/parser is plenty fast enough.  ssadump may be the wrong starting 
point for how to use it, though.

-- 
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: Code-base Refactoring Tool for Go , Move files from packages to sub packages

[adonovan via golang-nuts]

On Tuesday, 13 December 2016 20:06:49 UTC-5, Dave Cheney wrote:
>
> I advice caution, Go is not Java and does not permit circular 
> dependencies. The more packages you have, the greater the chance you have 
> of creating a circular dependency. 
>

That's a rather dark viewpoint. Absent further information, there's nothing 
wrong with breaking up a large package into smaller ones, nor with using 
tools to help do so.  Even packages with circular dependencies can be 
separated by using function or interface parameters to express the 
interdependence.  Of course it can be overused, but so can any technique.

-- 
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] import a "main" package

[adonovan via golang-nuts]

On Tuesday, 13 December 2016 11:34:24 UTC-5, Jan Mercl wrote:
>
> On Tue, Dec 13, 2016 at 5:19 PM Manlio Perillo  > wrote:
>
> > However I think that there is no reason why a "main" package should not 
> be importable, to the point that
> > I think that the fact that a "main" package is not importable is an 
> "exception" implemented in the Go tool.
>
> The package dependency graph must be (1) an acyclic graph, ie. a tree with 
> (2) main package at its root, for obvious reasons. Importing main violates 
> both of the properties.
>

Packages named main are importable, just like any other.  Occasionally this 
is useful when you want to write tests for members of that package.  Of 
course, the main function is not exported.


-- 
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: Code-base Refactoring Tool for Go , Move files from packages to sub packages

[adonovan via golang-nuts]

On Tuesday, 13 December 2016 08:58:00 UTC-5, jis...@hifx.co.in wrote:
>
>
>
> http://stackoverflow.com/questions/41121448/code-base-refactoring-tool-for-go-move-files-from-packages-to-sub-packages
>
> Currently my code-base have just 1 level of packages , due to the increase 
> in number of components it would make much sense if I use sub packages.Is 
> there any code refactoring tools I could use to achieve this?  I tried 
> *gomvpkg* https://godoc.org/golang.org/x/tools/cmd/gomvpkg but doesnot 
> support moving files from same package to different package.
>

We do not currently have a production-quality tool that can split a package 
into two or more parts, although Michael Matloob and I produced an 
experimental prototype of a tool (https://go-review.googlesource.com/3269) 
to analyze and refactor large packages such as "runtime" with complex 
internal dependencies.  It may be more complex than you need, but it might 
save you time.


-- 
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] Is there a tool or a library that lets me typecheck Go programs?

[adonovan via golang-nuts]

On Monday, 12 December 2016 12:22:51 UTC-5, Jan Mercl wrote:
>
> On Mon, Dec 12, 2016 at 6:20 PM  wrote:
>
> > I realize that obviously the Go compiler does it, I was wondering if 
> there is a good API for that I can use, like the ast package?
>
> See https://golang.org/pkg/go/types/
>

You can use go/types directly if you just want to type-check a single file, 
but all but the most trivial Go programs import other packages.  You have 
three choices for how to handle import declarations:
(1) ignore them
(2) load type information for exported packages from .a files produced by 
the compiler
(3) load the entire program from source.

The vet command takes approach #1, which of course means that it has 
incomplete information.  To use approach #2, you need to use the 
go/importer package, and furthermore rely on all the relevant .a files 
being up to date (which they rarely are).  For approach #3, you need to use 
the golang.org/x/tools/go/loader package, which loads, parses, and 
type-checks all the source code for a multi-package program laid out 
according to 'go build' conventions.  Look at any of several tools in that 
repository for an example of how to put the pieces together.  For example, 
with no flags, ssadump simply type-checks the specified packages:

$ go get golang.org/x/tools/cmd/ssadump
$ cat a.go
package main
var x int = "string"
$ ssadump a.go
a.go:2:13: cannot convert "string" (untyped string constant) to int

There's an in-depth tutorial for the go/types package here: 
https://github.com/golang/example/tree/master/gotypes

-- 
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] Are Go locks/mutex not the same as ordinary locks/mutexes?

[adonovan via golang-nuts]

On Tuesday, 29 November 2016 13:10:49 UTC-5, Ian Lance Taylor wrote:
>
> On Tue, Nov 29, 2016 at 9:51 AM, Roger Alsing  > wrote: 
> > Coming from C++/C# background where locks/mutexes are considered evil 
> due to 
> > blocking threads. 
> > Due to how the Go goroutine scheduler works, are the Go counterpart of 
> those 
> > primitives "different"? 
> > 
> > Should I see the Go variants of these primitives more like yield points 
> > where the execution of a goroutine yields to let other goroutines run. 
> > And thus not resulting in the same resource code/weight as the 
> primitives 
> > has in other languages? 
>
> Yes.  A Go sync.Mutex blocks a goroutine, not a thread.  Goroutines 
> are lighter weight than threads--they are basically just a stack. 
>

To elaborate: the key difference as it relates to your question is not 
really the size of the goroutine data structure or stack, but that a 
goroutine yield operation is usually handled entirely in user mode by the 
Go scheduler, avoiding execution of the the kernel's thread scheduler and a 
heavyweight context switch.

-- 
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: Large 2D slice performance question

[adonovan via golang-nuts]

>
> On Wednesday, 30 November 2016 03:37:55 UTC+2, Mandolyte wrote:
>>
>> I have a fairly large 2D slice of strings, about 115M rows. These are 
>> (parent, child) pairs that, processed recursively, form a tree. I am 
>> "materializing" all possible trees as well as determining for each root 
>> node all child nodes for all levels for it.
>>
>  
In addition to what Egon said:

If the elements of the outer [][]string slice are all []string slices of 
length 2, it would be much more efficient to use [2]string instead, that 
is, fixed-sized arrays of two strings, since this would avoid a lot of 
memory allocation and pointer indirection.  The type of the outer slice 
would become [][2]string.

Also, if all your strings are drawn from a finite set, you'll find many 
operations (such as comparison or set membership tests) much more efficient 
if you represent each string by its index in some side table.  Then instead 
of [2]string you can use [2]uint32, or perhaps even a narrower integer 
type, which will make your main array more compact by at least a factor of 
4.

-- 
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] CFG for a Go program

[adonovan via golang-nuts]

On Wednesday, 30 November 2016 05:13:15 UTC-5, akshans...@gmail.com wrote:
>
> Thanks a lot for your valuable suggestions. I think the one using SSA form 
> will be helpful for my project. 
>

Lest there be any confusion: there are two unrelated SSA forms for Go code, 
the one used internally by the gc compiler and the one defined by the 
golang.org/x/tools/go/ssa package.

-- 
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] CFG for a Go program

[adonovan via golang-nuts]

On Monday, 28 November 2016 09:04:55 UTC-5, atd...@gmail.com wrote:
>
>
> I  concur.
>
> On Monday, November 28, 2016 at 4:35:13 AM UTC+1, Michael Jones wrote:
>>
>> Details of this would make a great Go Blog post…
>>
>  

There is certainly a dearth of documentation on how to make the key design 
decisions when building tools to analyze Go source, but the topic seems 
rather esoteric for the Go Blog.

-- 
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] CFG for a Go program

[adonovan via golang-nuts]

If you're building tools for source code analysis, you may find the 
golang.org/x/go/ssa representation easier to work with than the internals 
of the compiler.  Build and run this command to see an example:

  $ go get golang.org/x/tools/cmd/ssadump
  $ ssadump -build=F fmt

Alternatively, the cmd/vet tool in the standard library has an internal 
subpackage that constructs the control-flow graph of a function.  In this 
representation, each block contains a sequence of Go statements and 
expressions, not low-level SSA instructions.

Which of these forms of control-flow graph is most appropriate depends on 
the (unmentioned) problem you're trying to solve.

>

-- 
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] Short Variable Declaration Question

[adonovan via golang-nuts]

On Friday, 18 November 2016 10:30:45 UTC-5, Ian Lance Taylor wrote:
>
> I think the book is trying to stress that it declares out but does not 
> declare err.  I agree that the sentence seems to imply that it does 
> not assign a value to out, but in fact it does both declare out and 
> assign a value to it. 
>

Indeed.  Apologies for the confusion.

(During copyediting, when reading aloud, I got into the habit of 
emphasizing the word immediately following "only" to help detect misplaced 
modifiers. In this instance the additional emphasis resolved the ambiguity 
the way I wanted it, but not the way one would normally read it.  Sigh.)

-- 
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: Concurrent map error in net/http/trasport

[adonovan via golang-nuts]

On Thursday, 10 November 2016 04:09:29 UTC-5, James Pettyjohn wrote:
>
> I ran into this on go 1.6.2 amd64, seems unlikely this is a core issue and 
> I need to look else where in the project but has anyone seen this before?
>
> fatal error: concurrent map read and map write
>
> goroutine 21619 [running]:
> runtime.throw(0xfefc00, 0x21)
> /usr/local/go/src/runtime/panic.go:547 +0x90 fp=0xc822727ac0 
> sp=0xc822727aa8
> runtime.mapaccess1(0xca4a00, 0xc828346120, 0xc822727c58, 0x1931c00)
> /usr/local/go/src/runtime/hashmap.go:289 +0x5a fp=0xc822727b08 
> sp=0xc822727ac0
> net/http.(*Transport).tryPutIdleConn(0xc822c00b40, 0xc82181fc70, 0x0, 0x0)
> /usr/local/go/src/net/http/transport.go:562 +0x41e fp=0xc822727c90 
> sp=0xc822727b08
> net/http.(*persistConn).readLoop.func2(0xc82181fc70)
> /usr/local/go/src/net/http/transport.go:1053 +0x32 fp=0xc822727cd0 
> sp=0xc822727c90
> net/http.(*persistConn).readLoop(0xc82181fc70)
> /usr/local/go/src/net/http/transport.go:1189 +0xc5d 
> fp=0xc822727fa8 sp=0xc822727cd0
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc822727fb0 
> sp=0xc822727fa8
> created by net/http.(*Transport).dialConn
> /usr/local/go/src/net/http/transport.go:857 +0x10a6
>


The locks surrounding idleConn map all look locally fine. Is it possible 
your application has made a (shallow) copy of an http.Transport?  The old 
and new copies would share the same idleConn map "guarded" by different 
idleMu mutexes.



-- 
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: Concurrent SQL queries with PG

[adonovan via golang-nuts]

On Monday, 7 November 2016 19:54:35 UTC-5, Mandolyte wrote:
>
> Thanks for the quick response. and for your book - one of the best I've 
> ever purchased!
>
 
Thanks!  Glad it was helpful.

-- 
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] Noob question: Pointers to interfaces

[adonovan via golang-nuts]

On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote:
>
> I'm trying to find a typesafe way to access a type-indexed map of 
> components.  This map can contain objects of any type, and the keys are 
> reflect.Type.
>
> One strategy I thought may work would be to pass a pointer to a pointer as 
> an out-var.  Using reflection to determine the pointer's type, it could be 
> populated with a corresponding value.
>
> For instance, if we did something like this:
>
> c := ComponentCollection{}
> c.addComponent(123) // Add an int component 
>
> var p : *int
> c.getComponent()
>
>
> In this case, p would point to the int component of c.
>
> That's wht the 2 levels of indirection are necessary: it's an out-var to a 
> pointer.
>
> Does that make sense?
>

Here's the basic pattern:

var m = make(map[reflect.Type]reflect.Value)

func addComponent(x interface{}) {
   v := reflect.ValueOf(x)
   m[v.Type(x)] = v
}

func getComponent(ptr interface{}) {
   rv := reflect.ValueOf(ptr)
   if rv.Kind() != reflect.Pointer {
panic("not a pointer")
   }
   rv.Elem().Set(m[rv.Type()])
}

-- 
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: Concurrent SQL queries with PG

[adonovan via golang-nuts]

On Monday, 7 November 2016 16:57:29 UTC-5, Mandolyte wrote:
>
> I have what amounts to a recursion problem and I wrote a minimal test 
> using go routines. I am able to vary the max number of go routines as a 
> parameter on the command line (*). But the times don't vary much whether a 
> single go routine is used or 50 are used. I get the correct results, no 
> matter how many are used.
>
> Are my expectations valid that I should be able to process faster with 
> multiple go routines using the lib/pg driver? 
>
> Even a minimal tester for this got to almost 200 lines, but if it helps:
> https://play.golang.org/p/y0cKhF7ujv
>
> Thanks for any advice...
>
>
> (*) The structure of my code are based on the technique used in gopl.io 
> in chapter 8, the concurrent filesystem directory traversal.
>

There's a bug in your code: numthreads is a pointer to an int variable that 
is modified by the flag package during the call to flag.Parse, which is 
usually the first thing done by main.  However, the channel you're using as 
a counting semaphore is created during package initialization, before main 
and the flag.Parse function are executed, so it always has the default size 
of 20.  Create the channel after flag.Parse and see if that solves your 
problem.

-- 
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: stop go run from printing "exit status 1"?

[adonovan via golang-nuts]

On Friday, 4 November 2016 22:49:17 UTC-4, Nate Finch wrote:
>
> If the script you run with go run returns a non-zero exit status, go run 
> prints "exit status N" and itself then returns with exit code 1.
>
> Now, this seems like a double mistake - first off, the only time go run 
> should print anything out is if it had some problem actually running the 
> code, i.e. unable to find the file, unable to compile, etc.  After that, it 
> should just directly mirror whatever the running code writes to stdout and 
> stderr, no more no less.  This also means that if the script returns exit 
> code 13, go run should return with exit code 13.  Right now it only ever 
> returns 0 for success and 1 for an error.
>
> Is this something that can be changed?  Not sure how backwards 
> compatibility is handled in these situations.
>

It does seem a little bit arbitrary and contrary to UNIX tool design 
principles.  It's unlikely that this is a compatibility concern for anyone. 
 File a bug if you feel strongly about it.

-- 
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] Multiple-reader single-writer map access - is this lockless workaround safe?

[adonovan via golang-nuts]

On Thursday, 3 November 2016 23:54:46 UTC-4, 刘桂祥 wrote:
>
> sorry could you provide a complete example ?
>
> I try this  but not find question
> package main
>
>
> import "time"
>
>
> type T struct{ x int }
>
>
> var global *T
>
>
> func f() {
>  p := new(T)
>  p.x = 1
>  global = p // "publish" the new T (racy!)
> }
>
>
> func g() {
>  p := global
>  if p != nil {
>  // println(p.x) // may print "0" due to data race
>  if p.x == 0 {
>  panic("ca")
>  }
>  }
> }
> func main() {
>  for i := 0; i < 1; i++ {
>  go func() {
>  for j := 0; j < 1000; j++ {
>  f()
>  }
>  }()
>  go func() {
>  for j := 0; j < 1000; j++ {
>  g()
>  }
>  }()
>  }
>  time.Sleep(100 * time.Second)
> }
>


I think you are saying you failed to observe a data race during execution 
of this program.  It is not safe to conclude that a program does not have a 
data race just because you didn't notice it.  The behavior of a program 
containing a data race depends on many things, including the set of 
optimizations done by a compiler, and the architecture and 
microarchitecture of the processor.

If you build this program with the -race flag, the dynamic race detector 
will almost certainly detect and report a problem.

-- 
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] golang closure variable

[adonovan via golang-nuts]

On Thursday, 3 November 2016 03:05:47 UTC-4, 刘桂祥 wrote:
>
>
> package main
>
> import "time"
>
> func main() {
> s := []int{100, 200}
> println()
> go func() {
> s[0] = 300
> s = []int{300, 400}
> }()
> time.Sleep(1 * time.Second)
> }
>
> just curious about this ,can you help explain the assemble code here 
>
> "".main t=1 size=241 args=0x0 locals=0x28
> 0x 0 (main.go:5) TEXT "".main(SB), $40-0
> 0x 0 (main.go:5) MOVQ (TLS), CX
> 0x0009 9 (main.go:5) CMPQ SP, 16(CX)
> 0x000d 00013 (main.go:5) JLS 231
> 0x0013 00019 (main.go:5) SUBQ $40, SP
> 0x0017 00023 (main.go:5) MOVQ BP, 32(SP)
> 0x001c 00028 (main.go:5) LEAQ 32(SP), BP
> 0x0021 00033 (main.go:5) FUNCDATA $0, 
> gclocals·69c1753bd5f81501d95132d08af04464(SB)
> 0x0021 00033 (main.go:5) FUNCDATA $1, 
> gclocals·0c8aa8e80191a30eac23f1a218103f16(SB)
> 0x0021 00033 (main.go:6) LEAQ type.[]int(SB), AX
> 0x0028 00040 (main.go:6) MOVQ AX, (SP)
> 0x002c 00044 (main.go:6) PCDATA $0, $0
> 0x002c 00044 (main.go:6) CALL runtime.newobject(SB)
> 0x0031 00049 (main.go:6) MOVQ 8(SP), AX
> 0x0036 00054 (main.go:6) MOVQ AX, "".+24(SP)
> 0x003b 00059 (main.go:6) LEAQ type.[2]int(SB), CX
> 0x0042 00066 (main.go:6) MOVQ CX, (SP)
> 0x0046 00070 (main.go:6) PCDATA $0, $1
> 0x0046 00070 (main.go:6) CALL runtime.newobject(SB)
> 0x004b 00075 (main.go:6) MOVQ 8(SP), AX
> 0x0050 00080 (main.go:6) MOVUPS "".statictmp_2(SB), X0
> 0x0057 00087 (main.go:6) MOVUPS X0, (AX)
> 0x005a 00090 (main.go:6) MOVQ "".+24(SP), CX
> 0x005f 00095 (main.go:6) MOVQ $2, 8(CX)
> 0x0067 00103 (main.go:6) MOVQ $2, 16(CX)
> 0x006f 00111 (main.go:6) MOVL runtime.writeBarrier(SB), DX
> 0x0075 00117 (main.go:6) TESTB DL, DL
> 0x0077 00119 (main.go:6) JNE $0, 210
> 0x0079 00121 (main.go:6) MOVQ AX, (CX)
> 0x007c 00124 (main.go:7) PCDATA $0, $1
> 0x007c 00124 (main.go:7) CALL runtime.printlock(SB)
> 0x0081 00129 (main.go:7) MOVQ "".+24(SP), AX
> 0x0086 00134 (main.go:7) MOVQ AX, (SP)
> 0x008a 00138 (main.go:7) PCDATA $0, $1
> 0x008a 00138 (main.go:7) CALL runtime.printpointer(SB)
> 0x008f 00143 (main.go:7) PCDATA $0, $1
> 0x008f 00143 (main.go:7) CALL runtime.printnl(SB)
> 0x0094 00148 (main.go:7) PCDATA $0, $1
> 0x0094 00148 (main.go:7) CALL runtime.printunlock(SB)
> 0x0099 00153 (main.go:11) MOVQ "".+24(SP), AX
> 0x009e 00158 (main.go:11) MOVQ AX, 16(SP)
> 0x00a3 00163 (main.go:11) MOVL $8, (SP)
> 0x00aa 00170 (main.go:11) LEAQ "".main.func1·f(SB), AX
> 0x00b1 00177 (main.go:11) MOVQ AX, 8(SP)
> 0x00b6 00182 (main.go:11) PCDATA $0, $0
> 0x00b6 00182 (main.go:11) CALL runtime.newproc(SB)
> 0x00bb 00187 (main.go:12) MOVQ $10, (SP)
> 0x00c3 00195 (main.go:12) PCDATA $0, $0
> 0x00c3 00195 (main.go:12) CALL time.Sleep(SB)
> 0x00c8 00200 (main.go:13) MOVQ 32(SP), BP
> 0x00cd 00205 (main.go:13) ADDQ $40, SP
> 0x00d1 00209 (main.go:13) RET
> 0x00d2 00210 (main.go:6) MOVQ CX, (SP)
> 0x00d6 00214 (main.go:6) MOVQ AX, 8(SP)
> 0x00db 00219 (main.go:6) PCDATA $0, $1
> 0x00db 00219 (main.go:6) CALL runtime.writebarrierptr(SB)
> 0x00e0 00224 (main.go:6) MOVQ "".+24(SP), CX
> 0x00e5 00229 (main.go:7) JMP 124
> 0x00e7 00231 (main.go:7) NOP
> 0x00e7 00231 (main.go:5) CALL runtime.morestack_noctxt(SB)
> 0x00ec 00236 (main.go:5) JMP 0
>

Tip: put as much thought into your question as you want others to put into 
the answer.

I'm sure you're capable of figuring out what most of this massive block of 
assembly means.  Perhaps you could identify the part you can't understand 
and ask a specific question about it.

-- 
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] Oxymoron: language spec: ``untyped boolean value''

[adonovan via golang-nuts]

On Wednesday, 2 November 2016 11:24:38 UTC-4, Martin Steffen wrote:
>
> I meant more: the _terminology_ of being untyped may reflect an internal 
> treatment of how the go compiler treats
> those things: inside the go-compiler, the ``static phase''/type 
> checker/type inferencer may treat 
> for instance literals as being in  one of 
> two states: one which is called "untyped", where said flexibility (or 
> polymorphism if you wish) is  possible, and one where this
> is not immediatly possible (without conversion). These to states are 
> called "untyped" and "typed" in the compiler. In that way, I meant 
> "implementation specific". 
>
> Fair enough. I also understand why this flexibility in typing is very 
> desirable, useful etc. 
>
> The only thing I maintain is that, if one would ask me (not that it's  
> generally recommended), 
> I'd had not chosen to call  the phenomenon of  this form of flexible or 
> polymorphiic handling
> of literals  in a typed language as "untypedness"  
> (even if that's accepted terminology in the Go community). 
>
> For me (with my background), I would have called 5 to be "polymorphically 
> typed" in that it can carry more
> than one type (namely as you said, all types which are ``compatible'' with 
> int without conversion).
>

 
Yes, the terminology is confusing to someone with a background in type 
theory, but I have learned it's best not to swim against the current.  A 
constant expression with an "untyped" type certainly has a type, one 
subject to a number of implicit conversions. Perhaps a better term would be 
"unnamed' or "uncommitted".  An untyped integer can be assigned or 
converted to any named integer type such as int, uint16, or MyInt, at which 
point the value is committed to a particular representation.


-- 
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] Re: There has no Mutex.Trylock() implemention or similar method ?

[adonovan via golang-nuts]

On Sunday, 23 October 2016 16:17:29 UTC-4, John Souvestre wrote:
>
> Take a look at https://github.com/LK4D4/trylock/blob/master/trylock.go .
>
>  
>
> I believe that it is easier and performs better.
>

Yes, this looks like a sound solution if you don't need the re-entrant 
behavior.

-- 
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: There has no Mutex.Trylock() implemention or similar method ?

[adonovan via golang-nuts]

On Friday, 21 October 2016 09:05:10 UTC-4, Michael Liu wrote:
>
> I've a race scenario used with Mutex.Lock with Lock() and Unlock(). now 
> multi-routines try to lock the resource and start a few logical code if the 
> Lock.Lock() succesfully. other routines don't need to block util 
> Lock.Unlock() that they can do the above logicals with next time or in 
> future(logical may changes some variables and those variables' change could 
> be see with latency). That looks like a Trylock() implemetion.
>

One reason the TryLock method does not exist is that its behavior cannot be 
expressed without reference to some notion of goroutine identity.  That is, 
its doc comment would read "succeeds immediately if the current goroutine 
already holds the lock".  The designers of the language have strived to 
avoid making goroutine state relevant to the behavior of any function since 
it makes programs had to reason about and prevents programmers from freely 
moving work to a different goroutine.

Another reason is described in Chapter 9 of our book (gopl.io): "There is a 
good reason Go’s mutexes are not re-entrant. The purpose of a mutex is to 
ensure that certain invariants of the

shared variables are maintained at critical points during program execution. 
One of the invariants is “no goroutine is accessing the shared variables,” 
but there may be additional invariants specific to the data structures that 
the mutex guards. When a goroutine acquires a mutex lock, it may assume 
that the invariants hold. While it holds the lock, it may update the shared 
variables so that the invariants are temporarily violated. However, when it 
releases the lock, it must guarantee that order has been restored and the 
invariants hold once again. Although a re-entrant mutex would ensure that 
no other goroutines are accessing the shared variables, it cannot protect 
the additional invariants of those variables."



-- 
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] the defer list

[adonovan via golang-nuts]

On Wednesday, 19 October 2016 16:50:55 UTC-4, Thomas Bushnell, BSG wrote:
>
> On Wed, Oct 19, 2016 at 1:47 PM Pietro Gagliardi  > wrote:
>
>> Manual memory management is a part of life in the C world. defer is the 
>> solution that Go comes up with to situations where explicit cleanup is 
>> necessary, and it's a powerful tool that I'm pretty sure *is* an innovation 
>> Go did first.
>>
>
> Oh my, no. It's a wonderful thing, but it's essentially equivalent to 
> Lisp's UNWIND-PROTECT or (in the outward case) Scheme's dynamic-wind.
>

Unwind-protect and the better known but equivalent try/finally both operate 
at the level of balanced lexical blocks: expressions in Lisp, statement 
blocks in Java or C++.  In contrast, defer operates at the function level 
and requires a dynamic stack, and in that sense it is novel, but I can't 
think of a single time I've actually wanted to defer an action beyond the 
point when try/finally would have executed it.

-- 
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] What is called reference values in Golang?

[adonovan via golang-nuts]

On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>
> On Wed, Oct 19, 2016 at 12:27 PM T L  
> wrote:
>
> Nothing. The language specification does not mention it.
>
> People use that term based on definitions specified for other programming 
> languages, but those are not always equal to each other.
>

Jan is write that the term does not appear in the spec, but I think it's 
possible to come up with a useful definition of a reference type that 
applies to all ALGOL-like languages: a reference type is one whose values 
indirectly refer to mutable state.  So, pointers are obviously references, 
as are slices, maps, and channels.  But a string is not a reference 
because, although internally it contains a pointer, you cannot mutate the 
array of bytes to which it refers.  Functions may be references, because a 
closure may refer to lexically enclosing variables.  Structs and arrays are 
references if their elements contain references.  An interface value is a 
reference if its payload contains a references.

The essence of a reference is that copying one creates a new alias for its 
underlying state, and changes made via one alias are visible to all others. 
 This definition is not absolute: a pointer to an immutable data structure, 
for example, can be considered to have "value" (non-reference) semantics 
since although it points to a variable, that variable can never be changed.


-- 
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: Is it safe to modify any part of a pointer?

[adonovan via golang-nuts]

On Tuesday, 18 October 2016 15:30:36 UTC-4, Joshua Liebow-Feeser wrote:
>
> are there any bits in a pointer which, when modified, won't mess with the 
> GC?
>

Even if there are, using them would constrain the future choices of the GC 
team, for which they will not thank you.

This seems like a bad idea for many reasons.

-- 
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: Proposal: add "future" internal type (similar to channel)

[adonovan via golang-nuts]

On Monday, 17 October 2016 10:10:47 UTC-4, Sokolov Yura wrote:
>
> Mutex needs not to be type-safe.
> And Mutex is not part of concept of "language tailored towards 
> concurrency". 
>

Go does not take a strong Erlang-like stance against concurrency with 
shared variables, so mutexes really are critical to Go's concurrency.

But "future" is well known, widely adopted (though, in different ways)
> concurrency primitive.
> It definitely has right to be part of "language for concurrency".
>
I've already implemented Futures as library code several times, but
> they are redundant.
> To build Future as a library code, you need:
> - redundant interface{}
> - redundant Mutex
> - you still need 'chan'
> - you need to wrap it in a struct
> - and then provide "convenient" redundant api.
>

This is really a special case of the argument for generics in Go.

Futures are to channels and stacks are to slices.  With generics, you could 
provide first-class Future and Stack, but without generics it's 
simply not worth the effort for most users to bother with the abstraction 
since it can be written in little more than a dozen lines of code: 
 https://play.golang.org/p/Obqag2hgZe  It's just easier to implement the 
underlying operations directly.

 

> But 99% of functionality is already in 'chan' implementation.
> And ":= <-" with "<-" is a perfect api for future.
> There is a need only in a (relatively) small change to runtime and (a
> bit larger) to compiler.
>

Adding a new data type is not a small change to the language.  It requires 
changes to the spec, the compiler, the reflect package, every program that 
uses the reflect package, every tool that manipulates Go source code, and 
many other things too.  The only types that currently enjoy special status 
in the type system are slice, map, channel and a small number of others, 
all of which are very widely used.


-- 
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: Using atomics for close checks

[adonovan via golang-nuts]

On Tuesday, 4 October 2016 13:32:03 UTC-4, Ahmed (OneOfOne) W. wrote:
>
> Some of our code uses something like:
>
> type Dummy struct {
> closed int64
> }
>
> func(d *Dummy) IsClosed() bool {
> return atomic.LoadInt64() == 1
> }
>
> func(d *Dummy) Close() error {
> if !atomic.CompareAndSwapInt64(, 0, 1) {
> return fmt.Errorf("already closed")
> }
> // other logic
> return nil
> }
>
> IsClosed feels racy to me, is it better to use 
> atomic.CompareAndSwap(, 
> 1, 1) for IsClosed?
>

No.  CompareAndSwap(1, 1) atomically checks whether the value is 1, and if 
so, sets it to 1, which is of course a no-op, so it's equivalent to the 
existing code but slower (and unnecessarily complex).

Be careful though: no matter which one you use, a caller of IsClosed that 
observes a true result might assume that the Close operation has completed, 
when in fact it has only begun.  Depending on what "// other logic" does, 
this could be a data race.  If so, you should use a mutex to make both 
Closed and IsClosed atomic.

-- 
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: Parsing ambiguity?

[adonovan via golang-nuts]

On Friday, 16 September 2016 06:43:38 UTC-4, Jan Mercl wrote:
>
> Which rule selects the first parse? Can anybody please enlighten me? 
> Thanks in advance.
>

The grammar is indeed ambiguous, but the ambiguity is (implicitly) resolved 
by favoring the leftmost derivation, which is what you get from an LL(k) 
parser.  By the same token (hah!), the grammar expresses that unary 
operations have higher precedence than binary ones.  For example, -x + y is 
parsed as (-x)+y, not -(x+y).   If you want a derivation other than the 
leftmost one, you need to use parentheses.

-- 
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] Multiple-reader single-writer map access - is this lockless workaround safe?

[adonovan via golang-nuts]

On Monday, 12 September 2016 12:04:30 UTC-4, sqweek E. wrote:
>
> Yes, through plain assignment. What problems arise from that?
>

Here's the general form of the problem.  In the code below, one goroutine 
(f) creates a variable, initializes it (x=1), then shares its address with 
another goroutine (in this case by assigning to a global variable, but 
that's a detail).  Another goroutine (g) reads the pointer out of the 
global variable and inspects the variable to which it points.

type T struct { x int }

var global *T

func f() {
p := new(T)
p.x = 1
global = p // "publish" the new T (racy!)
}

func g() {
p = global
if p != nil {
println(p.x) // may print "0" due to data race
}
}

go f()
go g()

One might naively think that the print statement always prints 1, but in 
fact it can print 0.  The reason is that the compiler or CPU is free to 
reorder the assignments p.x=1 and global=p, since f can't tell.  But 
reordering means other goroutines might observe a non-nil pointer in global 
before the thing it points to has been fully initialized.

To safely "publish" a variable initialized by one goroutine so that other 
goroutines see it properly initialized, you need "barrier semantics", that 
is, you need to tell the compiler and CPU not to reorder those assignments. 
That's what atomic.Value does.

But you shouldn't reach for atomic.Value without data.  In most programs, a 
mutex is simpler to reason about and plenty fast enough.

-- 
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: Type And Interface Equivalence

[adonovan via golang-nuts]

On Friday, 2 September 2016 09:51:52 UTC-4, Kevin Conway wrote:
>
> Given a type T that implements interfaces A1 and A2, T is an acceptable 
> input for any function that requires an A1 or A2 as input. Given A1 and A2 
> are identical in definition, the return value of a function that returns an 
> A1 is acceptable as input to a function at requires an A2, and vice versa.
>
> However, a type T2 defined as a function that accepts an A1 cannot be 
> satisfied by a function that accepts an A2. To illustrate, I've put 
> together a playground that encounters this issue: 
> https://play.golang.org/p/nsFCxP3T8H.
>
> To give a slightly more concrete example of why this is a pain point, 
> there is a common pattern among HTTP request routing libraries to define a 
> context sensitive alternative to the http.Handler interface defined as:
>
> type HanderC interface {
> ServeHTTPC(context.Context, http.ResponseWriter, *http.Request)
> }
>
> A benefit of the consistency across libraries is that my context sensitive 
> handlers are portable to virtually any routing library I want without 
> modification. However, each of these libraries also defines a form of 
> middleware which wrap a HandlerC. The typical pattern for these libraries 
> is to define a new type, Middleware, that is a function signature like 
> func(HandlerC) HandlerC. A problem with this approach is that middleware 
> become non-portable between libraries because a middleware defined as 
> func(A.HandlerC) A.HandlerC cannot be used to satisfy func(B.HandlerC) 
> B.HandlerC.
>
> This constraint feels odd because the interfaces required in the function 
> signatures are equivalent and, outside the context of that type definition, 
> are treated as equivalent in all ways. It is additionally frustrating 
> because the error message shown during compilation seems to indicate the 
> names of the types are being used for validation rather than the interfaces 
> themselves.
>
> Is this an expected behaviour with rationale behind the implementation or 
> is this considered a bug that will be resolved in future versions of go? 
> Alternatively, what strategies exist for overcoming this issue when 
> attempting to write code that is compatible with multiple, equivalent type 
> definitions?
>

It's an expected consequence of the spec, so it's not a bug, but as you 
point out, it is certainly inconvenient at times and it is not a necessary 
restriction.  There has been some recent discussion of relaxing the rules 
for assignability so that if interface types A1 and A2 are mutually 
assignable, then compounds made from them, such as []A1 and []A2, or 
func(A1) and func(A2), would be mutually assignable as well.  See 
https://github.com/golang/go/issues/16209

-- 
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: Close a reader to quit a loop without closing its source

[adonovan via golang-nuts]

On Wednesday, 31 August 2016 07:48:12 UTC-4, Dave Cheney wrote:
>
> Unfortunately POSIX does not guarantee that close from one thread will 
> unblock another.


To read from a file without waiting longer than a specified time, you need 
to use the POSIX 'select' system call, which you can find at 
syscall.Select.  (It was the inspiration for the Go select statement, but 
whereas Go's select multiplexes channels, POSIX's select multiplexes 
files.)  The select system call is quite a pain to use in Go; you might 
want to take a look at https://github.com/creack/goselect.

-- 
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 can't you take the address of a function's return value?

[adonovan via golang-nuts]

On Monday, 29 August 2016 13:36:00 UTC-4, Conrad Irwin wrote:
>
> because of the automatic escape detection, I no longer think of a pointer 
> as being the intrinsic address of a value; rather in my mind the & operator 
> creates a new pointer value that when dereferenced returns the value.
>
 

> With that mental model mixup in place, it's obvious why "()" makes sense 
> — it's just creating a new pointer to the value returned by "f()".
>
 
>
If you instead keep in mind that the meaning of "&" is supposed to be 
> closer to "what's the address of this thing?" for the purpose of 
> identity-based equality and reference sharing, it makes more sense to 
> prohibit "[k]" or "()" because each time you run those you may/will get 
> a new pointer (which is not useful for identity-based equality or reference 
> sharing). It still would be useful for my case which was essentially 
> converting one type to an "optional" type, but maybe that's enough of an 
> edge case that it doesn't matter.
>

The composite literal syntax {...} may have led you astray, as it is not 
equivalent to "&" + "T{}".  That is, it doesn't mean "here's an expression 
of type T, give me its address", it means, "create a new variable of type 
T, initialize it, then give me its address".  It's shorthand for:

   p := new(T); *p = T{...}; p

The key thing is that only variables have addresses.  (Escape analysis is 
irrelevant: all of this applies equally to stack and heap variables.)

>

-- 
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 can't you take the address of a function's return value?

[adonovan via golang-nuts]

On Friday, 26 August 2016 23:58:53 UTC-4, T L wrote:
>
> And there is also an exception for the counter rule: map elements are not 
> addressable.
>

Just because you can use the assignment syntax m[k]=v to update a map 
element does not mean a map element is a variable ("addressable").  This is 
not an exception to a rule.
 

> Please adapt it.
>

Compatibility with Go 1.0 means that fundamental changes to the semantics, 
no matter how sensible or popular, are not going to happen.

-- 
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: SSA back-translation / destruction

[adonovan via golang-nuts]

On Wednesday, 17 August 2016 12:00:46 UTC-4, HWJ wrote:
>
> TL;DR: what's the best way to do SSA back-translation when using 
> x/tools/go/ssa? 
>
> I'm thinking about a Go compiler which accepts a subset of Go and emits 
> assembly for a microcontroller. Instead of going all the way from 
> lexing, parsing etc. I'd like to use x/tools/go/ssa. 
>
> In order to generate assembly code I need to remove the Phi functions 
> and rename the registers accordingly. The register field in SSA is not 
> exported and can be accessed read-only by Name(). This makes SSA 
> back-translation cumbersome. 
>
> What do you suggest to solve this problem? 
>

You could just ignore the register names; they matter only for debugging. 
 The program's semantics are determined by the topology of the SSA value 
graph.


My ideas: 
>
> * visit all SSA nodes and clone them into a new data structure which 
>   supports register renaming. That would probably mean reimplementing a 
>   lot of x/tools/go/ssa. 
>
> * export the register field from x/tools/go/ssa. That would need to be 
>   done by Go devs with write access to the repository. 
>

Alternatively, you could fork go/ssa and modify your copy.  It is very 
stable and well tested, so you wouldn't be missing out on crucial fixes.

-- 
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: const values of any types can't be compared to interface{} values?

[adonovan via golang-nuts]

On Monday, 1 August 2016 17:53:59 UTC+1, T L wrote:
>
>
> ex:
>
> package main
>>
>> func main() {
>> // error: illegal constant expression: *int == interface {}
>> _ = (*int)(nil) == interface{}(nil)
>> }
>
>
This is a compiler bug (https://github.com/golang/go/issues/16702).  Thanks 
for reporting it.

alan


-- 
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: golang.org/x/tools/go/loader: file names of parsed *ast.File

[adonovan via golang-nuts]

On Saturday, 13 August 2016 22:27:42 UTC+1, Paul Jolly wrote:
>
> On Saturday, 13 August 2016 21:58:37 UTC+1, Paul Jolly wrote:
>>
>> Am I missing something obvious here?
>>
>
> Please excuse the reply to self, but I have discovered what I was missing.
>
> For the sake of completeness, here is how the equivalent mapping is 
> achieved in golang.org/x/tools/go/loader world:
>
> import (
> "go/ast"
> "go/parser"
> "golang.org/x/tools/go/loader"
> )
>
>
> conf := loader.Config{
> ParserMode: parser.AllErrors | parser.ParseComments,
> Cwd:path,
> }
>
> ...
>
> conf.CreateFromFilenames(path, toParse...)
>
> prog, err := conf.Load()
> if err != nil {
> panic(err)
> }
>
> At this point conf.CreatePkgs (type []loader.PkgSpec) and prog.Created 
> (type []*loader.PackageInfo) correspond to each other.
>
> For each (loader.PkgSpec, *loader.PackageInfo) pairing, say pkgSpec and 
> pkgInfo, then pkgSpec.Filenames (type []string) and pkgInfo (type 
> []*ast.File) again correspond, which gives us the required mapping.
>

You can obtain the name of the file from which the *ast.File f was parsed 
using the following expression: prog.Fset.Position(f.Pos()).Filename

cheers
alan

-- 
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] russian language books about Go

[adonovan via golang-nuts]

On Friday, 24 June 2016 03:10:56 UTC-4, Oleg Puchinin wrote:
>
> Hello !
> Where I can find subject ?
>

Hi Oleg,

our book The Go Programming Language (gopl.io) is now available in Russian, 
thanks to Williams Press:
http://www.williamspublishing.com/Books/978-5-8459-2051-5.html

The ozon.ru site features some sample chapters so you can try before you 
buy:
http://www.ozon.ru/context/detail/id/34671680/

cheers
alan


-- 
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: importer.Default not able to find packages in $GOPATH

[adonovan via golang-nuts]

On Friday, 17 June 2016 15:21:55 UTC-4, Joshua Liebow-Feeser wrote:
>
> Hi All,
>
> I'm trying to use the go/* packages to parse and type check Go source 
> code. I've downloaded github.com/coreos/etcd to test this on, and I'm 
> currently trying it out in the etcdserver subdirectory. When I run 'go 
> build' everything works fine, but when I try to type check, none of the 
> imports are found.
>

Try running 'go install' or 'go build -i' on the packages you want to 
analyze.

The default importer works great for packages in the standard 
library, which are always available in compiled form, but poorly for user 
packages, for which it may have been days or weeks since the most recent 
install.  Take a look at the golang.org/x/tools/go/loader package, 
which loads all packages from source.

Also, you may find this tutorial helpful: 
https://github.com/golang/example/tree/master/gotypes

-- 
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.