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
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
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
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
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
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
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
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
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
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.)
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 <
>
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
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),
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
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
15 matches
Mail list logo