are already heavily styled, which comes with initial
> convenience but can quickly get in your way when you're trying to customize -
> so this concept full separates the functionality from the styling).
>
> My personal time for this is pretty limited, but I'm definitel
Hello,
As noted in the Go Wiki for WebAssembly
"Note: The same major Go version of the compiler and wasm_exec.js support file
must be used together. That is, if main.wasm file is compiled using Go version
1.N, the corresponding wasm_exec.js file must also be copied from Go version
1.N. Other comb
Hi,
Could someone please clarify the intent of the slog.LevelVar.Set method?
Specifically is it the intent that slog.LevelVar.Set should set the logging
level regardless of the underlying handler (std or 3rd party package)?
To achieve this should all 3rd party handlers implement a "Level" field
Hi Dave,
As the original author of the post that Dan has referenced, I can say
that Go does indeed make IMHO a good first programming language. It all
comes down to how you explain things. Thanks Dan for the reference :)
I'm not going to repeat what the original discussion said, but let me
try to p
Hi David,
Ah ha, magic. And all fixed. Sometimes another pair of eyes is all that
is required.
While I had no doubt the race detector was correct in reporting the
race the key line in the reply was "The only goroutine that can safely
close a channel is the one that is writing to it." After that
ev
Hi All,
I am stumped by this one, so I am hoping that someone on the list can
spot the bug in this piece of code.
The code is here:
https://play.golang.org/p/c3356cVtWa
The code occasionally (roughly 1 in 10 to 1 in 5 on my hardware) fails
with the data race shown below.
The code uses a fairly
ailored advice.
Owen
On Tue, 2017-04-11 at 19:47 +0100, Owen Waller wrote:
> Hi Bala,
>
> > Good news, this entirely possible. I've been there done that. My
original post on the subject is here:
>
> > https://groups.google.com/forum/#!msg/golang-nuts/FIRSDBehb3g/BFiH
Hi Bala,
Good news, this entirely possible. I've been there done that. My
original post on the subject is here:
https://groups.google.com/forum/#!msg/golang-nuts/FIRSDBehb3g/BFiHYVNCw
zUJ
So, I can tell you that you can do this with 10/11 year olds and
upwards.
It would help enormously if you c
Hi Dimitry,
>
>
> The make goal of the current mapping is to make MemToShadow function
> fast (no memory accesses, no branching).
> For starters you can take any simple mapping at the cost making
> MemToShadow slower.
>
OK that's good. As I wasn't intending to do anything apart from put in the
> > > > Why are 64-bit atomic load and stores required? To take an example.
ARM6
> > > > cores have have load stores for a very long time[1]. But being a
32-bit core
> > > > that's usually attached to a 32 bit memory bus, the instructions
are 32-bit.
> > > > So is it just that an atomic pair of loa
Hi Dimitry,
> > > > ThreadSanitizer does not work on any 32-bit platforms. It assumes
that
> > it can reserve huge continuous chunks of address space for various
> > things.
> >
> >
> >
> >
> > > > Tsan reserves 4X for shadow memory (where X is amount of memory
where
> > > > user data resides)
Hi Dimitry,
>
> If there is somebody who is willing to work on this, then yes. Otherwise,
> maybe.
I have created https://github.com/golang/go/issues/19273 in order to
track this.
> > > > ThreadSanitizer does not work on any 32-bit platforms. It assumes
that
> > it can reserve huge continuou
Hi Dimitry,
> > C++ ThreadSanitizer works on arm64. So making it work for Go should
be
> a modest amount of work.
Thanks for confirming this. Should I now Open a issue on Github so we
can track adding this?
Also, does it exist for any other platforms?
There are hints of PPC64. What about MIPS64?
Hi Ian,
>
> Go's race detector is based on and uses Thread Sanitizer, which has
> only been implemented for amd64. I'm not aware of any effort to
> extend thread sanitizer to other processors. That would have been
> done before there is any likelihood of Go supporting it.
>
> Ian
Thanks for th
Hi Everyone,
I am assuming that the race detector is not yet supported on ARM
hardware. Having just tried to cross compile some code I am seeing:
go build: -race and -msan are only supported on linux/amd64,
freebsd/amd64, darwin/amd64 and windows/amd64.
The 1.8 docs back this up as well.
Does a
Done. The new issue is:
https://github.com/hybridgroup/gobot/issues/372
I have also updated my sample code after spotting a stupid mistake. The
result is exactly the same however.The code shows no errors and there
are no lights n the PiGlow.
The updated code is here:
https://play.golang.org/p/Xm
Hi Everyone,
With the release of GoBot 1.2 I thought I would try and put together a
"metal bot" for the PiGlow on a Raspberry Pi 1.
The PiGlow is based around a SN3218 IC that drives the 18 leds on the
board. The SN3218 communication with the Pi is via 12c.
GoBot 1.2 rewrote the i2c subsystem, b
17 matches
Mail list logo
