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

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

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

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

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

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,

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

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

[go-nuts] gomobile service daemon

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

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

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

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

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

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

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

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

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

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

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?

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

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

Re: [go-nuts] Excessive garbage collection

>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

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

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

Re: [go-nuts] Re: Golang and WebAssembly

+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

Re: [go-nuts] Are short variable declarations necessary?

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

Re: [go-nuts] Are short variable declarations necessary?

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.

Re: [go-nuts] Are short variable declarations necessary?

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

[go-nuts] Are short variable declarations necessary?

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) {

Re: [go-nuts] Are short variable declarations necessary?

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

[go-nuts] interface as valid method receivers ?

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

Re: [go-nuts] Excessive garbage collection

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

Re: [go-nuts] interface as valid method receivers ?

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

[go-nuts] Re: High CPU usage for process using mdns (Flame graph attached) - time spent in runtime.goexit and runtime.mstart

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

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

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

[go-nuts] New Proposal: Add support for pprof profiler labels

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

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

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

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

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

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

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

[go-nuts] Tooling experience feedback

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.

[go-nuts] Any reason make.bash does not allow you to pass asmflags?

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

[go-nuts] Re: Tooling experience feedback

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) ;

[go-nuts] Re: Tooling experience feedback

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

[go-nuts] Re: Tooling experience feedback

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

[go-nuts] Re: Tooling experience feedback

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

Re: [go-nuts] interface as valid method receivers ?

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)

Re: [go-nuts] Tooling experience feedback

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

[go-nuts] Re: Tooling experience feedback

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

Re: [go-nuts] Tooling experience feedback

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.

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

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

Re: [go-nuts] Any reason make.bash does not allow you to pass asmflags?

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

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

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

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

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

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

Re: [go-nuts] simplifying freeing CString

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

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

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

Re: [go-nuts] Are short variable declarations necessary?

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

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

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

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

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,

Re: [go-nuts] Are short variable declarations necessary?

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

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

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

[go-nuts] Re: High CPU usage for process using mdns (Flame graph attached) - time spent in runtime.goexit and runtime.mstart

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

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

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

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

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