[go-nuts] Golang subversion vcs
I see the latest (Go 1.17.X) releases support Subversion modules but I
cannot figure out how to get the `go get` command to pull in a tagged
subversion module. Subversion repo layout
- tags
- contracts
- configcontracts
- v2.8.1
- trunk
- contracts
- configcontracts
- go.mod file with module
{HOSTNAME}/svn/testrepo/trunk/contracts/configcontracts
I tried multiple different module definitions in the go.mod file along with
different go get commands. I was able to get go get to work with an
"invalid version" where the go.mod file lists:
XX/svn/testrepo/tags/contracts/configcontracts.svn v0.0.0-X
But obviously that isn't using versions (ie. v2.8.1) like Git. Is it
possible that there is a bug in the go get VCS for Subversion that I need
to support or does someone else have other recommendations?
--
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/898f9505-985f-46ce-867d-28e9aa714bf1n%40googlegroups.com.
[go-nuts] Re: gopls performance question
To follow up, I did submit an issue and it is related to a bug in gopls: https://github.com/golang/vscode-go/issues/299 -- 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/9fe795e4-d5e8-47ba-9bfd-9043da61e3d7o%40googlegroups.com.
[go-nuts] Re: gopls performance question
To add a bit more information to this topic: I also have Vim + ale + gopls setup and I tried the same file with Vim + gopls auto complete and it was much faster in Vim. Based on my rough timing, I got the correct auto complete responses from gopls in Vim in about 1.5 seconds vs about 4-5 seconds in VSCode. I am using VSCode 1.46.1 on Linux. Could this in some way be a VSCode issue instead of gopls? On Friday, July 3, 2020 at 3:43:53 PM UTC-4, Luke Mauldin wrote: > > I have a Go project that is relatively small in terms of number of files > (less than 30) but some Go files have auto-generated code that makes them > relatively large - some between 3-4 MB. I counted the SLOC using > https://github.com/hhatto/gocloc and it reports about 61K lines of code > and 40K lines of comments. When I am using `gopls` in my project on a > pretty high-end workstation (Intel Xeon W-2135, 32 GB RAM, SSD hard drive), > it is taking 4-5 seconds to give autocomplete suggestions in VSCode. Do > you have any recommendations of ways to improve the auto complete time? > Of note, one of the subdirectories of the project is a package that uses > CGO and it is wrapping about 440 C method calls. If it would help, I can > move that subdirectory into its own package entirely and reference it via > go.mod? > > Please let me know if you have any suggestions or if I should post this in > the `gopls` Github project. > > Luke > -- 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/16f60edd-a9b4-499f-8202-53c0edf17903o%40googlegroups.com.
[go-nuts] gopls performance question
I have a Go project that is relatively small in terms of number of files (less than 30) but some Go files have auto-generated code that makes them relatively large - some between 3-4 MB. I counted the SLOC using https://github.com/hhatto/gocloc and it reports about 61K lines of code and 40K lines of comments. When I am using `gopls` in my project on a pretty high-end workstation (Intel Xeon W-2135, 32 GB RAM, SSD hard drive), it is taking 4-5 seconds to give autocomplete suggestions in VSCode. Do you have any recommendations of ways to improve the auto complete time? Of note, one of the subdirectories of the project is a package that uses CGO and it is wrapping about 440 C method calls. If it would help, I can move that subdirectory into its own package entirely and reference it via go.mod? Please let me know if you have any suggestions or if I should post this in the `gopls` Github project. Luke -- 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/e5bc80df-3cdd-4d40-89d7-00af93ee8608o%40googlegroups.com.
[go-nuts] Re: Many instances question - shared library
I agree that it is not a scalable architecture but unfortunately it is a large third party application the business depends on and it cannot be rewritten. Option 3 to use grpc is a good idea but unfortunately won’t work either because the Go shared library invokes C function calls back into the process that loaded it to perform work. Long term, I am looking at having to rewrite the Go shared library into a language that doesn’t have a runtime like C++ or Rust but in the meantime I was checking to see if there is anything I can do to lessen the Go runtime overhead in this unique situation. -- 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/8166ec91-e9e9-4ade-9d89-94512a92fa2e%40googlegroups.com.
[go-nuts] Re: Many instances question - shared library
The multiple instances are required to due to way the 3rd party application works. In brief, it creates a new process for each user connection and then each new process dynamically load the Go shared library to provide C extension points. -- 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/fd96216b-2f15-49ac-af6d-e99f4e4f6ca6%40googlegroups.com.
[go-nuts] Many instances question - shared library
I have deployed a Go shared library on Linux that exposes C functions as extension points for a 3rd party application and is loaded dynamically at runtime. The 3rd party application then invokes "C" functions (which are backed by Go) and that is all working as expected. However, due to the nature of the application, there maybe 100 or 200 instances of the 3rd party application running on the server at any given time and each of those is loading its own copy of the Go shared library so I have to "pay the penalty" of the Go runtime for each process. Has anyone else encountered this scenario? Is there anything I can do to reduce this cost? I have already done simple things like setting GOMAXPROCS 1 because generally there will only be 1 primary goroutine running in each instance. I have looked at tinygo but that seems to be targeting a different use case. Any other recommendations? Luke -- 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/4e921205-67ab-4626-a8fd-441573d4164c%40googlegroups.com.
[go-nuts] Build with C dependencies
I have a Go program that I need to link against multiple C libraries in order to compile. I am setting the CFLAGS and LDFLAGS through #cgo directives which works nicely. My problem is that I would like to run my go builds (and test, etc...) inside a docker container so I can put the C include/library files in the docker container and make repeatable builds. This approach also enables me to update the C include/library files without having to update each of my build machines. I have written my own custom tool that encapsulates alot of the functionality of go build/test by taking command line arguments, starting the build process inside a docker container and then passing those command line arguments through to go build/test. However this has the drawback of being custom code, bugs, and it will have to be completely re-worked to work with go modules. I know there is a Go docker image at: https://hub.docker.com/_/golang but it looks like that does not play nicely with GOCACHE and I need the GOCACHE to work because my builds are rather large. Has anyone else had similar problems of trying to build Go applications inside custom docker containers? What were your solutions? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Windows cgo complier
Can someone please tell me what the golang team uses as the reference windows x64 compiler? I have heard references to mingw64 but it would be helpful to know the exact version they are using for their unit tests on Windows. I am experiencing different cgo windows behavior in 1.10 than 1.9.3 and I want to verify I am using the validated windows tool chain. Luke -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Go Windows vs Linux networking stack differences
One of the things I love about Go is its ability to write code in one OS
and easily cross-compile and deploy that code to another OS. Can someone
help me understand the differences in Windows vs Linux Go networking
stack? I know that at the top level they are both the same, just use
net.Dial("tcp", ":8080), etc.. but I would like to know if there are
underlying network stack differences in the Go standard library that will
cause different performance characteristics between the two OSes?
Luke Mauldin
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Win 32bit calling convention
I am using the steps as detailed at the bottom of this issue https://github.com/golang/go/issues/11058 to create a Go shared library on Windows exposing C function. Right now it is all working compiling in X64. If I also want to make an X32 version of my library, I know I will have to set some different environment variables and use a different version of mingw. However, my question is, what is the default calling convention that the exported Golang functions use and can this be changed? (ex: stdcall to cdecl or vice versa). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] C Syscall Memory Code Review
Can you please review the code here: https://play.golang.org/p/Yk6nqHhtTo This forms the basis of a "memory" package which I am using on Windows to do interoperability with some C APIs. These existing C APIs sometimes take/return a C-null terminated pointer and sometimes they take/return a pointer allocated with the CoTaskMemAlloc and CoTaskMemFree functions. I have some tested this package with some simple code and it works without crashes. My main concern is that I want to make sure it continues to work as the GC moves memory around, etc.. P.S. I know that CGO is an option but it isn't a good fit for my environment. Luke -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go string to uintptr
Thank you for the help, that worked. I don't want to use cgo directly because of the compile overhead and because cgo prevents debugging on Windows. Another question, if there is a C function with the declaration: void returnOutCString(char ** out) I can call the function using: var retPtr unsafe.Pointer proc.Call(uintptr(retPtr)) But how do I convert retPtr to a Go String? On Tuesday, September 6, 2016 at 4:13:01 PM UTC-5, Andy Balholm wrote: > If you use cgo, there is a helper function C.CString to do this. > > You can convert the string to a []byte, append 0 (for a null-terminated > string), and take the address of the first byte. > > Andy -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Cgo Pointer Arithmetic
I have questions about pointer arithmetic illustrated by this Play example: https://play.golang.org/p/-cZteTY_M2 Questions: 1) Is this the best way to do pointer arithmetic in Go to process a C array and convert it to a Go slice? 2) Go vet gives an error on line 18 but doesn't give much information on how to fix the usage of unsafe.Pointer. Any recommendations? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
