[go-nuts] time.Parse : hour out of range

[Diego Medina]

Hi,

>From a 3rd party I get a file with time like 1503  or 900 (meaning 3:03PM 
or 9:00 AM)

so I thought I could use this format:

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

x, err := time.Parse("1504", "900")

but the result is:

2009/11/10 23:00:00 parsing time "900": hour out of range

As a work around I check if the time is only 3 char long and then I prepend 
a 0, then parsing is ok.

Is this the only way or am I missing anything?

Thank you.

Diego


-- 
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: High CPU usage for process using mdns (Flame graph attached) - time spent in runtime.goexit and runtime.mstart

[Abhay Bothra]

Although what you are saying makes a lot of sense(thanks!), I see that my 
program is just using a 5 second timeout. Is it possible that it can still 
lead to this performance profile? 

On Tuesday, October 18, 2016 at 10:22:09 AM UTC-7, rhys.h...@gmail.com 
wrote:
>
> Does your program set a very large Timeout on its mdns requests (maybe 
> tens of hours long)?
>
> It looks like your program is consuming a lot of CPU cycles on managing 
> timers. On the left half of the flame graph, lots of CPU cycles are spent 
> in runtime.timerproc. Time here indicates a large number of active timers 
> (from time.NewTimer or time.After). The CPU cycles attributed to 
> runtime.sysmon in the right half of the flame graph are a side effect of 
> the runtime.timerproc goroutine doing a large number of short sleeps.
>
> So why are there a large number of active timers in your process? It looks 
> like the mdns package has a bug wherein it sets a timeout on operations, 
> but never cancels that timeout if the operation completes successfully. 
> Instead of using time.After, the mdns package should use time.NewTimer and 
> then defer a call to Stop: 
> https://github.com/hashicorp/mdns/blob/9d85cf22f9f8d53cb5c81c1b2749f438b2ee333f/client.go#L235
>
> The default timeout is one second, but it seems likely that your process 
> specifies a much larger timeout—likely a couple of days to match how long 
> it takes before the CPU usage levels out.
>
> You can fix this behavior in your program by using a smaller timeout, so 
> the "leaked" timers are released sooner, so there's a smaller number active 
> at any time. The mdns package should also be changed to clean up its timer 
> before the query method returns, via time.NewTimer and defer Stop.
>
> On Monday, October 17, 2016 at 11:51:52 AM UTC-7, Abhay Bothra wrote:
>>
>> We are using Hashicorp's mdns library (https://github.com/hashicorp/mdns) 
>> for node discovery, with a frequency of 1 mdns query / minute. The CPU 
>> consumption by the process increases very gradually over a couple of days, 
>> going from 2-3% to 20-30% over 3-4 days. From the runtime instrumentation 
>> we have done, the number of go-routines seems to be fairly static.
>>
>> The attached flame-graph from the pprof output suggests that a log of CPU 
>> is being spent on runtime.goexit and runtime.mstart. To me this seems to 
>> suggest that we are starting very short lived go-routines.
>> - Is it fair to blame lots of short-lived go-routines for this?
>> - What else can lead to this sort of behavior?
>> - How should be go about instrumenting our code in order to be able to 
>> get a root cause?
>>
>> Really appreciate any help.
>>
>> 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] Is it safe to modify any part of a pointer?

[Joshua Liebow-Feeser]

On Tue, Oct 18, 2016 at 4:19 PM, Ian Lance Taylor  wrote:

> On Tue, Oct 18, 2016 at 3:13 PM, Joshua Liebow-Feeser 
> wrote:
> >
> > On Tue, Oct 18, 2016 at 2:53 PM, Ian Lance Taylor 
> wrote:
> >>
> >> On Tue, Oct 18, 2016 at 2:45 PM, Joshua Liebow-Feeser  >
> >> wrote:
> >> >
> >> > On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser <
> he...@joshlf.com>
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor 
> >> >> wrote:
> >> >>>
> >> >>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser
> >> >>> 
> >> >>> wrote:
> >> >>> >
> >> >>> > I'm playing around with implementing a wait-free channel in the
> >> >>> > runtime
> >> >>> > package, and as part of this, it'd be really nice to have
> >> >>> > double-word
> >> >>> > compare-and-swap (CAS). Barring that, however, for my purposes, it
> >> >>> > would
> >> >>> > actually be fine to have a one-word value that encodes both a
> >> >>> > pointer
> >> >>> > and
> >> >>> > some extra information using bit packing. The problem, though, is
> >> >>> > that
> >> >>> > if I
> >> >>> > store this value as, for example, a uintptr, the GC may not
> realize
> >> >>> > that
> >> >>> > it's a pointer. So my question is: are there any bits in a pointer
> >> >>> > which,
> >> >>> > when modified, won't mess with the GC? Note that since this is
> >> >>> > implemented
> >> >>> > in the runtime, I'm totally OK with relying on behavior specific
> to
> >> >>> > the
> >> >>> > current GC implementation.
> >> >>>
> >> >>> See runtime/lfstack*.go.
> >> >>
> >> >> Awesome, thanks!
> >> >
> >> >
> >> > Actually, quick follow-up. I noticed that the lfstack implementation
> >> > side-steps the GC issue by just not keeping pointers. That might work
> >> > for me
> >> > if I just store runtime.g pointers, but that raises another question:
> >> > can
> >> > the GC ever free g's, or are they just explicitly freed when a
> goroutine
> >> > quits? That is, is it safe for me to store a pointer/counter hybrid
> like
> >> > in
> >> > lfstack - where that pointer is a *g - and assume that the GC won't
> >> > collect
> >> > the g from out from under me?
> >>
> >> For the specific case of a g, this is safe at the moment.  The current
> >> Go runtime caches all g's and never releases them.  See gfget and
> >> gfput in runtime/proc.go.
> >
> >
> > OK great. And they won't ever be moved? (Come to think of it, is pointer
> > rewriting only ever a thing on the stack?)
>
> Yes, with the current toolchain, objects in the heap are never moved.
>
> (Obviously no guarantees that this will always be true.)
>

Awesome, thanks.

>
> 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] Is it safe to modify any part of a pointer?

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 3:13 PM, Joshua Liebow-Feeser  wrote:
>
> On Tue, Oct 18, 2016 at 2:53 PM, Ian Lance Taylor  wrote:
>>
>> On Tue, Oct 18, 2016 at 2:45 PM, Joshua Liebow-Feeser 
>> wrote:
>> >
>> > On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser 
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor 
>> >> wrote:
>> >>>
>> >>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser
>> >>> 
>> >>> wrote:
>> >>> >
>> >>> > I'm playing around with implementing a wait-free channel in the
>> >>> > runtime
>> >>> > package, and as part of this, it'd be really nice to have
>> >>> > double-word
>> >>> > compare-and-swap (CAS). Barring that, however, for my purposes, it
>> >>> > would
>> >>> > actually be fine to have a one-word value that encodes both a
>> >>> > pointer
>> >>> > and
>> >>> > some extra information using bit packing. The problem, though, is
>> >>> > that
>> >>> > if I
>> >>> > store this value as, for example, a uintptr, the GC may not realize
>> >>> > that
>> >>> > it's a pointer. So my question is: are there any bits in a pointer
>> >>> > which,
>> >>> > when modified, won't mess with the GC? Note that since this is
>> >>> > implemented
>> >>> > in the runtime, I'm totally OK with relying on behavior specific to
>> >>> > the
>> >>> > current GC implementation.
>> >>>
>> >>> See runtime/lfstack*.go.
>> >>
>> >> Awesome, thanks!
>> >
>> >
>> > Actually, quick follow-up. I noticed that the lfstack implementation
>> > side-steps the GC issue by just not keeping pointers. That might work
>> > for me
>> > if I just store runtime.g pointers, but that raises another question:
>> > can
>> > the GC ever free g's, or are they just explicitly freed when a goroutine
>> > quits? That is, is it safe for me to store a pointer/counter hybrid like
>> > in
>> > lfstack - where that pointer is a *g - and assume that the GC won't
>> > collect
>> > the g from out from under me?
>>
>> For the specific case of a g, this is safe at the moment.  The current
>> Go runtime caches all g's and never releases them.  See gfget and
>> gfput in runtime/proc.go.
>
>
> OK great. And they won't ever be moved? (Come to think of it, is pointer
> rewriting only ever a thing on the stack?)

Yes, with the current toolchain, objects in the heap are never moved.

(Obviously no guarantees that this will always be true.)

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] Is it safe to modify any part of a pointer?

[Joshua Liebow-Feeser]

On Tue, Oct 18, 2016 at 2:53 PM, Ian Lance Taylor  wrote:

> On Tue, Oct 18, 2016 at 2:45 PM, Joshua Liebow-Feeser 
> wrote:
> >
> > On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser 
> > wrote:
> >>
> >>
> >>
> >> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor 
> wrote:
> >>>
> >>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser <
> he...@joshlf.com>
> >>> wrote:
> >>> >
> >>> > I'm playing around with implementing a wait-free channel in the
> runtime
> >>> > package, and as part of this, it'd be really nice to have double-word
> >>> > compare-and-swap (CAS). Barring that, however, for my purposes, it
> >>> > would
> >>> > actually be fine to have a one-word value that encodes both a pointer
> >>> > and
> >>> > some extra information using bit packing. The problem, though, is
> that
> >>> > if I
> >>> > store this value as, for example, a uintptr, the GC may not realize
> >>> > that
> >>> > it's a pointer. So my question is: are there any bits in a pointer
> >>> > which,
> >>> > when modified, won't mess with the GC? Note that since this is
> >>> > implemented
> >>> > in the runtime, I'm totally OK with relying on behavior specific to
> the
> >>> > current GC implementation.
> >>>
> >>> See runtime/lfstack*.go.
> >>
> >> Awesome, thanks!
> >
> >
> > Actually, quick follow-up. I noticed that the lfstack implementation
> > side-steps the GC issue by just not keeping pointers. That might work
> for me
> > if I just store runtime.g pointers, but that raises another question: can
> > the GC ever free g's, or are they just explicitly freed when a goroutine
> > quits? That is, is it safe for me to store a pointer/counter hybrid like
> in
> > lfstack - where that pointer is a *g - and assume that the GC won't
> collect
> > the g from out from under me?
>
> For the specific case of a g, this is safe at the moment.  The current
> Go runtime caches all g's and never releases them.  See gfget and
> gfput in runtime/proc.go.
>

OK great. And they won't ever be moved? (Come to think of it, is pointer
rewriting only ever a thing on the stack?)

>
> 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] Are short variable declarations necessary?

[Nyah Check]

Hi TL,

I can't talk on behalf of the creators of the language; but from my
personal experience; it makes code more succinct and easier to write;
something more or less like "doing more with less" if you know what I mean.
It's one the the features I love the most in Go. It just makes programming
more interesting. Rather spending much time writing a lot of code which I
think doesn't make much sense in today's programming world where the
programmer's time is very expensive compared to hardware. Le's just say it
reduces the number of lines immensely in code.

In all that feature is awesome! Hope it clears your doubts.

Cheers!
Nyah
-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

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

Re: [go-nuts] Is it safe to modify any part of a pointer?

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 2:45 PM, Joshua Liebow-Feeser  wrote:
>
> On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser 
> wrote:
>>
>>
>>
>> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor  wrote:
>>>
>>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser 
>>> wrote:
>>> >
>>> > I'm playing around with implementing a wait-free channel in the runtime
>>> > package, and as part of this, it'd be really nice to have double-word
>>> > compare-and-swap (CAS). Barring that, however, for my purposes, it
>>> > would
>>> > actually be fine to have a one-word value that encodes both a pointer
>>> > and
>>> > some extra information using bit packing. The problem, though, is that
>>> > if I
>>> > store this value as, for example, a uintptr, the GC may not realize
>>> > that
>>> > it's a pointer. So my question is: are there any bits in a pointer
>>> > which,
>>> > when modified, won't mess with the GC? Note that since this is
>>> > implemented
>>> > in the runtime, I'm totally OK with relying on behavior specific to the
>>> > current GC implementation.
>>>
>>> See runtime/lfstack*.go.
>>
>> Awesome, thanks!
>
>
> Actually, quick follow-up. I noticed that the lfstack implementation
> side-steps the GC issue by just not keeping pointers. That might work for me
> if I just store runtime.g pointers, but that raises another question: can
> the GC ever free g's, or are they just explicitly freed when a goroutine
> quits? That is, is it safe for me to store a pointer/counter hybrid like in
> lfstack - where that pointer is a *g - and assume that the GC won't collect
> the g from out from under me?

For the specific case of a g, this is safe at the moment.  The current
Go runtime caches all g's and never releases them.  See gfget and
gfput in runtime/proc.go.

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] Is it safe to modify any part of a pointer?

[Joshua Liebow-Feeser]

On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser 
wrote:

>
>
> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor  wrote:
>
>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser 
>> wrote:
>> >
>> > I'm playing around with implementing a wait-free channel in the runtime
>> > package, and as part of this, it'd be really nice to have double-word
>> > compare-and-swap (CAS). Barring that, however, for my purposes, it would
>> > actually be fine to have a one-word value that encodes both a pointer
>> and
>> > some extra information using bit packing. The problem, though, is that
>> if I
>> > store this value as, for example, a uintptr, the GC may not realize that
>> > it's a pointer. So my question is: are there any bits in a pointer
>> which,
>> > when modified, won't mess with the GC? Note that since this is
>> implemented
>> > in the runtime, I'm totally OK with relying on behavior specific to the
>> > current GC implementation.
>>
>> See runtime/lfstack*.go.
>>
> Awesome, thanks!
>

Actually, quick follow-up. I noticed that the lfstack implementation
side-steps the GC issue by just not keeping pointers. That might work for
me if I just store runtime.g pointers, but that raises another question:
can the GC ever free g's, or are they just explicitly freed when a
goroutine quits? That is, is it safe for me to store a pointer/counter
hybrid like in lfstack - where that pointer is a *g - and assume that the
GC won't collect the g from out from under me?

>
>> 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] Are short variable declarations necessary?

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 7:50 AM, T L  wrote:
>
> On Tuesday, October 18, 2016 at 10:40:02 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Tue, Oct 18, 2016 at 7:21 AM, T L  wrote:
>> >
>> > alternative question, why followings are not accepted in syntax:
>> >
>> > if var x = 5; x > 3 {
>> > _ = x
>> > }
>> >
>> > for var x = range []int{0,1,2} {
>> > _ = x
>> >
>> > }
>> >
>> > switch var x = "abc"; x {
>> > default:
>> > _ = x
>> > }
>> >
>> > switch var x = (interface{}(true)).(type) {
>> > default:
>> > _ = x
>> > }
>>
>> That syntax adds no functionality and, at least to me, seems uglier
>> and harder to read.
>>
>> Ian
>
>
> So the reason of adding short variable declarations is just to avoid
> so-called ugliness?

I'm sorry, I don't understand what you are asking.  Your examples are
about the way that various control flow statements permit a short
variable declaration.  Obviously short variable declarations can also
be used as statements by themselves.  I don't know what you are
referring to with your question.

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] Is it safe to modify any part of a pointer?

[Joshua Liebow-Feeser]

On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor  wrote:

> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser 
> wrote:
> >
> > I'm playing around with implementing a wait-free channel in the runtime
> > package, and as part of this, it'd be really nice to have double-word
> > compare-and-swap (CAS). Barring that, however, for my purposes, it would
> > actually be fine to have a one-word value that encodes both a pointer and
> > some extra information using bit packing. The problem, though, is that
> if I
> > store this value as, for example, a uintptr, the GC may not realize that
> > it's a pointer. So my question is: are there any bits in a pointer which,
> > when modified, won't mess with the GC? Note that since this is
> implemented
> > in the runtime, I'm totally OK with relying on behavior specific to the
> > current GC implementation.
>
> See runtime/lfstack*.go.
>
Awesome, thanks!

>
> 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] Is it safe to modify any part of a pointer?

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser  wrote:
>
> I'm playing around with implementing a wait-free channel in the runtime
> package, and as part of this, it'd be really nice to have double-word
> compare-and-swap (CAS). Barring that, however, for my purposes, it would
> actually be fine to have a one-word value that encodes both a pointer and
> some extra information using bit packing. The problem, though, is that if I
> store this value as, for example, a uintptr, the GC may not realize that
> it's a pointer. So my question is: are there any bits in a pointer which,
> when modified, won't mess with the GC? Note that since this is implemented
> in the runtime, I'm totally OK with relying on behavior specific to the
> current GC implementation.

See runtime/lfstack*.go.

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] Any reason make.bash does not allow you to pass asmflags?

[Michael Hudson-Doyle]

On 19 October 2016 at 07:53, Parker Evans  wrote:

> I was recently playing around with the assembler and compiler -trimpath
> option to remove build machine prefixes from the built from source
> toolchain and I realized that make.bash allows you to pass gcflags via the
> GO_GCFLAGS environment variable but there is no equivalent GO_ASMFLAGS
> environment variable that allows you to pass -asmflags.  As properly
> trimming all the paths involves passing the -trimpath option via -asmflags
> and -gcflags, this seems to be required.  Is there another way to do this?
> Or would this be a good patch for future Go releases?
>

-asmpath is a fairly new thing (added in 1.5?) so it's probably just an
oversight.

Cheers,
mwh

-- 
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: Proposal: add "future" internal type (similar to channel)

[Rob Pike]

What Ian said, plus select is awkward to implement as a library, but works
quite well when its syntax is analogous to switch.

-rob


On Tue, Oct 18, 2016 at 11:41 AM, Ian Lance Taylor  wrote:

> On Tue, Oct 18, 2016 at 8:52 AM,   wrote:
> > so why are channels and goroutines built into the language proper?
>
> Channels and goroutines are widely used.  Go does not follow a strict
> principle of putting everything in a library.  That said, ultimately
> these things boil down to matters of taste, in this case the taste of
> the original language designers.
>
> Ian
>
> > On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com
> wrote:
> >>
> >> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
> >>>
> >>> "future" is commonly used synchronization abstraction.
> >>>
> >>> It could be implemented in a library, using mutex, channel and
> interface.
> >>> Example:
> >>> https://github.com/Workiva/go-datastructures/blob/master/
> futures/selectable.go
> >>
> >>
> >> If it can be implemented as a library, why build it in to the language?
> >> You don't need futures very often---far less than, say, Mutex, and
> mutexes
> >> aren't built into the language either.
> >>
> > --
> > 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.

[go-nuts] Re: Tooling experience feedback

[ondrej . kokes]

go tool trace was nicely explained here

https://groups.google.com/forum/#!topic/Golang-Nuts/Ktvua7AGdkI

and had no proper documentation at the time. Would be good if it had a high 
level overview like that

On Tuesday, 18 October 2016 19:54:49 UTC+1, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
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 safe to modify any part of a pointer?

[Joshua Liebow-Feeser]

On Oct 18, 2016 12:42 PM, "adonovan via golang-nuts" <
golang-nuts@googlegroups.com> wrote:
>
> On Tuesday, 18 October 2016 15:30:36 UTC-4, Joshua Liebow-Feeser wrote:
>>
>> are there any bits in a pointer which, when modified, won't mess with
the GC?
>
>
> Even if there are, using them would constrain the future choices of the
GC team, for which they will not thank you.
>
> This seems like a bad idea for many reasons.
This is very experimental, so I'm fine doing things that would never
actually be accepted into the runtime. I just want an algorithm that works
with the current gc.
>
> --
> 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/3cLrmBoF5B8/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] Tooling experience feedback

['Jaana Burcu Dogan' via golang-nuts]

On Tue, Oct 18, 2016 at 12:34 PM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Tue, Oct 18, 2016 at 8:54 PM 'Jaana Burcu Dogan' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> The go tool already does a lot of things, perhaps too much of them.
>

Please contribute with specific items. Hiding complexity is also a goal we
want to achieve.


> The observation that newcomers have trouble to use it to their advantage
> is both correct and the evidence of its complexity. Adding new sub-commands
> has the potential to only make that worse, I'm afraid.
>
>
This is not a thread where we discuss what specifically will be added or
not. Major improvement ideas will be followed by proposals and will go
through the typical proposal process where you can give concrete feedback
about each item. This topic is about what could have improved by looking at
user's workflow and their actual daily interactions with the tools.


> --
>
> -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: Is it safe to modify any part of a pointer?

[adonovan via golang-nuts]

On Tuesday, 18 October 2016 15:30:36 UTC-4, Joshua Liebow-Feeser wrote:
>
> are there any bits in a pointer which, when modified, won't mess with the 
> GC?
>

Even if there are, using them would constrain the future choices of the GC 
team, for which they will not thank you.

This seems like a bad idea for many reasons.

-- 
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] Tooling experience feedback

[Jan Mercl]

On Tue, Oct 18, 2016 at 8:54 PM 'Jaana Burcu Dogan' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

The go tool already does a lot of things, perhaps too much of them. The
observation that newcomers have trouble to use it to their advantage is
both correct and the evidence of its complexity. Adding new sub-commands
has the potential to only make that worse, I'm afraid.

-- 

-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: Tooling experience feedback

[Florin Pățan]

Hi Jaana,



Thank you for this initiative.

I think currently one of the points that I think that is missing is easy to 
access documentation online.

My use-case is usually around the web and making things easier to access 
from there. Maybe I've got used to the command line for common tasks but 
the things that are really hard to find are the special instructions to the 
go compiler and linker (gcflags and ldflags), like here for 
example: https://godoc.org/cmd/go And having all of this in a single page, 
while convenient can be overwhelming the first few times.

 Also the documentation, while from a godoc point of view logically lists 
the flags and tools / subtools, is rather well hidden for the things that 
you'd search as a newbie and while the Tour tries to teach you some aspects 
of the language, it doesn't show anything related to how to use the tools 
of the language (nor does it show how to install it correctly for example, 
many people still having problems with understanding how to correctly set 
their workspace with env vars and so on).

I think more usage examples should be shown in general, with concrete 
use-cases:
- this is how you test things
- this is how you test things without vendors (which is a major pita right 
now btw)
- this is how you also get the coverage
- this is how you compile and set a random string value at compile time
- etc.

I'll try and come up with more examples later on.

I also see the pattern in other apps where main command has some flags then 
the subcommand has other flags so I guess that's ok, probably introducing 
aliases would make it even more complex to use.


Kind regards,
Florin

On Tuesday, October 18, 2016 at 7:54:49 PM UTC+1, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
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: Tooling experience feedback

[Egon]

On Tuesday, 18 October 2016 14:02:08 UTC-5, Zellyn wrote:
>
> I run go tests with something like this:
>
> while true; do go test ./foo/bar; fswatch -1 -r . > /dev/null; sleep 0.3; 
> done
>
>
> It would be nice if go test could do that itself. (The 0.3 second sleep is 
> to let the file-write that triggered the test complete.)
>

I've built a tool for myself based on Watch by Russ Cox (he showed it in 
this video http://research.swtch.com/acme)

Located at: https://github.com/loov/watchrun


*$ go get github.com/loov/watchrun*
*$ watchrun go test ./foo/bar*

Keeping it as a separate tool is much more flexible and useful... e.g.

*$ watchrun go build myapp ;; myapp*

Which would build the application and then start it. Or... chain it with 
code generation...

*$ watchrun go generate . ;; go build . ;; myapp*

etc... of course depending on your needs you may want some other features 
or an alternative implementation.

Zellyn
>
> On Tuesday, October 18, 2016 at 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>>
>> Hello gophers,
>>
>> I am going to spend some time on improving the not-documented or 
>> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
>> test. The work will consist of reorganizing manuals, proposing new 
>> subcommands or flags to support commonly used multi-step things and so on.
>>
>> To give you some concrete examples:
>>
>> I have been in cases where users cannot find the build flags because they 
>> are hidden. E.g.
>>
>> $ go test -help
>> test [build/test flags] [packages] [build/test flags & test binary 
>> flags]
>> ...
>>
>> requires you to know about where the build flags are. Some tools are 
>> invisible for the newcomers.
>>
>> The other example is about test coverage. It is so tedious that I need an 
>> alias.
>>
>> func gocover() {
>> go test -v -coverprofile=coverage.out && go tool cover 
>> -html=coverage.out
>> } 
>>
>> I want to learn more about your experience, aliases, etc to propose 
>> improvements and work on the most commonly suggested items. I also am 
>> planning to go through this mailing list, stack overflow and other channels 
>> to see the common complaints.
>>
>> Feel free to reply to this thread or write to me privately.
>>
>> Thanks,
>> JBD
>>
>

-- 
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] interface as valid method receivers ?

[xingtao zhao]

Why not make it a compiling time error? 

For example, for a struct: "type Foo has both field and method named 
DoSomething"
type Foo struct {
DoSomething func()
}

func (f Foo) DoSomething() {
}


And for interface version:

type Foo interface { 
func DoSomething() 
} 

func (f Foo) DoSomething() { 
} 

it is more straight forward: "Foo.DoSomething redeclared"

On Tuesday, October 18, 2016 at 11:27:36 AM UTC-7, Konstantin Khomoutov 
wrote:
>
> On Tue, 18 Oct 2016 11:11:59 -0700 (PDT) 
> parais...@gmail.com  wrote: 
>
> > Obviously in Go this is a compile time error : 
> > 
> > type Foo interface {} 
> > 
> > 
> > func (f Foo) DoSomething(){} 
> > 
> > 
> > I wonder if there is some technical limitations that make it 
> > undesirable or hard to implement, or it's just that Go designers 
> > didn't think it is a relevant feature. 
> > 
> > I personally think there is it could be handy in some situations, 
> > instead of having to write a function without receiver, it could 
> > allow to attach behavior to interfaces automatically 
> > instead of the explicit : 
> > 
> > func DoSomething(f Foo){} 
> > 
> > 
> > what is your opinion on the matter ? Unfortunately I wasn't able to 
> > catch anyone of the Go team during the recent conference in Paris to 
> > ask that question. 
>
>   type Foo interface { 
>   func DoSomething() 
>   } 
>
>   func (f Foo) DoSomething() { 
>   } 
>
>   var f Foo 
>
>   f.DoSomething() 
>
> How do you propose to distinguish these two DoSomething()-s? 
>
> More to the point: how could anyone infer what's about to get called 
> from looking at that "f.DoSomething()" expression even if there could 
> be no conflict as in my contrived example -- is it a call on an 
> "interface itself" or on a concrete type an interface value contains? 
>

-- 
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: Tooling experience feedback

[Russ Egan]

1. A "no vendor" switch (for build, test, fmt, vet, etc) would be nice.
2. Multi-package coverage would be nice.  We end up copying this stanza 
throughout our makefiles:

PACKAGES = $$(go list ./... | grep -v /vendor/)

 

test:

echo 'mode: atomic' > build/coverage.out

for pkg in $(PACKAGES) ; do \

go test -v -covermode=count -coverprofile=build/coverage.tmp $$pkg 2>&1 | 
tee -a build/test.out; \

if [ -e build/coverage.tmp ] ; then tail -n +2 build/coverage.tmp >> 
build/coverage.out; rm build/coverage.tmp; fi \

done

go tool cover -html=build/coverage.out -o build/coverage.html



-- 
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: Tooling experience feedback

[Zellyn]

I run go tests with something like this:

while true; do go test ./foo/bar; fswatch -1 -r . > /dev/null; sleep 0.3; 
done


It would be nice if go test could do that itself. (The 0.3 second sleep is 
to let the file-write that triggered the test complete.)


Zellyn

On Tuesday, October 18, 2016 at 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
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] Any reason make.bash does not allow you to pass asmflags?

[Parker Evans]

I was recently playing around with the assembler and compiler -trimpath 
option to remove build machine prefixes from the built from source 
toolchain and I realized that make.bash allows you to pass gcflags via the 
GO_GCFLAGS environment variable but there is no equivalent GO_ASMFLAGS 
environment variable that allows you to pass -asmflags.  As properly 
trimming all the paths involves passing the -trimpath option via -asmflags 
and -gcflags, this seems to be required.  Is there another way to do this? 
 Or would this be a good patch for future Go releases?

Thanks,
Parker

-- 
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] Tooling experience feedback

['Jaana Burcu Dogan' via golang-nuts]

Hello gophers,

I am going to spend some time on improving the not-documented or
hard-to-use parts of the Go tools. I will mainly focus on go build and go
test. The work will consist of reorganizing manuals, proposing new
subcommands or flags to support commonly used multi-step things and so on.

To give you some concrete examples:

I have been in cases where users cannot find the build flags because they
are hidden. E.g.

$ go test -help
test [build/test flags] [packages] [build/test flags & test binary
flags]
...

requires you to know about where the build flags are. Some tools are
invisible for the newcomers.

The other example is about test coverage. It is so tedious that I need an
alias.

func gocover() {
go test -v -coverprofile=coverage.out && go tool cover
-html=coverage.out
}

I want to learn more about your experience, aliases, etc to propose
improvements and work on the most commonly suggested items. I also am
planning to go through this mailing list, stack overflow and other channels
to see the common complaints.

Feel free to reply to this thread or write to me privately.

Thanks,
JBD

-- 
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: Proposal: add "future" internal type (similar to channel)

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 8:52 AM,   wrote:
> so why are channels and goroutines built into the language proper?

Channels and goroutines are widely used.  Go does not follow a strict
principle of putting everything in a library.  That said, ultimately
these things boil down to matters of taste, in this case the taste of
the original language designers.

Ian

> On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com wrote:
>>
>> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>>
>>> "future" is commonly used synchronization abstraction.
>>>
>>> It could be implemented in a library, using mutex, channel and interface.
>>> Example:
>>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>>
>>
>> If it can be implemented as a library, why build it in to the language?
>> You don't need futures very often---far less than, say, Mutex, and mutexes
>> aren't built into the language either.
>>
> --
> 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] interface as valid method receivers ?

[Konstantin Khomoutov]

On Tue, 18 Oct 2016 11:11:59 -0700 (PDT)
paraiso.m...@gmail.com wrote:

> Obviously in Go this is a compile time error :
> 
> type Foo interface {}
> 
> 
> func (f Foo) DoSomething(){}
> 
> 
> I wonder if there is some technical limitations that make it
> undesirable or hard to implement, or it's just that Go designers
> didn't think it is a relevant feature.
> 
> I personally think there is it could be handy in some situations,
> instead of having to write a function without receiver, it could
> allow to attach behavior to interfaces automatically 
> instead of the explicit :
> 
> func DoSomething(f Foo){}
> 
> 
> what is your opinion on the matter ? Unfortunately I wasn't able to
> catch anyone of the Go team during the recent conference in Paris to
> ask that question.

  type Foo interface {
  func DoSomething()
  }

  func (f Foo) DoSomething() {
  }

  var f Foo

  f.DoSomething()

How do you propose to distinguish these two DoSomething()-s?

More to the point: how could anyone infer what's about to get called
from looking at that "f.DoSomething()" expression even if there could
be no conflict as in my contrived example -- is it a call on an
"interface itself" or on a concrete type an interface value contains?

-- 
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] Excessive garbage collection

[Jiří Šimša]

Thank you for your explanation.

I was able to track this problem down to logic in one of the handlers
periodically invoked by the page; the handler logic would result in the
allocation pattern you described.

Best,

--
Jiří Šimša

On Tue, Oct 18, 2016 at 6:13 AM,  wrote:

> From the trace (4->4->0) it looks like the app is allocating about 4MB
> every 10ms. The app also has little (0 rounded) reachable data, sometimes
> called heap ballast. Since there is little ballast the GC is attempting to
> keep the heap from growing beyond 5MB. The GC is using about 2% of the CPU
> resources to do its job.
>
> All of this seems perfectly reasonable from the GC's perspective.
>
>
> On Tuesday, October 18, 2016 at 12:32:47 AM UTC-4, Jiří Šimša wrote:
>>
>> go version go1.7.1 darwin/amd64
>>
>> --
>> Jiří Šimša
>>
>> On Mon, Oct 17, 2016 at 8:02 PM, Ian Lance Taylor 
>> wrote:
>>
>>> On Mon, Oct 17, 2016 at 6:20 PM,   wrote:
>>> >
>>> > The backend of my web server (written in Go) have recently started
>>> consuming
>>> > large amounts of CPU. AFAICT, the CPU seems to be consumed by the
>>> garbage
>>> > collector and I would appreciate any information that would help me
>>> track
>>> > down the root cause.
>>>
>>> What version of Go?  What platform?
>>>
>>> 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] interface as valid method receivers ?

[paraiso . marc]

Obviously in Go this is a compile time error :

type Foo interface {}


func (f Foo) DoSomething(){}


I wonder if there is some technical limitations that make it undesirable or 
hard to implement, or it's just that Go designers didn't think it is a 
relevant feature.

I personally think there is it could be handy in some situations, instead 
of having to write a function without receiver, it could allow to attach 
behavior to interfaces automatically 
instead of the explicit :

func DoSomething(f Foo){}


what is your opinion on the matter ? Unfortunately I wasn't able to catch 
anyone of the Go team during the recent conference in Paris to ask that 
question.

-- 
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: Proposal: add "future" internal type (similar to channel)

[andrey mirtchovski]

> so why are channels and goroutines built into the language proper?

Channels and goroutines are not just language constructs in Go. They
are part of the formal language of Communicating Sequential Processes
and as such are being actively researched. CSP is under active
research. For example, CSPs can be used to specify and verify the
concurrent aspect of a system. More info here:

 https://en.wikipedia.org/wiki/Communicating_sequential_processes#Primitives

-- 
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] New Proposal: Add support for pprof profiler labels

[Michael Matloob]

Hello Gophers!

I've proposed adding a mechanism to the runtime profile support to allow
setting pprof labels. Profile labels are already supported by go tool
pprof, but there's no way of setting them yet.

Doc is here:
https://github.com/golang/proposal/blob/master/design/17280-profile-labels.md
Provide your comments here: https://github.com/golang/go/issues/17280

Thanks!
Michael

-- 
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: Proposal: add "future" internal type (similar to channel)

[gopher]

so why are channels and goroutines built into the language proper?

On Monday, October 17, 2016 at 9:42:17 AM UTC-4, adon...@google.com wrote:
>
> On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>>
>> "future" is commonly used synchronization abstraction.
>>
>> It could be implemented in a library, using mutex, channel and interface.
>> Example: 
>> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>>  
>> 
>>
>
> If it can be implemented as a library, why build it in to the language? 
>  You don't need futures very often---far less than, say, Mutex, and mutexes 
> aren't built into the language either.
>
>

-- 
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: High CPU usage for process using mdns (Flame graph attached) - time spent in runtime.goexit and runtime.mstart

[rhys . hiltner]

Does your program set a very large Timeout on its mdns requests (maybe tens 
of hours long)?

It looks like your program is consuming a lot of CPU cycles on managing 
timers. On the left half of the flame graph, lots of CPU cycles are spent 
in runtime.timerproc. Time here indicates a large number of active timers 
(from time.NewTimer or time.After). The CPU cycles attributed to 
runtime.sysmon in the right half of the flame graph are a side effect of 
the runtime.timerproc goroutine doing a large number of short sleeps.

So why are there a large number of active timers in your process? It looks 
like the mdns package has a bug wherein it sets a timeout on operations, 
but never cancels that timeout if the operation completes successfully. 
Instead of using time.After, the mdns package should use time.NewTimer and 
then defer a call to 
Stop: 
https://github.com/hashicorp/mdns/blob/9d85cf22f9f8d53cb5c81c1b2749f438b2ee333f/client.go#L235

The default timeout is one second, but it seems likely that your process 
specifies a much larger timeout—likely a couple of days to match how long 
it takes before the CPU usage levels out.

You can fix this behavior in your program by using a smaller timeout, so 
the "leaked" timers are released sooner, so there's a smaller number active 
at any time. The mdns package should also be changed to clean up its timer 
before the query method returns, via time.NewTimer and defer Stop.

On Monday, October 17, 2016 at 11:51:52 AM UTC-7, Abhay Bothra wrote:
>
> We are using Hashicorp's mdns library (https://github.com/hashicorp/mdns) 
> for node discovery, with a frequency of 1 mdns query / minute. The CPU 
> consumption by the process increases very gradually over a couple of days, 
> going from 2-3% to 20-30% over 3-4 days. From the runtime instrumentation 
> we have done, the number of go-routines seems to be fairly static.
>
> The attached flame-graph from the pprof output suggests that a log of CPU 
> is being spent on runtime.goexit and runtime.mstart. To me this seems to 
> suggest that we are starting very short lived go-routines.
> - Is it fair to blame lots of short-lived go-routines for this?
> - What else can lead to this sort of behavior?
> - How should be go about instrumenting our code in order to be able to get 
> a root cause?
>
> Really appreciate any help.
>
> 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] Are short variable declarations necessary?

['Axel Wagner' via golang-nuts]

The reason for short variable declarations is, that it makes reuse easier
in cases of multiple return values. e.g.

var a, err = Foo()
if err != nil {
return err
}
var b, err = a.Bar()
if err != nil {
return err
}

doesn't work. That being said, the duplication between ways of declaring
variables has long been acknowledged as an unfortunate historical accident.


On Tue, Oct 18, 2016 at 5:09 PM, T L  wrote:

>
>
> On Tuesday, October 18, 2016 at 11:01:18 PM UTC+8, Pietro Gagliardi
> (andlabs) wrote:
>>
>> No, the reason for short variable declarations is to avoid having to
>> stutter the type of variables everywhere.
>>
>
>  You can also avoid having to stutter the type of variables by using var
> declaration.
>
>
>> It's part of the reason why Go is strongly typed yet doesn't fully feel
>> that way, and was one of the main design goals at first.
>>
>
>> Why the control statements require one, however, is something I wouldn't
>> know.
>>
> On Oct 18, 2016, at 10:50 AM, T L  wrote:
>>
>>
>>
>> On Tuesday, October 18, 2016 at 10:40:02 PM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Tue, Oct 18, 2016 at 7:21 AM, T L  wrote:
>>> >
>>> > alternative question, why followings are not accepted in syntax:
>>> >
>>> > if var x = 5; x > 3 {
>>> > _ = x
>>> > }
>>> >
>>> > for var x = range []int{0,1,2} {
>>> > _ = x
>>> >
>>> > }
>>> >
>>> > switch var x = "abc"; x {
>>> > default:
>>> > _ = x
>>> > }
>>> >
>>> > switch var x = (interface{}(true)).(type) {
>>> > default:
>>> > _ = x
>>> > }
>>>
>>> That syntax adds no functionality and, at least to me, seems uglier
>>> and harder to read.
>>>
>>> Ian
>>>
>>
>> So the reason of adding short variable declarations is just to avoid
>> so-called ugliness?
>>
>>
>> --
>> 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] Are short variable declarations necessary?

[T L]

On Tuesday, October 18, 2016 at 11:01:18 PM UTC+8, Pietro Gagliardi 
(andlabs) wrote:
>
> No, the reason for short variable declarations is to avoid having to 
> stutter the type of variables everywhere. 
>

 You can also avoid having to stutter the type of variables by using var 
declaration.
 

> It's part of the reason why Go is strongly typed yet doesn't fully feel 
> that way, and was one of the main design goals at first.
>

> Why the control statements require one, however, is something I wouldn't 
> know.
>
On Oct 18, 2016, at 10:50 AM, T L  wrote:
>
>
>
> On Tuesday, October 18, 2016 at 10:40:02 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Tue, Oct 18, 2016 at 7:21 AM, T L  wrote: 
>> > 
>> > alternative question, why followings are not accepted in syntax: 
>> > 
>> > if var x = 5; x > 3 { 
>> > _ = x 
>> > } 
>> > 
>> > for var x = range []int{0,1,2} { 
>> > _ = x 
>> > 
>> > } 
>> > 
>> > switch var x = "abc"; x { 
>> > default: 
>> > _ = x 
>> > } 
>> > 
>> > switch var x = (interface{}(true)).(type) { 
>> > default: 
>> > _ = x 
>> > } 
>>
>> That syntax adds no functionality and, at least to me, seems uglier 
>> and harder to read. 
>>
>> Ian 
>>
>
> So the reason of adding short variable declarations is just to avoid 
> so-called ugliness?
>
>
> -- 
> 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] Are short variable declarations necessary?

[Pietro Gagliardi]

No, the reason for short variable declarations is to avoid having to stutter 
the type of variables everywhere. It's part of the reason why Go is strongly 
typed yet doesn't fully feel that way, and was one of the main design goals at 
first.

Why the control statements require one, however, is something I wouldn't know.
> On Oct 18, 2016, at 10:50 AM, T L  wrote:
> 
> 
> 
> On Tuesday, October 18, 2016 at 10:40:02 PM UTC+8, Ian Lance Taylor wrote:
> On Tue, Oct 18, 2016 at 7:21 AM, T L > wrote: 
> > 
> > alternative question, why followings are not accepted in syntax: 
> > 
> > if var x = 5; x > 3 { 
> > _ = x 
> > } 
> > 
> > for var x = range []int{0,1,2} { 
> > _ = x 
> > 
> > } 
> > 
> > switch var x = "abc"; x { 
> > default: 
> > _ = x 
> > } 
> > 
> > switch var x = (interface{}(true)).(type) { 
> > default: 
> > _ = x 
> > } 
> 
> That syntax adds no functionality and, at least to me, seems uglier 
> and harder to read. 
> 
> Ian 
> 
> So the reason of adding short variable declarations is just to avoid 
> so-called ugliness?
> 
> 
> -- 
> 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] Are short variable declarations necessary?

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 7:21 AM, T L  wrote:
>
> alternative question, why followings are not accepted in syntax:
>
> if var x = 5; x > 3 {
> _ = x
> }
>
> for var x = range []int{0,1,2} {
> _ = x
>
> }
>
> switch var x = "abc"; x {
> default:
> _ = x
> }
>
> switch var x = (interface{}(true)).(type) {
> default:
> _ = x
> }

That syntax adds no functionality and, at least to me, seems uglier
and harder to read.

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] Are short variable declarations necessary?

[T L]

alternative question, why followings are not accepted in syntax:

if var x = 5; x > 3 {
_ = x
}

for var x = range []int{0,1,2} {
_ = x

}

switch var x = "abc"; x {
default:
_ = x
}

switch var x = (interface{}(true)).(type) {
default:
_ = x
}

-- 
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: Proposal: add "future" internal type (similar to channel)

[Ian Lance Taylor]

On Tue, Oct 18, 2016 at 5:44 AM, Sokolov Yura  wrote:
>
> Then why should I watch ego of a man who didn't read this discussion,
> and posts another almost exact copy of sample code?
> Why that man do not respect other people in this chat, and I should respect
> him?
>
> I know, I will be banned after this.
> Nevertheless, why should I endure it?

I encourage you to read the code of conduct that applies to this
mailing list (https://golang.org/conduct):

People are complicated. You should expect to be misunderstood and
to misunderstand others; when this inevitably occurs, resist the urge
to be defensive or assign blame. Try not to take offense where no
offense was intended. Give people the benefit of the doubt. Even if
the intent was to provoke, do not rise to it. It is the responsibility
of all parties to de-escalate conflict when it arises.

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] Excessive garbage collection

[rlh]

>From the trace (4->4->0) it looks like the app is allocating about 4MB 
every 10ms. The app also has little (0 rounded) reachable data, sometimes 
called heap ballast. Since there is little ballast the GC is attempting to 
keep the heap from growing beyond 5MB. The GC is using about 2% of the CPU 
resources to do its job. 

All of this seems perfectly reasonable from the GC's perspective.


On Tuesday, October 18, 2016 at 12:32:47 AM UTC-4, Jiří Šimša wrote:
>
> go version go1.7.1 darwin/amd64
>
> --
> Jiří Šimša
>
> On Mon, Oct 17, 2016 at 8:02 PM, Ian Lance Taylor  > wrote:
>
>> On Mon, Oct 17, 2016 at 6:20 PM,   
>> wrote:
>> >
>> > The backend of my web server (written in Go) have recently started 
>> consuming
>> > large amounts of CPU. AFAICT, the CPU seems to be consumed by the 
>> garbage
>> > collector and I would appreciate any information that would help me 
>> track
>> > down the root cause.
>>
>> What version of Go?  What platform?
>>
>> 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] Re: Golang and WebAssembly

[bob]

+1 for 'Web-assembly is still some time in the *feature*'

On Sunday, July 12, 2015 at 8:15:41 AM UTC+1, Axel Wagner wrote:
>
> Tarrant Rollins  writes: 
> > My understanding, and I could be wrong, is that web assembly is 
> > largely a binary pre-parsed tree of asm.js source. I imagine it is 
> > easier to add a deploy target to gopherjs then anything else since it 
> > already has the logic for expressing go in JavaScript. 
>
> I assume, the way to webassembly for go will be llgo. Very simply, 
> because it's a llvm frontend, there will be an llvm backend for 
> web-assembly, so it should be pretty much trivial combining the two. 
>
> Anyway. Web-assembly is still some time in the feature. There isn't even 
> so much as a specification. I wouldn't sweat it quite yet. 
>

-- 
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: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Respect is not only "use of right words and polite phrases".
Respect is being attentive.

And that is why I ask you to excuse me for misspelling your name, 
Konstantin.

вторник, 18 октября 2016 г., 14:37:44 UTC+3 пользователь Konstantin 
Khomoutov написал:
>
> On Tue, 18 Oct 2016 01:10:36 -0700 (PDT) 
> Sokolov Yura  wrote: 
>
> > > If you want to make it possible, it's pretty easy: 
> > https://play.golang.org/p/YWYFSL2QTe 
> > 
> > Thank you for fifth copy of almost same code. I clearly have no 
> > enough experience to use close of channel and `sync.Once`. Do you 
> > really think so? 
>
> Do you really think we here have any desire to watch you playing smart 
> ass?  Your stream of ego pushing has been already cut in [1]; please 
> get easier on it here as well. 
>
> 1. https://github.com/golang/go/issues/17466 
>

-- 
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: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Konstantive,

Then why should I watch ego of a man who didn't read this discussion,
and posts another almost exact copy of sample code?
Why that man do not respect other people in this chat, and I should respect 
him?

I know, I will be banned after this.
Nevertheless, why should I endure it?

вторник, 18 октября 2016 г., 14:37:44 UTC+3 пользователь Konstantin 
Khomoutov написал:
>
> On Tue, 18 Oct 2016 01:10:36 -0700 (PDT) 
> Sokolov Yura  wrote: 
>
> > > If you want to make it possible, it's pretty easy: 
> > https://play.golang.org/p/YWYFSL2QTe 
> > 
> > Thank you for fifth copy of almost same code. I clearly have no 
> > enough experience to use close of channel and `sync.Once`. Do you 
> > really think so? 
>
> Do you really think we here have any desire to watch you playing smart 
> ass?  Your stream of ego pushing has been already cut in [1]; please 
> get easier on it here as well. 
>
> 1. https://github.com/golang/go/issues/17466 
>

-- 
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: Proposal: add "future" internal type (similar to channel)

[Konstantin Khomoutov]

On Tue, 18 Oct 2016 01:10:36 -0700 (PDT)
Sokolov Yura  wrote:

> > If you want to make it possible, it's pretty easy: 
> https://play.golang.org/p/YWYFSL2QTe 
> 
> Thank you for fifth copy of almost same code. I clearly have no
> enough experience to use close of channel and `sync.Once`. Do you
> really think so?

Do you really think we here have any desire to watch you playing smart
ass?  Your stream of ego pushing has been already cut in [1]; please
get easier on it here as well.

1. https://github.com/golang/go/issues/17466

-- 
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] gomobile service daemon

[Joe Blue]

Hey all,

gomobile when building complete apps (not binding), compiles into a 
NativeActivity as i understand it. 
Can one of these expose http services locally and run as a daemon service ?

thanks in advance


-- 
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 no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Aram Hăvărneanu]

> On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck  wrote:
>> bytes.Replace(s []byte, pos int, len uint, new []byte)
>
> I have no idea what this bizarre hypothetical function does. It's an
> awful interface that aims to solve an unknown problem nobody has
> claimed to have.
>
> Also, bytes.Replace already exists.
>

Also, slice lengths are signed integers, not unsigned integers. I
suggest you familiarize more with slices before suggest these
"improvements".

-- 
Aram Hăvărneanu

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

Re: [go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Aram Hăvărneanu]

On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck  wrote:
> bytes.Replace(s []byte, pos int, len uint, new []byte)

I have no idea what this bizarre hypothetical function does. It's an
awful interface that aims to solve an unknown problem nobody has
claimed to have.

Also, bytes.Replace already exists.

-- 
Aram Hăvărneanu

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

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Axel, thank you. Big heartfelt thanks. You really understand me.
My respect to you.

вторник, 18 октября 2016 г., 11:55:40 UTC+3 пользователь Axel Wagner 
написал:
>
> Not all of them are wrong (in fact, almost none of them are). They just 
> don't do everything and anything you could ever choose to want from an 
> implementation so they appear unsatisfactory.
>
> Which, in the long list of issues that have been presented and remain 
> unaddressed in regards to this proposal, adds another one: Writing one 
> implementation that covers every use case you could ever have for them 
> efficiently is, indeed, hard and error-prone. Whereas covering any specific 
> use case with channels takes only a small handful of lines of trivial code.
>
> On Tue, Oct 18, 2016 at 10:17 AM, andrey mirtchovski  > wrote:
>
>> as a person happy to remain willingly ignorant of promises and futures
>> i notice from the sidelines that the concepts seem to lack clarity and
>> vision. if five different implementations got them wrong there will be
>> five different people wondering why the stdlib one isn't working
>> right. that's five too many.
>>
>> On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura > > wrote:
>> > Roger
>> >
>> >> If you want to make it possible, it's pretty easy:
>> > https://play.golang.org/p/YWYFSL2QTe
>> >
>> > Thank you for fifth copy of almost same code. I clearly have no enough 
>> experience to use close of channel and `sync.Once`.
>> > Do you really think so?
>> >
>> >> There's another idiom I quite like for futures (when there's only one
>> > possible source of the value) putting the value back after
>> > taking it out: https://play.golang.org/p/_7p69KE_RZ
>> >
>> > And that is really broken idiom. It has race condition: concurrent 
>> goroutine may put dufferent value in the channel between those two lines of 
>> code. More over, if you use blocking send here, then you will end in 
>> blocked goroutine in this case.
>> > Another mistake in this idiom: if other concurrent goroutine checks 
>> this channel within select, and that check happens between those two lines 
>> (between receive and following send), then it see empty "future".
>> > And even ir when does not lead to mistake, it serialize "broadcast": 
>> goroutines are awoken one after other, instead of being awoken in parallel.
>> >
>> > That is why I want language (or standard library) to have reliable 
>> implementation:  people should not invent bicycles with square wheels.
>> >
>> > --
>> > 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...@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: Proposal: add "future" internal type (similar to channel)

['Axel Wagner' via golang-nuts]

Not all of them are wrong (in fact, almost none of them are). They just
don't do everything and anything you could ever choose to want from an
implementation so they appear unsatisfactory.

Which, in the long list of issues that have been presented and remain
unaddressed in regards to this proposal, adds another one: Writing one
implementation that covers every use case you could ever have for them
efficiently is, indeed, hard and error-prone. Whereas covering any specific
use case with channels takes only a small handful of lines of trivial code.

On Tue, Oct 18, 2016 at 10:17 AM, andrey mirtchovski 
wrote:

> as a person happy to remain willingly ignorant of promises and futures
> i notice from the sidelines that the concepts seem to lack clarity and
> vision. if five different implementations got them wrong there will be
> five different people wondering why the stdlib one isn't working
> right. that's five too many.
>
> On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura 
> wrote:
> > Roger
> >
> >> If you want to make it possible, it's pretty easy:
> > https://play.golang.org/p/YWYFSL2QTe
> >
> > Thank you for fifth copy of almost same code. I clearly have no enough
> experience to use close of channel and `sync.Once`.
> > Do you really think so?
> >
> >> There's another idiom I quite like for futures (when there's only one
> > possible source of the value) putting the value back after
> > taking it out: https://play.golang.org/p/_7p69KE_RZ
> >
> > And that is really broken idiom. It has race condition: concurrent
> goroutine may put dufferent value in the channel between those two lines of
> code. More over, if you use blocking send here, then you will end in
> blocked goroutine in this case.
> > Another mistake in this idiom: if other concurrent goroutine checks this
> channel within select, and that check happens between those two lines
> (between receive and following send), then it see empty "future".
> > And even ir when does not lead to mistake, it serialize "broadcast":
> goroutines are awoken one after other, instead of being awoken in parallel.
> >
> > That is why I want language (or standard library) to have reliable
> implementation:  people should not invent bicycles with square wheels.
> >
> > --
> > 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] Re: Proposal: add "future" internal type (similar to channel)

[andrey mirtchovski]

as a person happy to remain willingly ignorant of promises and futures
i notice from the sidelines that the concepts seem to lack clarity and
vision. if five different implementations got them wrong there will be
five different people wondering why the stdlib one isn't working
right. that's five too many.

On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura  wrote:
> Roger
>
>> If you want to make it possible, it's pretty easy:
> https://play.golang.org/p/YWYFSL2QTe
>
> Thank you for fifth copy of almost same code. I clearly have no enough 
> experience to use close of channel and `sync.Once`.
> Do you really think so?
>
>> There's another idiom I quite like for futures (when there's only one
> possible source of the value) putting the value back after
> taking it out: https://play.golang.org/p/_7p69KE_RZ
>
> And that is really broken idiom. It has race condition: concurrent goroutine 
> may put dufferent value in the channel between those two lines of code. More 
> over, if you use blocking send here, then you will end in blocked goroutine 
> in this case.
> Another mistake in this idiom: if other concurrent goroutine checks this 
> channel within select, and that check happens between those two lines 
> (between receive and following send), then it see empty "future".
> And even ir when does not lead to mistake, it serialize "broadcast": 
> goroutines are awoken one after other, instead of being awoken in parallel.
>
> That is why I want language (or standard library) to have reliable 
> implementation:  people should not invent bicycles with square wheels.
>
> --
> 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: Proposal: add "future" internal type (similar to channel)

[Sokolov Yura]

Roger

> If you want to make it possible, it's pretty easy: 
https://play.golang.org/p/YWYFSL2QTe 

Thank you for fifth copy of almost same code. I clearly have no enough 
experience to use close of channel and `sync.Once`.
Do you really think so?

> There's another idiom I quite like for futures (when there's only one 
possible source of the value) putting the value back after 
taking it out: https://play.golang.org/p/_7p69KE_RZ 

And that is really broken idiom. It has race condition: concurrent goroutine 
may put dufferent value in the channel between those two lines of code. More 
over, if you use blocking send here, then you will end in blocked goroutine in 
this case.
Another mistake in this idiom: if other concurrent goroutine checks this 
channel within select, and that check happens between those two lines (between 
receive and following send), then it see empty "future".
And even ir when does not lead to mistake, it serialize "broadcast": goroutines 
are awoken one after other, instead of being awoken in parallel.

That is why I want language (or standard library) to have reliable 
implementation:  people should not invent bicycles with square wheels.

-- 
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] simplifying freeing CString

[andrew . smith]

Thanks very much for your replies. I guess the killer argument is that 
finalizers are not guaranteed to run! I didnt know that. Just to be clear, 
Im not intending exposing WrappedString to my clients only standard go 
strings, everything *should* be freed up when my outer wrapper function 
exits (e.g. using defer), but there is definitely a high chance of 
forgetting one of these at some point.

I did start out planning to use the defer approach and trying to find a way 
to simplify writing these wrappers and avoid memory leaks through 
programmer error. 

On the defer approach. Is there any way, in a unit test to check that all 
CString objects have been freed? e.g. Can I get a list of all existing 
CString objects and walk it somehow?  

Thanks again,

Andy


On Monday, October 17, 2016 at 11:40:24 PM UTC+1, Pietro Gagliardi 
(andlabs) wrote:
>
>
> On Oct 17, 2016, at 5:03 PM, andrew...@miracl.com  wrote:
>
> Hi,
>
> When using cgo its my understanding that strings created with C.CString 
> must be freed with C.free, but yet numeric types do not need to be 
> explicitly freed.
>
>
> Yes. This is because strings in C are not first class objects like they 
> are in Go. In C, a string is an array of bytes that ends with a byte whose 
> value is 0, represented as '\0' in C and '\000' in Go.
>
> When you create a string using the "..." syntax, the string is made part 
> of the executable data. You cannot legally modify these strings, and they 
> do not need to be freed. All other strings need to be stored in a buffer 
> large enough for all those bytes (plus the extra null byte). This is 
> analogous to manipulating a slice in Go. If the string is created at 
> compile time (such as being stored in a char[512] or so), you don't have to 
> worry about managing the memory. But a string created at runtime must be 
> explicitly allocated, and since C does not have a garbage collector, must 
> be explicitly freed as well.
>
>
> Firstly, is CString a special case here, or are there other types that 
> need to be explicitly freed as well?
>
>
> C.CString() is the most obvious case. C.CBytes() (new in 1.7) also counts, 
> as does anything else allocated with the standard C malloc(), calloc(), and 
> realloc() functions, either directly or indirectly.
>
>
> Secondly, Im writing a lot of wrappers to cgo functions that will 
> requiring converting go 'string' arguments in the outer function, into 
> C.String arguments in the cgo inner function. Im looking for a simple way 
> to ensure that I dont create any memory leaks. In view of this I have an 
> idea to wrap the CString in a go struct and set the finalizer to free the 
> CString :
>
> // -- wrapped.go 
> --
>
> package golasso
>
> import (
> // #include 
> "C"
> "fmt"
> "runtime"
> "unsafe"
> )
>
> type WrappedString struct {
> s *C.char
> }
>
> func FreeWrappedString(s *WrappedString) {
> fmt.Print("Freeing WrappedString")
> C.free(unsafe.Pointer(s.s))
> }
>
> func NewWrappedString(s string) WrappedString {
> wrappedString := WrappedString{s: C.CString(s)}
> runtime.SetFinalizer(, FreeWrappedString)
> return wrappedString
> }
>
>
> // --
>
> func simulatedCCall(s *C.char) {
>
> fmt.Print("simulated C call")
>
> }
>
> // -- wrapped_test.go 
> --
> package golasso
>
> import (
> "runtime"
> "testing"
> )
>
> func TestWrapped(t *testing.T) {
> simulatedCCall(NewWrappedString("fred").s)
> t.Logf("simulated C call")
> runtime.GC()
> }
>
>
>
>
>
>
>
> I'm not sure what your question is. Idiomatic cgo code just uses defer 
> though:
>
> cstr := C.CString(str)
> defer C.free(unsafe.Pointer(cstr))
>
> NB: I do realise that, in a production scenario, it might be a long time 
> before the GC runs and therefore a long time before the GC calls the 
> finalizer to free the CString. Im not so worried about this, as my primary 
> concern is ensuring that *every* CString is definitely going to be freed at 
> some point, and therefore I have no *true* memory leaks.
>
> What are the pros/cons of this? Is it even correct? Is there an easier way 
> to achieve this?
>
>
> Finalizers are not guaranteed to run, even during a garbage collect. You 
> may accidentally be letting your C string escape to the heap without 
> knowing it. I'm not sure why we even have finalizers, or why they're public 
> API.
>
> Exposing C strings outside your package isn't really a good idea anyway. 
> Convert when necessary to keep things safer.
>
> Andy
>
>
> -- 
> 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 

Re: [go-nuts] Re: Proposal: add "future" internal type (similar to channel)

[roger peppe]

On 17 October 2016 at 17:18, Sokolov Yura  wrote:
>
> понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto Zanotto
> написал:
>>
>> I missed the chance to comment on github...
>>
>> This also works for implementing futures and it's simple, type-safe and
>> can be used with select:
>> https://play.golang.org/p/VDT36rC5A-
>> Of course the syntax is not as nice as built-in futures.
>
>
> Roberto, no it doesn't work.
> You miss possibility of filling future from several (usually, two)
> concurrently running goroutines.

I'd suggest that this requirement is fairly unusual. For example,
I just glanced at the C++ future implementation which suggests
using std::promise::set_value to set the associated value, and that
raises an exception if you try to set the value twice.

If you want to make it possible, it's pretty easy:
https://play.golang.org/p/YWYFSL2QTe

There's another idiom I quite like for futures (when there's only one
possible source of the value) putting the value back after
taking it out: https://play.golang.org/p/_7p69KE_RZ
Quite a while ago I wrote a blog post that leveraged that idiom to
make a kind of broadcast channel: https://rogpeppe.wordpress.com/2009/12/

That technique is also applicable to having multiple values in a channel
to implement a pool of available tokens.

BTW here's an example of a Go package that uses the future idiom
quite a bit: https://godoc.org/github.com/hashicorp/raft#ApplyFuture
It doesn't seem so onerous to do something like this without
needing direct support in the language (it would be easy
to add a wait channel too).

  cheers,
rog.

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