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 ar
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 d
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 := callLa
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 G
*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 w
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 environemen
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
> the
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 yo
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
>https://dl.google.com/go/go1.12
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 a
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 doesn
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 skip
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 API
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:
>
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 mess
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 th
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 fmt.Erro
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 applicatio
I see. One way is to create a wrapper error type in layer1, which takes a
layer2 error. Just like os.PathError.
package main
import (
"errors"
"fmt"
)
var (
// Layer1Error = errors.New("some error on layer 1")
Layer2Error = errors.New("some error on layer 2")
)
type Layer1Error struct {
inter
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.
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
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,
>
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 r
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 all
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 receive
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 receive
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 occu
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 interest
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 m
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.
>
> H
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
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
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" grou
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 > wr
Can you show me how is it possible to do with pkg/errors ? It is not
immediately apparent to me. The Causer interface is similar to the Unwrap
interface and errors.Cause recursively unwraps an error until it finds one
which does not implements the causer interface. So just with
errors.WithMessa
You are right, I think I mixed it up with some other library, I think it
was multierr from hashicorp. Have to check that...
--
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
36 matches
Mail list logo
