Re: [go-nuts] decoding various JSON in specific way (according to first JSON name)

On Thu, 2 Mar 2017 12:25:47 -0800 (PST) Basile Starynkevitch wrote: > This question is related to that one > > (which gives more detailed motivation). > > Assume I have some public type > Person = struct { > PersName: s

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Thu, 2 Mar 2017 23:49:52 -0800 (PST) T L wrote: > After all, the len and cap fields of any value of string and slice > values are immutable. Could you elaborate? Are you suggesting to replace var s []string if len(s) ... if cap(s) ... with if s.len ... if s.cap ... ? If yes,

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Fri, Mar 3, 2017 at 6:49 PM, T L wrote: > After all, the len and cap fields of any value of string and slice values > are immutable. > This is slices and strings are currently. A string value contains a length and a pointer to some bytes. A slice contains a length, capacity and a pointer to

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

Very basic explanation in the faq https://golang.org/doc/faq#methods_on_basics On 03/03/2017 08:49, T L wrote: After all, the len and cap fields of any value of string and slice values are immutable. -- You received this message because you are subscribed to the Google Groups "golang-nuts" gr

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 4:27:02 PM UTC+8, Konstantin Khomoutov wrote: > > On Thu, 2 Mar 2017 23:49:52 -0800 (PST) > T L > wrote: > > > After all, the len and cap fields of any value of string and slice > > values are immutable. > > Could you elaborate? > > Are you suggesting to replace

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

Perhaps you can help the discussion by explaining the advantages you see in that change? On Fri, 3 Mar 2017, at 11:44 AM, T L wrote: > > > On Friday, March 3, 2017 at 4:27:02 PM UTC+8, Konstantin > Khomoutov wrote: >> On Thu, 2 Mar 2017 23:49:52 -0800 (PST) >> T L wrote: >> >> > Aft

[go-nuts] Re: [ANN] chasquid: An SMTP (email) server written in Go

Nice work! Have you considered "un-internalizing" some of your packages that could be useful outside your project? The spf and systemd packages looks pretty useful. Cheers, Christian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubsc

[go-nuts] h2_bundle.go:3354: http2: server: error reading preface from client xx.xxx.xxx.128:43429: remote error: tls: revoked certificate

The latest Firefox (51) produces this, FF 47 and Chrome work fine. Start.com certificate. export GODEBUG=http2client=0 export GODEBUG=http2server=0 eliminates the 'reading preface' error but the Código de error: SEC_ERROR_REVOKED_CERTIFICATE persists. Any tips? Thanks -- You received this m

[go-nuts] Is it a concurrency issue?

Hey guys, Here is my code, https://github.com/myzhan/boomer/blob/dc6893a72c2b32c27ff6d7646a55b135493ba7e1/stats.go#L33 I'm trying to figure out *why I got nil from "this.**Entries(a map)"*, and I'm really confused. I hava checked if the key exists, and if not, I put a new key in "this.Entrie

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: > > Perhaps you can help the discussion by explaining the advantages you see > in that change? > The advantage is to save a few bytes memory and make faster copying. > > > On Fri, 3 Mar 2017, at 11:44 AM, T L wrote: > > > > On Frid

Re: [go-nuts] Is it a concurrency issue?

On Fri, Mar 3, 2017 at 2:34 AM, wrote: > Hey guys, > > Here is my code, > https://github.com/myzhan/boomer/blob/dc6893a72c2b32c27ff6d7646a55b135493ba7e1/stats.go#L33 > > I'm trying to figure out why I got nil from "this.Entries(a map)", and I'm > really confused. > > I hava checked if the key exi

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Fri, Mar 3, 2017 at 5:31 AM, T L wrote: > > On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: >> >> Perhaps you can help the discussion by explaining the advantages you see >> in that change? > > > The advantage is to save a few bytes memory and make faster copying. I don't see ho

[go-nuts] Re: Is it a concurrency issue?

maps are not thread safe, so when you read/write to them, you need to use a mutex, see the "concurrency" sections here https://blog.golang.org/go-maps-in-action That is a good explanation with code samples. Thanks Diego On Friday, March 3, 2017 at 8:31:12 AM UTC-5, 詹青朋 wrote: > > Hey guys,

[go-nuts] Re: casting slice of rune to string picks up extra characters for some inputs

Go strings are UTF-8 encoded as others have mentioned. This means that each human readable character in the string is really a cluster of one or more runes. Some characters are made up of one rune, some are made up of many. Some runes combine with others to create different characters. Also, run

[go-nuts] Re: SOLID Design Patterns in GO

Dave Cheney Solid Design Patterns in Go https://www.youtube.com/watch?v=0IaBAl7onCE On Tuesday, March 29, 2016 at 9:26:31 AM UTC-6, JM wrote: > > Anyone care to elaborate on how these are altered when using Go? For > example I would think that the O and the I may have to be adjusted given > the

[go-nuts] Problem calling http.HandlerFunc

Hi everyone, I just got started with GO and decided to attempt building an HTTP API package using Gorilla Mux for an existing backend. Unfortunately i have gotten stuck on an issue with initializing my routes for the past couple of days. I tried searching for a solution online and have read a

[go-nuts] Re: h2_bundle.go:3354: http2: server: error reading preface from client xx.xxx.xxx.128:43429: remote error: tls: revoked certificate

On Friday, March 3, 2017 at 2:30:52 PM UTC+1, KLR wrote: > > The latest Firefox (51) produces this, FF 47 and Chrome work fine. > Start.com certificate. > > export GODEBUG=http2client=0 > export GODEBUG=http2server=0 > > eliminates the 'reading preface' error but the Código de error: > SEC_ERR

[go-nuts] Re: Problem calling http.HandlerFunc

The method expression (*Api).ListHandler yields a function with the signature func(*Api, http.ResponseWriter, *http.Request) To use the method value with the signature func(http.ResponseWriter, *http.Request) you need an instance of `*Api` to call its method, so you can't assign

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 10:32:25 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Mar 3, 2017 at 5:31 AM, T L > > wrote: > > > > On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: > >> > >> Perhaps you can help the discussion by explaining the advantages you > see > >> in that

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Saturday, March 4, 2017 at 12:47:10 AM UTC+8, T L wrote: > > > > On Friday, March 3, 2017 at 10:32:25 PM UTC+8, Ian Lance Taylor wrote: >> >> On Fri, Mar 3, 2017 at 5:31 AM, T L wrote: >> > >> > On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote: >> >> >> >> Perhaps you can hel

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

I seriously doubt that it's actually going to make anything faster in reality. I bet that a) copying one word or three words doesn't actually make any observable difference, but b) it's not going to actually help a lot, because in most cases you will need to copy the indirected struct anyway and c)

Re: [go-nuts] A naive question, why not move the len and cap fields of string and slice types into the underlying types?

On Friday, March 3, 2017 at 11:47:10 AM UTC-5, T L wrote: > > > Yes, the suggestion needs more allocations in creating new string and > slice values. > But it makes copying string and slice values a little faster and a little > less memory consuming. > > In most cases there is no difference b

[go-nuts] Question about go test and -cpuprofile

Say you have a package with a test suite that completes in 30 seconds on average. You run: go test -cpuprofile cpu.pprof -timeout 10s > Then whether you abort tests by hitting CTRL+C or they end with a panic due to a low timeout value, in both cases, *cpu.pprof* will be empty. Is this intended b

Re: [go-nuts] Question about go test and -cpuprofile

On Fri, Mar 3, 2017 at 9:41 AM, wrote: > Say you have a package with a test suite that completes in 30 seconds on > average. You run: > >> go test -cpuprofile cpu.pprof -timeout 10s > > > Then whether you abort tests by hitting CTRL+C or they end with a panic due > to > a low timeout value, in bo

[go-nuts] Reading http.Request form values

Initially I intended to file this as an issue on the official Github repository for Go but were referred to this page. This is the first time I am posting. I am writing a web server using Go and trying to parse form data from client. The form is sent using the POST method and I am trying to ge

Re: [go-nuts] Reading http.Request form values

Have you checked what the request body contains? I suspect this is a browser issue. fre. 3. mar. 2017 kl. 19.36 skrev : > Initially I intended to file this as an issue on the official Github > repository for Go but were referred to this page. This is the first time I > am posting. > > I am writin

Re: [go-nuts] Reading http.Request form values

The document you referenced states that the name attribute is deprecated for the form element, not for input elements. On Fri, Mar 3, 2017 at 10:31 AM, wrote: > Initially I intended to file this as an issue on the official Github > repository for Go but were referred to this page. This is the fi

Re: [go-nuts] Reading http.Request form values

Oh yes! My mistake, sorry! fre 3 mars 2017 kl 20:22 skrev Kale Blankenship : > The document you referenced states that the name attribute is deprecated > for the form element, not for input elements. > > On Fri, Mar 3, 2017 at 10:31 AM, wrote: > > Initially I intended to file this as an issue on

[go-nuts] Re: Bit mask to represent set of flags

Its easy to use bit flag operations. But more easy i think is to use a small library for this, a library like this: https://github.com/albulescu/go-bitflag luni, 17 februarie 2014, 23:29:06 UTC+2, bsr a scris: > > Hello, > > I hate to ask this question without a "play" link, but I am not sure wh

Re: [go-nuts] SOLID Design Patterns in GO

Indeed... the pattern language book is excellent and its topic being different is helpful to teach deep ideas away from language/programming context. On Wed, Mar 30, 2016 at 10:46 AM Egon wrote: > On Wednesday, 30 March 2016 00:49:59 UTC+3, Staven wrote: > > On Tue, Mar 29, 2016 at 08:26:31AM -0

[go-nuts] How Build New Golang Console App in a Main Go App?

Hello,Go Team. How Build New Golang Console App in a Main Go App? mean on a system without go compilers with main app. example : > `$go build main.go` //this is main app (i dont know how make this!) `./main file.go` and after this , build file.go and save as `file`. may compiler without go com

[go-nuts] Re: SOLID Design Patterns in GO

Point of order, my talk was called "SOLID Go Design", and talks about the SOLID design _principles_, not patterns. This is important. On Saturday, 4 March 2017 02:15:33 UTC+11, JM wrote: > > Dave Cheney Solid Design Patterns in Go > https://www.youtube.com/watch?v=0IaBAl7onCE > > On Tuesday, Marc

[go-nuts] Are there any plans for TLS 1.3?

Or, is there any recommended early replacement? -- 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

[go-nuts] do {} for x, why or why not?

I rather like Go's loops, they are simple and easy to remember, and the problem so many languages have with dozens of different loop keywords is neatly avoided. Too many loop types is simply a pain, but I think that one more wouldn't hurt... Basically the following would be helpful in some case

Re: [go-nuts] reading/writing after http.Handler returns

I'm not sure I understand what the bug report here is. Is this https://github.com/golang/go/issues/16100 ? On Thu, Mar 2, 2017 at 3:06 PM, wrote: > A few weeks ago we implemented a context that given some readClosers and > writeClosers would track if any were idle and eventually cancel the > c

[go-nuts] CPU-intensive Go applications

Hi All, I am working on some cpu-intensive Go applications. I want to avoid the scheduler from moving the tasks to various cores. I am trying to pin the code to specific CPU cores and see if I can get better, predictable performance. Is there any info available that documents various techniques,

Re: [go-nuts] do {} for x, why or why not?

I agree that a new keyword seems like overkill, which is one reason I asked for other's ideas. I don't particularly agree that there is no need for a loop that checks its condition after instead of before, but in any case it's not a big deal. Mostly I am interesting in what others think. On Fr

Re: [go-nuts] do {} for x, why or why not?

On Fri, Mar 3, 2017 at 2:00 PM, wrote: > I rather like Go's loops, they are simple and easy to remember, and the > problem so many languages have with dozens of different loop keywords is > neatly avoided. Too many loop types is simply a pain, but I think that one > more wouldn't hurt... > > Basi

[go-nuts] Re: Are there any plans for TLS 1.3?

On Friday, March 3, 2017 at 9:47:35 PM UTC, Igor Gatis wrote: > > Or, is there any recommended early replacement? > It's being worked on: https://github.com/golang/go/issues/9671#issuecomment-282091772 It looks like Adam Langley will be working on it too during the 1.9 cycle, judging by a com

Re: [go-nuts] reading/writing after http.Handler returns

Yes and I'll wait for that change, thanks! On Friday, March 3, 2017 at 2:01:25 PM UTC-8, bradfitz wrote: > > I'm not sure I understand what the bug report here is. > > Is this https://github.com/golang/go/issues/16100 ? > > > On Thu, Mar 2, 2017 at 3:06 PM, > > wrote: > >> A few weeks ago we impl

Re: [go-nuts] CPU-intensive Go applications

On Fri, Mar 3, 2017 at 2:21 PM, Tharaneedharan Vilwanathan wrote: > > I am working on some cpu-intensive Go applications. > > I want to avoid the scheduler from moving the tasks to various cores. I am > trying to pin the code to specific CPU cores and see if I can get better, > predictable perform

[go-nuts] Re: do {} for x, why or why not?

milo, How is your loop different from this? for { // if condition { break } } Peter On Friday, March 3, 2017 at 5:00:41 PM UTC-5, milo.chr...@gmail.com wrote: > > I rather like Go's loops, they are simple and easy to remember, and the > problem so m

Re: [go-nuts] CPU-intensive Go applications

Hi, Ian, thanks for the quick response and useful info. I will give it a try. Request you all to share more thoughts. Thanks dharani On Fri, Mar 3, 2017 at 2:54 PM, Ian Lance Taylor wrote: > On Fri, Mar 3, 2017 at 2:21 PM, Tharaneedharan Vilwanathan > wrote: > > > > I am working on some cpu

[go-nuts] Re: do {} for x, why or why not?

It's not really, it is just syntactic sugar. I just happen to think that this kind of loop is common enough to have dedicated syntax. Not necessarily the syntax I used in my example (that has its issues), but something similar. Your example it is how I do it myself currently :) On Friday, Marc

Re: [go-nuts] CPU-intensive Go applications

dharani, On Sat, Mar 4, 2017 at 12:03 AM, Tharaneedharan Vilwanathan < vdhar...@gmail.com> wrote: > Hi, > > Ian, thanks for the quick response and useful info. I will give it a try. > > Request you all to share more thoughts. > here is the document that sparked the discussion Ian was alluding to

[go-nuts] Feedback on naming issue when interface vs main code struct

Would appreciate some feedback on a naming issue my team has been struggling with recently. We sometimes use interfaces for mocking in tests, as described in this blogpost: https://nathanleclaire.com/blog/2015/10/10/interfaces-and-composition-for-effective-unit-testing-in-golang/. The naming i

Re: [go-nuts] Question about go test and -cpuprofile

> > I would not expect to get a CPU profile if you hit ^C. > Just curious as of why? I mean we could use *signal.Notify* for that, no? пятница, 3 марта 2017 г., 23:04:30 UTC+5 пользователь Ian Lance Taylor написал: > > On Fri, Mar 3, 2017 at 9:41 AM,

Re: [go-nuts] Question about go test and -cpuprofile

On Fri, Mar 3, 2017 at 9:18 PM, wrote: >> I would not expect to get a CPU profile if you hit ^C. > > Just curious as of why? I mean we could use signal.Notify for that, no? We could, but why should we? We can't reasonably handle every possible way that the program could crash early. If it's im

Re: [go-nuts] Re: Understanding garbage collection in Go with infinite lists

On Friday, March 3, 2017 at 9:05:50 AM UTC+2, Yota Toyama wrote: > > Nathan, > > As I posted above right after you posted, you are right. > "Memory leak" was gone when I inserted sleep at the loop end. > Thank you for your advice! > > Yota > > On Friday, March 3, 2017 at 10:39:02 AM UTC+9, Nathan

Re: [go-nuts] Re: do {} for x, why or why not?

I asked for this early...long before it was too late. (Existing valid programs ma have variables named 'do' so it is a non starter in that form. Rob's objection was wise and thoughtful. He wanted Go to be friendly to program transformation and he felt that a single uniform iteration construct woul

Re: [go-nuts] Question about go test and -cpuprofile

I thought that hitting CTRL+C(i.e. sending SIGINT) is a relatively common way to abort tests that run for too long. суббота, 4 марта 2017 г., 10:32:47 UTC+5 пользователь Ian Lance Taylor написал: > > On Fri, Mar 3, 2017 at 9:18 PM, > > wrote: > >> I would not expect to get a CPU profile if yo