[go-nuts] Re: Repo with multiple modules and vendoring in main module: how to avoid constant re-vendoring?

I am not sure that it is possible just out of the box, some guys use my maven plugin to work with multiple module projects because it makes some business in the area and uses maven repository to share sources. -- You received this message because you are

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

Sorry, mixed things up in the code with layer1 and layer2... var ( Layer1Error= errors.New("some error on layer 1") Layer2Error= errors.New("some error on layer 2") ) func main() { err := callLayer1Function() // do something with error } func callLayer1Function() error { err :=

[go-nuts] Re: What did you see at GopherCon 2019 (San Diego)?

You're very welcome, JuciÊ Andrade. Meanwhile, to keep my promise, here's an update on what's available in terms of videos of the various talks at GopherCon 2019. I haven't seen an update, yet, in the GopherCon Slack channel itself. But did find some related info elsewhere--It turns out each

[go-nuts] RFC for opt-in streaming support in encoding/json package

*I debated posting here, or straight to GitHub. If that's the better place, I can move the thread there. * I have long wanted proper streaming support in the `encoding/json` library. Lately I’ve been doing some digging to understand the current state of things, and I think I’ve come to grips

[go-nuts] app not compiling

Hi: can someone explain this message that I've gotten recently after installing "go version go1.12.7 linux/amd64" in a new computer and compiling an application named xorto: # xorto 2019/08/09 09:14:58 readSym out of sync The same application compiles and runs well in the same

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 8:33 AM Jonathan Hall wrote: > > I debated posting here, or straight to GitHub. If that's the better place, I > can move the thread there. I have long wanted proper streaming support in the > `encoding/json` library. Lately I’ve been doing some digging to understand >

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Can you say more? Better in which way? On Friday, August 9, 2019 at 4:46:19 PM UTC+2, burak serdar wrote: > > > Instead of modifying the existing Encoder/Decoder, wouldn't it be > better to do this as a separate encoder/decoder? > > > > > > > > > > -- > > You received this message because

[go-nuts] Distributing task execution

Hi, We have used goLang for developing the web based application using micro service pattern. Each and every service will be scale as per demand. here, few of the functionality have to be worked periodically as *cron* , it is easy on the server is just one but if it is scaled then the problem

Re: [go-nuts] Re: Upgrade to Go1.12.7 problem [SOLVED]

On Mon, 5 Aug 2019 18:58:02 -0700 (PDT), you wrote: >I discovered that /usr/local/go was still version 1.11 for whatever reason >Ubuntu did not update that directory when I installed go via apt/dpkg This is correct behaviour, see below. >I therefore downloaded

Re: [go-nuts] Distributing task execution

Hey there, What you're describing is a distributed task scheduler. I am not aware of any frameworks for you to integrate this into your application in Go, although something in the stream processing family of libraries might be able to help if that's what you really want. That said, I generally

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Thanks for the reply. My responses inline below. On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote: > > On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall > wrote: > > > > Can you say more? Better in which way? > > Better in the way that it wouldn't change existing code. That

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall wrote: > > Can you say more? Better in which way? Better in the way that it wouldn't change existing code. Also, I think the use cases for existing and proposed json encoders/decoders are different enough to justify a separate implementation. A wihle

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

In other environments (e.g. Java), the streaming processors are distinct from the instance oriented - usually for good reason as the APIs are very different - the former is usually event based, and the latter returns realized instances as a whole or an error. The streaming processors can often

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

An interesting observation. Although in a sense, we already have the decoding half of that low-level streaming API exposed by way of the `json.Decoder` type. Would you be suggesting that a separate, stream-based API makes sense even within the stdlib? I'm not really sure what that separate

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

This is the right way. What is the issue you are facing ? See https://tip.golang.org/pkg/errors/ for more info. You can check for Layer1Error and Layer2Error using the Is function errors.Is(err, Layer1Error) errors.Is(err, Layer2Error) On Friday, 9 August 2019 19:09:24 UTC+5:30, Alex wrote: >

Re: [go-nuts] app not compiling

Insufficient information. What is "xorto"? What packages does it import? Googling "readsym out of sync" turns up a few mentions such https://github.com/golang/go/blob/master/src/cmd/link/internal/objfile/objfile.go On Fri, Aug 9, 2019 at 7:38 AM wrote: > Hi: > > can someone explain this

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, 9 Aug 2019, at 3:33 PM, Jonathan Hall wrote: > *I debated posting here, or straight to GitHub. If that's the better place, I > can move the thread there. * I have long wanted proper streaming support in > the `encoding/json` library. Lately I’ve been doing some digging to > understand

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

Yes, sure. This is always possible. :-) But this is kind of writing your own error wrapper. I was just wondering if this is somehow possible with the new error wrapper like it was with https://github.com/pkg/errors. Am Freitag, 9. August 2019 19:35:42 UTC+2 schrieb Agniva De Sarker: > > I see.

[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

Hi Agniva, the problem is: In the main function is no information that there was an Layer2 error (layer2 error is not included in the error anymore). I don't know how to take the error from layer2 and wrap another error (layer1-error) around it. You can only use the verb "%w" once in a

Re: [go-nuts] app not compiling

On Fri, Aug 9, 2019 at 7:38 AM wrote: > > can someone explain this message that I've gotten recently after installing > "go version go1.12.7 linux/amd64" in a new computer and compiling an > application named xorto: > > # xorto > 2019/08/09 09:14:58 readSym out of sync > > The same

[go-nuts] I know you cannot kill a goroutine, but ...

Background: UniVerse is a Pick model, multivalue database, https://groups.google.com/forum/#!forum/mvdbms for some general information. Multivalue databases permit more than one value in a column for a row. Since you do not know the size of the column with hundreds or thousands of values in the

Re: [go-nuts] I know you cannot kill a goroutine, but ...

The standard method in nearly all languages including go is to close the connection from another routine. Alternatively you can use a timeout/deadline on every operation. > On Aug 9, 2019, at 1:34 PM, reik...@gmail.com wrote: > > Background: > UniVerse is a Pick model, multivalue database,

[go-nuts] [security] Go 1.11.13 and Go 1.12.8 pre-announcement

Hello gophers, We plan to issue Go 1.11.13 and Go 1.12.8 on Tuesday, August 13. These are minor releases to fix multiple security issues. Following our policy at https://golang.org/security, this is the pre-announcement of those releases. Cheers, Filippo on behalf of the Go team -- You

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

The problem is that when encoding, even with json.Encoder, the entire object is marshaled, into memory, before it is written to the io.Writer. My proposal allows writing the JSON output immediately, rather than waiting for the entire process to complete successfully first. The same problem

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

Oh, thanks for pointing that out. it is indeed very similar to my proposal. What do you think the chances of getting it resurrected and merged? Is more discussion still needed with respect to sync.Pool? On Friday, August 9, 2019 at 6:15:31 PM UTC+2, Ian Davis wrote: > > You may also be

[go-nuts] [hooks] go get --post-download "make"

Hi, is it possible to run scripts after go get? -- 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. To view this discussion

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

I'm sorry, maybe I didn't understand your original concern. There is an example of doing stream based processing in the json package (using Decoder).How is this not sufficient?The only problem I see with it is that it doesn't allow error correction/continuation, but in the modern world that seems

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

I think you're right that most people are frustrated by the encoder, but as I mentioned in another message just a bit ago, the same fundamental problem exists with decoder, and for certain workloads, I believe it should be solved. Having said that, I think tackling the writer first definitely

Re: [go-nuts] [hooks] go get --post-download "make"

ok. I need the other way around (go get => calls make of bash).. thsnks On Saturday, August 10, 2019 at 12:15:18 PM UTC+10, saurabh singh wrote: > > It's possible to run go get in a make but not the other way around. > What's your use case? > > On Sat, Aug 10, 2019, 7:07 AM Dorival Pedroso >

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 2:10 PM Robert Engels wrote: > > I'm sorry, maybe I didn't understand your original concern. There is an > example of doing stream based processing in the json package (using Decoder). > > How is this not sufficient? > > The only problem I see with it is that it doesn't

[go-nuts] [security] Go 1.11.13 and Go 1.12.8 pre-announcement

Hello gophers, We plan to issue Go 1.11.13 and Go 1.12.8 on Tuesday, August 13. These are minor releases to fix multiple security issues. Following our policy at https://golang.org/security, this is the pre-announcement of those releases. Cheers, Filippo on behalf of the Go team -- You

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

On Fri, Aug 9, 2019 at 3:32 PM Jonathan Hall wrote: > > I think you're right that most people are frustrated by the encoder, but as I > mentioned in another message just a bit ago, the same fundamental problem > exists with decoder, and for certain workloads, I believe it should be solved. > >

[go-nuts] Re: buildmode=c-archive and statically linking into another lib

On Friday, April 12, 2019 at 1:21:25 PM UTC+12, Chao Chen wrote: > Do you any progress to solve the problem? I meet the same problem. > > > when I call golang build shared library on python from alpine 3.9 > container.failed with OSError: Error relocating ./cc.so: : initial-exec TLS > resolves

Re: [go-nuts] [hooks] go get --post-download "make"

It's possible to run go get in a make but not the other way around. What's your use case? On Sat, Aug 10, 2019, 7:07 AM Dorival Pedroso wrote: > Hi, is it possible to run scripts after go get? > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts"