Hi all,
I have ran the commands in https://go.googlesource.com/gollvm/#installing,
(I did not run `ninja install-gollvm`). Then I set the path of bin folder
to my $PATH using `export PATH=build-debug/bin:$PATH`.
Finally, I was able to run `go build/run test.go` successfully.
But my problem is
On Sat, 2021-06-26 at 20:44 -0700, Ian Lance Taylor wrote:
> Looks like you have multiple SearchResults values that refer to the
> same map.
Shouldn't that result in a panic, even without -race?
Dan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" gr
Hi,
*cmake -DCMAKE_INSTALL_PREFIX=/my/install/dir -DCMAKE_BUILD_TYPE=Release
-DLLVM_USE_LINKER=gold -G Ninja ../llvm-project/llvm*
I have tried to run the above command with updated third-party
repositories(latest llvm-project) and got the below error. Any idea on this?
*error: ‘class llvm::opt
On Sat, Jun 26, 2021 at 3:27 PM Rory Campbell-Lange wrote:
>
> I'm trying to work out why I have a data race problem (on go 1.15 and 1.16).
>
> *SearchResults.Set is called from several goroutines. I am trying to avoid
> concurrent access to its two maps using a mutex, but this isn't working.
>
>
I agree. So far, I've Installed Go1.15, reinstalled the Firebird library.
Compiled using Go1.15 and the problem persist. Trying to install Go1.14.9
but I'm not yet successful. I suppose Go1.14 is now deprecated so the
normal procedure to have it coexist with the later versions doesn't work.
On
You're going to need to provide more detail. Specifically, a minimal
reproducer. There is no obvious explanation for the race given what you've
already shown us so I suspect you've omitted an important fact.
On Sat, Jun 26, 2021 at 3:27 PM Rory Campbell-Lange
wrote:
> I'm trying to work out why
Try to use sync.RWMutex instead, you have more control when to read or
write.
Em sáb, 26 de jun de 2021 18:34, 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> escreveu:
> On Sat, 2021-06-26 at 23:26 +0100, Rory Campbell-Lange wrote:
> > I'm trying to work out why I have a data rac
Hi,
I am trying to get my programs up-to-date. I am looking for simple
graphics/image example programs for X11 and OpenGL. I have difficulty
running my old programs in Ubuntu 20.04 and newer versions.
It can be as simple as something like what we see here:
https://stackoverflow.com/questions/4907
On Sat, 2021-06-26 at 23:26 +0100, Rory Campbell-Lange wrote:
> I'm trying to work out why I have a data race problem (on go 1.15 and
> 1.16).
>
> *SearchResults.Set is called from several goroutines. I am trying to
> avoid concurrent access to its two maps using a mutex, but this isn't
> working.
I'm trying to work out why I have a data race problem (on go 1.15 and 1.16).
*SearchResults.Set is called from several goroutines. I am trying to avoid
concurrent access to its two maps using a mutex, but this isn't working.
108 type SearchResults struct {
109 Boxes map[string][]Box
110 s
When the query works with other DBs & their Go drivers this strongly
suggest that there is some incompatibility of the Firebird vs. Go 16.x.
Thus you should check the suggestion from Jake to update the Firebird
driver for Go.
In the Github project
https://github.com/nakagami/firebirdsql/commits/
Hi,
Thank you for your detailed explanation. I will try your suggestions and
let you know.
I used this cmake command.
`cmake -DCMAKE_INSTALL_PREFIX=/my/install/dir -DCMAKE_BUILD_TYPE=Release
-DLLVM_USE_LINKER=gold -G Ninja ../llvm-project/llvm`
Then I used, `ninja gollvm`, and it was successf
That is a possibility. I didn't try to rebuild under Go1.14., but I will
give that a try. Interestingly, one "select query" worked but the others
failed with similar error messages. After upgrading to G1.16 I ran "go
tidy" which downloaded the libraries and create a "mod" file in the working
f
Is it possible that the version of the library you are using also changed
when you changed versions of Go?
Have you tried building again, on the same machine, using Go 1.14 to make
sure that the only difference is the Go language version?
On Thursday, June 24, 2021 at 11:14:30 AM UTC-4 hugh@
Yeah, I noticed that and wondered if it could lead to problems. I don't
know enough about how the compiler works to know if it could. Personally, I
would think it would likely be better to be consistent either way. But I'll
let someone who knows more take this one.
On Sat, Jun 26, 2021 at 2:05 PM
I agree this is not a real problem in practice. It is just an aesthetics
problem.
No tests are broken if the consistency is made.
BTW, in the function "walkStringToBytes", there is a comparison "len(sc) <=
int(ir.MaxImplicitStackVarSize)",
which is inconsistent with other uses of MaxImplicitStac
Out of interest, I chased this down a bit using `git blame`. I think the
code in its current form (more or less - some constants where introduced
later and things where moved around a bit here and there) was introduced
here:
https://go-review.googlesource.com/c/go/+/10268/
It seems checks from mult
Sorry, a typo in title. It should be "comparison".
On Saturday, June 26, 2021 at 5:50:55 AM UTC-4 tapi...@gmail.com wrote:
>
> The code:
> https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025
>
> xxx > ir.MaxStackVarSize
The code:
https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025
xxx > ir.MaxStackVarSize
xxx >= ir.MaxImplicitStackVarSize
This leads to the elements of a slice with size as ir.
MaxImplicitStackVarSize will be allocated
If we're talking about an OSS project here, then having one of the
dependencies vanish is "just" a case of replacing that dependency in the
project. That is, it's part of normal project maintenance, in the same way
that if a severe security issue were discovered in a dependency, you'd have
to
Maybe the answer is something like:
- DO NOT vendor in OSS go library repos. Use go proxies, or at least, let
library consumers use go proxies with your library and do not force your
deps on them.
- Have the CLI/compilable repo do the vendoring.
- Even better, keep all your repos unvendored and
21 matches
Mail list logo
