On Mon, Jul 25, 2016 at 10:40 AM, Matt Harden wrote:
> The syntax is &type{...}. &42 does not match this syntax. What Jan was
> describing is specific to that syntax, not to the use of & in general; in
> fact let's try it for &x:
>
> tmp := x
> &tmp
>
> This gives a very different and not useful v
go-search.org and Google just found CVSS v2 implementations.
Anyone have any tips?
Eric.
--
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...
Yes, it is. The optimization occurs for any occurrence of
m[string(expression of type []byte)]. Where the byte slice came from
(global or otherwise) is irrelevant.
On Monday, July 25, 2016 at 8:37:03 AM UTC-7, T L wrote:
>
> @Randall, thanks for answer.
> You mean the answer is yes, right?
--
To put it another way, excluding error conditions, the request isn't done
until you've consumed the response body and closed it.
On Monday, July 25, 2016 at 3:11:01 PM UTC-4, fabian@gmail.com wrote:
>
> Hi,
>
> first, two points on the more obvious aspects:
>
>- The ContentLength header
This code "does the trick" (except in Playground) :
https://play.golang.org/p/kJAfNFZUev
$ go run macro.go
dump(a + b) = 14
dump(b * a) = 40
$ go build -o macro
$ ./macro
dump(a + b) = 14
dump(b * a) = 40
Read current stacktrace, extract source file path, read source file,
extract textual (u
Thanks Ian. But Its not clear how to get execution trace from that document
(https://golang.org/s/go15trace). When I list profiles for my application,
I get following list
block,goroutine,heap,threadcreate
And when I try to curl to http://my-app/debug/pprof/trace?seconds=30"; for my
applicati
A last though on that topic,
fedora and ubuntu are now pushing new package formats (flatpack / snap).
(sarcasm, Once again everybody s doing its own sauce)
I m not clear about flatpack, but snap is definitely a binary package
format.
Let s see what will happen in coming releases.
Le dimanche 2
>
> This is for a single-exe release right?
>
A tiny bit more as you can have extra files along your bin,
setup icon for menu launchers,
define env variables,
and for deb/rpm have pre/post script where you can install services or do
more fun stuff.
Msi support is definitely missing that last
Hi,
first, two points on the more obvious aspects:
- The ContentLength header is just a hint for the server. Nothing
prevents you from setting the content length to some value (like 1896240)
and then sending a request body with a different size. The resulting
request might not be a
If you are looking for a file watch tool where you can do those things, you
could look at modd:
https://github.com/cortesi/modd#quick-start
On Monday, July 25, 2016 at 10:36:18 AM UTC-7, KLR wrote:
>
> Hi, is there a nodemon style tool for go (or less bulky) or has anyone a
> recommendation for
The syntax is &type{...}. &42 does not match this syntax. What Jan was
describing is specific to that syntax, not to the use of & in general; in
fact let's try it for &x:
tmp := x
&tmp
This gives a very different and not useful value for &x. &T{...} is an
exceptional syntactic sugar for grabbing
Hi, is there a nodemon style tool for go (or less bulky) or has anyone a
recommendation for server restart after code changes bash script for that
and watching several files .go and polymer (.html)? Thanks, Karl
--
You received this message because you are subscribed to the Google Groups
"gola
On Mon, 25 Jul 2016 15:54:02 +
Jan Mercl <0xj...@gmail.com> wrote:
> > If T{} is like 42, why “(&T{})" is legal?
>
> Because
>
> &T{...}
>
> is syntactic sugar for
>
> tmp := T{...} // behind the scenes
> &tmp
>
> and &tmp is an okay receiver in the OP.
But by the
@Matt Harden, the recursive reason listens quite reasonable.
@all, thanks for paticipating this discussion.
--
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 golan
Looks good, Thanks.
This is for a single-exe release right?
Any plan to have share lib support for multiple-tool releases? I.e., to
allow many small tools written in GO to use the same shared lib, instead of
each carrying the full set of Go libs.
On Sunday, July 24, 2016 at 12:18:42 PM UTC-
On Mon, Jul 25, 2016 at 11:23 AM, T L wrote:
> It doesn't work. The receiver should be a pointer in function definition.
>
> https://play.golang.org/p/fQbbeDhB9O
Oh I see, I misunderstood. If the receiver is a pointer it's probably
so that you can modify the value, but in this case you are immedi
On Mon, Jul 25, 2016 at 9:10 AM Sam Whited wrote:
> On Mon, Jul 25, 2016 at 11:05 AM, T L wrote:
> > Then why
> >
> > T{...}
> >
> > can't be a syntactic sugar for
> >
> > tmp := T{...}
> > tmp
> >
> > and tmp is an okay receiver.
> > :P
>
> It is (effectively)
Not so.
It doesn't work. The receiver should be a pointer in function definition.
https://play.golang.org/p/fQbbeDhB9O
--
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 go
On Mon, Jul 25, 2016 at 11:05 AM, T L wrote:
> Then why
>
> T{...}
>
> can't be a syntactic sugar for
>
> tmp := T{...}
> tmp
>
> and tmp is an okay receiver.
> :P
It is (effectively); that works just fine: https://play.golang.org/p/SF2lznWaRj
eg. (T{}).f() should work.
Then why
T{...}
can't be a syntactic sugar for
tmp := T{...}
tmp
and tmp is an okay receiver.
:P
--
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
On Mon, Jul 25, 2016 at 5:50 PM T L wrote:
> If T{} is like 42, why “(&T{})" is legal?
Because
&T{...}
is syntactic sugar for
tmp := T{...} // behind the scenes
&tmp
and &tmp is an okay receiver in the OP.
--
-j
--
You received this message because you are subs
If T{} is like 42, why “(&T{})" is legal?
--
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:
On Mon, Jul 25, 2016 at 5:34 PM T L wrote:
I cannot see a problem.
> (&t).f() // ok
&t is a pointer, no problem here.
> t.f() // ok
t is adressable, again, no problem.
> (&T{}).f() // ok
&T{} is already a pointer, no surprise it's ok as a receiver of a pointer
method.
> T{}.f() // cannot c
@Randall, thanks for answer.
You mean the answer is yes, right?
--
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
package main
type T struct{}
func (t *T) f() {}
func main() {
t := T{}
(&t).f() // ok
t.f() // ok
(&T{}).f() // ok
T{}.f() // cannot call pointer method on T literal
// cannot take the address of T literal
}
--
You received this
Hello,
I'm trying to understand whether net.Conn.Read() is expected to use a lot
more CPU than reading using the lower level socket interface or if I am
doing something wrong(or perhaps comparing apples to oranges)?
Consumer and producer apps are running on two different Linux machines, in
"to
Set a io.Reader in http.NewRequest and do a http request, I found that
someone reads the io.Reader even after the http request done.
Is it a correct behaviour? And is it documented?
My client code is
package main
import (
"log"
"net/http"
"time")
type reader struct{}
func (r reade
Nice! I wasn't aware that the select statement is also for writing to
channels, most examples only show reading from channels. Thanks a lot!
On Monday, July 25, 2016 at 5:12:48 AM UTC+2, Alex Bucataru wrote:
>
> Hi Fabian,
>
> You could add a signal channel to tell your goroutine to exit. Editing
On 2016-07-25 12:35, roger peppe wrote:
On 24 July 2016 at 13:14, Johann Höchtl wrote:
Instead of thanking all reporters individually I'll do it here. I didn't expect
a clear winner but some of the rationales for prefering one dependency mgmt
tool over the other became more clear to me.
To
Your program doesn't work because changing os.Stdout and os.Stdin has no
effect on stdio stdin and stdout. Stdio stdout will still reference fd 1
and stderr fd 2.
I recommend following three solutions:
1. The simplest approach could be not to use cgo at all and run the C
code in a sepa
On 24 July 2016 at 13:14, Johann Höchtl wrote:
> Instead of thanking all reporters individually I'll do it here. I didn't
> expect a clear winner but some of the rationales for prefering one dependency
> mgmt tool over the other became more clear to me.
>
> To sum it up: I'll stick with godeps.
Given the following code https://play.golang.org/p/1_Q9SFIPjr one can see
that stdout of Go and cgo are piped to two different descriptors.
a.) Is it possible to redirect stderr/stdout of cgo calls directly to
os.Stderr/os.Stdout? Am I overlooking some argument or options of cgo so
that is done
32 matches
Mail list logo
