Re: [go-nuts] Re: Gracefully Shutdown File Server

[amkguo]

Maybe this is a bug or need clear documentation about this. 

I've filed a bug report here: https://github.com/golang/go/issues/19541

Andrew

-- 
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] dep: Roadmap for merging into the toolchain

[Sam Boyer]

Hi Russ -

thanks, this is great. I think all of this will be much easier with these 
discussions happening in the open.

On Monday, March 13, 2017 at 5:09:19 PM UTC-4, Russ Cox wrote:
>
> On Tue, Mar 7, 2017 at 6:47 AM, Sam Boyer  > wrote:
>
>> Hi folks,
>>
>> Since we opened up the dep project  in 
>> late January, there's been flurry of contributions, which has been great. 
>> However, the plans and end goal of dep haven't been entirely clear to 
>> everyone.
>>
>> To address that, and help guide contributors, we've put out a roadmap 
>> .
>>
>> We're hoping to have dep ready to merge into the toolchain at the 
>> beginning of the 1.10 cycle. But that'll only happen if the community steps 
>> up even more to help!
>>
>
> Hi Sam,
>
> You make it sound like dep is just going to become 'go dep' in Go 1.10. 
> That's not the plan I thought we discussed.
>

Ahh, if that's the way it's coming across, I apologize! I've tried to 
adhere as closely to the plans we've discussed as possible. At times, in 
some places (particularly high-level docs like roadmaps), I've omitted some 
detail, in favor of making the project approachable for new contributors.

For example, I can see how the wording I used in the OP here could be read 
as suggesting that it would become `go dep` in 1.10, which would violate 
your subcommand complexity requirement. That wasn't my intent; I most 
recently reiterated that requirement earlier today 
.

My guess is that my general enthusiasm about all of this may be obscuring 
some of the uncertainty. I mean...I'm enthusiastic about this effort, what 
can I say :) More on this at the bottom.

 

>
> As I wrote to you and the package management group in January:
>
> I think it's very important instead to weave package and dependency 
> management into the go command so that you don't notice it as a separate 
> thing in day-to-day work. As a result, I see dep as an important 
> improvement over current practice that's usable immediately, an important 
> step toward a final solution, and also an experiment that helps us learn 
> more about what structure works for people, but I don't see it, for 
> example, as a prototype of the eventual go command integration (since it's 
> not integrated at all).
>
> In particular, I agree strongly with all of these decisions in dep:
>
> - Manifest file listing version requirements.
> - Lock file listing exact versions for a reproducible build.
> - Version control repo as project granularity is good.
> - Calling the group of packages released as a unit a "project" is a good 
> name to establish.
> - Implementing coordination with the build by populating vendor is clearly 
> the right implementation.
>
> For eventual integration with the go command and the broader go toolchain, 
> some of the decisions are likely not optimal. In particular:
>
> - go get vs not. Dep creates a parallel world separate from 'go get'. 
> Having two is not great. Ideally, I'd like 'go get' to improve instead of 
> adding a second mechanism.
> - Subcommand complexity. As mentioned in #25, if dep foo became 'go dep 
> foo', then it would be the first sub-sub-commands and likely indicates a 
> less than clean integration.
> - Vendor directories. As an implementation mechanism today, these make 
> sense. They stop making sense if we can change the toolchain. Instead of 
> translating the lock file into an ephemeral vendor directory, the tooling 
> can just read the lock file directly.
> - Multiple packages. At scale, I think allowing v1 and v2 of a single 
> package to be linked into the final binary is unavoidable. It's also not 
> possible to express in the "top-level vendor directory" model. Another 
> reason to eliminate the "translate lock file to vendor directory" step.
> - GOPATH vs not. As I understand it, dep continues to assume GOPATH, but 
> in a multiversion world that may not be appropriate. We need to understand 
> the implications here. GOPATH has to keep working well, but I think we 
> probably want 'git clone foo && cd foo && do work' outside GOPATH to work 
> equally well, and package management has an important role to work out here.
>
>
> I understand that not changing the go command was a constraint from the 
> discussions at Gophercon and also from the point of view of making 
> something people can use today. That's absolutely appropriate and correct 
> for dep. But for long-term integration, I think we do need to rethink these 
> aspects of the go command itself. 
>
>
I realize we've discussed these a bit further since that email, but for 
everyone's benefit:

All of these are things that, as you note, can only really be addressed 
once we're seriously looking at moving directly into the toolchain. It's 
felt to me like there's a catch-22 in bringing up such things up publicly; 
doing so would provoke 

[go-nuts] Re: Does sync.Cond call Lock() twice on the underlying Locker?

[Albert Tedja]

Ugh. It makes sense now. cond.L.Lock() gets called from the first 
goroutine, then immediately followed by another Lock() from the second.  
Therefore, in order to properly implement Lock(), it actually has to be 
blocking.

On Monday, March 13, 2017 at 4:35:04 PM UTC-7, dja...@gmail.com wrote:
>
>
>
> On Tuesday, March 14, 2017 at 12:10:31 AM UTC+2, Albert Tedja wrote:
>>
>> I am writing a custom Locker which does a check if Lock() is being called 
>> more than once and throws a panic if it does.
>> I tested it to see if I can use it with sync.Cond, and for the most part, 
>> it was running as intended, except once in a while
>> the panic check triggered.
>>
>> Here's the dumbed down version of what I am trying to do:
>>
>> https://play.golang.org/p/2tWqY221RM
>>
>> I cannot get it to reproduce on the Go Playground, but copy paste it to 
>> your local computer and see if you get it to panic.
>> Here's what I got:
>>
>> panic: Cannot lock twice
>> goroutine 5 [running]:
>> main.(*CustomLocker).Lock(0xc42000e2e0)
>> /.../go/src/github.com/test/custom_locker.go:18 +0xc9
>> main.main.func1(0xc4200142c0, 0xc42000e2f0, 0xc42000e2d0)
>> /.../go/src/github.com/test/custom_locker.go:42 +0x37
>> created by main.main
>> /.../go/src/github.com/test/custom_locker.go:50 +0x159
>> exit status 2
>>
>> I thought sync.Cond.Wait() should Unlock(), sleeps itself, then when 
>> awaken by Broadcast() try to Lock() again?
>>
>
> Hi,
>
> First, your custom Locker implements Locker interface, but does not lock 
> as it call Unlock at function return.
> Second, Locker main job is to call Lock() multiple times (from different 
> goroutines)
>
> Djadala
>

-- 
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] cross compile windows from linux failed with -H=windowsgui

[brainman]

I think we should just get rid of Hwindowsgui. I am pretty sure it is only 
different from Hwindows in one place in cmd/link.

I will try and implement this when I have time.

Alex

-- 
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 sync.Cond call Lock() twice on the underlying Locker?

[djadala]

On Tuesday, March 14, 2017 at 12:10:31 AM UTC+2, Albert Tedja wrote:
>
> I am writing a custom Locker which does a check if Lock() is being called 
> more than once and throws a panic if it does.
> I tested it to see if I can use it with sync.Cond, and for the most part, 
> it was running as intended, except once in a while
> the panic check triggered.
>
> Here's the dumbed down version of what I am trying to do:
>
> https://play.golang.org/p/2tWqY221RM
>
> I cannot get it to reproduce on the Go Playground, but copy paste it to 
> your local computer and see if you get it to panic.
> Here's what I got:
>
> panic: Cannot lock twice
> goroutine 5 [running]:
> main.(*CustomLocker).Lock(0xc42000e2e0)
> /.../go/src/github.com/test/custom_locker.go:18 +0xc9
> main.main.func1(0xc4200142c0, 0xc42000e2f0, 0xc42000e2d0)
> /.../go/src/github.com/test/custom_locker.go:42 +0x37
> created by main.main
> /.../go/src/github.com/test/custom_locker.go:50 +0x159
> exit status 2
>
> I thought sync.Cond.Wait() should Unlock(), sleeps itself, then when 
> awaken by Broadcast() try to Lock() again?
>

Hi,

First, your custom Locker implements Locker interface, but does not lock as 
it call Unlock at function return.
Second, Locker main job is to call Lock() multiple times (from different 
goroutines)

Djadala

-- 
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 sync.Cond call Lock() twice on the underlying Locker?

[Albert Tedja]

$ go version
go version go1.8 linux/amd64

-- 
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 sync.Cond call Lock() twice on the underlying Locker?

[Albert Tedja]

I am writing a custom Locker which does a check if Lock() is being called 
more than once and throws a panic if it does.
I tested it to see if I can use it with sync.Cond, and for the most part, 
it was running as intended, except once in a while
the panic check triggered.

Here's the dumbed down version of what I am trying to do:

https://play.golang.org/p/2tWqY221RM

I cannot get it to reproduce on the Go Playground, but copy paste it to 
your local computer and see if you get it to panic.
Here's what I got:

panic: Cannot lock twice
goroutine 5 [running]:
main.(*CustomLocker).Lock(0xc42000e2e0)
/.../go/src/github.com/test/custom_locker.go:18 +0xc9
main.main.func1(0xc4200142c0, 0xc42000e2f0, 0xc42000e2d0)
/.../go/src/github.com/test/custom_locker.go:42 +0x37
created by main.main
/.../go/src/github.com/test/custom_locker.go:50 +0x159
exit status 2

I thought sync.Cond.Wait() should Unlock(), sleeps itself, then when awaken 
by Broadcast() try to Lock() again?

-- 
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] RSQL, a lighweight clone of Microsoft SQL Server written in Go

[Jan Mercl]

On Mon, Mar 13, 2017 at 10:10 PM 'simon place' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> i see Apache 2 licence file in the root.(github)

That repository seems to contain only "Go driver for connecting to RSQL
database server".

I followed OP's link chain

- http://rsql.ch/
- [Source Code] https://gitlab.com/rin01/rsql
- [Repository] https://gitlab.com/rin01/rsql/tree/master

No LICENSE there last time I checked (minutes ago).

Of course, I assume that's just an oversight and that the LICENSE will
appear there soon.

-- 

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

Re: [go-nuts] RSQL, a lighweight clone of Microsoft SQL Server written in Go

[mhhcbon]

https://github.com/rin01/rsql/blob/master/LICENSE

did you mean the license is not packed into the dist archives ?

in my concern i wonder where is the cli source, i can t find it.

Also it is said to be 140k LOC, but i can t see them all in the repo,
i must miss something. Are they the C part mentioned in the faq ? 
http://rsql.ch/misc/faq/

On Monday, March 13, 2017 at 9:36:28 PM UTC+1, Jan Mercl wrote:
>
>
> On Mon, Mar 13, 2017 at 9:13 PM nicolas riesch  > wrote:
>
> > But it would help me to have your first impression or opinion on this 
> project.
>
> Sounds very very interesting, but... Here are the first impressions:
>
> - I can see no LICENSE or similar file in the root directory. I consider 
> it unsafe to look at other's code w/o knowing the license terms.
>
> - Installation documentation seems to be silent about $ go 
> {get,build,install}, but it does mention installing some binaries. I 
> consider it unsafe to use binary programs of non trusted origin.
>
> -- 
>
> -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.

Re: [go-nuts] Re: What happens when appending to a slice exceeds the backing capacity?

[Dave Cheney]

A few clarifications, b does not point to a. a and b are variables of type 
[]int. The value of each slice's ptr fields point to a backing array of some 
capacity. 

If you append to a, this does not change th length or cap fields of b. If you 
do this enough times that ptr field of a will be updated to reflect that it now 
points to a different backing array. 

Perhaps something like this could be used to determine if a and b point to th 
same backing array, but as you suggested, it's probably the wrong question.

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

-- 
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] RSQL, a lighweight clone of Microsoft SQL Server written in Go

['simon place' via golang-nuts]

i see Apache 2 licence file in the root.(github)

-- 
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] dep: Roadmap for merging into the toolchain

[Russ Cox]

On Tue, Mar 7, 2017 at 6:47 AM, Sam Boyer  wrote:

> Hi folks,
>
> Since we opened up the dep project  in
> late January, there's been flurry of contributions, which has been great.
> However, the plans and end goal of dep haven't been entirely clear to
> everyone.
>
> To address that, and help guide contributors, we've put out a roadmap
> .
>
> We're hoping to have dep ready to merge into the toolchain at the
> beginning of the 1.10 cycle. But that'll only happen if the community steps
> up even more to help!
>

Hi Sam,

You make it sound like dep is just going to become 'go dep' in Go 1.10.
That's not the plan I thought we discussed.

As I wrote to you and the package management group in January:

I think it's very important instead to weave package and dependency
management into the go command so that you don't notice it as a separate
thing in day-to-day work. As a result, I see dep as an important
improvement over current practice that's usable immediately, an important
step toward a final solution, and also an experiment that helps us learn
more about what structure works for people, but I don't see it, for
example, as a prototype of the eventual go command integration (since it's
not integrated at all).

In particular, I agree strongly with all of these decisions in dep:

- Manifest file listing version requirements.
- Lock file listing exact versions for a reproducible build.
- Version control repo as project granularity is good.
- Calling the group of packages released as a unit a "project" is a good
name to establish.
- Implementing coordination with the build by populating vendor is clearly
the right implementation.

For eventual integration with the go command and the broader go toolchain,
some of the decisions are likely not optimal. In particular:

- go get vs not. Dep creates a parallel world separate from 'go get'.
Having two is not great. Ideally, I'd like 'go get' to improve instead of
adding a second mechanism.
- Subcommand complexity. As mentioned in #25, if dep foo became 'go dep
foo', then it would be the first sub-sub-commands and likely indicates a
less than clean integration.
- Vendor directories. As an implementation mechanism today, these make
sense. They stop making sense if we can change the toolchain. Instead of
translating the lock file into an ephemeral vendor directory, the tooling
can just read the lock file directly.
- Multiple packages. At scale, I think allowing v1 and v2 of a single
package to be linked into the final binary is unavoidable. It's also not
possible to express in the "top-level vendor directory" model. Another
reason to eliminate the "translate lock file to vendor directory" step.
- GOPATH vs not. As I understand it, dep continues to assume GOPATH, but in
a multiversion world that may not be appropriate. We need to understand the
implications here. GOPATH has to keep working well, but I think we probably
want 'git clone foo && cd foo && do work' outside GOPATH to work equally
well, and package management has an important role to work out here.

I understand that not changing the go command was a constraint from the
discussions at Gophercon and also from the point of view of making
something people can use today. That's absolutely appropriate and correct
for dep. But for long-term integration, I think we do need to rethink these
aspects of the go command itself.


By far the most important things to do with dep right now are (1) build
something people can use and get benefit from today and eliminate blockers
to adoption and (2) based on experience with that usage, learn what the
eventual design and go command integration should look like.

It's important to note that I do not expect projects using dep to
automatically work with the new go command integration too. In particular,
I expect that the lock and manifest files will change in syntax and
therefore file name during integration into the go command, so that it is
possible for projects to work with both dep and the go command during a
transition. I also expect that we need to have a discussion about supported
version constraints, to avoid forcing our tools to solve NP-complete
problems  (it's not just crazy
hard, it's crazy hard to explain to users when it breaks). The best input
to that discussion will be examination of what dep users use.

I also was hoping to have more thoughts fleshed out more than a month ago,
but I've had a sequence of higher-priority interrupts and haven't had a
chance to do that yet. That's on me, and I apologize for that. (I'm not
going to be around a lot for the next three weeks either, so likely not
much will happen on my end until April.)

Dep is another important step - just as vendor dirs were - in the effort
toward proper package management within the go command. It's a way for us
to learn more about what works and what doesn't. 

Re: [go-nuts] RSQL, a lighweight clone of Microsoft SQL Server written in Go

[John McKown]

On Mon, Mar 13, 2017 at 3:36 PM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Mon, Mar 13, 2017 at 9:13 PM nicolas riesch 
> wrote:
>
> > But it would help me to have your first impression or opinion on this
> project.
>
> Sounds very very interesting, but... Here are the first impressions:
>
> - I can see no LICENSE or similar file in the root directory. I consider
> it unsafe to look at other's code w/o knowing the license terms.
>

​OUCH! No LICENSE means "no look" in my book.​



>
> - Installation documentation seems to be silent about $ go
> {get,build,install}, but it does mention installing some binaries. I
> consider it unsafe to use binary programs of non trusted origin.
>
> --
>
> -j
>
>


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

-- 
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] RSQL, a lighweight clone of Microsoft SQL Server written in Go

[Jan Mercl]

On Mon, Mar 13, 2017 at 9:13 PM nicolas riesch 
wrote:

> But it would help me to have your first impression or opinion on this
project.

Sounds very very interesting, but... Here are the first impressions:

- I can see no LICENSE or similar file in the root directory. I consider it
unsafe to look at other's code w/o knowing the license terms.

- Installation documentation seems to be silent about $ go
{get,build,install}, but it does mention installing some binaries. I
consider it unsafe to use binary programs of non trusted origin.

-- 

-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] RSQL, a lighweight clone of Microsoft SQL Server written in Go

[nicolas riesch]

I have developed RSQL, a *lighweight clone of Microsoft SQL Server*, which 
runs on Linux and can execute T-SQL scripts.

It has been successfully tested with millions of records.

The source code is *written in Go*, and contains 140,000 lines.

It would help me very much if some of you could download it and play with 
it.

Stored procedures and other features will be implemented in the future, so 
be patient.

But* it would help me to have your first impression or opinion on this 
project*.

http://rsql.ch


For the moment, only a driver for Go exists. It is not a "database/sql" 
driver, but the API is not difficult to use.

driver:
https://github.com/rin01/rsql

driver documentation:
https://godoc.org/github.com/rin01/rsql/drv





-- 
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: Add Equals to sort.Interface?

[pauledwardbuis]

See https://github.com/zephyrtronium/sort/blob/master/2pqs.go for a dual 
pivot quicksort implementation that just uses Less without duplicate calls 
to Less to simulate Equals!

On Thursday, December 3, 2009 at 8:05:04 PM UTC-5, baldmountain wrote:
>
> I was having a go at porting the dual pivot quicksort to Go and there 
> are a few places where the algorithm tests for equals. You can 
> simulate this with: 
>
> !data.Less(idx1, idx2) && !data.Less(idx2, idx1) 
>
> But this is inefficient. An Equals method would eliminate at least one 
> function call over this method. 
>
> Should we add: 
>
> Equals(i, j int) bool; 
>
> to sorting.Interface? 
>

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

Re: [go-nuts] cross compile windows from linux failed with -H=windowsgui

[Ian Lance Taylor]

On Mon, Mar 13, 2017 at 8:05 AM,   wrote:
> I use Kubuntu 16.10, when compile a project over to windows, I get this
> error:
>
> crosscall2: adddynsym: unsupported binary format
> _cgo_panic: adddynsym: unsupported binary format
> _cgo_topofstack: adddynsym: unsupported binary format
> adddynlib: unsupported binary format
> adddynlib: unsupported binary format
>
> The command I used to compile was:
>
> export GOOS=windows
> go build -ldflags "-H=windowsgui" -o  main.go
>
>  if I remove "-H=windowsgui" the problem is gone.  What I wanted is to get
> rid of console window while run my program on Windows.  I found the solution
> here:
>
> http://stackoverflow.com/questions/23250505/how-do-i-create-an-executable-from-golang-that-doesnt-open-a-command-cmd-wind
>
> Unfortunately it didn't work.  Any ideas?

I think it's just a bug.  Some conditions that are checking for
Hwindows also need to check for Hwindowsgui.  Please open a bug report
at https://golang.org/issue/new with a complete, small, case we can
use to reproduce the problem.  Thanks.

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] Re: What happens when appending to a slice exceeds the backing capacity?

[xiiophen]

 
On Monday, 13 March 2017 07:20:57 UTC, Jan Mercl wrote:

> On Mon, Mar 13, 2017 at 8:05 AM st ov  
> wrote:
>  
> > I know it can be accessed the question relates to this
> > 
> http://stackoverflow.com/questions/36706843/how-to-get-the-underlying-array-of-a-slice-in-go
>  
> Let me ask what do you need the backing array for which cannot be done 
> using the slice value? Using the slice value you can read the backing 
> array, write to it, take address of its element and slice the array. What 
> use case is not covered by those operations?
>  
> -- 
>  
>
> -j
>
 
There's a "gotcha" with slices were knowing the pointer to the underlying 
array would help distinguish whether two slices still refer to the same 
data after append operations:
 
https://play.golang.org/p/JFUEBbyMi1
 

package main 

 

import (

"fmt"

)

 

func main() {

a := []int{1, 2, 3}

b := a

 

fmt.Printf(" a %v \n b %v \n\n", a, b)

 

a[0] = 77

 

fmt.Printf(" a %v \n b %v \n\n", a, b)

 

a = append(a, 18, 19, 110)

 

fmt.Printf(" a %v \n b %v \n\n", a, b)

 

a[0] = 44

 

fmt.Printf(" a %v \n b %v \n\n", a, b)

 

b[0] = 55

 

fmt.Printf(" a %v \n b %v \n\n", a, b)

}

 
Initially b "points" to a, and changes to either are reflected in both, as 
one would expect from a pointer to a traditional array.. 

However after appending beyond the original capacity the* a* variable is 
copied to an expanded underlying array, but *b* still points to the 
original underlying array . if *a*'s capacity was large enough initially 
then this (runtime) behaviour would change.

.. the solution is to avoid, not check for this though I think.

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

Re: [go-nuts] Re: Simple design question: method or function?

[Peter Herth]

One important difference is polymorphism/namespacing. If you have the types
X,Y,Z, each of them could implement a Quack() method, while you would have
to write a QuakX, QuakY, and QuakZ function, if you wanted to wanted to
have the three different implementations. So the method approach looks and
reads much cleaner, even if you do not plan to dispatch dynamically.

Peter

On Sun, Mar 12, 2017 at 3:36 PM,  wrote:

> Please check https://grisha.org/blog/2016/09/22/golang-receiver-vs-
> function/
>
>
> On Wednesday, March 2, 2016 at 1:04:55 AM UTC+5:30, Julio Guerra wrote:
>>
>> After all these years, this excellent question is still not clearly
>> answered... This point of the language makes this design decision really
>> unclear when beginning. Because method calls on method receivers are
>> statically resolved, while method calls on arguments whose types are
>> interfaces are dynamically dispatched and statically checked (compile-time
>> error when the expected interface is not implemented). So this question
>> really needs more attention and a more straightforward design rule. Mix in
>> type embedding and you end up with a mental node ><
>>
> --
> 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.

[go-nuts] GO Developer Job Opportunity - CINCINNATI

[Abby Recker]

Hi everyone!

One of my clients here in Cincinnati is looking for 3 GO Developers - high 
pay, great benefits, cool team. This position is a year long contract, 
which will then be converted to permanent. Please call/email Francesca or 
Andrew at my office for more details if you are interested at 513-578-6900. 
We are having trouble finding developers locally with GO experience - no 
minimum or maximum experience required. 



-- 
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] cross compile windows from linux failed with -H=windowsgui

[xrfang]

I use Kubuntu 16.10, when compile a project over to windows, I get this 
error:

crosscall2: adddynsym: unsupported binary format 
_cgo_panic: adddynsym: unsupported binary format 
_cgo_topofstack: adddynsym: unsupported binary format 
adddynlib: unsupported binary format 
adddynlib: unsupported binary format

The command I used to compile was:

export GOOS=windows
go build -ldflags "-H=windowsgui" -o  main.go

 if I remove "-H=windowsgui" the problem is gone.  What I wanted is to get 
rid of console window while run my program on Windows.  I found the 
solution here:

http://stackoverflow.com/questions/23250505/how-do-i-create-an-executable-from-golang-that-doesnt-open-a-command-cmd-wind

Unfortunately it didn't work.  Any ideas?

Thanks a lot.

xrfang

-- 
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: thread safety of map when each goroutine access a different key

[Marvin Stenger]

Why do you even use a shared map, if you only use distinct keys per 
goroutine. There probably is a better pattern for your use case.

Am Montag, 13. März 2017 07:39:59 UTC+1 schrieb Albert Tedja:
>
> Hello,
>
> I know map itself isn't threadsafe, but I am just wondering how threadsafe 
> it is if you can be absolutely sure that each goroutine accesses a 
> different key in the map.
> Say, goroutine 1 accesses mymap["1"]
> and goroutine 2 accesses mymap["2"] and so on.
>
> Thank you in advance.
>

-- 
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 pass value in nested template if possible?

[mhhcbon]

template func takes an extra argument to send data,

{{ template "inner" .}}{{end}}


I can t find a link to doc for that matter :s

nothing here
https://golang.org/pkg/text/template/#hdr-Nested_template_definitions

or here 
https://golang.org/pkg/text/template/#hdr-Functions

The only related example is in
https://golang.org/pkg/text/template/#hdr-Actions

{{template "name"}}
The template with the specified name is executed with nil data.

{{template "name" pipeline}}
The template with the specified name is executed with dot set
to the value of the pipeline.


Maybe the 2nd desc is not so obvious for new comers.
Maybe it is a bit lost in the middle of everything else.
not sure.

On Monday, March 13, 2017 at 12:28:21 PM UTC+1, Uvelichitel wrote:
>
> How to pass value in nested template if possible? 
> Template package has terse documentation and not much examples. 
> In brief I want to 
>  if err := template.Must(template.New("").Parse(`{{ define "inner" 
> }}{{ . }}{{end}}{{ define "outer" }}{{ template 
> "inner"}}{{end}}`)).ExecuteTemplate(os.Stdout, "outer", "foo"); err != nil 
> { 
>  print(err) 
>  } 
> which write 
>   
> instead of desired "foo". Error isn't spawned. Am I missing something? 
> Cheers. 
> __ 
> Ilya 
>

-- 
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] How to pass value in nested template if possible?

[Ilya Kostarev]

How to pass value in nested template if possible?
Template package has terse documentation and not much examples.
In brief I want to
if err := template.Must(template.New("").Parse(`{{ define "inner" 
}}{{ . }}{{end}}{{ define "outer" }}{{ template 
"inner"}}{{end}}`)).ExecuteTemplate(os.Stdout, "outer", "foo"); err != nil {

print(err)
}
which write

instead of desired "foo". Error isn't spawned. Am I missing something?
Cheers.
__
Ilya

--
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: thread safety of map when each goroutine access a different key

[Haddock]

Forgot to mention that ConcurrentHashMap has 256 segments (if I remember 
right). So you can have 256 map operations going on concurrently.

Am Montag, 13. März 2017 11:58:15 UTC+1 schrieb Haddock:
>
> You can download Java (JDK5 or later) and have a look at class 
> ConcurrentHashMap. This will give you a blueprint about how this can be 
> implemented using segments. After segment lookup for a given hash code only 
> the segment needs to be locked, but not any more the entire map. Note, that 
> you still have to lock the entire map when you do traversals. So it is 
> recommend to avoid traversals where possible.
>
> Am Montag, 13. März 2017 07:39:59 UTC+1 schrieb Albert Tedja:
>>
>> Hello,
>>
>> I know map itself isn't threadsafe, but I am just wondering how 
>> threadsafe it is if you can be absolutely sure that each goroutine accesses 
>> a different key in the map.
>> Say, goroutine 1 accesses mymap["1"]
>> and goroutine 2 accesses mymap["2"] and so on.
>>
>> Thank you in advance.
>>
>

-- 
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: thread safety of map when each goroutine access a different key

[Haddock]

You can download Java (JDK5 or later) and have a look at class 
ConcurrentHashMap. This will give you a blueprint about how this can be 
implemented using segments. After segment lookup for a given hash code only 
the segment needs to be locked, but not any more the entire map. Note, that 
you still have to lock the entire map when you do traversals. So it is 
recommend to avoid traversals where possible.

Am Montag, 13. März 2017 07:39:59 UTC+1 schrieb Albert Tedja:
>
> Hello,
>
> I know map itself isn't threadsafe, but I am just wondering how threadsafe 
> it is if you can be absolutely sure that each goroutine accesses a 
> different key in the map.
> Say, goroutine 1 accesses mymap["1"]
> and goroutine 2 accesses mymap["2"] and so on.
>
> Thank you in advance.
>

-- 
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] thread safety of map when each goroutine access a different key

[Albert Tedja]

Great. Thanks! Looks like it's just better if I return a struct if these 
goroutines are operating independently anyway.

On Monday, March 13, 2017 at 12:20:42 AM UTC-7, Konstantin Khomoutov wrote:
>
> On Sun, 12 Mar 2017 23:39:59 -0700 (PDT) 
> Albert Tedja  wrote: 
>
> > I know map itself isn't threadsafe, but I am just wondering how 
> > threadsafe it is if you can be absolutely sure that each goroutine 
> > accesses a different key in the map. 
> > Say, goroutine 1 accesses mymap["1"] 
> > and goroutine 2 accesses mymap["2"] and so on. 
>
> Contrary to a struct type, values of which are just pretty "static" 
> pieces of memory, where the compiler known an offset (in bytes) of each 
> field relative to the value's starting address, a value of a map type 
> contains a pointer to an intricate *dynamic* thing, where each insertion 
> of a new value might lead to drastic changes like moving of unrelated 
> values already stored in that map in memory. 
>
> Because of this, the only thing guaranteed to work concurrently with Go 
> maps is reading them.  So if your goroutites only read a map value, 
> then it does not matter which values they read.  If they write to a map 
> (that is, insert into it or delete from it), you must synchronize the 
> accesses to that no write even happens concurrently with either another 
> write or a read. 
>
> On the other hand, consider that if you store in the map pointers to 
> actual values which are themselves not stored in a map, then, after 
> reading such a pointer from a map, you're free to deal with the value 
> it points to concurrently with map modification.  That's because in 
> this scenario, the only values stored by the map are pointers, and 
> hence insertion to the map and deletions from it might move those 
> pointers in memory but not the values they point to. 
>

-- 
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: What happens when appending to a slice exceeds the backing capacity?

[st ov]

just a thought experiment :)


On Monday, March 13, 2017 at 12:20:57 AM UTC-7, Jan Mercl wrote:
>
> On Mon, Mar 13, 2017 at 8:05 AM st ov  
> wrote:
>
> > I know it can be accessed the question relates to this
> > 
> http://stackoverflow.com/questions/36706843/how-to-get-the-underlying-array-of-a-slice-in-go
>
> Let me ask what do you need the backing array for which cannot be done 
> using the slice value? Using the slice value you can read the backing 
> array, write to it, take address of its element and slice the array. What 
> use case is not covered by those operations?
>
> -- 
>
> -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.

Re: [go-nuts] Re: What happens when appending to a slice exceeds the backing capacity?

[Konstantin Khomoutov]

On Sun, 12 Mar 2017 17:36:53 -0700 (PDT)
st ov  wrote:

> > > What happens when appending to a slice exceeds the backing
> > > capacity?
> >
> > If the capacity of s is not large enough to fit the additional
> > values, append allocates a new, sufficiently large underlying array
> > that fits both the existing slice elements and the additional
> > values. Otherwise, append re-uses the underlying array.
> >
> > src: https://golang.org/ref/spec#Appending_and_copying_slices
> >
> anyway to get a reference to that new array without using reflect?

But this kind of "reverses" the whole idea of a slice which is a view
into the underlying array -- into any location within its data span.

If you need to have something like this, have a "master" slice
referencing the whole array from its beginning, and always use this
slice for appending.  The address of the backing array is then the
address of the first slice's element.
That is,

  s := make([]byte, 100)
  s = append(s, 100)
  p := [0] // The address of the backing array.

Note that if you have other slices pointing to the same array such a
master slice uses, you'll need to "reslice" them after appending to the
master slice.

-- 
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: What happens when appending to a slice exceeds the backing capacity?

[Jan Mercl]

On Mon, Mar 13, 2017 at 8:05 AM st ov  wrote:

> I know it can be accessed the question relates to this
>
http://stackoverflow.com/questions/36706843/how-to-get-the-underlying-array-of-a-slice-in-go

Let me ask what do you need the backing array for which cannot be done
using the slice value? Using the slice value you can read the backing
array, write to it, take address of its element and slice the array. What
use case is not covered by those operations?

-- 

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

Re: [go-nuts] thread safety of map when each goroutine access a different key

[Konstantin Khomoutov]

On Sun, 12 Mar 2017 23:39:59 -0700 (PDT)
Albert Tedja  wrote:

> I know map itself isn't threadsafe, but I am just wondering how
> threadsafe it is if you can be absolutely sure that each goroutine
> accesses a different key in the map.
> Say, goroutine 1 accesses mymap["1"]
> and goroutine 2 accesses mymap["2"] and so on.

Contrary to a struct type, values of which are just pretty "static"
pieces of memory, where the compiler known an offset (in bytes) of each
field relative to the value's starting address, a value of a map type
contains a pointer to an intricate *dynamic* thing, where each insertion
of a new value might lead to drastic changes like moving of unrelated
values already stored in that map in memory.

Because of this, the only thing guaranteed to work concurrently with Go
maps is reading them.  So if your goroutites only read a map value,
then it does not matter which values they read.  If they write to a map
(that is, insert into it or delete from it), you must synchronize the
accesses to that no write even happens concurrently with either another
write or a read.

On the other hand, consider that if you store in the map pointers to
actual values which are themselves not stored in a map, then, after
reading such a pointer from a map, you're free to deal with the value
it points to concurrently with map modification.  That's because in
this scenario, the only values stored by the map are pointers, and
hence insertion to the map and deletions from it might move those
pointers in memory but not the values they point to.

-- 
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: What happens when appending to a slice exceeds the backing capacity?

[st ov]

I know it can be accessed the question relates to this
http://stackoverflow.com/questions/36706843/how-to-get-the-underlying-array-of-a-slice-in-go



On Sunday, March 12, 2017 at 10:01:11 PM UTC-7, Jan Mercl wrote:
>
> What is a reference to the array? To access the array use the slice itself 
> as usual, no reflect needed.
>
> On Mon, Mar 13, 2017, 01:37 st ov  wrote:
>
>> Thanks!
>> anyway to get a reference to that new array without using reflect?
>>
>>
>>
>>
>> On Sunday, March 12, 2017 at 12:13:03 PM UTC-7, Jan Mercl wrote:
>>>
>>> On Sunday, March 12, 2017 at 11:49:33 AM UTC-7, st ov wrote:
>>>
>>> > What happens when appending to a slice exceeds the backing capacity?
>>>
>>> If the capacity of s is not large enough to fit the additional values, 
>>> append allocates a new, sufficiently large underlying array that fits both 
>>> the existing slice elements and the additional values. Otherwise, append 
>>> re-uses the underlying array.
>>>
>>> src: https://golang.org/ref/spec#Appending_and_copying_slices
>>>
>>> -- 
>>>
>>> -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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> -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] thread safety of map when each goroutine access a different key

[Albert Tedja]

Hello,

I know map itself isn't threadsafe, but I am just wondering how threadsafe 
it is if you can be absolutely sure that each goroutine accesses a 
different key in the map.
Say, goroutine 1 accesses mymap["1"]
and goroutine 2 accesses mymap["2"] and so on.

Thank you in advance.

-- 
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] json.Unmarshal and modifications to copies of structs

[Nigel Tao]

On Mon, Mar 13, 2017 at 9:10 AM, george.robinson via golang-nuts
 wrote:
> Can someone explain to me how this prints "test world" twice? I had expected
> to see "test hello" and "test world".
>
> https://play.golang.org/p/E7CRQNE6oT

m1 is not a pointer, but m1.S is a slice, and a slice is essentially a
pointer and a length (and a capacity, but that's not relevant here).
Read https://blog.golang.org/go-slices-usage-and-internals for more
details.

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