Re: [go-nuts] Pointer to a pointer

['Dan Kortschak' via golang-nuts]

On Wed, 2022-03-09 at 18:58 -0800, shan...@gmail.com wrote:
> This morning someone asked about dereferincing a pointer to a pointer
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer,
> but some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum
> * is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?

I think aspects of this thread are sad. None of us know the background
of the OP and this kind of thinking illustrates a joyful level of
curiosity that could have been answered in a way that helps the
questioner and build a positive community (for Shane, Rob did answer it
and in way that is really quite deep, and thinking about how he
answered it will teach you something that is worth learning).

Calling a question "silly" demeans the questioner without understanding
where they are coming from.

Dan


-- 
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/2ca392b4dd00815102200177bde7186d11e8e9ba.camel%40kortschak.io.

Re: [go-nuts] Pointer to a pointer

[peterGo]

Kurtis Rader,

Stop it. When you are in a hole, stop digging.

When you don't understand a question or topic, don't launch ad hominem 
attacks, calling people's questions silly. That's nasty and it's against 
the Go Code of Conduct.

Like Jan, Rob, and Volker, I found it to be an interesting question, worthy 
of an answer. I wrote a program and looked at the executable code. Are we 
silly too?

Peter

On Thursday, March 10, 2022 at 12:29:54 AM UTC-5 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it 
>> is you think you know, but that's a really *really* poor response
>>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
>  
>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 A linked list, for example, consists of pointers to pointers to 
 pointers...

 Why should any limit exist to the length of the list except resources 
 available?

>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 
>>> 64? Etcetera levels of indirection supported when defining a function. It's 
>>> a silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>  
>>>
 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
 wrote:

> This morning someone asked about dereferincing a pointer to a pointer 
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * 
> is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> -- 
> 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
  
 
 .

>>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> 

[go-nuts] Pod memory keeps on increasing and restart with error OOMKilled

[Rakesh K R]

HI,
I have a micro service application deployed on kubernetes cluster(with 1gb 
of pod memory limit). This app receive continuous messages(500 message per 
second) from producer app over kafka interface(these messages are encoded 
in protobuf format.)

*Basic application flow:*
1. Get the message one by one from kafka
2. unmarshal proto message
3. apply business logic
4. write the message to redis cache(in []byte format)

When pod starts memory will be around 50mb and memory starts increasing as 
traffic flows into the application. It is never released back to OS. As a 
result pod restarts with error code *OOMKilled*.
I have integrated grafana to see memory usage like RSS, heap, stack.
During this traffic flow, in-use heap size is 80mb, idle heap is 80mb where 
as process resident memory is at 800-1000MB. Stopping the traffic 
completely for hours did not help and RSS continue to remain in 1000mb.
Tried to analyze this with pprof and it reports only 80mb are in in-use 
section. So I am wondering where these remaining 800-1000mb of pods memory 
went. Also application allocates memory like slices/maps/strings to perform 
business logic(see alloc_space pprof output below)

I tried couple of experiments:
1. Calling FreeOsMemory() in the app but that did not help
2. invoking my app with GODEBUG=madvdontneed=1 my_app_executable and did 
not help
3. Leaving the application for 5-6hrs without any traffic to see whether 
memory comes down. It did not help
4. pprof shows only 80mb of heap in use
5. Tried upgrading golang version from 1.13 to 1.16 as there were some 
improvements in runtime. It did not help

pprof output for *alloc_space*:

(pprof) top20
Showing nodes accounting for 481.98GB, 91.57% of 526.37GB total
Dropped 566 nodes (cum <= 2.63GB)
Showing top 20 nodes out of 114
  flat  flat%   sum%cum   cum%
   78.89GB 14.99% 14.99%78.89GB 14.99% 
 github.com/go-redis/redis/v7/internal/proto.(*Reader).readStringReply
   67.01GB 12.73% 27.72%   285.33GB 54.21% 
 airgroup/internal/wrapper/agrediswrapper.GetAllConfigurationForGroups
   58.75GB 11.16% 38.88%58.75GB 11.16% 
 google.golang.org/protobuf/internal/impl.(*MessageInfo).MessageOf
   52.26GB  9.93% 48.81%52.26GB  9.93%  reflect.unsafe_NewArray
   45.78GB  8.70% 57.50%46.38GB  8.81% 
 encoding/json.(*decodeState).literalStore
   36.98GB  7.02% 64.53%36.98GB  7.02%  reflect.New
   28.20GB  5.36% 69.89%28.20GB  5.36% 
 gopkg.in/confluentinc/confluent-kafka-go.v1/kafka._Cfunc_GoBytes
   25.60GB  4.86% 74.75%63.62GB 12.09% 
 google.golang.org/protobuf/proto.MarshalOptions.marshal
   12.79GB  2.43% 77.18%   165.56GB 31.45% 
 encoding/json.(*decodeState).object
   12.73GB  2.42% 79.60%12.73GB  2.42%  reflect.mapassign
   11.05GB  2.10% 81.70%63.31GB 12.03%  reflect.MakeSlice
   10.06GB  1.91% 83.61%12.36GB  2.35% 
 filterServersForDestinationDevicesAndSendToDistributionChan
6.92GB  1.32% 84.92%   309.45GB 58.79% 
 groupAndSendToConfigPolicyChannel
6.79GB  1.29% 86.21%48.85GB  9.28% 
 publishInternalMsgToDistributionService
6.79GB  1.29% 87.50%   174.81GB 33.21%  encoding/json.Unmarshal
6.14GB  1.17% 88.67% 6.14GB  1.17% 
 google.golang.org/protobuf/internal/impl.consumeBytes
4.64GB  0.88% 89.55%14.39GB  2.73%  GetAllDevDataFromGlobalDevDataDb
4.11GB  0.78% 90.33%18.47GB  3.51%  GetAllServersFromServerRecordDb
3.27GB  0.62% 90.95% 3.27GB  0.62%  net.HardwareAddr.String
3.23GB  0.61% 91.57% 3.23GB  0.61%  reflect.makemap
(pprof)


Need experts help in analyzing this issue.

Thanks in advance!!

-- 
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/372b8f8f-d276-44a4-a6e2-e2b7ad393eb9n%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

Is this really how you want to be known?


On Thursday, March 10, 2022 at 4:44:52 PM UTC+11 Rob 'Commander' Pike wrote:

> Here's a program with 1000 *s. You can see the pattern, make it any
> number you like.
>
> https://go.dev/play/p/FZXWcQTutEG
>
> // You can edit this code!
> // Click here and start typing.
> package main
>
> import "fmt"
>
> type self *self
>
> func main() {
> var p self
> p = 
>
> fmt.Println(p)
> }
>
>
> -rob
>
> On Thu, Mar 10, 2022 at 4:29 PM Kurtis Rader  wrote:
> >
> > On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
> >>
> >> Um
> >>
> >> Really?
> >>
> >> Which of these things are you specifically trying to prevent happening
> >> - Curiousity
> >> - Creativity
> >> - Asking questions
> >> - Some combination of the above
> >>
> >> I mean, I appreciate that you think that people should *know* whatever 
> it is you think you know, but that's a really *really* poor response
> >
> >
> > Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
> >
> >>
> >> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
> >>>
> >>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
> 
>  A linked list, for example, consists of pointers to pointers to 
> pointers...
> 
>  Why should any limit exist to the length of the list except resources 
> available?
> >>>
> >>>
> >>> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera. For example, if
> >>>
> >>> func wtf(i int) {
> >>> }
> >>>
> >>> is supported, which has eight levels of indirection, why isn't 16? 32? 
> 64? Etcetera levels of indirection supported when defining a function. It's 
> a silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
> >>>
> 
>  On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
> wrote:
> >
> > This morning someone asked about dereferincing a pointer to a 
> pointer to a pointer
> >
> > At first nobody had ever thought about, let alone knew the answer, 
> but some example code was shown, and sure enough ***val is possible
> > ```
> > package main
> >
> > import "fmt"
> >
> > func main() {
> > a := 0
> > b := 
> > c := 
> > UltimatePointOne()
> > fmt.Println(a)
> > }
> >
> > func UltimatePointOne(n ***int) {
> > ***n = 1
> > }
> > ```
> >
> >
> > On a lark a go playground example was tried to find what the maximum 
> * is in Go
> >
> > https://go.dev/play/p/YhibY3p7TSD
> >
> > There's 28 there, but it's not the limit
> >
> > Does anyone know what the upper bound on this could be?
> >
> > 256 * ?
> >
> > 32k * ?
> >
> > --
> > 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
> .
> 
>  

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

> The limit is going to be both platform dependent and dependent on the 
resources (e.g., memory) available on the platform. 

Then this is the answer you should have started with

> absolutely no one will ever write a function that gets within many orders 
of magnitude of the limit

I mean, nobody will ever go to the stars, so nobody should ask what it 
would take to get their, right

That's really bad. That's attacking "creativity" and "curiousity" both at 
the same time

> So your question is interesting in a hypothetical sense 

This is also "curiousity" - learn to recognise it so you don't stifle it in 
future.



On Thursday, March 10, 2022 at 4:29:54 PM UTC+11 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it 
>> is you think you know, but that's a really *really* poor response
>>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
>  
>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 A linked list, for example, consists of pointers to pointers to 
 pointers...

 Why should any limit exist to the length of the list except resources 
 available?

>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 
>>> 64? Etcetera levels of indirection supported when defining a function. It's 
>>> a silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>  
>>>
 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
 wrote:

> This morning someone asked about dereferincing a pointer to a pointer 
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * 
> is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> -- 
> 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
  
 
 .

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

[go-nuts] Re: Pointer to a pointer

[Volker Dobler]

>
>
> Does anyone know what the upper bound on this could be?
>
>
Yes, I do: math.MaxUint64 !

The nice thing about upper bounds is that they can be larger than
the least upper bound :-) 

V.

-- 
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/5d61c9a6-b724-4598-9f29-d55d825fb6e8n%40googlegroups.com.

[go-nuts] Download a zip file from a URL

[Gaurav]

I am trying to download a zip file using a simple http Get. This program 
downloads the file but the downloaded file is corrupted.

package main
import (
"fmt"
"io"
"net/http"
"os"
)

func DownloadFile(url string) error {
resp, err := http.Get(url)
if err != nil {
return err
}
defer resp.Body.Close()

filepath := "test.zip"

_, err = os.Stat(filepath)
if err == nil {
err := os.Remove(filepath)
if err != nil {
return err
}
}

out, err := os.Create(filepath)
if err != nil {
return err
}
defer out.Close()

_, err = io.Copy(out, resp.Body)
if err != nil {
return err
}

return nil
}

func main() {
err := 
DownloadFile("https://store1.gofile.io/download/78f1898f-2b02-465a-a39c-4cf7e35822a2/test.zip;)
if err != nil {
fmt.Println(err)
}
}

What am I missing here? Regards
Gaurav

-- 
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/68254497-0003-43dc-99e7-db96a6374390n%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Rob Pike]

Here's a program with 1000 *s. You can see the pattern, make it any
number you like.

https://go.dev/play/p/FZXWcQTutEG

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

type self *self

func main() {
var p self
p = 
fmt.Println(p)
}


-rob

On Thu, Mar 10, 2022 at 4:29 PM Kurtis Rader  wrote:
>
> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  wrote:
>>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it is 
>> you think you know, but that's a really *really* poor response
>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental limits 
> imposed by the Go language or the platform it runs on absolutely no one will 
> ever write a function that gets within many orders of magnitude of the limit. 
> So your question is interesting in a hypothetical sense but not in a 
> practical sense. For the former I suggest you start a research project and 
> write a paper for review that explains why, or why not, the existing limit is 
> a problem.
>
>>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:

 A linked list, for example, consists of pointers to pointers to pointers...

 Why should any limit exist to the length of the list except resources 
 available?
>>>
>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 64? 
>>> Etcetera levels of indirection supported when defining a function. It's a 
>>> silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>

 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>
> This morning someone asked about dereferincing a pointer to a pointer to 
> a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * is 
> in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> --
> 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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] Pointer to a pointer

[Kurtis Rader]

On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com 
wrote:

> Um
>
> Really?
>
> Which of these things are you specifically trying to prevent happening
>  - Curiousity
>  - Creativity
>  - Asking questions
>  - Some combination of the above
>
> I mean, I appreciate that you think that people should *know* whatever it
> is you think you know, but that's a really *really* poor response
>

Yes, your question was silly. The limit is going to be both platform
dependent and dependent on the resources (e.g., memory) available on the
platform. Your question is silly because regardless of the fundamental
limits imposed by the Go language or the platform it runs on absolutely no
one will ever write a function that gets within many orders of magnitude of
the limit. So your question is interesting in a hypothetical sense but not
in a practical sense. For the former I suggest you start a research project
and write a paper for review that explains why, or why not, the existing
limit is a problem.


> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>
>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>
>>> A linked list, for example, consists of pointers to pointers to
>>> pointers...
>>>
>>> Why should any limit exist to the length of the list except resources
>>> available?
>>>
>>
>> Yes, but the O.P. was asking about a silly example. Specifically, when
>> defining a function that receives pointers how many levels of indirection
>> are allowed in the declaration. In practice 99.9% of the time a single
>> level of indirection is specified and 0.09% of the time two levels are
>> specified. Etcetera.  For example, if
>>
>> func wtf(i int) {
>> }
>>
>> is supported, which has eight levels of indirection, why isn't 16? 32?
>> 64? Etcetera levels of indirection supported when defining a function. It's
>> a silly question that shows the O.P. doesn't understand how compilers work.
>> Let alone how people use languages like Go in real life.
>>
>>
>>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>>>
 This morning someone asked about dereferincing a pointer to a pointer
 to a pointer

 At first nobody had ever thought about, let alone knew the answer, but
 some example code was shown, and sure enough ***val is possible
 ```
 package main

 import "fmt"

 func main() {
 a := 0
 b := 
 c := 
 UltimatePointOne()
 fmt.Println(a)
 }

 func UltimatePointOne(n ***int) {
 ***n = 1
 }
 ```


 On a lark a go playground example was tried to find what the maximum *
 is in Go

 https://go.dev/play/p/YhibY3p7TSD

 There's 28 there, but it's not the limit

 Does anyone know what the upper bound on this could be?

 256 * ?

 32k * ?

 --
 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/974ff13d-59ff-41f5-90a2-9a3ccd08f10dn%40googlegroups.com
> 
> .
>


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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

Um

Really?

Which of these things are you specifically trying to prevent happening
 - Curiousity
 - Creativity
 - Asking questions
 - Some combination of the above


I mean, I appreciate that you think that people should *know* whatever it 
is you think you know, but that's a really *really* poor response

On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> A linked list, for example, consists of pointers to pointers to 
>> pointers...
>>
>> Why should any limit exist to the length of the list except resources 
>> available?
>>
>
> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera.  For example, if
>
> func wtf(i int) {
> }
>
> is supported, which has eight levels of indirection, why isn't 16? 32? 64? 
> Etcetera levels of indirection supported when defining a function. It's a 
> silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
>  
>
>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>>
>>> This morning someone asked about dereferincing a pointer to a pointer to 
>>> a pointer
>>>
>>> At first nobody had ever thought about, let alone knew the answer, but 
>>> some example code was shown, and sure enough ***val is possible
>>> ```
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> a := 0
>>> b := 
>>> c := 
>>> UltimatePointOne()
>>> fmt.Println(a)
>>> }
>>>
>>> func UltimatePointOne(n ***int) {
>>> ***n = 1
>>> }
>>> ```
>>>
>>>
>>> On a lark a go playground example was tried to find what the maximum * 
>>> is in Go
>>>
>>> https://go.dev/play/p/YhibY3p7TSD
>>>
>>> There's 28 there, but it's not the limit
>>>
>>> Does anyone know what the upper bound on this could be?
>>>
>>> 256 * ?
>>>
>>> 32k * ?
>>>
>>> -- 
>>> 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/974ff13d-59ff-41f5-90a2-9a3ccd08f10dn%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Kurtis Rader]

On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:

> A linked list, for example, consists of pointers to pointers to pointers...
>
> Why should any limit exist to the length of the list except resources
> available?
>

Yes, but the O.P. was asking about a silly example. Specifically, when
defining a function that receives pointers how many levels of indirection
are allowed in the declaration. In practice 99.9% of the time a single
level of indirection is specified and 0.09% of the time two levels are
specified. Etcetera.  For example, if

func wtf(i int) {
}

is supported, which has eight levels of indirection, why isn't 16? 32? 64?
Etcetera levels of indirection supported when defining a function. It's a
silly question that shows the O.P. doesn't understand how compilers work.
Let alone how people use languages like Go in real life.


> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>
>> This morning someone asked about dereferincing a pointer to a pointer to
>> a pointer
>>
>> At first nobody had ever thought about, let alone knew the answer, but
>> some example code was shown, and sure enough ***val is possible
>> ```
>> package main
>>
>> import "fmt"
>>
>> func main() {
>> a := 0
>> b := 
>> c := 
>> UltimatePointOne()
>> fmt.Println(a)
>> }
>>
>> func UltimatePointOne(n ***int) {
>> ***n = 1
>> }
>> ```
>>
>>
>> On a lark a go playground example was tried to find what the maximum * is
>> in Go
>>
>> https://go.dev/play/p/YhibY3p7TSD
>>
>> There's 28 there, but it's not the limit
>>
>> Does anyone know what the upper bound on this could be?
>>
>> 256 * ?
>>
>> 32k * ?
>>
>> --
>> 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
> 
> .
>


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

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

Re: [go-nuts] Pointer to a pointer

[Jan Mercl]

A linked list, for example, consists of pointers to pointers to pointers...

Why should any limit exist to the length of the list except resources
available?

On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:

> This morning someone asked about dereferincing a pointer to a pointer to a
> pointer
>
> At first nobody had ever thought about, let alone knew the answer, but
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * is
> in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> --
> 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com.

Re: [go-nuts] Example of printing in go.dev

[Kurtis Rader]

On Wed, Mar 9, 2022 at 7:44 PM Nikhilesh Susarla 
wrote:

> Okay. I get it.
> When I ran through go playground I missed that type receiver was of
> pointer type, so I was not sure why it didn't print as mentioned in the docs
>

It doesn't matter that the receiver "was of pointer type". That's just an
optimization to avoid copying a, possibly large, object before calling it's
String() method. Go ahead and modify the example to use a non-pointer
receiver. It should behave the same (it does for me).


> On Thursday, 10 March 2022 at 09:00:49 UTC+5:30 kortschak wrote:
>
>> On Wed, 2022-03-09 at 19:16 -0800, Nikhilesh Susarla wrote:
>> > In https://go.dev/doc/effective_go#printing
>> > I saw an example for printing our custom string output for the type.
>> > The code below is from docs.
>> > func (t *T) String() string {
>> > return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
>> > }
>> > fmt.Printf("%v\n", t)
>> >
>> >
>> > But rather the statement should be this right? fmt.Printf("%v\n",
>> > t.String())
>> > Am I missing something?
>> >
>>
>> When the %v (or %s, %q and others[1]) verbs are used the `String()
>> string` is used to construct the printed value.
>>
>> You can see the logic here[2].
>>
>> [1]
>>
>> https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L611
>> [2]
>>
>> https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L623-L628
>>
>>
>> --
> 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/782337ca-4051-414a-a809-a6f88f5ffab1n%40googlegroups.com
> 
> .
>


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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD871uERNB9HoLHK_Ptig%3DzpP%3DwfZQh2pCJkMTSWZEpw-A%40mail.gmail.com.

Re: [go-nuts] Example of printing in go.dev

[Nikhilesh Susarla]

Okay. I get it. 
When I ran through go playground I missed that type receiver was of pointer 
type, so I was not sure why it didn't print as mentioned in the docs

Thank you
On Thursday, 10 March 2022 at 09:00:49 UTC+5:30 kortschak wrote:

> On Wed, 2022-03-09 at 19:16 -0800, Nikhilesh Susarla wrote:
> > In https://go.dev/doc/effective_go#printing
> > I saw an example for printing our custom string output for the type.
> > The code below is from docs.
> > func (t *T) String() string {
> > return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
> > }
> > fmt.Printf("%v\n", t)
> >
> >
> > But rather the statement should be this right? fmt.Printf("%v\n",
> > t.String())
> > Am I missing something?
> >
>
> When the %v (or %s, %q and others[1]) verbs are used the `String()
> string` is used to construct the printed value.
>
> You can see the logic here[2].
>
> [1]
>
> https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L611
> [2]
>
> https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L623-L628
>
>
>

-- 
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/782337ca-4051-414a-a809-a6f88f5ffab1n%40googlegroups.com.

Re: [go-nuts] Example of printing in go.dev

[Kurtis Rader]

On Wed, Mar 9, 2022 at 7:18 PM Nikhilesh Susarla 
wrote:

> In https://go.dev/doc/effective_go#printing
> I saw an example for printing our custom string output for the type.
> The code below is from docs.
> func (t *T) String() string {
> return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
> }
> fmt.Printf("%v\n", t)
>
>
> But rather the statement should be this right? fmt.Printf("%v\n",
> t.String())
> Am I missing something?
>

An object with a String() method causes that method to be used wherever a
string is desired. This includes the `%s` and `%v` formatting verbs. From
the paragraph preceding the example:

> If you want to control the default format for a custom type, all that's
required is to define a method with the signature String() string on the
type.

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD9FeOzh9Dsv%2BMt%2BhMVfA%2BeQU_M_7zCNbMnsQDkLJT8EnQ%40mail.gmail.com.

Re: [go-nuts] Example of printing in go.dev

['Dan Kortschak' via golang-nuts]

On Wed, 2022-03-09 at 19:16 -0800, Nikhilesh Susarla wrote:
> In https://go.dev/doc/effective_go#printing
> I saw an example for printing our custom string output for the type.
> The code below is from docs.
> func (t *T) String() string {
> return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
> }
> fmt.Printf("%v\n", t)
>
>
> But rather the statement should be this right? fmt.Printf("%v\n",
> t.String())
> Am I missing something?
>

When the %v (or %s, %q and others[1]) verbs are used the `String()
string` is used to construct the printed value.

You can see the logic here[2].

[1]
https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L611
[2]
https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L623-L628


-- 
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/6fabecec501d706ee876483cba1f5cefecf55df5.camel%40kortschak.io.

[go-nuts] Example of printing in go.dev

[Nikhilesh Susarla]

In https://go.dev/doc/effective_go#printing
I saw an example for printing our custom string output for the type. 
The code below is from docs. 
func (t *T) String() string {
return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
}
fmt.Printf("%v\n", t)


But rather the statement should be this right? fmt.Printf("%v\n", 
t.String())
Am I missing something?

Thank you
Nikhilesh

-- 
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/21a74232-88b2-4a46-9143-d6ffe27ddedfn%40googlegroups.com.

[go-nuts] Pointer to a pointer

[shan...@gmail.com]

This morning someone asked about dereferincing a pointer to a pointer to a 
pointer

At first nobody had ever thought about, let alone knew the answer, but some 
example code was shown, and sure enough ***val is possible
```
package main

import "fmt"

func main() {
a := 0
b := 
c := 
UltimatePointOne()
fmt.Println(a)
}

func UltimatePointOne(n ***int) {
***n = 1
}
```


On a lark a go playground example was tried to find what the maximum * is 
in Go

https://go.dev/play/p/YhibY3p7TSD

There's 28 there, but it's not the limit

Does anyone know what the upper bound on this could be?

256 * ?

32k * ?

-- 
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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com.

Re: [go-nuts] Possible float64 precision problem

[Pablo Caballero]

Hi Christopher, what input int64 is leading to this result (difference in
behavior between Go & C). Does it happen with any input?
I'm asking because I'm interested in playing around with this a bit, maybe
writing two trivial programs (one on each language) and comparing the
machine code generated from each one. I'm trying to venture into low level
debugging/reverse engineering and I think it will be a good exercise.

Thank you!

Best

Pablo

On Wed, Mar 9, 2022, 4:39 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wed, 2022-03-09 at 03:37 -0800, christoph...@gmail.com wrote:
> > I'm translating a scientific C program into Go that is doing some
> > 64bit floating point operations.
> >
> > In this process I check that the same input yields the same output.
> > Unfortunately they don't yield the same result, though the
> > computation is simple. It is as follow. I receive a 64bit integer
> > value.
> >
> > This value is converted to float64/double, and divided by 2^64.
> > The resulting number is multiplied by 1e8.
> >
> > With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09
> > E6 8E. The last 15bits are different. The computation is performed
> > with the same computer.
> >
> > Could it be that the C program is performing the computation with
> > long double (80 bit) precision and that Go is doing it with 64bit
> > precision ?
> >
> > Is there something I could do about it because that might be a red
> > flag for replacing the C program with a Go program.
>
> This is not very surprising depending on the algorithms that are being
> used/the problem that is being solved. Some problems are fundamentally
> difficult to solve exactly and the nature of floating point makes them
> sensitive to the precise set of operations used, intermediate rounding
> and the order of operations (even for operations that are commutative
> in theory). As Robert said, knowing the C compiler will be important,
> and I'd go further, knowing which platform you are building the Go
> program on can be important due to differences in how floating point
> operations are rendered into machine code by the compiler, or even how
> the processor orders apparently commutative operations.
>
> Assuming the values that you've pasted above are big endian, then the
> Go value is within a 1e12th of the value calculate by C (
> https://go.dev/play/p/dn7G2LI75RC). This is not terrible, and maybe
> that level of precision is all that can be promised by the algorithm
> (and believing digits smaller that 1e-12 is dangerous). Alternatively
> there is no fundamental limit at this point and there is a better more
> stable algorithm that you can use (though you are only four orders of
> magnitude from the machine epsilon
> https://en.wikipedia.org/wiki/Machine_epsilon, so be aware).
>
> Floats are tricky beasts and can easily trip people up. I would suggest
> that you read
> https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (and
> the more friendly https://floating-point-gui.de/).
>
>
>
> --
> 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/ee58b6e5ad163014b256d249e21c875307fecddb.camel%40kortschak.io
> .
>

-- 
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/CAPxFe-vuCoHfQnZxXLaseYty7672ku0_a1ee3BB4LexOs_qKcA%40mail.gmail.com.

Re: [go-nuts] Possible float64 precision problem

['Dan Kortschak' via golang-nuts]

On Wed, 2022-03-09 at 03:37 -0800, christoph...@gmail.com wrote:
> I'm translating a scientific C program into Go that is doing some
> 64bit floating point operations.
>
> In this process I check that the same input yields the same output.
> Unfortunately they don't yield the same result, though the
> computation is simple. It is as follow. I receive a 64bit integer
> value.
>
> This value is converted to float64/double, and divided by 2^64.
> The resulting number is multiplied by 1e8.
>
> With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09
> E6 8E. The last 15bits are different. The computation is performed
> with the same computer.
>
> Could it be that the C program is performing the computation with
> long double (80 bit) precision and that Go is doing it with 64bit
> precision ?
>
> Is there something I could do about it because that might be a red
> flag for replacing the C program with a Go program.

This is not very surprising depending on the algorithms that are being
used/the problem that is being solved. Some problems are fundamentally
difficult to solve exactly and the nature of floating point makes them
sensitive to the precise set of operations used, intermediate rounding
and the order of operations (even for operations that are commutative
in theory). As Robert said, knowing the C compiler will be important,
and I'd go further, knowing which platform you are building the Go
program on can be important due to differences in how floating point
operations are rendered into machine code by the compiler, or even how
the processor orders apparently commutative operations.

Assuming the values that you've pasted above are big endian, then the
Go value is within a 1e12th of the value calculate by C (
https://go.dev/play/p/dn7G2LI75RC). This is not terrible, and maybe
that level of precision is all that can be promised by the algorithm
(and believing digits smaller that 1e-12 is dangerous). Alternatively
there is no fundamental limit at this point and there is a better more
stable algorithm that you can use (though you are only four orders of
magnitude from the machine epsilon
https://en.wikipedia.org/wiki/Machine_epsilon, so be aware).

Floats are tricky beasts and can easily trip people up. I would suggest
that you read
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (and
the more friendly https://floating-point-gui.de/).



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

Re: [go-nuts] Re: "Cortex XDR has blocked a malicious activity! " when running Go binary

[Nugraha]

On 2022/3/9 23:37, Brian Candler wrote:

https://go.dev/doc/faq#virus

On Wednesday, 9 March 2022 at 11:14:47 UTC Rusco wrote:

On Win10 I get this Antivirus message and can not get runnig my .exe
on my company notebook.

This is the binary, the only import is "fmt" :
https://go.dev/play/p/GIUnvHMUJec?v=gotip


I checked antivirus diagnostics tools and found this:


https://www.virustotal.com/gui/file/01435f5f5fe574e8154a572094bd0dd21a6ce8bc506b9931be0e30a917fd68a1/detection



https://www.virustotal.com/gui/file/01435f5f5fe574e8154a572094bd0dd21a6ce8bc506b9931be0e30a917fd68a1/community



https://valhalla.nextron-systems.com/info/rule/SUSP_LazyDLL_Load_Golang_Jan20_1



So this is probably due to "suspicious LazyDLL loading in Golang
binaries".
Where is this Lazy DLL loading going on, in the runtime ?



LoadLibraryA, LoadLibraryW is used by syscall and runtime package
https://go.googlesource.com/go/+/refs/tags/go1.18rc1/src/runtime/syscall_windows.go 
at syscall_loadsystemlibrary, syscall_loadlibrary


and on 
https://go.googlesource.com/go/+/refs/tags/go1.18rc1/src/runtime/os_windows.go 
at windowsLoadSystemLib, loadOptionalSyscalls



Is there a way to avoid this, to make it static for example ?


No



I wonder why there a not more complaints about antivirus blocking of
Go binaries.
I never came across such blocking in my Rust binaries.


Any hints welcome
Rusco






--
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/a06db50e-bb79-41e0-ae54-fd8f0b2cae5dn%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/6a20f3c6-8942-fa94-2cbe-2e10af399055%40gmail.com.

[go-nuts] Re: "Cortex XDR has blocked a malicious activity! " when running Go binary

[Brian Candler]

https://go.dev/doc/faq#virus

On Wednesday, 9 March 2022 at 11:14:47 UTC Rusco wrote:

> On Win10 I get this Antivirus message and can not get runnig my .exe on my 
> company notebook. 
>
> This is the binary, the only import is "fmt" : 
> https://go.dev/play/p/GIUnvHMUJec?v=gotip
>
> I checked antivirus diagnostics tools and found this:
>
>
> https://www.virustotal.com/gui/file/01435f5f5fe574e8154a572094bd0dd21a6ce8bc506b9931be0e30a917fd68a1/detection
>
> https://www.virustotal.com/gui/file/01435f5f5fe574e8154a572094bd0dd21a6ce8bc506b9931be0e30a917fd68a1/community
>
> https://valhalla.nextron-systems.com/info/rule/SUSP_LazyDLL_Load_Golang_Jan20_1
>
> So this is probably due to "suspicious LazyDLL loading in Golang 
> binaries". 
> Where is this Lazy DLL loading going on, in the runtime ? 
> Is there a way to avoid this, to make it static for example ?
>
> I wonder why there a not more complaints about antivirus blocking of Go 
> binaries. 
> I never came across such blocking in my Rust binaries. 
>
>
> Any hints welcome
> Rusco
>
>
>
>
>
>
>

-- 
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/a06db50e-bb79-41e0-ae54-fd8f0b2cae5dn%40googlegroups.com.

[go-nuts] Re: in-memory caching in golang

[Rakesh K R]

Thank you Rick and Jason for the pointers

On Saturday, December 11, 2021 at 2:12:55 AM UTC+5:30 Rick wrote:

> Don't forget to think about cache coherency. Caching is more involved with 
> multiple caching microservices talking to the database. Creates and updates 
> require notification of all replicas to refresh their caches.
>
> On Thursday, 9 December 2021 at 23:08:16 UTC-8 Jason E. Aten wrote:
>
>> You might prefer a fixed size cache rather than a TTL, so that your 
>> cache's memory size never gets too big.  This is also simpler logic, using 
>> just a map to provide the cache, and a slice to constrain the cache size.  
>> It's almost too short to be a library, see below. Off the top of my head -- 
>> not run, but you'll get the idea:
>>
>> type Payload struct {
>>Key string  // typical, but your key doesn't have to be a string. Any 
>> suitable map key will work. 
>>pos int // where we are in Cache.Order
>>Val  string // change type from string to store your data. You can add 
>> multiple elements after Val if you desire.
>> }
>>
>> type Cache struct {
>>   Map map[string]*Payload
>>   Order []*Payload
>>   MaxSize int
>> }
>>
>> func NewCache(maxSize int) *Cache {
>> return {
>> Map: make(map[string]*Payload),
>> MaxSize: maxSize,
>> }
>> }
>>
>> func (c *Cache) Get(key string) *Payload {
>> return c.Map[key]
>> }
>>
>> func (c *Cache) Set(p *Payload) {
>>  v, already := c.Map[p.Key]
>>  if already {
>>// update logic, may not be needed if key -> value mapping is 
>> immutable
>>   //  remove any old payload under this same key
>>c.Order = append(c.Order[:v.pos], c.Order[v.pos+1:]) 
>>  }
>>  // add the new
>>  p.pos = len(c.Order)
>>  c.Order = append(c.Order, p)
>>  c.Map[p.Key] = p
>>
>>  // keep the cache size constant
>> if len(c.Order) > c.MaxSize {
>>// deleted the oldest
>>kill := c.Order[0]
>>delete(c.Map, kill.Key)
>>c.Order = c.Order[1:]
>> }
>> }
>>
>> If you really need a Time To Live and want to allow memory to balloon 
>> uncontrolled, then MaxSize would change from an int to a time.Time, and the 
>> deletion condition would change from being size based to being 
>> time.Time.Since() based.
>>
>> Also look at sync.Pool if you need goroutine safety. Obviously you can 
>> just add a sync.Mutex to Cache and lock during Set/Get, but for heavy 
>> contention sync.Pool can perform better.
>>
>>
>> On Thursday, December 9, 2021 at 9:59:32 AM UTC-6 Rakesh K R wrote:
>>
>>> Hi,
>>> In my application I have this necessity of looking into DBs to get the 
>>> data(read intensive application) so I am planning to store these data 
>>> in-memory with some ttl for expiry.
>>> Can someone suggest some in-memory caching libraries with better 
>>> performance available to suit my requirement?
>>>
>>>

-- 
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/20e0fd3a-ae54-4f77-8d0e-c2d3c27b7a7dn%40googlegroups.com.

Re: [go-nuts] Handle errors in init

['Axel Wagner' via golang-nuts]

You likely shouldn't do that in the init function, but do it from main,
where you have a clearly defined error handling path.

There are ~four things you can do with an error in init:
1. Ignore it
2. Log it
3. Store it in a package-scoped variable and check that later
4. Panic
Neither of these are good options, but they are the only ones you have.

On Wed, Mar 9, 2022 at 3:48 PM Nikhilesh Susarla 
wrote:

> I have an init func in a package.
>
> Inside the init function, I have a database initialization which returns
> error. How can I handle that error failure incase if it fails in the init
> function.
>
> Thank you
> Nikhilesh
>
> --
> 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/5600c2e2-9c6d-4a24-af98-ddf52845fe24n%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/CAEkBMfFbq9pCxPz-5_FyAdQL_kC%3DeE4j_87na5o9zotZy4-pTg%40mail.gmail.com.

[go-nuts] Handle errors in init

[Nikhilesh Susarla]

I have an init func in a package. 

Inside the init function, I have a database initialization which returns 
error. How can I handle that error failure incase if it fails in the init 
function.

Thank you
Nikhilesh

-- 
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/5600c2e2-9c6d-4a24-af98-ddf52845fe24n%40googlegroups.com.

Re: [go-nuts] Re: Possible float64 precision problem

[Robert Engels]

You will need to provide the C compiler used and the flags. See 
https://stackoverflow.com/questions/38815823/compiler-flags-for-enhancing-the-precision-of-intermediate-floating-point-calcul

> On Mar 9, 2022, at 6:46 AM, Sean Liao  wrote:
> 
> It would help if your could show the actual code for both C and Go, as well 
> as the input
> 
>> On Wednesday, March 9, 2022 at 11:37:10 AM UTC christoph...@gmail.com wrote:
>> I'm translating a scientific C program into Go that is doing some 64bit 
>> floating point operations. 
>> 
>> In this process I check that the same input yields the same output. 
>> Unfortunately they don't yield the same result, though the computation is 
>> simple. It is as follow. I receive a 64bit integer value. 
>> 
>> This value is converted to float64/double, and divided by 2^64.
>> The resulting number is multiplied by 1e8. 
>> 
>> With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 8E. 
>> The last 15bits are different. The computation is performed with the same 
>> computer.
>> 
>> Could it be that the C program is performing the computation with long 
>> double (80 bit) precision and that Go is doing it with 64bit precision ? 
>> 
>> Is there something I could do about it because that might be a red flag for 
>> replacing the C program with a Go program.
> 
> -- 
> 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/56218a68-dea9-4f02-b8cb-c74b97a71704n%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/F676DB08-CA96-44CB-9253-AD04108112F6%40ix.netcom.com.

[go-nuts] Re: Possible float64 precision problem

[christoph...@gmail.com]

A simple C and Go program to demonstrate the problem doesn't show any 
difference between C and Go. 
It's thus most probably a difference in the code that I must investigate. 
Sorry for the noise. 

Le mercredi 9 mars 2022 à 12:37:10 UTC+1, christoph...@gmail.com a écrit :

> I'm translating a scientific C program into Go that is doing some 64bit 
> floating point operations. 
>
> In this process I check that the same input yields the same output. 
> Unfortunately they don't yield the same result, though the computation is 
> simple. It is as follow. I receive a 64bit integer value. 
>
> This value is converted to float64/double, and divided by 2^64.
> The resulting number is multiplied by 1e8. 
>
> With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 
> 8E. The last 15bits are different. The computation is performed with the 
> same computer.
>
> Could it be that the C program is performing the computation with long 
> double (80 bit) precision and that Go is doing it with 64bit precision ? 
>
> Is there something I could do about it because that might be a red flag 
> for replacing the C program with a Go program.
>

-- 
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/94204dc3-9a9b-4957-8cda-5addf9522327n%40googlegroups.com.

[go-nuts] Re: Possible float64 precision problem

[Sean Liao]

It would help if your could show the actual code for both C and Go, as well 
as the input

On Wednesday, March 9, 2022 at 11:37:10 AM UTC christoph...@gmail.com wrote:

> I'm translating a scientific C program into Go that is doing some 64bit 
> floating point operations. 
>
> In this process I check that the same input yields the same output. 
> Unfortunately they don't yield the same result, though the computation is 
> simple. It is as follow. I receive a 64bit integer value. 
>
> This value is converted to float64/double, and divided by 2^64.
> The resulting number is multiplied by 1e8. 
>
> With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 
> 8E. The last 15bits are different. The computation is performed with the 
> same computer.
>
> Could it be that the C program is performing the computation with long 
> double (80 bit) precision and that Go is doing it with 64bit precision ? 
>
> Is there something I could do about it because that might be a red flag 
> for replacing the C program with a Go program.
>

-- 
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/56218a68-dea9-4f02-b8cb-c74b97a71704n%40googlegroups.com.

[go-nuts] Possible float64 precision problem

[christoph...@gmail.com]

I'm translating a scientific C program into Go that is doing some 64bit 
floating point operations. 

In this process I check that the same input yields the same output. 
Unfortunately they don't yield the same result, though the computation is 
simple. It is as follow. I receive a 64bit integer value. 

This value is converted to float64/double, and divided by 2^64.
The resulting number is multiplied by 1e8. 

With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 
8E. The last 15bits are different. The computation is performed with the 
same computer.

Could it be that the C program is performing the computation with long 
double (80 bit) precision and that Go is doing it with 64bit precision ? 

Is there something I could do about it because that might be a red flag for 
replacing the C program with a Go program.

-- 
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/f9b7a823-e010-4c51-9491-6da865754dc2n%40googlegroups.com.

[go-nuts] "Cortex XDR has blocked a malicious activity! " when running Go binary

[Rusco]

On Win10 I get this Antivirus message and can not get runnig my .exe on my 
company notebook. 

This is the binary, the only import is "fmt" : 
https://go.dev/play/p/GIUnvHMUJec?v=gotip

I checked antivirus diagnostics tools and found this:

https://www.virustotal.com/gui/file/01435f5f5fe574e8154a572094bd0dd21a6ce8bc506b9931be0e30a917fd68a1/detection
https://www.virustotal.com/gui/file/01435f5f5fe574e8154a572094bd0dd21a6ce8bc506b9931be0e30a917fd68a1/community
https://valhalla.nextron-systems.com/info/rule/SUSP_LazyDLL_Load_Golang_Jan20_1

So this is probably due to "suspicious LazyDLL loading in Golang binaries". 
Where is this Lazy DLL loading going on, in the runtime ? 
Is there a way to avoid this, to make it static for example ?

I wonder why there a not more complaints about antivirus blocking of Go 
binaries. 
I never came across such blocking in my Rust binaries. 


Any hints welcome
Rusco






-- 
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/b4125129-a244-40b3-8a9a-ae989d0f101cn%40googlegroups.com.