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

2020-02-27 Thread roger peppe 
On Thu, 27 Feb 2020 at 22:25, David Finkel  wrote:

>
>
> On Thu, Feb 27, 2020 at 1:52 PM roger peppe  wrote:
>
>> If you really just want to reverse rune-by-rune, it's pretty
>> straightforward:
>>
>> func Reverse(s string) string {
>> r := make([]byte, 0, len(s))
>> for len(s) > 0 {
>> _, n := utf8.DecodeLastRuneInString(s)
>> i := len(s) - n
>> r = append(r, s[i:]...)
>> s = s[:i]
>> }
>> return string(r)
>> }
>>
>> That will also deal correctly with invalid utf8 encoding - all the bytes
>> of the original string will be present in the result.
>>
>
> Another option with slightly less bookkeeping (but slightly more magic
> indices):
> https://play.golang.org/p/sfMLimbcHSj
>
> func reverse(str string) string {
>
> if len(str) == 0 {
>
> return ""
>
> }
>
> out := make([]byte, len(str))
> lastoffset := len(str)
> for offset, r := range str {
>
> rl := utf8.RuneLen(r)
>
> copy(out[lastoffset-rl:lastoffset], str[offset:offset+rl])
>
> lastoffset -= rl
>
> }
> return string(out)
>
> }
>

I'm afraid that doesn't work correctly in the face of invalid utf8.
https://play.golang.org/p/xH7zSY4vAbP

The reason is that when there's an invalid rune, only one byte is consumed,
but
the rune is '\uFFFD' (utf8.RuneError) which encodes as more than one byte.

That said, consuming from the start is quite likely a better approach as
I'm fairly
sure that `DecodeRune` will have received a great deal more optimisation
effort
than `DecodeLastRune` which looks like it hasn't changed much since I wrote
it
almost a decade ago :)

This does the job and does indeed seem to be somewhat (~10%) faster than
going backwards:

func Reverse(s string) string {
r := make([]byte, len(s))
i := len(r)
for {
_, n := utf8.DecodeRuneInString(s)
if n == 0 {
break
}
copy(r[i-n:], s[:n])
i -= n
s = s[n:]
}
return string(r)
}

  cheers,
rog.


>
>>
>> On Wed, 26 Feb 2020 at 14:20,  wrote:
>>
>>> 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
>>> 
>>> .
>>>
>> --
>> 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/CAJhgacjhm5TxaTgN3zwrKuD7YYBoXcpCitCuWeipqV_thhtYFQ%40mail.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/CAJhgachoWUTKuak%2Bhcgq812xx7pfF3btOJmG%2BeXxxqaJ0C%3D5jA%40mail.gmail.com.

Re: [go-nuts] What is the output of objdump?

2020-02-27 Thread wagner riffel 
On Thu, 27 Feb 2020 19:03:02 -0800 (PST)
bucha...@gmail.com wrote:

> Can someone please explain the columns printed by "go tool objdump"?
> instruction. I'm not sure what columns 2, 3, and 5 are.

Column $2 is the memory address offset, $3 is the entire instruction
encoded in hexadecimal, $5 is a continuation of $4, a disassembled
version of $3

> what the "TEXT %22%22.main(SB)
> gofile../Users/abuchanan/projects/gobuild/simple/ main.go" line is.

TEXT is a pseudo-operation to the "entry point" to the function,
%22%22.main(SB) is the function label itself.

You can find reference only here:
https://golang.org/doc/asm
https://9p.io/sys/doc/asm.html

—wagner

-- 
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/20200228021236.2cc4e759%40pampas.

[go-nuts] What is the output of objdump?

2020-02-27 Thread buchanae 
Can someone please explain the columns printed by "go tool objdump"?

For example:

TEXT %22%22.main(SB) gofile../Users/abuchanan/projects/gobuild/simple/main.
go
  main.go:30x2db65488b0c25MOVQ GS:0, CX 
   [5:9]R_TLS_LE
  main.go:30x2e4483b6110CMPQ 0x10(CX), SP
  main.go:30x2e8763bJBE 0x325
  main.go:30x2ea4883ec18SUBQ $0x18, SP
  main.go:30x2ee48896c2410MOVQ BP, 0x10(SP)
  main.go:30x2f3488d6c2410LEAQ 0x10(SP), BP
  main.go:40x2f8e8CALL 0x2fd[1:5
]R_CALL:runtime.printlock
  main.go:40x2fd488d05LEAQ 0(IP), AX   
 [3:7]R_PCREL:go.string."main"
  main.go:40x30448890424MOVQ AX, 0(SP)
  main.go:40x30848c74424080400MOVQ $0x4, 0x8(SP)
  main.go:40x311e8CALL 0x316[1:5
]R_CALL:runtime.printstring
  main.go:40x316e8CALL 0x31b[1:5
]R_CALL:runtime.printunlock
  main.go:50x31b488b6c2410MOVQ 0x10(SP), BP
  main.go:50x3204883c418ADDQ $0x18, SP
  main.go:50x324c3RET
  main.go:30x325e8CALL 0x32a[1:5
]R_CALL:runtime.morestack_noctxt
  main.go:30x32aebafJMP %22%22.main(SB)

Column 1 is the source file + line. Column 4 is the machine code 
instruction. I'm not sure what columns 2, 3, and 5 are. Also not sure what 
the "TEXT %22%22.main(SB) gofile../Users/abuchanan/projects/gobuild/simple/
main.go" line is.

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/a532e0fa-c219-46b9-8760-1aac9aaf0aca%40googlegroups.com.

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

2020-02-27 Thread Amnon Baron Cohen 
lol!

Where are you rob?
We miss you!

On Thursday, 27 February 2020 23:23:57 UTC, Rob 'Commander' Pike wrote:
>
> Once bytten, twice shy.
>
> -rob
>
>
> On Fri, Feb 28, 2020 at 10:17 AM Jesper Louis Andersen <
> jesper.lo...@gmail.com > wrote:
>
>> The key observation is that you only look at a byte once.
>>
>>
>>

-- 
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/d0ae98a8-357d-4c53-bb6c-7381d4a0e2a8%40googlegroups.com.

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

2020-02-27 Thread Rob Pike 
Once bytten, twice shy.

-rob


On Fri, Feb 28, 2020 at 10:17 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> The key observation is that you only look at a byte once.
>
> On Thu, Feb 27, 2020, 22:49 Amnon Baron Cohen  wrote:
>
>> You are right.
>> I had wrongly assumed that utf8.DecodeLastRuneInString has O(n) runtime.
>> But it has constant runtime as it reads at most 4 bytes at the end of the
>> string.
>>
>>
>> On Thursday, 27 February 2020 21:47:19 UTC, kortschak wrote:
>>>
>>> Why? There's a single correctly sized allocation made up front and then
>>> a linear time walk along the encoded runes with truncation after each
>>> rune.
>>>
>>> On Thu, 2020-02-27 at 13:05 -0800, Amnon Baron Cohen wrote:
>>> > O(n^2)
>>> >
>>> > On Thursday, 27 February 2020 18:53:01 UTC, rog wrote:
>>> > > If you really just want to reverse rune-by-rune, it's pretty
>>> > > straightforward:
>>> > >
>>> > > func Reverse(s string) string {
>>> > > r := make([]byte, 0, len(s))
>>> > > for len(s) > 0 {
>>> > > _, n := utf8.DecodeLastRuneInString(s)
>>> > > i := len(s) - n
>>> > > r = append(r, s[i:]...)
>>> > > s = s[:i]
>>> > > }
>>> > > return string(r)
>>> > > }
>>> > >
>>> > > That will also deal correctly with invalid utf8 encoding - all the
>>> > > bytes of the original string will be present in the result.
>>> > > >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it,
>>> > send an email to golan...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> >
>>> https://groups.google.com/d/msgid/golang-nuts/2333bc33-8740-4f8b-972e-37d2d60b9dc7%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/18eb08a5-f2be-452b-a31f-9643932fc4bd%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/CAGrdgiXMyCTZhNQniRmf9G3SUEqwZY%3D4exDCD7ZrEPUk8QJ5XQ%40mail.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/CAOXNBZQNja-C0M4PefgYNryp_eQW_PHPeEWo9tB-pGwwYR00Lw%40mail.gmail.com.

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

2020-02-27 Thread Jesper Louis Andersen 
The key observation is that you only look at a byte once.

On Thu, Feb 27, 2020, 22:49 Amnon Baron Cohen  wrote:

> You are right.
> I had wrongly assumed that utf8.DecodeLastRuneInString has O(n) runtime.
> But it has constant runtime as it reads at most 4 bytes at the end of the
> string.
>
>
> On Thursday, 27 February 2020 21:47:19 UTC, kortschak wrote:
>>
>> Why? There's a single correctly sized allocation made up front and then
>> a linear time walk along the encoded runes with truncation after each
>> rune.
>>
>> On Thu, 2020-02-27 at 13:05 -0800, Amnon Baron Cohen wrote:
>> > O(n^2)
>> >
>> > On Thursday, 27 February 2020 18:53:01 UTC, rog wrote:
>> > > If you really just want to reverse rune-by-rune, it's pretty
>> > > straightforward:
>> > >
>> > > func Reverse(s string) string {
>> > > r := make([]byte, 0, len(s))
>> > > for len(s) > 0 {
>> > > _, n := utf8.DecodeLastRuneInString(s)
>> > > i := len(s) - n
>> > > r = append(r, s[i:]...)
>> > > s = s[:i]
>> > > }
>> > > return string(r)
>> > > }
>> > >
>> > > That will also deal correctly with invalid utf8 encoding - all the
>> > > bytes of the original string will be present in the result.
>> > > >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it,
>> > send an email to golan...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/golang-nuts/2333bc33-8740-4f8b-972e-37d2d60b9dc7%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/18eb08a5-f2be-452b-a31f-9643932fc4bd%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/CAGrdgiXMyCTZhNQniRmf9G3SUEqwZY%3D4exDCD7ZrEPUk8QJ5XQ%40mail.gmail.com.

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

2020-02-27 Thread David Finkel 
On Thu, Feb 27, 2020 at 1:52 PM roger peppe  wrote:

> If you really just want to reverse rune-by-rune, it's pretty
> straightforward:
>
> func Reverse(s string) string {
> r := make([]byte, 0, len(s))
> for len(s) > 0 {
> _, n := utf8.DecodeLastRuneInString(s)
> i := len(s) - n
> r = append(r, s[i:]...)
> s = s[:i]
> }
> return string(r)
> }
>
> That will also deal correctly with invalid utf8 encoding - all the bytes
> of the original string will be present in the result.
>

Another option with slightly less bookkeeping (but slightly more magic
indices):
https://play.golang.org/p/sfMLimbcHSj

func reverse(str string) string {

if len(str) == 0 {

return ""

}

out := make([]byte, len(str))
lastoffset := len(str)
for offset, r := range str {

rl := utf8.RuneLen(r)

copy(out[lastoffset-rl:lastoffset], str[offset:offset+rl])

lastoffset -= rl

}
return string(out)

}

>
>
> On Wed, 26 Feb 2020 at 14:20,  wrote:
>
>> 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
>> 
>> .
>>
> --
> 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/CAJhgacjhm5TxaTgN3zwrKuD7YYBoXcpCitCuWeipqV_thhtYFQ%40mail.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/CANrC0BjVdtMuPoOiyfUrW4yTO-kfqsMFhp-bsDXLqOL1yQwwmw%40mail.gmail.com.

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

2020-02-27 Thread Elias Naur 
On Mon, Feb 24, 2020 at 9:36 AM Elias Naur  wrote:

>> For example, with Gio, I had to download a set of .DLL files and extract 
>> them into the root folder of my Go build, as documented on the Gio website.
>
>
> I happen to be working on a direct3d port of Gio which I hope to have ready 
> within this week, in which case the 3 opengl DLLs are no longer needed. You 
> can follow the work at https://git.sr.ht/~eliasnaur/gio/log/d3d11.
>

Direct3D is now done, which should eliminate the dependency on OpenGL
emulation DLLs.

-- 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/CAMAFT9XJKG3Oq0CCPHQVx6HGYnB%3D6Y5%2BdtrJWQyKRiFcRq-gSg%40mail.gmail.com.

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

2020-02-27 Thread Amnon Baron Cohen 
You are right.
I had wrongly assumed that utf8.DecodeLastRuneInString has O(n) runtime.
But it has constant runtime as it reads at most 4 bytes at the end of the 
string.


On Thursday, 27 February 2020 21:47:19 UTC, kortschak wrote:
>
> Why? There's a single correctly sized allocation made up front and then 
> a linear time walk along the encoded runes with truncation after each 
> rune. 
>
> On Thu, 2020-02-27 at 13:05 -0800, Amnon Baron Cohen wrote: 
> > O(n^2) 
> > 
> > On Thursday, 27 February 2020 18:53:01 UTC, rog wrote: 
> > > If you really just want to reverse rune-by-rune, it's pretty 
> > > straightforward: 
> > > 
> > > func Reverse(s string) string { 
> > > r := make([]byte, 0, len(s)) 
> > > for len(s) > 0 { 
> > > _, n := utf8.DecodeLastRuneInString(s) 
> > > i := len(s) - n 
> > > r = append(r, s[i:]...) 
> > > s = s[:i] 
> > > } 
> > > return string(r) 
> > > } 
> > > 
> > > That will also deal correctly with invalid utf8 encoding - all the 
> > > bytes of the original string will be present in the result. 
> > > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, 
> > send an email to golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/golang-nuts/2333bc33-8740-4f8b-972e-37d2d60b9dc7%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/18eb08a5-f2be-452b-a31f-9643932fc4bd%40googlegroups.com.

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

2020-02-27 Thread Dan Kortschak 
Why? There's a single correctly sized allocation made up front and then
a linear time walk along the encoded runes with truncation after each
rune.

On Thu, 2020-02-27 at 13:05 -0800, Amnon Baron Cohen wrote:
> O(n^2)
> 
> On Thursday, 27 February 2020 18:53:01 UTC, rog wrote:
> > If you really just want to reverse rune-by-rune, it's pretty
> > straightforward:
> > 
> > func Reverse(s string) string {
> > r := make([]byte, 0, len(s))
> > for len(s) > 0 {
> > _, n := utf8.DecodeLastRuneInString(s)
> > i := len(s) - n
> > r = append(r, s[i:]...)
> > s = s[:i]
> > }
> > return string(r)
> > }
> > 
> > That will also deal correctly with invalid utf8 encoding - all the
> > bytes of the original string will be present in the result.
> > > 
> 
> -- 
> 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/2333bc33-8740-4f8b-972e-37d2d60b9dc7%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/30f228360543d7f880c3702b20c5b74b553d8056.camel%40kortschak.io.

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

2020-02-27 Thread Robert Engels 
As Ian pointed out you need to use 

GODEBUG=asyncpreemptoff=1

> On Feb 27, 2020, at 2:26 PM, Peter Kleiweg  wrote:
> 
> 
> GODEBUG=noasyncpreempt=1 makes no difference.
> 
> I added the option -race and I got some warnings from that, all happening in 
> a call to reactor.Run().
> When I disable all tests that use reactor.Run() the test run no longer 
> freezes. So I have to look at
> the implementation of the reactor. 
> 
> I still get the interrupted system calls, so I have to fix those too.
> 
> It looks like these are two different issues.
> 
> 
> Op donderdag 27 februari 2020 19:07:54 UTC+1 schreef Robert Engels:
>> 
>> Does it freeze if you use GODEBUG=noasyncpreempt=1 ?
>> -Original Message- 
>> From: Peter Kleiweg 
>> Sent: Feb 27, 2020 11:59 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
>> version 1.14, no errors with earlier versions 
>> 
>> Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor:
>>> 
>>> On Thu, Feb 27, 2020 at 9:41 AM Robert Engels  wrote: 
>>> > 
>>> > 
>>> > I re-read your comments, and I agree that a rare error is still and 
>>> > error, and needs to be handled, but if it the platform is introducing 
>>> > lots of errors, is that the library writers issue? 
>>> > 
>>> > Maybe an easy solution is a flag to disable the signal usage for 
>>> > tight-loop preemption as a "backwards compatibility" mode ? 
>>> > 
>>> > As the OP pointed out, he can't really change ZeroMQ, and this is a 
>>> > fairly established product, maybe more so than Go, so doesn't it make 
>>> > more sense that Go adapts rather than the other way around? 
>>> 
>>> We already have that flag: GODEBUG=noasyncpreempt=1. 
>>> 
>>> The discussion upthread explains that the Go wrapper for ZeroMQ should 
>>> handle EINTR, and take the appropriate action such as retrying the 
>>> operation when appropriate.  The response to that was a bit of 
>>> distraction, as it discussed generic problems with EINTR.  At this 
>>> point there is no reason to assume that any of those problems actually 
>>> apply to using ZeroMQ. 
>> 
>> Yes, a lot is said about handling EINTR.
>> 
>> Nothing is said about the code just freezing. How to handle that?
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com.
>> 
>> 
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a95feca4-17f4-4a43-80c7-3adc76d0cabf%40googlegroups.com.

-- 
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/CCDAC624-1B54-4E5B-BE7D-9991C7BAE727%40ix.netcom.com.

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

2020-02-27 Thread Amnon Baron Cohen 
O(n^2)

On Thursday, 27 February 2020 18:53:01 UTC, rog wrote:
>
> If you really just want to reverse rune-by-rune, it's pretty 
> straightforward:
>
> func Reverse(s string) string {
> r := make([]byte, 0, len(s))
> for len(s) > 0 {
> _, n := utf8.DecodeLastRuneInString(s)
> i := len(s) - n
> r = append(r, s[i:]...)
> s = s[:i]
> }
> return string(r)
> }
>
> That will also deal correctly with invalid utf8 encoding - all the bytes 
> of the original string will be present in the result.
>
>>
>>
>>

-- 
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/2333bc33-8740-4f8b-972e-37d2d60b9dc7%40googlegroups.com.

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

2020-02-27 Thread Brian Candler 
The magic behind contexts is that they use a channel but without sending 
any data over it.  Instead, *closing* the channel is a signal to terminate.

This allows you to have multiple goroutines listening on the channel, and 
they will *all* receive the termination signal, as a broadcast.  (It 
wouldn't work if you sent an item of data on the channel: if you did that, 
then only one of the receivers would get it)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ebd00f1f-d384-457f-8ec8-bc09968d64f8%40googlegroups.com.

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

2020-02-27 Thread Peter Kleiweg 
GODEBUG=noasyncpreempt=1 makes no difference.

I added the option -race and I got some warnings from that, all happening 
in a call to reactor.Run().
When I disable all tests that use reactor.Run() the test run no longer 
freezes. So I have to look at
the implementation of the reactor. 

I still get the interrupted system calls, so I have to fix those too.

It looks like these are two different issues.


Op donderdag 27 februari 2020 19:07:54 UTC+1 schreef Robert Engels:
>
> Does it freeze if you use GODEBUG=noasyncpreempt=1 ?
>
> -Original Message- 
> From: Peter Kleiweg 
> Sent: Feb 27, 2020 11:59 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
> version 1.14, no errors with earlier versions 
>
> Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor:
>>
>> On Thu, Feb 27, 2020 at 9:41 AM Robert Engels  
>> wrote: 
>> > 
>> > 
>> > I re-read your comments, and I agree that a rare error is still and 
>> error, and needs to be handled, but if it the platform is introducing lots 
>> of errors, is that the library writers issue? 
>> > 
>> > Maybe an easy solution is a flag to disable the signal usage for 
>> tight-loop preemption as a "backwards compatibility" mode ? 
>> > 
>> > As the OP pointed out, he can't really change ZeroMQ, and this is a 
>> fairly established product, maybe more so than Go, so doesn't it make more 
>> sense that Go adapts rather than the other way around? 
>>
>> We already have that flag: GODEBUG=noasyncpreempt=1. 
>>
>> The discussion upthread explains that the Go wrapper for ZeroMQ should 
>> handle EINTR, and take the appropriate action such as retrying the 
>> operation when appropriate.  The response to that was a bit of 
>> distraction, as it discussed generic problems with EINTR.  At this 
>> point there is no reason to assume that any of those problems actually 
>> apply to using ZeroMQ. 
>>
>
> Yes, a lot is said about handling EINTR.
>
> Nothing is said about the code just freezing. How to handle that?
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com
>  
> 
> .
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a95feca4-17f4-4a43-80c7-3adc76d0cabf%40googlegroups.com.

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

2020-02-27 Thread Juan Mamani 
Hi Brian,

Thanks for your help.  I will try out  to implement your samples in my 
project.
But still studying Goroutines and now Context.



El miércoles, 26 de febrero de 2020, 10:41:26 (UTC-3), Brian Candler 
escribió:
>
> 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/9461a095-a8a5-4511-8436-e0f314817568%40googlegroups.com.

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

2020-02-27 Thread Ian Lance Taylor 
On Thu, Feb 27, 2020 at 10:07 AM Robert Engels  wrote:
>
> Does it freeze if you use GODEBUG=noasyncpreempt=1 ?

Sorry, I got it wrong earlier.  It's GODEBUG=asyncpreemptoff=1.

I can verify that the tests seem to pass with
GODEBUG=asyncpreemptoff=1, and hang without it.

I took a quick look at TestMultipleContexts, which sometimes freezes.
I haven't verified this but I think it's because the server is
failing, probably due to an EINTR error.  The server is reporting an
error on a channel, but the test carries on and only looks at the
channel at the end.  My guess is that since the server has failed the
test is hanging waiting for the server to respond.

Ian


> -Original Message-
> From: Peter Kleiweg
> Sent: Feb 27, 2020 11:59 AM
> To: golang-nuts
> Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
> version 1.14, no errors with earlier versions
>
> Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor:
>>
>> On Thu, Feb 27, 2020 at 9:41 AM Robert Engels  wrote:
>> >
>> >
>> > I re-read your comments, and I agree that a rare error is still and error, 
>> > and needs to be handled, but if it the platform is introducing lots of 
>> > errors, is that the library writers issue?
>> >
>> > Maybe an easy solution is a flag to disable the signal usage for 
>> > tight-loop preemption as a "backwards compatibility" mode ?
>> >
>> > As the OP pointed out, he can't really change ZeroMQ, and this is a fairly 
>> > established product, maybe more so than Go, so doesn't it make more sense 
>> > that Go adapts rather than the other way around?
>>
>> We already have that flag: GODEBUG=noasyncpreempt=1.
>>
>> The discussion upthread explains that the Go wrapper for ZeroMQ should
>> handle EINTR, and take the appropriate action such as retrying the
>> operation when appropriate.  The response to that was a bit of
>> distraction, as it discussed generic problems with EINTR.  At this
>> point there is no reason to assume that any of those problems actually
>> apply to using ZeroMQ.
>
>
> Yes, a lot is said about handling EINTR.
>
> Nothing is said about the code just freezing. How to handle that?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com.
>
>
>
>
> --
> 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/394898919.2193.1582826837964%40wamui-lucy.atl.sa.earthlink.net.

-- 
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/CAOyqgcUCb_bY21FsmnhFwkWt7Vb-5b%3DJDncgfgBdpz3RN_Fg9Q%40mail.gmail.com.

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

2020-02-27 Thread roger peppe 
If you really just want to reverse rune-by-rune, it's pretty
straightforward:

func Reverse(s string) string {
r := make([]byte, 0, len(s))
for len(s) > 0 {
_, n := utf8.DecodeLastRuneInString(s)
i := len(s) - n
r = append(r, s[i:]...)
s = s[:i]
}
return string(r)
}

That will also deal correctly with invalid utf8 encoding - all the bytes of
the original string will be present in the result.


On Wed, 26 Feb 2020 at 14:20,  wrote:

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

-- 
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/CAJhgacjhm5TxaTgN3zwrKuD7YYBoXcpCitCuWeipqV_thhtYFQ%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

2020-02-27 Thread Robert Engels 
Does it freeze if you use GODEBUG=noasyncpreempt=1 ?-Original Message-
From: Peter Kleiweg 
Sent: Feb 27, 2020 11:59 AM
To: golang-nuts 
Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor:On Thu, Feb 27, 2020 at 9:41 AM Robert Engels  wrote:
>
>
> I re-read your comments, and I agree that a rare error is still and error, and needs to be handled, but if it the platform is introducing lots of errors, is that the library writers issue?
>
> Maybe an easy solution is a flag to disable the signal usage for tight-loop preemption as a "backwards compatibility" mode ?
>
> As the OP pointed out, he can't really change ZeroMQ, and this is a fairly established product, maybe more so than Go, so doesn't it make more sense that Go adapts rather than the other way around?

We already have that flag: GODEBUG=noasyncpreempt=1.

The discussion upthread explains that the Go wrapper for ZeroMQ should
handle EINTR, and take the appropriate action such as retrying the
operation when appropriate.  The response to that was a bit of
distraction, as it discussed generic problems with EINTR.  At this
point there is no reason to assume that any of those problems actually
apply to using ZeroMQ.
Yes, a lot is said about handling EINTR.Nothing is said about the code just freezing. How to handle that?



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com.




-- 
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/394898919.2193.1582826837964%40wamui-lucy.atl.sa.earthlink.net.

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

2020-02-27 Thread Peter Kleiweg 
Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor:
>
> On Thu, Feb 27, 2020 at 9:41 AM Robert Engels  > wrote: 
> > 
> > 
> > I re-read your comments, and I agree that a rare error is still and 
> error, and needs to be handled, but if it the platform is introducing lots 
> of errors, is that the library writers issue? 
> > 
> > Maybe an easy solution is a flag to disable the signal usage for 
> tight-loop preemption as a "backwards compatibility" mode ? 
> > 
> > As the OP pointed out, he can't really change ZeroMQ, and this is a 
> fairly established product, maybe more so than Go, so doesn't it make more 
> sense that Go adapts rather than the other way around? 
>
> We already have that flag: GODEBUG=noasyncpreempt=1. 
>
> The discussion upthread explains that the Go wrapper for ZeroMQ should 
> handle EINTR, and take the appropriate action such as retrying the 
> operation when appropriate.  The response to that was a bit of 
> distraction, as it discussed generic problems with EINTR.  At this 
> point there is no reason to assume that any of those problems actually 
> apply to using ZeroMQ. 
>

Yes, a lot is said about handling EINTR.

Nothing is said about the code just freezing. How to handle that?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com.

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

2020-02-27 Thread Ian Lance Taylor 
On Thu, Feb 27, 2020 at 9:41 AM Robert Engels  wrote:
>
>
> I re-read your comments, and I agree that a rare error is still and error, 
> and needs to be handled, but if it the platform is introducing lots of 
> errors, is that the library writers issue?
>
> Maybe an easy solution is a flag to disable the signal usage for tight-loop 
> preemption as a "backwards compatibility" mode ?
>
> As the OP pointed out, he can't really change ZeroMQ, and this is a fairly 
> established product, maybe more so than Go, so doesn't it make more sense 
> that Go adapts rather than the other way around?

We already have that flag: GODEBUG=noasyncpreempt=1.

The discussion upthread explains that the Go wrapper for ZeroMQ should
handle EINTR, and take the appropriate action such as retrying the
operation when appropriate.  The response to that was a bit of
distraction, as it discussed generic problems with EINTR.  At this
point there is no reason to assume that any of those problems actually
apply to using ZeroMQ.

Ian



> -Original Message-
> >From: Ian Lance Taylor 
> >Sent: Feb 27, 2020 9:51 AM
> >To: Robert Engels 
> >Cc: Michael Jones , Manlio Perillo 
> >, golang-nuts 
> >Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
> >version 1.14, no errors with earlier versions
> >
> >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.
> >
> >You're right, I do disagree.  I don't think it's the Go developers who
> >are taking that position.  It's the Unix library developers.  While a
> >main program can make its own choices about signals, a library has to
> >consider the possibility that it will be included in a program that
> >uses signals.  A rare error is still an error.  Just because Go 1.14
> >interrupts system calls more often doesn't mean the system calls were
> >not interrupted.  And non-Go programs use signals too, e.g. SIGURG and
> >SIGIO.
> >
> >Ian
> >
> >
> >> > 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

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

2020-02-27 Thread Robert Engels 


I re-read your comments, and I agree that a rare error is still and error, and 
needs to be handled, but if it the platform is introducing lots of errors, is 
that the library writers issue?

Maybe an easy solution is a flag to disable the signal usage for tight-loop 
preemption as a "backwards compatibility" mode ?

As the OP pointed out, he can't really change ZeroMQ, and this is a fairly 
established product, maybe more so than Go, so doesn't it make more sense that 
Go adapts rather than the other way around?




-Original Message-
>From: Ian Lance Taylor 
>Sent: Feb 27, 2020 9:51 AM
>To: Robert Engels 
>Cc: Michael Jones , Manlio Perillo 
>, golang-nuts 
>Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
>version 1.14, no errors with earlier versions
>
>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.
>
>You're right, I do disagree.  I don't think it's the Go developers who
>are taking that position.  It's the Unix library developers.  While a
>main program can make its own choices about signals, a library has to
>consider the possibility that it will be included in a program that
>uses signals.  A rare error is still an error.  Just because Go 1.14
>interrupts system calls more often doesn't mean the system calls were
>not interrupted.  And non-Go programs use signals too, e.g. SIGURG and
>SIGIO.
>
>Ian
>
>
>> > 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.
>> 
>> 
>>

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

2020-02-27 Thread Robert Engels 
I think the difference is that a user program can block signals when working 
with certain devices. With Go that is not possible so the only choice is to not 
use Go. 

Unless I am missing something else?

> On Feb 27, 2020, at 9:52 AM, Ian Lance Taylor  wrote:
> 
> 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.
> 
> You're right, I do disagree.  I don't think it's the Go developers who
> are taking that position.  It's the Unix library developers.  While a
> main program can make its own choices about signals, a library has to
> consider the possibility that it will be included in a program that
> uses signals.  A rare error is still an error.  Just because Go 1.14
> interrupts system calls more often doesn't mean the system calls were
> not interrupted.  And non-Go programs use signals too, e.g. SIGURG and
> SIGIO.
> 
> Ian
> 
> 
 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

Re: [go-nuts] Bound checks elimination hint.

2020-02-27 Thread 'drc...@google.com' via golang-nuts 
FYI, strided iteration is something we're trying to do better but this is 
very tricky code, and it is also possible for it to get very expensive at 
compile time.  
On Saturday, February 22, 2020 at 4:42:03 PM UTC-5 Nigel Tao wrote:

> On 2/23/20, Bruno Albuquerque  wrote:
> > Would adding an explicit len() check before the loop help the
> > compiler in any way (can not test right now)?
>
> I don't know. Sorry.
>

-- 
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/5659e74b-b823-41de-84ad-c14cbd8e45a9%40googlegroups.com.

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

2020-02-27 Thread Ian Lance Taylor 
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.

You're right, I do disagree.  I don't think it's the Go developers who
are taking that position.  It's the Unix library developers.  While a
main program can make its own choices about signals, a library has to
consider the possibility that it will be included in a program that
uses signals.  A rare error is still an error.  Just because Go 1.14
interrupts system calls more often doesn't mean the system calls were
not interrupted.  And non-Go programs use signals too, e.g. SIGURG and
SIGIO.

Ian


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

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

2020-02-27 Thread Jesper Louis Andersen 
PC loser-ing is a brilliant thing which also finds its use in various
proofs about programming languages.

I guess the primary problem is that you have code out there which doesn't
assume the presence of a signal handler in the code, yet suddenly you get
EINTR back because of signal delivery in other libraries. Correctly
programming Unix systems requires attention to detail :)

On Wed, Feb 26, 2020 at 6:33 PM Amnon Baron Cohen  wrote:

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

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

2020-02-27 Thread Manlio Perillo 
On Thursday, February 27, 2020 at 2:15:14 AM UTC+1, 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: 
> > [...]
> >> > 
> >> > 
> 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. 
>
>
I suspect people will complain whatever you do.
It EINTR is returned to the caller, people will complain that they don't 
want to handle it.  Probably they don't even know what EINTR means. 
If EINTR is handled by the runtime and all the exported API of the stdlib 
never return EINTR, some people may complain that they want to handle EINTR 
in their program, since only the main program can decide how to handle 
EINTR.

I ported the example http://250bpm.com/blog:12 to Go:
https://play.golang.org/p/OkjrqtW6SdM

For a server it is the right thing to do to ignore EINTR, but for an 
interactive client it is not.
By the way, cmd/go use this pattern, closing the Interrupted channel when 
receiving a SIGINT or SIGQUIT signals.

One thing Go can probably do is to not treat EINTR as a temporary error (as 
defined by Errno.Temporary method in syscall), and instead add a new method 
Errno.Interrupted.
In this way the stdlib have more control over EINTR.


Thanks
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/7e2a3d16-0253-4cf8-84eb-441830086f4f%40googlegroups.com.