[go-nuts] Re: Discussion on "Vendoring edge case, critical problem"
Libraries can vendor in the directory "internal"? -- 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] Append to slice... what happens?
This: https://play.golang.org/p/AE670rTMpE I don't know what I expected, but it's weird. Don't mess with slices. -- 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 1.8 : cmd/go : test timed out after 3m0s
Installing Go 1.8 with: git pull git checkout go1.8 cd src GOROOT_BOOTSTRAP=/path/to/go1.4 ./all.bash I get this: panic: test timed out after 3m0s (stacktrace) FAILcmd/go 193.895s The problem is I am installing this on a system with a very slow, network file system. How can I increase the timeout for this test? -- 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] Request for advice: Developing for Android
I want to start developing for Android, and would like your advice on that: Where to start. My background is Linux. I have a lot of programming experience. Mainly C and Perl, followed by C and Python, and for the last five years it's mainly Go. I did some Java programming for a few weeks, decades ago, and I didn't like it. I played around briefly with DroidScript http://droidscript.org/ a while ago, but never used it for anything useful. My first goal is to get to know Android as a developer, learn its concepts, architecture, possibilities. What I am going to do with it is something I don't know yet, but I don't want to limit myself by using the wrong development platform. So, Android Studio would be the obvious choice. But: Java. How about Go Mobile? Is that useful as a starting point, or should I try to get to know the system first using Android Studio? What are the capabilities of Go Mobile? Can it do all the stuff a native app can do, system calls, events, graphics, sound, sensors, communications, all that stuff? Can I use all the Java libraries for Android that I assume must be available out there? Or should I use another platform all together? There seem to be so many. A quick search got me Adobe PhoneGap, Apache Cordova, DroidScript, NativeScript, AppDeck... (If things can run on iPhone too... I don't care.) I would like to hear your advice on what you think is the best platform. But what's important too is: does it have good tutorials, that explain concepts and architecture, as well as how to do practical stuff. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Request for advice: Developing for Android
Op vrijdag 23 september 2016 04:12:47 UTC+2 schreef parais...@gmail.com: > > My advice, unless you need to do some low level stuff with the NDK in C or > C++ use Java, that's the only viable way to develop for Android. > > With Phonegap (html,javascript) you will never take advantage of Android > SDK widgets and won't be able to write background activities ,and you won't > really learn Android development. > I ruled that one out, and several other solutions. But I'm still thinking of NativeScript as a viable alternative. I just don't know yet what its limitations are, and if those limitations are a problem. > Gomobile is not production ready in my opinion, and there is no GUI aside > from developing your own with OpenGL. > It looks attrative for building libraries. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Request for advice: Developing for Android
Op donderdag 22 september 2016 19:53:17 UTC+2 schreef Elias Naur: Does subsequent go gets after rm -fr'ing once, or only if you rm -fr before > go get every time? If it works from now on, you might have had some old > crud in the existing directory. If you need rm -fr every time, here's the > output from similar runs on my machine: > When I rm the examples/bind directory, and then do ` go get -d golang.org/x/mobile/example/bind/...` I get the same error, even if I add the flags -u and -f. I guess this is just how git works. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Request for advice: Developing for Android
I try the examples on https://github.com/golang/go/wiki/Mobile
Native applications -> Building and deploying to Android works fine.
On "SDK applications and generating bindings" I get into problems.
It says:
go get -d golang.org/x/mobile/example/bind/...
I get:
warning: "golang.org/x/mobile/example/bind/..." matched no packages
can't load package: package golang.org/x/mobile/example: no buildable
Go source files in /home/peter/go/src/golang.org/x/mobile/example
But this works:
go get -d github.com/golang/mobile/example/bind/...
But then building in Studio fails.
I edit example/bind/android/hello/build.gradle to set GO and GOPATH, and I
change pkg from "golang.org/x/mobile/example/bind/hello" to
"github.com/golang/mobile/example/bind/hello"
When I do Build -> Make Project, I get:
Executing tasks: [clean, :app:generateDebugSources,
:app:mockableAndroidJar, :app:prepareDebugUnitTestDependencies,
:app:generateDebugAndroidTestSources, :app:compileDebugSources,
:app:compileDebugUnitTestSources, :app:compileDebugAndroidTestSources]
Configuration on demand is an incubating feature.
Incremental java compilation is an incubating feature.
:app:clean
:hello:clean UP-TO-DATE
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:hello:gobind
:app:prepareAndroidHelloUnspecifiedLibrary
:app:prepareComAndroidSupportAppcompatV72211Library
:app:prepareComAndroidSupportSupportV42211Library
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
:app:generateDebugResValues
:app:generateDebugResources
:app:mergeDebugResources
:app:processDebugManifest
:app:processDebugResources
:app:generateDebugSources
:app:mockableAndroidJar UP-TO-DATE
:app:preDebugUnitTestBuild UP-TO-DATE
:app:prepareDebugUnitTestDependencies
:app:preDebugAndroidTestBuild UP-TO-DATE
:app:prepareDebugAndroidTestDependencies
:app:compileDebugAndroidTestAidl
:app:processDebugAndroidTestManifest
:app:compileDebugAndroidTestRenderscript
:app:generateDebugAndroidTestBuildConfig
:app:generateDebugAndroidTestResValues
:app:generateDebugAndroidTestResources
:app:mergeDebugAndroidTestResources
:app:processDebugAndroidTestResources
:app:generateDebugAndroidTestSources
:app:incrementalDebugJavaCompilationSafeguard
:app:compileDebugJavaWithJavac
:app:compileDebugJavaWithJavac - is not incremental (e.g. outputs have
changed, no previous execution, etc.).
/home/peter/go/src/github.com/golang/mobile/example/bind/android/app/src/main/java/org/golang/example/bind/MainActivity.java:27:
error: cannot find symbol
String greetings = Hello.Greetings("Android and Gopher");
^
symbol: method Greetings(String)
location: class Hello
1 error
:app:compileDebugJavaWithJavac FAILED
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Request for advice: Developing for Android
Op donderdag 22 september 2016 18:08:10 UTC+2 schreef Elias Naur:
>
>
>
> On Thursday, September 22, 2016 at 5:34:24 PM UTC+2, Peter Kleiweg wrote:
>>
>> I try the examples on https://github.com/golang/go/wiki/Mobile
>>
>> Native applications -> Building and deploying to Android works fine.
>>
>> On "SDK applications and generating bindings" I get into problems.
>>
>> It says:
>>
>> go get -d golang.org/x/mobile/example/bind/...
>>
>> I get:
>>
>> warning: "golang.org/x/mobile/example/bind/..." matched no packages
>> can't load package: package golang.org/x/mobile/example: no
>> buildable Go source files in /home/peter/go/src/
>> golang.org/x/mobile/example
>>
>>
> That's odd, and it should definitely work. With Go 1.7.1 and after
> removing my existing $GOPATH/golang.org directory out of the way, running
>
> $ go get -d golang.org/x/mobile/example/bind/.
> <http://golang.org/x/mobile/example/bind/>..
>
> outputs no error and downloads golang.org/x/mobile just fine. Which
> version of Go are you using? Regardless of this issue, I recommend 1.7.1
> because it contains fixes for several issues on mobiles, in particular iOS.
>
(peter) ~ go version
go version go1.7.1 linux/amd64
(peter) ~ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/peter/go"
GORACE=""
GOROOT="/my/opt/go"
GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build429704933=/tmp/go-build
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
(peter) ~ go get -v -u -d golang.org/x/mobile/example/bind/...
Fetching https://golang.org/x/mobile/example/bind?go-get=1
Parsing meta tags from
https://golang.org/x/mobile/example/bind?go-get=1 (status code 200)
get "golang.org/x/mobile/example/bind": found meta tag
main.metaImport{Prefix:"golang.org/x/mobile", VCS:"git",
RepoRoot:"https://go.googlesource.com/mobile"} at
https://golang.org/x/mobile/example/bind?go-get=1
get "golang.org/x/mobile/example/bind": verifying non-authoritative
meta tag
Fetching https://golang.org/x/mobile?go-get=1
Parsing meta tags from https://golang.org/x/mobile?go-get=1 (status
code 200)
golang.org/x/mobile (download)
warning: "golang.org/x/mobile/example/bind/..." matched no packages
can't load package: package .: no buildable Go source files in
/home/peter
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Request for advice: Developing for Android
Op donderdag 22 september 2016 18:28:43 UTC+2 schreef Peter Kleiweg:
>
> Op donderdag 22 september 2016 18:08:10 UTC+2 schreef Elias Naur:
>>
>>
>>
>> On Thursday, September 22, 2016 at 5:34:24 PM UTC+2, Peter Kleiweg wrote:
>>>
>>> I try the examples on https://github.com/golang/go/wiki/Mobile
>>>
>>> Native applications -> Building and deploying to Android works fine.
>>>
>>> On "SDK applications and generating bindings" I get into problems.
>>>
>>> It says:
>>>
>>> go get -d golang.org/x/mobile/example/bind/...
>>>
>>> I get:
>>>
>>> warning: "golang.org/x/mobile/example/bind/..." matched no packages
>>> can't load package: package golang.org/x/mobile/example: no
>>> buildable Go source files in /home/peter/go/src/
>>> golang.org/x/mobile/example
>>>
>>>
>> That's odd, and it should definitely work. With Go 1.7.1 and after
>> removing my existing $GOPATH/golang.org directory out of the way, running
>>
>> $ go get -d golang.org/x/mobile/example/bind/.
>> <http://golang.org/x/mobile/example/bind/>..
>>
>> outputs no error and downloads golang.org/x/mobile just fine. Which
>> version of Go are you using? Regardless of this issue, I recommend 1.7.1
>> because it contains fixes for several issues on mobiles, in particular iOS.
>>
>
> (peter) ~ go version
> go version go1.7.1 linux/amd64
> (peter) ~ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/peter/go"
> GORACE=""
> GOROOT="/my/opt/go"
> GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build429704933=/tmp/go-build
> -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> (peter) ~ go get -v -u -d golang.org/x/mobile/example/bind/...
> Fetching https://golang.org/x/mobile/example/bind?go-get=1
> Parsing meta tags from
> https://golang.org/x/mobile/example/bind?go-get=1 (status code 200)
> get "golang.org/x/mobile/example/bind": found meta tag
> main.metaImport{Prefix:"golang.org/x/mobile", VCS:"git", RepoRoot:"
> https://go.googlesource.com/mobile"} at
> https://golang.org/x/mobile/example/bind?go-get=1
> get "golang.org/x/mobile/example/bind": verifying non-authoritative
> meta tag
> Fetching https://golang.org/x/mobile?go-get=1
> Parsing meta tags from https://golang.org/x/mobile?go-get=1 (status
> code 200)
> golang.org/x/mobile (download)
> warning: "golang.org/x/mobile/example/bind/..." matched no packages
> can't load package: package .: no buildable Go source files in
> /home/peter
>
When I do this first, it works:
rm -fr $GOPATH/src/golang.org/x/mobile
--
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 1.7.3 is released
Same problem here. Also, after the last package test cmd/vet/internal/cfg, all further tests are skipped. GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/net/aps/64/opt/gosite" GORACE="" GOROOT="/net/aps/64/opt/go" GOTOOLDIR="/net/aps/64/opt/go/pkg/tool/linux_amd64" CC="gcc" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build028705261=/tmp/go-build -gno-record-gcc-switches" CXX="g++" CGO_ENABLED="1" -- 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] xml omitempty for sub-elements
Four years later, and this still hasn't been fixed. The conversation you
are linking to has been locked. What can we do? File a new bug report?
Op donderdag 15 november 2012 13:41:55 UTC+1 schreef Vladimir Mihailenco:
>
> I guess you have to vote for
> http://code.google.com/p/go/issues/detail?id=4168 .
>
> For now I do post processing like replace("", ""), because
> xml schema validators does not accept such constructs.
>
>
> On Thu, Nov 15, 2012 at 1:49 PM, OmarShariffDontLikeIt <
> omarsharif...@gmail.com > wrote:
>
>> http://play.golang.org/p/E65WSpB8BY
>>
>> How can I Marshal an instance of the above structure and have the
>> "" element omited if it contains no items in the array? I want
>> the following output:
>>
>> My Project
>>
>> Any suggestions?
>>
>> Cheers,
>> Ben
>>
>
--
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] Are these types discarded? Is this a compiler bug?
Op donderdag 23 maart 2017 20:58:53 UTC+1 schreef Ian Lance Taylor:
>
> On Thu, Mar 23, 2017 at 11:56 AM, Peter Kleiweg <pkle...@xs4all.nl
> > wrote:
> > Op donderdag 23 maart 2017 17:46:18 UTC+1 schreef Ian Lance Taylor:
> >>
> >> On Thu, Mar 23, 2017 at 8:54 AM, Peter Kleiweg <pkle...@xs4all.nl>
> wrote:
> >> > Some code that includes C code compiles fine on Linux, but gives
> strange
> >> > errors on Darwin.
> >> >
> >> >
> >> > In one source file, that doesn't include C, I have this:
> >> >
> >> > type reactor_socket struct {
> >> > e State
> >> > f func(State) error
> >> > }
> >> >
> >> > and...
> >> >
> >> > reactor_socket{e: events, f: handler}
> >> >
> >> >
> >> >
> >> > In another file that does include C, I have this:
> >> >
> >> > type State int
> >> >
> >> >
> >> >
> >> > Compiling of the first source file gives these errors on the line
> >> > creating
> >> > the reactor_socket:
> >> >
> >> > workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use
> >> > events
> >> > (type State) as type int in field value
> >> > workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use
> >> > handler
> >> > (type func(State) error) as type func(int) error in field value
> >> >
> >> > It looks like in one source file, the type State is preserved, while
> in
> >> > the
> >> > other it is replaced by an int.
> >> >
> >> >
> >> > Is this a compiler bug? What else could it be?
> >> >
> >> > Please see details at https://github.com/pebbe/zmq4/issues/97
> >>
> >> I suppose it could be a cgo bug. I can't recreate it, but I'm using
> >> GNU/Linux. I tried both GCC and clang.
> >>
> >> Try running `go build -work` to preserve the temporary directory and
> >> look at the generated .go files.
> >
> >
> > There is no generated Go file corresponding to the file that generates
> the
> > error.
>
> No, I wouldn't expect one, but it seems that the contents of the files
> that are generated must be triggering the error somehow. In
> particular it might be interesting to compare the generated files on a
> working system with the ones on a failing system.
>
OK, here are all the
differences: https://pkleiweg.home.xs4all.nl/go/diff.txt
--
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] Are these types discarded? Is this a compiler bug?
Some code that includes C code compiles fine on Linux, but gives strange
errors on Darwin.
In one source file, that doesn't include C, I have this:
type reactor_socket struct {
e State
f func(State) error
}
and...
reactor_socket{e: events, f: handler}
In another file that does include C, I have this:
type State int
Compiling of the first source file gives these errors on the line creating
the reactor_socket:
workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use events
(type State) as type int in field value
workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use
handler (type func(State) error) as type func(int) error in field value
It looks like in one source file, the type State is preserved, while in the
other it is replaced by an int.
Is this a compiler bug? What else could it be?
Please see details at https://github.com/pebbe/zmq4/issues/97
--
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] Are these types discarded? Is this a compiler bug?
Op donderdag 23 maart 2017 17:46:18 UTC+1 schreef Ian Lance Taylor:
>
> On Thu, Mar 23, 2017 at 8:54 AM, Peter Kleiweg <pkle...@xs4all.nl
> > wrote:
> > Some code that includes C code compiles fine on Linux, but gives strange
> > errors on Darwin.
> >
> >
> > In one source file, that doesn't include C, I have this:
> >
> > type reactor_socket struct {
> > e State
> > f func(State) error
> > }
> >
> > and...
> >
> > reactor_socket{e: events, f: handler}
> >
> >
> >
> > In another file that does include C, I have this:
> >
> > type State int
> >
> >
> >
> > Compiling of the first source file gives these errors on the line
> creating
> > the reactor_socket:
> >
> > workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use
> events
> > (type State) as type int in field value
> > workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use
> handler
> > (type func(State) error) as type func(int) error in field value
> >
> > It looks like in one source file, the type State is preserved, while in
> the
> > other it is replaced by an int.
> >
> >
> > Is this a compiler bug? What else could it be?
> >
> > Please see details at https://github.com/pebbe/zmq4/issues/97
>
> I suppose it could be a cgo bug. I can't recreate it, but I'm using
> GNU/Linux. I tried both GCC and clang.
>
> Try running `go build -work` to preserve the temporary directory and
> look at the generated .go files.
>
There is no generated Go file corresponding to the file that generates the
error.
--
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] Uncontrolled map access can crash the program --- how?
>From the faq: https://golang.org/doc/faq#atomic_maps ... uncontrolled map access can crash the program. In what situations does this apply? Can I have two goroutines reading a single map at the same time? Can I have one goroutine putting something in a map while at the same time another goroutine is reading the map? Does it depend on the type of the key or the type of the value? -- 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] To panic or not to panic, that's the question
If a package can't be used because some precondition can't be fulfilled, you can use a panic. Then the whole program will crash at start-up. The alternative would be to not panic in the init, but have all function calls return an error. If the package is used in a large program, part of it may still be functional. Using panic in an init function of a package, do or don't? -- 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] Problems with cache
Since Go 1.10, the cache causes many headaches. You can disable the cache with GOCACHE=off. Unless you work on mega projects, you don't need a cache anyway. But disabling the cache won't be an option in Go 1.12. What to do then? Stick with old version of Go? The release notes for Go 1.11 have this to say: " Go 1.11 will be the last release to support setting the environment variable GOCACHE=off to disable the build cache, introduced in Go 1.10. Starting in Go 1.12, the build cache will be required, as a step toward eliminating $GOPATH/pkg. The module and package loading support described above already require that the build cache be enabled. If you have disabled the build cache to avoid problems you encountered, please file an issue to let us know about them. " However, when you file an issue, they tell you "it is working as intended". -- 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] Problems with cache
Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg: > > On 25 Aug 2018, at 15:21, Peter Kleiweg > > wrote: > > > disabling the cache won't be an option in Go 1.12. What to do then? > > > You don’t say what your issues with the build cache are. If you did, you > might get suggestions. > Actually, setting GOCACHE=off doesn't solve all problems. So I am now back to Go version 1.9.7 Some problems: - You can't use packages that require local adjustments to the environment to install. - Code completion in Emacs doesn't work (using gocode) - Running Go in a Jupyter Notebook (using lgo) is slow with Go version 1.10 and higher. -- 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] Problems with cache
Op zaterdag 25 augustus 2018 19:06:27 UTC+2 schreef Sebastien Binet: > > > > On Sat, Aug 25, 2018 at 6:54 PM Ian Lance Taylor > wrote: > >> On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg > > wrote: >> > Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg: >> >> >> >> On 25 Aug 2018, at 15:21, Peter Kleiweg wrote: >> >> >> >> >> >> disabling the cache won't be an option in Go 1.12. What to do then? >> >> >> >> >> >> You don’t say what your issues with the build cache are. If you did, >> you >> >> might get suggestions. >> > >> > >> > Actually, setting GOCACHE=off doesn't solve all problems. So I am now >> back >> > to Go version 1.9.7 >> > >> > Some problems: >> > >> > - You can't use packages that require local adjustments to the >> environment >> > to install. >> >> Can you expand on this. I'm not sure what you mean. >> >> >> > - Code completion in Emacs doesn't work (using gocode) >> >> That sounds like a bug to be fixed. The golang.org/x/go/packages >> package is intended to use the build cache for input where >> appropriate. The likely path forward will be to make gocode use >> go/packages. >> > > in my experience, nsf/gocode was quite problematic to properly handle Go > version bumps (I would end-up with "PANIC" messages in vim-go, resulting > from a weird mix of a new Go compiler, gocode using parts of the old one, > and my local code that would use the new one.) > I migrated to mdempsky/gocode. never looked back. > I tried this. It works for me too. > > >> >> > - Running Go in a Jupyter Notebook (using lgo) is slow with Go version >> 1.10 >> > and higher. >> >> I don't know what lgo is. In general the cache does not slow down the >> build. Quite the opposite: in my experience, it speeds it up. If you >> see cases where the cache makes things slower, please report them so >> that they can be fixed. >> > > Ian: that's https://github.com/yunabe/lgo > > Peter: you could try the one from gopherdata: > https://github.com/gopherdata/gophernotes > Yes, it works, but is it as good as lgo? I don't know if this comparison is up to date: https://github.com/yunabe/lgo#gophernotes -- 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] Problems with cache
Op zaterdag 25 augustus 2018 18:54:32 UTC+2 schreef Ian Lance Taylor: > > On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg > wrote: > > Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg: > >> > >> On 25 Aug 2018, at 15:21, Peter Kleiweg wrote: > >> > >> > >> disabling the cache won't be an option in Go 1.12. What to do then? > >> > >> > >> You don’t say what your issues with the build cache are. If you did, > you > >> might get suggestions. > > > > > > Actually, setting GOCACHE=off doesn't solve all problems. So I am now > back > > to Go version 1.9.7 > > > > Some problems: > > > > - You can't use packages that require local adjustments to the > environment > > to install. > > Can you expand on this. I'm not sure what you mean. > > See this issue: https://github.com/golang/go/issues/27027 > > - Code completion in Emacs doesn't work (using gocode) > > That sounds like a bug to be fixed. The golang.org/x/go/packages > package is intended to use the build cache for input where > appropriate. The likely path forward will be to make gocode use > go/packages. > > > > - Running Go in a Jupyter Notebook (using lgo) is slow with Go version > 1.10 > > and higher. > > I don't know what lgo is. In general the cache does not slow down the > build. Quite the opposite: in my experience, it speeds it up. If you > see cases where the cache makes things slower, please report them so > that they can be fixed. > It says here: https://github.com/yunabe/lgo#go110 " lgo works with go1.10. But the overhead of code execution is 4-5x larger in go1.10 than go1.9. It is due to a regression of the cache mechnism of go install in go1.10. I recommend you to use lgo with go1.9 until the bug is fixed in go1.10. " -- 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] identifier ... may conflict with identifiers generated by cgo
Installing packages with go1.12beta2 I get these messages: ... github.com/rug-compling/alpinocorpus-go/alpinocorpus/reader.go:39:15: identifier "_Ctype_alpinocorpus_iter" may conflict with identifiers generated by cgo ... github.com/rug-compling/alpinocorpus-go/alpinocorpus/reader.go:184:14: identifier "_Ctype_alpinocorpus_reader" may conflict with identifiers generated by cgo ... github.com/rug-compling/alpinocorpus-go/alpinocorpus/writer.go:30:13: identifier "_Ctype_alpinocorpus_writer" may conflict with identifiers generated by cgo ... github.com/pebbe/dbxml/dbxml.go:327:16: identifier "_Ctype_char" may conflict with identifiers generated by cgo ... github.com/pebbe/dbxml/dbxml.go:492:16: identifier "_Ctype_char" may conflict with identifiers generated by cgo ... github.com/pebbe/go-proj-4/proj/proj.go:48:9: identifier "_Ctype_projPJ" may conflict with identifiers generated by cgo ... github.com/jbowtie/gokogiri/xml/document.go:330:19: identifier "_Ctype_struct__xmlDoc" may conflict with identifiers generated by cgo What should I do with this? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go 1.12 Beta 1 is released
Ian Lance Taylor schreef op 20 december 2018 16:47:20 CET: > On Thu, Dec 20, 2018 at 1:07 AM Peter Kleiweg > wrote: > > > > Ian Lance Taylor schreef op 20 december 2018 > 00:06:58 CET: > > > > > How about this: > > > > > > Move the C files to a subdirectory. Write a script or Makefile > that > > > compiles the C files into a .syso file in the main package > directory, > > > using flags that you specify. Fetch the package using `go get > -d`. > > > Run the script with the appropriate flags to generate the .syso > file. > > > At that point `go build` should work. > > > > The C files are part of the package. This would mean, downloading > the package and reorganize it. > > I was imagining that this rearrangement would be done at the package > source, not each time it was downloaded. That would be nice, but the package developers are not on our payroll. They do not cater for our odd requirements. > > I was thinking there might be a better way. Add a file with local > configuration, a file that imports '"C" and sets CFLAGS and LDFLAGS, > without modifying the official package files. This works, except for > packages that rely on pkg-config. I don't see how I can modify the > contents of PKG_CONFIG_PATH in a Go file. > > Sure, that could work too. > > I don't understand why pkg-config would need to be correct on a > specific system. Why would pkg-config be incorrect? Sometimes, standard systems are too rigid. Things clash. Sometimes, you have to bend the accepted practices to get very odd bunches of software to work together. So you work in an odd environment. The Gnu build system handles this very well. It gives you options to tweak anything. In comparison, Go is rigid, and becoming more rigid. It assumes too much sameness on development platforms. Why would pkg-config be incorrect? Who cares. I just want to be able to fix it, when I need to. And I need to. -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- 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 1.12 Beta 1 is released
Ian Lance Taylor schreef op 20 december 2018 19:20:13 CET: > On Thu, Dec 20, 2018 at 8:02 AM Peter Kleiweg > wrote: > > > > Ian Lance Taylor schreef op 20 december 2018 > 16:47:20 CET: > > > On Thu, Dec 20, 2018 at 1:07 AM Peter Kleiweg > > > wrote: > > > > > > > > Ian Lance Taylor schreef op 20 december 2018 > > > 00:06:58 CET: > > > > > > > > > How about this: > > > > > > > > > > Move the C files to a subdirectory. Write a script or > Makefile > > > that > > > > > compiles the C files into a .syso file in the main package > > > directory, > > > > > using flags that you specify. Fetch the package using `go get > > > -d`. > > > > > Run the script with the appropriate flags to generate the > .syso > > > file. > > > > > At that point `go build` should work. > > > > > > > > The C files are part of the package. This would mean, > downloading > > > the package and reorganize it. > > > > > > I was imagining that this rearrangement would be done at the > package > > > source, not each time it was downloaded. > > > > That would be nice, but the package developers are not on our > payroll. They do not cater for our odd requirements. > > > > > > I was thinking there might be a better way. Add a file with > local > > > configuration, a file that imports '"C" and sets CFLAGS and > LDFLAGS, > > > without modifying the official package files. This works, except > for > > > packages that rely on pkg-config. I don't see how I can modify the > > > contents of PKG_CONFIG_PATH in a Go file. > > > > > > Sure, that could work too. > > > > > > I don't understand why pkg-config would need to be correct on a > > > specific system. Why would pkg-config be incorrect? > > > > Sometimes, standard systems are too rigid. Things clash. Sometimes, > you have to bend the accepted practices to get very odd bunches of > software to work together. So you work in an odd environment. The Gnu > build system handles this very well. It gives you options to tweak > anything. In comparison, Go is rigid, and becoming more rigid. It > assumes too much sameness on development platforms. > > > > Why would pkg-config be incorrect? Who cares. I just want to be able > to fix it, when I need to. And I need to. > > Adding the file with the local configuration should work just as well > when you need to adjust pkg-config results as it would for a package > that does not use pkg-config. No it doesn't. Unless I modify the original code, there is no way to switch off a failing call to pkg-config. I don't think modifying third-party package files is good idea. > I'm sorry you have trouble with the go tool. But to me it sounds like > you were using binary packages as a hack to get around that trouble, > not as a clean solution. There are good reasons why binary packages > do not work in general, as I outlined earlier. I don't want to use binary packages. But at the moment, it's the only working solution that doesn't require modifying third-party package files. > It sounds like you should be using a more flexible tool, such as make, > rather than trying to force-fit your complex and unusual scenario into > the go tool. I don't need make. A simple script will do. Or rather, it should. I can install the packages, but I can't import them because Go is too limited to remember the necessary environment settings. Starting from Go 1.14 I can only fix it by modifying files that should not be modified. Y -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- 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 1.12 Beta 1 is released
Ian Lance Taylor schreef op 20 december 2018 23:10:17 CET: > On Thu, Dec 20, 2018 at 10:58 AM Peter Kleiweg > wrote: > > > > Ian Lance Taylor schreef op 20 december 2018 > 19:20:13 CET: > > > Adding the file with the local configuration should work just as > well > > > when you need to adjust pkg-config results as it would for a > package > > > that does not use pkg-config. > > > > No it doesn't. Unless I modify the original code, there is no way to > switch off a failing call to pkg-config. I don't think modifying > third-party package files is good idea. > > In your go tool wrapper set the PKG_CONFIG environment variable to > something that does what you want. E.g., does nothing, to let you use > the fake .go file that you added. I prefer to keep package-specific configuration with the package, not polluting the environment unless the package is used. There may be incompatible settings between packages. But it is an option. -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- 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 1.12 Beta 1 is released
How do I do what runtime/race does? Is it what I want? I have a package with C and Go files. I want to install that package. Then I want to import that package into a program, and build that program without recompiling the package. Because recompile fails. How do I do that? This was an issue before, and the provided solution: after installation, mark the source as binary-only. That is a bit of a pain, but it works. Starting with Go 1.13, Go is going to make its users work more difficult again. Why? I just want to install a package and use it, without having to worry about external stuff. -- 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 1.12 Beta 1 is released
> I assume that the recompile fails because compiling the C code fails. You should compile the C code yourself, producing a .syso file. You should add that .syso file to your package directory. You should remove the C code from your package directory--you can still put it in a subdirectory, of course, for reference. Then a Go program can import your package, compile the Go code as usual, and use the .syso file for the C code. Hopefully that won't be any more painful than the approach you are using today, although it is different. This is not an option. > The reason for the change is that binary packages are hard to support correctly. There are many ways to modify how Go code is compiled, with options like -buildmode and -gcflags. If those options do not match exactly how the binary package was built, it's easy for there to be a silent error in the resulting program. That is not a good experience. The only thing that changes in our situation is the location of dynamic libraries. Is there any way to specify at installation time where packages should look for resources? Or what options to use when importing the package? Something like... go get -L /opt/foo/lib -I /opt/foo/include -Wl,-rpath=/opt/foo/lib github.com/some/gofoo And then Go would know to add those options whenever it needs to compile the package? -- 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 1.12 Beta 1 is released
Ian Lance Taylor schreef op 20 december 2018 00:06:58 CET: > How about this: > > Move the C files to a subdirectory. Write a script or Makefile that > compiles the C files into a .syso file in the main package directory, > using flags that you specify. Fetch the package using `go get -d`. > Run the script with the appropriate flags to generate the .syso file. > At that point `go build` should work. The C files are part of the package. This would mean, downloading the package and reorganize it. I was thinking there might be a better way. Add a file with local configuration, a file that imports '"C" and sets CFLAGS and LDFLAGS, without modifying the official package files. This works, except for packages that rely on pkg-config. I don't see how I can modify the contents of PKG_CONFIG_PATH in a Go file. -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- 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 1.12 Beta 1 is released
Ian Lance Taylor schreef op 19 december 2018 23:27:13 CET: > On Wed, Dec 19, 2018 at 2:15 PM Peter Kleiweg > wrote: > > > > > I assume that the recompile fails because compiling the C code > fails. > > You should compile the C code yourself, producing a .syso file. You > > should add that .syso file to your package directory. You should > > remove the C code from your package directory--you can still put it > in > > a subdirectory, of course, for reference. Then a Go program can > > import your package, compile the Go code as usual, and use the .syso > > file for the C code. Hopefully that won't be any more painful than > > the approach you are using today, although it is different. > > > > This is not an option. > > If you were able to use Go binary packages, then I don't understand > why this is not an option. The Go binary package must have included > compiled versions of the C code. They do not. They have Go code and C code. They are installed with go get. Then I add a file to the package source code that marks it as binary package. After any upgrade of Go or the package, I remove the binary marker, and repeat the procedure. > Perhaps I completely misunderstand > what you want to do. I want to provide packages in a environment where not all resources are available in a standard location (because of access restrictions in the organisation), packages that can only be installed with options relevant to that environment. I want multiple users to be able to import those package without them having to worry about environment settings. In practice, this mostly means including into the final program the path to some C libraries (rpath). Also in our set-up, the command 'go' is a wrapper script that adds a non-standard location to the end of GOPATH. > > > > The reason for the change is that binary packages are hard to > support > > correctly. There are many ways to modify how Go code is compiled, > > with options like -buildmode and -gcflags. If those options do not > > match exactly how the binary package was built, it's easy for there > to > > be a silent error in the resulting program. That is not a good > > experience. > > > > The only thing that changes in our situation is the location of > dynamic libraries. Is there any way to specify at installation time > where packages should look for resources? Or what options to use when > importing the package? > > > > Something like... > > > > go get -L /opt/foo/lib -I /opt/foo/include > -Wl,-rpath=/opt/foo/lib github.com/some/gofoo > > > > > > And then Go would know to add those options whenever it needs to > compile the package? > > If I understand you correctly, you can do this by setting the > CGO_CFLAGS and CGO_LDFLAGS environment variables when you run `go > get`. Yes, that used to work for older versions of Go. It doesn't work since Go a few versions back. Now building any program that imports the package, directly or indirectly, needs to set those same CGO_CFLAGS and CGO_LDFLAGS environment variables. -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- 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 1.12 Beta 1 is released
Go 1.12 is the last release that will support binary-only packages. What are the alternatives? I need binary-only packages for packages that use cgo with non-standard environment variable 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: [security] Go 1.13.2 and Go 1.12.11 are released
I did a git pull. There is a tag go1.13.1, but no tag go1.13.2. Also, no tag go1.12.11. -- 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/a519908d-d862-4145-8255-05ee40a34230%40googlegroups.com.
[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
This is with go version go1.14 linux/amd64 Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg: > > With Go version 1.14 I get a lot of errors when I run: > > go test -v github.com/pebbe/zmq4 > > I didn't see this with Go 1.13.8 or any earlier version. > > Is this a problem with Go 1.14, or am I doing something wrong and just got > lucky until now? > > How do I debug this? The errors are different for each run. Below is a > sample of some errors. > Line numbers are not always accurate, because I inserted some calls to > test.Log(). > > === RUN TestSocketEvent > TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted > system call > > > === RUN TestMultipleContexts > TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted > system call > > freeze: > === RUN TestMultipleContexts > ^CFAIL github.com/pebbe/zmq4 30.226s > > freeze: > === RUN TestMultipleContexts > TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: > expected [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got > interrupted system call [] > ^CFAIL github.com/pebbe/zmq4 21.445s > > > > freeze: > === RUN TestSecurityCurve > ^CFAIL github.com/pebbe/zmq4 31.143s > > > > freeze: > === RUN TestSecurityNull > TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource > temporarily unavailable > ^CFAIL github.com/pebbe/zmq4 44.828s > > > === RUN TestDisconnectInproc > TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system > call > TestDisconnectInproc: zmq4_test.go:623: isSubscribed > > === RUN TestHwm > TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system > call > TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected > 1, got -1 > > freeze: > === RUN TestSecurityPlain > ^CFAIL github.com/pebbe/zmq4 46.395s > > === RUN TestPairIpc > TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: > interrupted system call > > -- 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/cdb7319d-542a-45ab-842b-bc1b5d838e93%40googlegroups.com.
[go-nuts] Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
With Go version 1.14 I get a lot of errors when I run: go test -v github.com/pebbe/zmq4 I didn't see this with Go 1.13.8 or any earlier version. Is this a problem with Go 1.14, or am I doing something wrong and just got lucky until now? How do I debug this? The errors are different for each run. Below is a sample of some errors. Line numbers are not always accurate, because I inserted some calls to test.Log(). === RUN TestSocketEvent TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted system call === RUN TestMultipleContexts TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted system call freeze: === RUN TestMultipleContexts ^CFAIL github.com/pebbe/zmq4 30.226s freeze: === RUN TestMultipleContexts TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: expected [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got interrupted system call [] ^CFAIL github.com/pebbe/zmq4 21.445s freeze: === RUN TestSecurityCurve ^CFAIL github.com/pebbe/zmq4 31.143s freeze: === RUN TestSecurityNull TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource temporarily unavailable ^CFAIL github.com/pebbe/zmq4 44.828s === RUN TestDisconnectInproc TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system call TestDisconnectInproc: zmq4_test.go:623: isSubscribed === RUN TestHwm TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system call TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected 1, got -1 freeze: === RUN TestSecurityPlain ^CFAIL github.com/pebbe/zmq4 46.395s === RUN TestPairIpc TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: interrupted system call -- 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/745bfcea-2adf-44ce-bfd2-32bd4d2cf834%40googlegroups.com.
[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
Op woensdag 26 februari 2020 13:05:40 UTC+1 schreef Manlio Perillo: > > On Wednesday, February 26, 2020 at 12:33:05 PM UTC+1, Peter Kleiweg wrote: >> >> With Go version 1.14 I get a lot of errors when I run: >> >> go test -v github.com/pebbe/zmq4 >> >> I didn't see this with Go 1.13.8 or any earlier version. >> >> Is this a problem with Go 1.14, or am I doing something wrong and just >> got lucky until now? >> >> How do I debug this? The errors are different for each run. Below is a >> sample of some errors. >> Line numbers are not always accurate, because I inserted some calls to >> test.Log(). >> > > The errors are probably caused by https://golang.org/doc/go1.14#runtime. > > The solution is to update zmq4 to explicitly handle interrupted system > calls. > Often the program freezes before I get an interrupted system call. It hangs inside a ZeroMQ C++ library function. zmq4 is just a wrapper for ZeroMQ. I can't "fix" ZeroMQ to make it work with Go. Is there a way to stop Go from interrupting my system calls? It happens rather randomly all over the place. > However it is strange that they happen in the tests. Is this cause by > SIPIPE? > I don't know about this. The only flag to `go test` I used was -v. -- 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/8824260b-139d-4130-bbfa-790d85e85023%40googlegroups.com.
Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels: > > > Can you clarify that a bit? Did you change the code to look for EINTR > errors and then retry the system call? > Yes, I did. But as an option that must be enabled by the user. > -Original Message----- > From: Peter Kleiweg > Sent: Feb 28, 2020 9:04 AM > To: golang-nuts > Subject: [go-nuts] Re: Lot's of test errors in package zmq4 with Go > version 1.14, no errors with earlier versions > > Retry after EINTR solved the code lock-up too. > > Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg: >> >> With Go version 1.14 I get a lot of errors when I run: >> >> go test -v github.com/pebbe/zmq4 >> >> I didn't see this with Go 1.13.8 or any earlier version. >> >> Is this a problem with Go 1.14, or am I doing something wrong and just >> got lucky until now? >> >> How do I debug this? The errors are different for each run. Below is a >> sample of some errors. >> Line numbers are not always accurate, because I inserted some calls to >> test.Log(). >> >> === RUN TestSocketEvent >> TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted >> system call >> >> >> === RUN TestMultipleContexts >> TestMultipleContexts: zmq4_test.go:131: sock1.Connect: >> interrupted system call >> >> freeze: >> === RUN TestMultipleContexts >> ^CFAIL github.com/pebbe/zmq4 30.226s >> >> freeze: >> === RUN TestMultipleContexts >> TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: >> expected [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got >> interrupted system call [] >> ^CFAIL github.com/pebbe/zmq4 21.445s >> >> >> >> freeze: >> === RUN TestSecurityCurve >> ^CFAIL github.com/pebbe/zmq4 31.143s >> >> >> >> freeze: >> === RUN TestSecurityNull >> TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource >> temporarily unavailable >> ^CFAIL github.com/pebbe/zmq4 44.828s >> >> >> === RUN TestDisconnectInproc >> TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system >> call >> TestDisconnectInproc: zmq4_test.go:623: isSubscribed >> >> === RUN TestHwm >> TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system >> call >> TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): >> expected 1, got -1 >> >> freeze: >> === RUN TestSecurityPlain >> ^CFAIL github.com/pebbe/zmq4 46.395s >> >> === RUN TestPairIpc >> TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: >> interrupted system call >> >> -- > 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/f7eb247c-f772-4663-9d0b-5cb07c62e427%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/f7eb247c-f772-4663-9d0b-5cb07c62e427%40googlegroups.com?utm_medium=email_source=footer> > . > > > > > -- 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/7659417a-8b56-4a7d-9ae4-91878c7899e1%40googlegroups.com.
[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
Retry after EINTR solved the code lock-up too. Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg: > > With Go version 1.14 I get a lot of errors when I run: > > go test -v github.com/pebbe/zmq4 > > I didn't see this with Go 1.13.8 or any earlier version. > > Is this a problem with Go 1.14, or am I doing something wrong and just got > lucky until now? > > How do I debug this? The errors are different for each run. Below is a > sample of some errors. > Line numbers are not always accurate, because I inserted some calls to > test.Log(). > > === RUN TestSocketEvent > TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted > system call > > > === RUN TestMultipleContexts > TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted > system call > > freeze: > === RUN TestMultipleContexts > ^CFAIL github.com/pebbe/zmq4 30.226s > > freeze: > === RUN TestMultipleContexts > TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: > expected [tcp://127.0.0.1:9997 tcp://127.0.0.1:9997], got > interrupted system call [] > ^CFAIL github.com/pebbe/zmq4 21.445s > > > > freeze: > === RUN TestSecurityCurve > ^CFAIL github.com/pebbe/zmq4 31.143s > > > > freeze: > === RUN TestSecurityNull > TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource > temporarily unavailable > ^CFAIL github.com/pebbe/zmq4 44.828s > > > === RUN TestDisconnectInproc > TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system > call > TestDisconnectInproc: zmq4_test.go:623: isSubscribed > > === RUN TestHwm > TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system > call > TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected > 1, got -1 > > freeze: > === RUN TestSecurityPlain > ^CFAIL github.com/pebbe/zmq4 46.395s > > === RUN TestPairIpc > TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: > interrupted system call > > -- 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/f7eb247c-f772-4663-9d0b-5cb07c62e427%40googlegroups.com.
Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
GODEBUG=noasyncpreempt=1 makes no difference. I added the option -race and I got some warnings from that, all happening in a call to reactor.Run(). When I disable all tests that use reactor.Run() the test run no longer freezes. So I have to look at the implementation of the reactor. I still get the interrupted system calls, so I have to fix those too. It looks like these are two different issues. Op donderdag 27 februari 2020 19:07:54 UTC+1 schreef Robert Engels: > > Does it freeze if you use GODEBUG=noasyncpreempt=1 ? > > -Original Message----- > From: Peter Kleiweg > Sent: Feb 27, 2020 11:59 AM > To: golang-nuts > Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go > version 1.14, no errors with earlier versions > > Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor: >> >> On Thu, Feb 27, 2020 at 9:41 AM Robert Engels >> wrote: >> > >> > >> > I re-read your comments, and I agree that a rare error is still and >> error, and needs to be handled, but if it the platform is introducing lots >> of errors, is that the library writers issue? >> > >> > Maybe an easy solution is a flag to disable the signal usage for >> tight-loop preemption as a "backwards compatibility" mode ? >> > >> > As the OP pointed out, he can't really change ZeroMQ, and this is a >> fairly established product, maybe more so than Go, so doesn't it make more >> sense that Go adapts rather than the other way around? >> >> We already have that flag: GODEBUG=noasyncpreempt=1. >> >> The discussion upthread explains that the Go wrapper for ZeroMQ should >> handle EINTR, and take the appropriate action such as retrying the >> operation when appropriate. The response to that was a bit of >> distraction, as it discussed generic problems with EINTR. At this >> point there is no reason to assume that any of those problems actually >> apply to using ZeroMQ. >> > > Yes, a lot is said about handling EINTR. > > Nothing is said about the code just freezing. How to handle that? > > -- > 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/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com?utm_medium=email_source=footer> > . > > > > > -- 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/a95feca4-17f4-4a43-80c7-3adc76d0cabf%40googlegroups.com.
Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
Op vrijdag 28 februari 2020 16:57:00 UTC+1 schreef Ian Lance Taylor: > > On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg > wrote: > > > > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels: > >> > >> > >> Can you clarify that a bit? Did you change the code to look for EINTR > errors and then retry the system call? > > > > > > Yes, I did. But as an option that must be enabled by the user. > > I don't understand why you're making it an option. The README > suggests that you would not want to enable it if you want to handle > ^C, but in Go the ^C will be delivered on a channel, presumably to a > separate goroutine. At that point your program will either exit or do > some other operation. If the program doesn't exit, then it's not > going to want the interrupted system call to fail. It's going to want > it to be retried. > I leave it to the end user to decide. I was inspired by this: http://250bpm.com/blog:12 > (As a minor side note, calls like getsockopt will never return EINTR, > it's not necessary to retry them. But it doesn't hurt.) > zmq_getsockopt can return EINTR says the man page. And some zmq functions can return EINTR even though their man page doesn't mention 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/cbfe48d1-5af8-409a-8d73-87e99f04f1f1%40googlegroups.com.
Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor: > > On Thu, Feb 27, 2020 at 9:41 AM Robert Engels > wrote: > > > > > > I re-read your comments, and I agree that a rare error is still and > error, and needs to be handled, but if it the platform is introducing lots > of errors, is that the library writers issue? > > > > Maybe an easy solution is a flag to disable the signal usage for > tight-loop preemption as a "backwards compatibility" mode ? > > > > As the OP pointed out, he can't really change ZeroMQ, and this is a > fairly established product, maybe more so than Go, so doesn't it make more > sense that Go adapts rather than the other way around? > > We already have that flag: GODEBUG=noasyncpreempt=1. > > The discussion upthread explains that the Go wrapper for ZeroMQ should > handle EINTR, and take the appropriate action such as retrying the > operation when appropriate. The response to that was a bit of > distraction, as it discussed generic problems with EINTR. At this > point there is no reason to assume that any of those problems actually > apply to using ZeroMQ. > Yes, a lot is said about handling EINTR. Nothing is said about the code just freezing. How to handle that? -- 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/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com.
Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
That leaves the problem that often, the program just waits forever in C code, not returning an interrupted system call. Op woensdag 26 februari 2020 16:14:38 UTC+1 schreef Ian Lance Taylor: > > On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo > wrote: > > > > On Wednesday, February 26, 2020 at 3:51:54 PM UTC+1, Peter Kleiweg > wrote: > >> > >> Op woensdag 26 februari 2020 13:05:40 UTC+1 schreef Manlio Perillo: > >>> > >>> On Wednesday, February 26, 2020 at 12:33:05 PM UTC+1, Peter Kleiweg > wrote: > >>>> > >>>> With Go version 1.14 I get a lot of errors when I run: > >>>> > >>>> go test -v github.com/pebbe/zmq4 > >>>> > >>>> I didn't see this with Go 1.13.8 or any earlier version. > >>>> > >>>> Is this a problem with Go 1.14, or am I doing something wrong and > just got lucky until now? > >>>> > >>>> How do I debug this? The errors are different for each run. Below is > a sample of some errors. > >>>> Line numbers are not always accurate, because I inserted some calls > to test.Log(). > >>> > >>> > >>> The errors are probably caused by > https://golang.org/doc/go1.14#runtime. > >>> > >>> The solution is to update zmq4 to explicitly handle interrupted > system calls. > >> > >> > >> Often the program freezes before I get an interrupted system call. It > hangs inside a ZeroMQ C++ library function. > >> zmq4 is just a wrapper for ZeroMQ. I can't "fix" ZeroMQ to make it work > with Go. > >> > >> Is there a way to stop Go from interrupting my system calls? It happens > rather randomly all over the place. > > > > > > > https://stackoverflow.com/questions/36040547/zeromq-how-to-react-on-different-signal-types-on-eintr > > > > > ZeroMQ may return an EINTR error , but zmq4 does not list it in > errors.go. > > ZeroMQ asks the caller to handle EINTR, so zmq4 should handle it > internally or return it to the caller. > > > > https://golang.org/doc/go1.14#runtime should have mentioned that not > only programs that use packages like syscall or golang.org/x/sys/unix > will see more slow system calls fail with EINTR errors, but also programs > that use Cgo. > > I don't know ZeroMQ. If the ZeroMQ calls correspond closely to system > calls, then it could work for them to return EINTR. In that case the > fix is going to be for the Go wrapper around ZeroMQ to check whether > the error returned is syscall.EINTR, and to retry the call if it is. > > 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/aab5e1f7-c3ad-42b6-9806-395c3b14cdee%40googlegroups.com.
[go-nuts] How do you get an update for the tip of a package?
I try to install a Go program from github at tip. This works: go get github.com/some/program@HEAD But when there is a new push to the repository, and I do this: go get -u github.com/some/program@HEAD ... I still have the previous version. The same with go install. The same when I run this first: go clean -cache -modcache -- 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/7f488c2f-9144-40ac-b810-e05acb7807f6n%40googlegroups.com.
[go-nuts] Re: Go 1.16 is released
`go get` is broken. It doesn't download packages. Op dinsdag 16 februari 2021 om 20:56:37 UTC+1 schreef Alex Rakoczy: > Hello gophers, > > We just released Go 1.16 > > To find out what has changed in Go 1.16, read the release notes: > https://golang.org/doc/go1.16 > > You can download binary and source distributions from our download page: > https://golang.org/dl/ > > If you have Go installed already, an easy way to try go1.16 > is by using the go command: > $ go get golang.org/dl/go1.16 > $ go1.16 download > > To compile from source using a Git clone, update to the release with > "git checkout go1.16" and build as usual. > > Thanks to everyone who contributed to the release! > > Cheers, > Alex and Dmitri for the Go Team > -- 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/040e8124-7675-4767-9348-90ab88908ac8n%40googlegroups.com.
[go-nuts] Re: go get not working in Go 1.16
Op dinsdag 16 februari 2021 om 21:40:52 UTC+1 schreef Ian Lance Taylor: > On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg wrote: > > > > `go get` is broken. It doesn't download packages. > > Tell us what you did, what you expected to happen, and what happened > instead. Thanks. > > Note that module support is now on by default > (https://golang.org/doc/go1.16#go-command), which can affect the > behavior of "go get". > > Ian Ah, modules are the culprit. When I set `GO111MODULE=auto` everything works as it should. Without `GO111MODULE=auto` : - `go get` doesn't download to $GOPATH/src - `go build` doesn't work with packages in `$GOPATH/src` This means you can't use packages that need modification to an unusual environment. Also, you can't use local packages without a dot in the name. So why would you ever want to *not* set `GO111MODULE=auto` ? -- 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/44245bab-e577-4490-b5f4-02c465a5fae5n%40googlegroups.com.
[go-nuts] How do you test an unpublished module?
Suppose I am writing a package that is in its own module, and I want to test it. Not with unit tests, but with a larger program that uses other non-standard packages as well. Before modules, I would develop the package in ~/go/src, write the test program somewhere else, and import the package. This doesn't work with modules. What does work is move the test program into a subdirectory of the package, add that directory to .gitignore . This works, as long as the test program doesn't need any non-standard packages that the package I am writing needs. When the test program needs more non-standard packages, I need to add these to go.mod of the package I am developing, even though that package itself doesn't need it. When I give the directory with the test program its own go.mod then it can't use the files in the parent directory as the imported package. I turned it the other way around. I put the package I am writing in a subdirectory of the test program. That works, as long as that subdirectory doesn't have its own go.mod . So, in one setup, I end up with a package with a go.mod with too many dependencies. An in the other I end up with a package without a go.mod . How do I get this right? Is there a way to tell go.mod that it should use local files instead of a repository, just for the development phase? -- 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/5390153a-0c05-436e-888f-9ab911d75bf8n%40googlegroups.com.
Re: [go-nuts] How do you test an unpublished module?
Reading https://github.com/rogpeppe/gohack en trying some things, I found that you *can* tell go.mod that it should use local files instead of a repository. I have a test program outside my `~/go` tree with a `go.mod` like this: ``` module peter.nl/tester go 1.16 replace github.com/pebbe/package => /home/peter/go/src/github.com/pebbe/package ``` Then I run this: ``` go get github.com/pebbe/package ``` Now I can build and run the test program, and when I change anything locally in `/home/peter/go/src/github.com/pebbe/package` and build the test program again, it reflects the changes made in the package. This is exactly what I need. Op zaterdag 20 februari 2021 om 13:45:15 UTC+1 schreef ohir: > Dnia 2021-02-20, o godz. 04:10:38 > Peter Kleiweg napisał(a): > > > Suppose I am writing a package that is in its own module, and I want > > to test it. Not with unit tests, but with a larger program that uses > > other non-standard packages as well. > [...] > > How do I get this right? > > > > Is there a way to tell go.mod that it should use local files instead > > of a repository, just for the development phase? > > No. You can not replace *files*. You can use workaround with > briliant hack of https://github.com/rogpeppe/gohack > > Other hack is to have two or more modules you want to tinker with > vendored simultaneously to "all interested parties". This can be achieved > in Linux as shared mount, on other OS it need to be exact copy. > It is tedious but works. > > Look at https://github.com/golang/go/issues/27542#issue-357818109 and > https://github.com/golang/go/issues/37755 to get hints about other hacks > people conceived to be able to work on interdependent code. > > 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/529fd74b-aad4-4f93-ae19-df9e0a37723dn%40googlegroups.com.
