Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Michael Jones]

Ian, I guess not. I’d not thought of that indirectness. I withdraw my
musings.

On Wed, Feb 26, 2020 at 8:36 PM Robert Engels  wrote:

> The problem is that Go designers are taking the position that any sys call
> should be able to be interrupted. This is invalid. For the vast majority or
> “unix” os an interrupt is a very rare condition and so they treat it as an
> error. If you issue interrupts continually you are creating an unexpected
> context.
>
> > On Feb 26, 2020, at 8:39 PM, Ian Lance Taylor  wrote:
> >
> > On Wed, Feb 26, 2020 at 5:51 PM Michael Jones 
> wrote:
> >>
> >> Sorry...I meant the go system signal interface could loop if desired.
> (Not recommending, just saying that panicky people could be coddled if
> desired)
> >
> > Ah, I see.  Except, no, I don't.  Could we really do that?  Even if
> > the signal arrived while executing some function written in C and
> > called via cgo?
> >
> > Ian
> >
> >
> >>> On Wed, Feb 26, 2020 at 5:48 PM Ian Lance Taylor 
> wrote:
> >>>
> >>> On Wed, Feb 26, 2020 at 5:42 PM Michael Jones 
> wrote:
> 
>  There is the BSD notion of sa_restart, a convenience to loop for the
> caller as appropriate.
> 
>  https://www.freebsd.org/cgi/man.cgi?query=sigaction
> 
>  Go could adopt such a notion if desired.
> >>>
> >>> We already do.  We install all signal handlers with the SA_RESTART
> flag set.
> >>>
> >>> Unfortunately if you peruse "man 7 signal" on a GNU/Linux system you
> >>> will see a list of system calls that return EINTR even if the handler
> >>> has SA_RESTART set.
> >>>
> >>> Ian
> >>>
>  On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor 
> wrote:
> >
> > On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo <
> manlio.peri...@gmail.com> wrote:
> >>
> >> On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance
> Taylor wrote:
> >>>
> >>> On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo <
> manlio...@gmail.com> 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.
> >>>
> >>
> >> Unfortunately it is not that simple:
> >>
> >> http://250bpm.com/blog:12
> >> https://alobbs.com/post/54503240599/close-and-eintr
> >> http://man7.org/linux/man-pages/man7/signal.7.html
> >> https://github.com/golang/go/issues/11180
> >> https://www.python.org/dev/peps/pep-0475/
> >>
> >> The second entry about close and EINTR is enlightening.
> >
> > Thanks for the links.  Note that these issues don't really have
> > anything to do with Go.  For certain system calls, you need to handle
> > EINTR one way or another.  The Go runtime does as much as it 

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Robert Engels]

The problem is that Go designers are taking the position that any sys call 
should be able to be interrupted. This is invalid. For the vast majority or 
“unix” os an interrupt is a very rare condition and so they treat it as an 
error. If you issue interrupts continually you are creating an unexpected 
context. 

> On Feb 26, 2020, at 8:39 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Feb 26, 2020 at 5:51 PM Michael Jones  
> wrote:
>> 
>> Sorry...I meant the go system signal interface could loop if desired. (Not 
>> recommending, just saying that panicky people could be coddled if desired)
> 
> Ah, I see.  Except, no, I don't.  Could we really do that?  Even if
> the signal arrived while executing some function written in C and
> called via cgo?
> 
> Ian
> 
> 
>>> On Wed, Feb 26, 2020 at 5:48 PM Ian Lance Taylor  wrote:
>>> 
>>> On Wed, Feb 26, 2020 at 5:42 PM Michael Jones  
>>> wrote:
 
 There is the BSD notion of sa_restart, a convenience to loop for the 
 caller as appropriate.
 
 https://www.freebsd.org/cgi/man.cgi?query=sigaction
 
 Go could adopt such a notion if desired.
>>> 
>>> We already do.  We install all signal handlers with the SA_RESTART flag set.
>>> 
>>> Unfortunately if you peruse "man 7 signal" on a GNU/Linux system you
>>> will see a list of system calls that return EINTR even if the handler
>>> has SA_RESTART set.
>>> 
>>> Ian
>>> 
 On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor  wrote:
> 
> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo  
> wrote:
>> 
>> On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor 
>> wrote:
>>> 
>>> 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.
>>> 
>> 
>> Unfortunately it is not that simple:
>> 
>> http://250bpm.com/blog:12
>> https://alobbs.com/post/54503240599/close-and-eintr
>> http://man7.org/linux/man-pages/man7/signal.7.html
>> https://github.com/golang/go/issues/11180
>> https://www.python.org/dev/peps/pep-0475/
>> 
>> The second entry about close and EINTR is enlightening.
> 
> Thanks for the links.  Note that these issues don't really have
> anything to do with Go.  For certain system calls, you need to handle
> EINTR one way or another.  The Go runtime does as much as it can to
> avoid these problems, but on Unix systems it is impossible to avoid
> them entirely.
> 
> Ian
> 
> --
> You received this message because you are 

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Wed, Feb 26, 2020 at 5:51 PM Michael Jones  wrote:
>
> Sorry...I meant the go system signal interface could loop if desired. (Not 
> recommending, just saying that panicky people could be coddled if desired)

Ah, I see.  Except, no, I don't.  Could we really do that?  Even if
the signal arrived while executing some function written in C and
called via cgo?

Ian


> On Wed, Feb 26, 2020 at 5:48 PM Ian Lance Taylor  wrote:
>>
>> On Wed, Feb 26, 2020 at 5:42 PM Michael Jones  
>> wrote:
>> >
>> > There is the BSD notion of sa_restart, a convenience to loop for the 
>> > caller as appropriate.
>> >
>> > https://www.freebsd.org/cgi/man.cgi?query=sigaction
>> >
>> > Go could adopt such a notion if desired.
>>
>> We already do.  We install all signal handlers with the SA_RESTART flag set.
>>
>> Unfortunately if you peruse "man 7 signal" on a GNU/Linux system you
>> will see a list of system calls that return EINTR even if the handler
>> has SA_RESTART set.
>>
>> Ian
>>
>> > On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor  wrote:
>> >>
>> >> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo  
>> >> wrote:
>> >> >
>> >> > On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor 
>> >> > wrote:
>> >> >>
>> >> >> 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.
>> >> >>
>> >> >
>> >> > Unfortunately it is not that simple:
>> >> >
>> >> > http://250bpm.com/blog:12
>> >> > https://alobbs.com/post/54503240599/close-and-eintr
>> >> > http://man7.org/linux/man-pages/man7/signal.7.html
>> >> > https://github.com/golang/go/issues/11180
>> >> > https://www.python.org/dev/peps/pep-0475/
>> >> >
>> >> > The second entry about close and EINTR is enlightening.
>> >>
>> >> Thanks for the links.  Note that these issues don't really have
>> >> anything to do with Go.  For certain system calls, you need to handle
>> >> EINTR one way or another.  The Go runtime does as much as it can to
>> >> avoid these problems, but on Unix systems it is impossible to avoid
>> >> them entirely.
>> >>
>> >> 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 
>> >> 

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Michael Jones]

Sorry...I meant the go system signal interface could loop if desired. (Not
recommending, just saying that panicky people could be coddled if desired)

On Wed, Feb 26, 2020 at 5:48 PM Ian Lance Taylor  wrote:

> On Wed, Feb 26, 2020 at 5:42 PM Michael Jones 
> wrote:
> >
> > There is the BSD notion of sa_restart, a convenience to loop for the
> caller as appropriate.
> >
> > https://www.freebsd.org/cgi/man.cgi?query=sigaction
> >
> > Go could adopt such a notion if desired.
>
> We already do.  We install all signal handlers with the SA_RESTART flag
> set.
>
> Unfortunately if you peruse "man 7 signal" on a GNU/Linux system you
> will see a list of system calls that return EINTR even if the handler
> has SA_RESTART set.
>
> Ian
>
> > On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor 
> wrote:
> >>
> >> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo <
> manlio.peri...@gmail.com> wrote:
> >> >
> >> > On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor
> wrote:
> >> >>
> >> >> 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.
> >> >>
> >> >
> >> > Unfortunately it is not that simple:
> >> >
> >> > http://250bpm.com/blog:12
> >> > https://alobbs.com/post/54503240599/close-and-eintr
> >> > http://man7.org/linux/man-pages/man7/signal.7.html
> >> > https://github.com/golang/go/issues/11180
> >> > https://www.python.org/dev/peps/pep-0475/
> >> >
> >> > The second entry about close and EINTR is enlightening.
> >>
> >> Thanks for the links.  Note that these issues don't really have
> >> anything to do with Go.  For certain system calls, you need to handle
> >> EINTR one way or another.  The Go runtime does as much as it can to
> >> avoid these problems, but on Unix systems it is impossible to avoid
> >> them entirely.
> >>
> >> 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/CAOyqgcXGcdfpPAz8t8adfqGodKPjZNxKzkTUyB0b4L1zysVFSQ%40mail.gmail.com
> .
> >
> >
> >
> > --
> > Michael T. Jones
> > michael.jo...@gmail.com
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Wed, Feb 26, 2020 at 5:42 PM Michael Jones  wrote:
>
> There is the BSD notion of sa_restart, a convenience to loop for the caller 
> as appropriate.
>
> https://www.freebsd.org/cgi/man.cgi?query=sigaction
>
> Go could adopt such a notion if desired.

We already do.  We install all signal handlers with the SA_RESTART flag set.

Unfortunately if you peruse "man 7 signal" on a GNU/Linux system you
will see a list of system calls that return EINTR even if the handler
has SA_RESTART set.

Ian

> On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor  wrote:
>>
>> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo  
>> wrote:
>> >
>> > On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor 
>> > wrote:
>> >>
>> >> 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.
>> >>
>> >
>> > Unfortunately it is not that simple:
>> >
>> > http://250bpm.com/blog:12
>> > https://alobbs.com/post/54503240599/close-and-eintr
>> > http://man7.org/linux/man-pages/man7/signal.7.html
>> > https://github.com/golang/go/issues/11180
>> > https://www.python.org/dev/peps/pep-0475/
>> >
>> > The second entry about close and EINTR is enlightening.
>>
>> Thanks for the links.  Note that these issues don't really have
>> anything to do with Go.  For certain system calls, you need to handle
>> EINTR one way or another.  The Go runtime does as much as it can to
>> avoid these problems, but on Unix systems it is impossible to avoid
>> them entirely.
>>
>> 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/CAOyqgcXGcdfpPAz8t8adfqGodKPjZNxKzkTUyB0b4L1zysVFSQ%40mail.gmail.com.
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUow4D2o-pcZ6J4%3DAnrv9HD0Qcx_cs4e_rgjCeBSbasaw%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Michael Jones]

There is the BSD notion of sa_restart, a convenience to loop for the caller
as appropriate.

https://www.freebsd.org/cgi/man.cgi?query=sigaction

Go could adopt such a notion if desired.

On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor  wrote:

> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo 
> wrote:
> >
> > On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor
> wrote:
> >>
> >> 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.
> >>
> >
> > Unfortunately it is not that simple:
> >
> > http://250bpm.com/blog:12
> > https://alobbs.com/post/54503240599/close-and-eintr
> > http://man7.org/linux/man-pages/man7/signal.7.html
> > https://github.com/golang/go/issues/11180
> > https://www.python.org/dev/peps/pep-0475/
> >
> > The second entry about close and EINTR is enlightening.
>
> Thanks for the links.  Note that these issues don't really have
> anything to do with Go.  For certain system calls, you need to handle
> EINTR one way or another.  The Go runtime does as much as it can to
> avoid these problems, but on Unix systems it is impossible to avoid
> them entirely.
>
> 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/CAOyqgcXGcdfpPAz8t8adfqGodKPjZNxKzkTUyB0b4L1zysVFSQ%40mail.gmail.com
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQzADfr-DxiAMkPN8JGpPiFux8tJX%2Bf2vB6E-HLMe%2Bsmuw%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Ian Lance Taylor]

On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo  wrote:
>
> On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor wrote:
>>
>> 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.
>>
>
> Unfortunately it is not that simple:
>
> http://250bpm.com/blog:12
> https://alobbs.com/post/54503240599/close-and-eintr
> http://man7.org/linux/man-pages/man7/signal.7.html
> https://github.com/golang/go/issues/11180
> https://www.python.org/dev/peps/pep-0475/
>
> The second entry about close and EINTR is enlightening.

Thanks for the links.  Note that these issues don't really have
anything to do with Go.  For certain system calls, you need to handle
EINTR one way or another.  The Go runtime does as much as it can to
avoid these problems, but on Unix systems it is impossible to avoid
them entirely.

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/CAOyqgcXGcdfpPAz8t8adfqGodKPjZNxKzkTUyB0b4L1zysVFSQ%40mail.gmail.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Doug Clark]

Thanks for the follow up Eric. Your experience with the concurrency 
primitives lines up with my experience porting projects from various 
languages into Go. The ability to maintain exceptionally low cognitive 
overhead when adding concurrency is pretty amazing.

On an unrelated note, if in the future you find yourself converting more 
projects and need the advanced regexp features you can use this regexp 
implementation: https://github.com/dlclark/regexp2
It's closer to what you're used to with Python (or C#, or Javascript, etc), 
but those advanced features do have a cost that shouldn't be entered into 
lightly.

- Doug


On Friday, February 21, 2020 at 11:08:53 AM UTC-6, Eric Raymond wrote:
>
> This is a belated addition to my notes on the Go translation of 
> reposurgeon. I'll be adding it to the revised version I post to golang-dev.
>
> One extremely positive thing I must say before closing.  Translation from 
> Python, which is a dreadful language to try to do concurrency in due to its 
> global interpreter lock, really brought home to me how unobtrusively 
> brilliant the Go implementation of Communicating Sequential Processes is.  
> The primitives are right and the integration with the rest of the language 
> is wonderfully seamless.  The Go port of reposurgeon got some very large 
> speedups at an incremental-complexity cost that I found to be astonishingly 
> low.  I am impressed both by the power of the CSP part of the design and 
> the extreme simplicity and non-fussiness of the interface it presents.  I 
> hope it will become a model for how concurrency is managed in future 
> languages.
>
>
>

-- 
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/0113e65f-c809-476b-a9b4-c0ab4830134f%40googlegroups.com.

Re: [go-nuts] godoc-static - Generate static documentation for your packages

[tslocum]

I've had some time to polish this project somewhat. It should be fairly 
usable.

I've added ZIP archive generation to allow browsing offline without godoc.

Any additional feedback is welcome.

On Monday, February 10, 2020 at 8:22:51 AM UTC-8, Trevor Slocum wrote:
>
> Hey Nick, I did consider that and hope to still visit it.  I chose to 
> scrape instead because the output requires only minimal alteration to 
> achieve the desired result. Example code expansion is rewritten to not 
> require JavaScript by using  and  and not much more.  
> Large changes to output from the godoc tool can certainly break 
> godoc-static in its current state.  Assistance with exploring generating 
> similar output without using godoc would be appreciated.
>
>
> On Monday, February 10, 2020 at 7:14:51 AM UTC-8, Nick wrote:
>>
>> Quoth tsl...@gmail.com: 
>> > Inspired by the recent news of godoc.org shutting down I have created 
>> > godoc-static.  While we could all migrate to pkg.go.dev 
>> ,
>>  
>> we could also host and 
>> > update our documentation ourselves. 
>>
>> Cool, sounds interesting, I like the idea of more tools to make more 
>> distributed hosting of go stuff easier! 
>>
>> > When invoked, "godoc -http=localhost:" is started, relevant package 
>> > documentation pages and source code is scraped and rewritten to fix 
>> styling, 
>> > expanding content, etc., then godoc is terminated. 
>>
>> Interesting approach. Did you consider taking the code that godoc 
>> uses (either direct copying or including it somehow) and generating 
>> the HTML directly? I can imagine that might not be straightforward, 
>> but I'm interested to hear why you chose this approach instead.   
>> Without having looked at the code, I would imagine it would be more 
>> liable to break with future versions of godoc which change the 
>> output. 
>>
>> Anyway, good job, I may use it myself soon, and will let you know 
>> how I get on. 
>>
>> Nick 
>>
>

-- 
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/68e59b93-511d-466b-ab7b-4038d3d85df0%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[pboampong5]

How should I handle EINTR from syscall.Dup2 (Linux)?

- The effect of SA_RESTART on dup2(2) is undocumented.
- If dup2 returns EINTR, can I be sure that nothing has been done? (Otherwise 
retrying is racy.)
- libuv uv__dup2_cloexec [1] never retries the syscall but treats EINTR as a 
failure.
- Python os.dup2 [2] also never retries, but it seems that it treats EINTR as 
success ("ignores EINTR error").
- See also unresolved question: 
https://stackoverflow.com/questions/15930013/can-dup2-really-return-eintr

All very confusing.
Also, can os.File.Close / syscall.Close return EINTR? Is it affected by 
SA_RESTART?

[1] https://github.com/libuv/libuv/issues/462
[2] https://www.python.org/dev/peps/pep-0475

-- 
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/9c8cc343-48f0-4f14-9e32-9b14647bacd0%40googlegroups.com.

[go-nuts] RegexWriter - not sure if there's something equivalent out there

[tim . dufrane]

Hi all,

Needed a writer that would let me take actions based on input but didn't 
want much fuss, wrote a thing: https://github.com/timdufrane/regexwriter/. 
I'm no good at this "Github" stuff or this "good code" stuff but this did 
the trick for my use case and maybe it can help someone else. I'm open to 
suggestions for improvements, or a heads up if there's something built-in 
or out there already that does this better. Thanks!

-- 
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/faa7b968-cb48-4719-8041-1b57f23f7416%40googlegroups.com.

[go-nuts] Re: Modules and cross-compilation

[Manlio Perillo]

On Wednesday, February 26, 2020 at 8:53:52 PM UTC+1, geoff.j...@gmail.com 
wrote:
>
> Hello.
>
>
> > [...]
>
>
>
> So:
>
>1. 
>
>I don’t understand why go build foo.com/foobar fails to find the 
>module if it doesn’t contain some top-level .go file, but go list -m 
>finds it perfectly fine.
>
>
This fails with GOPATH mode, too:
can't load package: package foo.com/foobar: no Go files in 
.../foo.com/foobar

The problem is that the error message is incorrect/confusing.
I have tested with go1.14 and it is even more confusing:
can't load package: cannot find module providing package 
github.com/perillo/gocmd: invalid github.com/ import path 
"github.com/perillo"

>
>1. 
>
>[How] can I have a module X that provides packages X/Y and X/Z, with 
>no source files in the top-level package X? Or am I not supposed to do 
>this under Go modules?
>
>
Of course you can work with it.
Just do go build -o build. ./...
Note that this will fail if there are no main packages in the main module.

When cross compiling you can create a Makefile or shell script, that do:
mkdir -p build/$GOOS-$GOARCH
go build -o build/$GOOS-$GOARCH/ ./...


   1. 
   
   Go modules appear to break my assumption that “I just set GOOS and/or 
   GOARCH to cross-compile, and everything else just works”. The is (was?) 
   one of the biggest benefits of Go for me. I need to cross-compile for Linux 
   (ARM, AArch64 and AMD64) and Windows (AMD64) all the time.
   

I have to admit that I never noticed that go build installed executables in 
$GOBIN/$GOOS-$GOARCH.  I don't know the reason for the change.

> [...]

Manlio 

-- 
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/b452b48e-cf25-482e-941a-897cf23834c4%40googlegroups.com.

[go-nuts] Re: Modules and cross-compilation

[Volker Dobler]

On Wednesday, 26 February 2020 20:53:52 UTC+1, geoff.j...@gmail.com wrote:
>
> This baffles me:
>
>
> $ go build foo.com/foobar
> can't load package: package foo.com/foobar: cannot find module providing 
> package foo.com/foobar
>
>
You simply cannot build a module. Only packages can be built.
and there is no package at the root of your module. Try
   cd cmd/foo; go build
or go build foo.com/foobar/cmd/foo
 

> $ head -1 go.mod
> module foo.com/foobar
>
> $ go list -m foo.com/foobar # but this finds it perfectly well?
>
> Yes. You are asking questions about a module and this
question is answered.
 

> although this seems to work:
>
>
> $ GOBIN=/some/path go install ./...$ find /some/path -type 
> f/some/path/foo/some/path/bar
>
> Well sure. Asked to build every package and that was done.
 

> [... larger rant on the tooling ...]
>
 

> So:
>
>1. 
>
>I don’t understand why go build foo.com/foobar fails to find the 
>module if it doesn’t contain some top-level .go file, but go list -m 
>finds it perfectly fine.
>
> The error message clearly is suboptimal and I think there is
an issue already for that. Just pick it up and fix it.
Note that what you asked the go tool to do is not
something it can do. The go tool operates on packages
during build, install, test, etc. and not on modules.
 

>
>1. 
>
>[How] can I have a module X that provides packages X/Y and X/Z, with 
>no source files in the top-level package X? Or am I not supposed to do 
>this under Go modules?
>
> Just like you did. Everything works just fine, you just
cannot ask the go tool to build or install the module.
You noticed that module stuff works properly without
*.go files in the module root.
Remember: A  module is a collection of packages versioned
together and their dependencies.

>
>1. 
>
>Go modules appear to break my assumption that “I just set GOOS and/or 
>GOARCH to cross-compile, and everything else just works”. The is 
>(was?) one of the biggest benefits of Go for me. I need to cross-compile 
>for Linux (ARM, AArch64 and AMD64) and Windows (AMD64) all the time.
>
> I do not see how modules infer with cross-compilation.
I doubt you could set GOBIN in GOPATH mode either

>
>1. 
>
>Cross-compiled go install to some non-global output directory worked 
>fine in GOPATH days: creating $GOPATH/bin/$GOOS-$GOARCH/*, which 
>seemed perfectly sensible to me. I don’t understand why it’s broken under 
>modules, particularly when I set GOBIN, which I take to mean “Put the 
>binaries here please: I know what I’m doing; please don’t argue”. Or at 
>least have some sort of -yes-really flag to stop the toolchain arguing.
>
> You should probably address this on the issue tracker.
 

>
>
> At the moment I can see two solutions:
>
>1. 
>
>Split up my project into individual modules for the shared code (or 
>even every package therein), and each executable. Since none of those 
>components, in this context, makes sense individually, this seems like the 
>tail wagging the dog.
>2. 
>
>Revert to using GOPATH and hope that it never gets removed. History 
>teaches me that this is unwise.
>
> but I can’t help thinking that I’m doing something fundamentally wrong. 
> I’ve read the docs, help pages, Wiki et cetera, and found nothing that has 
> helped me. Can someone please put me right?
>

I do not see why doing a simple mkdir before running go install
would be a no-go. It might take a handful of more commands
to crosscompile multiple executables from a module but nothing
rocket science. If typing these command annoys you: put the in 
a shell script.

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/8d6b726a-fa19-4ee9-8143-7603233d0ccc%40googlegroups.com.

Re: [go-nuts] Cross compiling with CGO without having a C compiler for each target platform

[Ian Lance Taylor]

On Wed, Feb 26, 2020 at 7:07 AM Jan Flyborg  wrote:
>
> We are building a system that targets many different combinations of OS's and 
> architectures.
>
> Up until now we have been able to keep the whole code base and external 
> packages in pure Go (no CGO), which means that the cross compiler 
> functionality of GC has been sufficient for us.
>
> However, recently we have introduced a dependency to an SQLite library 
> (https://github.com/mattn/go-sqlite3) which needs CGO and I want to avoid 
> having each developer to install C compilers for all combinations, so I'm 
> investigating if it would be possible to simplify this process.
>
> So let's say I am running Linux/AMD64 on my PC and that my colleague is using 
> a Windows machine. Could I build the CGO part on my machine as an archive 
> file and then ship this archive to my colleagues machine in order to make it 
> possible for him to change GOOS and GOARCH to Linux/AMD64 and thereby 
> enabling him to cross compile (with "go build") for this architecture 
> (without having a C compiler for Linux/AMD64 available)?
>
> Is this possible or do we always have to have a C-toolchain available on the 
> machine where we perform the cross compilation?

You can build the cgo part on your machine and use ld -r to turn the
archive into a single object.  Then you can the object
x_linux_amd64.syso, x_windows_amd64.syso, etc., and distribute those
files.  That will let your users skip the C compilation.  They can set
CGO_ENABLED=0 to skip building the file that does import "C".

But this technique will only work for simple objects that can be
handled by the Go linker in internal linking mode.  It will not work
for C++ code.

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/CAOyqgcWK8_UyAdGQDCs63%3DASSK%2BNcuZLTT8tyWSkJ7CYVaQRdA%40mail.gmail.com.

Re: [go-nuts] Cross compiling with CGO without having a C compiler for each target platform

[Sebastien Binet]

On Wed, Feb 26, 2020 at 6:34 PM Robert Engels  wrote:

> Depending on your use of SQLite there are a few pure Go libraries that
> might simplify things.
>

such as:
- https://github.com/go-sqlite/sqlite3 (incomplete)
- https://github.com/alicebob/sqlittle (much more complete)

(I am the original author of the first one)

-s


>
> On Feb 26, 2020, at 9:11 AM, Jan Flyborg  wrote:
>
> 
> We are building a system that targets many different combinations of OS's
> and architectures.
>
> Up until now we have been able to keep the whole code base and external
> packages in pure Go (no CGO), which means that the cross compiler
> functionality of GC has been sufficient for us.
>
> However, recently we have introduced a dependency to an SQLite library (
> https://github.com/mattn/go-sqlite3) which needs CGO and I want to avoid
> having each developer to install C compilers for all combinations, so I'm
> investigating if it would be possible to simplify this process.
>
> So let's say I am running Linux/AMD64 on my PC and that my colleague is
> using a Windows machine. Could I build the CGO part on my machine as an
> archive file and then ship this archive to my colleagues machine in order
> to make it possible for him to change GOOS and GOARCH to Linux/AMD64 and
> thereby enabling him to cross compile (with "go build") for this
> architecture (without having a C compiler for Linux/AMD64 available)?
>
> Is this possible or do we always have to have a C-toolchain available on
> the machine where we perform the cross compilation?
>
> Best Regards
> //Jan Flyborg
>
> --
> 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/660a29f0-7dc9-43c6-ad46-6dd26ff5146e%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/32008098-4891-44DB-AE42-94507F049379%40ix.netcom.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAAV3P_AgQEgSEYcm-vP6q2fkg47wULmZxOpED5McAEr%3DvBVRaA%40mail.gmail.com.

[go-nuts] Modules and cross-compilation

[geoff . johnstone]

Hello.


I’m getting rather confused by Go modules and cross-compilation. I think 
that I have fundamentally misunderstood some module-related concept in the 
way that I’ve structured my project.


Scenario: My project consists of some individual executables that share 
some common code. The project is (or should be) a coherent, self-contained 
whole: the executables don’t make much sense individually, and I want to 
work on / version the supporting code and executables together.


In GOPATH times I had something like:


 $ find . -type f 
./src/cmd/foo/main.go
 
./src/cmd/bar/main.go
 ./src/qux/qux.go 
 
$ cat 
src/qux/qux.go 
package qux 
 
const Qux = `qux` 
 
$ 
src/cmd/foo/main.go # bar/main.go is essentially the same 
package main 
 
import "qux" 
 
func main() { 

println(`foo: ` + qux.Qux) 
}



and the following works as expected, following my understanding that 
cross-compilation just means setting GOOS and/or GOARCH:


 $ uname -sm 
Darwin x86_64 
 
$ GOPATH=$PWD go 
install ./... $ 
GOOS=linux GOARCH=arm GOPATH=$PWD go install ./... 
 
$ find bin -type 
f 
bin/linux_arm/foo 
bin/linux_arm/bar 
bin/foo 
bin/bar



I’ve tried to migrate this to modules. At a logical level, these binaries 
plus support code are one unit: if Go doesn’t require me to spread them 
across separate modules then I’d rather not.


First I removed the src directory, then added a go.mod:


 $ find . -type f 
./cmd/foo/main.go 
./cmd/bar/main.go 
./qux/qux.go 
 
$ go mod init 
foo.com/foobar



This baffles me:


$ go build foo.com/foobar
can't load package: package foo.com/foobar: cannot find module providing 
package foo.com/foobar


$ head -1 go.mod
module foo.com/foobar


$ go list -m foo.com/foobar # but this finds it perfectly well?


although this seems to work:


 $ 
GOBIN=/some/path go install ./... 
$ find /some/path 
-type f 
/some/path/foo 
/some/path/bar



But: now I want to cross-compile:


 $ GOOS=linux 
GOBIN=/some/path go install ./... 
go install: 
cannot install cross-compiled binaries when GOBIN is set 
go install: 
cannot install cross-compiled binaries when GOBIN is set


(Why not? If I set GOBIN then I’m saying “please put the binaries over 
there”. I know that I don’t want them appearing on my Mac’s $PATH: that’s 
what I’m setting GOBIN. I want to cross-compile some binaries and have them 
appear in some suitable output directory, so that I can then put them into 
some disk image or whatever. In any case, if this runs in CI then, 
cross-compilation or not, I don’t want them appear on the CI box’s PATH at 
all.)



The Internet says that I should use go build instead of go install, and use 
-o to write the results somewhere:


 $ GOOS=linux go 
build -o /some/path ./... 
go build: cannot 
write multiple packages to non-directory /some/path


This seems to work, but I’ve never had to create the output directory 
before, and it doesn't do the handy creation of per-OS/ARCH subdirectories 
for me:


 $ mkdir /tmp/bin 
$ GOOS=linux go 
build -o /some/path ./...



So:

   1. 
   
   I don’t understand why go build foo.com/foobar fails to find the module 
   if it doesn’t contain some top-level .go file, but go list -m finds it 
   perfectly fine.
   2. 
   
   [How] can I have a module X that provides packages X/Y and X/Z, with no 
   source files in the top-level package X? Or am I not supposed to do this 
   under Go modules?
   3. 
   
   Go modules appear to break my assumption that “I just set GOOS and/or 
   GOARCH to cross-compile, and everything else just works”. The is (was?) 
   one of the biggest benefits of Go for me. I need to cross-compile for Linux 
   (ARM, AArch64 and AMD64) and Windows (AMD64) all the time.
   4. 
   
   Cross-compiled go install to some non-global output directory worked 
   fine in GOPATH days: creating $GOPATH/bin/$GOOS-$GOARCH/*, which seemed 
   perfectly sensible to me. I don’t understand why it’s broken under modules, 
   particularly when I set GOBIN, which I take to mean “Put the binaries 
   here please: I know what I’m doing; please don’t argue”. Or at least have 
   some sort of -yes-really flag to stop the toolchain arguing.
   
At the moment I can see two solutions:

   1. 
   
   Split up my project into individual modules for the shared code (or even 
   every package therein), and each executable. Since none of those 
   components, in this context, makes sense individually, this seems like the 
   tail wagging the dog.
   2. 
   
   Revert to using GOPATH and hope that it never gets removed. History 
   teaches me that this is unwise.
   
but I can’t help thinking that I’m doing something fundamentally wrong. 
I’ve read the docs, help pages, Wiki et cetera, and found nothing that has 
helped me. Can someone please put me right?


Many thanks,

Geoff.


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

[go-nuts] Re: SIGILL running 1.14 on macOS

[James Pettyjohn]

Looks like this was already resolved for 1.14.1 
.

On Wednesday, February 26, 2020 at 11:00:24 AM UTC-8, James Pettyjohn wrote:
>
> A little further digging shows that VZEROUPPER is part of the AVX 
> instruction set, not supported on any Apple computers prior to 2011 from 
> what I can tell.
>
> Given the rc1 code worked fine, that could be an alternative for Darwin 
> where the CPU does not support AVX. While not ideal, I'd argue it's better 
> than cutting off support for these machines which can run High Sierra. Once 
> support for High Sierra is dropped then it should not matter as it takes a 
> 2013 or later model to run anything after High Sierra.
>
> - James
>
>
>
> On Wednesday, February 26, 2020 at 10:29:33 AM UTC-8, James Pettyjohn 
> wrote:
>>
>> I am trying to run go1.14 on macOS 10.13.2 with on a late 2009 iMac with 
>> an i7 but always get the same crash:
>>
>>
>> SIGILL: illegal instruction
>> PC=0x1066040 m=0 sigcode=1
>>
>>
>> goroutine 1 [running, locked to thread]:
>> runtime.asyncPreempt()
>> /usr/local/go/src/runtime/preempt_amd64.s:8 fp=0xc58ef0 sp=
>> 0xc58ee8 pc=0x1066040
>> fmt.init()
>> /usr/local/go/src/fmt/scan.go:465 fp=0xc58ef8 sp=0xc58ef0 
>> pc=0x10e6540
>> runtime.doInit(0x1a80520)
>> /usr/local/go/src/runtime/proc.go:5414 +0x8a fp=0xc58f28 sp=
>> 0xc58ef8 pc=0x1043aca
>> runtime.doInit(0x1a80ec0)
>> /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc58f58 sp=
>> 0xc58f28 pc=0x1043a97
>> runtime.doInit(0x1a850c0)
>> /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc58f88 sp=
>> 0xc58f58 pc=0x1043a97
>> runtime.main()
>> /usr/local/go/src/runtime/proc.go:190 +0x1ce fp=0xc58fe0 sp=
>> 0xc58f88 pc=0x103702e
>> runtime.goexit()
>> /usr/local/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc58fe8 
>> sp=0xc58fe0 pc=0x10647d1
>>
>>
>> rax0x1a80520
>> rbx0xb
>> rcx0x0
>> rdx0x1a80578
>> rdi0xcb2020
>> rsi0x10e6540
>> rbp0xc58f18
>> rsp0xc58ee8
>> r8 0x3277901
>> r9 0x203000
>> r100x8
>> r110x55
>> r120x1
>> r130x55
>> r140x171acac
>> r150x38
>> rip0x1066040
>> rflags 0x10202
>> cs 0x2b
>> fs 0x0
>> gs 0x0
>>
>>
>> Which appears to be a call to VZEROUPPER in preempt_amd64.s 
>> 
>> .
>>
>> This was not the case in rc1, which runs just fine. I get the same 
>> results from installing it with brew, .pkg and .tgz installs - have done 
>> the install from source yet.
>>
>> Any tips would be appreciated.
>>
>

-- 
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/ebfc97e6-bf43-46cc-bfbd-cbe4b756353d%40googlegroups.com.

[go-nuts] Re: SIGILL running 1.14 on macOS

[James Pettyjohn]

A little further digging shows that VZEROUPPER is part of the AVX 
instruction set, not supported on any Apple computers prior to 2011 from 
what I can tell.

Given the rc1 code worked fine, that could be an alternative for Darwin 
where the CPU does not support AVX. While not ideal, I'd argue it's better 
than cutting off support for these machines which can run High Sierra. Once 
support for High Sierra is dropped then it should not matter as it takes a 
2013 or later model to run anything after High Sierra.

- James



On Wednesday, February 26, 2020 at 10:29:33 AM UTC-8, James Pettyjohn wrote:
>
> I am trying to run go1.14 on macOS 10.13.2 with on a late 2009 iMac with 
> an i7 but always get the same crash:
>
>
> SIGILL: illegal instruction
> PC=0x1066040 m=0 sigcode=1
>
>
> goroutine 1 [running, locked to thread]:
> runtime.asyncPreempt()
> /usr/local/go/src/runtime/preempt_amd64.s:8 fp=0xc58ef0 sp=
> 0xc58ee8 pc=0x1066040
> fmt.init()
> /usr/local/go/src/fmt/scan.go:465 fp=0xc58ef8 sp=0xc58ef0 
> pc=0x10e6540
> runtime.doInit(0x1a80520)
> /usr/local/go/src/runtime/proc.go:5414 +0x8a fp=0xc58f28 sp=
> 0xc58ef8 pc=0x1043aca
> runtime.doInit(0x1a80ec0)
> /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc58f58 sp=
> 0xc58f28 pc=0x1043a97
> runtime.doInit(0x1a850c0)
> /usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc58f88 sp=
> 0xc58f58 pc=0x1043a97
> runtime.main()
> /usr/local/go/src/runtime/proc.go:190 +0x1ce fp=0xc58fe0 sp=
> 0xc58f88 pc=0x103702e
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc58fe8 sp
> =0xc58fe0 pc=0x10647d1
>
>
> rax0x1a80520
> rbx0xb
> rcx0x0
> rdx0x1a80578
> rdi0xcb2020
> rsi0x10e6540
> rbp0xc58f18
> rsp0xc58ee8
> r8 0x3277901
> r9 0x203000
> r100x8
> r110x55
> r120x1
> r130x55
> r140x171acac
> r150x38
> rip0x1066040
> rflags 0x10202
> cs 0x2b
> fs 0x0
> gs 0x0
>
>
> Which appears to be a call to VZEROUPPER in preempt_amd64.s 
> .
>
> This was not the case in rc1, which runs just fine. I get the same results 
> from installing it with brew, .pkg and .tgz installs - have done the 
> install from source yet.
>
> Any tips would be appreciated.
>

-- 
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/3ca625a5-c45e-4f05-92f9-36e3e61ff739%40googlegroups.com.

[go-nuts] SIGILL running 1.14 on macOS

[James Pettyjohn]

I am trying to run go1.14 on macOS 10.13.2 with on a late 2009 iMac with an 
i7 but always get the same crash:


SIGILL: illegal instruction
PC=0x1066040 m=0 sigcode=1


goroutine 1 [running, locked to thread]:
runtime.asyncPreempt()
/usr/local/go/src/runtime/preempt_amd64.s:8 fp=0xc58ef0 sp=
0xc58ee8 pc=0x1066040
fmt.init()
/usr/local/go/src/fmt/scan.go:465 fp=0xc58ef8 sp=0xc58ef0 pc
=0x10e6540
runtime.doInit(0x1a80520)
/usr/local/go/src/runtime/proc.go:5414 +0x8a fp=0xc58f28 sp=
0xc58ef8 pc=0x1043aca
runtime.doInit(0x1a80ec0)
/usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc58f58 sp=
0xc58f28 pc=0x1043a97
runtime.doInit(0x1a850c0)
/usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc58f88 sp=
0xc58f58 pc=0x1043a97
runtime.main()
/usr/local/go/src/runtime/proc.go:190 +0x1ce fp=0xc58fe0 sp=
0xc58f88 pc=0x103702e
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc58fe8 sp=
0xc58fe0 pc=0x10647d1


rax0x1a80520
rbx0xb
rcx0x0
rdx0x1a80578
rdi0xcb2020
rsi0x10e6540
rbp0xc58f18
rsp0xc58ee8
r8 0x3277901
r9 0x203000
r100x8
r110x55
r120x1
r130x55
r140x171acac
r150x38
rip0x1066040
rflags 0x10202
cs 0x2b
fs 0x0
gs 0x0


Which appears to be a call to VZEROUPPER in preempt_amd64.s 
.

This was not the case in rc1, which runs just fine. I get the same results 
from installing it with brew, .pkg and .tgz installs - have done the 
install from source yet.

Any tips would be appreciated.

-- 
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/5fa8d757-9f5a-474c-9ae1-79deaff08d0a%40googlegroups.com.

[go-nuts] Re: Go 1.14 is released

[HaWe]

> Both pages were moved to the x/website repository 
 
so 
they could be kept up to date outside the 6-month release cycle.

Thank you, this helps.
(I'm using git diff and I'm trying to keep a bunch of german translations 
up-to-date: https://bitloeffel.de/DOC/golang/install_de.html ... not yet 
ready for Go 1.14.)

-- 
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/9500fd21-ad21-4f56-87b6-7c72db129c58%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Robert Engels]

It is especially difficult when the driver has complex timing and/or hardware 
flags. Interrupting these calls usually lead to unretriable failures. 

> On Feb 26, 2020, at 11:41 AM, Peter Kleiweg  wrote:
> 
> 
> 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.

-- 
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/96273FB7-6926-41E7-8038-FAF21DB784CB%40ix.netcom.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Peter Kleiweg]

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.

Re: [go-nuts] Cross compiling with CGO without having a C compiler for each target platform

[Robert Engels]

Depending on your use of SQLite there are a few pure Go libraries that might 
simplify things. 

> On Feb 26, 2020, at 9:11 AM, Jan Flyborg  wrote:
> 
> 
> We are building a system that targets many different combinations of OS's and 
> architectures.
> 
> Up until now we have been able to keep the whole code base and external 
> packages in pure Go (no CGO), which means that the cross compiler 
> functionality of GC has been sufficient for us.
> 
> However, recently we have introduced a dependency to an SQLite library 
> (https://github.com/mattn/go-sqlite3) which needs CGO and I want to avoid 
> having each developer to install C compilers for all combinations, so I'm 
> investigating if it would be possible to simplify this process.
> 
> So let's say I am running Linux/AMD64 on my PC and that my colleague is using 
> a Windows machine. Could I build the CGO part on my machine as an archive 
> file and then ship this archive to my colleagues machine in order to make it 
> possible for him to change GOOS and GOARCH to Linux/AMD64 and thereby 
> enabling him to cross compile (with "go build") for this architecture 
> (without having a C compiler for Linux/AMD64 available)?
> 
> Is this possible or do we always have to have a C-toolchain available on the 
> machine where we perform the cross compilation?
> 
> Best Regards
> //Jan Flyborg
> 
> -- 
> 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/660a29f0-7dc9-43c6-ad46-6dd26ff5146e%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/32008098-4891-44DB-AE42-94507F049379%40ix.netcom.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Amnon Baron Cohen]

from https://www.jwz.org/doc/worse-is-better.html

Two famous people, one from MIT and another from Berkeley (but working on 
Unix) once met to discuss operating system issues. The person from MIT was 
knowledgeable about ITS (the MIT AI Lab operating system) and had been 
reading the Unix sources. He was interested in how Unix solved the PC 
loser-ing problem. 

The PC loser-ing problem occurs when a user program invokes a system 
routine to perform a lengthy operation that might have significant state, 
such as IO buffers. If an interrupt occurs during the operation, the state 
of the user program must be saved. Because the invocation of the system 
routine is usually a single instruction, the PC of the user program does 
not adequately capture the state of the process. The system routine must 
either back out or press forward. The right thing is to back out and 
restore the user program PC to the instruction that invoked the system 
routine so that resumption of the user program after the interrupt, for 
example, re-enters the system routine. It is called ``PC loser-ing'' 
because the PC is being coerced into ``loser mode,'' where ``loser'' is the 
affectionate name for ``user'' at MIT.


The MIT guy did not see any code that handled this case and asked the New 
Jersey guy how the problem was handled. The New Jersey guy said that the 
Unix folks were aware of the problem, but the solution was for the system 
routine to always finish, but sometimes an error code would be returned 
that signaled that the system routine had failed to complete its action. A 
correct user program, then, had to check the error code to determine 
whether to simply try the system routine again. The MIT guy did not like 
this solution because it was not the right thing.


The New Jersey guy said that the Unix solution was right because the design 
philosophy of Unix was simplicity and that the right thing was too complex. 
Besides, programmers could easily insert this extra test and loop. The MIT 
guy pointed out that the implementation was simple but the interface to the 
functionality was complex. The New Jersey guy said that the right tradeoff 
has been selected in Unix-namely, implementation simplicity was more 
important than interface simplicity.


On Wednesday, 26 February 2020 17:10:48 UTC, Manlio Perillo wrote:
>
> On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor 
> wrote:
>>
>> 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. 
>>
>>
> Unfortunately it is not that simple:
>
> http://250bpm.com/blog:12
> https://alobbs.com/post/54503240599/close-and-eintr
> http://man7.org/linux/man-pages/man7/signal.7.html
> https://github.com/golang/go/issues/11180
> https://www.python.org/dev/peps/pep-0475/
>
> 

[go-nuts] Re: Fuchsia Programming Language Policy

[David Skinner]

I quite understand their critic.

   - GC sometimes causes me problems that result in me writing part of my 
   code in C++ or ASM. But over the last 10 years the GC seems to be mostly 
   improving and that is rarely a problem for me.
   - I used to write engineering, accounting, and legal apps that ran on 4k 
   RAM on dual tape drives. Go is a real memory hog. But memory is cheap and 
   plentiful and my time has value and Go lets me be three times as productive 
   as C++.
   - I have written some real dog programs in Go, my son Daniel had to 
   profile, clean up, refactor, and get things to where it was faster, used 
   less memory and did not suffer delays. Just because Go is easy to use does 
   not mean that novices can always create high-quality code using Go.

I understand why they would make this decision for their use case but I do 
think that they are somewhat short-sighted and flawed in thinking only 
about certain specific details that can easily be overcome with profiling, 
optimization, and additional programmer training. Using Go may seem easy 
but after using it for ten years, I find that I am still learning how to 
use the language, but the investment of time is yielding very real 
dividends. If you want instant gratification and gotta have it now, then 
maybe Go is not your best choice, it is more of a long term investment.

On Tuesday, February 25, 2020 at 11:22:11 AM UTC-6, Jon Conradt wrote:
>
> The Fuchsia Programming Language Policy 
> 
>  gives 
> some insight into the experience the Fuchsia team has had with Go, and it 
> doesn't sound good.
>
> "The Fuchsia Platform Source Tree has had negative implementation 
> experience using Go. The system components the Fuchsia project has built in 
> Go have used more memory and kernel resources than their counterparts (or 
> replacements) the Fuchsia project has built using C++ or Rust."
>
>
> The Fuchsia Platform Source tree is defined as "The *Fuchsia Platform 
> Source Tree* is the source code hosted on fuchsia.googlesource.com."
>
> Their conclusion, and each language has some issues is pretty severe.
>
>- Go is not approved, with the following exceptions:
>   - *netstack*. Migrating netstack to another language would require 
>   a significant investment. In the fullness of time, we should migrate 
>   netstack to an approved language.
>- All other uses of Go in Fuchsia for production software on the 
>target device must be migrated to an approved language.
>
>  That's a shame. I was hoping that Fuchsia would provide a way for Go to 
> have a nice GUI.
>
> Two of the issues listed as cons include the toolchain producing 'large 
> binaries' and the related issue of their being a 'substantial runtime.' It 
> seems to me that both of these issues can be addressed through some of the 
> techniques used to build tiny Docker images from Go, but I suspect they 
> would like to have a much simpler route, e.g. a go build flag.
>
> Jon
>

-- 
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/2aa45252-c340-48ca-a464-03e0208b73c4%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Manlio Perillo]

On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor wrote:
>
> 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. 
>
>
Unfortunately it is not that simple:

http://250bpm.com/blog:12
https://alobbs.com/post/54503240599/close-and-eintr
http://man7.org/linux/man-pages/man7/signal.7.html
https://github.com/golang/go/issues/11180
https://www.python.org/dev/peps/pep-0475/

The second entry about close and EINTR is enlightening.


Manlio 

-- 
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/f28d8228-a5b0-4385-8cff-a86f54fb4f62%40googlegroups.com.

Re: [go-nuts] Re: Go 1.14 is released

['Jay Conrod' via golang-nuts]

Both pages were moved to the x/website repository

so
they could be kept up to date outside the 6-month release cycle.

On Wed, Feb 26, 2020 at 7:33 AM HaWe  wrote:

> Firts of all, many thanks for a great new release.
>
> Now my question:
> The (new) document "How to Write Go Code" is available at
> golang.org/doc/code.html, the older version, now named "How to Write Go
> Code (with GOPATH)" at golang.org/doc/gopath_code.html.
> But they seem to be no longer part of the Git repository.
>
> Is this deliberate?
>
> --
> 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/70d888f4-ea86-49ef-9815-6b02dc26a883%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/CAGCADbZqZLvTmg%2BYNLdy-LK61zn41vqiNyuCvUoL7NSHqrw%2B%2BQ%40mail.gmail.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[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/CAOyqgcUGT0eeZxknAd-L2FVRavh6XNYchrUw8WeW7CnmySVFnw%40mail.gmail.com.

[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Manlio Perillo]

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.


Manlio

-- 
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/e876fe34-651a-46f8-b891-9f84c340bf30%40googlegroups.com.

Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Gregor Best]

This looks like fallout of the 1.14 changes that made Goroutines 
preemptively schedulable.


It seems likely that this code hasn't worked before either, just that 
the failure cases were masked because less signals got delivered (and 
thus had less chance of interrupting system calls).


On 26.02.20 12:34, Peter Kleiweg wrote:

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 
.


--
--
  Gregor Best
  b...@pferdewetten.de

--
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/09df487b-31c2-11a5-4195-1968fb5a7f8e%40pferdewetten.de.

[go-nuts] Cross compiling with CGO without having a C compiler for each target platform

[Jan Flyborg]

We are building a system that targets many different combinations of OS's 
and architectures.

Up until now we have been able to keep the whole code base and external 
packages in pure Go (no CGO), which means that the cross compiler 
functionality of GC has been sufficient for us.

However, recently we have introduced a dependency to an SQLite library 
(https://github.com/mattn/go-sqlite3) which needs CGO and I want to avoid 
having each developer to install C compilers for all combinations, so I'm 
investigating if it would be possible to simplify this process.

So let's say I am running Linux/AMD64 on my PC and that my colleague is 
using a Windows machine. Could I build the CGO part on my machine as an 
archive file and then ship this archive to my colleagues machine in order 
to make it possible for him to change GOOS and GOARCH to Linux/AMD64 and 
thereby enabling him to cross compile (with "go build") for this 
architecture (without having a C compiler for Linux/AMD64 available)?

Is this possible or do we always have to have a C-toolchain available on 
the machine where we perform the cross compilation?

Best Regards
//Jan Flyborg

-- 
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/660a29f0-7dc9-43c6-ad46-6dd26ff5146e%40googlegroups.com.

[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Peter Kleiweg]

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.

[go-nuts] Re: Why isn't there strings.reverse("str") function?

[ffm2002]

Maybe the implementation in Java is something you could steal to save time. 
Have a look into class StringBuilder where there is a reverse() method. It 
does the reversion differently depending on whether dealing with UTF16 or 
not.

Am Samstag, 15. Februar 2020 17:37:15 UTC+1 schrieb Amarjeet Anand:
>
> Hi
>
> I was wondering why isn't there built-in string reverse function. Is it 
> left intentionally because of some reason?
>
> Although strings are immutable in go, there are multiple ways to achieve 
> this pretty easily. But having this function inbuilt will save our time 
> because we need it quite often.
>
>
>

-- 
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/934265f6-666b-446b-aa5e-73f0b2bdcd78%40googlegroups.com.

Re: [go-nuts] Understind how to apply timeout using gouritine

[Brian Candler]

Perhaps slightly clearer:
https://play.golang.org/p/DDZxqaEFi-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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/35b396a3-04ab-4bab-acee-d7cd186e519c%40googlegroups.com.

Re: [go-nuts] Understind how to apply timeout using gouritine

[Brian Candler]

>
> My previous questions were: How can I cancel execution of goToSleep() 
> function?  How can I break it?
>
>
Maybe you want something like this?
https://play.golang.org/p/2dKbVMxBjaJ

context  is the standard way to be able to 
cancel one or more of goroutines, such as those working together to handle 
a particular request.  The goroutines need to cooperate with this 
mechanism, by noticing that the cancellation signal has been sent and then 
finishing. This is done inside interruptibleSleep in the above example. 
Many library functions now accept a context so that they can be terminated 
in this way.

Also, if the point of this is to give up after a timeout, the context 
itself can carry a deadline, which simplifies things:
https://play.golang.org/p/TPJYrCcnq8c

-- 
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/46f94c36-c632-4e08-859e-61171c4381b8%40googlegroups.com.

[go-nuts] Re: Go 1.14 is released

[HaWe]

Firts of all, many thanks for a great new release.

Now my question:
The (new) document "How to Write Go Code" is available at 
golang.org/doc/code.html, the older version, now named "How to Write Go 
Code (with GOPATH)" at golang.org/doc/gopath_code.html.
But they seem to be no longer part of the Git repository.

Is this deliberate?

-- 
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/70d888f4-ea86-49ef-9815-6b02dc26a883%40googlegroups.com.

Re: [go-nuts] Understind how to apply timeout using gouritine

[Jake Montgomery]

The code you posted above never actually called goToSleep(), because the 
'strings ' channel was nil. Could you post a playground link to the new 
code that you are running below?


On Tuesday, February 25, 2020 at 8:38:27 PM UTC-5, Juan Mamani wrote:
>
> Ok, you are right.  But I was confused with this:
>
> 2009/11/10 23:00:00 -Start
> 2009/11/10 23:00:00 Sleeping  8 seconds..2009/11/10 23:00:03 Canceling doWork 
> goroutine reach 3s...2009/11/10 23:00:08 Done sleeping!
> 2009/11/10 23:00:08 doWork exited.
> 2009/11/10 23:00:08 Done.
> 2009/11/10 23:00:08 -End
> My previous questions were: How can I cancel execution ofv function?  How can 
> I break it? Because I expect  code to stop function gotoTosleep()  at 3s, but 
> I saw still running at 8s because prints "Done sleeping!"..
>
> But Michael Levieux got the idea and repliedr:"You cannot terminate a 
> function execution from its caller.." .  So I was wrong in my understanding 
> how to implement "cancel" or "break" goroutinea.
>
>
> El martes, 25 de febrero de 2020, 13:45:03 (UTC-3), Jake Montgomery 
> escribió:
>>
>> Expected behaviour is  to end  anonyimous func when  3s timeout is 
>>> reached.
>>>
>>
>> So what is the problem? The whole thing *does *exit after 3 seconds. Of 
>> course, your main() is a loop, so it starts again. 
>>
>> 2009/11/10 23:00:00 -Start
>> 2009/11/10 23:00:03 Canceling doWork goroutine reach 3s...
>> 2009/11/10 23:00:03 doWork exited.
>> 2009/11/10 23:00:03 Done.
>> 2009/11/10 23:00:03 -End
>>
>>
>> What exactly did you expect to see other than that?
>>
>> On Monday, February 24, 2020 at 6:45:26 PM UTC-5, Juan Mamani wrote:
>>>
>>> Sorry again.   Well, I followed your advice. Here is the link 
>>> https://play.golang.org/p/7DigEVsKbdx
>>> How can I cancel goToSleep() when timeout is reached?
>>>
>>>
>>> El lunes, 24 de febrero de 2020, 14:16:32 (UTC-3), Jake Montgomery 
>>> escribió:

 Your code will still not compile. In this group, it is often helpful to 
 include a link to your code in the playground (https://play.golang.org/) 
 using the "Share" button. That is in addition to, or instead of, posting 
 your code in the message. This will allow others to easily run your code, 
 but also will allow you to make sure it compiles. 

 On Monday, February 24, 2020 at 10:01:01 AM UTC-5, Juan Mamani wrote:
>
> Sorry}, here is the right code:  ( just was the effect to b working 
> til At 5:20am  sleepy and lost)
>
> Expected behaviour is  to end  anonyimous func when  3s timeout is 
> reached.
>
> //
> package main
>
> import(
> //"fmt"
> "time"
> "math/rand"
> "log"
> )
>
> func main(){
>
>  for{
>log.Println("-Start")
>Task()
>log.Println("-End")
>
>   }
>
> }
>
>
> // Trying to adapt from Concurrency in Go by Katherine Cox-Buday
> func Task(){
>
> doWork := func(  done <-chan interface{}, strings <-chan string, ) 
> <-chan interface{} { //1
> terminated := make(chan interface{})
> go func() {
> defer log.Println("doWork exited.")
> defer close(terminated)
> for {
> goToSleep()
> select {
>  //case s := <-strings:
>  // case s := ran():
> // Do something interesting
> //fmt.Println(s)
> case <-done: //2
> return
> }
> }
> }()
> return terminated
> }
>
> done := make(chan interface{})
> terminated := doWork(done, nil)
>
> go func() { //3
> // Cancel the operation after 3 second.
> time.Sleep(3 * time.Second)
> log.Println("Canceling doWork goroutine reach 3s...")
> close(done)
> }()
>
> <-terminated //4
> log.Println("Done.")
> }
>
> done := make(chan interface{})
> terminated := doWork(done, nil)
>
> go func() { //3
> // Cancel the operation after 3 second.
> time.Sleep(3 * time.Second)
> log.Println("Canceling doWork goroutine reach 3s...")
> close(done)
> }()
>
> <-terminated //4
> log.Println("Done.")
> }
>
>
>
> func goToSleep(){
>   
>   
>   
>   
>   
>
> rand.Seed(time.Now().UnixNano())
> n := rand.Intn(12) // n will be between 0 and 10
> log.Println("Sleeping ",n,"seconds..")
> time.Sleep(time.Duration(n)*time.Second)
> 

[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[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.
However it is strange that they happen in the tests.  Is this cause by 
SIPIPE?

> [...]


Manlio 

-- 
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/b584e5ae-fcd3-4eb5-80a2-863b534dcebd%40googlegroups.com.

[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

[Peter Kleiweg]

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

[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/745bfcea-2adf-44ce-bfd2-32bd4d2cf834%40googlegroups.com.

Re: [go-nuts] Re: [ANN] Renderview v0.1.0 with go mod, Gio, and Fyne support

[Elias Naur]

On Tue Feb 25, 2020 at 3:21 PM,  wrote:
> I worked it out, will update the programs later. It was not that the
> events
> were missing - once I enabled the good old Printf debugger, I saw that
> the
> events are flowing fine. The issue is that on Linux, every Move Mouse
> event
> reflected what buttons were pressed the entire time they were pressed.
> On
> Windows, only the Press Mouse event included a value for the Button that
> was pressed (i.e. pointer.ButtonLeft).
>

That's a bug, now fixed with


https://git.sr.ht/~eliasnaur/gio/commit/e3f8d1a1afb27213f5e4c2e0b161e76d69778ff3

Thanks for finding it!

-- elias

-- 
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/C0W07JWK2MY0.OTB79OIYI1FI%40testmac.