[go-nuts] Re: best practices of client middleware

[Eyal Posener]

Very Nice stuff - shame he didn't merge it.
But I see that you changes the request in the RoundTrip function, which is 
claimed as forbidden in the docs.
Again, I don't understand why the docs forbid it...


On Wednesday, March 7, 2018 at 1:52:55 AM UTC+2, Sangjin Lee wrote:
>
> I offered a PR on alice (which is a middleware library for the handlers) 
> that does that. It's essentially an application of the same pattern. We're 
> getting a lot of mileage for this.
>
> https://github.com/justinas/alice/pull/40
>
> On Tuesday, March 6, 2018 at 6:41:53 AM UTC-8, Eyal Posener wrote:
>>
>> Good stuff,
>> So I see that this library wraps the http.Client and doesn't use the 
>> roundtripper.
>> Pretty elegant!
>>
>> I still have two questions about the standard library:
>>
>>- Didn't understand yet why it is not allowed to add headers in the 
>>roundtripper.
>>- Is this a bit strange that the standard library provides a 
>>beautiful way to have server middleware, but no way to have client 
>>middlewares?
>>
>> Cheers,
>> Eyal
>>
>> On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote:
>>>
>>> As far as I am aware, there is very little information about best 
>>> practices regarding client side middlewares. 
>>>
>>> I though that having such support is neat idea and I have implemented 
>>> something (that I use for some time now, though still in beta) that you 
>>> might find useful for your use case. I have written small library that 
>>> describes client middleware protocol , 
>>> some useful middlewares  
>>> and HTTP client  that's using these 
>>> libraries. 
>>>
>>> This might solve your problem directly (writing new middleware is 
>>> trivial), but it might introduce dependency that you don't want, so I hope 
>>> this will provide inspiration on how you would do something similar 
>>> yourself. 
>>>
>>> On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote:

 Hi

 I want to implement a client middleware - for example: sign the request 
 body and add the signature as an HTTP header.
 I thought that the best way to do it is to implement a RoundTripper 
 interface  which up on 
 request, calculate the signature, adds the header, and invoke a "next" 
 ToundTripper.

 This could be a very generic implementation, which i can inject to any 
 client that uses the standard library http.Client.

 However, I found the following in the doc:

 // RoundTrip should not modify the request, except for
 // consuming and closing the Request's Body. RoundTrip may
 // read fields of the request in a separate goroutine. Callers
 // should not mutate the request until the Response's Body has
 // been closed.


 Is there a standard way to do it?

 Thanks,
 Eyal

>>>

-- 
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: My views on Go and why it's better than Scripting

[Rich]

I am a systems administrator. I find it easier and faster to write a 
program in Go than it is to script it in Bash.  Since writing scripts is 
something most Sys Admins do I've had to write them in Perl, PHP, TCL, 
Ruby, etc. and the BIGGEST frustration is that I would get a script written 
debugged etc. and I'd go to deploy it to the server.   The server doesn't 
use the right version, or doesn't have the right package installed, and 
hours of additional work are done to get your script to work. On a 
production server installing one binary for something like a Nagios alarm I 
can get away with on a production system, I can't just go and start 
apt-getting or yum installing a bunch of new packages.  With Go I install 
the dependancies on MY system -- and that system is a Mac.  Cross compiling 
is trivial (unless the package it used CGO), and I normally generate code 
that will run on Windows, Linux, Mac and the 32 / 64 bit variations, and I 
can copy that one binary on to the system. No DLLs, no installing extra 
packages, it just runs, no dependency or version headaches. 

On Friday, March 2, 2018 at 4:29:45 PM UTC-5, dorival...@gmail.com wrote:
>
> Hi, I could be wrong (please correct me ;-), but here you are what I think 
> about Go:
>
> INTRODUCTION
> Computers and software were initially developed for scientific computing; 
> e.g., ALGOL and FORTRAN from the 1950s! Therefore, several computer 
> languages and libraries have been invented and are used in scientific 
> computing to date.  Nonetheless, when programming a new scientific 
> simulation, the question about computational efficiency versus ease-of-use 
> remains open. Here, we aim to shed light on a suitable answer to this 
> question---TL;DR use Go and Gosl!
>
> One would say that scripting (interpreted) languages might provide the 
> convenient platform for computations as long as care is taken to send 
> intensive tasks to functions pre-compiled with high-performance languages. 
> This strategy fails to create an easy-to-use environment because the 
> programmer needs to think when and where those tasks should go. Considering 
> that this kind of decision is essential for performance, we argue that 
> scripting language is not the best solution.  Furthermore, we argue that 
> scripting is the worst tool for teaching new programmers in scientific 
> computing.
>
> We argue that only experts should use scripting languages (scripts) for 
> computer programming because beginners cannot understand how dangerous the 
> flexibility of scripts can be. For example, the assignment of variables 
> with the same name to different types is often a cause of misunderstandings 
> and failures. To make this problem even worse, failures due to wrong types 
> are not captured at runtime---certainly not at compilation time (there is 
> no compilation time in scripts). In other words, the interpreter is too 
> permissive.  The scientist, if aware (rarely the case with students), will 
> investigate the numerical output and, after much work, will find the source 
> of the error. Therefore, this situation is not ideal. To exemplify, the 
> following is allowed in Python (or Julia---similar syntax):
>
> ```
> a = 1.0
> a = "a" # OK in Python or Julia
> ```
>
> In the following code, Go will detect the error with a message such as 
> `./test.go:5: cannot use "a" (type string) as type float64 in assignment`:
>
> ```
> package main
> func main() {
> a := 1.0
> a = "a" // not accepted in Go
> }
> ```
>
> The problem propagates in scripting languages when developing 
> objected-oriented code. For example, a member data of a class can be 
> entirely modified by `anyone`, `anywhere` in Python! This issue completely 
> defeats the purpose of encapsulation in OOP.
>
> In summary, scripting (e.g., Python) and alike (e.g., Julia, Matlab) 
> languages are excellent for the expert programmer only who can understand 
> what is going on. However, they are very misleading to the beginner. In 
> other words, the strictness of compiled languages DOES help to learn 
> computer programming. Furthermore, the tools for working with compiled 
> language often take advantage of well-defined types. The shift towards type 
> declaration is so apparent that new languages and strategies are being 
> invented to overcome these issues. For example, TypeScript and Javascript 
> (ES6) combined with FlowType have been recently developed and have a fast 
> adoption among web developers. It seems that no new large project will use 
> non-typed Javascript code.
>
> GO LANGUAGE
> Go is a modern programming language created by Google engineers in 2007, 
> including Robert Griesemer, Rob Pike, and Ken Thompson. The language was 
> later made public as open source in 2009. Go has since grown exponentially 
> attracting a large number of co-developers and users. The primary goal 
> leading to the introduction of yet a new language was the combination of 
> efficiency (like C/C++) with ease of 

Re: [go-nuts] Undocumented behaviour - panic exiting with exit code 2?

[Rob Pike]

Largely in agreement. Moved the conversation to the bug.


On Wed, Mar 7, 2018 at 11:08 AM, Ian Lance Taylor  wrote:

> On Tue, Mar 6, 2018 at 3:55 PM, Rob Pike  wrote:
> > That's poor. Exit code 2 is supposed to mean 'incorrect arguments' in the
> > Unix tradition.
> >
> > Something like 127 or 255 would be better.
>
> I think you actually set it to 2, back in June, 2008, in what is now
> known as git revision aeb43984ec7c86aee220cc56146e0127de4ce2e3.
>
> See the change to runtime.c in
> https://github.com/golang/go/commit/aeb43984ec7c86aee220cc56146e01
> 27de4ce2e3
> .
>
>
> I don't know what Supervisor is but if it is running on a Unix system
> I don't think it should treat exit code 2 as success.
>
> I don't think we should document the exit status of panic except to
> say that it is non-zero.
>
> Ian
>
>
>
> > On Wed, Mar 7, 2018 at 10:39 AM, cachvico 
> wrote:
> >>
> >> Curious why panic appears to exit with code 2
> >> (https://golang.org/src/runtime/panic.go line 757)
> >>
> >> I can't find any mention of this in the spec; this should probably be
> >> documented?
> >>
> >> For example Supervisor treats exit codes 2 (and 0) as "expected" by
> >> default, which leads to processes not restarting on a Go panic.
> >>
> >> Thanks,
> >>
> >> Darren
> >>
> >> --
> >> 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.

Re: [go-nuts] Undocumented behaviour - panic exiting with exit code 2?

[Ian Lance Taylor]

On Tue, Mar 6, 2018 at 3:55 PM, Rob Pike  wrote:
> That's poor. Exit code 2 is supposed to mean 'incorrect arguments' in the
> Unix tradition.
>
> Something like 127 or 255 would be better.

I think you actually set it to 2, back in June, 2008, in what is now
known as git revision aeb43984ec7c86aee220cc56146e0127de4ce2e3.

See the change to runtime.c in
https://github.com/golang/go/commit/aeb43984ec7c86aee220cc56146e0127de4ce2e3
.


I don't know what Supervisor is but if it is running on a Unix system
I don't think it should treat exit code 2 as success.

I don't think we should document the exit status of panic except to
say that it is non-zero.

Ian



> On Wed, Mar 7, 2018 at 10:39 AM, cachvico  wrote:
>>
>> Curious why panic appears to exit with code 2
>> (https://golang.org/src/runtime/panic.go line 757)
>>
>> I can't find any mention of this in the spec; this should probably be
>> documented?
>>
>> For example Supervisor treats exit codes 2 (and 0) as "expected" by
>> default, which leads to processes not restarting on a Go panic.
>>
>> Thanks,
>>
>> Darren
>>
>> --
>> 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.

Re: [go-nuts] Undocumented behaviour - panic exiting with exit code 2?

[Rob Pike]

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

On Wed, Mar 7, 2018 at 10:55 AM, Rob Pike  wrote:

> That's poor. Exit code 2 is supposed to mean 'incorrect arguments' in the
> Unix tradition.
>
> Something like 127 or 255 would be better.
>
> -rob
>
> On Wed, Mar 7, 2018 at 10:39 AM, cachvico 
> wrote:
>
>> Curious why panic appears to exit with code 2 (
>> https://golang.org/src/runtime/panic.go line 757)
>>
>> I can't find any mention of this in the spec; this should probably be
>> documented?
>>
>> For example Supervisor treats exit codes 2 (and 0) as "expected" by
>> default, which leads to processes not restarting on a Go panic.
>>
>> Thanks,
>>
>> Darren
>>
>> --
>> 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] Undocumented behaviour - panic exiting with exit code 2?

[Rob Pike]

That's poor. Exit code 2 is supposed to mean 'incorrect arguments' in the
Unix tradition.

Something like 127 or 255 would be better.

-rob

On Wed, Mar 7, 2018 at 10:39 AM, cachvico  wrote:

> Curious why panic appears to exit with code 2 (
> https://golang.org/src/runtime/panic.go line 757)
>
> I can't find any mention of this in the spec; this should probably be
> documented?
>
> For example Supervisor treats exit codes 2 (and 0) as "expected" by
> default, which leads to processes not restarting on a Go panic.
>
> Thanks,
>
> Darren
>
> --
> 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] Undocumented behaviour - panic exiting with exit code 2?

[cachvico]

Curious why panic appears to exit with code 2 
(https://golang.org/src/runtime/panic.go line 757)

I can't find any mention of this in the spec; this should probably be 
documented?

For example Supervisor treats exit codes 2 (and 0) as "expected" by 
default, which leads to processes not restarting on a Go panic.

Thanks,

Darren

-- 
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] Pass by value in struct not yielding expected result

[Burak Serdar]

On Tue, Mar 6, 2018 at 2:58 PM, Bharath Ram  wrote:
> In that case, for a nested struct from top to bottom, all the values are
> copies as values, correct? i.e, string, int, float, array etc will be copied
> by value & map, slice, channel etc will be copied as pointers if they are
> initialized?
>
> https://play.golang.org/p/NzH8LVyQ0rp code works as I wanted. Generally,
> what practice should I follow? If I want a shared variable, should I have to
> keep all the variables as pointers like in the example
> (https://play.golang.org/p/NzH8LVyQ0rp) or like the way I showed earlier?

It depends on the case. What exactly do you want to do? I find dealing
with the semantics of copies of structures harder to comprehend, so I
try to avoid it when the structure has reference types, but sometimes
it is really useful. For instance, if the structure will be used as
read-only and has a reasonable size, a copy of it is just fine. In my
opinion, the only general rule is that you have to know how the data
is organized and that you know what you're doing.

>
> On Tuesday, March 6, 2018 at 3:40:47 PM UTC-5, Burak Serdar wrote:
>>
>> On Tue, Mar 6, 2018 at 1:23 PM,   wrote:
>> > go version 1.10
>> >
>> >
>> > Operating system and processor architecture
>> >
>> > GOHOSTARCH="amd64"
>> > GOHOSTOS="darwin"
>> > However, this happens in play.golang.org env as well.
>> >
>> >
>> > Checkout the code.
>> >
>> > https://play.golang.org/p/v6u7R_nbGRp
>>
>> doc1 := Document{}
>>  // Here, doc1.Data is nil
>>
>> ds := DataStore{Doc: doc1}
>>  // Here, ds.Doc has a copy of doc1, and ds.Doc.Data is nil
>>
>> ds.Doc.Data = DocData{}
>>  // Here, ds.Doc.Data is initialized, but not doc1.Data, because
>> ds.Doc is a copy of doc1
>>
>>
>> On the other hand:
>>
>> doc2 := Document{Data: DocData{}}
>> // Here, doc2.Data is initialized to an empty map
>>   ds2 := DataStore{Doc: doc2}
>> // And here, ds2.Doc is a copy of doc2, which contains a reference to
>> that empty map. The underlying maps are shared.
>>
>>
>>
>> >
>> >
>> > In the example, if the struct (Document) is not initialized at first,
>> > there
>> > is no place holder for future values pointing to same object. Is this
>> > intended?
>> >
>> > --
>> > 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.

[go-nuts] Custom Go Playground using Docker for Sandboxing

[Brad]

I'm in the middle of building out a Go library that does various things and 
am considering hosting something similar to Go Playground which can be used 
to create demos using the library.  Two big snags: 1) I of course need to 
be able to import my packages, and 2) I need sqlite support, which means 
CGO support.

I'm considering forking from https://github.com/xiam/go-playground, using 
the "unsafebox" (which basically builds using the regular amd64 OS instead 
of nacl).  This would solve the two issues above.

If I run these programs inside docker, as a non-root user, in a chroot-ed 
filesystem... any thoughts on how safe/unsafe this is likely to be.  I 
would probably run it on a separate machine that can just be thrown away 
and rebuilt if something goes horribly wrong, but I'm just curious about 
opinions on if this is a decent idea.

-- 
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] Pass by value in struct not yielding expected result

[Bharath Ram]

Thanks a lot!

On Mar 6, 2018 5:22 PM, "Burak Serdar"  wrote:

> On Tue, Mar 6, 2018 at 2:58 PM, Bharath Ram 
> wrote:
> > In that case, for a nested struct from top to bottom, all the values are
> > copies as values, correct? i.e, string, int, float, array etc will be
> copied
> > by value & map, slice, channel etc will be copied as pointers if they are
> > initialized?
> >
> > https://play.golang.org/p/NzH8LVyQ0rp code works as I wanted. Generally,
> > what practice should I follow? If I want a shared variable, should I
> have to
> > keep all the variables as pointers like in the example
> > (https://play.golang.org/p/NzH8LVyQ0rp) or like the way I showed
> earlier?
>
> It depends on the case. What exactly do you want to do? I find dealing
> with the semantics of copies of structures harder to comprehend, so I
> try to avoid it when the structure has reference types, but sometimes
> it is really useful. For instance, if the structure will be used as
> read-only and has a reasonable size, a copy of it is just fine. In my
> opinion, the only general rule is that you have to know how the data
> is organized and that you know what you're doing.
>
> >
> > On Tuesday, March 6, 2018 at 3:40:47 PM UTC-5, Burak Serdar wrote:
> >>
> >> On Tue, Mar 6, 2018 at 1:23 PM,   wrote:
> >> > go version 1.10
> >> >
> >> >
> >> > Operating system and processor architecture
> >> >
> >> > GOHOSTARCH="amd64"
> >> > GOHOSTOS="darwin"
> >> > However, this happens in play.golang.org env as well.
> >> >
> >> >
> >> > Checkout the code.
> >> >
> >> > https://play.golang.org/p/v6u7R_nbGRp
> >>
> >> doc1 := Document{}
> >>  // Here, doc1.Data is nil
> >>
> >> ds := DataStore{Doc: doc1}
> >>  // Here, ds.Doc has a copy of doc1, and ds.Doc.Data is nil
> >>
> >> ds.Doc.Data = DocData{}
> >>  // Here, ds.Doc.Data is initialized, but not doc1.Data, because
> >> ds.Doc is a copy of doc1
> >>
> >>
> >> On the other hand:
> >>
> >> doc2 := Document{Data: DocData{}}
> >> // Here, doc2.Data is initialized to an empty map
> >>   ds2 := DataStore{Doc: doc2}
> >> // And here, ds2.Doc is a copy of doc2, which contains a reference to
> >> that empty map. The underlying maps are shared.
> >>
> >>
> >>
> >> >
> >> >
> >> > In the example, if the struct (Document) is not initialized at first,
> >> > there
> >> > is no place holder for future values pointing to same object. Is this
> >> > intended?
> >> >
> >> > --
> >> > 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] Pass by value in struct not yielding expected result

[Bharath Ram]

In that case, for a nested struct from top to bottom, all the values are 
copies as values, correct? i.e, string, int, float, array etc will be 
copied by value & map, slice, channel etc will be copied as pointers if 
they are initialized? 

https://play.golang.org/p/NzH8LVyQ0rp code works as I wanted. Generally, 
what practice should I follow? If I want a shared variable, should I have 
to keep all the variables as pointers like in the example 
(https://play.golang.org/p/NzH8LVyQ0rp) or like the way I showed earlier?

On Tuesday, March 6, 2018 at 3:40:47 PM UTC-5, Burak Serdar wrote:
>
> On Tue, Mar 6, 2018 at 1:23 PM,   
> wrote: 
> > go version 1.10 
> > 
> > 
> > Operating system and processor architecture 
> > 
> > GOHOSTARCH="amd64" 
> > GOHOSTOS="darwin" 
> > However, this happens in play.golang.org env as well. 
> > 
> > 
> > Checkout the code. 
> > 
> > https://play.golang.org/p/v6u7R_nbGRp 
>
> doc1 := Document{} 
>  // Here, doc1.Data is nil 
>
> ds := DataStore{Doc: doc1} 
>  // Here, ds.Doc has a copy of doc1, and ds.Doc.Data is nil 
>
> ds.Doc.Data = DocData{} 
>  // Here, ds.Doc.Data is initialized, but not doc1.Data, because 
> ds.Doc is a copy of doc1 
>
>
> On the other hand: 
>
> doc2 := Document{Data: DocData{}} 
> // Here, doc2.Data is initialized to an empty map 
>   ds2 := DataStore{Doc: doc2} 
> // And here, ds2.Doc is a copy of doc2, which contains a reference to 
> that empty map. The underlying maps are shared. 
>
>
>
> > 
> > 
> > In the example, if the struct (Document) is not initialized at first, 
> there 
> > is no place holder for future values pointing to same object. Is this 
> > intended? 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [go-nuts] Pass by value in struct not yielding expected result

[Dave Cheney]

On Wednesday, 7 March 2018 07:39:56 UTC+11, andrey mirtchovski wrote:
>
> maybe this will give you a hint: https://play.golang.org/p/ANIjc3tCdwp 
>
> maps are reference types, but they still get passed by value.
>

Maps are pointers, pointers are values. 

-- 
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] Pass by value in struct not yielding expected result

[Burak Serdar]

On Tue, Mar 6, 2018 at 1:23 PM,   wrote:
> go version 1.10
>
>
> Operating system and processor architecture
>
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> However, this happens in play.golang.org env as well.
>
>
> Checkout the code.
>
> https://play.golang.org/p/v6u7R_nbGRp

doc1 := Document{}
 // Here, doc1.Data is nil

ds := DataStore{Doc: doc1}
 // Here, ds.Doc has a copy of doc1, and ds.Doc.Data is nil

ds.Doc.Data = DocData{}
 // Here, ds.Doc.Data is initialized, but not doc1.Data, because
ds.Doc is a copy of doc1


On the other hand:

doc2 := Document{Data: DocData{}}
// Here, doc2.Data is initialized to an empty map
  ds2 := DataStore{Doc: doc2}
// And here, ds2.Doc is a copy of doc2, which contains a reference to
that empty map. The underlying maps are shared.



>
>
> In the example, if the struct (Document) is not initialized at first, there
> is no place holder for future values pointing to same object. Is this
> intended?
>
> --
> 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] Pass by value in struct not yielding expected result

[andrey mirtchovski]

maybe this will give you a hint: https://play.golang.org/p/ANIjc3tCdwp

maps are reference types, but they still get passed by value. if you
pass a nil map around, the old value you passed will not magically
start pointing to a new map once you instantiate it elsewhere.

-- 
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] Pass by value in struct not yielding expected result

[bharathramh92]

go version 1.10
Operating system and processor architecture

GOHOSTARCH="amd64"
GOHOSTOS="darwin"
However, this happens in play.golang.org env as well.


Checkout the code.

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


In the example, if the struct (Document) is not initialized at first, there 
is no place holder for future values pointing to same object. Is this 
intended?

-- 
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] JOB : GoLang Programmer : Waltham, MA

[Hemanth]

Hi

 

I found your skills relevant to this role with my client. Please let me know
your interest along with updated resume. 

w  Share & Spread word about this opening with someone you like. 

 

Position : GoLang Programmer

Location : Waltham, MA

Duration : 6+ months Contract

 

.Must have Strong Go Lang

.Must have good C Language Background

.Must have worked in Linux Environment

.Must have some experience in AWS

.The Database they are using is Postgres DB

 

 

Thank you,

Hemanth

Direct Number - (201) 256 6703 | VajraSoft LLC | An e-verified, MBE
certified corporation

-- 
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] High precision timer data?

[James Chacon]

I have a hard time believing that will have anywhere near < 100ns
granularity considering time.Sleep has microsecond only in testing.

James


On Mon, Mar 5, 2018 at 5:00 AM, Frederic Landais  wrote:

> Hello,
>
> have you considered using time.NewTicker
>  ?
>
> Check the best answer of https://stackoverflow.com/
> questions/16466320/is-there-a-way-to-do-repetitive-tasks-at-
> intervals-in-golang for an example
>
> Frederic
>
> --
> 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: Compare values in a for loop that ranges over string array of array

[timilsina . ashish . 03]

Awesome, that makes so much sense. Thanks for explaining it and your help!

On Monday, March 5, 2018 at 4:03:33 PM UTC-7, Ignacio Gómez wrote:
>
> Hi, Ashish.
>
> If you have a map[string]int (or int 64, float 64, etc.) "m", doing
>
> m[key] += value
>
>
> is equivalent to this:
>
> m[key] = m[key] + value.
>
>
> Thus, on each iteration we sum the value at dataarray[j][1] (which you 
> stored at sumFloat) to the current value of sums[dataarray[j][0]] (on first 
> iteration, it just gets initialized to the zero value, in this case 0.0) in 
> order to sum values among the same letter, which are used as keys for the 
> map. So, in short, yes, that's accurate. Take a look at this to get some 
> more info on maps: https://blog.golang.org/go-maps-in-action
>
> El lunes, 5 de marzo de 2018, 18:35:11 (UTC-3), Ashish Timilsina escribió:
>>
>> Hi Ignacio,
>>
>> This is excellent, works perfectly. Thank you so much. 
>> I will try to do my research but just out of curiosity and make sure I 
>> understand the code, what does this line do? I also don't have proper 
>> understanding of golang maps 
>> sums[dataarray[j][0]] += sumFloat
>>
>>
>> So 'sum' map is taking the first index in dataarray as key, summing the 
>> second index and assigning it as the value to the key. As it is looping 
>> through the array, if it sees that the key is the same, it automatically 
>> sums it up? Is that accurate?
>>
>

-- 
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: best practices of client middleware

[Eyal Posener]

Good stuff,
So I see that this library wraps the http.Client and doesn't use the 
roundtripper.
Pretty elegant!

I still have two questions about the standard library:

   - Didn't understand yet why it is not allowed to add headers in the 
   roundtripper.
   - Is this a bit strange that the standard library provides a beautiful 
   way to have server middleware, but no way to have client middlewares?
   
Cheers,
Eyal

On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote:
>
> As far as I am aware, there is very little information about best 
> practices regarding client side middlewares. 
>
> I though that having such support is neat idea and I have implemented 
> something (that I use for some time now, though still in beta) that you 
> might find useful for your use case. I have written small library that 
> describes client middleware protocol , 
> some useful middlewares  
> and HTTP client  that's using these 
> libraries. 
>
> This might solve your problem directly (writing new middleware is 
> trivial), but it might introduce dependency that you don't want, so I hope 
> this will provide inspiration on how you would do something similar 
> yourself. 
>
> On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote:
>>
>> Hi
>>
>> I want to implement a client middleware - for example: sign the request 
>> body and add the signature as an HTTP header.
>> I thought that the best way to do it is to implement a RoundTripper 
>> interface  which up on 
>> request, calculate the signature, adds the header, and invoke a "next" 
>> ToundTripper.
>>
>> This could be a very generic implementation, which i can inject to any 
>> client that uses the standard library http.Client.
>>
>> However, I found the following in the doc:
>>
>> // RoundTrip should not modify the request, except for
>> // consuming and closing the Request's Body. RoundTrip may
>> // read fields of the request in a separate goroutine. Callers
>> // should not mutate the request until the Response's Body has
>> // been closed.
>>
>>
>> Is there a standard way to do it?
>>
>> Thanks,
>> Eyal
>>
>

-- 
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: confusing differences in reflect Type knowledge for a receiver vs. an argument

[Ian Lance Taylor]

On Mon, Mar 5, 2018 at 9:53 PM, Randall O'Reilly  wrote:
> On Mar 5, 2018, at 10:32 PM, Ian Lance Taylor  wrote:
>>
>> Go doesn't have anything like inheritance in C++.  What you are
>> calling the "true underlying type" simply doesn't exist in Go.  Go has
>> embedded fields, and methods of embedded fields are promoted to become
>> methods of the outer type in which they are embedded.  But the outer
>> type does not inherit anything from the inner type, at least not if
>> you are using the word "inherit" in the sense that it is used in C++.
>> The promoted methods are still methods on the inner type, they are
>> just accessible directly from the outer type.
>>
>> I think it's generally best to approach these problems in terms of how
>> Go works, rather than trying to recreate C++ approaches in Go.  Go
>> doesn't work the way that C++ does.
>>
>> Ian
>
> So why then does reflect.TypeOf(obj) return the “Outer” type in the example 
> code I posted, here:
>
> func ArgFun(in InType) {
> typ := reflect.TypeOf(in).Elem()
> fmt.Printf("ArgFun on in tells the truth: %v\n", typ.Name())
> }
>
> https://play.golang.org/p/KmihXxU19Dd

Because that isn't a call of a promoted method.  That's examining the
dynamic type of an interface value.


> Per the discussion here: https://github.com/golang/go/issues/22013 — it seems 
> like Go is rather unclear about exactly what level of C++-like inheritance it 
> wants to support.  I don’t want to recreate any of that discussion here, but 
> I’ll just add a tiny vote for at least keeping the notion of embedding as it 
> is — don’t throw the baby out with the bathwater!  The presence of interfaces 
> and the compositional model in Go is TONS better than C++’s rigid inheritance 
> constraints, but sometimes a simple inherit-and-extend model is just the 
> right thing, and it seems like it doesn’t add that much additional complexity 
> to support it.  Maybe just need to add a bit of relevant docs in places to 
> resolve residual confusions, such as the one I encountered.  Thanks for all 
> your hard work on creating this awesome language!

I want to repeat that Go doesn't support any sort of C++-like
inheritance at all.

In C++, declaring one class as a child of another class (class child :
parent) is both a subtyping relationship and an inheritance
relationship.  In Go those notions are separate.  In Go embedded
fields provide an inheritance relationship: the child object--the one
with the embedded field--acquires the behavior of the parent object.
But Go's embedded fields are not a subtyping relationship: the child
object can not be used in place of the parent object, as it can in
C++.  In Go, subtyping is expressed using interface types.  A type
that implements an interface can be considered a subtype of that
interface--the implementing type can be used anywhere the interface
type can be used--although there is no inheritance relationship.

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] Re: What's everyone using as an asset pipeline?

[levko]

The go-assets package looks like it might be what you're interested in. 
It has many features and different handlers. 

https://github.com/burburas/go-assets

On Friday, December 6, 2013 at 6:15:47 AM UTC+2, Alex Zorin wrote:
>
> Lots of web frameworks out there but we seem to be lacking in the asset 
> compilation/minification/concatenation department.  
>
> Anybody working on a middleware that deals with this? I've played a little 
> with https://github.com/jim/monk, but I've yet to decipher whether it 
> works or how far it has to go.
>
> Ideas/suggestions/desires very welcome.
>
> Alex
>

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