Go does not flag unused global variables, it is intended functionality.
I've personally found that unused global variables have a higher chance at
being benign than local variables, but there's probably an argument to be
made for flagging globals, too.
On Sat, Apr 21, 2018, 06:30 wrote:
> W
The syntax is correct: https://play.golang.org/p/t5Oi8vyCsbw
I don't think comparing an interface to a boolean in a switch is very
common. It would need some strong evidence to justify adding an exception
to the rule.
Le dimanche 22 avril 2018 02:53:14 UTC+2, Louki Sumirniy a écrit :
>
> Your s
@Silviu
But no slice expansion is happening.
On Sunday, April 22, 2018 at 5:41:11 AM UTC+4:30, Silviu Capota Mera wrote:
>
> Hi Kaveh,
>
> Change the line:
> *ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...)
>
> to
> *ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...)
>
> The bucket
The State type is just a POGO with no methods. The part that changes is the
implementation of Clone() (State, error) method.
On Sunday, April 22, 2018 at 5:18:00 AM UTC+4:30, Louki Sumirniy wrote:
>
> I only just finally wrapped my head around this stuff and forgive me if I
> have missed the poi
On Saturday, April 21, 2018 at 9:30:22 AM UTC-4, b97...@gmail.com wrote:
>
> var someInterfaceValue interface{}
> switch {
> case someInterfaceValue: // proposal: compile error: non-bool used as
> condition
> case someInterfaceValue == true: // OK
> }
>
> Sometimes carefulness is just not e
Kaveh, for this particular circumstance, based on your playground snippet,
that's why you got no race.
As per the original 2013 race detector blog post, "Because of its design,
the race detector can detect race conditions only when they are actually
triggered by running code, which means it's
In that code, isn't the interface{} typing overridden by the value assigned
to it? The override is compile-time, isn't it? Otherwise that condition
would not evaluate to true. If you change the assignment to any other value
the code will fall right through and no case will be executed.
On Sund
I ran a goroutine 3 times, at the end of each, I run runtime.GC() and print
mem stats. Just before exiting program, I do it once more. This is what I
get in each runs -
HeapSys = 720896 Alloc = 48408 TotalAlloc = 62464 StackSys = 327680 Sys =
2461696 GCSys = 63488 NumGC = 1 PauseTotalNs = 1680
That's an interesting case. It does seem to me that if you have an
interface-typed value in a no-condition switch statement then it's quite
likely to be an accident. However, AFAICS this issue applies only to the
empty interface type, so ISTM that it is unlikely to be common.
It's too late for Go
Hi all,
I needed to write an SVG renderer; something that draws an SVG file onto an
image (not to be confused with an SVG generator such as SVGo). I wanted to
do this in native go, and not rely on wrapping pre-existing C code.
The golang 2D drawing packages I could find were not capable of ren
Well, that "commonly used" is about the no-condition switch, so it's
possible that one may make this kind of mistakes, which I did and was
surprised for a moment that the Go compiler lived with it.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group
Thanks Silviu,
Even when accessing the array directly in a concurrent manner, -race does
not complain: https://play.golang.org/p/l-c2aPeOGwF
So, is this assumption correct? : As long as two goroutines are not
modifying the same item in an array, accessing it is safe.
The initial intent was to
I essentially am trying to find an effective method in Go, preferably not
too wordy, that lets me create an abstract data type, a struct, and a set
of functions that bind to a different data type, and that I can write,
preferably not in too much code, a change that allows the data type of the
e
Interface types are useful when the data structure is varied. Why not an
interface containing these varying functions as methods instead of function
types?
Matt
On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>
> I essentially am trying to find an effective method in Go, pr
your assumption: "As long as two goroutines are not modifying the same item
in an array, accessing it is safe." is not entirely correct, or is
incomplete.
Even when only one goroutine is writing to that item, and a different one
or more are reading, you still got a race, and the race detector
You will see in the code I linked in the previous message that I already do
have the interfaces in there. They can't be bound to the struct directly
because I can't specify a function type that matches the signature, thus
the use of a wrapper, and the interface types in the parameters.
I just c
FYI, I've put together a solaris x86 page on my site for Go.
It provides go 1.10 binaries, as well as gccgo binaries, for Solaris 11.
http://www.bolthole.com/solaris/go-lang.html
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe fr
Type assertion is not required in the given example (from array of structs
to interface), But you need to assert if array of one interface is type
casted to array of another interface. I started this thread to know whether
this pattern requires a language level change to avoid unwanted array co
https://github.com/golang/go/issues/24996#issuecomment-383424588
It seems that (Type).FuncName in the assignment binds to the struct... I am
glad I found an answer so quickly because my hackish solution was gonna be
implemented today.
On Monday, 23 April 2018 02:20:47 UTC+3, Louki Sumirniy wrot
If there's no uncoordinated write and read/write of the same slot, then it's
race-free.
Only reads does not need coordination.
I'm using a pattern alike: allocate a slice for the results, start the
goroutines, each writing into it's own slot, then wait all of them to complete,
and use the resu
There does still need to be a mutex for reads on an element that is being
written to. It's a minor edge case but it could cause a serious problem
when it hoppens.
On Monday, 23 April 2018 08:36:38 UTC+3, Tamás Gulácsi wrote:
>
> If there's no uncoordinated write and read/write of the same slot,
@Silviu The code is mutating same item from two goroutines. While the
original target is to create a buffer pool that their items is not being
mutated from two goroutines - actually they can not do that because at a
specific time only one goroutine has access to one buffer.
@Tamas Regarding "If
Absolutely fantastic! The series of articles were fun to work through,
and, for once the subject matter of block-chains just clicked for me!
On Saturday, April 14, 2018 at 7:53:09 PM UTC-7, no...@mycoralhealth.com
wrote:
>
>
> https://medium.com/@mycoralhealth/code-a-simple-p2p-blockchain-in-go
On Sunday, 1 April 2018 05:47:09 UTC+9, iv...@vucica.net wrote:
>
>
> This still gets escaped:
>
> https://play.golang.org/p/eZxQrHy1vCE
>
> Is this a bug? How do I avoid html/template escaping this, while still
> escaping
> href?
>
Use text/template and explicitly escape the things which need
Hi all.
LiteIDE x33.3 released!
This version support import line jump to package source file, support import
hints for all package (GOPATH / vendor) on code completer.
Refactor debug, move golang Debug/DebugTest to build menu, fix build debug
gcflags for selected go version, and better support go
25 matches
Mail list logo
