[go-nuts] Re: Bitstring package?

https://github.com/RoaringBitmap/roaring -- 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

[go-nuts] Does golang uses copyOnWrite like java? where?

THX -- 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] maptype questions

On Mon, Jun 29, 2020 at 6:33 PM arthurwil...@gmail.com wrote: > > On Monday, June 29, 2020 at 8:16:14 PM UTC-5 Ian Lance Taylor wrote: >> >> On Mon, Jun 29, 2020 at 5:32 PM Bill Morgan >> wrote: >> > >> > for this code: >> > >> > m := make(map[int]int, 9) >> > >> > I think the compiler creates a

Re: [go-nuts] Bitstring package?

Won't https://golang.org/pkg/math/bits/ do? > On Jun 29, 2020, at 6:58 PM, hardconnect@gmail.com wrote: > > I'm looking for a package that implements arbitrary length bit strings and > supports set all, clear all, set and reading back of arbitrary bits

Re: [go-nuts] Bitstring package?

Probably math/big.Int will do what you want. Dan On Mon, 2020-06-29 at 18:58 -0700, hardconnect@gmail.com wrote: > I'm looking for a package that implements arbitrary length bit > strings and > supports set all, clear all, set and reading back of arbitrary bits > and setting and clearing

[go-nuts] Bitstring package?

I'm looking for a package that implements arbitrary length bit strings and supports set all, clear all, set and reading back of arbitrary bits and setting and clearing the next set or unset bit. I've seen a couple of packages that come close. Does anyone know of a package that meets all my

Re: [go-nuts] maptype questions

On Monday, June 29, 2020 at 8:16:14 PM UTC-5 Ian Lance Taylor wrote: > On Mon, Jun 29, 2020 at 5:32 PM Bill Morgan > wrote: > > > > for this code: > > > > m := make(map[int]int, 9) > > > > I think the compiler creates a maptype that is stored at > type.*+60480(SB) that it uses for the

Re: [go-nuts] maptype questions

On Mon, Jun 29, 2020 at 5:32 PM Bill Morgan wrote: > > for this code: > > m := make(map[int]int, 9) > > I think the compiler creates a maptype that is stored at type.*+60480(SB) > that it uses for the call to runtime.makemap: > > m := make(map[int]int, 9) > 0x10d0b81 488d05f8ec LEAQ

[go-nuts] maptype questions

for this code: m := make(map[int]int, 9) I think the compiler creates a maptype that is stored at type.*+60480(SB) that it uses for the call to runtime.makemap: m := make(map[int]int, 9) 0x10d0b81 488d05f8ec LEAQ type.*+60480(SB), AX 0x10d0b88 48890424 MOVQ AX, 0(SP) 0x10d0b8c

Re: [go-nuts] Port to powerpc 440fpu

On Mon, Jun 29, 2020 at 1:01 AM Hugo Cornelis wrote: > > The standard Go distribution doesn't support 32-bit PPC. > > To compile Golang code to 32-bit PPC we first built a proof of concept based > on docker-cli using the gccgo packages for Ubuntu. We got this working > without too much effort.

Re: [go-nuts] Re: Generic syntax idea

On Mon, Jun 29, 2020 at 7:28 PM Jake Montgomery wrote: > I'm curious how you would propose rewriting: > func Foo(type T comparable, B interface{})(a T, b B, c T) { > You could just annotate each distinct type on first appeareance: func Foo(a T:type comparable, b B:type interface{}, c T) { >

Re: [go-nuts] Expanding variables and fmt.Printf() issue

[pedantic correction] * Marvin Renich [200629 14:10]: > The final argument to Printf is []interface{}, while you are trying to ^ ...interface{} ...Marvin -- You received this message because you are subscribed to the Google

Re: [go-nuts] Expanding variables and fmt.Printf() issue

* yves baumes [200629 03:22]: > Hello, > > considering this code > > ``` > package main > > import ( > "fmt" > ) > > func main() { > host := []string{"127", "0", "0", "1"} > > fmt.Printf("%v.%v.%v.%v\n", host[0], host[1], host[2], host[3]) > fmt.Printf("%v.%v.%v.%v\n", host[0:4]...) > } >

[go-nuts] Go Lang @ Plano,TX

Hi, Hope You Are Doing Well. If You Are Interested with Below Position Please Forward Me Your Updated Resume As Soon As Possible. *Go Lang Developers w/Testing background * *Plano, TX * *Long Term Contract* *Responsibilities: * • 3-5 years of strong API development experience

[go-nuts] Re: Generic syntax idea

I'm curious how you would propose rewriting: func Foo(type T comparable, B interface{})(a T, b B, c T) { On Friday, June 19, 2020 at 6:57:45 PM UTC-4, mit...@gmail.com wrote: > > Hello, Ian, > > Would it be possible to have a generic type annotation syntax like this: > > // Print prints the

Re: [go-nuts] text template and white space suppression

Maybe templating engines help.. here's one example. https://github.com/gobuffalo/plush On Mon, Jun 29, 2020 at 3:27 AM Bill Nixon wrote: > I am trying to do some creative formatting using text template and wanted > to see if there might be a better approach than what I implemented. > > I have

Re: [go-nuts] Why does function escape to heap?

On Mon, Jun 29, 2020 at 5:15 PM Pure White wrote: > I would like to know: > 1. How can a function "escapes to heap"? Isn't it a pointer to the code > area? It is not:

[go-nuts] Re: godoc.org (and pkg.go.dev) only showing one global function?

The go doc command lists these under global functions, whereas godoc.org and pkg.go.dev was listing them under the base type they return for example ParseAcceptLang was listed under Tag. The difference between go doc and the web based documentation confused me. Shouldn't the output of both ways

[go-nuts] godoc.org (and pkg.go.dev) only showing one global function?

I am having problems that some of the docs I am looking at show only one single line of exported global functions. Example here https://godoc.org/golang.org/x/text/language#pkg-index Running this command: go doc golang.org/x/text/language I get much more exported global functions: ... func

[go-nuts] Re: Expanding variables and fmt.Printf() issue

> If I use append() instead of Printf(), this expanding of the host > variables just works out. Is this a compiler bug in the case of the > fmt.Printf() ? > I doubt that append("%v.%v.%v.%v\n", host[0:4]...) does compile. V. -- You received this message because you are subscribed to

Re: [go-nuts] Port to powerpc 440fpu

Hi, The standard Go distribution doesn't support 32-bit PPC. To compile Golang code to 32-bit PPC we first built a proof of concept based on docker-cli using the gccgo packages for Ubuntu. We got this working without too much effort. Afterwards we integrated this type of cross-compilation into

Re: [go-nuts] Expanding variables and fmt.Printf() issue

On Mon, Jun 29, 2020 at 9:22 AM yves baumes wrote: > If I use append() instead of Printf(), this expanding of the host variables > just works out. Is this a compiler bug in the case of the fmt.Printf() ? No bug. That's how variable arguments and assignability rules are specified to work. --

[go-nuts] Expanding variables and fmt.Printf() issue

Hello, considering this code ``` package main import ( "fmt" ) func main() { host := []string{"127", "0", "0", "1"} fmt.Printf("%v.%v.%v.%v\n", host[0], host[1], host[2], host[3]) fmt.Printf("%v.%v.%v.%v\n", host[0:4]...) } ``` The first Printf works and prints the host value. While the