[go-nuts] Re: How example can be run in test?
I got it. In my case, there was only Example func. When adding something Testxxx func, it worked well. 2016年9月17日土曜日 6時52分30秒 UTC+9 James Bardin: > > This is fixed in master. In go1.7 the Examples and Benchmarks aren't run > if there are no Test functions. -- 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 deal with "Expect: 100-continue" *without* sending a 100 status
Tricky one. A couple of options spring to mind, none of them amazingly good: - Use a GCE Network LB instead of HTTP LB. You can bring the TCP sessions straight to your web servers, with load-balancing done per-TCP-session rather than per-HTTP-request. - Build your web server using a modified Go stdlib codebase that removes this conditional block: https://golang.org/src/net/http/server.go#L1562 . If you do this, I suggest also filing a bug against Go to evaluate whether "don't do automatic Continue support" should be added as a Server knob. - Stick the Go web servers behind a non-Go proxy layer (e.g. nginx) that strips out the "Expect: 100-continue" header before forwarding to the Go server. Run one nginx per Go server, on the same machines (or in the same Kubernetes pods if using GKE), so that the system properties look the same from the POV of the upstream load-balancer (same number of backends, same arrangement...). - Wait for GCE to support 100-Continue. Given that 100-Continue is almost non-existent on the web, personally I wouldn't hold my breath, I suspect it's a low-priority item. - You say your clients can't be modified... Can't they? I've never heard of browsers using 100-Continue unprompted, so if it is just chrome/firefox/IE, what are you doing that's causing them to use 100-Continue? Or are they some other client software like Mercurial? - Dave On Fri, Sep 16, 2016 at 10:00 AM, Ian Rose wrote: > Howdy, > > I'm currently running a group of Go web servers behind an HTTP(s) load > balancer on Google Compute Engine. Unfortunately I have learned that GCE > load balancers do not support the "Expect: 100-continue" header [1]. From > my experiments, it appears that it isn't actually the request header that > causes the problem, but instead is the server's "100 Continue" response > that the load balancer dies on. Specifically, the load balancer responds > with a 502 to the client. > > Any suggestions on how to deal with this? We don't control our clients > (they are just "browsers across the internet") so solving things on that > side isn't possible. After digging through the net/http code a bit, my > best thought is to hijack the connection, which (I think) will prevent a > "100 Continue" status from being sent. I'm concerned, however, that this > won't work in all cases - for example http2 connections are not hijackable ( > https://github.com/golang/go/issues/15312). > > Is there a better path forward? > > Thanks, > Ian > > [1] https://code.google.com/p/google-compute-engine/issues/detail?id=298 > (also see "notes and restrictions" here: https://cloud.google. > com/compute/docs/load-balancing/http/) > > -- > 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] differences between pointer and value slice in for-range loop
Hi:
Please check this code snippet:
package main
import (
"fmt"
"time"
)
type field struct {
name string
}
func (p *field) print() {
fmt.Println(p.name)
}
func main() {
fmt.Println("use values:")
// use values in range loop and go rountines
values := []field{{"one"},{"two"},{"three"}}
for _, v := range values {
go v.print()
}
time.Sleep(time.Second)
fmt.Println()
fmt.Println("use pointers:")
// use pointers in range loop and go rountines
poniters := []*field{{"one"},{"two"},{"three"}}
for _, v := range poniters {
go v.print()
}
time.Sleep(time.Second)
}
Link here: https://play.golang.org/p/cdryPmyWt5
The code above is going to check the differences between pointers and
values in a for loop, while go statement is also used at the same time. For
code:
values := []field{{"one"},{"two"},{"three"}}
for _, v := range values {
go v.print()
}
we know that the console will print *three three three* as result, because
for loop runs into its end before go routines start executing, which write
*v* as the last element of the slice. But what about pointers?
poniters := []*field{{"one"},{"two"},{"three"}}
for _, v := range poniters {
go v.print()
}
It seems to print* one two three*, why?
Thanks.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why + and += operators for string but not slices?
On 17 Sep 2016 12:31 p.m., wrote: > > Context enables homonyms in spoken languages and overloaded or polymorphic notation in mathematics. Types do the same in programming languages. The rationale for + over join() or cat() for string is equally applicable to slices. 1+1 give you a new number that doesn't modify the original numbers being added. This is the expected way addition works. In Go this also works for strings, "a"+"b" gives you "ab" and the original strings are unmodified. For slices this is different, two slices can refer to the same backing array so slice1 + slice2 could either allocate a new slice and copy both slices in to it, or it could modify slice1 by appending slice2. If slice1 and slice2 refer to the same backing array, their addition could change both of the original values, this addition can also effect slice3 that happens to also reference the same backing array. append() isn't addition because of these properties. -- 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: Why + and += operators for string but not slices?
Context enables homonyms in spoken languages and overloaded or polymorphic
notation in mathematics. Types do the same in programming languages. The
rationale for + over join() or cat() for string is equally applicable to
slices. a ++ b wouldn't be an unreasonable replacement for append(a, b...)
and append([]T, ...T) can stay as is but who needs it when you have []T ++
[]T{...T}
On Saturday, September 17, 2016 at 12:31:31 AM UTC+1, parais...@gmail.com
wrote:
>
> Because Go creators have a strong opinion about what + means. I would
> argue the languages that engage into these sort of things especially those
> who allow operator overloading are antithetic to Go goals, but that's an
> opinion., I didn't create Go, I don't agree with all its design choices but
> understand why they were made. Go is only sophisticated in the way it
> handles concurrency.
>
> Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit :
>>
>> I have not been able to find an explanation. Does anyone care to explain
>> or point to relevant documentation?
>>
>
--
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: Why + and += operators for string but not slices?
Because Go creators have a strong opinion about what + means. I would argue the languages that engage into these sort of things especially those who allow operator overloading are antithetic to Go goals, but that's an opinion., I didn't create Go, I don't agree with all its design choices but understand why they were made. Go is only sophisticated in the way it handles concurrency. Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit : > > I have not been able to find an explanation. Does anyone care to explain > or point to relevant documentation? > -- 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: Why + and += operators for string but not slices?
The thread already shows several alternative interpretations which are different from that. Go tries to avoid constructions that require careful specification of that sort. Append already causes enough confusion, but that's important enough that dropping it would be a loss. + for slices is only syntactic sugar. Thomas On Fri, Sep 16, 2016 at 3:09 PM wrote: > The semantics of + and append() preclude a "data aliasing" ambiguity. > Consider: > > c = a + b > > and > > c = append(a, b...) > > > > On Friday, September 16, 2016 at 9:14:45 PM UTC+1, Thomas Bushnell, BSG > wrote: > > The values of the summation are indeed unambiguous, but the data aliasing > properties are not. > > On Fri, Sep 16, 2016, 12:58 PM wrote: > > Thank you both. > > To Ian: but a slice is not a matrix or a list. > > To Axel: append() and copy() compliment indexing and slicing well enough. > > It would be a shame if ambiguity is indeed the reason. We've accepted 1 + > 1 as numeric addition and "a" + "b" as string concatenation. For a slice, > perceived as a window on a string of elements, concatenation is > unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z] > > > > > > > > On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote: > > I have not been able to find an explanation. Does anyone care to explain > or point to relevant documentation? > > -- > 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] Re: Why + and += operators for string but not slices?
The semantics of + and append() preclude a "data aliasing" ambiguity. Consider: c = a + b and c = append(a, b...) On Friday, September 16, 2016 at 9:14:45 PM UTC+1, Thomas Bushnell, BSG wrote: > > The values of the summation are indeed unambiguous, but the data aliasing > properties are not. > > On Fri, Sep 16, 2016, 12:58 PM > wrote: > >> Thank you both. >> >> To Ian: but a slice is not a matrix or a list. >> >> To Axel: append() and copy() compliment indexing and slicing well enough. >> >> It would be a shame if ambiguity is indeed the reason. We've accepted 1 + >> 1 as numeric addition and "a" + "b" as string concatenation. For a slice, >> perceived as a window on a string of elements, concatenation is >> unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z] >> >> >> >> >> >> >> >> On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com >> wrote: >>> >>> I have not been able to find an explanation. Does anyone care to explain >>> or point to relevant documentation? >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] How example can be run in test?
This is fixed in master. In go1.7 the Examples and Benchmarks aren't run if there are no Test functions. -- 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: Why + and += operators for string but not slices?
The values of the summation are indeed unambiguous, but the data aliasing properties are not. On Fri, Sep 16, 2016, 12:58 PM wrote: > Thank you both. > > To Ian: but a slice is not a matrix or a list. > > To Axel: append() and copy() compliment indexing and slicing well enough. > > It would be a shame if ambiguity is indeed the reason. We've accepted 1 + > 1 as numeric addition and "a" + "b" as string concatenation. For a slice, > perceived as a window on a string of elements, concatenation is > unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z] > > > > > > > > On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote: > > I have not been able to find an explanation. Does anyone care to explain > or point to relevant documentation? > > -- > 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: Why + and += operators for string but not slices?
Thank you both. To Ian: but a slice is not a matrix or a list. To Axel: append() and copy() compliment indexing and slicing well enough. It would be a shame if ambiguity is indeed the reason. We've accepted 1 + 1 as numeric addition and "a" + "b" as string concatenation. For a slice, perceived as a window on a string of elements, concatenation is unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z] On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote: > > I have not been able to find an explanation. Does anyone care to explain > or point to relevant documentation? > -- 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] Need explain on error inteface work?
got it, thank you.
On Saturday, September 17, 2016 at 12:14:34 AM UTC+7, Ian Lance Taylor
wrote:
>
> On Fri, Sep 16, 2016 at 8:24 AM, Giang Tran > wrote:
> >
> > I have a small test like this
> >
> > package main
> >
> > type MError struct {
> >
> > }
> >
> > func (m *MError) Error() string {
> > return "MError"
> > }
> >
> > func NewMError() *MError {
> > return nil
> > }
> >
> > func main() {
> > var e error
> > e = NewMError()
> > println(e.Error())
> > }
> >
> >
> >
> > I know that interface actually combine like (Type, value), if I change
> >
> >
> > func (m *MError) Error() string {
> >
> >
> > to
> >
> >
> > func (m MError) Error() string {
> >
> >
> > would lead to "panic: value method main.MError.Error called using nil
> > *MError pointer",
> >
> > why we have this different behave?
>
> When you have a pointer, and call a value method, what that means is
> that the value is copied out of the pointer and then the method is
> invoked. That is, when you write e.Error(), where e is type *MError
> and Error is a value method, the actual code is something like
> tmp := *e
> tmp.Error()
> But in this case e is nil, so copying out the value fails, and you get a
> panic.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Why + and += operators for string but not slices?
I would take it to mean
c := make(elementof(a), len(a)+len(b))
copy(c, a)
copy(c[len(a):], b)
which is subtly different from append(a, b...). And when you don't care
about the difference, it would be less efficient. For strings, on the other
hand, it can only mean one of the two (as strings are immutable, there is
no append).
So even if you discount the elementwise add, it would still be ambiguous.
On Fri, Sep 16, 2016 at 7:33 PM, Ian Lance Taylor wrote:
> On Fri, Sep 16, 2016 at 9:02 AM, wrote:
> > I have not been able to find an explanation. Does anyone care to explain
> or
> > point to relevant documentation?
>
> Slices are not strings. I think that a + b has an intuitively clear
> value when a and b are strings. I do not think it does when a and b
> are slices. You would presumably suggest that it means the same as
> append(a, b...) but I think it could also mean
> c := make(elementof(a), len(a))
> for i, v := range a {
> c[i] = v + b[i]
> }
>
> Given the lack of clear meaning for addition of slices, the language
> omits it. Instead, it provides append and loops.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Why + and += operators for string but not slices?
On Fri, Sep 16, 2016 at 9:02 AM, wrote:
> I have not been able to find an explanation. Does anyone care to explain or
> point to relevant documentation?
Slices are not strings. I think that a + b has an intuitively clear
value when a and b are strings. I do not think it does when a and b
are slices. You would presumably suggest that it means the same as
append(a, b...) but I think it could also mean
c := make(elementof(a), len(a))
for i, v := range a {
c[i] = v + b[i]
}
Given the lack of clear meaning for addition of slices, the language
omits it. Instead, it provides append and loops.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Need explain on error inteface work?
On Fri, Sep 16, 2016 at 8:24 AM, Giang Tran wrote:
>
> I have a small test like this
>
> package main
>
> type MError struct {
>
> }
>
> func (m *MError) Error() string {
> return "MError"
> }
>
> func NewMError() *MError {
> return nil
> }
>
> func main() {
> var e error
> e = NewMError()
> println(e.Error())
> }
>
>
>
> I know that interface actually combine like (Type, value), if I change
>
>
> func (m *MError) Error() string {
>
>
> to
>
>
> func (m MError) Error() string {
>
>
> would lead to "panic: value method main.MError.Error called using nil
> *MError pointer",
>
> why we have this different behave?
When you have a pointer, and call a value method, what that means is
that the value is copied out of the pointer and then the method is
invoked. That is, when you write e.Error(), where e is type *MError
and Error is a value method, the actual code is something like
tmp := *e
tmp.Error()
But in this case e is nil, so copying out the value fails, and you get a panic.
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: How example can be run in test?
you are using the testing framework incorrectly-
https://golang.org/pkg/testing/
your function is incompatible with the test harness. The function signature
must follow a few rules.
Your test file does not have any functions matching the required signature.
What you are doing is running an example. The test harness ran your
function with no problems so you got no output.
// This Example function fails in the test harness as the fmt.Println
output does not match the expected output conveyed within the Output tag.
The test harness throws a fit.
func ExampleMethod1 ( ) {
fmt.Println("hi")
// Output: hello
}
// This Example function passes in the test harness as the fmt.Println
output does match the expected output conveyed within the Output tag. The
test harness is silent.
func ExampleMethod1 ( ) {
fmt.Println("hi")
// Output: hi
}
On Monday, September 12, 2016 at 7:46:24 PM UTC-4, Harry wrote:
>
> Hi there,
>
> I'm trying to run example in test.
> However after running, warning is shown.
> ```
> testing: warning: no tests to run
> ```
>
> This example code include // Output comment.
>
> ```
> func ExampleMethod1() {
> fmt.Printf("result: %x", Method1())
> // Output:
> }
> ```
>
> What is wrong? When running test, I exec like this.
>
> ```go test -v _test.go```
>
>
> Thanks.
>
> Harry
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] How to deal with "Expect: 100-continue" *without* sending a 100 status
Howdy, I'm currently running a group of Go web servers behind an HTTP(s) load balancer on Google Compute Engine. Unfortunately I have learned that GCE load balancers do not support the "Expect: 100-continue" header [1]. From my experiments, it appears that it isn't actually the request header that causes the problem, but instead is the server's "100 Continue" response that the load balancer dies on. Specifically, the load balancer responds with a 502 to the client. Any suggestions on how to deal with this? We don't control our clients (they are just "browsers across the internet") so solving things on that side isn't possible. After digging through the net/http code a bit, my best thought is to hijack the connection, which (I think) will prevent a "100 Continue" status from being sent. I'm concerned, however, that this won't work in all cases - for example http2 connections are not hijackable (https://github.com/golang/go/issues/15312). Is there a better path forward? Thanks, Ian [1] https://code.google.com/p/google-compute-engine/issues/detail?id=298 (also see "notes and restrictions" here: https://cloud.google.com/compute/docs/load-balancing/http/) -- 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] Why + and += operators for string but not slices?
I have not been able to find an explanation. Does anyone care to explain or point to relevant documentation? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Is it possible to serve a directory without indexing the contents?
Thanks Rodrigo.
When you suggested rewriting the FileSystem I re-implemented
src/net/http/fs.go and it seems the offender is in the serveFile function:
if d.IsDir() {
if checkLastModified(w, r, d.ModTime()) {
return
}
//dirList(w, f) <-here
return
}
This seems to be working. I will try your suggestion and see which seems to
be easier.
Thanks again,
toby
On Thursday, September 15, 2016 at 4:40:46 PM UTC-4, tobyjaguar wrote:
>
> Is possible to serve a directory, http.FileServer(http.Dir(".")), without
> listing the directory contents of that directory by navigating one folder
> above it in the browser?
>
> http.Handle("/img/", http.FileServer(http.Dir("static")))
>
> https://groups.google.com/d/optout.
[go-nuts] [ANN] go-scp: a scp client library in go
Hi all, I noticed the golang.org/x/crypto/ssh package exists, but the scp package does not. So I wrote a scp client library in go. https://github.com/hnakamur/go-scp I also wrote a sshd server just usable for testing go-scp. https://github.com/hnakamur/go-sshd Right now, go-scp only exports high level functions which are supposed to be easy to use. https://godoc.org/github.com/hnakamur/go-scp However I wonder if there APIs can be improved. For example, better function names and better arguments. Could you tell me what you think? Thanks! Hiroaki Nakamura -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Is it possible to serve a directory without indexing the contents?
Oh, my bad. I've updated the example to properly reference the embedded fs'
Open.
https://play.golang.org/p/wbfrElxCsH
On Thu, Sep 15, 2016 at 8:09 PM tobyjaguar wrote:
> Rodrigo, I may need a bit more help with your example.
> Can you get me past the Open function, when playing with the example it
> seems to get stuck here:
>
> func (fs filesOnlyFS) Open(name string) (http.File, error) {
> f, err := fs.Open(name)
>
> Is this a recursive call?..doesn't seem to get past this when this
> function gets called, and I'm not seeing where it would return the file and
> the error.
>
> thank you
>
>
> On Thursday, September 15, 2016 at 4:40:46 PM UTC-4, tobyjaguar wrote:
>>
>> Is possible to serve a directory, http.FileServer(http.Dir(".")), without
>> listing the directory contents of that directory by navigating one folder
>> above it in the browser?
>>
>> http.Handle("/img/", http.FileServer(http.Dir("static")))
>>
>> 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] Need explain on error inteface work?
Hello
I have a small test like this
package main
type MError struct {
}
func (m *MError) Error() string {
return "MError"
}
func NewMError() *MError {
return nil
}
func main() {
var e error
e = NewMError()
println(e.Error())
}
I know that interface actually combine like (Type, value), if I change
func (m *MError) Error() string {
to
func (m MError) Error() string {
would lead to "panic: value method main.MError.Error called using nil *MError
pointer",
why we have this different behave?
--
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: Parsing ambiguity?
On Fri, Sep 16, 2016 at 4:13 PM adonovan via golang-nuts < golang-nuts@googlegroups.com> wrote: > The grammar is indeed ambiguous, but the ambiguity is (implicitly) resolved by favoring the leftmost derivation, which is what you get from an LL(k) parser. By the same token (hah!), the grammar expresses that unary operations have higher precedence than binary ones. For example, -x + y is parsed as (-x)+y, not -(x+y). If you want a derivation other than the leftmost one, you need to use parentheses. Thank you as well. This information is valuable for fixing the issue. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] filtering and forwarding email?
could you recommend a good POP3 library? Best regards, Ty On Friday, September 16, 2016 at 10:16:39 AM UTC-4, Shawn Milochik wrote: > > Sure, all you need is the ability to send and receive e-mail. Then you > write your filtering logic. > > https://github.com/go-gomail/gomail > > This will take care of the heavy lifting. > -- 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] Regex questions: flags & match from start of string
On Fri, Sep 16, 2016 at 7:00 AM, Scott Frazer wrote: > I'm struggling a lot here... I want to be able to pass flags to my regexps > (specifically the flag where dot matches any character). The only mention > of flags at all is here: https://golang.org/pkg/regexp/syntax/#Parse. > Though this API is strange and confusing. I'm not sure what exactly to do > with a syntax.Regexp. Seems I can turn it into a syntax.Prog, but I'm very > unclear about what to do with that object. > > Also, is there a way to say "match this regex anchored to the beginning of > the string" without pre-pending the '^' character to all of my regexp's? Don't worry about the regexp/syntax package. You shouldn't use it. If we could hide it without breaking the Go 1 contract, we would. Specify flags by putting "(?flags)" at the start of your regexp. I don't know of a way to anchor a regexp other than using ^. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] filtering and forwarding email?
Sure, all you need is the ability to send and receive e-mail. Then you write your filtering logic. https://github.com/go-gomail/gomail This will take care of the heavy lifting. -- 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] Parsing ambiguity?
On Fri, Sep 16, 2016 at 4:02 PM Ian Lance Taylor wrote: > The rule you are looking for is at https://golang.org/ref/spec#Conversions : "If the type starts with the operator * or <-, or if the type starts with the keyword func and has no result list, it must be parenthesized when necessary to avoid ambiguity." Thank you very much. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Parsing ambiguity?
On Friday, 16 September 2016 06:43:38 UTC-4, Jan Mercl wrote: > > Which rule selects the first parse? Can anybody please enlighten me? > Thanks in advance. > The grammar is indeed ambiguous, but the ambiguity is (implicitly) resolved by favoring the leftmost derivation, which is what you get from an LL(k) parser. By the same token (hah!), the grammar expresses that unary operations have higher precedence than binary ones. For example, -x + y is parsed as (-x)+y, not -(x+y). If you want a derivation other than the leftmost one, you need to use parentheses. -- 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] Regex questions: flags & match from start of string
I'm struggling a lot here... I want to be able to pass flags to my regexps (specifically the flag where dot matches any character). The only mention of flags at all is here: https://golang.org/pkg/regexp/syntax/#Parse. Though this API is strange and confusing. I'm not sure what exactly to do with a syntax.Regexp. Seems I can turn it into a syntax.Prog, but I'm very unclear about what to do with that object. Also, is there a way to say "match this regex anchored to the beginning of the string" without pre-pending the '^' character to all of my regexp's? Thanks, Scott -- 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] Parsing ambiguity?
On Fri, Sep 16, 2016 at 3:42 AM, Jan Mercl <0xj...@gmail.com> wrote:
> Consider this program (https://play.golang.org/p/V0fu9rD8_D)
>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> c := make(chan int, 1)
> c <- 1
> d := <-chan int(c)
> fmt.Printf("%T\n", d)
> e := (<-chan int)(c)
> fmt.Printf("%T\n", e)
> }
>
> Its output is
>
> int
> <-chan int
>
> Intuitively it seems ok (and I believe the output is correct). Let's look
> closer on the RHS expression of line
>
> d := <-chan int(c)
>
> From the specs:
>
> Expression = UnaryExpr | Expression binary_op Expression .
> UnaryExpr = PrimaryExpr | unary_op UnaryExpr .
> unary_op = "+" | "-" | "!" | "^" | "*" | "&" | "<-" .
> PrimaryExpr = Operand | Conversion | PrimaryExpr Selector | PrimaryExpr
> Index | PrimaryExpr Slice | PrimaryExpr TypeAssertion | PrimaryExpr
> Arguments .
> Conversion = Type "(" Expression [ "," ] ")" .
> Type = TypeName | TypeLit | "(" Type ")" .
> TypeLit = ArrayType | StructType | PointerType | FunctionType |
> InterfaceType | SliceType | MapType | ChannelType .
> ChannelType = ( "chan" | "chan" "<-" | "<-" "chan" ) ElementType .
>
> It seems to me that parsing `<-chan int(c)` as
>
> a receive operation from a conversion of `c` to type `chan int`
>
> is as valid as parsing it as
>
> a conversion of `c` to type `<-chan int`.
>
> In the later case the program would output
>
> <-chan int
> <-chan int
>
> I must be missing something. Which rule selects the first parse? Can anybody
> please enlighten me? Thanks in advance.
The rule you are looking for is at
https://golang.org/ref/spec#Conversions : "If the type starts with the
operator * or <-, or if the type starts with the keyword func and has
no result list, it must be parenthesized when necessary to avoid
ambiguity."
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] filtering and forwarding email?
Are there any email projects in Go that can act as a email filter where the client would pull email down from the an account and based upon some rules forward the email. Best regards, Ty -- 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] Parsing ambiguity?
Consider this program (https://play.golang.org/p/V0fu9rD8_D)
package main
import (
"fmt"
)
func main() {
c := make(chan int, 1)
c <- 1
d := <-chan int(c)
fmt.Printf("%T\n", d)
e := (<-chan int)(c)
fmt.Printf("%T\n", e)
}
Its output is
int
<-chan int
Intuitively it seems ok (and I believe the output is correct). Let's look
closer on the RHS expression of line
d := <-chan int(c)
>From the specs:
Expression = UnaryExpr
| Expression
binary_op
Expression
.
UnaryExpr = PrimaryExpr
| unary_op
UnaryExpr
.
unary_op = "+" | "-" | "!" | "^" |
"*" | "&" | "<-" .
PrimaryExpr = Operand
| Conversion
| PrimaryExpr
Selector
| PrimaryExpr
Index
| PrimaryExpr
Slice
| PrimaryExpr
TypeAssertion
| PrimaryExpr
Arguments
.
Conversion = Type
"(" Expression
[ "," ] ")" .
Type = TypeName
| TypeLit
| "(" Type
")" .
TypeLit = ArrayType
| StructType
| PointerType
| FunctionType
| InterfaceType
| SliceType
| MapType
| ChannelType
.
ChannelType = ( "chan" | "chan"
"<-" | "<-" "chan" ) ElementType .
It seems to me that parsing `<-chan int(c)` as
a receive operation from a conversion of `c` to type `chan int`
is as valid as parsing it as
a conversion of `c` to type `<-chan int`.
In the later case the program would output
<-chan int
<-chan int
I must be missing something. Which rule selects the first parse? Can
anybody please enlighten me? Thanks in advance.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go get creating strange git messages in bash. Any ideas what causes this ?
thanks, it was a dependency of the repo. Makes sense. thanks. consider closed :) On Fri, Sep 16, 2016 at 11:27 AM Wojciech S. Czarnecki wrote: > Dnia 2016-09-16, o godz. 07:48:32 > Joe Blue napisał(a): > > > thanks again. > > > > your explanation about go get helped. > > SO i looked at the offending repo. Its not my repo, just someones on > github > > > > github.com/pkg/sftp > Your *local* copy is in detached head state. I.e. you manually or some > vendoring script checked out something else than master at head. To fix > it you need to checkout master as said. > > > What i cant work out is WHY this repo outputs weird git messages, and > > others dont. > Others (your local copies) were not touched. > > > Its not blocking me working, but i am just wanting to know. I am OC > > (Obsessive Compulsive) i guess :) > > Get a book on git, e.g. "Git Essentials" ISBN 978-1-78528-790-9 or some > other out of 20+ written. > > > Maybe i shoudl just move on, but if you or others know why that repo does > > what it does would be great to understand. > > You will - just read a decent book bedtime. > > > x-MacBook-Pro:pkg apple$ rm -rf sftp/ > This is NOT the offending repo, github.com/kr/fs is. > > > # cd /Users/apple/workspace/go/src/github.com/kr/fs > Do 'git checkout master' here > then 'git pull --ff-only' > > > Joe > > > -- > Wojciech S. Czarnecki >^oo^ OHIR-RIPE > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/JIhHPOuiHTQ/unsubscribe. > To unsubscribe from this group and all its topics, 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] Base58check to decimal
In the fact the author has already made it easy for you: https://github.com/saracen/bitcoin-all-key-generator Also, it starts at 1, not 0 :-) On 16 September 2016 at 11:30, Donovan Hide wrote: > Not sure what the exact questions is, but I think if you study and play > around with this section of code, you'll get somewhere closer to > understanding how Bitcoin private keys and addresses work: > > https://github.com/saracen/directory.io/blob/master/directory.go#L70-L101 > > The (joke) app is basically just going from 0 to the maximum possible > bitcoin private key value and generating the matching address: > > http://directory.io/faq > > On 16 September 2016 at 09:17, Nosferatu fist > wrote: > >> Hello donovan First I thank you for having me cleared >> by implenter against how your code in this application >> ?https://github.com/saracen/directory.io/blob/master/directory.go >> >> to get this: >> >> 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf >> 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm >> 103754284494436883955695059393877833907143043 >> >> if you could help me I would be very grateful to you . >> >> -- >> 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] Base58check to decimal
Not sure what the exact questions is, but I think if you study and play around with this section of code, you'll get somewhere closer to understanding how Bitcoin private keys and addresses work: https://github.com/saracen/directory.io/blob/master/directory.go#L70-L101 The (joke) app is basically just going from 0 to the maximum possible bitcoin private key value and generating the matching address: http://directory.io/faq On 16 September 2016 at 09:17, Nosferatu fist wrote: > Hello donovan First I thank you for having me cleared > by implenter against how your code in this application > ?https://github.com/saracen/directory.io/blob/master/directory.go > > to get this: > > 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf > 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm > 103754284494436883955695059393877833907143043 > > if you could help me I would be very grateful to you . > > -- > 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] go get creating strange git messages in bash. Any ideas what causes this ?
Dnia 2016-09-16, o godz. 07:48:32 Joe Blue napisał(a): > thanks again. > > your explanation about go get helped. > SO i looked at the offending repo. Its not my repo, just someones on github > > github.com/pkg/sftp Your *local* copy is in detached head state. I.e. you manually or some vendoring script checked out something else than master at head. To fix it you need to checkout master as said. > What i cant work out is WHY this repo outputs weird git messages, and > others dont. Others (your local copies) were not touched. > Its not blocking me working, but i am just wanting to know. I am OC > (Obsessive Compulsive) i guess :) Get a book on git, e.g. "Git Essentials" ISBN 978-1-78528-790-9 or some other out of 20+ written. > Maybe i shoudl just move on, but if you or others know why that repo does > what it does would be great to understand. You will - just read a decent book bedtime. > x-MacBook-Pro:pkg apple$ rm -rf sftp/ This is NOT the offending repo, github.com/kr/fs is. > # cd /Users/apple/workspace/go/src/github.com/kr/fs Do 'git checkout master' here then 'git pull --ff-only' > Joe -- Wojciech S. Czarnecki ^oo^ OHIR-RIPE -- 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] Base58check to decimal
Hello donovan First I thank you for having me cleared by implenter against how your code in this application ? https://github.com/saracen/directory.io/blob/master/directory.go to get this: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm 103754284494436883955695059393877833907143043 if you could help me I would be very grateful to you . -- 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: make a struct pointer _not_ implement an interface
On Monday, September 12, 2016 at 4:20:46 PM UTC-5, Alex Flint wrote: > > Is it possible to have a struct that implements an interface, but have > pointers to the struct not implement the interface? The reason is that I > want to find all the places in our codebase that attempt to use a pointer > to a certain struct as a certain interface. > Just change (temporarily) the return value of one of the methods on that struct pointer (or otherwise alter the signature of the implementing method(s)). The compiler will point out all places you use it as that interface. -- 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 get creating strange git messages in bash. Any ideas what causes this ?
thanks again.
your explanation about go get helped.
SO i looked at the offending repo. Its not my repo, just someones on github
github.com/pkg/sftp
What i cant work out is WHY this repo outputs weird git messages, and
others dont.
Its not blocking me working, but i am just wanting to know. I am OC
(Obsessive Compulsive) i guess :)
Maybe i shoudl just move on, but if you or others know why that repo does
what it does would be great to understand.
x-MacBook-Pro:pkg apple$ rm -rf sftp/
x-MacBook-Pro:pkg apple$ go get github.com/pkg/sftp
x-MacBook-Pro:pkg apple$ rm -rf sftp/
x-MacBook-Pro:pkg apple$ go get -u -v github.com/pkg/sftp
github.com/pkg/sftp (download)
github.com/kr/fs (download)
# cd /Users/apple/workspace/go/src/github.com/kr/fs; git pull --ff-only
You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull
package github.com/kr/fs: exit status 1
github.com/pkg/errors (download)
Fetching https://golang.org/x/crypto/ssh?go-get=1
Parsing meta tags from https://golang.org/x/crypto/ssh?go-get=1 (status
code 200)
get "golang.org/x/crypto/ssh": found meta tag main.metaImport{Prefix:"
golang.org/x/crypto", VCS:"git", RepoRoot:"
https://go.googlesource.com/crypto"} at
https://golang.org/x/crypto/ssh?go-get=1
get "golang.org/x/crypto/ssh": verifying non-authoritative meta tag
Fetching https://golang.org/x/crypto?go-get=1
Parsing meta tags from https://golang.org/x/crypto?go-get=1 (status code
200)
golang.org/x/crypto (download)
Fetching https://golang.org/x/crypto/curve25519?go-get=1
Parsing meta tags from https://golang.org/x/crypto/curve25519?go-get=1
(status code 200)
get "golang.org/x/crypto/curve25519": found meta tag
main.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"
https://go.googlesource.com/crypto"} at
https://golang.org/x/crypto/curve25519?go-get=1
get "golang.org/x/crypto/curve25519": verifying non-authoritative meta tag
Fetching https://golang.org/x/crypto/ed25519?go-get=1
Parsing meta tags from https://golang.org/x/crypto/ed25519?go-get=1 (status
code 200)
get "golang.org/x/crypto/ed25519": found meta tag main.metaImport{Prefix:"
golang.org/x/crypto", VCS:"git", RepoRoot:"
https://go.googlesource.com/crypto"} at
https://golang.org/x/crypto/ed25519?go-get=1
get "golang.org/x/crypto/ed25519": verifying non-authoritative meta tag
Fetching https://golang.org/x/crypto/ed25519/internal/edwards25519?go-get=1
Parsing meta tags from
https://golang.org/x/crypto/ed25519/internal/edwards25519?go-get=1 (status
code 200)
get "golang.org/x/crypto/ed25519/internal/edwards25519": found meta tag
main.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"
https://go.googlesource.com/crypto"} at
https://golang.org/x/crypto/ed25519/internal/edwards25519?go-get=1
get "golang.org/x/crypto/ed25519/internal/edwards25519": verifying
non-authoritative meta tag
x-MacBook-Pro:pkg apple$
cheers
Joe
On Fri, Sep 16, 2016 at 2:14 AM James Bardin wrote:
> On Thu, Sep 15, 2016 at 5:53 PM, Joe Blue wrote:
>
>> thanks James
>>
>> You lost me here.
>>
>
> Where's here? O can try to provide more detail if you let me know what
> you're not following. If you go into each repo that's not working and
> checkout master, "go get -u" will work again.
>
>
>> go get always pulls from master though ?
>>
>>
> Yes, "go get" clones the master branch if there is no local copy, and runs
> `git pull --ff-only` if the repo exists and the -u flag is provided (as you
> see in the log).
>
>
--
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.
