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

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 va

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

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 declar

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

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

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

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 n

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

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 d

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

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 w

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

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

Re: [go-nuts] is not executable

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

Re: [go-nuts] is not executable

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, 20

Re: [go-nuts] is not executable

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 a

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

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, l

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

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

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

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,

Re: [go-nuts] is not executable

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 p

Re: [go-nuts] is not executable

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

Re: [go-nuts] is not executable

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

[go-nuts] is not executable

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

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

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

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

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

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

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 t

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

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 */ } f

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

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 tes

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

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 Th

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

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

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

2019. augusztus 4., vasárnap 11:15:58 UTC+2 időpontban Reto a következőt írta: > > 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 > >

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

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?