Re: [go-nuts] Shuffle Items in a Slice

[Martin Geisler]

On Fri, Jun 24, 2016 at 2:54 PM, Val  wrote:
> The playground caches everything, so running multiple times the same program
> will just serve the previously generated output.

Thanks, that's good to know! Makes a lot of sense too.

> Also in the playground everything is frozen at some point in the past : the
> clock, the randomness sources, and you can't make outgoing requests to
> import randomness from the network.

I found this blog post with a lot more background information:

  https://blog.golang.org/playground

-- 
Martin Geisler

-- 
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: Shuffle Items in a Slice

[Martin Geisler]

Hi Val

On Fri, Jun 24, 2016 at 2:48 PM, Val  wrote:
> 2 implementations here :
> http://www.programming-idioms.org/idiom/10/shuffle-a-list/1564/go
>
> As for the map iteration trick, the runtime doesn't guarantee to randomize
> anything, although it often tries to, so developers don't rely on some
> specific order.

That's a nice feature and very helpful when writing tests... otherwise
you end up with a test that works fine on one version/architecture and
"suddenly" breaks later.

Randomizing the order "on purpose" is probably also done for security
reasons. Python works much the same, and some years ago, the CPython
VM began randomizing the dict (map) type. The problem was that
carefully crafted input would trigger a worst-case scenario in the
hash table used behind the scenes and suddenly make your server crawl
to a halt.

The input could be HTTP headers, for example, with carefully chosen
names: these are normally read from the client and used as keys in a
map. With the right keys, you can trigger hash collisions and make the
map allocate much more memory than you would expect with typical keys.

Having the runtime add a bit of randomness to the keys prevents this
scenario. When the randomness changes at every execution, it further
helps the developers by highlighting the nondeterministic iteration
order of the hash table.

> I've seen (in the past) some map iterations consistently not
> randomized at all. This behaviour may have evolved, but don't rely on it.

That's good advice :-)

-- 
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: Trouble querying REST API with net/http (api verified working with curl)

[Kiki Sugiaman]

I know this is a bit late, so perhaps you don't care anymore...

Anyway, the server may not understand the "Get" method in this line:
|req, err := http.NewRequest("Get", 
"https://"+host+".here.com:443/rest/json/flows";, nil)

|


On 27/06/16 08:22, mark mellar wrote:
For anyone else having similar issues, I found I was able to work 
around this by using client.Get() rather than client.Do().


Still not sure what the root cause is though...

Cheers.

On Friday, June 24, 2016 at 7:32:36 AM UTC+1, mark mellar wrote:

Good tip on using httputil to inspect the request! Unfortunately
I'm not seeing anything obviously wrong...

Using curl -v

*   Trying ...
* Connected to host.here.com  () port
443 (#0)
* TLS 1.0 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate: host
> GET /rest/json/flows HTTP/1.1
> Host: host.here.com 
> User-Agent: curl/7.43.0
> Accept: */*
> Cookie:

connect.sid=s%3AeQ30DeGtFyrhrntWofMWpGXo.%2F745zwxR0ErYrpnoVDklkt%2F7H9FX5GfcroBFXg5M6Ag

> Content-Type: application/json


using httputil.DumpRequestOut

Get /rest/json/flows HTTP/1.1

Host: host.here.com:443 

User-Agent: Go-http-client/1.1

Content-Type: application/json

Cookie:

connect.sid=s%3A%2FWuxV7HdAnHDweXFvs4N8%2BaB.DuNDxfVN6sLhLO%2Flu3hIY7PfUnfMquyRIfXSllGtZpM

Accept-Encoding: gzip


I'm suspicious about the Accept-Encoding field. I tried
twiddling DisableCompression in my transport but nothing changed...

Cheers,

Mark

On Friday, June 24, 2016 at 5:46:06 AM UTC+1, Tamás Gulácsi wrote:

Just a blind shoot into the darkness: try to use one (global)
http.Client! Also, you can ask curl to dump the request, and
net/http/httputil also to compare them.

--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Append to slice... what happens?

[Dan Kortschak]

On Mon, 2016-06-27 at 07:49 +0200, Martin Geisler wrote:
> BTW, I was about to say that you could simplify the line one step
> further with
> 
>   b := append(a[::len(a)], 3, 4)
> 
> but that gives a compilation error:
> 
>   prog.go:11: middle index required in 3-index slice
> 
> I wonder what the rationale is for this? It seems inconsistent to me
> since the second (middle) index has a useful default (len(a)) that is
> used when there are only two indexes used.

As I remember it, during the design discussions the possibility of using
the shortened syntax you show above was considered, but rejected as an
opening to bug entry (too much semantic weight on a single repeated
character).

-- 
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] Append to slice... what happens?

[Martin Geisler]

On Mon, Jun 27, 2016 at 12:34 AM, Jan Mercl <0xj...@gmail.com> wrote:
> On Mon, Jun 27, 2016 at 12:26 AM Peter Kleiweg  wrote:
>
>> I don't know what I expected, but it's weird. Don't mess with slices.
>
> Well, working as expected, considering slice backing array is possibly
> shared wrt the result of append. (Or other slice op, b/c slices _are_
> values.)
>
> However, it's easy to avoid the append sharing when/where not desirable:
> https://play.golang.org/p/oIFHamYWB-

To unpack what Jan wrote a little: when slicing, you can specify a
third integer which becomes the capacity of the new slice. So

  b := a[:len(a):len(a)]

will create a new slice b with len(b) = len(a) and cap(b) = len(a).
Without the third argument, cap(b) = cap(a). When cap(a) > len(a) you
have the situation where append(a, 123) is quick: is can just insert
the element into the underlying array without having to reallocate
anything.

So the line

  b := append(a[:len(a):len(a)], 3, 4)

does two things: it slices a to obtain a new slice with a lower than
normal capacity. Because the capacity exactly matches the length of
the new slice, trying to append to it is guaranteed to reallocate the
underlying array. So append makes a new, larger array and copies
len(a) elements into it. It then writes 3 and 4 into the new array as
well before returning a slice of the array. That slice becomes b.

>From that point onwards, a and a are no longer connected via the
underlying array.

BTW, I was about to say that you could simplify the line one step further with

  b := append(a[::len(a)], 3, 4)

but that gives a compilation error:

  prog.go:11: middle index required in 3-index slice

I wonder what the rationale is for this? It seems inconsistent to me
since the second (middle) index has a useful default (len(a)) that is
used when there are only two indexes used.

-- 
Martin Geisler

-- 
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] Append to slice... what happens?

[Martin Geisler]

Hi Henry,

On Mon, Jun 27, 2016 at 3:55 AM, Henry  wrote:
> If you were to change the code a bit as follows 
> https://play.golang.org/p/VwtWRQBrEe , it will work as you expect.
>
> I think it is probably safer to instantiate a slice without specifying the 
> initial capacity.

Having the capacity larger than the number of used elements (the
length of the slice) is indeed the problem. However, not specifying
the capacity can also fail you. Here I changed the numbers of elements
appended slightly and print the capacity after each operation:

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

As you can see, append will over-allocate and set the capacity of the
underlying array to 4 when we go from an empty slice to a slice with
length 3. This in turn makes the following appends to a and b share
the 4th slot in the array and appending to a will ultimately update
the value you see in b.

In your example you were "lucky" since you started with a = [1, 2] and
cap(a) = 2. When you create b, append notices that the capacity is
exhausted and *creates a new underlying array for b*. After that step,
a and b are no longer "entangled" like this and updates to one cannot
affect the other.

-- 
Martin Geisler

-- 
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: Gomobile: Large .so/aar file size on Android

[rajiivkanchan]

Thanks for the response. 
We went ahead and re-wrote the Golang part in Java. Did not get a chance to 
test your suggestions. Thanks for your suggestions.


On Monday, June 20, 2016 at 9:33:57 PM UTC+5:30, nsa...@gmail.com wrote:
>
> Did you try the beta
>  https://groups.google.com/forum/#!topic/golang-announce/ITzPaJnZGZw
> ?
>
> It should be a lot better than go 1.6 at code elimination.
>
>

-- 
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: Getting a pointer in a type switch gives a *interface {} if case lists several options

[Constantin Konstantinidis]

This is (old) documented issue https://github.com/golang/go/issues/460 
related to multiple values in one case of the switch.

On Sunday, June 26, 2016 at 5:40:55 PM UTC+2, Constantin Konstantinidis 
wrote:
>
> A part of the answer is in the specifications as the method set is 
> inherited from the type https://golang.org/ref/spec#Method_sets
>
>
> On Wednesday, June 22, 2016 at 12:02:02 AM UTC+2, raido...@gmail.com 
> wrote:
>>
>> I have encountered some unexpected and inconsistent behavior with type 
>> switches. Can someone shed some light as to why Go behaves this way?
>>
>> Take a look at https://play.golang.org/p/YPV5YPtWF8
>>
>> I would expect both of the switches to behave the same way, but for some 
>> reason the one with multiple options in the case ends up with a pointer to 
>> an interface and the one with just one option ends up with a pointer to the 
>> correct type.
>>
>

-- 
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 it safe enough to read uint without lock/atomic operation?

[Jan Mercl]

On Mon, Jun 27, 2016 at 5:44 AM 苏沛  wrote:

Data race occurs when there are concurrent accesses to the same memory and
at least one of them is a write. Channel capacity is never written to after
a chan is created.
-- 

-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] Is it safe enough to read uint without lock/atomic operation?

[苏沛]

https://github.com/golang/go/blob/master/src/runtime/chan.go#L655

func reflect_chancap(c *hchan) int {
if c == nil {
return 0
}
return int(c.dataqsiz)
}


-- 
苏沛

-- 
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] Append to slice... what happens?

[Henry]

If you were to change the code a bit as follows 
https://play.golang.org/p/VwtWRQBrEe , it will work as you expect. 

I think it is probably safer to instantiate a slice without specifying the 
initial capacity.

-- 
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] russian language books about Go

[adonovan via golang-nuts]

On Friday, 24 June 2016 03:10:56 UTC-4, Oleg Puchinin wrote:
>
> Hello !
> Where I can find subject ?
>

Hi Oleg,

our book The Go Programming Language (gopl.io) is now available in Russian, 
thanks to Williams Press:
http://www.williamspublishing.com/Books/978-5-8459-2051-5.html

The ozon.ru site features some sample chapters so you can try before you 
buy:
http://www.ozon.ru/context/detail/id/34671680/

cheers
alan


-- 
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] Webcam

[JM]

I searched the forum and there were a few posts but they were old. Looking 
for any updates

I'm looking for a way to take a photo from my default webcam via code.  I 
am using ComandCam now with exec.Command and it works fine, but it takes 3 
seconds for each photo if i loop though and keep taking photos.  Is there 
any other library to take a photo? Im running on windows right now.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Any keyboard players here?

[Daniel Skinner]

Finally have a place to setup my keyboard and tgui-harm worked well, nice
work.

On Sun, Jun 26, 2016 at 3:25 AM  wrote:

> Hi Daniel,
>
> I already investigated your piano and snd projects at github, but could
> not get them working: too much unknown libraries. Anyhow, it seemed to be
> aiming at the Android platform, with an on-screen piano keyboard and no
> MIDI interface. For Android this is a sensible project, but for a musician
> it qualifies as a toy app, not fit to play real music, and competing with a
> lot of similar apps. In the past I created several myself, and believe me:
> you cannot use a touch screen as a real piano keyboard. It's unplayable.
>
> About the speed of Go: that depends on what you compare it to. In the past
> I wrote similar programs in C++. There I used more complicated algorithms,
> with more calculations at each signal frame, and still the program could
> run at 48000Hz without problems. So apparently in this area Go is 2x slower
> then C++. I tried all known trics to increase the speed, like: no garbage
> creation, and also pre-calculate as much as possible. Increasing the buffer
> size had little effect, because all needed calculations still must be done.
>
> I would love to hear how your piano is sounding. Can't you update your
> github projects and also augment the README's such that a simple user like
> me can build something that works?
>
> Wouter Boeke
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Append to slice... what happens?

[Jan Mercl]

On Mon, Jun 27, 2016 at 12:26 AM Peter Kleiweg  wrote:

> I don't know what I expected, but it's weird. Don't mess with slices.

Well, working as expected, considering slice backing array is possibly
shared wrt the result of append. (Or other slice op, b/c slices _are_
values.)

However, it's easy to avoid the append sharing when/where not desirable:
https://play.golang.org/p/oIFHamYWB-


-- 

-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] Append to slice... what happens?

[Peter Kleiweg]

This:

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

I don't know what I expected, but it's weird. Don't mess with slices.

-- 
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: Trouble querying REST API with net/http (api verified working with curl)

[mark mellar]

For anyone else having similar issues, I found I was able to work around 
this by using client.Get() rather than client.Do().

Still not sure what the root cause is though...

Cheers.

On Friday, June 24, 2016 at 7:32:36 AM UTC+1, mark mellar wrote:
>
> Good tip on using httputil to inspect the request! Unfortunately I'm not 
> seeing anything obviously wrong...
>
> Using curl -v
>
> *   Trying ...
> * Connected to host.here.com () port 443 (#0) 
> * TLS 1.0 connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
> * Server certificate: host 
> > GET /rest/json/flows HTTP/1.1 
> > Host: host.here.com 
> > User-Agent: curl/7.43.0 
> > Accept: */* 
> > Cookie: 
> connect.sid=s%3AeQ30DeGtFyrhrntWofMWpGXo.%2F745zwxR0ErYrpnoVDklkt%2F7H9FX5GfcroBFXg5M6Ag
>  
>
> > Content-Type: application/json
>
>
> using httputil.DumpRequestOut
>
> Get /rest/json/flows HTTP/1.1
>
> Host: host.here.com:443
>
> User-Agent: Go-http-client/1.1
>
> Content-Type: application/json
>
> Cookie: 
> connect.sid=s%3A%2FWuxV7HdAnHDweXFvs4N8%2BaB.DuNDxfVN6sLhLO%2Flu3hIY7PfUnfMquyRIfXSllGtZpM
>
> Accept-Encoding: gzip
>
> I'm suspicious about the Accept-Encoding field. I tried 
> twiddling DisableCompression in my transport but nothing changed...
>
> Cheers,
>
> Mark
>
> On Friday, June 24, 2016 at 5:46:06 AM UTC+1, Tamás Gulácsi wrote:
>>
>> Just a blind shoot into the darkness: try to use one (global) 
>> http.Client! Also, you can ask curl to dump the request, and 
>> net/http/httputil also to compare them.
>
>

-- 
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] Where is .gosymtab in go binaries with cgo?

[Ian Lance Taylor]

On Sun, Jun 26, 2016 at 1:28 PM, Tamás Gulácsi  wrote:
>
> 2016. június 26., vasárnap 21:42:15 UTC+2 időpontban Ian Lance Taylor a
> következőt írta:
>>
>> On Sun, Jun 26, 2016 at 12:18 AM, Tamás Gulácsi 
>> wrote:
>> > I want to find out the source package's given the binary.
>> >
>> > github.com/FiloSottile/gorebuild (and github.com/rjeczalik/which) works
>> > fine
>> > with binaries built with the "go" tool.
>> > But fails if cgo (and thus I think gcc) is included in the build
>> > procedure.
>> >
>> > A minimal example is attached to
>> > https://github.com/FiloSottile/gorebuild/issues/3
>> >
>> > Can anybody help me?
>>
>> I don't see how the .gosymtab section is relevant here.  It's
>> currently always empty.  When using external linking, as when building
>> a program that uses cgo, it gets dropped.  But even when it remains in
>> the file, it is empty.  I don't think gosymtab has had any contents
>> since the 1.2 release.  Yes, the situation is somewhat confusing, and
>> I'm not sure I entirely understand it.
>>
>> Ian
>
>
> Ok, than anz other idea to get the binary's main.main function's package's
> path, from the binary?
> The other way around (go list -e .../binary) has its own weaknesses (dirs
> with same names)...

If you're happy with gorebuild, keep using it.  Just change it so that
it doesn't care if there is no .gosymtab section, and to treat a
missing .gosymtab section as an empty one.

Ian

-- 
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: formal verification in Go? someday perhaps?

[wsc]

I think a better question is:  can go tools for formal verification become 
available?  The distinction is that formal verification tools can be 
applied to
hardware, protocols, assembly, software, etc.   Why not do that in go?

Most such tools are in C or C++, and the low level engines/components are 
highly optimised.  Go can easily compete with "standard" C/C++, i.e. 
software which has not been highly optimised.  It also provides enough 
low-level access to be competitive against highly optimised C/C++ (e.g. 
assembly, precision of memory representations) but it takes work.  

One of the research initiatives we are taking up is "scalable cloud 
 architectures for formal technologies".  Basically, composable cloud 
microservices for formal technologies like model checking, SAT/BDD/SMT, 
theorem proving, as well as encoders for verification problems, etc, but in 
terms of deployment in the cloud.  A related startup is satalia.  Go is a 
natural fit for this initiative, and we already have some results with go.

I think the biggest obstacle to formal tools targeting analysis of go 
programs is formal representations in the golang "go" package.  Once that 
is available, things will start to snowball.

 



Le lundi 9 mars 2015 01:07:36 UTC+1, Camilo Aguilar a écrit :
>
> I ran across this post today: 
> http://blog.adacore.com/testing-static-formal. Basically, showing how you 
> can do formal verifications in ADA2012. Is it realistic to think that a 
> feature like that would someday arrive to Go? 

-- 
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] Where is .gosymtab in go binaries with cgo?

[Tamás Gulácsi]

2016. június 26., vasárnap 21:42:15 UTC+2 időpontban Ian Lance Taylor a 
következőt írta:
>
> On Sun, Jun 26, 2016 at 12:18 AM, Tamás Gulácsi  > wrote: 
> > I want to find out the source package's given the binary. 
> > 
> > github.com/FiloSottile/gorebuild (and github.com/rjeczalik/which) works 
> fine 
> > with binaries built with the "go" tool. 
> > But fails if cgo (and thus I think gcc) is included in the build 
> procedure. 
> > 
> > A minimal example is attached to 
> > https://github.com/FiloSottile/gorebuild/issues/3 
> > 
> > Can anybody help me? 
>
> I don't see how the .gosymtab section is relevant here.  It's 
> currently always empty.  When using external linking, as when building 
> a program that uses cgo, it gets dropped.  But even when it remains in 
> the file, it is empty.  I don't think gosymtab has had any contents 
> since the 1.2 release.  Yes, the situation is somewhat confusing, and 
> I'm not sure I entirely understand it. 
>
> Ian 
>

Ok, than anz other idea to get the binary's main.main function's package's 
path, from the binary?
The other way around (go list -e .../binary) has its own weaknesses (dirs 
with same names)...

-- 
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] Unused var written in closure

[Ian Lance Taylor]

On Sat, Jun 25, 2016 at 12:34 PM, Val  wrote:
> Hello
> It seems that this code doesn't compile :
>
> func main() {
> var err error
> err = f()
> }
>
> prog.go:8: err declared and not used
>
>
> but this one does :
>
> func main() {
> var err error
> g := func() {
> err = f()
> }
> g()
> }
>
> Is the function binding regarded as a "use"?  Or does escape analysis decide
> to not check too deep about never-read variables?
>
> Whether expected or not, I supposed this compiler behavior won't change,
> because of the Go1 compatibility promise.

While the rest of this thread gives something of an explanation, I
think this is a bug, and I think it could be fixed in a future
release.  This is https://golang.org/issue/3059.

The gccgo compiler does give an error for this code.

Ian

-- 
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] Where is .gosymtab in go binaries with cgo?

[Ian Lance Taylor]

On Sun, Jun 26, 2016 at 12:18 AM, Tamás Gulácsi  wrote:
> I want to find out the source package's given the binary.
>
> github.com/FiloSottile/gorebuild (and github.com/rjeczalik/which) works fine
> with binaries built with the "go" tool.
> But fails if cgo (and thus I think gcc) is included in the build procedure.
>
> A minimal example is attached to
> https://github.com/FiloSottile/gorebuild/issues/3
>
> Can anybody help me?

I don't see how the .gosymtab section is relevant here.  It's
currently always empty.  When using external linking, as when building
a program that uses cgo, it gets dropped.  But even when it remains in
the file, it is empty.  I don't think gosymtab has had any contents
since the 1.2 release.  Yes, the situation is somewhat confusing, and
I'm not sure I entirely understand it.

Ian

-- 
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] Custom syscall.Sockaddr

[Elliot Morrison-Reed]

I added the SockaddrCAN type to the golang.org/x/sys/unix package, and it
works great.  I create an issue with links the patch and some test code.

https://github.com/golang/go/issues/16188

On Fri, Jun 24, 2016 at 8:57 PM, Elliot Morrison-Reed 
wrote:

> SocketCAN has been part of mainline linux since kernel 2.6.25 (so getting
> close to a decade now), and it is pretty much the standard for all CAN bus
> communication on linux.
>
> Thanks for the hint, I will look into adding support in the
> golang.org/x/sys/unix package.
>
> Regards,
> Elliot
>
> On Fri, Jun 24, 2016 at 7:52 PM, Ian Lance Taylor  wrote:
>
>> On Fri, Jun 24, 2016 at 8:05 AM,   wrote:
>> >
>> > I am trying to set up an interface from Go to SocketCAN
>> > (https://www.kernel.org/doc/Documentation/networking/can.txt).  This
>> > implements the linux socket interface, however it is a completely
>> separate
>> > socket type from the regular AF_INET or AF_UNIX socket types.
>> >
>> > The sockaddr struct for SocketCAN looks like this:
>> >
>> > struct sockaddr_can {
>> > sa_family_t can_family;
>> > int can_ifindex;
>> > union {
>> > /* transport protocol class address info (e.g. ISOTP) */
>> > struct { canid_t rx_id, tx_id; } tp;
>> >
>> > /* reserved for future CAN protocols address information */
>> > } can_addr;
>> > };
>> >
>> >
>> > Since the union only has one possible entry right now, this is easy
>> enough
>> > to write in Go
>> >
>> > type CanID uint32
>> >
>> > type sockaddrCan struct {
>> >Family  uint16
>> >IfIndex int32
>> >TpRxId  CanID
>> >TpTxId  CanID
>> > }
>> >
>> >
>> > Everything is straight forward so far, but now if I want to pass this to
>> > different syscall functions ( syscall.Bind, syscall.Connect, etc.) I
>> have to
>> > implement the syscall.Sockaddr interface, however looking in the code I
>> see
>> > this:
>> >
>> > type Sockaddr interface {
>> > sockaddr() (ptr unsafe.Pointer, len _Socklen, err error) //
>> lowercase;
>> > only we can define Sockaddrs
>> > }
>> >
>> >
>> > So, finally the questions:
>> >
>> > Why is this interface private? It says that it is, but provides no
>> > rationale.
>> > Does this mean that I have to reimplement all the functions syscall
>> > functions using raw syscall.Syscall?  Or is there some clever way around
>> > this so I can use the syscall package to make a Sockaddr type that is
>> not
>> > already defined.
>>
>> If this is going to be a standard thing in future Linux kernels, I
>> suggest that you add support for it to the golang.org/x/sys/unix
>> package.
>>
>> I don't actually know the answer to why Sockaddr has a private method.
>> I agree that it doesn't seem strictly necessary.
>>
>> Ian
>>
>
>

-- 
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] golang subnet calculation.

[hellobhaskar]

Hello

I have a requirement to take a supernet ("10.0.0.0/8") and split it into 
small subnets say /24 size.
is there any library which i can use ? in python netaddr has useful 
routines which i can use to do the same
on a side note any one aware of  open source IPAM suite written in golang.

-- 
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] Difference between gowalker.org and godoc.org

[DM]

Can some one please explain me the difference between gowalker.org and 
godoc.org? I have viewed this thread 
.
 
But that seems to be little old.

-- 
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: Getting a pointer in a type switch gives a *interface {} if case lists several options

[Constantin Konstantinidis]

A part of the answer is in the specifications as the method set is 
inherited from the type https://golang.org/ref/spec#Method_sets


On Wednesday, June 22, 2016 at 12:02:02 AM UTC+2, raido...@gmail.com wrote:
>
> I have encountered some unexpected and inconsistent behavior with type 
> switches. Can someone shed some light as to why Go behaves this way?
>
> Take a look at https://play.golang.org/p/YPV5YPtWF8
>
> I would expect both of the switches to behave the same way, but for some 
> reason the one with multiple options in the case ends up with a pointer to 
> an interface and the one with just one option ends up with a pointer to the 
> correct type.
>

-- 
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: Unused var written in closure

[Val]

If such an implicit closure struct is implicitly what happens under the 
hood, then this is a very good explanation of the behavior.
And indeed taking the address of err is regarded as a use 
.
Thanks Andrew, thanks folks!

On Sunday, June 26, 2016 at 3:49:51 PM UTC+2, Andrew Mezoni wrote:
>
> >> If you set the var statement outside the main func, the issue is gone 
> because err is then a "global" var.
>
> Not quite correct.
>
> This is how it work and why `err` is used:
>
>
> package main
> import "fmt"
> type closure03 struct {
>   err *error
>   f   func() error
> }
> func (c *closure03) fn() {
>   *c.err = c.f()
> }
> func main() {
>   var err error
>
>   closure03 := &closure03{err: &err, f: f}
>
>   g := closure03.fn
>
>   g()
>   fmt.Println(err)
> }
> func f() error {
>   return fmt.Errorf("Some error occurred")
> }
>
>
> https://play.golang.org/p/ji_8QW1hIr
>
>
>

-- 
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: Unused var written in closure

[Andrew Mezoni]

>> If you set the var statement outside the main func, the issue is gone 
because err is then a "global" var.

Not quite correct.

This is how it work and why `err` is used:


package main
import "fmt"
type closure03 struct {
err *error
f   func() error
}
func (c *closure03) fn() {
*c.err = c.f()
}
func main() {
var err error

closure03 := &closure03{err: &err, f: f}

g := closure03.fn

g()
fmt.Println(err)
}
func f() error {
return fmt.Errorf("Some error occurred")
}


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


-- 
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: Unused var written in closure

[Constantin Konstantinidis]

The official statement is here 
https://golang.org/doc/faq#unused_variables_and_imports
Compiling methods details are slightly above.

On Sunday, June 26, 2016 at 3:15:15 PM UTC+2, Hotei wrote:
>
>
>
> On Saturday, June 25, 2016 at 3:34:57 PM UTC-4, Val wrote:
>>
>> Hello
>> It seems that this code  doesn't 
>> compile :
>>
>> func main() {
>> var err error
>> err = f()
>> }
>>
>> *prog.go:8: err declared and not used*
>>
>>
>> but this one  does :
>>
>> func main() {
>> var err error
>> g := func() {
>> err = f()
>> }
>> g()
>> }
>>
>> Is the function binding regarded as a "use"?  Or does escape analysis 
>> decide to not check too deep about never-read variables?
>>
>> Whether expected or not, I supposed this compiler behavior won't change, 
>> because of the Go1 compatibility promise.
>>
>> Cheers
>>  Val
>>
>
> Assignment isn't "use".  Doesn't matter if it's a function binding or just 
> x = 3,  if you don't use the left side of your "=" later it's a compile 
> error. 
>

-- 
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: Unused var written in closure

[Hotei]

On Saturday, June 25, 2016 at 3:34:57 PM UTC-4, Val wrote:
>
> Hello
> It seems that this code  doesn't 
> compile :
>
> func main() {
> var err error
> err = f()
> }
>
> *prog.go:8: err declared and not used*
>
>
> but this one  does :
>
> func main() {
> var err error
> g := func() {
> err = f()
> }
> g()
> }
>
> Is the function binding regarded as a "use"?  Or does escape analysis 
> decide to not check too deep about never-read variables?
>
> Whether expected or not, I supposed this compiler behavior won't change, 
> because of the Go1 compatibility promise.
>
> Cheers
>  Val
>

Assignment isn't "use".  Doesn't matter if it's a function binding or just 
x = 3,  if you don't use the left side of your "=" later it's a compile 
error. 

-- 
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] Getting a pointer in a type switch gives a *interface {} if case lists several options

[raidopahtma]

Yeah, the way I needed it was to pass a pointer of the correct type and 
have a value stored there. The problem is that when passing a pointer to an 
interface, it seems that the function is unable to figure out where that 
pointer points to (I guess there is an additional step of reflection needed 
for that). Sure I can have a switch for each type, but then I need to 
explicitly write it 8 times, which is basically what I did, was just hoping 
to not have to and let the compiler do it instead - I thought that 
unrolling the switch is what the compiler does, but I guess it doesn't.

On Wednesday, June 22, 2016 at 2:48:21 PM UTC+3, Marvin Renich wrote:
>
> * raido...@gmail.com  > 
> [160621 18:02]: 
> > I have encountered some unexpected and inconsistent behavior with type 
> > switches. Can someone shed some light as to why Go behaves this way? 
> > 
> > Take a look at https://play.golang.org/p/YPV5YPtWF8 
> > 
> > I would expect both of the switches to behave the same way, but for some 
> > reason the one with multiple options in the case ends up with a pointer 
> to 
> > an interface and the one with just one option ends up with a pointer to 
> the 
> > correct type. 
>
> (Aside: reusing the variable t makes it harder to discuss specific 
> instances of that variable.  I am pasting your code here with variable 
> name changes.) 
>
> package main 
>
> import "fmt" 
> import "reflect" 
>
> func main() { 
> var v uint8 = 0 
> var t interface{} = v 
> fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(v), 
> reflect.TypeOf(&v))) 
> switch w := t.(type) { 
> case uint8: 
> fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(w), 
> reflect.TypeOf(&w))) 
> } 
> switch x := t.(type) { 
> case uint8, int8: 
> fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(x), 
> reflect.TypeOf(&x))) 
> } 
> } 
>
> The compiler must know, at compile time, what type w and x are 
> everywhere except in the switch expression itself.  For w in the "case 
> uint8" clause, the type of w is known to be uint8.  For x in the "case 
> uint8, int8" clause, it cannot be determined whether x will be uint8 or 
> int8, so the compiler must use interface{} so that it can generate a 
> single block of code that works for both possible case types. 
>
> If you use different case clauses for the different types, you will get 
> what you expected.  (I.e. add a separate "case int8:" to the first 
> switch statement.) 
>
> ...Marvin 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Unused var written in closure

[Andrew Mezoni]

But what you want if it (`err`) really not used in your example?

func main() {
var err error
err = f()
}

-- 
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: Unused var written in closure

['Murat Knecht' via golang-nuts]

While that fixes the compile issue, the question remains: ‘Is the
function binding regarded as a "use"?’

I, too, am interested in understanding *why* the compiler declares this
closure non-usage as “fine”.


On 06/26/2016 07:28 PM, Constantin Konstantinidis wrote:
> If you set the var statement outside the main func, the issue is gone
> because err is then a "global" var.
> Setting var inside main makes it a local "unused" var.
> If the returning code must be discarded then _ = f() also solves the
> issue.
>
> Regards,
>
> On Saturday, June 25, 2016 at 9:34:57 PM UTC+2, Val wrote:
>
> Hello
> It seems that this code 
> doesn't compile :
>
> |
> func main(){
> varerr error
> err =f()
> }
> |
>
> *prog.go:8: err declared and not used*
>
>
> but this one  does :
>
> |
> func main(){
> varerr error
> g :=func(){
> err =f()
> }
> g()
> }
> |
>
> Is the function binding regarded as a "use"?  Or does escape
> analysis decide to not check too deep about never-read variables?
>
> Whether expected or not, I supposed this compiler behavior won't
> change, because of the Go1 compatibility promise.
>
> Cheers
>  Val
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Unused var written in closure

[Constantin Konstantinidis]

If you set the var statement outside the main func, the issue is gone 
because err is then a "global" var.
Setting var inside main makes it a local "unused" var.
If the returning code must be discarded then _ = f() also solves the issue.

Regards,

On Saturday, June 25, 2016 at 9:34:57 PM UTC+2, Val wrote:
>
> Hello
> It seems that this code  doesn't 
> compile :
>
> func main() {
> var err error
> err = f()
> }
>
> *prog.go:8: err declared and not used*
>
>
> but this one  does :
>
> func main() {
> var err error
> g := func() {
> err = f()
> }
> g()
> }
>
> Is the function binding regarded as a "use"?  Or does escape analysis 
> decide to not check too deep about never-read variables?
>
> Whether expected or not, I supposed this compiler behavior won't change, 
> because of the Go1 compatibility promise.
>
> Cheers
>  Val
>

-- 
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: Any keyboard players here?

[Daniel Skinner]

I made some updates to the example and will make some more. I have some
"text" stuff I'm in the middle of working on, but for the sake of moving
things along, here's a sample of individual keys.

https://drive.google.com/file/d/0B6hxg-gC2Uz_WXlyeno2YUo4Z00/view

I did cheat a little by ignoring how the keys play along with each other,
so when you press 3+ keys in the app, the signals collide and clip due to
how i did the reverb. This was mostly due to time and contest submission,
so i didn't spend much additional time resolving it. It's just lingering on
my TODO.

I fired up tgui-harm but it seems that I need to get an actual midi device
connected before I can make it do anything. I moved recently and have a
desk+chair to put together before i unbox my midi keyboard, so maybe I'll
try it out then. Suggestions otherwise, I'd say go ahead and let a row on
the keyboard play in-place of an actual keyboard.

On Thu, Jun 23, 2016 at 7:44 AM Daniel Skinner  wrote:

> Yes, the Android app is a toy app. Touchscreen or not, the hardware
> latency alone makes that a fact. But that's why it's an example, not the
> root project.
>
> I've been using the gui example as a playground to work out further
> improvements to a separate project and I realize this is in disarray. I
> need to fix that and will be shortly. But ive also added a standalone
> example that runs from command line and generates a tone. Once midi support
> is added, I wanted to bring in the piano sound and let a cli example play a
> piece with it.
>
> I'll try and fix it up this Sunday and let you know. But my interest in
> Android isn't as a target but rather a more general interest in low powered
> devices and hardware I'd like to build on TUIO protocol. The gui example
> itself will break out into its own project but is intended for desktop.
>
> As for how serious anyone takes it, doesn't matter since I record my own
> music and I'm writing these primarily for my own use. Package snd is really
> all about live inputs, for example, once I have FFT, I can create a vocoder
> for a mic based on the input from my guitar and I'll make a song based
> solely on that. This is just what I do, but I've used other libs before I
> wanted more control over the process.
>
> Things like the piano sound will always just be examples for package snd,
> it's just not the intent, only a possibility.
>
>
> On Thu, Jun 23, 2016, 3:46 AM  wrote:
>
>> Hi Daniel,
>>
>> I already investigated your piano and snd projects at github, but could
>> not get them working: too much unknown libraries. Anyhow, it seemed to be
>> aiming at the Android platform, with an on-screen piano keyboard and no
>> MIDI interface. For Android this is a sensible project, but for a musician
>> it qualifies as a toy app, not fit to play real music, and competing with a
>> lot of similar apps. In the past I created several myself, and believe me:
>> you cannot use a touch screen as a real piano keyboard. It's unplayable.
>>
>> About the speed of Go: that depends on what you compare it to. In the
>> past I wrote similar programs in C++. There I used more complicated
>> algorithms, with more calculations at each signal frame, and still the
>> program could run at 48000Hz without problems. So apparently in this area
>> Go is 2x slower then C++. I tried all known trics to increase the speed,
>> like: no garbage creation, and also pre-calculate as much as possible.
>> Increasing the buffer size had little effect, because all needed
>> calculations still must be done.
>>
>> I would love to hear how your piano is sounding. Can't you update your
>> github projects and also augment the README's such that a simple user like
>> me can build something that works?
>>
>> Wouter Boeke
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Where is .gosymtab in go binaries with cgo?

[Tamás Gulácsi]

I want to find out the source package's given the binary.

github.com/FiloSottile/gorebuild (and github.com/rjeczalik/which) works 
fine with binaries built with the "go" tool.
But fails if cgo (and thus I think gcc) is included in the build procedure.

A minimal example is attached to 
https://github.com/FiloSottile/gorebuild/issues/3

Can anybody help me?

Thanks,
Tamás Gulácsi

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