Re: [go-nuts] package-level structs vs package-level vars

[Robert Engels]

I would assume so. That is the advantage of Go compared to others in that is 
has value objects. Someone else can confirm. 

> On Aug 4, 2019, at 9:52 PM, burak serdar  wrote:
> 
>> On Sun, Aug 4, 2019 at 8:14 PM B Carr  wrote:
>> 
>> 
>> Would that be where structs live as well?
> 
> Any global variable, struct or not, would be in the data section. For
> interfaces/pointers, the variable itself will be in the data section,
> but where it points may be in the heap.
> 
> Any variable you declare within a function that escapes will be in
> heap. These are things such as having a global cache, and cache
> elements allocated within a function. Something similar to this is
> what I understood when I read your description in your first post.
> 
> Any variable you declare within a function that is shared between
> goroutines escapes, and that will be in the heap. There are other ways
> a variable can escape.
> 
> If a variable is declared in a function and it doesn't escape, then it
> will be on stack.
> 
>> 
>>> On Sunday, August 4, 2019 at 6:25:55 PM UTC-6, Robert Engels wrote:
>>> 
>>> I’m pretty sure they will be in the data section, for non interface/pointer 
>>> types which is even better than the stack.
>>> 
>>> 
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/96d1c669-a65c-48ad-9ac1-17663e20c416%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoVmnY%2B-n1-jgtdbq9TizaciAm3e7Wp%3DwENr3NZbtBnmw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/448B73A6-8B7D-4440-8B83-14AFAD49A031%40ix.netcom.com.

Re: [go-nuts] package-level structs vs package-level vars

[burak serdar]

On Sun, Aug 4, 2019 at 8:14 PM B Carr  wrote:
>
>
> Would that be where structs live as well?

Any global variable, struct or not, would be in the data section. For
interfaces/pointers, the variable itself will be in the data section,
but where it points may be in the heap.

Any variable you declare within a function that escapes will be in
heap. These are things such as having a global cache, and cache
elements allocated within a function. Something similar to this is
what I understood when I read your description in your first post.

Any variable you declare within a function that is shared between
goroutines escapes, and that will be in the heap. There are other ways
a variable can escape.

If a variable is declared in a function and it doesn't escape, then it
will be on stack.

>
> On Sunday, August 4, 2019 at 6:25:55 PM UTC-6, Robert Engels wrote:
>>
>> I’m pretty sure they will be in the data section, for non interface/pointer 
>> types which is even better than the stack.
>>
>>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/96d1c669-a65c-48ad-9ac1-17663e20c416%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoVmnY%2B-n1-jgtdbq9TizaciAm3e7Wp%3DwENr3NZbtBnmw%40mail.gmail.com.

Re: [go-nuts] package-level structs vs package-level vars

[B Carr]

Would that be where structs live as well?

On Sunday, August 4, 2019 at 6:25:55 PM UTC-6, Robert Engels wrote:
>
> I’m pretty sure they will be in the data section, for non 
> interface/pointer types which is even better than the stack.


>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96d1c669-a65c-48ad-9ac1-17663e20c416%40googlegroups.com.

Re: [go-nuts] package-level structs vs package-level vars

[Robert Engels]

I’m pretty sure they will be in the data section, for non interface/pointer 
types which is even better than the stack. 

> On Aug 4, 2019, at 7:16 PM, burak serdar  wrote:
> 
>> On Sun, Aug 4, 2019 at 6:06 PM Robert Engels  wrote:
>> 
>> Just because you declare in functions and pass around does not have anything 
>> to do if it will be on the heap or the stack. It depends on if the compiler 
>> can detect if the object does not “escape”.
> 
> Right. However, if the variables are declared globally (as I
> understand it is the first case in the post), then there is no chance
> that they will be on stack.
> 
>> 
 On Aug 4, 2019, at 5:35 PM, burak serdar  wrote:
 
 On Sun, Aug 4, 2019 at 11:19 AM B Carr  wrote:
 
 Concept observation. Could use some amplification from the congregants, 
 please...
 
 I'm learning about Go.
 
 My webserver program had lots of package level vars and only two, small 
 structs. I set a dozen webpages to refresh very busy data calculations 
 every 6 seconds. Over the course of an hour, looking at the pprof output 
 for 'alloc' & 'heapAlloc' it looked like the GC was very busy and 
 collected >6 GiB of stuff. It looked like it would have continued 
 increasing into infinity. Even during that time, the GC rarely went over 
 10ms active times.
 
 I got rid of all the package level vars and put them inside of structs and 
 pass around the struct values to the functions as needed. Using the same 
 test setup above, I set a dozen webpages to refresh very busy data 
 calculations every 6 seconds. Over the course of an hour, looking at the 
 pprof output for 'alloc' & 'heapAlloc' it looked like the GC just loafed 
 along and collected <10 MiB of stuff. And that number was pretty level. 
 The GC was showing mostly zero nanosecond times.
>>> 
>>> The GC activity will depend on what goes to the heap. I can't say I
>>> understand your program structure from your description, but it sounds
>>> like in the first case you have global variables, but in the second
>>> case you started declaring variables in your functions and passed them
>>> around. If that's really the case, then GC will have less to do in the
>>> second case as most of the memory will be allocated on the stack, and
>>> GC will not be involved in cleaning them up.
>>> 
 
 I didn't do any timing testing, but the speediness of all the webpages 
 felt about the same in both test cases.
 
 I have a notion about what I'm seeing. Anyone care to increase my level of 
 understanding? Are my interpretations about what pprof is showing me 
 accurate?
 
 (ps - a big thank you to Burak Serdar who, in a previous thread, showed me 
 something I hadn't considered and put me on the path to making my 
 webserver program successfully concurrent!)
 
 TIA,
 
 Bucky
 
 --
 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/fb49d5bb-f795-4ca3-af5c-d883aabcf1af%40googlegroups.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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrEB7nOOx-CytFXYiTu7s5PosPZP%3D1ugJsE6MxK6KtwJA%40mail.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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/F94EF844-937B-47AF-BC45-DACCCB267107%40ix.netcom.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/81ADF621-1311-437B-BA01-60CB4E1856A4%40ix.netcom.com.

Re: [go-nuts] package-level structs vs package-level vars

[burak serdar]

On Sun, Aug 4, 2019 at 6:06 PM Robert Engels  wrote:
>
> Just because you declare in functions and pass around does not have anything 
> to do if it will be on the heap or the stack. It depends on if the compiler 
> can detect if the object does not “escape”.

Right. However, if the variables are declared globally (as I
understand it is the first case in the post), then there is no chance
that they will be on stack.

>
> > On Aug 4, 2019, at 5:35 PM, burak serdar  wrote:
> >
> >> On Sun, Aug 4, 2019 at 11:19 AM B Carr  wrote:
> >>
> >> Concept observation. Could use some amplification from the congregants, 
> >> please...
> >>
> >> I'm learning about Go.
> >>
> >> My webserver program had lots of package level vars and only two, small 
> >> structs. I set a dozen webpages to refresh very busy data calculations 
> >> every 6 seconds. Over the course of an hour, looking at the pprof output 
> >> for 'alloc' & 'heapAlloc' it looked like the GC was very busy and 
> >> collected >6 GiB of stuff. It looked like it would have continued 
> >> increasing into infinity. Even during that time, the GC rarely went over 
> >> 10ms active times.
> >>
> >> I got rid of all the package level vars and put them inside of structs and 
> >> pass around the struct values to the functions as needed. Using the same 
> >> test setup above, I set a dozen webpages to refresh very busy data 
> >> calculations every 6 seconds. Over the course of an hour, looking at the 
> >> pprof output for 'alloc' & 'heapAlloc' it looked like the GC just loafed 
> >> along and collected <10 MiB of stuff. And that number was pretty level. 
> >> The GC was showing mostly zero nanosecond times.
> >
> > The GC activity will depend on what goes to the heap. I can't say I
> > understand your program structure from your description, but it sounds
> > like in the first case you have global variables, but in the second
> > case you started declaring variables in your functions and passed them
> > around. If that's really the case, then GC will have less to do in the
> > second case as most of the memory will be allocated on the stack, and
> > GC will not be involved in cleaning them up.
> >
> >>
> >> I didn't do any timing testing, but the speediness of all the webpages 
> >> felt about the same in both test cases.
> >>
> >> I have a notion about what I'm seeing. Anyone care to increase my level of 
> >> understanding? Are my interpretations about what pprof is showing me 
> >> accurate?
> >>
> >> (ps - a big thank you to Burak Serdar who, in a previous thread, showed me 
> >> something I hadn't considered and put me on the path to making my 
> >> webserver program successfully concurrent!)
> >>
> >> TIA,
> >>
> >> Bucky
> >>
> >> --
> >> 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.
> >> To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/golang-nuts/fb49d5bb-f795-4ca3-af5c-d883aabcf1af%40googlegroups.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.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrEB7nOOx-CytFXYiTu7s5PosPZP%3D1ugJsE6MxK6KtwJA%40mail.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/F94EF844-937B-47AF-BC45-DACCCB267107%40ix.netcom.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqr1nU9FGSgm1h-qcHW74Pk2ms42uvgMR%3D%2Bw6HjJgRT7DA%40mail.gmail.com.

Re: [go-nuts] package-level structs vs package-level vars

[Robert Engels]

Just because you declare in functions and pass around does not have anything to 
do if it will be on the heap or the stack. It depends on if the compiler can 
detect if the object does not “escape”. 

> On Aug 4, 2019, at 5:35 PM, burak serdar  wrote:
> 
>> On Sun, Aug 4, 2019 at 11:19 AM B Carr  wrote:
>> 
>> Concept observation. Could use some amplification from the congregants, 
>> please...
>> 
>> I'm learning about Go.
>> 
>> My webserver program had lots of package level vars and only two, small 
>> structs. I set a dozen webpages to refresh very busy data calculations every 
>> 6 seconds. Over the course of an hour, looking at the pprof output for 
>> 'alloc' & 'heapAlloc' it looked like the GC was very busy and collected >6 
>> GiB of stuff. It looked like it would have continued increasing into 
>> infinity. Even during that time, the GC rarely went over 10ms active times.
>> 
>> I got rid of all the package level vars and put them inside of structs and 
>> pass around the struct values to the functions as needed. Using the same 
>> test setup above, I set a dozen webpages to refresh very busy data 
>> calculations every 6 seconds. Over the course of an hour, looking at the 
>> pprof output for 'alloc' & 'heapAlloc' it looked like the GC just loafed 
>> along and collected <10 MiB of stuff. And that number was pretty level. The 
>> GC was showing mostly zero nanosecond times.
> 
> The GC activity will depend on what goes to the heap. I can't say I
> understand your program structure from your description, but it sounds
> like in the first case you have global variables, but in the second
> case you started declaring variables in your functions and passed them
> around. If that's really the case, then GC will have less to do in the
> second case as most of the memory will be allocated on the stack, and
> GC will not be involved in cleaning them up.
> 
>> 
>> I didn't do any timing testing, but the speediness of all the webpages felt 
>> about the same in both test cases.
>> 
>> I have a notion about what I'm seeing. Anyone care to increase my level of 
>> understanding? Are my interpretations about what pprof is showing me 
>> accurate?
>> 
>> (ps - a big thank you to Burak Serdar who, in a previous thread, showed me 
>> something I hadn't considered and put me on the path to making my webserver 
>> program successfully concurrent!)
>> 
>> TIA,
>> 
>> Bucky
>> 
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/fb49d5bb-f795-4ca3-af5c-d883aabcf1af%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrEB7nOOx-CytFXYiTu7s5PosPZP%3D1ugJsE6MxK6KtwJA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F94EF844-937B-47AF-BC45-DACCCB267107%40ix.netcom.com.

Re: [go-nuts] package-level structs vs package-level vars

[burak serdar]

On Sun, Aug 4, 2019 at 11:19 AM B Carr  wrote:
>
> Concept observation. Could use some amplification from the congregants, 
> please...
>
> I'm learning about Go.
>
> My webserver program had lots of package level vars and only two, small 
> structs. I set a dozen webpages to refresh very busy data calculations every 
> 6 seconds. Over the course of an hour, looking at the pprof output for 
> 'alloc' & 'heapAlloc' it looked like the GC was very busy and collected >6 
> GiB of stuff. It looked like it would have continued increasing into 
> infinity. Even during that time, the GC rarely went over 10ms active times.
>
> I got rid of all the package level vars and put them inside of structs and 
> pass around the struct values to the functions as needed. Using the same test 
> setup above, I set a dozen webpages to refresh very busy data calculations 
> every 6 seconds. Over the course of an hour, looking at the pprof output for 
> 'alloc' & 'heapAlloc' it looked like the GC just loafed along and collected 
> <10 MiB of stuff. And that number was pretty level. The GC was showing mostly 
> zero nanosecond times.

The GC activity will depend on what goes to the heap. I can't say I
understand your program structure from your description, but it sounds
like in the first case you have global variables, but in the second
case you started declaring variables in your functions and passed them
around. If that's really the case, then GC will have less to do in the
second case as most of the memory will be allocated on the stack, and
GC will not be involved in cleaning them up.

>
> I didn't do any timing testing, but the speediness of all the webpages felt 
> about the same in both test cases.
>
> I have a notion about what I'm seeing. Anyone care to increase my level of 
> understanding? Are my interpretations about what pprof is showing me accurate?
>
> (ps - a big thank you to Burak Serdar who, in a previous thread, showed me 
> something I hadn't considered and put me on the path to making my webserver 
> program successfully concurrent!)
>
> TIA,
>
> Bucky
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/fb49d5bb-f795-4ca3-af5c-d883aabcf1af%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrEB7nOOx-CytFXYiTu7s5PosPZP%3D1ugJsE6MxK6KtwJA%40mail.gmail.com.

Re: [go-nuts] is not executable

[Allan Edwards]

Alright, so in goland, of which I love the ide and tooling, you have to 
setup a configuration to point to a go file that has package main in it.  
When you point he goland configuration to a library (module/package) that 
is not executable, the tool will complain that your exe is in in the wrong 
format.  So I am being a newb on this issue but you live and learn.

Now, what would be more ideal is if the goland ide (which jetbrains needs 
to change) told you that your config was not pointed to an exe.

On Sunday, August 4, 2019 at 1:54:20 PM UTC-5, Qais Patankar wrote:
>
> Please share the solution.
>
> On Sunday, 4 August 2019 16:50:45 UTC+1, Allan Edwards wrote:
>>
>> I am sorry, ignore me, I figured it out.  Problem in goland 
>> configuration.   Thanks for the response.
>>
>> On Sunday, August 4, 2019 at 10:44:12 AM UTC-5, Alexander Kapshuk wrote:
>>>
>>> On Sun, Aug 4, 2019 at 6:37 PM Allan Edwards  
>>> wrote: 
>>> > 
>>> > I have written a small console application that has package main at 
>>> the top and the program looks just like another console that runs 
>>> successfully.  On both mac and windows I am getting a message stating the 
>>> executable created is not executable.  Has anyone else seen this error?  I 
>>> am on go 1.12.7. 
>>> > 
>>> > Thanks!!! 
>>> > Allan 
>>> > 
>>> > -- 
>>> > 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 golan...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.
>>>  
>>>
>>>
>>> Can you please run the command line below on your Mac and post the 
>>> output: 
>>> file your_executable 
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21221161-7fe7-449f-95ac-e8c1d5ebe6f3%40googlegroups.com.

Re: [go-nuts] is not executable

[Qais Patankar]

Please share the solution.

On Sunday, 4 August 2019 16:50:45 UTC+1, Allan Edwards wrote:
>
> I am sorry, ignore me, I figured it out.  Problem in goland 
> configuration.   Thanks for the response.
>
> On Sunday, August 4, 2019 at 10:44:12 AM UTC-5, Alexander Kapshuk wrote:
>>
>> On Sun, Aug 4, 2019 at 6:37 PM Allan Edwards  
>> wrote: 
>> > 
>> > I have written a small console application that has package main at the 
>> top and the program looks just like another console that runs successfully. 
>>  On both mac and windows I am getting a message stating the executable 
>> created is not executable.  Has anyone else seen this error?  I am on go 
>> 1.12.7. 
>> > 
>> > Thanks!!! 
>> > Allan 
>> > 
>> > -- 
>> > 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 golan...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.
>>  
>>
>>
>> Can you please run the command line below on your Mac and post the 
>> output: 
>> file your_executable 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5dfbaf7a-00a1-4c88-8660-f687314b5094%40googlegroups.com.

Re: [go-nuts] is not executable

[Qais Patankar]

Please share the solution.

-- Qais

On Sun, 4 Aug 2019 at 16:50, Allan Edwards  wrote:

> I am sorry, ignore me, I figured it out.  Problem in goland
> configuration.   Thanks for the response.
>
> On Sunday, August 4, 2019 at 10:44:12 AM UTC-5, Alexander Kapshuk wrote:
>>
>> On Sun, Aug 4, 2019 at 6:37 PM Allan Edwards 
>> wrote:
>> >
>> > I have written a small console application that has package main at the
>> top and the program looks just like another console that runs
>> successfully.  On both mac and windows I am getting a message stating the
>> executable created is not executable.  Has anyone else seen this error?  I
>> am on go 1.12.7.
>> >
>> > Thanks!!!
>> > Allan
>> >
>> > --
>> > 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 golan...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.
>>
>>
>> Can you please run the command line below on your Mac and post the
>> output:
>> file your_executable
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ae81d542-1c3a-4322-b9b0-e07918b0a68b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALe3CMk8qZpkqpea4S2vNywPJaj8ZAD7YMzaWF34RzTz4theHQ%40mail.gmail.com.

[go-nuts] package-level structs vs package-level vars

[B Carr]

Concept observation. Could use some amplification from the congregants, 
please...

I'm learning about Go.

My webserver program had lots of package level vars and only two, small 
structs. I set a dozen webpages to refresh very busy data calculations 
every 6 seconds. Over the course of an hour, looking at the pprof output 
for 'alloc' & 'heapAlloc' it looked like the GC was very busy and collected 
>6 GiB of stuff. It looked like it would have continued increasing into 
infinity. Even during that time, the GC rarely went over 10ms active times.

I got rid of all the package level vars and put them inside of structs and 
pass around the struct values to the functions as needed. Using the same 
test setup above, I set a dozen webpages to refresh very busy data 
calculations every 6 seconds. Over the course of an hour, looking at the 
pprof output for 'alloc' & 'heapAlloc' it looked like the GC just loafed 
along and collected <10 MiB of stuff. And that number was pretty level. The 
GC was showing mostly zero nanosecond times.

I didn't do any timing testing, but the speediness of all the webpages felt 
about the same in both test cases.

I have a notion about what I'm seeing. Anyone care to increase my level of 
understanding? Are my interpretations about what pprof is showing me 
accurate?

(ps - a big thank you to Burak Serdar who, in a previous thread, showed me 
something I hadn't considered and put me on the path to making my webserver 
program successfully concurrent!)

TIA,

Bucky

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fb49d5bb-f795-4ca3-af5c-d883aabcf1af%40googlegroups.com.

Re: [go-nuts] Re: Windows syscall.Open() change to fix os.Rename() & .Remove()

[Liam Breck]

If you can point to an example that depends on the windows-specific error,
could you post it in the issue?


On Sun, Aug 4, 2019, 2:16 AM Reto  wrote:

> On Wed, Jul 31, 2019 at 07:00:46PM -0700, Liam wrote:
> > In this issue, Microsoft suggested that Go on Windows switch to
> Unix-like
> > behavior in Go 1.14:
> > https://github.com/golang/go/issues/32088
> >
> > I believe this will change early in pre-release 1.14.
>
> May I inquire as to why you believe that?
> Reading the issue itself, nothing points to a favorable opinion to your
> change request.
> At least not from the comments there.
>
> Most of the members / contributors either speak clearly against it, or are
> very
> cautious.
>
> The only thing is the go1.4 milestone, but milestones tend to be shifted
> around quite often.
>
> Can you please point to the discussion where this was decided?
>
> --
> 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/aRvSo3iKvJY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20190804091533.o2lz7s7gpyqotaz2%40feather.localdomain
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgTu2EO4OFrvPo%3DVoxeFLaVxM2nWScuoxbfrzNXcrJRd0g%40mail.gmail.com.

Re: [go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[Andrey Tcherepanov]

It is actually not that bad. Quite a lot of C# (especially LINQ) code is 
written that way


On Sunday, August 4, 2019 at 5:56:20 PM UTC+3, Robert Engels wrote:
>
> Would honestly want to maintain somebody else’s code that was written in 
> this style?  I wouldn’t. 
>
> On Aug 4, 2019, at 9:13 AM, clement auger  > wrote:
>
> You tell me.
>
>
> https://github.com/clementauger/sta
>
>
> sta - stream async 
>
> Implements responsive data stream pipeline.
>
> It is a reasearch and concept project not to be used in production.
> Install go get -u 
> github.com/clementauger/sta Doc 
> godoc.org/github.com/clementauger/sta 
> Example 
>
> most simple.
>
> sta.Map([]string{"a", "b", "c"}).
>   Map(strings.ToUpper).
>   Sink(fmt.Println)
>
> This example demonstrate the implementation of a pipeline that bulks by 
> slices of strings of length 4. It declares two parallel workers to change 
> the strings cases. It outputs resulting values to stdout.
>
> sta.Map([]string{"a","b"}).
>   Map(sta.Accumulate(make([]string, 4), time.Second)).
>   Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
>   Sink(fmt.Println)
>
> Rationale 
> Introduction 
>
> sta takes full advantage of the CSP channel based go capabilities to 
> provide a simple implementation to compose, implement and refactor 
> responsive data stream pipeline.
>
> A data stream pipeline is said to be responsive when it is able to react 
> with its downstream at any point in time in response to a variation of its 
> input.
>
> An implementation is said to be simple to compose, implement and refactor 
> a data stream pipeline if its overall result expresses the solution with 
> less lines of code, easier understanding, improved rewriting capabilities 
> and testing experience.
>
> Does this attempt reaches its goal ? yes and no...
> Concepts 
>
> https://blog.golang.org/pipelines
> Usage 
>
> sta exposes a Map function, to create stream instances.
>
>   s := sta.Map(src)
>
> src is a value that can take a plurality of data kind.
>
>   s := sta.Map([]string{"a","b"})
>   s = sta.Map([]int{1,2})
>   s = sta.Map(make(chan string))
>   s = sta.Map(func(output chan string){ output<-"hello world!" })
>
> sta.Map reads the given input in a separate routine and manages for it 
> the required output communication channels.
>
> The generated output channels are given to downstream transforms of the 
> stream.
>
>   s := sta.Map([]string{"a","b"}).
> Map(func(v string) int { return len(v)})
>
> stream.Map transforms a given input to an output, in a separate routine. 
> It generates the required communication channels and connects them with the 
> upstream and downstream automatically.
>
> To handle fine control of the data flow, stream.Map can handle functions 
> that receives the upstream channel. Those functions must return a processor 
> function that implements the loop over the upstream channel, and an output 
> channel they are writing. The output channel is closed after that the 
> processor function has terminated.
>
>   s := sta.Map([]string{"a","b"}).
> Map(func(input chan string) (func()error, chan int) {
>   output := make(chan int)
>   processor := func()error {
> for v := range input {
>   output<-len(v)
> }
>   }
>   return processor, output
> })
>
> To execute the pipeline, the developer must call for the stream.Sink 
> function. stream.Sink is realy just like stream.Map except that it closes 
> the stream by executing it.
>
>   err := sta.Map([]string{"a","b"}).
> Map(strings.ToUpper).
> Sink(sta.DevNull)
>
> stream.Sink writes the destination in a separate routine.
>
> The given destination value can be of kinds such as slice pointers, 
> channels or functions.
>
>   outSlice := []string{}
>   sta.Map([]string{"a","b"}).Sink()
>
>   outChan := make(chan string)
>   sta.Map([]string{"a","b"}).Sink(outChan)
>
>   outFn := func(v string){}
>   sta.Map([]string{"a","b"}).Sink(outFn)
>
>   outChanFn := func(v chan string) (func() error) { return func()error{return 
> nil}}
>   sta.Map([]string{"a","b"}).Sink(outChanFn)
>
> Merge 
>
> To merge a source, simply add more sources to the stream. Each source runs 
> into their own routine.
>
> It results in a simple merge operation of the output values.
>
> Sources can have different kind, but they should converge to a compatible 
> output type.
>
>   sta.Map(
> []string{"a","b"},
> []string{"c","d"},
> func(output chan string) {
>   output<-"e"
>   output<-"f"
> },
> func(output chan string) {
>   

Re: [go-nuts] is not executable

[Allan Edwards]

I am sorry, ignore me, I figured it out.  Problem in goland configuration.  
 Thanks for the response.

On Sunday, August 4, 2019 at 10:44:12 AM UTC-5, Alexander Kapshuk wrote:
>
> On Sun, Aug 4, 2019 at 6:37 PM Allan Edwards  > wrote: 
> > 
> > I have written a small console application that has package main at the 
> top and the program looks just like another console that runs successfully. 
>  On both mac and windows I am getting a message stating the executable 
> created is not executable.  Has anyone else seen this error?  I am on go 
> 1.12.7. 
> > 
> > Thanks!!! 
> > Allan 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.
>  
>
>
> Can you please run the command line below on your Mac and post the output: 
> file your_executable 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ae81d542-1c3a-4322-b9b0-e07918b0a68b%40googlegroups.com.

Re: [go-nuts] is not executable

[Allan Edwards]

On windows it says that my executable is not compatible with windows 
64-bit.  On mac, when I build the console from go tooling (outside of 
goland) the console will execute but crash.  So some progress.  This is my 
second issue with goland so far.  The go tooling seems solid but the goland 
might be doing something weird on the build.  

On Sunday, August 4, 2019 at 10:44:12 AM UTC-5, Alexander Kapshuk wrote:
>
> On Sun, Aug 4, 2019 at 6:37 PM Allan Edwards  > wrote: 
> > 
> > I have written a small console application that has package main at the 
> top and the program looks just like another console that runs successfully. 
>  On both mac and windows I am getting a message stating the executable 
> created is not executable.  Has anyone else seen this error?  I am on go 
> 1.12.7. 
> > 
> > Thanks!!! 
> > Allan 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.
>  
>
>
> Can you please run the command line below on your Mac and post the output: 
> file your_executable 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2d357ef4-1bc5-4e5d-9426-0194bd7ac89e%40googlegroups.com.

Re: [go-nuts] is not executable

[Alexander Kapshuk]

On Sun, Aug 4, 2019 at 6:37 PM Allan Edwards  wrote:
>
> I have written a small console application that has package main at the top 
> and the program looks just like another console that runs successfully.  On 
> both mac and windows I am getting a message stating the executable created is 
> not executable.  Has anyone else seen this error?  I am on go 1.12.7.
>
> Thanks!!!
> Allan
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.

Can you please run the command line below on your Mac and post the output:
file your_executable

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJ1xhMWzrjPbAgvHvk7y%3D_HiQkXPsbu4Ma%2BN3eEJAXkVwrLQpg%40mail.gmail.com.

[go-nuts] is not executable

[Allan Edwards]

I have written a small console application that has package main at the top 
and the program looks just like another console that runs successfully.  On 
both mac and windows I am getting a message stating the executable created 
is not executable.  Has anyone else seen this error?  I am on go 1.12.7.

Thanks!!!
Allan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e1073a26-1288-40e2-b14e-bca0b926760d%40googlegroups.com.

Re: [go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[Robert Engels]

Would honestly want to maintain somebody else’s code that was written in this 
style?  I wouldn’t. 

> On Aug 4, 2019, at 9:13 AM, clement auger  wrote:
> 
> You tell me.
> 
> 
> https://github.com/clementauger/sta
> 
> 
> sta - stream async
> 
> Implements responsive data stream pipeline.
> 
> It is a reasearch and concept project not to be used in production.
> 
> 
> Install
> 
> go get -u github.com/clementauger/sta
> 
> Doc
> 
> godoc.org/github.com/clementauger/sta
> 
> Example
> 
> most simple.
> 
> sta.Map([]string{"a", "b", "c"}).
>   Map(strings.ToUpper).
>   Sink(fmt.Println)
> This example demonstrate the implementation of a pipeline that bulks by 
> slices of strings of length 4. It declares two parallel workers to change the 
> strings cases. It outputs resulting values to stdout.
> 
> sta.Map([]string{"a","b"}).
>   Map(sta.Accumulate(make([]string, 4), time.Second)).
>   Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
>   Sink(fmt.Println)
> 
> Rationale
> 
> 
> Introduction
> 
> sta takes full advantage of the CSP channel based go capabilities to provide 
> a simple implementation to compose, implement and refactor responsive data 
> stream pipeline.
> 
> A data stream pipeline is said to be responsive when it is able to react with 
> its downstream at any point in time in response to a variation of its input.
> 
> An implementation is said to be simple to compose, implement and refactor a 
> data stream pipeline if its overall result expresses the solution with less 
> lines of code, easier understanding, improved rewriting capabilities and 
> testing experience.
> 
> Does this attempt reaches its goal ? yes and no...
> 
> 
> Concepts
> 
> https://blog.golang.org/pipelines
> 
> 
> Usage
> 
> sta exposes a Map function, to create stream instances.
> 
>   s := sta.Map(src)
> src is a value that can take a plurality of data kind.
> 
>   s := sta.Map([]string{"a","b"})
>   s = sta.Map([]int{1,2})
>   s = sta.Map(make(chan string))
>   s = sta.Map(func(output chan string){ output<-"hello world!" })
> sta.Map reads the given input in a separate routine and manages for it the 
> required output communication channels.
> 
> The generated output channels are given to downstream transforms of the 
> stream.
> 
>   s := sta.Map([]string{"a","b"}).
> Map(func(v string) int { return len(v)})
> stream.Map transforms a given input to an output, in a separate routine. It 
> generates the required communication channels and connects them with the 
> upstream and downstream automatically.
> 
> To handle fine control of the data flow, stream.Map can handle functions that 
> receives the upstream channel. Those functions must return a processor 
> function that implements the loop over the upstream channel, and an output 
> channel they are writing. The output channel is closed after that the 
> processor function has terminated.
> 
>   s := sta.Map([]string{"a","b"}).
> Map(func(input chan string) (func()error, chan int) {
>   output := make(chan int)
>   processor := func()error {
> for v := range input {
>   output<-len(v)
> }
>   }
>   return processor, output
> })
> To execute the pipeline, the developer must call for the stream.Sink 
> function. stream.Sink is realy just like stream.Map except that it closes the 
> stream by executing it.
> 
>   err := sta.Map([]string{"a","b"}).
> Map(strings.ToUpper).
> Sink(sta.DevNull)
> stream.Sink writes the destination in a separate routine.
> 
> The given destination value can be of kinds such as slice pointers, channels 
> or functions.
> 
>   outSlice := []string{}
>   sta.Map([]string{"a","b"}).Sink()
> 
>   outChan := make(chan string)
>   sta.Map([]string{"a","b"}).Sink(outChan)
> 
>   outFn := func(v string){}
>   sta.Map([]string{"a","b"}).Sink(outFn)
> 
>   outChanFn := func(v chan string) (func() error) { return func()error{return 
> nil}}
>   sta.Map([]string{"a","b"}).Sink(outChanFn)
> 
> Merge
> 
> To merge a source, simply add more sources to the stream. Each source runs 
> into their own routine.
> 
> It results in a simple merge operation of the output values.
> 
> Sources can have different kind, but they should converge to a compatible 
> output type.
> 
>   sta.Map(
> []string{"a","b"},
> []string{"c","d"},
> func(output chan string) {
>   output<-"e"
>   output<-"f"
> },
> func(output chan string) {
>   output<-"e"
>   output<-"f"
> },
>   )
> 
> Parallel
> 
> To implement parallel transforms, simply add more transform to the targeted 
> step. Each added transform runs into its own routine.
> 
> The stream will implement automatic distribution of input data and inline 
> output data to downstream.
> 
> sta.Map([]string{"a","b"}).
>   Map(strings.ToUpper, strings.ToUpper, strings.ToUpper)
> 
> sta.Map([]string{"a","b"}).
>   Map(sta.Workers(3, strings.ToUpper)...)
> 
> 

[go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[clement auger]

You tell me.


https://github.com/clementauger/sta


sta - stream async 

Implements responsive data stream pipeline.

It is a reasearch and concept project not to be used in production.
Install go get -u 
github.com/clementauger/sta Doc 
godoc.org/github.com/clementauger/sta 
Example 

most simple.

sta.Map([]string{"a", "b", "c"}).
Map(strings.ToUpper).
Sink(fmt.Println)

This example demonstrate the implementation of a pipeline that bulks by 
slices of strings of length 4. It declares two parallel workers to change 
the strings cases. It outputs resulting values to stdout.

sta.Map([]string{"a","b"}).
  Map(sta.Accumulate(make([]string, 4), time.Second)).
  Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
  Sink(fmt.Println)

Rationale 
Introduction 

sta takes full advantage of the CSP channel based go capabilities to 
provide a simple implementation to compose, implement and refactor 
responsive data stream pipeline.

A data stream pipeline is said to be responsive when it is able to react 
with its downstream at any point in time in response to a variation of its 
input.

An implementation is said to be simple to compose, implement and refactor a 
data stream pipeline if its overall result expresses the solution with less 
lines of code, easier understanding, improved rewriting capabilities and 
testing experience.

Does this attempt reaches its goal ? yes and no...
Concepts 

https://blog.golang.org/pipelines
Usage 

sta exposes a Map function, to create stream instances.

  s := sta.Map(src)

src is a value that can take a plurality of data kind.

  s := sta.Map([]string{"a","b"})
  s = sta.Map([]int{1,2})
  s = sta.Map(make(chan string))
  s = sta.Map(func(output chan string){ output<-"hello world!" })

sta.Map reads the given input in a separate routine and manages for it the 
required output communication channels.

The generated output channels are given to downstream transforms of the 
stream.

  s := sta.Map([]string{"a","b"}).
Map(func(v string) int { return len(v)})

stream.Map transforms a given input to an output, in a separate routine. It 
generates the required communication channels and connects them with the 
upstream and downstream automatically.

To handle fine control of the data flow, stream.Map can handle functions 
that receives the upstream channel. Those functions must return a processor 
function that implements the loop over the upstream channel, and an output 
channel they are writing. The output channel is closed after that the 
processor function has terminated.

  s := sta.Map([]string{"a","b"}).
Map(func(input chan string) (func()error, chan int) {
  output := make(chan int)
  processor := func()error {
for v := range input {
  output<-len(v)
}
  }
  return processor, output
})

To execute the pipeline, the developer must call for the stream.Sink 
function. stream.Sink is realy just like stream.Map except that it closes 
the stream by executing it.

  err := sta.Map([]string{"a","b"}).
Map(strings.ToUpper).
Sink(sta.DevNull)

stream.Sink writes the destination in a separate routine.

The given destination value can be of kinds such as slice pointers, 
channels or functions.

  outSlice := []string{}
  sta.Map([]string{"a","b"}).Sink()

  outChan := make(chan string)
  sta.Map([]string{"a","b"}).Sink(outChan)

  outFn := func(v string){}
  sta.Map([]string{"a","b"}).Sink(outFn)

  outChanFn := func(v chan string) (func() error) { return func()error{return 
nil}}
  sta.Map([]string{"a","b"}).Sink(outChanFn)

Merge 

To merge a source, simply add more sources to the stream. Each source runs 
into their own routine.

It results in a simple merge operation of the output values.

Sources can have different kind, but they should converge to a compatible 
output type.

  sta.Map(
[]string{"a","b"},
[]string{"c","d"},
func(output chan string) {
  output<-"e"
  output<-"f"
},
func(output chan string) {
  output<-"e"
  output<-"f"
},
  )

Parallel 

To implement parallel transforms, simply add more transform to the targeted 
step. Each added transform runs into its own routine.

The stream will implement automatic distribution of input data and inline 
output data to downstream.

sta.Map([]string{"a","b"}).
  Map(strings.ToUpper, strings.ToUpper, strings.ToUpper)

sta.Map([]string{"a","b"}).
  Map(sta.Workers(3, strings.ToUpper)...)

sta.Map([]string{"a","b"}).
  Map(sta.Workers(3, func() interface{} {
// 

[go-nuts] Re: [Go tool capable of hiding any file within an image.

[Michael Jones]

Thank you for sharing this.

On Fri, Aug 2, 2019 at 11:45 AM Dimitar Petrov 
wrote:

> Okay, thanks for clarification!
>
> петък, 2 август 2019 г., 21:42:23 UTC+3, Bryan C. Mills написа:
>>
>> This list is for discussion of the development of the Go project.
>>
>> For announcements of third-party tools and libraries written in Go,
>> please use the golang-nuts list instead.
>>
>>
>> On Friday, August 2, 2019 at 12:51:35 PM UTC-4, buldoz...@gmail.com
>> wrote:
>>>
>>> stegify  is a simple command
>>> line tool capable of fully transparent hiding any file within an image. It
>>> works pretty good and it is very useful for hiding any secrets in slightly
>>> extraordinary way. :) (https://github.com/DimitarPetrov/stegify)
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/bcd07698-3737-42d8-af74-65a8a6bb2e24%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQwbqW7diNOX%2Bd1cJCFKZTs1NKuwtcNfk5%3Da1yOnW14XPA%40mail.gmail.com.

Re: [go-nuts] Re: How to mock functions in Go ?

[Wojciech S. Czarnecki]

On Sat, 3 Aug 2019 22:35:44 -0700 (PDT)
Andrey Tcherepanov  wrote:

> what if you need only a subpart of the package to be mocked ?

import smthorig "smth"

type smthT struct{
//functions 
f1 func signature
f2 func signature
}

// functions
func mof1 (in...) (out...) { /* here your mock goes */ }
func mof2 (in...) (out...) { return smthorig(in...) }

var smth = smthT{ f1: mof1, f2: mof2 }

// methods
func (o smth) m1 (in...) (out...) { /* here your mock goes */ }
func (o smth) m2 (in...) (out...) { return smthorig(in...) }

Types are aliased
interfaces should be used from smthorig intact

Beware of packages that have init and keep state.

Hope this helps.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190804140657.4af7792a%40zuzia.

Re: [go-nuts] Re: How to mock functions in Go ?

[Robert Engels]

Similarly the fact that you need to mock just os.Hostname and you know that 
means you are probably testing implementation details which I wouldn’t do. As 
I’ve pointed out before most of the Go stdlib tests are black box in a 
different test package. I think you’ll create better more resilient tests that 
way. 

> On Aug 4, 2019, at 6:23 AM, Robert Engels  wrote:
> 
> In an ideal case got exported functions it would defer to the original. 
> 
> Still I think the package might have too many responsibilities if that’s the 
> case. 
> 
>> On Aug 4, 2019, at 12:35 AM, Andrey Tcherepanov 
>>  wrote:
>> 
>> what if you need only a subpart of the package to be mocked ?
>> 
>>> On Thursday, August 1, 2019 at 5:29:30 PM UTC+3, Robert Engels wrote:
>>> That brings up an interesting idea. A ‘package replace’ during compile. So 
>>> you request that the os package is replaced by osmock etc. 
>>> 
>>> This would allow easy general reuse mocking frameworks without changing the 
>>> stdlib and all user code. 
>>> 
 On Aug 1, 2019, at 8:38 AM, kyle...@sezzle.com wrote:
 
 You'll want to check out `gomock` and `mockgen`. You'll need to write an 
 interface to be able to mock, so you may need to write a receiver struct 
 to encapsulate os.Hostname() or whatever you need to mock, then mock your 
 HostnameGetter (surely a better name than that), maybe?
 
 type OsClient struct {}
 
 (o *OsClient) GetHostname() (string, error) { return os.Hostname() }
 
 type HostnameGetter interface { GetHostname() (string, error)}
 
 
 
 Here is repo w/ documentation: https://github.com/golang/mock
 
 And here are a couple other nice introductions: 
 - https://blog.codecentric.de/en/2017/08/gomock-tutorial/
 - https://www.philosophicalhacker.com/post/getting-started-with-gomock/
 
> On Thursday, August 1, 2019 at 7:09:54 AM UTC-5, Nitish Saboo wrote:
> Hi,
> 
> How can we mock a function in Go like os.Hostname() or os.Getwd() ?
> Any framework or Library that we can use for mocking the function calls ?
> 
> Thanks,
> Nitish
 
 -- 
 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 golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/bceaef08-4ee2-4f57-8c0d-5fee59e8cfd7%40googlegroups.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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/1e62434b-d7b6-403e-87a8-d0edf42d3dc0%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/29CF1F67-E62C-410D-8DCF-9DFD75A10B62%40ix.netcom.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/50AE5174-CC06-472B-8AE9-C3E7420DB6BB%40ix.netcom.com.

Re: [go-nuts] Re: How to mock functions in Go ?

[Robert Engels]

In an ideal case got exported functions it would defer to the original. 

Still I think the package might have too many responsibilities if that’s the 
case. 

> On Aug 4, 2019, at 12:35 AM, Andrey Tcherepanov 
>  wrote:
> 
> what if you need only a subpart of the package to be mocked ?
> 
>> On Thursday, August 1, 2019 at 5:29:30 PM UTC+3, Robert Engels wrote:
>> That brings up an interesting idea. A ‘package replace’ during compile. So 
>> you request that the os package is replaced by osmock etc. 
>> 
>> This would allow easy general reuse mocking frameworks without changing the 
>> stdlib and all user code. 
>> 
>>> On Aug 1, 2019, at 8:38 AM, kyle...@sezzle.com wrote:
>>> 
>>> You'll want to check out `gomock` and `mockgen`. You'll need to write an 
>>> interface to be able to mock, so you may need to write a receiver struct to 
>>> encapsulate os.Hostname() or whatever you need to mock, then mock your 
>>> HostnameGetter (surely a better name than that), maybe?
>>> 
>>> type OsClient struct {}
>>> 
>>> (o *OsClient) GetHostname() (string, error) { return os.Hostname() }
>>> 
>>> type HostnameGetter interface { GetHostname() (string, error)}
>>> 
>>> 
>>> 
>>> Here is repo w/ documentation: https://github.com/golang/mock
>>> 
>>> And here are a couple other nice introductions: 
>>> - https://blog.codecentric.de/en/2017/08/gomock-tutorial/
>>> - https://www.philosophicalhacker.com/post/getting-started-with-gomock/
>>> 
 On Thursday, August 1, 2019 at 7:09:54 AM UTC-5, Nitish Saboo wrote:
 Hi,
 
 How can we mock a function in Go like os.Hostname() or os.Getwd() ?
 Any framework or Library that we can use for mocking the function calls ?
 
 Thanks,
 Nitish
>>> 
>>> -- 
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/bceaef08-4ee2-4f57-8c0d-5fee59e8cfd7%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/1e62434b-d7b6-403e-87a8-d0edf42d3dc0%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/29CF1F67-E62C-410D-8DCF-9DFD75A10B62%40ix.netcom.com.

Re: [go-nuts] Re: Windows syscall.Open() change to fix os.Rename() & .Remove()

[Reto]

>They did:
>https://github.com/golang/go/issues/32088#issuecomment-502850674

No, that's not a member of the go team.

>TL;DR; setting it by default would move the things to a little bit more
>
>POSIXy, but
>possibly creating more hiddent deviations.

yeah but that wasn't my question was 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B735D528-DD9B-4CF7-8C63-3593E81A88F0%40labrat.space.

Re: [go-nuts] Re: Windows syscall.Open() change to fix os.Rename() & .Remove()

[Reto]

On Wed, Jul 31, 2019 at 07:00:46PM -0700, Liam wrote:
> In this issue, Microsoft suggested that Go on Windows switch to Unix-like 
> behavior in Go 1.14:
> https://github.com/golang/go/issues/32088
> 
> I believe this will change early in pre-release 1.14.

May I inquire as to why you believe that?
Reading the issue itself, nothing points to a favorable opinion to your change 
request.
At least not from the comments there.

Most of the members / contributors either speak clearly against it, or are very
cautious.

The only thing is the go1.4 milestone, but milestones tend to be shifted
around quite often.

Can you please point to the discussion where this was decided?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190804091533.o2lz7s7gpyqotaz2%40feather.localdomain.