Re: [go-nuts] does Go memory model guarantee this program always prints 1?

[Jan Mercl]

On Mon, Jul 10, 2017 at 2:24 PM T L  wrote:

> Aha, what I wanted to express is the execution orders of the two lines
may be randomized.
>
> atomic.AddInt32(, 1)
> atomic.AddInt32(, 1)

No, assuming those two lines are as written, ie. part of single function
and thus executed in a single/the same goroutine. Then the memory model
guarantees they are executed in order, ie. x will be updated before y. But
there's no such guarantee when the same variable x and y are observed in a
different, concurrently executing goroutine. To establish such ordering you
have to synchronize, only that gives you the H-B relation within the
synchronization participants.

-- 

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

Re: [go-nuts] does Go memory model guarantee this program always prints 1?

[Jan Mercl]

On Sun, Jul 9, 2017 at 10:56 AM T L  wrote:

> But I remember that the "happens-before relationship" is never written
down in any official Go documentation.

https://golang.org/ref/mem#tmp_2


-- 

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

Re: [go-nuts] Re: Random Number Generation in a given range

[Jan Mercl]

On Mon, Jul 10, 2017 at 4:41 PM Alok Kumar Singh 
wrote:

> in my usecasei use this to generate random slice everytime
> dont want the same result
> using it to test my algos

For that you need one only call to Seed at init().

-- 

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

Re: [go-nuts] Sorting user defined collection in multiple ways

[Jan Mercl]

On Fri, Jul 21, 2017 at 3:17 PM  wrote:

> - I have user defined data structure called Employee with attributes
"age", name and sal. I want to write three different go functions that
sorts based on age, name and sal.

Are you sorting a slice? https://golang.org/pkg/sort/#Slice

-- 

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

Re: [go-nuts] GoDoc: ignore GOPATH, local serving of help files

[Jan Mercl]

On Mon, Jul 24, 2017 at 5:33 PM me  wrote:

> $ GOPATH= godoc -http :6060 &

-- 

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

Re: [go-nuts] Bitwise operators applications

[Jan Mercl]

On Sun, Jul 23, 2017 at 5:36 AM Alexey Dvoretskiy 
wrote:

> The question is what are practical applications of bitwise operations in
Go and when I should use/learn them?

Evolution clearly figured out the advantage of repeating fylogenesis in
ontogenesis. Programmers learning machine code first, assembler next, then
probably C (Pascal, ...) do that to their later substantial advantage as
well.

-- 

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

Re: [go-nuts] Understanding least significant byte operation

[Jan Mercl]

On Sun, Jul 23, 2017 at 7:26 PM John Souvestre  wrote:

> I believe that the result is the least significant bit, not byte.

Does not look like that: https://play.golang.org/p/thzUaazLSp

-- 

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

Re: [go-nuts] Why default stack size is 1gb?

[Jan Mercl]

On Mon, Jul 24, 2017 at 5:32 PM taozle  wrote:

> I found that the default stack size for 64-bit is 1gb, but i can't see
any reason for such a large stack, can anyone help me find out the purpose
for this?

Where did you find that info? AFAICT it's not true. Thread stack size is
probably same or similar to the default C stack size on each platform and
goroutine stack defaults to few kB only.

-- 

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

Re: [go-nuts] How make fastest map[uint32]uint64 with fixed size(250m)?

[Jan Mercl]

On Mon, Jul 24, 2017 at 5:32 PM il  wrote:

> Can you help me best solution?

Create a perfect hash function in 28 bits. Use a [1<<28]T array for the map
values.


-- 

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

Re: [go-nuts] no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[Jan Mercl]

On Wed, Jul 26, 2017 at 11:28 AM <370265...@qq.com> wrote:

I think I can see at least one data race in your code. Try to run it using
the race detector to verify.

-- 

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

Re: [go-nuts] Why default stack size is 1gb?

[Jan Mercl]

On Wed, Jul 26, 2017 at 4:26 PM T L  wrote:

> BTW, I think we do need a GrowCurrentStackTo API, to avoid predicted
several stack copies in stack growing.

The specification does not requires Go implementations to have any stack at
all.

-- 

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

Re: [go-nuts] Alternative to reflect.DeepEqual that considers "shape" of cycles?

[Jan Mercl]

On Wed, Jul 26, 2017 at 6:37 PM Julian Andres Klode 
wrote:

> Is there an existing alternative to reflect.DeepEqual() that also
respects the shape of the arguments? For example, the following tests fail:

a and b _are_ of equal shape and contain equal values:
https://play.golang.org/p/Uam97DXOTy




-- 

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

Re: [go-nuts] go get awkwardness with packages outside of GOPATH

[Jan Mercl]

On Wed, Jul 19, 2017 at 8:45 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> tldr: Please let me update dependencies of packages that are in arbitrary
directories.

Dependencies are derived from import paths. Import paths are not complete
paths. They are transformed to complete paths by searching every part in
$GOPATH as in filepath.Join(part, "src", importPath).

How do you propose to update dependencies outside a $GOPATH? How should be
the import paths transformed to complete paths?



-- 

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

Re: [go-nuts] Expiring map

[Jan Mercl]

On Wed, Jul 19, 2017 at 9:22 PM Rajanikanth Jammalamadaka <
rajanika...@gmail.com> wrote:

> Does somebody have a recommendation for an expiring dict? If I have to
write my own, is there a way to avoid iterating over all the keys to delete
the expired entries?

Common approach is to tag the entries with insertion or expiration time and
remove invalid items only on retrieval. If there are not enough retrievals
that keep the ratio of useful/expired map entries sane, a "cleaner"
goroutine can be run concurrently.




-- 

-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: Pointer dereference operator precedence

[Jan Mercl]

Consider

var x *[N]*T

What is the type of *x[0]? *T or T? Only the parentheses can disambiguate
it: (*x)[0] vs *(x[0]).

On Thu, Jul 20, 2017, 00:28  wrote:

> A question on Stack Overflow led me to carefully examine the spec and I
> feel like there may be some detail that's missing - the behavior is easy
> enough to work with, but it's effectively undefined according to the
> language spec. Specifically, with a variable x of type *[]string for
> example, *x[0] will not work because it is evaluated as *(x[0]), not as
> (*x)[0]. This is unexpected based on the spec because the only
> specifications that could apply are the general order of evaluation, which
> is left to right (not the case here), and operator precedence which states
> that pointer dereference is a unary operator and unary operators have
> highest precedence (again clearly not what's happening).
>
> The closest it comes to explaining this behavior is in the section on
> address operators, which implies that the address operator & applies to the
> entire slice expression next to it (or struct field selector, etc). This
> leaves one to assume the same implication applies to the pointer
> dereference operator as well.
>
> Is there something covering this that I glossed over reading the spec? If
> it's not just something I missed, is this worth clarifying in the spec,
> without changing the behavior (purely a documentation change)?
>
> --
> 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.
>
-- 

-j
-- 

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

Re: [go-nuts] Understanding least significant byte operation

[Jan Mercl]

On Mon, Jul 24, 2017 at 12:25 AM John Souvestre  wrote:

> That looks like the least significant set bit to me.

To me too ;-)

But I was responding to your

> On Sun, Jul 23, 2017 at 7:26 PM John Souvestre  wrote:
>
>> I believe that the result is the least significant bit, not byte.

Where the word 'set' is not present.

-- 

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

Re: [go-nuts] why rot13Reader example run twice?

[Jan Mercl]

On Fri, Jun 30, 2017 at 9:48 AM Franco Marchesini <
franco.marches...@gmail.com> wrote:

> Why after the execution the k value is 2?

What value of k do you expect instead and why? (
https://play.golang.org/p/wdWo3fahAS)

-- 

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

Re: [go-nuts] why rot13Reader example run twice?

[Jan Mercl]

On Fri, Jun 30, 2017 at 2:42 PM Franco Marchesini <
franco.marches...@gmail.com> wrote:

> Aside from the correction, however, I did not understand why the method
is called 2 times.

HTH: https://play.golang.org/p/Na7GtgZ-_B


-- 

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

Re: [go-nuts] No luck running 'go install' from within go program

[Jan Mercl]

On Sat, Jul 1, 2017 at 5:12 AM  wrote:

> and the golang version is go_project.go


cmd = exec.Command("go install -x")


Attempts to execute a command named 'go install -x' which is probably not
what you want. Check the documentation example
.

-- 

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

Re: [go-nuts] How to access pointer to pointer in cgo

[Jan Mercl]

On Wed, Jul 5, 2017 at 1:04 PM Manohar Reddy  wrote:

> fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS
MAGIC VARIABLE

Who wants to guess what does "did not work for me" mean without having the
source code and the compiler output to look at?

Please post a complete example at eg. the Go playgound:
https://play.golang.org/

-- 

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:

> what is the relation between `type literal` and `named type`,

Orthogonality.

> aren't they mutually exclusive?

No. Otherwise `type T U` would be illegal.

-- 

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 11:39 AM Darren Hoo  wrote:

> In https://talks.golang.org/2015/tricks.slide#5 says int is type literal,
then you say int is named type.
>
> How can int be both type literal and named type while they are orthogonal?

A type literal can be a named type or an anonymous type. IOW, being
named/anonymous plays no role in using the type in a type literal. Hence
the orhogonality (not dichotomy).

-- 

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:

>>> what is the relation between `type literal` and `named type`,
>>
>> Orthogonality.
>
> Then `int` is not named type.

Please explain why do you think so. I don't get it.

> `int` and `int64` are not the same in this regard?

Both are named types, nothing special about them except being predeclared
in the universe scope.

-- 

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 9:17 AM Darren Hoo  wrote:

> f1's type is func(int), and f2's type is main.f, they are different
types, does implicit conversion happen here?

It's not a conversion. The rule is about assignability
: "x's type V and T have
identical underlying types  and at least
one of V or T is not a named type ."

-- 

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 10:33 AM Darren Hoo  wrote:

> So in https://talks.golang.org/2015/tricks.slide#5
>
> Other examples of type literals are int and []string,
>
> is actually not correct.

The text is completely correct. Type literal is like a type expression. To
express/describe a type you can use any type, anonymous or named.

-- 

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 9:54 AM Darren Hoo  wrote:

> which part did I misunderstand?

'u' and 'int64' are both named types.



-- 

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

Re: [go-nuts] Capture test output per-function

[Jan Mercl]

On Thu, Jul 6, 2017 at 12:56 AM  wrote:

> As far as I can tell, go test captures the output per-package, and when
one test fails it dumps all the captured logs.

It's per test, not package.

jnml@r550:~/tmp/test$ ls
all_test.go
jnml@r550:~/tmp/test$ cat all_test.go
package foo

import "testing"

func Test1(t *testing.T) {
// ok
}

func Test2(t *testing.T) {
t.Fatal("a")
t.Fatal("b")
t.Fatal("c")
}

func Test3(t *testing.T) {
// ok
}
jnml@r550:~/tmp/test$ go test
--- FAIL: Test2 (0.00s)
all_test.go:10: a
FAIL
exit status 1
FAIL _/home/jnml/tmp/test 0.003s
jnml@r550:~/tmp/test$

-- 

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

Re: [go-nuts] bytes.Buffer WriteAt

[Jan Mercl]

On Wed, Apr 26, 2017 at 11:21 AM Chris Hopkins  wrote:

> However I cannot find anyone else having written something similar.

FWIW, a [memory] cache with file os.File-like interface:
https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/file/file.go#L49
A file cache is just above it. Not importable so you need to copy/paste any
code if you want to play with it.



-- 

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

Re: [go-nuts] Re: Recover considered harmful

[Jan Mercl]

On Wed, Apr 26, 2017 at 11:58 AM roger peppe  wrote:

> FWIW I have seen real problems in production where long-running worker
goroutines stopped working. We looked into it and found that certain rare
requests were panicking, not releasing a mutex
and thus preventing the long-running goroutine from acquiring that mutex.

Code bug: Don't Lock without defer Unlock(). (I'm a sinner, just telling
what I learned.)

-- 

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

Re: [go-nuts] Recover considered harmful

[Jan Mercl]

On Mon, Apr 24, 2017 at 3:19 PM Sokolov Yura  wrote:

> And what about unrecoverable panic? C-style `assert`?

fmt.Fprintf(os.Stderr, "it's full of stars!\n")
os.Exit(1)

-- 

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

Re: [go-nuts] https://go-proverbs.github.io/ what do you think of this one ?

[Jan Mercl]

On Mon, Apr 24, 2017 at 4:39 PM  wrote:

> Any thoughts?

Yes. In the second version there is something that can be withdrawn. The
special case of handling an error value, which is just an interface value
like many other interface values. Getting rid of that special case and the
special syntax for handling it results in the current language
specification.


-- 

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Jan Mercl]

On Sat, Jul 29, 2017 at 7:36 PM  wrote:

> But as Gofmt can ALREADY enforces this common coding style, and can be
run at any time, including before committing code on the depots, why should
it be enforced by the COMPILER too ?

Let me pick just one misconception. The compiler does not care about
formatting style at all - because it cannot see it! Token sequences have no
style as they contain no white space or any other kind of token separators.
It's just tokens. All the way down.

The specification prescribes how the source code text is transformed into
the token sequence the compiler only cares about. It's different in
details, but conceptually it's just a transformation stage in the sense of
what the specification of the, for example, C language prescribes.

You may dislike the specification, but you can hardly argue it's not well
thought out and reasonable as a trade-off between mandatory semicolons (pre
Go 1 had them) and almost no need to write them in exchange for adjusting
to the implications and/or costs of that comfort.

If Go changed its specification such that the left brace of a statement
block must be on its own line, it'll take me probably just a few minutes to
adapt and forget about it completely, because it's such an unimportant
detail compared to what I love about Go. Why some others cannot do the same
is beyond my comprehension, but that's by definition my fault, admitted.

-- 

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

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

[Jan Mercl]

On Wed, Aug 9, 2017 at 12:32 AM Pierpaolo Bernardi 
wrote:

> Downloading the paper requires a scribd account which costs money(*).
> Is the paper available for free somewhere else?

My 2-minute skimming smells quite crackpot-ish
 (#25). Or maybe it's a
download-fee scam?

Check also:
https://www.google.com/search?q=%22humble+request%22+%22The+Segmented+Sieve+of+Zakiya%22=%22humble+request%22+%22The+Segmented+Sieve+of+Zakiya%22

-- 

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

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

[Jan Mercl]

On Tue, Aug 8, 2017 at 9:06 AM  wrote:

> Sort.Search is nice, but then the list has to be sorted.

Then it's a simple for range loop.

> So why not come up with
>
> func findFirst(slice interface{}, matches func(i int
) bool
)

I hope this never happens, but the standard approach is to fill a
'proposal: foo' at the issue tracker.


-- 

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

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.

Re: [go-nuts] "fallthrough statement out of place" in `if` block inside `swicth` block

[Jan Mercl]

On Tue, Aug 1, 2017 at 2:34 PM Fumi Takeuchi  wrote:

> Example code: https://play.golang.org/p/dVtPVt3oKt
>
> Maybe `fallthrough` statement cannot be used in `if` block even if it's
put inside `swicth` block)

True: It may be used only as the final non-empty statement in such a clause
.

> 3. Other (please comment)

https://play.golang.org/p/8rL0zqaLP3

-- 

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

Re: [go-nuts] Get a copy of reflect.Value's underlying value

[Jan Mercl]

On Tue, Aug 1, 2017 at 2:58 PM Josh Humphries  wrote:

> Using an interface, the value will be inlined instead of heap-allocated
if it fits without boxing (so most primitive types and pointer types won't
need heap allocation).

This was true some years ago, but it is no more.

-- 

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

Re: [go-nuts] Re: Generics are overrated.

[Jan Mercl]

On Tue, Aug 8, 2017 at 1:37 PM Haddock  wrote:

> Currently Java developers would not change to Go.

Never enough of good news.

-- 

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

Re: [go-nuts] [Go2] append

[Jan Mercl]

On Mon, Aug 7, 2017 at 9:23 PM Gert  wrote:

> Can append or the compiler be made to prevent or warn for bugs like this?

No. Slice is a value and append accepts s not  as its first argument.
That means the new slice value need be returned for code that uses the
resulting slice, which is the case most often seen.

> func main() {
> a := []byte("Help")
> b := append(a, []byte(" Me ")...)
> c := append(a, []byte(" Her")...)
> fmt.Println(string(a), "-", string(b), "-", string(c))
> }

Does this code really output what you want it to output?
https://play.golang.org/p/DWQXtkGByv

Assigning the result value of append to a different variable than its first
argument is completely valid, but one has to be really sure why to do that.
Did you mean https://play.golang.org/p/-OMw3qGYjU ?

-- 

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

Re: [go-nuts] [Go2] append

[Jan Mercl]

On Mon, Aug 7, 2017 at 9:52 PM Gert  wrote:

> Exactly, pretty sure some day if Go get used in a power plant or
something we will have a outage for bugs like this that fly under the radar
so easily passing all tooling, error checks and probably unit tests too :)

Detecting the buggy case, unfortunately, requires first to solve the
halting problem. So revisit this one afterwards ;-)

-- 

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

Re: [go-nuts] Re: No Allman-Style, No go!

[Jan Mercl]

On Thu, Jul 27, 2017 at 10:39 PM Michael Jones 
wrote:

> Ecstatic, ...

Excellent post!

Isn't it strange, that we, programmers, well used to model the problem once
in term of CPU registers and raw memory, then in a pure functional style
and then again in some imperative PL, to name just a few cases, can
sometime become so inflexible when it comes to such a minor detail as
indentation style? Even just the different grammars of different languages
are in orders of magnitude more complex to switch between - but we are
nearly universally able to do that almost instantly.


-- 

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

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

[Jan Mercl]

On Mon, Aug 7, 2017 at 4:23 PM  wrote:

> 2) find(sliceB, item_i_look_for) int, -1 for not found

See https://golang.org/pkg/sort/#Search and friends

-- 

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

Re: [go-nuts] Go 2 suggestion - Types like "int?"

[Jan Mercl]

On Sat, Aug 19, 2017 at 5:05 PM Tong Sun  wrote:

> Suggesting C# type syntax like "int?" so as to take nil as valid value.

- As int is not a pointer type, what would nil int mean?

- Are you willing to sacrifice extra storage for the additional isNil
information or do you prefer that int cannot represent 2^(sizeof(int)*8)
different values?

- (xyproblem?) If you need the information like 'isValid', why a separate
bool [field] is not enough?

-- 

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

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

[Jan Mercl]

On Tue, Aug 22, 2017 at 3:33 PM roger peppe  wrote:

> I *think* that the current implementation was inspired by Minux's comment
here:
> https://groups.google.com/d/msg/golang-dev/G-uGL-jpOFw/vfazKS47_ckJ
>
> but I can't seem to find a comment from Russ that I seem to remember
> where that's specifically acknowledged.

Maybe it's this one:
https://groups.google.com/d/msg/golang-dev/x328N8hiN5k/8S3CP_S3rEUJ

-- 

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

Re: [go-nuts] Initializing Go Struct Literals

[Jan Mercl]

On Tue, Aug 22, 2017 at 4:38 PM Tong Sun  wrote:

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

-- 

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 6:00 PM T L  wrote:

> Just like what expected for constants.

For constants it's expected to reuse the last iota expression when absent.
Do you propose that

var (
a = iota
b
)

will become valid and initialize a to 0 and b to 1?

If so, is it valid and what shall happen when one writes

var (
a = iota
b
s string
d
)

?

If it's not valid, why?


-- 

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 4:38 PM T L  wrote:

> The request is not essential, but any harm of it?

How can anybody know that if nobody knows what it shall actually do and
what will be the impact on the complexity of the specification and
implementation?

-- 

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 5:07 PM T L  wrote:

> The complexity is the same as iota in constant declarations.

How can that be claimed when still nobody ever seen any specification of
what var foo = iota shall do at all? The space of possible semantics is
unbounded. The sane subspace seems to me to be of zero volume, but will you
please just explain what you expect from assigning iota to a variable?

Don't suppose telepathy exists, thank you ;-)

-- 

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 3:19 PM T L  wrote:

Why would you want to assign iota to a variable? What value should iota in
such case have?


-- 

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 4:24 PM Piotr Narewski  wrote:

> I've just tried it and unfortunately it doesn't seem to be better than
the traditional approach.
>
> With the pool in place, it still user too much memory (unlike my solution
with using a heap via glibc).

Sorry to hear that. There are few things worth checking:

- slice.Put must be called once the slice will be no more used.
- The program may not keep any references to the slice passed to slice.Put.
- If you use append on the slice returned from slice.Get() you will
effectively stop using the pool as append can allocate a new backing array
but not by calling slice.Get/CGet. IOW, in such cases it's also necessary
to write one's own append ;-)

The best way to figure out where the memory consumption is happening when
using slice.Pool is to profile it, example:

$ go test -run @ -bench . -memprofile mem.out -memprofilerate 1
$ go tool pprof -lines -web -alloc_space *.test mem.out

-- 

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

Re: [go-nuts] Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 3:14 PM Piotr Narewski  wrote:

> Wouldn't it require me to only use slices of a fixed size?

No, the slice.Pool object has 63 sync.Pool objects:
https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/slice/pool.go#L95,
ie. 63 buckets, one for each log_2(size). Get and Put work on the bucket
selected by the request size (Get) or the capacity of the slice passed
(Put).
-- 

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

Re: [go-nuts] Is there a way to fee a memory object on demand?

[Jan Mercl]

On Tue, May 2, 2017 at 8:35 PM Piotr Narewski  wrote:

> Does anyone know a way to do something like this (freeing memory on
demand), but using pure Go?
> Something that will compile (and work) on any platform, without any extra
dependencies..

sync.Pool could be probably a good fit. Usage example:
https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/slice/pool.go
-- 

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 6:50 PM Piotr Narewski  wrote:

> Perhaps that is the reason; when I need 515 bytes, it actually allocates
1024
> This might be when I'm loosing the mem.

Not if you Put() it back after use ;-)

It's of course also possible to make the allocation granularity finer if
necessary (and/or Fibonacci-ish).

-- 

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 6:28 PM Piotr Narewski  wrote:

> I've checked it and I think there is something wrong with this lib.

I haven't checked thoroughly, but it seems to be working as intended. If
you Put(515) the correct bin to use is the one for sizes 257-512. If you
Get(515), the correct bin to use is the [next] one for sizes 513-1024.

Try it differently:

dat := slice.Bytes.Get(515)
println(dat)
slice.Bytes.Put(dat)
dat = slice.Bytes.Get(515)
println(dat)

Now the first Get(515) will create (the list.Pool is empty) a new cap(1024)
slice. The subsequent Put returns the slice to the correct bin so the last
println should show the same address.

-- 

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 6:39 PM Piotr Narewski  wrote:

> I am supposed to allocate the slice with "slice.Bytes.Get(515).(*[]byte)"
not "make([]byte, 515)"

Yes. Even better is

p := slice.Bytes.Get(n)
b := *p
... use b as usual, it's already a []byte.
slice.Bytes.Put(p)

This way the slice header will not be allocated again (out of the pool).



-- 

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

Re: [go-nuts] accidental 'testing' import

[Jan Mercl]

On Wed, May 10, 2017 at 5:01 PM Brian Fallik  wrote:

> Or would this make sense as
> an external tool, and does one already exist?

Maybe grep of the output of 'go list' may be helpful:
https://golang.org/cmd/go/#hdr-List_packages

-- 

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

Re: [go-nuts] Golang map is getting corrupted with Memory mapped files

[Jan Mercl]

On Wed, May 17, 2017 at 2:49 PM chaitanya reddy 
wrote:

Maps must be initialized before mutating them, which the program does not
do. However, when initializing a map it's not possible to chose where the
map instance will be allocated neither where the map will acquire memory
when needed.
-- 

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

Re: [go-nuts] Are there any implicit type conversions in Go?

[Jan Mercl]

On Sat, May 13, 2017 at 8:19 PM st ov  wrote:

> Go appears to be very strict when using types. Even aliases need to be
explicitly cast.
>
> Are there any contexts where types are implicitly cast? Or must all type
conversions be specified?

cast != conversion

Otherwise for example:

- Ideal constants are implicitly converted according to context in which
they appear.
- If valid, any value is implicitly converted to the appropriate interface
type on assignment/when used as a function argument.

-- 

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

Re: [go-nuts] why received can be defined with/without pointer?

[Jan Mercl]

On Tue, May 9, 2017 at 2:22 PM Volker Dobler 
wrote:

> Go offers two types of methods, those
> defined on value types and those defined on pointer types.

To avoid possible confusion: It's not possible to attach methods to a
pointer type. The receiver has form T or *T, but T cannot be a pointer type.

-- 

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

Re: [go-nuts] Re: {CGO,VM}-free SQLite (ATM Linux/Intel only, pre-alpha)

[Jan Mercl]

On Fri, Jun 9, 2017 at 5:01 AM David Anderson  wrote:

> It looks like it takes the sqlite3 source code (specifically,
https://www.sqlite.org/amalgamation.html), mechanically translates it from
C to Go using https://github.com/cznic/ccgo , then adds a thin layer to
adapt the database/sql interfaces to the C-in-Go codebase.

Exactly.



-- 

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

Re: [go-nuts] How to include unused functions into binary

[Jan Mercl]

On Wed, Jun 21, 2017 at 2:44 PM  wrote:

> I read somewhere that Go will remove unused functions so that it wont be
included into binaries when it can prove no code is using it.

Correct.


> However I am using reflection to call functions that are inside the
binaries without first having any variable using it.

How do you use reflection to call a function that's not referenced anywhere?


> Is there compiler option to include every functions in source code into
binary so that it will be used at runtime upon request?

AFAIK no.


> PS : Please don't suggest to call those unused functions and discard the
output just to make it compiles into binary

No option bellow calls f.

var _ = f

or

var _ = f != nil
or

var foo = f

-- 

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

Re: [go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

[Jan Mercl]

On Wed, Jun 21, 2017 at 1:50 PM Ronald  wrote:

> for {
> ct++
> if ct%6 == 0 {
> t2 := time.Now().UnixNano()
> fmt.Println("hooray", t2, t1, float64(t2-t1)/1e6)
> t1 = t2
> }
> }

> This piece code is not "dead spin", it is just cpu intensive.

This piece of code prohibits cooperative scheduling in 599 999 999 out of
600 000 000 times. It's a nice example how to not code in Go. Particularly,
delays should be implemented using the functions in the time package, not
by burning CPU cycles at the expense of other useful work that could have
been done instead.

-- 

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

Re: [go-nuts] Go get function improvements

[Jan Mercl]

On Thu, Jun 22, 2017 at 4:44 PM Vickey Rawat  wrote:

> GITHUB/GOTA

> Now when i use go get github/gota

github/gota does not look like a valid import path.

If you mean this:

jnml@mate1610-32:~$ echo $GOPATH
/home/jnml
jnml@mate1610-32:~$ rm -rf $GOPATH/src $GOPATH/pkg
jnml@mate1610-32:~$ go get -v github.com/kniren/gota
github.com/kniren/gota (download)
package github.com/kniren/gota: no buildable Go source files in
/home/jnml/src/github.com/kniren/gota
jnml@mate1610-32:~$

then the problem is that the import path does not refer to any package so
there are no transitive dependencies to download.

Try this:

github.com/gonum/matrix (download)
github.com/gonum/blas (download)
github.com/gonum/internal (download)
github.com/gonum/floats (download)
github.com/gonum/lapack (download)
github.com/gonum/blas
github.com/gonum/blas/native/internal/math32
github.com/gonum/internal/asm/f32
github.com/gonum/internal/asm/f64
github.com/kniren/gota/series
github.com/gonum/floats
github.com/gonum/blas/native
github.com/gonum/lapack
github.com/gonum/matrix
github.com/gonum/blas/blas64
github.com/gonum/lapack/native
github.com/gonum/lapack/lapack64
github.com/gonum/matrix/mat64
github.com/kniren/gota/dataframe
jnml@mate1610-32:~$


-- 

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

Re: [go-nuts] Go get function improvements

[Jan Mercl]

Copy paste error eated

jnml@mate1610-32:~$ go get -v github.com/kniren/gota/...

-- 

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

Re: [go-nuts] issues about struct align

[Jan Mercl]

On Fri, May 19, 2017 at 1:29 PM xjdrew  wrote:

> uint64 should aligin in 8 bytes, why it aligns in 4 bytes in
go1.8.1.linux-386?

https://en.wikipedia.org/wiki/Data_structure_alignment#Typical_alignment_of_C_structs_on_x86

> Could anyone tell me how I can get the same result with go playground?

Why should the playground output the same results when the GOARCH and/or
GOOS differs?

-- 

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

Re: [go-nuts] Problem with HINDI NAMES

[Jan Mercl]

On Thu, May 25, 2017 at 4:25 PM Vikram Rawat 
wrote:

It's working as specified: https://play.golang.org/p/yviuaufGDQ

-- 

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

Re: [go-nuts] [ERROR] invalid argument when executing bufio.NewWriter.Flush()

[Jan Mercl]

On Sat, Jun 3, 2017 at 12:42 PM Harry  wrote:

> How can I handle to write something out using bufio.NewWriter?

Just fine. The problem is you haven't created any file to write to in the
first place, which checking the error could have told you.

-- 

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

Re: [go-nuts] os.Args[0] for program executed by go

[Jan Mercl]

On Thu, Jun 1, 2017 at 7:41 PM Santhosh Ram Manohar 
wrote:

> Args: []string{"self", "selftest"},

Here you explicitly pass arsg[0] == "self" and that's what the program gets.

> What is the reason for this difference only for the binaries executed by
the exec package ?

-- 

-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] {CGO,VM}-free SQLite (ATM Linux/Intel only, pre-alpha)

[Jan Mercl]

https://github.com/cznic/sqlite

-- 

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

Re: [go-nuts] understanding utf-8 for a newbie

[Jan Mercl]

On Sun, May 7, 2017 at 8:39 PM peterGo  wrote:

> "[Rob Pike and Ken Thompson] they made sure it was backwards compatible
with ASCII."

> ASCII is 7-bits.

So is any UTF-8 encoded ASCII.

-- 

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

Re: [go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

[Jan Mercl]

On Thu, May 4, 2017 at 1:54 PM  wrote:

> Can you help me explain this behaviour?

The universe scope is not a package.

-- 

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

Re: [go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

[Jan Mercl]

On Thu, May 4, 2017 at 2:22 PM Alberto Cortes  wrote:

> Can you elaborate on your answer?

%T produces packageName.typeName, where 'packageName' is the name of the
package where 'typeName' is defined. But the universe scope is not a
package, hence no 'packageName.'.


-- 

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

Re: [go-nuts] sort.SliceStable behaves incorrectly, but only sometimes!

[Jan Mercl]

On Fri, May 5, 2017 at 11:37 AM Ondřej Kupka  wrote:

> It seems that the slice is sometimes sorted properly and sometimes it
isn't obviously sorted. How is that possible?

Performing separate stable sorts on a partial key does not produce a stable
sort on the full key.

-- 

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

Re: [go-nuts] Possible optimization bug in go1.8?

[Jan Mercl]

On Mon, May 8, 2017 at 3:50 PM  wrote:

> Could it be a bug?

No, the xrand function will always return the same number.

-- 

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

Re: [go-nuts] Is this a race detector false positive case

[Jan Mercl]

On Fri, Sep 15, 2017 at 3:15 PM  wrote:

https://stackoverflow.com/q/46233680


-- 

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

Re: [go-nuts] Are you tired typing if err != nil {} ?

[Jan Mercl]

On Fri, Sep 15, 2017 at 2:32 AM Wojciech S. Czarnecki 
wrote:

I code a lot in Go, but saving a couple of seconds/minutes when writing
code which, including research, thinking, testing, debugging and
documenting, takes hours or even months to develop makes no sense to me.

Vim is my IDE and I don't have any snippet inserting macros in .vimrc.

2c

-- 

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

Re: [go-nuts] buffered io.ReaderAt

[Jan Mercl]

On Sat, Sep 16, 2017 at 1:52 PM Sebastien Binet  wrote:

> Has anybody written a buffered version of an io.ReaderAt ?

IIUC what's needed, you might want to try
https://github.com/cznic/file/blob/efffc965e97bbf31b0ed00deb82fe697500f22b5/file.go#L1039

-- 

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

Re: [go-nuts] Going crazy on golang maps

[Jan Mercl]

On Sat, Sep 23, 2017 at 4:37 PM Chris Polderman 
wrote:

> The full code reads:

The full code is not full code. It lacks eg. the import declarations.
Please provide a link to the really full code at a specific commit for
others to reproduce.

-- 

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

Re: [go-nuts] [ANN] 99c

[Jan Mercl]

Do you have any particular feature(s) of C11 on your mind? Because maybe
some of them are possibly easy to add.  Also, IIRC, one or two are already
there, just disabled by default, so adding support of the -std flag can
make them available.

On Sun, Oct 8, 2017, 01:37 Devon H. O'Dell <devon.od...@gmail.com> wrote:

> Is there any desire to support c11?
> On Sat, Oct 7, 2017 at 1:01 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> Command 99c is a c99 compiler targeting a virtual machine:
>> https://github.com/cznic/99c
>>
>>
>>
>> --
>>
>> -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.
>>
> --

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

Re: [go-nuts] Re: Why is there a slow-down to split one method of a struct pointer into two methods?

[Jan Mercl]

On Sun, Oct 8, 2017 at 8:02 PM Zack Scholl  wrote:

> Why does it slow down the code if its not inlined? Since the method is on
a pointer struct I assume it wouldn't need to copy anything?

Call/return is not free even before stack limit checking, pushing the
arguments and retrieving the return values.


-- 

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

Re: [go-nuts] Re: important

[Jan Mercl]

On Mon, Oct 9, 2017 at 6:43 PM Ian Lance Taylor  wrote:

> Didn't I answer this question already?

Obviously you did, I can see your answer in the web interface, but if the
OP is using only the mail for communicating with the group, as I do, I must
say that your answer never made it to my inbox and that's probably why the
OP is asking again.

-- 

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

Re: [go-nuts] Re: important

[Jan Mercl]

On Mon, Oct 9, 2017 at 7:04 PM Francisco Dalla Rosa Soares <
dallar...@gmail.com> wrote:

> Actually I have the email here from three days ago, so it might have been
marked as spam at some inboxes

No such message in my spam folder (using inbox.google.com).

-- 

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

Re: [go-nuts] Is iota increment behavior implemented here?

[Jan Mercl]

On Sun, Oct 15, 2017 at 8:59 PM  wrote:

> I'm writing an article about iota and I've found that its counting
behavior is implemented in the below source code? Am I right, if not, where
it is? Can you help me?
>
>
https://github.com/golang/go/blob/90d71fe99e21b68e292327c966946f1706d66514/src/cmd/compile/internal/gc/noder.go#L263

AFAICS, the field named 'iota' at line 267 has nothing common with the
predeclared identifier 'iota' in the universe scope. The later _is_
special, as a field name in this case it's not.


-- 

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

Re: [go-nuts] binary.Read()

[Jan Mercl]

On Thu, Oct 5, 2017 at 5:22 PM Johan terryn  wrote:

> Or is this working as intended?

Hard to tell w/o a complete, self contained reproduction program. But note
that os.File is not an io.Reader, *os.File is.

-- 

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

Re: [go-nuts] installing the rename tool

[Jan Mercl]

On Thu, Oct 5, 2017 at 5:22 PM sparc1998  wrote:

> I tried to install go's rename tool using go get
golang.org/x/tools/refactor/rename. This installed some related files in
~/go/src and ~/go/pkg, but it didn't install a new tool in ~/go/bin, and
I'm wondering why?

Because its a package. Use $ go get golang.org/x/tools
/cmd
/gorename to install the command.

-- 

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

Re: [go-nuts] How to generate long int with k random bits.

[Jan Mercl]

> On Fri, Oct 13, 2017 at 4:37 PM Christian LeMoussel 
wrote:

See https://golang.org/pkg/math/big/#Int.Rand

-- 

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

Re: [go-nuts] Strange behavior when dealing with certain emojis

[Jan Mercl]

On Wed, Oct 11, 2017 at 10:58 AM Gianguido Sorà  wrote:

WAI: "\x32" == "2"



-- 

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

Re: [go-nuts] Strange behavior when dealing with certain emojis

[Jan Mercl]

On Wed, Oct 11, 2017 at 11:34 AM Ian Davis  wrote:

> At first glance this looks like a bug in strings.Replacer.

What bug do you mean? https://play.golang.org/p/0DBwWt2TU9

-- 

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

Re: [go-nuts] Why go does't have NullInt type on database/sql?

[Jan Mercl]

On Thu, Oct 12, 2017 at 2:38 AM 高橋誠二  wrote:

> There are NullInt64 and NullFloat64, but not about NullInt, NullFloat.
(or NullInt32 etc...)
> After scanning from rds, my team always convert them to int, but it seems
so silly.

That does not work accross architectures.

> What is the reason?

The driver model has only one integer type - int64. NullInt would not be
able to handle 64 bit ints on 32-bit architectures.

-- 

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

Re: [go-nuts] Testing on Go templates Range's index

[Jan Mercl]

On Sat, Sep 9, 2017 at 6:01 PM Tong Sun  wrote:

As documented , ne is
a function, not an infix operator: https://play.golang.org/p/sJSzoNyrJz


-- 

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

Re: [go-nuts] unicode constant

[Jan Mercl]

On Fri, Sep 8, 2017 at 12:09 AM Tong Sun  wrote:

https://play.golang.org/p/FD8UMrDkf-

> How can I make it works?

Follow the language specification.

-- 

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

Re: [go-nuts] Tiny FSM

[Jan Mercl]

On Sun, Sep 24, 2017 at 11:07 AM dc0d  wrote:

https://youtu.be/HxaD_trXwRE?t=14m7s

-- 

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

Re: [go-nuts] Errors out of syscall

[Jan Mercl]

On Mon, Oct 2, 2017 at 2:51 PM Chris Hopkins  wrote:

> Yes, it has dynamic type. That doesn't mean you can't test against it.
> I thought the preferred way to to handle errors was for a package to
expert the error variables, then you could test for those variables as in
the above code.

The code shown uses only type switches, so it will always  work. I don't
know what "does not work".


-- 

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

Re: [go-nuts] Errors out of syscall

[Jan Mercl]

On Mon, Oct 2, 2017 at 2:19 PM Chris Hopkins  wrote:

I'm not sure I understand: error is an interface and it always has some
dynamic type when non-nil. But that type cannot by string b/c string does
not implement the error interface.

-- 

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

Re: [go-nuts] Defer with anon func and func literal

[Jan Mercl]

On Thu, Sep 28, 2017 at 2:18 PM Karan Chaudhary  wrote:

That's expected, the specs say that execution of the defer statement
evaluates the arguments of the deferred function.

-- 

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

Re: [go-nuts] Graphing libraries in golang

[Jan Mercl]

On Wed, Sep 27, 2017 at 5:05 PM Vikram Rawat 
wrote:

Also there's https://github.com/cznic/plot.

-- 

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

Re: [go-nuts] Defer with anon func and func literal

[Jan Mercl]

On Thu, Sep 28, 2017 at 2:50 PM Karan Chaudhary  wrote:

> I'm trying to find rationale for this: why is "defer foo(x)" treated
differently than "defer func() { foo(x) }" by the language designers?

They are not treated differently. The defered functions are different.


-- 

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

Re: [go-nuts] Example output not visible in godoc

[Jan Mercl]

On Mon, Sep 25, 2017 at 10:55 AM snmed  wrote:

> Has anyone an idea why it is no working correct?

Blind shot: Try removing the final empty line:
https://bitbucket.org/snmed/sting/src/85748cacc8970f60582428bf05d52fcfb051ba5f/example_inject_test.go?at=master=file-view-default#example_inject_test.go-87

-- 

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

Re: [go-nuts] Potential race condition in prototypical network server code

[Jan Mercl]

No, wg.Add cannot "switch" to wg.Wait, they're both in the samr goroutine,
the go statement will be always the next one to execute after wg.Add within
serve().

On Thu, Aug 24, 2017, 19:29 Tom Payne  wrote:

> I'm not singling out Dave Cheney here, I'd just like to check my
> understanding of Go's resource handling and concurrency.
>
> In this blog post a "prototypical network server" is presented:
>
>https://dave.cheney.net/2017/08/20/context-isnt-for-cancellation
>
> Code:
>
> func serve(l net.Listener) error {
> var wg sync.WaitGroup
> var conn net.Conn
> var err error
> for {
> conn, err = l.Accept()
> if err != nil {
> break
> }
> wg.Add(1)
> go func(c net.Conn) {
> defer wg.Done()
> handle(c)
> }(conn)
> }
> wg.Wait()
> return err
> }
>
> My understanding is that this contains a race condition. Specifically, a
> goroutine switch can occur at the entry to wg.Add(1), switching to
> wg.Wait() in the main goroutine. At this point, a connection has been
> accepted, but the WaitGroup counter has not been incremented, so the serve
> function will terminate while silently dropping a network connection (the
> connection will be accepted, but never handled, so will probably eventually
> time out on the client side and leak a file descriptor on the server side).
>
> Is this understanding correct? Furthermore, I suspect that it's impossible
> to implement race-free graceful termination using only sync.WaitGroups. Is
> it actually possible to do so?
>
> Thanks for any correction, and apologies to Dave for picking on his code.
>
> Cheers,
> Tom
>
> --
> 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.
>
-- 

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

Re: [go-nuts] Potential race condition in prototypical network server code

[Jan Mercl]

The wg.Wait will be executed after l.Accept returns an error. It's purpose
is to wait for the completions of all handlers invoked in the go statement
that did not finished already.

On Thu, Aug 24, 2017, 19:49 Tom Payne <twpa...@gmail.com> wrote:

> Awesome, thanks Jan for the fast and clear response.
>
> In fact, the for {} is an infinite loop so wg.Wait() will never be reached
> and serve() will never terminate. Correct?
>
> I guess I over-read how much this prototypical code was representative of
> a real server loop. Sorry Dave!
>
> Tom
>
> On Thursday, August 24, 2017 at 7:41:59 PM UTC+2, Jan Mercl wrote:
>
>> No, wg.Add cannot "switch" to wg.Wait, they're both in the samr
>> goroutine, the go statement will be always the next one to execute after
>> wg.Add within serve().
>>
>> On Thu, Aug 24, 2017, 19:29 Tom Payne <twp...@gmail.com> wrote:
>>
> I'm not singling out Dave Cheney here, I'd just like to check my
>>> understanding of Go's resource handling and concurrency.
>>>
>>> In this blog post a "prototypical network server" is presented:
>>>
>>>https://dave.cheney.net/2017/08/20/context-isnt-for-cancellation
>>>
>>> Code:
>>>
>>> func serve(l net.Listener) error {
>>> var wg sync.WaitGroup
>>> var conn net.Conn
>>> var err error
>>> for {
>>> conn, err = l.Accept()
>>> if err != nil {
>>> break
>>> }
>>> wg.Add(1)
>>> go func(c net.Conn) {
>>> defer wg.Done()
>>> handle(c)
>>> }(conn)
>>> }
>>> wg.Wait()
>>> return err
>>> }
>>>
>>> My understanding is that this contains a race condition. Specifically, a
>>> goroutine switch can occur at the entry to wg.Add(1), switching to
>>> wg.Wait() in the main goroutine. At this point, a connection has been
>>> accepted, but the WaitGroup counter has not been incremented, so the serve
>>> function will terminate while silently dropping a network connection (the
>>> connection will be accepted, but never handled, so will probably eventually
>>> time out on the client side and leak a file descriptor on the server side).
>>>
>>> Is this understanding correct? Furthermore, I suspect that it's
>>> impossible to implement race-free graceful termination using only
>>> sync.WaitGroups. Is it actually possible to do so?
>>>
>>> Thanks for any correction, and apologies to Dave for picking on his code.
>>>
>>> Cheers,
>>> Tom
>>>
>>> --
>>> 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...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> -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.
>
-- 

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