Hi,
Well, you are using a 3th party lib for assertion, and you haven't told
which one, so it's hard to reason about it. one idea is to check the
library's docs to ensure it's ding the comparison as you expect.
2 things would help to get some insight on your problem are:
- format the code,
nishant gupta,
You have a bug in your validateK8ResourcesLength function.
A fix:
https://play.golang.org/p/olKsOOWAmzC
Peter
On Friday, January 29, 2021 at 12:53:01 PM UTC-5 nishant...@gmail.com wrote:
> Hi Gophers,
>
> Being new to programming and to Golang i am running into issues while
>
Not yet, but probably an go 1.17: https://github.com/golang/go/issues/395
On Mon, Feb 1, 2021 at 1:38 PM Amit Lavon wrote:
> I know it's possible to create a slice variable from an array with the [:]
> syntax, and it points to the same underlying buffer.
> Can one do the opposite? Given a
On Mon, Feb 1, 2021 at 1:38 PM Amit Lavon wrote:
> I know it's possible to create a slice variable from an array with the [:]
> syntax, and it points to the same underlying buffer.
> Can one do the opposite? Given a slice, create an array variable based on the
> same buffer?
Arrays are values
I'm trying to put external library under the interface but it seems that
this is not possible the way I thought it would be...
My interfaces are as following...
*type Beginner interface {Begin(ctx context.Context) (Tx, error)}type
Querier interface {Exec(ctx
I know it's possible to create a slice variable from an array with the [:]
syntax, and it points to the same underlying buffer.
Can one do the opposite? Given a slice, create an array variable based on
the same buffer?
Amit
--
You received this message because you are subscribed to the
Thanks! Something to look forward to.
On Mon, Feb 1, 2021 at 2:43 PM Axel Wagner
wrote:
> Not yet, but probably an go 1.17: https://github.com/golang/go/issues/395
>
> On Mon, Feb 1, 2021 at 1:38 PM Amit Lavon wrote:
>
>> I know it's possible to create a slice variable from an array with the
Hi,
this is answered (to a degree) in the FAQ:
https://golang.org/doc/faq#covariant_types
On Mon, Feb 1, 2021 at 2:51 PM Miha Vrhovnik
wrote:
>
> I'm trying to put external library under the interface but it seems that
> this is not possible the way I thought it would be...
>
> My interfaces
here is the code:
package main
import "fmt"
func main() {
counter := 0
ch := make(chan struct{}, 1)
closeCh := make(chan struct{})
go func() {
counter++ //(1)
ch <- struct{}{}
}()
go func() {
_ = <-ch
fmt.Println(counter) //(2)
close(closeCh)
}()
_ =<-closeCh
}
is (1) happens before (2)?
> On 1 Feb 2021, at 22.05, xie cui wrote:
>
> here is the code:
> package main
>
> import "fmt"
>
> func main() {
> counter := 0
> ch := make(chan struct{}, 1)
> closeCh := make(chan struct{})
> go func() {
> counter++ //(1)
> ch <-
Yes.
1. `counter++` happens-before `ch <- struct{}{}`, because in a single
goroutine, happens-before is equivalent with lexical statement order
2. `ch <- struct{}{}` happens-before `<-ch` completes, because "A send on a
channel happens before the corresponding receive from that channel
On Fri, Jan 29, 2021 at 6:52 PM nishant gupta wrote:
> Being new to programming and to Golang i am running into issues while
> asserting my test case. Looking for help here from the pros -
> Any help is appreciated in this regards. Thanks in advance.
Possibly not a popular advice: When
On Sat, 30 Jan 2021 at 20:12, Christian Worm Mortensen wrote:
> Hi Mike,
>
> Thank you for your consideration. I think you exactly got the essence of
> my question: How do I wait on all go routines to finish (or be blocked on
> one or more channels) before advancing time.
>
This is an
On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 wrote:
>
>
> $ go version
> go version go1.13 linux/amd64
>
>
> I'm not sure how to deal with this phenomenon when I find that the parallel
> performance using go routine is not very good when writing database(olap)
> code.
What does runtime.GOMAXPROCS(0)
On Mon, Feb 1, 2021 at 10:35 AM saurav deshpande
wrote:
>
> Hello, I am trying to run a make file but it gives me the following error:
> go.mod: 1: module: not found
> go 1.15: unknown command
...
> go.o:
> @mkdir -p $(BUILD_DIR)
> @echo "[go] compiling go sources into a standalone .o file"
>
Hello, I am trying to run a make file but it gives me the following error:
*go.mod: 1: module: not found*
*go 1.15: unknown command*
here is the make file:
OS = $(shell uname -s)
ARCH := x86
BUILD_DIR := build
BUILD_ABS_DIR := $(CURDIR)/$(BUILD_DIR)
export SHELL := /bin/bash -o pipefail
LD :=
We have a go.mod file.
The same make file worked with go 1.9.7 version, it did not support mod.
I am trying to make this work with go 1.15, can you please suggest changes
that would make this work.
Thank you
On Tuesday, February 2, 2021 at 12:48:51 AM UTC+5:30 Ian Lance Taylor wrote:
> On
I can't find the announcement off hand, but I remember gopls being
announced as stable at least a few months ago. Like Brian, I think this
documentation needs to be updated.
Anecdotally, I was around and using gopls back when it was definitely not
stable. It's gotten leagues better and now I have
Here we go: https://pastebin.com/6c6rq92K
The code to access the C lib was generated with c-for-go, so there is a lot
of house-keeping stuff going on. However, I don't think this has any
influence on the C code data.
I implemented getCHeight (see commented lines 155ff, to access the C data
If it works, it's fine, I'll just keep using vtune. I only work on x86
anyway. That said, I found another miracle, my program has 13 routines as
soon as it starts. It's so peculiar. I simply can't understand why this is.
This is my code:
[image: 2021-02-02 15-45-01 的屏幕截图.png]
And then this is
Note: I don't use the init function
在2021年2月2日星期二 UTC+8 下午3:48:26<颜文泽> 写道：
> If it works, it's fine, I'll just keep using vtune. I only work on x86
> anyway. That said, I found another miracle, my program has 13 routines as
> soon as it starts. It's so peculiar. I simply can't understand why
runtime.GOMAXPROCS(0) = 8, I write cpu-intensive olap databases, and the
basic principle of routines is smaller than the cpu, which I still control.
However, I found that routines can be very harsh and lead to a linear
performance increase, whereas the same implementation in cpp and c did not
Os: ubuntu 18.04
Arch: arm64 linux
go version: go1.15.7
What did I do:
$ go get -u golang.org/x/tools/...
package mvdan.cc/gofumpt/format: unrecognized import path
"mvdan.cc/gofumpt/format": reading
https://mvdan.cc/gofumpt/format?go-get=1: 404 Not Found
But with the tip version of Go, I can
That is not what you told us, but perhaps there is a misunderstanding. In
your first message you said:
> My machine has exactly 8 cpu's and I found that the runtime does not
decrease linearly when the number of go routines increases.
Are you saying that the runtime does not decrease linearly
I don't understand what you mean.
在2021年2月2日星期二 UTC+8 上午10:56:41 写道：
> Having more cpu bound routines than you have physical cpus is not a good
> idea.
>
> On Feb 1, 2021, at 8:21 PM, 颜文泽 wrote:
>
> I'll try 1.14, when writing cpu-intensive programs (I'm mainly a
> database), I found that
Sorry, my machine has a cpu core of 8. I wrote the code this way because
the main routine is also involved in the calculation. So there will be code
like i = 1; i < Mcpu.
I considered the main routines when trying to control that the number of
routines is not more than the number of cpu. This
I don't know much about the internal implementation of golang, sorry. I was
a c programmer and I tried to implement the original logic (olap database)
by using routine as a thread replacement. But I found that I would
encounter bottlenecks, and I don't know how to solve them. Maybe I should
Unless it is an in memory database, I would expect the IO costs to dwarf the
cpu costs, but I guess a lot depends on how you define ‘analytical processing’.
In my experience, “out of the box” performance of Go routines in IO processing
is outstanding.
For the cpu bound case, I think with
Dnia 2021-02-01, o godz. 11:12:22
Ian Lance Taylor napisał(a):
> On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 wrote:
> > go version go1.13 linux/amd64
> Goroutines that run for a long time without yielding the processor are
> preempted.
Since go1.14 TMK. OP is using 1.13.
> > I'm not sure how to
I'll try 1.14, when writing cpu-intensive programs (I'm mainly a database),
I found that cache misses from routines switching is also a headache and I
don't know how to deal with it.
在2021年2月2日星期二 UTC+8 上午8:10:12 写道：
> On Mon, Feb 1, 2021 at 4:07 PM Wojciech S. Czarnecki
> wrote:
> >
> >
But the number of my routines is smaller than the number of cpu
在2021年2月2日星期二 UTC+8 上午11:17:55 写道：
> If you look at the “disrupter pattern” you’ll see what I mean. If the
> tasks are cpu bound - by having more threads/routines than cpus you cause
> inefficiencies (scheduling overhead, cache
On Mon, Feb 1, 2021 at 4:07 PM Wojciech S. Czarnecki wrote:
>
> Dnia 2021-02-01, o godz. 11:12:22
> Ian Lance Taylor napisał(a):
>
> > On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 wrote:
>
> > > go version go1.13 linux/amd64
>
> > Goroutines that run for a long time without yielding the processor are
>
Having more cpu bound routines than you have physical cpus is not a good idea.
> On Feb 1, 2021, at 8:21 PM, 颜文泽 wrote:
>
> I'll try 1.14, when writing cpu-intensive programs (I'm mainly a database),
> I found that cache misses from routines switching is also a headache and I
> don't know
You wrote “I found that cache misses from routines switching is also a
headache”.
They would not be switching if they are cpu bound and there are less of than
number of cpus. Remember too that you need some % of the cpus to execute the
runtime GC code and other housekeeping.
> On Feb 1,
Vtune is very useful for squeezing the ultimate performance out of Go
programs, once you have done
the usual optimisation, mimized allocations, io etc.
pprof is more than adequate for the average programmer. But when you need
to super-optimise
functions which implement math kernels, crypto
Here's the related issue that refers to enabling `gopls` be default:
https://github.com/golang/vscode-go/issues/1037
On Tue, Feb 2, 2021, 06:24 Tyler Compton wrote:
> I can't find the announcement off hand, but I remember gopls being
> announced as stable at least a few months ago. Like
If you look at the “disrupter pattern” you’ll see what I mean. If the tasks are
cpu bound - by having more threads/routines than cpus you cause inefficiencies
(scheduling overhead, cache locality / invalidation, lock contention).
> On Feb 1, 2021, at 9:02 PM, 颜文泽 wrote:
>
>
> I don't
One more question, is it effective to use vtune to tune golang. I am afraid
that vtune is not suitable, although intel claims to be effective.
在2021年2月2日星期二 UTC+8 下午2:32:40<颜文泽> 写道：
> Thanks, it's not memory db, but my current test is not involving io. I'll
> take time to look at your
On Mon, Feb 1, 2021 at 11:24 AM saurav deshpande
wrote:
>
> We have a go.mod file.
> The same make file worked with go 1.9.7 version, it did not support mod.
> I am trying to make this work with go 1.15, can you please suggest changes
> that would make this work.
What does your go.mod file look
I know all about the problems of FP comparison, and yes I know that I need
to provide more information. What makes me suspicious is, that I have a
bunch of equivalent tests before the failing one, and all pass. I still
believe in the determinism of programs. Hence, this is all really strange.
This twitter announcement was made today about the Gopls language server
being enabled by default in the VSCode editor.
https://twitter.com/golang/status/1356289079575506950
Is this a wise move, seeing as though the documentation for Gopls states:
"It is currently in *alpha*, so it is *not
In this particular case, I would assume that documentation is outdated.
They've been hard at work on gopls and would not set an unstable tool as
the default, as evidenced by them developing it as the not-default for some
time now.
On Mon, Feb 1, 2021 at 3:15 PM 'kale...@googlemail.com' via
it just contains:
module babyLotus
go 1.15
On Tuesday, February 2, 2021 at 3:04:39 AM UTC+5:30 Ian Lance Taylor wrote:
> On Mon, Feb 1, 2021 at 11:24 AM saurav deshpande
> wrote:
> >
> > We have a go.mod file.
> > The same make file worked with go 1.9.7 version, it did not support mod.
> > I
It turns out that you were right. Despite my antivirus not logging
anything, and the directories and executables being allowed, they were
blocked.
An antivirus update seems to have resolved it.
On Tue., Jan. 26, 2021, 3:28 a.m. Wojciech S. Czarnecki,
wrote:
> Dnia 2021-01-25, o godz. 11:07:50
$ go version
go version go1.13 linux/amd64
I'm not sure how to deal with this phenomenon when I find that the parallel
performance using go routine is not very good when writing database(olap)
code. I have written the following example to verify this:
```
package main
import (
"fmt"
On Mon, Feb 1, 2021 at 1:52 PM Robert M. Münch
wrote:
>
> I know all about the problems of FP comparison, and yes I know that I need to
> provide more information. What makes me suspicious is, that I have a bunch of
> equivalent tests before the failing one, and all pass. I still believe in the
On Mon, Feb 1, 2021 at 1:42 PM saurav deshpande
wrote:
>
> it just contains:
>
> module babyLotus
>
> go 1.15
The module name should probably be a path name.
I bet that "go build -n" is printing an error, and you are piping that
error to sh.
Ian
> On Tuesday, February 2, 2021 at 3:04:39 AM
47 matches
Mail list logo
