[go-nuts] Re: Go 1.11 and 1.10.4 are Released

[Amnon Baron Cohen]

Any plans to upgrade https://play.golang.org/ to 1.11?

On Friday, 24 August 2018 23:24:25 UTC+1, Andrew Bonventre wrote:
>
> Hello gophers,
>
> We just released Go 1.11 and 1.10.4.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.1 1
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.11" or "git checkout go1.10.4" and build as usual.
>
> To find out what has changed in Go 1.11, read the release notes:
>   https://golang.org/doc/go1.1 1
>
> Thanks to everyone who contributed to the release!
>
> Cheers,
> The Go Team
>

-- 
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] Is the go 1.11 godoc tool 'module-aware'?

[Justin Israel]

I've been trying out converting some of our internal projects to go 1.11 
using modules instead of glide. We have a build system that provides the 
ability to generate html docs via "godoc" and I am wondering if godoc has 
been made "module-aware" in go 1.11?

My particular project is using the migration approach of setting "v3" at in 
the go.mod, and in all import paths within the project. But it seems godoc 
is not happy about this:

godoc -links=0 -html domain.com/group/project/v3/lib/foo

2018/08/29 11:52:12 error while importing build package: cannot find package 
"domain.com/group/project/v3/lib/foo" in any of:
/path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo (from 
$GOROOT)
/usr/home/justin/src/go/src/domain.com/group/project/v3/lib/foo (from 
$GOPATH)
2018/08/29 11:52:12 cannot find package "." in:
/src/domain.com/group/project/v3/lib/foo


It seems to only care about the filesystem structure and not the module import 
path naming?


Justin


-- 
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: Does fmt.Print* automatically render an error string in as struct (play link)

[mart]

You have implemented error on *Thing, so it is *that* which fmt is running, 
which then in turn runs the implementation from your wrapped error.

If you don't wish fmt to treat your *Thing as an error, you must remove 
method Error() string from it.



On Tuesday, August 28, 2018 at 5:15:31 PM UTC-7, Louki Sumirniy wrote:
>
> I discovered quite by accident and now I can't find anything saying as 
> such, but this example
>
> package main
>
> import (
>   "fmt"
>   "errors"
> )
>
> type Thing struct {
>   err error
> }
>
> type thing interface {
>   Error() string
> }
>
> func (t *Thing) Error() string {
>   return t.err.Error()
> }
>
> func main() {
>   t := new(Thing)
>   t.err = errors.New("testing")
>   fmt.Println(t)
> }
>
> https://play.golang.org/p/xBIGIvSZkqO
>
> as you can see by running it, prints the error value inside the struct. 
>
> I am writing a library where I am using a 'pipeline' model so I can string 
> pointer methods together in a chain, which requires putting an error value 
> inside the structure, and then it does this when I print the struct. It's 
> quite handy but unexpected. I assume if a struct satisfies the error 
> interface it calls it to generate the string.
>

-- 
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] Does fmt.Print* automatically render an error string in as struct (play link)

[Louki Sumirniy]

I discovered quite by accident and now I can't find anything saying as 
such, but this example

package main

import (
  "fmt"
  "errors"
)

type Thing struct {
  err error
}

type thing interface {
  Error() string
}

func (t *Thing) Error() string {
  return t.err.Error()
}

func main() {
  t := new(Thing)
  t.err = errors.New("testing")
  fmt.Println(t)
}

https://play.golang.org/p/xBIGIvSZkqO

as you can see by running it, prints the error value inside the struct. 

I am writing a library where I am using a 'pipeline' model so I can string 
pointer methods together in a chain, which requires putting an error value 
inside the structure, and then it does this when I print the struct. It's 
quite handy but unexpected. I assume if a struct satisfies the error 
interface it calls it to generate the string.

-- 
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] gofmt formats different than goimports in go1.11

[Ian Lance Taylor]

On Tue, Aug 28, 2018 at 10:26 AM, Rohit Jain  wrote:
>
> ```err := testService.test.UpdateWithQuery(
>  ctx,
>  bson.M{
> -"id":   campaignID,
> +"id": campaignID,
>  "x_yyy.testing": x.y,
>  },
> ```
> gofmt reports above diff
>
>
> ```err := testService.test.UpdateWithQuery(
>  ctx,
>  bson.M{
> -"id": campaignID,
> +"id":   campaignID,
>   "x_yyy.testing": x.y,
>  },
> ```
>
> goimport reports above diff
>
> if I correct the `goimports` suggrstion , gofmt reports the error and vice
> -versa.
>
> how do I solve this?

Rebuild goimports with Go 1.11.

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.

Re: [go-nuts] astutil.AddImport -- loosing all but the first import

[Todd Neal]

n...@mit.edu writes:

> Thanks Todd.  That fixed my problem.
>
> Concerning the dummy nodes to want to add to an AST, you could try adding 
> dummy methods to make them to conform to ast.Stmt or whatever?
>

You can, and you can add them as Expr's or Decl's but then you lose the
ability to use ast.Walk or format.Node.  They both panic upon seeing a
type they don't expect.

I've also run into problems with trying to add comments to generated
code.  In some places it's easy as some of the nodes have a comment
member, but in others you need to add them to ast.File, and then have
the positions set correctly which gets you back to token.FileSet and
token.Pos.

- Todd

-- 
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] gofmt formats different than goimports in go1.11

[David Collier-Brown]

>
>
> It was funnier inside my head. 
>
>
Sounded grumpy from out here. 

-- 
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] Unexpected behavior of %+02d in Sprintf() and friends

['Borman, Paul' via golang-nuts]

I believe +0 is correct.  That is 2 bytes which is what you requested with 
%+02d and the + takes up the first byte and 0 fits in the second byte.

On Aug 28, 2018, at 10:55 AM, Eric Raymond 
mailto:e...@thyrsus.com>> wrote:

Under Go 1.10.1, feeding an 0 value to a %+02d specifier sometimes yields  
"+0", not "+00". The attached tiny Go program may reproduce this behavior.  I 
say "may" because I first observed it in a series of unit tests of date format 
conversions - in different format strings %+02d expanded differently.  I 
haven't found a pattern to this, or I'd report it. On my system this program, 
at least, has repeatable behavior.

If this behavior were consistent, I'm not sure it would be a bug. It's possible 
that the sign is supposed to be counted as part of the number width; if so, 
it's an interesting question whether this is the right thing when explicit sign 
is forced by +.  The documentation is unclear.

The apparent inconsistency worries me.  There may be some state in the 
form,at-interpretation code that is not always tracked correctly.

In accordance with the Contribution Guidelines, I'm tossing  the question out 
here for a sanity check before throwing it on the bugtracker.  Have there been 
any similar reports?

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


-- 
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: Regarding string immutablity

['Borman, Paul' via golang-nuts]

You are only overwriting the pointer to the string (a string is essentially a 
pointer and a length).  If you want to use memory and then zero it out, use a 
byte slice instead and be careful to not call append where append might 
allocate new memory.  Take a look at https://play.golang.org/p/GkrKRSvkoRJ.

-Paul

On Aug 28, 2018, at 11:45 AM, Jay Sharma 
mailto:jaysharma...@gmail.com>> wrote:

@Jan, The example you shown it is copying a string to new variable. but my 
question was related to same variable.

I want to know if I have variable :

x := "testsring"

Now it overwrite the content of same variable x to some other value:
x = "new1string"

Will it overwrite the same memory or it will create some copy ?

@Jake Montgomery,

 It is about security. I have some keys and I want to delete the content of 
key, when no longer required. Here my API is expecting a string key.


On Tuesday, August 28, 2018 at 8:25:27 PM UTC+5:30, Jay Sharma wrote:
Hi All,

I went through documentation and many post. Every where it is specified strings 
are immutable.

I have some string :

x := "teststring"


I want to wipe out/overwrite the content of this string x from disk/memory.

As per me the simplest way to do this:

x = ""


or If I want to overwrite it with some new content, I can do this: [Here length 
of new string is equal to length of old string]

x = "new1string"


As I am overwriting the content with new content, Is it inplace replacement 
[same memory is being updated] or a new copy will be created with new content 
and old content will be there in the memory ?



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

-- 
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] astutil.AddImport -- loosing all but the first import

[naha]

Thanks Todd.  That fixed my problem.

Concerning the dummy nodes to want to add to an AST, you could try adding 
dummy methods to make them to conform to ast.Stmt or whatever?


On Tuesday, August 28, 2018 at 6:33:12 PM UTC-4, Todd Neal wrote:
>
>
>
> na...@mit.edu  writes: 
>
> > As can be seen from my recent posts, I've been playing a lot with the 
> > automatic generation if go programs using go/ast and related packages. 
> > 
> > My current problem is that when I use astutil.AddImport. 
> > 
> > When I rn the program below, which creates a new ast.File and uses 
> > astutil.AddImport to import to packages into it, the serialization of 
> that 
> > File only includes the first import: 
> > 
> > go run add_import.go 
> > package foo 
> > 
> > import "fmt" 
> > 
> > Has anyone else seen this? 
> > 
>
> Arguably it's a bug in AddImport.  You need a valid Lparen for it to 
> print multiple specs. Try this after you add call AddImport: 
>
>   newAstFile.Decls[0].(*ast.GenDecl).Lparen = token.Pos(1) 
>
>
> go/ast is nice, but I'm in the middle of using it to generate a large 
> amount of code and am looking at just copying go/ast and making some 
> changes. 
>
>  - token.Pos and filesets just aren't convenient to use for code 
>generation 
>  - Walk/Format can't handle non go/ast nodes.  I want to insert some 
>temporary nodes that I can replace later on once I determine what 
>type they should really be. 
>  - oddities like you ran into, you'll see the same thing when creating a 
>type alias (set Assign to something besides token.NoPos for an alias) 
>
> - Todd 
>

-- 
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] astutil.AddImport -- loosing all but the first import

[Todd Neal]

n...@mit.edu writes:

> As can be seen from my recent posts, I've been playing a lot with the 
> automatic generation if go programs using go/ast and related packages.
>
> My current problem is that when I use astutil.AddImport.
>
> When I rn the program below, which creates a new ast.File and uses 
> astutil.AddImport to import to packages into it, the serialization of that 
> File only includes the first import:
>
> go run add_import.go
> package foo
>
> import "fmt"
>
> Has anyone else seen this?
>

Arguably it's a bug in AddImport.  You need a valid Lparen for it to
print multiple specs. Try this after you add call AddImport:

newAstFile.Decls[0].(*ast.GenDecl).Lparen = token.Pos(1)


go/ast is nice, but I'm in the middle of using it to generate a large
amount of code and am looking at just copying go/ast and making some
changes.

 - token.Pos and filesets just aren't convenient to use for code
   generation
 - Walk/Format can't handle non go/ast nodes.  I want to insert some
   temporary nodes that I can replace later on once I determine what
   type they should really be.
 - oddities like you ran into, you'll see the same thing when creating a
   type alias (set Assign to something besides token.NoPos for an alias)

- Todd

-- 
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] Looking for a way to monitor all active Go channels

[Ingo Jaeckel]

I am building lots of apps where the consumer/producer pattern plays a big 
role. Usually, I end up tracking metrics on individual Go channels (e.g. 
enqueue/dequeue rate, periodically calling len(channel)). This works well 
to confirm if channels have the right capacity, consumers are keeping up, 
etc.  

That said, I would love to generalize this and *gather information about 
all Go channels* in my app. For Go Routines, the runtime 
 and pprof 
 packages have some cool 
functionality like determining go routine count & listing each go routine's 
stacktrace. However, I can't find anything providing data about active 
channels. reflect  provides some useful 
functionality, but until I can programmatically discover all active 
channels that functionality is not going to help me.

Is there any way to list all active go channels similar to the go routine 
functionality provided by pprof/runtime? If not, I will likely just create 
all channels in a central location which can keep tabs on their state.

Thanks,
Ingo

-- 
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: Regarding string immutablity

[peterGo]

Jay,

A Go string is represented by a struct.

type stringStruct struct {
str unsafe.Pointer
len int
}

Assigning a new value to a string variable is a struct assignment that does 
not immediately destroy the underlying value of the original string.

Peter

On Tuesday, August 28, 2018 at 10:55:27 AM UTC-4, Jay Sharma wrote:
>
> Hi All,
>
> I went through documentation and many post. Every where it is specified 
> *strings 
> are immutable*.
>
> I have some string :
>
> x := "teststring"
>
>
> I want to *wipe out/overwrite* the content of this string x from 
> disk/memory. 
>
> As per me the simplest way to do this:
>
> x = ""
>
>
> or If I want to overwrite it with some new content, I can do this: [*Here 
> length of new string is equal to length of old string*]
>
> x = "new1string"
>
>
> As I am overwriting the content with new content, Is it *inplace 
> replacement* [same memory is being updated] or a new copy will be created 
> with new content and old content will be there in the memory ? 
>
>
>

-- 
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: Unexpected behavior of %+02d in Sprintf() and friends

[peterGo]

Eric,

For example,

package main

import (
"fmt"
"runtime"
)

func main() {
// Correctly prints "+0 00\n" as +00 00
fmt.Printf("%s: %+03d %02d\n", runtime.Version(), 0, 0)
}

Output:

go1.10.3: +00 00

Playground: https://play.golang.org/p/Pt2-YJfQvEo

Widths three and two.

Peter

On Tuesday, August 28, 2018 at 4:49:02 PM UTC-4, peterGo wrote:
>
> Eric,
>
> "Width is specified by an optional decimal number immediately preceding 
> the verb. If absent, the width is whatever is necessary to represent the 
> value. "
>
> https://golang.org/pkg/fmt/
>
> Width is two.
>
> Peter
>
> On Tuesday, August 28, 2018 at 12:09:26 PM UTC-4, Eric Raymond wrote:
>>
>> Under Go 1.10.1, feeding an 0 value to a %+02d specifier sometimes 
>> yields  "+0", not "+00". The attached tiny Go program may reproduce this 
>> behavior.  I say "may" because I first observed it in a series of unit 
>> tests of date format conversions - in different format strings %+02d 
>> expanded differently.  I haven't found a pattern to this, or I'd report it. 
>> On my system this program, at least, has repeatable behavior.
>>
>> If this behavior were consistent, I'm not sure it would be a bug. It's 
>> possible that the sign is supposed to be counted as part of the number 
>> width; if so, it's an interesting question whether this is the right thing 
>> when explicit sign is forced by +.  The documentation is unclear.
>>
>> The apparent inconsistency worries me.  There may be some state in the 
>> form,at-interpretation code that is not always tracked correctly.
>>
>> In accordance with the Contribution Guidelines, I'm tossing  the question 
>> out here for a sanity check before throwing it on the bugtracker.  Have 
>> there been any similar reports?
>>
>

-- 
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: Unexpected behavior of %+02d in Sprintf() and friends

[peterGo]

Eric,

"Width is specified by an optional decimal number immediately preceding the 
verb. If absent, the width is whatever is necessary to represent the value. 
"

https://golang.org/pkg/fmt/

Width is two.

Peter

On Tuesday, August 28, 2018 at 12:09:26 PM UTC-4, Eric Raymond wrote:
>
> Under Go 1.10.1, feeding an 0 value to a %+02d specifier sometimes yields  
> "+0", not "+00". The attached tiny Go program may reproduce this behavior.  
> I say "may" because I first observed it in a series of unit tests of date 
> format conversions - in different format strings %+02d expanded 
> differently.  I haven't found a pattern to this, or I'd report it. On my 
> system this program, at least, has repeatable behavior.
>
> If this behavior were consistent, I'm not sure it would be a bug. It's 
> possible that the sign is supposed to be counted as part of the number 
> width; if so, it's an interesting question whether this is the right thing 
> when explicit sign is forced by +.  The documentation is unclear.
>
> The apparent inconsistency worries me.  There may be some state in the 
> form,at-interpretation code that is not always tracked correctly.
>
> In accordance with the Contribution Guidelines, I'm tossing  the question 
> out here for a sanity check before throwing it on the bugtracker.  Have 
> there been any similar reports?
>

-- 
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] astutil.AddImport -- loosing all but the first import

[naha]

As can be seen from my recent posts, I've been playing a lot with the 
automatic generation if go programs using go/ast and related packages.

My current problem is that when I use astutil.AddImport.

When I rn the program below, which creates a new ast.File and uses 
astutil.AddImport to import to packages into it, the serialization of that 
File only includes the first import:

go run add_import.go
package foo

import "fmt"

Has anyone else seen this?

I have added debugging code to my application and that shows that all of 
the imports appear as separate ast.ImportSpecs in the same ast.GenDecl.


Here's my test program.  The Playground isn't able to import astutil.

*// Test astutil.AddImport*
*package main*

*import "go/ast"*
*import "go/format"*
*import "go/token"*
*import "os"*
*import "golang.org/x/tools/go/ast/astutil"*

*func main() {*
* fset := token.NewFileSet()*
* newAstFile := {*
* Name:  ast.NewIdent("foo"),*
* Decls: []ast.Decl{},*
* }*
* astutil.AddImport(fset, newAstFile, "fmt")*
* astutil.AddImport(fset, newAstFile, "reflect")*
* format.Node(os.Stdout, fset, newAstFile)*
*}*




-- 
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: Regarding string immutablity

[mark]

https://github.com/awnumar/memguard is the only project I've noticed that 
attempts to deal with string security in Go.

I haven't used it personally.

On Tuesday, August 28, 2018 at 9:45:29 AM UTC-7, Jay Sharma wrote:
>
> *@Jan*, The example you shown it is copying a string to new variable. but 
> my question was related to same variable. 
>
> I want to know if I have variable :
>
> x := "testsring"
>
> Now it overwrite the content of same variable x to some other value:
> x = "new1string"
>
> Will it overwrite the same memory or it will create some copy ? 
>
> @Jake Montgomery, 
>
>  It is about *security*. I have some keys and I want to delete the 
> content of key, when no longer required. Here my API is expecting a string 
> key.
>
>
> On Tuesday, August 28, 2018 at 8:25:27 PM UTC+5:30, Jay Sharma wrote:
>>
>> Hi All,
>>
>> I went through documentation and many post. Every where it is specified 
>> *strings 
>> are immutable*.
>>
>> I have some string :
>>
>> x := "teststring"
>>
>>
>> I want to *wipe out/overwrite* the content of this string x from 
>> disk/memory. 
>>
>> As per me the simplest way to do this:
>>
>> x = ""
>>
>>
>> or If I want to overwrite it with some new content, I can do this: [*Here 
>> length of new string is equal to length of old string*]
>>
>> x = "new1string"
>>
>>
>> As I am overwriting the content with new content, Is it *inplace 
>> replacement* [same memory is being updated] or a new copy will be 
>> created with new content and old content will be there in the memory ? 
>>
>>
>>

-- 
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: Regarding string immutablity

[Tamás Gulácsi]

For security, you should use a []byte and overwrite there, and never create 
a string out of it (that'd induce a copy).

2018. augusztus 28., kedd 18:45:29 UTC+2 időpontban Jay Sharma a következőt 
írta:
>
> *@Jan*, The example you shown it is copying a string to new variable. but 
> my question was related to same variable. 
>
> I want to know if I have variable :
>
> x := "testsring"
>
> Now it overwrite the content of same variable x to some other value:
> x = "new1string"
>
> Will it overwrite the same memory or it will create some copy ? 
>
> @Jake Montgomery, 
>
>  It is about *security*. I have some keys and I want to delete the 
> content of key, when no longer required. Here my API is expecting a string 
> key.
>
>
> On Tuesday, August 28, 2018 at 8:25:27 PM UTC+5:30, Jay Sharma wrote:
>>
>> Hi All,
>>
>> I went through documentation and many post. Every where it is specified 
>> *strings 
>> are immutable*.
>>
>> I have some string :
>>
>> x := "teststring"
>>
>>
>> I want to *wipe out/overwrite* the content of this string x from 
>> disk/memory. 
>>
>> As per me the simplest way to do this:
>>
>> x = ""
>>
>>
>> or If I want to overwrite it with some new content, I can do this: [*Here 
>> length of new string is equal to length of old string*]
>>
>> x = "new1string"
>>
>>
>> As I am overwriting the content with new content, Is it *inplace 
>> replacement* [same memory is being updated] or a new copy will be 
>> created with new content and old content will be there in the memory ? 
>>
>>
>>

-- 
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] gofmt formats different than goimports in go1.11

[Matthias B.]

On Tue, 28 Aug 2018 22:56:24 +0530
Rohit Jain  wrote:

> 
> how do I solve this?
> 

Wait for goimports to be updated. Until then, increase the dose of your
OCD medication till you stop caring about the difference.

MSB

-- 
It was funnier inside my head.

-- 
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] gofmt formats different than goimports in go1.11

[Rohit Jain]

```err := testService.test.UpdateWithQuery(
 ctx,
 bson.M{
-"id":   campaignID,
+"id": campaignID,
 "x_yyy.testing": x.y,
 },
```
gofmt reports above diff


```err := testService.test.UpdateWithQuery(
 ctx,
 bson.M{
-"id": campaignID,
+"id":   campaignID,
  "x_yyy.testing": x.y,
 },
```

goimport reports above diff

if I correct the `goimports` suggrstion , gofmt reports the error and vice
-versa.

how do I solve this?

-- 
Rohit Jain

-- 
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: Regarding string immutablity

[Jan Mercl]

On Tue, Aug 28, 2018 at 6:45 PM Jay Sharma  wrote:

> @Jan, The example you shown it is copying a string to new variable. but
my question was related to same variable.

> Will it overwrite the same memory or it will create some copy ?

The same concept applies as before. String variables are unique, mutable
and independent entities, string values are possibly shared, meaning
different string variables can point to the same string value.

IOW, reasignment of 'x' mutates x but not what 'x' points to. In case of a
string literal, like in "foo" or "bar", no memory is ever written or
allocated wrt the string value. All literals are fixed at compile time to
reside in the text, read only segment of the program. Assigning "foo" to
'x' or "bar" to 'x' just mutates 'x' to point to "foo" or "bar"
respectively. The only thing mutated is the variable. The memory occupied
by the variable is overwritten, the string value it points to is not.

Assignment  of a string value/expression does not copy the string value.
Instead it copies/writes the pointer to the string value into the string
variable. More details can be found for example here:
https://research.swtch.com/godata

PS: It's like C char* pointers to a certain extent. Except Go strings know
their length without need to search for the NULL terminator - so they also
can include zero bytes. Moreover, different string variables can point to
different characters of the same string value. Thanks to that, if you slice
a string, like in `s = s[lo:hi]`, it's again an O(1) operation (as is
len(s)).

All of that is enabled by the imutability of string values. Compare to
slices. After 'a := []int{1, 2, 3}; b := a; b[1] = 42', a[1] == 42 is true.
However,  one cannot do the same with strings. s[expr] = 'X' is illegal if
s is of a string type.

-- 

-j

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

[go-nuts] Re: Regarding string immutablity

[Jay Sharma]

*@Jan*, The example you shown it is copying a string to new variable. but 
my question was related to same variable. 

I want to know if I have variable :

x := "testsring"

Now it overwrite the content of same variable x to some other value:
x = "new1string"

Will it overwrite the same memory or it will create some copy ? 

@Jake Montgomery, 

 It is about *security*. I have some keys and I want to delete the content 
of key, when no longer required. Here my API is expecting a string key.


On Tuesday, August 28, 2018 at 8:25:27 PM UTC+5:30, Jay Sharma wrote:
>
> Hi All,
>
> I went through documentation and many post. Every where it is specified 
> *strings 
> are immutable*.
>
> I have some string :
>
> x := "teststring"
>
>
> I want to *wipe out/overwrite* the content of this string x from 
> disk/memory. 
>
> As per me the simplest way to do this:
>
> x = ""
>
>
> or If I want to overwrite it with some new content, I can do this: [*Here 
> length of new string is equal to length of old string*]
>
> x = "new1string"
>
>
> As I am overwriting the content with new content, Is it *inplace 
> replacement* [same memory is being updated] or a new copy will be created 
> with new content and old content will be there in the memory ? 
>
>
>

-- 
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] Unexpected behavior of %+02d in Sprintf() and friends

[Eric Raymond]

Under Go 1.10.1, feeding an 0 value to a %+02d specifier sometimes yields  
"+0", not "+00". The attached tiny Go program may reproduce this behavior.  
I say "may" because I first observed it in a series of unit tests of date 
format conversions - in different format strings %+02d expanded 
differently.  I haven't found a pattern to this, or I'd report it. On my 
system this program, at least, has repeatable behavior.

If this behavior were consistent, I'm not sure it would be a bug. It's 
possible that the sign is supposed to be counted as part of the number 
width; if so, it's an interesting question whether this is the right thing 
when explicit sign is forced by +.  The documentation is unclear.

The apparent inconsistency worries me.  There may be some state in the 
form,at-interpretation code that is not always tracked correctly.

In accordance with the Contribution Guidelines, I'm tossing  the question 
out here for a sanity check before throwing it on the bugtracker.  Have 
there been any similar reports?

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


gobug1.go
Description: Binary data

[go-nuts] Cross compiling sers (with CGO) to Android

[distributed]

I am trying to cross compile the sers library from 
github.com/distributed/sers to arm64 android.

I have an Android SDK on my computer and I point $AR, $CC, $CXX and so on 
to the relevant programs.

In a checkout of the sers library (git clone 
https://github.com/distributed/sers.git) I run:

~/tmp/sers$ CGO_ENABLED=1 GOARCH=arm64 GOOS=linux go get 
# runtime/cgo
/home/joe/android/toolchain/bin/../lib/gcc/aarch64-linux-android/4.9.x
/../../../../aarch64-linux-android/bin/ld: cannot find -lpthread
clang60: error: linker command failed with exit code 1 (use -v to see 
invocation)

My go env is:

~/tmp/sers$ CGO_ENABLED=1 GOARCH=arm64 GOOS=linux go env
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/joe/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/joe/gop"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="aarch64-linux-android-clang"
CXX="aarch64-linux-android-clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -fdebug-prefix-map=/tmp/go-build095666131=/tmp/go-build 
-gno-record-gcc-switches"

I am using Go 1.11.


I suspect that the toolchain attempts to link against -lpthread, but this 
is not necessary, since pthread functionality is included in the C library 
in Android.

Does anybody know how to circumvent this build 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: Regarding string immutablity

[jake6502]

I think Jan answered the question asked. But, do you have some specific 
concern that prompted the question? Is it about security, or memory usage, 
or just curiosity?

On Tuesday, August 28, 2018 at 10:55:27 AM UTC-4, Jay Sharma wrote:
>
> Hi All,
>
> I went through documentation and many post. Every where it is specified 
> *strings 
> are immutable*.
>
> I have some string :
>
> x := "teststring"
>
>
> I want to *wipe out/overwrite* the content of this string x from 
> disk/memory. 
>
> As per me the simplest way to do this:
>
> x = ""
>
>
> or If I want to overwrite it with some new content, I can do this: [*Here 
> length of new string is equal to length of old string*]
>
> x = "new1string"
>
>
> As I am overwriting the content with new content, Is it *inplace 
> replacement* [same memory is being updated] or a new copy will be created 
> with new content and old content will be there in the memory ? 
>
>
>

-- 
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] Regarding string immutablity

[Jan Mercl]

On Tue, Aug 28, 2018 at 4:55 PM Jay Sharma  wrote:

> As I am overwriting the content with new content, Is it inplace
replacement [same memory is being updated] or a new copy will be created
with new content and old content will be there in the memory ?

Basically none of that. Strings indeed are immutable. Consider

   s := "foo"
   t := s
   s := "bar"

After this t == "foo" is still true. The implementation of this is that a
mutable _variable_ of type string internally points to an immutable string
_value_ (in the first approximation). So assigning(copying) the 's'
variable makes 't' have the value "foo" and keeps it even if the variable
's' is later mutated to point to a different string value. The concept
extends to any RHS string expression assignment, not only 's'. The LHS (or
the pointee in p :=  *pt := whatever) is mutable independently of the
immutable value it represents (provides, points to).

The nice side effect is that every string variable is unique, but the
string values they represent may be shared without copying the actual
string value - only the string variable is ever copied. And that's an O(1)
thing.

-- 

-j

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

[go-nuts] Go 1.11 module cache not safe for concurrent use?

[Maxim Khitrov]

I'm running into non-deterministic errors when I try to build multiple
binaries from the same module with goreleaser in a CI/CD system. Here
are some examples:

go: finding github.com/pkg/browser v0.0.0-20170505125900-c90ca0c84f15
go: github.com/pkg/browser@v0.0.0-20170505125900-c90ca0c84f15: git
fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in
/go/pkg/mod/cache/vcs/8755ee3fe34afbf0e42bd94de4ff233c0a12a60e9ddcc7a72c38f16620d3eebf:
chdir 
/go/pkg/mod/cache/vcs/8755ee3fe34afbf0e42bd94de4ff233c0a12a60e9ddcc7a72c38f16620d3eebf:
no such file or directory

go: github.com/davecgh/go-spew@v1.1.1: git remote add origin
https://github.com/davecgh/go-spew in
/go/pkg/mod/cache/vcs/b9a4b9bbdb4a59723f2348415ad7ffda91568455a1cfd92e97976132bdfbaf57:
exit status 128:
fatal: remote origin already exists.

go: github.com/pmezard/go-difflib@v1.0.0: unknown revision v1.0.0

go: error loading module requirements

If I run 'go mod download' before the build, everything works fine, so
I believe that this problem is caused by goreleaser starting multiple
parallel builds with an empty module cache. I've tested this several
times now by removing pkg/mod and GOCACHE directories.

My question is whether it should be possible to do so or if this is
just a known limitation of how the module cache works? The following
issue suggests that GOCACHE is safe for concurrent use, but I couldn't
find information on the module cache:

https://github.com/golang/go/issues/26677

-Max

-- 
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] Regarding string immutablity

[Jay Sharma]

Hi All,

I went through documentation and many post. Every where it is specified 
*strings 
are immutable*.

I have some string :

x := "teststring"


I want to *wipe out/overwrite* the content of this string x from 
disk/memory. 

As per me the simplest way to do this:

x = ""


or If I want to overwrite it with some new content, I can do this: [*Here 
length of new string is equal to length of old string*]

x = "new1string"


As I am overwriting the content with new content, Is it *inplace 
replacement* [same memory is being updated] or a new copy will be created 
with new content and old content will be there in the memory ? 


-- 
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] Calling HTML DOM functions with wasm

[Halil Can Kaşkavalcı]

I'm trying to create a table. I thought I can call DOM functions with wasm 
but my attempts so far are not fruitful. Can somebody illustrate how to 
call, let's say, insertRow() 
?

-- 
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: GoAWK: an AWK interpreter written in Go

[Ben Hoyt]

>
> Once you have some proper benchmarks, it might be fun to compare GoAWK's
> performance to that of my awk package .
>

Nice -- will do!

I don't know how much performance difference this makes in practice, but my
> value struct (also in a value.go file) lazily converts among strings,
> floats, and ints and caches the conversions.  I don't keep track of "the"
> type of a value (your typ field), just whether I have a currently valid
> string/float/int representation.
>

Interesting approach. I hope to try out different value representations,
but from a quick profiling run I don't think that's the bottleneck right
now (using maps for variables is).

No need to change your lexer/parser at this stage, but I've recently grown
> quite fond of PEG parsers
> .  These are a
> lot like hand-rolled, recursive-descent parsers so they're relatively easy
> to wrap your head around and reasonably powerful but require less
> code/effort than actually rolling your own.  For Go, I've used pigeon
>  for a few projects (e.g., edif2qmasm
> , for which a PEG parser is probably
> overkill).  I like pigeon, but I admit I didn't do a thorough analysis of
> all the available PEG parsers for Go before going with that one.
>

I'll check them out.

Nice work!
>

Thanks!

-Ben

-- 
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: sync.(*Map).Load: relocation target sync/atomic.(*Value).Load not defined when building for ios_arm

[Steeve Morin]

Actually, the problem happens also without c-archive.

I've put out a repro repo at: https://github.com/steeve/rules_go_ios_arm

You'll need to run this on macOS (because iOS...).

On Monday, August 27, 2018 at 4:37:37 PM UTC+2, Steeve Morin wrote:
>
> Hey folks,
>
> I'm trying to build a project with Bazel on with buildmode=c-archive, and 
> I'm running into the following issue on ios_arm and Go 1.11 only:
>
> sync.(*Map).Load: relocation target sync/atomic.(*Value).Load not defined
> sync.(*Map).Store: relocation target sync/atomic.(*Value).Load not defined
> sync.(*Map).LoadOrStore: relocation target sync/atomic.(*Value).Load not 
> defined
> sync.(*Map).dirtyLocked: relocation target sync/atomic.(*Value).Load not 
> defined
> internal/testlog.Logger: relocation target sync/atomic.(*Value).Load not 
> defined
>
> Go 1.10 works fine.
>
> Now I know this is probably something that rules_go is doing wrong, 
> because gomobile is working as expected.
> That said, I am not sure where to look on how to pinpoint the issue, so I 
> would gladly appreciate pointers.
>
> The revelant rules_go issue is at: 
> https://github.com/bazelbuild/rules_go/issues/1693#issuecomment-416081365
>
> There was a similar problem with ios_386 which was solved by not building 
> the stdlib with -shared.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] http client GET with err : dial tcp:look up xxxxx: Temporary failure in name resolution

['Rick Timmis' via golang-nuts]

Hi, try running your code in a debugger, it smells like a DNS resolution 
failing, leaving your code awaiting a response.
In a debugger you would be able to see this happening

HTH

-- 
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: Go 1.11 and 1.10.4 are Released

[Michel Casabianca]

Hi Gophers,

I have updated my list of Go interfaces for these releases : http://sweetohm
.net/article/go-interfaces.en.html

Enjoy!

Le sam. 25 août 2018 à 00:41, Nathan Kerr  a
écrit :

> I updated my release related resources:
>
>- Go Release Timeline 
>- When Should You Upgrade Go?
>
>
>
> On Friday, August 24, 2018 at 3:24:25 PM UTC-7, Andrew Bonventre wrote:
>>
>> Hello gophers,
>>
>> We just released Go 1.11 and 1.10.4.
>>
>> You can read the announcement blog post here:
>>   https://blog.golang.org/go1.1 1
>>
>> You can download binary and source distributions from our download page:
>>   https://golang.org/dl/
>>
>> To compile from source using a Git checkout, update to the release with
>> "git checkout go1.11" or "git checkout go1.10.4" and build as usual.
>>
>> To find out what has changed in Go 1.11, read the release notes:
>>   https://golang.org/doc/go1.1 1
>>
>> Thanks to everyone who contributed to the release!
>>
>> Cheers,
>> The Go Team
>>
> --
> 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.
>


-- 
Michel Casabianca

-- 
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: How to post Form data using Go WASM?

[comexx]

You can check this example: 
https://github.com/nlepage/golang-wasm/tree/master/examples/long-running

On Monday, August 27, 2018 at 4:27:57 PM UTC+2, Tad Vizbaras wrote:
>
> I am struggling to get this working. 
>
> How to post Form data to the web server using Go WASM?
> Do I use fetch API or XMLHttpRequest?
>
>

-- 
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] Test caching unexpectedly disabled by -exec

[Steven Hartland]

On 24/08/2018 18:00, Ian Lance Taylor wrote:

On Fri, Aug 24, 2018 at 8:31 AM, Steven Hartland  wrote:

Hi all I've just been banging my head why test our linux test env isn't
caching tests and found that its down to -exec.

The docs (https://golang.org/cmd/go/#hdr-Build_and_test_caching) refer to
cacheable "test" flags but doesn't mention standard non-test flags.

In addition to this GODEBUG=gocachetest=1 reports all cases where it
disables caching except when there is a execCmd which simply skips setting
-test.testlogfile:
https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L1107

This was the most frustrating part as it meant hacking the runtime to figure
out why caching was not working.

So two question:

Is disabling test caching with -exec really intended and why?
Would it be acceptable to have to option to cache with -exec?

In terms of background, we use -exec so we change the binary permissions so
the tests run correctly, it changes CAP's, without which the test wont run.

I'm sorry you had to hack the runtime, but I do want to mention that
this is documented at https://golang.org/cmd/go/#hdr-Test_packages:

 The rule for a match in the cache is that the run involves the
same test binary and the flags on the command line come entirely from
a restricted set of 'cacheable' test flags, defined as -cpu, -list,
-parallel, -run, -short, and -v. If a run of go test has any test or
non-test flags outside this set, the result is not cached.

To me it seems reasonable that we should be able to cache test results
if -exec is specified, though of course it means that the cache would
need to include the -exec argument in the cache key.  I suggest that
you open a feature request for that at https://golang.org/issue.
Thanks.

Ian

Thanks for the feedback Ian.

Issue https://golang.org/issue/27207 raised, as you've see, and PR to 
fix also pushed https://go-review.googlesource.com/c/go/+/131415


Fix was simple in the end as ExecCmd is already included in the 
cache.ActionID for tests, so only required removing the extra condition 
from builderRunTest and docs update, reviews appreciated.


    Regards
    Steve

--
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] gocontracts with type invariants

[Marko Ristin]

Hi,
We implemented a tool to allow design-by-contract in Go by automatically 
generating pre and postcondition checks in code: 
https://github.com/Parquery/gocontracts. 

However, the most interesting part of the design-by-contract, namely 
invariants, is still missing and I'd like to hear your feedback on how to 
implement it. 

In an OO language, invariants should hold after the constructor and after 
invocation of each public method. They are particularly interesting way to 
formalize the properties on your more complex contained data structures. 
For example, if you internally use a sorted slice to perform binary search 
on it for interval queries, an invariant would be that the slice is always 
sorted. Another example is a directed acyclic graph with an invariant that 
there should be no cycles.

For a more detailed (and better) article on advantages of 
design-by-contract in general and invariants in particular, please see: 
https://cacm.acm.org/blogs/blog-cacm/227928-why-not-program-right/fulltext

Right now, gocontracts operates on individual files. To add the invariants 
to a type, I thought about passing the package folder (instead of 
individual files) to gocontracts, inspecting the type comments and 
iterating through all the public methods associated with the type. Since 
there are no constructors in Go, I'd establish the invariants in all the 
public methods as additional pre and postconditions.

I though that a documentation defining the invariants could look like this:

// SomeType represents something.
//
// SomeType establishes:
// * x >= 0
// * x < Width
// * x < somePrivateProperty
type SomeType struct {
   // ...
}

For some method:

// SomeFunc does something.
//
// SomeFunc requires:
// * x % 3 == 0
func (s *SomeType) SomeFunc(x int) {
   // ...
}


gocontracts would append the invariants of the type to the pre and 
postconditions and generate the checks as:

// SomeFunc does something.
//
// SomeFunc requires:
// * x % 3 == 0
func (s *SomeType) SomeFunc(x int) {
   // Pre-conditions
   switch {
   case !(s.x >= 0):
  // panic ...
   case !(x % 3 == 0):
  // panic ...
   // ...
   }

   // Post-conditions
   defer func() {
  switch {
  case !(s.x >= 0):
 // panic ...
  // ...
  }
   }()
   // ...
}


How do you like the idea? Is the syntax appealing? Would you mind if you 
could only disable/enable checks on per-package basis?

In case gocontracts would still keep on operating on individual files, 
would it be confusing if it parsed all the other go files in the file's 
directory to read the invariants and then apply it to only the given file 
(and not establishing invariants on the functions defined in other files)?

Thanks a lot for your feedback!
Marko

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