Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

2021-01-18 Thread 'Axel Wagner' via golang-nuts
Hi, On Tue, Jan 19, 2021 at 6:47 AM mortdeus wrote: > The more I look at the proposed generic syntax the more I feel like a > texan fearing the californian relocation to my state. In other words I am > feeling like Go had something awesome and extremely conservative going on > in terms of

Re: [go-nuts] [ANN] New Go package: xmorph

2021-01-18 Thread Tyler Compton
That GIF makes me very happy. It reminds me of the Animorphs book covers made with Elastic Reality :) On Mon, Jan 18, 2021 at 12:24 PM Scott Pakin wrote: > It's perhaps a bit of a niche tool, but I just released *xmorph*, a > package for warping and morphing images. The code is available from

[go-nuts] Re: instead of generics, why cant we just implement an "any" builtin?

2021-01-18 Thread mortdeus
And you might argue, well hell this is no different than proposing func Sort(a, b interface{}[]){ if a.(type) ... } Exactly because the language isn't broken. C gets along just fine without generics. In fact that is considered a feature of the language. What absolutely doesn't scale is

[go-nuts] instead of generics, why cant we just implement an "any" builtin?

2021-01-18 Thread mortdeus
The more I look at the proposed generic syntax the more I feel like a texan fearing the californian relocation to my state. In other words I am feeling like Go had something awesome and extremely conservative going on in terms of syntax and because people from other super convoluted languages

[go-nuts] Instead of convoluted generics why can't we just have an "any" builtin?

2021-01-18 Thread mortdeus
The more I look at the proposed generic syntax the more I feel like a texan fearing the californian relocation to my state. In other words I am feeling like Go had something awesome and extremely conservative going on in terms of syntax and because people from other super convoluted languages

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

2021-01-18 Thread Peter Wilson
Robert I was interested in channel peformance only because it's the 'go idiom'. Channel communication is relatively complex, and so is a useful upper limit to costs of inter-goroutine synchronisation. It's reassuring to see that 50nsec per operation is what my machinery delivers. Simpler

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

2021-01-18 Thread Robert Engels
Channels are built with locks which without biased locking can lead to delays as routines are scheduled / blocked under -especially under contention. github.com/robaho/go-concurrency-test might illuminate some other options to try. > On Jan 18, 2021, at 8:13 PM, Pete Wilson wrote: > > No

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

2021-01-18 Thread Pete Wilson
No need to beg forgiveness. For me, the issue is the synchronisation, not how the collection is specified. You’re right; there’s no reason why a slice (or an array) couldn’t be used to define the collection. In fact, that’s the plan. But the synchronisation is still a pain. FWIW I built a

[go-nuts] unable to access 'https://github.com/labstack/gommon/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

2021-01-18 Thread Barry Goldstein
I'm getting this error when trying to do a "go get" for external dependencies. fatal: unable to access 'https://github.com/labstack/gommon/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version I was running go 1.15, so I upgraded to 1.15.6 and still getting the

[go-nuts] [ANN] New Go package: xmorph

2021-01-18 Thread Scott Pakin
It's perhaps a bit of a niche tool, but I just released *xmorph*, a package for warping and morphing images. The code is available from https://github.com/spakin/xmorph (If nothing else, you can see there my crude attempt at morphing the cartoon Go gopher into the corresponding plush toy.)

Re: [go-nuts] nil pointer ref can't figure out why

2021-01-18 Thread 'Axel Wagner' via golang-nuts
You might want to use `Printf("the dao: %+v", dao)`, for example - it will also print type-names and should make it more obvious what you have. On Mon, Jan 18, 2021 at 9:16 PM Axel Wagner wrote: > On Mon, Jan 18, 2021 at 9:12 PM 'Alexander Mills' via golang-nuts < >

Re: [go-nuts] nil pointer ref can't figure out why

2021-01-18 Thread 'Axel Wagner' via golang-nuts
On Mon, Jan 18, 2021 at 9:12 PM 'Alexander Mills' via golang-nuts < golang-nuts@googlegroups.com> wrote: > does anyone know why calling the method would result in a nil pointer? To > me it seems like the object for which the method is being called is nil > No, it is a pointer to a struct with

[go-nuts] nil pointer ref can't figure out why

2021-01-18 Thread 'Alexander Mills' via golang-nuts
I have this line: fmt.Printlin("the dao:", dao); and it logs: the dao: &{ } the overall method looks like: func (dao *UserAttributeDao) GetDecryptedUserAttributes(workflowID string) (*PayoutUserAttributeRecord, error) { getItemInput := { TableName: aws.String(payoutUserAttributesTableName),

Re: [go-nuts] Advice, please

2021-01-18 Thread Bakul Shah
On Jan 18, 2021, at 4:39 AM, Kevin Chadwick wrote: > > On 1/17/21 4:46 PM, Bakul Shah wrote: >> I’d be tempted to just use C for this. That is, generate C code from a >> register >> level description of your N simulation cores and run that. That is more or >> less >> what “cycle based” verilog

Re: [go-nuts] Advice, please

2021-01-18 Thread Kevin Chadwick
On 1/17/21 4:46 PM, Bakul Shah wrote: > I’d be tempted to just use C for this. That is, generate C code from a > register > level description of your N simulation cores and run that. That is more or > less > what “cycle based” verilog simulators (used to) do. The code gen can also > split > it