[go-nuts] How to define struct with defined properties that is also a map
This is probably basic, but I'm working on some code that unmarshals JIRA
tickets (just for some context). Examining the Json output, there is a big
"fields" object that mostly contains custom fields, but also some defined
fields. Right now, I defined "Fields" as a "map[string]any", which is
appropriate for the custom fields. However, I would really like to define
something like this:
type JIRAFields struct {
map[string]any
Parent JIRAParent
}
type JIRAParent struct {
...
}
So I could reference a custom field like "Fields[key]", but the parent
field with "Fields.Parent".
I'm certain the syntax I have so far isn't correct, as it flags the "map"
saying "}" was expected.
--
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/CAA5t8VqfpZ7og6Zxobcy388Zbyj%2BnTGc-J0gW_LBj9ngrErg4w%40mail.gmail.com.
[go-nuts] Using client-go to access a specific context, not current context
I'm relatively new to golang, although I'm pretty familiar with Kubernetes. I want to see if I can use client-go as a framework for a set of scripts that get (or set) information on a specific cluster. I don't want to use the current context, I want to set the context name on the command line and "use" that context, but I want to avoid setting that as the current context. I could hack this together by manually navigating through ~/.kube/config and extracting the server and token, but I'm still not familiar enough with the client-go api to know whether that will even help. In any case, I would hope that client-go would provide an easier way to do this. I wish I could find more examples of "out-of-cluster" client applications using this api. -- 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/4377e4fd-1d16-431c-8cf2-406d7d2304f3n%40googlegroups.com.
Re: [go-nuts] How to have a raw parameter value in cobra?
Ok, that worked. I had tried that before, but I had done it wrong.
On Sunday, February 25, 2024 at 1:04:10 PM UTC-8 burak serdar wrote:
> Somewhere in your main, you should be calling rootCmd.Execute(). Instead:
>
> func main() {
> // first, make sure there are at least 2 args. Then, process the
> 1st parameter
> // Then
> rootCmd.SetArgs(os.Args[2:])
> rootCmd.Execute()
> }
>
> On Sun, Feb 25, 2024 at 1:50 PM David Karr wrote:
> >
> > But where would that be done? I'm not certain of the exact role of the
> "rootCmd.Execute()" function, or the optional "Run" function in the Command
> object. Neither of those appear to be executed, when I just run "
> subcommand, and that gets printed, but nothing else.
> >
> > On Sunday, February 25, 2024 at 10:52:10 AM UTC-8 burak serdar wrote:
> >>
> >> You can do rootCmd.SetArgs(os.Args[2:]), and process the first
> >> parameter yourself.
> >>
> >> On Sun, Feb 25, 2024 at 11:43 AM David Karr
> wrote:
> >> >
> >> > I am not a new programmer, but I am pretty new to golang, having only
> written a couple of small applications, and that was several months ago.
> I'm trying to construct an application using Cobra, using some nonstandard
> conventions. Is it better to ask a question like this in an issue in the
> Cobra github site?
> >> >
> >> > The application I am trying to write will be used extremely often,
> and I want to minimize the required syntax.
> >> >
> >> > I want to set up a command line like the following:
> >> >
> >> >
> >> >
> >> > The parameter right after the application name will always be
> present. I don't want it to be a flag. After that parameter value will be a
> subcommand, followed by additional parameters, also not flags. There are
> some situations where I want to allow for flags, but that will be uncommon.
> >> >
> >> > It's not clear to me how to cleanly set up this organization. Is it
> simply not practical to do with Cobra? Should I just do ad hoc parameter
> processing?
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to golang-nuts...@googlegroups.com.
> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/14b9efb1-7fbb-45a6-8e0e-56f25be310a3n%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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9d8fac62-f70a-488d-8bf9-7800b5d44d34n%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/c18c9fe2-c85e-49b9-a3f9-167a8c2236f5n%40googlegroups.com.
Re: [go-nuts] How to have a raw parameter value in cobra?
But where would that be done? I'm not certain of the exact role of the "rootCmd.Execute()" function, or the optional "Run" function in the Command object. Neither of those appear to be executed, when I just run " You can do rootCmd.SetArgs(os.Args[2:]), and process the first > parameter yourself. > > On Sun, Feb 25, 2024 at 11:43 AM David Karr wrote: > > > > I am not a new programmer, but I am pretty new to golang, having only > written a couple of small applications, and that was several months ago. > I'm trying to construct an application using Cobra, using some nonstandard > conventions. Is it better to ask a question like this in an issue in the > Cobra github site? > > > > The application I am trying to write will be used extremely often, and I > want to minimize the required syntax. > > > > I want to set up a command line like the following: > > > > > > > > The parameter right after the application name will always be present. I > don't want it to be a flag. After that parameter value will be a > subcommand, followed by additional parameters, also not flags. There are > some situations where I want to allow for flags, but that will be uncommon. > > > > It's not clear to me how to cleanly set up this organization. Is it > simply not practical to do with Cobra? Should I just do ad hoc parameter > processing? > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/14b9efb1-7fbb-45a6-8e0e-56f25be310a3n%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/9d8fac62-f70a-488d-8bf9-7800b5d44d34n%40googlegroups.com.
[go-nuts] How to have a raw parameter value in cobra?
I am not a new programmer, but I am pretty new to golang, having only written a couple of small applications, and that was several months ago. I'm trying to construct an application using Cobra, using some nonstandard conventions. Is it better to ask a question like this in an issue in the Cobra github site? The application I am trying to write will be used extremely often, and I want to minimize the required syntax. I want to set up a command line like the following: The parameter right after the application name will always be present. I don't want it to be a flag. After that parameter value will be a subcommand, followed by additional parameters, also not flags. There are some situations where I want to allow for flags, but that will be uncommon. It's not clear to me how to cleanly set up this organization. Is it simply not practical to do with Cobra? Should I just do ad hoc parameter processing? -- 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/14b9efb1-7fbb-45a6-8e0e-56f25be310a3n%40googlegroups.com.
Re: [go-nuts] Re: New edition of the Go Programming Language comming soon ?
There is nothing new here. Every programming language, framework, and tool has had the same problem. Quality documentation and training is often the hardest thing to produce, and is often deemphasized in budgets. It's also part of the last 10% of doing something that usually takes 90% of the time. On Mon, Mar 14, 2022 at 9:58 PM Rob Muhlestein wrote: > The essential issue is that there are a number of resources for people > "with prior programming experience" and literally none for people learning > Go as a first language. I find this to be very unfortunate because so much > of Go promotes solid programming practices that could significantly impact > beginners for the rest of their coding lives (goroutines instead of > promises, for example). Instead, the community seems content with simply > suggesting beginners "learn another language first" and I've accepted that. > I just find it a real loss of an excellent opportunity. > > The rest of this is just me blabbing on about helping beginners. 😀 > > And I'm sorry, that book is anything but clear. In my experience, the > people who say such things also say that K&R C is "clear." It's a matter of > opinion and audience, and if you are a Ph.D in computer science with C > coding under your belt, hell yeah, it's *very* clear. I just work with > beginners with no CS experience a lot and they balk at the irrelevant > examples, unnecessary bombastic voice, and excessive assumptions. I'm > sincerely glad some do find it valuable. > > By the way, why doesn't our community promote more top-of-the-line, free > resources over paid books that become immediately out of date? With all the > money being dumped into "universities" and "free training" of late from > different corporations facing the doubt of good IT talent I want to believe > a dedicated team focused specifically on helping beginners adopt Go is a > possibility --- especially given the critical dependency on Go in all of > cloud native computing. Being able to read Go source (minimally) should be > mandatory learning for any infrastructure engineer these days. I've solved > so many problems simply from reading the K8S or Helm source rather than the > docs. > > I get the impression so many are so busy doing amazing things *with* Go > that there is very little energy left to do things to help others start, > and by others I don't mean those paying for corporate training. I mean > those capable of learning but with limited means; I mean the AP CS programs > that are still mandating mastering of single OOP inheritance that > completely neglect concurrent programming practices; I mean self-taught > upskillers learning to write their own Kubernetes operators. Go could > easily displace Java as the best AP CS language if more attention were > given to these considerations. > > The Tour of Go is only about 60% finished according to the project > milestones in the source of the project. And who thought throwing bitwise > operators in the first chapter (or so) was a good idea? > > It just seems like people are content letting beginners fend for > themselves, which is fine for most, but not for the vast majority of people > for whom Go is supposedly created. This is the reason I regularly receive > feedback about Go from the many I've helped who say, "Go just isn't > beginner friendly" and I'm tired of them saying that "Rust is more > welcoming" (which is just so untrue). > > I know I'm droning on, but someone has to bring this up. Go *is* for > beginners. We just need help convince people, and frankly that starts with > being able to make a simple, solid book/resource recommendation for > beginners. There's just nothing out there. I've read 'em all. There are > literally no books that cover even 1.17 for beginners. (Modules were one of > the worst things to happen to beginners and we are finally getting on with > a simpler future.) With Go 1.18 we have a real opportunity to correct this. > > For the record, I'm slowly putting together enough material to > crowd-source a beginner Go 1.18 book and have probably a few dozen people > interested in helping, but like so many others, I have other stuff I'm > first required to focus on. Look forward to anything I can do to help. > > Thank you. > > --- > Rob Muhlestein > r...@rwx.gg > https://twitch.tv/rwxrob > > --- Original Message --- > > On Monday, March 14th, 2022 at 1:06 PM, Steve Mynott < > steve.myn...@gmail.com> wrote: > > > My experience with this book has been different. I thought it was > > > > superb -- a masterpiece of clarity. > > > > I don't think it's intended for absolute beginners to programming but > > > > it's great for people with prior programming experience. > > > > It seems to me unlikely there isn't a suitable absolute beginners book > > > > available from publishers such as Manning, O'Reilly and No Starch > > > > Press. > > > > S > > > > On Mon, 14 Mar 2022 at 16:09, Rob Muhlestein r...@rwx.gg wrote: > > > > > As an educator and mentor I'v
Re: [go-nuts] How to debug "Not a valid zip file" from zip.OpenReader
Ok. I did that. https://github.com/golang/go/issues/51337 . On Wed, Feb 23, 2022 at 4:20 PM Ian Lance Taylor wrote: > On Wed, Feb 23, 2022 at 1:46 PM David Karr > wrote: > > > > A while ago, I wrote a small Go app that reads things from zip files. I > tested it with various zip files (usually Java jar files), and it has > always worked perfectly fine. > > > > Today I'm looking at another jar file. The Java "jar" command likes it > perfectly fine. I could list the contents and extract all the files. Java > had no particular trouble running with the jar file. > > > > When I try to call "zip.OpenReader()" on this jar file, it just gives me > ""zip: not a valid zip file"". Well, great. > > > > I then ran a command to run the same command on every jar file in my > home directory tree, where there are a couple of thousand from various tool > distributions. I counted how many failed with that same error. I found > just the one I already have. > > > > This jar file is a little over 12mb. Several of the jar files that > don't fail are quite a bit larger than this. Most of the ones that don't > fail are smaller than this. The permissions on this jar are the same as the > others. > > > > I then tried passing this jar file to "unzip". It was able to unzip it, > but it did print this: > > > > warning []: 3624 extra bytes at beginning or within > zipfile > > (attempting to process anyway) > > > > I tried this on some of the working jar files, and it didn't print this > warning. > > > > So, it appears that if anything, this jar file is "nonstandard", but > both unzip and jar have no problem with it, and jar didn't even say there > was an issue with it. The zip package, however, bombs on this with no > information. > > > > I'm going to go to the people who gave me that jar file and ask them how > they produced it, but I think it's clear it's not fatally broken. > > > > I haven't submitted a bug report for this package yet, as I wanted some > feedback on this first. > > The error is zip.ErrFormat. From a quick look at the sources it can > be returned if > > - a file header does not start with the required signature (0x04034b50) > - a directory header does not start with the required signature > (0x02014b50) > - a directory entry is too short to contain the additional information > it claims to hold > - a directory entry fails to contain the additional information it > claims to hold > - the directory end signature (0x06054b50) is not found > - the offset in the directory is invalid (negative or larger than the file > size) > > There is no especially easy way to find out exactly which one is > happening. You could add some print statements to > archive/zip/reader.go to narrow it down. > > I'm not sure what to make of the "3624 extra bytes". > > Not sure how much this helps. If you can share the zip file, you > could open a bug report. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA5t8VpRkTniYnMKhQ%2BDfL8v57wM8Gj-4vHFq5i887Tw2Rwaeg%40mail.gmail.com.
[go-nuts] How to debug "Not a valid zip file" from zip.OpenReader
A while ago, I wrote a small Go app that reads things from zip files. I tested it with various zip files (usually Java jar files), and it has always worked perfectly fine. Today I'm looking at another jar file. The Java "jar" command likes it perfectly fine. I could list the contents and extract all the files. Java had no particular trouble running with the jar file. When I try to call "zip.OpenReader()" on this jar file, it just gives me ""zip: not a valid zip file"". Well, great. I then ran a command to run the same command on every jar file in my home directory tree, where there are a couple of thousand from various tool distributions. I counted how many failed with that same error. I found just the one I already have. This jar file is a little over 12mb. Several of the jar files that don't fail are quite a bit larger than this. Most of the ones that don't fail are smaller than this. The permissions on this jar are the same as the others. I then tried passing this jar file to "unzip". It was able to unzip it, but it did print this: warning []: 3624 extra bytes at beginning or within zipfile (attempting to process anyway) I tried this on some of the working jar files, and it didn't print this warning. So, it appears that if anything, this jar file is "nonstandard", but both unzip and jar have no problem with it, and jar didn't even say there was an issue with it. The zip package, however, bombs on this with no information. I'm going to go to the people who gave me that jar file and ask them how they produced it, but I think it's clear it's not fatally broken. I haven't submitted a bug report for this package yet, as I wanted some feedback on this first. -- 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/3a235738-3ce0-4357-8c78-870fc61c8829n%40googlegroups.com.
[go-nuts] Getting "$GOPATH/go.mod exists but should not" when running build in a Docker image
I had earlier written a note about troubles refactoring my project to have a "src" directory, but I've backed off on that for now. I see that the main problem I saw with that hasn't changed when backing out those changes. It appears that running this build inside a docker image seems to be somehow causing this problem. In any case, I have a relatively simple go application with main.go, go.mod, and go.sum in the root directory, with subdirectories containing other source files in packages. When I just run "go build ..." from the command line in the root directory of my project, it works fine and produces a working executable. However, I'm trying to get this build to work within a published go "builder" image, which I will use as the first stage in a multi-stage Docker build. I will first state that this has something to do with GOPATH, and I've gone through https://www.digitalocean.com/community/tutorials/understanding-the-gopath , but I'd have to say that I still don't understand its proper role here. Not sure what you would want to see first, but here's a plain "ls" of the root directory of my project: - ./ Dockerfilego.mod JenkinsfileREADME.md ../ .dockerignorego.sum lib/ target/ app/ .git/handlers/ main.gotrustStore/ config/ .gitignoreinclude/ Makefilefuncs/ --- Just running "make build" does this: - CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o ../target/dist/linux-amd64 - Which is fine. My "dockerbuild" target in the Makefile is this: dockerbuild: docker build \ --build-arg host_src_path=. \ --build-arg packages=. \ --build-arg executable_name=appgo \ --build-arg cgo_enabled_01=1 \ --build-arg goos=linux \ --build-arg goarch=amd64 \ -f Dockerfile -t appgo . --- My Dockerfile, before the start of the second build stage, is this: FROM .../golang:1.17.6-bullseye as go-builder ARG packages ARG executable_name ARG host_src_path ARG cgo_enabled_01 ARG goos ARG goarch COPY $host_src_path . RUN env RUN ls -lt RUN ls -lt $GOPATH #RUN go mod download RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build -o $executable_name $packages When I run "make dockerbuild", I see this: -- Sending build context to Docker daemon 125.8MB Step 1/19 : FROM .../golang:1.17.6-bullseye as go-builder ---> 80d9a75ccb38 Step 2/19 : ARG packages ---> Using cache ---> d98015e225b1 Step 3/19 : ARG executable_name ---> Using cache ---> 1d336ac5cf1b Step 4/19 : ARG host_src_path ---> Using cache ---> 59595b09a376 Step 5/19 : ARG cgo_enabled_01 ---> Using cache ---> 3c4c08392ede Step 6/19 : ARG goos ---> Using cache ---> 6ed0d6881fb4 Step 7/19 : ARG goarch ---> Using cache ---> 9e4b94e86b09 Step 8/19 : COPY $host_src_path . ---> 4727e2fc3e80 Step 9/19 : RUN env ---> Running in 8fcedaa86227 HOSTNAME=8fcedaa86227 HOME=/root packages=. cgo_enabled_01=1 goarch=amd64 host_src_path=. PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin goos=linux GOPATH=/go executable_name=appgo PWD=/go GOLANG_VERSION=1.17.6 Removing intermediate container 8fcedaa86227 ---> 46e44a5a3539 Step 10/19 : RUN ls -lt ---> Running in 75107286d337 total 128 -rw-rw-r-- 1 root root 635 Feb 11 18:37 Dockerfile -rw-rw-r-- 1 root root 737 Feb 11 18:29 Makefile -rw-rw-r-- 1 root root 131 Feb 10 18:59 Jenkinsfile drwxrwxrwx 2 root root 4096 Jan 27 10:09 bin drwxrwxrwx 2 root root 4096 Jan 27 10:09 src -rw-rw-r-- 1 root root 967 Jan 13 18:34 main.go drwxrwxr-x 3 root root 4096 Jan 11 23:46 target drwxrwxr-x 2 root root 4096 Jan 11 23:46 funcs drwxrwxr-x 3 root root 4096 Jan 11 21:06 trustStore -rw-rw-r-- 1 root root 1454 Jan 11 21:06 README.md drwxrwxr-x 2 root root 4096 Jan 11 21:06 app drwxrwxr-x 2 root root 4096 Jan 11 21:06 config -rw-rw-r-- 1 root root 806 Jan 11 21:06 go.mod -rw-rw-r-- 1 root root 65194 Jan 11 21:06 go.sum drwxrwxr-x 2 root root 4096 Jan 11 21:06 handlers drwxrwxr-x 3 root root 4096 Jan 11 21:06 include drwxrwxr-x 4 root root 4096 Jan 11
[go-nuts] Having trouble getting app to build with Docker after moving to a "src" directory
I had a small go application building successfully. I had the go.mod and main.go in the root directory of the project, and I was building it pretty easily with a Makefile, which just did the following: CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o target/dist/linux-amd64 I decided I wanted to move the go source files out of the root dir, so I created a "src" directory, then moved "go.*" and my package subdirs to "src". Getting this simple build to work was simple. I also am constructing a multi-stage Dockerfile, which will be used in the CI build. This is a little more complicated, and I'm getting an error on the build command that I don't understand. My Dockerfile looks something like this (... in some places): -- FROM .../golang:1.17.6-bullseye as go-builder ARG packages ARG executable_name ARG host_src_path ARG cgo_enabled_01 ARG goos ARG goarch COPY $host_src_path . RUN ls -lt #RUN go mod download RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build -o $executable_name $packages FROM .../ubuntu-base:20.04 COPY ... EXPOSE 8080 ENTRYPOINT ... -- The Docker build looks something like this (... in some places): - docker build \ --build-arg host_src_path=src \ --build-arg packages=. \ --build-arg executable_name=... \ --build-arg cgo_enabled_01=1 \ --build-arg goos=linux \ --build-arg goarch=amd64 \ -f Dockerfile -t target/dist/linux/amd64/... . - When I run this, I see the following: Step 10/17 : RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build -o $executable_name $packages ---> Running in 62ef0147061e $GOPATH/go.mod exists but should not The command '/bin/sh -c CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build -o $executable_name $packages' returned a non-zero code: 1 make: *** [Makefile:12: dockerbuild] Error 1 --- I googled that error message about go.mod, but I don't understand the results, and I don't fully understand how to use GOPATH. I don't remember doing anything with it before. I'm sure I'm operating on some misconceptions, but I'm not sure what I'm doing wrong. -- 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/484dc24a-18c6-4a7c-84ca-f8acc61c0460n%40googlegroups.com.
[go-nuts] What exactly can be supplied as "packages" on the go build command line?
When I enter "go help build", the first few lines shows this: usage: go build [-o output] [build flags] [packages] Build compiles the packages named by the import paths, The instructions say very little about what can be supplied as "packages". It says it can be a list of .go files, and apparently assumes all of the supplied files are in a single package , which seems like an odd assumption. However, I discovered one resource, and from my testing, that just supplying "." (period) there also builds the application. >From what I can see, it appears that the basic help information doesn't tell the entire story about what can be supplied there, and exactly how those values are used. What are all the legal variations of what can be supplied there, and what are the exact semantics of those values? -- 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/a6e92bac-e8d6-4cea-b451-a7a1c14af6c3n%40googlegroups.com.
Re: [go-nuts] How to vary cgo lib path by os?
On Saturday, November 27, 2021 at 1:13:12 PM UTC-8 David Karr wrote:
> On Sat, Nov 27, 2021 at 11:57 AM Ian Lance Taylor
> wrote:
>
>> On Sat, Nov 27, 2021 at 11:01 AM David Karr
>> wrote:
>> >
>> > I'm aware of the "build constraints" mechanism, which lets individual
>> files be only compiled on specific oses or architectures.
>> >
>> > I am constructing an app that has a single cgo module, which is the
>> "meat" of the application (longest module). In my poc, the cgo header
>> specifies a lib path with "linux" in the path, to point to the linux
>> libraries. I haven't constructed a Makefile for this yet, but this works
>> well with vscode and simple testing.
>> >
>> > I now have to consider how to build this on Windows, although the
>> deployment target for this will be Linux. I have to allow for testing of it
>> on Windows, if possible. I thought perhaps that I could change the lib path
>> in the cgo header to reference "${GOOS}" instead, but it doesn't seem to
>> recognize that.
>> >
>> > It's not reasonable to use build constraints for this, because it seems
>> like I would have to duplicate the entire module in order to vary the lib
>> path. That would be absurd.
>> >
>> > What are reasonable strategies for this, including facilitating testing
>> of it in vscode on both Linux and Windows?
>>
>> If I'm reading this correctly, you can address this by using
>> GOOS/GOARCH build tags in your #cgo comments. See, for example,
>> https://go.dev/src/runtime/cgo/cgo.go?#L14. This is documented at
>> https://pkg.go.dev/cmd/cgo#hdr-Using_cgo_with_the_go_command.
>>
>> Ian
>>
>
> So you're saying I could do this:
>
> // #cgo linux LDFLAGS: -L${SRCDIR}/../lib/linux -llib1 -llib2 -llib3
> -llib4
> // #cgo windows LDFLAGS: -L${SRCDIR}/../lib/windows -llib1 -llib2
> -llib3 -llib4
>
> If so, that would be much better than duplicating the entire file. It
> looks a little odd to duplicate the library list, but if that's the best we
> can do, I guess that's it.
>
> I'll test this later.
>
Hm, I'm going to guess you're going to tell me that I can't quite do that,
as I just verified that, unless I'm simply doing it wrong. I wrote almost
exactly what I showed there. I'm having some trouble figuring out how to
set up the C compiler on Windows, but I have verified with other
applications that I can cross-compile a build on Linux for Windows, so I
simply ran this:
GOOS=windows go build -o target/dist/windows-amd64
This fails with:
imports voltagems/voltagefuncs: build constraints exclude all Go files
in /home/dk068x/git/voltagego/voltagefuncs
Any way to fix 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3612945d-3a99-4bf8-9ea1-262f4f5fa244n%40googlegroups.com.
Re: [go-nuts] How to vary cgo lib path by os?
On Sat, Nov 27, 2021 at 11:57 AM Ian Lance Taylor wrote:
> On Sat, Nov 27, 2021 at 11:01 AM David Karr
> wrote:
> >
> > I'm aware of the "build constraints" mechanism, which lets individual
> files be only compiled on specific oses or architectures.
> >
> > I am constructing an app that has a single cgo module, which is the
> "meat" of the application (longest module). In my poc, the cgo header
> specifies a lib path with "linux" in the path, to point to the linux
> libraries. I haven't constructed a Makefile for this yet, but this works
> well with vscode and simple testing.
> >
> > I now have to consider how to build this on Windows, although the
> deployment target for this will be Linux. I have to allow for testing of it
> on Windows, if possible. I thought perhaps that I could change the lib path
> in the cgo header to reference "${GOOS}" instead, but it doesn't seem to
> recognize that.
> >
> > It's not reasonable to use build constraints for this, because it seems
> like I would have to duplicate the entire module in order to vary the lib
> path. That would be absurd.
> >
> > What are reasonable strategies for this, including facilitating testing
> of it in vscode on both Linux and Windows?
>
> If I'm reading this correctly, you can address this by using
> GOOS/GOARCH build tags in your #cgo comments. See, for example,
> https://go.dev/src/runtime/cgo/cgo.go?#L14. This is documented at
> https://pkg.go.dev/cmd/cgo#hdr-Using_cgo_with_the_go_command.
>
> Ian
>
So you're saying I could do this:
// #cgo linux LDFLAGS: -L${SRCDIR}/../lib/linux -llib1 -llib2 -llib3
-llib4
// #cgo windows LDFLAGS: -L${SRCDIR}/../lib/windows -llib1 -llib2
-llib3 -llib4
If so, that would be much better than duplicating the entire file. It looks
a little odd to duplicate the library list, but if that's the best we can
do, I guess that's it.
I'll test this later.
--
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/CAA5t8VpJmWicztChWPPEQSw1zH3Z68UzNYroQGEs%3DaAG%2BO2Gww%40mail.gmail.com.
[go-nuts] How to vary cgo lib path by os?
I'm aware of the "build constraints" mechanism, which lets individual files
be only compiled on specific oses or architectures.
I am constructing an app that has a single cgo module, which is the "meat"
of the application (longest module). In my poc, the cgo header specifies a
lib path with "linux" in the path, to point to the linux libraries. I
haven't constructed a Makefile for this yet, but this works well with
vscode and simple testing.
I now have to consider how to build this on Windows, although the
deployment target for this will be Linux. I have to allow for testing of it
on Windows, if possible. I thought perhaps that I could change the lib path
in the cgo header to reference "${GOOS}" instead, but it doesn't seem to
recognize that.
It's not reasonable to use build constraints for this, because it seems
like I would have to duplicate the entire module in order to vary the lib
path. That would be absurd.
What are reasonable strategies for this, including facilitating testing of
it in vscode on both Linux and Windows?
--
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/6d32bce7-b9db-4e08-9494-6cd115fa4f5cn%40googlegroups.com.
Re: [go-nuts] some incorrect code in blog.
I meant, did you test it with a bad path, and with the defer before the
error check? I believe you implied that this didn't result in a failure.
It would have happened on exit from the method, if anything.
On Thu, Nov 25, 2021 at 12:49 PM Roland Müller wrote:
> Yes. Actually I only tested with a non-existing file.
>
> But if you mean that case were also the directory is missing: behavior is
> still the same.
>
> BR,
> Roland
>
> func main() {
> f, err := os.Open("/tmp/dat_is_net_do/dat")
> //defer f.Close()
> fmt.Printf("%v\n", f)
> if err != nil {
> fmt.Println("NO FILE")
> //return
>}
>defer f.Close()
>fmt.Println("END")
> }
>
>
> Am Do., 25. Nov. 2021 um 21:43 Uhr schrieb David Karr <
> davidmichaelk...@gmail.com>:
>
>> And did you test that with a file path that would fail?
>>
>> On Thu, Nov 25, 2021, 11:40 Roland Müller wrote:
>>
>>> Hello,
>>>
>>> actually trying this with os.Open() the program behaves the same
>>> regardless whether the defer is before or after the error handling, Thus,
>>> no panic :-)
>>>
>>> Isn't anything declared with defer always running after the user code in
>>> the given func ends? I am too tired now to look this up.
>>>
>>> BR,
>>>
>>> Roland
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "os"
>>> )
>>>
>>> func main() {
>>> f, err := os.Open("/tmp/dat")
>>> //defer f.Close()
>>> fmt.Printf("%v\n", f)
>>> if err != nil {
>>> fmt.Println("NO FILE")
>>> //return
>>>}
>>>defer f.Close()
>>>fmt.Println("END")
>>> }
>>>
>>> Output:
>>>
>>> NO FILE
>>> END
>>>
>>>
>>> On 11/25/21 10:19, Fannie Zhang wrote:
>>>
>>> OK, I see. Thank you.
>>>
>>>
>>>
>>> *From:* Kurtis Rader
>>> *Sent:* Thursday, November 25, 2021 10:26 AM
>>> *To:* Fannie Zhang
>>> *Cc:* golang-nuts
>>>
>>> *Subject:* Re: [go-nuts] some incorrect code in blog.
>>>
>>>
>>>
>>> Notice the date of that blog article: 2010-08-04. It's more than eleven
>>> years old. Blog articles are not updated as the language changes. However,
>>> in this case the example in that article is correct. If `os.Open()` returns
>>> an error then the `src` return value is invalid.
>>>
>>>
>>>
>>> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang
>>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> There is some incorrect code in
>>> https://go.dev/blog/defer-panic-and-recover blog.
>>>
>>>
>>>
>>> The original code is
>>>
>>> *func CopyFile() {*
>>>
>>> * ...*
>>>
>>> * if err != nil {*
>>>
>>> * return*
>>>
>>> * }*
>>>
>>> * defer src.Close()*
>>>
>>> * ...*
>>>
>>> *}*
>>>
>>>
>>>
>>> I think the correct code should be
>>>
>>> *func CopyFile() {*
>>>
>>> * ...*
>>>
>>> * defer src.Close()*
>>>
>>> * if err != nil {*
>>>
>>> * return*
>>>
>>> * }*
>>>
>>> * ...*
>>>
>>> *}*
>>>
>>>
>>>
>>> I do not know how to modify the go blog, can anyone help? Thank you.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Fannie Zhang
>>>
>>> --
>>> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Kurtis Rad
Re: [go-nuts] some incorrect code in blog.
And did you test that with a file path that would fail?
On Thu, Nov 25, 2021, 11:40 Roland Müller wrote:
> Hello,
>
> actually trying this with os.Open() the program behaves the same
> regardless whether the defer is before or after the error handling, Thus,
> no panic :-)
>
> Isn't anything declared with defer always running after the user code in
> the given func ends? I am too tired now to look this up.
>
> BR,
>
> Roland
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> func main() {
> f, err := os.Open("/tmp/dat")
> //defer f.Close()
> fmt.Printf("%v\n", f)
> if err != nil {
> fmt.Println("NO FILE")
> //return
>}
>defer f.Close()
>fmt.Println("END")
> }
>
> Output:
>
> NO FILE
> END
>
>
> On 11/25/21 10:19, Fannie Zhang wrote:
>
> OK, I see. Thank you.
>
>
>
> *From:* Kurtis Rader
> *Sent:* Thursday, November 25, 2021 10:26 AM
> *To:* Fannie Zhang
> *Cc:* golang-nuts
>
> *Subject:* Re: [go-nuts] some incorrect code in blog.
>
>
>
> Notice the date of that blog article: 2010-08-04. It's more than eleven
> years old. Blog articles are not updated as the language changes. However,
> in this case the example in that article is correct. If `os.Open()` returns
> an error then the `src` return value is invalid.
>
>
>
> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang wrote:
>
> Hi all,
>
>
>
> There is some incorrect code in
> https://go.dev/blog/defer-panic-and-recover blog.
>
>
>
> The original code is
>
> *func CopyFile() {*
>
> * ...*
>
> * if err != nil {*
>
> * return*
>
> * }*
>
> * defer src.Close()*
>
> * ...*
>
> *}*
>
>
>
> I think the correct code should be
>
> *func CopyFile() {*
>
> * ...*
>
> * defer src.Close()*
>
> * if err != nil {*
>
> * return*
>
> * }*
>
> * ...*
>
> *}*
>
>
>
> I do not know how to modify the go blog, can anyone help? Thank you.
>
>
>
> Best regards,
>
> Fannie Zhang
>
> --
> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
>
> .
>
>
>
>
> --
>
> Kurtis Rader
>
> Caretaker of the exceptional canines Junior and Hank
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you. --
> 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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.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/4d0b379f-c2a0-a314-e2d3-5fec36528845%40gmail.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/CAA5t8Vq9m6rrR3GRcUqq-iKZc%3DX0okVuC6%2BPbH3n0zJx-SMZ7w%40mail.gmail.com.
Re: [go-nuts] some incorrect code in blog.
On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang wrote:
> Hi all,
>
> There is some incorrect code in
> https://go.dev/blog/defer-panic-and-recover blog.
>
> The original code is
> *func CopyFile() {*
> * ...*
> * if err != nil {*
> * return*
> * }*
> * defer src.Close()*
> * ...*
> *}*
>
> I think the correct code should be
> *func CopyFile() {*
> * ...*
> * defer src.Close()*
> * if err != nil {*
> * return*
> * }*
> * ...*
> *}*
>
> I do not know how to modify the go blog, can anyone help? Thank you.
>
Well, I would call myself a Go newbie, but I would think that if err !=
nil, that means there was an error, so the value of "src" would be either
invalid or nil, so putting the "defer" before the err check would possibly
result in a panic. I'd say the original code is correct.
> Best regards,
> Fannie Zhang
>
> --
> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%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/CAA5t8Vp4-dYHApveOObvQMXqg0s%2B_8Lu1WhCDKgyB8rst9cytw%40mail.gmail.com.
[go-nuts] Re: Getting "cgo argument has Go pointer to Go pointer"
On Monday, November 15, 2021 at 3:49:20 PM UTC-8 David Karr wrote:
>
> I'm pretty new to Go (many years in other languages). I'm trying to use
> cgo to use a C library we're using.
>
> I have the following line of code, which is compiling (that's been enough
> of a struggle):
>
> status = int(C.VeProtect(C.VeObj(fpeProtect), &argsProtect))
>
> This is failing at runtime with
>
> panic serving [::1]:55146: runtime error: cgo argument has Go pointer to
> Go pointer goroutine 20 [running]: net/http.(*conn).serve.func1()
> /usr/local/go/src/net/http/server.go:1801 +0x13a panic({0xc21cc0,
> 0xc93700}) /usr/local/go/src/runtime/panic.go:1047 +0x262 voltagems
> /voltagefuncs.protectAndAccess.func1(0x0, 0xcb2960)
> /media/sf_winhome/git/voltagego/voltagefuncs/voltagefuncs.go:71 +0x90
>
>
> The first thing that's frustrating about this error is that I can't tell
> which argument it's talking
> about. I would guess it's the first one, as it's more complicated than the
> second.
>
> The type of "fpeProtect" is "C.VeFPE", and "C.VeObj" is an alias for
> "void*".
>
> And "C.VeFPE" is defined as:
>
> type _Ctype_VeFPE *_Ctype_struct_VeFPE_st
>
> Any suggestions?
>
>
Note that all the properties of this structure are set by C functions. All
I do is define the variable and pass a pointer to it to functions.
Also, I saw one note that suggesting that setting "GODEBUG=cgocheck=0"
might disable this check (not sure if that will help me or not), but I'm
using vscode for this, and I don't know how to set the GO environment
variables.
--
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/17f65eee-5da7-4194-945c-2e34f65a372an%40googlegroups.com.
[go-nuts] Getting "cgo argument has Go pointer to Go pointer"
I'm pretty new to Go (many years in other languages). I'm trying to use
cgo to use a C library we're using.
I have the following line of code, which is compiling (that's been enough
of a struggle):
status = int(C.VeProtect(C.VeObj(fpeProtect), &argsProtect))
This is failing at runtime with
panic serving [::1]:55146: runtime error: cgo argument has Go pointer to Go
pointer goroutine 20 [running]: net/http.(*conn).serve.func1()
/usr/local/go/src/net/http/server.go:1801 +0x13a panic({0xc21cc0,
0xc93700}) /usr/local/go/src/runtime/panic.go:1047 +0x262 voltagems
/voltagefuncs.protectAndAccess.func1(0x0, 0xcb2960)
/media/sf_winhome/git/voltagego/voltagefuncs/voltagefuncs.go:71 +0x90
The first thing that's frustrating about this error is that I can't tell
which argument it's talking
about. I would guess it's the first one, as it's more complicated than the
second.
The type of "fpeProtect" is "C.VeFPE", and "C.VeObj" is an alias for
"void*".
And "C.VeFPE" is defined as:
type _Ctype_VeFPE *_Ctype_struct_VeFPE_st
Any suggestions?
--
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/f89005a3-6cbf-4f4c-bc90-3cdb1e6eb87cn%40googlegroups.com.
