Thanks Liam,
your suggested placement would make it somehow impossible (or at least I
cannot see it right now) to use with someExpression?.someMember
If I am not mistaken, yours is close to the currently proposed "try", just
replacing it with ?, am I right on that ?
A.
On Monday, July 1, 2019
One other thing to think about - 500 qps is a lot for a single server if things
start blocking and you have a low memory cap. Imagine the scenario where the
DynamoDB “locks up / heavy delays due to IO contention / something”, depending
on how your server is written/configured it may still keep
Are you using anything like fast-http, or such? Have you tried running the
server with the race-detector enabled? I could see a race condition causing a
rare failure that causes the code to go into a ‘spinning loop’ preventing GC to
work properly. It’s a guess but I would try that to rule out
Does your process use mmap? Maybe you are leaking there, as this counts against
process memory size.
> On Jul 1, 2019, at 9:11 PM, Mighty Guava wrote:
>
> I don't understand. What would adding runtime.Goscheduled() do here? I don't
> have any explicit loops in this service.
>> On Jul 1,
One theory you advanced is of a desperate garbage collector. If you prevent
it from running all along, then maybe that could be possible. Pursuing that
line of reasoning I though you could ensure it’s chances with gosched() in
your code.
On Mon, Jul 1, 2019 at 7:17 PM Mighty Guava wrote:
> I
You can use the Index method on reflect.Value if it is an integer-
indexable type.
https://play.golang.org/p/07YXRPBMqo6
On Mon, 2019-07-01 at 12:45 -0700, Mark Bauermeister wrote:
> I have the following code, where the TokenMap struct is actually part
> of another package.
> idMap is not
Does adding runtime.GoSched() calls make any difference?
On Mon, Jul 1, 2019 at 5:37 PM 'Yunchi Luo' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Following that logic, a leak of TCP connections should manifest as a file
> descriptor leak. We have the process_open_fds metric from
Following that logic, a leak of TCP connections should manifest as a file
descriptor leak. We have the process_open_fds metric from Prometheus, that
is the number of open file descriptors as found in /proc//fd. The
number of descriptors overtime correlates well with the amount of traffic,
pretty
Correction:
cat go.mod
> module github.com/myuser/myproject
I had a correct go.mod in my project, I just updated it wrong when I posted
the "sanitized" example.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
Does this tool no longer work since the move to go modules?
pushd myproject/
cat go.mod
> github.com/myuser/myproject
gomvpkg -from github.com/myuser/myproject/foo/bar -to
github.com/myuser/myproject/foo/baz
> gomvpkg: src dir not found for package:
> github.com/myuser/myproject/foo/bar.
>
>
> I'm not confident that there is now more documentation in this thread in
> regards to go forward than there is anywhere else on the web.
>
I meant to say "I'm now confident that there is more ..."
What it does:
It reads an entire source package and outputs a single type alias file that
I think don't think you are going to find it in the 'heap', rather it would be in native memory.I would use the monitor the /proc/[pid] for the process, and pay attention to the 'fd','net' and 'statm' - if my theory is correct you will see growth here long before the process is killed. Since you
Below works for me.
k8s.io/api v0.0.0-20181221193117-173ce66c1e39
k8s.io/apimachinery v0.0.0-2019095121-fa6ddc151d63
k8s.io/client-go v10.0.0+incompatible
Regards,
Venky
On Mon, Jul 1, 2019 at 12:42 PM wrote:
> Can anyone share a working go module file that gets client-go and
>
I actually have a heap profile (pasted at the bottom) from about 1 second
before the service died (the goroutine that is logging "[Memory]" triggers
heap profiles once RSS > 100MB). I don't see TCP connections there. Maybe
it's too few to be sampled. How would I verify your theory? That the
A leak of the TCP connections (maybe not properly closed)? Each TCP connection will use kernel memory and process memory (local buffers), that won't be on the heap (the reference to the TCP connection will be in the Go heap, but is probably much smaller than the buffer allocation).That would be my
I have the following code, where the TokenMap struct is actually part of
another package.
idMap is not exported and thus not accessible without reflection.
Through reflection I can easily find the value of "int", which is "28".
Now, I'd like to do the opposite though. I'd like to find "28"'s
Seeing paths that begin with "_" in the go list output means those modules
are not in your GOPATH. In my case, I was collecting list of modules in a
subshell (i.e. $(shell)) which doesn't have my GOPATH. If I run my go list
command via backtick then it can use the global GOPATH define and works
Hello, I'd like to solicit some help with a weird GC issue we are seeing.
I'm trying to debug OOM on a service we are running in k8s. The service is
just a CRUD server hitting a database (DynamoDB). Each replica serves about
300 qps of traffic. There are no memory leaks. On occasion (seemingly
> In terms of how you get it, when you go to
> https://go-review.googlesource.com/c/tools/+/137076/, you should see a
> 'Download' button on the right side. If you click on that, it gives you 4-5
> options ranging from 'git fetch' to downloading a zip.
>
I did not see that before. Odd that
[*.go]
indent_size = 4
indent_style = tab
>From my base .editorconfig
On Monday, July 1, 2019 at 10:54:29 AM UTC-5, Sankar wrote:
>
> Hi
>
> We use github for our sources. Developers are free to choose their IDEs
> and tools. Sometimes, people end up committing sources using spaces instead
>
Can anyone share a working go module file that gets client-go and
apimachinery to play nicely? I tried letting go mod determine the versions
and I get:
k8s.io/apimachinery v0.0.0-20181127025237-2b1284ed4c93
k8s.io/client-go v10.0.0+incompatible
Which are incompatible and produce the
I never disputed that there were (in both camps). I disputed the original argument that preferring the input of people with extensive Go experience, over minimal Go experience was a valid approach, and argued that approach was short-sighted and error prone (for the reasons cited).Not to fan any
I am not making this argument but you are continuously referring to
experienced developer's preferences (perhaps someone else more if so I am
sorry).
Don't get me wrong. Experience is good and weigh a lot especially combined
with education and wits. Perhaps we can both concede that there are such
I don't think that has anything to do with what I said.I stated that experienced developers with minimal Go experience can probably offer deeper insights than new developers with only Go experience.The Go team is experienced developers (at least the ones I know), AND have deep Go experience (I am
This is funny since you are perfectly describing the Go core team... ;)
I really can't get my head around it that this topic generates so much
vitriol (maybe harsh).
Generics I kinda get but this is just incredible.
Don't like try? Don't use it.
On Mon, Jul 1, 2019, 18:42 Robert Engels wrote:
I think that is going to suffer greatly from sampling bias.You may have an engineer with 20+ years of programming in a variety of languages - using both exceptions, and error values, and be new to Go, but still have substantial insight as to the relative merits and drawbacks of proposed options.In
They are almost certainly caused by a 1) bug in Go, 2) improper use of CGO, 3) improper use of unsafe.With 3 being most likely, and most likely caused by overwriting memory buffers.You don't want to recover from these - need to fix the source of the problem. If you included more of the stack trace
The number of posts on this topic piqued my curiosity so I hope to add some
considerations after doing some research on this trail that I hope you find
useful.
TL;DR: It is possible that the reason for the interest in improving
"exception handling" in the proposed way is driven by individuals
Your program dereferenced a NULL pointer. This is most likely to be caused
by C/C++ code you've linked with your Go code. You'll need to find out
what function is at address 0xd9c026. Try doing "ulimit -c unlimited" to
enable a core dump that you can then examine using a debugger like gdb.
On
unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xd9c026]
goroutine 11707890 [running]:
runtime.throw(0x13c74b7, 0x5)
/usr/local/go/src/runtime/panic.go:617 +0x72 fp=0xc0080ac5f0
sp=0xc0080ac5c0 pc=0x42f5c2
runtime.sigpanic()
Hi
We use github for our sources. Developers are free to choose their IDEs and
tools. Sometimes, people end up committing sources using spaces instead of
tabs, etc. Not all developers do goimports/gofmt on save. So, we want to
automate this process. However, instead of adding git pre-commit
Ah, wasn't aware that was how finalizers were implemented in Go. I guess the
reason I never need to know that, is because of the Go error handling - never
needed to use them :)
-Original Message-
>From: Ian Lance Taylor
>Sent: Jul 1, 2019 8:46 AM
>To: Robert Engels
>Cc: Tyler
On Mon, Jul 1, 2019 at 6:20 AM Robert Engels wrote:
>
> You’ve also mentioned stack allocation without destructors again. Isn’t the
> proper way to handle this with defer (which in an exception based system
> would still run) or finalizers? Java routinely allocates on the stack using
> escape
I meant wrapping the lower level checked exceptions n a higher level exception.
E.g. DataInputException that wraps date date format exceptions, missing entry
exceptions etc. Easier for higher level functions to handle these than knowing
all of the possible low level exceptions that could be
Also, I already pointed out the problems of exceptions in functional designs
(e.g. streams), luckily and thankfully for us Go doesn’t have that concern :)
> On Jul 1, 2019, at 1:46 AM, Sanjay wrote:
>
> 3 of the most well-known new languages in the past decade (Swift, Rust, and
> Go,
I agree that exceptions are definitely not in vogue, but there are a lot of
things that are which I also don’t agree with - e.g. using Python to write
anything more than page long scripts, writing major applications in JS, etc.
As someone that lived through the C errno days, and has spent a
On Mon, Jul 1, 2019 at 3:43 AM Ian Lance Taylor wrote:
>
> Checked exceptions address some of the difficulties with exceptions.
> However, they introduce new difficulties, and I do not believe they
> work in large-scale programs.
It is essentially a nominal effect system on exceptions. My bet
On Sun, Jun 30, 2019 at 7:05 PM Jan Mercl <0xj...@gmail.com> wrote:
> On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
> wrote:
>
> > This is where the try-construct will definitely improve the ergonomics
> of the programming.
>
> With full respect to you opinion and/or personal
If it is as bad as "every sane Go shop" comes to this conclusion then I am
sure "try" will not be added...
On Mon, Jul 1, 2019 at 12:57 PM Wojciech S. Czarnecki
wrote:
> On Mon, 1 Jul 2019 12:33:16 +0200
> Henrik Johansson wrote:
>
> > That is one big strawman. I can live without "try" but
> >
On Mon, 1 Jul 2019 12:33:16 +0200
Henrik Johansson wrote:
> That is one big strawman. I can live without "try" but
> I think it would be a net gain for the language.
I think it would be not. While anyone who consider 'try()' func being awkward
and full of traps need not to use it in her code,
That is one big strawman. I can live without "try" but I think it would be
a net gain for the language.
Sign of the times that any discussion becomes polarized I guess...
On Mon, Jul 1, 2019 at 12:18 PM Denis Cheremisov
wrote:
> > I think many people like the proposal but are not vocal about
> I think many people like the proposal but are not vocal about it.
Emoji count should reflect that "silent majority" better than comments. We
have larger negative count on `try` and overwhelming 1293 vs 154 positive
count on leaving it as is. People who care generally dislike poorly thought
I've noted in several places that a 'try' expression (via keyword,
built-in, or symbol) is suitable only when the function is expected to
always succeed, and so would panic on error.
Also the symbol, which I agree is preferable, works best this way
will?(always?(work?())) vs
On Sun, Jun 30, 2019 at 7:34 PM robert engels wrote:
>
> I’ve developed systems that wrap checked exceptions in unchecked ones, but in
> every case I can think of it was to “abort to the top” - returning control
> (or exiting) - it is a specialized case of the re-throw, but I would argue it
>
3 of the most well-known new languages in the past decade (Swift, Rust, and
Go, respectively) have all eschewed exceptions for control flow in favor of
some sigil in the source code to propagate errors explicitly. Swift uses
try-statements (along with a few other control flow constructs), Rust
45 matches
Mail list logo
