[go-nuts] what is the origin of Go's reference time system?

[Ayan George]

I'm really impressed by the simplicity of Go's time formatting and parsing 
mechanisms -- particularly when compared with strftim().

Does anyone know the origin or history of it?  Is there a precedent for 
using reference layouts that include string like 2006, January, etc.?

Do other languages provide something similar or is this completely unique 
to Go?

Can someone point me to or describe the history of Go's time formatting 
method?

-ayan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%40googlegroups.com.

[go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

[Ayan George]

The Go FAQ begins the answer to the question, "Is Go an object-oriented
language," with, "yes and no."

  https://go.dev/doc/faq#Is_Go_an_object-oriented_language

The section goes on to say that Go has methods but there is no type
hierarchy.  I guess those are the yes and no.

But I feel like programmers bringing their ideas from other less
ambiguously object oriented languages like Java and C++ often have
difficulty writing idiomatic Go.

If the answer to that question is "yes and no," it'd be less ambiguous to
simply say, "no."  And that would be a definitive way of indicating that it
woul be inappropriate to apply many patterns from object oriented languages
to Go -- and to encourage people to accept Go for what it is.

Since receivers are parameters and one could use methods without using the
method calling syntax at all, I'd suggest we'd classify it as a structured
programming language with methods.

In either case, is there a way to make the FAQ more clear on this point?

-ayan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPSh2XBozm9bOe-O3SphET3A3wTif%3D0RiV%3D1Bw6GJkgT3wedLA%40mail.gmail.com.

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

[Ayan George]

Great points.

For me this is as much if not more of a communications issue than a 
technical one.  It seems like the definition of what an OO language is 
broad enough that we could go on forever about if Go is one.

The language developers can also choose to declare what it is meant to be 
definitively.

I feel like we should either say it is or it isn't OO and not equivocate in 
the FAQ.

I land on the side of simply saying it is not an OO language because of the 
conceptual baggage the notion carries.  I've personally seen these concepts 
misapplied to Go because if you squint... Go resembles other languages 
while being fundamentally different.

But in general, that lack of clarity seems un-Go like. I've always found 
the unwillingness to commit to an answer in the FAQ jarring.

On Tuesday, November 22, 2022 at 11:11:44 AM UTC-5 Thomas Bushnell, BSG 
wrote:

> Asking "the definition of object oriented programming" seems a bad idea to 
> me. Alan Kay invented the term, and he was pretty clear that C++ was not 
> anything like what he had in mind, and yet, a lot of people think C++ is an 
> object oriented language. I don't, as it happens.
>
> Inheritance used to be thought of as quite fundamental, but not so much 
> any more. I think that's probably right.
>
> But here are some other things: object oriented languages are supposed to 
> have object ubiquity. I think Stroustrup probably did not understand the 
> point, and the designers of Java couldn't figure out how to make it 
> efficient. So much for them. C++ gets so much wrong it hardly matters. But 
> Java doesn't; it more or less regrets that it has non-object types. Go is 
> very different however: Go does not regard interfaces as something that 
> should be ubiquitous or feel bad when they aren't used. In fact, they are 
> discouraged except when actually required.
>
> Late binding is another key feature, one which again C++ mostly didn't 
> understand the point of, and Java couldn't figure out how to implement 
> efficiently, so everyone does "final" instead. Go does have late binding 
> for interface method calls, but only on-demand.
>
> Object oriented languages are generally either class-based or 
> prototype-based. Go is neither, having nothing like classes and nothing 
> like prototypes. For me, this is the most salient thing to keep in mind.
>
> On Tue, Nov 22, 2022 at 10:56 AM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Tue, Nov 22, 2022 at 4:43 PM Robert Engels  
>> wrote:
>>
>> > Go is not listed as an OO language on Wikipedia.
>>
>> Check https://en.wikipedia.org/wiki/Go_(programming_language):
>> "ParadigmMulti-paradigm: concurrent imperative, object-oriented[1][2]"
>>
>> > Personally I think it is OO-like. OO typically has inheritance.
>>
>> Typically they may, but that's not the same as what a requirement
>> would be, right?
>>
>> > There are also no “class variables” - only package level - which makes 
>> some encapsulation patterns harder (every class has to become a package).
>>
>> No class has to become a package because Go has no classes. You may
>> think of what a "class" in Go means, but you have not defined that
>> idea and the language specification is somehow silent about Go
>> classes.
>>
>> -- 
>> 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.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-U%3DG8gqAZEHrnLUxbg5vsAcRkNV35c86c79xcrhSzLSWw%40mail.gmail.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/18fb45c6-6511-4b1a-ad4b-c60886838ccan%40googlegroups.com.

Re: [go-nuts] Re: clarifying Go FAQ: Is Go an object-oriented language?

[Ayan George]

Rob Pike  wrote:

> Let me ask, because I'm genuinely curious: Why does it matter? The labels
> we apply to things do not affect their function. Perhaps it affects how we
> think about them. Is that it?
>

Yes -- that's it exactly!

I think the amount of hair-splitting over what is an object oriented language
is reason to say it *isn't* an Object Oriented language at all.

This variety of definitions means Go will probably not meet anyone's
expectations.  It's useless to talk about it in terms of something that we
can't clearly define.

Practically, I think the phrase "Object Oriented" is almost synonymous with
Java and maybe C++ and C#.

If you kind of load that context in your mind as you read, it becomes:

Is Go an Object Oriented Language Like Java (or C++ or C#...)

Answering "yes" is almost permission to apply patterns from those languages to
Go as well.  And that's rarely a good fit.  We've all seen it: A Go code base
written with Java idioms or with C++ idioms, etc.

Saying "yes or no" is a non-answer. :)

Saying "yes" opens the possibility for people falsely attributing things to Go.

Saying "no" encourages people to abandon their pre-conceived notions and take
Go for what it is.

I recognize this is a kind of soft issue that is prone to bikeshedding.  I
considered it settled when Ian answered.

-ayan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/637ee17a.rAmwWESC82r2zuxK%25ayan%40ayan.net.

Re: [go-nuts] Generic service via interfaces...

[Ayan George]

On 05/28/2017 02:40 PM, Darko Luketic wrote:
> I'm stuck and I hoped it wouldn't come to that.
> 

As Justin said, interfaces on their own don't do anything and their zero
value is nil.

Beyond that I'd consider thinking more carefully about your
interface names. Whenever I see the word "interface" inside of an
interface name it makes me wary.

Notice that the standard library doesn't have much of that -- the only
one I can think of is sort.Interface. Instead you see Reader, Writer,
CookieJar, Valuer, Pinger, Signer, Decrypter, etc...

It seems like the best interface names are nouns that describe behavior
that other types can comply with. You should be able to define a type
and ask your self, "is this type a Writer," or, "is this type a Decrypter?"

Notice how, "is this type a UserStorageInterface," doesn't quite roll
off the tongue as easily. :)

It seems like using a simple and descriptive noun reflects a clearer
mental model for what you are trying to abstract. When I see
"interface" used in an interface name it tells me that you're not trying
to abstract behavior; you're using interfaces purely as a way to wedge
functions into some code.

-ayan

-- 
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] Help with Dataframes

[Ayan George]

On 05/29/2017 07:23 AM, Vikram Rawat wrote:> Can anybody please tell me
how to write GOTA Golang dataframes on a csv...
>
> It's been 2 days I am trying to find a way to write dataframes onto a
> csv. can anybody please help me understand what does this IO.writer
> means and how to use it...
>
> I have given up understanding it...
>
> Please any help will be appriciated.
>

io.Writer is an interface that matches any concrete type that implements
the Write() method:

   https://golang.org/pkg/io/#Writer

os.Create returns a writer that you can use to write to a file like:

  w, err := os.Create("myfile.csv")

and you can write your CSV to it using the WriteCSV() method described
below:

  https://godoc.org/github.com/kniren/gota/dataframe

So based on the documentation, something like the code below should work:

  df := dataframe.LoadRecords(
  [][]string{
  []string{"A", "B", "C", "D"},
  []string{"a", "4", "5.1", "true"},
  []string{"b", "4", "6.0", "true"},
  []string{"c", "3", "6.0", "false"},
  []string{"a", "2", "7.1", "false"},
  },
  )

  w, err := os.Create("myfile.csv")

  if err == nil {
/* handle os.Create() error here. */
  }

  df.WriteCSV(w)

  ...


-- 
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: Generic service via interfaces...

[Ayan George]

On 05/29/2017 04:44 PM, Darko Luketic wrote:
> 
> Ayan, no that's alright it was storage.UserModelInterface and I know
>  what you're all saying but I saw no other way to make them type 
> agnostic and I'm a fan of explicitly calling things what they are 
> especially when I'm experimenting. And it's not really the point.
> 

Totally -- I realize that naming isn't the point of the post.  I figured
I'd point it out.  I won't belabor it (any further at least) but I
recommend reconsidering your approach to this.  If you really explicitly
call things what they are, do you also add "Struct" to your type names?

IMHO, type naming is a subtle but important part of building
abstractions and reflects and affects how you think about the structure
of the code. That's all I've got -- I'll shut up about it from here on. :)

-ayan

-- 
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] Why *cookie and cookie variables returns the cookie in different format upon printing it to terminal?

[Ayan George]

Hi Aman --

When you print *http.Cookie, Go does it's best to print each field knowing
that it is a pointer to a struct.  This is the format you end up with.

But http.Cookie has a String() method associated with it that provides the
output that you get when you simply print 'cookie' (without the asterisk).
You can find the source for this by following the link below.

   https://golang.org/src/net/http/cookie.go?s=432:945#L138

This is AFAIK and I could be wrong.

On Wed, Jun 14, 2017 at 11:24 AM, Aman Kapoor  wrote:

> Hi,
>
> I was setting up cookies today. Go is my first web development language.
> And, in my code (https://github.com/amankapoor/basic-
> authentication-using-cookies), I outputted the cookie to command line
> because I wanted to see how it looked there.
>
> I found that *cookie and cookie are returning answers in different
> formats. Why so?
>
>
> 
>
> --
> 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] Why *cookie and cookie variables returns the cookie in different format upon printing it to terminal?

[Ayan George]

Well -- I was wrong.

I got it backwards.  There is a String() function is a receiver for
*http.Cookie so it gets called when you need a string representation of a
*http.Cookie (pointer to http.Cookie).

On Wed, Jun 14, 2017 at 1:18 PM, Aman Kapoor  wrote:

> Hi Ayan,
>
> Thank you for pointing me to the right code. I saw there how string method
> is creating the response. I think this is what I needed to see for my
> question. Thank you.
>
> On Wednesday, 14 June 2017 22:28:55 UTC+5:30, Ayan George wrote:
>>
>> Hi Aman --
>>
>> When you print *http.Cookie, Go does it's best to print each field
>> knowing that it is a pointer to a struct.  This is the format you end up
>> with.
>>
>> But http.Cookie has a String() method associated with it that provides
>> the output that you get when you simply print 'cookie' (without the
>> asterisk).  You can find the source for this by following the link below.
>>
>>https://golang.org/src/net/http/cookie.go?s=432:945#L138
>>
>> This is AFAIK and I could be wrong.
>>
>> On Wed, Jun 14, 2017 at 11:24 AM, Aman Kapoor  wrote:
>>
>>> Hi,
>>>
>>> I was setting up cookies today. Go is my first web development language.
>>> And, in my code (https://github.com/amankapoor
>>> /basic-authentication-using-cookies), I outputted the cookie to command
>>> line because I wanted to see how it looked there.
>>>
>>> I found that *cookie and cookie are returning answers in different
>>> formats. Why so?
>>>
>>>
>>> <https://lh3.googleusercontent.com/-xehgFZhq3m8/WUFS_diHQSI/XXo/y1kbRHMl5qAx1DcC6ClEF_5pIDsiRrc_wCLcBGAs/s1600/Capture1.JPG>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Implicit cast of string vs. []byte

[Ayan George]

On 06/24/2017 08:16 PM, Ivan Bertona wrote:
> Hello,
>
> When I try to compile this piece of code:
>

I think it violates the second assignability rule since both 'string'
and MyString are named types.  string happens to be a a pre-declared
named type:

  https://golang.org/ref/spec#Assignability

Whereas []byte is unnamed therefore at least one of the types in the
expression is unnamed.

Here are a couple of relevant blog posts about it:

  https://medium.com/learning-the-go-programming-language
  http://www.laktek.com/2012/01/27/learning-go-types/

Someone please correct me if I'm wrong.

-ayan

-- 
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] Understanding least significant byte operation

[Ayan George]

On 07/23/2017 08:50 AM, Pablo Rozas Larraondo wrote:
> I have seen Go code using this function to find out the least 
> significant byte of unsigned integers:
> 
> func LSB(ci uint64) uint64 { return uint64(ci) & -uint64(ci) }
> 
> This function works fine but I wonder why, if call the same AND 
> operation, it results in an error: "constant -X overflows uint64"
> 
> Here is a playground example to illustrate this: 
> https://play.golang.org/p/_0EYtlLnmG
> 
> Does anyone know what changes when -uint64() is called in a return 
> statement? How a negative uint should be interpreted?
> 


(-uint64(24)) is a constant that can't be represented by a uint64.

I think the relevant bit from the spec is:

"The values of typed constants must always be accurately representable
as values of the constant type. The following constant expressions are
illegal..."

BUT, the rules for expressions that cause overflow are well defined and
operations on the variable 'ci' abide by them.

So I think it is a matter of compile-time correctness vs runtime behavior.

The following also works:

  https://play.golang.org/p/GYREFdz8-M

That is AFAIK. Someone please correct me if I'm wrong.

-ayan

-- 
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] Assigning files (names) to string array.

[Ayan George]

On 08/31/2017 08:41 PM, djl...@gmail.com wrote:
> I am pretty new it GoLang but I am trying to read file directorys and
> assign the directory name to array list.
> 
> Exampe I have been working with this
> 
> funccaptureDir() {
>files, err:=ioutil.ReadDir("./")
>iferr !=nil{
>log.Fatal(err)
>}
> 
> for_, f:=rangefiles {
>dirlist[f] = f.Name
>}
> }
> 

Name is a method not a variable so it should be f.Name(). There might be
other issues with that snippet though.

-ayan

-- 
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] go env GOPATH not reflecting $GOPATH

[Ayan George]

On 08/31/2017 09:38 PM, burpswangy wrote:
> Debian 9.1 Stretch... using Go 1.9, go env shows GOPATH=/home/dev/go
> while echo $GOPATH=/home/dev/devSync/workspace.
> 
> No matter what I do, I can't get Go 1.9 to find my workspace!  What is
> goin' on!?
> 

have you tried:

export GOPATH=/home/dev/devSync/workspace

-- 
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] go 1.9 go test build fail on // Output:

[Ayan George]

On 09/28/2017 08:12 AM, gocss wrote:
> go test
> # testmain
> /tmp/go-build584983468/csspc/alog/_test/_testmain.go:30:22: cannot use
> alog.ExampleNew (type func(*testing.T)) as type func() in field value
> FAIL    csspc/alog [build failed]
> 
> code follows:
> package alog
> 
> import (
>     "fmt"
>     "testing"
> )
> 
> func ExampleNew(t *testing.T) {
>     alog, err := New("alog:")
>     if err != nil {
>     t.Fatal(err)
>     }
>     fmt.Println(LogFlagsDefault)
>     alog.Debug.SetFlags(0)
>     // Output: 123
> }
> 

ExampleNew() shouldn't take a *testing.T.

Its signature should be just:

func ExampleNew() {
  ...
}

I get it. It is probably habit to add testing.T to tests. :)

-ayan

-- 
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: go 1.9 go test build fail on // Output:

[Ayan George]

gocss  wrote:

> good catch  however the thing that made it not obvious
> is that is it built without the // Output:   line ... 
> Running go test -work  can show why it fails ... further this does make 
> sense too
> that no such testing args should be in an 'Example' program.

Just out of curiosity, how might you use a testing.T value in an Example type
test?  Off the top of my head t.Log()/t.Logf() are the only things I can think
of.

> I think the test apparatus should fail or warn in either case.

If you ran go vet -tests, It would have complained but I think its output is
also a little cryptic and it doesn't appear to check for "// Output:" comments
Either way, go vet would have helped you here:

$ go vet -tests
ex_test.go:7: ExampleNew should be niladic

I also I think reading the testing docs and a careful read of the error text
explains almost as clearly as go vet:

> /tmp/go-build584983468/csspc/alog/_test/_testmain.go:30:22: cannot use 
> alog.ExampleNew (type func(*testing.T)) as type func() in field value

I agree that this was probably annoying and hard to catch. I think you solved
it correctly by either reading the docs or asking for help and I doubt you'll
ever make this mistake again.

Maybe you should also add go vet to your toolbox if it isn't already there?

-ayan

-- 
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] go test fails - appear that it misses capturing stdout

[Ayan George]

On 09/28/2017 07:29 PM, gocss wrote:
> first the code follow by output from 'go test -v'
> 

Take a look at src/testing/example.go around line 15.

The testing code temporarily re-assigns os.Stdout for the duration of
the Example.  It sets it to one of the end of a pipe that it uses to
capture the output of anything that writes to os.Stdout.

Since you are logging to a copy of os.Stdout, your first test wirtes to
a copy of os.Stdout and thus escapes/avoids having it's output captured
by go test.

I think the short answer is: don't do that?

-ayan

-- 
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] go test fails - appear that it misses capturing stdout

[Ayan George]

On 09/28/2017 07:29 PM, gocss wrote:
> first the code follow by output from 'go test -v'
> 

Also, you can sort of fix this by copying os.Stdout within the example
instead of the global var () section like:

// this does not fail because iowr is a copy of os.Stdout after
// it has been 'hijacked'.
func ExampleX1() {
var iowr io.Writer = os.Stdout
Trace = log.New(iowr, "trace:", 0)
Trace.Println("123")
// Output: trace:123
}

-- 
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] godoc only indexes packages in GOROOT?

[Ayan George]

farid.m.zaka...@gmail.com wrote:

> Is there a reason why GODOC only indexes packages it finds in $GOROOT ?  I
> would like to create indices of my personal packages + the standard library.
>

I think it does.  It looks in my ${GOPATH} and gives me what docs it can for my
poorly commented code.

-ayan

-- 
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] TCP writes without a corresponding read?

[Ayan George]

On 10/22/2017 04:50 AM, Matt Mueller wrote:
> Hey everyone!
> 
> This question cropped up while testing. It's 2 related questions:
> 
> *1. Why am I able to write to without accepting a connection?*
> 

As I understand it, by the time you accept() a connection, the TCP
stream has already been established.  The linux man page for listen()
says this about the backlog parameter:

  Now it specifies the queue length for completely established sockets
  waiting to be accepted, instead of the number of incomplete connection
  requests.

So I think we're talking about two things:  establishing a TCP
connection and building the plumbing to read from it.

> *2. How would I only allow it to write what it's able to read? In
> this example, the server connection only reads 1 byte before closing.
> This would be useful for testing flaky connections and retry logic:*
> 

I think once you've established a TCP strean -- that is by the time
net.Dial() (and I guess the underlying connect() system call) unblocks,
you should have a working stream that you can write on.

The server has to choose to accept and read from the descriptor.

To answer why you only read one byte:

Because you only make your receiving buffer (buf) in the server 1 byte.

Instead of:

buf := make([]byte, 1)

try:

buf := make([]byte, 0, 20)

or read into your buf using a loop.

-ayan


-- 
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] TCP writes without a corresponding read?

[Ayan George]

On 10/22/2017 06:06 AM, Ayan George wrote:
> 
> 
> buf := make([]byte, 0, 20)
> 

Sorry -- I meant:

  buf := make([]byte, 20)


-- 
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 reflect package performant?

[Ayan George]

On 10/27/2017 04:32 AM, go-question wrote:
> I'm accustomed to avoiding reflection in other languages due to 
> performance concerns, is that unfounded with Go's reflect package?
> 

There is some cost to using the reflect package but I don't think that
cost is unusually high.

I think whether it is 'performant' depends on your requirements. I'd
start by using the test tool to benchmark your code that needs reflect
too see if it meets your needs.

-ayan

-- 
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: How to know if interface{} data is nil w/o reflecting?

[Ayan George]

On 10/31/2017 10:25 AM, oju...@gmail.com wrote:
> Not being able to test for a nil interface is a Go language bug.
> 

Just curious:  How would you do this without type assertion or reflection?

-- 
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: How to know if interface{} data is nil w/o reflecting?

[Ayan George]

On 10/31/2017 12:42 PM, oju...@gmail.com wrote:
> Today you can't, Ayan.
> 

Right -- I understand that.  I'm asking how would you propose Go do
that?  What changes would you make to fix this?

I'm asking: If you claim Go is fundamentally broken in this way, how
would you fix it?

-ayan


-- 
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: How to know if interface{} data is nil w/o reflecting?

[Ayan George]

On 11/01/2017 07:18 AM, oju...@gmail.com wrote:
> Ayan, imagine I am part of a development team. In our program I have a
> pointer r:
> 
> r *myType
> 
> My variable r can be nil, because that is a valid situation. It is used
> in dozens of places, like this:
> 
> if r != nil {
>     r.doSomething()
> }
> 
> That is a very usual idiom, no only in Go, but in many languages. Every
> programmer is acquainted to that.
> 
> Then, years later, other programmer in my team decides to create an
> interface to better capture a new understanding of the problem at hand,
> changing the type of r to:
> 
> r myInterface
> 
> Subtly, the meaning of
> 
> if r != nil {
>     r.doSomething()
> }
> 
> changes. Under the right circumstances our software starts to behave
> strangely. What?
> 
> This problem is dangerous because it is so subtle. We will read our old
> code time and again to no avail, because everything seems fine and no
> one has changed that "if r != nil r.doSomething" in ages.
> 

I think I understand what you're saying. The thing is: You changed the
type of r and I don't believe anyone ever promised that you can change
the type of a variable to an interface AND preserve its behavior.

Would you expect r to behave the same if you changed it from type string
to an int?

Also, you understand how interfaces work. I think our hypothetical
developer should simply understand how interfaces work as well; it is
reasonable to expect developers to know the language.

I don't think it is reasonable to introduce this kind of ambiguity to
protect developers from actually learning the language. I think
interfaces as they are are clear and consistent and making nil
interfaces suddenly equal to interfacess with nil values is more
'subtle' and harder to understand.

-- 
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: How to know if interface{} data is nil w/o reflecting?

[Ayan George]

On 11/03/2017 05:23 AM, oju...@gmail.com wrote:
> Could somebody please point me to any example of comparing an
> interface to nil, in production code? Thanks.
> 

Does checking if a variable of type error is nil count?

-ayan

-- 
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] fetching URLs Concurrently

[Ayan George]

On 11/13/2017 04:10 AM, 2891132l...@gmail.com wrote:

> for range os.Args[1:] {
>   fmt.Println(<-ch)
>      }
>      fmt.Printf("%.2fs elasped\n", time.Since(start).Seconds())
> }

If I understand correctly, you want fetch() to get each URL twice but
you only read from the 'ch' channel once per URL.

So if I passed it 3 urls, we should expect to receive at least 6
responses back on ch but you only read from it 3 times.

If that loop above was something more like (and this is a kludge):

for range append(os.Args[1:], os.Args[1:]...) {
  fmt.Println(<-ch)
}

or maybe better:

for i := 0; i < len(os.Args[1:]) * 2; i++ {
  fmt.Println(<-ch)
}

The problem is that you return from fetch() early if there is an error
so you might end up blocking on <-ch forever because the number of sends
to that channel will not match the number of receives.

If I were you, I'd consider using a sync.WaitGroup to wait for all of
the fetch() calls to complete and store the results in a buffered channel.

Once all of the fetch() calls are done, you can close the channel and
range over it like this:

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


-- 
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] Running commands via SSH

[Ayan George]

kburke...@gmail.com wrote:

> Hi, I'd like to SSH to a remote host and run an arbitrary command. I found 
> this pretty difficult to do with existing Go libraries.
>
> The first problem I had was around escaping; commands run locally are 
> appropriately escaped but I found it difficult to get the right escaping 
> for commands run remotely. As an example, this hangs, I believe because of 
> the {<& in the middle of the command.
>
> cmd := exec.Command("ssh", "remote-host", "echo", "zdUZUKv{<&MsZG")
> bits, err := cmd.CombinedOutput()
> if err != nil {
> log.Fatal(err)
> }
> os.Stdout.Write(bits)
>
> Note exec.Command("echo", "{<&") runs just fine.
>

(my previous post didn't seem to make it.  this is probably better anyway.)

I think ssh is using your login shell execute the remote command so the
<& is being interpreted as a redirect whereas when you run echo on
your local machine, it is simply being fork()/exec()ed and your
string is passed directly as a parameter without being interpreted
by a shell.

When I try your ssh command my shell (bash) gives the following
complaint:

err: exit status 1
bash: MsZG: ambiguous redirect

I can get it to work by escaping the '<' and '&' individually as well as
putting the entire offending argument in single quotes.

Which characters are special depends on your shell and even which mode
your shell is running in! This is trickier than it seems at first glance
and I think the ultimate solution is that you'll have to be aware of
which shell you're running on the remote machine and how to properly
escape arguments for it.

It'd be interesting to know if there is a way to get ssh to execute a
command without invoking the login shell. After a quick glance of the
man page and source (for FreeBSD at least) I couldn't find a way.

-ayan

-- 
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: Idiomatic way to remove duplicates in a slice

[Ayan George]

On 12/14/2016 12:14 PM, Michael Jones wrote:
> Do we know anything about the structure of the slice?
> 
> 

Just FYI -- this thread was started on 8/11/2012 and you, Michael, even
responded to it at the time..  I think it was pretty well hashed out
back then and I'm not sure why this was resurrected:

   https://groups.google.com/forum/#!topic/golang-nuts/-pqkICuokio

-ayan

-- 
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] float32 vs float64 precision lost when casting to int

[Ayan George]

On 12/14/2016 12:44 PM, Jan Mercl wrote:
> On Wed, Dec 14, 2016 at 6:36 PM Mauro Romano Trajber  > wrote:
> 
>> The float to int conversion behaves different for 32 and 64 precision.
>> https://play.golang.org/p/-zkCNSTbNa
> 

I may be wrong but I think that 32 bit floating point types allow up
to 23bits in the mantissa. 8091765 requires 24 bits to encode so with
float32, you're dropping the last bit (1 of course) after you multiply
by 100.0 and that throws the rounding off.

In fact, 80917.64 does predictably work with both types.

-- 
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] Hashing (u)int8

[Ayan George]

On 12/16/2016 07:01 PM, Ondrej wrote:
> Hey,
> I had int as a key in my map and later realised I only used 100 or so
> values, so swapped it for a uint8, expecting a minor speed increase, but
> saw a major slowdown instead. To recreate this, I tried this simple
> microbenchmark and was surprised by the difference between (u)int8/16
> and int/int32/int64.
> 
> https://play.golang.org/p/RxmtASRiS4
> 
> In my actual code I have the key in a slice, so I expected []uint8 to be
> more cache friendly than []int, but I guess any potential cache
> friendliness was outweighed by this hashing performance difference.
> 

It looks like any type that isn't the size of a word is slower.
Probably due to all sort of masking and maybe shifting it has to do.

-ayan

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

Re: [go-nuts] how to seek in file using go

[Ayan George]

On 01/19/2017 01:22 AM, hui zhang wrote:
> I am using encoding/binary to read/write (struct)data to/from file.
> Some times , I need to seek in the file while reading .
> how to do this in go.
> Check the code below

[snip!]
>
>
> fi, err := os.Open("./output.bin")
>if err != nil {
>   panic(err)
>}
>// close fi on exit and check for its returned error
> defer func() {
>   if err := fi.Close(); err != nil {
>  panic(err)
>   }
>}()
>
>rd := bufio.NewReader(fi)
>err = binary.Read(rd, binary.LittleEndian, &pi)
>if err != nil {
>   fmt.Println("binary.Read failed:", err)
>}
>fmt.Println(pi)
>
>fi.seek()?
>

Is File.Seek() what you're looking for or do you need something else?

  https://golang.org/pkg/os/#File.Seek

-ayan

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

Re: [go-nuts] how to seek in file using go

[Ayan George]

On 01/19/2017 02:00 AM, hui zhang wrote:
> so the file seek does not work in bufio.Read  ?
> 

It looks like this has been answered before:

   https://groups.google.com/forum/#!topic/golang-nuts/mOvX0bmJoeI

You could also create another bufio.Reader after you seek like:

   rd := bufio.NewReader(fi)
   err = binary.Read(rd, binary.LittleEndian, &pi)
   fmt.Println(pi)


   fi.Seek(0, os.SEEK_SET )?

   rd = bufio.NewReader(fi)
   err = binary.Read(rd, binary.LittleEndian, &pi)
   fmt.Println(pi)

If you look at the bufio.Reader struct, it doesn't appear to have a
notion of where it is in the file -- it just contains a buffer, read and
write positions within that buffer, etc.

-ayan

-- 
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] Unexpected Behaviour of goroutine

[Ayan George]

Srivathsan Madhavan  wrote:

> Hi all,
>
> I still consider myself a newbie to Golang hence my question here could be 
> due to my fundamental misunderstanding of this language
>
> I have the following code:
>
> func main() {
>
> for i := 0; i < 5; i++ {
>
> go func() {
>
> log.Println("i=", i)
>
> }()
>
> }
>
>
> fmt.Print("Press  to quit...")
>
> var input string
>
> fmt.Scanln(&input)
>
> }
>
>
> The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But what I
> got was 5, 5, 5, 5 and 5!  Why is that so?
>

I'm learning golang too so please correct any errors here.

It looks like you created a closure where i is lexically scoped to
each of your gofunc() instances.  Since they're all accessing the same
i variable, you're seeing the race between incrementing i and spooling
up / starting each goroutine -- that is, the value of i reaches 5
before all of the goroutines get to print it.  You can verify this by
printing the address of i by changing your log.Println() call to
something like:

  log.Printf("i = %d, &i = %p", i, &i)

The addresses should be the same.

If you want each goroutine to have a copy of I, you should declare and
run gofunc() like below:

gofunc(c int) {
  log.Println("c=",c)
}(i)

Which passes a copy of i to each routine.  That should give you what
you're looking for -- that is if you're not expecting i to be printed
in order. :)

-ayan

-- 
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] Building Go from Source / Managing my ${GOROOT}

[Ayan George]

I'm somewhat new to go and I've been relying on FreeBSD and Ubuntu
packages for the compiler.

I decided to try building Go from source to get go1.8 and I realized
it is really convenient to simply clone the repo into my
${GOROOT}/src (which is now simply ${HOME}/go), build Go (I did
extract 1.8 binaries to bootstrap my environment), and add
${HOME}/go/bin to my path.

Now I don't have to worry about finding the latest source and I can
even keep up with new developments by pulling new code.

Am I missing anything by not using the packages?  Is this idiomatic?

-ayan

-- 
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] Goroutine in a for loop: Closure versus direct

[Ayan George]

On 02/25/2017 03:48 AM, Amit Saha wrote:
> 
> I think both these approaches are fine, but just wanted to check.
> 

tl;dr: I think the second example is the way to go.

I'm somewhat new to Golang so please someone correct me if I'm wrong.

Neither of your examples are closures and, AFAIK, they're both
effectively the same. As Jan mentioned -- if you actually used a
closure like below, there *would* be a data race:

func main() {
  slice := []int{1, 23, 100, 101}
  for _, val := range slice {
go func() {
  fmt.Printf("val = %d\n", val)
}()
  }
}

Notice the goroutines access the same 'val' variable concurrently
while 'val' changes.

I don't think your code presents a race because it copies 'val' when it
is passed as a parameter to printme() or to your anonymous function.

I think the choice to use an anonymous function and the choice to use a
closure have their own considerations.

You typically choose to use an anonymous function if the code
you want to execute is relatively short and if the code is something
that you don't plan to re-use.

Your example is short but it is only one statement so wrapping it in an
anonymous function doesn't buy you anything. If it were two or three
statements I think it'd be worthwhile.

-ayan

-- 
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 do I convert a byte into BigEndian or LittleEndian?

[Ayan George]

On 02/27/2017 04:45 PM, Glen Newton wrote:
> 
> 
> |Given a byte b, how do I convert it to a byte of particular
> endianness? It is not clear to me looking at ||"encoding/binary"
> 
> (I am assuming that golang byte endianness varies across 
> ||architectures. If this is wrong please educate me). :-)
> 

Endianness only makes sense when talking about multiple bytes.  One byte
is the same in little and big endian. :P

Still, I assume you're talking about multiple bytes so you should check
out the encoding/binary package:

  https://godoc.org/encoding/binary



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

Re: [go-nuts] Why is Go Unicode concat so slow compared to Python3 ?

[Ayan George]

On 02/27/2017 07:21 PM, Ian Lance Taylor wrote:
> On Mon, Feb 27, 2017 at 3:58 PM, Shubha Ramani 
>  wrote:
>> Please see the attached two scripts.
>> 
>> Use python3 for concat_test.py.
>> 
>> I'm getting 591 nsec for the micro benchmark in python and 4453 ns 
>> for the microbenchmark in go. I stole this benchmark from 
>> Unicode.py of pybench, but changed it a bit.
>> 
>> (py36env) shubha@shubha-Z170X-UD5:~/myperformance$ go test 
>> --bench=UnicodeConcat BenchmarkUnicodeConcat-8  30 4453
>> ns/op
>> 
>> (py36env) shubha@shubha-Z170X-UD5:~/myperformance$ python 
>> concat_test.py time_taken = 591.0059640882537 nsec
> 
> I'm no Python expert, but I don't see any evidence that your Python 
> code is actually executing either mysetup or concat.
> 

I noticed the same thing.  Even after you do call myinit() the
performance difference is still the same with python2.7.

python3 has similar performance to Go:

ayan@kiwi:~/unicode$ python --version
Python 2.7.13
ayan@kiwi:~/unicode$ python ./concat_test.py
time_taken = 924.661159515 nsec

ayan@kiwi:~/unicode$ python3 ./concat_test.py
time_taken = 2005.0194200011902 nsec

ayan@kiwi:~/unicode$ go test -bench=.
BenchmarkUnicodeConcat-2  10 19751 ns/op
PASS
ok  _/home/ayan/unicode 2.175s


Here's pprof output on my machine.  The runtime.memclr() call sticks out
to me.

ayan@kiwi:~/unicode$ go tool pprof prof.cpu
Entering interactive mode (type "help" for commands)
(pprof) top10
1090ms of 1430ms total (76.22%)
Showing top 10 nodes out of 103 (cum >= 20ms)
  flat  flat%   sum%cum   cum%
 480ms 33.57% 33.57%  480ms 33.57%  runtime.memmove
 240ms 16.78% 50.35%  240ms 16.78%  runtime.memclr
 110ms  7.69% 58.04%  550ms 38.46%  runtime.mallocgc
  60ms  4.20% 62.24% 1180ms 82.52%  runtime.concatstrings
  40ms  2.80% 65.03%   40ms  2.80%  runtime.futex
  40ms  2.80% 67.83%   40ms  2.80%  runtime.heapBitsForObject
  40ms  2.80% 70.63%   40ms  2.80%  runtime/internal/atomic.Xchg
  30ms  2.10% 72.73%   80ms  5.59%  runtime.(*mheap).allocSpanLocked
  30ms  2.10% 74.83%  620ms 43.36%  runtime.rawstring
  20ms  1.40% 76.22%   20ms  1.40%  runtime.(*mSpanList).remove
(pprof)

-- 
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] Why is Go Unicode concat so slow compared to Python3 ?

[Ayan George]

On 02/27/2017 10:25 PM, Dan Kortschak wrote:
> When the python functions are actually called the comparison is more
> reasonable:
> 
> ```
> ~/concat $ go test -bench . concat_test.go 
> BenchmarkUnicodeConcat-820 10379 ns/op
> PASS
> okcommand-line-arguments  2.193s
> ~/concat $ python concat_test.py 
> time_taken = 8901.3030529 nsec
> 
> ~/concat $ python3 concat_test.py 
> time_taken = 7210.201049922034 nsec
> ```
> 
> This involved appending "; concat()" and "; mysetup()" to the stmt and
> setup parameters.
>

D'oh!  I was printing myinit() too but somehow I wasn't calling it
inside of the benchmark.

-- 
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: constant 256 overflows byte

[Ayan George]

On 03/07/2017 07:06 PM, Eric Brown wrote:
> memoryBlock[2] = 256 - (187 - memoryBlock[2]) ' results in error: 
> constant 256 overflows byte


So since you're assigning to a byte I think Go is treating all of the
constants as bytes.  A byte can only encode between 0 and 255. You need
an extra bit (ie, more than a byte) to store 256.   Something like the
following works but might be silly:

 memoryBlock[2] = byte(int(256) - (187 - int(memoryBlock[2])))

-- 
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: constant 256 overflows byte

[Ayan George]

On 03/07/2017 07:06 PM, Eric Brown wrote:
> By the way, this is code snipped from within a conditional check, so
> memoryBlock[2] will always be < 187 in this situation.
> 
> On Tuesday, March 7, 2017 at 6:02:59 PM UTC-6, Eric Brown wrote:
> 
> memoryBlock := make([]byte, 4)
> binary.LittleEndian.PutUint32(memoryBlock, 12345678)
> 
> memoryBlock[2] = 256 - (187 - memoryBlock[2]) ' results in error:
> constant 256 overflows byte
> memoryBlock[2] = 255 - (187 - memoryBlock[2]) + 1 ' results in no
> errors
> 

Sorry, I only needed to cast the variable:

   memoryBlock[2] = byte(256 - (187 - int(memoryBlock[2])))

-- 
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] Cross compiling from Windows to Linux produces non-working go routines

[Ayan George]

On 03/08/2017 08:30 AM, asci...@gmail.com wrote:

> In the main function I call various go routines, I've set println after
> each call, so I know they are being executed. But I don't get the
> printlns I've set inside of some of those routines, for the same purpose.
> 

So you are seeing some Println()s but not others or are you not seeing
any Println()s at all?

-ayan

-- 
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] Best practice for Method Receivers

[Ayan George]

On 03/24/2017 09:20 PM, st ov wrote:
> Is it idiomatic to mix-&-match pointer and value method receivers for
> a given type? or in *_general_*, if a single method requires a 
> pointer receiver than *all methods* should take a pointer, regardless
> if a value receiver is appropriate?
> 
> For example, should Foo.SetVal also be a pointer receiver even though
> a value receiver would be acceptable?

IMHO this decision should be made exactly the way you would decide if
any other parameter to a function is a pointer. In fact, I think
function receivers are equivalent to passing an additional parameter to
a function. Someone please correct me if I'm wrong.

Particularly: Do you plan to modify the receiver and is the receiver so
large that copying it would be cumbersome.

I don't think there is a hard rule that if you make one receiver a
pointer then all of them must be (or vice versa).

-ayan

-- 
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] sql: please, guys, tell me I am doing it wrong.

[Ayan George]

On 04/03/2017 08:50 AM, oju...@gmail.com wrote:
> I built a little command line utility for running arbitrary sql queries.
> You use it like:
> 
> runQuery "select * from myTable"
> 
> 
> Previously I have build similar tools in C and Java and I don't remember
> needing to code a hack to handle a variable number of columns.
> 
> https://play.golang.org/p/6WOu1SzgcZ
> 

Just going from the documentation, rows.Scan() is a variadic function so
you should be able to do something like:

  cols, _ := rows.Columns()
  v := make([]interface{}, len(cols))
  err = rows.Scan(v...)

-ayan


-- 
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] why iota can't be assigned to variables?

[Ayan George]

On 05/03/2017 10:38 AM, T L wrote:
> 
> 
> On Wednesday, May 3, 2017 at 9:28:28 PM UTC+8, Jan Mercl wrote:
> 
> On Wed, May 3, 2017 at 3:19 PM T L > 
> wrote:
> 
> Why would you want to assign iota to a variable? What value should 
> iota in such case have?
> 
> 
> The request is not essential, but any harm of it?
> 

Can you show an example (some preferably some mocked up Go code) of how
this can be useful?

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

Re: [go-nuts] Using database/sql in a web application

[Ayan George]

On 01/05/2018 10:16 AM, Manlio Perillo wrote:
> Recently I have developed a few web applications in Go, using a 
> PostgreSQL database, but I have yet understand the best way to use
> the database/sql package.
> 

I don't know how you're serving web pages but I typically use net/http.
This also means that I typically build an http.Server.  This requires
that I create a type that conforms to the http.Handler interface.

You can use this type to pass around all of the data you need, including
sql.DB instances, log.Logger, etc.

So here's the skeleton of what I normally do.  I haven't tested this --
this is just to get the point across.  Finally, this may be completely
off base.  I'm open to any criticisms etc. anyone may have.

package main

import (
  "database/sql"
  _ "github.com/lib/pq"
  "log"
  "net/http"
  "time"
)

type app struct {
  db *sql.DB
}

func (a *app) ServeHTTP(w http.ResponseWriter, r *http.Request) {
  // here we can use all of the fields of our app struct -- including
the db!

  row := db.QueryRow("select current_timestamp;")

  var time string
  err := row.Scan(&time)

  if err != nil {
// handle the error.  maybe log it?  i typically
// create a log.Logger instance in my app and use it
// at times like these.
return
  }

  w.Write([]byte("hello, world!"))
}

func main() {
  db, err := sql.Open("postgres", "...")

  if err != nil {
log.Fatal(err)
  }

  if err := db.Ping(); err != nil {
log.Fatal(err)
  }

  myapp := app{
db: db,
  }

  srv := http.Server{
Addr: ":8080",
ReadTimeout:  1 * time.Second,
WriteTimeout: 1 * time.Second,
Handler:  &myapp,
  }

  log.Fatal(srv.ListenAndServe())
}

-- 
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] http.FileServer: how to serve static files requested from different domains?

[Ayan George]

Constantine Vassilev  wrote:

>
> I have web server serving requests from two domains: domain1.com and 
> domain2.com
> The assets directories are different for the two domains.
>
> webrootdomain1/assets
> and
> webrootdomain2/assets
>
> How to make the handler for assets to serve different directory depending 
> from 
> the requests from different domains? So they to be dependent from the host?

I think you'll have to check the http.Request.Host and conditionally execute
the ServeHTTP method of an http.FileServer based on it.

You can find an example of what I'm describing below.  I hope I understood your
problem.

package main

import (
  "log"
  "net/http"
)

func main() {
  webrootdomain1 := "./assets1"
  webrootdomain2 := "./assets2"

  http.HandleFunc("/assets/", func() func(http.ResponseWriter, *http.Request) {
// create a closure with our file handlers.
fs1 := http.StripPrefix("/assets", 
http.FileServer(http.Dir(webrootdomain1)))
fs2 := http.StripPrefix("/assets", 
http.FileServer(http.Dir(webrootdomain2)))

// retrun a function that executes the ServeHTTP() method of 
one of our
// filehandlers based on the contents of r.Host.
return func(w http.ResponseWriter, r *http.Request) {
  log.Printf("got request for host %q, path %q", r.Host, r.URL.Path)
  switch r.Host {
  case "localhost:8080":
log.Printf("trying to serve file for domain %q", r.Host)
fs1.ServeHTTP(w, r)
  case "anotherdomain.com":
fs2.ServeHTTP(w, r)
  }
}
  }())

  http.ListenAndServe(":8080", nil)
}

-- 
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] New identifiers and selectors in short variable declarations

[Ayan George]

On 01/09/2018 04:45 PM, Ian Lance Taylor wrote:
> On Tue, Jan 9, 2018 at 1:02 PM, Jim Bishopp
>  wrote:
>> 
>> Has there ever been a discussion about allowing new identifiers and
>> selectors in short variable declarations?
>> 
>> var a struct { x int } b, a.x := 1, 2
>> 
>> ERROR: expected identifier on left side of :=
> 
> That idea appears in https://golang.org/issue/377, along with many 
> others.
> 

I had the same question myself. I settled on the idea that that is a
short declaration -- not an assignment -- though it does re-declare
existing variables (of the same type!). That behaves like assignment
but I think it is still declaration.

But its behavior makes sense if you consider that you can't declare or
re-declare struct member.

-ayan

-- 
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] http.FileServer: how to serve static files requested from different domains?

[Ayan George]

On 01/09/2018 02:34 PM, Andy Balholm wrote:
> Try:
> 
> http.Handle(“domain1.com/assets/", http.StripPrefix("/", 
> http.FileServer(http.Dir(*webrootdomain1
> http.Handle(“domain2.com/assets/", http.StripPrefix("/", 
> http.FileServer(http.Dir(*webrootdomain2
> 

Wow! Reading is fundamental. I didn't know ServeMux handled the domain
name. I wish I could take back my previous email now. :)

-ayan

-- 
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] http.FileServer: how to serve static files requested from different domains?

[Ayan George]

On 01/13/2018 11:26 PM, Constantine Vassilev wrote:
> Here is how I implemented it:
> 

Well -- just to be clear:  I think my solution is wrong.  I didn't
understand how http.ServeMux worked:

  https://golang.org/pkg/net/http/#ServeMux

Andy Balholm pointed out that http.Handle() can accept a domain name
name as part of the pattern in the first argument:


On 01/09/2018 02:34 PM, Andy Balholm wrote:
> Try:
> 
> http.Handle(“domain1.com/assets/", http.StripPrefix("/",
http.FileServer(http.Dir(*webrootdomain1
> http.Handle(“domain2.com/assets/", http.StripPrefix("/",
http.FileServer(http.Dir(*webrootdomain2
> 

If you're going to use the default http.Server and http.ServeMux, I
think that's the way to go.  Please disregard my wrong response.

-ayan

-- 
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] Go as your first language

[Ayan George]

On 01/16/2018 02:10 AM, James Pettyjohn wrote:
> 
> Are there tracks of knowledge to take someone from 0 to understanding
> baseline knowledge?
> 
> And from there through taking them to a professional grade standard?
> 

I think "Introducing Go" is a great book for someone relatively new to
programming:

  amzn.com/1491941952

It is fairly short and gives a really gentle introduction to Go without
(IIRC) complaining about other languages.

I'd probably recommend the following in order:

  * Introducing Go
  * The Go Programming Language
  * Concurrency in Go

-ayan

-- 
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] Using reflect to call functions on struct members

[Ayan George]

On 01/18/2018 01:28 PM, Boone Severson wrote:
> Hi,
> 
> I've got structs containing custom types. I'm hoping to use reflect 
> to create some fairly generic code to Validate() every field of a
> struct based on its type, but I can't seem to get the code right. Is
> this possible? I've set up a playground to show where I've gotten.
> 
> https://play.golang.org/p/SgaGuLOjA4L
> 

The problem is that the Validate() functions take pointer receivers but
you MyStruct uses the actual FooTypeA and FooTypeB values.

You can get it to work by either making the Validate functions take a
copy of the value:

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

or by making the members of MyStruct pointers:

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

Check out the Method Sets section of the Go spec:

  https://golang.org/ref/spec#Method_sets

-ayan

-- 
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: Using log Package with log.Lshortfile Flag

[Ayan George]

On Wednesday, April 11, 2018 at 5:31:55 AM UTC-4, Kaveh Shahbazian wrote:
>
> The code resides here .
>
> The output from the program is:
>
> NaClMain [ info  ] 23:00:00 main.go:13: main.main started
> NaClMain [ info  ] 23:00:00 main.go:13: main.compute1 started
> NaClMain [ info  ] 23:00:00 main.go:13: main.compute2 started
> NaClMain [ info  ] 23:00:00 main.go:27: main.compute2 took 10ms
> NaClMain [ info  ] 23:00:00 main.go:22: main.compute1 took 20ms
> NaClMain [ info  ] 23:00:00 main.go:15: main.main took 20ms
>
> Program exited.
>
> The problem is the expected line number in first three lines is 37. But it 
> is 13.
> I failed to understand why this is happening since log.Println internally 
> relies on runtime.Caller
>
> Note: I am aware that there is a logical bug in my code since the intended 
> first three lines were 13, 18 and 25 - but that does not affects the 
> expectations of the issue at hand.
>


I think the issue is that the parameters to your  inflog.Println() routine 
are evaluated and stored when you execute defer.

https://golang.org/ref/spec#Defer_statements

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