Surely these issues already exist in gogo-protobuf? How are they handled
there?
On Thu, Feb 1, 2018, 08:28 'Jisi Liu' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> This is not Java specific. I just used Java as an example. For most
> protobuf implementations, there is a contract betwee
I guess a middleware wrapping any of the available rate limiters
https://godoc.org/?q=rate+limit should do the trick?
fre 2 feb. 2018 kl 11:30 skrev Patrik Iselind :
> Hi,
>
> If i define a webserver as such (taken from the docs)
>
> http.Handle("/foo", fooHandler)
>
> http.HandleFunc("/bar", fun
You can either use one of the existing other routers that have meddleware
support or you could wrap your handlers in another handler much like this:
handle("/foo",wrapHandler(rateLimiter, realHandler))
func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
*http.Request)) func(ht
Happy to help!
The limit can be anything from the link above or something more advanced
that Jesper suggested. The skeleton could be as outlined above however.
On Fri, Feb 2, 2018, 15:40 mrx wrote:
> On Fri, Feb 2, 2018 at 1:28 PM, Henrik Johansson
> wrote:
>
>> You can either
This is good news in so many ways! Finally a useable language in university
courses! Sure everyone could use a good lisp now and then but for most
engineering getting to useable stuff fast is very important.
And there is a lot of stuff there! Thank you!
lör 3 feb. 2018 kl 11:18 skrev Stefan Nilss
The GOCACHE variable. What is it's effect when building Go itself?
It doesn't disable test caching when using the resulting go tools right?
sön 18 feb. 2018 kl 19:55 skrev Lucio :
>
>
> On Sunday, 18 February 2018 04:20:39 UTC+2, Dmitriy Cherchenko wrote:
>>
>> I like how the Go team isn't trying
> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson
> wrote:
> > The GOCACHE variable. What is it's effect when building Go itself?
> > It doesn't disable test caching when using the resulting go tools right?
>
> Right.
>
> Ian
>
--
You received th
I disagree that generics would decrease readability at the call site.
Perhaps within the library where it is used but maybe not even there. The
only complexity is within the compiler and other internals. This is not
irrelevant by far but the carte blanche "generics is bad" is most often
hyperbole.
Ah, that's not what I meant but GOCACHE var itself and if it will be
permanent as a way to disable the cache.
On Mon, Feb 19, 2018, 21:00 Ian Lance Taylor wrote:
> On Sun, Feb 18, 2018 at 11:00 PM, Henrik Johansson
> wrote:
> >
> > Why I wondered was because to build
Yes I understand. I was just wondering if the GOCACHE flag is permanent or
as a temp safety in case someone encounters a bug in the caching.
On Mon, Feb 19, 2018, 21:35 Ian Lance Taylor wrote:
> On Mon, Feb 19, 2018 at 12:08 PM, Henrik Johansson
> wrote:
> > Ah, that's not
Ok, good to know. Thanks!
On Mon, Feb 19, 2018, 21:49 Ian Lance Taylor wrote:
> On Mon, Feb 19, 2018 at 12:40 PM, Henrik Johansson
> wrote:
> > Yes I understand. I was just wondering if the GOCACHE flag is permanent
> or
> > as a temp safety in case someone encounters
Well, first I'll have a look at it's magic 😀
On Mon, Feb 19, 2018, 22:06 Rob Pike wrote:
> You could say
>
> export GOCACHE=off
>
> in your bashrc to disable the cache permanently.
>
> -rob
>
>
> On Tue, Feb 20, 2018 at 8:00 AM, Henrik Johansson
I am currently running `vgo build` on a decent sized project that has a few
dependencies.
It bailed on import case it seems:
import "github.com/spf13/jwalterweatherman": module path of repo is
github.com/spf13/jWalterWeatherman, not github.com/spf13/jwalterweatherman
(wrong case)
This is a trans
Actually it seems viper imports it with lower case.
I don't remember if import paths are to be considered different if they
only differ in case.
ons 21 feb. 2018 kl 09:04 skrev Henrik Johansson :
> I am currently running `vgo build` on a decent sized project that has a
> few d
But wait. Wasn't there a mention of archive downloads instead of relying on
the different VCS's?
In the GitHub case I guess it amount to downloading releases (or any commit
I guess) as a zip or tarball.
On Wed, Feb 21, 2018, 20:54 Sam Whited wrote:
> On Wed, Feb 21, 2018, at 13:49, Peter Bourgo
That's not necessarily true.
The tool can understand from the tag and assert or even rewrite the imports
to make the compiler happy.
On Wed, Feb 21, 2018, 21:51 Sam Whited wrote:
> On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote:
> > But wait. Wasn't there a mention o
Why would that be a mistake? Working with tags and branches is what the VCS
is for. Extracting a given version and using that per the convention that
the import ends with the major version sounds very reasonable.
On Wed, Feb 21, 2018, 22:51 Zellyn wrote:
> On Wednesday, February 21, 2018 at 4:45
A sidenote is that there seems to always be issues with using kubernetes
client.
Is it structured very un Go-ish?
Very nice writeup!
NB: I was also hit by the casing issue with the same viper dependency.
fre 23 feb. 2018 kl 08:28 skrev David Anderson :
> I should add: even though I spent severa
I am sure it's really cool but the docs are in chinese I assume. Most other
projects speared by non native English speakers still write in English.
Is a translation available?
On Fri, Mar 2, 2018, 14:44 wrote:
> https://github.com/aliyun/alibaba-cloud-sdk-go
>
> Any questions you have when usin
What do you mean atomic? The individual operations create happens before
edges afaik and since your channel is local there is nothing to worry about.
If you publish that channel then no I would say someone else can puh or
pull in between the two operations.
fre 9 mars 2018 kl 07:47 skrev Andrey Tc
That post is fantastic and horrible at the same time. It is mandatory read
for anyone endeavoring into concurrent programming however.
On Sun, Mar 18, 2018, 09:42 David Anderson wrote:
> There's a difference though. The program that uses sync/atomic will behave
> non-deterministically, but withi
Out of curiosity is it Open Tracing compatible?
On Wed, Mar 21, 2018, 02:55 Andrew Wilkins wrote:
> Hi folks,
>
> Elastic APM [0] is an open source APM solution being developed by Elastic.
> The Elastic APM server [1] is written in Go. We've recently started working
> on a package for tracing/mo
There is a PR for `date` marshalling https://github.com/gocql/gocql/pull/878
that is merged March last year.
If you have gocql older than that I suggest trying to update but I am not
sure if it helps.
Timestamp/time.Time has always worked very well for me though so if you can
switch that could be
How in the name of anything does using Maven make life easier?
Hyperbole aside I am curious. How does it help?
tis 15 maj 2018 kl 07:55 skrev Igor Maznitsa :
> as usual - to make life easier
>
>
> On Tuesday, May 15, 2018 at 8:36:40 AM UTC+3, kortschak wrote:
>>
>> Why!
>>
>> --
> You received th
ke to build everything through single command and move
> projects between machines without pain
> 4. I want distribute my projects without big notes how to build them and
> how to tune environment
>
>
> On Tuesday, May 15, 2018 at 9:31:08 AM UTC+3, Henrik Johansson wrote:
>
>
Afaik it works fine for Go programs as long as these limits translates to
things like taskset etc.
ons 12 sep. 2018 kl 08:48 skrev Leigh McCulloch :
> Hi,
>
> Does anyone here know how Go interacts with memory limits inside
> containers? (e.g. Kubernetes, Docker)
>
> Does the Go runtime have sim
taskset works for sure and I managed to crash a program with ulimit.
I thought these stuff was what the container runtimes used under the hood.
Am I missing something?
ons 12 sep. 2018 kl 16:14 skrev Ian Lance Taylor :
> On Wed, Sep 12, 2018 at 7:07 AM, robert engels
> wrote:
> > With the Azul V
Perhaps you can try https://github.com/avikivity/diskplorer to estimate how
many readers you should optimally create.
mån 17 sep. 2018 kl 11:33 skrev Thomas S :
> Is my time display method wrong ?
>
> t := time.Now()
> // Process
> fmt.Println(time.Since(t))
>
>
>
> Le dimanche 16 septembre 2018
This sounds much like the trickery people have used both successfully but
also disastrously using weak references in Java.
Is that where you got the idea from?
fre 28 sep. 2018 kl 08:36 skrev Keith Randall :
> On Thu, Sep 27, 2018 at 11:26 PM Peter Mogensen wrote:
>
>>
>>
>> On 09/28/2018 08:17
How is storing unintptrs in a map different from say java.util.WeakHashMap?
The data pointed to by the uintptrs can at any given time have been
reclaimed by the GC much the same as weak references in Java.
I am not saying you are using it the same way as one would normally use
weak references in o
That's clever but irrelevant for this discussion.
fre 28 sep. 2018 kl 14:57 skrev Jan Mercl <0xj...@gmail.com>:
> On Fri, Sep 28, 2018 at 2:53 PM Henrik Johansson
> wrote:
>
> > The data pointed to by the uintptrs ...
>
> Uintptrs are integers. They do no
erence to anything, it is just an
> integer.
>
> On Sep 28, 2018, at 8:00 AM, Henrik Johansson
> wrote:
>
> That's clever but irrelevant for this discussion.
>
> fre 28 sep. 2018 kl 14:57 skrev Jan Mercl <0xj...@gmail.com>:
>
>> On Fri, Sep 28, 2018 at 2:
Mutexes aren't expensive when compared to channels. They are usually harder
to get right and that's why there is the old Go mantra:
"Don't communicate by sharing memory; instead, share memory by
communicating."
I would say you should use what fits the use case but prefer channels if
possible.
ti
I have always used https://github.com/cespare/reflex what is the main
benefit vs this and the other quite numerous options?
tis 23 okt. 2018 kl 11:28 skrev Nelo Mitranim :
> Good day gophers!
>
> I want to highlight a certain Go development tool. My golleagues (sic) and
> I have found it quite en
I am feeling slightly ambivalent but cool and congrats!
fre 21 juli 2017 kl 18:02 skrev Michael Jones :
> Maybe not news, and certainly not big news, but I just filed a patent that
> uses Go source code to illustrate logical methods claimed in the invention.
> So if it was not already the case, G
The consensus seems to be to generate and checking artefacts such as this.
It does help with reproducibility and doesn't force the enduser to install
all kinds of possibly weird tools.
fre 28 juli 2017 kl 20:46 skrev 'Laurent Demailly' via golang-nuts <
golang-nuts@googlegroups.com>:
> This might
I don't miss Javas generics so much for the ability to create generic
libraries but for using them.
Things like map, group, filtering etc is so much simpler to write (maybe
not always read).
And it is fine to loop explicitly by hand coding but with grouping and
perhaps several levels of filtering
At home on my Arch i really prefer pacman for everything and only as a last
resort do I ever exec any curlable installer.
The problem is usually that they don't get properly updated and the
packagemanager anyway pulls in Go since it is a dependency for
something else and it is a mess with two or mo
How should I know when it is safe to omit using locks? What I have drilled
into my head is "yes you not only need a lock but every read of shared data
has to have a corresponding write that uses a lock". Lock meaning anything
that results in the proper memory effects.
I can sort of get that this e
I think I am mostly after a mental pattern to easily recognise when
synchronizations are needed.
I am decently good at this but I tend to be very conservative and use locks
and atomics perhaps when they are not needed.
But here we have several goroutines all taking part in the initialisation
itsel
But isn't this what is happening in the example? Or is write-only not
sharing?
On Thu, 3 Aug 2017, 09:23 Dave Cheney, wrote:
> IMO you need a lock whenever you are sharing a value between goroutines by
> storing it in memory.
>
> On Thu, 3 Aug 2017, 17:21 Henrik Johansson wrot
> IMO you need a lock whenever you are sharing a value between goroutines
>>>> by storing it in memory.
>>>>
>>>> On Thu, 3 Aug 2017, 17:21 Henrik Johansson
>>>> wrote:
>>>>
>>>>> I think I am mostly after a mental pattern
What is your target service you are calling? Is it available online?
tors 3 aug. 2017 kl 09:46 skrev :
>
--
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
It does help, thank you Konstantin.
tors 3 aug. 2017 kl 10:25 skrev Konstantin Khomoutov :
> On Thu, Aug 03, 2017 at 07:21:24AM +0000, Henrik Johansson wrote:
>
> [...]
> > It gets hypothetical pretty quick and usually when this happens I make
> sure
> > to create a new
Out of curiosity do you do something like this in wireshark?
ip.dst_host=="duckduckgo.com" && tcp.flags.syn == 0
My wireshark fu is really weak...
tors 3 aug. 2017 kl 11:35 skrev :
> Works, thanks a lot!!!
> Also found this related discussion:
> https://github.com/golang/go/issues/13397
>
> BR
Actually I get the same as the original program on my mac.
time ./ccode
sum=606329794183272.375000
./ccode 0.17s user 0.00s system 98% cpu 0.170 total
The Go version -O2 -Wall
time ./pow
sum=6.063297941832724e+14./pow 5.47s user 0.01s system 99% cpu 5.490 total
fre 4 aug. 2017 kl 09:38 skrev
gt; res = 6.0633e+14
>
> real 0m0.157s
> user 0m0.156s
> sys 0m0.004s
>
> So the question might be: what is CLANG doing? (and how to do this with
> Go?...)
>
>
> On Friday, August 4, 2017 at 6:04:01 PM UTC+10, Sebastien Binet wrote:
>
>>
>>
>> On
Ah of course that explains it.
On Fri, 4 Aug 2017, 11:22 Dave Cheney, wrote:
> Gcc on OS X is an alias for clang as Apple does not ship any GPLv3
> software with their os.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe f
https://i.redd.it/tfugj4n3l6ez.png
I am sorry, I couldn't help it!
ons 9 aug. 2017 kl 08:40 skrev Jakob Borg :
> On 7 Aug 2017, at 16:38, Lukas Senger wrote:
> >
> > Basically the idea is to
> > encourage writing and sharing simple self-contained functions.
>
> This sounds like a good thing, bu
I beg to differ. Most Java apps I have seen over many years almost
unanimously suffer from over-modeling. That Go encourages another style of
modeling does not make it too simple. It only makes it different which may
be good or bad according to taste.
That said, I personally think that generics wo
Not just there. I got internal server error.
On Fri, 11 Aug 2017, 11:47 Norbert Fuhs, wrote:
> Hi,
>
> it seems https://godoc.org/ is unreachable from Germany.
>
> Its also noted on Go Forums:
> https://forum.golangbridge.org/t/godoc-org-is-down/6265
>
>
> --
> You received this message because
Sorry to but in but what happened to the whole logging initiative that was
on going?
Did I miss something about that? It seems very related to this.
tors 17 aug. 2017 kl 09:10 skrev dc0d :
> As they say global variables/things are bad. But I even use a global
> Context and WaitGroup for signaling
17, 2017 at 3:14:09 AM UTC-4, Henrik Johansson wrote:
>>
>> Sorry to but in but what happened to the whole logging initiative that
>> was on going?
>> Did I miss something about that? It seems very related to this.
>>
>
> That discussion took place in this threa
I understand the the issue you are having. We had the same where we
differentiate between absent string and empty string.
It was messy with data from json but it worked.
I think "int?", Optional or Maybe are not as helpful in Go as they can be
in Java or perhaps C# since a small type with custom m
ay
> have optional fields present?
>
> If the second then surely it's a case of use protobuf/gob/the standard
> library?
> If it's the first then I guess it's a tradeoff between language complexity
> and laziness?
>
> Regards
>
> On Monday, 21 August 2017 1
No but generally I would say that _everything_ is better today than lets
say fifty years ago.
Maybe every step wasn't better than the one immediately before but many
steps later it surely is.
If there was a way to easily test language features as just pulling in the
golango.org/x libs then this co
Experience reports are very valuable but there are many things that are
hardly possible to formulate as "something that hurt and needs to be fixed".
For example the dreaded generics, it doesn't hurt much but I think that,
for me, it is more that I am so happy with Go in general that I sort of
forge
I am sorry Dave but you can ignore the needs of the many few as much as you
want but the tiny things won't go away.
There probably won't be any _written_ experience reports for most of the
little things. The things that people live through and sometimes just have
the time to email the list about a
res decades of research then I strongly disagree
with the approach.
tis 22 aug. 2017 kl 09:12 skrev Egon :
> On Tuesday, 22 August 2017 09:12:45 UTC+3, Henrik Johansson wrote:
>>
>> I am sorry Dave but you can ignore the needs of the many few as much as
>> you want but the tiny
I disagree, I think we are doing Go a disservice with this line of
reasoning.
I may be alone in this sentiment and that is fine.
tis 22 aug. 2017 kl 10:27 skrev Axel Wagner :
> On Tue, Aug 22, 2017 at 9:56 AM, Henrik Johansson
> wrote:
>
>> I am sorry but you are missing the
from generics.
Still this is not about generics but how what goes into Go 2.
On Tue, 22 Aug 2017, 11:17 Egon wrote:
> On Tuesday, 22 August 2017 10:56:52 UTC+3, Henrik Johansson wrote:
>>
>> I am sorry but you are missing the point. I think there already is a lot
>> of _exp
You are right that there is a benefit analysis to be made. I just think the
problems are more known than you do.
On Tue, 22 Aug 2017, 12:08 Egon wrote:
> On Tuesday, 22 August 2017 12:49:14 UTC+3, Henrik Johansson wrote:
>
>> The siphoning and "talking to other language design
I may suffer from a "fundamental lack of understanding" about many things
but there isn't much to misunderstand in Russ blog post. I have also seen
the talk. I simply disagree wrt generics. I appreciate that he has thought
a lot about it and needs more feedback to feel it worth continuing. I
disagr
ons 23 aug. 2017 kl 08:37 skrev Florin Pățan :
> On Wednesday, August 23, 2017 at 6:45:57 AM UTC+1, Henrik Johansson wrote:
> > I may suffer from a "fundamental lack of understanding" about many
> things but there isn't much to misunderstand in Russ blog post. I h
For all vscode users there is
https://github.com/Microsoft/vscode-go/issues/1160 to maybe vote for to get
editor support.
ons 23 aug. 2017 kl 10:57 skrev Walter Schulze :
> Thanks, that is good to know :)
> If you do, please let me know.
> It would be nice to add more projects to the user list.
>
for your patience and calm in what spun away needlessly.
On Thu, 24 Aug 2017, 00:14 Ian Lance Taylor wrote:
> On Wed, Aug 23, 2017 at 1:30 AM, Henrik Johansson
> wrote:
> >
> > Sure, I am a bit short in this but again my opinion is that experience
> > reports wrt generi
How do you code for storing a logger in context.Value? The same usual
issues with lacking a shared logger interface happens or did I miss
something neat?
On Fri, 25 Aug 2017, 08:26 Peter Mogensen wrote:
>
>
> On 2017-08-25 05:38, buchanae.o...@gmail.com wrote:
> > - We create a child logger inst
interface for
logging. There was some promising work alas no consensus afaik.
fre 25 aug. 2017 kl 08:47 skrev Peter Mogensen :
>
>
> On 2017-08-25 08:31, Henrik Johansson wrote:
> > How do you code for storing a logger in context.Value? The same usual
> > issues with lacking a sh
kl 11:14 skrev Peter Mogensen :
>
>
> On 2017-08-25 10:45, Henrik Johansson wrote:
> > Me neither but it can be very neat occasionally.
> >
> > Agreed and it also applies fine things like Tracing.
> > But logger? If you change logger implementation you have to
Ah yes unfortunate that Ians proposal was rejected.
fre 25 aug. 2017 kl 10:39 skrev 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:
> Maybe a loaded question but what is the goal of this thread? Is it to
> establish whether or not generics impact readability? In that case it
> shou
I don't know I have met many a newbie from university who didn't know their
way around the Java world but would happily work with Haskell because their
advanced courses used it.
On Mon, 28 Aug 2017, 12:30 Wojciech S. Czarnecki wrote:
> On Sun, 27 Aug 2017 17:28:07 +
> Jesper Louis Andersen
Try it out! It would be great if the scheduler and garbage collector could
be so good as to making such tricks unnecessary.
On Thu, 31 Aug 2017, 15:59 wrote:
> Hi Guys,
>
> So, we wrote a Go service which does some heavy network IO over ZMQ (using
> cgo calls).
>
> Now, we have to put this servi
If you absolutely must make sure you ever create 2 instances of any value
in the map then I guess you have to lock.
Otherwise you can maybe use map.LoadOrStore?
fre 1 sep. 2017 kl 00:18 skrev bep :
> sync.Map in Go 1.9 is a little low on examples/doc in the wild, so I
> thought I should ask here.
I think Rob is really on to something here and I have seen it evolve in my
own programming.
I tend to make simple things "flatter" and model things around cores that
don't error out and just at the boundaries evaluate and possibly produce an
error.
Is that "monadic"? Anyway it gets easier if you tr
Maybe it is better nowadays but at least last time I tried a bigger
framework the first thing that happened was I had to either change logger
or wrestle with how the framework did it's logging.
I would from experience in both Go and other languages (mostly Java, Spring
is not your friend) very much
The switching of databases can happen but I have always solved it at a
higher "service" level.
What ORM's help you with is quickly getting started and it can in some
cases help you with type safety. In the (not so) long run only the second
matter and personally I wish there was something like Slick
I always check in. It is super nice to not have to download separately and
have one transitive dep destroy everything when you need it the least.
On Fri, 15 Sep 2017, 02:37 Kevin Malachowski wrote:
> I generally vote for checking in, or at least ensuring that /something/
> has an in-house copy o
I just have a case where I was wondering if a Makefile could be the answer.
Ill try mage instead and see what it can do!
lör 23 sep. 2017 kl 07:11 skrev snmed :
> Hi Nate
>
> Awesome, i never liked make files and fortunately i could use npm scripts
> to build front and backend. I'm glad to see an
I am sorry but this type of straw man is not what Nate and others are
arguing for.
Never has anyone suggested we sacrifice quality for quantity but rather
that more better than less to turn the old adage around.
If code review can be done efficiently enough and by enough people then
more contribu
No not at all. If you can write a game engine in any language you should be
fine just try to avoid too big design decisions too early so that once you
get a better grasp of Go you can more easily refactor.
mån 2 okt. 2017 kl 06:13 skrev Aaron :
> Hi I am in a process of rewriting a realtime game
https://play.golang.org/p/xILWETuAii
I have started to use non pointer slices much more as of late.
Every time I bother measuring it is always faster and it is better for the
GC (usually, caveats apply).
It also, perhaps naively, feels safer... :)
fre 20 okt. 2017 kl 13:41 skrev Juliusz Chrobocz
No, you are right but then I have made an explicit decision that state is
important and mutable so hopefully I would take that into consideration
when exposing the data.
lör 21 okt. 2017 kl 13:00 skrev Juliusz Chroboczek :
> > I have started to use non pointer slices much more as of late.
> > Eve
I think it's the non-preemptive scheduler that hits you.
Afaik it is a known behavior that I am not sure how to fix.
I did not at all look at the solution itself.
mån 30 okt. 2017 kl 18:29 skrev :
> Dear Go-community,
>
> I noticed a very strange effect by translating the
> mutual exclusion algor
And technically they are not tracking goroutines but done things. Each
goroutine could each finish 10 things.
On Thu, 2 Nov 2017, 17:01 Andy Balholm, wrote:
> You can add goroutines to a WaitGroup as you create them. There is nothing
> that keeps you from calling Add more than once.
>
> Andy
>
>
I find continuously adding and calling done on a waitgroup a bit odd. The
waiting goroutine can continue as soon as the count is zero so there is a
race between adds and dones.
On Sat, 4 Nov 2017, 10:01 , <2891132l...@gmail.com> wrote:
> Thank you very much.Sorry I still have some question:what'
:
> Always call Add() before spawning the corresponding goroutine(s). And
> always call Add() in the same goroutine that also calls Wait(). This way
> you have no race condition between Add(), Done(), and Wait().
>
>
> On Saturday, November 4, 2017 at 10:46:21 AM UTC+1, H
Ifaik rusts safety is compiler magic. Nothing special runtime you just
can't share stuff in dangerous ways. Syntax is horrible compared to Go but
who knows sometimes it can maybe be worth it.
On Sat, 25 Nov 2017, 05:10 , wrote:
>
>
> On Thursday, November 23, 2017 at 9:15:27 AM UTC-7, Haddock wr
Hi,
https://play.golang.org/p/bLiYSsKL_7
I have perhaps missed something simple or misunderstood the contract for
MarshalText/UnmarshalText but it seems to me that it should work it just
doesn't... :)
If I uncomment the return of the parse error "BOOM" then I just get a new
"default" key with 3
:
> Think UnmarshalText needs to have a pointer receiver or you'll only be
> modifying a copy of the struct
>
> On 27 November 2017 at 23:13, Henrik Johansson
> wrote:
>
>> Hi,
>>
>> https://play.golang.org/p/bLiYSsKL_7
>>
>> I have perhaps miss
It seems that time.Time as keys exhibit the same issue:
https://play.golang.org/p/-_H3ZD6YLG
Is this really intended or a bug?
mån 27 nov. 2017 kl 11:25 skrev Henrik Johansson :
> There is a discussion here
> https://groups.google.com/forum/#!searchin/golang-dev/json$20map/gola
gt;
> This works OK: https://play.golang.org/p/KJk4iR3D3D
>
> On 27 November 2017 at 10:53, Henrik Johansson
> wrote:
> > It seems that time.Time as keys exhibit the same issue:
> > https://play.golang.org/p/-_H3ZD6YLG
> >
> > Is this really intended or a bug?
> >
using
strings as the key. A bit less typed but not unmanageable.
Thanks for clarifying everyone!
On Tue, Nov 28, 2017, 3:34 PM Marvin Renich wrote:
> * Henrik Johansson [171128 07:43]:
> > But wouldn't unmarshal just overwrite in case of more trivial keys?
> >
> > So poin
implemented by pointer
> values too), then your method couldn't change the original value, so
> the JSON unmarshaler
> just saw the zero value unchanged.
>
> On 28 November 2017 at 16:10, Henrik Johansson
> wrote:
> > The time example I have was just an example.
> &g
Huh... I could have sworn that I tried it.
Thx!
On Tue, Nov 28, 2017, 5:59 PM roger peppe wrote:
> On 28 November 2017 at 16:30, Henrik Johansson
> wrote:
> > Ok, thanks for the clarification.
> >
> > Is there some way to reliably handle these situations?
> > I
Hi,
I am befuddled by GC SW times on several seconds (seen 20s once) in the
metrics page for our app. There are several things that are strange but
perhaps I am misreading it. The same metrics page reports Max Total 35 MB
out of which 1 MB s swap the rest RSS. The response times on the service is
Now we have to rewrite all our apps to use Lambda :D
Joking aside, it is cool and good news!
lör 2 dec. 2017 kl 00:38 skrev JM :
> just announced this week at re:invent. also cloud 9 the new dev ide also
> supports go.
>
> In case anyone cares ^^^
>
> --
> You received this message because you a
the GC's view of the application.
>
> In any case these kinds of numbers, running on a real systems, and
> duplicatable on tip are worth filing an issue.
>
> On Saturday, December 2, 2017 at 3:02:30 AM UTC-5, Henrik Johansson wrote:
>>
>> Hi,
>>
>> I am be
spection. I will download the logs later today and try to generate
realistic load.
What is the overhead of running like this, aside from the obvious extra
logging?
Are there any automatic tools to analyze these logs?
lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson :
> I am sorry, I was uncle
I found https://github.com/davecheney/gcvis from +Dave Cheney
is it a good choice for inspecting the gc logs?
tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson :
> I have just added the gc tracing and it looks like this more or less all
> the time:
>
> gc 78 @253.095s 0%: 0.032+3.3+0
2017 kl 08:10 skrev Dave Cheney :
> Probably not for your scenario, gcviz assumes it can run your program
> as a child.
>
> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson
> wrote:
> > I found https://github.com/davecheney/gcvis from +Dave Cheney is it a
> good
> > cho
1 - 100 of 212 matches
Mail list logo