[go-nuts] Looking for a way to monitor all active Go channels

['Ingo Oeser' via golang-nuts]

I would suggest opening an issue for that, if it isn't.

A runtime provided profile similar to the contention profile might be very 
useful here. 

But that needs careful design. 

-- 
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] Does fmt.Print* automatically render an error string in as struct (play link)

['Borman, Paul' via golang-nuts]

In your code, anything that implements thing also implements the error 
interface, which looks just like your thing interface.  Printf knows to use the 
Error method if it is defined.  See https://play.golang.org/p/JucIqt9H2FF.  You 
will notice that with your code you can say:

var e error = t

demonstrating that t is in fact an error (was well as a thing).

-Paul

From:  on behalf of Louki Sumirniy 

Date: Tuesday, August 28, 2018 at 7:16 PM
To: golang-nuts 
Subject: [go-nuts] Does fmt.Print* automatically render an error string in as 
struct (play link)

I discovered quite by accident and now I can't find anything saying as such, 
but this example

package main

import (
  "fmt"
  "errors"
)

type Thing struct {
  err error
}

type thing interface {
  Error() string
}

func (t *Thing) Error() string {
  return t.err.Error()
}

func main() {
  t := new(Thing)
  t.err = errors.New("testing")
  fmt.Println(t)
}

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

as you can see by running it, prints the error value inside the struct.

I am writing a library where I am using a 'pipeline' model so I can string 
pointer methods together in a chain, which requires putting an error value 
inside the structure, and then it does this when I print the struct. It's quite 
handy but unexpected. I assume if a struct satisfies the error interface it 
calls it to generate the string.
--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: Unexpected behavior of %+02d in Sprintf() and friends

[Eric Raymond]

On Tuesday, August 28, 2018 at 4:49:02 PM UTC-4, peterGo wrote:
>
> "Width is specified by an optional decimal number immediately preceding 
> the verb. If absent, the width is whatever is necessary to represent the 
> value. "
>
> https://golang.org/pkg/fmt/
>
> Width is two.
>

Thanks for the clarification.  May I recommend appending to that sentence 
"(including the leading sign, if any, even if the sign is forced by a + 
modifier)"?

I still think i saw apparently inconsistent behavior.  I'm still writing 
unit tests involving date conversions, so I'm going to try to reproduce 
this and turn in an actionable report.

-- 
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] More trouble with date formatting

[Eric Raymond]

The attached program emits 

go1.10.1: value '2010-10-27 18:43:32 + +' error 

on my system.  Note the duplicated zone field. Is this expected?

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


gobug2.go
Description: Binary data

Re: [go-nuts] Re: Unexpected behavior of %+02d in Sprintf() and friends

['Borman, Paul' via golang-nuts]

Is it possible you used the format string “+%02d” vs “%+02d”?  The first will 
give you the +00 you expected while the second is +0, as discussed.

On Aug 29, 2018, at 6:53 AM, Eric Raymond 
mailto:e...@thyrsus.com>> wrote:

On Tuesday, August 28, 2018 at 4:49:02 PM UTC-4, peterGo wrote:
"Width is specified by an optional decimal number immediately preceding the 
verb. If absent, the width is whatever is necessary to represent the value. "

https://golang.org/pkg/fmt/

Width is two.

Thanks for the clarification.  May I recommend appending to that sentence 
"(including the leading sign, if any, even if the sign is forced by a + 
modifier)"?

I still think i saw apparently inconsistent behavior.  I'm still writing unit 
tests involving date conversions, so I'm going to try to reproduce this and 
turn in an actionable report.

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

[Paul Jolly]

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+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: Unexpected behavior of %+02d in Sprintf() and friends

[Eric Raymond]

On Wednesday, August 29, 2018 at 7:57:23 AM UTC-4, Borman, Paul wrote:
>
> Is it possible you used the format string “+%02d” vs “%+02d”?  The first 
> will give you the +00 you expected while the second is +0, as discussed.
>

Alas, no.  Here's the line from my test program:

fmt.Printf("%s: %+02d %02d\n", runtime.Version(), 0, 0)

In the original context where I saw the behavior, I was generating [+-]hhmm 
strings corresponding to timezone offsets. The sign in the output could not 
be fixed in the format; it had to be derived from the offset.




-- 
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] Possible bug in Windows runtime?

[tobykennon via golang-nuts]

Hi All

I'm seeing intermittent crashes in my unit test and wanted to check here 
first to see if anyone has suggestions before I filed an official issue.

Go version: go1.10.3 windows/amd64
GOPATH: C:\go
GOROOT: C:\toolss\go
OS: Windows 10 (10.0.17134) Pro
Computer: Dell XPS 15 9560 with intel core i7

I have written a client/server application. Both client and server are on 
the same machine and communicate via gRPC over a named pipe. In the unit 
tests for the client side I spin up a stubbed server implementation and 
connect to it. The tests pass around 75% of the time, but the remaining 25% 
of the time they fail with runtime errors like this (I can't give the full 
stacktrace as the code is private):

runtime: waitforsingleobject wait_failed; errno=6
fatal error: runtime.semasleep wait_failed

runtime stack:
runtime.throw(0x94ba8a, 0x1d)
C:/tools/go/src/runtime/panic.go:616 +0x88
runtime.semasleep.func2()
C:/tools/go/src/runtime/os_windows.go:579 +0x80
runtime.semasleep(0x, 0x0)
C:/tools/go/src/runtime/os_windows.go:577 +0xe7
runtime.notesleep(0xc04225ed18)
C:/tools/go/src/runtime/lock_sema.go:167 +0xf7
runtime.stopm()
C:/tools/go/src/runtime/proc.go:1952 +0xf3
runtime.findrunnable(0xc04202c500, 0x0)
C:/tools/go/src/runtime/proc.go:2415 +0x521
runtime.schedule()
C:/tools/go/src/runtime/proc.go:2541 +0x149
runtime.goexit0(0xc042214f00)
C:/tools/go/src/runtime/proc.go:2713 +0x244
runtime.mcall(0x0)
C:/tools/go/src/runtime/asm_amd64.s:351 +0x5e

goroutine 1 [chan receive]:
testing.(*T).Run(0xc0423b62d0, 0x93fd1d, 0xb, 0x961438, 0x4932ad)
C:/tools/go/src/testing/testing.go:825 +0x308
testing.runTests.func1(0xc0423b61e0)
C:/tools/go/src/testing/testing.go:1063 +0x6b
testing.tRunner(0xc0423b61e0, 0xc042091dd8)
C:/tools/go/src/testing/testing.go:777 +0xd7
testing.runTests(0xc042178ee0, 0xc13f20, 0x9, 0x9, 0x0)
C:/tools/go/src/testing/testing.go:1061 +0x2cb
testing.(*M).Run(0xc04218c280, 0x0)
C:/tools/go/src/testing/testing.go:978 +0x178
path/to/my/client.TestMain(0xc04218c280)
C:/go/src/path/to/my/client/my_client_test.go:390 +0x4e
main.main()
_testmain.go:56 +0x158

  .

And like this:

runtime: setevent failed; errno=6
fatal error: runtime.semawakeup

runtime stack:
runtime.throw(0x944972, 0x12)
C:/tools/go/src/runtime/panic.go:616 +0x88
runtime.semawakeup.func1()
C:/tools/go/src/runtime/os_windows.go:597 +0x80
runtime.semawakeup(0xc042204800)
C:/tools/go/src/runtime/os_windows.go:595 +0x53
runtime.notewakeup(0xc042204918)
C:/tools/go/src/runtime/lock_sema.go:147 +0x60
runtime.startm(0x0, 0xc042028001)
C:/tools/go/src/runtime/proc.go:2017 +0xe1
runtime.wakep()
C:/tools/go/src/runtime/proc.go:2083 +0x4f
runtime.resetspinning()
C:/tools/go/src/runtime/proc.go:2454 +0x7f
runtime.schedule()
C:/tools/go/src/runtime/proc.go:2548 +0x133
runtime.goexit0(0xc042348000)
C:/tools/go/src/runtime/proc.go:2713 +0x244
runtime.mcall(0x0)
C:/tools/go/src/runtime/asm_amd64.s:351 +0x5e

goroutine 1 [chan receive]:
testing.(*T).Run(0xc04249a1e0, 0x93fd1d, 0xb, 0x961438, 0x4932ad)
C:/tools/go/src/testing/testing.go:825 +0x308
testing.runTests.func1(0xc04249a0f0)
C:/tools/go/src/testing/testing.go:1063 +0x6b
testing.tRunner(0xc04249a0f0, 0xc042091dd8)
C:/tools/go/src/testing/testing.go:777 +0xd7
testing.runTests(0xc042178ec0, 0xc13f20, 0x9, 0x9, 0x0)
C:/tools/go/src/testing/testing.go:1061 +0x2cb
testing.(*M).Run(0xc04218e280, 0x0)
C:/tools/go/src/testing/testing.go:978 +0x178
path/to/my/client.TestMain(0xc04218e280)
C:/go/src/path/to/my/client/my_client_test.go:390 +0x4e
main.main()
_testmain.go:56 +0x158

  .

Errno 6 is Windows jargon for an invalid handle which is an expected error 
from WaitForSingleObject (
https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-waitforsingleobject).
 
Has anyone seen this before?

Any help greatly appreciate, and let me know if I can provide more 
information.

Cheers
Toby

-- 
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] UnmarshalTypeError does not provide Field name anynmore

[kiteboarder34]

I’m using a custom unmarshaler in my code for dedicated types, in case of 
error my code was returning a json.UnmarhsalTypeError


This allowed to retrieve field name where the error occured in case the 
dedicated type was used within a structure


Since I migrated to go1.11, my code do not allow to retrieve field name 
anymore (was Ok in go1.10.3)


Looking at new version of decode.go I could not find an easy workaround to 
this behavior change


To describe more precisely the issue I'm seeing :here is a simple 
playground sample that highlight behavior

https://play.golang.org/p/AtX-5f5jWwS 4 



I saw a few activity around a regression fix in 

https://github.com/golang/go/issues/27275

I did a quick tests on my side using the accepted chagne for the issue 
mentionned abobe and unfortunately this does not help


Is this a regression or an unexpected behavior that dosappeared 
unfortunately ?


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.

Re: [go-nuts] More trouble with date formatting

['Borman, Paul' via golang-nuts]

I put your program onto the playground: https://play.golang.org/p/L0xJgwdLuI3

I notice the output is:

go1.10.3: value '2010-10-27 18:43:32 + UTC' error 

The default format for printing time (it is documented in the Format method on 
time.Time) is:

Mon Jan 2 15:04:05 -0700 MST 2006

Notice the format has both -0700 and MST

Your second + is in place of UTC on the playground.  I would guess your 
system does not have the necessary locale information to translate + to UTC.

-Paul

On Aug 29, 2018, at 6:57 AM, Eric Raymond 
mailto:e...@thyrsus.com>> wrote:

The attached program emits

go1.10.1: value '2010-10-27 18:43:32 + +' error 

on my system.  Note the duplicated zone field. Is this expected?

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


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

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

[wilk]

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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: More trouble with date formatting

[peterGo]

Eric,

The fmt package verb %v  is the value in a default format, typically the 
String method for the type.

func (Time) String 

func (t Time) String() string

String returns the time formatted using the format string

"2006-01-02 15:04:05.9 -0700 MST"

The returned string is meant for debugging.

See https://golang.org/pkg/time/#Time.String

Peter

On Wednesday, August 29, 2018 at 7:57:04 AM UTC-4, Eric Raymond wrote:
>
> The attached program emits 
>
> go1.10.1: value '2010-10-27 18:43:32 + +' error 
>
> on my system.  Note the duplicated zone field. Is this expected?
>

-- 
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] More trouble with date formatting

[peterGo]

Paul,

The Go Playground sandbox has a few peculiarities, for example for date and 
time. Results may not match those found in ordinary use.

Peter

On Wednesday, August 29, 2018 at 9:24:32 AM UTC-4, Borman, Paul wrote:
>
> I put your program onto the playground: 
> https://play.golang.org/p/L0xJgwdLuI3
>
> I notice the output is:
>
> go1.10.3: value '2010-10-27 18:43:32 + UTC' error 
>
> The default format for printing time (it is documented in the Format 
> method on time.Time) is:
>
> Mon Jan 2 15:04:05 -0700 MST 2006
>
> Notice the format has both -0700 and MST
>
> Your second + is in place of UTC on the playground.  I would guess 
> your system does not have the necessary locale information to translate 
> + to UTC.
>
> -Paul
>
> On Aug 29, 2018, at 6:57 AM, Eric Raymond > 
> wrote:
>
> The attached program emits  
>
> go1.10.1: value '2010-10-27 18:43:32 + +' error 
>
> on my system.  Note the duplicated zone field. Is this expected?
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
> 
>
>
>

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

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

[Paul Jolly]

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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: Does fmt.Print* automatically render an error string in as struct (play link)

[jake6502]

>
> I can't find anything saying as such

 
  From https://golang.org/pkg/fmt/ : "*4. If an operand implements the 
error interface, the Error method will be invoked to convert the object to 
a string, which will then be formatted as required by the verb (if any).*"

  As mentioned in another reply, Thing has an Error() method, so it " 
implements the error interface."


On Tuesday, August 28, 2018 at 8:15:31 PM UTC-4, Louki Sumirniy wrote:
>
> I discovered quite by accident and now I can't find anything saying as 
> such, but this example
>
> package main
>
> import (
>   "fmt"
>   "errors"
> )
>
> type Thing struct {
>   err error
> }
>
> type thing interface {
>   Error() string
> }
>
> func (t *Thing) Error() string {
>   return t.err.Error()
> }
>
> func main() {
>   t := new(Thing)
>   t.err = errors.New("testing")
>   fmt.Println(t)
> }
>
> https://play.golang.org/p/xBIGIvSZkqO
>
> as you can see by running it, prints the error value inside the struct. 
>
> I am writing a library where I am using a 'pipeline' model so I can string 
> pointer methods together in a chain, which requires putting an error value 
> inside the structure, and then it does this when I print the struct. It's 
> quite handy but unexpected. I assume if a struct satisfies the error 
> interface it calls it to generate the string.
>

-- 
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] gofmt does not recognize "type x = y"

[rajesh nataraja]

whereas go compiler recognizes it. Why are the tools not matching? This is 
with go 1.9.7 


gofmt throws the following error 

 expected type, found '='


Thanks
Rajesh.

-- 
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: Looking for a way to monitor all active Go channels

[Ingo Jaeckel]

Thanks for the suggestion. I outlined the proposal on 
https://github.com/golang/go/issues/27347. I agree this needs a careful 
design. 


On Wednesday, August 29, 2018 at 2:05:32 AM UTC-7, Ingo Oeser wrote:
>
> I would suggest opening an issue for that, if it isn't.
>
> A runtime provided profile similar to the contention profile might be very 
> useful here. 
>
> But that needs careful design. 
>
>

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

[Justin Israel]

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

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

[go-nuts] Golang function(s) returning EINTR due to 3rd party products being linked/used (revisited)

[estess]

Although I spent some time searching, I have not found an issue quite like 
the one I’m experiencing so here goes. We are working to create a set of 
Golang wrapper functions/methods that call into an existing database 
product (YottaDB) that has a C interface. This was going well until we ran 
into a situation where some Golang design attributes and YottaDB design 
attributes are clashing. Below are listed some of the long-existing design 
attributes of YottaDB that are clashing with Golang:



   1. 
   
   YottaDB uses signal based interrupts – mostly SIGALRM for timer support 
   but other signals as well (SIGINT, SIGUSR1, etc).
   2. 
   
   The design is such that one can specify timeouts for certain functions 
   like socket connection, socket read, lock acquisition, console IO, etc. The 
   expectation is that some system call is interrupted, returns an EINTR, 
   which the code checks for along with a timeout flag set by the actual 
   interrupt, and the wait for whatever resource is ended as the function 
   “times out”. 
   3. 
   
   There are timers throughout the code base that behave the same way – 
   database flush timer, epoch timer, critical section acquisition timer, etc. 
   These all depend on being interrupted rather than just posting an event on 
   a queue or something similar.
   

What I noticed when mixing console input and database actions in a Golang 
program was I’d get errors from things like bufio.ReadString() that 
contained “read /dev/stdin: interrupted system call”, which is of course an 
EINTR return. While I was able to add a check for this error (with a 
seemingly clumsy string comparison with the above string) and just 
‘continue’ the loop to retry, this solution does not lend itself to all 
possible problems this would cause as some failing calls could be deep in 
code we cannot or would not want to change (BTW, it does this on both 
Golang 1.6.2 on my Ubuntu 16.04 box and on Golang 1.9.4 on RHEL 7.5).


My research showed that this issue happens because Golang requires all 
signal handlers in the same process with it have SA_RESTART and SA_ONSTACK 
enabled but YottaDB cannot do that because of the need to cause *some* 
currently running system calls to be interrupted and aborted. I did try it 
and sure enough several tests in our regression test system got hangs due 
to a lack of timeouts.


Is there some workaround for this issue short of redesigning a few hundred 
Kloc of C in YottaDB to play better with Golang (not really an option at 
this point)? If I had complete control over the threads in Golang, I’d 
disable interrupts on all of them except for one bound to a goroutine where 
YottaDB was initialized to control what threads got interrupted but I don’t 
think I have that sort of control. Or if I do, I don’t know what it is or 
how to use it.


SE


-- 
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] gofmt does not recognize "type x = y"

[Ian Lance Taylor]

On Wed, Aug 29, 2018 at 11:41 AM, rajesh nataraja  wrote:
>
> whereas go compiler recognizes it. Why are the tools not matching? This is
> with go 1.9.7
>
>
> gofmt throws the following error
>
>  expected type, found '='

Make sure you are using a gofmt built with Go 1.9, not some older
version that may be on your PATH.

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] Golang function(s) returning EINTR due to 3rd party products being linked/used (revisited)

[Ian Lance Taylor]

On Wed, Aug 29, 2018 at 12:23 PM,   wrote:
>
> Although I spent some time searching, I have not found an issue quite like
> the one I’m experiencing so here goes. We are working to create a set of
> Golang wrapper functions/methods that call into an existing database product
> (YottaDB) that has a C interface. This was going well until we ran into a
> situation where some Golang design attributes and YottaDB design attributes
> are clashing. Below are listed some of the long-existing design attributes
> of YottaDB that are clashing with Golang:
>
>
> YottaDB uses signal based interrupts – mostly SIGALRM for timer support but
> other signals as well (SIGINT, SIGUSR1, etc).
>
> The design is such that one can specify timeouts for certain functions like
> socket connection, socket read, lock acquisition, console IO, etc. The
> expectation is that some system call is interrupted, returns an EINTR, which
> the code checks for along with a timeout flag set by the actual interrupt,
> and the wait for whatever resource is ended as the function “times out”.
>
> There are timers throughout the code base that behave the same way –
> database flush timer, epoch timer, critical section acquisition timer, etc.
> These all depend on being interrupted rather than just posting an event on a
> queue or something similar.
>
>
> What I noticed when mixing console input and database actions in a Golang
> program was I’d get errors from things like bufio.ReadString() that
> contained “read /dev/stdin: interrupted system call”, which is of course an
> EINTR return. While I was able to add a check for this error (with a
> seemingly clumsy string comparison with the above string) and just
> ‘continue’ the loop to retry, this solution does not lend itself to all
> possible problems this would cause as some failing calls could be deep in
> code we cannot or would not want to change (BTW, it does this on both Golang
> 1.6.2 on my Ubuntu 16.04 box and on Golang 1.9.4 on RHEL 7.5).
>
>
> My research showed that this issue happens because Golang requires all
> signal handlers in the same process with it have SA_RESTART and SA_ONSTACK
> enabled but YottaDB cannot do that because of the need to cause *some*
> currently running system calls to be interrupted and aborted. I did try it
> and sure enough several tests in our regression test system got hangs due to
> a lack of timeouts.
>
>
> Is there some workaround for this issue short of redesigning a few hundred
> Kloc of C in YottaDB to play better with Golang (not really an option at
> this point)? If I had complete control over the threads in Golang, I’d
> disable interrupts on all of them except for one bound to a goroutine where
> YottaDB was initialized to control what threads got interrupted but I don’t
> think I have that sort of control. Or if I do, I don’t know what it is or
> how to use it.

I believe this is https://golang.org/issue/20400.  Unfortunately I do
not know of any good workaround for this problem.  Sorry.  The
process-wide nature of signals makes them very hard to manage in
multi-language programs.

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] gofmt does not recognize "type x = y"

[rajesh nataraja]

My bad! I sent it out too soon.  You are right, my paths ended up being 
inconsistent between the two binaries. 

Rajesh.

On Wednesday, August 29, 2018 at 1:09:32 PM UTC-7, Ian Lance Taylor wrote:
>
> On Wed, Aug 29, 2018 at 11:41 AM, rajesh nataraja  > wrote: 
> > 
> > whereas go compiler recognizes it. Why are the tools not matching? This 
> is 
> > with go 1.9.7 
> > 
> > 
> > gofmt throws the following error 
> > 
> >  expected type, found '=' 
>
> Make sure you are using a gofmt built with Go 1.9, not some older 
> version that may be on your PATH. 
>
> Ian 
>

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

Re: [go-nuts] Re: Regarding string immutablity

[Dan Kortschak]

Also see caveats discussed here https://groups.google.com/d/topic/golan
g-nuts/sKQtvluD_So/discussion

On Tue, 2018-08-28 at 17:00 +, 'Borman, Paul' via golang-nuts
wrote:
> You are only overwriting the pointer to the string (a string is
> essentially a pointer and a length).  If you want to use memory and
> then zero it out, use a byte slice instead and be careful to not call
> append where append might allocate new memory.  Take a look at https:
> //play.golang.org/p/GkrKRSvkoRJ.
> 
> -Paul
> 
> On Aug 28, 2018, at 11:45 AM, Jay Sharma  to:jaysharma...@gmail.com>> wrote:
> 
> @Jan, The example you shown it is copying a string to new variable.
> but my question was related to same variable.
> 
> I want to know if I have variable :
> 
> x := "testsring"
> 
> Now it overwrite the content of same variable x to some other value:
> x = "new1string"
> 
> Will it overwrite the same memory or it will create some copy ?
> 
> @Jake Montgomery,
> 
>  It is about security. I have some keys and I want to delete the
> content of key, when no longer required. Here my API is expecting a
> string key.
> 
> 
> On Tuesday, August 28, 2018 at 8:25:27 PM UTC+5:30, Jay Sharma wrote:
> Hi All,
> 
> I went through documentation and many post. Every where it is
> specified strings are immutable.
> 
> I have some string :
> 
> x := "teststring"
> 
> 
> I want to wipe out/overwrite the content of this string x from
> disk/memory.
> 
> As per me the simplest way to do this:
> 
> x = ""
> 
> 
> or If I want to overwrite it with some new content, I can do this:
> [Here length of new string is equal to length of old string]
> 
> x = "new1string"
> 
> 
> As I am overwriting the content with new content, Is it inplace
> replacement [same memory is being updated] or a new copy will be
> created with new content and old content will be there in the memory
> ?
> 
> 
> 
> --
> 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 ng-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] go1.11 no longer supports compressed hostnames in SRV lookup replies

[jason]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go2 Error Handling - Alternate Handler Concept

[Liam]

Re the Go2 Error Handling proposal
  
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

I have posted this feedback
  https://gist.github.com/networkimprov/c6cb3e2dff18d31840f2ef22e79d4a1e

Which contains an alternate handler concept. Please let me know if you 
think this merits its own github.com/golang issue.

A *flag identifier *indicates errors of various types. This also allows 
chaining of handlers with the same flag name. There are options for the #flag 
syntax, e.g. flag!, $flag, @flag, etc.

func f() {
   v, #ret := returnIfError()   // #ret can be any type; any non-zero value for 
it triggers its catch
   v, #fat := fatalIfError()// #ret, etc are (probably) not local variables
   v, #wrt := writeOnError()
   if v != nice { // new scope
  #fat = MyError{msg:"!nice", ...}
  catch fat error { debug.PrintStack() }  // no return/exit; chained 
with next catch fat
   }
   #packageFlag = anotherError() // invokes package-level handler
   
   catch ret error { return ret } // if type is error, type 
name could be optional
   catch fat error { log.Fatal(fat) }
   catch wrt error { con.Write(...); return nil } // return/exit required in 
last handler on chain
}

catch packageFlag error { ... } // package-level handler; packageFlag is not a 
package variable

-- 
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] go1.11 no longer supports compressed hostnames in SRV lookup replies

[Nathan Fisher]

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+unsubscr...@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] go1.11 no longer supports compressed hostnames in SRV lookup replies

[jason]

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.

[go-nuts] Compiler Bug: function argument hiding built-in function results in a compiler crash

[taylorza]

Hi,

Before reporting this bug I thought I would post here to confirm that it 
has not been covered already.

If a function argument hides a built-in function and there is an attempt to 
call the built-in function the compiler will crash with no indication of 
where it was in the compilation process, which makes it hard to find in a 
large codebase.

Here is a simple repo of the issue

package main

var a = []byte{1,2,3}

func bug(len int) bool {
return len < len(a)
}

func main() { 
println(bug(5))
}

Here the argument len hides the built-in function len, and in that same 
function a call is made to the function len. The expected result would be a 
compiler error

*cannot call non-function len (type int)*

The actual result is 


> *panic: runtime error: invalid memory address or nil pointer 
> dereference[signal 0xc005 code=0x0 addr=0x70 pc=0xb94675]*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *goroutine 1 [running]:cmd/compile/internal/gc.typecheck1(0xc000352580, 
> 0x2, 0xc00033fa40)
> c:/go/src/cmd/compile/internal/gc/typecheck.go:1270 
> +0x3ed5cmd/compile/internal/gc.typecheck(0xc000352580, 0x2, 
> 0xc00033fa40)c:/go/src/cmd/compile/internal/gc/typecheck.go:238 
> +0x6b4cmd/compile/internal/gc.typecheck1(0xc000352600, 0x12, 
> 0xc84998)c:/go/src/cmd/compile/internal/gc/typecheck.go:585 
> +0x2ccecmd/compile/internal/gc.typecheck(0xc000352600, 0x12, 
> 0xc849d8)c:/go/src/cmd/compile/internal/gc/typecheck.go:238 
> +0x6b4cmd/compile/internal/gc.typecheckslice(0xc885d0, 0x1, 0x1, 
> 0x12)c:/go/src/cmd/compile/internal/gc/typecheck.go:68 
> +0x57cmd/compile/internal/gc.typecheck1(0xc000352680, 0x1, 0xcbf373)
> c:/go/src/cmd/compile/internal/gc/typecheck.go:2065 
> +0xadd4cmd/compile/internal/gc.typecheck(0xc000352680, 0x1, 0x3)
> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 
> +0x6b4cmd/compile/internal/gc.typecheckslice(0xc885d8, 0x1, 0x1, 
> 0x1)c:/go/src/cmd/compile/internal/gc/typecheck.go:68 
> +0x57cmd/compile/internal/gc.Main(0xcdea30)
> c:/go/src/cmd/compile/internal/gc/main.go:518 +0x20d0main.main()
> c:/go/src/cmd/compile/main.go:51 +0x9d*
>

Best Regards,

Chris 

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

[go-nuts] Character Replacement/Algorithm for Replacement

[agruetz45]

I have approximately 9 characters that all need to be replaced with 
different characters. I know there are a number of ways to do this but what 
is the most efficient?


   - 1) Do a []byte walk and compare each byte and replace when found?
   - Seems expensive if you have a 100 bytes in the []byte
 - comes out to a max of 900 operations
  - 2) Use byte.Replace() for each one?
   - This seems to be about the same as #1 but seems like it makes a copy 
  so might use slightly more memory
   - 3) Regex for each one?
   - Seems like using a nuke to kill a flee
  - Seems expensive in processing
   - 4) Something I have not thought of?
   - Specific algorithm to solve this?
   

The []byte slice it self likely will not be over 100 bytes, however they 
may be be 10s of thousands of them.

Thanks,
Anthony Gruetzmacher

-- 
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: Compiler Bug: function argument hiding built-in function results in a compiler crash

[taylorza]

Sorry, should have mentioned I came across this in *go1.11* but I have not 
validated that it is not an issue in earlier releases.

On Wednesday, August 29, 2018 at 9:14:03 PM UTC-4, Chris Taylor wrote:
>
> Hi,
>
> Before reporting this bug I thought I would post here to confirm that it 
> has not been covered already.
>
> If a function argument hides a built-in function and there is an attempt 
> to call the built-in function the compiler will crash with no indication of 
> where it was in the compilation process, which makes it hard to find in a 
> large codebase.
>
> Here is a simple repo of the issue
>
> package main
>
> var a = []byte{1,2,3}
>
> func bug(len int) bool {
> return len < len(a)
> }
>
> func main() { 
> println(bug(5))
> }
>
> Here the argument len hides the built-in function len, and in that same 
> function a call is made to the function len. The expected result would be a 
> compiler error
>
> *cannot call non-function len (type int)*
>
> The actual result is 
>
>
>> *panic: runtime error: invalid memory address or nil pointer 
>> dereference[signal 0xc005 code=0x0 addr=0x70 pc=0xb94675]*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *goroutine 1 [running]:cmd/compile/internal/gc.typecheck1(0xc000352580, 
>> 0x2, 0xc00033fa40)
>> c:/go/src/cmd/compile/internal/gc/typecheck.go:1270 
>> +0x3ed5cmd/compile/internal/gc.typecheck(0xc000352580, 0x2, 
>> 0xc00033fa40)c:/go/src/cmd/compile/internal/gc/typecheck.go:238 
>> +0x6b4cmd/compile/internal/gc.typecheck1(0xc000352600, 0x12, 
>> 0xc84998)c:/go/src/cmd/compile/internal/gc/typecheck.go:585 
>> +0x2ccecmd/compile/internal/gc.typecheck(0xc000352600, 0x12, 
>> 0xc849d8)c:/go/src/cmd/compile/internal/gc/typecheck.go:238 
>> +0x6b4cmd/compile/internal/gc.typecheckslice(0xc885d0, 0x1, 0x1, 
>> 0x12)c:/go/src/cmd/compile/internal/gc/typecheck.go:68 
>> +0x57cmd/compile/internal/gc.typecheck1(0xc000352680, 0x1, 0xcbf373)
>> c:/go/src/cmd/compile/internal/gc/typecheck.go:2065 
>> +0xadd4cmd/compile/internal/gc.typecheck(0xc000352680, 0x1, 0x3)
>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 
>> +0x6b4cmd/compile/internal/gc.typecheckslice(0xc885d8, 0x1, 0x1, 
>> 0x1)c:/go/src/cmd/compile/internal/gc/typecheck.go:68 
>> +0x57cmd/compile/internal/gc.Main(0xcdea30)
>> c:/go/src/cmd/compile/internal/gc/main.go:518 +0x20d0main.main()
>> c:/go/src/cmd/compile/main.go:51 +0x9d*
>>
>
> Best Regards,
>
> Chris 
>

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

Re: [go-nuts] Re: Compiler Bug: function argument hiding built-in function results in a compiler crash

[Ian Lance Taylor]

On Wed, Aug 29, 2018 at 6:16 PM,   wrote:
> Sorry, should have mentioned I came across this in go1.11 but I have not
> validated that it is not an issue in earlier releases.

I can't find anything similar in the issue tracker.  Please do file a
bug report at https://golang.org/issue.  Thanks.

Ian


> On Wednesday, August 29, 2018 at 9:14:03 PM UTC-4, Chris Taylor wrote:
>>
>> Hi,
>>
>> Before reporting this bug I thought I would post here to confirm that it
>> has not been covered already.
>>
>> If a function argument hides a built-in function and there is an attempt
>> to call the built-in function the compiler will crash with no indication of
>> where it was in the compilation process, which makes it hard to find in a
>> large codebase.
>>
>> Here is a simple repo of the issue
>>
>> package main
>>
>> var a = []byte{1,2,3}
>>
>> func bug(len int) bool {
>> return len < len(a)
>> }
>>
>> func main() {
>> println(bug(5))
>> }
>>
>> Here the argument len hides the built-in function len, and in that same
>> function a call is made to the function len. The expected result would be a
>> compiler error
>>
>>> cannot call non-function len (type int)
>>
>>
>> The actual result is
>>
>>> panic: runtime error: invalid memory address or nil pointer dereference
>>> [signal 0xc005 code=0x0 addr=0x70 pc=0xb94675]
>>> goroutine 1 [running]:
>>> cmd/compile/internal/gc.typecheck1(0xc000352580, 0x2, 0xc00033fa40)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:1270 +0x3ed5
>>> cmd/compile/internal/gc.typecheck(0xc000352580, 0x2, 0xc00033fa40)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6b4
>>> cmd/compile/internal/gc.typecheck1(0xc000352600, 0x12, 0xc84998)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:585 +0x2cce
>>> cmd/compile/internal/gc.typecheck(0xc000352600, 0x12, 0xc849d8)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6b4
>>> cmd/compile/internal/gc.typecheckslice(0xc885d0, 0x1, 0x1, 0x12)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x57
>>> cmd/compile/internal/gc.typecheck1(0xc000352680, 0x1, 0xcbf373)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:2065 +0xadd4
>>> cmd/compile/internal/gc.typecheck(0xc000352680, 0x1, 0x3)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6b4
>>> cmd/compile/internal/gc.typecheckslice(0xc885d8, 0x1, 0x1, 0x1)
>>> c:/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x57
>>> cmd/compile/internal/gc.Main(0xcdea30)
>>> c:/go/src/cmd/compile/internal/gc/main.go:518 +0x20d0
>>> main.main()
>>> c:/go/src/cmd/compile/main.go:51 +0x9d
>>
>>
>> Best Regards,
>>
>> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] gofmt formats different than goimports in go1.11

[Ian Lance Taylor]

On Tue, Aug 28, 2018 at 11:58 PM, Rohit Jain  wrote:
>>Rebuild goimports with Go 1.11.
>
> Thanks, Ian,
> I did go get -v -u golang.org/x/tools/cmd/goimports after removing
> `goimports` from $GOPATH/bin, still the same behaviour

Ah, OK, in that case make sure you are using the 1.11 version of gofmt.

Ian


> On Wed, Aug 29, 2018 at 5:24 AM Ian Lance Taylor  wrote:
>>
>> On Tue, Aug 28, 2018 at 10:26 AM, Rohit Jain 
>> wrote:
>> >
>> > ```err := testService.test.UpdateWithQuery(
>> >  ctx,
>> >  bson.M{
>> > -"id":   campaignID,
>> > +"id": campaignID,
>> >  "x_yyy.testing": x.y,
>> >  },
>> > ```
>> > gofmt reports above diff
>> >
>> >
>> > ```err := testService.test.UpdateWithQuery(
>> >  ctx,
>> >  bson.M{
>> > -"id": campaignID,
>> > +"id":   campaignID,
>> >   "x_yyy.testing": x.y,
>> >  },
>> > ```
>> >
>> > goimport reports above diff
>> >
>> > if I correct the `goimports` suggrstion , gofmt reports the error and
>> > vice
>> > -versa.
>> >
>> > how do I solve this?
>>
>> Rebuild goimports with Go 1.11.
>>
>> Ian
>
>
>
> --
> Rohit Jain

-- 
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: Compiler Bug: function argument hiding built-in function results in a compiler crash

[taylorza]

Thanks Ian, I have filed the bug report : 
https://github.com/golang/go/issues/27356

On Wednesday, August 29, 2018 at 9:22:49 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Aug 29, 2018 at 6:16 PM,  > 
> wrote: 
> > Sorry, should have mentioned I came across this in go1.11 but I have not 
> > validated that it is not an issue in earlier releases. 
>
> I can't find anything similar in the issue tracker.  Please do file a 
> bug report at https://golang.org/issue.  Thanks. 
>
> Ian 
>
>
> > On Wednesday, August 29, 2018 at 9:14:03 PM UTC-4, Chris Taylor wrote: 
> >> 
> >> Hi, 
> >> 
> >> Before reporting this bug I thought I would post here to confirm that 
> it 
> >> has not been covered already. 
> >> 
> >> If a function argument hides a built-in function and there is an 
> attempt 
> >> to call the built-in function the compiler will crash with no 
> indication of 
> >> where it was in the compilation process, which makes it hard to find in 
> a 
> >> large codebase. 
> >> 
> >> Here is a simple repo of the issue 
> >> 
> >> package main 
> >> 
> >> var a = []byte{1,2,3} 
> >> 
> >> func bug(len int) bool { 
> >> return len < len(a) 
> >> } 
> >> 
> >> func main() { 
> >> println(bug(5)) 
> >> } 
> >> 
> >> Here the argument len hides the built-in function len, and in that same 
> >> function a call is made to the function len. The expected result would 
> be a 
> >> compiler error 
> >> 
> >>> cannot call non-function len (type int) 
> >> 
> >> 
> >> The actual result is 
> >> 
> >>> panic: runtime error: invalid memory address or nil pointer 
> dereference 
> >>> [signal 0xc005 code=0x0 addr=0x70 pc=0xb94675] 
> >>> goroutine 1 [running]: 
> >>> cmd/compile/internal/gc.typecheck1(0xc000352580, 0x2, 0xc00033fa40) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:1270 +0x3ed5 
> >>> cmd/compile/internal/gc.typecheck(0xc000352580, 0x2, 0xc00033fa40) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6b4 
> >>> cmd/compile/internal/gc.typecheck1(0xc000352600, 0x12, 0xc84998) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:585 +0x2cce 
> >>> cmd/compile/internal/gc.typecheck(0xc000352600, 0x12, 0xc849d8) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6b4 
> >>> cmd/compile/internal/gc.typecheckslice(0xc885d0, 0x1, 0x1, 0x12) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x57 
> >>> cmd/compile/internal/gc.typecheck1(0xc000352680, 0x1, 0xcbf373) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:2065 +0xadd4 
> >>> cmd/compile/internal/gc.typecheck(0xc000352680, 0x1, 0x3) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6b4 
> >>> cmd/compile/internal/gc.typecheckslice(0xc885d8, 0x1, 0x1, 0x1) 
> >>> c:/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x57 
> >>> cmd/compile/internal/gc.Main(0xcdea30) 
> >>> c:/go/src/cmd/compile/internal/gc/main.go:518 +0x20d0 
> >>> main.main() 
> >>> c:/go/src/cmd/compile/main.go:51 +0x9d 
> >> 
> >> 
> >> Best Regards, 
> >> 
> >> Chris 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@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: os.WriteFile not writing files in long running process

[Matt Harden]

>From the program's perspective the file is indeed flushed on close. The
kernel deferring writes to disk can only have any effect if the system
crashes, and the files will be flushed to disk within a short time anyway.
You absolutely do NOT need to call fsync every file on close unless you
require the data to be written to disk synchronously. In the vast majority
of cases you don't need that, and calling fsync takes a long time and makes
the system less efficient.

On Mon, Aug 27, 2018 at 3:09 AM Manlio Perillo 
wrote:

> No, the file is not flushed on close.
> https://linux.die.net/man/2/close
>
> "A successful close does not guarantee that the data has been successfully
> saved to disk, as the kernel defers writes. It is not common for a file
> system to flush the buffers when the stream is closed. If you need to be
> sure that the data is physically stored use fsync
> (2). (It will depend on the disk
> hardware at this point.)"
>
> You can just Sync the file, to make sure this not the problem.
>
>
> Manlio
>
> On Monday, August 27, 2018 at 10:19:37 AM UTC+2, Paweł Szczur wrote:
>>
>> If you're asking about dmesg, I'm not seeing anything related.
>> Yes, I'm on linux. The dir was created successfully, I guess it was not a
>> problem. Also, I believe the file is flushed on Close.
>>
>> I will look into the link.
>>
>> Paweł
>>
>> On Friday, August 24, 2018 at 6:33:15 PM UTC+2, Manlio Perillo wrote:
>>>
>>> On Friday, August 24, 2018 at 4:19:17 PM UTC+2, Paweł Szczur wrote:

 Thanks. Both things you mentioned are already fixed. The MakeDir may of
 course fail and now I handle it, but in described situation it was not an
 issue.
 The files were written for most of the day successfully and suddenly
 they stopped to appear.
 The disk was and is not full. There was no error returned by any
 function (I've examined logs).

>>>
>>> Did you checked the system/kernel logs?
>>>
>>> If you still are unable to find the cause of the problem, and assuming
>>> you are on an UNIX system, you can try to change the code to make sure that
>>> both the new directory entry, and the new file data is flushed to disk.
>>> For the directory entry you have to open the directory with os.OpenFile,
>>> passing the os.O_RDONLY|unix.O_DIRECTORY flags, and call Sync after the new
>>> file is created.
>>>
>>> See http://danluu.com/file-consistency/
>>>
>>>
>>> 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.
>

-- 
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] Are Go floats smarter?

[José Colón]

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] Are Go floats smarter?

[Dan Kortschak]

The calculation you are doing there is likely using the compiler's
constants which are at least 256 bits wide (https://golang.org/ref/spec
#Constants)

This displays the difference: https://play.golang.org/p/qNDzoh63LDk

See also https://blog.golang.org/constants

On Wed, 2018-08-29 at 19:33 -0700, 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.

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

[Tristan Rice]

I believe this is because that expression is handled as an untyped constant 
by the compiler. If you actually create proper variables with the values 
you get the same result as Java, Python, etc.

https://play.golang.org/p/tIMpYT-bFzm

On Wednesday, August 29, 2018 at 7:33:16 PM UTC-7, 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

[Daniela Petruzalek]

Do you have an example?

I'm assuming that the replacement is one character for another. (ie.: not
one character being replaced by a group of characters).

Regarding to finding the positions to replace you can't beat O(n)
complexity as you must look at least once at every character on the source
string.

In regards to finding the replacement... the 9 characters could be stored
in a dictionary (map in Go) with their counterparts. Since a dictionary
lookup is O(1) in the average case you still have an O(n) algorithm. But,
since the byte[] size will not be over 100, you may assume that n is
constant too, so it's a constant time algorithm.

You didn't mention if the replacement should be in-place or not, so I'm
assuming it's in place.

Something like this I suppose:

func main() {
dict := map[byte]byte {0:1, 1:2, 3: 5}
arr := []byte{0,1,1,2,3,5,8,13,21}
fmt.Printf("Before: %#v", arr)
for i, b := range arr {
if replacement, ok := dict[b]; ok {
arr[i] = replacement
}
}
fmt.Printf("After: %#v", arr)
}

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

O(n) time complexity (or O(1) if n  == 100) and O(k) additional space for
the dictionary.

Best,

Dani

Em qua, 29 de ago de 2018 às 22:15,  escreveu:

> I have approximately 9 characters that all need to be replaced with
> different characters. I know there are a number of ways to do this but what
> is the most efficient?
>
>
>- 1) Do a []byte walk and compare each byte and replace when found?
>- Seems expensive if you have a 100 bytes in the []byte
>  - comes out to a max of 900 operations
>   - 2) Use byte.Replace() for each one?
>- This seems to be about the same as #1 but seems like it makes a copy
>   so might use slightly more memory
>- 3) Regex for each one?
>- Seems like using a nuke to kill a flee
>   - Seems expensive in processing
>- 4) Something I have not thought of?
>- Specific algorithm to solve this?
>
>
> The []byte slice it self likely will not be over 100 bytes, however they
> may be be 10s of thousands of them.
>
> Thanks,
> Anthony Gruetzmacher
>
> --
> 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]

[John Shahid]

-- 
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] using go modules replace with old repos

[John Shahid]

Hi all,

Is there a way to use the go module `replace' directive for packages
that don't have go.mod yet ? I tried doing that and I get the following
error:

> go: parsing ../pkg/go.mod: open /path/to/pkg/go.mod: no such file or
> directory

According to https://github.com/golang/go/issues/24110 it looks like
this is the intended behavior.  My question is why the go tool (e.g. go
get) can deal with such package when downloading it from github and
could give it a pseudo version without a go.mod file but refuses to when
the source code is local.

I'm happy to construct a sample github project to repro the issue if
that is needed.

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

[agruetz45]

Makes sense. Best I am going to get is a linear search w/ a divide and 
conquer if I want to speed it up. Thanks needed the sounding board and feed 
back.

Thanks,
Anthony 

On Wednesday, August 29, 2018 at 8:16:44 PM UTC-7, Daniela Petruzalek wrote:
>
> Do you have an example?
>
> I'm assuming that the replacement is one character for another. (ie.: not 
> one character being replaced by a group of characters).
>
> Regarding to finding the positions to replace you can't beat O(n) 
> complexity as you must look at least once at every character on the source 
> string.
>
> In regards to finding the replacement... the 9 characters could be stored 
> in a dictionary (map in Go) with their counterparts. Since a dictionary 
> lookup is O(1) in the average case you still have an O(n) algorithm. But, 
> since the byte[] size will not be over 100, you may assume that n is 
> constant too, so it's a constant time algorithm.
>
> You didn't mention if the replacement should be in-place or not, so I'm 
> assuming it's in place.
>
> Something like this I suppose:
>
> func main() {
> dict := map[byte]byte {0:1, 1:2, 3: 5}
> arr := []byte{0,1,1,2,3,5,8,13,21}
> fmt.Printf("Before: %#v", arr)
> for i, b := range arr {
> if replacement, ok := dict[b]; ok {
> arr[i] = replacement
> }
> }
> fmt.Printf("After: %#v", arr)
> }
>
> https://play.golang.org/p/hXnBKK3pDWk
>
> O(n) time complexity (or O(1) if n  == 100) and O(k) additional space for 
> the dictionary.
>
> Best,
>
> Dani
>
> Em qua, 29 de ago de 2018 às 22:15, > 
> escreveu:
>
>> I have approximately 9 characters that all need to be replaced with 
>> different characters. I know there are a number of ways to do this but what 
>> is the most efficient?
>>
>>
>>- 1) Do a []byte walk and compare each byte and replace when found?
>>- Seems expensive if you have a 100 bytes in the []byte
>>  - comes out to a max of 900 operations
>>   - 2) Use byte.Replace() for each one?
>>- This seems to be about the same as #1 but seems like it makes a 
>>   copy so might use slightly more memory
>>- 3) Regex for each one?
>>- Seems like using a nuke to kill a flee
>>   - Seems expensive in processing
>>- 4) Something I have not thought of?
>>- Specific algorithm to solve this?
>>
>>
>> The []byte slice it self likely will not be over 100 bytes, however they 
>> may be be 10s of thousands of them.
>>
>> Thanks,
>> Anthony Gruetzmacher
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] Character Replacement/Algorithm for Replacement

[Tamás Gulácsi]

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.

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