Re: [go-nuts] Slice capacity changes

[sno]

Thanks for the explanation.

On Wednesday, August 9, 2017 at 11:50:57 PM UTC+12, Marvin Renich wrote:
>
> [I'm subscribed; reply-to set.] 
>
> * sno  [170808 21:34]: 
> > Hmm, interesting. However, wouldn't that mean that if I removed the 
> > function and did the following: https://play.golang.org/p/enI6UmYoFJ 
> the 
> > escape analysis wouldn't happen? 
>
> Why would escape analysis not happen for main just like for any other 
> function?  (main is just a function.)  By passing the value of 
> sliceHeader.Data to fmt.Printf, the address of the backing array 
> allocated for the slice escapes, so it is allocated on the heap. 
>
> And, as Jan Mercl says in another reply, the size of the backing array 
> allocated for a slice created from a literal is an implementation detail 
> that is not specified in the language spec, and so the size can vary 
> between invocations, including between different invocations of the 
> slice initialization code within the same invocation of the program 
> (e.g. if the slice is initialized within the body of a for loop). 
>
> ...Marvin 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [Blog] Context should go away for Go 2

[Lucio]

If you treat a timeout as a kind of failure, then context makes more sense. 
In fact, context deals with unblocking a procedure when this is found 
necessary. That's really all there is to it. Why it is blocked, when it 
needs to be unblocked, just confuse the picture. The context narrows the 
"damage" required to unblock something to functions that have been 
instructed how to deal with it.

In the full picture, the "error" argument to a function necessarily becomes 
part of the context, not of the argument list (return values are just a 
special case of arguments, just like the receiver is). So is a timeout, of 
course, and distinguishing them is an option in some cases, a necessity in 
others, but from a "context" perspective it is what the Univac Exec-8 
programmers rightly called a "contingency".

The name "context" could not have been more fortunate, as the context is 
very much the gift-wrap that keeps related activities linked and determines 
what happens when the defined conditions (and perhaps some unexpected ones) 
are encountered.

That, at least, is my uneducated understanding of where the "context" 
concept is heading. I'm looking forward to a much more robust programming 
paradigm when the final outcome is eventually reached.

Lucio.

On Tuesday, 8 August 2017 18:20:08 UTC+2, Piero de Salvia wrote:
>
> I agree with Dave Cheney and Michal Strba that Context should not be used 
> for storage of any kind and only serve the purpose of cancelation.
>
> In effect, the original purpose of Context, I think, was avoiding 
> cascading failure in chains of  *network* calls, where the result of one 
> call would be used as argument to the next call. In effect, a kill switch 
> on the whole chain.
>
> A deeper analysis of this feature makes me think that this is not so much 
> about goroutines (hence not so much about thread local storage) as much as 
> network failures.
>
> And finally, I think the last thing anybody wants is to pollute the whole 
> stdlib with Contexts. 
>
> To me, given these requirements, context should become embedded in all 
> network functions, just like a timeout is. 
>
> Only difference, when creating a network function (client or server) one 
> would (optionally) call SetContextName("MyContext") on it (I think the 
> namespace suggestion from plan 9 is excellent), so a chain of network calls 
> would belong to the same named context.
>
> So when code owning that chain of network calls would need to cancel (in 
> effect kill) the chain, it would just call a lib function called Cancel(ctx 
> string) and the whole chain of calls would be killed: every network 
> functions must obey a Cancel() call.
>
> As far as extending it to Reader, it does not make sense to me. The reason 
> why there is a Context today is that failures in chained network calls are 
> difficult to detect and correct, because of inherent network 
> characteristics. That is not a general case for a Reader.
>
>
> On Monday, August 7, 2017 at 3:40:05 PM UTC+2, Michal Strba wrote:
>>
>> Hi everyone!
>>
>> I've written a blog post called 'Context should go away for Go 2':
>>
>> https://faiface.github.io/post/context-should-go-away-go2/
>>
>> The post is about the cancelation problem in Go, how context package 
>> solves it, why context package is bad anyway, and that Go 2 should do 
>> something about it. Hope you enjoy reading ;)
>>
>> PS: I'm not sure if this post is acceptable for an experience report. If 
>> you think it is / isn't, let me know.
>>
>> Michal Štrba
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Trying to understand Go benchmarking

[dj]

Hi

I am trying to benchmark a key-value store written in Go. I have the code 
as shown below. There are a few lines that are specific to the store 
itself, other than that it is all related to benchmarking. I am trying to 
find the no. of keys that have valid values versus the no. of keys that 
dont have values.

Running the code below as 

go test -v --bench BenchmarkReadRandomBadger  --timeout 10m --benchtime 3m 

results in this output

===
BenchmarkReadRandomBadger/read-random-badger-1282000   
  11842 ns/op
--- BENCH: BenchmarkReadRandomBadger
bench_test.go:101: badger 13277801 keys had valid values.
bench_test.go:102: badger 7732300 keys had no values
bench_test.go:103: badger 0 keys had errors
PASS
ok  github.com/dgraph-io/badger-bench   256.448s
===

Now, based on my understanding, the values above should add up to the 
number of iterations (2000), but instead add up to 13277801+7732300 
= 21010101

Can somebody help me understand this discrepancy.

Code:

===
func BenchmarkReadRandomBadger(b *testing.B) {
// store setup
bdb, err := getBadger()
y.Check(err)
defer bdb.Close()

var totalFound uint64
var totalErr uint64
var totalNotFound uint64
b.Run("read-random-badger", func(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
var found, errored, notFound uint64
for pb.Next() {
key := newKey()
var val badger.KVItem
// get value from store
if err := bdb.Get(key, ); err == nil && val.Value() != nil {
found++
} else if err != nil {
errored++
} else {
notFound++
}
}
atomic.AddUint64(, found)
atomic.AddUint64(, errored)
atomic.AddUint64(, notFound)
})
})
b.Logf("badger %d keys had valid values.", totalFound)
b.Logf("badger %d keys had no values", totalNotFound)
b.Logf("badger %d keys had errors", totalErr)
}
===

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Check for minimum Go version

['Chris Manghane' via golang-nuts]

You might want to follow the discussion in golang.org/issue/21207 which
might be related to this, depending on the reason you need to know the
minimum Go version. `go version` doesn't return the version number on
non-tagged releases so if you're building off of tip, for example, the
output is a bit harder to parse in terms "what's the minimum tagged
version?"

Hopefully that's helpful,
Chris

On Wed, Aug 9, 2017 at 7:05 AM, Noilson Caio  wrote:

> Maybe something like this may help you
>
> #!/bin/bash## requirements: bc, awk, tr, cut##_gocurrel="$(go version|awk 
> '{print $3}'|tr -d "go"|cut -d"." -f1-2)"_gominrel="1.5"###_key=$(echo 
> "$_gominrel > $_gocurrel" | bc -l)###if [ "$_key" != "0" ]then
>   echo "Ops! Current go release is $_gocurrel and you need $_gominrel"
>   exit 1fi###
>
>
>
> On Wed, Aug 9, 2017 at 10:15 AM, Shawn Milochik 
> wrote:
>
>> Running "go version" at the command line returns a version number. You
>> can parse 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
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Noilson Caio Teixeira de Araújo
> https://ncaio.wordpress.com
> https://br.linkedin.com/in/ncaio
> https://twitter.com/noilsoncaio
> https://jammer4.wordpress.com/
> http://8bit.academy
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A humble request/challenge

[Lutz Horn]

Hi Jabari,

Am 08.08.2017 22:18 schrieb Jabari Zakiya:

Here's a link to read and download the paper:


Was your paper published in some scientific journal?

You've asked similar questions already[0]. How may replies did you get 
so far? Did anybody implement your algorithm in any other language you 
don't master yourself?


Besides, as having a degree in Mathematics: can you provide a proof that 
a) your algorithm is correct, and b) what runtime complexity it has?


Regards

Lutz

[0] https://u.lhorn.de/ma9g

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "find" for Slices like "append"

[as]

For loops are not your enemy. Cyclomatic complexity in cute_loop_functions is. 
The for loop tells you something is happening. Your contains loop is always 
running for the entire length of the slice. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Check for minimum Go version

[Shawn Milochik]

Running "go version" at the command line returns a version number. You can
parse 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 email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Check for minimum Go version

[Michael Banzon]

Hi,

Is there a way to have a (bash) script check if the version of the Go compiler 
installed is a specific minimum version?

-- 
Michael Banzon
https://michaelbanzon.com/




-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go channels overused and hyped?

[Caleb Doxsey]

Channels are very useful and necessary to really get your program using all 
the resources at your disposal. Doing that with locks or callbacks is error 
prone and makes solving some problems all but impossible. Let me give you 
an example of a pattern we used a few days ago:

We were processing message from a queue, writing some data to Cassandra, 
and then committing offsets when the work was completed. It was really 
important for the commits to come out in the same order they came in, so 
that we never commit an offset when we haven't actually written all the 
data. (on crash or restart its ok to process the same messages again 
because the writing is idempotent)

Modeled as a pipeline we had a few stages:

intake -> decode -> encode -> write to cassandra -> commit

The naive approach would be to spin up a bunch of writer goroutines, but 
then the order of messages to commit would be unpredictable. Instead we 
created two slices of channels:

ins := make([]chan intakeMessage, options.workers)
outs := make([]chan commitMessage, options.workers)

And spun up goroutines that read from one of the input channels and wrote 
to the corresponding out channel:

for i := 0; i < options.workers; i++ {
ins[i] = make(chan intakeMessage, 1)
outs[i] := make(chan commitMessage, 1)
go worker(ins[i], outs[i])
}

We then use these slices as a circular buffer and keep track of two 
pointers, one for the next available in and another for the next remaining 
out. There are 3 cases:

   1. The slice is empty, in which case we insert at 0 and increment the in 
   counter
   2. The slice is full (all workers are busy), in which case we wait until 
   a result is pushed into the channel at the out counter
   3. We're somewhere in between, in which case we use a select on either 
   the next available in channel or the next remaining out counter

So all the commits come out in the order they came in, we get nice 
parallelism and there's no blocking or polling.

There is overhead to channels but if you send messages of adequate size 
you'll barely notice it in real programs. Batch and send slices.

The thing I find remarkable about channels and goroutines is how often the 
solutions for improving the performance of a Go program are almost exactly 
the same as the solutions for distributing that program across multiple 
machines. The patterns really map well to these kinds of problems.

On Tuesday, August 8, 2017 at 2:01:12 AM UTC-4, snmed wrote:
>
> Hi Gophers
>
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> "
>  
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
>
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
>
> Cheers snmed
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Arrays, structs and marshalJSON

[Sankar P]

aah. Damn it :-) Thanks a lot. I am hitting myself for missing this.

2017-08-09 16:40 GMT+05:30 Jakob Borg :

> On 9 Aug 2017, at 12:26, Sankar  wrote:
> >
> > Now for the same, Item object, the json.Marshal function returns two
> different strings for the `Item` object.
> >
> > If you run the playground url, you will find that:
> >
> > {"Items":[{"SD":"2009-11-10T23:00"}]}
> > {"Item":{"SD":"2009-11-10T23:00:00Z"}}
> >
> > are two different outputs (notice the "seconds" and the "Z" in the
> second line). I expected both the lines to print the same output for "SD"
> as the same object is re-used for them both.
> >
> > Now, should I define MarshalJson and UnmarshalJSON function for the
> []Item too (after making it a custom struct) ?
> >
> > Or is this a bug, or do I misunderstand anything ?
>
> The issue is that you have defined MarshalJSON as a method with a pointer
> receiver, while the JSON marshaller will access it through an interface
> value that is not addressable. Instead, declare the MarshalJSON method with
> a value receiver:
>
> func (ct CustomTime) MarshalJSON() ([]byte, error) { ... }
>
> //jb
>
>


-- 
Sankar P
http://psankar.blogspot.com

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Slice capacity changes

[Marvin Renich]

[I'm subscribed; reply-to set.]

* sno  [170808 21:34]:
> Hmm, interesting. However, wouldn't that mean that if I removed the 
> function and did the following: https://play.golang.org/p/enI6UmYoFJ the 
> escape analysis wouldn't happen?

Why would escape analysis not happen for main just like for any other
function?  (main is just a function.)  By passing the value of
sliceHeader.Data to fmt.Printf, the address of the backing array
allocated for the slice escapes, so it is allocated on the heap.

And, as Jan Mercl says in another reply, the size of the backing array
allocated for a slice created from a literal is an implementation detail
that is not specified in the language spec, and so the size can vary
between invocations, including between different invocations of the
slice initialization code within the same invocation of the program
(e.g. if the slice is initialized within the body of a for loop).

...Marvin

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: "find" for Slices like "append"

[Haddock]

You can create your own generic List struct using one of the existing code 
generators like:

https://github.com/cheekybits/genny
https://github.com/taylorchu/generic
https://github.com/joeshaw/gengen
https://github.com/clipperhouse/gen
https://github.com/ncw/gotemplate
https://github.com/droundy/gotgo

and add your own find function to it.

Am Montag, 7. August 2017 16:23:57 UTC+2 schrieb marti...@programmfabrik.de:
>
> Being fairly new to Go, I am trying to evaluate if it s possible and worth 
> to move our huge C++ codebase over to Go.
>
> 1) append(sliceA, my_new_item) sliceA
>
> Why can I not append something to a Slice in place, why does it have to 
> return a new Slice?
>
> 2) find(sliceB, item_i_look_for) int, -1 for not found
>
> Why can I not find easily search for an item inside a Slice. Every other 
> language I know has this. And I need this in a generic form.
>
> Or am I missing something entirely here?
>
> Best
> Martin
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: "find" for Slices like "append"

[Haddock]

Yio

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Arrays, structs and marshalJSON

[Jakob Borg]

On 9 Aug 2017, at 12:26, Sankar  wrote:
> 
> Now for the same, Item object, the json.Marshal function returns two 
> different strings for the `Item` object.
> 
> If you run the playground url, you will find that:
> 
> {"Items":[{"SD":"2009-11-10T23:00"}]} 
> {"Item":{"SD":"2009-11-10T23:00:00Z"}}
> 
> are two different outputs (notice the "seconds" and the "Z" in the second 
> line). I expected both the lines to print the same output for "SD" as the 
> same object is re-used for them both.
> 
> Now, should I define MarshalJson and UnmarshalJSON function for the []Item 
> too (after making it a custom struct) ?
> 
> Or is this a bug, or do I misunderstand anything ?

The issue is that you have defined MarshalJSON as a method with a pointer 
receiver, while the JSON marshaller will access it through an interface value 
that is not addressable. Instead, declare the MarshalJSON method with a value 
receiver:

func (ct CustomTime) MarshalJSON() ([]byte, error) { ... }

//jb

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "find" for Slices like "append"

[Volker Dobler]

On Wednesday, 9 August 2017 09:10:30 UTC+2, marti...@programmfabrik.de 
wrote:
>
> Volker thanks for the reply. Coming from Python I can do a simple test like
>
> if item in my_array:
># do something
> else:
># do something else
>
> I can understand that it cannot be that easy in Go (and then, why not, 
> "equals" is already defined), but image you
> have to use a for-loop every time or a specialized function every time. 
> That is awkward and unnecessary.
>

See Jan's comment. This is the exact problem here.

(I think you may well assume that most people in this list know
and have experience in Python and possible a dozen other
languages too. So there is not much need showing how
something is done in Python: The question is how it could
be done in Go and we argue that it cannot be made that
simple.)

 

> I agree, that the more complex idea to have a "findFirst" with a dedicated 
> matching function
> is more complicated, but hey, sort.Slice is the same thing, isn't it? It 
> takes a comparison func to return -1, 0, or 1.
>
> func findFirst(slice interface{}, matches func(i int 
> ) int)
>

There is a major difference in sort.SortSlice and your proposed 
sort.FindFirst:
The complicated logic is in different places.
For SortSlice it is in the sorting code (and not in the less function).
For FindFirst it is in the match function (and not in finding code).
That's why it is sensible to have a function doing the heavy lifting,
the sorting but hiding a trivial (because all logic is in match) for loop
for finding the first element is not needed.

V.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Arrays, structs and marshalJSON

[Sankar]

Hi,

There is a difference in the way MarshalJSON of a struct is called when an 
instance of a struct is either part of an array or embedded directly inside 
another object. I am not sure if it is a bug or if it is the intended 
behavior. 

Please see the Go source available at: https://play.golang.org/p/NpWj4VAjrz

I have a custom struct `CustomTime` which has a MarshalJSON and an 
UnmarshalJSON function.

Now I have a struct `Item`, which has an instance of the above `CustomTime` 
struct.

There are two other structs, ItemsArray and ItemsMember where Item is part 
of an array or a direct member.

type ItemsArray struct {
Items []Item
}

type ItemsMember struct {
Item Item
}

Now for the same, Item object, the json.Marshal function returns two 
different strings for the `Item` object.

If you run the playground url, you will find that:

{"Items":[{"SD":"2009-11-10T23:00"}]} 

{"Item":{"SD":"2009-11-10T23:00:00Z"}}


are two different outputs (notice the "seconds" and the "Z" in the second 
line). I expected both the lines to print the same output for "SD" as the 
same object is re-used for them both.

Now, should I define MarshalJson and UnmarshalJSON function for the []Item 
too (after making it a custom struct) ?

Or is this a bug, or do I misunderstand anything ?

Thanks.



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Slice capacity changes

[Jan Mercl]

On Wed, Aug 9, 2017 at 2:56 AM sno  wrote:

> In the above code, the capacity prints 32. However, if you comment the
first print statement and remove the commenting on the second and run the
program again the capacity will only be 8. What is happening with
sliceHeader.Data to make its capacity grow like that?

The runtime is free to make the slice of whatever larger-than-required
capacity. The algorithm that picks a suitable memory block in the allocator
is an implementation detail and the choice can be obviously influenced by
the dynamics of the heap. IOW, the example program cannot expect any
particular capacity that can be relied upon or even necessarily
reproducible.
-- 

-j

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go channels overused and hyped?

[Jason Stillwell]

Here's the thing about channels in go. They're a primitive. Just like int 
is a primitive and string is a primitive. They're not an entire library, or 
framework. they're just a primitive.

In other languages, currency "tools" are usually provided as some part of a 
fully featured library, or package, or framework. But not in go. Go 
provides the primitive, and its up to you to use that to implement your 
actual concurrency tools.

You might try to store a date in an int. But there are lots of caveats 
along with doing so. Instead you take primitives like ints and structs and 
put them together to make a package and set of structures for dealing with 
Dates. You don't complain that int alone isn't good enough for doing all 
your date processing.

But a lot of devs see the channel and assume its some high level 
abstraction built with an API to deal with all your common situations, 
because thats what they are used to expecting from their other language 
experience. Its not though. Its just a building block. Build something with 
it, and then use that something.

On Monday, August 7, 2017 at 11:01:12 PM UTC-7, snmed wrote:
>
> Hi Gophers
>
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> "
>  
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
>
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
>
> Cheers snmed
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Can warnings of race detector be ignored and toleranted?

[Konstantin Khomoutov]

On Tue, Aug 08, 2017 at 07:52:19PM -0700, Cholerae Hu wrote:

> Some of my colleagues think that, in some cases, such as approximately 
> counting the sum total of requests, we don't need to know the accurate 
> value, so we can let several goroutines to access one variable without lock 
> or atomic operation to get the highest performance, and we can ignore the 
> warning of race detector in these cases. Is that true?

Using atomic.AddInt64() won't really affect your performance.
If it will, you should probably consider switching from Go to assembly.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "find" for Slices like "append"

[martin . rode]

Volker thanks for the reply. Coming from Python I can do a simple test like

if item in my_array:
   # do something
else:
   # do something else

I can understand that it cannot be that easy in Go (and then, why not, 
"equals" is already defined), but image you
have to use a for-loop every time or a specialized function every time. 
That is awkward and unnecessary.

I agree, that the more complex idea to have a "findFirst" with a dedicated 
matching function
is more complicated, but hey, sort.Slice is the same thing, isn't it? It 
takes a comparison func to return -1, 0, or 1.

func findFirst(slice interface{}, matches func(i int 
) int)

Just my 0.02. 


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "find" for Slices like "append"

[Volker Dobler]

On Tuesday, 8 August 2017 09:06:08 UTC+2, marti...@programmfabrik.de wrote:
>
> [...] So why not come up with
>
> func findFirst(slice interface{}, matches func(i int 
> ) bool 
> )
>
> or so?
>

Well, this looks harmless but the major work is not in iterating the slice
but in handling all the subtle cases in match. E.g. in numerical code
the NaNs, the +/-Infs, the values just formally != 0 (but too small for
general computations). For strings the various Unicode normalisation
forms, BOMs, etc. For objects without simple value semantics like
streams, channel or network connections where matching them might
change their state and might no be easily undoable.

So if match is simple like func(i int){ s[i].Id == 7 } then the proposed
findFirst function saves 2 or three lines of code. Code almost any
team gets right on the first try in 10 minutes.
But if the match is non-trivial then the 2 lines saved is not a game
changer.

So why bother?

One more point: There might be no match in the slice so this findFirst
would have to return -1 to indicate "not found". If this can happen your
code would have to handle this as well; which makes the ratio of
"lines you have to write to cover the business logic" to "lines saved
by having a generic findFirst" even bigger.
(Of course one could go down the function proliferation road and add a
mustFindFirst...)

V.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Repository of self-contained functions

[Henrik Johansson]

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, but in practice it gives you npm.
>
> //jb
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "find" for Slices like "append"

[Jakob Borg]

On 8 Aug 2017, at 09:06, martin.r...@programmfabrik.de wrote:
> 
> So why not come up with
> 
> func findFirst(slice interface{}, matches func(i int) bool) int
> 
> or so?

For what it's worth, it's not super difficult to implement this function once 
and for all if it's something that would make your life easier. It not being in 
the standard library today doesn't mean it's something you're forbidden from 
doing. The gain is just three lines of trivial code per invocation, but it's 
certainly possible.

Using it is going to be more expensive than the obvious loop so I would be 
surprised to see this function surface in the stdlib. 

//jb

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Offline Go Documentation Tools

[Tyler Compton]

> Is Visual Studio Code a .Net app that takes up lots of memory and CPU?

Worse, it's an Electron app :)
I don't personally use VSC, so I can't speak to its performance or
efficiency. However, LSP is currently supported at some level in Neovim
using a plugin, and first-class support is planned. It's possible that
there's a project to implement LSP in your editor of choice already.

On Mon, Aug 7, 2017 at 7:33 PM me  wrote:

>
>
> On Monday, July 24, 2017 at 2:52:48 PM UTC-6, Rob 'Commander' Pike wrote:
>>
>> The "go doc" (distinct from "godoc") command works fine offline. It fact
>> it never goes on line.
>>
>> -rob
>>
>>
> That's a good tip, I might be even able to use that and pipe it into an
> editor Memo/Edit widget for instant help with an F1 shortcut. Some editors
> have "tools" that you can pipe the output of a process into a status memo
> based on the context (current selected item in editor or cursor). Just
> running it at a command line and reading it like a man page is an option,
> but, I'll likely want something a bit more than that, such as a pop up
> window when I hit F1 or a shortcut.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.