Re: [go-nuts] wrong ELF class error: How to compile 64 bit binary on Solaris 11 using gccgo

[Ian Lance Taylor]

On Thu, Sep 27, 2018 at 5:34 PM,   wrote:
> Yes, this works for a simple program I have. Now I modified the helloworld
> to use glog as follows:
>
> package main
>
> import (
>   "fmt"
>   "github.com/golang/glog"
> )
>
> func main() {
>   fmt.Println("Hello world")
>   glog.Info("Hello world...")
> }
>
> But now I get another error from libglog.a:
>
> amandeep@s113ldom1:~/workspace$ go build -gccgoflags=-m64 helloworld.go
> # command-line-arguments
> ld: warning: file
> /opt/go_pkgs/pkg/gccgo_solaris_sparc/github.com/golang/libglog.a(_go_.o):
> wrong ELF class: ELFCLASS32
> Undefined   first referenced
>  symbol in file
> github_com_golang_glog..import  $WORK/b001/_pkg_.a(_go_.o)
> github_com_golang_glog.Info $WORK/b001/_pkg_.a(_go_.o)
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
>
> So, I thought recompiling glog with 64 bit option would help. None of the
> following helped:
>
> sudo GOPATH=/opt/go_pkgs/ CGO_LDFLAGS='-m64' go install
> sudo GOPATH=/opt/go_pkgs/ go install -gccgoflags '-m64'
> sudo GOPATH=/opt/go_pkgs/ go install -gccgoflags='-m64'
>
> All of these generate the following:
>
> amandeep@s113ldom1:/opt/go_pkgs/src/github.com/golang/glog$ file
> /opt/go_pkgs/pkg/gccgo_solaris_sparc/github.com/golang/libglog.a
> /opt/go_pkgs/pkg/gccgo_solaris_sparc/github.com/golang/libglog.a:
> current ar archive, 32-bit symbol table

For a package that uses cgo, you'll need to use -gccgoflags=-m64 and
also set both CGO_CFLAGS and CGO_LDFLAGS to -m64.

Ian



> On Thursday, September 27, 2018 at 3:01:12 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Thu, Sep 27, 2018 at 2:57 PM, Amandeep Gautam
>>  wrote:
>> > Hi,
>> >I am trying to compile a 64bit executable using gccgo on Solaris
>> > 11/10.
>> > Following is what I have tried:
>> >
>> > CGO_LDFLAGS='-m64' go build hello_world.go
>> > GOARCH=sparc64 CGO_LDFLAGS='-m64' go build hello_world.go
>> >
>> > Below is the output of the first command:
>> >
>> > amandeep@s113ldom1:~/workspace$ CGO_LDFLAGS='-m64' go build pqrs.go
>> > # command-line-arguments
>> > ld: warning: file $WORK/b001/_pkg_.a(_go_.o): wrong ELF class:
>> > ELFCLASS32
>> > Undefined   first referenced
>> >  symbol in file
>> > main.main
>> > /usr/gnu/lib/gcc/sparc-sun-solaris2.11/8.2.1/../../../sparcv9/libgo.so
>> > __go_init_main
>> > /usr/gnu/lib/gcc/sparc-sun-solaris2.11/8.2.1/../../../sparcv9/libgo.so
>> > ld: fatal: symbol referencing errors
>> > collect2: error: ld returned 1 exit status
>> >
>> > However, I am able to generate 64 bit executable for c++ helloworld
>> > using
>> > just gcc, so I am hoping it boils down to passing the right set of
>> > flags.
>> > For example:
>> >
>> > amandeep@s113ldom1:~/workspace$ /usr/gnu/bin/gcc -m64 helloworld.c
>> > amandeep@s113ldom1:~/workspace$ file ./a.out
>> > ./a.out:ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
>> > linked, not stripped, no debugging information available
>> > amandeep@s113ldom1:~/workspace$ file /usr/gnu/bin/gcc
>> > /usr/gnu/bin/gcc:   ELF 32-bit MSB executable SPARC32PLUS Version 1,
>> > V8+
>> > Required, dynamically linked, not stripped
>> >
>> > How would you compile a 64 bit executable for Solaris using gccgo?
>>
>> CGO_LDFLAGS only affects your program if it actually uses cgo.
>>
>> Does it work to do
>> go build -gccgoflags=-m64
>> ?
>
>
> --
> 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: Canonical module arrangement in a multi-language project.

[Dave Cheney]

With the modules support added to Go 1.11 this should be straight forward.

Create a subdirectory for your go code inside your working copy; change 
into that and run 

go mod init example.com/your/repo

Where example.com/your/repo is a placeholder for the _prefix_ you want to 
apply to all of the packages inside your module, replace it with whatever 
makes sense for your company and project.

>From then on, your Go code can be built by changing into that subdirectory 
and running go build.

Dave

On Friday, 28 September 2018 09:48:54 UTC+10, Ian Bruene wrote:
>
>
> I am working on setting up NTPsec's build system to properly handle Go 
> code, and can only find limited information of the preferred way of 
> structuring the directory tree.
>
> Forcing the entire project into GOPATH would be sloppy and a giant kluge 
> all around.
>
> Placing the go code in a folder with no special structure (as we currently 
> do with Python), and then using relative module paths appears to work in 
> testing. However from what I gather relative module paths are a deeply 
> unkosher feature that should not be depended on.
>
> The only other way I see is simply to replicate a GOPATH directory 
> structure within the project and have the build tools define a custom 
> GOPATH. This forces a somewhat clunky directory structure on the project 
> with an otherwise unneeded src/ directory. A possible workaround would be 
> to structure the code as with Python, then have the build system copy the 
> files into a src/ directory under build/ and run with that GOPATH.
>
>

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[keith . randall]

Objects returned by Get() are not special in any way. They will be GCd just 
like an object returned by new(). In fact, they will often be just a 
new()'d object.
There is no association of such an object with the pool.  A pool is just a 
fancy free list. Get might return a previously Put'd object instead of a 
new() one.

Your scheme is unsafe. Storing a *Object as a uintptr means the underlying 
Object will be collected out from under your map.

On Thursday, September 27, 2018 at 2:15:11 PM UTC-7, Francis wrote:
>
> Ah, ok. In that case keeping a reference to a *Object in a uintptr will 
> not prevent it from being garbage collected.
>
> For each garbage collection cycle the runtime visits every memory 
> reference that is still 'alive'. Any references which were not visited will 
> be reclaimed as free memory.
>
> So if you wrote a map `map[uintptr]bool` the GC will not visit any of the 
> locations pointed to by any of the `uintptr`s in the map. So they would all 
> look like unused memory locations, and they would be reclaimed by the 
> garbage collector.
>
> So when you went to cast them back into a *Object, you would be pointing 
> into memory the runtime thought had been freed.
>
> On Thursday, 27 September 2018 19:52:41 UTC+2, Peter Mogensen wrote:
>>
>>
>>
>> On 09/27/2018 07:44 PM, Francis wrote: 
>> > I believe the pool does not track the objects that it returns from a 
>> > call to `Get()`. I would be surprised if it did track these objects. 
>> > There is no real need for it to track these objects. 
>>
>> Exactly, that was my point. Else there would be no reason to call Put() 
>>
>> > I think now your proposal makes a lot more sense to me. If I understand 
>> > correctly you had understood that the sync.Pool would track all the 
>> > instances of objects it had created, via Get(), and so they wouldn't be 
>> > GCed, This would be (to me) a very surprising implementation of 
>> sync.Pool. 
>>
>> No. My understanding of sync.Pool is that only the objects Put() back 
>> into it would be subject to GC. (I could of course, just read the source) 
>> The objects handed out by Get() and still in the hand of the program 
>> would be the responsibility of the application. 
>>
>> My intention was then to handle that responsibility by temporarily 
>> storing these pointers as uintptr and by using them as a value in a map, 
>> be able to exploit the map-of-non-pointers optimization to avoid GC 
>> scans of the map. 
>>
>> ... and of course remember to Put() back any map entries delete()'ed 
>> from the map and any entries left before the reference to the map it 
>> self is forgotten and the map is left to be garbage collected. 
>>
>> /Peter 
>>
>>
>>
>>

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

Re: [go-nuts] Canonical module arrangement in a multi-language project.

[robert engels]

The only thing I’ve found that works is the latter… and then I go yelled at 
that I wasn’t using proper structure…

The only other choice is a different repo for the go code, and another repo for 
everything else.

It doesn’t seem workable to me for large multi-language projects… but no one 
seems to care…

The basic problem is that the imports in Go are absolute. They should be 
logical names, and then external config to point to where they are located… 
imagine now if a major project moved from github to some other internet repo…. 
mass chaos I think…

Sorry to say, but once again Java (especially with maven) has Go beat here.

> On Sep 27, 2018, at 6:40 PM, Ian Bruene  wrote:
> 
> 
> I am working on setting up NTPsec's build system to properly handle Go code, 
> and can only find limited information of the preferred way of structuring the 
> directory tree.
> 
> Forcing the entire project into GOPATH would be sloppy and a giant kluge all 
> around.
> 
> Placing the go code in a folder with no special structure (as we currently do 
> with Python), and then using relative module paths appears to work in 
> testing. However from what I gather relative module paths are a deeply 
> unkosher feature that should not be depended on.
> 
> The only other way I see is simply to replicate a GOPATH directory structure 
> within the project and have the build tools define a custom GOPATH. This 
> forces a somewhat clunky directory structure on the project with an otherwise 
> unneeded src/ directory. A possible workaround would be to structure the code 
> as with Python, then have the build system copy the files into a src/ 
> directory under build/ and run with that GOPATH.
> 
> 
> -- 
> 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] Canonical module arrangement in a multi-language project.

[Ian Bruene]

I am working on setting up NTPsec's build system to properly handle Go 
code, and can only find limited information of the preferred way of 
structuring the directory tree.

Forcing the entire project into GOPATH would be sloppy and a giant kluge 
all around.

Placing the go code in a folder with no special structure (as we currently 
do with Python), and then using relative module paths appears to work in 
testing. However from what I gather relative module paths are a deeply 
unkosher feature that should not be depended on.

The only other way I see is simply to replicate a GOPATH directory 
structure within the project and have the build tools define a custom 
GOPATH. This forces a somewhat clunky directory structure on the project 
with an otherwise unneeded src/ directory. A possible workaround would be 
to structure the code as with Python, then have the build system copy the 
files into a src/ directory under build/ and run with that GOPATH.

-- 
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] Release 1.11.1 arrival estimate

[Francis]

Thanks Ian,

I will start agitating. :)

On Friday, 28 September 2018 00:17:38 UTC+2, Ian Lance Taylor wrote:
>
> On Thu, Sep 27, 2018 at 4:07 AM, Francis  > wrote: 
> > Does anyone have a feeling for when the 1.11.1 release  will be ready 
> > 
> > I can see from https://github.com/golang/go/milestone/80 that  it's 
> about 
> > half done with no release date. But does anyone have a clearer feeling 
> for 
> > when it might be ready by? 
> > 
> > We are reluctant to deploy with the DNS regression unfixed, but are 
> really 
> > looking forward to the performance improvements that come with this 
> release. 
>
> Likely the first week in October.  If all goes well. 
>
> Please make sure that the bug fixes you want are in the 1.11 release 
> branch, and agitate for them if not.  Thanks. 
>
> Ian 
>

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

Re: [go-nuts] Release 1.11.1 arrival estimate

[Ian Lance Taylor]

On Thu, Sep 27, 2018 at 4:07 AM, Francis  wrote:
> Does anyone have a feeling for when the 1.11.1 release  will be ready
>
> I can see from https://github.com/golang/go/milestone/80 that  it's about
> half done with no release date. But does anyone have a clearer feeling for
> when it might be ready by?
>
> We are reluctant to deploy with the DNS regression unfixed, but are really
> looking forward to the performance improvements that come with this release.

Likely the first week in October.  If all goes well.

Please make sure that the bug fixes you want are in the 1.11 release
branch, and agitate for them if not.  Thanks.

Ian

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

Re: [go-nuts] wrong ELF class error: How to compile 64 bit binary on Solaris 11 using gccgo

[Ian Lance Taylor]

On Thu, Sep 27, 2018 at 2:57 PM, Amandeep Gautam
 wrote:
> Hi,
>I am trying to compile a 64bit executable using gccgo on Solaris 11/10.
> Following is what I have tried:
>
> CGO_LDFLAGS='-m64' go build hello_world.go
> GOARCH=sparc64 CGO_LDFLAGS='-m64' go build hello_world.go
>
> Below is the output of the first command:
>
> amandeep@s113ldom1:~/workspace$ CGO_LDFLAGS='-m64' go build pqrs.go
> # command-line-arguments
> ld: warning: file $WORK/b001/_pkg_.a(_go_.o): wrong ELF class: ELFCLASS32
> Undefined   first referenced
>  symbol in file
> main.main
> /usr/gnu/lib/gcc/sparc-sun-solaris2.11/8.2.1/../../../sparcv9/libgo.so
> __go_init_main
> /usr/gnu/lib/gcc/sparc-sun-solaris2.11/8.2.1/../../../sparcv9/libgo.so
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
>
> However, I am able to generate 64 bit executable for c++ helloworld using
> just gcc, so I am hoping it boils down to passing the right set of flags.
> For example:
>
> amandeep@s113ldom1:~/workspace$ /usr/gnu/bin/gcc -m64 helloworld.c
> amandeep@s113ldom1:~/workspace$ file ./a.out
> ./a.out:ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
> linked, not stripped, no debugging information available
> amandeep@s113ldom1:~/workspace$ file /usr/gnu/bin/gcc
> /usr/gnu/bin/gcc:   ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
> Required, dynamically linked, not stripped
>
> How would you compile a 64 bit executable for Solaris using gccgo?

CGO_LDFLAGS only affects your program if it actually uses cgo.

Does it work to do
go build -gccgoflags=-m64
?

Ian

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

[go-nuts] wrong ELF class error: How to compile 64 bit binary on Solaris 11 using gccgo

[Amandeep Gautam]

Hi,
   I am trying to compile a 64bit executable using gccgo on Solaris 11/10. 
Following is what I have tried:

CGO_LDFLAGS='-m64' go build hello_world.go
GOARCH=sparc64 CGO_LDFLAGS='-m64' go build hello_world.go

Below is the output of the first command:

amandeep@s113ldom1:~/workspace$ CGO_LDFLAGS='-m64' go build pqrs.go 
# command-line-arguments
ld: warning: file $WORK/b001/_pkg_.a(_go_.o): wrong ELF class: ELFCLASS32
Undefined   first referenced
 symbol in file
main.main  
 /usr/gnu/lib/gcc/sparc-sun-solaris2.11/8.2.1/../../../sparcv9/libgo.so
__go_init_main  
/usr/gnu/lib/gcc/sparc-sun-solaris2.11/8.2.1/../../../sparcv9/libgo.so
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status

However, I am able to generate 64 bit executable for c++ helloworld using 
just gcc, so I am hoping it boils down to passing the right set of flags. 
For example:

amandeep@s113ldom1:~/workspace$ /usr/gnu/bin/gcc -m64 helloworld.c 
amandeep@s113ldom1:~/workspace$ file ./a.out 
./a.out:ELF 64-bit MSB executable SPARCV9 Version 1, dynamically 
linked, not stripped, no debugging information available
amandeep@s113ldom1:~/workspace$ file /usr/gnu/bin/gcc
/usr/gnu/bin/gcc:   ELF 32-bit MSB executable SPARC32PLUS Version 1, 
V8+ Required, dynamically linked, not stripped

How would you compile a 64 bit executable for Solaris using gccgo?

-- 
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: Debug Go program with GDB on macOS shows nothing

[Ian Lance Taylor]

On Thu, Sep 27, 2018 at 11:13 AM, changkun  wrote:
> Works, thanks! Hope the information cloud added to golang.org/doc/gdb

Sent https://golang.org/cl/138182 .

Ian

> On Thursday, September 27, 2018 at 8:02:20 PM UTC+2, David Chase wrote:
>>
>> You did nothing wrong, in 1.11 we started compressing the debug
>> information to reduce binary size, and gdb on the Mac does not understand
>> compressed DWARF.
>> We had hoped that the several speedbumps involved in running gdb on modern
>> OSX would have caused most users to move to Delve, which handles compressed
>> DWARF, but obviously this was overoptimistic.
>>
>> The workaround is to also specify "-ldflags=-compressdwarf=false" which
>> does exactly what it claims.
>> If you wanted to do this generally (so you did not need to remember),
>>
>> export GOFLAGS="-ldflags=-compressdwarf=false"
>>
>> You might try not specifying "-N -l" and see whether optimized binaries
>> have adequate debugging information; it's not perfect, but we are hoping to
>> get it good enough that core dumps and probes from/on running applications
>> will yield useful information.
>>
>> Sorry for the inconvenience.
>>
>>
>> On Thursday, September 27, 2018 at 9:38:23 AM UTC-4, changkun wrote:
>>>
>>> Debugging with GDB works fine on Linux, it is able to show everything
>>> with the breakpoint. However, nothing appears on macOS.
>>>
>>> A simple Go program, say `main.go`:
>>>
>>> package main
>>>
>>> func main() {
>>> println("hello, world!")
>>> }
>>>
>>>
>>> Then build with
>>>
>>> go build -gcflags "-N -l" -o main main.go
>>>
>>>
>>> Using GDB:
>>>
>>> $ gdb main
>>> GNU gdb (GDB) 8.2
>>> (...)
>>> Reading symbols from main...(no debugging symbols found)...done.
>>> Loading Go Runtime support.
>>> (gdb) source
>>> /usr/local/Cellar/go/1.11/libexec/src/runtime/runtime-gdb.py
>>> Loading Go Runtime support.
>>> (gdb) info files
>>> Symbols from "/Users/changkun/Desktop/demo/main".
>>> Local exec file:
>>> `/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
>>> Entry point: 0x1049e20
>>> 0x01001000 - 0x0104dfcf is .text
>>> 0x0104dfe0 - 0x01077344 is __TEXT.__rodata
>>> (...)
>>> (gdb) b *0x1049e20
>>> Breakpoint 1 at 0x1049e20
>>> (gdb)
>>>
>>>
>>> There is no `at` in the GDB outputs, the version of Go is `go version
>>> go1.11 darwin/amd64` and:
>>>
>>> $ ls -al /usr/local/bin | grep go
>>> lrwxr-xr-x1 changkun  admin24 Aug 25 16:37 go ->
>>> ../Cellar/go/1.11/bin/go
>>>
>>>
>>>
>>> ==
>>>
>>> Same process in linux environment:
>>>
>>> docker run -it --rm --name golang golang:1.11 bash
>>>
>>> then entering container install `gdb`
>>>
>>> root@1326d3f1a957:/# gdb main
>>> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
>>> (...)
>>> (gdb) info files
>>> Symbols from "/main".
>>> Local exec file:
>>> `/main', file type elf64-x86-64.
>>> Entry point: 0x44a2e0
>>> 0x00401000 - 0x0044ea8f is .text
>>> (...)
>>> (gdb) b *0x44a2e0
>>> Breakpoint 1 at 0x44a2e0: file
>>> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.
>>> (gdb)
>>>
>>>
>>> Linux is able to show with a breakpoint, `(gdb) b *0x44a2e0
>>> Breakpoint 1 at 0x44a2e0: file
>>> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.`
>>>
>>> What did I do wrong on macOS? How can I perform low-level debugging for
>>> Go programs on macOS with GDB?
>
> --
> 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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Francis]

Ah, ok. In that case keeping a reference to a *Object in a uintptr will not 
prevent it from being garbage collected.

For each garbage collection cycle the runtime visits every memory reference 
that is still 'alive'. Any references which were not visited will be 
reclaimed as free memory.

So if you wrote a map `map[uintptr]bool` the GC will not visit any of the 
locations pointed to by any of the `uintptr`s in the map. So they would all 
look like unused memory locations, and they would be reclaimed by the 
garbage collector.

So when you went to cast them back into a *Object, you would be pointing 
into memory the runtime thought had been freed.

On Thursday, 27 September 2018 19:52:41 UTC+2, Peter Mogensen wrote:
>
>
>
> On 09/27/2018 07:44 PM, Francis wrote: 
> > I believe the pool does not track the objects that it returns from a 
> > call to `Get()`. I would be surprised if it did track these objects. 
> > There is no real need for it to track these objects. 
>
> Exactly, that was my point. Else there would be no reason to call Put() 
>
> > I think now your proposal makes a lot more sense to me. If I understand 
> > correctly you had understood that the sync.Pool would track all the 
> > instances of objects it had created, via Get(), and so they wouldn't be 
> > GCed, This would be (to me) a very surprising implementation of 
> sync.Pool. 
>
> No. My understanding of sync.Pool is that only the objects Put() back 
> into it would be subject to GC. (I could of course, just read the source) 
> The objects handed out by Get() and still in the hand of the program 
> would be the responsibility of the application. 
>
> My intention was then to handle that responsibility by temporarily 
> storing these pointers as uintptr and by using them as a value in a map, 
> be able to exploit the map-of-non-pointers optimization to avoid GC 
> scans of the map. 
>
> ... and of course remember to Put() back any map entries delete()'ed 
> from the map and any entries left before the reference to the map it 
> self is forgotten and the map is left to be garbage collected. 
>
> /Peter 
>
>
>
>

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

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Dan Kortschak]

Unless you are holding a real pointer to the value, they will have no
root to hold them and so will by GC'd. Further, the uintptr in the map
will not be updated if the value is moved (does not happen now but may
in the future).

What you're doing here is unsafe.

On Thu, 2018-09-27 at 19:52 +0200, Peter Mogensen wrote:
> My intention was then to handle that responsibility by temporarily
> storing these pointers as uintptr and by using them as a value in a
> map,
> be able to exploit the map-of-non-pointers optimization to avoid GC
> scans of the map.

-- 
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] announce: LRMP - light weight reliable multicast protocol

[robert engels]

I have ported LRMP (light weight reliable multicast protocol) to Go.

It is available at lrmp 

There is also a Java implementation there, so it makes an ideal setup for 
local/wan notifications between processes/servers without a broker.

The Java implementation was originally done by Inria in France, and released by 
Sun Microsystems. I cleaned it up a bit to use modern Java facilities.

In a nutshell, it adds ‘reliability’ and ‘order’ to multicast streams, so it 
can be far more efficient than N to N tcp based notifications.

The full design is available at design document 


There was a internet specification for the protocol at one point online 
specification, may be newer 

I am in the process of adding a ‘channels’ layer to allow simple multiplexing 
and large message distribution.

It was mainly for my continued Go learning, but others may find it useful.





-- 
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: having issues setting up favicon.ico on my site

[Tamás Gulácsi]

/favicon and /favicon/ is not the same!

2018. szeptember 27., csütörtök 20:18:43 UTC+2 időpontban Grey White a 
következőt írta:
>
> Good day guys,
> I need help with attaching favicon.ico to my site
> that is my folder structure.
> i really can't tel what am doing wrong
>
> [image: Capture.PNG]
> func main() {
>http.HandleFunc("/favicon", faviconHandler)
>log.Fatal(http.ListenAndServe(":8080", nil))
> }
>
> func faviconHandler(w http.ResponseWriter, r *http.Request) {
> http.ServeFile(w, r, "/crm-app/favicon.ico")
> }
>
> my links in index.html
> 
>
>
>
>
>
>
>
>
>
>
>

-- 
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] having issues setting up favicon.ico on my site

[Justin Israel]

On Fri, Sep 28, 2018, 6:18 AM Grey White  wrote:

> Good day guys,
> I need help with attaching favicon.ico to my site
> that is my folder structure.
> i really can't tel what am doing wrong
>
> [image: Capture.PNG]
> func main() {
>http.HandleFunc("/favicon", faviconHandler)
>log.Fatal(http.ListenAndServe(":8080", nil))
> }
>
> func faviconHandler(w http.ResponseWriter, r *http.Request) {
> http.ServeFile(w, r, "/crm-app/favicon.ico")
> }
>

Are your deployed assets actually stored in /cram-app? Otherwise maybe you
want the path to be relative to where the binary is running:
crm-app/favicon.ico


> my links in index.html
> 
>
>
>
>
>
>
>
>
>
>
> --
> 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] having issues setting up favicon.ico on my site

[Grey White]

Good day guys,
I need help with attaching favicon.ico to my site
that is my folder structure.
i really can't tel what am doing wrong

[image: Capture.PNG]
func main() {
   http.HandleFunc("/favicon", faviconHandler)
   log.Fatal(http.ListenAndServe(":8080", nil))
}

func faviconHandler(w http.ResponseWriter, r *http.Request) {
http.ServeFile(w, r, "/crm-app/favicon.ico")
}

my links in index.html

   
   
   
   
   
   
   
   


-- 
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: Debug Go program with GDB on macOS shows nothing

[changkun]

Works, thanks! Hope the information cloud added to golang.org/doc/gdb

On Thursday, September 27, 2018 at 8:02:20 PM UTC+2, David Chase wrote:
>
> You did nothing wrong, in 1.11 we started compressing the debug 
> information to reduce binary size, and gdb on the Mac does not understand 
> compressed DWARF.
> We had hoped that the several speedbumps involved in running gdb on modern 
> OSX would have caused most users to move to Delve, which handles compressed 
> DWARF, but obviously this was overoptimistic.
>
> The workaround is to also specify "-ldflags=-compressdwarf=false" which 
> does exactly what it claims.
> If you wanted to do this generally (so you did not need to remember), 
>
> export GOFLAGS="-ldflags=-compressdwarf=false"
>
> You might try not specifying "-N -l" and see whether optimized binaries 
> have adequate debugging information; it's not perfect, but we are hoping to 
> get it good enough that core dumps and probes from/on running applications 
> will yield useful information.
>
> Sorry for the inconvenience.
>
>
> On Thursday, September 27, 2018 at 9:38:23 AM UTC-4, changkun wrote:
>>
>> Debugging with GDB works fine on Linux, it is able to show everything 
>> with the breakpoint. However, nothing appears on macOS.
>>
>> A simple Go program, say `main.go`:
>>
>> package main
>> 
>> func main() {
>> println("hello, world!")
>> }
>>
>>
>> Then build with 
>>
>> go build -gcflags "-N -l" -o main main.go
>>
>>
>> Using GDB:
>>
>> $ gdb main
>> GNU gdb (GDB) 8.2
>> (...)
>> Reading symbols from main...(no debugging symbols found)...done.
>> Loading Go Runtime support.
>> (gdb) source /usr/local/Cellar/go/1.11/libexec/src/runtime/runtime-
>> gdb.py
>> Loading Go Runtime support.
>> (gdb) info files
>> Symbols from "/Users/changkun/Desktop/demo/main".
>> Local exec file:
>> `/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
>> Entry point: 0x1049e20
>> 0x01001000 - 0x0104dfcf is .text
>> 0x0104dfe0 - 0x01077344 is __TEXT.__rodata
>> (...)
>> (gdb) b *0x1049e20
>> Breakpoint 1 at 0x1049e20
>> (gdb)
>>
>>
>> There is no `at` in the GDB outputs, the version of Go is `go version 
>> go1.11 darwin/amd64` and:
>>
>> $ ls -al /usr/local/bin | grep go
>> lrwxr-xr-x1 changkun  admin24 Aug 25 16:37 go -> ../
>> Cellar/go/1.11/bin/go
>>
>>
>>
>> ==
>>
>> Same process in linux environment:
>>
>> docker run -it --rm --name golang golang:1.11 bash
>>
>> then entering container install `gdb`
>>
>> root@1326d3f1a957:/# gdb main
>> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
>> (...)
>> (gdb) info files
>> Symbols from "/main".
>> Local exec file:
>> `/main', file type elf64-x86-64.
>> Entry point: 0x44a2e0
>> 0x00401000 - 0x0044ea8f is .text
>> (...)
>> (gdb) b *0x44a2e0
>> Breakpoint 1 at 0x44a2e0: file 
>> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.
>> (gdb)
>>
>>
>> Linux is able to show with a breakpoint, `(gdb) b *0x44a2e0
>> Breakpoint 1 at 0x44a2e0: file 
>> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.`
>>
>> What did I do wrong on macOS? How can I perform low-level debugging for 
>> Go programs on macOS with GDB?
>>
>

-- 
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: Debug Go program with GDB on macOS shows nothing

['David Chase' via golang-nuts]

You did nothing wrong, in 1.11 we started compressing the debug information 
to reduce binary size, and gdb on the Mac does not understand compressed 
DWARF.
We had hoped that the several speedbumps involved in running gdb on modern 
OSX would have caused most users to move to Delve, which handles compressed 
DWARF, but obviously this was overoptimistic.

The workaround is to also specify "-ldflags=-compressdwarf=false" which 
does exactly what it claims.
If you wanted to do this generally (so you did not need to remember), 

export GOFLAGS="-ldflags=-compressdwarf=false"

You might try not specifying "-N -l" and see whether optimized binaries 
have adequate debugging information; it's not perfect, but we are hoping to 
get it good enough that core dumps and probes from/on running applications 
will yield useful information.

Sorry for the inconvenience.


On Thursday, September 27, 2018 at 9:38:23 AM UTC-4, changkun wrote:
>
> Debugging with GDB works fine on Linux, it is able to show everything 
> with the breakpoint. However, nothing appears on macOS.
>
> A simple Go program, say `main.go`:
>
> package main
> 
> func main() {
> println("hello, world!")
> }
>
>
> Then build with 
>
> go build -gcflags "-N -l" -o main main.go
>
>
> Using GDB:
>
> $ gdb main
> GNU gdb (GDB) 8.2
> (...)
> Reading symbols from main...(no debugging symbols found)...done.
> Loading Go Runtime support.
> (gdb) source /usr/local/Cellar/go/1.11/libexec/src/runtime/runtime-gdb
> .py
> Loading Go Runtime support.
> (gdb) info files
> Symbols from "/Users/changkun/Desktop/demo/main".
> Local exec file:
> `/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
> Entry point: 0x1049e20
> 0x01001000 - 0x0104dfcf is .text
> 0x0104dfe0 - 0x01077344 is __TEXT.__rodata
> (...)
> (gdb) b *0x1049e20
> Breakpoint 1 at 0x1049e20
> (gdb)
>
>
> There is no `at` in the GDB outputs, the version of Go is `go version 
> go1.11 darwin/amd64` and:
>
> $ ls -al /usr/local/bin | grep go
> lrwxr-xr-x1 changkun  admin24 Aug 25 16:37 go -> ../Cellar
> /go/1.11/bin/go
>
>
>
> ==
>
> Same process in linux environment:
>
> docker run -it --rm --name golang golang:1.11 bash
>
> then entering container install `gdb`
>
> root@1326d3f1a957:/# gdb main
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> (...)
> (gdb) info files
> Symbols from "/main".
> Local exec file:
> `/main', file type elf64-x86-64.
> Entry point: 0x44a2e0
> 0x00401000 - 0x0044ea8f is .text
> (...)
> (gdb) b *0x44a2e0
> Breakpoint 1 at 0x44a2e0: file 
> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.
> (gdb)
>
>
> Linux is able to show with a breakpoint, `(gdb) b *0x44a2e0
> Breakpoint 1 at 0x44a2e0: file 
> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.`
>
> What did I do wrong on macOS? How can I perform low-level debugging for Go 
> programs on macOS with GDB?
>

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Peter Mogensen]

On 09/27/2018 07:44 PM, Francis wrote:
> I believe the pool does not track the objects that it returns from a
> call to `Get()`. I would be surprised if it did track these objects.
> There is no real need for it to track these objects.

Exactly, that was my point. Else there would be no reason to call Put()

> I think now your proposal makes a lot more sense to me. If I understand
> correctly you had understood that the sync.Pool would track all the
> instances of objects it had created, via Get(), and so they wouldn't be
> GCed, This would be (to me) a very surprising implementation of sync.Pool.

No. My understanding of sync.Pool is that only the objects Put() back
into it would be subject to GC. (I could of course, just read the source)
The objects handed out by Get() and still in the hand of the program
would be the responsibility of the application.

My intention was then to handle that responsibility by temporarily
storing these pointers as uintptr and by using them as a value in a map,
be able to exploit the map-of-non-pointers optimization to avoid GC
scans of the map.

... and of course remember to Put() back any map entries delete()'ed
from the map and any entries left before the reference to the map it
self is forgotten and the map is left to be garbage collected.

/Peter



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

Re: [go-nuts] Dependency resolution weirdness with Go Modules.

[Josh Harshman]

Thanks Paul, I read through that issue you linked and was able to work 
through the dependency issues. Seems like the issue arises when the 
dependencies aren't tagging their releases properly.  I had to update 
numerous dependencies to commits past their latest tagged release.

On Thursday, September 27, 2018 at 3:17:01 AM UTC-7, Paul Jolly wrote:
>
> Looks related to https://github.com/golang/go/issues/27457. 
>
> Perhaps a variation of 
> https://github.com/golang/go/issues/27457#issuecomment-419364867 helps 
> in this situation? 
> On Thu, 27 Sep 2018 at 00:51, Josh Harshman  > wrote: 
> > 
> > Using Go 1.11 and Go Modules to resolve package dependencies for my 
> project. 
> > Unfortunately I am running into some vendoring issues and 
> incompatibilities that have me a little stumped. 
> > 
> > Here is my go.mod file, there are a few packages listed as incompatible 
> etc... 
> > go.mod 
> > module github.ancestry.com/Ancestry/platform-haas 
> > 
> > require ( 
> > github.com/BurntSushi/toml v0.3.1 // indirect 
> > github.com/Masterminds/semver v1.4.2 // indirect 
> > github.com/Masterminds/sprig v2.16.0+incompatible // indirect 
> > github.com/aokoli/goutils v1.0.1 // indirect 
> > github.com/docker/distribution v2.6.2+incompatible // indirect 
> > github.com/ghodss/yaml v1.0.0 // indirect 
> > github.com/gobwas/glob v0.2.3 // indirect 
> > github.com/gogo/protobuf v1.1.1 // indirect 
> > github.com/golang/mock v1.1.1 
> > github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db // 
> indirect 
> > github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // 
> indirect 
> > github.com/google/uuid v1.0.0 // indirect 
> > github.com/gorilla/mux v1.6.2 
> > github.com/hashicorp/errwrap v1.0.0 // indirect 
> > github.com/hashicorp/go-cleanhttp v0.5.0 
> > github.com/hashicorp/go-rootcerts 
> v0.0.0-20160503143440-6bb64b370b90 
> > github.com/hashicorp/go-sockaddr 
> v0.0.0-20180320115054-6d291a969b86 // indirect 
> > github.com/hashicorp/vault v0.11.1 
> > github.com/huandu/xstrings v1.2.0 // indirect 
> > github.com/imdario/mergo v0.3.6 // indirect 
> > github.com/json-iterator/go v1.1.5 // indirect 
> > github.com/mitchellh/go-homedir v1.0.0 
> > github.com/modern-go/concurrent 
> v0.0.0-20180306012644-bacd9c7ef1dd // indirect 
> > github.com/modern-go/reflect2 v1.0.1 // indirect 
> > github.com/ryanuber/go-glob v0.0.0-20170128012129-256dc444b735 
> // indirect 
> > github.com/sethgrid/pester v0.0.0-20180430140037-03e26c9abbbf 
> > github.com/sirupsen/logrus v1.1.0 
> > github.com/spf13/cobra v0.0.3 
> > github.com/spf13/viper v1.2.0 
> > golang.org/x/net v0.0.0-20180926154720-4dfa2610cdf3 
> > golang.org/x/time v0.0.0-20180412165947-fbb02b2291d2 // 
> indirect 
> > google.golang.org/grpc v1.15.0 // indirect 
> > gopkg.in/inf.v0 v0.9.1 // indirect 
> > gopkg.in/yaml.v2 v2.2.1 
> > k8s.io/api v0.0.0-20180925152912-a191abe0b71e // indirect 
> > k8s.io/apiextensions-apiserver 
> v0.0.0-20180925155151-c0b566b8903b // indirect 
> > k8s.io/apimachinery v0.0.0-20180925152725-5ae511e0ed34 // 
> indirect 
> > k8s.io/apiserver v0.0.0-20180925200106-4eecb3917976 // indirect 
> > k8s.io/client-go v8.0.0+incompatible // indirect 
> > k8s.io/helm v2.11.0+incompatible 
> > k8s.io/kubernetes v1.11.3 // indirect 
> > ) 
> > 
> > 
> > and predicibly I suppose when running go build ./... I receive the 
> following errors. 
> > 
> > ...[snip]... 
> > 
> > # k8s.io/client-go/pkg/apis/clientauthentication/v1alpha1 
> > /go/pkg/mod/
> k8s.io/client-go@v8.0.0+incompatible/pkg/apis/clientauthentication/v1alpha1/zz_generated.conversion.go:39:15:
>  
> scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs) 
> > # k8s.io/client-go/pkg/apis/clientauthentication/v1beta1 
> > /go/pkg/mod/
> k8s.io/client-go@v8.0.0+incompatible/pkg/apis/clientauthentication/v1beta1/zz_generated.conversion.go:39:15:
>  
> scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs) 
> > # k8s.io/kubernetes/pkg/util/parsers 
> > /go/pkg/mod/k8s.io/kubernetes@v1.11.3/pkg/util/parsers/parsers.go:36:16: 
> undefined: reference.ParseNormalizedNamed 
> > # k8s.io/kubernetes/pkg/apis/admissionregistration/v1alpha1 
> > /go/pkg/mod/
> k8s.io/kubernetes@v1.11.3/pkg/apis/admissionregistration/v1alpha1/zz_generated.conversion.go:39:15:
>  
> scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs) 
> > # k8s.io/kubernetes/pkg/apis/admissionregistration/v1beta1 
> > /go/pkg/mod/
> 

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Francis]

I believe the pool does not track the objects that it returns from a call 
to `Get()`. I would be surprised if it did track these objects. There is no 
real need for it to track these objects.

The role of a sync pool is to give you an instance of *Object when you need 
it. As an optimisation if it has some pooled instances it will give you 
those instead of creating a new one. Whatever it gives you as a return to 
Get() it doesn't need to keep track of. It can't give that instance to 
anyone else, so it just forgets about it, unless you call Put(), then it 
will track that - so it can give that instance to someone else.

I think now your proposal makes a lot more sense to me. If I understand 
correctly you had understood that the sync.Pool would track all the 
instances of objects it had created, via Get(), and so they wouldn't be 
GCed, This would be (to me) a very surprising implementation of sync.Pool.

On Thursday, 27 September 2018 19:28:07 UTC+2, Peter Mogensen wrote:
>
>
>
> On 09/27/2018 07:19 PM, Francis wrote: 
> > It is true that uintptr is not looked at by the garbage collector. This 
> > will definitely reduce your GC costs. But there is no way (that I know 
> > of) to convert your uintptr back into a *Object that is safe. 
>
> I assume of course that we know that all uintptr in the map is actuall 
> *Object 
>
> > Because uintptr is ignored by the GC it won't keep the memory it points 
> > to alive. So the *Object could, and very likely will, be collected as 
> > garbage. As noted above the sync.Pool is allowed to discard things that 
> > it is pooling. The last time I read the details the strategy was to 
> > clear _everything_ in the pool during a GC run. 
>
> But not objects returned by Get() for which Put() has not yet been 
> called, I assume. ? 
>
> /Peter 
>

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

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Peter Mogensen]

On 09/27/2018 07:19 PM, Francis wrote:
> It is true that uintptr is not looked at by the garbage collector. This
> will definitely reduce your GC costs. But there is no way (that I know
> of) to convert your uintptr back into a *Object that is safe.

I assume of course that we know that all uintptr in the map is actuall
*Object

> Because uintptr is ignored by the GC it won't keep the memory it points
> to alive. So the *Object could, and very likely will, be collected as
> garbage. As noted above the sync.Pool is allowed to discard things that
> it is pooling. The last time I read the details the strategy was to
> clear _everything_ in the pool during a GC run.

But not objects returned by Get() for which Put() has not yet been
called, I assume. ?

/Peter

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

[go-nuts] Dead-simple dialog boxes?

[jclc via golang-nuts]

So, I've been thinking about the GUI situation with Go and I'm seeing a lot 
of interesting projects coming up lately. However, none of these really 
satisfy my needs. All of these projects are suitable for larger graphical 
applications, but what I want is a dead simple, dependency- and (L)GPL-free 
package that lets users make dialog boxes with some widgets, such as 
buttons, radio buttons, text input boxes, dropdown-menus and progress bars. 

The idea is that it could be plugged into simple script-like Go programs 
that could be operated without the need for a command-line interface. Some 
use-cases may include a launcher before starting a game, settings window 
for a background process or a program that takes a file and operates on it 
with several options.

My initial plan is that on Unix, it would dynamically link to GTK3 on 
runtime (_without_ including it with the program); on Windows it would use 
the WinAPI and on Mac it would use the native Cocoa libraries. One problem 
of this approach is that it would require CGO on platforms other than 
Windows, though maybe this could be alleviated by supplying a binary-only 
version of this package. Are there any projects like this around?

-- 
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] ticker for poisson processes?

[Tristan Colgate]

Both use the runtime timers underneath. Ticker requires an extra channel
send.

Tracking this down was interesting!

On Thu, 27 Sep 2018, 14:56 David Wahlstedt, 
wrote:

> I mean that an ordinary go thread executing a sleep instruction may risk
> to be starved by the scheduler, so the real sleeping time is likely to be
> longer. But with the ticker, a incoming message in the channel waking up a
> routine that waits for it, things may behave differently?
>
> /David
>
>
> Den onsdag 26 september 2018 kl. 17:33:29 UTC+2 skrev Sebastien Binet:
>>
>>
>>
>> On Wed, Sep 26, 2018 at 2:29 PM David Wahlstedt 
>> wrote:
>>
>>> Thanks--nice!
>>> Will this be less reliable than the built-in Ticker (that uses
>>> runtimeTimer), besides the intentional randomness?
>>>
>>
>> modulo the possible bug(s) I may have unintentionally introduced, I think
>> it should be as reliable.
>> (perhaps a bit less efficient than runtimeTimer, I haven't had the
>> intellectual curiosity to look at what runtimeTimer does.)
>>
>> -s
>>
>>
>>>
>>> /David
>>>
>>> Den tisdag 25 september 2018 kl. 18:43:33 UTC+2 skrev Sebastien Binet:



 On Tue, Sep 25, 2018 at 11:34 AM David Wahlstedt <
 david.wah...@gmail.com> wrote:

> Hi,
> What would be a nice way to implement a ticker that generates events
> according to a Poisson process?
> The built-in Ticker in ticker.go uses a runtimeTimer that has a field
> called period.
> I would like to implement a "random ticker" such that each tick
> interval is random, using ExpFloat64() * d, with average duration d,
> instead of a fixed interval.
> I could have a go routine that sleeps a random amount of time in a
> loop, but it would be nice to use something similar to the ticker.
>

 just for fun:  https://play.golang.org/p/kt0qVQ41E1C
 (yes, it uses a goroutine that sleeps a random amount of time in a
 loop.)

 -s

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@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.

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Francis]

It's unclear to me how this could be useful.

It is true that uintptr is not looked at by the garbage collector. This 
will definitely reduce your GC costs. But there is no way (that I know of) 
to convert your uintptr back into a *Object that is safe.

Because uintptr is ignored by the GC it won't keep the memory it points to 
alive. So the *Object could, and very likely will, be collected as garbage. 
As noted above the sync.Pool is allowed to discard things that it is 
pooling. The last time I read the details the strategy was to clear 
_everything_ in the pool during a GC run.

You can avoid this by going old-fashioned and using a `chan *Object` as 
your pool. Assuming, you are storing these things in the channel at the 
same time you are storing their `uintptr`s in the map they won't be 
recovered by the garbage collector. This will probably work. But, 
critically _only_ with the non-moving GC that Go uses currently. There is a 
reasonable chance that Go, or some implementation of Go, will adopt a 
moving garbage collector. Then your `uintptr`s would potentially point to 
an old memory location after a GC run.

On Thursday, 27 September 2018 16:39:48 UTC+2, Robert Engels wrote:
>
> No offense, sorry for high jacking, I was trying to counter point their 
> usefulness, as a way to limit additional resources being spent to improve 
> GC when using them, since I think their application is error prone in many 
> most? cases. 
>
> > On Sep 27, 2018, at 9:30 AM, Peter Mogensen > 
> wrote: 
> > 
> > 
> > 
> >> On 09/27/2018 04:20 PM, Ian Davis wrote: 
> >> 
> >> https://github.com/golang/go/issues/23199 describes another gotcha 
> when using pools: pinning of memory buffers. 
> >> 
> > 
> > Yes... that's a good point for people considering to use sync.Pool. 
> > 
> > For the purpose of this question however, let's assume the decision to 
> > use sync.Pool for the actual objects already has been taken and that 
> > knowing when to call Put() is not an issue. 
> > We can also perfectly assume that the pool managed objects are NOT of 
> > variable size (as in the above link) and do not use growing buffers, 
> > either by bytes.Buffer or by using append()   ... which is actually the 
> > case for my current code. 
> > 
> > I hope I'm not rude, when I try to steer this thread back on topic and 
> > avoid that it degenerates to a discussion of whether sync.Pool is hard 
> > to use in general - which was not the intention of my original question 
> > regarding the fix in https://go-review.googlesource.com/c/go/+/3288 
> > 
> > Well meaning, 
> > Peter 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

Re: [go-nuts] Re: Updating a struct from goroutines

[Agniva De Sarker]

Sure, feel free to do what you are comfortable with. I just couldn't
understand why there is a need for the Update function at all.

Hope that your Go transition goes smoothly :)

-Agniva

On Thu, 27 Sep 2018 at 21:29 Michael Ellis 
wrote:

> Thanks for the feedback, Agni.  I think I may not have included enough
> detail in my original post.
>
> At present, the app is in the middle of transitioning to an all-Go
> implementation.  For business reasons, that process will be stretched out
> over the next several months or longer.  In the meantime, it needs to keep
> working so I've already implemented something quite similar to what you
> describe by porting the busiest Python processes first and providing a
> socket interface that replaces the ZeroMQ interface in a way that allows
> the calls from the remaining Python processes to have the same signature
> and behavior as before.  That's working quite well so far and we're already
> seeing better performance and improved reliability.
>
> I should also mention that the target for the system is an inexpensive
> Linux SBC, a Raspberry Pi.  In the pure Python version,  the overhead for
> serializing, transmitting and de-serializing data had grown to use far more
> CPU than seemed wise in a system that needs to run reliably for months at a
> time at customer sites around the world.
>
> Within the collection of processes that are now goroutines, I can't see a
> benefit to incurring the overhead to marshal and unmarshal the data if
> there's a concurrency-safe way to perform updates and get snapshots of the
> state data.
>
> Sending functions over a channel seems to be a match made in heaven for
> our use cases.  It nicely supports our application logic that parcels out
> responsibility for updating pieces of the state struct to long-running
> goroutines.  Most of them are loops that fetch a snapshot of the state,
> inspect it to make decisions about what actions to take, perform the
> actions and update the state.
>
> In that context, sending anonymous update functions wrapped in struct with
> a disposable "done" channel doesn't seem overcomplicated at all.  The
> update actions in my first post boil down to three lines that can be
> wrapped up in a single function, e.g.
>
> func Update(f func(*Big)) {
> u := update{make(chan struct{}), f}
> upch <- u // upch is a toplevel var visible to all goroutines
> <-u.done
> }
>
> and an (oversimplified) goroutine that, say, reads a new value from a
> sensor looks like
>
> func gopher() {
> var newA int
> f := func(b *Big) {
> b.A = newA
> }
> for {
> newA = ReadSensor()
> Update(f)
> }
> }
>
> As I see it, the beauties of this approach are:
>
>1.  f is locally defined and therefore has access to gopher's locals,
>2. gopher has no direct access to the instance of Big that holds the
>state.
>3. Update pauses gopher until the state update has completed in the
>single goroutine that reads from upch.  So no worries about gopher changing
>its own locals before the update is complete.
>4. Benchmarking shows it's more than fast enough for our needs.
>5. The compiler catches any type mismatches instead of depending on
>the runtime to report it at deserialization.
>
>
> Sorry for the long-winded reply. I really appreciate the feedback and the
> opportunity to learn from you and others who've been using Go far longer
> than I.
>
>
>
>
>
>
>
> On Thu, Sep 27, 2018 at 12:48 AM Agniva De Sarker <
> agniva.quicksil...@gmail.com> wrote:
>
>> I think you are overcomplicating this a bit. It seems like a simple
>> pattern of broadcasting a change to multiple agents. You send the change
>> over a REQ-REP pair, and broadcast it to others over a PUB-SUB pair.
>>
>> Why do you need to copy the struct again ? Just get the struct from the
>> REP socket and push it to the PUB socket ?
>>
>> Here is what I would do  -
>>
>> Use protobuf to marshal/unmarshal the config struct when
>> sending/receiving it through the socket. That way you have perfect interop
>> between Go and Python.
>>
>> And use a for-select pattern to do the job of receiving and broadcasting.
>> Pseudo code as follows
>>
>> package main
>>
>> func main() {
>> // setup REP socket in a goroutine, unmarshal the msg, send the struct to
>> updateChan
>> // create PUB socket, store it in mem somewhere
>>
>> go run()
>>
>> // setup signal handlers, and send signal to done chan when
>> ctrl-c is received.
>> }
>>
>> func run() {
>> for {
>> select {
>> case msg := <-updateChan:
>> // push msg to the PUB socket
>> case <-done:
>> // you have to send signal to this from main()
>> return
>> }
>> }
>> }
>>
>> Isn't this what you are trying to do ?
>>
>>
>>
>> On Wednesday, 26 September 2018 00:09:07 UTC+5:30, Michael Ellis wrote:
>>>
>>> Hi, new gopher here.
>>> I considered asking this on SO, but they (rightly, IMO) discourage "Is
>>> this a good way to do it?" questions.  Hope that's ok here.
>>>
>>> By 

Re: [go-nuts] Re: Updating a struct from goroutines

[Michael Ellis]

Thanks for the feedback, Agni.  I think I may not have included enough
detail in my original post.

At present, the app is in the middle of transitioning to an all-Go
implementation.  For business reasons, that process will be stretched out
over the next several months or longer.  In the meantime, it needs to keep
working so I've already implemented something quite similar to what you
describe by porting the busiest Python processes first and providing a
socket interface that replaces the ZeroMQ interface in a way that allows
the calls from the remaining Python processes to have the same signature
and behavior as before.  That's working quite well so far and we're already
seeing better performance and improved reliability.

I should also mention that the target for the system is an inexpensive
Linux SBC, a Raspberry Pi.  In the pure Python version,  the overhead for
serializing, transmitting and de-serializing data had grown to use far more
CPU than seemed wise in a system that needs to run reliably for months at a
time at customer sites around the world.

Within the collection of processes that are now goroutines, I can't see a
benefit to incurring the overhead to marshal and unmarshal the data if
there's a concurrency-safe way to perform updates and get snapshots of the
state data.

Sending functions over a channel seems to be a match made in heaven for our
use cases.  It nicely supports our application logic that parcels out
responsibility for updating pieces of the state struct to long-running
goroutines.  Most of them are loops that fetch a snapshot of the state,
inspect it to make decisions about what actions to take, perform the
actions and update the state.

In that context, sending anonymous update functions wrapped in struct with
a disposable "done" channel doesn't seem overcomplicated at all.  The
update actions in my first post boil down to three lines that can be
wrapped up in a single function, e.g.

func Update(f func(*Big)) {
u := update{make(chan struct{}), f}
upch <- u // upch is a toplevel var visible to all goroutines
<-u.done
}

and an (oversimplified) goroutine that, say, reads a new value from a
sensor looks like

func gopher() {
var newA int
f := func(b *Big) {
b.A = newA
}
for {
newA = ReadSensor()
Update(f)
}
}

As I see it, the beauties of this approach are:

   1.  f is locally defined and therefore has access to gopher's locals,
   2. gopher has no direct access to the instance of Big that holds the
   state.
   3. Update pauses gopher until the state update has completed in the
   single goroutine that reads from upch.  So no worries about gopher changing
   its own locals before the update is complete.
   4. Benchmarking shows it's more than fast enough for our needs.
   5. The compiler catches any type mismatches instead of depending on the
   runtime to report it at deserialization.


Sorry for the long-winded reply. I really appreciate the feedback and the
opportunity to learn from you and others who've been using Go far longer
than I.







On Thu, Sep 27, 2018 at 12:48 AM Agniva De Sarker <
agniva.quicksil...@gmail.com> wrote:

> I think you are overcomplicating this a bit. It seems like a simple
> pattern of broadcasting a change to multiple agents. You send the change
> over a REQ-REP pair, and broadcast it to others over a PUB-SUB pair.
>
> Why do you need to copy the struct again ? Just get the struct from the
> REP socket and push it to the PUB socket ?
>
> Here is what I would do  -
>
> Use protobuf to marshal/unmarshal the config struct when sending/receiving
> it through the socket. That way you have perfect interop between Go and
> Python.
>
> And use a for-select pattern to do the job of receiving and broadcasting.
> Pseudo code as follows
>
> package main
>
> func main() {
> // setup REP socket in a goroutine, unmarshal the msg, send the struct to
> updateChan
> // create PUB socket, store it in mem somewhere
>
> go run()
>
> // setup signal handlers, and send signal to done chan when ctrl-c
> is received.
> }
>
> func run() {
> for {
> select {
> case msg := <-updateChan:
> // push msg to the PUB socket
> case <-done:
> // you have to send signal to this from main()
> return
> }
> }
> }
>
> Isn't this what you are trying to do ?
>
>
>
> On Wednesday, 26 September 2018 00:09:07 UTC+5:30, Michael Ellis wrote:
>>
>> Hi, new gopher here.
>> I considered asking this on SO, but they (rightly, IMO) discourage "Is
>> this a good way to do it?" questions.  Hope that's ok here.
>>
>> By way of background, I'm porting a largish industrial control
>> application from Python to Go.  The Python version uses multiple processes
>> (about a dozen in all) communicating over ZeroMQ.  One process, called the
>> statehouse,  controls access to the application state.  The others obtain
>> copies and send updates over REQ sockets.  The data are serialized as JSON
>> objects that map nicely to Python dicts.
>>
>> Since there's no 

[go-nuts] http router collaborators

[Alex]

https://github.com/golangdaddy/tarantula

Docs:

https://github.com/golangdaddy/tarantula/tree/master/router


Hi, I wrote this http router over the last couple of years, I now have used 
it for many projects and employers.

It's node based, has very flexible routing options and has full input 
sanitation and validators.

I would like some contributors to come on, who can help release it as a 
modern routing solution.

The repo has some other helper packages in there like a full sql-backed 
graph-database, httpclient, app-engine datastore abstractions that can be 
removed if necessary to make it clean.

The package generates a service discovery document, has a testing framework 
which has self-mocking capability.

If you are bored of gorilla and frustrated by other routers, this has been 
designed to be super fast to work with and code-maintainable at scale.

It has core/http and fasthttp support, and app engine.

Closest thing to it is Gin, but I have taken a slightly different approach. 
Should have shared ages ago but been shy.

I need help with unit tests, documentation etc, otherwise it's an awesome 
solution for making web apps.



-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Robert Engels]

No offense, sorry for high jacking, I was trying to counter point their 
usefulness, as a way to limit additional resources being spent to improve GC 
when using them, since I think their application is error prone in many most? 
cases. 

> On Sep 27, 2018, at 9:30 AM, Peter Mogensen  wrote:
> 
> 
> 
>> On 09/27/2018 04:20 PM, Ian Davis wrote:
>> 
>> https://github.com/golang/go/issues/23199 describes another gotcha when 
>> using pools: pinning of memory buffers.
>> 
> 
> Yes... that's a good point for people considering to use sync.Pool.
> 
> For the purpose of this question however, let's assume the decision to
> use sync.Pool for the actual objects already has been taken and that
> knowing when to call Put() is not an issue.
> We can also perfectly assume that the pool managed objects are NOT of
> variable size (as in the above link) and do not use growing buffers,
> either by bytes.Buffer or by using append()   ... which is actually the
> case for my current code.
> 
> I hope I'm not rude, when I try to steer this thread back on topic and
> avoid that it degenerates to a discussion of whether sync.Pool is hard
> to use in general - which was not the intention of my original question
> regarding the fix in https://go-review.googlesource.com/c/go/+/3288
> 
> Well meaning,
> Peter
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Ian Davis]

On Thu, 27 Sep 2018, at 3:06 PM, Peter Mogensen wrote:
> 
> 
> On 09/27/2018 03:58 PM, Robert Engels wrote:
> > It wasn’t necessarily a warning to you :)
> > 
> > It comes from the days of GC bashing in Java and so everyone tried to 
> > manually write garbage free programs using pools and it had a bad effect on 
> > both performance and reliability. GC is there for a reason, use it... :) I 
> > would just hate to see Go developers “go” down the same path...
> 
> Well... being blissfully ignorant of JVM garbage collection pain I
> occasionally use sync.Pool to improve code in Go with measurable
> results. I've never really found it difficult to know when to call Put()
> 

https://github.com/golang/go/issues/23199 describes another gotcha when using 
pools: pinning of memory buffers.

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Robert Engels]

In a highly concurrent system it can be difficult to know when to call Put if 
the object reference is shared among threads/routines. Similar to why C++ has 
shared pointers. It might be easy for the original author to know when a Put 
should be called but as a system grows and new functionality is added, it can 
become increasing difficult to perform manual reference counting - which is 
what you are doing...

> On Sep 27, 2018, at 9:06 AM, Peter Mogensen  wrote:
> 
> 
> 
>> On 09/27/2018 03:58 PM, Robert Engels wrote:
>> It wasn’t necessarily a warning to you :)
>> 
>> It comes from the days of GC bashing in Java and so everyone tried to 
>> manually write garbage free programs using pools and it had a bad effect on 
>> both performance and reliability. GC is there for a reason, use it... :) I 
>> would just hate to see Go developers “go” down the same path...
> 
> Well... being blissfully ignorant of JVM garbage collection pain I
> occasionally use sync.Pool to improve code in Go with measurable
> results. I've never really found it difficult to know when to call Put()
> 
> I'm not that familiar with the GC issues around Go maps with pointers
> though, but I can see that the difference between map[string]*Object and
> map[int]int are not trivial for huge maps ... and I wondered whether you
> really needed to pay the cost for using pointers if they came for a
> sync.Pool anyway.
> ... which seems like a rather common use case to me.
> 
> /Peter
> 

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

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Peter Mogensen]

On 09/27/2018 03:58 PM, Robert Engels wrote:
> It wasn’t necessarily a warning to you :)
> 
> It comes from the days of GC bashing in Java and so everyone tried to 
> manually write garbage free programs using pools and it had a bad effect on 
> both performance and reliability. GC is there for a reason, use it... :) I 
> would just hate to see Go developers “go” down the same path...

Well... being blissfully ignorant of JVM garbage collection pain I
occasionally use sync.Pool to improve code in Go with measurable
results. I've never really found it difficult to know when to call Put()

I'm not that familiar with the GC issues around Go maps with pointers
though, but I can see that the difference between map[string]*Object and
map[int]int are not trivial for huge maps ... and I wondered whether you
really needed to pay the cost for using pointers if they came for a
sync.Pool anyway.
 ... which seems like a rather common use case to me.

/Peter

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

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Robert Engels]

It wasn’t necessarily a warning to you :)

It comes from the days of GC bashing in Java and so everyone tried to manually 
write garbage free programs using pools and it had a bad effect on both 
performance and reliability. GC is there for a reason, use it... :) I would 
just hate to see Go developers “go” down the same path...

> On Sep 27, 2018, at 8:29 AM, Peter Mogensen  wrote:
> 
> 
> 
>> On 09/27/2018 03:25 PM, Robert Engels wrote:
>> Based on my experience and I believe many others, I would caution against 
>> the use of pools. Although it can be useful for objects that are very 
>> expensive to create/initialize using it in a more general case just to 
>> improve GC can be fraught with issues in a highly concurrent and/or complex 
>> system. It is much more difficult to know when an object can be “put back” 
>> and be sure there are no more references. This is why there is GC in the 
>> first place, to avoid the types of bugs this leads to. 
> 
> regardless of the map GC issues, if one doesn't know when to call
> Pool.Put(), one shouldn't use sync.Pool  ... that's probably a given.
> 
> But for the question at hand, let's assume that proper use of sync.Pool
> is mastered.
> 
> /Peter
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+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] ticker for poisson processes?

[David Wahlstedt]

I mean that an ordinary go thread executing a sleep instruction may risk to 
be starved by the scheduler, so the real sleeping time is likely to be 
longer. But with the ticker, a incoming message in the channel waking up a 
routine that waits for it, things may behave differently?

/David


Den onsdag 26 september 2018 kl. 17:33:29 UTC+2 skrev Sebastien Binet:
>
>
>
> On Wed, Sep 26, 2018 at 2:29 PM David Wahlstedt  > wrote:
>
>> Thanks--nice!
>> Will this be less reliable than the built-in Ticker (that uses 
>> runtimeTimer), besides the intentional randomness?
>>
>
> modulo the possible bug(s) I may have unintentionally introduced, I think 
> it should be as reliable.
> (perhaps a bit less efficient than runtimeTimer, I haven't had the 
> intellectual curiosity to look at what runtimeTimer does.)
>
> -s
>  
>
>>
>> /David
>>
>> Den tisdag 25 september 2018 kl. 18:43:33 UTC+2 skrev Sebastien Binet:
>>>
>>>
>>>
>>> On Tue, Sep 25, 2018 at 11:34 AM David Wahlstedt  
>>> wrote:
>>>
 Hi,
 What would be a nice way to implement a ticker that generates events 
 according to a Poisson process?
 The built-in Ticker in ticker.go uses a runtimeTimer that has a field 
 called period.
 I would like to implement a "random ticker" such that each tick 
 interval is random, using ExpFloat64() * d, with average duration d, 
 instead of a fixed interval.
 I could have a go routine that sleeps a random amount of time in a 
 loop, but it would be nice to use something similar to the ticker.

>>>
>>> just for fun:  https://play.golang.org/p/kt0qVQ41E1C
>>> (yes, it uses a goroutine that sleeps a random amount of time in a loop.)
>>>
>>> -s
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@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] Debug Go program with GDB on macOS shows nothing

[changkun]

Debugging with GDB works fine on Linux, it is able to show everything with 
the breakpoint. However, nothing appears on macOS.

A simple Go program, say `main.go`:

package main

func main() {
println("hello, world!")
}


Then build with 

go build -gcflags "-N -l" -o main main.go


Using GDB:

$ gdb main
GNU gdb (GDB) 8.2
(...)
Reading symbols from main...(no debugging symbols found)...done.
Loading Go Runtime support.
(gdb) source /usr/local/Cellar/go/1.11/libexec/src/runtime/runtime-gdb.
py
Loading Go Runtime support.
(gdb) info files
Symbols from "/Users/changkun/Desktop/demo/main".
Local exec file:
`/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
Entry point: 0x1049e20
0x01001000 - 0x0104dfcf is .text
0x0104dfe0 - 0x01077344 is __TEXT.__rodata
(...)
(gdb) b *0x1049e20
Breakpoint 1 at 0x1049e20
(gdb)


There is no `at` in the GDB outputs, the version of Go is `go version 
go1.11 darwin/amd64` and:

$ ls -al /usr/local/bin | grep go
lrwxr-xr-x1 changkun  admin24 Aug 25 16:37 go -> ../Cellar/
go/1.11/bin/go



==

Same process in linux environment:

docker run -it --rm --name golang golang:1.11 bash

then entering container install `gdb`

root@1326d3f1a957:/# gdb main
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
(...)
(gdb) info files
Symbols from "/main".
Local exec file:
`/main', file type elf64-x86-64.
Entry point: 0x44a2e0
0x00401000 - 0x0044ea8f is .text
(...)
(gdb) b *0x44a2e0
Breakpoint 1 at 0x44a2e0: file 
/usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.
(gdb)


Linux is able to show with a breakpoint, `(gdb) b *0x44a2e0
Breakpoint 1 at 0x44a2e0: file 
/usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.`

What did I do wrong on macOS? How can I perform low-level debugging for Go 
programs on macOS with GDB?

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Robert Engels]

Based on my experience and I believe many others, I would caution against the 
use of pools. Although it can be useful for objects that are very expensive to 
create/initialize using it in a more general case just to improve GC can be 
fraught with issues in a highly concurrent and/or complex system. It is much 
more difficult to know when an object can be “put back” and be sure there are 
no more references. This is why there is GC in the first place, to avoid the 
types of bugs this leads to. 

> On Sep 27, 2018, at 8:20 AM, Peter Mogensen  wrote:
> 
> 
> 
>> On 09/27/2018 03:12 PM, Ian Davis wrote:
>> 
>> 
>>> On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote:
>>> 
>>> Of course... it requires that you handle any collisions in hashing the
>>> string key to an int yourself, but wrt. the value I curious if anyone
>>> can see issued with just storing a uintptr instead of the pointer for
>>> sync.Pool managed objects. - (provided you remember to call pool.Put()
>>> before loosing the map reference or doing delete() on a key.)
>>> 
>>> m[key] = uintptr(unsafe.Pointer(pool.Get().(*Object)))
>>> 
>> 
>> sync.Pools are cleared on every GC run so I expect that will cause some 
>> issues with your approach
>> 
> 
> I don't think so... the point being that the "huge" part comes from a
> lot of objects tied up in the map, not so much in the garbage pile.
> Of course I would still like Objects which I don't use anymore to be
> collected. I just don't want the map to be checked for Objects I've
> already promised myself to tell when are garbage.
> 
> /Peter
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Peter Mogensen]

On 09/27/2018 03:25 PM, Robert Engels wrote:
> Based on my experience and I believe many others, I would caution against the 
> use of pools. Although it can be useful for objects that are very expensive 
> to create/initialize using it in a more general case just to improve GC can 
> be fraught with issues in a highly concurrent and/or complex system. It is 
> much more difficult to know when an object can be “put back” and be sure 
> there are no more references. This is why there is GC in the first place, to 
> avoid the types of bugs this leads to. 

regardless of the map GC issues, if one doesn't know when to call
Pool.Put(), one shouldn't use sync.Pool  ... that's probably a given.

But for the question at hand, let's assume that proper use of sync.Pool
is mastered.

/Peter

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

[go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Peter Mogensen]

On 09/27/2018 03:12 PM, Ian Davis wrote:
> 
> 
> On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote:
>>
>> Of course... it requires that you handle any collisions in hashing the
>> string key to an int yourself, but wrt. the value I curious if anyone
>> can see issued with just storing a uintptr instead of the pointer for
>> sync.Pool managed objects. - (provided you remember to call pool.Put()
>> before loosing the map reference or doing delete() on a key.)
>>
>> m[key] = uintptr(unsafe.Pointer(pool.Get().(*Object)))
>>
> 
> sync.Pools are cleared on every GC run so I expect that will cause some 
> issues with your approach
> 

I don't think so... the point being that the "huge" part comes from a
lot of objects tied up in the map, not so much in the garbage pile.
Of course I would still like Objects which I don't use anymore to be
collected. I just don't want the map to be checked for Objects I've
already promised myself to tell when are garbage.

/Peter

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

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Ian Davis]

On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote:
> 
> Of course... it requires that you handle any collisions in hashing the
> string key to an int yourself, but wrt. the value I curious if anyone
> can see issued with just storing a uintptr instead of the pointer for
> sync.Pool managed objects. - (provided you remember to call pool.Put()
> before loosing the map reference or doing delete() on a key.)
> 
> m[key] = uintptr(unsafe.Pointer(pool.Get().(*Object)))
> 

sync.Pools are cleared on every GC run so I expect that will cause some issues 
with your approach

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Peter Mogensen]

Hi,

I noticed the GC fix which avoids scanning maps if both key and value
are not pointer types. [1] and see it used [2] and discussed [3]

So... Initially, I figured this was not worth thinking too much about,
but then I came to thing about the relatively common use case where your
map value is an object you get from a sync.Pool

In other words... you already have exempted the *Objects from normal
garbage collection probably already have some structure in place for
knowing when to call pool.Put() to return the objects.
I would seem silly to scan an entire map which only contains Pool issued
pointers.

So, I tried to measure GC time the same way as [3] but now with a
map[int]uintptr holding pointers to the objects I got from sync.Pool and
it seems there are still significant GC gains to be had.

Of course... it requires that you handle any collisions in hashing the
string key to an int yourself, but wrt. the value I curious if anyone
can see issued with just storing a uintptr instead of the pointer for
sync.Pool managed objects. - (provided you remember to call pool.Put()
before loosing the map reference or doing delete() on a key.)

m[key] = uintptr(unsafe.Pointer(pool.Get().(*Object)))

/Peter


1: https://go-review.googlesource.com/c/go/+/3288
2: https://github.com/allegro/bigcache/blob/master/shard.go#L14
3: https://www.komu.engineer/blogs/go-gc-maps

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

[go-nuts] Re: proposal: generic generics proposal

[Scott Cotton]

On Thursday, 20 September 2018 01:59:27 UTC+2, kortschak wrote:
>
> It's pretty clear for the flood of emails to golang-nuts and golang-dev 
> regarding the recent generics/contracts proposal that there are many 
> ways to implement generics proposals. 
>
> Because of this and risks associated with copy pasting generics 
> proposals to modify and re-propose, I would like to propose a mechanism 
> for implementing generics proposals generically — that is a parametric 
> proposal proposal (possibly with either metacontracts or nested 
> boxing). 
>
> Is anyone adequately versed in metaphysics and the philosophy of self- 
> reference to help me out with this? 
>

Maybe, fork modify and present with github diff link like 
https://github.com/golang/proposal/compare/master...wsc1:master
is a pretty flexible option.

self-reference: check
metaphysics: not as far as I know :)
generic:  at least a general way of doing it.

Scott

 

>
> thanks 
> Dan 
>

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

Re: [go-nuts] [ANN] go-formal github organisation

[Scott Cotton]

Good question!

There is an entire field of "formal" verification with associated
conferences such as FMCAD, CAV, etc which has a long history, and the
meaning has indeed changed over time.  It may well mean different things to
different people.

In general, to me, "formal" comes from "formal logic" and fully specified
proof systems.  In the field of verification, "formal" often means there is
an associated proof of correctness or of unreachability say of a panic.

But it has come to also mean bug-hunting tools such as cbmc
 which are based on modelling C for bounded
model checking.

So some examples may be
- SAT/MAXSAT/SMT solvers
- verification tools like SLAM
- modal logic solvers
- Golang source analysers which produce models of source code execution and
then prove things about them


Some folks consider type theory formal, as in pure form (like system F,
type systems for ocaml) "formal" as well.

There are also things like proof carrying code which contains a proof that
remote execution is safe in some way.

so what "formal" is not formally defined :)

Hopefully, this will help clarify for those without prior exposure to the
field.

Scott

On Thu, 27 Sep 2018 at 11:42, Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Sep 27, 2018 at 11:38 AM Scott Cotton  wrote:
>
> > I've just created a github organisation for formal tools in and for Go.
>
> Please expand on what a 'formal tool' is. I have no idea.
>
> --
>
> -j
>


-- 
Scott Cotton
http://www.iri-labs.com

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

Re: [go-nuts] [ANN] go-formal github organisation

[Jan Mercl]

On Thu, Sep 27, 2018 at 11:38 AM Scott Cotton  wrote:

> I've just created a github organisation for formal tools in and for Go.

Please expand on what a 'formal tool' is. I have no idea.

-- 

-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: [ANN] go-formal github organisation

[Scott Cotton]

And of course, it's at https://github.com/go-formal

On Thursday, 27 September 2018 11:38:08 UTC+2, Scott Cotton wrote:
>
> Hi all,
>
> I've just created a github organisation for formal tools in and for Go.
>
> There's not much there now, but it is open to all to list and house 
> related repos.
>
> Membership is open upon request (for now just send an email to 
> w...@iri-labs.com), we ask 
> only that you be an open (not secret) github member.
>
> Best,
> Scott
>
>

-- 
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] [ANN] go-formal github organisation

[Scott Cotton]

Hi all,

I've just created a github organisation for formal tools in and for Go.

There's not much there now, but it is open to all to list and house related 
repos.

Membership is open upon request (for now just send an email to 
w...@iri-labs.com), we ask 
only that you be an open (not secret) github member.

Best,
Scott

-- 
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 doesn't vgo use git checkout?

[Nilsocket]

I think there was something absolutely wrong with my question.

I'm not a professional software developer, so excuse me if I was wrong.

I was just watching russ cox go with versions keynote 
,

Why not one do a git checkout to the version which is required by 
particular package and build it.
Since the binaries in go are static by default, I don't think there would 
be any problem.

Regarding git, anyhow versions are being mentioned with git tags, Is there 
something fundamentally wrong with this.

Does go compiler need whole code to be visible?
If that is the case, 
I'm not sure, but can't one use compiled packages to link or build the 
final binary.

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