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
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 a
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 someF
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 interva
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
}
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() {
>
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 respe
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 comp
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
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
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
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 St
(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 exec
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 contain
14 matches
Mail list logo