Re: [go-nuts] filepath.Clean

[brainman]

I don't remember. I suspect I was only worried about making tests pass. And 
keep existing code as simple as I have found it. (Just as Ian explained)

Alex

On Thursday, 14 July 2016 06:41:53 UTC+10, Anmol Sethi wrote:
>
> I’ve cced him, hopefully he can state exactly why. 
>
> > On Jul 13, 2016, at 4:02 PM, Ian Lance Taylor  > wrote: 
> > 
> > On Wed, Jul 13, 2016 at 10:40 AM, Anmol Sethi  > wrote: 
> >> Why does filepath.Clean replace each slash with a separator at the end 
> of the function? What’s the point of attempting to clean it if the 
> separator used is incorrect? Wouldn’t doing this at the start of the 
> function make more sense? 
> > 
> > It dates back to https://golang.org/cl/4758051 in 2011.  I would guess 
> > that Alex thought it would be simpler to just do it at the end rather 
> > than reworking the rest of the function. 
> > 
> > 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...@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: cockroachdb install with the homebrew option on Mac OS X El Capitan

[Young Lee]

My bad,

Well, turns out that our company is using a thirdparty filtering service 
and apparently is blocking access to the url
https://honnef.co/go/unused?go-get=1 , :(

- Young

On Saturday, April 2, 2016 at 6:55:14 PM UTC-7, Young Lee wrote:
>
> Hi,
>
> I saw the cockroachdb beta announcement and decided to try out cockroachdb 
> with the homebrew option.
>
> I am running version 10.11.2 of Mac OS X El Capitan.
>
> I also have golang version 1.6 installed with homebrew
>
> Below is the error I encountered when attempting to install with brew:
>
> Does anyone else encountered similar or same issue?
>
> Thanx,
>
> - Young
>
> $ brew install 
> https://raw.githubusercontent.com/cockroachdb/cockroach/master/build/cockroach.rb
>
>  
> 100.0%
>
> ==> Cloning https://github.com/cockroachdb/cockroach.git
>
> Updating /Library/Caches/Homebrew/cockroach--git
>
> ==> Checking out tag beta-20160330
>
> ==> xcrun make GOFLAGS=-v -C src/github.com/cockroachdb/cockroach build
>
> Last 15 lines from 
> /Users/younglee/Library/Logs/Homebrew/cockroach/01.xcrun:
>
> installing githooks/post-merge
>
> installing githooks/post-rewrite
>
> failed to get: honnef.co/go/unused
>
>
> > go get -v -d honnef.co/go/unused
>
> Fetching https://honnef.co/go/unused?go-get=1
>
> Parsing meta tags from https://honnef.co/go/unused?go-get=1 (status code 
> 403)
>
> package honnef.co/go/unused: unrecognized import path "honnef.co/go/unused" 
> (parse https://honnef.co/go/unused?go-get=1: no go-import meta tags)
>
> exit status 1
>
>
> > import honnef.co/go/unused
>
> cannot find package "honnef.co/go/unused" in any of:
>
> /usr/local/Cellar/go/1.6/libexec/src/honnef.co/go/unused (from $GOROOT)
>
> /private/tmp/cockroach20160402-9480-5al24w/src/honnef.co/go/unused (from 
> $GOPATH)
>
> make: *** [.bootstrap] Error 1
>
>
> READ THIS: https://git.io/brew-troubleshooting
>
>
>
> younglee at wm720L17837c in ~ 
>
> $ brew doctor
>
> Your system is ready to brew.
>
>

-- 
You received this message because you are subscribed 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 concurrency design question

[nakuldesai88]

I was going through the concurrent directory traversal program (similar to 
the unix du command) provided as an example in the "Go Programming 
Language" book (by Kernighan and Donovan). The example is on lines of the 
following (slightly modified to clarify the question):


*// semaphore to control the number of open file descriptorsvar sem = 
make(chan struct{}, 20)*

func dirents(dirName string) []os.FileInfo {
  




* defer func() {   <-sem   }()   // Acquire a semaphore to read a Dir   
sem <- struct{}{}*

entrySlice, err := ioutil.ReadDir(dirName)

if err != nil {
return nil
}
return entrySlice
}


func walkDir(directoryName string, filesizeChan chan int64, wg 
*sync.WaitGroup) {
 defer wg.Done()

 for _, entry := range dirents(name) {
 if entry.IsDir() {
  // if it is a directory, recurse 
  subDirName := ...
  wg.Add(1)
  go walkDir(...)
  } else {
  // if it is a file, send down the size
  filesizeChan <- entry.size 
 }
}
}

The above example basically recurses through a directory 
(ioutil.ReadDir()), if it is a file, then send its size, if it is a 
directory, recurse again.
A semaphore is used to control the number of open file descriptors (control 
ioutil.ReadDir()). Lets assume we have a deeply nested structure of files 
and directories, there
could potentially be 200 goroutines active in the system with only 20 
proceeding and the remaining blocked. This is because the program in the 
example first spawns a goroutine 
and then potentially blocks on the semaphore. 

Wouldn't is be better to first acquire the semaphore and then spawn the 
goroutine. This way we are limiting the number of the goroutines that would 
remain blocked at any given moment. i.e the walkDir function would look 
like this :
 
func walkDir(directoryName string, filesizeChan chan int64, wg 
*sync.WaitGroup) {
defer wg.Done()

   




* defer func() { <-sem}()// Acquire a semaphore be 
proceedingsem <- struct{}{}*

for _, entry := range dirents(name) {
 if entry.IsDir() {
  // if it is a directory, recurse 
  subDirName := ...
  wg.Add(1)
  go walkDir(...)
  } else {
  // if it is a file, send down the size
  filesizeChan <- entry.size 
 }
}
}


This approach would limit the number of goroutines active in a system. 
Wouldnt this be a better approach ? 
Essentially, the question boils downs to either spawn a goroutine and then 
block or block and then spawn a goroutine.

Thanks,
Nakul

-- 
You received this message because you are subscribed 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: Reverse proxy with HTTP2 support

[Tamás Gulácsi]

caddyserver.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: How to make the first character in a string lowercase?

[Tamás Gulácsi]

But this works only for ASCII input!

-- 
You received this message because you are subscribed 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] Streaming deflate - can't reliably read chunks as they arrive instead of the entire stream

[Nigel Tao]

On Thu, Jul 14, 2016 at 12:35 AM, A Keeton  wrote:
> I'm trying to decompress messages arriving over websockets that are using
> permessage-deflate.

You say that you're using "per message" deflate...


> Each new websockets message is written into buf and then I call Read on

...but then it sounds like you're concatenating all of the messages
together, writing them all to the one buffer, so you're treating it as
"per stream" deflate instead of "per message".


> flater. It works for 1 or more messages (sometimes several right up until I
> fill the 32k window). Eventually the Read fails and flate says there is a
> corrupt byte before some offset. Even after more data has been written to
> buf, successive reads fail. I presume there's some need to reset the flater
> to a previous state, but Reset hasn't gotten me anywhere.

Calling Reset is probably the way to go, but it's hard to give more
specific advice without seeing your code, preferably a self-contained
example and one that's as small and as simple as possible.

-- 
You received this message because you are subscribed 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: any way to save an image to 8-bit indexed png format?

[Nigel Tao]

On Thu, Jul 14, 2016 at 2:07 AM,   wrote:
> [haven't actually checked if the PNG package will work with this - but this
> would be the way to go if supported]

The PNG package should work with this: https://play.golang.org/p/Sxl-nLnecy

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

Re: [go-nuts] What dependency management tool do you use?

[Sean Russell]

Hi Nathan,

On Wednesday, July 13, 2016 at 11:43:09 AM UTC-4, Nathan Fisher wrote:
> Out of curiosity if the upstream deletes their repo does a force push
> invalidating a sha or in some other way causes a dangling reference how do you
> protect against that without checking the dependency in? I'm thinking about

You can commit external repositories or not, whichever is your preference.  gvt 
doesn't force you to do one or the other.  The difference is whether the build 
process includes a step to pull the dependencies.

--- SER

-- 
You received this message because you are subscribed 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] Trying to verify io.Copy and underlying way of handling files.

[Eliezer Croitoru]

I have looked at : https://github.com/rainycape/vfs

and I am trying to understand and predict what to be expected from the VFS
when I will be using io.Copy on a file.

The VFS has a lock on a file but from what I have seen until now in the
source code it locks the file on a "read' operation but it releases the lock
with a defer on a read.

I am trying to predict if I would need to "lock" the whole file manually as
long as I want it to be or not.

I have seen the sources of io.Copy which led me to:
https://golang.org/src/io/io.go?s=12235:12295#L366

And it seems that the read is being used in a loop with couple basic exit
states.

Between these read operations, there is a state which the file would not
stay in under a "read" operation which allows the vfs file to be unlocked.

 

Would any lower level of the language will "assume" that the file will be
"unlocked"(since the read operation ended) at runtime or
it will be considered or optimized to be a single long "read" operation and
by that will allow me to count on the VFS lock?

As I am writing myself I feel like I have the answer already but I need more
eyes to ease my mind.

 

Thanks,

Eliezer

 



Eliezer Croitoru  
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



 

-- 
You received this message because you are subscribed 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: exec.Cmd: if the child forks Wait may hang forever

[noxiouz]

https://github.com/golang/go/blob/master/src/os/exec/exec.go#L484 set 
io.Writer explicitly so it looks like a bug

среда, 13 июля 2016 г., 23:50:56 UTC+3 пользователь noxiouz написал:
>
> Good day!
>
> I faced a corner case of cmd.Exec usage and want to find out if it's 
> designed behavior.
>
>
> go version go1.6.2 darwin/amd64 and linux
>>
>
> Let's assume we use cmd.Exec to start some process, that can fork and 
> dies, but the fork will live forever. For example:
>
> #!/usr/bin/env python
>
> import os
> import time
>
> pid = os.fork()
> if pid == 0:
> while True:
> time.sleep(10)
>
> print "main process has quited"
>
>
> The real script is much more complicated but it's not important.
>
> Also there is a go code:
>
> package main
>
> import (
> "io"
> "log"
> "os/exec"
> )
>
> func main() {
> cmd := exec.Command("./forker.py")
> rd, wr := io.Pipe()
> cmd.Stdout = wr
> go func() {
> b := make([]byte, 100)
> for {
> nn, err := rd.Read(b)
> if nn > 0 {
> log.Printf("%s", b[:nn])
> }
> if err != nil {
> log.Fatal(err)
> return
> }
> }
> }()
> if err := cmd.Start(); err != nil {
> log.Fatal(err)
> }
>
> log.Printf("PID %d", cmd.Process.Pid)
>
> if err := cmd.Wait(); err != nil {
> log.Fatal(err)
> }
> }
>
> The output would be like this:
>
> 2016/07/13 23:40:20 PID 90614
>> 2016/07/13 23:40:20 main process has quited
>>
>  
> but the Go process will hang forever, because of waiting on: 
> https://github.com/golang/go/blob/release-branch.go1.6/src/os/exec/exec.go#L401
> I think, because stdout fd of child process would not be closed .
>
> On the other hand the next code works perfectly and does not hang:
>
> package main
>
> import (
> "log"
> "os/exec"
> )
>
> func main() {
> cmd := exec.Command("./forker.py")
> rd, err := cmd.StdoutPipe()
> if err != nil {
> log.Fatal(err)
> }
> go func() {
> b := make([]byte, 100)
> for {
> nn, err := rd.Read(b)
> if nn > 0 {
> log.Printf("%s", b[:nn])
> }
> if err != nil {
> log.Fatal(err)
> return
> }
> }
> }()
> if err := cmd.Start(); err != nil {
> log.Fatal(err)
> }
>
> log.Printf("PID %d", cmd.Process.Pid)
>
> if err := cmd.Wait(); err != nil {
> log.Fatal(err)
> }
> }
>
>
> So I would like to find out if setting cmd.Stdout explicitly is not 
> expected.
>
>
> 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] exec.Cmd: if the child forks Wait may hang forever

[Steven Hartland]

If your forked process still has stdin / stdout open then I would say 
this is expected.


You could confirm this by adding the following to the python script.
import sys
...
if pid == 0:
   sys.stdin.close()
   sys.stdout.close()

On 13/07/2016 21:50, noxiouz wrote:

Good day!

I faced a corner case of cmd.Exec usage and want to find out if it's 
designed behavior.



go version go1.6.2 darwin/amd64 and linux


Let's assume we use cmd.Exec to start some process, that can fork and 
dies, but the fork will live forever. For example:


|
#!/usr/bin/env python

importos
importtime

pid =os.fork()
ifpid ==0:
whileTrue:
time.sleep(10)

print"main process has quited"

|

The real script is much more complicated but it's not important.

Also there is a go code:

|
packagemain

import(
"io"
"log"
"os/exec"
)

func main(){
cmd :=exec.Command("./forker.py")
rd,wr :=io.Pipe()
cmd.Stdout=wr
go func(){
b :=make([]byte,100)
for{
nn,err :=rd.Read(b)
ifnn >0{
log.Printf("%s",b[:nn])
}
iferr !=nil{
log.Fatal(err)
return
}
}
}()
iferr :=cmd.Start();err !=nil{
log.Fatal(err)
}

log.Printf("PID %d",cmd.Process.Pid)

iferr :=cmd.Wait();err !=nil{
log.Fatal(err)
}
}
|

The output would be like this:

2016/07/13 23:40:20 PID 90614
2016/07/13 23:40:20 main process has quited


but the Go process will hang forever, because of waiting on: 
https://github.com/golang/go/blob/release-branch.go1.6/src/os/exec/exec.go#L401

I think, because stdout fd of child process would not be closed .

On the other hand the next code works perfectly and does not hang:

|
packagemain

import(
"log"
"os/exec"
)

func main(){
cmd :=exec.Command("./forker.py")
rd,err :=cmd.StdoutPipe()
iferr !=nil{
log.Fatal(err)
}
go func(){
b :=make([]byte,100)
for{
nn,err :=rd.Read(b)
ifnn >0{
log.Printf("%s",b[:nn])
}
iferr !=nil{
log.Fatal(err)
return
}
}
}()
iferr :=cmd.Start();err !=nil{
log.Fatal(err)
}

log.Printf("PID %d",cmd.Process.Pid)

iferr :=cmd.Wait();err !=nil{
log.Fatal(err)
}
}

|

So I would like to find out if setting cmd.Stdout explicitly is not 
expected.



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] exec.Cmd: if the child forks Wait may hang forever

[Ian Lance Taylor]

On Wed, Jul 13, 2016 at 1:50 PM, noxiouz  wrote:
>
> I faced a corner case of cmd.Exec usage and want to find out if it's
> designed behavior.

...

> So I would like to find out if setting cmd.Stdout explicitly is not
> expected.

Sounds like https://golang.org/issue/13155 .

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] filepath.Clean

[Anmol Sethi]

I’ve cced him, hopefully he can state exactly why.

> On Jul 13, 2016, at 4:02 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 13, 2016 at 10:40 AM, Anmol Sethi  wrote:
>> Why does filepath.Clean replace each slash with a separator at the end of 
>> the function? What’s the point of attempting to clean it if the separator 
>> used is incorrect? Wouldn’t doing this at the start of the function make 
>> more sense?
> 
> It dates back to https://golang.org/cl/4758051 in 2011.  I would guess
> that Alex thought it would be simpler to just do it at the end rather
> than reworking the rest of the function.
> 
> Ian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Initializing a channel as "Closed" so that it doesn't block if a "Thing" hasn't been done yet

[Harmen B]

I don't understand the problems 100%, but maybe these things can point you
in the right direction:

- try to see if using a sync.WaitGroup{} can help you. WaitGroups are great
to use when you need to keep track of a varying bunch of Go routines.
- you can send channels over channels, to wait for things to happen.
In pseudo-pseudo-code:

type myThing struct {
quit chan chan struct{}
}

func (m *myThing) Quit() {
q := make(chan struct{})
m.quit <- q
<- q
}

elsewhere:

for {
select {
case <-somewhere:
// do something.
case q := <- m.quit:
// tell all Go routines to quit and wait for that. Maybe
using a WaitGroup
close(q)
}
}

On Wed, Jul 13, 2016 at 6:28 PM, Evan Digby  wrote:

> Hi All,
>
> I'm looking for some advice on a pattern I've found myself trapped in. I
> don't think I like it.
>
> For all examples, assume I have to meet the following interface (enforced
> externally):
>
> type DoerCloser interface {
> Do()
> Close()
> }
>
>
> The code below is mostly snippets from:
>
> https://play.golang.org/p/RQp97u4ZeK
>
> First, the part that seems standard (or is this my first incorrect
> assumption?):
>
> I'm using a "closed" (or "closing") channel to tell all methods on a
> struct that the user has asked us to close, and then a "done" channel to
> allow the methods to alert that they're done.
>
> func (t *doerCloser) do() {
> t.doneDoing = make(chan struct{})
> defer close(t.doneDoing)
> for {
> select {
> case <-t.closed:
> return
> case <-time.After(time.Second):
> fmt.Println("Doing a thing!")
> }
> }
> }
>
> func (t *doerCloser) Close() {
> close(t.closed)
> <-t.doneDoing
> }
>
> This works fine if the "New" function that creates the struct kicks off
> the action, and therefore the "doneDoing" channel is always created and in
> a good state.
>
> func NewDoerCloser1() DoerCloser {
> dc := {
> closed: make(chan struct{}),
> }
> go dc.do()
> return dc
> }
>
> User can do the following safely:
>
> dc := NewDoerCloser1()
> defer dc.Close()
>
>
> Where it gets tricky is if "Do" can't be kicked off right away. In my
> current real-world example I need to meet an external interface, and the
> interface dictates that "Do" kicks of the thing--in other examples perhaps
> you simply want the user to be able to explicitly start the doing.
>
> // If "do" is never called, Close will "Block" because it's a nil channel
> func NewDoerCloser2() DoerCloser {
> return {
> closed: make(chan struct{}),
> }
> }
>
> If "do" is never called, then "Close" will block forever on:
>
> <-t.doneDoing.
>
> One solution would be to create "doneDoing" and then close it immediately.
> Seems crazy to me; however, It's fairly simple so perhaps it isn't crazy?
>
> func NewDoerCloser3() DoerCloser {
> doneDoing := make(chan struct{})
> defer close(doneDoing)
>
> return {
> closed:make(chan struct{}),
> doneDoing: doneDoing,
> }
> }
>
> Another solution would be to "kick off" the "Do" functionality, but have
> it wait to start processing until "Do" is explicitly called. This seems
> much more complex than the "create and close immediately" idea.
>
> func NewDoerCloser() DoerCloser {
> dc := {
> closed:   make(chan struct{}),
> doCalled: make(chan struct{}),
> }
>
> go dc.do()
>
> return dc
> }
>
> func (t *doerCloser) do() {
> t.doneDoing = make(chan struct{})
> defer close(t.doneDoing)
>
> select {
> case <-t.closed:
> return
> case <-t.doCalled:
> }
>
> // Let's start doing!
>
> for {
> select {
> case <-t.closed:
> return
> case <-time.After(time.Millisecond):
> fmt.Println("Doing a thing!")
> }
> }
> }
>
>
> https://play.golang.org/p/qA3_oFF_EP
>
> Any other options? Am I totally crazy? Is this overcomplicated and there
> is a much simpler solution I'm spacing on?
>
> Thank's everyone!
>
> Evan
>
> --
> You received this message because you are subscribed 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] filepath.Clean

[Ian Lance Taylor]

On Wed, Jul 13, 2016 at 10:40 AM, Anmol Sethi  wrote:
> Why does filepath.Clean replace each slash with a separator at the end of the 
> function? What’s the point of attempting to clean it if the separator used is 
> incorrect? Wouldn’t doing this at the start of the function make more sense?

It dates back to https://golang.org/cl/4758051 in 2011.  I would guess
that Alex thought it would be simpler to just do it at the end rather
than reworking the rest of the function.

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] filepath.Join

[Steven Hartland]

Are the unexported methods OS specific?

On 13/07/2016 20:56, Anmol Sethi wrote:

Why does filepath.Join only call to the unexported join? Why not just export 
the unexported join?



--
You received this message because you are subscribed 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] Rel in path package

[Anmol Sethi]

Thanks Ian!

> On Jul 13, 2016, at 10:23 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 13, 2016 at 2:43 AM, Anmol Sethi  wrote:
>> Right here: 
>> https://github.com/nsf/gocode/blob/f535dc686130fcc7b942c504ce5903222a205ca3/autocompletecontext.go#L254
>> 
>> I have to annoyingly use filepath.ToSlash after just in case the user was on 
>> windows.
> 
> I don't know what that code is doing, but the fact that you are
> passing fpath to readdir makes me think that fpath is a path in the
> file system, and that you should be using the path/filepath package
> anyhow.  Why are you using the path package here?  (To be clear, the
> path package is for things like URLs, and the path/filepath package is
> for file system paths.)
> 
> Ian
> 
> 
> 
>>> On Jul 12, 2016, at 10:58 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Jul 12, 2016 at 5:17 PM, Anmol Sethi  wrote:
 Why is there no function in the path package to get relative paths, like 
 filepath.Rel?
>>> 
>>> When would you want to use it?
>>> 
>>> 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] Rel in path package

[Anmol Sethi]

fixed here: https://github.com/nsf/gocode/pull/361/files

Not sure what I was thinking when I wrote that code. My bad.
> On Jul 13, 2016, at 10:23 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 13, 2016 at 2:43 AM, Anmol Sethi  wrote:
>> Right here: 
>> https://github.com/nsf/gocode/blob/f535dc686130fcc7b942c504ce5903222a205ca3/autocompletecontext.go#L254
>> 
>> I have to annoyingly use filepath.ToSlash after just in case the user was on 
>> windows.
> 
> I don't know what that code is doing, but the fact that you are
> passing fpath to readdir makes me think that fpath is a path in the
> file system, and that you should be using the path/filepath package
> anyhow.  Why are you using the path package here?  (To be clear, the
> path package is for things like URLs, and the path/filepath package is
> for file system paths.)
> 
> Ian
> 
> 
> 
>>> On Jul 12, 2016, at 10:58 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Jul 12, 2016 at 5:17 PM, Anmol Sethi  wrote:
 Why is there no function in the path package to get relative paths, like 
 filepath.Rel?
>>> 
>>> When would you want to use it?
>>> 
>>> Ian
>> 

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

[go-nuts] filepath.Clean

[Anmol Sethi]

Why does filepath.Clean replace each slash with a separator at the end of the 
function? What’s the point of attempting to clean it if the separator used is 
incorrect? Wouldn’t doing this at the start of the function make more sense?

-- 
You received this message because you are subscribed 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] bodyless functions in standard libary

[Aram Hăvărneanu]

https://golang.org/doc/asm

-- 
Aram Hăvărneanu

-- 
You received this message because you are subscribed 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: Reverse proxy with HTTP2 support

[Tim Hawkins]

https://github.com/containous/traefik
On 14 Jul 2016 2:13 a.m., "Kevin Klues"  wrote:

> Im curious about this as well. Are there any plans to build native support
> for a reverse proxy that can directly forward HTTP/2 traffic to a backend
> server? If not, does anyone know of a usable external project that provides
> this functionality?
>
> On Wednesday, March 30, 2016 at 2:48:11 AM UTC-7, Piyush Dewnani wrote:
>>
>> The default reverse proxy at
>> https://golang.org/pkg/net/http/httputil/#ReverseProxy has some
>> hard-coded vars which uses http 1.1
>>
>> For example:
>> https://golang.org/src/net/http/httputil/reverseproxy.go#L178
>>
>> Not sure about the changes targeted to support 'HTTP 2' out of the box
>> for 'HTTP 2' enabled backend.
>>
>> --
> You received this message because you are subscribed 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: Reverse proxy with HTTP2 support

[Kevin Klues]

Im curious about this as well. Are there any plans to build native support 
for a reverse proxy that can directly forward HTTP/2 traffic to a backend 
server? If not, does anyone know of a usable external project that provides 
this functionality?

On Wednesday, March 30, 2016 at 2:48:11 AM UTC-7, Piyush Dewnani wrote:
>
> The default reverse proxy at 
> https://golang.org/pkg/net/http/httputil/#ReverseProxy has some 
> hard-coded vars which uses http 1.1 
>
> For example: https://golang.org/src/net/http/httputil/reverseproxy.go#L178
>
> Not sure about the changes targeted to support 'HTTP 2' out of the box for 
> 'HTTP 2' enabled backend.
>
>

-- 
You received this message because you are subscribed 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: How to make the first character in a string lowercase?

[narenarya . 007]

On Saturday, November 24, 2012 at 4:21:23 PM UTC+5:30, Nikolai wrote:
>
> Hi!
>
> What is the easiest way to make a string "LikeThis" --> "likeThis"?
>

Here is my answer 

bytestr := []byte(str)
for index, character := range bytestr {
char := string(character)
if char == strings.ToUpper(char) {
// Is lowercase
bytestr[index] = []byte(strings.ToLower(char))[0]
} else {
bytestr[index] = []byte(strings.ToUpper(char))[0]
}
}

Small hack of converting byte to string. Applying method re-converting to 
byte array. But we know it consists on ly one element. So index 0 will 
return you the modified byte.

Hope it is useful. Ugly but does the job for me.

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

[go-nuts] Re: [ANN] Vermeer - physically based rendering (raytracing) with Go

[Jamie Clarkson]

Ah yes, thanks for that - it should be relatively easy to add back in the 
Go code to support all architectures (it was all originally Go before 
rewriting in ASM for the SIMD) so I'll add a note to do that soonish.  The 
SSE4 requirement may be able to be relaxed too as the traversal code 
doesn't use anything > SSE2 so I'll look into it at some point.

Jamie

On Wednesday, July 13, 2016 at 12:19:13 AM UTC+1, anthony Place wrote:
>
> am interesting in ray-tracing, but unfortunately you seem to have done a 
> bit a optimisation for SSE4, and got rid of other architectures support, so 
> my core 2 and arm based machines cant use it.
>
> I hope someone fancies trying it out - if so let me know how you get on!
>>
>>

-- 
You received this message because you are subscribed 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] bodyless functions in standard libary

[xiiophen]

 
Thanks 

- so I assume the exported function Frexp is a golang fallback if the 
relevant architecture assembly file isn't found (?)

Is there any official (or unofficial) documentation on linking assembly 
from packages?

-- 
You received this message because you are subscribed 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] bodyless functions in standard libary

[xiiophen]

(newb question)

Bodyless functions - such as 
https://golang.org/src/math/frexp.go?s=469:514#L6 found in the standard 
library are currently mystifying me..

There's an unexported function of the same name and signature on the same 
file but no call to it.

Is this explained somewhere (I read the language spec and sure didn't seen 
this covered?) maybe I need to read it two times.? 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.

[go-nuts] Re: any way to save an image to 8-bit indexed png format?

[xiiophen]

On Wednesday, 13 July 2016 03:32:55 UTC+1, sleepy wrote:
>
> I need to shrink images to as small as possible with an acceptable quality.
> found https://tinypng.com/ could convert the image to 8-bit indexed png, 
> which is best fit my requirement.
>
> however, I need to do this by my go program, any hints for this?
>
> thanks in advance.
>

Have you tried converting a starting image - lets say in color.NRGBA 
palette to a new 8 bit palette image (eg there are two at 
https://golang.org/pkg/image/color/palette/ )

ie using  the function : func (p *Palette* 
) Convert(c *Color* 
) *Color* 
 to convert the (32bit) image 
pixels to an 8 bit palette image.

and then passing this paletted image to the PNG.encode function like you 
would with any other image

??
[haven't actually checked if the PNG package will work with this - but this 
would be the way to go if supported]

-- 
You received this message because you are subscribed 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: Redis / Gin Framework Performance Issue

[desaiabhijit]

Unix sockets taken performance to 87 k req/sec

redisClient = redis.NewClient({
  Dialer: func() (net.Conn, error) {
return net.DialTimeout("unix", "/tmp/redis.sock", 
1*time.Second)
  },
  Password: "",
  DB:   0,
  PoolSize: 10,
  })

Thanks,

Abhi

On Monday, July 11, 2016 at 8:51:37 PM UTC+5:30, desaia...@gmail.com wrote:
>
> Thanks very much
>
> **Point 1 - Are you discarding Gin's log output? Writing stderr/stdout *to 
> a terminal *can be a major bottleneck.
>
> //Gin Code - Simply gin.Default() replaced with for your 1st point - no 
> logs
> r := gin.New()
>
> and simply getting 82k req / sec :-)
>
> Now will check other 3 points
>
> http://server:8001/testkey
>
>   10 threads and 500 connections
>
>   Thread Stats   Avg  Stdev Max   +/- Stdev
>
> Latency 6.38ms6.40ms 250.52ms   96.28%
>
> Req/Sec 8.25k 1.30k   19.75k89.09%
>
>   828565 requests in 10.08s, 120.11MB read
>
> Requests/sec:  82168.43
>
> Transfer/sec: 11.91MB
>
> Thanks,
>
> Abhi
>
>
> On Monday, July 11, 2016 at 7:38:18 PM UTC+5:30, Matt Silverlock wrote:
>>
>> Questions:
>>
>>
>>- Are you discarding Gin's log output? Writing stderr/stdout *to a 
>>terminal *can be a major bottleneck.
>>- I can't see where you've allowed more ephemeral ports? By default 
>>it's around ~28k ephemeral ports on most Linux distros; you may wish to 
>>increase this.
>>- On a i7 4770k w/ 16GB RAM (SSD, but there's no disk IO here, so 
>>makes no difference) - I can realize about 45k req/s with stdout+stderr 
>>re-directed to /dev/null, talking to Redis over a Unix socket instead of 
>>TCP.
>>
>> You should profile your application to see where it's spending the most 
>> time waiting, otherwise we are both ultimately guessing.
>>
>>
>> On Monday, July 11, 2016 at 12:18:19 AM UTC-7, desaia...@gmail.com wrote:
>>>
>>> Hi Matt
>>>
>>> Thanks for the reply
>>>
>>> Test is done on different server on the same network
>>> Application using "gopkg.in/redis.v3" as plugin so TCP
>>> Pool size = 10
>>>
>>> Below is the simple program storing "Hello World" small data compare to 
>>> what I use to store in my actual application where Redis not even 
>>> supporting 4k reads/sec even after using snapply and probuffing compression
>>>
>>> Redis-benchmark utility shows 80 k reads etc
>>>
>>> //Output - "Hello World" http://server:8001/testkey
>>>
>>> package main
>>>
>>> import (
>>>   "gopkg.in/redis.v3"
>>>   "github.com/gin-gonic/gin"
>>>)
>>>
>>> var redisClient *redis.Client
>>> func main() {
>>>   redisClient = redis.NewClient({
>>>   Addr: "localhost:6379",
>>>   Password: "",
>>>   DB:   0,
>>>   PoolSize: 10,
>>>   })
>>>
>>>   //Gin Code
>>>   gin.SetMode(gin.ReleaseMode)
>>>   r := gin.Default()
>>>   //r.Use(Proton.Gzip(Proton.BestSpeed))
>>>
>>>   r.GET("/:key", func(c *gin.Context) {
>>> key := c.Param("key")
>>> value, _ := redisClient.Get(key).Result()
>>> c.JSON(200, gin.H{"response": value})
>>>   })
>>>   r.Run(":8001")
>>> }
>>>
>>> $ wrk -t1 -c500 http://server:8001/testkey
>>> Running 10s test @ http://server:8001/testkey
>>>   1 threads and 500 connections
>>>   Thread Stats   Avg  Stdev Max   +/- Stdev
>>> Latency15.24ms   16.99ms 296.58ms   90.73%
>>> Req/Sec28.84k 3.20k   35.90k87.88%
>>>   288461 requests in 10.08s, 41.81MB read
>>> Requests/sec:  28606.13
>>> Transfer/sec:  4.15MB
>>>
>>> $ wrk -t4 -c500 http://server:8001/testkey
>>> Running 10s test @ http://server:8001/testkey
>>>   4 threads and 500 connections
>>>   Thread Stats   Avg  Stdev Max   +/- Stdev
>>> Latency19.41ms   17.19ms 306.65ms   68.10%
>>> Req/Sec 7.08k 1.00k8.91k73.75%
>>>   281946 requests in 10.03s, 40.87MB read
>>> Requests/sec:  28098.00
>>> Transfer/sec:  4.07MB
>>>
>>> $ wrk -t10 -c500 http://server:8001/testkey
>>> Running 10s test @ http://server:8001/testkey
>>>   10 threads and 500 connections
>>>   Thread Stats   Avg  Stdev Max   +/- Stdev
>>> Latency19.51ms   18.30ms 316.32ms   66.97%
>>> Req/Sec 2.86k   349.38 3.88k78.39%
>>>   286221 requests in 10.07s, 41.49MB read
>>> Requests/sec:  28413.52
>>> Transfer/sec:  4.12MB
>>>
>>> Thanks for your help
>>>
>>> Rgds,
>>>
>>> Abhi 
>>>
>>>
>>> On Monday, July 11, 2016 at 4:08:36 AM UTC+5:30, Matt Silverlock wrote:


- Are your wrk threads starving your Go program? (why 10 threads? 
Why not 4 for wrk, 4 for Go?)
- How are you connecting to Redis? (TCP? Unix socket?)
- What size pool have you set for Redis?
- Show us your code.

 This is likely a classic example of where framework 'benchmarks' are 
 completely divorced from reality. 


 On Sunday, July 10, 2016 at 4:55:56 AM UTC-7, desaia...@gmail.com 
 wrote:
>
> I am 

[go-nuts] Re: Generation of Strings - generation

[catalasexx]

what about https://play.golang.org/p/TbZ-fbhUCb ?

the code don't create goroutine. thus you don't have to care about troubles 
with managing goroutine.

2016년 7월 13일 수요일 오전 6시 36분 15초 UTC+9, The MrU 님의 말:
>
> Hi,
>
> I have this code https://play.golang.org/p/9o5TReZ7jT3 
> 
>
> My idea was to generate all possible combinations pretty much this:
>
> aaa
> bbb
> ccc
> abb
> acc
> baa
> bbb
> bcc
> caa
> cbb
> ccc
> aba
> abb
> abc
>
> you get the picture I think.
>
> I got this solution but the objective is to simplify the solution without 
> using channels if possible :
>
> package main
>
> import "fmt"
>
> func GenerateCombinations(alphabet string, length int) <-chan string {
>   c := make(chan string)
>
>   go func(c chan string) {
>   defer close(c)
>
>   AddLetter(c, "", alphabet, length)
>   }(c)
>
>   return c
> }
>
> func AddLetter(c chan string, combo string, alphabet string, length int) {
>   if length <= 0 {
>   return
>   }
>
>   var newCombo string
>   for _, ch := range alphabet {
>   newCombo = combo + string(ch)
>   c <- newCombo
>   AddLetter(c, newCombo, alphabet, length-1)
>   }
> }
>
> func main() {
>
>   list := "abc"
>
>   for combination := range GenerateCombinations(list, 3) {
>   if len(combination) == 3 {
>   fmt.Println(combination)
>   }
>
>   }
>
>   fmt.Println("Done!")
> }
>
>

-- 
You received this message because you are subscribed 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] Rel in path package

[Ian Lance Taylor]

On Wed, Jul 13, 2016 at 2:43 AM, Anmol Sethi  wrote:
> Right here: 
> https://github.com/nsf/gocode/blob/f535dc686130fcc7b942c504ce5903222a205ca3/autocompletecontext.go#L254
>
> I have to annoyingly use filepath.ToSlash after just in case the user was on 
> windows.

I don't know what that code is doing, but the fact that you are
passing fpath to readdir makes me think that fpath is a path in the
file system, and that you should be using the path/filepath package
anyhow.  Why are you using the path package here?  (To be clear, the
path package is for things like URLs, and the path/filepath package is
for file system paths.)

Ian



>> On Jul 12, 2016, at 10:58 PM, Ian Lance Taylor  wrote:
>>
>> On Tue, Jul 12, 2016 at 5:17 PM, Anmol Sethi  wrote:
>>> Why is there no function in the path package to get relative paths, like 
>>> filepath.Rel?
>>
>> When would you want to use it?
>>
>> 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] How can I get running func name?

[Jan Mercl]

On Wed, Jul 13, 2016 at 3:56 PM Harry  wrote:

> I want to keep something records as log and where it is to specify.

Many loggers are able to include the file_name:line_number info, which is
cheaper to obtain at runtime.

-- 

-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] How can I get running func name?

[Harry]

I want to keep something records as log and where it is to specify.

2016年7月13日水曜日 21時28分52秒 UTC+9 Konstantin Khomoutov:
>
> On Wed, 13 Jul 2016 04:48:18 -0700 (PDT) 
> Harry  wrote: 
>
> > func SomethingFunc() { 
> >   fmt.Printf("func is %s\n", funcName) 
> >   /* code */ 
> > } 
> > 
> > I want to show func name when running each func. 
> > If I could get func name automatically, same code can be used. 
>
> What problem are you trying to solve with this? 
>

-- 
You received this message because you are subscribed 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 can I get running func name?

[Jan Mercl]

On Wed, Jul 13, 2016 at 1:48 PM Harry  wrote:

> If I could get func name automatically, same code can be used.

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

-- 

-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] How can I get running func name?

[Harry]

Hello, everyone.

As title, I'm trying the below.

func SomethingFunc() {
  fmt.Printf("func is %s\n", funcName)
  /* code */
}

I want to show func name when running each func.
If I could get func name automatically, same code can be used.


Thank you.

Harry.

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

Re: [go-nuts] Plurality of package naming

[Nathan Fisher]

struct and class semantics aren't equivalent but they are similar. Which is
why I think the rule "avoid -er" is relevant. If you're struggling to name
something then you probably don't know what it is and what it needs to do.

I'm not advocating going to the Java extreme of fifty syllable names.
Rather I'm siding with the principle that poor names are a smell of they
don't fit or are buckets for random bits of code (eg util).
On Wed, 13 Jul 2016 at 00:26, Thomas Bushnell, BSG 
wrote:

> That's advice for a very different style of language than Go.
>
> Go does not have "objects" in the sense of that post. A Go interface, for
> example, does not "have lots of instance variables, lots of arguments, and
> pass lots of data around probably."
>
> A class is not a struct is not a Go interface.
>
> Thomas
>
> On Tue, Jul 12, 2016 at 4:23 PM Nathan Fisher 
> wrote:
>
>> There's a good oop blog article on the caveats of naming classes (struct)
>> ending in -er.
>>
>> http://objology.blogspot.co.uk/2011/09/one-of-best-bits-of-programming-advice.html?m=1
>>
>> I know the reader/writer interface kind of flies in the face of this but
>> I think that's partly associated with it being an interface and its focus
>> on one method.
>>
>> Personally if it's RESTy I'd opt for BlahResource where Blah is the
>> resource that it manages which will probably map to an underlying
>> serialisable struct with additional REST elements (eg next, self, etc).
>>
>> On Tue, 12 Jul 2016 at 17:41, Sam Whited  wrote:
>>
>>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland  wrote:
>>> > When does it make sense for a package to be named in plural? For
>>> example,
>>> > I'm currently working on a MVC framework and for me it makes sense to
>>> have a
>>> > "controller" package as opposed to "controllers", but I saw that Beego
>>> > prefers plural for the same case.
>>>
>>> Generally speaking, try to consider how your users will write things
>>> that use your package and not what's actually in it. For instance,
>>> which makes the better API:
>>>
>>> controller.New()
>>>
>>> or:
>>>
>>> controllers.NewController()
>>>
>>> The second is redundant, so I'd argue that the first one will look
>>> better in your users code. However, given the example:
>>>
>>> byte.Split(b []byte)
>>>
>>> vs.
>>>
>>> bytes.Split(b []byte)
>>>
>>> the second may be more expected because you're operating on a collection.
>>>
>>> Of course, both of these are just my opinion, but it's just to
>>> illustrate how I generally think about picking a name. Instead of
>>> "what will my code in the package look like" think "what will my users
>>> write using this package?"
>>>
>>> —Sam
>>>
>>> --
>>> You received this message because you are subscribed 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.