Re: [go-nuts] Built-in log Package

That may be (still IMH-Experience in the majority of cases, this is the proper default to go). But the main concern to express here is, the default logger should accept an interface like *Output* instead of *io.Writer*. That way any necessary mechanism can be added without touching the log pack

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

On 14 August 2017 at 07:08, 'Axel Wagner' via golang-nuts wrote: > For the general interest: I wrote up my thoughts on this in a lengthy blog > post: > Why context.Value matters and how to improve it > In particular, I sketch a design how context.Value could be made a > language-level feature remo

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

On Mon, Aug 14, 2017 at 12:10 PM, roger peppe wrote: > Thanks for the blog post. ISTM that you're essentially proposing > package-scoped thread-local variables. To be clear: I am not proposing anything, really :) I'm just trying to separate the different concerns people have about context.Value

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

On 14 August 2017 at 11:37, Axel Wagner wrote: > On Mon, Aug 14, 2017 at 12:10 PM, roger peppe wrote: >> >> Thanks for the blog post. ISTM that you're essentially proposing >> package-scoped thread-local variables. > > > To be clear: I am not proposing anything, really :) I'm just trying to > sep

[go-nuts] ungetc behavior in go

I want to do something analogous to this C code. c = getchar() if (isdigit(c)) { ungetc(c, stdin); scanf("%d", &num); } In fmt package, fmt.Scanf("%d", &num) exists but ungetc doesn't exist. For bufio package, Peek function exists which is great but there is no ReadInt. Is there an elegant so

Re: [go-nuts] ungetc behavior in go

On Mon, Aug 14, 2017 at 05:09:00AM -0700, Doğan Kurt wrote: > I want to do something analogous to this C code. > > c = getchar() > > if (isdigit(c)) { > ungetc(c, stdin); > scanf("%d", &num); > } > > In fmt package, fmt.Scanf("%d", &num) exists but ungetc doesn't exist. For > bufio package, Pe

[go-nuts] Receiving Post Using Go

Hello guys, I would want to inquire how I can receive POST data from a URL using Golang. A case study would be where a system sends a username and password via POST and my Go receiving file reads the post and the values. Thank you in advance. -- You received this message because you are subsc

Re: [go-nuts] ungetc behavior in go

> > Consider combining using the bufio package and scanning form a buffered > reader using fmt.Fscanf(). > Great worked like a charm. I just thought i couldn't pass *bufio.Reader to Fscanf which takes io.Reader. -- You received this message because you are subscribed to the Google Groups "

Re: [go-nuts] ungetc behavior in go

On Mon, Aug 14, 2017 at 05:43:04AM -0700, Doğan Kurt wrote: > > Consider combining using the bufio package and scanning form a buffered > > reader using fmt.Fscanf(). > > Great worked like a charm. I just thought i couldn't pass *bufio.Reader to > Fscanf which takes io.Reader. Oh, then that'

Re: [go-nuts] Receiving Post Using Go

https://golang.org/pkg/net/http/#Request.ParseForm https://golang.org/pkg/net/http/#Request.FormValue -- 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

Re: [go-nuts] ungetc behavior in go

Thanks it's perfectly clear now. I actually knew that but it didn't look immediately obvious. On Monday, August 14, 2017 at 2:51:13 PM UTC+2, Konstantin Khomoutov wrote: > > On Mon, Aug 14, 2017 at 05:43:04AM -0700, Doğan Kurt wrote: > > > > Consider combining using the bufio package and scanni

Re: [go-nuts] Receiving Post Using Go

On Mon, Aug 14, 2017 at 05:06:08AM -0700, Kennedy Kanyi wrote: > I would want to inquire how I can receive POST data from a URL using Golang. > > A case study would be where a system sends a username and password via POST > and my Go receiving file reads the post and the values. In addition to

Re: [go-nuts] Built-in log Package

On 2017-08-14 11:04, dc0d wrote: > That may be (still IMH-Experience in the majority of cases, this is the > proper default to go). > > But the main concern to express here is, the default logger should > accept an interface like /Output/ instead of /io.Writer/. I would agree, if not for the fa

Re: [go-nuts] Receiving Post Using Go

Thanks for this feedback. To be precise, Am looking at two things 1. Receiving raw post data in Go (like HTML PHP Forms) where I have a file receive.go that can read the post as it comes. 2. Receiving json data Like in PHP Json ( $data = json_decode( file_get_contents('php://input'), true);) T

[go-nuts] Re: Go based JSON Escape/Unescape

I've wrapped into a tool, and here is why I'm doing that... Usage https://github.com/go-jsonfile/jsonfiddle#usage-1 jsonfiddle esc will escape any arbitrary string so as to embed it as content of json string. This seems useless at first, but it actually allows you to embed any arbitrary file

Re: [go-nuts] Built-in log Package

Some packages tried that approach, adding levels as prefixes (which I prefer to defining methods). But did not get enough attention. Whatever approach that may get chosen for a logging package, the logger struct should implement some Logger interface and should accept an instance of another obj

Re: [go-nuts] cgo related error assigning from a ((size_T)(-1)) define

On 10 August 2017 at 23:21, Dan Kortschak wrote: > Yeah, that doesn't work. Returning the value from the C.func does > though. The whole system is pretty queasy-making. It works for me: https://play.golang.org/p/I6HSdFHMog I'd probably use a uintptr as being closer in spirit to size_t, though.

Re: [go-nuts] Built-in log Package

The main problem with the Printf-style interface is that it's not worth building real applications with. For anything with non-trivial logging needs, you need: * tagging of log lines with identifiers such as PID, host, request ID, etc * structured for easier downstream analysis by tools like the

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

Interesting, Alex - almost identical to my recent proposal , with similar conclusions about a cancellation variable. The main difference is that in my proposal you have to declare it in each scope where you'd use it, which

Re: [go-nuts] Why does vet's 'rangeloop' check only check the last statement of a loop?

On Fri, Aug 11, 2017 at 4:38 PM, Ian Lance Taylor wrote: > On Thu, Aug 10, 2017 at 1:43 PM, wrote: >> >> Yes, it makes sense that it would be impossible to really check at that >> level. What surprised me was that this does not trigger vet: >> >> for i := range slice { >> go f(i) >> _ =

Re: [go-nuts] Why does vet's 'rangeloop' check only check the last statement of a loop?

Yes, very tricky stuff. I've replied on the issue - it seems best to keep discussion in one place. Thank you very much for opening the issue! On Mon, Aug 14, 2017 at 2:35 PM, Ian Lance Taylor wrote: > On Fri, Aug 11, 2017 at 4:38 PM, Ian Lance Taylor wrote: > > On Thu, Aug 10, 2017 at 1:43 PM,

Re: [go-nuts] Built-in log Package

On 2017-08-14 18:36, dc0d wrote: > Another question that I failed to answer properly (by myself) is: are > metrics same as logs? Or they are a higher level concept (which also can > be logged)? And should logging be in charge of delivering metrics (seems > it can be)? Depends... I guess. I imple

[go-nuts] If do not release the memory created by the C.CString of CGO all the way, what would be happen?

Hey Guys, I need to call a C function with CGO, but if I release the memory of the C.CString, then the related C function returns errors. I think the C function based on the string slice(char**) created by the C.CString all the way. So, if I do not release the memory created by the C.CString of

Re: [go-nuts] cgo related error assigning from a ((size_T)(-1)) define

Well that's odd. That works for me too (after having changes the typedef to an import of stddef.h). It shouldn't be a uintptr (or even a uint64, it should be an int - for reasons that are boring and result from the C code-base design). The failure that we see is here[1] for this sha[2]. [1]https

[go-nuts] Re: Is it possible to create Application server in Golang?

I think this is what you looking for https://github.com/CargoWebServer/CargoWebServer Le mardi 22 mars 2016 07:30:18 UTC-4, Kolleru Gaurav a écrit : > > Is is possible to simultaneously run two web application created in golang > so that both application run in sequence and maintain the web flow

Re: [go-nuts] If do not release the memory created by the C.CString of CGO all the way, what would be happen?

On Mon, Aug 14, 2017 at 7:21 PM, wrote: > > I need to call a C function with CGO, but if I release the memory of the > C.CString, then the related C function returns errors. > I think the C function based on the string slice(char**) created by the > C.CString all the way. > So, if I do not releas

Re: [go-nuts] If do not release the memory created by the C.CString of CGO all the way, what would be happen?

Thanks your reply, the point is that I do not know where the C code is completely done it. So, I do not release the C.CString currently, but I worry if I have not released the C.CString, whether the Go code will crash somewhere. 在 2017年8月15日星期二 UTC+8下午12:35:05，Ian Lance Taylor写道： > > On Mon, Aug

Re: [go-nuts] If do not release the memory created by the C.CString of CGO all the way, what would be happen?

No, not releasing memory means only used memory. Crash your program only if the OOM killer is invoked (too much unreleased memory). -- 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

Re: [go-nuts] If do not release the memory created by the C.CString of CGO all the way, what would be happen?

So, in other words, if I do not release the memory of the C.CString, the Go program may be crashed caused of the OOM, right? This is not what I expect, so, I have to release the C.CString on Go side, and fix this problem(if release the C.CString immediately after invoked the C function, the C fu

Re: [go-nuts] cgo related error assigning from a ((size_T)(-1)) define

On 15 August 2017 at 03:30, Dan Kortschak wrote: > Well that's odd. That works for me too (after having changes the > typedef to an import of stddef.h). > > It shouldn't be a uintptr (or even a uint64, it should be an int - for > reasons that are boring and result from the C code-base design). I