Re: [go-nuts] issue with past-the-end pointer

Thank you Ian! Le mercredi 18 mars 2020 23:20:15 UTC+4, Ian Lance Taylor a écrit : > > On Wed, Mar 18, 2020 at 9:33 AM Vincent Blanchon > > wrote: > > > > In this proposal > https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md, > > it is mentioned

Re: [go-nuts] issue with past-the-end pointer

On Wed, Mar 18, 2020 at 9:33 AM Vincent Blanchon wrote: > > In this proposal > https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md, > it is mentioned past-the-end pointer and the fact it should be avoided. My > assumption is that it could lead to a bad

Re: [go-nuts] building C++ wrapper for mabain lib with go1.13

On Wed, Mar 18, 2020 at 9:59 AM Mohamed Mahmoud wrote: > > On Wednesday, March 18, 2020 at 11:59:38 AM UTC-4, Ian Lance Taylor wrote: >> >> On Wed, Mar 18, 2020 at 5:18 AM Mohamed Mahmoud wrote: >> > >> > On Wednesday, March 18, 2020 at 8:01:27 AM UTC-4, Mohamed Mahmoud wrote: >> >> >> >> >> >>>

Re: [go-nuts] Sort of misleading coverage stats

Im sorry then - I just assumed the tool would exclude or note the difference there. Personally code test coverage I take with a grain of salt because most people can’t write correct tests to begin with, so I’m almost always looking as tests in the low level packages that are used upstream. >

Re: [go-nuts] Benchmarking code that mutates its input data

The test package has methods to disable the timing - wrap the setup in these. > On Mar 18, 2020, at 10:50 AM, Sam Whited wrote: > > I'd like to quickly suggest that the "filtering without allocating" > technique from this page is probably what you want and you may want to > consider if/why

Re: [go-nuts] building C++ wrapper for mabain lib with go1.13

On Wednesday, March 18, 2020 at 11:59:38 AM UTC-4, Ian Lance Taylor wrote: > > On Wed, Mar 18, 2020 at 5:18 AM Mohamed Mahmoud > wrote: > > > > On Wednesday, March 18, 2020 at 8:01:27 AM UTC-4, Mohamed Mahmoud wrote: > >> > >> > >>> It doesn't look like the -ldflags option is getting

[go-nuts] Re: Mysterious crypto/opengpg: invalid signature: hash tag doesn’t match

Oh my ... Many thanks... On Wednesday, March 18, 2020 at 12:21:00 PM UTC-4, Brian Candler wrote: > > You didn't include the newline in the plaintext. Add "\n" to the end of > var text, and it is happy. > > https://play.golang.org/p/DG7GajcTuHx > -- You received this message because you are

[go-nuts] issue with past-the-end pointer

Hi all, In this proposal https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md, it is mentioned past-the-end pointer and the fact it should be avoided. My assumption is that it could lead to a bad memory tracking/cleaning since the write barriers keep

[go-nuts] Re: Mysterious crypto/opengpg: invalid signature: hash tag doesn’t match

You didn't include the newline in the plaintext. Add "\n" to the end of var text, and it is happy. https://play.golang.org/p/DG7GajcTuHx -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

Re: [go-nuts] libgo is more fast that grouting.

On Tue, Mar 17, 2020 at 11:12 PM 'Benjamin' via golang-nuts wrote: > > Benchmark shows that lingo is faster than goroutine. > > Many china internet companies use similar c++ libraries to support trillions > of concurrency. > Like Tencent use a smiler project libco: >

Re: [go-nuts] building C++ wrapper for mabain lib with go1.13

On Wed, Mar 18, 2020 at 5:18 AM Mohamed Mahmoud wrote: > > On Wednesday, March 18, 2020 at 8:01:27 AM UTC-4, Mohamed Mahmoud wrote: >> >> >>> It doesn't look like the -ldflags option is getting through to the linker. >>> Try >>> go build "-ldflags=all=-w -extldflags=-lmabain -v" >>> >>> Ian

Re: [go-nuts] Benchmarking code that mutates its input data

I'd like to quickly suggest that the "filtering without allocating" technique from this page is probably what you want and you may want to consider if/why you even need to benchmark this: https://github.com/golang/go/wiki/SliceTricks However, if you do need to benchmark it: On Wed, Mar 18, 2020,

[go-nuts] Benchmarking code that mutates its input data

We have a slice containing a mix of data items, some of which are deemed to be 'valid', some 'invalid'. We need to remove the invalid items. In the current implementation we have a function which takes the slice as input and removes the invalid' elements from it in place i.e. not from a copy.

[go-nuts] Mysterious crypto/opengpg: invalid signature: hash tag doesn’t match

I’m using crypto/opengpg to verify a PGP signature but constantly receive: openpgp: invalid signature: hash tag doesn't match. Sample code is available here: https://play.golang.org/p/NqjiG3n9Xk8 With the same input data from the above and gpg CLI, gpg --verify works correctly and the

[go-nuts] Re: Go lang

It sounds like you have Tomcat running, and it's listening on port 8080. If that's the case, then your go program will be unable to bind a listening socket on port 8080 at the same time. Either modify your go program to bind to a different port; or stop Tomcat before starting your go program;

[go-nuts] Recursive dependencies vendoring?

Hi : Let's say main.go is using a dependency A and A in turn using B. When I do `go mod vendoring` on main package, i see that `vendor` dir contains A artifacts plus its go.mod and go.sum files BUT I don't see the dependencies of A like B being vendoring automatically. Furthermore, when I attempt

Re: [go-nuts] Sort of misleading coverage stats

But they are callable - I'm only doing this for exported functions and methods - as I described in the initial post (and the implementation). On Wednesday, 18 March 2020 15:15:30 UTC+1, Robert Engels wrote: > > Exactly, but unless those functions are externally callable there is no > reason to

[go-nuts] Go lang

I have crud example of insert on localhost when i start with server http://localhost:8080 i get the view of apache Tomcat/8.5.43 So can u please help me out exactly what i have to write in url so that i can get the output of form. Below i have attached my go and template file if any changes

Re: [go-nuts] go build output depending on project structure

Hi Gregor, Do you mean like this 'go build -v -x main.go node.c' ? But it does not compile and gives the following output: WORK=/tmp/go-build714119815 named files must be .go files Thanks, Nitish On Wed, Mar 18, 2020 at 7:44 PM Gregor Best wrote: > Hi, > > it looks like my initial reply

Re: [go-nuts] go build output depending on project structure

Hi, it looks like my initial reply wasn't entirely correct. It should build if you pass in both the `.go` file and the `.c` file. On 18.03.20 15:02, Nitish Saboo wrote: Hi Gregor, nitish        main.go        node.c        node.h I compiled using 'go build -v -x main.go' But if my cgo

Re: [go-nuts] Sort of misleading coverage stats

Exactly, but unless those functions are externally callable there is no reason to test them in isolation. > On Mar 18, 2020, at 9:04 AM, Ondrej wrote: > >  > That omission is not really relevant. Even if I included an assertion in the > test, it wouldn't affect the point I am making. I just

Re: [go-nuts] Sort of misleading coverage stats

That omission is not really relevant. Even if I included an assertion in the test, it wouldn't affect the point I am making. I just wanted to have at least some source code to reproduce the problem - adding if Calculator(1,2) != 3 {t.Error(...)} would make it more of a complete test, but my

Re: [go-nuts] go build output depending on project structure

Hi Gregor, nitish main.go node.c node.h I compiled using 'go build -v -x main.go' But if my cgo directive is defined in main.go, this should have compiled successfully..right? But it fails with the following whereas 'go build -v -x' works fine.

Re: [go-nuts] go build output depending on project structure

Hi Gregor, Got your point.Thank you for your response. That explains why the binaries have different names post compilation. Thanks, Nitish On Wed, Mar 18, 2020 at 7:06 PM Gregor Best wrote: > Hi, > > In both `go build main.go`-examples, you tell the compiler to _only_ build > `main.go`. > >

Re: [go-nuts] go build output depending on project structure

Hi, In both `go build main.go`-examples, you tell the compiler to _only_ build `main.go`. In your first example, `main.go` probably imports both `util` and `lib` (you might want to give them less generic names by the way). The go compiler thus knows "to build `main.go`, I need to build both

[go-nuts] go build output depending on project structure

Hi, *Case 1--* I have a project called 'nitish' where the folder structure looks like the following: nitish main.go util util.go lib node.c node.h a.go When I try compiling this project in the following ways: 1) go

Re: [go-nuts] Sort of misleading coverage stats

It’s because you are not writing the top level test correctly - there is no testing at all ! > On Mar 18, 2020, at 7:02 AM, Ondrej wrote: > >  > Hey! > > There's an issue I've been grappling with for ages - say I have a custom > function, Print, that calls six other functions, FormatString,

Re: [go-nuts] building C++ wrapper for mabain lib with go1.13

On Wednesday, March 18, 2020 at 8:01:27 AM UTC-4, Mohamed Mahmoud wrote: > > > It doesn't look like the -ldflags option is getting through to the linker. >> Try >> go build "-ldflags=all=-w -extldflags=-lmabain -v" >> >> Ian >> > > I tried the new format however it still can't link

[go-nuts] Sort of misleading coverage stats

Hey! There's an issue I've been grappling with for ages - say I have a custom function, Print, that calls six other functions, FormatString, FormatBool, FormatXYZ, ..., and I have no tests. Once I write some basic tests for Print, it does call some of the other functions and from looking at my

Re: [go-nuts] building C++ wrapper for mabain lib with go1.13

> It doesn't look like the -ldflags option is getting through to the linker. > Try > go build "-ldflags=all=-w -extldflags=-lmabain -v" > > Ian > I tried the new format however it still can't link mabain lib and I get the same errors Step 25/26 : RUN cd ${MABAIN_SRC}/; go build -x -i

Re: [go-nuts] Re: Mem-Leak in Go method

Hi, Yeah, even I did not expect the program to have 29% memory usage.Not sure if this is how the Go GC works. Thanks, Nitish On Wed, Mar 18, 2020 at 12:48 AM Robert Engels wrote: > My only thought was that maybe you had more Go routines accessing it than > you thought. > > It is remains

[go-nuts] Re: How to read http.Response from http.Request

That _is_ the correct way iff req is not nil. Check your errors first. V. On Wednesday, 18 March 2020 06:22:07 UTC+1, Alexander Mills wrote: > > > hey all I am trying to read the Response from http.Request like so: > > func (ctr *Controller) Login(c *common.CPContext, req *http.Request, res >

Re: [go-nuts] libgo is more fast that grouting.

Benchmark shows that lingo is faster than goroutine. Many china internet companies use similar c++ libraries to support trillions of concurrency. Like Tencent use a smiler project libco: https://github.com/Tencent/libco I think the go team should learn some