Re: [go-nuts] Help

[Matthias B.]

On Wed, 5 Sep 2018 19:14:43 +0530
Kathiresh Kumar  wrote:

> How can I connect golang with mongoDB
> 

http://lmgtfy.com/?q=How+can+I+connect+golang+with+mongoDB%3F%3F%3F%3F

-- 
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] Generics as builtin typeclasses

[Matthias B.]

On Tue, 4 Sep 2018 11:57:02 -0700 (PDT)
Matt Sherman  wrote:

> Here’s a riff on generics focused on builtin typeclasses (instead of
> user contracts): https://clipperhouse.com/go-generics-typeclasses/
> 
> Feedback welcome.
> 

The main motivation behind generics has always been type-safe
containers of custom types. I'm not seeing this in your proposal.

MSB


-- 
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] gofmt formats different than goimports in go1.11

[Matthias B.]

On Tue, 28 Aug 2018 22:56:24 +0530
Rohit Jain  wrote:

> 
> how do I solve this?
> 

Wait for goimports to be updated. Until then, increase the dose of your
OCD medication till you stop caring about the difference.

MSB

-- 
It was funnier inside my head.

-- 
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] Re: Ternary ... again

[Matthias B.]

On Thu, 16 Aug 2018 16:54:35 -0700
Liam Breck  wrote:

> Indeed, the problem is largely go fmt, I already raised this, but no
> one picked up on it:
> 
> I use this one-liner:
> 
> v := a; if t { v = b }
> 
> This is not compatible with go fmt, but that tool's effects are
> undocumented (see issue 18790
>  which was declined), and
> it has no switches to disable/enable features.

Now THAT is something I can help you with:

https://github.com/mbenkmann/goformat

has the option "inlineblocks=keep" which should give you what you want.
And if it doesn't, you're welcome to contribute more switches. 

MSB

-- 
Brains are the thing most fairly distributed on this world
because everyone thinks he's got more than anyone else.

-- 
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] Re: Ternary ... again

[Matthias B.]

On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
Hoo Luu  wrote:

> 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
> 
> > var color = temperature > 100 ? “red” : “blue”
> 
>  
> Although this feature will not be accepted, we could just talk about
> it. I prefer 'if-expression'  to ternary.
> 
> var color = if temperature > 100 { "red" } else { "blue" }
> 
> vs. current if statement syntax:
> 
> var color 
> if temperature > 100 {
> color = "red"
> } else {
> color = "blue"
> }
> 

I get the impression that the real issue here is that gofmt will break

if temperature > 100 { color = "red" } else { color = "blue" }

over multiple lines and that what the people asking for a ternary
operator really want is a one-liner. So ask yourselves, if gofmt were
to format your ternary operator (or the above suggested if-expression)
identical to the if statement, i.e. across the same number of lines,
would you still want it?

var color =
if temperature > 100 {
 "red"
} else {
 "blue"
}


var color =
temperature > 100 ?
  "red"
:
  "blue"


If you would NOT use these, your real issue is with gofmt, not the Go
language.


MSB

-- 
To understand recursion you must first understand recursion.

-- 
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] Re: Is the memory allocated for x in f guaranteed to be reachable after a GC call?

[Matthias B.]

On Sat, 26 May 2018 07:26:12 -0700 (PDT)
T L  wrote:

> Looks the answer is not. But any one can confirm this?

I can tell you that your program does not have any defined behavior
according to the Go language standard, because your use of
unsafe.Pointer to reinterpret bytes as a pointer is not one of the
officially supported usage patterns for unsafe.Pointer.

https://golang.org/pkg/unsafe/#Pointer

MSB

-- 
True power lies not in what you can do
but in what you don't have to do in the first place.

-- 
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] Does Golang need the innovation of C++ move semantics too

[Matthias B.]

On Sat, 26 May 2018 03:15:45 +
Li Jianhua  wrote:

>   1.  Why does C++ introduce move semantics anyway? What problems is
> it going to solve? 2.  How come Golang, C (Without ++) don’t have
> that move semantics yet? Will they need the move soon?
> 

C++ is a language used among other things for low level performance
critical applications, including microcontroller programming. Some of
these applications do not even have a traditional memory allocator. A
lot of the language is concerned with managing memory allocations and
related issues (constructors and destructors).

Giving the programmer control over move vs copy is useful/necessary in
C++ because of the existence of constructors and destructors. A simple
assignment a = b may cause multiple calls of complex functions that
may do things like obtain database locks etc. Move semantics allow the
programmer to avoid some of these calls in the common situation where a
copy is made and the original is immediately destroyed afterwards. In
this case, instead of constructing a whole new copy with all the
complexity involved, the programmer can arrange for a cheaper move to
be performed instead.

Go on the other hand is a garbage collected language that does not
allow the programmer to manually control allocation, object
construction or deconstruction. Before it would even make remote sense
to give the programmer control over the intricacies of object copying
vs moving there would have to be constructors and destructors added to
Go. For that to happen, probably more than 50% of Go's core team would
have to die.

MSB

-- 
If you do not fear death, how can you love life?

-- 
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] golang maps; using slice as a key

[Matthias B.]

On Wed, 23 May 2018 03:03:18 -0700 (PDT)
lafolle  wrote:

> Thanks Mathias for clearing this out.
> 
> I reasoned this out by looking at the address to which `i` was
> allocated to, though I wanted to _peek_ inside the slice's header to
> be affirmative.  But I can't clearly understand how to use unsafe
> pointer.  Thanks for showing how to use it.
> 
>  One thing I don't understand is that why `i` is always allocated to
> same address?  Is it to reduce allocations?  Do other languages also
> do this?

Most languages do not have arrays as values and therefore this special
case does not apply to them. With respect to ordinary loops, yes,
that's the normal way to do it. In fact for typical loops that use
integer loop variables that live only for the duration of the loop,
there is no allocation. The variable is simply kept in a processor
register. Even the Go compiler does that when possible. It's easier to
understand when you look at a loop like this

for i := 0; i < 10; i++ {
  ...
} 

The "i:=0" is only executed ONCE, at the very start of the loop. So
it's obvious that if an allocation is necessary, it occurs only once,
as neither "i<10" nor "i++" can cause an allocation.

Your loop is really just a fancy version of this same pattern.

MSB

-- 
Light travels faster than sound. This is why some people appear bright
until you hear them speak.

-- 
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] golang maps; using slice as a key

[Matthias B.]

On Wed, 23 May 2018 13:29:17 +0530
Sankar P  wrote:

> I extracted the confusing part alone, when appending to an array, the
> items are different than the resultant array into a separate go
> program.
> 
> The Playground URL is: https://play.golang.org/p/BJM0H_rYNdb
> 
> If someone can explain the output I would be thankful. It feels like
> a bug to me, but I am sure that I am only misunderstanding and it may
> not be a bug.

Maybe this makes it clearer:

https://play.golang.org/p/YolkDuYzrW8

There are 2 things to realize:

a) arrays are VALUES in Go, not pointers like in C. This means that the
loop variable i is not a pointer, it's an actual independent array that
has its own storage not shared with any of the arrays that are stored
as keys in the map. At the start of the first iteration of the map, the
numbers 1,2,3 are COPIED from the memory of the key [1,2,3] stored in
m1 to the memory of i. At the start of the 2nd iteration of the loop,
the numbers 4,5,6 are COPIED from the memory of the key [4,5,6] stored
in m1 to the memory of i. This overwrites the memory of i.

b) slices are a triples of a pointer, a length and maximum
length(capacity). Length and capacity are not relevant to understanding
this issue. So for the purposes of this issue, you can consider a slice
as a pointer. This means that the expression i[:] creates a pointer to
the storage address of i. Because i does not change its storage for the
whole duration of the loop, the expression i[:] is always the same.
It's a pointer to the storage that during the 1st iteration of the loop
contains 1,2,3 and during the 2nd iteration contains 4,5,6.
You can see this in my playground example. The printed pointer address
is the same in both cases.

Taken together this means that at the end of the program, b contains 2
copies of the same (address,length,capacity) triple with address
pointing to the storage of i (which because Go is garbage collected
remains valid). The storage of i contains the last value copied to it,
which is 4,5,6.

MSB

-- 
If you do not fear death, how can you love life?

-- 
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] Go license and fitness for purpose

[Matthias B.]

On Tue, 15 May 2018 06:39:40 -0700 (PDT)
matthewju...@gmail.com wrote:

> I don’t think I’m suggesting to not disclaim liability. I’m
> suggesting to claim that I didn’t hide anything to make a use break
> on purpose. It does add liability, but this is liability that is
> completely in the author’s control unlike regular bugs or misuse that

That's where you are wrong.
The author has no control over WHAT OTHER PEOPLE CLAIM he did.
If he makes a statement that he didn't intentionally put bad things into
the code and bad things happen, he ends up having to prove that these
are actually bugs and not intentional. And if the developer is unlucky
enough to live in the US, this looks like this:

* a jury of 12 laypersons, with NO UNDERSTANDING OF CODE WHATSOEVER
* a very slick and convincing expert who says that he's reviewed the
  code and he's 100% certain that this is intentional and not a bug
* some awkward nerd claiming it's a bug

The 12 laypeople decide who they trust more based on their "soft
skills".

It's not a coincidence that this whole EULA and total disclaimer BS was
started by US organizations. The US legal system is pure madness and US
lawyers are like mosquitoes. If you leave just a tiny bit of skin
exposed, they'll smell it and will try to land on it to suck your
blood. Whatever drawbacks you perceive from the current language in
licenses is way less bad than the alternative.

MSB

-- 
No man is more pitiful than the one who looks to the shadows for warmth.

-- 
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] Go license and fitness for purpose

[Matthias B.]

On Sun, 13 May 2018 08:56:08 -0700 (PDT)
matthewju...@gmail.com wrote:

> My tools are my responsibility, so I’m wondering what stops the GCC,
> Go, or other open source authors from including practical jokes.

That depends on the jurisdiction and the kind of practical joke. But
it's a fact that software has contained practical jokes in the past, in
particular in cases where the software determined that it was running
without a proper license. So this does indeed happen and I've not heard
of any developer being sued for it.

> These license terms seem to remove all responsibility, and in certain
> hands that is an opportunity to cause some chaos. Why isn’t there a
> license section about intention of code implementation matching
> stated goals?

Ask yourself: If you can choose between having NO LIABILITY and having
just a little bit of liability, which option do you choose? Why would
you assume more liability than necessary? Are you Jesus or Gandhi? 

> 
> THE AUTHORS OF THIS SOFTWARE DID NOT INTENTIONALLY MAKE MISTAKES OR
> INCLUDE PRACTICAL JOKES.
> 
> I’m not a lawyer, but I’d feel better about these tools if there was 
> something like that followed by the fitness disclaimer.

And as an open source developer who does not get paid, I feel better if
I have no liability whatsoever. Now, if you were PAYING ME for my
services, then I will be happy to provide you with assurances that make
you feel better.



MSB

-- 
A naked man with a can of beans can eat only one meal
but play a hundred soccer games.

-- 
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] os/exec always fails with fork/exec /usr/bin/qemu-img: invalid argument

[Matthias B.]

On Fri, 11 May 2018 20:36:18 -0700 (PDT)
Tashi Lu  wrote:

> Hi gophers,
> 
> I faced a strange problem： os/exec always fails with `fork/exec 
> /usr/bin/qemu-img: invalid argument'. 
> 
> Simplified code is at https://play.golang.org/p/v1APfzmS2p9. It seems
> this simplified snippet runs well without errors, but my real code is
> no more than just some variable initializations than this snippet. So
> I suspect it's the context's problem, but my context is too complex
> to simplify and put onto the playground. What I can think of that
> what might be linked to this error is that this function is run in a
> goroutine. But I did write a simplified goroutine version, sadly it
> worked well too... I had no idea how to do further debugging.
> 
> And further, the executable is not to blame, it fails with the same
> error even if I substitute the executable to `ls' or anything else.

Try deleting the relevant lines of code and then write them again,
actually type them again, without referring to and especially not
copy'n'pasting code from somewhere else. Sounds stupid I know, but I've
given this advice many times over the years and it has an extremely
high success rate in the situation you're describing.

MSB

-- 
Light travels faster than sound. This is why some people appear bright
until you hear them speak.

-- 
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] Bug or not?

[Matthias B.]

On Thu, 10 May 2018 08:33:32 +
Jan Mercl <0xj...@gmail.com> wrote:

> This modified example from another thread does not compile:

You modified it in a pretty significant way. The original example had

type T = *T

which is a recursive type alias (which is disallowed). Your new example
has

type T  *T

which is a recursive type which, while weird, is legal. The important
thing to realise is that the second T in "type T *T" IS NOT
an "int", has nothing to do with "int", does not even necessarily have
the same storage size as "int".

> 
> package main
> 
> import (
> "fmt"
> )
> 
> type T int
> 
> func main() {
> var v T

v is effectively an int. On an LP64 platform that's a 32bit variable.

> type T *T
> var w T

w is a pointer to a pointer to a pointer to ...  NOT int. On an LP64
platform that's a 64bit variable.

> w = 

On an LP64 platform  is a pointer to a 32bit storage, while w is a
pointer to a 64bit storage. There is no surprise that this
assignment does not work.

> *w = v
> fmt.Printf("%T %T\n", v, w)
> }
> 
> https://play.golang.org/p/3wos23oim0I
> 
> The compiler says
> 
> prog.go:13:4: cannot use  (type *T) as type T in assignment

What the compiler means is

cannot use  (type *T_declared_outside_of_main_which_is_a_kind_of_int)
as type T_declared_inside_main_which_is_a_type_of_pointer in assignment.

MSB

-- 
Wenn du dich mit einer Frau einlässt, verändert sich nicht die Frau.
Die Frau verändert dich.

-- 
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.