Re: [go-nuts] Slices of pointers or not?

[Amnon]

Go runtime is dominated by the costs of allocation and GC.

If you return 1 persons, then if we make the (unrealistic) assumption 
that a Person contains not pointers (strings etc). then returning []Person 
would require one allocation, whereas returning []*Person would require 
10,001. And GC will be much slower as there will be 10,000 more objects to 
mark.
Iteration across the returned slice will also be much faster in the former 
case, as each Person will 
reside in (cache friendly) sequential memory locations, whereas in the 
latter case the memory location
of each person will be effectively randomised and entail a cache miss.

So in general returning []Person will be much faster. 
Of course you should make sure you pre-allocate the entire slice, rather 
than letting it grow automatically
as the result of appends.


On Friday, 4 February 2022 at 09:43:28 UTC pauloaf...@gmail.com wrote:

> I appreciate your help.
>
> Em sexta-feira, 4 de fevereiro de 2022 às 00:12:47 UTC-3, 
> ren...@ix.netcom.com escreveu:
>
>> I think the OPs question was specifically about the cost of returning 
>> from a function - it is the same. 
>>
>> > On Feb 3, 2022, at 8:03 PM, Connor Kuehl  wrote: 
>> > 
>> > On Thu, Feb 3, 2022 at 7:07 PM Paulo Júnior  
>> wrote: 
>> >> 
>> >> Hi all. 
>> >> 
>> >> I hope you are well. 
>> >> 
>> >> Is there a big difference, in terms of performance or functionality, 
>> between declaring []*Person or []Person as a return type of a function? 
>> > 
>> > If you find yourself iterating over a group of structs like this a lot 
>> > (especially if there's a lot of them to iterate over), you might want 
>> > to consider measuring the performance differences between []*Person or 
>> > []Person. With pointers, the actual structs might be far away from 
>> > each other in memory, which may prevent you from taking full advantage 
>> > of your processor's cache since it won't be able to benefit from the 
>> > spatial locality that an array (or slice) offers. 
>> > 
>> > Connor 
>> > 
>> > -- 
>> > 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/CAC_QXZS-QEKTgvsK3TKk-yUyc1jP81HngHz6dcDV8bZwqLBT6Q%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/1f76f2e2-a26a-4f05-bb5a-435f98a93219n%40googlegroups.com.

[go-nuts] Re: A Question about `unsafe.Slice`

[rmfr]

I found the comments of `findObject` in the runtime source:

```go
// findObject returns the base address for the heap object **containing**
// the address p, the object's span, and the index of the object in s.
// If p does not point into a heap object, it returns base == 0.
//
// If p points is an invalid heap pointer and debug.invalidptr != 0,
// findObject panics.
//
// refBase and refOff optionally give the base address of the object
// in which the pointer p was found and the byte offset at which it
// was found. These are used for error reporting.
//
// It is nosplit so it is safe for p to be a pointer to the current 
goroutine's stack.
// Since p is a uintptr, it would not be adjusted if the stack were to move.
//go:nosplit
func findObject(p, refBase, refOff uintptr) (base uintptr, s *mspan, 
objIndex uintptr)
```

On Sunday, February 6, 2022 at 10:33:35 AM UTC+8 rmfr wrote:

> It suddenly occurred to me that it was very like `re-slice` —— as long as 
> part of the underlying array is referenced, the whole underlying array is 
> never gc-ed. I guess there is a method in gc which could locate the whole 
> underlying array as long as one address inside the array's address interval 
> was provided? So now I tend to believe that `Element1` is correct too, and 
> the `underlyBuf` filed in `Element2` is redundant and is not quite 
> necessary, am I correct?
>
> On Sunday, February 6, 2022 at 10:08:06 AM UTC+8 rmfr wrote:
>
>> Please take a look at the following code:
>>
>> ```go
>> package main
>>
>> import (
>> "fmt"
>> "runtime"
>> "unsafe"
>> )
>>
>> func assert(b bool) {
>> if b {
>> } else {
>> panic("unexpected")
>> }
>> }
>>
>> type Elementer interface {
>> GetInt64Slice() []int64
>> GetByteSlice() []byte
>> String() string
>> }
>>
>> type Element1 struct {
>> int64s []int64
>> bs []byte
>> }
>>
>> func newElement1(int64Sz, bsSz int) *Element1 {
>> assert(int64Sz > 0 && bsSz > 0)
>> len0 := int64Sz * 8
>> len1 := bsSz
>> buf := make([]byte, len0+len1)
>> for i := range buf {
>> buf[i] = byte(i)
>> }
>> e := {
>> int64s: unsafe.Slice((*int64)(unsafe.Pointer([0])), int64Sz),
>> bs: unsafe.Slice((*byte)([len0]), bsSz),
>> }
>> return e
>> }
>>
>> func (e *Element1) GetInt64Slice() []int64 {
>> return e.int64s
>> }
>>
>> func (e *Element1) GetByteSlice() []byte {
>> return e.bs
>> }
>>
>> func (e *Element1) String() string {
>> return fmt.Sprintf("Element1:[% x % x]", e.GetInt64Slice(), 
>> e.GetByteSlice())
>> }
>>
>> type Element2 struct {
>> underlyBuf []byte  // <- is this field needed?
>> int64s []int64
>> bs []byte
>> }
>>
>> func newElement2(int64Sz, bsSz int) *Element2 {
>> assert(int64Sz > 0 && bsSz > 0)
>> len0 := int64Sz * 8
>> len1 := bsSz
>> buf := make([]byte, len0+len1)
>> for i := range buf {
>> buf[i] = byte(i)
>> }
>> e := {
>> underlyBuf: buf,   // <-
>> int64s: unsafe.Slice((*int64)(unsafe.Pointer([0])), 
>> int64Sz),
>> bs: unsafe.Slice((*byte)([len0]), bsSz),
>> }
>> return e
>> }
>>
>> func (e *Element2) GetInt64Slice() []int64 {
>> runtime.KeepAlive(e.underlyBuf)
>> return e.int64s
>> }
>>
>> func (e *Element2) GetByteSlice() []byte {
>> runtime.KeepAlive(e.underlyBuf)
>> return e.bs
>> }
>>
>> func (e *Element2) String() string {
>> runtime.KeepAlive(e.underlyBuf)
>> return fmt.Sprintf("Element2:[% x % x]", e.GetInt64Slice(), 
>> e.GetByteSlice())
>> }
>>
>> func main() {
>> var e Elementer
>> fmt.Println("print with host endian:")
>> e = newElement1(2, 4)
>> fmt.Println("hi", e)
>> e = newElement2(2, 4)
>> fmt.Println("hi", e)
>> }
>> ```
>>
>> And which yields:
>>
>> ```
>> hi Element1:[[ 706050403020100  f0e0d0c0b0a0908] 10 11 12 13]
>> hi Element2:[[ 706050403020100  f0e0d0c0b0a0908] 10 11 12 13]
>> ```
>>
>> I'm not sure whether the `underlyBuf` filed in `Element2` is needed or 
>> not. When I'm reading the doc from `
>> https://pkg.go.dev/reflect#SliceHeader` 
>>  there is:
>>
>> > Moreover, the Data field is not sufficient to guarantee the data it 
>> references will not be garbage collected, so programs must keep a separate, 
>> correctly typed pointer to the underlying data.
>>
>> But in `https://pkg.go.dev/unsafe#Slice` 
>>  there are no such comments. So the 
>> question:
>>
>> Which implementation of `Elementer` is correct? `Element2` or both of 
>> them?
>>
>> Thanks a lot for your help.
>>
>

-- 
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] Going thorough "Type parameters proposal" with Go 1.18 beta

[Ian Lance Taylor]

On Sat, Feb 5, 2022 at 4:27 PM Kamil Ziemian  wrote:
>
> On the other hand this code compiled
> > package main
> >
> > import "fmt"
> >
> > type Stringer interface {
> > String() string
> > }
> >
> > type StringableVector[T Stringer] []T
> >
> > type someFloat float64
> >
> > func (sF someFloat) String() string {
> > return fmt.Sprintf("someFloat: %v", float64(sF))
> > }
> >
> > func main() {
> > var varStringer Stringer = someFloat(7)
> > sliceSomeFloat := make([]someFloat, 3)
> >
> > var varStringableVector StringableVector[someFloat] = sliceSomeFloat
> >
> > fmt.Printf("varStringer type: %T\n", varStringer)
> > fmt.Printf("sliceSomeFloat type: %T\n", sliceSomeFloat)
> > fmt.Printf("varStringableVector type: %T\n", varStringableVector)
> > }
>
> and produced result
>
> > stringerVar type: main.someFloat
> > sliceScomeFloat type: []main.someFloat
> > stringableVectorVar type: main.StringableVector[main.someFloat]
>
> Variable stringableVectorVar is not of interface type, because in such case 
> its type printed by fmt.Printf should be []main.someFloat. So, it looks like 
> to me as []main.someFloat is implicitly conversed to 
> main.StringableVector[main.someFloat].
>
> Answer to my previous questions was that []stupidFloat/[]someFloat is not of 
> type StringableVector[stupidFloat] so it doesn't have method String() string. 
> But in my poor understanding of Go, this code shouldn't compile due to 
> implicit conversion of two types.
>
> Can anyone explain to me, where am I wrong?

You are not permitted to assign directly from one named type to
another named type.  But here you are assigning an unnamed type,
[]someFloat, to a named type, StringableVector[someFloat].  Assigning
an unnamed type to a named type is permitted if the underlying type of
the named is identical to the unnamed type, which in this case it is.
The same is true in non-generic Go.  The exact rules are at
https://go.dev/ref/spec#Assignability.

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/CAOyqgcU1sOL-_h_L1xvtY-79i%3DEef6%3D9%3DafQjEANv4Q4HcriZg%40mail.gmail.com.

[go-nuts] Re: A Question about `unsafe.Slice`

[rmfr]

It suddenly occurred to me that it was very like `re-slice` —— as long as 
part of the underlying array is referenced, the whole underlying array is 
never gc-ed. I guess there is a method in gc which could locate the whole 
underlying array as long as one address inside the array's address interval 
was provided? So now I tend to believe that `Element1` is correct too, and 
the `underlyBuf` filed in `Element2` is redundant and is not quite 
necessary, am I correct?

On Sunday, February 6, 2022 at 10:08:06 AM UTC+8 rmfr wrote:

> Please take a look at the following code:
>
> ```go
> package main
>
> import (
> "fmt"
> "runtime"
> "unsafe"
> )
>
> func assert(b bool) {
> if b {
> } else {
> panic("unexpected")
> }
> }
>
> type Elementer interface {
> GetInt64Slice() []int64
> GetByteSlice() []byte
> String() string
> }
>
> type Element1 struct {
> int64s []int64
> bs []byte
> }
>
> func newElement1(int64Sz, bsSz int) *Element1 {
> assert(int64Sz > 0 && bsSz > 0)
> len0 := int64Sz * 8
> len1 := bsSz
> buf := make([]byte, len0+len1)
> for i := range buf {
> buf[i] = byte(i)
> }
> e := {
> int64s: unsafe.Slice((*int64)(unsafe.Pointer([0])), int64Sz),
> bs: unsafe.Slice((*byte)([len0]), bsSz),
> }
> return e
> }
>
> func (e *Element1) GetInt64Slice() []int64 {
> return e.int64s
> }
>
> func (e *Element1) GetByteSlice() []byte {
> return e.bs
> }
>
> func (e *Element1) String() string {
> return fmt.Sprintf("Element1:[% x % x]", e.GetInt64Slice(), 
> e.GetByteSlice())
> }
>
> type Element2 struct {
> underlyBuf []byte  // <- is this field needed?
> int64s []int64
> bs []byte
> }
>
> func newElement2(int64Sz, bsSz int) *Element2 {
> assert(int64Sz > 0 && bsSz > 0)
> len0 := int64Sz * 8
> len1 := bsSz
> buf := make([]byte, len0+len1)
> for i := range buf {
> buf[i] = byte(i)
> }
> e := {
> underlyBuf: buf,   // <-
> int64s: unsafe.Slice((*int64)(unsafe.Pointer([0])), 
> int64Sz),
> bs: unsafe.Slice((*byte)([len0]), bsSz),
> }
> return e
> }
>
> func (e *Element2) GetInt64Slice() []int64 {
> runtime.KeepAlive(e.underlyBuf)
> return e.int64s
> }
>
> func (e *Element2) GetByteSlice() []byte {
> runtime.KeepAlive(e.underlyBuf)
> return e.bs
> }
>
> func (e *Element2) String() string {
> runtime.KeepAlive(e.underlyBuf)
> return fmt.Sprintf("Element2:[% x % x]", e.GetInt64Slice(), 
> e.GetByteSlice())
> }
>
> func main() {
> var e Elementer
> fmt.Println("print with host endian:")
> e = newElement1(2, 4)
> fmt.Println("hi", e)
> e = newElement2(2, 4)
> fmt.Println("hi", e)
> }
> ```
>
> And which yields:
>
> ```
> hi Element1:[[ 706050403020100  f0e0d0c0b0a0908] 10 11 12 13]
> hi Element2:[[ 706050403020100  f0e0d0c0b0a0908] 10 11 12 13]
> ```
>
> I'm not sure whether the `underlyBuf` filed in `Element2` is needed or 
> not. When I'm reading the doc from `
> https://pkg.go.dev/reflect#SliceHeader` 
>  there is:
>
> > Moreover, the Data field is not sufficient to guarantee the data it 
> references will not be garbage collected, so programs must keep a separate, 
> correctly typed pointer to the underlying data.
>
> But in `https://pkg.go.dev/unsafe#Slice`  
> there are no such comments. So the question:
>
> Which implementation of `Elementer` is correct? `Element2` or both of them?
>
> Thanks a lot for your help.
>

-- 
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/3af951b7-2e5c-40d2-8b61-ddc59c97eef3n%40googlegroups.com.

[go-nuts] A Question about `unsafe.Slice`

[rmfr]

Please take a look at the following code:

```go
package main

import (
"fmt"
"runtime"
"unsafe"
)

func assert(b bool) {
if b {
} else {
panic("unexpected")
}
}

type Elementer interface {
GetInt64Slice() []int64
GetByteSlice() []byte
String() string
}

type Element1 struct {
int64s []int64
bs []byte
}

func newElement1(int64Sz, bsSz int) *Element1 {
assert(int64Sz > 0 && bsSz > 0)
len0 := int64Sz * 8
len1 := bsSz
buf := make([]byte, len0+len1)
for i := range buf {
buf[i] = byte(i)
}
e := {
int64s: unsafe.Slice((*int64)(unsafe.Pointer([0])), int64Sz),
bs: unsafe.Slice((*byte)([len0]), bsSz),
}
return e
}

func (e *Element1) GetInt64Slice() []int64 {
return e.int64s
}

func (e *Element1) GetByteSlice() []byte {
return e.bs
}

func (e *Element1) String() string {
return fmt.Sprintf("Element1:[% x % x]", e.GetInt64Slice(), 
e.GetByteSlice())
}

type Element2 struct {
underlyBuf []byte  // <- is this field needed?
int64s []int64
bs []byte
}

func newElement2(int64Sz, bsSz int) *Element2 {
assert(int64Sz > 0 && bsSz > 0)
len0 := int64Sz * 8
len1 := bsSz
buf := make([]byte, len0+len1)
for i := range buf {
buf[i] = byte(i)
}
e := {
underlyBuf: buf,   // <-
int64s: unsafe.Slice((*int64)(unsafe.Pointer([0])), 
int64Sz),
bs: unsafe.Slice((*byte)([len0]), bsSz),
}
return e
}

func (e *Element2) GetInt64Slice() []int64 {
runtime.KeepAlive(e.underlyBuf)
return e.int64s
}

func (e *Element2) GetByteSlice() []byte {
runtime.KeepAlive(e.underlyBuf)
return e.bs
}

func (e *Element2) String() string {
runtime.KeepAlive(e.underlyBuf)
return fmt.Sprintf("Element2:[% x % x]", e.GetInt64Slice(), 
e.GetByteSlice())
}

func main() {
var e Elementer
fmt.Println("print with host endian:")
e = newElement1(2, 4)
fmt.Println("hi", e)
e = newElement2(2, 4)
fmt.Println("hi", e)
}
```

And which yields:

```
hi Element1:[[ 706050403020100  f0e0d0c0b0a0908] 10 11 12 13]
hi Element2:[[ 706050403020100  f0e0d0c0b0a0908] 10 11 12 13]
```

I'm not sure whether the `underlyBuf` filed in `Element2` is needed or not. 
When I'm reading the doc from `https://pkg.go.dev/reflect#SliceHeader` 
there is:

> Moreover, the Data field is not sufficient to guarantee the data it 
references will not be garbage collected, so programs must keep a separate, 
correctly typed pointer to the underlying data.

But in `https://pkg.go.dev/unsafe#Slice` there are no such comments. So the 
question:

Which implementation of `Elementer` is correct? `Element2` or both of them?

Thanks a lot for your help.

-- 
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/5da1eda9-536a-4553-8405-0551792ae449n%40googlegroups.com.

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Excuse me, but I'm lost again. I think I read it in the "A Tour of Go" and 
"Go FAQ", that "In Go types just are" and "There is no implicit conversion 
of types in Go". Because of that code below doesn't compile.

> package main
>
> import "fmt"
>
> type someFloat float64
>
> func main() {
> var floatVar float64 = 1.0
> var someFloatVar someFloat = floatVar
>
> fmt.Println(someFloatVar)
> }

We need explicit type conversion "someFloat(floatVar)" to make it compile.

On the other hand this code compiled
> package main
>
> import "fmt"
>
> type Stringer interface {
> String() string
> }
>
> type StringableVector[T Stringer] []T
>
> type someFloat float64
>
> func (sF someFloat) String() string {
> return fmt.Sprintf("someFloat: %v", float64(sF))
> }
>
> func main() {
> var varStringer Stringer = someFloat(7)
> sliceSomeFloat := make([]someFloat, 3)
>
> var varStringableVector StringableVector[someFloat] = 
sliceSomeFloat
>
> fmt.Printf("varStringer type: %T\n", varStringer)
> fmt.Printf("sliceSomeFloat type: %T\n", sliceSomeFloat)
> fmt.Printf("varStringableVector type: %T\n", varStringableVector)
> }

and produced result

> stringerVar type: main.someFloat
> sliceScomeFloat type: []main.someFloat
> stringableVectorVar type: main.StringableVector[main.someFloat]

Variable stringableVectorVar is not of interface type, because in such case 
its type printed by fmt.Printf should be []main.someFloat. So, it looks 
like to me as []main.someFloat is implicitly conversed to 
main.StringableVector[main.someFloat].

Answer to my previous questions was that []stupidFloat/[]someFloat is not 
of type StringableVector[stupidFloat] so it doesn't have method String() 
string. But in my poor understanding of Go, this code shouldn't compile due 
to implicit conversion of two types.

Can anyone explain to me, where am I wrong?

Best,
Kamil
sobota, 5 lutego 2022 o 11:44:06 UTC+1 Kamil Ziemian napisał(a):

> Thank you very much for information. I think now I understand my problem. 
> I was thinking about method just as a function ("methods are just a 
> functions" is one line from "A Tour of Go", that I know but don't 
> understand its depth-in-simplicity) and for some reason I assumed 
> StringableVector[T Stringer] is a kind of constraint. A such my thinking 
> was that sliceStupidFloat is of type []stupidFloat, when stupidFloat 
> satisfying constraint Stringer, so function (method) find that such 
> constraint is satisfied.
>
> Good gopher probably from the start would understand that since 
> StringableVector[T Stringer] is NOT an interface type, it is a concrete 
> generic type, not constraint. (Is calling something "concrete generic type" 
> correct statement?) My stupid excuse is that materials on generics in Go 
> focus on using generic functions, not generic types. I don't want to be 
> misunderstood, in materials about Go I find a lot of examples how to define 
> and call generic function. There is also many examples of defining generic 
> types, but very little of creating and using objects (?) of generic types.
>
> For example "Tutorial: Getting started with generics" (
> https://go.dev/doc/tutorial/generics) deals only with generic functions. 
> I guess some additional tutorial about generic types will be good thing for 
> people like me.
>
> Best regards,
> Kamil
> sobota, 5 lutego 2022 o 02:57:23 UTC+1 Ian Lance Taylor napisał(a):
>
>> On Fri, Feb 4, 2022 at 5:01 PM Kamil Ziemian  wrote: 
>> > 
>> > 
>> > I title say, I download Go 1.18 beta (at this moment "go version 
>> go1.18beta2 linux/amd64") and I try to work through "Type Parameters 
>> Proposal" with it (
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
>>  
>> This thread is about thing that I can't code properly into Go 1.18 beta. 
>> > 
>> > I hope that you forgive me if I ask some questions before reading full 
>> proposal for the second time, previously I read in the September of the 
>> last year, and trying every solution obvious to good gopher. I have a 
>> little time and energy recently and I still want to try my hand with 
>> generics ASAP. 
>> > 
>> > I read and try every example from "Tutorial: Getting started with 
>> generics" (https://go.dev/doc/tutorial/generics), but it didn't help me 
>> with my problems. Maybe I just not advanced enough gopher (I'm at most 
>> medicore gopher) or I'm to tired recently to think creatively about Go. 
>> > 
>> > My first stumbling block is from section "Generic types" (
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#generic-types).
>>  
>> At the end of it we have code. 
>> > > type StringableVector[T Stringer] []T 
>> > > 
>> > > func (s StringableVector[T]) String() string { 
>> > > var sb strings.Builder 
>> > > for i, v := range s { 
>> > > if i > 0 { 
>> > > sb.WriteString(", ") 
>> > > } 
>> > > // It's OK to call 

Re: [go-nuts] Generic integer math limitation

['Axel Wagner' via golang-nuts]

On Sat, Feb 5, 2022 at 7:38 PM Marcelo Cantos 
wrote:

> Explicit casting is no better, and there is no promotion (e.g., cast i to
> int and cast the result back to T) that's suitable for all integer types.
>

FWIW `uint64` and `int64` are large enough to represent any un/signed
integer types respectively.
Depending on the case, as long as you can assume that your values fall in
an appropriate range, you can use one of them.

I would like to shrink the block size for (u)int8, but there's no way to
> specialize the logic for specific types.
>
> I figured out that I can use *i >> 9* instead of *i / 512* in this
> instance, though there will be other cases (divide by non-Po2) where there
> isn't a simple workaround Is there a general way around this limitation?
>
> --
> 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/6a844487-0c22-443f-8e6e-c38860929515n%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/CAEkBMfGbLYnivnwO-_d_Z%2B-PuhWZYaMUEqP-JH8Xh74_E_uFoA%40mail.gmail.com.

Re: [go-nuts] Generic integer math limitation

[Ian Lance Taylor]

On Sat, Feb 5, 2022 at 10:38 AM Marcelo Cantos  wrote:
>
> I am porting an int-set type to generics. It holds bits in a block structure 
> with 512 bits per block. At some point, I need to divide by 512:
>
> func block[T constraints.Integer](i T) T {
> return i / 512
> }
>
> Go 1.18 beta 2 complains: cannot convert 512 (untyped int constant) to T
>
> The problem is that uint8 and int8 cannot represent the number 512. If I 
> build a constraint similar to constraints.Integer that excludes ~uint8 and 
> ~int8, it works fine. Explicit casting is no better, and there is no 
> promotion (e.g., cast i to int and cast the result back to T) that's suitable 
> for all integer types. I would like to shrink the block size for (u)int8, but 
> there's no way to specialize the logic for specific types.
>
> I figured out that I can use i >> 9 instead of i / 512 in this instance, 
> though there will be other cases (divide by non-Po2) where there isn't a 
> simple workaround Is there a general way around this limitation?

It's not clear to me what is supposed to happen for the int8/uint8
case.  It sounds like your block type won't work for int8/uint8.  In
that case it seems like the right approach is to use a constraint that
doesn't permit it, as you suggest.  What other kind of workaround
would be appropriate?

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/CAOyqgcXHMRgJ1A1hKseHvkydA%2BKGO_b0sNevp-V6Gf3dxv3u7A%40mail.gmail.com.

Re: [go-nuts] decoding DWARF data

[Ian Lance Taylor]

On Sat, Feb 5, 2022 at 1:45 AM stephen.t@gmail.com
 wrote:
>
> I'm trying to decode the DWARF data in an ELF binary and I'm not sure how to 
> handle functions.
>
> I'm using the elf/dwarf package in the Go standard library and successfully 
> using it to identify compile units and source files and also to find line 
> entries for an executed address.
>
> What I can't see is how to relate a dwarf.LineEntry to a function (or 
> SubProgram as it is called in DWARF terminology).
>
> If the SubProgram TAG has both Low PC and High PC attributes then I can see 
> how it can be done. Where it gets tricky is if a SubProgram has been inlined.
>
> What I don't fully understand is how InlinedSubPrograms relate to SubPrograms.
>
> I realise that this isn't really a Go question but I'm hoping someone has 
> used the Go standard library in this way and understands how to solve this 
> problem.

The DWARF line number information maps PC values to a file name and a
line number.  It sounds like you want to map a PC value to a function,
and you want to consider inlining information.  To do that use
https://pkg.go.dev/debug/dwarf#Reader.SeekPC to get an Entry and look
for the AttrName or AttrLinkageName attribute.  Note that, as the
documentation says, SeekPC is not efficient if you need to look up a
bunch of PC values.  For that you'll want to loop through the entries,
call the Ranges method, and build a lookup table.

Hope this helps.

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

[go-nuts] Generic integer math limitation

[Marcelo Cantos]

I am porting an int-set type to generics. It holds bits in a block 
structure with 512 bits per block. At some point, I need to divide by 512:



*func block[T constraints.Integer](i T) T {return i / 512}*

Go 1.18 beta 2 complains: *cannot convert 512 (untyped int constant) to T*

The problem is that uint8 and int8 cannot represent the number 512. If I 
build a constraint similar to constraints.Integer that excludes ~uint8 and 
~int8, it works fine. Explicit casting is no better, and there is no 
promotion (e.g., cast i to int and cast the result back to T) that's 
suitable for all integer types. I would like to shrink the block size for 
(u)int8, but there's no way to specialize the logic for specific types.

I figured out that I can use *i >> 9* instead of *i / 512* in this 
instance, though there will be other cases (divide by non-Po2) where there 
isn't a simple workaround Is there a general way around this limitation?

-- 
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/6a844487-0c22-443f-8e6e-c38860929515n%40googlegroups.com.

[go-nuts] Re: Is Go good choice for porting graph based app?

[drv drv]

I don't know the background of this Python code but *" It seems 
underdeveloped, buggy and running it first time is a pain, because of 
dependencies. "* is not a language problem.
I cannot imagine any dependencies in this kind of program.
JSON "equals" dictionaries in case of Python and it supports natively so it 
is quite fast and can be write very simple and elegant code.
It is true that GO is faster (in this case I guess 2x on single core) but 
if you cannot take advance of goroutines (and multicore) use Python.

On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com wrote:

> Hello,
>
> I was handed proof-of-concept app written in Python. It seems 
> underdeveloped, buggy and running it first time is a pain, because of 
> dependencies. Basically it need to read some graphs stored in JSON files 
> and manipulated them accordingly and write them to JSON files again.
>
> It seems that porting it now to more suitable language is worth a gain at 
> this stage and I wonder if Go is a good choice? I read and watch many Ian 
> Lance Taylor presentations about generics, so I know that only that generic 
> graph (tree) data structure is something that can be a pain,  but in this 
> case it would be were small issue. It seems that we have only few data 
> types to be stored in graph, mostly strings and ints.
>
> I'm not true gopher, so I don't know if Go is proper choice for this task. 
> I don't believe that Python is any better, but maybe I should check another 
> language.
>
> Also, if someone know better thing to sore graphs than JSON, I would 
> appreciate it any suggestion.
>
> I don't write anymore about this app, since I don't know if company allows 
> for it.
>
> Best regards,
> Kamil
>

-- 
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/8c61081a-dccd-422e-a765-59e8f79fbc79n%40googlegroups.com.

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Thank you very much for information. I think now I understand my problem. I 
was thinking about method just as a function ("methods are just a 
functions" is one line from "A Tour of Go", that I know but don't 
understand its depth-in-simplicity) and for some reason I assumed 
StringableVector[T Stringer] is a kind of constraint. A such my thinking 
was that sliceStupidFloat is of type []stupidFloat, when stupidFloat 
satisfying constraint Stringer, so function (method) find that such 
constraint is satisfied.

Good gopher probably from the start would understand that since 
StringableVector[T Stringer] is NOT an interface type, it is a concrete 
generic type, not constraint. (Is calling something "concrete generic type" 
correct statement?) My stupid excuse is that materials on generics in Go 
focus on using generic functions, not generic types. I don't want to be 
misunderstood, in materials about Go I find a lot of examples how to define 
and call generic function. There is also many examples of defining generic 
types, but very little of creating and using objects (?) of generic types.

For example "Tutorial: Getting started with generics" (
https://go.dev/doc/tutorial/generics) deals only with generic functions. I 
guess some additional tutorial about generic types will be good thing for 
people like me.

Best regards,
Kamil
sobota, 5 lutego 2022 o 02:57:23 UTC+1 Ian Lance Taylor napisał(a):

> On Fri, Feb 4, 2022 at 5:01 PM Kamil Ziemian  wrote:
> >
> >
> > I title say, I download Go 1.18 beta (at this moment "go version 
> go1.18beta2 linux/amd64") and I try to work through "Type Parameters 
> Proposal" with it (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
>  
> This thread is about thing that I can't code properly into Go 1.18 beta.
> >
> > I hope that you forgive me if I ask some questions before reading full 
> proposal for the second time, previously I read in the September of the 
> last year, and trying every solution obvious to good gopher. I have a 
> little time and energy recently and I still want to try my hand with 
> generics ASAP.
> >
> > I read and try every example from "Tutorial: Getting started with 
> generics" (https://go.dev/doc/tutorial/generics), but it didn't help me 
> with my problems. Maybe I just not advanced enough gopher (I'm at most 
> medicore gopher) or I'm to tired recently to think creatively about Go.
> >
> > My first stumbling block is from section "Generic types" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#generic-types).
>  
> At the end of it we have code.
> > > type StringableVector[T Stringer] []T
> > >
> > > func (s StringableVector[T]) String() string {
> > > var sb strings.Builder
> > > for i, v := range s {
> > > if i > 0 {
> > > sb.WriteString(", ")
> > > }
> > > // It's OK to call v.String here because v is of type T
> > > // and T's constraint is Stringer.
> > > sb.WriteString(v.String())
> > > }
> > > return sb.String()
> > > }
> >
> > So, I try to code it.
> >
> > > package main
> > >
> > > import (
> > > "fmt"
> > > "strings"
> > > )
> > >
> > > type Stringer interface {
> > > String() string
> > > }
> > >
> > > type StringableVector[T fmt.Stringer] []T
> > >
> > > type stupidFloat float64
> > >
> > > func (sF stupidFloat) String() string {
> > > return fmt.Sprintf("Stupid float %v", float64(sF))
> > > }
> > >
> > > func main() {
> > > var varStupidFloat stupidFloat = -1.0
> > >
> > > sliceStupidFloat := make([]stupidFloat, 3)
> > >
> > > for i := 0; i < 3; i++ {
> > > sliceStupidFloat[i] = stupidFloat(float64(i))
> > > }
> > >
> > > fmt.Println("stupidFloat.String(): ", varStupidFloat.String())
> > >
> > > fmt.Println("sliceStupidFloat:", sliceStupidFloat)
> > >
> > > fmt.Println("sliceStupidFloat:", sliceStupidFloat)
> > // fmt.Println("sliceStupidFloat.String():", sliceStupidFloat.String())
> > > }
> > >
> > > func (s StringableVector[T]) String() string {
> > > var sb strings.Builder
> > >
> > > for i, v := range s {
> > > if i > 0 {
> > > sb.WriteString(", ")
> > > }
> > > sb.WriteString(v.String())
> > > }
> > >
> > > return sb.String()
> > > }
> >
> > It works fine and produce result.
> > > stupidFloat.String(): Stupid float -1
> > > sliceStupidFloat: [Stupid float 0 Stupid float 1 Stupid float 2]
> > > sliceStupidFloat: [Stupid float 0 Stupid float 1 Stupid float 2]
> >
> > But, when I uncommon last line in function main I get
> > > ./Go-s11-08.go:46:61: sliceStupidFloat.String undefined
> > > (type []stupidFloat has no field or method String)
> >
> > I try to change my code in several ways, but result is always the same. 
> How correct code should look like?
>
> sliceStupidFloat is a variable of type []stupidFloat. As such, it
> does not have a String method. That doesn't have anything to do with
> generics, it's just how the Go language works.
>
> Perhaps the line that you are looking for, rather than the commented
> out line, is
>
> 

[go-nuts] decoding DWARF data

[stephen.t....@gmail.com]

(This is possibly off-topic)

I'm trying to decode the DWARF data in an ELF binary and I'm not sure how 
to handle functions.

I'm using the elf/dwarf package in the Go standard library and successfully 
using it to identify compile units and source files and also to find line 
entries for an executed address.

What I can't see is how to relate a dwarf.LineEntry to a function (or 
SubProgram as it is called in DWARF terminology).

If the SubProgram TAG has both Low PC and High PC attributes then I can see 
how it can be done. Where it gets tricky is if a SubProgram has been 
inlined.

What I don't fully understand is how InlinedSubPrograms relate to 
SubPrograms. 

I realise that this isn't really a Go question but I'm hoping someone has 
used the Go standard library in this way and understands how to solve this 
problem.

Thanks.

-- 
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/6b1b4e4f-e9af-4954-9296-de50b4d548f5n%40googlegroups.com.

[go-nuts] Re: Web development with Go

[Brian Candler]

On Saturday, 5 February 2022 at 00:05:18 UTC merson...@actmedical.com.au 
wrote:

> the same app
> rewritten in Go reduces the size by a huge amount as the only thing you 
> need to include in a scratch base image is the binary plus
> some certificates.
>

I wouldn't put certificates into a container image either, and definitely 
not the related private keys.  I'd store them as kubernetes Secrets and 
provide them to the container that way.  It reduces the exposure of the 
private keys, and allows certificates to be replaced without rebuilding the 
image - e.g. to deploy the same container in two different places.

-- 
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/ebf39aae-aeee-4272-8824-45f9bc17c199n%40googlegroups.com.