[go-nuts] type checking custom interface{} is not working as expected

[Santhosh Kumar T]

I have a function call nextRow which returns []interface{}

i want to add support for json, since json value can be string, number 
which conflicts
with native types, i used following:
type Json interface{}
and returning json values as:
return Json(v)
but in type checking it fails.

i extract minimal code to explain my issue:
   https://play.golang.org/p/AAbeOzH-SHE

in the above example, it prints: v3 is myinterface
but v3 is regular interface{} not of type myinterface

could someone help in resolving the issue. 
Is this expected behavior. what can i do to workaround if so

thanks
Santhosh

-- 
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/bcaa91b2-38ab-4713-93c6-34dd55792f4dn%40googlegroups.com.

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

[Jonathan Amsterdam]

I changed the encoding so that the previous generated code is no longer 
necessary. Encoded data now carries all the information needed to decode 
struct fields correctly, even if fields have been added and reordered.


On Sunday, January 24, 2021 at 8:29:58 AM UTC-5 Jonathan Amsterdam wrote:

> Thanks for the suggestions. I created https://github.com/jba/codec/pull/1 
> to address them. You can comment in more detail there if you'd like.
>
> On Wed, Jan 20, 2021 at 12:13 PM roger peppe  wrote:
>
>> On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam  
>> wrote:
>>
>>> The encoding scheme is described briefly in the README[0] and the 
>>> code[1].
>>>
>>> To answer your two specific questions, interfaces are represented as a 
>>> pair (typeNumber, value) where typeNumber maps to a registered type. (Like 
>>> gob, types must be registered.) Structs are represented as: startCode 
>>> (fieldNumber value)* endCode. The field numbers are assigned by the 
>>> generator.
>>>
>>
>> It might be good to be more explicit about how the field numbers are 
>> assigned. From a brief experiment, it seems like there's not a deterministic
>> relationship between a struct and its wire representation, and instead 
>> the generated field numbers are taken from the generated code file
>> when it's present. So ISTM that any user of this must be very careful to 
>> preserve that file, and realise that it's not OK to generate
>> the codec code for a type independently.
>>
>> I'd also suggest that it would be good to fully document the syntax and 
>> explain the trade-offs of this format and when
>> it might or might not be appropriate to use.
>>
>> One other question: how are the type numbers maintained as stable 
>> entities over time?
>>
>>   cheers,
>> rog.
>>
>>

-- 
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/ad1d2cc1-acfc-4278-93b7-05e09bb8b8aan%40googlegroups.com.

Re: [go-nuts] How to use atomic_int in cgo?

[Devon H. O'Dell]

Forgot to reply to the list. Oops. Sorry for the second delivery, Changkun.

On Mon, Feb 15, 2021 at 12:39 changkun  wrote:

> Hi Ian,
>
> Thanks for the hint, but I have some follow-up questions:
>
>
>> Even if there were a way to do this, an atomic variable is not a good
>> synchronization mechanism, because the other side has to poll the
>> variable.
>
> Indeed, it the other side will be a spin loop to poll the atomic variable,
> which ...
>
>
>
>> You can do this as a last resort, but it doesn't sound like
>> you are at a last resort here. I suggest that you have your C
>> function call a Go function to write a value on a channel.
>
> seems easy to write than this (?).
>
> Say a Go function foo is called from the C side, to be able to send to the
> corresponding channel, C must pass that channel to the Go function, which
> brings to the initial question:  pass a channel from Go to C, is it
> supported at the moment (?)
>
> How could a Go function be able to send content to differently allocated
> channels in correspondingly invoked C functions?
>


I think this is only a problem if you need a separate channel per
invocation for some reason, which seems unlikely. But if you did, you could
have a  map of int to chan T and pass the integer key through C.

Kind regards,

--dho


>
>
> Sincerely,
> Changkun
>
> --
> 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/7adba3a6-ee2f-4923-905d-9afc2b9f796an%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/CAFgOgC_zWPuPtNAc74CM7aimNh7k-ZbNT_TsFbCntWDT6mX_VQ%40mail.gmail.com.

Re: [go-nuts] How to use atomic_int in cgo?

[Ian Lance Taylor]

On Mon, Feb 15, 2021 at 12:39 PM changkun  wrote:
>
> Thanks for the hint, but I have some follow-up questions:
>
>>
>> Even if there were a way to do this, an atomic variable is not a good
>> synchronization mechanism, because the other side has to poll the
>> variable.
>
> Indeed, it the other side will be a spin loop to poll the atomic variable, 
> which ...
>
>
>>
>> You can do this as a last resort, but it doesn't sound like
>> you are at a last resort here. I suggest that you have your C
>> function call a Go function to write a value on a channel.
>
> seems easy to write than this (?).
>
> Say a Go function foo is called from the C side, to be able to send to the 
> corresponding channel, C must pass that channel to the Go function, which 
> brings to the initial question:  pass a channel from Go to C, is it supported 
> at the moment (?)
>
> How could a Go function be able to send content to differently allocated 
> channels in correspondingly invoked C functions?

For example, on the Go side write

type chanToUse struct {
c chan int
}

//export MyGoFunction
func MyGoFunction(u unsafe.Pointer, val int) {
cu = (*chanToUse)(u)
cu.c <- val
}

ch := make(chan int)
...
C.MyCFunction(unsafe.Pointer({ch}))

and on the C side write

void MyCFunction(void *goData) {
...
MyGoFunction(goData, 0);
}

Yes, it's more work.  But it's not a good idea to poll an atomic
variable in Go.  The Go scheduler reacts badly to busy loops.

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/CAOyqgcV--J_RWUhonaDtVh%3DS0ON-6xiqSBJQXEaqLsMtWK%3DV1Q%40mail.gmail.com.

Re: [go-nuts] How to use atomic_int in cgo?

[changkun]

Hi Ian,

Thanks for the hint, but I have some follow-up questions:


> Even if there were a way to do this, an atomic variable is not a good 
> synchronization mechanism, because the other side has to poll the 
> variable.

Indeed, it the other side will be a spin loop to poll the atomic variable, 
which ...

 

> You can do this as a last resort, but it doesn't sound like 
> you are at a last resort here. I suggest that you have your C 
> function call a Go function to write a value on a channel.

seems easy to write than this (?). 

Say a Go function foo is called from the C side, to be able to send to the 
corresponding channel, C must pass that channel to the Go function, which 
brings to the initial question:  pass a channel from Go to C, is it 
supported at the moment (?)

How could a Go function be able to send content to differently allocated 
channels in correspondingly invoked C functions?


Sincerely,
Changkun

-- 
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/7adba3a6-ee2f-4923-905d-9afc2b9f796an%40googlegroups.com.

Re: [go-nuts] about -buildmode c-shared

[Ian Lance Taylor]

On Mon, Feb 15, 2021 at 6:51 AM Frédéric De Jaeger
 wrote:
>
> On Saturday, February 13, 2021 at 4:21:34 PM UTC+1 Ian Lance Taylor wrote:
>>
>>
>>
>> > I was naively assuming that the unloading issue is easy to tackle when the 
>> > runtime is not shared between .so. Is it true ?
>>
>> No. The current Go runtime has no ability to shut down all
>> goroutines. If any goroutines are left running, and the plugin is
>> unloaded, the program will crash.
>>
>
> I was not assuming a synchronous uncooperative way for the runtime to kill a 
> running goroutine.  I was more thinking about some cooperative strategy. Like 
> a running go routine could check sometimes (maybe in the function prologue, 
> or when doing an allocation) that it is time to die.

I don't see how that could be completely reliable, especially when Go
code calls into C code.  For something like this Go aims for solutions
that are 100% reliable.


> Anycase, that could be also a constraint of the business code in the plugin.  
> Like in C, they are not supposed to be actively running when the .so is 
> dlclosed.
> In fact, what happens in practice today if we dlclose a plugin that has no 
> running goroutine (and also no cgo invocations).  Does it "work" somehow ?  
> Are we leaking threads, waiting on some dead semaphore or something ?

The current Go plugin support does not support calling dlclose on a plugin.


> This `ld` flag makes me think of another approach.  Maybe it is  ok to just 
> turn off the effective unloading of the .so (with that ld flag).  So dlclose 
> is no-op.  But if the business code takes care of cleaning most of its global 
> state, maybe the gc has the opportunity to return some memory back to the OS 
> (well, since the gc is not moving stuff, maybe the hope is slim, I don't 
> know).

The Go runtime does already return some memory to the operating system
over time.  It won't return all of it, though.


> By the way, what the most efficient way to detect if two runtime are being 
> instantiated ?  Something like a debug log that is supposed to happen once, 
> or a similar trick.

I don't know of a way to do this.

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/CAOyqgcX08rd_Gkg_e_QLqDu%2BodFCK6SD13BLoSL0HJLKpQ0z2A%40mail.gmail.com.

Re: [go-nuts] How to use atomic_int in cgo?

[Ian Lance Taylor]

On Mon, Feb 15, 2021 at 1:32 AM changkun  wrote:
>
> I would like to call a C function from Go and get notified about the 
> execution status in Go, say a goroutine wait until the C function finally 
> made some progress.
> Initially, I thought about passing a channel to C but the cgo document does 
> not say anything about that:
>
> Later, I am thinking about using an atomic variable to sync status according 
> to its value, but somehow I end up with this warning while I am compiling a 
> cgo program:
>
> package main
>
> /*
> #include 
> void ainit(atomic_int *val) {
> atomic_init(val, 0);
> }
> */
> import "C"
>
> func main() {
> var v C.atomic_int
> C.ainit()
> }
>
> cgo-gcc-prolog: In function ‘_cgo_8a67e594de48_Cfunc_ainit’:
> cgo-gcc-prolog:49:14: warning: passing argument 1 of ‘ainit’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
> ./main.go:5:24: note: expected ‘_Atomic atomic_int *’ {aka ‘_Atomic int *’} 
> but argument is of type ‘int *’
> 5 | void ainit(atomic_int *val) {
>   |^~~
>
> According to the warning and note, it seems that cgo is lacking translating 
> atomic_init? Did I do anything wrong? Or is there any better and preferred 
> way to get notified from C function?

Even if there were a way to do this, an atomic variable is not a good
synchronization mechanism, because the other side has to poll the
variable.  You can do this as a last resort, but it doesn't sound like
you are at a last resort here.  I suggest that you have your C
function call a Go function to write a value on a channel.

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/CAOyqgcU7UFk%2BecZcRNOgA8vspQx%3D2rvTSSGmYpF2kD%2Bm_UqUPQ%40mail.gmail.com.

Re: [go-nuts] Error handling

[robert engels]

And I will tell you that after working with error returns and exceptions, 
exceptions are superior - but much depends on the complexity of the system. For 
small system level tools that are pieced together via pipes, C error handling 
is fine - because the process serves as the exception handling point. For 
complex server long-lived processes, exception handling makes it much easier to 
design and deliver secure fault tolerant systems. Resilient Unix relies on the 
ability to start new processes to handle requests, track DoS attacks, faulty 
clients, etc. Process termination is a part of this. The Go runtime does not 
fit this model, so it needs to replicate it.

People write bad exception code - people write bad error return code. It’s 
easier to write and maintain good exception code. To this day, very few major 
systems are written in Go - at some point we have to ask honestly why - I think 
Go’s  error handling is an important factor here.

Go can probably get there without exceptions, but it entails standardized error 
declarations, wrapping, inspection, logging, etc. I think the Go2 error 
handling proposals attempt this.

> On Feb 15, 2021, at 11:25 AM, Volker Dobler  
> wrote:
> 
> I think there is strong consensus, that the current style of error handling 
> is currently the best option. Nobody has been able to come up with something 
> better (really better, not just more comfortable while ignoring hefty 
> drawbacks).
> 
> It is true that a loud minority seems to miss exceptions to a point where 
> they are unwilling to even try the language. How much their expertise counts 
> if they never really worked with proper error handling in Go is debatable. 
> Having worked with error returns and exceptions I can tell you that proper 
> error handling with exceptions is much more painful than with errors. But of 
> course: If your infrastructure, your business requirements and your 
> acceptance criteria allow for making any problem a problem of someone else 
> than exceptions are godsend.
> 
> V.
> 
> On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote:
> I think ’strong census’ is not accurate - thus the discussions around 
> improving error handling in Go2. 
> 
> Many have commented here and elsewhere that the number one reason they don’t 
> use Go is due to lack of exception handling. 
> 
> > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki  > > wrote: 
> > 
> > Dnia 2021-02-13, o godz. 17:44:47 
> > Michael MacInnis  > > napisał(a): 
> > 
> >> I've been playing around with reducing error handling boilerplate 
> > 
> > You're not alone. Hundreds of us went into such thinking in the first weeks 
> > of reading/using Go - yet before we noticed how much more productive we 
> > are with Go's "boilerplate" than we were in languages where handling errors 
> > (failures) was "a problem of others", including future-us as "others". 
> > 
> > Perceived consensus of the Go community is that "error handling 
> > boilerplate" 
> > is a strong feature. I.e. in normal production software you MUST handle 
> > failures 
> > and you should do it as close as possible to the source of said failure. 
> > 
> > Go helps with that. Even team's proposal was finally retracted: 
> > https://github.com/golang/go/issues/32437 
> >  Discussion there is lengthy, 
> > but worth 
> > reading to sense why wider community considers "boilerplate" as asset. 
> > 
> > Error handling proposals umbrella: 
> > https://github.com/golang/go/issues/40432 
> >  
> > 
> >> Michael. 
> > 
> > Hope this helps, 
> > 
> > -- 
> > Wojciech S. Czarnecki 
> > << ^oo^ >> OHIR-RIPE 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to golang-nuts...@googlegroups.com 
> > . 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint
> >  
> > .
> >  
> 
> 
> -- 
> 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/d9cdb32d-2609-4ae9-a9ff-36830c877245n%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 

Re: [go-nuts] [ANN] Hare - a nimble little DBMS written in Go.

[Artur Vianna]

Looks very cool! Seems like a nice fit for persistent storage in games

On Mon, 15 Feb 2021, 14:37 Jamey Cribbs,  wrote:

> After working on this package off and on for a long time, I've finally
> decided to set it free into the wild.
>
> Hare is a pure Go database management system that stores each table as a
> text file of line-delimited JSON. Each line of JSON represents a record. It
> is a good fit for applications that require a simple embedded DBMS.
>
> Here is the github repo: https://github.com/jameycribbs/hare
>
> Feedback is welcome!
>
> --
> 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/654ec351-fd36-45d0-a446-07fa2e5985f6n%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/CAE%3DAWBUo6CqA0Xn3V%2BeTvfH%3DWV5%2BBRf1Yz_r5e%2BcARbuD_KsaQ%40mail.gmail.com.

Re: [go-nuts] Error handling

[Arnaud Delobelle]

I do sometimes do something similar, but without the check() function.
The exit points are explicit, it is guaranteed that errors will be
wrapped.

func do(name string) (err error) {
defer PWrapf(, "do(%s)", name)

s, err := works(name);
if err != nil {
return err
}

// ...
}

// PWrapf applies Wrapf to an error pointer
func PWrapf(err *error, format string, args ...interface{}) {
*err = errors.Wrapf(*err, format, args...)
}

On Sun, 14 Feb 2021 at 01:45, Michael MacInnis
 wrote:
>
> I've been playing around with reducing error handling boilerplate using 
> standard language constructs.
>
> I'm currently doing something that looks like this:
>
> import (
> "github.com/michaelmacinnis/handle"
> )
>
> func do(name string) (err error) {
> check, handle := handle.Errorf(, "do(%s)", name); defer handle()
>
> s, err := works(name); check(err)
>
> // ...
> }
>
> Other than the named return value and check being a hidden return, are there 
> reasons I would want to avoid doing this? I assume others have tried similar 
> things but I haven't stumbled across any similar packages.
>
> Before using it in production I would probably want a linter that checks to 
> make sure that the statement after handle.Error or handle.Errorf is defer 
> blah, where blah is the name given to the second value returned by those 
> functions and that all of this happens at the start of a function.
>
> Michael.
>
> --
> 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/cbe53d07-4f99-49fa-a708-dcb85b1aff5bn%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/CAJ6cK1ZgvpGV_vUFwHc%2BbadJXcoJO%3Dwv4-tfaWTYqjQbM%2BOMMg%40mail.gmail.com.

[go-nuts] [ANN] Hare - a nimble little DBMS written in Go.

[Jamey Cribbs]

After working on this package off and on for a long time, I've finally 
decided to set it free into the wild. 

Hare is a pure Go database management system that stores each table as a 
text file of line-delimited JSON. Each line of JSON represents a record. It 
is a good fit for applications that require a simple embedded DBMS.

Here is the github repo: https://github.com/jameycribbs/hare

Feedback is welcome!

-- 
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/654ec351-fd36-45d0-a446-07fa2e5985f6n%40googlegroups.com.

Re: [go-nuts] Error handling

[Volker Dobler]

I think there is strong consensus, that the current style of error handling 
is currently the best option. Nobody has been able to come up with 
something better (really better, not just more comfortable while ignoring 
hefty drawbacks).

It is true that a loud minority seems to miss exceptions to a point where 
they are unwilling to even try the language. How much their expertise 
counts if they never really worked with proper error handling in Go is 
debatable. Having worked with error returns and exceptions I can tell you 
that proper error handling with exceptions is much more painful than with 
errors. But of course: If your infrastructure, your business requirements 
and your acceptance criteria allow for making any problem a problem of 
someone else than exceptions are godsend.

V.

On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote:

> I think ’strong census’ is not accurate - thus the discussions around 
> improving error handling in Go2.
>
> Many have commented here and elsewhere that the number one reason they 
> don’t use Go is due to lack of exception handling.
>
> > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki  
> wrote:
> > 
> > Dnia 2021-02-13, o godz. 17:44:47
> > Michael MacInnis  napisał(a):
> > 
> >> I've been playing around with reducing error handling boilerplate
> > 
> > You're not alone. Hundreds of us went into such thinking in the first 
> weeks
> > of reading/using Go - yet before we noticed how much more productive we
> > are with Go's "boilerplate" than we were in languages where handling 
> errors
> > (failures) was "a problem of others", including future-us as "others".
> > 
> > Perceived consensus of the Go community is that "error handling 
> boilerplate"
> > is a strong feature. I.e. in normal production software you MUST handle 
> failures
> > and you should do it as close as possible to the source of said failure.
> > 
> > Go helps with that. Even team's proposal was finally retracted:
> > https://github.com/golang/go/issues/32437 Discussion there is lengthy, 
> but worth
> > reading to sense why wider community considers "boilerplate" as asset.
> > 
> > Error handling proposals umbrella: 
> https://github.com/golang/go/issues/40432
> > 
> >> Michael.
> > 
> > Hope this helps,
> > 
> > -- 
> > Wojciech S. Czarnecki
> > << ^oo^ >> OHIR-RIPE
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint
> .
>
>

-- 
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/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com.

Re: [go-nuts] big.Float.Cmp does not work as expected

[Jesper Louis Andersen]

On Sun, Feb 14, 2021 at 9:20 PM Santhosh Kumar T 
wrote:

> I created:
> one instance using big.NewFloat function
> another instance using big.Float.SetString method
>
>
Adding to this:

Generally, comparing FP values for equality can give results you don't
expect due to the way numerics for floating point values work. They almost
behave like normal numbers. In particular, you would like laws such as

(x + y) + z = x + (y + z)
(x * y) * z = x * (y * z)

to hold (which are the associative laws from math). But for floating point
numbers they don't due to rounding errors. Equality tests can also feel, as
you see. I know that the original problem is one about parsing, so the
underlying representation isn't the same. But if you want to compare
floating point numbers for equality it is often better to define a small
epsilon constant as something like 1e-06 or such and then compare if |x -
y| < epsilon.

For background, there are some good documents on the net about numerics of
FP. http://https://floating-point-gui.de/ is one such resource. If you want
the deep in-depth treatment I can recommend Knuth's "The Art of Computer
Programming Vol 2: Seminumerical Algorithms".

-- 
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/CAGrdgiU0AgN8r4JbRX-OXAGhVGgTQG5OnU7R-fgwwTJximT2WA%40mail.gmail.com.

Re: [go-nuts] Error handling

[Michael MacInnis]

>
> Go helps with that. Even team's proposal was finally retracted: 
> https://github.com/golang/go/issues/32437 Discussion there is lengthy, 
> but worth 
> reading to sense why wider community considers "boilerplate" as asset.
>

Thanks, I did follow the try proposal and the earlier check/handle proposal.

I agree that handling errors, and doing so close to where they occur, is a 
good thing. I also agree with the goals as outlined in the error handling 
problem statement. Specifically, that it would be nice if it was possible 
to make "error checks more lightweight, reducing the amount of Go program 
text dedicated to error checking". But that in doing so "error checks and 
error handling must remain explicit".

What I find interesting is how close we can get to something resembling try 
or check/handle with existing constructs.

While

f, err := os.Open(filename); check(err)
is not as terse as

f := try(os.Open(filename))

there is less much less text dedicated to error checking than with

f, err := os.Open(filename)
if err != nil {
// Handle err.
}

and passing err explicitly also means there isn't something to unwrap when 
debugging (to get to err) which I thought was an interesting objection to 
try.

Similarly, while

check, handle := handle.Errorf(, "copy %s %s", src, dst)
defer handle()

requires the enclosing function to use named return values and is not as 
terse as

handle err {
fmt.Errorf("copy %s %s: %v", src, dst, err)
}

it is close to the suggestion for decorating errors in the try proposal

defer fmt.HandleErrorf(, "copy %s %s", src, dst)

The problem is that forgetting to defer handle (in my version) means that 
check will cause an unrecovered panic. I'm also wondering if there are 
other interactions that I've overlooked. It is these more mechanism than 
policy considerations where I'm looking for feedback.

Michael.

-- 
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/f6673e29-1366-476a-8fcc-31f6a4efe22dn%40googlegroups.com.

Re: [go-nuts] about -buildmode c-shared

[Frédéric De Jaeger]

On Saturday, February 13, 2021 at 4:21:34 PM UTC+1 Ian Lance Taylor wrote:

>
>
> > I was naively assuming that the unloading issue is easy to tackle when 
> the runtime is not shared between .so. Is it true ? 
>
> No. The current Go runtime has no ability to shut down all 
> goroutines. If any goroutines are left running, and the plugin is 
> unloaded, the program will crash. 
>
>
I was not assuming a synchronous uncooperative way for the runtime to kill 
a running goroutine.  I was more thinking about some cooperative strategy. 
Like a running go routine could check sometimes (maybe in the function 
prologue, or when doing an allocation) that it is time to die.  
Anycase, that could be also a constraint of the business code in the 
plugin.  Like in C, they are not supposed to be actively running when the 
.so is *dlclosed*.
In fact, what happens in practice today if we *dlclose* a plugin that has 
no running goroutine (and also no cgo invocations).  Does it "*work*" 
somehow ?  Are we leaking threads, waiting on some dead semaphore or 
something ?


> > A last technical question, do you link the shared object with the ld 
> flag `- z nodelete` (which turn dlclose into no op). 
>
> As far as I know we do not. 
>
>
This `ld` flag makes me think of another approach.  Maybe it is  ok to just 
turn off the effective unloading of the .so (with that ld flag).  So 
*dlclose* is no-op.  But if the business code takes care of cleaning most 
of its global state, maybe the gc has the opportunity to return some memory 
back to the OS (well, since the gc is not moving stuff, maybe the hope is 
slim, I don't know).
That approach does not solve the problem of the developer iteratively 
working on a plugin.  Apart from that, this looks like an acceptable 
compromise for someone who wants to ship an loadable plugin that can be "
*unloaded*".  At least it *works* somehow, leaking a bit of memory.  But it 
does not crash.
Of course, it is expected that if I load *libfoo.so* unload it, and load it 
again, everything works.  I don't see why it would not.  The second *dlopen* 
is presumably no-op.

Now about the unique  runtime constraint.  In the previous message, you 
said that we might be able to run several runtimes in the same process 
(private runtime symbols, ...)
If that works, it would mean that if the runtime symbols are public, but 
*versioned*, then maybe the runtime constraint is gone, isn't it?  
If two lib *libfoo.so* and *libbar.so* are built with different runtimes, 
we get two instantiated runtime in the binary that loads them 
simultaneously.  Well, too bad, we lose a bit of memory, but at least it 
works.  It looks acceptable to me.
In the favorable case, they share the same runtime and every one is happy.

I am curious about what happens on MacOS today.  Because my understanding 
of their *two level namespace  
*(https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html#//apple_ref/doc/uid/TP40002850-BCIHJBBF)
 
implies that you instantiate a new runtime whenever you load a c-shared 
.dylib.  I'm not sure at all.  It seems there is a way to force a flat 
namespace (it does not seem to be the default, thought).  I haven't 
verified that yet.  By the way, what the most efficient way to detect if 
two runtime are being instantiated ?  Something like a debug log that is 
supposed to happen once, or a similar trick.

Thanks
Fred


-- 
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/edc90dd0-9f6d-4fbb-8629-db52b11ede42n%40googlegroups.com.

Re: [go-nuts] big.Float.Cmp does not work as expected

[roger peppe]

Thanks for bringing this up. It surprised me too until I realised what was
going on.

The issue here is about the default precision that you're getting for those
big.Float values.
When you use big.NewFloat, the precision you get is exactly the same as
that of a base64 float (53 bits).
When you use SetString, you're getting 64 bits. If you change both float
values to use the same
precision, you'll see a difference in representation:
https://play.golang.org/p/4tBpBsPgGtE

This is documented, although arguably not that easy to find:

For the precision used by big.NewFloat:

NewFloat allocates and returns a new Float set to x, with precision 53


For the precision set by SetString:

If z's precision is 0, it is changed to 64 before rounding takes effect.


For the string output when used with fmt.Print:

The 'v' format is handled like 'g'.



> A negative precision selects the smallest number of decimal digits
> necessary to identify the value x uniquely using x.Prec() mantissa bits.


Actually I don't think the docs explicitly say that a missing precision for
%g is treated as a negative precision passed to the Text method, which
could be considered a flaw in the docs.

 One other thing to be aware of: the String method doesn't do quite what
you might expect: https://github.com/golang/go/issues/42887

  cheers,
rog.

On Sun, 14 Feb 2021 at 21:33, Santhosh Kumar T 
wrote:

> now I understand it. why they are not same
>
> but why f2 printed as 123.4139
> f2 is constructed using SetString method, so it should be accurate and
> printed as 123.4000.
>
> - Santhosh
>
> On Monday, February 15, 2021 at 2:53:45 AM UTC+5:30 kortschak wrote:
>
>> On Sun, 2021-02-14 at 13:19 -0800, Santhosh Kumar T wrote:
>> > When I print both values, they print exactly same. so I am assuming
>> > no precision lost for this specific example 123.4.
>> > but still Cmp returns non-zero.
>>
>> This is not a good assumption to make, and is refuted by the result of
>> Cmp.
>>
>> https://play.golang.org/p/ROr6cHMzWIf
>>
>>
>>
>>
>> --
> 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/b6a82206-6660-4a08-85bd-86e482b8527en%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/CAJhgacg-ZzDSupwS%2BaXdKfoCWveHvsT8NnDUVmo8NpD8sY6McA%40mail.gmail.com.

[go-nuts] How to use atomic_int in cgo?

[changkun]

Hi golang-nuts,

I would like to call a C function from Go and get notified about the 
execution status in Go, say a goroutine wait until the C function finally 
made some progress.
Initially, I thought about passing a channel to C but the cgo document does 
not say anything about that:

Later, I am thinking about using an atomic variable to sync status 
according to its value, but somehow I end up with this warning while I am 
compiling a cgo program:

package main

/*
#include 
void ainit(atomic_int *val) {
atomic_init(val, 0);
}
*/
import "C"

func main() {
var v C.atomic_int
C.ainit()
}

cgo-gcc-prolog: In function ‘_cgo_8a67e594de48_Cfunc_ainit’:
cgo-gcc-prolog:49:14: warning: passing argument 1 of ‘ainit’ from 
incompatible pointer type [-Wincompatible-pointer-types]
./main.go:5:24: note: expected ‘_Atomic atomic_int *’ {aka ‘_Atomic int *’} 
but argument is of type ‘int *’
5 | void ainit(atomic_int *val) {
  |^~~

According to the warning and note, it seems that cgo is lacking translating 
atomic_init? Did I do anything wrong? Or is there any better and preferred 
way to get notified from C function?

-- 
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/b4e8b7c7-015d-4b9e-80ef-e49c07bea301n%40googlegroups.com.