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

[Santhosh T]

If it is not in stadnard library, then i will use the approach taken by
json.Number in stdlib

that seems simpler, let the users decide how to use it.

thanks
Santhosh

On Wed, Feb 17, 2021 at 3:02 AM Brian Candler  wrote:

> Not in the standard libraries. See (declined):
>
> https://github.com/golang/go/issues/12127
> https://github.com/golang/go/issues/12332
>
> However there are links to third-party libraries in those tickets.
>
> On Tuesday, 16 February 2021 at 21:04:30 UTC Santhosh T wrote:
>
>> is there java's BigDecimal equivalent in golang ?
>>
>> thanks
>> Santhosh
>>
>> On Wed, Feb 17, 2021 at 2:05 AM Brian Candler  wrote:
>>
>>> You compared Golang's BigFloat with Java's BigDecimal.  They are not the
>>> same.
>>>
>>> On Tuesday, 16 February 2021 at 20:30:28 UTC Santhosh T wrote:
>>>
 in Java, this is not case.

 BigDecimal v = new BigDecimal("123.4");
 System.out.printf("%.20f\n", v); // prints
 123.4000
 System.out.printf("%.40f\n", v); // prints
 123.4000

 you can see that it is represented exactly. I thought it was the same
 with big.Float in golang.

 thanks
 Santhosh


 On Tue, Feb 16, 2021 at 10:26 PM Brian Candler 
 wrote:

> On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:
>
>> 123.4 cannot be represented in binary with a finite number of bits.
>>
>>
> See:  https://0.30004.com/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/721b9ad4-32f0-4aeb-93e6-4fe757174b5dn%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e2fc093f-b730-4748-85d2-f85cdec6a29bn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e2bb6a46-02f0-4840-b147-c947f31a3ea8n%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/CABv5LKU_5Fs_0fnWD8QQB5q7k-Z11c11xAGdhDtx22X3%2BhueJg%40mail.gmail.com.

[go-nuts] Re: embed.FS and memory limitations

['Kevin Chowski' via golang-nuts]

If you had a simple test program or microbenchmark which put some numbers 
behind your concerns, I think you'll get a bit more traction. Have you 
tried to measure the effect of page faults on reading data from embedded 
files (or, I guess, any sort of data that has fallen out of the pagecache)? 
I'm interested in calibrating my gut, which is currently surprised that 
you're talking about page fault latency in the context of a 
garbage-collected language like Go, but I'm happy to be proven wrong :)

(And from a tuning side, if you're only concerned about tying up Ps I 
suspect you could increase GONUMPROCS to get threads "running", but of 
course that might cause trouble if you have something that is CPU-bounded 
in the server.)

On Tuesday, February 16, 2021 at 9:48:30 AM UTC-7 ca...@mercari.com wrote:

> Was going through the implementation of embed.FS and started wondering 
> about the lack of WriteTo - specifically about the implications in case 
> the embedded data is not present in memory e.g. because it got evicted due 
> to memory pressure - or simply due to outright not fitting in memory. Won’t 
> this tie Ps up while the data is faulted in, with no way for the scheduler 
> to park the offending Gs?
> The design doc discusses some arguments against adding WriteTo 
> 
>  
> but does not discuss the issue described above. Am I missing something?
> Obviously, WriteTo wouldn't solve this problem above for *all* cases 
> (e.g. all cases in which the WriteTo implementation is unable to bypass 
> the userspace copy) although it should help significantly when it does 
> (e.g. in case of embedded static files to be served over plain HTTP). Or 
> maybe reads from embed.FS instances could try to opportunistically 
> madvise(MADV_WILLNEED) and yield if mincore returns that the pages are 
> not (yet) resident in memory? Or the scheduler/sysmon should be taught how 
> to handle that case (e.g. with userfaultfd on Linux)?
>
> Carlo
>
>

-- 
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/b49a03e3-ead3-4c11-9044-85affe8e1017n%40googlegroups.com.

[go-nuts] Re: go get not working in Go 1.16

['Carla Pfaff' via golang-nuts]

On Tuesday, 16 February 2021 at 22:57:07 UTC+1 pkle...@xs4all.nl wrote:

> Also, you can't use local packages without a dot in the name.
>

I do this all the time.

-- 
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/61ae8671-1e1c-4136-9c3a-496297c5fd98n%40googlegroups.com.

[go-nuts] Re: go get not working in Go 1.16

[Peter Kleiweg]

Op dinsdag 16 februari 2021 om 21:40:52 UTC+1 schreef Ian Lance Taylor:

> On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg  wrote: 
> > 
> > `go get` is broken. It doesn't download packages. 
>
> Tell us what you did, what you expected to happen, and what happened 
> instead. Thanks. 
>
> Note that module support is now on by default 
> (https://golang.org/doc/go1.16#go-command), which can affect the 
> behavior of "go get". 
>
> Ian


 Ah, modules are the culprit. When I set `GO111MODULE=auto` everything 
works as it should.

Without `GO111MODULE=auto` :

 - `go get` doesn't download to $GOPATH/src
 - `go build` doesn't work with packages in `$GOPATH/src`

This means you can't use packages that need modification to an unusual 
environment.
Also, you can't use local packages without a dot in the name.

So why would you ever want to *not* set `GO111MODULE=auto` ?

-- 
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/44245bab-e577-4490-b5f4-02c465a5fae5n%40googlegroups.com.

Re: [go-nuts] Re: SQLite3 Support without CGo

[ben...@gmail.com]

Jan, is there any write-up about modernc.org/sqlite? I've dabbled in 
automated conversion, and I'm very curious if there's more information 
about how it works, any pitfalls / unsupported stuff, etc, but having 
trouble finding anything like that in the repos.


On Sunday, January 24, 2021 at 7:38:12 AM UTC+13 Jan Mercl wrote:

> On Sat, Jan 23, 2021 at 7:02 PM sup...@lieferpool.de
>  wrote:
>
> > If you want sqlite3 support without cgo, you might check out
> > https://github.com/cvilsmeier/sqinn-go
>
> Shameless plug: https://pkg.go.dev/modernc.org/sqlite
>

-- 
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/37809716-6deb-4b8b-be81-08a3c618cb17n%40googlegroups.com.

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

[Brian Candler]

Not in the standard libraries. See (declined):

https://github.com/golang/go/issues/12127
https://github.com/golang/go/issues/12332

However there are links to third-party libraries in those tickets.

On Tuesday, 16 February 2021 at 21:04:30 UTC Santhosh T wrote:

> is there java's BigDecimal equivalent in golang ?
>
> thanks
> Santhosh
>
> On Wed, Feb 17, 2021 at 2:05 AM Brian Candler  wrote:
>
>> You compared Golang's BigFloat with Java's BigDecimal.  They are not the 
>> same.
>>
>> On Tuesday, 16 February 2021 at 20:30:28 UTC Santhosh T wrote:
>>
>>> in Java, this is not case.
>>>
>>> BigDecimal v = new BigDecimal("123.4");
>>> System.out.printf("%.20f\n", v); // prints 
>>> 123.4000
>>> System.out.printf("%.40f\n", v); // prints 
>>> 123.4000
>>>
>>> you can see that it is represented exactly. I thought it was the same 
>>> with big.Float in golang.
>>>
>>> thanks
>>> Santhosh
>>>
>>>
>>> On Tue, Feb 16, 2021 at 10:26 PM Brian Candler  
>>> wrote:
>>>
 On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:

> 123.4 cannot be represented in binary with a finite number of bits. 
>
>
 See:  https://0.30004.com/ 

 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 golang-nuts...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/721b9ad4-32f0-4aeb-93e6-4fe757174b5dn%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e2fc093f-b730-4748-85d2-f85cdec6a29bn%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/e2bb6a46-02f0-4840-b147-c947f31a3ea8n%40googlegroups.com.

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

['Dan Kortschak' via golang-nuts]

On Wed, 2021-02-17 at 02:33 +0530, Santhosh T wrote:
> is there java's BigDecimal equivalent in golang ?

There is, for example https://github.com/shopspring/decimal. But you
should ask yourself why you need this.


-- 
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/9ec3d92f53e72009f0b5cbae61e8766a22522eff.camel%40kortschak.io.

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

[Santhosh T]

is there java's BigDecimal equivalent in golang ?

thanks
Santhosh

On Wed, Feb 17, 2021 at 2:05 AM Brian Candler  wrote:

> You compared Golang's BigFloat with Java's BigDecimal.  They are not the
> same.
>
> On Tuesday, 16 February 2021 at 20:30:28 UTC Santhosh T wrote:
>
>> in Java, this is not case.
>>
>> BigDecimal v = new BigDecimal("123.4");
>> System.out.printf("%.20f\n", v); // prints
>> 123.4000
>> System.out.printf("%.40f\n", v); // prints
>> 123.4000
>>
>> you can see that it is represented exactly. I thought it was the same
>> with big.Float in golang.
>>
>> thanks
>> Santhosh
>>
>>
>> On Tue, Feb 16, 2021 at 10:26 PM Brian Candler  wrote:
>>
>>> On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:
>>>
 123.4 cannot be represented in binary with a finite number of bits.


>>> See:  https://0.30004.com/
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/721b9ad4-32f0-4aeb-93e6-4fe757174b5dn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e2fc093f-b730-4748-85d2-f85cdec6a29bn%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/CABv5LKXTsHuetKffbHvS54V7txJdbacyTn5tnON%3DGuXVqkCemw%40mail.gmail.com.

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

[Fernando Meyer]

$ go get -u github.com/boyter/scc/
go: downloading github.com/boyter/scc v1.12.1
go: downloading github.com/boyter/scc v2.12.0+incompatible
go: downloading github.com/spf13/cobra v1.1.3
go: downloading golang.org/x/text v0.3.5
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading github.com/dbaggerman/cuba v0.3.2
go: downloading github.com/minio/blake2b-simd v0.0.0-20160723061019-3f5f724cb5b1
go: downloading github.com/monochromegane/go-gitignore 
v0.0.0-20200626010858-205db1a8cc00
~ took 12s
$ go get -u github.com/rakyll/gotest
go: downloading github.com/rakyll/gotest v0.0.5
go: downloading github.com/mattn/go-isatty v0.0.11
go: downloading golang.org/x/sys v0.0.0-20191026070338-33540a1f6037
go: downloading golang.org/x/sys v0.0.0-20210216163648-f7da38b97c65
~ took 3s
$ go version
go version go1.16 linux/amd64

I just tested on both linux and M1 and it's working for me. What OS have you 
tried? 

Are you facing any networking issues? 
Can you ping github.com? 


Best, 

--
  Fernando Meyer
 


On Tue, Feb 16, 2021, at 9:34 PM, Peter Kleiweg wrote:
> `go get` is broken. It doesn't download packages.
> 
> Op dinsdag 16 februari 2021 om 20:56:37 UTC+1 schreef Alex Rakoczy:
>> Hello gophers, 
>> 
>> We just released Go 1.16 
>> 
>> To find out what has changed in Go 1.16, read the release notes: 
>> https://golang.org/doc/go1.16 
>> 
>> You can download binary and source distributions from our download page: 
>> https://golang.org/dl/ 
>> 
>> If you have Go installed already, an easy way to try go1.16 
>> is by using the go command: 
>> $ go get golang.org/dl/go1.16 
>> $ go1.16 download 
>> 
>> To compile from source using a Git clone, update to the release with 
>> "git checkout go1.16" and build as usual. 
>> 
>> Thanks to everyone who contributed to the release! 
>> 
>> Cheers, 
>> Alex and Dmitri for 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/040e8124-7675-4767-9348-90ab88908ac8n%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/75cfd397-3570-4b99-949f-145dcf0db716%40www.fastmail.com.

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

[Brad Fitzpatrick]

Elaborate?

On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg  wrote:

> `go get` is broken. It doesn't download packages.
>
> Op dinsdag 16 februari 2021 om 20:56:37 UTC+1 schreef Alex Rakoczy:
>
>> Hello gophers,
>>
>> We just released Go 1.16
>>
>> To find out what has changed in Go 1.16, read the release notes:
>> https://golang.org/doc/go1.16
>>
>> You can download binary and source distributions from our download page:
>> https://golang.org/dl/
>>
>> If you have Go installed already, an easy way to try go1.16
>> is by using the go command:
>> $ go get golang.org/dl/go1.16
>> $ go1.16 download
>>
>> To compile from source using a Git clone, update to the release with
>> "git checkout go1.16" and build as usual.
>>
>> Thanks to everyone who contributed to the release!
>>
>> Cheers,
>> Alex and Dmitri for 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/040e8124-7675-4767-9348-90ab88908ac8n%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/CAFzRk03KRJ11E1KwNjXV7K5jui7uJ9Vp1N5OEppQYczD4OKJzA%40mail.gmail.com.

[go-nuts] go get not working in Go 1.16

[Ian Lance Taylor]

On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg  wrote:
>
> `go get` is broken. It doesn't download packages.

Tell us what you did, what you expected to happen, and what happened
instead.  Thanks.

Note that module support is now on by default
(https://golang.org/doc/go1.16#go-command), which can affect the
behavior of "go get".

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/CAOyqgcUz%3D2%2BG7TP3sb_RuOyxJM3Ojo3bVb-08LOr0WzLQUNEPA%40mail.gmail.com.

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

[Brian Candler]

You compared Golang's BigFloat with Java's BigDecimal.  They are not the 
same.

On Tuesday, 16 February 2021 at 20:30:28 UTC Santhosh T wrote:

> in Java, this is not case.
>
> BigDecimal v = new BigDecimal("123.4");
> System.out.printf("%.20f\n", v); // prints 123.4000
> System.out.printf("%.40f\n", v); // prints 
> 123.4000
>
> you can see that it is represented exactly. I thought it was the same with 
> big.Float in golang.
>
> thanks
> Santhosh
>
>
> On Tue, Feb 16, 2021 at 10:26 PM Brian Candler  wrote:
>
>> On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:
>>
>>> 123.4 cannot be represented in binary with a finite number of bits. 
>>>
>>>
>> See:  https://0.30004.com/ 
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/721b9ad4-32f0-4aeb-93e6-4fe757174b5dn%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/e2fc093f-b730-4748-85d2-f85cdec6a29bn%40googlegroups.com.

[go-nuts] Re: Go 1.16 is released

[Peter Kleiweg]

`go get` is broken. It doesn't download packages.

Op dinsdag 16 februari 2021 om 20:56:37 UTC+1 schreef Alex Rakoczy:

> Hello gophers,
>
> We just released Go 1.16
>
> To find out what has changed in Go 1.16, read the release notes:
> https://golang.org/doc/go1.16
>
> You can download binary and source distributions from our download page:
> https://golang.org/dl/
>
> If you have Go installed already, an easy way to try go1.16
> is by using the go command:
> $ go get golang.org/dl/go1.16
> $ go1.16 download
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.16" and build as usual.
>
> Thanks to everyone who contributed to the release!
>
> Cheers,
> Alex and Dmitri for 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/040e8124-7675-4767-9348-90ab88908ac8n%40googlegroups.com.

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

[Jan Mercl]

On Tue, Feb 16, 2021 at 9:30 PM Santhosh T  wrote:

> in Java, this is not case.

That compares decimal vs floating point representations. Those have
very different properties, for different usage patterns.

-- 
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-XJ5qMKPKXBChrCK3O3%3D7TekFLF887wMTcWP0bp0oddcg%40mail.gmail.com.

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

[Santhosh T]

in Java, this is not case.

BigDecimal v = new BigDecimal("123.4");
System.out.printf("%.20f\n", v); // prints 123.4000
System.out.printf("%.40f\n", v); // prints
123.4000

you can see that it is represented exactly. I thought it was the same with
big.Float in golang.

thanks
Santhosh


On Tue, Feb 16, 2021 at 10:26 PM Brian Candler  wrote:

> On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:
>
>> 123.4 cannot be represented in binary with a finite number of bits.
>>
>>
> See:  https://0.30004.com/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/3t9ao7qtrlM/unsubscribe.
> To unsubscribe from this group and all its topics, 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/721b9ad4-32f0-4aeb-93e6-4fe757174b5dn%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/CABv5LKWzc-T2C-w%2BkngtRQc8MurSXB%2BwNTZsndJSyzSYovaTsA%40mail.gmail.com.

[go-nuts] Go 1.16 is released

[Alex Rakoczy]

Hello gophers,

We just released Go 1.16

To find out what has changed in Go 1.16, read the release notes:
https://golang.org/doc/go1.16

You can download binary and source distributions from our download page:
https://golang.org/dl/

If you have Go installed already, an easy way to try go1.16
is by using the go command:
$ go get golang.org/dl/go1.16
$ go1.16 download

To compile from source using a Git clone, update to the release with
"git checkout go1.16" and build as usual.

Thanks to everyone who contributed to the release!

Cheers,
Alex and Dmitri for 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/CA%2BxaJdQA7pqS8yeRvXa6UFC_8_LD___qtt_QOY%2BYZg6Pn64R4Q%40mail.gmail.com.

Re: [go-nuts] The Generics Proposal has been accepted!

[David Skinner]

I have been so very much looking forward to Go 2.0 and generics. Getting it 
in 1.18 is the icing on the cake. I seriously did not think you could do it 
considering that everyone was pulling you in different directions. Well 
Done! Defining the job is 90% of the project. The coding and testing before 
you ship will likely be the other 90%. I am looking forward to testing the 
new product! Thanks.

On Friday, February 12, 2021 at 10:01:27 AM UTC-6 Amnon wrote:

> Thanks, Ian, for the correction, and for all the hard work...
> All much appreciated! 
>
> On Friday, 12 February 2021 at 15:49:57 UTC Ian Lance Taylor wrote:
>
>> On Fri, Feb 12, 2021 at 7:39 AM Amnon  wrote:
>> >
>> > And should be out in 1.17 (this Autumn).
>> >
>> > Congratulations to all those who made it happen,
>> > and to the Go team for making sure that the design was right before it
>> > was accepted.
>>
>> Thanks!
>>
>> But, a clarification: we are targeting the 1.18 release for generics,
>> not the 1.17 release. There is a lot of work to do.
>>
>> 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/8b505f67-a7f8-49e4-894c-3f5ad5134a8dn%40googlegroups.com.

Re: [go-nuts] Error handling

[David Skinner]

I wanted to express my thanks to Mickael McKinnus for his research.

I am someone who is quite happy with the error handling in Go as it lets me 
implement whatever I like, I must say it is obviously flawed from the 
standpoint that the proper constructs are not part of the language but part 
of our training. The discreet patterns I use are:

   - Handle errors that can be handled close to where they occur.
   - Report errors that cannot be handled because they were caused by the 
   calling function passing a bad parameter.
   - Panic on errors that prevent a function that MustComplete from 
   completing because they cannot be handled. 
   - Try a MustComplete() with recover from the panic that reports to the 
   User and or Developer the nature of the problem and how to resolve it 
   manually or at least add it to issues.
   - Ensure that no matter what happens, you do not corrupt the HDD, lockup 
   the hardware, CTD, or leave unexpected artefacts on the screen.

There is no one best way of dealing with errors but there are patterns for 
dealing with errors, if you only learn one pattern then you will not be 
writing good code (if you only have a hammer, everything looks like a nail).

Golang does not have error patterns that are clear and distinct for novice 
programmers and it does not inhibit advanced programmers from dealing with 
errors in whatever way they think appropriate.

A useful abstraction would be to simplify the error handling by 
identification of the type of pattern desired and use the most concise and 
yet easily understood way of writing it. Go has tools in place to allow 
each user to create a preprocessor for error handling or any other purpose 
but it would be nice if we were all on the same page.

On Monday, February 15, 2021 at 12:53:43 PM UTC-6 ren...@ix.netcom.com 
wrote:

> 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

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

[Brian Candler]

On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:

> 123.4 cannot be represented in binary with a finite number of bits. 
>
>
See:  https://0.30004.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/721b9ad4-32f0-4aeb-93e6-4fe757174b5dn%40googlegroups.com.

[go-nuts] embed.FS and memory limitations

[Carlo Alberto Ferraris]

Was going through the implementation of embed.FS and started wondering 
about the lack of WriteTo - specifically about the implications in case the 
embedded data is not present in memory e.g. because it got evicted due to 
memory pressure - or simply due to outright not fitting in memory. Won’t 
this tie Ps up while the data is faulted in, with no way for the scheduler 
to park the offending Gs?
The design doc discusses some arguments against adding WriteTo 

 
but does not discuss the issue described above. Am I missing something?
Obviously, WriteTo wouldn't solve this problem above for *all* cases (e.g. 
all cases in which the WriteTo implementation is unable to bypass the 
userspace copy) although it should help significantly when it does (e.g. in 
case of embedded static files to be served over plain HTTP). Or maybe reads 
from embed.FS instances could try to opportunistically 
madvise(MADV_WILLNEED) and yield if mincore returns that the pages are not 
(yet) resident in memory? Or the scheduler/sysmon should be taught how to 
handle that case (e.g. with userfaultfd on Linux)?

Carlo

-- 
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/66a3d0ba-d54e-4a36-8512-30f397f6ce2dn%40googlegroups.com.

[go-nuts] [ANN] star-tex: a Go engine for TeX

[Sebastien Binet]

hi there,

I'd like to introduce star-tex[1], a (Work In Progress) TeX engine.

it wraps the output of the official texlive tex.w WEB file (ie: C/C++
files) as a CGo package.

the idea is to replace in an adiabatical fashion the C bits with their
Go equivalent.

there's already code that can correctly decode TeX Font metrics files.

$> go get git.sr.ht/~sbinet/star-tex/cmd/star-tex

$> star-tex ./testdata/hello.tex out.div
$> dvipdf out.dvi
$> pdf out.pdf


PR and patches welcomed :)

-s

[1]: https://sr.ht/~sbinet/star-tex

-- 
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/tnlpJDSD6hTx9ultczM0GG3VStFSQDq0ijOvPKjtE%40cp3-web-016.plabs.ch.

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

[Santhosh Kumar T]

I change it to following:

type JSON struct{ Val interface{} }

thanks
Santhosh

On Tuesday, February 16, 2021 at 1:58:58 PM UTC+5:30 arn...@gmail.com wrote:

> You need you Json type to be a concrete type, e.g. (if the underlying type 
> is a string)
>
> type Json string
>
> Then users can try to assert that what they get is of concrete type Json
>
> Cheers,
>
> Arnaud
>
> On Tue, 16 Feb 2021, 08:20 Santhosh Kumar T,  wrote:
>
>> I am not using either json.Marshaler or json.Unmarshaller
>>
>> my project implements mysql binlog replication protocol
>>
>> i have a method:   fn nextRow() []interafce{}
>> which returns values in row as slice.
>> the row might contain VARCHAR and JSON type columns in mysql table 
>> definition
>> if actual json value for a row is string, then nextRow() return a slice 
>> containing two strings
>> to distinguish i am trying to returns []interface{}{"value1", 
>> Json("value2")}
>> but this seems does not solve the issue, since user of my library cannot 
>> check if it is json value or not
>>
>> thanks
>> Santhosh
>>
>> On Tuesday, February 16, 2021 at 1:32:07 PM UTC+5:30 
>> axel.wa...@googlemail.com wrote:
>>
>>> An interface type-assertion asserts that the dynamic value in the 
>>> interface (in this case it's `string`) implements the interface you are 
>>> asserting (in this case `myinterface`). As `myinterface` has no methods, 
>>> every value implements that interface.
>>>
>>> In general, a type-assertion will assert things about the dynamic value 
>>> stored in an interface. In that code, the dynamic value is `string` *either 
>>> way*. In one case, you assign a `string` to `interface{}`, in the other you 
>>> assign a `string` to `myinterface`. But both will ultimately store a 
>>> `string`. That's also why your first case, using `mystring` works as 
>>> expected - in that case, the dynamic type is `string` in one case and 
>>> `mystring` in the other (note that the dynamic type is *always* a "concrete 
>>> type", not an interface).
>>>
>>> In general, ways to get around this is to either a) not use an 
>>> interface, or b) give that interface a method only specific types 
>>> implement, or c) store a `*myinterface` - it's a pointer, not an interface, 
>>> thus a concrete type, which can be distinguished. However, in your case, 
>>> neither of these strategies would likely be fruitful. The `json` package 
>>> needs to know how to store the values it decodes and it won't be able to, 
>>> if it doesn't have a concrete type or a `json.Unmarshaler`.
>>>
>>> So in your specific case, you might want to consider using something like
>>>
>>> type struct {
>>> s string
>>> n int64
>>> isString bool
>>> }
>>>
>>> and have that implement `json.Marshaler` and `json.Unmarshaler`.
>>>
>>> On Tue, Feb 16, 2021 at 8:47 AM Santhosh Kumar T  
>>> wrote:
>>>
 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...@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
  
 
 .

>>> -- 
>> 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/41a88e9f-8301-4717-b07c-b067c687ad1cn%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/3fa06aea-9ae6-44b7-8f5f-f6bddb

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

[Arnaud Delobelle]

You need you Json type to be a concrete type, e.g. (if the underlying type
is a string)

type Json string

Then users can try to assert that what they get is of concrete type Json

Cheers,

Arnaud

On Tue, 16 Feb 2021, 08:20 Santhosh Kumar T, 
wrote:

> I am not using either json.Marshaler or json.Unmarshaller
>
> my project implements mysql binlog replication protocol
>
> i have a method:   fn nextRow() []interafce{}
> which returns values in row as slice.
> the row might contain VARCHAR and JSON type columns in mysql table
> definition
> if actual json value for a row is string, then nextRow() return a slice
> containing two strings
> to distinguish i am trying to returns []interface{}{"value1",
> Json("value2")}
> but this seems does not solve the issue, since user of my library cannot
> check if it is json value or not
>
> thanks
> Santhosh
>
> On Tuesday, February 16, 2021 at 1:32:07 PM UTC+5:30
> axel.wa...@googlemail.com wrote:
>
>> An interface type-assertion asserts that the dynamic value in the
>> interface (in this case it's `string`) implements the interface you are
>> asserting (in this case `myinterface`). As `myinterface` has no methods,
>> every value implements that interface.
>>
>> In general, a type-assertion will assert things about the dynamic value
>> stored in an interface. In that code, the dynamic value is `string` *either
>> way*. In one case, you assign a `string` to `interface{}`, in the other you
>> assign a `string` to `myinterface`. But both will ultimately store a
>> `string`. That's also why your first case, using `mystring` works as
>> expected - in that case, the dynamic type is `string` in one case and
>> `mystring` in the other (note that the dynamic type is *always* a "concrete
>> type", not an interface).
>>
>> In general, ways to get around this is to either a) not use an interface,
>> or b) give that interface a method only specific types implement, or c)
>> store a `*myinterface` - it's a pointer, not an interface, thus a concrete
>> type, which can be distinguished. However, in your case, neither of these
>> strategies would likely be fruitful. The `json` package needs to know how
>> to store the values it decodes and it won't be able to, if it doesn't have
>> a concrete type or a `json.Unmarshaler`.
>>
>> So in your specific case, you might want to consider using something like
>>
>> type struct {
>> s string
>> n int64
>> isString bool
>> }
>>
>> and have that implement `json.Marshaler` and `json.Unmarshaler`.
>>
>> On Tue, Feb 16, 2021 at 8:47 AM Santhosh Kumar T 
>> wrote:
>>
>>> 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...@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
>>> 
>>> .
>>>
>> --
> 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/41a88e9f-8301-4717-b07c-b067c687ad1cn%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/CAJ6cK1Y7-SYpJYp_Bpswz9Z1MD5pFdzvbvwRxnC14wg5boLfog%40mail.gmail.com.

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

[Santhosh Kumar T]

I am not using either json.Marshaler or json.Unmarshaller

my project implements mysql binlog replication protocol

i have a method:   fn nextRow() []interafce{}
which returns values in row as slice.
the row might contain VARCHAR and JSON type columns in mysql table 
definition
if actual json value for a row is string, then nextRow() return a slice 
containing two strings
to distinguish i am trying to returns []interface{}{"value1", 
Json("value2")}
but this seems does not solve the issue, since user of my library cannot 
check if it is json value or not

thanks
Santhosh

On Tuesday, February 16, 2021 at 1:32:07 PM UTC+5:30 
axel.wa...@googlemail.com wrote:

> An interface type-assertion asserts that the dynamic value in the 
> interface (in this case it's `string`) implements the interface you are 
> asserting (in this case `myinterface`). As `myinterface` has no methods, 
> every value implements that interface.
>
> In general, a type-assertion will assert things about the dynamic value 
> stored in an interface. In that code, the dynamic value is `string` *either 
> way*. In one case, you assign a `string` to `interface{}`, in the other you 
> assign a `string` to `myinterface`. But both will ultimately store a 
> `string`. That's also why your first case, using `mystring` works as 
> expected - in that case, the dynamic type is `string` in one case and 
> `mystring` in the other (note that the dynamic type is *always* a "concrete 
> type", not an interface).
>
> In general, ways to get around this is to either a) not use an interface, 
> or b) give that interface a method only specific types implement, or c) 
> store a `*myinterface` - it's a pointer, not an interface, thus a concrete 
> type, which can be distinguished. However, in your case, neither of these 
> strategies would likely be fruitful. The `json` package needs to know how 
> to store the values it decodes and it won't be able to, if it doesn't have 
> a concrete type or a `json.Unmarshaler`.
>
> So in your specific case, you might want to consider using something like
>
> type struct {
> s string
> n int64
> isString bool
> }
>
> and have that implement `json.Marshaler` and `json.Unmarshaler`.
>
> On Tue, Feb 16, 2021 at 8:47 AM Santhosh Kumar T  
> wrote:
>
>> 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...@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
>>  
>> 
>> .
>>
>

-- 
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/41a88e9f-8301-4717-b07c-b067c687ad1cn%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

An interface type-assertion asserts that the dynamic value in the interface
(in this case it's `string`) implements the interface you are asserting (in
this case `myinterface`). As `myinterface` has no methods, every value
implements that interface.

In general, a type-assertion will assert things about the dynamic value
stored in an interface. In that code, the dynamic value is `string` *either
way*. In one case, you assign a `string` to `interface{}`, in the other you
assign a `string` to `myinterface`. But both will ultimately store a
`string`. That's also why your first case, using `mystring` works as
expected - in that case, the dynamic type is `string` in one case and
`mystring` in the other (note that the dynamic type is *always* a "concrete
type", not an interface).

In general, ways to get around this is to either a) not use an interface,
or b) give that interface a method only specific types implement, or c)
store a `*myinterface` - it's a pointer, not an interface, thus a concrete
type, which can be distinguished. However, in your case, neither of these
strategies would likely be fruitful. The `json` package needs to know how
to store the values it decodes and it won't be able to, if it doesn't have
a concrete type or a `json.Unmarshaler`.

So in your specific case, you might want to consider using something like

type struct {
s string
n int64
isString bool
}

and have that implement `json.Marshaler` and `json.Unmarshaler`.

On Tue, Feb 16, 2021 at 8:47 AM Santhosh Kumar T 
wrote:

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

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