Re: [go-nuts] [Proposal] Std Lib Logging Abstraction

[Sotirios Mantziaris]

let's assume you use a package that logs with std "log" package and my app 
uses something else let's say logrus.
What would the logging result be? Would it not be inconsistent?

On Monday, February 13, 2017 at 9:47:46 AM UTC+2, Jan Mercl wrote:
>
> On Mon, Feb 13, 2017 at 8:44 AM Sotirios Mantziaris  > wrote:
>
>  > ... which prohibit me of using anything else if i want to have a 
> consistent logging experience.
>
> What does "consistent logging experience" mean?
>
> -- 
>
> -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] [Proposal] Std Lib Logging Abstraction

[Jan Mercl]

On Mon, Feb 13, 2017 at 8:44 AM Sotirios Mantziaris 
wrote:

 > ... which prohibit me of using anything else if i want to have a
consistent logging experience.

What does "consistent logging experience" mean?

-- 

-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] [Proposal] Std Lib Logging Abstraction

[Sotirios Mantziaris]

Hi, 

i was wondering if the std lib should implement a logging abstraction so 
that every lib developer can abstract away logging and let the final lib 
user provide the implementation it needs.
The reason for this is that like everybody else i use a lot of open source 
and many of them use std "log" package(some may us other which is worse) 
which prohibit me of using anything else if i want to have a consistent 
logging experience.

-- 
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] 2016 Go User Survey results

[Matt Joiner]

Thanks Dave

On 13 February 2017 at 08:30, Dave Cheney  wrote:

> I raised https://github.com/golang/go/issues/19050 to track this.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/LNdbk97fBiA/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Looking for free, part-time, remote internship.

[Jakob Borg]

You can probably assume by default that any open source project out there with 
open issues welcomes your help. :)

On GitHub, you can list the most starred repos. These are projects that have 
been around for a long time and probably are fairly mature in welcoming new 
contributors. Definitely browse past the first page of results. I see Syncthing 
is still on there and we certainly welcome you. ;) The ones not obviously tied 
to a corporate backer may be more in need - although if you're looking for a 
position at one of the companies in question this could maybe be an inroad, I 
don't know.

https://github.com/search?l=go=stars%3A%3E1=stars=Repositories

There are also the currently trending ones, although these may in some sense be 
the ones least in need of additional help since they are apparently getting 
lots of attention now anyway. But they are also hot (and cool) and probably get 
lots of bug reports if they are just coming into fame.

https://github.com/trending/go?since=monthly

Try to find something that you use yourself, or that uses a technology or 
solves a problem you find interesting.

//jb


> On 13 Feb 2017, at 03:09, Néstor  wrote:
> 
> Hi,
> 
> I like e in San Diego, California and I am in the same boat as Malhar, 
> looking for a chance in the Golang world.
> 
> Jonathan, how do you find out about open source projects  in Golang that need 
> help?
> 
> Thanks,
> 
> Néstor
> 
> 
> On Feb 12, 2017 5:35 PM, "Jonathan Yu"  wrote:
> Have you considered contributing to an open source project of interest to you?
> 
> 
> On Sun, Feb 12, 2017, 10:27 Malhar Vora  wrote:
>   
>  
>  
>  Hi Everyone,
> 
>  I am looking for part-time, remote internship kind of opportunity to 
> work for completely free to learn Golang. Can anyone help me with that ?.
> 
>  Just for your information I already have 3 years of experience in Python 
> and zero experience in Golang.
> 
>  Please inbox me at mlvora.2...@gmail.com.
> 
> 
> 
> 
> 
> 
> 
>  Thanks,
>  Malhar Vora
> 
> -- 
> 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.
> -- 
> Jonathan Yu / @jawnsy on LinkedIn, Twitter, GitHub, Facebook
> “Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.” — 
> Samuel Beckett, Worstward Ho (1983) 
> 
> “In an adaptive environment, winning comes from adapting to change by 
> continuously experimenting and identifying new options more quickly and 
> economically than others. The classical strategist's mantra of sustainable 
> competitive advantage becomes one of serial temporary advantage.” — 
> Navigating the Dozens of Different Strategy Options (HBR)
> 
> 
> -- 
> 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.

-- 
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] Writing safe CGO calls and callbacks and how that affects system threads

[Luka Napotnik]

Thanks for the answers. I'll play around with C.gettid.

Greets,

On Mon, Feb 13, 2017 at 7:06 AM, Ian Lance Taylor  
wrote:

On Sun, Feb 12, 2017 at 9:57 PM, Luka Napotnik  wrote:
 Thanks for the reply. I've created a test program with function F1 
that

 calls a C function F2. The function F2 then calls a Go function F3.

 I've started the test once with GOMAXPROCS set to 1, and the second 
time
 without an env. (using Go 1.7). There are short pauses between 
calls and
 I've measured the number of system threads used by the process with 
ps -o

 nlwp.

 I found that when running the test with GOMAXPROCS=1, a new thread 
is always
 spawned when the C function F2 calls a Go function, but not if the 
env. is
 not set. Why is that? I know GOMAXPROCS can be ignored in some 
cases, so I
 assumed the GO runtime needed an extra thread for executing 
function F3,

 after it was called from C.


I would guess that the new thread is being spawned to run the system
monitor or to run the garbage collector.  But without seeing your
program I don't actually know.

You can check for yourself whether you are running in the same thread
easily enough by calling C.gettid.

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] Writing safe CGO calls and callbacks and how that affects system threads

[Ian Lance Taylor]

On Sun, Feb 12, 2017 at 9:57 PM, Luka Napotnik  wrote:
> Thanks for the reply. I've created a test program with function F1 that
> calls a C function F2. The function F2 then calls a Go function F3.
>
> I've started the test once with GOMAXPROCS set to 1, and the second time
> without an env. (using Go 1.7). There are short pauses between calls and
> I've measured the number of system threads used by the process with ps -o
> nlwp.
>
> I found that when running the test with GOMAXPROCS=1, a new thread is always
> spawned when the C function F2 calls a Go function, but not if the env. is
> not set. Why is that? I know GOMAXPROCS can be ignored in some cases, so I
> assumed the GO runtime needed an extra thread for executing function F3,
> after it was called from C.

I would guess that the new thread is being spawned to run the system
monitor or to run the garbage collector.  But without seeing your
program I don't actually know.

You can check for yourself whether you are running in the same thread
easily enough by calling C.gettid.

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] The feature I want most, weak *

[Ian Lance Taylor]

On Fri, Feb 10, 2017 at 10:04 PM, Keynan Pratt  wrote:
> Yes it CAN be implemented that way, but that throws away type information,
> and makes code less readable.

The question of compile-time type information boils down to the generics issue.

> It also seems to conflate the difference
> between language and library, i suppose go has already trod that bridge.
> What I'm asking for is something that can be used to reason about programs
> at compile time. It seems like an opaque type at runtime wouldn't achieve
> this. For example, if you where to implement this type could I still do
>
> var x interface{} = nil
>
> ?
>
> If you have weak as a language feature you can make that illegal, insisting
> that only
>
> var x weak interface{} = nil
>
> is allowed, and any program written for a compiler that enforces
> non-nullable strong pointers would be valid to compile with the official
> compiler. Fast compile time is great, it's part of the reason I love go. But
> it would be nice to have a flag I can turn on that gets me some of those
> wonderful correctness checking features that you see in languages with
> stronger type systems. Avoiding nulls just seems like the bare minimum. So
> those are the things we theoretically get. On the other hand what is the
> cost of adding this? I suspect it is (very) small and I also acknowledge it
> will never get added. I just think that's a shame.

I'm sorry, but that doesn't seem to me like Go.  Go is a language with
a simple type system.  I can understand how weak pointers could fit
into Go.  But once you start saying that we are going to reject
storing nil in an interface value unless it is weak, then you are
greatly complicating the type system.  The cost of adding that kind of
complexity to the language is high.  The cost is not in
implementation--though I don't see offhand how to implement it, since
now non-weak interfaces have no zero value--the cost is in requiring
everybody learning the language to learn a complex new concept.

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] Writing safe CGO calls and callbacks and how that affects system threads

[Luka Napotnik]

I forgot to mention that the main goroutine in the test program is 
locked to a thread as I call runtime.LockOSThread() in init()


Greets,

On Mon, Feb 13, 2017 at 6:57 AM, Luka Napotnik  wrote:
Thanks for the reply. I've created a test program with function F1 
that calls a C function F2. The function F2 then calls a Go function 
F3.


I've started the test once with GOMAXPROCS set to 1, and the second 
time without an env. (using Go 1.7). There are short pauses between 
calls and I've measured the number of system threads used by the 
process with ps -o nlwp.


I found that when running the test with GOMAXPROCS=1, a new thread is 
always spawned when the C function F2 calls a Go function, but not if 
the env. is not set. Why is that? I know GOMAXPROCS can be ignored in 
some cases, so I assumed the GO runtime needed an extra thread for 
executing function F3, after it was called from C.


Greets,

On Mon, Feb 13, 2017 at 6:17 AM, Ian Lance Taylor  
wrote:

On Sun, Feb 12, 2017 at 1:47 AM,   wrote:
 Hello. I have a Go program that calls C functions in order to 
create a Gtk+
 GUI. Because Gtk+ itself isn't thread-safe, I'm wondering if it's 
even
 possible to write GUI apps this way since there's no guarantee 
that the same
 thread will be used to call the API (even if I lock the main 
goroutine

 inside a OS thread). Am I correct?


You have to arrange to make all Gtk calls from a single goroutine, 
and

you have to make that single goroutine call runtime.LockOSThread
before it makes any Gtk calls.  Making all the calls from a single
goroutine typically means that that goroutine has to sit waiting on a
channel that other goroutines use to tell it what to do.  This
approach should be reliable.

 Also, what happens if the called CGO function calls a Go function? 
Can it
 happen that the Go runtime will create a new thread, because the 
previous

 one is still locked?


If a Go function F1 calls a C function and the C function (running in
the same C thread) calls a Go function F2, F2 will run in the same
thread as F1.  This is true whether or not F1 is locked to the 
thread.

In fact, for the duration of the C function, the goroutine will be
locked to the thread anyhow.

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] Writing safe CGO calls and callbacks and how that affects system threads

[Luka Napotnik]

Thanks for the reply. I've created a test program with function F1 that 
calls a C function F2. The function F2 then calls a Go function F3.


I've started the test once with GOMAXPROCS set to 1, and the second 
time without an env. (using Go 1.7). There are short pauses between 
calls and I've measured the number of system threads used by the 
process with ps -o nlwp.


I found that when running the test with GOMAXPROCS=1, a new thread is 
always spawned when the C function F2 calls a Go function, but not if 
the env. is not set. Why is that? I know GOMAXPROCS can be ignored in 
some cases, so I assumed the GO runtime needed an extra thread for 
executing function F3, after it was called from C.


Greets,

On Mon, Feb 13, 2017 at 6:17 AM, Ian Lance Taylor  
wrote:

On Sun, Feb 12, 2017 at 1:47 AM,   wrote:
 Hello. I have a Go program that calls C functions in order to 
create a Gtk+
 GUI. Because Gtk+ itself isn't thread-safe, I'm wondering if it's 
even
 possible to write GUI apps this way since there's no guarantee that 
the same
 thread will be used to call the API (even if I lock the main 
goroutine

 inside a OS thread). Am I correct?


You have to arrange to make all Gtk calls from a single goroutine, and
you have to make that single goroutine call runtime.LockOSThread
before it makes any Gtk calls.  Making all the calls from a single
goroutine typically means that that goroutine has to sit waiting on a
channel that other goroutines use to tell it what to do.  This
approach should be reliable.

 Also, what happens if the called CGO function calls a Go function? 
Can it
 happen that the Go runtime will create a new thread, because the 
previous

 one is still locked?


If a Go function F1 calls a C function and the C function (running in
the same C thread) calls a Go function F2, F2 will run in the same
thread as F1.  This is true whether or not F1 is locked to the thread.
In fact, for the duration of the C function, the goroutine will be
locked to the thread anyhow.

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: Unexpected Behaviour of goroutine

[peterGo]

Srivathsan,

Go Frequently Asked Questions (FAQ)
What happens with closures running as goroutines?
https://golang.org/doc/faq#closures_and_goroutines

Peter

On Sunday, February 12, 2017 at 5:51:14 AM UTC-5, Srivathsan Madhavan wrote:
>
> Hi all,
>
> I still consider myself a newbie to Golang hence my question here could be 
> due to my fundamental misunderstanding of this language
>
> I have the following code:
>
> func main() {
>
> for i := 0; i < 5; i++ {
>
> go func() {
>
> log.Println("i=", i)
>
> }()
>
> }
>
>
> fmt.Print("Press  to quit...")
>
> var input string
>
> fmt.Scanln()
>
> }
>
>
> The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But what I 
> got was 5, 5, 5, 5 and 5!  Why is that so?
>
> Thanks in advance
>
> rgds,
> Vatsan
>

-- 
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] Unexpected Behaviour of goroutine

[Michael Jones]

asking is good! first, it helps people who are too shy or insecure to ask.
second, it is part of the adventure of learning.

it has often been my experience that the people with the most and best
questions end up with the best understanding and spirit.

On Sun, Feb 12, 2017 at 9:36 PM, Vatsan  wrote:

> Thanks to all who answered; I got explanation I needed.
>
> @"Michael Jones": yes, your solution also works - "i := i" overshadows the
> i defined as part of the for-loop and that was also explained in one of the
> Go-blogs.
>
> Anyways, as I have already acknowledged earlier, this was an RTFM moment
> for me.  Had I read the relevant blogs / articles earlier, I wouldn't have
> asked this at all.
>
> rgds,
> Vatsan
>
> Google+ 
> Maverick Software Engineer
> 
>
> On Sun, Feb 12, 2017 at 8:20 PM, Michael Jones 
> wrote:
>
>> These answers are all correct.
>>
>> Here is another way to see the problem and address it. Not as clear to
>> the next reader perhaps so not the recommendation, but a good example to
>> contemplate. "Precisely what does this extra statement do?"
>>
>> package main
>>
>> import "fmt"
>> import "log"
>>
>> func main() {
>> for i := 0; i < 5; i++ {
>> i := i
>> go func() {
>> log.Println("i=", i)
>> }()
>> }
>>
>> fmt.Print("Press  to quit...")
>> var input string
>> fmt.Scanln()
>> }
>>
>>
>>
>> On Sun, Feb 12, 2017 at 3:12 AM, Ayan George  wrote:
>>
>>> Srivathsan Madhavan  wrote:
>>>
>>> > Hi all,
>>> >
>>> > I still consider myself a newbie to Golang hence my question here
>>> could be
>>> > due to my fundamental misunderstanding of this language
>>> >
>>> > I have the following code:
>>> >
>>> > func main() {
>>> >
>>> > for i := 0; i < 5; i++ {
>>> >
>>> > go func() {
>>> >
>>> > log.Println("i=", i)
>>> >
>>> > }()
>>> >
>>> > }
>>> >
>>> >
>>> > fmt.Print("Press  to quit...")
>>> >
>>> > var input string
>>> >
>>> > fmt.Scanln()
>>> >
>>> > }
>>> >
>>> >
>>> > The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But
>>> what I
>>> > got was 5, 5, 5, 5 and 5!  Why is that so?
>>> >
>>>
>>> I'm learning golang too so please correct any errors here.
>>>
>>> It looks like you created a closure where i is lexically scoped to
>>> each of your gofunc() instances.  Since they're all accessing the same
>>> i variable, you're seeing the race between incrementing i and spooling
>>> up / starting each goroutine -- that is, the value of i reaches 5
>>> before all of the goroutines get to print it.  You can verify this by
>>> printing the address of i by changing your log.Println() call to
>>> something like:
>>>
>>>   log.Printf("i = %d,  = %p", i, )
>>>
>>> The addresses should be the same.
>>>
>>> If you want each goroutine to have a copy of I, you should declare and
>>> run gofunc() like below:
>>>
>>> gofunc(c int) {
>>>   log.Println("c=",c)
>>> }(i)
>>>
>>> Which passes a copy of i to each routine.  That should give you what
>>> you're looking for -- that is if you're not expecting i to be printed
>>> in order. :)
>>>
>>> -ayan
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Michael T. Jones
>> michael.jo...@gmail.com
>>
>
>


-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] Unexpected Behaviour of goroutine

[Vatsan]

Thanks to all who answered; I got explanation I needed.

@"Michael Jones": yes, your solution also works - "i := i" overshadows the
i defined as part of the for-loop and that was also explained in one of the
Go-blogs.

Anyways, as I have already acknowledged earlier, this was an RTFM moment
for me.  Had I read the relevant blogs / articles earlier, I wouldn't have
asked this at all.

rgds,
Vatsan

Google+ 
Maverick Software Engineer


On Sun, Feb 12, 2017 at 8:20 PM, Michael Jones 
wrote:

> These answers are all correct.
>
> Here is another way to see the problem and address it. Not as clear to the
> next reader perhaps so not the recommendation, but a good example to
> contemplate. "Precisely what does this extra statement do?"
>
> package main
>
> import "fmt"
> import "log"
>
> func main() {
> for i := 0; i < 5; i++ {
> i := i
> go func() {
> log.Println("i=", i)
> }()
> }
>
> fmt.Print("Press  to quit...")
> var input string
> fmt.Scanln()
> }
>
>
>
> On Sun, Feb 12, 2017 at 3:12 AM, Ayan George  wrote:
>
>> Srivathsan Madhavan  wrote:
>>
>> > Hi all,
>> >
>> > I still consider myself a newbie to Golang hence my question here could
>> be
>> > due to my fundamental misunderstanding of this language
>> >
>> > I have the following code:
>> >
>> > func main() {
>> >
>> > for i := 0; i < 5; i++ {
>> >
>> > go func() {
>> >
>> > log.Println("i=", i)
>> >
>> > }()
>> >
>> > }
>> >
>> >
>> > fmt.Print("Press  to quit...")
>> >
>> > var input string
>> >
>> > fmt.Scanln()
>> >
>> > }
>> >
>> >
>> > The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But
>> what I
>> > got was 5, 5, 5, 5 and 5!  Why is that so?
>> >
>>
>> I'm learning golang too so please correct any errors here.
>>
>> It looks like you created a closure where i is lexically scoped to
>> each of your gofunc() instances.  Since they're all accessing the same
>> i variable, you're seeing the race between incrementing i and spooling
>> up / starting each goroutine -- that is, the value of i reaches 5
>> before all of the goroutines get to print it.  You can verify this by
>> printing the address of i by changing your log.Println() call to
>> something like:
>>
>>   log.Printf("i = %d,  = %p", i, )
>>
>> The addresses should be the same.
>>
>> If you want each goroutine to have a copy of I, you should declare and
>> run gofunc() like below:
>>
>> gofunc(c int) {
>>   log.Println("c=",c)
>> }(i)
>>
>> Which passes a copy of i to each routine.  That should give you what
>> you're looking for -- that is if you're not expecting i to be printed
>> in order. :)
>>
>> -ayan
>>
>> --
>> 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.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>

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

Re: [go-nuts] Writing safe CGO calls and callbacks and how that affects system threads

[Ian Lance Taylor]

On Sun, Feb 12, 2017 at 1:47 AM,   wrote:
> Hello. I have a Go program that calls C functions in order to create a Gtk+
> GUI. Because Gtk+ itself isn't thread-safe, I'm wondering if it's even
> possible to write GUI apps this way since there's no guarantee that the same
> thread will be used to call the API (even if I lock the main goroutine
> inside a OS thread). Am I correct?

You have to arrange to make all Gtk calls from a single goroutine, and
you have to make that single goroutine call runtime.LockOSThread
before it makes any Gtk calls.  Making all the calls from a single
goroutine typically means that that goroutine has to sit waiting on a
channel that other goroutines use to tell it what to do.  This
approach should be reliable.

> Also, what happens if the called CGO function calls a Go function? Can it
> happen that the Go runtime will create a new thread, because the previous
> one is still locked?

If a Go function F1 calls a C function and the C function (running in
the same C thread) calls a Go function F2, F2 will run in the same
thread as F1.  This is true whether or not F1 is locked to the thread.
In fact, for the duration of the C function, the goroutine will be
locked to the thread anyhow.

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] Looking for free, part-time, remote internship.

[Néstor]

Hi,

I like e in San Diego, California and I am in the same boat as Malhar,
looking for a chance in the Golang world.

Jonathan, how do you find out about open source projects  in Golang that
need help?

Thanks,

Néstor


On Feb 12, 2017 5:35 PM, "Jonathan Yu"  wrote:

Have you considered contributing to an open source project of interest to
you?


On Sun, Feb 12, 2017, 10:27 Malhar Vora  wrote:

>
>
>
>  Hi Everyone,
>
>  I am looking for part-time, remote internship kind of opportunity to
> work for completely free to learn Golang. Can anyone help me with that ?.
>
>  Just for your information I already have 3 years of experience in
> Python and zero experience in Golang.
>
>  Please inbox me at mlvora.2...@gmail.com.
>
>
>
>
>
>
>
>  Thanks,
>  Malhar Vora
>
> --
> 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.
>
-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 

*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

-- 
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] Looking for free, part-time, remote internship.

[Jonathan Yu]

Have you considered contributing to an open source project of interest to
you?

On Sun, Feb 12, 2017, 10:27 Malhar Vora  wrote:

>
>
>
>  Hi Everyone,
>
>  I am looking for part-time, remote internship kind of opportunity to
> work for completely free to learn Golang. Can anyone help me with that ?.
>
>  Just for your information I already have 3 years of experience in
> Python and zero experience in Golang.
>
>  Please inbox me at mlvora.2...@gmail.com.
>
>
>
>
>
>
>
>  Thanks,
>  Malhar Vora
>
> --
> 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.
>
-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 

*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

-- 
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: Panic in go1.8rc3 using cgo to get binary data from database

[Daniel Theophanes]

It is difficult to be certain, but I would put my bets on your sql anywhere 
driver may not be handling the c data lifetimes correctly, or might not be 
keeping a reference. It is difficult to tell without the driver code.

Thanks, -Daniel

On Saturday, February 11, 2017 at 7:27:11 PM UTC-8, Mark Crook wrote:
>
> Hello,
>
> I'm seeing a panic in go version go1.8rc3 linux/amd64 while trying to 
> write a database driver using cgo. The go code runs in a docker container, 
> the database in another.
>
> Generally it works reliably, but occasionally, during repeated retrieval 
> of binary data (photos approx 100K to 2M), the code panics.
>
> I haven't isolated a reproducible example, but I think it's related to 
> this code:
>
>
> value := new(C.a_sqlany_data_value)
>
> //load the column value binary data into value.buffer
>
> C.sqlany_get_column(r.stmt.ptr, C.sacapi_u32(i), value)
>
>
> //copy the value buffer from C to Go
>
> val = C.GoBytes(unsafe.Pointer(value.buffer), C.int(value.length))
>
>
> I haven't seen the panic if the last line is commented out.
>
> Below is a stack trace. Perhaps it panics when a garbage collection is 
> triggered while waiting for C.GoBytes to return?
>
> Any suggestions?
>
> Thank you,
> Mark
>
>  
>
> runtime: unexpected return pc for runtime.sigpanic called from 0xc420e1a000
> fatal error: unknown caller pc
>
> runtime stack:
> runtime.throw(0x59a90e, 0x11)
> /go/src/runtime/panic.go:596 +0x95
> runtime.gentraceback(0x, 0xc42002a5d8, 0x0, 0xc4200c49c0, 
> 0x0, 0x0, 0x7fff, 0x7fb675ad5cb8, 0x0, 0x0, ...)
> /go/src/runtime/traceback.go:317 +0x13ea
> runtime.scanstack(0xc4200c49c0, 0xc420021828)
> /go/src/runtime/mgcmark.go:842 +0x265
> runtime.newstack(0x0)
> /go/src/runtime/stack.go:1064 +0x41e
> runtime.morestack()
> /go/src/runtime/asm_amd64.s:398 +0x86
>
> goroutine 11 [GC worker (idle) (scan)]:
> runtime.assertE2I2(0x56c220, 0x569e20, 0x841d20, 0xc42002a6b0, 
> 0xc4200c49e0, 0xc42002a640)
> /go/src/runtime/iface.go:289 +0xb2 fp=0xc42002a5e0 sp=0xc42002a5d8
> runtime.preprintpanics(0xc42002a6b0)
> /go/src/runtime/panic.go:389 +0x9f fp=0xc42002a650 sp=0xc42002a5e0
> panic(0x569e20, 0x841d20)
> /go/src/runtime/panic.go:528 +0x1ab fp=0xc42002a6e8 sp=0xc42002a650
> runtime.panicmem()
> /go/src/runtime/panic.go:63 +0x5e fp=0xc42002a708 sp=0xc42002a6e8
> runtime.sigpanic()
> /go/src/runtime/signal_unix.go:290 +0x29f fp=0xc42002a758 sp=0xc42002a708
> created by runtime.gcBgMarkStartWorkers
> /go/src/runtime/mgc.go:1410 +0x98
>
> goroutine 1 [chan receive]:
> testing.(*T).Run(0xc420072820, 0x598622, 0x8, 0x5a3718, 0xc420051d01)
> /go/src/testing/testing.go:698 +0x2f4
> testing.runTests.func1(0xc420072820)
> /go/src/testing/testing.go:881 +0x67
> testing.tRunner(0xc420072820, 0xc420051de0)
> /go/src/testing/testing.go:657 +0x96
> testing.runTests(0xc42000cb60, 0x8461e0, 0x4, 0x4, 0xc420051ef8)
> /go/src/testing/testing.go:887 +0x2c1
> testing.(*M).Run(0xc420051f20, 0xc420051f20)
> /go/src/testing/testing.go:822 +0xfc
> main.main()
> github.com/mdcnz/sqlanywhere/_test/_testmain.go:48 +0xf7
>
> goroutine 17 [syscall, 6 minutes, locked to thread]:
> runtime.goexit()
> /go/src/runtime/asm_amd64.s:2197 +0x1
>
> goroutine 231 [GC assist wait]:
> database/sql.convertAssign(0x5517a0, 0xc4200c20a0, 0x55a040, 0xc42000c0e0, 
> 0x85b5c0, 0x4535c0)
> /go/src/database/sql/convert.go:161 +0x1a22
> database/sql.(*Rows).Scan(0xc42001c6c0, 0xc420041f68, 0x1, 0x1, 0x0, 0x0)
> /go/src/database/sql/sql.go:2342 +0xca
> github.com/mdcnz/sqlanywhere.TestBlob(0xc4200728f0)
> /root/gome/src/github.com/mdcnz/sqlanywhere/test.go:26 +0x2a5
> testing.tRunner(0xc4200728f0, 0x5a3718)
> /go/src/testing/testing.go:657 +0x96
> created by testing.(*T).Run
> /go/src/testing/testing.go:697 +0x2ca
>
> goroutine 233 [chan receive]:
> database/sql.(*Rows).awaitDone(0xc42001c6c0, 0x84b240, 0xc42047e080)
> /go/src/database/sql/sql.go:2091 +0x54
> created by database/sql.(*Rows).initContextClose
> /go/src/database/sql/sql.go:2086 +0x92
>
> goroutine 232 [chan receive]:
> database/sql.(*DB).connectionOpener(0xc42008c210)
> /go/src/database/sql/sql.go:835 +0x4a
> created by database/sql.Open
> /go/src/database/sql/sql.go:580 +0x1c8
> exit status 2
>
>

-- 
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: Panic in go1.8rc3 using cgo to get binary data from database

[Mark Crook]

Thanks Damian

On Monday, 13 February 2017 04:29:59 UTC+13, Damian Gryski wrote:
>
> Please file an issue at https://golang.org/issues
>
> Damian
>

-- 
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] 2016 Go User Survey results

[Dave Cheney]

I raised https://github.com/golang/go/issues/19050 to track this. 

-- 
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] Given a `[]string` key list and a `map[string]interface{}`, can we find the value?

[John Feminella]

Agreed on the panic, and yours handles that better. (Although I hope it's
obvious that this was just a toy example and not the real thing!)
best,~ jf--John Feminella@jxxfhttp://jxf.me  





On Sun, Feb 12, 2017 3:23 PM, Paul Borman bor...@google.com  wrote:
Your code can panic. Take a look at:
https://play.golang.org/p/MrPtar9oEK
traverse2 has the type assertion. Notice how the call to traverse2 works but the
following call to traverse panics.
-Paul
On Sun, Feb 12, 2017 at 12:06 PM, John Feminella   wrote:
Thanks. I wound up doing this with a recursive traversal:
https://play.golang.org/p/k9iy3sHOZ9
best,~ jf--John Feminella@jxxfhttp://jxf.me  





On Sun, Feb 12, 2017 3:05 PM, Paul Borman bor...@google.com  wrote:
Take a look at the reflect package, or if you know that the only internal maps
will be of type map[string]interface{} you can use type assertion to determine
if the element is a map or some other type.
On Sun, Feb 12, 2017 at 7:53 AM,   wrote:
I would like to write a function which, given:
* a `[]string` keys, and * a `map[string]interface{}` m,
will return the value obtained by traversing `m` for each key in `keys`.
For example, if `m` looks like:
{ "foo": 123, "bar": map[string]interface{}{ "one": 111, "two": "22" }, }
then I would like to be able to pass `["bar", "two"]` and receive `"22"`.
Similarly I would like to be able to pass ["foo"] and receive `123`.
Does this make sense? Is this doable?  

-- 
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] Given a `[]string` key list and a `map[string]interface{}`, can we find the value?

['Paul Borman' via golang-nuts]

Your code can panic.  Take a look at:

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

traverse2 has the type assertion.  Notice how the call to traverse2 works
but the following call to traverse panics.

-Paul

On Sun, Feb 12, 2017 at 12:06 PM, John Feminella  wrote:

> Thanks. I wound up doing this with a recursive traversal:
>
> https://play.golang.org/p/k9iy3sHOZ9
>
> best,
> ~ jf
> --
> John Feminella
> @jxxf
> http://jxf.me
>
>
>
> On Sun, Feb 12, 2017 3:05 PM, Paul Borman bor...@google.com wrote:
>
>> Take a look at the reflect package, or if you know that the only internal
>> maps will be of type map[string]interface{} you can use type assertion to
>> determine if the element is a map or some other type.
>>
>> On Sun, Feb 12, 2017 at 7:53 AM,  wrote:
>>
>> I would like to write a function which, given:
>>
>>  * a `[]string` keys, and
>>  * a `map[string]interface{}` m,
>>
>> will return the value obtained by traversing `m` for each key in `keys`.
>>
>> For example, if `m` looks like:
>>
>>  {
>>  "foo": 123,
>>  "bar": map[string]interface{}{
>>  "one": 111,
>>  "two": "22"
>>  },
>>  }
>>
>> then I would like to be able to pass `["bar", "two"]` and receive
>> `"22"`. Similarly I would like to be able to pass ["foo"] and receive
>> `123`.
>>
>> Does this make sense? Is this doable?
>>
>> --
>> 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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [go-nuts] Given a `[]string` key list and a `map[string]interface{}`, can we find the value?

[John Feminella]

Thanks. I wound up doing this with a recursive traversal:
https://play.golang.org/p/k9iy3sHOZ9
best,~ jf--John Feminella@jxxfhttp://jxf.me  





On Sun, Feb 12, 2017 3:05 PM, Paul Borman bor...@google.com  wrote:
Take a look at the reflect package, or if you know that the only internal maps
will be of type map[string]interface{} you can use type assertion to determine
if the element is a map or some other type.
On Sun, Feb 12, 2017 at 7:53 AM,   wrote:
I would like to write a function which, given:
* a `[]string` keys, and * a `map[string]interface{}` m,
will return the value obtained by traversing `m` for each key in `keys`.
For example, if `m` looks like:
{ "foo": 123, "bar": map[string]interface{}{ "one": 111, "two": "22" }, }
then I would like to be able to pass `["bar", "two"]` and receive `"22"`.
Similarly I would like to be able to pass ["foo"] and receive `123`.
Does this make sense? Is this doable?  

-- 
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] Given a `[]string` key list and a `map[string]interface{}`, can we find the value?

['Paul Borman' via golang-nuts]

Take a look at the reflect package, or if you know that the only internal
maps will be of type map[string]interface{} you can use type assertion to
determine if the element is a map or some other type.

On Sun, Feb 12, 2017 at 7:53 AM,  wrote:

> I would like to write a function which, given:
>
>   * a `[]string` keys, and
>   * a `map[string]interface{}` m,
>
> will return the value obtained by traversing `m` for each key in `keys`.
>
> For example, if `m` looks like:
>
>   {
> "foo": 123,
> "bar": map[string]interface{}{
>   "one": 111,
>   "two": "22"
> },
>   }
>
> then I would like to be able to pass `["bar", "two"]` and receive
> `"22"`. Similarly I would like to be able to pass ["foo"] and receive
> `123`.
>
> Does this make sense? Is this doable?
>
> --
> 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.


smime.p7s
Description: S/MIME Cryptographic Signature

[go-nuts] A new Golang build tool release

[zhangbodut]

Hi list,

Recently I have implemented a build tool named Gogradle to provide fully 
automatic support for Golang. It is a Gradle plugin which supports 
automatic project-scoped dependency management and many other features:

- Perfect cross-platform support, all tests have passed on OS/Windows/Linux
- No need to preinstall Go and GOPATH, multiple Golang version can exist 
together
- Automatic dependency management, including transitive dependency, 
dependency locking, vendor, dependency flattening, automatic conflict 
resolution, SemVersion and so on
- Various external tools such as 
glide/glock/godep/gom/gopm/govendor/gvt/gbvendor/trash import
- Dependency tree visualization
- Multiple vcs tool
- Build/test/cross-compile
- Various  availble Gradle plugins to do production-grade build
...
and more.

To see more features, please visit https://github.com/blindpirate/gogradle 

PRs and issues are always welcomed.

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.

[go-nuts] Writing safe CGO calls and callbacks and how that affects system threads

[luka]

Hello. I have a Go program that calls C functions in order to create a Gtk+ 
GUI. Because Gtk+ itself isn't thread-safe, I'm wondering if it's even 
possible to write GUI apps this way since there's no guarantee that the 
same thread will be used to call the API (even if I lock the main goroutine 
inside a OS thread). Am I correct?

Also, what happens if the called CGO function calls a Go function? Can it 
happen that the Go runtime will create a new thread, because the previous 
one is still locked? 

Greets,
Luka

-- 
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] Looking for free, part-time, remote internship.

[Malhar Vora]

  
 
 
 Hi Everyone,

 I am looking for part-time, remote internship kind of opportunity to 
work for completely free to learn Golang. Can anyone help me with that ?.

 Just for your information I already have 3 years of experience in 
Python and zero experience in Golang.

 Please inbox me at mlvora.2...@gmail.com.







 Thanks,
 Malhar Vora

-- 
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: Struggling with working directory

[Igor Maznitsa]

also you can try build golang projects through mvn-golang (with the java 
maven tool)  in the case you should 
play with environment much less

-- 
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] Given a `[]string` key list and a `map[string]interface{}`, can we find the value?

[jxf]

I would like to write a function which, given:

  * a `[]string` keys, and 
  * a `map[string]interface{}` m,

will return the value obtained by traversing `m` for each key in `keys`.

For example, if `m` looks like:

  {
"foo": 123,
"bar": map[string]interface{}{
  "one": 111,
  "two": "22"
},
  }

then I would like to be able to pass `["bar", "two"]` and receive 
`"22"`. Similarly I would like to be able to pass ["foo"] and receive 
`123`.

Does this make sense? Is this doable?

-- 
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] Panic in go1.8rc3 using cgo to get binary data from database

[Damian Gryski]

Please file an issue at https://golang.org/issues

Damian

-- 
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] Unexpected Behaviour of goroutine

[Michael Jones]

These answers are all correct.

Here is another way to see the problem and address it. Not as clear to the
next reader perhaps so not the recommendation, but a good example to
contemplate. "Precisely what does this extra statement do?"

package main

import "fmt"
import "log"

func main() {
for i := 0; i < 5; i++ {
i := i
go func() {
log.Println("i=", i)
}()
}

fmt.Print("Press  to quit...")
var input string
fmt.Scanln()
}



On Sun, Feb 12, 2017 at 3:12 AM, Ayan George  wrote:

> Srivathsan Madhavan  wrote:
>
> > Hi all,
> >
> > I still consider myself a newbie to Golang hence my question here could
> be
> > due to my fundamental misunderstanding of this language
> >
> > I have the following code:
> >
> > func main() {
> >
> > for i := 0; i < 5; i++ {
> >
> > go func() {
> >
> > log.Println("i=", i)
> >
> > }()
> >
> > }
> >
> >
> > fmt.Print("Press  to quit...")
> >
> > var input string
> >
> > fmt.Scanln()
> >
> > }
> >
> >
> > The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But what
> I
> > got was 5, 5, 5, 5 and 5!  Why is that so?
> >
>
> I'm learning golang too so please correct any errors here.
>
> It looks like you created a closure where i is lexically scoped to
> each of your gofunc() instances.  Since they're all accessing the same
> i variable, you're seeing the race between incrementing i and spooling
> up / starting each goroutine -- that is, the value of i reaches 5
> before all of the goroutines get to print it.  You can verify this by
> printing the address of i by changing your log.Println() call to
> something like:
>
>   log.Printf("i = %d,  = %p", i, )
>
> The addresses should be the same.
>
> If you want each goroutine to have a copy of I, you should declare and
> run gofunc() like below:
>
> gofunc(c int) {
>   log.Println("c=",c)
> }(i)
>
> Which passes a copy of i to each routine.  That should give you what
> you're looking for -- that is if you're not expecting i to be printed
> in order. :)
>
> -ayan
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] Go Optimizations for IO Intensive programs

[Jan Mercl]

On Sat, Feb 11, 2017 at 1:58 AM  wrote:

> Are there any other methodologies where I can optimize compresssion part
and upload part

Many ISPs have upload speed several times slower than download. The
symptoms you described would be consistent with that. But maybe you have a
better, symmetric connection?

-- 

-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 Optimizations for IO Intensive programs

[Jesper Louis Andersen]

On Sat, Feb 11, 2017 at 1:58 AM  wrote:

> Are there any other methodologies where I can optimize compresssion part
> and upload part
>
>
Start by establishing a baseline. If you just grab the files from S3 and do
nothing to to them, how fast is that? If you are not CPU-bound, chances are
that you are just saturating something else, the IO-layer of the kernel for
instance, and then no amount of tweaking inside Go is going to help you.

In short, Go (pun intended) for establishing your assumptions first, before
jumping to optimization. One AWS-wisdom is that the most expensive thing
they have is disk IO and usually you run your head against the IO being the
bottleneck. You have to establish that their own tools (for instance) is
beating you by more than a factor of 2 in the download/upload operation. If
they are, you need to start profiling in order to figure out what they do
differently than you.

Once you know the bottleneck, optimize it.

-- 
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] Unexpected Behaviour of goroutine

[Ayan George]

Srivathsan Madhavan  wrote:

> Hi all,
>
> I still consider myself a newbie to Golang hence my question here could be 
> due to my fundamental misunderstanding of this language
>
> I have the following code:
>
> func main() {
>
> for i := 0; i < 5; i++ {
>
> go func() {
>
> log.Println("i=", i)
>
> }()
>
> }
>
>
> fmt.Print("Press  to quit...")
>
> var input string
>
> fmt.Scanln()
>
> }
>
>
> The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But what I
> got was 5, 5, 5, 5 and 5!  Why is that so?
>

I'm learning golang too so please correct any errors here.

It looks like you created a closure where i is lexically scoped to
each of your gofunc() instances.  Since they're all accessing the same
i variable, you're seeing the race between incrementing i and spooling
up / starting each goroutine -- that is, the value of i reaches 5
before all of the goroutines get to print it.  You can verify this by
printing the address of i by changing your log.Println() call to
something like:

  log.Printf("i = %d,  = %p", i, )

The addresses should be the same.

If you want each goroutine to have a copy of I, you should declare and
run gofunc() like below:

gofunc(c int) {
  log.Println("c=",c)
}(i)

Which passes a copy of i to each routine.  That should give you what
you're looking for -- that is if you're not expecting i to be printed
in order. :)

-ayan

-- 
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] Unexpected Behaviour of goroutine

[Jan Mercl]

On Sun, Feb 12, 2017 at 11:51 AM Srivathsan Madhavan 
wrote:

A race detector should complain about write to i here

for i := 0; i < 5; i++ {

concurrently with reading i here

log.Println("i=", i)

Passing i to the goroutine, instead of sharing it should fix the issue

go func(i int) {
log.Println("i=", i)
}(i)


-- 

-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] Unexpected Behaviour of goroutine

[Srivathsan Madhavan]

Hi all,

I still consider myself a newbie to Golang hence my question here could be 
due to my fundamental misunderstanding of this language

I have the following code:

func main() {

for i := 0; i < 5; i++ {

go func() {

log.Println("i=", i)

}()

}


fmt.Print("Press  to quit...")

var input string

fmt.Scanln()

}


The output I expect is 0, 1, 2, 3, and 4 in any jumbled order.  But what I 
got was 5, 5, 5, 5 and 5!  Why is that so?

Thanks in advance

rgds,
Vatsan

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