Re: [go-nuts] installing the rename tool

Thank you! On Thursday, October 5, 2017 at 9:31:09 AM UTC-7, Jan Mercl wrote: > > > On Thu, Oct 5, 2017 at 5:22 PM sparc1998 > wrote: > > > I tried to install go's rename tool using go get > golang.org/x/tools/refactor/rename. This installed some related files in >

[go-nuts] Variable scope for text/template

Hi all, Please see linked example code. I've been trying set a "global" variable ($LastName in the example) for use inside a named template (phony in the example), but the scoping rules for the template packages does not follow common scoping rules typically used in other languages, including

RE: [go-nuts] Are all running goroutines killed when main ends?

The only answer I have is to ask those goroutines to exit, the wait for them to exit. Context is part of this, combined with a waitgroup to track goroutines in flight. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

RE: [go-nuts] Are all running goroutines killed when main ends?

Any easy way to make their defers run? John John Souvestre - New Orleans LA -Original Message- From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 October 05, Thu 23:36 To: golang-nuts Subject: [go-nuts] Are all running

[go-nuts] Are all running goroutines killed when main ends?

Yes, they will be stopped. However they will be stopped abruptly, no defers will run. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Are all running goroutines killed when main ends?

On Thu, Oct 5, 2017 at 8:09 PM, go-question wrote: > > When a program's main ends, will all running goroutines that were created by > the program also be stopped and cleaned up? Yes. Ian -- You received this message because you are subscribed to the Google Groups

[go-nuts] Are all running goroutines killed when main ends?

When a program's main ends, will all running goroutines that were created by the program also be stopped and cleaned up? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an

Re: [go-nuts] binary.Read()

On Thu, Oct 5, 2017 at 9:10 PM Johan terryn wrote: > Here is the full (trimmed) working program: The program compiles just fine (https://play.golang.org/p/Xg3qlovrzg), where is the problem? -- -j -- You received this message because you are subscribed to the Google

Re: [go-nuts] binary.Read()

Here is the full (trimmed) working program: // Exif project Exif.go package main import ( //"bytes" "encoding/binary" "fmt" "os" ) const JPEGSOIMarker = 0xffd8 const APPMarkerBegin = 0xffe1 const APPMarkerEnd = 0xffef const ExifEncoding = "II" type Header struct {

Re: [go-nuts] binary.Read()

On Thu, 5 Oct 2017, at 08:58 AM, Johan terryn wrote: > In following code: > > type JPGFile struct { > Exif_SOI [2]byte Exif } type Exif struct { APP1Marker [2]byte > APP1DataSize uint16 ExifHeader [6]byte TIFFHeader[6]byte }> func > ReadFile(filename string) (JPGFile, error) {

Re: [go-nuts] binary.Read()

On Thu, Oct 5, 2017 at 5:22 PM Johan terryn wrote: > Or is this working as intended? Hard to tell w/o a complete, self contained reproduction program. But note that os.File is not an io.Reader, *os.File is. -- -j -- You received this message because you are

Re: [go-nuts] installing the rename tool

On Thu, Oct 5, 2017 at 5:22 PM sparc1998 wrote: > I tried to install go's rename tool using go get golang.org/x/tools/refactor/rename. This installed some related files in ~/go/src and ~/go/pkg, but it didn't install a new tool in ~/go/bin, and I'm wondering why? Because

Re: [go-nuts] Best practices for internal repository management

Thank you, Russ! Those points make a lot of sense. >From a logistics standpoint, I'm curious if there have been successful go-monorepo code base built on top of commonly available systems (i.e. git). Like is a Bazel system as per kubernetes a

[go-nuts] binary.Read()

In following code: type JPGFile struct { Exif_SOI [2]byte Exif } type Exif struct {APP1Marker [2]byteAPP1DataSize uint16ExifHeader [6]byteTIFFHeader[6]byte} func ReadFile(filename string) (JPGFile, error) { jpgFile := JPGFile{} in, err :=

[go-nuts] installing the rename tool

I am using go on OS X 10.12. I installed go using the OS X package installer , which installed it to /usr/local/go. I've tried installing other go tools. For example, I used go get golang.org/x/tools/cmd/goimports to install goimports, and it installed to

Re: [go-nuts] Announcing 3 new libraries

HI Shawn, Thanks for the response! The main thing with apex log is that it was designed to allow centralisation of logs from multiple sources - and that's the use case I had when developing these extensions. It's also a little lighter and simpler than logrus, but structured in such a way

Re: [go-nuts] Announcing 3 new libraries

Thanks, Geoffrey! I hadn't heard of the Apex logger, but after your e-mail I found this: https://medium.com/@tjholowaychuk/apex-log-e8d9627f4a9a Looks great. Let me point out that Geoffrey is the original author of the tealeg/xlsx package, which I know many of us have used. ^_^ Since it's

[go-nuts] Announcing 3 new libraries

On behalf of the development team at Avocet Systems Ltd, I'm happy to announce 3 small open-source Go libraries that all extend the functionality of the github.com/apex/log package. 1. apexorc ( https://github.com/avct/apexorc  )

[go-nuts] Why are two slices in this example less costly than one?

I was playing around with the implementation of FieldsFunc from the bytes package and I was wondering how it would affect the benchmarks to disregard the extra slice that was used there to calculate offsets. It only made sense that it would make things faster. To my amusement (although

Re: [go-nuts] Go Fonts: Double double copyright notice in gomono.TTF and friends

Thanks for clarifying that On Wednesday, October 4, 2017 at 11:13:25 PM UTC-7, Nigel Tao wrote: > > On Sun, Oct 1, 2017 at 8:50 AM, as > wrote: > > The official go fonts contain two identical copyright notices inside the > TTF > > data slice. One in UTF-8 and one in UTF16

Re: [go-nuts] Re: XML unmarshaller doesn't handle whitespace

On Thu, Oct 05, 2017 at 12:48:53AM -0700, Per Persson wrote: > > Probably it's best to ask here before I try to contact the Go developers. > > > > I had a file with space padded numbers (NumberOfPoints=" 266703") and > > the XML unmarshaller couldn't handle the spaces. > > > > Booleans are

[go-nuts] Re: XML unmarshaller doesn't handle whitespace

Thanks for a good answer and a good suggestion of a solution! Perhaps I should take the question to the developers to have them either give a technical answer or discuss a change. Den måndag 2 oktober 2017 kl. 12:10:19 UTC+2 skrev Per Persson: > > Probably it's best to ask here before I try to

Re: [go-nuts] XML unmarshaller doesn't handle whitespace

On Mon, Oct 02, 2017 at 03:10:19AM -0700, Per Persson wrote: > Probably it's best to ask here before I try to contact the Go developers. > > I had a file with space padded numbers (NumberOfPoints=" 266703") and the > XML unmarshaller couldn't handle the spaces. > > Booleans are trimmed >

Re: [go-nuts] Go Fonts: Double double copyright notice in gomono.TTF and friends

On Sun, Oct 1, 2017 at 8:50 AM, as wrote: > The official go fonts contain two identical copyright notices inside the TTF > data slice. One in UTF-8 and one in UTF16 format. These make their way into > the final go binary. Bug or intentional TTF standard? Intentional,