Re: [go-nuts] x/mobile: avoid to catch sigabort signal
Ehy Ian, thanks for the response. Apology if I was not clear, I try to explain in a different way but it's hard for me too since I'm not 100% confident about what it's happening here exactly, I'm tring to follow the trace but any feedback is more than welcome. The problem I'm facing is the following: I've a small utility written in GO and integrated in an app iOS as SDK. At the moment if I've undestood correctly from the thread I've linked the GO runtime are cacthing a sigabort signal that are not from the GO stack but it's generated from another thread with the result that it's look like the GO runtime is crashing from the apple report. If this behavior of the GO runtime is legittime when GO is an executable in my context is a problem since the developer follow the GO stack instead of the other thread stack. Now what I'm try to understand if this behavior can be somehow change, and if so how should I do? Il giorno venerdì 8 settembre 2023 alle 22:34:07 UTC+2 Ian Lance Taylor ha scritto: > On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug > wrote: > > > > Some weeks ago I've opened a possible bug on github and the only > response I received is a reference to > > "This looks like the program (the Go runtime, or not) intentionally > crashing when it is already in a bad condition, like receiving an unhandled > signal on a non-Go thread." > > > > I would like to stop the GO system to do this kind of behaviour > (intercepting unhandled signal) otherwise the team who work on the crash > keep searching the problem on the GO thread crashed instead of elsewhere. > This for us is a big problem and I love if someone can help me to address > this matter! > > I'm sorry, I don't really understand what you are asking. What I can > tell you is that signal handling in Go programs is managed via the > os/signal package. See https://pkg.go.dev/os/signal. > > 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/3a7ac4f8-4623-41d2-8d43-3e134d538c14n%40googlegroups.com.
Re: [go-nuts] x/mobile: avoid to catch sigabort signal
On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug wrote: > > Some weeks ago I've opened a possible bug on github and the only response I > received is a reference to > "This looks like the program (the Go runtime, or not) intentionally crashing > when it is already in a bad condition, like receiving an unhandled signal on > a non-Go thread." > > I would like to stop the GO system to do this kind of behaviour (intercepting > unhandled signal) otherwise the team who work on the crash keep searching the > problem on the GO thread crashed instead of elsewhere. This for us is a big > problem and I love if someone can help me to address this matter! I'm sorry, I don't really understand what you are asking. What I can tell you is that signal handling in Go programs is managed via the os/signal package. See https://pkg.go.dev/os/signal. 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/CAOyqgcXYe-n%3DZvF4h5sMJWZO%2BGTYVfMJgvwS-KUPi1yogDyk3g%40mail.gmail.com.
[go-nuts] Re: GO language best practice document
Go Style | styleguide https://google.github.io/styleguide/go/index peter On Friday, September 8, 2023 at 9:05:12 AM UTC-4 Alexandre Roy wrote: > Hi, > > I want to start a new web application using GO with AWS Lambda, but first > I want to learn the GO language. I mostly have C / Python experience. > > I started reading https://go.dev/doc/effective_go, but as mentioned in > the following issue https://github.com/golang/go/issues/28782, this > documentation is deprecated with new best practice. > > Since the issue is still open and no new document is available, what do > you recommend to learn GO the right way (best practice) in 2023? > > Thanks for your help and your time, > > Alexandre > -- 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/9d1a4832-e49a-4fff-8830-186bbd0c6931n%40googlegroups.com.
Re: [go-nuts] How to constrain an integral type's values
I recommend using strings as the base type for things like this, rather
than ints. There is no need to use ints, just because that's what C uses.
Thomas
On Fri, Sep 8, 2023 at 3:24 AM 'Mark' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I often create small multi-value flag types, e.g.
> ```go
> type mode uint8
>
> const (
> argMode mode = iota
> baseMode
> cmdMode
> )
> ```
> The problem is that if I write, say, `m := baseMode`, although `m` has
> the correct type (`mode`), there is no way to constrain its values to the
> consts I've declared.
> In theory I could create a `NewMode(int) mode` function and have it panic
> if the given int isn't valid; but that won't prevent, say, `m += 99`. The
> next step would be to define a full type, e.g., something like:
> ```go
> type mode struct {
> m int
> }
> ```
> This would prevent `m++` and similar since all accesses would have to go
> through the public functions. However, this would still do all its checking
> at _runtime_; whereas for this kind of use it should surely be possible to
> check at compile time.
>
> In Pascal it is easy to declare a "subrange" type which might look like
> this in Go-like syntax:
>
> `type mode uint8 0..2`
>
> Is there a compile-time solution for this that I've missed?
>
> --
> 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/8ba9ef87-984c-4b14-a760-343d2731e91dn%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/CA%2BYjuxunOzRKt2vB9u8QtOmP%2Bwqavn7Yjky9jz4-C3b0%2BkAWRg%40mail.gmail.com.
[go-nuts] GO language best practice document
Hi, I want to start a new web application using GO with AWS Lambda, but first I want to learn the GO language. I mostly have C / Python experience. I started reading https://go.dev/doc/effective_go, but as mentioned in the following issue https://github.com/golang/go/issues/28782, this documentation is deprecated with new best practice. Since the issue is still open and no new document is available, what do you recommend to learn GO the right way (best practice) in 2023? Thanks for your help and your time, Alexandre -- 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/CAKtYRj7Y5ysS%2B%3D_3dsSKcm3ej9sJcjZnzyDfOBP_%2B7CqBYZeOw%40mail.gmail.com.
Re: [go-nuts] How to constrain an integral type's values
On Fri, Sep 8, 2023 at 9:24 AM 'Mark' via golang-nuts wrote: > Is there a compile-time solution for this that I've missed? No. Go does not have enum types. -- 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/CAA40n-Xt4awDMhsKvL_EQZzN_B7O1pzss95PZC6xaufssQuoYA%40mail.gmail.com.
[go-nuts] How to constrain an integral type's values
I often create small multi-value flag types, e.g.
```go
type mode uint8
const (
argMode mode = iota
baseMode
cmdMode
)
```
The problem is that if I write, say, `m := baseMode`, although `m` has the
correct type (`mode`), there is no way to constrain its values to the
consts I've declared.
In theory I could create a `NewMode(int) mode` function and have it panic
if the given int isn't valid; but that won't prevent, say, `m += 99`. The
next step would be to define a full type, e.g., something like:
```go
type mode struct {
m int
}
```
This would prevent `m++` and similar since all accesses would have to go
through the public functions. However, this would still do all its checking
at _runtime_; whereas for this kind of use it should surely be possible to
check at compile time.
In Pascal it is easy to declare a "subrange" type which might look like
this in Go-like syntax:
`type mode uint8 0..2`
Is there a compile-time solution for this that I've missed?
--
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/8ba9ef87-984c-4b14-a760-343d2731e91dn%40googlegroups.com.
