Re: [go-nuts] CPU profiling with pprof

[Ian Lance Taylor]

On Fri, Sep 6, 2019 at 8:36 PM Vincent Blanchon
 wrote:
>
> The documentation of the profiling 
> (https://blog.golang.org/profiling-go-programs) explains that: "Go program 
> stops about 100 times per second".
> However, in the code, I could see that the collector has a sleep of 100ms 
> https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go#L779. 
> Therefore, it collects data only 10 times per second?
> Also, it does not stop the program since it is a separated goroutine 
> https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go#L764.
>
> Did I miss something here?

The actual profile data is collected by the code in runtime/cpuprof.go
and runtime/profBuf.go.  That data is generated 100 times per second.
The code you are looking at in the runtime/pprof package is the code
that is collecting that data, which is generated at interrupt time,
and converting it into a format that can be reported to the user or
the pprof program.

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/CAOyqgcXkjsaHq%2BLEak9ZEO6afV9MFcCFMjE2WDz%3D23x4uPQ1fA%40mail.gmail.com.

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

[Ian Lance Taylor]

On Sun, Sep 8, 2019 at 7:46 AM stefan via golang-nuts
 wrote:
>
> Please release 1.13.1 to fix the "xerrors" breakage: 
> https://github.com/golang/go/issues/32246

As far as I know, there is no breakage with the up to date version of
golang.org/x/xerrors.  If you are having trouble, please open an issue
with details.  Thanks.

Ian


> On Tuesday, September 3, 2019 at 9:16:53 PM UTC+2, Dmitri Shuralyov wrote:
>>
>> Hello gophers,
>>
>> We just released Go 1.13.
>>
>> You can read the announcement blog post here:
>> https://blog.golang.org/go1.13
>>
>> You can download binary and source distributions from our download page:
>> https://golang.org/dl/
>>
>> To compile from source using a Git clone, update to the release with
>> "git checkout go1.13" and build as usual.
>>
>> To find out what has changed in Go 1.13, read the release notes:
>> https://golang.org/doc/go1.13
>>
>> Thanks to everyone who contributed to the release!
>>
>> Cheers,
>> The Go Team
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2f47b65d-6c0b-49b3-b6e3-6b63551a2272%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/CAOyqgcXKhEEa7Fig%3Dy5ymBPUwsVH_FBHE_fnW5ccqPecCRyp9A%40mail.gmail.com.

Re: [go-nuts] go build reports relocation target not defined for ABI0 (but is defined for ABIInternal)

[Ian Lance Taylor]

On Mon, Sep 9, 2019 at 7:57 PM Zhang Chao  wrote:
>
> Thanks for your interpretation. So is there any workaround?

Don't try to call an internal runtime package function.  Call a Go
function defined in your own package that calls the print builtin.

Ian


> On Tuesday, September 10, 2019 at 10:55:00 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Mon, Sep 9, 2019 at 8:09 AM Zhang Chao  wrote:
>> >
>> > I'm trying to write a tiny go program with a SayHello function written by 
>> > assembly.
>> > When I build it, the go build command giving me an error message:
>> >
>> > # bar
>> > main.asmSayHello: relocation target runtime.printstring not defined for 
>> > ABI0 (but is defined for ABIInternal)
>> >
>> > Here are the codes.
>> >
>> > main.go:
>> >
>> > package main
>> >
>> > func main() { asmSayHello() }
>> >
>> > func asmSayHello()
>> >
>> > and main_amd64.s:
>> >
>> > #include "textflag.h"
>> > #include "funcdata.h"
>> >
>> > // "Hello, World\n"
>> > DATA text<>+0(SB)/8,$"Hello Wo"
>> > DATA text<>+8(SB)/8,$"rld!\n"
>> > GLOBL text<>(SB),NOPTR,$16
>> >
>> > // func asmSayHello()
>> > TEXT ·asmSayHello(SB), $16-0
>> > NO_LOCAL_POINTERS
>> > MOVQ $text<>+0(SB), AX
>> > MOVQ AX, (SP)
>> > MOVQ $16, 8(SP)
>> > CALL runtime·printstring(SB)
>> > RET
>> >
>> > The go facility version information:
>> >
>> > # go version
>> > go version go1.12.5 linux/amd64
>> >
>> > Anyone who can help me to solve this weird problem (at least for me :) )?
>>
>> You are trying to reach into the runtime package to run an internal
>> function.  That isn't permitted.  It's never been permitted, although
>> it used to work.  Now it doesn't work.
>>
>> For more information see
>> https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md#compatibility
>> .
>>
>> 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/9d2517e2-0992-4631-a4dc-e854433423a4%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/CAOyqgcUoLoC0G%2BesHAvOyhRpWgsWy2D%2BymLshePO0opNWONaLg%40mail.gmail.com.

Re: [go-nuts] go build reports relocation target not defined for ABI0 (but is defined for ABIInternal)

[Zhang Chao]

Hello!

Thanks for your interpretation. So is there any workaround?

On Tuesday, September 10, 2019 at 10:55:00 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Sep 9, 2019 at 8:09 AM Zhang Chao > 
> wrote: 
> > 
> > I'm trying to write a tiny go program with a SayHello function written 
> by assembly. 
> > When I build it, the go build command giving me an error message: 
> > 
> > # bar 
> > main.asmSayHello: relocation target runtime.printstring not defined for 
> ABI0 (but is defined for ABIInternal) 
> > 
> > Here are the codes. 
> > 
> > main.go: 
> > 
> > package main 
> > 
> > func main() { asmSayHello() } 
> > 
> > func asmSayHello() 
> > 
> > and main_amd64.s: 
> > 
> > #include "textflag.h" 
> > #include "funcdata.h" 
> > 
> > // "Hello, World\n" 
> > DATA text<>+0(SB)/8,$"Hello Wo" 
> > DATA text<>+8(SB)/8,$"rld!\n" 
> > GLOBL text<>(SB),NOPTR,$16 
> > 
> > // func asmSayHello() 
> > TEXT ·asmSayHello(SB), $16-0 
> > NO_LOCAL_POINTERS 
> > MOVQ $text<>+0(SB), AX 
> > MOVQ AX, (SP) 
> > MOVQ $16, 8(SP) 
> > CALL runtime·printstring(SB) 
> > RET 
> > 
> > The go facility version information: 
> > 
> > # go version 
> > go version go1.12.5 linux/amd64 
> > 
> > Anyone who can help me to solve this weird problem (at least for me :) 
> )? 
>
> You are trying to reach into the runtime package to run an internal 
> function.  That isn't permitted.  It's never been permitted, although 
> it used to work.  Now it doesn't work. 
>
> For more information see 
>
> https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md#compatibility
>  
> . 
>
> 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/9d2517e2-0992-4631-a4dc-e854433423a4%40googlegroups.com.

Re: [go-nuts] go build reports relocation target not defined for ABI0 (but is defined for ABIInternal)

[Ian Lance Taylor]

On Mon, Sep 9, 2019 at 8:09 AM Zhang Chao  wrote:
>
> I'm trying to write a tiny go program with a SayHello function written by 
> assembly.
> When I build it, the go build command giving me an error message:
>
> # bar
> main.asmSayHello: relocation target runtime.printstring not defined for ABI0 
> (but is defined for ABIInternal)
>
> Here are the codes.
>
> main.go:
>
> package main
>
> func main() { asmSayHello() }
>
> func asmSayHello()
>
> and main_amd64.s:
>
> #include "textflag.h"
> #include "funcdata.h"
>
> // "Hello, World\n"
> DATA text<>+0(SB)/8,$"Hello Wo"
> DATA text<>+8(SB)/8,$"rld!\n"
> GLOBL text<>(SB),NOPTR,$16
>
> // func asmSayHello()
> TEXT ·asmSayHello(SB), $16-0
> NO_LOCAL_POINTERS
> MOVQ $text<>+0(SB), AX
> MOVQ AX, (SP)
> MOVQ $16, 8(SP)
> CALL runtime·printstring(SB)
> RET
>
> The go facility version information:
>
> # go version
> go version go1.12.5 linux/amd64
>
> Anyone who can help me to solve this weird problem (at least for me :) )?

You are trying to reach into the runtime package to run an internal
function.  That isn't permitted.  It's never been permitted, although
it used to work.  Now it doesn't work.

For more information see
https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md#compatibility
.

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/CAOyqgcWrC8aGn7XqshfZbThvQuW04MQzfwWL-O0-1MuoQxngcw%40mail.gmail.com.

Re: [go-nuts] Re: Running golang compiled binary on QNX

[Adrian Petrescu]

On 09/09 11:30AM, scab...@gmail.com wrote:

It's been at least 18 months since this question was asked. Has anything
changed?


On Tuesday, January 30, 2018 at 4:44:42 PM UTC-5, sbez...@cisco.com wrote:


Hello,

I was wondering if anybody managed to get golang compiled binary to run on
32-bit QNX?

I compiled it with  GOARCH=386 GOOS=linux go build -o blah


I might be missing some context here, but why would you expect a binary
compiled for Linux to run unaided on QNX? They're two completely
different operating systems.

[This issue](https://github.com/golang/go/issues/23633) seems to confirm
that there's no special compatibility layer that would allow this to
work.


--
Adrian

--
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/20190910005929.wpu7m5ibtthbcfub%40coxeter.

Re: [go-nuts] Re: Expectations for errors.Is/As with error trees

['Abhinav Gupta' via golang-nuts]

Hey,

Thanks for your response. Although we were unsure about this at first (which
is why we started this thread), after further discussion we agree that this
API makes sense. Part of the discussion is summarized below for others
trying
to make a similar decision, and to help plan future APIs around multi-error
situations.

We had a couple requirements in mind during this discussion:

   1. It was all or nothing. Most users will expect symmetry between
   errors.Is
   and errors.As. That is, if errors.Is(err, target) succeeds,
   errors.As(err, ) should also succeed.
   2. Users should not know that they are dealing with a multierr error
   unless
   necessary. Knowledge of multierr is not part of the contract of a
   function
   returning error unless explicitly documented. So introducing new
   functions to the multierr package for errors.Is/As was to be avoided
   for now.

The first issue we discussed was what users expect when they call
errors.Is(err, cause) where err is a multierr error (but the user does not
know that). Does the user expect a match if *all* errors inside err match,
or if *any* error inside err matches? Valid scenarios are conceivable in
both directions. We agreed that there were more cases for the “any error may
match” route than the “all errors must match.”

The second issue was around loss of information with errors.As when the
error is a multierr error. For non-multierr errors, when extracting an error
with errors.As, you will usually have one instance of each error type in the
chain.

fmt.Errorf("something went wrong: %w", myError{Cause: net.OpError{Err: ..}})

It will be uncommon to have, myError{...{Err: myError{...}}} where myError
is meaningful. So the “first match succeeds” behavior implemented by
errors.As suffices for most cases.

With multierr errors, it will be more common to have multiple error chains
with the same wrapper type as these will be commonly produced from the same
context.

err = multierr.Combine(
fooFailed{Cause: net.OpError{..}},
fmt.Errorf("...: %w", fooFailed{Cause: context.DeadlineExceeded}),
net.OpError{Err: fooFailed{cause: os.ErrNotExist}},
)

Returning just the first match with errors.As seems like a significant loss
of information, and non-deterministic if the error list is constructed
non-deterministically (from multiple concurrent operations, for example).

We think that the ideal behavior here would be for errors.As to produce a
view of the original multierr error, filtered down to the requested type.
That
is, something roughly equivalent to the following:

// var target fooFailed
// errors.As(err, )

*target = multierr.Combine(
fooFailed{Cause: net.OpError{..}},
fooFailed{Cause: context.DeadlineExceeded},
fooFailed{cause: os.ErrNotExist},
)

// or,
//  var target []fooFailed

But that’s impossible to do cleanly with the current design of errors.As:
target is expected to be of type fooFailed, not multierr‘s error type.

Eventually we decided that the loss of information with errors.As, although
regrettable, is acceptable in the short term while we experiment with the
new
functionality internally.

We may also end up bending requirement (2) above and implement a
multierr.Find API that extracts a slice of matching error objects by type,
but we’d like to experiment with just the basic functionality first.

In conclusion, we decided that the PR on multierr is fine as-is. We’ll merge
and release it in the near future.

We hope this discussion was helpful to others, and perhaps provided
inspiration for future APIs around multi-error use cases.

Thanks.

Abhinav


On Thu, Sep 5, 2019 at 4:35 PM Mitchell Hashimoto  wrote:

> Hi,
>
> On Tuesday, September 3, 2019 at 8:29:36 PM UTC-7, Abhinav Gupta wrote:
>
>> The PR we have open
>> 
>> implements the following behavior:
>>
>>- For errors.As
>>
>> ,
>>the first error in the list where errors.As
>>
>> 
>>succeeds is
>>returned.
>>- For errors.Is
>>
>> ,
>>all errors are checked until one matches, in which case we
>>succeed. If none of the errors matched, we fail.
>>
>> This means that if you have multiple 

Re: [go-nuts] Is there a preferred REDIS driver or go psckage?

[Steven Hartland]

https://github.com/gomodule/redigo/ written by Gary Burd is still
maintained. We actively use it in production heavily.

On Mon, 9 Sep 2019 at 19:19, joe mcguckin 
wrote:

>
>
> Thanks,
>
> Joe
>
> --
> 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/a82996c6-6163-4025-a3f2-f0d6f37b0473%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/CAHEMsqbde8iA0Jnfon8AWm0ZYmYjSCth4eNv8nwCf1v726D0Cw%40mail.gmail.com.

[go-nuts] Re: [ANN] CBOR Library - Small, safe, and easy CBOR encoding and decoding (for WebAuthn, etc.) in Go

[Faye Amacker]

Answers to some questions received today:

*Is the API stable?*
There's no plan to change the API -- but I wanted to leave room to improve 
the API based on initial feedback.

The API will always be backwards compatible unless the major version number 
changes.  

*Is this production ready?*
Current version passed fuzzing for 9+ hours on linux_amd64 without problems 
using RFC 7049 test vectors as seeds. It appears ready for production use 
on linux_amd64.

*Why is version number only 0.3?*
I was tempted to release 0.3 as 1.0.  I'll promote version 0.3 to 1.0 this 
month, unless API changes are requested by the Go community.  I'm using 
semantic versioning, so I didn't want to risk a 2.0 release right after 
announcing 1.0.

I've updated the README to include this info. 

-- 
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/5461c158-705c-440b-afda-c700d87126d4%40googlegroups.com.

Re: [go-nuts] Is there a preferred REDIS driver or go psckage?

[Mhd Shulhan]

In the following redis page: https://redis.io/clients#go

you can see list of Go packages, the recommended ones are marked with star; 
while package with smile icon mark packages that have activities within last 
six months.

-- 
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/A06B7048-8FB1-4A33-AF32-77A318857467%40gmail.com.

[go-nuts] Re: Running golang compiled binary on QNX

[scabooz]

It's been at least 18 months since this question was asked. Has anything 
changed?


On Tuesday, January 30, 2018 at 4:44:42 PM UTC-5, sbez...@cisco.com wrote:
>
> Hello, 
>
> I was wondering if anybody managed to get golang compiled binary to run on 
> 32-bit QNX? 
>
> I compiled it with  GOARCH=386 GOOS=linux go build -o blah 
>
> But when I start it in QNX I get core dump. I double check and the time of 
> executable matches type of native qnx binaries.  Appreciate any 
> suggestions. 
>
> Thank you 
> Serguei 
>
>   
>
>

-- 
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/f92b9871-8c45-49ec-9190-97ed45e83596%40googlegroups.com.

[go-nuts] Is there a preferred REDIS driver or go psckage?

[joe mcguckin]

Thanks,

Joe

-- 
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/a82996c6-6163-4025-a3f2-f0d6f37b0473%40googlegroups.com.

Re: [go-nuts] html/template escaping problem

[Jens-Uwe Mager]

This gives me the output:

{{test}}



So this does not work at all.

On Monday, September 9, 2019 at 4:20:06 PM UTC+2, Kurtis Rader wrote:
>
> You have
>
> href="{{safeurl .href}}",
>
> Shouldn't that be "safejs"? Using "safehref" is causing the string to be 
> hex encoded as a URL. Which means most special chars will be converted to 
> hex representation.
>
> On Mon, Sep 9, 2019 at 4:53 AM Jens-Uwe Mager  > wrote:
>
>> I am having a problem to properly escape javascript urls in my templates. 
>> I do have the situation where I build a template that is having javascript 
>> urls that are from variables in the go program (read from yaml files). The 
>> go program generates static html, but the html is supposed to use 
>> moustache.js to expand some further variables at render time. I am just not 
>> able to preserve my javascript from the html/template escaping. Any ideas 
>> what I am doing wrong? 
>>
>> The output is:
>>
>> {{test}}
>>
>>
>> But I would like it to be:
>>
>> {{test}}
>>
>>
>> package main
>>
>> import (
>> "html/template"
>> "os"
>> )
>>
>> var t = template.Must(template.New("test").Funcs(template.FuncMap{
>> "safeattr": func(value string) template.HTMLAttr {
>> return template.HTMLAttr(value)
>> },
>> "safehtml": func(value string) template.HTML {
>> return template.HTML(value)
>> },
>> "safejs": func(value string) template.JS {
>> return template.JS(value)
>> },
>> "safecss": func(value string) template.CSS {
>> return template.CSS(value)
>> },
>> "safeurl": func(value string) template.URL {
>> return template.URL(value)
>> },
>> }).Parse(`
>> {{safehtml .content}}
>> `))
>>
>> func main() {
>> data := map[string]string{
>> "href":"javascript:doSlide('{{area}}');",
>> "content": "{{test}}",
>> }
>> err := t.Execute(os.Stdout, data)
>> if err != nil {
>> panic(err)
>> }
>> }
>>
>>
>>
>> https://play.golang.org/p/F2EiuECCZWo
>>
>>
>> -- 
>> 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/0c93e49c-1e8b-4617-baef-0848b57fde93%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/556ed9b5-8d41-4826-bdfc-fab4eb503d80%40googlegroups.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

['Axel Wagner' via golang-nuts]

Hey,

On Mon, Sep 9, 2019 at 9:55 AM changkun  wrote:

> Here comes with more interesting points. My "intuitive" comes from this
> scenario:
> I have an unbuffered channel "closedCh" that indicates if a network
> connection is closed, a timer handles for heartbeat detection and polls
> some data, if a connection is closed, then returns an error.
>
> At some point, I close the "closedCh" for the termination of previous
> for-select loop.
> I initially thought that the heartbeat detection case will not be executed
> and
> closedCh will safely return and terminates the loop.
> However, there are some "false negative" results returned by the loop,
> because select still can select the heartbeat case if the heartbeat and
> closedCh arrive concurrently.
>

That's fair and I have to admit that I ran into similar situations once or
twice in the past without having a super good solution. FWIW, I think one
hindrance is that network interactions are usually inherently racey. You
can't really know or guarantee when and in what order packages arrive. So
it might be a good idea to think about a way to prevent this from causing
issues anyway. For example, I would probably just try writing/reading the
heartbeat and if an error occurs while doing that, follow that with a check
if the connection was already closed. e.g. something like

case <- ticker.C:
err := heartbeat()
if err == nil {
continue
}
select {
case <-closedCh:
// connection was closed properly, error is expected
return nil
default:
return err
}
}

this means that you *might* sometimes send an extra heartbeat message, but
that's why I'm mentioning that you can't fully prevent that in practice
anyway, so the receiver needs to be able to cope.

Note in particular, that your code remains racey. No matter *how* you
implement the check for closed-nes (including your atomic variable), the
close could always happen right after your check and before you do the
heartbeat processing. It's an inherently asynchronous problem :)

Best,

Axel

PS: Don't worry about the name, it happens *all* the time and I'm no longer
bothered :)


See the following code for TLDR:
>
> // goroutine1
> closedCh := make(chan struct{})
>
> // do some preparation
> ...
>
> for {
> select {
> case <- ticker.C:
> // it is possible that this case can still being executed
> // one more time if closedCh arrives.
>
> // heartbeat detection, data processing..
> ...
>
> case <- closedCh
> return
> }
>
>
>
> // goroutine2
> close(closedCh)
>
> To fix the issue I have encountered, I have to use an atomic value for
> double check
> if the channel is closed inside the ticker case:
>
> // "global" data
> closedCh := make(chan struct{})
> closed := uint32(0)
>
> // goroutine1
>
> // do some preparation
> ...
>
> for {
> select {
> case <- ticker.C:
> // now it is ok
> if atomic.LoadUint32() == 1 {
> return
> }
>
> // heartbeat detection, data processing..
> ...
>
> case <- closedCh
> return
> }
>
>
>
> // goroutine2
> if !atomic.CompareAndSwapUint32(, 0, 1) {
> return ErrClosed
> }
> close(closedCh)
>
> which does not like an ideal solution (not sure if there is a better
> way?), because for close a ticker,
> I need an atomic value and an unbuffered channel that appear in three
> different places.
>
>
>>
>> Now, ISTM that the simplest intuitive interpretation of what "event A and
>> B happen concurrently" (defined abstractly as "are not ordered in the
>> happens-before partial order) is that the order that A and B happen in real
>> time in is unclear and could happen either way olin practice. And under
>> that intuitive understanding, I don't know how you conclude that the select
>> should prioritize either or not execute the ticker case at all. After all -
>> you can never know whether the ticker *has actually fired* at the concrete
>> real point in time the select executed.
>>
> Sorry for lack of problem statement, see above
>
>
>>
>> Note, by the way, that the fact that you observe either result doesn't
>> actually say anything about the pseudo-randomness or lack thereof of the
>> select statement: You can't, from the output of the program, distinguish
>> between "both cases where ready to proceed and select flipped a coin coming
>> up close" from "only close was ready to proceed, because select executed in
>> between the closing/firing" (and the same for the timer firing). The
>> pseudo-randomness of select is irrelevant for your case, it's the fact that
>> these events are concurrent, both as specified and IMO as intuitively
>> obvious.
>>
> You are right, it is not a suitable example for the question I have. I
> feel sorry about it. I hope you didn't get trouble for reading it.
> In fact, I am curious: if select work with a random selection, is it
> possible that a case will never be executed?
> How can select 

Re: [go-nuts] html/template escaping problem

[Kurtis Rader]

You have

href="{{safeurl .href}}",

Shouldn't that be "safejs"? Using "safehref" is causing the string to be
hex encoded as a URL. Which means most special chars will be converted to
hex representation.

On Mon, Sep 9, 2019 at 4:53 AM Jens-Uwe Mager  wrote:

> I am having a problem to properly escape javascript urls in my templates.
> I do have the situation where I build a template that is having javascript
> urls that are from variables in the go program (read from yaml files). The
> go program generates static html, but the html is supposed to use
> moustache.js to expand some further variables at render time. I am just not
> able to preserve my javascript from the html/template escaping. Any ideas
> what I am doing wrong?
>
> The output is:
>
> {{test}}
>
>
> But I would like it to be:
>
> {{test}}
>
>
> package main
>
> import (
> "html/template"
> "os"
> )
>
> var t = template.Must(template.New("test").Funcs(template.FuncMap{
> "safeattr": func(value string) template.HTMLAttr {
> return template.HTMLAttr(value)
> },
> "safehtml": func(value string) template.HTML {
> return template.HTML(value)
> },
> "safejs": func(value string) template.JS {
> return template.JS(value)
> },
> "safecss": func(value string) template.CSS {
> return template.CSS(value)
> },
> "safeurl": func(value string) template.URL {
> return template.URL(value)
> },
> }).Parse(`
> {{safehtml .content}}
> `))
>
> func main() {
> data := map[string]string{
> "href":"javascript:doSlide('{{area}}');",
> "content": "{{test}}",
> }
> err := t.Execute(os.Stdout, data)
> if err != nil {
> panic(err)
> }
> }
>
>
>
> https://play.golang.org/p/F2EiuECCZWo
>
>
> --
> 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/0c93e49c-1e8b-4617-baef-0848b57fde93%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD8g6n9WomHSzt7d%2BFF%2BvjJEUquT2uHXyr1Kz4m0Nv3E7Q%40mail.gmail.com.

Re: [go-nuts] Re: x/mobile: Samples for reverse binding in gomobile

[Elias Naur]

On Mon Sep 9, 2019 at 3:09 AM Jay Sharma wrote:
> 
> *Next I want to try with my own classes in java.. I want to define class 
> and call it from go. *
> *Can you please suggest, in that case how to build with gomobile ?*
> 

I think you can use the -classpath option to gomobile.

-- 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/BWVGLNVRYFPP.2S3AHD3ABK0VZ%40toolbox.

[go-nuts] html/template escaping problem

[Jens-Uwe Mager]

I am having a problem to properly escape javascript urls in my templates. I 
do have the situation where I build a template that is having javascript 
urls that are from variables in the go program (read from yaml files). The 
go program generates static html, but the html is supposed to use 
moustache.js to expand some further variables at render time. I am just not 
able to preserve my javascript from the html/template escaping. Any ideas 
what I am doing wrong? 

The output is:

{{test}}


But I would like it to be:

{{test}}


package main

import (
"html/template"
"os"
)

var t = template.Must(template.New("test").Funcs(template.FuncMap{
"safeattr": func(value string) template.HTMLAttr {
return template.HTMLAttr(value)
},
"safehtml": func(value string) template.HTML {
return template.HTML(value)
},
"safejs": func(value string) template.JS {
return template.JS(value)
},
"safecss": func(value string) template.CSS {
return template.CSS(value)
},
"safeurl": func(value string) template.URL {
return template.URL(value)
},
}).Parse(`
{{safehtml .content}}
`))

func main() {
data := map[string]string{
"href":"javascript:doSlide('{{area}}');",
"content": "{{test}}",
}
err := t.Execute(os.Stdout, data)
if err != nil {
panic(err)
}
}



https://play.golang.org/p/F2EiuECCZWo


-- 
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/0c93e49c-1e8b-4617-baef-0848b57fde93%40googlegroups.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[changkun]

Sincerely sorry for the typo of your name :( Axel

-- 
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/0e9ae45e-77cc-4610-a9fe-b551c6411e29%40googlegroups.com.

Re: [go-nuts] What is the memory order when select on multiple channels that one is closing and the other is receiving?

[changkun]

Hi Alex,

Thank you for giving such great clarification. You thought is more 
sophisticated than me. 

First: The close *does* happen-before the case clause of the select for the 
> closed channel, as per the memory model. 
>

Indeed, no question here.
 

> Second: If you actually establish an ordering "close happens-before the 
> select statement, which happens-before the ticker firing", you should 
> actually get the result you want, in that only the close-case is 
> deterministically chosen, AIUI. So we are only talking about the case you 
> tried to enforce, where you *don't* have that ordering - that is, where the 
> close happens concurrently with the ticker firing and both happen 
> concurrently to the select starting to execute.
>

Here comes with more interesting points. My "intuitive" comes from this 
scenario: 
I have an unbuffered channel "closedCh" that indicates if a network 
connection is closed, 
a timer handles for heartbeat detection and polls some data, if a 
connection is closed, then returns an error.

At some point, I close the "closedCh" for the termination of previous 
for-select loop.
I initially thought that the heartbeat detection case will not be executed 
and 
closedCh will safely return and terminates the loop.
However, there are some "false negative" results returned by the loop, 
because select still can select the heartbeat case if the heartbeat and 
closedCh arrive concurrently.
See the following code for TLDR:

// goroutine1
closedCh := make(chan struct{})

// do some preparation
...

for {
select {
case <- ticker.C:
// it is possible that this case can still being executed
// one more time if closedCh arrives.

// heartbeat detection, data processing..
...

case <- closedCh
return
}



// goroutine2
close(closedCh)

To fix the issue I have encountered, I have to use an atomic value for 
double check
if the channel is closed inside the ticker case:

// "global" data
closedCh := make(chan struct{})
closed := uint32(0)

// goroutine1

// do some preparation
...

for {
select {
case <- ticker.C:
// now it is ok
if atomic.LoadUint32() == 1 {
return
}

// heartbeat detection, data processing..
...

case <- closedCh
return
}



// goroutine2
if !atomic.CompareAndSwapUint32(, 0, 1) {
return ErrClosed
}
close(closedCh)

which does not like an ideal solution (not sure if there is a better way?), 
because for close a ticker, 
I need an atomic value and an unbuffered channel that appear in three 
different places.
 

>
> Now, ISTM that the simplest intuitive interpretation of what "event A and 
> B happen concurrently" (defined abstractly as "are not ordered in the 
> happens-before partial order) is that the order that A and B happen in real 
> time in is unclear and could happen either way olin practice. And under 
> that intuitive understanding, I don't know how you conclude that the select 
> should prioritize either or not execute the ticker case at all. After all - 
> you can never know whether the ticker *has actually fired* at the concrete 
> real point in time the select executed.
>
Sorry for lack of problem statement, see above
 

>
> Note, by the way, that the fact that you observe either result doesn't 
> actually say anything about the pseudo-randomness or lack thereof of the 
> select statement: You can't, from the output of the program, distinguish 
> between "both cases where ready to proceed and select flipped a coin coming 
> up close" from "only close was ready to proceed, because select executed in 
> between the closing/firing" (and the same for the timer firing). The 
> pseudo-randomness of select is irrelevant for your case, it's the fact that 
> these events are concurrent, both as specified and IMO as intuitively 
> obvious.
>
You are right, it is not a suitable example for the question I have. I feel 
sorry about it. I hope you didn't get trouble for reading it. 
In fact, I am curious: if select work with a random selection, is it 
possible that a case will never be executed?
How can select statement provide fairness similar to the FIFO-semantic 
channel (https://github.com/golang/go/issues/11506)?
 

-- 
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/7736fea9-b4c0-4b1b-8b0e-9bc3b0e3bd7b%40googlegroups.com.