Re: [go-nuts] What 5 things does Go need in 2017?

[Russel Winder]

On Sun, 2016-09-11 at 18:58 -0700, Dave Cheney wrote:
> An 'official' deb/apt/yum repo for Go would be much 
> appreciated, https://github.com/golang/go/issues/10965
> 

Go stuff is packaged for Debian and Fedora, they are the official
Debian and Fedora packages. Any other packages in any other repository
would be unofficial!

Given this is the case what is the benefit of another repository?
Wouldn't this just lead to replication of effort or decay of the
official packages.

Many people running servers will only use the official repositories, so
an extra repository would not be used. Having Go packages in the
official repository is good for Go. 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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


signature.asc
Description: This is a digitally signed message part

Re: [go-nuts] What 5 things does Go need in 2017?

[Dave Cheney]

Distros are always out of date, sometimes hilariously. Official in my parlance 
means "from the go team"

> On 12 Sep 2016, at 17:06, Russel Winder  wrote:
> 
>> On Sun, 2016-09-11 at 18:58 -0700, Dave Cheney wrote:
>> An 'official' deb/apt/yum repo for Go would be much 
>> appreciated, https://github.com/golang/go/issues/10965
> 
> Go stuff is packaged for Debian and Fedora, they are the official
> Debian and Fedora packages. Any other packages in any other repository
> would be unofficial!
> 
> Given this is the case what is the benefit of another repository?
> Wouldn't this just lead to replication of effort or decay of the
> official packages.
> 
> Many people running servers will only use the official repositories, so
> an extra repository would not be used. Having Go packages in the
> official repository is good for Go. 
> 
> -- 
> Russel.
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: [go-nuts] What 5 things does Go need in 2017?

[Russel Winder]

On Mon, 2016-09-12 at 17:21 +1000, Dave Cheney wrote:
> Distros are always out of date, sometimes hilariously. Official in my
> parlance means "from the go team"

If the official distro repository is not as up-to-date as is should be
then fix it, either by helping the current packagers or by becoming the
official packagers. To ignore the official repository and yet replicate
exactly the same work seems significantly less than optimal.

Debian Sid and Fedora Rawhide seem fairly up to date, at least for core
Go stuff.

Though Fedora packaging of Go is somewhat at odds with the packaging of
GCCGo, and indeed does need fixing.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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


signature.asc
Description: This is a digitally signed message part

Re: [go-nuts] What 5 things does Go need in 2017?

[Dave Cheney]

Ubuntu 12.04 LTS ships with Go 1.0.
Ubuntu 14.04 LTS ships with Go 1.2
Ubuntu 16.04 LTS ships with Go 1.6 (I hope)

None of the LTS versions of Ubuntu ship with a supporter version of Go. This is 
a policy decision by Ubuntu. 

What Go needs is an official repo, just like Chrome has.

> On 12 Sep 2016, at 19:41, Russel Winder  wrote:
> 
>> On Mon, 2016-09-12 at 17:21 +1000, Dave Cheney wrote:
>> Distros are always out of date, sometimes hilariously. Official in my
>> parlance means "from the go team"
> 
> If the official distro repository is not as up-to-date as is should be
> then fix it, either by helping the current packagers or by becoming the
> official packagers. To ignore the official repository and yet replicate
> exactly the same work seems significantly less than optimal.
> 
> Debian Sid and Fedora Rawhide seem fairly up to date, at least for core
> Go stuff.
> 
> Though Fedora packaging of Go is somewhat at odds with the packaging of
> GCCGo, and indeed does need fixing.
> 
> -- 
> Russel.
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: [go-nuts] What 5 things does Go need in 2017?

[Henrik Johansson]

Some distros suffer less from this. Arch is perfectly up2date in line with
its rolling approach.

I agree with Dave that a supported repo is very nice.
It is not unusual for companies to lag behind even on LTS installs but
still having a need for updates of a particular software.



mån 12 sep. 2016 kl 11:53 skrev Dave Cheney :

> Ubuntu 12.04 LTS ships with Go 1.0.
> Ubuntu 14.04 LTS ships with Go 1.2
> Ubuntu 16.04 LTS ships with Go 1.6 (I hope)
>
> None of the LTS versions of Ubuntu ship with a supporter version of Go.
> This is a policy decision by Ubuntu.
>
> What Go needs is an official repo, just like Chrome has.
>
> > On 12 Sep 2016, at 19:41, Russel Winder  wrote:
> >
> >> On Mon, 2016-09-12 at 17:21 +1000, Dave Cheney wrote:
> >> Distros are always out of date, sometimes hilariously. Official in my
> >> parlance means "from the go team"
> >
> > If the official distro repository is not as up-to-date as is should be
> > then fix it, either by helping the current packagers or by becoming the
> > official packagers. To ignore the official repository and yet replicate
> > exactly the same work seems significantly less than optimal.
> >
> > Debian Sid and Fedora Rawhide seem fairly up to date, at least for core
> > Go stuff.
> >
> > Though Fedora packaging of Go is somewhat at odds with the packaging of
> > GCCGo, and indeed does need fixing.
> >
> > --
> > Russel.
> >
> =
> > Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> --
> 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] A compatible extension to the for construct

[Lucio De Re]

On 9/12/16, Ian Lance Taylor  wrote:
>
> My guess as to what this means is that it is precisely equivalent to
> for x++; x < n; x++ {
>
I can't argue with your analysis, it seems flawless and I didn't spot that.
I'm going to go back where I thought continue would be the only
sensible option and see if your alternative still (too many things in
my head at the same time).

Ian, thanks.
-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435

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

Re: [go-nuts] What 5 things does Go need in 2017?

[Tim Hawkins]

Especialy since the distros often lag the release cycle by quite a bit.
1.7.x is not due on Fedora until release 25, which is several months away.

On 12 Sep 2016 09:58, "Dave Cheney"  wrote:

An 'official' deb/apt/yum repo for Go would be much appreciated,
https://github.com/golang/go/issues/10965


On Monday, 12 September 2016 11:44:06 UTC+10, Mark Richman wrote:
>
> Ian,
>
> I would definitely be interested in triage, backlog refinement, etc. Are
> there product owners designated for each functional area? I could start by
> making sure new issues are at least assigned to the correct PO for
> prioritization.
>
> With respect to packaging, I'm aware of the current effort underway. In my
> day job, I'm responsible for packaging -- both our internal library
> packages, and our customer-facing product packages. This includes the
> tooling around the packages, the delivery mechanism(s), web front end for
> administration, etc. I am admittedly a Go novice, but I think this is a
> relatively language-agnostic discipline. However, I know of the vendoring
> quirks and lack of portable libraries (i.e. dll or jar style references).
>
> If you think these are areas I could be of service, feel free to follow up
> with me offline if you like.
>
> Thanks,
> Mark
> http://markrichman.com
> mark [at] markrichman.com
>
> On Sunday, September 11, 2016 at 1:55:52 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Sun, Sep 11, 2016 at 6:43 AM, Mark Richman 
>> wrote:
>> >
>> > I'm somewhat new to the community, and seek to understand its
>> challenges
>> > better. I'm also looking for opportunities to contribute.
>> >
>> > To that end, what 5 things does Go need in 2017?
>> >
>> > For example: language features, tooling, advocacy, community, platform
>> > support, etc.
>>
>> Thanks for offering.  There are many open issues at
>> https://golang.org/issue.  Issue triage is an ongoing consumer of
>> time.
>>
>> Personally I think our biggest open issues relate to packaging,
>> especially managing third party packages.  There is an active effort
>> to sort this out.
>>
>> Unfortunately helping with those does require some familiarity with
>> the language and the community.
>>
>> The documentation can always be improved.
>>
>> This is just off the top of my head, others may have other suggestions.
>>
>> 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.

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

Re: [go-nuts] What 5 things does Go need in 2017?

[Tim Hawkins]

But fedora for example is stuck on 1.6 until fedora 25 is released,  its a
simular situation to elasticsearch, distro version is old, and has severe
limitations,  nobody in thier right mind would install from there. Far far
safer to use the official version fom the elastic.co site. The same is true
for mongodb.

Developers may like to have the option to track current.

On 12 Sep 2016 15:06, "Russel Winder"  wrote:

On Sun, 2016-09-11 at 18:58 -0700, Dave Cheney wrote:
> An 'official' deb/apt/yum repo for Go would be much
> appreciated, https://github.com/golang/go/issues/10965
>

Go stuff is packaged for Debian and Fedora, they are the official
Debian and Fedora packages. Any other packages in any other repository
would be unofficial!

Given this is the case what is the benefit of another repository?
Wouldn't this just lead to replication of effort or decay of the
official packages.

Many people running servers will only use the official repositories, so
an extra repository would not be used. Having Go packages in the
official repository is good for Go.

--
Russel.

=
Dr Russel Winder  t: +44 20 7585 2200   voip:
sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

--
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] What 5 things does Go need in 2017?

[Michael Hudson-Doyle]

On 12 September 2016 at 21:53, Dave Cheney  wrote:

> Ubuntu 12.04 LTS ships with Go 1.0.
> Ubuntu 14.04 LTS ships with Go 1.2
> Ubuntu 16.04 LTS ships with Go 1.6 (I hope)
>

Yeah, 1.6 got into 16.04.


> None of the LTS versions of Ubuntu ship with a supporter version of Go.
> This is a policy decision by Ubuntu.
>

Indeed. Updating whole new versions of things into released versions just
isn't how things are expected to work. Things are changing here (snaps,
etc) but that's where we are.


> What Go needs is an official repo, just like Chrome has.


In the mean time, there's
https://code.launchpad.net/~gophers/+archive/ubuntu/archive for your Go 1.X
versions on Ubuntu (and probably Debian, but not tested) needs.

Cheers,
mwh


> > On 12 Sep 2016, at 19:41, Russel Winder  wrote:
> >
> >> On Mon, 2016-09-12 at 17:21 +1000, Dave Cheney wrote:
> >> Distros are always out of date, sometimes hilariously. Official in my
> >> parlance means "from the go team"
> >
> > If the official distro repository is not as up-to-date as is should be
> > then fix it, either by helping the current packagers or by becoming the
> > official packagers. To ignore the official repository and yet replicate
> > exactly the same work seems significantly less than optimal.
> >
> > Debian Sid and Fedora Rawhide seem fairly up to date, at least for core
> > Go stuff.
> >
> > Though Fedora packaging of Go is somewhat at odds with the packaging of
> > GCCGo, and indeed does need fixing.
> >
> > --
> > Russel.
> > 
> =
> > Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> --
> 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] What 5 things does Go need in 2017?

[Micky]

Go doesn't need anything. You just need to write more code ;)

On Sun, Sep 11, 2016 at 6:43 PM, Mark Richman  wrote:
> I'm somewhat new to the community, and seek to understand its challenges
> better. I'm also looking for opportunities to contribute.
>
> To that end, what 5 things does Go need in 2017?
>
> For example: language features, tooling, advocacy, community, platform
> support, etc.
>
> --
> 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] What 5 things does Go need in 2017?

[Nathan Fisher]

s/hilarious/sad/

If I had a pound for every time I've had to create custom packages/repos
for various languages, libraries and apps... I could buy myself a fancy
dinner or two.

Mon, 12 Sep 2016 at 08:21, Dave Cheney  wrote:

> Distros are always out of date, sometimes hilariously. Official in my
> parlance means "from the go team"
>
> > On 12 Sep 2016, at 17:06, Russel Winder  wrote:
> >
> >> On Sun, 2016-09-11 at 18:58 -0700, Dave Cheney wrote:
> >> An 'official' deb/apt/yum repo for Go would be much
> >> appreciated, https://github.com/golang/go/issues/10965
> >
> > Go stuff is packaged for Debian and Fedora, they are the official
> > Debian and Fedora packages. Any other packages in any other repository
> > would be unofficial!
> >
> > Given this is the case what is the benefit of another repository?
> > Wouldn't this just lead to replication of effort or decay of the
> > official packages.
> >
> > Many people running servers will only use the official repositories, so
> > an extra repository would not be used. Having Go packages in the
> > official repository is good for Go.
> >
> > --
> > Russel.
> >
> =
> > Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> --
> 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.
>
-- 
- from my thumbs to yours

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Tamás Gulácsi]

2016. szeptember 12., hétfő 7:28:26 UTC+2 időpontban davidmi...@gmail.com a 
következőt írta:
>
> *I have two Golang questions that I hope someone could help me out with.*
>
>
> *1) Am I misunderstanding Golang maps?*
>
>
> *I'm trying to translate a project from PHP to Golang for the websockets 
> and the concurrency. *
>
>
> *However, I can't do this.*
>
>
> *  var MyArray [string]string*
>
>
> *Instead, I have to do this.*
>
>
> *  var MyMap map[string]string*
>
>
> *However, since the same array (map) would be used at least once for each 
> call to the Golang code from the Front End, which occurs any time a user 
> sends data to the Back End, I have been led to believe that I would have to 
> lock and unlock the map for each use. Wouldn't that essentially break 
> concurrency (or at least eliminate its benefits??? No other user's function 
> could use this map until the current user's function is done with it. I'd 
> be back to "single threaded" again (concurrently speaking). This would 
> defeat much of the point in my switching the project from PHP to Golang. To 
> maintain concurrency without blocking other users, one would have to avoid 
> using maps. Arrays (maps) are central to programming. How does anyone get 
> by in Golang without using Maps?*
>
>
> *For example, if I do the following.*
>
>
> *func MyFunc (whatever) *map[string]string *{*
>
>
>  var MyMap map[string]string
>
>
> * // Do something with the map*
>
>
> * return MyMap*
>
>
> *}*
>
>
> *func CallingFunction (whatever) {*
>
>
> * MyReturnedMap := go  MyFunc(whatever)*
>
>
> *}*
>
>
> *.would I have to lock and unlock the map or are two separate 
> instances of the map declared?*
>
>
> *Again, am** I misunderstanding Golang maps?*
>
>
>
Use the lock for as short time as possible: only around get and set access! 
Maybe even:
  mMu.RLock()
  v, ok := m[k]
  mMu.RUnlock()

  if ok {...
  if v ...

  mMu.Lock()
  m[k] = v
  mMu.Unlock()

By the way your example does not use the map concurrently, as *MyFunc* will 
return a new map.
And your code won't even compile! (no "v := go f()" syntax in go).



 

> *2) Also, how would one build a multidimensional array with a string index 
> (or even a map of maps) for something like a large file directory where the 
> number of files, folders and levels are unknown at the outset (without 
> repeatedly using the append function that apparently uses memory on an 
> exponential scale of 2^x)? I've figured out how to do 
> map[string]map[string]map[string]string, but one would have to know how 
> many levels there would be, in advance, to be able to use something like 
> that. Also, when I've tried that, I can't put a string on any level except 
> for the last one, since the only data type that any level other than the 
> last one will accept is another map! What if the map turns out to be only 
> three levels deep for one path and five levels deep for another path?** I've 
> tried the following, which I found online, but I can't dynamically add any 
> new folders to the directory with any kind of ease. It seems that 
> initializing the struct is the only way to get data into the struct without 
> declaring a new struct for every manipulation!*
>
>
> *(Below code from 
> **http://stackoverflow.com/questions/19080116/golang-tree-like-solution-for-filesystem
>  
> )*
>
>
> package Websocket
>
> import "fmt"
>
> type File struct {
>Name string
> }
>
> type Folder struct {
>Namestring
>Files   []File
>Folders []Folder
> }
>
> func main() {
>root := Folder{
>   Name: "Root",
>   Files: []File{
>  {"One"},
>  {"Two"},
>   },
>   Folders: []Folder{
>  {
> Name: "Empty",
>  },
>   },
>}
>fmt.Printf("Root %#v\n", root)
> }
>
>
> *Given the above, how would i now add another folder to the directory tree. 
> Among many other variations, I've tried the following.*
>
>
> *root.Folders[0].Name = "MyFirstFolder"*
>
>
> *.but nothing I have tried has worked.*
>
>
> *What I've been trying to do is set up an array that looks like the 
> following.*
>
>
> *MyArray["Number of Sub Items"] = 6*
>
> *MyArray["Type of Sub Items"] = "Folders"*
>
> *MyArray[0] = "Folder 1"*
>
> *MyArray[1]** = "Folder 2"*
>
> *MyArray[2]** = "Folder 3"*
>
> *MyArray[3]** = "Folder 4"*
>
> *MyArray[4]** = "Folder 5"*
>
> *MyArray[6]** = "Folder 6"*
>
>
> *MyArray[3]**["Number of Sub Items"]** = 3*
>
> *MyArray["Type of Sub Items"] = "Folders"*
>
> *MyArray[3][0] = "Folder 1"*
>
> *MyArray[3][1]** = "Folder 2"*
>
> *MyArray[3][2]** = "Folder 3"*
>
>
> *Note that this problem is not exclusive to directory structure. Using 
> directory structure is just a simple way to descr

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

[Markus Zimmermann]

Hi gophers!

I am wondering why we have a "declared and not used" compile error for 
variables [https://play.golang.org/p/KLzHVO5L7q] but not for constants 
[https://play.golang.org/p/JG9dSa_VKg]? I am sure there is some rational 
decision behind this that I have missed, but my Google-fu is just not 
strong enough to find an answer.

Cheers,
Markus

-- 
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] Why is there no " declared and not used" compile error?

[Sjon Kosse]

Hello,

Const values can be accesed still by reflection in a reasonable manner. This 
question has come by quite a few times before on the mailing list, better 
explanations should be easy to find.

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

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

[adonovan via golang-nuts]

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

I suspect the answer is: because unused constants and types cost nothing at 
run time.  It's not that simple, of course, because constant and type 
declarations may be the only uses of an import of a package whose 
initialization has some cost; but this is quite marginal.

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

[sqweek E.]

Ok so after getting away with using maps to share data between threads for 
a lng time, I've finally seen the light and accepted that this is not 
safe.

In my case the threads in question are a painter thread and a 
mouse/keyboard event processing thread. They want to share data because 
obviously a mouse hitbox needs to match what is being drawn on the screen, 
unless you're going for a ux that drives your users insane :)

Anyway as I said it's not safe to concurrently read and write a map; 
eventually this will result in a panic. Yet I'm stuck with a codebase that 
does this all over the place. So despite hating the thought of blocking 
either thread I did what any honest java-for-dayjob coder would do and 
resigned myself to hiding the maps behind an RWLock.

Of course things are never that simple; adding locks to code that was not 
designed with them in mind is a good way to introduce deadlocks 
(particularly of the 
recursive-read-lock-while-other-thread-is-acquiring-write-lock variety). I 
made another change to address recursive lock acquisition, realised I 
missed a couple of shared maps and suddenly locking code was strewn all 
over my program; I got to the point of acquiring a read-lock every time the 
mouse moved before giving up in disgust. I thought about using an actual 
concurrent map, but giving up the builtin map's ease of use and 
well-typedness didn't thrill me. After some thought I came up with an 
alternative approach...

TLDR; My shared structures are *mostly* read-only, in the sense that read 
operations are much more common than writes. I decided I can afford to 
change the writes so instead of updating the maps in place, they (a) take a 
copy of the current map (b) update the copy and (c) replace the reference 
to the original map (held in a struct field) with the updated copy.

I was pretty chuffed with this approach. It's clearly not the most 
efficient but it allowed me to solve the panic without risking deadlock. 
I'd be surprised if I'm the first person to come up with it, but I haven't 
seen it mentioned - the majority of advice seems to be "use an RWLock" or 
"use a concurrent map".

I'm interested in understanding how safe/portable the approach is. I'm no 
expert on ARM/memory barriers but my understanding is that without an 
explicit sync/channel operation there's no guarantee another thread will 
see a change (in this case, the new map instance). In my case I have a 
channel based notification mechanism running alongside to wake up the 
painter thread when something changes, I'm just not sure what memory 
changes that is guaranteed to communicate.

I also just wanted to share the approach and see how other people feel 
about it. It reminds me a bit of a double-buffering - writing to the 
backbuffer and then swapping it into action.

-sqweek

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

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

[Peter Bourgon]

How are you replacing the reference to the original map? If you're
just using plain assignment e.g. x.myMap = newMap then that's not
safe. You could use sync/atomic.Value if you always made sure to do
map reads via the Load method.

On Mon, Sep 12, 2016 at 5:04 PM, sqweek E.  wrote:
> Ok so after getting away with using maps to share data between threads for a
> lng time, I've finally seen the light and accepted that this is not
> safe.
>
> In my case the threads in question are a painter thread and a mouse/keyboard
> event processing thread. They want to share data because obviously a mouse
> hitbox needs to match what is being drawn on the screen, unless you're going
> for a ux that drives your users insane :)
>
> Anyway as I said it's not safe to concurrently read and write a map;
> eventually this will result in a panic. Yet I'm stuck with a codebase that
> does this all over the place. So despite hating the thought of blocking
> either thread I did what any honest java-for-dayjob coder would do and
> resigned myself to hiding the maps behind an RWLock.
>
> Of course things are never that simple; adding locks to code that was not
> designed with them in mind is a good way to introduce deadlocks
> (particularly of the
> recursive-read-lock-while-other-thread-is-acquiring-write-lock variety). I
> made another change to address recursive lock acquisition, realised I missed
> a couple of shared maps and suddenly locking code was strewn all over my
> program; I got to the point of acquiring a read-lock every time the mouse
> moved before giving up in disgust. I thought about using an actual
> concurrent map, but giving up the builtin map's ease of use and
> well-typedness didn't thrill me. After some thought I came up with an
> alternative approach...
>
> TLDR; My shared structures are *mostly* read-only, in the sense that read
> operations are much more common than writes. I decided I can afford to
> change the writes so instead of updating the maps in place, they (a) take a
> copy of the current map (b) update the copy and (c) replace the reference to
> the original map (held in a struct field) with the updated copy.
>
> I was pretty chuffed with this approach. It's clearly not the most efficient
> but it allowed me to solve the panic without risking deadlock. I'd be
> surprised if I'm the first person to come up with it, but I haven't seen it
> mentioned - the majority of advice seems to be "use an RWLock" or "use a
> concurrent map".
>
> I'm interested in understanding how safe/portable the approach is. I'm no
> expert on ARM/memory barriers but my understanding is that without an
> explicit sync/channel operation there's no guarantee another thread will see
> a change (in this case, the new map instance). In my case I have a channel
> based notification mechanism running alongside to wake up the painter thread
> when something changes, I'm just not sure what memory changes that is
> guaranteed to communicate.
>
> I also just wanted to share the approach and see how other people feel about
> it. It reminds me a bit of a double-buffering - writing to the backbuffer
> and then swapping it into action.
>
> -sqweek
>
> --
> 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] Re: Multiple-reader single-writer map access - is this lockless workaround safe?

[pierre . curto]

You might be interested in this:
https://golang.org/pkg/sync/atomic/#Value


Le lundi 12 septembre 2016 17:04:39 UTC+2, sqweek E. a écrit :
>
> Ok so after getting away with using maps to share data between threads for 
> a lng time, I've finally seen the light and accepted that this is not 
> safe.
>
> In my case the threads in question are a painter thread and a 
> mouse/keyboard event processing thread. They want to share data because 
> obviously a mouse hitbox needs to match what is being drawn on the screen, 
> unless you're going for a ux that drives your users insane :)
>
> Anyway as I said it's not safe to concurrently read and write a map; 
> eventually this will result in a panic. Yet I'm stuck with a codebase that 
> does this all over the place. So despite hating the thought of blocking 
> either thread I did what any honest java-for-dayjob coder would do and 
> resigned myself to hiding the maps behind an RWLock.
>
> Of course things are never that simple; adding locks to code that was not 
> designed with them in mind is a good way to introduce deadlocks 
> (particularly of the 
> recursive-read-lock-while-other-thread-is-acquiring-write-lock variety). I 
> made another change to address recursive lock acquisition, realised I 
> missed a couple of shared maps and suddenly locking code was strewn all 
> over my program; I got to the point of acquiring a read-lock every time the 
> mouse moved before giving up in disgust. I thought about using an actual 
> concurrent map, but giving up the builtin map's ease of use and 
> well-typedness didn't thrill me. After some thought I came up with an 
> alternative approach...
>
> TLDR; My shared structures are *mostly* read-only, in the sense that read 
> operations are much more common than writes. I decided I can afford to 
> change the writes so instead of updating the maps in place, they (a) take a 
> copy of the current map (b) update the copy and (c) replace the reference 
> to the original map (held in a struct field) with the updated copy.
>
> I was pretty chuffed with this approach. It's clearly not the most 
> efficient but it allowed me to solve the panic without risking deadlock. 
> I'd be surprised if I'm the first person to come up with it, but I haven't 
> seen it mentioned - the majority of advice seems to be "use an RWLock" or 
> "use a concurrent map".
>
> I'm interested in understanding how safe/portable the approach is. I'm no 
> expert on ARM/memory barriers but my understanding is that without an 
> explicit sync/channel operation there's no guarantee another thread will 
> see a change (in this case, the new map instance). In my case I have a 
> channel based notification mechanism running alongside to wake up the 
> painter thread when something changes, I'm just not sure what memory 
> changes that is guaranteed to communicate.
>
> I also just wanted to share the approach and see how other people feel 
> about it. It reminds me a bit of a double-buffering - writing to the 
> backbuffer and then swapping it into action.
>
> -sqweek
>

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

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

[sqweek E.]

Yes, through plain assignment. What problems arise from that?

On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote:
>
> How are you replacing the reference to the original map? If you're 
> just using plain assignment e.g. x.myMap = newMap then that's not 
> safe. You could use sync/atomic.Value if you always made sure to do 
> map reads via the Load method. 
>
> On Mon, Sep 12, 2016 at 5:04 PM, sqweek E. > 
> wrote: 
> > instead of updating the maps in place, they (a) take a 
> > copy of the current map (b) update the copy and (c) replace the 
> reference to 
> > the original map (held in a struct field) with the updated copy. 
>
>

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

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

[Caleb Spare]

That's still a data race. Are you using the race detector?

On Mon, Sep 12, 2016 at 9:04 AM, sqweek E.  wrote:
> Yes, through plain assignment. What problems arise from that?
>
> On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote:
>>
>> How are you replacing the reference to the original map? If you're
>> just using plain assignment e.g. x.myMap = newMap then that's not
>> safe. You could use sync/atomic.Value if you always made sure to do
>> map reads via the Load method.
>>
>> On Mon, Sep 12, 2016 at 5:04 PM, sqweek E.  wrote:
>> > instead of updating the maps in place, they (a) take a
>> > copy of the current map (b) update the copy and (c) replace the
>> > reference to
>> > the original map (held in a struct field) with the updated copy.
>>
> --
> 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] Multiple-reader single-writer map access - is this lockless workaround safe?

[Peter Bourgon]

All memory operations are unsafe for concurrent goroutines unless
explicitly noted otherwise. In practice, if you have multiple
goroutines accessing the same memory, you need to protect it with the
primitives available to you in package sync or sync/atomic. Please
review https://golang.org/ref/mem for more details.

Many Go programmers opt to sidestep these sorts of problems by using
channels to orchestrate behavior and/or the flow of data between
goroutines — i.e. not communicating by sharing memory, but rather
sharing memory by communicating.


On Mon, Sep 12, 2016 at 6:04 PM, sqweek E.  wrote:
> Yes, through plain assignment. What problems arise from that?
>
> On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote:
>>
>> How are you replacing the reference to the original map? If you're
>> just using plain assignment e.g. x.myMap = newMap then that's not
>> safe. You could use sync/atomic.Value if you always made sure to do
>> map reads via the Load method.
>>
>> On Mon, Sep 12, 2016 at 5:04 PM, sqweek E.  wrote:
>> > instead of updating the maps in place, they (a) take a
>> > copy of the current map (b) update the copy and (c) replace the
>> > reference to
>> > the original map (held in a struct field) with the updated copy.
>>
> --
> 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: [ANN] A Go based map reduce system (second attempt)

[David Crawshaw]

The map-reduce systems I've worked with in the past bundle up the map
and reduce functions in a binary, distribute it, and then communicate
with it by an IPC or RPC system. This lets them take advantage of the
operating system to control resource allocation. (Given how popular
containers are becoming, I expect someone will do it with Linux
containers to provide even better isolation.) I suspect this is a more
flexible approach than using plugins.

On Mon, Sep 12, 2016 at 2:38 AM, Raj  wrote:
>>> However, it is still limited by the fact that Go code can not be sent and
>>> executed remotely.
>
> I am not sure if this makes the situation better for this particular use
> case, but I see that David Crawshaw is working on plugin mode for Go. It
> looks like it will be part of Go1.8.
>
> --
> 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: [ANN] A Go based map reduce system (second attempt)

[Henrik Johansson]

Perhaps something like this?

https://github.com/pachyderm/chess



mån 12 sep. 2016 kl 18:32 skrev David Crawshaw :

> The map-reduce systems I've worked with in the past bundle up the map
> and reduce functions in a binary, distribute it, and then communicate
> with it by an IPC or RPC system. This lets them take advantage of the
> operating system to control resource allocation. (Given how popular
> containers are becoming, I expect someone will do it with Linux
> containers to provide even better isolation.) I suspect this is a more
> flexible approach than using plugins.
>
> On Mon, Sep 12, 2016 at 2:38 AM, Raj 
> wrote:
> >>> However, it is still limited by the fact that Go code can not be sent
> and
> >>> executed remotely.
> >
> > I am not sure if this makes the situation better for this particular use
> > case, but I see that David Crawshaw is working on plugin mode for Go. It
> > looks like it will be part of Go1.8.
> >
> > --
> > 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.
>

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

*Thank you for responding. My response has been placed inline, below.*

On Monday, September 12, 2016 at 8:08:28 AM UTC-4, Tamás Gulácsi wrote:
>
>
>
> 2016. szeptember 12., hétfő 7:28:26 UTC+2 időpontban davidmi...@gmail.com 
> a következőt írta:
>>
>> *I have two Golang questions that I hope someone could help me out with.*
>>
>>
>> *1) Am I misunderstanding Golang maps?*
>>
>>
>> *I'm trying to translate a project from PHP to Golang for the websockets 
>> and the concurrency. *
>>
>>
>> *However, I can't do this.*
>>
>>
>> *  var MyArray [string]string*
>>
>>
>> *Instead, I have to do this.*
>>
>>
>> *  var MyMap map[string]string*
>>
>>
>> *However, since the same array (map) would be used at least once for each 
>> call to the Golang code from the Front End, which occurs any time a user 
>> sends data to the Back End, I have been led to believe that I would have to 
>> lock and unlock the map for each use. Wouldn't that essentially break 
>> concurrency (or at least eliminate its benefits??? No other user's function 
>> could use this map until the current user's function is done with it. I'd 
>> be back to "single threaded" again (concurrently speaking). This would 
>> defeat much of the point in my switching the project from PHP to Golang. To 
>> maintain concurrency without blocking other users, one would have to avoid 
>> using maps. Arrays (maps) are central to programming. How does anyone get 
>> by in Golang without using Maps?*
>>
>>
>> *For example, if I do the following.*
>>
>>
>> *func MyFunc (whatever) *map[string]string *{*
>>
>>
>>  var MyMap map[string]string
>>
>>
>> * // Do something with the map*
>>
>>
>> * return MyMap*
>>
>>
>> *}*
>>
>>
>> *func CallingFunction (whatever) {*
>>
>>
>> * MyReturnedMap := go  MyFunc(whatever)*
>>
>>
>> *}*
>>
>>
>> *.would I have to lock and unlock the map or are two separate 
>> instances of the map declared?*
>>
>>
>> *Again, am** I misunderstanding Golang maps?*
>>
>>
>>
> Use the lock for as short time as possible: only around get and set 
> access! Maybe even:
>   mMu.RLock()
>   v, ok := m[k]
>   mMu.RUnlock()
>
>   if ok {...
>   if v ...
>
>   mMu.Lock()
>   m[k] = v
>   mMu.Unlock()
>
>
*That's the exact scenario that would eliminate the purpose of using 
concurrency whenever a map is used. All goroutines would have to wait 
their turn (in some order or another) to use the map. *

*One of the primary benefits of concurrency is that if one procedure gets 
stuck or slows down, other procedures can keep moving along, evading the 
bottleneck. Once you throw a shared bottleneck into the concurrent 
routines, one loses out on the benefit of using concurrent procedures.*

*It's like if cars were driving down the highway in two lanes and the lanes 
merged for just a moment and then separated again into two lanes. If there 
were no exits before the merge (between the cars approaching the merge and 
the merge), then using two lanes would be pointless, since they all have to 
merge with each other anyway at that bottleneck. When they get to the merge 
point and have to wait their turn. It doesn't matter that they were 
concurrent (even parallel) before the bottleneck. They might as well have 
not as been concurrent in the first place! In that case, there would be no 
merge and everyone could just travel in a straight line at a steady speed! 
No bottleneck! Notice how there can be two traffic points at a toll on a 
toll road. The first is when someone takes a long time to pay. The second 
is the merge after the toll. If the first can be eliminated, splitting the 
lanes up into multiple toll lanes and then merging them again would only 
cause traffic and not prevent it. In my scenario, a Golang map would 
apparently work, not like a toll, but like the merge after the toll.*

*It doesn't really matter how long the merge takes or how short a time one 
locks the map. If it's so fast that it can be done in "single threaded" 
mode (concurrently speaking) anyway, why use concurrency? The fact that no 
other procedure can use the map while it is locked potentially forces a 
full stop on all other procedures waiting to use the map. As just stated, 
it's as if all such procedures have gone back to "single threaded" mode 
(concurrently speaking).*

*That's not to say that there aren't other potential bottlenecks being 
evaded by using concurrent routines that do no have the shared map problem, 
but if one is using locks often or if the map bottleneck is a central part 
of a procedure's functionality, it seems possible that one might not really 
be benefiting much from using concurrency in the first place.*
 

> By the way your example does not use the map concurrently, as *MyFunc *will 
> return a new map.
>

*This comment might be an answer to my question. *

*Also, if yes, then I thank you very much for your answer to this question!*

*Please clarify.*

*The map is declared within the goroutine. Sin

[go-nuts] C Syscall Memory Code Review

[Luke Mauldin]

Can you please review the code here: https://play.golang.org/p/Yk6nqHhtTo

This forms the basis of a "memory" package which I am using on Windows to 
do interoperability with some C APIs.  These existing C APIs sometimes 
take/return a C-null terminated pointer and sometimes they take/return a 
pointer allocated with the CoTaskMemAlloc and CoTaskMemFree functions.  I 
have some tested this package with some simple code and it works without 
crashes.  My main concern is that I want to make sure it continues to work 
as the GC moves memory around, etc..

P.S.  I know that CGO is an option but it isn't a good fit for my 
environment.

Luke

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Tamás Gulácsi]

TL;DR
I know what concurrency is.
For a map access, if you hold the lock for as few instructions as possible, it 
shouldn't hurt much.
If you're after an idea of the best solution, that will be harser - maybe not a 
map is the best answer for your specific use case, but a slice. Or a slice of 
maps with hashed access.
Or just copy the map before read it, and swap the whole map after a change.


If you can write down the access to the innermost element of your 
multidimensional map as m[a][b][c][d], then you know that you won't have more 
than four levels, so you can use a map[[4]string]string.

If you want an unbounded level, then first please define the equality on them, 
to be able to use them as map keys!

-- 
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] make a struct pointer _not_ implement an interface

[Alex Flint]

Is it possible to have a struct that implements an interface, but have
pointers to the struct not implement the interface? The reason is that I
want to find all the places in our codebase that attempt to use a pointer
to a certain struct as a certain 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] Multiple-reader single-writer map access - is this lockless workaround safe?

[adonovan via golang-nuts]

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

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

type T struct { x int }

var global *T

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

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

go f()
go g()

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

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

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

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

Re: [go-nuts] Re: Assigning +Inf to a float32 ..

[Michael Jones]

Actually, you would also want a way to say “which type of NaN” as there are two 
classes and several subclasses. I wrote code for this a while back and posted 
it here (IIRC).

 

From:  on behalf of 
Date: Sunday, September 11, 2016 at 6:32 AM
To: golang-nuts 
Cc: 
Subject: Re: [go-nuts] Re: Assigning +Inf to a float32 ..

 



On Sunday, 11 September 2016 14:25:29 UTC+1, Ian Lance Taylor wrote:

On Sun, Sep 11, 2016 at 6:06 AM,   wrote: 
> 
> Also curious as why the implementation is as math.NaN() rather than just 
> math.NaN (function/method not constant). It doesn't seem to help with a 
> potential interfaces. 

Go constants are untyped, more or less unlimited, and do not support 
NaN or infinity or negative zero.  There would be no simple way to 
make math.NaN a constant. 

Ian 

 

Sorry my terminology error.

 

I meant exported variable, not constant.

-- 
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] Re: make a struct pointer _not_ implement an interface

[Tyler Compton]

I don't believe this is possible. See the spec on method sets[1].

The excerpt I'm looking at:

> The method set of any other type T consists of all methods 
>  declared with receiver 
> type T. The method set of the corresponding pointer type 
>  *T is the set of all methods 
> declared with receiver *T or T (that is, it also contains the method set 
> of T).


Which leads me to believe that a pointer to a type always includes at least 
the methods of the original type.

1. https://golang.org/ref/spec#Method_sets

On Monday, September 12, 2016 at 2:20:46 PM UTC-7, Alex Flint wrote:
>
> Is it possible to have a struct that implements an interface, but have 
> pointers to the struct not implement the interface? The reason is that I 
> want to find all the places in our codebase that attempt to use a pointer 
> to a certain struct as a certain 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.

[go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

['Keith Randall' via golang-nuts]

Tamás's suggestion of using [4]string as the key is a good one.  You could 
use any struct you want as well, if you want to name the parts of the key.

How are you using the map?  If you're only reading the map, then concurrent 
access is allowed.  Concurrent access is only forbidden if one of the 
accesses is a write.  If you have only occasional writes, a sync.RWMutex 
might be appropriate.

Yes, locking around the map accesses does serialize the goroutines.  But 
the shorter the critical section, the faster your app will run.  In your 
traffic analogy, the more cars/sec can fit though a merge point, the more 
traffic flows.  And if other parts of the road have a lower speed limit, it 
may still pay to make those sections of road wider (parallel).

On Monday, September 12, 2016 at 1:13:10 PM UTC-7, Tamás Gulácsi wrote:
>
> TL;DR
> I know what concurrency is.
> For a map access, if you hold the lock for as few instructions as 
> possible, it shouldn't hurt much.
> If you're after an idea of the best solution, that will be harser - maybe 
> not a map is the best answer for your specific use case, but a slice. Or a 
> slice of maps with hashed access.
> Or just copy the map before read it, and swap the whole map after a change.
>
>
> If you can write down the access to the innermost element of your 
> multidimensional map as m[a][b][c][d], then you know that you won't have 
> more than four levels, so you can use a map[[4]string]string.
>
> If you want an unbounded level, then first please define the equality on 
> them, to be able to use them as map keys!
>
>

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Justin Israel]

On Tue, Sep 13, 2016 at 7:42 AM  wrote:

>
> *One of the primary benefits of concurrency is that if one procedure gets
> stuck or slows down, other procedures can keep moving along, evading the
> bottleneck. Once you throw a shared bottleneck into the concurrent
> routines, one loses out on the benefit of using concurrent procedures.*
>
> *It's like if cars were driving down the highway in two lanes and the
> lanes merged for just a moment and then separated again into two lanes. If
> there were no exits before the merge (between the cars approaching the
> merge and the merge), then using two lanes would be pointless, since they
> all have to merge with each other anyway at that bottleneck. When they get
> to the merge point and have to wait their turn. It doesn't matter that they
> were concurrent (even parallel) before the bottleneck. They might as well
> have not as been concurrent in the first place! In that case, there would
> be no merge and everyone could just travel in a straight line at a steady
> speed! No bottleneck! Notice how there can be two traffic points at a toll
> on a toll road. The first is when someone takes a long time to pay. The
> second is the merge after the toll. If the first can be eliminated,
> splitting the lanes up into multiple toll lanes and then merging them again
> would only cause traffic and not prevent it. In my scenario, a Golang map
> would apparently work, not like a toll, but like the merge after the toll.*
>
> *It doesn't really matter how long the merge takes or how short a time one
> locks the map. If it's so fast that it can be done in "single threaded"
> mode (concurrently speaking) anyway, why use concurrency? The fact that no
> other procedure can use the map while it is locked potentially forces a
> full stop on all other procedures waiting to use the map. As just stated,
> it's as if all such procedures have gone back to "single threaded" mode
> (concurrently speaking).*
>

This and your previous impressions of concurrency seem like some pretty
wild ideas, making me feel like you may not have a complete grasp of
concurrency vs parallelism. A map doesn't magically become "concurrency
safe". It requires either a form of locking, or to be a lock-free
implementation. Go maps are not concurrent by design. This makes them
faster for when you aren't using them concurrently. And when you are, you
are required to synchronise access to them. Now, I don't have much PHP
experience, but if I understand correctly, PHP doesn't put you in a
situation where a global associative array can even be accessible across
requests because it is "shared nothing". So you are finding yourself being
introduced to one of a number of languages that expose you to real
concurrency concerns with shared data structures.

I also feel the example of the cars on the highway doesn't properly
describe concurrency. It implies that the cars have absolutely nothing to
do, aside from driving in a straight line next to each other. But really
they are free to do all kinds of other work before and after the point that
the need to merge (synchronize) for a moment. Your requests can do all
kinds of things in their own goroutines up to the point where they need to
read or write a shared map. For that extremely brief moment, the access to
the map is protected. That does not stop other requests from continuing to
do the other work they intended to do. It only blocks the access to the
map. Now lets assume that the map implementation was already safe for
concurrent access... that could STILL mean the access would block. Only
that you aren't the one having to arrange it.

Point being, your take on concurrency implies that if any kind of
synchronization occurs in the system, that the entire concept of
concurrency is broken. It is just not true. What you aim to do is have as
much work as possible happen in parallel. Sometimes it cannot, either
because there are not enough physical cores, or there are synchronization
points in the code between various tasks that want to happen.

See: Rob Pike - 'Concurrency Is Not Parallelism'




>
>>
>>
>>
>>> *2) Also, how would one build a multidimensional array with a string
>>> index (or even a map of maps) for something like a large file directory
>>> where the number of files, folders and levels are unknown at the outset
>>> (without repeatedly using the append function that apparently uses memory
>>> on an exponential scale of 2^x)? I've figured out how to do
>>> map[string]map[string]map[string]string, but one would have to know how
>>> many levels there would be, in advance, to be able to use something like
>>> that. Also, when I've tried that, I can't put a string on any level except
>>> for the last one, since the only data type that any level other than the
>>> last one will accept is another map! What if the map turns out to be only
>>> three levels deep for one path and five levels deep for another path?** I've
>>> tried

[go-nuts] How example can be run in test?

[Harry]

Hi there,

I'm trying to run example in test.
However after running, warning is shown.
```
testing: warning: no tests to run
```

This example code include // Output comment.

```
func ExampleMethod1() {
fmt.Printf("result: %x", Method1())
// Output: 
}
```

What is wrong? When running test, I exec like this.

```go test -v _test.go```


Thanks.

Harry

-- 
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: Another divide by zero (float) question

[xiiophen]

I see - so if I understood correctly the spec for constants disallowing 
divide by zero has accidentally been applied to divide by zero for float32s

Does this mean there will be a fix at some distant point ?

-- 
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: Assigning +Inf to a float32 ..

[xiiophen]

On Monday, 12 September 2016 23:39:09 UTC+1, Michael Jones wrote:
>
> Actually, you would also want a way to say “which type of NaN” as there 
> are two classes and several subclasses. I wrote code for this a while back 
> and posted it here (IIRC).
>
>
>
yes  -I'm aware of 'signalling' and 'quiet' NaNs at least

It seems that Golang does currently fully implement/expose all of the 
IEE754 standards .. the problem is a little deeper than my original issue 
about being able to simply assign -Inf, -0 etc.

Short of doing my own bit tests there doesn't seem to be any way to detect 
different NaNs in go ?

I think these should be core language features, just as float32 and float64 
are core language features.

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

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

[sqweek E.]

Thanks all. "Plain assignment" is not quite the full story actually - as I 
mentioned originally there's also a channel in use to wake up the painter 
thread. So in terms of memory model what I'm doing is more like:

x.myMap = newMap
x.refresh <- nil // i don't think it matters what value is sent across 
the channel?

Also I don't mind a bit of racy non-determinism. If the painter thread 
happens to be actively painting when I do this update I don't care if it 
notices the newMap immediately or not, just as long as it sees the update 
when painting the next frame. That will be after it has drained the refresh 
channel, so should be guaranteed by the memory model if I've understood 
correctly.

For the general case sync.Value sounds appropriate. It means touching all 
the reader code aswell, but in a fairly trivial way.

Thanks again!
-sqweek

On Tuesday, September 13, 2016 at 12:24:09 AM UTC+8, Peter Bourgon wrote:
>
> All memory operations are unsafe for concurrent goroutines unless 
> explicitly noted otherwise. In practice, if you have multiple 
> goroutines accessing the same memory, you need to protect it with the 
> primitives available to you in package sync or sync/atomic. Please 
> review https://golang.org/ref/mem for more details. 
>
> Many Go programmers opt to sidestep these sorts of problems by using 
> channels to orchestrate behavior and/or the flow of data between 
> goroutines — i.e. not communicating by sharing memory, but rather 
> sharing memory by communicating. 
>
>
> On Mon, Sep 12, 2016 at 6:04 PM, sqweek E. > 
> wrote: 
> > Yes, through plain assignment. What problems arise from that? 
> > 
> > On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote: 
> >> 
> >> How are you replacing the reference to the original map? If you're 
> >> just using plain assignment e.g. x.myMap = newMap then that's not 
> >> safe. You could use sync/atomic.Value if you always made sure to do 
> >> map reads via the Load method. 
> >> 
> >> On Mon, Sep 12, 2016 at 5:04 PM, sqweek E.  wrote: 
> >> > instead of updating the maps in place, they (a) take a 
> >> > copy of the current map (b) update the copy and (c) replace the 
> >> > reference to 
> >> > the original map (held in a struct field) with the updated copy. 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [go-nuts] Multiple-reader single-writer map access - is this lockless workaround safe?

[Caleb Spare]

If you have a data race, you lose a lot of guarantees about the
correct operation of your program. It may work today but fail
occasionally, or a future version of the compiler may break it very
badly.

See 
https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong.

Most Go programmers consider programs with data races to be logically
incorrect / broken.

-Caleb

On Mon, Sep 12, 2016 at 6:41 PM, sqweek E.  wrote:
> Thanks all. "Plain assignment" is not quite the full story actually - as I
> mentioned originally there's also a channel in use to wake up the painter
> thread. So in terms of memory model what I'm doing is more like:
>
> x.myMap = newMap
> x.refresh <- nil // i don't think it matters what value is sent across
> the channel?
>
> Also I don't mind a bit of racy non-determinism. If the painter thread
> happens to be actively painting when I do this update I don't care if it
> notices the newMap immediately or not, just as long as it sees the update
> when painting the next frame. That will be after it has drained the refresh
> channel, so should be guaranteed by the memory model if I've understood
> correctly.
>
> For the general case sync.Value sounds appropriate. It means touching all
> the reader code aswell, but in a fairly trivial way.
>
> Thanks again!
> -sqweek
>
> On Tuesday, September 13, 2016 at 12:24:09 AM UTC+8, Peter Bourgon wrote:
>>
>> All memory operations are unsafe for concurrent goroutines unless
>> explicitly noted otherwise. In practice, if you have multiple
>> goroutines accessing the same memory, you need to protect it with the
>> primitives available to you in package sync or sync/atomic. Please
>> review https://golang.org/ref/mem for more details.
>>
>> Many Go programmers opt to sidestep these sorts of problems by using
>> channels to orchestrate behavior and/or the flow of data between
>> goroutines — i.e. not communicating by sharing memory, but rather
>> sharing memory by communicating.
>>
>>
>> On Mon, Sep 12, 2016 at 6:04 PM, sqweek E.  wrote:
>> > Yes, through plain assignment. What problems arise from that?
>> >
>> > On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote:
>> >>
>> >> How are you replacing the reference to the original map? If you're
>> >> just using plain assignment e.g. x.myMap = newMap then that's not
>> >> safe. You could use sync/atomic.Value if you always made sure to do
>> >> map reads via the Load method.
>> >>
>> >> On Mon, Sep 12, 2016 at 5:04 PM, sqweek E.  wrote:
>> >> > instead of updating the maps in place, they (a) take a
>> >> > copy of the current map (b) update the copy and (c) replace the
>> >> > reference to
>> >> > the original map (held in a struct field) with the updated copy.
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to golang-nuts...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

My response is inline.

On Monday, September 12, 2016 at 7:43:12 PM UTC-4, Keith Randall wrote:
>
> Tamás's suggestion of using [4]string as the key is a good one.  You could 
> use any struct you want as well, if you want to name the parts of the key.
>

I tried that. I can't seem to get it to work. I'm clearly doing something 
wrong, probably because I am misunderstanding Tamás's response.

Test_Map := make(map[[4]string]string)

I've tried this way.


Test_Map["Folder_1"]["Folder_2"]["Folder_3"]["Folder_4"] = "File_Name_1"


I've also tried this way.


Test_Map["Folder"[0]] = "File_Name_1"
Test_Map["Folder"[1]] = "File_Name_2"
Test_Map["Folder"[2]] = "File_Name_3"
Test_Map["Folder"[3]] = "File_Name_4"

 
The second way isn't really what I'm looking for anyway. I'm trying to get 
the first way to work.

For the first way, I get the following errors.

cannot use "Folder_1" (type string) as type [4]string in map index
non-integer string index "Folder_2"
invalid operation: Test_Map["Folder_1"]["Folder_2"]["Folder_3"] (type byte 
does not support indexing)

For the second way, I get the following errors.

cannot use "Folder"[0] (type byte) as type [4]string in map index
cannot use "Folder"[1] (type byte) as type [4]string in map index
cannot use "Folder"[2] (type byte) as type [4]string in map index
cannot use "Folder"[3] (type byte) as type [4]string in map index

How are you using the map?  If you're only reading the map, then concurrent 
> access is allowed.  Concurrent access is only forbidden if one of the 
> accesses is a write.  If you have only occasional writes, a sync.RWMutex 
> might be appropriate.
>

As I said, use of a multidimensional map isn't a "one time only" thing and 
it could appear in numerous circumstances. Some of them may be read only, 
while others would include plenty of writing.
 

> Yes, locking around the map accesses does serialize the goroutines.  
>

Thank you for understanding my underlying question and answering it. The 
question is, therefore, how one gets around this problem. (See my further 
comments on this, below.)
 

> But the shorter the critical section, the faster your app will run.  In 
> your traffic analogy, the more cars/sec can fit though a merge point, the 
> more traffic flows.  And if other parts of the road have a lower speed 
> limit, it may still pay to make those sections of road wider (parallel).
>

I made that point in my previous email.

*"That's not to say that there aren't other potential bottlenecks being 
evaded by using concurrent routines that do no have the shared map 
problem."*

*The problem I'm having is that the map manipulation would be among the 
core functionality of the concurrent procedures. Essentially, the cars are 
on a very short road and do (almost) nothing except go through a merge.*

*The answer I'm seeking now is whether or not I can avoid the locking 
problem by declaring the map within the goroutine so that multiple, 
independent, instances will be declared. I'm wondering if those would be 
safe within the context (and only within the context) of each of those 
goroutines or whether golang will be using the same shared space for each 
instance, causing problematic behavior.*

*In other words, are map instances protected by their scope?*
 

> On Monday, September 12, 2016 at 1:13:10 PM UTC-7, Tamás Gulácsi wrote:
>>
>> TL;DR
>> I know what concurrency is.
>> For a map access, if you hold the lock for as few instructions as 
>> possible, it shouldn't hurt much.
>> If you're after an idea of the best solution, that will be harser - maybe 
>> not a map is the best answer for your specific use case, but a slice. Or a 
>> slice of maps with hashed access.
>> Or just copy the map before read it, and swap the whole map after a 
>> change.
>>
>>
>> If you can write down the access to the innermost element of your 
>> multidimensional map as m[a][b][c][d], then you know that you won't have 
>> more than four levels, so you can use a map[[4]string]string.
>>
>> If you want an unbounded level, then first please define the equality on 
>> them, to be able to use them as map keys!
>>
>>

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

*I already made your point in my previous post.*

*"That's not to say that there aren't other potential bottlenecks being 
evaded by using concurrent routines that do no have the shared map 
problem."*

*I think you made have taken my comment that "**Once you throw a shared 
bottleneck into the concurrent routines, one loses out on the benefit of 
using concurrent procedures." further than I intended. I am aware of the 
difference between parallel and concurrent and have already watched the 
video you referred me to a while ago. The difference between the two really 
isn't that hard to understand and I was actually surprised that there was a 
whole 30 minute video on it.*

*The problem I'm having is that the map manipulation would be among the 
core functionality of the concurrent procedures. Essentially, the cars are 
on a very short road and do (almost) nothing except go through a merge.*

*The answer I'm seeking now is whether or not I can avoid the locking 
problem by declaring the map within the goroutine so that multiple, 
independent, instances will be declared. I'm wondering if those would be 
safe within the context (and only within the context) of each of those 
goroutines or whether golang will be using the same shared space for each 
instance, causing problematic behavior.*

On Monday, September 12, 2016 at 7:47:20 PM UTC-4, Justin Israel wrote:
>
>
> On Tue, Sep 13, 2016 at 7:42 AM > 
> wrote:
>
>>
>> *One of the primary benefits of concurrency is that if one procedure gets 
>> stuck or slows down, other procedures can keep moving along, evading the 
>> bottleneck. Once you throw a shared bottleneck into the concurrent 
>> routines, one loses out on the benefit of using concurrent procedures.*
>>
>> *It's like if cars were driving down the highway in two lanes and the 
>> lanes merged for just a moment and then separated again into two lanes. If 
>> there were no exits before the merge (between the cars approaching the 
>> merge and the merge), then using two lanes would be pointless, since they 
>> all have to merge with each other anyway at that bottleneck. When they get 
>> to the merge point and have to wait their turn. It doesn't matter that they 
>> were concurrent (even parallel) before the bottleneck. They might as well 
>> have not as been concurrent in the first place! In that case, there would 
>> be no merge and everyone could just travel in a straight line at a steady 
>> speed! No bottleneck! Notice how there can be two traffic points at a toll 
>> on a toll road. The first is when someone takes a long time to pay. The 
>> second is the merge after the toll. If the first can be eliminated, 
>> splitting the lanes up into multiple toll lanes and then merging them again 
>> would only cause traffic and not prevent it. In my scenario, a Golang map 
>> would apparently work, not like a toll, but like the merge after the toll.*
>>
>> *It doesn't really matter how long the merge takes or how short a time 
>> one locks the map. If it's so fast that it can be done in "single threaded" 
>> mode (concurrently speaking) anyway, why use concurrency? The fact that no 
>> other procedure can use the map while it is locked potentially forces a 
>> full stop on all other procedures waiting to use the map. As just stated, 
>> it's as if all such procedures have gone back to "single threaded" mode 
>> (concurrently speaking).*
>>
>
> This and your previous impressions of concurrency seem like some pretty 
> wild ideas, making me feel like you may not have a complete grasp of 
> concurrency vs parallelism. A map doesn't magically become "concurrency 
> safe". It requires either a form of locking, or to be a lock-free 
> implementation. Go maps are not concurrent by design. This makes them 
> faster for when you aren't using them concurrently. And when you are, you 
> are required to synchronise access to them. Now, I don't have much PHP 
> experience, but if I understand correctly, PHP doesn't put you in a 
> situation where a global associative array can even be accessible across 
> requests because it is "shared nothing". So you are finding yourself being 
> introduced to one of a number of languages that expose you to real 
> concurrency concerns with shared data structures.
>
> I also feel the example of the cars on the highway doesn't properly 
> describe concurrency. It implies that the cars have absolutely nothing to 
> do, aside from driving in a straight line next to each other. But really 
> they are free to do all kinds of other work before and after the point that 
> the need to merge (synchronize) for a moment. Your requests can do all 
> kinds of things in their own goroutines up to the point where they need to 
> read or write a shared map. For that extremely brief moment, the access to 
> the map is protected. That does not stop other requests from continuing to 
> do the other work they intended to do. It only blocks the access to the 
> map. Now lets assume that the map im

[go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

My response is inline.

On Monday, September 12, 2016 at 4:13:10 PM UTC-4, Tamás Gulácsi wrote:
>
> TL;DR
> I know what concurrency is.
>

ok, but I wasn't explaining concurrency to you.

If you're referring to the paragraph about the cars, I was explaining why 
your answer was incorrect. I was not explaining concurrency.

If you're referring to my comments about the map (following my "Please 
clarify." statement), I was simply setting up the scenario I was facing 
and was asking for clarification as to where I may have made a mistake. I 
was, again, not explaining concurrency to you.
 

> For a map access, if you hold the lock for as few instructions as 
> possible, it shouldn't hurt much.
>

You either didn't understand the paragraph about the cars or you didn't 
read it. Much of what I wrote was explaining why this isn't necessarily the 
case. In my case, running goroutines to avoid users blocking each other and 
then setting up a bottleneck undermines the point in using goroutines 
because they all have to wait for each other anyway to complete their 
goroutines.
 

> If you're after an idea of the best solution, that will be harser - maybe 
> not a map is the best answer for your specific use case, but a slice. Or a 
> slice of maps with hashed access.
> Or just copy the map before read it, and swap the whole map after a change.


I'm not sure I understand your suggestions here. As far as I know, the only 
structure in golang that allows one to use a string as a key would be a map.


> If you can write down the access to the innermost element of your 
> multidimensional map as m[a][b][c][d], then you know that you won't have 
> more than four levels, so you can use a map[[4]string]string.
>

I spent about an hour or two trying to get this suggestion to work. I 
clearly don't properly understand what you're suggesting.
 

> If you want an unbounded level, then first please define the equality on 
> them, to be able to use them as map keys!
>

I don't understand what you mean by "define the equality" on them. I was 
under the impression that Golang has strictly defined equality.

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Dan Kortschak]

https://play.golang.org/p/6ZyybAKWpp


On Mon, 2016-09-12 at 18:50 -0700, davidmiller...@gmail.com wrote:
> I tried that. I can't seem to get it to work. I'm clearly doing
> something 
> wrong, probably because I am misunderstanding Tamás's response.
> 
> Test_Map := make(map[[4]string]string)
> 
> I've tried this way.
> 
> 
> Test_Map["Folder_1"]["Folder_2"]["Folder_3"]["Folder_4"] =
> "File_Name_1"


-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

Thank you for clarifying that, but how does that resolve my problem?

The output I get is.

map[[Folder_1 Folder_2 Folder_3 Folder_4]:File_Name_1]

If I understand that correctly, my index key is now "Folder_1 Folder_2 
Folder_3 Folder_4" and my value is now "File_Name_1". How would I now 
assign "File_Name_2" to Folder_2, for example?

In other words, how is this any different than using ":" or "/" to fake the 
behavior of a multidimensional array? In this case, I'd be simply using 
spaces, which would technically mean that I couldn't have multi word 
folders with spaces in their names because the spaces would be considered a 
level divider.

On Monday, September 12, 2016 at 10:54:36 PM UTC-4, kortschak wrote:
>
> https://play.golang.org/p/6ZyybAKWpp 
>
>
> On Mon, 2016-09-12 at 18:50 -0700, davidmi...@gmail.com  
> wrote: 
> > I tried that. I can't seem to get it to work. I'm clearly doing 
> > something 
> > wrong, probably because I am misunderstanding Tamás's response. 
> > 
> > Test_Map := make(map[[4]string]string) 
> > 
> > I've tried this way. 
> > 
> > 
> > Test_Map["Folder_1"]["Folder_2"]["Folder_3"]["Folder_4"] = 
> > "File_Name_1" 
>
>
>

-- 
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] Best way to extract hostname from "host" or "host:port" style?

[Jonathan Yu]

Hi,

I tried searching Google, but didn't find anything. I'm probably just 
missing something obvious here, but I'm relatively new to Go - please bear 
with me :)

In URLs (of the net/url variety), the Host field may be either a hostname 
or host/port combination.  In the combined host/port case, we can use 
net.SplitHostPort to isolate the host/port portions, but if a port isn't 
specified, then we'll get an error.

We can use the same code as in SplitHostPort ("last" to check if the string 
contains a 
colon): https://github.com/golang/go/blob/master/src/net/ipsock.go#L119 but 
this is a bit less convenient than having SplitHostPort return the host 
directly (though I understand this may not be changeable without breaking 
API compatibility)

Is there an easier way to say "give me the host/port if the input is 
host:port, or host otherwise?" Alternately, some way to check for the error 
type might be useful (similar to how os.IsNotExist(err) works) -- my way of 
doing it (simply checking for a colon) seems like it'd be problematic with 
IPv6 addresses.

Thanks!

Jonathan

-- 
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: add default implementation to interfaces ( similar to abstract class in java)

[adrianwit via golang-nuts]

Agreed, that said I'm still unclear while implementing interface, is it 
better to use anonymous or explicit interface embedding:
That might help too:  Abstract Classes in Go 




On Monday, 3 September 2012 14:25:59 UTC-7, ChrisLu wrote:
>
> Thanks! This helps a lot!
>
> Here is what I concluded: implementing the abstract class in Go should be 
> split into two tasks.
> 1. implement an interface
> 2. implement an interface implementation, and mixin the implementation to 
> the "inheriting" class.
>
> Chris
>
> On Sunday, September 2, 2012 6:23:27 AM UTC-7, Jesse McNelis wrote:
>>
>> On Sun, Sep 2, 2012 at 6:29 PM, ChrisLu  wrote: 
>> > Thanks for replying! My concern is that if Node is an interface, I need 
>> to 
>> > put the implementation of AddChild() to each of the struct Rack and 
>> > DataCenter. 
>>
>> AddChild() seems like it would be a two line method not exactly a 
>> worrying amount of code duplication. 
>> But you can just do this. 
>>
>> type Node interface{ 
>> AddChild(Node) 
>> } 
>>
>> type Element struct{ 
>>   parent Node 
>>   children []Node 
>> } 
>>
>> func (*Element) AddChild(Node){} 
>>
>> type Server struct { 
>>   Element 
>>   ipAddress string 
>>   ... 
>> } 
>> type Rack struct { 
>>   Element 
>>   ipAddressRange string 
>>   ... 
>> } 
>> type DataCenter struct { 
>>   Element 
>>   ipAddressRange string 
>>   ... 
>> } 
>>
>> Server, Rack, DataCenter all satisfy the Node interface. 
>>
>>
>> -- 
>> = 
>> http://jessta.id.au 
>>
>

-- 
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] Oops ! i thought 'go' would be an easy to use programming language like BASIC or Scratch ( ! )

[Chrstphre Campbell]

Now that it turns out to be some kind of crazy Assembler Code for Terminal, 
i would like to delete it,
But the Brief and cursory instructions for how to do this; Assumes that i 
am already fluent in Unix or Whatever ?
Could someone provide me with instructions for how to remove it; 
for a 6_year old.

Thanx !

-- 
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] Linux SYS_SETGROUPS problem in forkAndExecInChild?

[celledge]

I think that golang on Linux ARM is inappropriately using the 16bit variant 
of the setgroups syscall when using exec.

I've been having problems with setting additional groups on a Linux ARM 
system with a statement like this:
groups = []uint32{20, 21}
cmd.SysProcAttr.Credential = &syscall.Credential{Groups: groups}
cmd.Run()

If I run strace on the process, I see this syscall:
setgroups(2, [20, 0])

I did some experiments and discovered that the syscall is treating groups 
as a uint16 array despite the Groups slice in golang being uint32.
groups = []uint32{1310740, 1376277, 0, 0} //20,20,21,21,0,0,0,0

gives a strace result of:
setgroups(4, [20, 20, 21, 21])

I tracked it down to this line in exec_linux.go:
_, _, err1 = RawSyscall(SYS_SETGROUPS, ngroups, groups, 0)

That's the 16bit syscall. In zsyscall_linux_arm.go setgroups() uses the 
32bit:
 _, _, e1 := RawSyscall(SYS_SETGROUPS32, uintptr(n), 
uintptr(unsafe.Pointer(list)), 0)

Since, the syscall.Credential.Group field is explicitly a uint32 in linux, 
why would the 16bit version be in use? Why not use the already properly 
defined syscall.setgroups()? Am I missing something?

Thanks,
Chris

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

[go-nuts] parsing millisecond coming after colon

[Geetha Adinarayan]

Hi,

I am trying to parse time coming in "6/9/15 15:54:04:393 CST" format. Note 
: before millisecond. When there is dot before millisecond, time.parse is 
working fine.. but when there is : before millisecond, time.parse does not 
work. am I missing anything?

I tried the following

package main

import (
"fmt"
"time"

)

func main() {
  const inputTime = "1/2/06 15:04:05:000 MST"
  t, _ := time.Parse(inputTime, "6/9/15 15:54:04:393 CST")
  fmt.Println(t)
  fmt.Println(t.Format("2006-01-02T15:04:05.000-0700"))
}

but I get the following 

0001-01-01 00:00:00 + UTC
0001-01-01T00:00:00.000+


-- 
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 Golang implements slice?

[Fei Ding]

Hi guys:

I met a problem when I try to understand slice when using as function 
parameters. After writing some code, I made a conclusion by myself, but 
need some real check and explanation here, with your help.

As far as I know, Golang's function parameters are passed by value, and 
slice could be treated as a descriptor, which seems like *{pointer to first 
element of underlying array, length of element, capacity of array}* 
according to Go Slices: usage and internals 
. So, can I say:

*When passing a slice as a function parameter, it is, in fact, passing a 
pointer, and two int values (or as a whole struct, or maybe more parameters 
to describe the slice, whatever).*

To make it clear using code:

func foo(s []T) {...}
// can this function be treated as following 3-parameter function? 
func foo(p Pointer, length, capa int) {...}

// Note: type is not the point here,
//   and we just need 3 parameters, while there maybe more

You may wonder why I have this question? Here is where everything started:

func foo(s []int) {
 s := []int{1,2,3}
 foo(s)
 fmt.Println(s)
}

Everyone know it will print [1 2 3], not [1 2 3 100]. But what I am 
interested in, is *whether the function call does modify the memory* just 
after the tail of element 3, to an int of 100. If my assumption above is 
right, then the modification may happen.

So, I made some experiments.

package main

import "fmt"
import "strconv"

type Node struct {
val int
left *Node
right *Node
}

func (n Node) String () string {
return strconv.Itoa(n.val)
}

func newNode(val int) *Node {
return &Node{val, nil, nil}
}

// Given a binary tree and a target sum, find all root-to-leaf paths 
// where each path's sum equals the given sum
func bs(root *Node, path []*Node, now int, target int, ret *[][]*Node) {
if root == nil {
return
}
path = append(path, root)
now += root.val
if now == target && root.left == nil && root.right == nil {
*ret = append(*ret, path)
return
}
bs(root.left, path, now, target, ret)
bs(root.right, path, now, target, ret)
}

func main() {
// a simple tree like:
//0
//   / \
//  1   2
root := newNode(0)
left := newNode(1)
right := newNode(2)
root.left = left
root.right = right

ret := [][]*Node{}
bs(root, make([]*Node, 0, 10), 0, 1, &ret)
fmt.Println(ret)
}


As the code above, it is a function to find all root-to-leaf paths where 
each path's sum equals the given sum in a binary tree, and, I make a simple 
test case which there are only 3 nodes: one root, two children, with values 
of 0, 1 and 2. 

Say, I want to find the paths of sum of 1. So, I call this function as:

bs(root, make([]*Node, 0, 10), 0, 1, &ret)

It is petty common to make a guess that, this call will give us a final 
result of [0, 1], which is obviously the correct answer, however, it gives 
us [0, 2], try yourself if you don't believe:

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

The algorithm here is correct, don't worry about it. Instead, please pay 
attention to the second parameter of bs(). It makes a slice which has no 
element in it, and has a capacity of 10. What if we change this parameter 
to:

bs(root, make([]*Node, 0, 1), 0, 1, &ret)

Yes, just make the slice's capacity as 1. This time you will get the right 
answer, [0, 1]. Try yourself if you are interested.

Here is my understanding of this strange problem, feel free to point out 
anything wrong:

Still the simplest code:

package main

import (
"fmt"
)

func foo(s []int) {
fmt.Println(len(s), cap(s))   // 3 3
s = append(s, 100)
fmt.Println(len(s), cap(s))   // 4 8
}

func main() {
s := []int{1,2,3}
foo(s)
fmt.Println(len(s), cap(s))   // 3 3
fmt.Println(s)// [1 2 3]
}

When the function foo() called, it has 3 parameters: a pointer of the first 
element of the array, which points to the element 1, an int for array 
length: 3, an int for array capacity: 3.  In foo(), it tries to append 100 
at the tail, but there is no room for it, according to the parameter of 
capacity it receive, so, it makes a larger array, which capacity is 8, then 
do some copy-and-append job. Unfortunately, all the work it does is useless 
because all three parameters is still themselves. So, at last, it prints [1 
2 3]

But, what will happen if the slice passed into foo() is large enough 
already?

package main

import (
"fmt"
)

func foo(s []int) {
fmt.Println(len(s), cap(s))   // 3 10
s = append(s, 100)
fmt.Println(len(s), cap(s))   // 4 10
}

func main() {
s := make([]int, 3, 10)
s[0], s[1], s[2] = 1, 2, 3
foo(s)
fmt.Println(len(s), cap(s))   // 3 10
fmt.Println(s)// [1 2 3]
}

Now, foo() is lucky, he does not need to allocate any memory, he just 
append 100 at the tail, the descriptor now becomes {address somewhere, 4, 
10}. However, in main, it is still {address somewhere, 3, 10} on account of 
the pass-by-value-calling-rule, *so, we just care about the first 3 
elements of the array, and ignore others because the descrip

[go-nuts] Cross-compilation of golang assembly via 'go tool asm'

[pcj127]

I'm implementing cross-compilation support in rules_go 
.  This takes a low-level approach 
to building golang targets that involves use of the individual toolchain 
components such as 'go tool asm', 'go tool compile', 'go tool link', etc...

Cross-compilation of pure-go inputs is working swimmingly.  However, I'm 
wondering how to cross-compile assembly inputs correctly.  Consider the 
following assembly file that defines an 'add' method.

*#include "textflag.h"*

*TEXT ·add(SB),NOSPLIT,$0*
* MOVQ x+0(FP), BX*
* MOVQ y+8(FP), BP*
* ADDQ BP, BX*
* MOVQ BX, ret+16(FP)*
* RET*

For example, this works:

*$ go tool asm -I $(go env GOROOT)/pkg/include -o add.o add.s*
*$ hexdump add.o*

*000 67 6f 20 6f 62 6a 65 63 74 20 64 61 72 77 69 6e*

*010 20 61 6d 64 36 34 20 67 6f 31 2e 36 2e 32 0a 21*

*020 0a 00 00 67 6f 31 33 6c 64 01 00 fe 02 0c 22 22*

*030 2e 61 64 64 00 00 40 00 00 40 48 8b 5c 24 08 48*

*040 8b 6c 24 10 48 01 eb 48 89 5c 24 18 c3 cc cc cc*

*050 cc cc cc cc cc cc cc cc cc cc 00 ff ff ff ff 0f*

*060 00 02 00 00 06 02 20 00 06 02 20 00 16 0a 05 02*

*070 05 02 03 02 05 02 0e 00 00 02 28 22 22 2e 61 64*

*080 64 2e 61 72 67 73 5f 73 74 61 63 6b 6d 61 70 00*

*090 00 02 52 2f 55 73 65 72 73 2f 70 63 6a 2f 67 69*

*0a0 74 68 75 62 2f 67 72 70 63 2d 67 72 65 65 74 65*

*0b0 72 74 69 6d 65 72 2f 61 64 64 2e 73 02 ff ff 67*

*0c0 6f 31 33 6c 64 *

*0c5*


Given the magic of "goose" and "garch" (and it is magical), I expected this 
to work:

*$ env GOOS=linux GOARCH=arm go tool asm -I $(go env GOROOT)/pkg/include -o 
add.o add.s*

*add.s:4: unrecognized instruction "MOVQ"*

*add.s:5: unrecognized instruction "MOVQ"*

*add.s:6: unrecognized instruction "ADDQ"*

*add.s:7: unrecognized instruction "MOVQ"*

*asm: asm: assembly of add.s failed*


This was the initial issue for this post.  However, I figured that part out 
(the std library needs to be compiled first).  So this works:

*$ env GOOS=linux GOARCH=arm go install std && go tool asm -I $(go env 
GOROOT)/pkg/include -o add.o add.s*

However, now I'm curious why whatever platform GOOS_GOARCH I choose, the 
file is exactly the same (see hexdump above).

So i'm wondering why that is.  Am I doing something wrong?  If not, why are 
GOOS and GOARCH needed at all at this stage?  

Thanks for helping me clear this up, and thanks for golang!
Paul

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Dan Kortschak]

On Mon, 2016-09-12 at 20:06 -0700, davidmiller...@gmail.com wrote:
> If I understand that correctly, my index key is now "Folder_1
> Folder_2 
> Folder_3 Folder_4" and my value is now "File_Name_1". How would I now 
> assign "File_Name_2" to Folder_2, for example?

The key would be []string{"Folder_1", "Folder_2", "Folder_3",
"Folder_4"}

> In other words, how is this any different than using ":" or "/" to
> fake the behavior of a multidimensional array?

It's not except that you can use ":" and "/" in the names.

> In this case, I'd be simply using spaces, which would technically mean
> that I couldn't have multi word folders with spaces in their names
> because the spaces would be considered a level divider.

If it's a multidimensional array where the number of dimensions varies,
then this is probably not what you want, though you could use "" as a
null key entry. So to answer the question about "File_Name_2" in g
"Folder_2"

m[[4]string{"Folder_1", "Folder_2", "", ""}] = "File_Name_2"

It doesn't seem very satisfying, but you get it essentially for free. In
many cases, you get what you pay for.

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

Thank you for clarifying. My response is inline.

On Monday, September 12, 2016 at 11:20:10 PM UTC-4, kortschak wrote:
>
> On Mon, 2016-09-12 at 20:06 -0700, davidmi...@gmail.com  
> wrote: 
> > If I understand that correctly, my index key is now "Folder_1 
> > Folder_2 
> > Folder_3 Folder_4" and my value is now "File_Name_1". How would I now 
> > assign "File_Name_2" to Folder_2, for example? 
>
> The key would be []string{"Folder_1", "Folder_2", "Folder_3", 
> "Folder_4"} 
>
>
That's what I thought. That's not what is needed.
 

> > In other words, how is this any different than using ":" or "/" to 
> > fake the behavior of a multidimensional array? 
>
> It's not except that you can use ":" and "/" in the names. 
>
> > In this case, I'd be simply using spaces, which would technically mean 
> > that I couldn't have multi word folders with spaces in their names 
> > because the spaces would be considered a level divider. 
>
> If it's a multidimensional array where the number of dimensions varies, 
> then this is probably not what you want, 


You are correct. It's not what I want. The number of dimensions does vary 
and is unknown at the outset when the map is declared.

though you could use "" as a 
> null key entry. So to answer the question about "File_Name_2" in g 
> "Folder_2" 
>
> m[[4]string{"Folder_1", "Folder_2", "", ""}] = "File_Name_2" 
>
> It doesn't seem very satisfying, but you get it essentially for free. In 
> many cases, you get what you pay for. 
>
>
Well, PHP is also free. It can do multidimensional associative arrays and 
much more. What good is Golang's tremendous efficiency if it isn't capable 
of doing what is needed in the first place? 

Thank you for your response.

-- 
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] parsing millisecond coming after colon

[Dave Cheney]

You're ignoring the error from time.Parse, that will tell you what went wrong. 

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

[go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[davidmiller124]

I've spent many, many, many hours on this (measured in days, at this point) 
and I'm convinced that Golang is missing a fundamental programming 
capability, that of multidimensional associative arrays. Searching through 
this forum's archives and other sites, I've found that I'm not the first 
one to face this problem and no one who has posted about this has yet 
received a decent response (at least, not one that I have found)! The best 
responses consist either of maps that are, at most, two levels deep or maps 
whose depth is known in advance and declared using something like 
make(map[string]map[string]map[string]map[string]map[string]string) and 
even in those cases, one cannot replace a map with just a string on any of 
those levels. 

This is a MAJOR missing feature in Golang.

In PHP, for example, multidimensional associative arrays are declarable and 
usable in a single line of code. In Javascript, Objects can serve that 
purpose and those serve as the foundation of pretty much the entire 
language. HTML is built on the tree structure, which is essentially just a 
multimentional array. The Internet is essentiallly built on it 
multidimensional associative arrays! Take XML or JSON, both of which are 
essentially multidimensional associative arrays. Take the file/folder 
system on your desktop computers and on servers as another example. Take 
relational database recordsets. I mean, the list goes on and on and on! How 
can Golang not have a simple way to initialize, manipulate and maintain 
multidimensional associative arrays?

This is such a big problem that I've even spent time looking into alternate 
options to Golang, such as Clojure, Erlang and Elixir, and I'm quite 
certain others have followed my route. I am not about to give up on Golang 
just yet, because it would mean a tremendous amount of rewriting what I've 
already done and learning yet another new language, but this is a very 
serious missing piece in Golang.

It's incredible that this has gone overlooked in Golang for so long. The 
posts I found were from as early as 2012! This is a very disappointing 
discovery. I have found many things about Golang that I really like and 
many things about Golang that I really don't like, but the lack of 
multidimensional associative arrays beats out even the lack of decent 
global error handling! By the way, while I'm at it are there any libraries 
for that?

Is there any of doing multidimensional associative arrays in Golang (beyond 
two levels and without specifying the depth of the array or map in advance) 
or am I wasting my time on this problem? If not, does anyone know if this 
feature is planned for an upcoming version of Golang?

On Monday, September 12, 2016 at 1:28:26 AM UTC-4, davidmi...@gmail.com 
wrote:
>
> *I have two Golang questions that I hope someone could help me out with.*
>
>
> *1) Am I misunderstanding Golang maps?*
>
>
> *I'm trying to translate a project from PHP to Golang for the websockets 
> and the concurrency. *
>
>
> *However, I can't do this.*
>
>
> *  var MyArray [string]string*
>
>
> *Instead, I have to do this.*
>
>
> *  var MyMap map[string]string*
>
>
> *However, since the same array (map) would be used at least once for each 
> call to the Golang code from the Front End, which occurs any time a user 
> sends data to the Back End, I have been led to believe that I would have to 
> lock and unlock the map for each use. Wouldn't that essentially break 
> concurrency (or at least eliminate its benefits??? No other user's function 
> could use this map until the current user's function is done with it. I'd 
> be back to "single threaded" again (concurrently speaking). This would 
> defeat much of the point in my switching the project from PHP to Golang. To 
> maintain concurrency without blocking other users, one would have to avoid 
> using maps. Arrays (maps) are central to programming. How does anyone get 
> by in Golang without using Maps?*
>
>
> *For example, if I do the following.*
>
>
> *func MyFunc (whatever) *map[string]string *{*
>
>
>  var MyMap map[string]string
>
>
> * // Do something with the map*
>
>
> * return MyMap*
>
>
> *}*
>
>
> *func CallingFunction (whatever) {*
>
>
> * MyReturnedMap := go  MyFunc(whatever)*
>
>
> *}*
>
>
> *.would I have to lock and unlock the map or are two separate 
> instances of the map declared?*
>
>
> *Again, am** I misunderstanding Golang maps?*
>
>
> *2) Also, how would one build a multidimensional array with a string index 
> (or even a map of maps) for something like a large file directory where the 
> number of files, folders and levels are unknown at the outset (without 
> repeatedly using the append function that apparently uses memory on an 
> exponential scale of 2^x)? I've figured out how to do 
> map[string]map[string]map[string]string, but one would have to know how 
> many levels there would be, in advance, to be able to use something like 
> that. Also,

[go-nuts] std.flag require noname-flag support

[Ally Dale]

Hi all,
I found that std.flag require noname-flag support.
For example: 
"ping 127.0.0.1 -n 2" and "ping 127.0.0.1 /n 2" 
are legal windows "ping" command line usages, but std.flag does not support 
these formats.
Moreover, I found std.flag has a suspect BUG:
I think "ping 127.0.0.1 -n = 2" or "ping 127.0.0.1 -n= 2" or "ping 
127.0.0.1 -n =2"
are possibly legal usages of command line, but unfortunately std.flag will 
cause panic.

So, I have solved these problems in my cmdline project:
https://github.com/vipally/cmdline

And, I hope std.flag can consider these requirements and allow merge the 
feature changes.
You can see my detail test case at:
https://github.com/vipally/cmdline/blob/master/flag_test.go
I hope std.falg can take these cases PASS one day.
Thanks all.

-- 
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] Best way to extract hostname from "host" or "host:port" style?

[Edward Muller]

There is probably some code here (
https://github.com/golang/go/commit/1ff19201fd898c3e1a0ed5d3458c81c1f062570b)
you can lift until go1.8 comes out.

On Mon, Sep 12, 2016 at 8:17 PM Jonathan Yu  wrote:

> Hi,
>
> I tried searching Google, but didn't find anything. I'm probably just
> missing something obvious here, but I'm relatively new to Go - please bear
> with me :)
>
> In URLs (of the net/url variety), the Host field may be either a hostname
> or host/port combination.  In the combined host/port case, we can use
> net.SplitHostPort to isolate the host/port portions, but if a port isn't
> specified, then we'll get an error.
>
> We can use the same code as in SplitHostPort ("last" to check if the
> string contains a colon):
> https://github.com/golang/go/blob/master/src/net/ipsock.go#L119 but this
> is a bit less convenient than having SplitHostPort return the host directly
> (though I understand this may not be changeable without breaking API
> compatibility)
>
> Is there an easier way to say "give me the host/port if the input is
> host:port, or host otherwise?" Alternately, some way to check for the error
> type might be useful (similar to how os.IsNotExist(err) works) -- my way of
> doing it (simply checking for a colon) seems like it'd be problematic with
> IPv6 addresses.
>
> Thanks!
>
> Jonathan
>
> --
> 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] parsing millisecond coming after colon

[Caleb Spare]

As Dave said, you should check the error, but unfortunately I think
you'll find that time.Parse doesn't handle fractional seconds that use
a character other than . as a decimal separator.

One possible workaround would be to replace all the : with . first:

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

-Caleb

On Mon, Sep 12, 2016 at 1:17 PM, Geetha Adinarayan
 wrote:
> Hi,
>
> I am trying to parse time coming in "6/9/15 15:54:04:393 CST" format. Note :
> before millisecond. When there is dot before millisecond, time.parse is
> working fine.. but when there is : before millisecond, time.parse does not
> work. am I missing anything?
>
> I tried the following
>
> package main
>
> import (
> "fmt"
> "time"
>
> )
>
> func main() {
>   const inputTime = "1/2/06 15:04:05:000 MST"
>   t, _ := time.Parse(inputTime, "6/9/15 15:54:04:393 CST")
>   fmt.Println(t)
>   fmt.Println(t.Format("2006-01-02T15:04:05.000-0700"))
> }
>
> but I get the following
>
> 0001-01-01 00:00:00 + UTC
> 0001-01-01T00:00:00.000+
>
>
>
> --
> 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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Dan Kortschak]

On Mon, 2016-09-12 at 20:26 -0700, davidmiller...@gmail.com wrote:
> Well, PHP is also free. It can do multidimensional associative arrays
> and much more. What good is Golang's tremendous efficiency if it isn't
> capable of doing what is needed in the first place? 

Depends on how much work you want to put in.

> Thank you for your response.
> 
Brad Fitzpatrick sent an arbitrarily deep map approach some time back
that might do what you want without any real additional programming.

A map[interface{}]string will do what you want if you make sure the keys
are always equalable. The approach Brad used went something like this.

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


-- 
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: Oops ! i thought 'go' would be an easy to use programming language like BASIC or Scratch ( ! )

[Dave Cheney]

I'm sorry you've not enjoyed Go. How to uninstall Go will depend on how you 
installed it. I'll give tree options, if they do not apply, please reply 
with more detail about how you installed Go.

1. If you installed Go via homebrew, which is quite common, use the brew 
command to uninstall Go
2. If you used the OS X installer, then delete /usr/local/go and remove 
check /etc/profile.d for a file that adds /usr/local/go/bin to your $PATH
3. If you installed Go using a tarball, again into /usr/local/go, remove 
that directly and remove any references to it from your $PATH

In any case you should remove any GOROOT and GOPATH environment variables 
from your shell environment.

You can also delete the contents of what was your $GOPATH if you like, 
that's up to you.

Thanks

Dave

On Tuesday, 13 September 2016 13:17:24 UTC+10, Chrstphre Campbell wrote:
>
> Now that it turns out to be some kind of crazy Assembler Code for 
> Terminal, i would like to delete it,
> But the Brief and cursory instructions for how to do this; Assumes that i 
> am already fluent in Unix or Whatever ?
> Could someone provide me with instructions for how to remove it; 
> for a 6_year old.
>
> Thanx !
>

-- 
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-compilation of golang assembly via 'go tool asm'

[Michael Hudson-Doyle]

On 13 September 2016 at 13:43,  wrote:

> I'm implementing cross-compilation support in rules_go
> .  This takes a low-level
> approach to building golang targets that involves use of the individual
> toolchain components such as 'go tool asm', 'go tool compile', 'go tool
> link', etc...
>
> Cross-compilation of pure-go inputs is working swimmingly.  However, I'm
> wondering how to cross-compile assembly inputs correctly.  Consider the
> following assembly file that defines an 'add' method.
>
> *#include "textflag.h"*
>
> *TEXT ·add(SB),NOSPLIT,$0*
> * MOVQ x+0(FP), BX*
> * MOVQ y+8(FP), BP*
> * ADDQ BP, BX*
> * MOVQ BX, ret+16(FP)*
> * RET*
>
> For example, this works:
>
> *$ go tool asm -I $(go env GOROOT)/pkg/include -o add.o add.s*
> *$ hexdump add.o*
>
> *000 67 6f 20 6f 62 6a 65 63 74 20 64 61 72 77 69 6e*
>
> *010 20 61 6d 64 36 34 20 67 6f 31 2e 36 2e 32 0a 21*
>
> *020 0a 00 00 67 6f 31 33 6c 64 01 00 fe 02 0c 22 22*
>
> *030 2e 61 64 64 00 00 40 00 00 40 48 8b 5c 24 08 48*
>
> *040 8b 6c 24 10 48 01 eb 48 89 5c 24 18 c3 cc cc cc*
>
> *050 cc cc cc cc cc cc cc cc cc cc 00 ff ff ff ff 0f*
>
> *060 00 02 00 00 06 02 20 00 06 02 20 00 16 0a 05 02*
>
> *070 05 02 03 02 05 02 0e 00 00 02 28 22 22 2e 61 64*
>
> *080 64 2e 61 72 67 73 5f 73 74 61 63 6b 6d 61 70 00*
>
> *090 00 02 52 2f 55 73 65 72 73 2f 70 63 6a 2f 67 69*
>
> *0a0 74 68 75 62 2f 67 72 70 63 2d 67 72 65 65 74 65*
>
> *0b0 72 74 69 6d 65 72 2f 61 64 64 2e 73 02 ff ff 67*
>
> *0c0 6f 31 33 6c 64 *
>
> *0c5*
>
>
> Given the magic of "goose" and "garch" (and it is magical), I expected
> this to work:
>
> *$ env GOOS=linux GOARCH=arm go tool asm -I $(go env GOROOT)/pkg/include
> -o add.o add.s*
>
> *add.s:4: unrecognized instruction "MOVQ"*
>
> *add.s:5: unrecognized instruction "MOVQ"*
>
> *add.s:6: unrecognized instruction "ADDQ"*
>
> *add.s:7: unrecognized instruction "MOVQ"*
>
> *asm: asm: assembly of add.s failed*
>

The problem here is that MOVQ is not a valid instruction for arm.


> This was the initial issue for this post.  However, I figured that part
> out (the std library needs to be compiled first).  So this works:
>
> *$ env GOOS=linux GOARCH=arm go install std && go tool asm -I $(go env
> GOROOT)/pkg/include -o add.o add.s*
>

And here, the GOOS/GOARCH settings only apply to the first command that is
run, not the asm invocation.

Cheers,
mwh


> However, now I'm curious why whatever platform GOOS_GOARCH I choose, the
> file is exactly the same (see hexdump above).
>
> So i'm wondering why that is.  Am I doing something wrong?  If not, why
> are GOOS and GOARCH needed at all at this stage?
>
> Thanks for helping me clear this up, and thanks for golang!
> Paul
>
> --
> 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] How Golang implements slice?

[Edward Muller]

On Mon, Sep 12, 2016 at 8:17 PM Fei Ding  wrote:

> Hi guys:
>
> I met a problem when I try to understand slice when using as function
> parameters. After writing some code, I made a conclusion by myself, but
> need some real check and explanation here, with your help.
>
> As far as I know, Golang's function parameters are passed by value, and
> slice could be treated as a descriptor, which seems like *{pointer to
> first element of underlying array, length of element, capacity of array}*
> according to Go Slices: usage and internals
> . So, can I say:
>
> *When passing a slice as a function parameter, it is, in fact, passing a
> pointer, and two int values (or as a whole struct, or maybe more parameters
> to describe the slice, whatever).*
>
> To make it clear using code:
>
> func foo(s []T) {...}
> // can this function be treated as following 3-parameter function?
> func foo(p Pointer, length, capa int) {...}
>
> // Note: type is not the point here,
> //   and we just need 3 parameters, while there maybe more
>
> You may wonder why I have this question? Here is where everything started:
>
> func foo(s []int) {
>  s := []int{1,2,3}
>  foo(s)
>  fmt.Println(s)
> }
>
> Everyone know it will print [1 2 3], not [1 2 3 100]. But what I am
> interested in, is *whether the function call does modify the memory* just
> after the tail of element 3, to an int of 100. If my assumption above is
> right, then the modification may happen.
>
> So, I made some experiments.
>
> package main
>
> import "fmt"
> import "strconv"
>
> type Node struct {
> val int
> left *Node
> right *Node
> }
>
> func (n Node) String () string {
> return strconv.Itoa(n.val)
> }
>
> func newNode(val int) *Node {
> return &Node{val, nil, nil}
> }
>
> // Given a binary tree and a target sum, find all root-to-leaf paths
> // where each path's sum equals the given sum
> func bs(root *Node, path []*Node, now int, target int, ret *[][]*Node) {
> if root == nil {
> return
> }
> path = append(path, root)
> now += root.val
> if now == target && root.left == nil && root.right == nil {
> *ret = append(*ret, path)
> return
> }
> bs(root.left, path, now, target, ret)
> bs(root.right, path, now, target, ret)
> }
>
> func main() {
> // a simple tree like:
> //0
> //   / \
> //  1   2
> root := newNode(0)
> left := newNode(1)
> right := newNode(2)
> root.left = left
> root.right = right
>
> ret := [][]*Node{}
> bs(root, make([]*Node, 0, 10), 0, 1, &ret)
> fmt.Println(ret)
> }
>
>
> As the code above, it is a function to find all root-to-leaf paths where
> each path's sum equals the given sum in a binary tree, and, I make a simple
> test case which there are only 3 nodes: one root, two children, with values
> of 0, 1 and 2.
>
> Say, I want to find the paths of sum of 1. So, I call this function as:
>
> bs(root, make([]*Node, 0, 10), 0, 1, &ret)
>
> It is petty common to make a guess that, this call will give us a final
> result of [0, 1], which is obviously the correct answer, however, it gives
> us [0, 2], try yourself if you don't believe:
>
> https://play.golang.org/p/hSKIOaVK2S
>
> The algorithm here is correct, don't worry about it. Instead, please pay
> attention to the second parameter of bs(). It makes a slice which has no
> element in it, and has a capacity of 10. What if we change this parameter
> to:
>
> bs(root, make([]*Node, 0, 1), 0, 1, &ret)
>
> Yes, just make the slice's capacity as 1. This time you will get the right
> answer, [0, 1]. Try yourself if you are interested.
>
> Here is my understanding of this strange problem, feel free to point out
> anything wrong:
>
> Still the simplest code:
>
> package main
>
> import (
> "fmt"
> )
>
> func foo(s []int) {
> fmt.Println(len(s), cap(s))   // 3 3
> s = append(s, 100)
> fmt.Println(len(s), cap(s))   // 4 8
> }
>
> func main() {
> s := []int{1,2,3}
> foo(s)
> fmt.Println(len(s), cap(s))   // 3 3
> fmt.Println(s)// [1 2 3]
> }
>
> When the function foo() called, it has 3 parameters: a pointer of the
> first element of the array, which points to the element 1, an int for array
> length: 3, an int for array capacity: 3.  In foo(), it tries to append 100
> at the tail, but there is no room for it, according to the parameter of
> capacity it receive, so, it makes a larger array, which capacity is 8, then
> do some copy-and-append job. Unfortunately, all the work it does is useless
> because all three parameters is still themselves. So, at last, it prints [1
> 2 3]
>
> But, what will happen if the slice passed into foo() is large enough
> already?
>
> package main
>
> import (
> "fmt"
> )
>
> func foo(s []int) {
> fmt.Println(len(s), cap(s))   // 3 10
> s = append(s, 100)
> fmt.Println(len(s), cap(s))   // 4 10
> }
>
> func main() {
> s := make([]int, 3, 10)
> s[0], s[1], s[2] = 1, 2, 3
> foo(s)
> fmt.Println(len(s), cap(s))   // 3 10
> fmt.Println(s)// [1 2 3]
> }
>
> Now, foo() is lucky, he do

Re: [go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Dan Kortschak]

Another way that you can use (based on a recursive map[string]T - where
T is an interface type - can be seen here where I use it create a
filesystem of arbitrary behaviours).

https://github.com/ev3go/sisyphus

The general case though uses map[string]interface{}. Each time you want
to add a layer at "basepath", you navigate the tree and add a newly made
map[string]interface{} at that key. See
https://github.com/ev3go/sisyphus/blob/master/fs.go for code that does
this kind of thing.

-- 
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-compilation of golang assembly via 'go tool asm'

[pcj127]

On Monday, September 12, 2016 at 9:58:58 PM UTC-6, Michael Hudson-Doyle 
wrote:
>
>
>
> On 13 September 2016 at 13:43, > wrote:
>
>> I'm implementing cross-compilation support in rules_go 
>> .  This takes a low-level 
>> approach to building golang targets that involves use of the individual 
>> toolchain components such as 'go tool asm', 'go tool compile', 'go tool 
>> link', etc...
>>
>> Cross-compilation of pure-go inputs is working swimmingly.  However, I'm 
>> wondering how to cross-compile assembly inputs correctly.  Consider the 
>> following assembly file that defines an 'add' method.
>>
>> *#include "textflag.h"*
>>
>> *TEXT ·add(SB),NOSPLIT,$0*
>> * MOVQ x+0(FP), BX*
>> * MOVQ y+8(FP), BP*
>> * ADDQ BP, BX*
>> * MOVQ BX, ret+16(FP)*
>> * RET*
>>
>> For example, this works:
>>
>> *$ go tool asm -I $(go env GOROOT)/pkg/include -o add.o add.s*
>> *$ hexdump add.o*
>>
>> *000 67 6f 20 6f 62 6a 65 63 74 20 64 61 72 77 69 6e*
>>
>> *010 20 61 6d 64 36 34 20 67 6f 31 2e 36 2e 32 0a 21*
>>
>> *020 0a 00 00 67 6f 31 33 6c 64 01 00 fe 02 0c 22 22*
>>
>> *030 2e 61 64 64 00 00 40 00 00 40 48 8b 5c 24 08 48*
>>
>> *040 8b 6c 24 10 48 01 eb 48 89 5c 24 18 c3 cc cc cc*
>>
>> *050 cc cc cc cc cc cc cc cc cc cc 00 ff ff ff ff 0f*
>>
>> *060 00 02 00 00 06 02 20 00 06 02 20 00 16 0a 05 02*
>>
>> *070 05 02 03 02 05 02 0e 00 00 02 28 22 22 2e 61 64*
>>
>> *080 64 2e 61 72 67 73 5f 73 74 61 63 6b 6d 61 70 00*
>>
>> *090 00 02 52 2f 55 73 65 72 73 2f 70 63 6a 2f 67 69*
>>
>> *0a0 74 68 75 62 2f 67 72 70 63 2d 67 72 65 65 74 65*
>>
>> *0b0 72 74 69 6d 65 72 2f 61 64 64 2e 73 02 ff ff 67*
>>
>> *0c0 6f 31 33 6c 64 *
>>
>> *0c5*
>>
>>
>> Given the magic of "goose" and "garch" (and it is magical), I expected 
>> this to work:
>>
>> *$ env GOOS=linux GOARCH=arm go tool asm -I $(go env GOROOT)/pkg/include 
>> -o add.o add.s*
>>
>> *add.s:4: unrecognized instruction "MOVQ"*
>>
>> *add.s:5: unrecognized instruction "MOVQ"*
>>
>> *add.s:6: unrecognized instruction "ADDQ"*
>>
>> *add.s:7: unrecognized instruction "MOVQ"*
>>
>> *asm: asm: assembly of add.s failed*
>>
>
> The problem here is that MOVQ is not a valid instruction for arm.
>

I see (apologies for limited knowledge of assembly).  

My interpretation of golang's assembly is that it represents an 
intermediate pseudo-language that is transformed via "instruction 
selection" to a concrete form.  Therefore, is it possible to re-write the 
above to a cross-compilable form?  If so, is this generalizable?
 

>  
>
>> This was the initial issue for this post.  However, I figured that part 
>> out (the std library needs to be compiled first).  So this works:
>>
>> *$ env GOOS=linux GOARCH=arm go install std && go tool asm -I $(go env 
>> GOROOT)/pkg/include -o add.o add.s*
>>
>
> And here, the GOOS/GOARCH settings only apply to the first command that is 
> run, not the asm invocation.
>
>
That makes sense...  I should get up and walk around more often.  No wonder 
the file is always the same!
 

> Cheers,
> mwh
>  
>
>> However, now I'm curious why whatever platform GOOS_GOARCH I choose, the 
>> file is exactly the same (see hexdump above).
>>
>> So i'm wondering why that is.  Am I doing something wrong?  If not, why 
>> are GOOS and GOARCH needed at all at this stage?  
>>
>> Thanks for helping me clear this up, and thanks for golang!
>> Paul
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Tamás Gulácsi]

2016. szeptember 13., kedd 3:50:45 UTC+2 időpontban davidmi...@gmail.com a 
következőt írta:
>
> My response is inline.
>
> On Monday, September 12, 2016 at 7:43:12 PM UTC-4, Keith Randall wrote:
>>
>> Tamás's suggestion of using [4]string as the key is a good one.  You 
>> could use any struct you want as well, if you want to name the parts of the 
>> key.
>>
>
> I tried that. I can't seem to get it to work. I'm clearly doing something 
> wrong, probably because I am misunderstanding Tamás's response.
>
> Test_Map := make(map[[4]string]string)
>
> I've tried this way.
>
>
> Test_Map["Folder_1"]["Folder_2"]["Folder_3"]["Folder_4"] = "File_Name_1"
>
>
> As others already said, for
  TestMap := make(map[[4]string]string)
  TestMap[{"Folder_1","Folder_2","Folder_3","Folder_4"}] = "File_Name_1"
will work.

If you really want a multidimensional array, you can use a 
map[string]interface{}, but then you must check (or know) whether the 
actual value at that key is a string or another map[string]interface{}:
  TestMap := map[string]interface{}{"Folder_1": 
map[string]interface{}{"Folder_2": map[string]interface{}{"Folder_3": 
map[string]interface{}{"Folder_4": "File_Name_1"
  fn := 
TestMap["Folder_1"].(map[string]interface{}))["Folder_2"].(map[string]interface{}))["Folder_3"].(map[string]interface{})).(map[string]interface{}))["Folder_4"].(string)

If you really want to use it such, you should create a type for 
map[string]interface{}, and add accessor methods to ease up usage. 


>From the usage description, I feel you want to use multidimensional arrays 
everywhere. That's not the best approach. With Go you have slices, too! And 
of course you can build other data structures right for the actual 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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Tamás Gulácsi]

2016. szeptember 13., kedd 4:01:24 UTC+2 időpontban davidmi...@gmail.com a 
következőt írta:
>
> My response is inline.
>
> On Monday, September 12, 2016 at 4:13:10 PM UTC-4, Tamás Gulácsi wrote:
>>
>> TL;DR
>> I know what concurrency is.
>>
>
> ok, but I wasn't explaining concurrency to you.
>
> If you're referring to the paragraph about the cars, I was explaining why 
> your answer was incorrect. I was not explaining concurrency.
>
>
That's what TL;DR meant: Too Long, Didn't Read.

I feel you fight against locking (synchronizing concurrent access) 'cause 
you feel that will block all your goroutines. But that's not the case!
As Justin said, a lock serializes access only to the the lock, and if you 
use it properly, it will block only the other (1) goroutine - the others 
will be able to do what they're doing.

A concurrent map is possible to program, but that'd be slower than a 
non-concurrent-access-safe map with proper synchronization.
E.g. if you first populate (write) the map, then read it (and won't modify 
after), then you won't need locking at all!


(Sorry, but for multidimensional array, I associated to the "PHP hammer": 
https://blog.codinghorror.com/the-php-singularity/)

> If you're referring to my comments about the map (following my "Please 
> clarify." statement), I was simply setting up the scenario I was facing 
> and was asking for clarification as to where I may have made a mistake. I 
> was, again, not explaining concurrency to you.
>  
>
>> For a map access, if you hold the lock for as few instructions as 
>> possible, it shouldn't hurt much.
>>
>
> You either didn't understand the paragraph about the cars or you didn't 
> read it. Much of what I wrote was explaining why this isn't necessarily the 
> case. In my case, running goroutines to avoid users blocking each other and 
> then setting up a bottleneck undermines the point in using goroutines 
> because they all have to wait for each other anyway to complete their 
> goroutines.
>  
>
>> If you're after an idea of the best solution, that will be harser - maybe 
>> not a map is the best answer for your specific use case, but a slice. Or a 
>> slice of maps with hashed access.
>> Or just copy the map before read it, and swap the whole map after a 
>> change.
>
>
> I'm not sure I understand your suggestions here. As far as I know, the 
> only structure in golang that allows one to use a string as a key would be 
> a map.
>
>
>> If you can write down the access to the innermost element of your 
>> multidimensional map as m[a][b][c][d], then you know that you won't have 
>> more than four levels, so you can use a map[[4]string]string.
>>
>
> I spent about an hour or two trying to get this suggestion to work. I 
> clearly don't properly understand what you're suggesting.
>  
>
>> If you want an unbounded level, then first please define the equality on 
>> them, to be able to use them as map keys!
>>
>
> I don't understand what you mean by "define the equality" on them. I was 
> under the impression that Golang has strictly defined equality.
>

-- 
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: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

[Egon]

On Tuesday, 13 September 2016 06:31:20 UTC+3, davidmi...@gmail.com wrote:
>
> I've spent many, many, many hours on this (measured in days, at this 
> point) and I'm convinced that Golang is missing a fundamental programming 
> capability, that of multidimensional associative arrays. Searching through 
> this forum's archives and other sites, I've found that I'm not the first 
> one to face this problem and no one who has posted about this has yet 
> received a decent response (at least, not one that I have found)! The best 
> responses consist either of maps that are, at most, two levels deep or maps 
> whose depth is known in advance and declared using something like 
> make(map[string]map[string]map[string]map[string]map[string]string) and 
> even in those cases, one cannot replace a map with just a string on any of 
> those levels. 
>

I know it's frustrating to convert one piece of software based on a set of 
idioms, to another language that uses other idioms. I can remember trying 
to convert some highly OO JavaScript code to Delphi -- oh it was a pain and 
in the end it looked terrible in Delphi.

I guess one point everyone is trying to get across is that "Go doesn't have 
a multidimensional array -- at least not a convenient one -- for a reason." 

Implicit structures significantly harm readability at the cost of 
convenience. I.e. it's probably fine for small code bases (i.e. below 
50KLOC and ~5 people), but the larger it gets the harder it is to verify 
that the structures are consistently used. This means that refactoring is 
more difficult. *(You can partly see TypeScript and Hack as trying to deal 
with the aftermath.)*

But, I should say -- I love JS objects -- they are super-convenient and 
nice to use... but I wouldn't use them in Go.

So, let's take a step back, 

and investigate how people would solve your problem in Go -- rather than 
figuring out, how to write PHP code in Go. Remember Go is not PHP, JS nor 
Haskell... hence the code you write in Go will look different than in any 
of those languages. Yes, the larger code structures will stay the same, but 
the details will vary. *Sure, the first conversion could be crude.*

Basically, what business problem are you trying to solve with 
multidimensional arrays? If you can show the PHP code you are trying to 
convert, it would be even better.

+ Egon

-- 
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] Static race detector?

[josvazg]

Why does Go does not have a static race detector? What are the difficulties?
(just pointing me to the right docs to read is fine)

I was thinking in a naive high level way...
 
If Rust can do it, using its ownership model, Go could have a tool checking 
the AST that analyzes variable scopes and checks globals, variables passed 
to goroutines and to/from channels.

If one such followed variable is found in any piece of code to be accessed 
from more than 2 places and any access is a write, bam! flag that code with 
an error.

What is this not possible or too difficult? too many corner cases? not 
enough supporting info in the code? (that could be build by the tool)
Or maybe is a work in progress,? maybe 100% reliable escape analysis is 
required beforehand?

My question is about tooling, not language changes. Although the goal would 
be such a win that, if needed, having the compiler generate more info to 
support this (without changing the specs) would we worth it.

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

Re: [go-nuts] Static race detector?

[Jan Mercl]

On Tue, Sep 13, 2016 at 7:53 AM josvazg  wrote:

> Why does Go does not have a static race detector? What are the
difficulties?

For example, the halting problem. Ok, now seriously.

> If Rust can do it, using its ownership model, Go could have a tool
checking the AST that analyzes variable scopes and checks globals,
variables passed to goroutines and to/from channels.
>
> If one such followed variable is found in any piece of code to be
accessed from more than 2 places and any access is a write, bam! flag that
code with an error.

I don't speak Rust, but AFAIK, its model of ownership does not provide
static race detecting, but can prove a race cannot happen, ie. no two paths
can concurrently read and write the same data. But a Go program can be
perfectly reasonable and completely race free even if it can be proven by
Rust's model as having a potential for races - assuming the Go program uses
synchronization properly. Proper synchronization avoids races, but it is
not possible in the general case to prove the synchronization is used
properly, because - the halting problem etc.

OTOH, a program proving that a particular Go program cannot have a race is
IMO possible to write. What I doubt is its value, because Go code which can
be proven race-free is probably only a small subset of Go code people write.

-- 

-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: Static race detector?

[Egon]

On Tuesday, 13 September 2016 08:53:39 UTC+3, josvazg wrote:
>
> Why does Go does not have a static race detector? What are the 
> difficulties?
> (just pointing me to the right docs to read is fine)
>
> I was thinking in a naive high level way...
>  
> If Rust can do it, using its ownership model, Go could have a tool 
> checking the AST that analyzes variable scopes and checks globals, 
> variables passed to goroutines and to/from channels.
>
> If one such followed variable is found in any piece of code to be accessed 
> from more than 2 places and any access is a write, bam! flag that code with 
> an error.
>
> What is this not possible or too difficult? too many corner cases? not 
> enough supporting info in the code? (that could be build by the tool)
> Or maybe is a work in progress,? maybe 100% reliable escape analysis is 
> required beforehand?
>

One WIP http://www.doc.ic.ac.uk/~cn06/pub/2016/dingo/

It's mainly -- *someone has to put in the effort*.

AFAIR the main difficulty lies in buffered channels.

+ Egon

-- 
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: Static race detector?

[Egon]

On Tuesday, 13 September 2016 09:15:57 UTC+3, Egon wrote:
>
> On Tuesday, 13 September 2016 08:53:39 UTC+3, josvazg wrote:
>>
>> Why does Go does not have a static race detector? What are the 
>> difficulties?
>> (just pointing me to the right docs to read is fine)
>>
>> I was thinking in a naive high level way...
>>  
>> If Rust can do it, using its ownership model, Go could have a tool 
>> checking the AST that analyzes variable scopes and checks globals, 
>> variables passed to goroutines and to/from channels.
>>
>> If one such followed variable is found in any piece of code to be 
>> accessed from more than 2 places and any access is a write, bam! flag that 
>> code with an error.
>>
>> What is this not possible or too difficult? too many corner cases? not 
>> enough supporting info in the code? (that could be build by the tool)
>> Or maybe is a work in progress,? maybe 100% reliable escape analysis is 
>> required beforehand?
>>
>
> One WIP http://www.doc.ic.ac.uk/~cn06/pub/2016/dingo/
>
> It's mainly -- *someone has to put in the effort*.
>
> AFAIR the main difficulty lies in buffered channels.
>

Oh, forgot to mention -- it's not a race detector, but rather a deadlock 
detector -- but, I guess, the principles are similar.

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