Re: [go-nuts] keep just 2 decimal places in a float64

[Robert Engels]

You can use github.com/robaho/fixed :)

> On Jan 25, 2020, at 11:40 PM, Jamil Djadala  wrote:
> 
> On Sat, 25 Jan 2020 19:14:15 -0800 (PST)
> "Jason E. Aten"  wrote:
> 
>> 
>> https://play.golang.org/p/87bDubJxjHO
>> 
>> I'd like to truncate a float64 to just 2 decimal places (in base 10),
>> but math.Trunc is not helping me here... ideally I put 0.29 in and I
>> get 0.29 out.
>> Suggestions?  Playground examples appreciated.
> 
> you can use int types:
> https://play.golang.org/p/qLnynemd3S1
> -- 
> Jamil Djadala
> 
> -- 
> 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/20200126074011.0f17b4fa%40wolf.home.

-- 
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/4FB8D934-4C40-49D1-B748-4F2051C04B8C%40ix.netcom.com.

Re: [go-nuts] keep just 2 decimal places in a float64

[Jamil Djadala]

On Sat, 25 Jan 2020 19:14:15 -0800 (PST)
"Jason E. Aten"  wrote:

> 
> https://play.golang.org/p/87bDubJxjHO
> 
> I'd like to truncate a float64 to just 2 decimal places (in base 10),
> but math.Trunc is not helping me here... ideally I put 0.29 in and I
> get 0.29 out.
> Suggestions?  Playground examples appreciated.

you can use int types:
https://play.golang.org/p/qLnynemd3S1
-- 
Jamil Djadala

-- 
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/20200126074011.0f17b4fa%40wolf.home.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[Kurtis Rader]

On Sat, Jan 25, 2020 at 9:26 PM  wrote:

> Floating point math has many pitfalls.
> https://play.golang.org/p/LK0lla8hM9w See also
> https://0.30004.com/
>

I was not aware of URL https://0.30004.com/. Like the XY
problem URL, http://xyproblem.info/, the URL you cited is another one to
remember to cite when a FAQ about floating point values occurs :-)

-- 
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-MhGVGup20mTFs3K%3DVBmOCMrx_TuT1ddmac2m%2BjVNZCw%40mail.gmail.com.

[go-nuts] Re: keep just 2 decimal places in a float64

[cratermoon]

Floating point math has many 
pitfalls.  https://play.golang.org/p/LK0lla8hM9w See also 
https://0.30004.com/

s

On Saturday, January 25, 2020 at 7:14:15 PM UTC-8, Jason E. Aten wrote:
>
>
> https://play.golang.org/p/87bDubJxjHO
>
> I'd like to truncate a float64 to just 2 decimal places (in base 10), but 
> math.Trunc is not helping me here... ideally I put 0.29 in and I get 0.29 
> out.
> Suggestions?  Playground examples appreciated.
>
> package main
>
> import (
> "fmt"
> "math"
> )
>
> // truncate off everything after the last two decimals, no rounding.
> func decimal2(x float64) float64 {
> return math.Trunc(x*100) / 100
> }
>
> func main() {
> x := 0.29
> y := decimal2(x)
> fmt.Printf("x=%v -> y = %v", x, y) // prints x=0.29  ->  y=0.28
> }
>

-- 
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/d3250e2a-e72d-40e5-987c-b9f5012dd3cc%40googlegroups.com.

Re: [go-nuts] keep just 2 decimal places in a float64

[Aston Motes]

Picking the first decimal library on pkg.go.dev, what about
https://play.golang.org/p/Co96HKlvSMp ?

On Sat, Jan 25, 2020 at 7:34 PM Kurtis Rader  wrote:

> You've fallen into a common trap. Base 2 floating point values cannot
> represent most decimal values precisely. This is why you should never,
> ever, do a simple equality test involving a F.P. value derived from a
> calculation. You always have to apply an epsilon to define a range within
> which the two F.P. values should be considered equal. The %v formatter does
> something similar. The base 10 value 0.29 is actually
> 0.28998002 when stored base 2 (that's from printing a long
> double var on a x86_64 platform).
>
> Welcome to floating point pitfalls. Here be dragons!
>
>
> On Sat, Jan 25, 2020 at 7:14 PM Jason E. Aten  wrote:
>
>>
>> https://play.golang.org/p/87bDubJxjHO
>>
>> I'd like to truncate a float64 to just 2 decimal places (in base 10), but
>> math.Trunc is not helping me here... ideally I put 0.29 in and I get 0.29
>> out.
>> Suggestions?  Playground examples appreciated.
>>
>> package main
>>
>> import (
>> "fmt"
>> "math"
>> )
>>
>> // truncate off everything after the last two decimals, no rounding.
>> func decimal2(x float64) float64 {
>> return math.Trunc(x*100) / 100
>> }
>>
>> func main() {
>> x := 0.29
>> y := decimal2(x)
>> fmt.Printf("x=%v -> y = %v", x, y) // prints x=0.29  ->  y=0.28
>> }
>>
>> --
>> 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/96528d64-a670-45ba-ad4c-0701dcd0d78d%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%3DD8JvQETOfkO63FWveyS7AbpKpLM1uVQsB6QH_mDNGajgw%40mail.gmail.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/CANfvvbX4jw1NK%2BEyFpbo1s8yLPuGtTsABQDiYHRaHFmPRDuvjA%40mail.gmail.com.

Re: [go-nuts] keep just 2 decimal places in a float64

[Kurtis Rader]

You've fallen into a common trap. Base 2 floating point values cannot
represent most decimal values precisely. This is why you should never,
ever, do a simple equality test involving a F.P. value derived from a
calculation. You always have to apply an epsilon to define a range within
which the two F.P. values should be considered equal. The %v formatter does
something similar. The base 10 value 0.29 is actually
0.28998002 when stored base 2 (that's from printing a long
double var on a x86_64 platform).

Welcome to floating point pitfalls. Here be dragons!


On Sat, Jan 25, 2020 at 7:14 PM Jason E. Aten  wrote:

>
> https://play.golang.org/p/87bDubJxjHO
>
> I'd like to truncate a float64 to just 2 decimal places (in base 10), but
> math.Trunc is not helping me here... ideally I put 0.29 in and I get 0.29
> out.
> Suggestions?  Playground examples appreciated.
>
> package main
>
> import (
> "fmt"
> "math"
> )
>
> // truncate off everything after the last two decimals, no rounding.
> func decimal2(x float64) float64 {
> return math.Trunc(x*100) / 100
> }
>
> func main() {
> x := 0.29
> y := decimal2(x)
> fmt.Printf("x=%v -> y = %v", x, y) // prints x=0.29  ->  y=0.28
> }
>
> --
> 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/96528d64-a670-45ba-ad4c-0701dcd0d78d%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%3DD8JvQETOfkO63FWveyS7AbpKpLM1uVQsB6QH_mDNGajgw%40mail.gmail.com.

[go-nuts] keep just 2 decimal places in a float64

[Jason E. Aten]

https://play.golang.org/p/87bDubJxjHO

I'd like to truncate a float64 to just 2 decimal places (in base 10), but 
math.Trunc is not helping me here... ideally I put 0.29 in and I get 0.29 
out.
Suggestions?  Playground examples appreciated.

package main

import (
"fmt"
"math"
)

// truncate off everything after the last two decimals, no rounding.
func decimal2(x float64) float64 {
return math.Trunc(x*100) / 100
}

func main() {
x := 0.29
y := decimal2(x)
fmt.Printf("x=%v -> y = %v", x, y) // prints x=0.29  ->  y=0.28
}

-- 
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/96528d64-a670-45ba-ad4c-0701dcd0d78d%40googlegroups.com.

[go-nuts] Printing *go/ast.CommentGroup

[Shane H]

Hi all, I'm trying to learn how to write a linter (because long weekend, 
etc)

I looked at Fatih's very fine blog post (
https://arslan.io/2019/06/13/using-go-analysis-to-write-a-custom-linter/) 
as well as the one that precedes it, although I was a LOT lost reading that 
one.

Copying and pasting 
https://github.com/fatih/addlint/blob/master/addcheck/addcheck.go got me 
started, but the linter I have in mind needs to see strings, a trip to 
https://golang.org/src/go/token/token.go and 
https://golang.org/src/go/ast/ast.go showed me the possibilities. This  
(fortunately?) made me switch priorities slightly, as I now want to write 
something that is going to print each and every node (and this is where my 
problems began).

I used Fatih's run and render functions but discovered that an error is 
being generated for the Doc comment, and I cannot see *why* 
(ast.CommentGroup is fine in parts of the code.. except for `func (p 
*printer) printNode(node interface{}) error`
 (https://golang.org/src/go/printer/printer.go 
 line 1073), the format node 
section (lines 1125 - 1155) take me to the unsupported label, which 
generates an error

My code (main.go, lencheck.go, and complete output can be found 
at https://play.golang.org/p/olvJ64EDdKZ, please excuse the length of the 
paste, I put *everything* in there)

As you can see in my code there are 4 nodes that throw errors, and I don't 
understand if 1) that is intended or 2) I am doing (or not doing as the 
case may be) something to cause the issue.

 Any help/pointers appreciated

-- 
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/e305e103-c8d1-46e5-816d-87f45ec9b963%40googlegroups.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Saturday, January 25, 2020 at 5:43:24 AM UTC-5, Brian Candler wrote:
>
> 1. When the issue of keyword arguments has come up before, usually someone 
> suggests passing a struct as the function argument.  Did you try this?  It 
> might be worth mentioning in your analysis, if only to give an example of 
> why it wasn't a good match.
>

I'm picky about when I'll do that.  I view putting a bunch of items in a 
structure as a promise to people reading the code that the structure isn't 
just a vacuous shim but captures an interesting chunk in the ontology of 
the program.  "They're all arguments to this function" isn't interesting 
enough. 

2. I notice some potential overlap between a couple of features you 
> mention.  The first is map(f,x) for mapping a slice of arbitrary type 
> (incidentally it couldn't be called "map" for obvious reasons)  The second 
> is using generator functions as ranges.
>
> It occurs to me that if you could initialize a slice from a generator 
> function, you'd have another way to achieve your map. The generator 
> function could also do filtering, making it more like a comprehension.
>

Perhaps. But map-over=sequence seems to me like a simpler primitive idea 
than "comprehension" and thus preferable.
 

> 3. A generator function would have to maintain its own thread of execution 
> independent from the recipient - much like a goroutine.  So this might end 
> up looking very similar to a function which stuffs values down a channel, 
> which is option 3 in the linked article 
> .
>
> The problem with garbage collection needs to be dealt with, which at the 
> simplest could be that the receiver closes the channel when done. Today 
> this would cause the sender to panic, so that would need to be dealt with - 
> perhaps some sort of "soft close".
>

And that's the insight that led be to the extension I proposed. I asked 
myself what the most natural way to pass out a soft close might be.
 

-- 
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/04b5ee2c-40d0-4275-a53a-eaad9828c849%40googlegroups.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Eric Raymond]

On Saturday, January 25, 2020 at 10:04:19 AM UTC-5, Robert Engels wrote:
>
> Whenever I see a type switch it screams to me “use an interface and 
> restructure. “
>

You may be right.  On the other hand, I think I've already gone far enough 
down the  interface road to have collected most of the gains from that 
tactic.

Interfaces are fine when you have a bunch of disparate types with similar 
external interfaces and are at a stage of processing where you can 
disregard the differences.  You end up in type-switch land when the point 
is that they have *dissimilar* external interfaces but you have to cope 
anyway.

Not ideal, but sometimes necessary.

-- 
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/88b8c01c-b70e-41dc-a1e7-fb412b831f50%40googlegroups.com.

Re: [go-nuts] Can anyone explain this code Please. It is not giving expected result.

[Ian Lance Taylor]

On Sat, Jan 25, 2020 at 9:15 AM burak serdar  wrote:
>
> On Sat, Jan 25, 2020 at 9:55 AM Kaleemullah Software Engineer
>  wrote:
> >
> >
> > When i change the value U at 0 index , It changes the value of t and u at 
> > zero index why it is not changing the value of S. Please Explain I got 
> > stuck here.
> >
> >
> >
> >
> > package main
> >
> > import (
> > "fmt"
> > )
> >
> > func main() {
> >
> > var s []int
> > var t []int
> > s= make([]int,3)
>
> Here, you allocate a slice with cap=3,
>
> > s[0]=100
> > s[1]=200
> > s[2]=300
> > t=append(s,400)
>
> Here, you append an element to s, which has cap=3, so a new slice is
> allocated with larger cap, that becomes t. s still has cap=3 and it
> has its three elements. t has 4 elements,
>
> > fmt.Println(s,len(s),cap(s))
> > fmt.Println(t,len(t),cap(t))
> > var u []int
> > u=append(t,500)
>
> Here, you append an element to t, and apparently t has capacity, so it
> does not reallocate a new array. t and u are pointing to the same
> underlying array, with len(t)=4 and len(u)=5
>
> > fmt.Println(u,len(u),cap(u))
> > u[0]=
>
> This sets the first element of the underlying array for t and u.
>
> > fmt.Println("//")
> >
> > fmt.Println(s,len(s),cap(s))
> > fmt.Println(t,len(t),cap(t))
> > fmt.Println(u,len(u),cap(u))
> > }



Please read https://blog.golang.org/slices.

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/CAOyqgcWp188utufLBq_xgSk_y_VH3xS5%3DzP8EOaXZOXDg5%3D%3DUQ%40mail.gmail.com.

Re: [go-nuts] Can anyone explain this code Please. It is not giving expected result.

[burak serdar]

On Sat, Jan 25, 2020 at 9:55 AM Kaleemullah Software Engineer
 wrote:
>
>
> When i change the value U at 0 index , It changes the value of t and u at 
> zero index why it is not changing the value of S. Please Explain I got stuck 
> here.
>
>
>
>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
>
> var s []int
> var t []int
> s= make([]int,3)

Here, you allocate a slice with cap=3,

> s[0]=100
> s[1]=200
> s[2]=300
> t=append(s,400)

Here, you append an element to s, which has cap=3, so a new slice is
allocated with larger cap, that becomes t. s still has cap=3 and it
has its three elements. t has 4 elements,

> fmt.Println(s,len(s),cap(s))
> fmt.Println(t,len(t),cap(t))
> var u []int
> u=append(t,500)

Here, you append an element to t, and apparently t has capacity, so it
does not reallocate a new array. t and u are pointing to the same
underlying array, with len(t)=4 and len(u)=5

> fmt.Println(u,len(u),cap(u))
> u[0]=

This sets the first element of the underlying array for t and u.

> fmt.Println("//")
>
> fmt.Println(s,len(s),cap(s))
> fmt.Println(t,len(t),cap(t))
> fmt.Println(u,len(u),cap(u))
> }
>
>
> --
> 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/83571b55-1834-4aa8-994d-bc99df4ab0ee%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/CAMV2RqqkJhh9kU4hjks8XVd4G-gejPX6w5xC%3DJD29FiFeWCFjg%40mail.gmail.com.

[go-nuts] Can anyone explain this code Please. It is not giving expected result.

[Kaleemullah Software Engineer]

When i change the value U at 0 index , It changes the value of t and u at 
zero index why it is not changing the value of S. Please Explain I got 
stuck here. 




package main

import (
"fmt"
)

func main() {

var s []int
var t []int
s= make([]int,3)
s[0]=100
s[1]=200
s[2]=300
t=append(s,400)
fmt.Println(s,len(s),cap(s))
fmt.Println(t,len(t),cap(t))
var u []int
u=append(t,500)
fmt.Println(u,len(u),cap(u))
u[0]=
fmt.Println("//")

fmt.Println(s,len(s),cap(s))
fmt.Println(t,len(t),cap(t))
fmt.Println(u,len(u),cap(u))
}


-- 
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/83571b55-1834-4aa8-994d-bc99df4ab0ee%40googlegroups.com.

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

[Robert Engels]

Very in-depth and interesting. 

Although I agree with most of the points, I think a better use of interfaces 
would address some of your concerns, and have more maintainable code. 

Whenever I see a type switch it screams to me “use an interface and 
restructure. “

>> On Jan 25, 2020, at 4:43 AM, Brian Candler  wrote:
> 
> Very insightful.
> 
> I am relatively new to go, but I would like to make a few observations.
> 
> 1. When the issue of keyword arguments has come up before, usually someone 
> suggests passing a struct as the function argument.  Did you try this?  It 
> might be worth mentioning in your analysis, if only to give an example of why 
> it wasn't a good match.
> 
> 2. I notice some potential overlap between a couple of features you mention.  
> The first is map(f,x) for mapping a slice of arbitrary type (incidentally it 
> couldn't be called "map" for obvious reasons)  The second is using generator 
> functions as ranges.
> 
> It occurs to me that if you could initialize a slice from a generator 
> function, you'd have another way to achieve your map. The generator function 
> could also do filtering, making it more like a comprehension.
> 
> 3. A generator function would have to maintain its own thread of execution 
> independent from the recipient - much like a goroutine.  So this might end up 
> looking very similar to a function which stuffs values down a channel, which 
> is option 3 in the linked article.
> 
> The problem with garbage collection needs to be dealt with, which at the 
> simplest could be that the receiver closes the channel when done. Today this 
> would cause the sender to panic, so that would need to be dealt with - 
> perhaps some sort of "soft close".
> -- 
> 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/fdd4882f-0c17-42f2-b301-ab65e5ce08a7%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/C1720736-D9CC-4D98-9D54-5EF69CF1B9CD%40ix.netcom.com.

[go-nuts] Re: Experience report on a large Python-to-Go translation

[Brian Candler]

Very insightful.

I am relatively new to go, but I would like to make a few observations.

1. When the issue of keyword arguments has come up before, usually someone 
suggests passing a struct as the function argument.  Did you try this?  It 
might be worth mentioning in your analysis, if only to give an example of 
why it wasn't a good match.

2. I notice some potential overlap between a couple of features you 
mention.  The first is map(f,x) for mapping a slice of arbitrary type 
(incidentally it couldn't be called "map" for obvious reasons)  The second 
is using generator functions as ranges.

It occurs to me that if you could initialize a slice from a generator 
function, you'd have another way to achieve your map. The generator 
function could also do filtering, making it more like a comprehension.

3. A generator function would have to maintain its own thread of execution 
independent from the recipient - much like a goroutine.  So this might end 
up looking very similar to a function which stuffs values down a channel, 
which is option 3 in the linked article 
.

The problem with garbage collection needs to be dealt with, which at the 
simplest could be that the receiver closes the channel when done. Today 
this would cause the sender to panic, so that would need to be dealt with - 
perhaps some sort of "soft close".

-- 
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/fdd4882f-0c17-42f2-b301-ab65e5ce08a7%40googlegroups.com.

Re: [go-nuts] link order in executable

['Michael Stiller' via golang-nuts]

Thank you Ian.

Best regards,

Michael


> On 24. Jan 2020, at 22:19, Ian Lance Taylor  wrote:
> 
> On Fri, Jan 24, 2020 at 1:10 PM 'Michael Stiller' via golang-nuts
>  wrote:
>> 
>> playing around with tamago i noticed that if i compile with this command:
>> 
>> GO_EXTLINK_ENABLED=0 CGO_ENABLED=0 GOOS=tamago GOARM=6 GOARCH=arm \
>>  ${TAMAGO} build -ldflags "-v -T 0x8000 -E _rt0_arm_tamago -R 0x1000" $@
>> 
>> The generated (elf) binary has the following symbols:
>> 
>> nm main | sort | head
>> 8000 T internal/cpu.Initialize
>> 8000 t runtime.text
>> 8144 T internal/cpu.processOptions
>> 87d4 T internal/cpu.indexByte
>> 8848 T type..hash.internal/cpu.CacheLinePad
>> 8858 T type..eq.internal/cpu.CacheLinePad
>> 8868 T type..hash.internal/cpu.arm
>> 88b0 T type..eq.internal/cpu.arm
>> 88ec T type..hash.internal/cpu.arm64
>> 8934 T type..eq.internal/cpu.arm64
>> 
>> What determines and is this configurable that internal/cpu.Initialize gets 
>> linked at 0x8000?
>> 
>> What i want to achieve is, that the -E entry symbol gets linked first at 
>> 0x8000.
> 
> Nothing in particular determines that that symbol is a 0x8000.  The -T
> option says that the text segment will start at 0x8000.  The Go linker
> doesn't have any support for ordering the symbols in the text segment.
> They just wind up being placed based on the order in which the linker
> processes its inputs, which is unpredictable and subject to change.
> 
> The -E option sets the value stored in the ELF ehdr's e_entry field.
> 
> 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/109F6334-906B-4E8E-B1B0-D24563A1CEF5%40ymail.com.

[go-nuts] Experience report on a large Python-to-Go translation

[Eric Raymond]

Most of the remainder of this post is asciidoc source, because that's easy 
to quote.  If you want to look at a nicely rendered version, see

https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc

= Notes on the Go translation of Reposurgeon =
version 1.8, 2020-01-25

This is an experience report on a Python-to-Go translation of a
program with significant complexity, written in attempted conformance
with the Go community's practice for grounding language enhancement
requests not in it-would-be-nice-to-have abstractions but rather in a
description of real-world problems.

Reposurgeon is a program for editing version-control histories and
interconverting them among version-control systems. I spent much of
2019 moving the reposurgeon codebase from Python to Go because the
Python implementation was too slow to be useful on on really large
repositories.  The workflow it is designed to support is rapid
iterative improvement of conversion recipes by a human operator;
long test cycles disrupt this by making experimentation painful.

Subversion-to-git conversion of the Gnu Compiler Collection history,
at over 280K commits (over 1.6M individual change actions), was the
straw that broke the camel's back. Using PyPy with every optimization
on semi-custom hardware tuned for this job still yielded test
conversion times of over 9 hours, which is death on the
recipe-debugging cycle.  A test translation of the auxiliary
repocutter tool suggested that we could expect up to a 40x speedup,
which was in line with published Python vs. Go comparative benchmarks.

The problem directed the choice of Go, not the other way around.  I
seriously considered OCaml or a compiled Lisp as alternatives.  I
concluded that in either case the semantic gap between Python and
the target language was so large that translation would be
impractical. Only Go offered me any practical hope.

I did examine two automated tools for Python to Go translation, but
rejected them because I judged the generated Go code would have been a
maintainability disaster.  Thus, translation by hand.  Though at about
22% in I did write https://gitlab.com/esr/pytogo[a fast, crude,
incomplete Python-to-Go source translator] to assist the process.

The man barrier to translation was that, while at 14KLOC of Python
reposurgeon was not especially large, the code is very *dense*.  It's
a DSL that's a structure editor for attributed DAGs - algorithmically
complex, bristling with graph theory, FSMs, parsing, tricky data
structures, two robot harnesses driving other tools, and three
different operator-composition algebras.  It became 21KLOC of Go.

The algorithmic density of reposurgeon is such that it would be a
challenge to the expressiveness of any language it were implemented
in.  It makes a good test of the relative expressiveness of Python and
Go, and an effective way to audit for places where moving from Python
to Go hinders concision and readability.

The skillset I approached this problem with is: Go novice, Python and
C expert; old Unix hand; Lisp hacker of even more ancient vintage;
ex-mathematician with strength in graph theory, group theory and
combinatorics; lots of experience as a systems programmer, lots of
exposure to odd languages, and lots of domain knowledge about
version-control systems.  Adjust bias compensators accordingly.

== Expected problems that weren't ==

Semantic distance. In general, the translation gap between Python and
Go is narrower than I initially expected, especially considering the
dynamic-vs-static type-system difference.  On reflection, I think it
turns out that GC and the existence of maps as first-class types do
more to narrow that gap than the static/dynamic divergence in type
systems does to widen it.

Polymorphic lists.  The principal data structure of a repository's
representation in reposurgeon is a list of events - data structures
representing modification operations on sets of files.  The list is
necessarily polymorphic because (for example) a change commit and a
tag creation are different kinds of things.  Translating this to
static typing using interfaces proved less arduous than I had feared,
though the process revealed a documentation issue and a problem
with absence of sum types; I will return to both points.

Operator overloading.  Good style in Python, but surprisingly easy to
relinquish in Go.  I went in thinking that they'd be on my want list
for Go before I was done, but no - not even at reposurgeon's
complexity scale.

Generics.  Yes, these would have made translation easier, but the main
impact turned out to be that I had to write my own set-of-int and
set-of-string classes.  That was a surprisingly light hit.  What I
really missed was generic map-function-over-slice, which could be
handled by adding a much narrower feature.

The positive part of my summation is that hand-translation of Python
to Go even at this scale and complexity is not horrible.  It's not
*easy*, exactly, but quite doable.  It is however