[go-nuts] Cross-compile macOS binary with cgo DNS resolver enabled

[Julien Gricourt]

I'm trying to cross-compile a macOS binary in Docker with the cgo DNS 
resolver enabled. My understanding is that this is doable without setting 
up a full macOS SDK toolchain, and by using the package from the macOS 
distribution. However, I'm unable to make it work. Somehow the compiler 
always rebuilds the net package from sources and the netgo DNS resolver 
becomes the de facto. 

Very short implementation I'm using for testing:

package main

import "net"

func main() {
   net.LookupIP("google.com")
}

The build output shows that net.a is built from sources instead of picking 
up /usr/local/go/pkg/darwin_amd64/net.a:

$ ls -la /usr/local/go/pkg/darwin_amd64/net.a
-rw-r--r-- 1 root root 1241304 Jun  6 23:51 
/usr/local/go/pkg/darwin_amd64/net.a

$ go clean -cache

$ go build -x -o dns-test ./dns
WORK=/tmp/go-build098597944
mkdir -p $WORK/b002/
cat >$WORK/b002/importcfg << 'EOF' # internal
# import config
importmap golang_org/x/net/route=vendor/golang_org/x/net/route
packagefile context=/usr/local/go/pkg/darwin_amd64/context.a
packagefile errors=/usr/local/go/pkg/darwin_amd64/errors.a
packagefile 
vendor/golang_org/x/net/route=/usr/local/go/pkg/darwin_amd64/vendor/golang_org/x/net/route.a
packagefile 
internal/nettrace=/usr/local/go/pkg/darwin_amd64/internal/nettrace.a
packagefile internal/poll=/usr/local/go/pkg/darwin_amd64/internal/poll.a
packagefile 
internal/singleflight=/usr/local/go/pkg/darwin_amd64/internal/singleflight.a
packagefile io=/usr/local/go/pkg/darwin_amd64/io.a
packagefile math/rand=/usr/local/go/pkg/darwin_amd64/math/rand.a
packagefile os=/usr/local/go/pkg/darwin_amd64/os.a
packagefile runtime=/usr/local/go/pkg/darwin_amd64/runtime.a
packagefile sort=/usr/local/go/pkg/darwin_amd64/sort.a
packagefile sync=/usr/local/go/pkg/darwin_amd64/sync.a
packagefile sync/atomic=/usr/local/go/pkg/darwin_amd64/sync/atomic.a
packagefile syscall=/usr/local/go/pkg/darwin_amd64/syscall.a
packagefile time=/usr/local/go/pkg/darwin_amd64/time.a
EOF
cd /usr/local/go/src/net
/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b002/_pkg_.a -trimpath 
$WORK/b002 -p net -std -buildid _tpOUnWlUki4sCfaeRYL/_tpOUnWlUki4sCfaeRYL 
-goversion go1.10.3 -D "" -importcfg $WORK/b002/importcfg -pack -c=4 
./addrselect.go ./cgo_stub.go ./conf.go ./dial.go ./dnsclient.go 
./dnsclient_unix.go ./dnsconfig_unix.go ./dnsmsg.go ./error_posix.go 
./fd_unix.go ./file.go ./file_unix.go ./hook.go ./hook_unix.go ./hosts.go 
./interface.go ./interface_bsd.go ./interface_darwin.go ./ip.go 
./iprawsock.go ./iprawsock_posix.go ./ipsock.go ./ipsock_posix.go 
./lookup.go ./lookup_unix.go ./mac.go ./net.go ./nss.go ./parse.go 
./pipe.go ./port.go ./port_unix.go ./rawconn.go ./sendfile_stub.go 
./sock_bsd.go ./sock_posix.go ./sockopt_bsd.go ./sockopt_posix.go 
./sockoptip_bsdvar.go ./sockoptip_posix.go ./sys_cloexec.go ./tcpsock.go 
./tcpsock_posix.go ./tcpsockopt_darwin.go ./tcpsockopt_posix.go 
./udpsock.go ./udpsock_posix.go ./unixsock.go ./unixsock_posix.go 
./writev_unix.go
/usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b002/_pkg_.a # internal
cp $WORK/b002/_pkg_.a 
/root/.cache/go-build/71/71d5652836fbf72132d2864101b08cfb7dc5657beaa4cd0804e7d893646a3d60-d
 
# internal
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile net=$WORK/b002/_pkg_.a
packagefile runtime=/usr/local/go/pkg/darwin_amd64/runtime.a
EOF
cd /workspace/src/go.example.com/dns
/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath 
$WORK/b001 -p main -complete -buildid 
t_6XipuZQQ3V_Rlugib8/t_6XipuZQQ3V_Rlugib8 -goversion go1.10.3 -D "" 
-importcfg $WORK/b001/importcfg -pack -c=4 ./main.go
/usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a 
/root/.cache/go-build/35/35e87cb5622549aaa8a434a32334706a5b3862ff7d49ce9daf3b29ba88094f41-d
 
# internal
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile go.example.com/dns=$WORK/b001/_pkg_.a
packagefile net=$WORK/b002/_pkg_.a
packagefile runtime=/usr/local/go/pkg/darwin_amd64/runtime.a
packagefile context=/usr/local/go/pkg/darwin_amd64/context.a
packagefile errors=/usr/local/go/pkg/darwin_amd64/errors.a
packagefile 
vendor/golang_org/x/net/route=/usr/local/go/pkg/darwin_amd64/vendor/golang_org/x/net/route.a
packagefile 
internal/nettrace=/usr/local/go/pkg/darwin_amd64/internal/nettrace.a
packagefile internal/poll=/usr/local/go/pkg/darwin_amd64/internal/poll.a
packagefile 
internal/singleflight=/usr/local/go/pkg/darwin_amd64/internal/singleflight.a
packagefile io=/usr/local/go/pkg/darwin_amd64/io.a
packagefile math/rand=/usr/local/go/pkg/darwin_amd64/math/rand.a
packagefile os=/usr/local/go/pkg/darwin_amd64/os.a
packagefile sort=/usr/local/go/pkg/darwin_amd64/sort.a
packagefile sync=/usr/local/go/pkg/darwin_amd64/sync.a
packagefile sync/atomic=/usr/local/go/pkg/darwin_amd64/sync/atomic.a
packagefile syscall=/usr/local/go/pkg/darwin_amd64/syscall.a
packagefile time=/usr/local/go/pkg/darwin_amd64/time.a

Re: [go-nuts] go1.11 no longer supports compressed hostnames in SRV lookup replies

[jason]

We have traced the issue to the Kubernetes DNS server, kube-dns. It is 
returning compressed hostnames in SRV query responses. It can be reproduced 
by running 

The following app exits with an error in MiniKube (or any other Kubernetes 
cluster with kube-dns). 

cannot unmarshal DNS message - Target: compressed name in SRV resource data

func main() {
  _,_, err := net.LookupSRV("dns-tcp", "tcp", "kube-dns.kube-system")
  if err != nil {
log.Fatal(err)
  }
}

Is it worth creating an issue around this? We have extracted the DNS client 
from `net` and are currently using it with the compressed flag enabled to 
allow compressed hostnames - the behavior that existed in go 1.10 and 
earlier.


On Wednesday, August 29, 2018 at 4:57:04 PM UTC-6, Jason Newman wrote:
>
> This code works in our Kubernetes cluster when compiled with Go 1.10 and 
> does not work when compiled with Go 1.11, we are using the built-in Go 
> resolver.
>
> https://play.golang.org/p/JNSJEm1n6hg
>
> On Wednesday, August 29, 2018 at 4:28:54 PM UTC-6, Nathan Fisher wrote:
>>
>> Can you share examples?
>> On Wed, Aug 29, 2018 at 19:08,  wrote:
>>
>>> We are using SRV records in Kubernetes for various purposes and Go 1.11 
>>> no longer supports compressed names in SRV resource data (
>>> https://github.com/golang/net/commit/24dd3780ca4f75fed9f321890729414a4b5d3f13#diff-47e2241916c7047eab73daf76c89fc3fR2055).
>>>  
>>> The error we are getting is "cannot unmarshal DNS message" and the 
>>> underlying error is "Target: compressed name in SRV resource data".
>>>
>>> Ultimately, we believe the issue lies with dnsmasq returning a 
>>> non-compliant SRV response, but it is stopping us from upgrading to Go1.11. 
>>> Are there any known workarounds which would allow us to handle these 
>>> noncompliant SRV responses?
>>>
>>>
>>>
>>>
>>> -- 
>>> 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.
>>>
>> -- 
>> - sent from my mobile
>>
>

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

Re: [go-nuts] How to make UDP server performance better?

[Matt Harden]

The time spent in the syscall would include time blocked, waiting for a
packet to arrive. I would look at the other parts of the profile for
possible improvements. The kernel may also be dropping packets if there is
not enough buffer space to receive them into; see the SO_RCVBUF socket
option. Maybe ntpd sets this option to a larger value than the default.

On Mon, Aug 27, 2018 at 4:42 AM Zhuo Meng  wrote:

> Hi, Gophers
>
> I'm doing benmarking for my GoNTPd 
> .
>
> I found that my implement is only can handle about 100Kpps (kilo packets
> per second) per goroutine while ntpd can handle about 170 Kpps. on Intel
> Xeon E312
> The pprof shows most of function time spend on syscall.Syscall6
> (Read/Write from UDP socket), how can I improve that?
>
> Many thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Agniva De Sarker]

We will shift over the features from godoc to "go doc" before removing 
support, so that the output remains consistent. I think there is already an 
open issue for exactly what you have shown above. So no worries, things 
will be the same.

On Friday, 31 August 2018 02:16:54 UTC+5:30, John Shahid wrote:
>
>
> Agniva De Sarker > writes: 
>
> > Also - note that godoc cli mode is going to go away. So "godoc -links=0 
> > -html domain.com/group/project/v3/lib/foo" is not going to work after 
> 1.12. 
> > You should be using the http server. If you want command line help, use 
> "go 
> > doc". 
>
> Is there a way to get the same output as godoc ? `go doc' lists the 
> exported symbols but not their documentation.  For example the following 
> is what I get from `godoc' 
>
> func ResolveIPAddr(network, address string) (*IPAddr, error) 
> ResolveIPAddr returns an address of IP end point. 
>
> The network must be an IP network name. 
>
> If the host in the address parameter is not a literal IP address, 
> ResolveIPAddr resolves the address to an address of IP end point. 
> Otherwise, it parses the address as a literal IP address. The 
> address 
> parameter can use a host name, but this is not recommended, 
> because it 
> will return at most one of the host name's IP addresses. 
>
> See func Dial for a description of the network and address 
> parameters. 
>
>
> as opposed to the following less useful `go doc' output: 
>
> func Pipe() (Conn, Conn) 
> func ResolveIPAddr(network, address string) (*IPAddr, error) 
> func ResolveTCPAddr(network, address string) (*TCPAddr, error) 
>
> I have been relying on this behavior for a long time to open up the 
> documentation of a package and just search for the method I'm using. 
> Instead of having to open the docs for each method/symbol separately. 
>
> Thanks, 
>
> -js 
>

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

[Agniva De Sarker]

Hmm .. you can still generate html docs in a round-about fashion by 
spinning up the godoc server and storing the response of the http request 
of the package path.

Otherwise, you are free to use the godoc2md tool 
- https://github.com/davecheney/godoc2md, which generates markdown pages 
from a package path. It's a great way to generate static docs.

On Friday, 31 August 2018 01:39:06 UTC+5:30, Justin Israel wrote:
>
>
>
> On Thu, Aug 30, 2018, 9:54 PM Agniva De Sarker  > wrote:
>
>> I had filed https://github.com/golang/go/issues/26827 to list the 
>> changes that godoc needs to make. Please feel free to add your comments 
>> there.
>>
>> Also - note that godoc cli mode is going to go away. So "godoc -links=0 
>> -html domain.com/group/project/v3/lib/foo" is not going to work after 
>> 1.12. You should be using the http server. If you want command line help, 
>> use "go doc".
>>
>
> Fair enough. I should just discontinue the feature we have in our build 
> systems Go tool. It was neat to generate html docs with our deploys. 
>
>
>> - Agniva
>>
>>
>> On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>>>
>>> Thanks for that update, Paul!
>>>
>>> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly  wrote:
>>>
 Perhaps better (because of the automatic linking, status updates etc)
 is to create issues in respective tools under the umbrella of
 https://github.com/golang/go/issues/24661

 Indeed I know there are a number of such issues, so it's just a case
 of linking those from #24661.
 On Wed, 29 Aug 2018 at 07:46, wilk  wrote:
 >
 >
 > It could be fine to start a wiki page to list the tools and ide
 > (not)ready for modules with the linked issues.
 >
 > In https://github.com/golang/go/wiki/Modules or a new page ?
 >
 > On 29-08-2018, Paul Jolly wrote:
 > > --50127c057491b176
 > > Content-Type: text/plain; charset="UTF-8"
 > >
 > > Please see https://github.com/golang/gddo/issues/567
 > >
 > > On Tue, 28 Aug 2018, 18:59 Justin Israel,  
 wrote:
 > >
 > >> I've been trying out converting some of our internal projects to 
 go 1.11
 > >> using modules instead of glide. We have a build system that 
 provides the
 > >> ability to generate html docs via "godoc" and I am wondering if 
 godoc has
 > >> been made "module-aware" in go 1.11?
 > >>
 > >> My particular project is using the migration approach of setting 
 "v3" at
 > >> in the go.mod, and in all import paths within the project. But it 
 seems
 > >> godoc is not happy about this:
 > >>
 > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
 > >>
 > >> 2018/08/29 11:52:12 error while importing build package: cannot 
 find package "domain.com/group/project/v3/lib/foo" in any of:
 > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo 
 (from $GOROOT)
 > >> /usr/home/justin/src/go/src/
 domain.com/group/project/v3/lib/foo (from $GOPATH)
 > >> 2018/08/29 11:52:12 cannot find package "." in:
 > >> /src/domain.com/group/project/v3/lib/foo
 > >>
 > >>
 > >> It seems to only care about the filesystem structure and not the 
 module import path naming?
 > >>
 > >>
 > >> Justin
 > >>
 > >>
 > >> --
 > >> You received this message because you are subscribed to the Google 
 Groups
 > >> "golang-nuts" group.
 > >> To unsubscribe from this group and stop receiving emails from it, 
 send an
 > >> email to golang-nuts...@googlegroups.com.
 > >> For more options, visit https://groups.google.com/d/optout.
 > >>
 > >
 >
 >
 > --
 > William
 >
 > --
 > 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...@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...@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 

Re: [go-nuts] Reference to type satisfying a specified interface

[Nigel Tao]

On Fri, Aug 31, 2018 at 11:41 AM Eric Raymond  wrote:
> On Thursday, August 30, 2018 at 8:31:44 PM UTC-4, Ian Lance Taylor wrote:
>> Which docs did you look at?  Just wondering what could be updated.
>
> This:  https://research.swtch.com/interfaces

I'm only guessing, but I think Ian's "which docs did you look at" was
referring to your previous "I was unable to extract this enlightenment
from the documentation, despite sweating over it pretty hard", before
https://research.swtch.com/interfaces was mentioned.

-- 
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] Some background on reposurgeon and my Go translation problem

[Eric Raymond]

There's been enough interest here in the technical questions I've been 
raising recently that a bit of a backgrounder seems in order.

Back in 2010 I noticed that git's fast-import stream format opened up some 
possibilities its designers probably hadn't anticipated. Their original 
motivation was to make it easy to write exporters from other 
version-control systems.  Their offer was this: here's a flat-file format 
that can serialize the entire state of a git repository.  If you can dump 
your repository state from random version control system X in this format, 
we can reanimate the history in git.

This was a very clever idea, and lots of people proceeded to write 
exporters on this model.  A few VCS implementers, noticing that this 
implied a vast  one way traffic of user attention away from them and 
towards git, wrote importers that could consume fast-export streams from 
git back *to *random version-control system X.  I noticed that the effect 
was to turn git stream dumps into a de-facto exchange standard for 
version-control histories.

One of my quirks is that I like thinking about version-control systems and 
the tools around them.  I had been noticing for years that most repository 
conversion tools are pretty bad in a specific way.  They tend to try to 
over-automate the process, producing brute-force conversions full of crufty 
artifacts and minor defects around the places where the data models of 
source and target systems don't quite match.  There were, at the time, no 
tools fit for a human to fix these problems.

Reposurgeon implements - in Python - a domain-specific language for 
describing surgical operation on repositories.  It can be run in batch mode 
or as an interactive structure editor for doing forensics on damaged 
repository metadata.  It works by calling a front end to get a stream dump 
of the repository you want to edit, deserializing the dump into an 
attributed graph, supporting a full repertoire of operations on that graph, 
and then writing the result out as a stream dump fed to an importer for the 
target system.

The target system can be the same as the source.  Or a different one.  
There are front-end/back-end pairs to support RCS, CVS, Subversion, git, 
mercurial, darcs, monotone,  bitkeeper, bzr, and src. Not all of these 
combinations are well-tested, but moves from CVS, Subversion, git, bzr, and 
mercurial to git or mercurial are pretty solid.

My conjecture that a human-driven tool with good exploratory capabilities 
would produce higher-quality history translations than fully-automated 
converters rapidly proved correct, rather dramatically so in fact. 
Reposurgeon has been the key tool for a great many high-complexity, 
high-risk history translations.  Probably the most consequential single 
success was moving the history of GNU Emacs from bzr to git, cleaning up a 
lot of ancient cruft from RCS and CVS along the way.

Below the size of GCC, which IIRC was around 40K commits, Python gave me 
reasonable turnaround times. This is important if you need to do a lot of 
exploration to find a good conversion recipe, which you always do with 
these large old histories.  But there was an adverse-selection effect.  The 
average size of the histories people wanted by to convert kept increasing. 
Eventually I ended up designing a semi-custom PC optimized for the job 
load, with high CPU-to-memory bandwidth and beefy primary caches to enable 
it to handle large working sets - graph-theory problems gigabytes wide.  
Its fans call it the Great Beast, and three years after it was built you 
still can't spec a machine that performs better from COTS parts.

(That may change soon. The guy who actually put togeether the Beast for me 
is contemplating an upgrade based on the Cascade Lake chipset due out from 
Intel in Q4.  His plan is to build one for me and another for Linus 
Torvalds. The clever fellow has sponsors lined up a block long to be in the 
build video.)

Then came GCC.  The GCC repository is over 259K commits.  It brings the 
Great Beast to its knees. Minimum 9-hour times for test conversions, which 
is intolerable. I concluded that Python doesn't just cut it at this scale.  
I then shopped for a new language pretty carefully before choosing Go.  
Compiled Lisp was a contender, and I even briefly considered OCaml.  Go won 
in part because the semantic distance from Python is not all that large, 
considering the whole late-binding issue.

Python reposurgeon is about 14KLOC  of code.  In six days I've translated 
about 11% of it, building unit tests as I go. (There's already a very 
strong set of functional and end-to-end tests. There has to be; I wouldn't 
dare modify it otherwise. To say it's become algorithmically dense enough 
to be tricky to change would be to wallow in understatement...)

However, this is only my second Go project.  My first was a finger 
exercise, a re-implementation of David A. Wheeler's sloccount tool.  So I'm 
in a weird place where I'm 

Re: [go-nuts] Reference to type satisfying a specified interface

[Eric Raymond]

On Thursday, August 30, 2018 at 8:31:44 PM UTC-4, Ian Lance Taylor wrote:
>
> > That was helpful.  I feel like I have a more solid grasp  now, though 
> I'm a 
> > bit worried about what details might have changed.  Is there any chance 
> of 
> > getting the author to update this and add it to the official Go 
> > documentation? 
>
> Conceptually speaking, nothing has changed. 
>
> Which docs did you look at?  Just wondering what could be updated. 
>

This:  https://research.swtch.com/interfaces 

It did look rather like the abstractions had not changed, but I don't have 
the expertise to be sure.

I'm successfully writing type switches on my Events now, so that is 
significant progress. I expect the  rest of the translation to be tedious 
but not conceptually difficult. All 13KLOC of it,  ouch.

Oh, actually, I have one other issue; how to translate virtual methods in a 
Python base class into Go's object model.  I'll start another thread about 
that.

-- 
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: parse date/time with comma before millis

[peterGo]

Adam,

In Go, it's usual to hide any ugliness in a function. For example,

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

Peter

On Thursday, August 30, 2018 at 7:21:33 PM UTC-4, skirmish wrote:
>
> In example code here; https://play.golang.org/p/4P2nH_KE8uu
>
> I'm trying to parse a date time string of the form 2015-09-09 15:21:08,431 
> but 
> using the format of 2006-01-02 15:04:05,999 (among many others that I've 
> tried) which I'd expect to work, the time.Parse doesn't want to take the 
> format. Looking through time.Parse, it seems it doesn't ever want to accept 
> a comma before millis, is this true? For now, I'm using a strings.Replace 
> to get rid of the comma, but it just feels bad.
>
> I feel like I'm doing it wrong, and as ever I can't change the app 
> generating the data I'm parsing.
>
> --adam
>

-- 
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] Reference to type satisfying a specified interface

[Ian Lance Taylor]

On Thu, Aug 30, 2018 at 4:50 PM, Eric Raymond  wrote:
>
> On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote:
>>
>> On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar  wrote:
>> > If b is an interface to a *Blob, what's stored in the slice is {Type:
>> > *Blob, Value: pointer to the object}. A copy of this interface value
>> > is also in the map. So you have two copies of the interface value,
>> > both pointing to the same Blob object.
>>
>> Yes, the details might have changed slightly since 2009, but
>> https://research.swtch.com/interfaces might help grok the mental model
>> for Go interfaces.
>
>
> That was helpful.  I feel like I have a more solid grasp  now, though I'm a
> bit worried about what details might have changed.  Is there any chance of
> getting the author to update this and add it to the official Go
> documentation?

Conceptually speaking, nothing has changed.

Which docs did you look at?  Just wondering what could be updated.

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] Reference to type satisfying a specified interface

[Eric Raymond]

On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote:
>
> On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar  > wrote: 
> > If b is an interface to a *Blob, what's stored in the slice is {Type: 
> > *Blob, Value: pointer to the object}. A copy of this interface value 
> > is also in the map. So you have two copies of the interface value, 
> > both pointing to the same Blob object. 
>
> Yes, the details might have changed slightly since 2009, but 
> https://research.swtch.com/interfaces might help grok the mental model 
> for Go interfaces. 
>

That was helpful.  I feel like I have a more solid grasp  now, though I'm a 
bit worried about what details might have changed.  Is there any chance of 
getting the author to update this and add it to the official Go 
documentation?

-- 
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] Reference to type satisfying a specified interface

[Nigel Tao]

On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar  wrote:
> If b is an interface to a *Blob, what's stored in the slice is {Type:
> *Blob, Value: pointer to the object}. A copy of this interface value
> is also in the map. So you have two copies of the interface value,
> both pointing to the same Blob object.

Yes, the details might have changed slightly since 2009, but
https://research.swtch.com/interfaces might help grok the mental model
for Go interfaces.

-- 
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] reflect to get value type of a map

[Dan Kortschak]

The Type.Elem method gets you that.

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

On Thu, 2018-08-30 at 18:06 -0500, Mark Volkmann wrote:
> I see that I can use the `reflect` package to get the key type of a
> map
> like this:
> 
> ```go
> mt := reflect.TypeOf(myMap)
> fmt.Println("key type is", mt.Key())
> ```
> 
> But I don't see a way to get the value type of a map. Is there a
> method to
> do this?
> 
> -- 
> R. Mark Volkmann
> Object Computing, Inc.
> 

-- 
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] parse date/time with comma before millis

[skirmish]

In example code here; https://play.golang.org/p/4P2nH_KE8uu

I'm trying to parse a date time string of the form 2015-09-09 15:21:08,431 but 
using the format of 2006-01-02 15:04:05,999 (among many others that I've 
tried) which I'd expect to work, the time.Parse doesn't want to take the 
format. Looking through time.Parse, it seems it doesn't ever want to accept 
a comma before millis, is this true? For now, I'm using a strings.Replace 
to get rid of the comma, but it just feels bad.

I feel like I'm doing it wrong, and as ever I can't change the app 
generating the data I'm parsing.

--adam

-- 
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] reflect to get value type of a map

[Mark Volkmann]

I see that I can use the `reflect` package to get the key type of a map
like this:

```go
mt := reflect.TypeOf(myMap)
fmt.Println("key type is", mt.Key())
```

But I don't see a way to get the value type of a map. Is there a method to
do this?

-- 
R. Mark Volkmann
Object Computing, Inc.

-- 
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: runtime: invalid pc-encoded table (invalid runtime symbol table)

[Krzysztof Kowalczyk]

The second issue is a bug in runtime, which might be fixed in 1.11 
(https://github.com/golang/go/issues/24925 
and https://github.com/golang/go/issues/25499 
and https://github.com/golang/go/issues/24634 look like might be the issue).

The original issue is that storage library calls Client.Do() on nil 
*http.Client which eventually crashes.

This could be a bug in the library but more likely a bug in how you use the 
library.

Skimming the code of storage library, it can be triggered if you call 
client.Close() before calling Download().
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/storage/storage.go#L114
(this clears c.hc which is *http.Client on which Do() is called which 
causes a crash).

-- kjk

On Thursday, August 30, 2018 at 12:22:39 PM UTC-7, Ewan Walker wrote:
>
> I've been trying to trace a crash (seemingly from a dependency) for quite 
> some time:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x656492]
>
>
> goroutine 86 [running]:
> net/http.(*Client).deadline(0x0, 0xc42e2dc0b0, 0xc420456be0, 0x0)
> /usr/local/go/src/net/http/client.go:189 +0x22
> net/http.(*Client).Do(0x0, 0xc42054c800, 0xc43631e237, 0x1, 0xc450328900)
> /usr/local/go/src/net/http/client.go:500 +0x86
> vendor/
> cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2.1(0xc450328988,
>  
> 0x5da16f)
> /src/vendor/cloud.google.com/go/storage/reader.go:100 +0x64
> vendor/cloud.google.com/go/storage.runWithRetry.func1(0x0, 0x0, 
> 0xc450328a20)
> /src/vendor/cloud.google.com/go/storage/invoke.go:27 +0x2a
> vendor/cloud.google.com/go/internal.retry(0x7ff670cac2a8, 0xc45032cde0, 
> 0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0xd1b648, 0xc42005dc00, 0x688335)
> /src/vendor/cloud.google.com/go/internal/retry.go:39 +0x4c
> vendor/cloud.google.com/go/internal.Retry(0x7ff670cac2a8, 0xc45032cde0, 
> 0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0x80, 0x80)
> /src/vendor/cloud.google.com/go/internal/retry.go:32 +0x82
> vendor/cloud.google.com/go/storage.runWithRetry(0x7ff670cac2a8, 
> 0xc45032cde0, 0xc450328b88, 0xc42005dc00, 0xc4205ca800)
> /src/vendor/cloud.google.com/go/storage/invoke.go:26 +0x73
> vendor/
> cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2(0x0, 
> 0xc420456b80, 0x0, 0x0)
> /src/vendor/cloud.google.com/go/storage/reader.go:99 +0x125
> vendor/
> cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader(0xc445af0210, 
> 0x7ff670cac2a8, 0xc45032cde0, 0x0, 0x, 0x0, 0xc43b62a600, 
> 0x7ff670c5f1d0)
> /src/vendor/cloud.google.com/go/storage/reader.go:129 +0x5bf
> vendor/cloud.google.com/go/storage.(*ObjectHandle).NewReader(0xc445af0210, 
> 0x7ff670c5f1d0, 0xc43b62a660, 0x7ff670c5f1d0, 0xc43b62a660, 0xc43cbc4690)
> /src/vendor/cloud.google.com/go/storage/reader.go:42 +0x51
> project/storage/cloud.(*Client).Download(0xc4204f69f0, 0xc429129f00, 0x13, 
> 0xcea887, 0x6, 0xc4205ff798, 0x8, 0x0, 0xc420335080, 0x18)
> /src/project/storage/cloud/client.go:306 +0x3e2
> project/storage/retention.insert.download(0xc420018600, 0x0, 0x0, 
> 0xbed7eea2f2ff5d40, 0x98b539fed9f, 0x11f7e60)
> /src/project/storage/retention/insert.go:303 +0x96
> project/storage/retention.(*insert).Run(0xc4220f60c0, 0x0, 0x0)
> /src/project/storage/retention/insert.go:82 +0x2a7
> project/storage/retention.(*repair).Run(0xc42000e580, 0x98b539bca2f, 
> 0x11f7e60)
> /src/project/storage/retention/repair.go:62 +0x7e9
> project/storage/retention.(*Client).sync(0xc42052e150, 0xc42025, 0x1f, 
> 0x20, 0x0, 0x0)
> /src/project/storage/retention/client.go:371 +0x2cb
> project/storage/retention.(*Client).Run(0xc42052e150, 0x0, 0x0)
> /src/project/storage/retention/client.go:222 +0x137
> project/storage.Engine.retention(0xc4200b9d80, 0xc4201d9e00, 0xc42052e150, 
> 0xc4200b7630)
> /src/project/storage/engine.go:90 +0x43
> created by project/storage.New
> /src/project/storage/engine.go:55 +0x270
>
>
> To prevent the problem I've added a defer'd recover to try to catch the 
> exception, however now I'm getting:
>
>
> runtime: invalid pc-encoded table f=net/http.(*conn).readRequest 
> pc=0x6934d3 targetpc=0x6934da tab=[0/0]0x0
> value=0 until pc=0x692812
> value=304 until pc=0x692bcb
> value=0 until pc=0x692bcc
> value=304 until pc=0x692c76
> value=0 until pc=0x692c77
> value=304 until pc=0x692f96
> value=0 until pc=0x692f97
> value=304 until pc=0x693114
> value=0 until pc=0x693115
> value=304 until pc=0x693154
> value=0 until pc=0x693155
> value=304 until pc=0x6931bc
> value=0 until pc=0x6931bd
> value=304 until pc=0x6932c1
> value=0 until pc=0x6932c2
> value=304 until pc=0x693316
> value=0 until pc=0x693317
> value=304 until pc=0x693338
> value=0 

Re: [go-nuts] runtime: invalid pc-encoded table (invalid runtime symbol table)

[Ewan Walker]

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Minute)

reader, err := object.NewReader(ctx)
if err != nil {
//handle
}

Likely then an issue with the cloud storage library when it needs to retry! 
That is what I had figured... I'm going to have to open an issue there.

On Thursday, August 30, 2018 at 4:26:47 PM UTC-4, Borman, Paul wrote:
>
> Looks like a nil context? 
>
> vendor/cloud.google.com/go/storage.runWithRetry.func1(0x0, 0x0, 
> 0xc450328a20)
>
> 100  err = runWithRetry(ctx, func() error {
>
> -Paul
>
> On Aug 30, 2018, at 1:05 PM, Ewan Walker  > wrote:
>
> I've been trying to trace a crash (seemingly from a dependency) for quite 
> some time: 
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x656492]
>
>
> goroutine 86 [running]:
> net/http.(*Client).deadline(0x0, 0xc42e2dc0b0, 0xc420456be0, 0x0)
> /usr/local/go/src/net/http/client.go:189 +0x22
> net/http.(*Client).Do(0x0, 0xc42054c800, 0xc43631e237, 0x1, 0xc450328900)
> /usr/local/go/src/net/http/client.go:500 +0x86
> vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2.1(0xc450328988,
>  
> 0x5da16f)
> /src/vendor/cloud.google.com/go/storage/reader.go:100 +0x64
> vendor/cloud.google.com/go/storage.runWithRetry.func1(0x0, 0x0, 
> 0xc450328a20)
> /src/vendor/cloud.google.com/go/storage/invoke.go:27 +0x2a
> vendor/cloud.google.com/go/internal.retry(0x7ff670cac2a8, 0xc45032cde0, 
> 0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0xd1b648, 0xc42005dc00, 0x688335)
> /src/vendor/cloud.google.com/go/internal/retry.go:39 +0x4c
> vendor/cloud.google.com/go/internal.Retry(0x7ff670cac2a8, 0xc45032cde0, 
> 0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0x80, 0x80)
> /src/vendor/cloud.google.com/go/internal/retry.go:32 +0x82
> vendor/cloud.google.com/go/storage.runWithRetry(0x7ff670cac2a8, 
> 0xc45032cde0, 0xc450328b88, 0xc42005dc00, 0xc4205ca800)
> /src/vendor/cloud.google.com/go/storage/invoke.go:26 +0x73
> vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2(0x0, 
> 0xc420456b80, 0x0, 0x0)
> /src/vendor/cloud.google.com/go/storage/reader.go:99 +0x125
> vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader(0xc445af0210,
>  
> 0x7ff670cac2a8, 0xc45032cde0, 0x0, 0x, 0x0, 0xc43b62a600, 
> 0x7ff670c5f1d0)
> /src/vendor/cloud.google.com/go/storage/reader.go:129 +0x5bf
> vendor/cloud.google.com/go/storage.(*ObjectHandle).NewReader(0xc445af0210, 
> 0x7ff670c5f1d0, 0xc43b62a660, 0x7ff670c5f1d0, 0xc43b62a660, 0xc43cbc4690)
> /src/vendor/cloud.google.com/go/storage/reader.go:42 +0x51
> project/storage/cloud.(*Client).Download(0xc4204f69f0, 0xc429129f00, 0x13, 
> 0xcea887, 0x6, 0xc4205ff798, 0x8, 0x0, 0xc420335080, 0x18)
> /src/project/storage/cloud/client.go:306 +0x3e2
> project/storage/retention.insert.download(0xc420018600, 0x0, 0x0, 
> 0xbed7eea2f2ff5d40, 0x98b539fed9f, 0x11f7e60)
> /src/project/storage/retention/insert.go:303 +0x96
> project/storage/retention.(*insert).Run(0xc4220f60c0, 0x0, 0x0)
> /src/project/storage/retention/insert.go:82 +0x2a7
> project/storage/retention.(*repair).Run(0xc42000e580, 0x98b539bca2f, 
> 0x11f7e60)
> /src/project/storage/retention/repair.go:62 +0x7e9
> project/storage/retention.(*Client).sync(0xc42052e150, 0xc42025, 0x1f, 
> 0x20, 0x0, 0x0)
> /src/project/storage/retention/client.go:371 +0x2cb
> project/storage/retention.(*Client).Run(0xc42052e150, 0x0, 0x0)
> /src/project/storage/retention/client.go:222 +0x137
> project/storage.Engine.retention(0xc4200b9d80, 0xc4201d9e00, 0xc42052e150, 
> 0xc4200b7630)
> /src/project/storage/engine.go:90 +0x43
> created by project/storage.New
> /src/project/storage/engine.go:55 +0x270
>
>
> To prevent the problem I've added a defer'd recover to try to catch the 
> exception, however now I'm getting:
>
>
> runtime: invalid pc-encoded table f=net/http.(*conn).readRequest 
> pc=0x6934d3 targetpc=0x6934da tab=[0/0]0x0
> value=0 until pc=0x692812
> value=304 until pc=0x692bcb
> value=0 until pc=0x692bcc
> value=304 until pc=0x692c76
> value=0 until pc=0x692c77
> value=304 until pc=0x692f96
> value=0 until pc=0x692f97
> value=304 until pc=0x693114
> value=0 until pc=0x693115
> value=304 until pc=0x693154
> value=0 until pc=0x693155
> value=304 until pc=0x6931bc
> value=0 until pc=0x6931bd
> value=304 until pc=0x6932c1
> value=0 until pc=0x6932c2
> value=304 until pc=0x693316
> value=0 until pc=0x693317
> value=304 until pc=0x693338
> value=0 until pc=0x693339
> value=304 until pc=0x6933ef
> value=0 until pc=0x6933f0
> value=304 until pc=0x6934c8
> value=0 until pc=0x6934d3
> fatal error: invalid runtime symbol table
>
> 

Re: [go-nuts] Re: Is the go 1.11 godoc tool 'module-aware'?

[Paul Jolly]

cc Ian Cottrell
On Thu, 30 Aug 2018 at 14:08, Justin Israel  wrote:
>
>
>
> On Thu, Aug 30, 2018, 9:54 PM Agniva De Sarker  
> wrote:
>>
>> I had filed https://github.com/golang/go/issues/26827 to list the changes 
>> that godoc needs to make. Please feel free to add your comments there.
>>
>> Also - note that godoc cli mode is going to go away. So "godoc -links=0 
>> -html domain.com/group/project/v3/lib/foo" is not going to work after 1.12. 
>> You should be using the http server. If you want command line help, use "go 
>> doc".
>
>
> Fair enough. I should just discontinue the feature we have in our build 
> systems Go tool. It was neat to generate html docs with our deploys.
>
>>
>> - Agniva
>>
>>
>> On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>>>
>>> Thanks for that update, Paul!
>>>
>>> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly  wrote:

 Perhaps better (because of the automatic linking, status updates etc)
 is to create issues in respective tools under the umbrella of
 https://github.com/golang/go/issues/24661

 Indeed I know there are a number of such issues, so it's just a case
 of linking those from #24661.
 On Wed, 29 Aug 2018 at 07:46, wilk  wrote:
 >
 >
 > It could be fine to start a wiki page to list the tools and ide
 > (not)ready for modules with the linked issues.
 >
 > In https://github.com/golang/go/wiki/Modules or a new page ?
 >
 > On 29-08-2018, Paul Jolly wrote:
 > > --50127c057491b176
 > > Content-Type: text/plain; charset="UTF-8"
 > >
 > > Please see https://github.com/golang/gddo/issues/567
 > >
 > > On Tue, 28 Aug 2018, 18:59 Justin Israel,  wrote:
 > >
 > >> I've been trying out converting some of our internal projects to go 
 > >> 1.11
 > >> using modules instead of glide. We have a build system that provides 
 > >> the
 > >> ability to generate html docs via "godoc" and I am wondering if godoc 
 > >> has
 > >> been made "module-aware" in go 1.11?
 > >>
 > >> My particular project is using the migration approach of setting "v3" 
 > >> at
 > >> in the go.mod, and in all import paths within the project. But it 
 > >> seems
 > >> godoc is not happy about this:
 > >>
 > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
 > >>
 > >> 2018/08/29 11:52:12 error while importing build package: cannot find 
 > >> package "domain.com/group/project/v3/lib/foo" in any of:
 > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo 
 > >> (from $GOROOT)
 > >> 
 > >> /usr/home/justin/src/go/src/domain.com/group/project/v3/lib/foo (from 
 > >> $GOPATH)
 > >> 2018/08/29 11:52:12 cannot find package "." in:
 > >> /src/domain.com/group/project/v3/lib/foo
 > >>
 > >>
 > >> It seems to only care about the filesystem structure and not the 
 > >> module import path naming?
 > >>
 > >>
 > >> Justin
 > >>
 > >>
 > >> --
 > >> You received this message because you are subscribed to the Google 
 > >> Groups
 > >> "golang-nuts" group.
 > >> To unsubscribe from this group and stop receiving emails from it, 
 > >> send an
 > >> email to golang-nuts...@googlegroups.com.
 > >> For more options, visit https://groups.google.com/d/optout.
 > >>
 > >
 >
 >
 > --
 > William
 >
 > --
 > 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...@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.

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

Re: [go-nuts] runtime: invalid pc-encoded table (invalid runtime symbol table)

['Borman, Paul' via golang-nuts]

Looks like a nil context?

vendor/cloud.google.com/go/storage.runWithRetry.func1(0x0,
 0x0, 0xc450328a20)

100  err = runWithRetry(ctx, func() error {

-Paul

On Aug 30, 2018, at 1:05 PM, Ewan Walker 
mailto:e...@grandslammedia.com>> wrote:

I've been trying to trace a crash (seemingly from a dependency) for quite some 
time:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x656492]


goroutine 86 [running]:
net/http.(*Client).deadline(0x0, 0xc42e2dc0b0, 0xc420456be0, 0x0)
/usr/local/go/src/net/http/client.go:189 +0x22
net/http.(*Client).Do(0x0, 0xc42054c800, 0xc43631e237, 0x1, 0xc450328900)
/usr/local/go/src/net/http/client.go:500 +0x86
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2.1(0xc450328988,
 0x5da16f)

/src/vendor/cloud.google.com/go/storage/reader.go:100
 +0x64
vendor/cloud.google.com/go/storage.runWithRetry.func1(0x0,
 0x0, 0xc450328a20)

/src/vendor/cloud.google.com/go/storage/invoke.go:27
 +0x2a
vendor/cloud.google.com/go/internal.retry(0x7ff670cac2a8,
 0xc45032cde0, 0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0xd1b648, 0xc42005dc00, 
0x688335)

/src/vendor/cloud.google.com/go/internal/retry.go:39
 +0x4c
vendor/cloud.google.com/go/internal.Retry(0x7ff670cac2a8,
 0xc45032cde0, 0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0x80, 0x80)

/src/vendor/cloud.google.com/go/internal/retry.go:32
 +0x82
vendor/cloud.google.com/go/storage.runWithRetry(0x7ff670cac2a8,
 0xc45032cde0, 0xc450328b88, 0xc42005dc00, 0xc4205ca800)

/src/vendor/cloud.google.com/go/storage/invoke.go:26
 +0x73
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2(0x0,
 0xc420456b80, 0x0, 0x0)

/src/vendor/cloud.google.com/go/storage/reader.go:99
 +0x125
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader(0xc445af0210,
 0x7ff670cac2a8, 0xc45032cde0, 0x0, 0x, 0x0, 0xc43b62a600, 
0x7ff670c5f1d0)

/src/vendor/cloud.google.com/go/storage/reader.go:129
 +0x5bf
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewReader(0xc445af0210,
 0x7ff670c5f1d0, 0xc43b62a660, 0x7ff670c5f1d0, 0xc43b62a660, 0xc43cbc4690)

/src/vendor/cloud.google.com/go/storage/reader.go:42
 +0x51
project/storage/cloud.(*Client).Download(0xc4204f69f0, 0xc429129f00, 0x13, 
0xcea887, 0x6, 0xc4205ff798, 0x8, 0x0, 0xc420335080, 0x18)
/src/project/storage/cloud/client.go:306 +0x3e2
project/storage/retention.insert.download(0xc420018600, 0x0, 0x0, 
0xbed7eea2f2ff5d40, 0x98b539fed9f, 0x11f7e60)
/src/project/storage/retention/insert.go:303 +0x96
project/storage/retention.(*insert).Run(0xc4220f60c0, 0x0, 0x0)
/src/project/storage/retention/insert.go:82 +0x2a7
project/storage/retention.(*repair).Run(0xc42000e580, 0x98b539bca2f, 0x11f7e60)
/src/project/storage/retention/repair.go:62 +0x7e9
project/storage/retention.(*Client).sync(0xc42052e150, 0xc42025, 0x1f, 
0x20, 0x0, 0x0)
/src/project/storage/retention/client.go:371 +0x2cb
project/storage/retention.(*Client).Run(0xc42052e150, 0x0, 0x0)
/src/project/storage/retention/client.go:222 +0x137
project/storage.Engine.retention(0xc4200b9d80, 0xc4201d9e00, 0xc42052e150, 
0xc4200b7630)
/src/project/storage/engine.go:90 +0x43
created by project/storage.New
/src/project/storage/engine.go:55 +0x270


To prevent the problem I've added a defer'd recover to try to catch the 
exception, however now I'm getting:


runtime: invalid pc-encoded table f=net/http.(*conn).readRequest pc=0x6934d3 
targetpc=0x6934da tab=[0/0]0x0
value=0 until pc=0x692812
value=304 until pc=0x692bcb
value=0 until pc=0x692bcc
value=304 until pc=0x692c76
value=0 until pc=0x692c77
value=304 until pc=0x692f96
value=0 until pc=0x692f97
value=304 until pc=0x693114
value=0 until pc=0x693115
value=304 until pc=0x693154
value=0 until pc=0x693155
value=304 until pc=0x6931bc
value=0 until pc=0x6931bd
value=304 until pc=0x6932c1
value=0 until pc=0x6932c2
value=304 until pc=0x693316
value=0 until 

Re: [go-nuts] Re: Is the go 1.11 godoc tool 'module-aware'?

[Justin Israel]

On Thu, Aug 30, 2018, 9:54 PM Agniva De Sarker 
wrote:

> I had filed https://github.com/golang/go/issues/26827 to list the changes
> that godoc needs to make. Please feel free to add your comments there.
>
> Also - note that godoc cli mode is going to go away. So "godoc -links=0
> -html domain.com/group/project/v3/lib/foo" is not going to work after
> 1.12. You should be using the http server. If you want command line help,
> use "go doc".
>

Fair enough. I should just discontinue the feature we have in our build
systems Go tool. It was neat to generate html docs with our deploys.


> - Agniva
>
>
> On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>>
>> Thanks for that update, Paul!
>>
>> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly  wrote:
>>
>>> Perhaps better (because of the automatic linking, status updates etc)
>>> is to create issues in respective tools under the umbrella of
>>> https://github.com/golang/go/issues/24661
>>>
>>> Indeed I know there are a number of such issues, so it's just a case
>>> of linking those from #24661.
>>> On Wed, 29 Aug 2018 at 07:46, wilk  wrote:
>>> >
>>> >
>>> > It could be fine to start a wiki page to list the tools and ide
>>> > (not)ready for modules with the linked issues.
>>> >
>>> > In https://github.com/golang/go/wiki/Modules or a new page ?
>>> >
>>> > On 29-08-2018, Paul Jolly wrote:
>>> > > --50127c057491b176
>>> > > Content-Type: text/plain; charset="UTF-8"
>>> > >
>>> > > Please see https://github.com/golang/gddo/issues/567
>>> > >
>>> > > On Tue, 28 Aug 2018, 18:59 Justin Israel, 
>>> wrote:
>>> > >
>>> > >> I've been trying out converting some of our internal projects to go
>>> 1.11
>>> > >> using modules instead of glide. We have a build system that
>>> provides the
>>> > >> ability to generate html docs via "godoc" and I am wondering if
>>> godoc has
>>> > >> been made "module-aware" in go 1.11?
>>> > >>
>>> > >> My particular project is using the migration approach of setting
>>> "v3" at
>>> > >> in the go.mod, and in all import paths within the project. But it
>>> seems
>>> > >> godoc is not happy about this:
>>> > >>
>>> > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
>>> > >>
>>> > >> 2018/08/29 11:52:12 error while importing build package: cannot
>>> find package "domain.com/group/project/v3/lib/foo" in any of:
>>> > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo
>>> (from $GOROOT)
>>> > >> /usr/home/justin/src/go/src/
>>> domain.com/group/project/v3/lib/foo (from $GOPATH)
>>> > >> 2018/08/29 11:52:12 cannot find package "." in:
>>> > >> /src/domain.com/group/project/v3/lib/foo
>>> > >>
>>> > >>
>>> > >> It seems to only care about the filesystem structure and not the
>>> module import path naming?
>>> > >>
>>> > >>
>>> > >> Justin
>>> > >>
>>> > >>
>>> > >> --
>>> > >> You received this message because you are subscribed to the Google
>>> Groups
>>> > >> "golang-nuts" group.
>>> > >> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> > >> email to golang-nuts...@googlegroups.com.
>>> > >> For more options, visit https://groups.google.com/d/optout.
>>> > >>
>>> > >
>>> >
>>> >
>>> > --
>>> > William
>>> >
>>> > --
>>> > 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...@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] Reference to type satisfying a specified interface

[Eric Raymond]

On Thursday, August 30, 2018 at 3:00:18 PM UTC-4, Burak Serdar wrote:
>
> If you're porting from another language, you're likely to encounter 
> this situation soon, if not already. 
>

Right, and because Python code  often makes aggressive use of runtime 
polymorphism it's *particularly *likely to come from that direction.

I don't think my case is at all a strange outlier. Maybe there ought to be 
a FAQ entry on this addressed to Python programmers?

-- 
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] runtime: invalid pc-encoded table (invalid runtime symbol table)

[Ewan Walker]

I've been trying to trace a crash (seemingly from a dependency) for quite 
some time:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x656492]


goroutine 86 [running]:
net/http.(*Client).deadline(0x0, 0xc42e2dc0b0, 0xc420456be0, 0x0)
/usr/local/go/src/net/http/client.go:189 +0x22
net/http.(*Client).Do(0x0, 0xc42054c800, 0xc43631e237, 0x1, 0xc450328900)
/usr/local/go/src/net/http/client.go:500 +0x86
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2.1(0xc450328988,
 
0x5da16f)
/src/vendor/cloud.google.com/go/storage/reader.go:100 +0x64
vendor/cloud.google.com/go/storage.runWithRetry.func1(0x0, 0x0, 
0xc450328a20)
/src/vendor/cloud.google.com/go/storage/invoke.go:27 +0x2a
vendor/cloud.google.com/go/internal.retry(0x7ff670cac2a8, 0xc45032cde0, 
0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0xd1b648, 0xc42005dc00, 0x688335)
/src/vendor/cloud.google.com/go/internal/retry.go:39 +0x4c
vendor/cloud.google.com/go/internal.Retry(0x7ff670cac2a8, 0xc45032cde0, 
0x0, 0x0, 0x0, 0x0, 0xc450328aa8, 0x80, 0x80)
/src/vendor/cloud.google.com/go/internal/retry.go:32 +0x82
vendor/cloud.google.com/go/storage.runWithRetry(0x7ff670cac2a8, 
0xc45032cde0, 0xc450328b88, 0xc42005dc00, 0xc4205ca800)
/src/vendor/cloud.google.com/go/storage/invoke.go:26 +0x73
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader.func2(0x0, 
0xc420456b80, 0x0, 0x0)
/src/vendor/cloud.google.com/go/storage/reader.go:99 +0x125
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewRangeReader(0xc445af0210, 
0x7ff670cac2a8, 0xc45032cde0, 0x0, 0x, 0x0, 0xc43b62a600, 
0x7ff670c5f1d0)
/src/vendor/cloud.google.com/go/storage/reader.go:129 +0x5bf
vendor/cloud.google.com/go/storage.(*ObjectHandle).NewReader(0xc445af0210, 
0x7ff670c5f1d0, 0xc43b62a660, 0x7ff670c5f1d0, 0xc43b62a660, 0xc43cbc4690)
/src/vendor/cloud.google.com/go/storage/reader.go:42 +0x51
project/storage/cloud.(*Client).Download(0xc4204f69f0, 0xc429129f00, 0x13, 
0xcea887, 0x6, 0xc4205ff798, 0x8, 0x0, 0xc420335080, 0x18)
/src/project/storage/cloud/client.go:306 +0x3e2
project/storage/retention.insert.download(0xc420018600, 0x0, 0x0, 
0xbed7eea2f2ff5d40, 0x98b539fed9f, 0x11f7e60)
/src/project/storage/retention/insert.go:303 +0x96
project/storage/retention.(*insert).Run(0xc4220f60c0, 0x0, 0x0)
/src/project/storage/retention/insert.go:82 +0x2a7
project/storage/retention.(*repair).Run(0xc42000e580, 0x98b539bca2f, 
0x11f7e60)
/src/project/storage/retention/repair.go:62 +0x7e9
project/storage/retention.(*Client).sync(0xc42052e150, 0xc42025, 0x1f, 
0x20, 0x0, 0x0)
/src/project/storage/retention/client.go:371 +0x2cb
project/storage/retention.(*Client).Run(0xc42052e150, 0x0, 0x0)
/src/project/storage/retention/client.go:222 +0x137
project/storage.Engine.retention(0xc4200b9d80, 0xc4201d9e00, 0xc42052e150, 
0xc4200b7630)
/src/project/storage/engine.go:90 +0x43
created by project/storage.New
/src/project/storage/engine.go:55 +0x270


To prevent the problem I've added a defer'd recover to try to catch the 
exception, however now I'm getting:


runtime: invalid pc-encoded table f=net/http.(*conn).readRequest 
pc=0x6934d3 targetpc=0x6934da tab=[0/0]0x0
value=0 until pc=0x692812
value=304 until pc=0x692bcb
value=0 until pc=0x692bcc
value=304 until pc=0x692c76
value=0 until pc=0x692c77
value=304 until pc=0x692f96
value=0 until pc=0x692f97
value=304 until pc=0x693114
value=0 until pc=0x693115
value=304 until pc=0x693154
value=0 until pc=0x693155
value=304 until pc=0x6931bc
value=0 until pc=0x6931bd
value=304 until pc=0x6932c1
value=0 until pc=0x6932c2
value=304 until pc=0x693316
value=0 until pc=0x693317
value=304 until pc=0x693338
value=0 until pc=0x693339
value=304 until pc=0x6933ef
value=0 until pc=0x6933f0
value=304 until pc=0x6934c8
value=0 until pc=0x6934d3
fatal error: invalid runtime symbol table

goroutine 0 [idle]:
runtime: unexpected return pc for runtime.sigtramp called from 
0x7f406d73a390
stack: frame={sp:0xc42050fa68, fp:0xc42050fac0} 
stack=[0xc420508000,0xc42051)
00c42050f968:    
00c42050f978:    0001
00c42050f988:  00c4205d0760  00c4201ed610
00c42050f998:  00c42050fbf0  00c42050fac0
00c42050f9a8:  00c42050fa58  00441dfc 

00c42050f9b8:  00c4001b  00c42050fbf0
00c42050f9c8:  00c42050fac0  00c42031be00
00c42050f9d8:    0081e810 

00c42050f9e8:    
00c42050f9f8:    
00c42050fa08:    

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

oops, gave link to a dup, here's a right 
one: https://github.com/golang/go/issues/27380

четверг, 30 августа 2018 г., 22:06:36 UTC+3 пользователь Denis Cheremisov 
написал:
>
> Filled a new issue: https://github.com/golang/go/issues/27381
> Please let me know if a title is too weird, I am about as good with them 
> as with variable names :)
>
> четверг, 30 августа 2018 г., 21:35:21 UTC+3 пользователь Sam Whited 
> написал:
>>
>> FWIW, I have the same issue (I have to unset GO111MODULE before 
>> attempting to fetch a binary or before building Go) and there appear to be 
>> several comments on the closed issue suggesting that this is still a 
>> problem: 
>>
>> https://golang.org/issues/26639 
>>
>> I just tested this on tip (currently devel +360771e422) but haven't dug 
>> in further. 
>>
>> —Sam 
>>
>> On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote: 
>> > strange, still the same 
>> > 
>> > $ go get -x -u golang.org/x/tools/cmd/goimports 
>> > go: cannot find main module; see 'go help modules' 
>> > 
>> > I am using 
>> > 
>> > $ go version 
>> > go version go1.11 linux/amd64 
>> > 
>> > with 
>> > 
>> > export GO111MODULE=on 
>> > 
>> > 
>> > 
>> > четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis 
>> написал: 
>> > > 
>> > > 
>> > > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote: 
>> > > 
>> > > Hi! 
>> > > With Go 1.10 and earlier one can install binaries via regular `go 
>> get`, `go 
>> > > get golang.org/x/tools/cmd/goimports` 
>>  for instance. 
>> > > It doesn't work with Go modules enabled: 
>> > > 
>> > > $ go get golang.org/x/tools/cmd/goimports 
>> > > go: cannot find main module; see 'go help modules' 
>> > > 
>> > > this is an obvious usability downgrade. I wonder if someone knows 
>> about 
>> > > some sort of replacement for the functionality? 
>> > > 
>> > > 
>> > > It should still work (and does for me). 
>> > > 
>> > > Can you try go get -x -u golang.org/x/tools/cmd/goimports and see 
>> what 
>> > > the output prints about the problem. 
>> > > 
>> > > 
>> > > 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "golang-nuts" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> > an email to golang-nuts...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>
>> -- 
>> Sam Whited 
>> s...@samwhited.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] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

Filled a new issue: https://github.com/golang/go/issues/27381
Please let me know if a title is too weird, I am about as good with them as 
with variable names :)

четверг, 30 августа 2018 г., 21:35:21 UTC+3 пользователь Sam Whited написал:
>
> FWIW, I have the same issue (I have to unset GO111MODULE before attempting 
> to fetch a binary or before building Go) and there appear to be several 
> comments on the closed issue suggesting that this is still a problem: 
>
> https://golang.org/issues/26639 
>
> I just tested this on tip (currently devel +360771e422) but haven't dug in 
> further. 
>
> —Sam 
>
> On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote: 
> > strange, still the same 
> > 
> > $ go get -x -u golang.org/x/tools/cmd/goimports 
> > go: cannot find main module; see 'go help modules' 
> > 
> > I am using 
> > 
> > $ go version 
> > go version go1.11 linux/amd64 
> > 
> > with 
> > 
> > export GO111MODULE=on 
> > 
> > 
> > 
> > четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis 
> написал: 
> > > 
> > > 
> > > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote: 
> > > 
> > > Hi! 
> > > With Go 1.10 and earlier one can install binaries via regular `go 
> get`, `go 
> > > get golang.org/x/tools/cmd/goimports` 
>  for instance. 
> > > It doesn't work with Go modules enabled: 
> > > 
> > > $ go get golang.org/x/tools/cmd/goimports 
> > > go: cannot find main module; see 'go help modules' 
> > > 
> > > this is an obvious usability downgrade. I wonder if someone knows 
> about 
> > > some sort of replacement for the functionality? 
> > > 
> > > 
> > > It should still work (and does for me). 
> > > 
> > > Can you try go get -x -u golang.org/x/tools/cmd/goimports and see 
> what 
> > > the output prints about the problem. 
> > > 
> > > 
> > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> Sam Whited 
> s...@samwhited.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] Reference to type satisfying a specified interface

[Burak Serdar]

On Thu, Aug 30, 2018 at 12:49 PM Eric Raymond  wrote:
>
>
>
> On Thursday, August 30, 2018 at 2:18:38 PM UTC-4, Burak Serdar wrote:
>>
>> If b is an interface to a *Blob, what's stored in the slice is {Type:
>> *Blob, Value: pointer to the object}. A copy of this interface value
>> is also in the map. So you have two copies of the interface value,
>> both pointing to the same Blob object.
>
>
> Thank you!  That is the answer I was looking for!
>
> I note that I was unable to extract this enlightenment from the  
> documentation, despite sweating over it pretty hard.
>
> Either I'm stupid or this is a documentation/tutorial issue that could stand 
> to be addressed better.  And I don't think I'm stupid.

I agree. This should be explained better. I myself didn't understand
it completely when I first started working with go, then I had a
day-long debugging session, which ended when I discovered this:

https://golang.org/doc/faq#nil_error

If you're porting from another language, you're likely to encounter
this situation soon, if not already.

>
> --
> 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] Reference to type satisfying a specified interface

[Eric Raymond]

On Thursday, August 30, 2018 at 2:18:38 PM UTC-4, Burak Serdar wrote:
>
> If b is an interface to a *Blob, what's stored in the slice is {Type: 
> *Blob, Value: pointer to the object}. A copy of this interface value 
> is also in the map. So you have two copies of the interface value, 
> both pointing to the same Blob object. 
>

Thank you!  That is the answer I was looking for!

I note that I was unable to extract this enlightenment from the  
documentation, despite sweating over it pretty hard.

Either I'm stupid or this is a documentation/tutorial issue that could 
stand to be addressed better.  And I don't think I'm stupid.

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

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

[Sam Whited]

FWIW, I have the same issue (I have to unset GO111MODULE before attempting to 
fetch a binary or before building Go) and there appear to be several comments 
on the closed issue suggesting that this is still a problem:

https://golang.org/issues/26639

I just tested this on tip (currently devel +360771e422) but haven't dug in 
further.

—Sam

On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote:
> strange, still the same
> 
> $ go get -x -u golang.org/x/tools/cmd/goimports 
> go: cannot find main module; see 'go help modules'
> 
> I am using 
> 
> $ go version
> go version go1.11 linux/amd64
> 
> with
> 
> export GO111MODULE=on
> 
> 
> 
> четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis написал:
> >
> >
> > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote:
> >
> > Hi!
> > With Go 1.10 and earlier one can install binaries via regular `go get`, `go 
> > get golang.org/x/tools/cmd/goimports` for instance.
> > It doesn't work with Go modules enabled:
> >
> > $ go get golang.org/x/tools/cmd/goimports
> > go: cannot find main module; see 'go help modules'
> >
> > this is an obvious usability downgrade. I wonder if someone knows about 
> > some sort of replacement for the functionality?
> >
> >
> > It should still work (and does for me).
> >
> > Can you try go get -x -u golang.org/x/tools/cmd/goimports and see what 
> > the output prints about the problem.
> >
> >
> >
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Sam Whited
s...@samwhited.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] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

strange, still the same

$ go get -x -u golang.org/x/tools/cmd/goimports 
go: cannot find main module; see 'go help modules'

I am using 

$ go version
go version go1.11 linux/amd64

with

export GO111MODULE=on



четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis написал:
>
>
> On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote:
>
> Hi!
> With Go 1.10 and earlier one can install binaries via regular `go get`, `go 
> get golang.org/x/tools/cmd/goimports` for instance.
> It doesn't work with Go modules enabled:
>
> $ go get golang.org/x/tools/cmd/goimports
> go: cannot find main module; see 'go help modules'
>
> this is an obvious usability downgrade. I wonder if someone knows about 
> some sort of replacement for the functionality?
>
>
> It should still work (and does for me).
>
> Can you try go get -x -u golang.org/x/tools/cmd/goimports and see what 
> the output prints about the problem.
>
>
>

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

Re: [go-nuts] Reference to type satisfying a specified interface

[Burak Serdar]

On Thu, Aug 30, 2018 at 12:09 PM Eric Raymond  wrote:
>
>
>>
>> If Event is your interface and EventImpl is your struct, what you need
>> is a map[string]Event, not map[string]*Event. Make sure you put
>> {} to your slices and maps, not EventImpl{}
>>
>
> Here'a what is confusing me.  Yes, I can write
>
>  _mark_to_object  map[string]Event
>
>
> and
>
> b.repo._mark_to_object[mark] = b
>
> for b a pointer to Blob, with Blob satisfying Event.  This compiles without 
> error.
>
> But what actually happens here? Is the new value a pointer to the same Blob 
> instance that is in the main list, or does the code dereference b and put a 
> *copy* of the blob in the map?  The first behavior (reference) is what I want.

If b is an interface to a *Blob, what's stored in the slice is {Type:
*Blob, Value: pointer to the object}. A copy of this interface value
is also in the map. So you have two copies of the interface value,
both pointing to the same Blob object.




>
> --
> 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] Reference to type satisfying a specified interface

[Eric Raymond]

>
> If Event is your interface and EventImpl is your struct, what you need 
> is a map[string]Event, not map[string]*Event. Make sure you put 
> {} to your slices and maps, not EventImpl{} 
>
>
Here'a what is confusing me.  Yes, I can write

 _mark_to_object  map[string]Event


and

b.repo._mark_to_object[mark] = b

for b a pointer to Blob, with Blob satisfying Event.  This compiles without 
error. 

But what actually happens here? Is the new value a pointer to the same Blob 
instance that is in the main list, or does the code dereference b and put a 
*copy* of the blob in the map?  The first behavior (reference) is what I 
want.

-- 
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: Reference to type satisfying a specified interface

[Eric Raymond]

On Thursday, August 30, 2018 at 1:32:18 PM UTC-4, Akram Ahmad wrote:
>
> Your work on porting *reposurgeon* (from Python into Go) for improved 
> performance sounds very cool, Eric (BTW, your work in, and musings on, Lisp 
> and UNIX have been a huge influence on my evolution as a programmer. Kudos 
> for that!
>

Thanks for the kind words.

I have rather been forced into this. In cooperation with the GCC devteam, 
I'm trying to move their repository from Subversion to git.  It's so 
freaking big and Python is so slow that test conversions are taking more 
than 9 hours, with occasional OOMs because the  working set is so huge.  I 
have got to reduce that cycle time, it is making forensics on the 
malformations in the history effectively impossible.  

Go seems to be a tool that fits the job - translation of a smaller 
auxiliary program suggests I ca n reasonably expect a 40x speed increase -  
but this is my first major project in it and I have not yet mastered the 
language.

Once I do, I expect it to replace C for all my new projects that would 
otherwise have been C.  Also anything I would havew written in Python that 
needs to perform at machine speeds rather than human speed.

-- 
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] Reference to type satisfying a specified interface

['Thomas Bushnell, BSG' via golang-nuts]

Basically you almost never want pointer-to-interface in practice.

The temptation is to have a struct which satisfies your interface, and then
you end up with thinking you want pointer-to-interface.

Instead, make pointer-to-struct satisfy the interface, and then you don't
need pointer-to-interface any more.

On Thu, Aug 30, 2018 at 10:34 AM Eric Raymond  wrote:

>
>
> On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote:
>
>> On Thu, Aug 30, 2018, 18:57 Eric Raymond  wrote:
>>
>>> I'm trying to translate this to Go in a type-safe way. To do this, I
>>> need to be able to write two declarations: "Slice of pointers to objects
>>> satisfying the Event interface"
>>>
>>
>> []*Event, but quite probably []Event is what is really needed.
>>
>> and "map of string keys to pointers to objects satisfying the Event
>>> interface".
>>>
>>
>> map[string]*Event, but once again, my bet is on map[string]Event.
>>
>> My attempts so far have yielded very cryptic error messages and no
>>> success.
>>>
>>
>> It would probably help your case if you could provide some self-contained
>> example reproducing the errors and post a link to the Go Playground.
>>
>
> That's hard.  The structures are intertwingled parts of ab only partly
> translated 14KLOC program  But I can isolate some key declarations.  If
> Event is my interface type, and I write
>
> events []Event
> _mark_to_object  map[string]*Event
>
> as member declarations in the Repository class, and b is a pointer to a
> just-allocated instance of a Blob object satisfying the Event interface,
> and  I write this
>
>  b.repo._mark_to_object[mark] = b
>
> I get this message:
>
> cannot use b (type *Blob) as type *Event in assignment:
> *Event is pointer to interface, not interface
>
> Note that the map values really do need to be pointers, because I need the
> map to refer to the mutable data in the event list, not a local copy of it
> in the map.  What's stumping me is how to communicate this to the compiler.
>
> --
> 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] Reference to type satisfying a specified interface

[Burak Serdar]

On Thu, Aug 30, 2018 at 11:34 AM Eric Raymond  wrote:
>
>
>
> On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote:
>>
>> On Thu, Aug 30, 2018, 18:57 Eric Raymond  wrote:
>>>
>>> I'm trying to translate this to Go in a type-safe way. To do this, I need 
>>> to be able to write two declarations: "Slice of pointers to objects 
>>> satisfying the Event interface"
>>
>>
>> []*Event, but quite probably []Event is what is really needed.
>>
>>> and "map of string keys to pointers to objects satisfying the Event 
>>> interface".
>>
>>
>> map[string]*Event, but once again, my bet is on map[string]Event.
>>
>>> My attempts so far have yielded very cryptic error messages and no success.
>>
>>
>> It would probably help your case if you could provide some self-contained 
>> example reproducing the errors and post a link to the Go Playground.
>
>
> That's hard.  The structures are intertwingled parts of ab only partly 
> translated 14KLOC program  But I can isolate some key declarations.  If Event 
> is my interface type, and I write
>
> events []Event
> _mark_to_object  map[string]*Event


If Event is your interface and EventImpl is your struct, what you need
is a map[string]Event, not map[string]*Event. Make sure you put
{} to your slices and maps, not EventImpl{}

>
> as member declarations in the Repository class, and b is a pointer to a 
> just-allocated instance of a Blob object satisfying the Event interface, and  
> I write this
>
>  b.repo._mark_to_object[mark] = b
>
> I get this message:
>
> cannot use b (type *Blob) as type *Event in assignment:
> *Event is pointer to interface, not interface
>
> Note that the map values really do need to be pointers, because I need the 
> map to refer to the mutable data in the event list, not a local copy of it in 
> the map.  What's stumping me is how to communicate this to the compiler.
>
> --
> 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] Character Replacement/Algorithm for Replacement

[Michael Jones]

Always true. But hard to believe that a map could be faster. The array will
be on the stack.

On Thu, Aug 30, 2018 at 9:31 AM Marvin Renich  wrote:

> * Michael Jones  [180830 11:44]:
> > The task to "translate a string through a table" is common. It is a
> single
> > computer instruction (TR) in the IBM 360 and was extended over time with
> > related instructions for conversion in and out of UTF-8, testing before
> and
> > after translation, and expanded character sizes. Tamás Gulácsi's approach
> > would be mine too.
>
> Wow, that brings back memories!  The x86 has xlat as well, which can be
> used with lodsb and stosb for efficient string translation.  The
> question is whether the go compiler will produce optimized code using
> these instructions.
>
> I was not disagreeing with Tamás.  My point was simply that without
> benchmarking, or prior in-depth knowledge of both how the Go compiler
> translates these constructs to assembly and the characteristics of the
> processor/motherboard/memory bus, it is hard to say which Go algorithm
> is the fastest for the OP's data.
>
> ...Marvin
>
> --
> 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.
>
-- 

*Michael T. jonesmichael.jo...@gmail.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] Reference to type satisfying a specified interface

[Eric Raymond]

On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote:
>
> On Thu, Aug 30, 2018, 18:57 Eric Raymond > 
> wrote:
>
>> I'm trying to translate this to Go in a type-safe way. To do this, I need 
>> to be able to write two declarations: "Slice of pointers to objects 
>> satisfying the Event interface" 
>>
>
> []*Event, but quite probably []Event is what is really needed.
>
> and "map of string keys to pointers to objects satisfying the Event 
>> interface".  
>>
>
> map[string]*Event, but once again, my bet is on map[string]Event.
>
> My attempts so far have yielded very cryptic error messages and no success.
>>
>
> It would probably help your case if you could provide some self-contained 
> example reproducing the errors and post a link to the Go Playground.
>

That's hard.  The structures are intertwingled parts of ab only partly 
translated 14KLOC program  But I can isolate some key declarations.  If 
Event is my interface type, and I write

events []Event
_mark_to_object  map[string]*Event

as member declarations in the Repository class, and b is a pointer to a 
just-allocated instance of a Blob object satisfying the Event interface, 
and  I write this

 b.repo._mark_to_object[mark] = b

I get this message:

cannot use b (type *Blob) as type *Event in assignment:
*Event is pointer to interface, not interface

Note that the map values really do need to be pointers, because I need the 
map to refer to the mutable data in the event list, not a local copy of it 
in the map.  What's stumping me is how to communicate this to the compiler.

-- 
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: Reference to type satisfying a specified interface

[Akram Ahmad]

Your work on porting *reposurgeon* (from Python into Go) for improved 
performance sounds very cool, Eric (BTW, your work in, and musings on, Lisp 
and UNIX have been a huge influence on my evolution as a programmer. Kudos 
for that!

On Thursday, August 30, 2018 at 11:56:58 AM UTC-5, Eric Raymond wrote:
>
> I apologize if this seems like an elementary question, but web searches 
> and reading the Go documentation is not turning up an answer.
>
> I'm in the process of translating reposurgeon, an editor for 
> version-control histories, from Python into Go for improved performance, 
> .The central data structure is Repository, which consists mainly of a list 
> of events such as commits and tags.  In Python, I use the language's late 
> binding and simply declare a list of containing multiple object types named 
> Commit, Tag, etc.  There are also a number of lookup maps pointing at 
> objects in the main event list.  Because objects in Pytron are passed by 
> reference everything is fairly straightforward.
>
> I'm trying to translate this to Go in a type-safe way. To do this, I need 
> to be able to write two declarations: "Slice of pointers to objects 
> satisfying the Event interface" and "map of string keys to pointers to 
> objects satisfying the Event interface".  My attempts so far have yielded 
> very cryptic error messages and no success.
>
> Is it actually possible to restrict the main list's polymorphism in this 
> way and avoid casts?
>
>
>
>
>
>
>  
>

-- 
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] Reference to type satisfying a specified interface

[Jan Mercl]

On Thu, Aug 30, 2018, 18:57 Eric Raymond  wrote:

> I apologize if this seems like an elementary question, but web searches
> and reading the Go documentation is not turning up an answer.
>
> I'm in the process of translating reposurgeon, an editor for
> version-control histories, from Python into Go for improved performance,
> .The central data structure is Repository, which consists mainly of a list
> of events such as commits and tags.  In Python, I use the language's late
> binding and simply declare a list of containing multiple object types named
> Commit, Tag, etc.  There are also a number of lookup maps pointing at
> objects in the main event list.  Because objects in Pytron are passed by
> reference everything is fairly straightforward.
>
> I'm trying to translate this to Go in a type-safe way. To do this, I need
> to be able to write two declarations: "Slice of pointers to objects
> satisfying the Event interface"
>

[]*Event, but quite probably []Event is what is really needed.

and "map of string keys to pointers to objects satisfying the Event
> interface".
>

map[string]*Event, but once again, my bet is on map[string]Event.

My attempts so far have yielded very cryptic error messages and no success.
>

It would probably help your case if you could provide some self-contained
example reproducing the errors and post a link to the Go Playground.


> Is it actually possible to restrict the main list's polymorphism in this
> way and avoid casts?
>

I believe it is and that no conversions/type assertions are necessary to
invoke the interface declared methods accros any instance satisfying Event
in the list or map declared as suggested above.

>
> --

-j

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

Re: [go-nuts] Reference to type satisfying a specified interface

[Burak Serdar]

Did you try something like this? What errors did you get?

type Event interface {
  ...
}

type EventImpl struct {
 ...
}

eventSlice:=make([]Event,0)
eventMap:=make(map[string]Event)


event:={}
eventSlice=append(eventSlice,event)
eventMap["key"]=event


On Thu, Aug 30, 2018 at 10:57 AM Eric Raymond  wrote:
>
> I apologize if this seems like an elementary question, but web searches and 
> reading the Go documentation is not turning up an answer.
>
> I'm in the process of translating reposurgeon, an editor for version-control 
> histories, from Python into Go for improved performance, .The central data 
> structure is Repository, which consists mainly of a list of events such as 
> commits and tags.  In Python, I use the language's late binding and simply 
> declare a list of containing multiple object types named Commit, Tag, etc.  
> There are also a number of lookup maps pointing at objects in the main event 
> list.  Because objects in Pytron are passed by reference everything is fairly 
> straightforward.
>
> I'm trying to translate this to Go in a type-safe way. To do this, I need to 
> be able to write two declarations: "Slice of pointers to objects satisfying 
> the Event interface" and "map of string keys to pointers to objects 
> satisfying the Event interface".  My attempts so far have yielded very 
> cryptic error messages and no success.
>
> Is it actually possible to restrict the main list's polymorphism in this way 
> and avoid casts?
>
>
>
>
>
>
>
>
> --
> 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] Reference to type satisfying a specified interface

[Eric Raymond]

I apologize if this seems like an elementary question, but web searches and 
reading the Go documentation is not turning up an answer.

I'm in the process of translating reposurgeon, an editor for 
version-control histories, from Python into Go for improved performance, 
.The central data structure is Repository, which consists mainly of a list 
of events such as commits and tags.  In Python, I use the language's late 
binding and simply declare a list of containing multiple object types named 
Commit, Tag, etc.  There are also a number of lookup maps pointing at 
objects in the main event list.  Because objects in Pytron are passed by 
reference everything is fairly straightforward.

I'm trying to translate this to Go in a type-safe way. To do this, I need 
to be able to write two declarations: "Slice of pointers to objects 
satisfying the Event interface" and "map of string keys to pointers to 
objects satisfying the Event interface".  My attempts so far have yielded 
very cryptic error messages and no success.

Is it actually possible to restrict the main list's polymorphism in this 
way and avoid casts?






 

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

[go-nuts] Re: Are Go floats smarter?

[José Colón]

>From what I've seen in the wild and searching for options on the Web, using 
big integers to store the lowest denomination of any given currency is very 
popular indeed, and I suspect ir should also perform better as a bonus.

On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

-- 
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] Character Replacement/Algorithm for Replacement

[Marvin Renich]

* Michael Jones  [180830 11:44]:
> The task to "translate a string through a table" is common. It is a single
> computer instruction (TR) in the IBM 360 and was extended over time with
> related instructions for conversion in and out of UTF-8, testing before and
> after translation, and expanded character sizes. Tamás Gulácsi's approach
> would be mine too.

Wow, that brings back memories!  The x86 has xlat as well, which can be
used with lodsb and stosb for efficient string translation.  The
question is whether the go compiler will produce optimized code using
these instructions.

I was not disagreeing with Tamás.  My point was simply that without
benchmarking, or prior in-depth knowledge of both how the Go compiler
translates these constructs to assembly and the characteristics of the
processor/motherboard/memory bus, it is hard to say which Go algorithm
is the fastest for the OP's data.

...Marvin

-- 
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] Character Replacement/Algorithm for Replacement

[Michael Jones]

The task to "translate a string through a table" is common. It is a single
computer instruction (TR) in the IBM 360 and was extended over time with
related instructions for conversion in and out of UTF-8, testing before and
after translation, and expanded character sizes. Tamás Gulácsi's approach
would be mine too.

On Thu, Aug 30, 2018 at 5:30 AM Marvin Renich  wrote:

> * Tamás Gulácsi  [180830 01:17]:
> > An even faster lookup is creating a [256]byte array for the
> replacements,
> > having the 9 replacements candidates _position_ having the replacements,
> > all others the identity:
> >
> > // prepare the lookup table
> > var a [256]byte
> > for i := 0; i<256; i++ {
> >   a[i] = i
> > }
> > a[37] = '-'
> > a[129] = '-'
> > ...
> >
> > // replace the bytes, in-place operation
> > func replace(p []byte) {
> >   for i, b := range p {
> > p[i] = a[b]
> >   }
> > }
> >
> > Although map lookup is O(1), array lookup is O(1) with a smaller
> constant
> > factor, I'm sure.
> > And this has no branching, so should be even faster.
>
> I'm not convinced, and only benchmarking will tell.  If len(p) == 100
> and only six of those are in the set to be replaced, doing 100 memory
> writes instead of branching and doing six memory writes might very well
> be slower.
>
> Today's hardware has all sorts of optimizations that help with both
> cases.  Predictive branching and caching will each help with one of the
> two approaches.  You can't be sure until you have benched with realistic
> data.
>
> I would, however, replace the map in the previous suggestion with a
> [256]int16 with -1 meaning "don't replace".  This is really just a
> special-case optimized map.  If 0 is not a valid replacement byte, use
> [256]byte with 0 meaning "don't replace".
>
> ...Marvin
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.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] How to deal with binaries compilation with go modules enabled?

[Ian Davis]

On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote:
> Hi!
> With Go 1.10 and earlier one can install binaries via regular `go
> get`, `go get golang.org/x/tools/cmd/goimports` for instance.> It doesn't 
> work with Go modules enabled:
> 
> $ go get golang.org/x/tools/cmd/goimports
> go: cannot find main module; see 'go help modules'
> 
> this is an obvious usability downgrade. I wonder if someone knows
> about some sort of replacement for the functionality?
It should still work (and does for me).

Can you try go get -x -u golang.org/x/tools/cmd/goimports and see what
the output prints about the problem.

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

Re: [go-nuts] Calling HTML DOM functions with wasm

[Jannis Andrija Schnitzer]

https://gist.github.com/Xjs/d6b879915716dddff486301a169b4c21 works for me. What 
was the exact problem you were having?

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] Coming to Go (from Java / Scala / Clojure).

[Akram Ahmad]

I must confess that Go has taken me by surprise: It's is refreshingly 
lightweight language that's steadily growing on. Has anyone (around 
here) shared their journey to Go land?

FWIW, here's a rundown of my journey: *Further Adventures In Go Land 
*
 

Enjoy, and meanwhile, I'm looking forward to catching up on the stuff 
around here in this cool discussion group!

 ~Akram

-- 
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] Urgent Freelancer Position at Verisart in London

[Robert Norton]

*We’re looking for a Senior **Golang and RESTful API developer* to support 
our in-house development team and who could start immediately. Knowledge 
of micro services also helpful.  The main issue we’re facing is that we’re 
currently upgrading our technical stack and moving from a tightly coupled 
backend and front end to using react/redux and we have brought on a new 
front end dev but need someone with strong web app and restful API 
experience.  

The role would involve setting up the API framework as well as any 
authentication (OAuth2.0) and validation middleware. Routes would then need 
to be implemented and integrated. Role would also involve supporting any 
extra code requirements of the development team inside the scope of the API 
project. The work would be done as part of a small team, based in London 
(Mayfair). Competitive rates offered, as well as flexible working 
hours although the position is full time and on site and the candidate must 
be available at least 4 days per week at our office in London.

Let me know if this challenge sounds interesting for you.

Many thanks

Robert

PS I am including below some further information on us.


*Background*

Verisart is looking for engineers interested in applying cryptography at 
real world problems. Our problem lies within the art market as we address 
the problem of proving provenance for artworks and building evidence based 
certificates of authenticity. We recognize that cryptography is not a magic 
bullet. We want to use it intelligently to provide evidence where possible 
for people to interpret, like the web of trust.

What we look for?
We’re looking for people who understand how to apply cryptography to 
problems. While understanding the mathematical backgrounds to cryptography 
is great, it’s not essential if you understand how the cryptographic 
primitives like hashing and message signing work together to solve real 
problems.

We look for passion above all else although an interest in arts and 
collectibles is helpful. We are a small team based in London although the 
company began in California.

Requirements
Computer science degree or similar (preferred but not necessary). Git. High 
level experience such as C++, Golang, Rust, Java, Python. Bitcoin 
experience is an asset. 

Our stack
Golang, Postgres, Javascript, Heroku, Python, 

Who we are
Verisart is building the most trusted way to certify and verify artworks 
and collectibles using distributed ledger technology. We are a rapidly 
growing team of applied cryptographers, software engineers and designers 
with offices in Los Angeles and London. Robert Norton, former CEO of 
Sedition Art and Saatchi Art, leads the company. Peter Todd, core developer 
for the Bitcoin blockchain protocol and Dr. Ahmed Elgammal, Professor in 
Computer Science at The Art & AI Lab at Rutgers University are Board 
Advisors.

*Applications should be sent to rob...@verisart.com *



Robert Norton
Founder/CEO
www.verisart.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.

[go-nuts] Re: os.WriteFile not writing files in long running process

[Manlio Perillo]

On Friday, August 24, 2018 at 11:20:46 AM UTC+2, Paweł Szczur wrote:
>
> Hi,
>
> I have a long running hobby program with a code: 
>
> var (
>url  = "https://example.com;
>lastBody []byte
> )
>
>
> func get(client *http.Client, dir) (changed bool, data []byte, err error) {
>
>resp, err := client.Get(url)
>if err != nil {
>   return false, nil, err
>}
>if resp.StatusCode != http.StatusOK {
>   log.Printf("status code: %d", resp.StatusCode)
>   return false, nil,  nil
>}
>body, err := ioutil.ReadAll(resp.Body)
>if err != nil {
>   return false, nil, err
>}
>if bytes.Compare(body, lastBody) == 0 {
>   logrus.Info("data is equal")
>   return false, data, nil
>}
>
>lastBody = body
>log.Printf("got %dB data", len(body))
>
>dir = path.Join(dir, t.Format("2006/01/02"))
>if err = os.MkdirAll(dir, defaultDirPerm); err != nil {
>   log.Print("failed to create a dir")
>}
>p := path.Join(dir, fmt.Sprintf("%d.json", t.Unix()))
>
>return true, body, ioutil.WriteFile(p, body, 0640)
> }
>
>
> After around 14 days the process stops writing files. However, it executes 
> os.WriteFile and does not return any error.
> The function is called repeatedly every N second (~40-60sec.). It produces 
> around 1700 files a day.
>
> Any ideas?
>
>
If files are created but are empty, there is a very simple explanation: the 
body of the GET response is empty.
Check if resp.ContentLength is equal to 0.

Also, if resp.StatusCode is not StatusOK, I suggest to return a not nil 
error.


Manlio

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

[go-nuts] How to deal with binaries compilation with go modules enabled?

[Denis Cheremisov]

Hi!
With Go 1.10 and earlier one can install binaries via regular `go get`, `go 
get golang.org/x/tools/cmd/goimports` for instance.
It doesn't work with Go modules enabled:

$ go get golang.org/x/tools/cmd/goimports
go: cannot find main module; see 'go help modules'

this is an obvious usability downgrade. I wonder if someone knows about 
some sort of replacement for the functionality?

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

Re: [go-nuts] Are Go floats smarter?

['Borman, Paul' via golang-nuts]

For financial programs you may want to consider fixed point decimal values 
rather than floats.  In simple terms, rather than using floating point units of 
currency, you use integers for the smallest acceptable quantity.  This might 
be, for example, using an int to say how many pennies are involved and then 
dividing by 100 when you want to display dollars.  This would be fixed point 
decimal with two decimal places.

I often think of time durations as a fixed point decimal number of seconds with 
9 decimal places (nanoseconds).

-Paul

> On Aug 30, 2018, at 8:27 AM, Marvin Renich  wrote:
> 
> * José Colón  [180830 06:53]:
>> Very interesting. So would it be a good idea to use these types of untyped 
>> constant calculations for financial applications, or instances where one 
>> would use the math.big package?
> 
> Not likely.  You would have to know at compile time the exact values you
> wanted to calculate, so you might as well not even write the program!
> 
> If you are writing financial applications or other applications where
> rounding and/or precision are important, you must have a much more
> thorough understanding of how the computer stores floating point values,
> how calculations are performed, how results are represented in the
> precision available, and how (and why) those results differ from the
> exact values.
> 
> Simply learning that Java and Python have rounding errors and that using
> Go's untyped constants give you the "human expected" results for some
> simple examples is woefully insufficient to write correct floating point
> code when such details are important.
> 
> On the other hand, there is a wide variety of programs that use floating
> point values that don't need to worry about the rounding error in the
> least significant bits.
> 
> As an example, if you had a set of coordinates, stored as floating point
> numbers, representing a graphical figure, it is highly probable that you
> could translate and scale those coordinates for display on the screen
> without worrying about, or having a deep understanding of, rounding
> errors.
> 
> ...Marvin
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Are Go floats smarter?

[Marvin Renich]

* José Colón  [180830 06:53]:
> Very interesting. So would it be a good idea to use these types of untyped 
> constant calculations for financial applications, or instances where one 
> would use the math.big package?

Not likely.  You would have to know at compile time the exact values you
wanted to calculate, so you might as well not even write the program!

If you are writing financial applications or other applications where
rounding and/or precision are important, you must have a much more
thorough understanding of how the computer stores floating point values,
how calculations are performed, how results are represented in the
precision available, and how (and why) those results differ from the
exact values.

Simply learning that Java and Python have rounding errors and that using
Go's untyped constants give you the "human expected" results for some
simple examples is woefully insufficient to write correct floating point
code when such details are important.

On the other hand, there is a wide variety of programs that use floating
point values that don't need to worry about the rounding error in the
least significant bits.

As an example, if you had a set of coordinates, stored as floating point
numbers, representing a graphical figure, it is highly probable that you
could translate and scale those coordinates for display on the screen
without worrying about, or having a deep understanding of, rounding
errors.

...Marvin

-- 
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] Character Replacement/Algorithm for Replacement

[Marvin Renich]

* Tamás Gulácsi  [180830 01:17]:
> An even faster lookup is creating a [256]byte array for the replacements, 
> having the 9 replacements candidates _position_ having the replacements, 
> all others the identity:
> 
> // prepare the lookup table
> var a [256]byte
> for i := 0; i<256; i++ {
>   a[i] = i
> }
> a[37] = '-'
> a[129] = '-'
> ...
> 
> // replace the bytes, in-place operation
> func replace(p []byte) {
>   for i, b := range p {
> p[i] = a[b]
>   }
> }
> 
> Although map lookup is O(1), array lookup is O(1) with a smaller constant 
> factor, I'm sure.
> And this has no branching, so should be even faster.

I'm not convinced, and only benchmarking will tell.  If len(p) == 100
and only six of those are in the set to be replaced, doing 100 memory
writes instead of branching and doing six memory writes might very well
be slower.

Today's hardware has all sorts of optimizations that help with both
cases.  Predictive branching and caching will each help with one of the
two approaches.  You can't be sure until you have benched with realistic
data.

I would, however, replace the map in the previous suggestion with a
[256]int16 with -1 meaning "don't replace".  This is really just a
special-case optimized map.  If 0 is not a valid replacement byte, use
[256]byte with 0 meaning "don't replace".

...Marvin

-- 
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: Cross compiling sers (with CGO) to Android

[distributed]

This is embarassing, but setting GOOS=android fixed the issue.

I was under the impression that android builds were only supported with an 
addition to the toolchain.

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

[go-nuts] Re: Are Go floats smarter?

[José Colón]

Very interesting. So would it be a good idea to use these types of untyped 
constant calculations for financial applications, or instances where one 
would use the math.big package?

On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

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

[Agniva De Sarker]

I had filed https://github.com/golang/go/issues/26827 to list the changes 
that godoc needs to make. Please feel free to add your comments there.

Also - note that godoc cli mode is going to go away. So "godoc -links=0 
-html domain.com/group/project/v3/lib/foo" is not going to work after 1.12. 
You should be using the http server. If you want command line help, use "go 
doc".

- Agniva


On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>
> Thanks for that update, Paul!
>
> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly > 
> wrote:
>
>> Perhaps better (because of the automatic linking, status updates etc)
>> is to create issues in respective tools under the umbrella of
>> https://github.com/golang/go/issues/24661
>>
>> Indeed I know there are a number of such issues, so it's just a case
>> of linking those from #24661.
>> On Wed, 29 Aug 2018 at 07:46, wilk > 
>> wrote:
>> >
>> >
>> > It could be fine to start a wiki page to list the tools and ide
>> > (not)ready for modules with the linked issues.
>> >
>> > In https://github.com/golang/go/wiki/Modules or a new page ?
>> >
>> > On 29-08-2018, Paul Jolly wrote:
>> > > --50127c057491b176
>> > > Content-Type: text/plain; charset="UTF-8"
>> > >
>> > > Please see https://github.com/golang/gddo/issues/567
>> > >
>> > > On Tue, 28 Aug 2018, 18:59 Justin Israel, > > wrote:
>> > >
>> > >> I've been trying out converting some of our internal projects to go 
>> 1.11
>> > >> using modules instead of glide. We have a build system that provides 
>> the
>> > >> ability to generate html docs via "godoc" and I am wondering if 
>> godoc has
>> > >> been made "module-aware" in go 1.11?
>> > >>
>> > >> My particular project is using the migration approach of setting 
>> "v3" at
>> > >> in the go.mod, and in all import paths within the project. But it 
>> seems
>> > >> godoc is not happy about this:
>> > >>
>> > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
>> > >>
>> > >> 2018/08/29 11:52:12 error while importing build package: cannot find 
>> package "domain.com/group/project/v3/lib/foo" in any of:
>> > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo 
>> (from $GOROOT)
>> > >> /usr/home/justin/src/go/src/
>> domain.com/group/project/v3/lib/foo (from $GOPATH)
>> > >> 2018/08/29 11:52:12 cannot find package "." in:
>> > >> /src/domain.com/group/project/v3/lib/foo
>> > >>
>> > >>
>> > >> It seems to only care about the filesystem structure and not the 
>> module import path naming?
>> > >>
>> > >>
>> > >> Justin
>> > >>
>> > >>
>> > >> --
>> > >> You received this message because you are subscribed to the Google 
>> Groups
>> > >> "golang-nuts" group.
>> > >> To unsubscribe from this group and stop receiving emails from it, 
>> send an
>> > >> email to golang-nuts...@googlegroups.com .
>> > >> For more options, visit https://groups.google.com/d/optout.
>> > >>
>> > >
>> >
>> >
>> > --
>> > William
>> >
>> > --
>> > 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...@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.