[go-nuts] [slog] Intent of slog.LevelVar.Set and slog.HandlerOptions

[Owen Waller]

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 in
their HandlerOptions struct, and respect it's value if changed?

I am looking to moving our codebase over to the new slog, but we already have
logging via the uber zap logger. There is now an (experimental) bridge from
slog to uber zap [1] which would make this transition easier.

But as far as I can tell, you can't use slog to change the logging level with
this bridge to a zap based handler.

You can still change the log level but you have to drop down to zap level which
exposes the fact you are using zap. This also leaves you with two ways to
change the level, only one of which will impact the output.

I don't think was the intent or what a developer might expect.

I have tried to show this with a simple example on the playground.

https://go.dev/play/p/KSaCCzP5Fi3

The problems seems to be the current zap implementation of the
zapslog.HandlerOptions struct [2] is missing a "Level" field (of type
slog.Leveler). This seems to be what is implied by the "How to write a handler"
[3] documentation as the "Options" struct in the example does have a "Level"
filed of type "slog.Leveler". 

So, before I raise an issue on github against zap, could someone clarify what
the original intent was? 

Many thanks

Owen

[1] see: https://github.com/uber-go/zap/blob/exp/v0.2.0/exp/zapslog/handler.go
[NOTE: this is against the exp/v0.2.0 tag which is what my go tool chain
installed).
[2] see:
https://github.com/uber-go/zap/blob/87e467e9b7509962236295e116116980580ef8bc/exp/zapslog/handler.go#L42
[3] https://github.com/golang/example/blob/master/slog-handler-guide/README.md

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/85ef698122c73c9570ef06affd9fe2b6b2bf31b6.camel%40kulawe.com.

Re: [go-nuts] Go course

[Owen Waller]

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 pick out a few things.
I was teaching the very young - 10 & 11 year olds. So I had to simplify
things down quite a bit. So I didn't cover things like:
* functions - arguments vs parameters I thought this was just too to
big a step. Yes they used functions, but they didn't write them,
including functions with no parameters and no return values.
* structs - again its just to big a jump. You can do a lot with just
numbers and strings
* Local vs global variables - again too big a jump and doesn't make
sense without functions.
* Anything you might think of as advanced - so concurrency, testing,
packages and modules, file and network IO, even errors etc I left out.
With an older group I'd put all of those back in except concurrency,
starting with functions, then packages, then IO. 
But that still leaves the key things that all programming languages
have in common namely variables, instruction sequencing, selection and
repetition. In the UK this is what they have to cover at this age
group. This is also the order I introduce these in, and over about 15
hours. So I let them work slowly. At least at this age group typing is
still an issue, so they need time just for that.
Static typing I did not find to be a problem at all. The way I
approached it was simple. Kids already have a good grasp of numbers
(whole and fractions and decimals fractions) and words at this age. So
they know that writing "hello+world" in English makes no sense. The "+"
symbol is only used with numbers. So "1+1" does make sense in a
different context. 
All I had to do was ask the kids did they think they needed a number or
a word for a variable type? If they where reading a variable from the
keyboard that they had to use in a sum, they can work out they need a
number not a word. If all they wanted to do was echo the variable back
- say their name - then they work out it's a word. It takes a few
hours, but within 3-4 hours most of the kids have worked it out. After
that its just a syntax and typing problem.
You'll find that having the types helps the kids reason about the
programs. This is something I personally find very difficult with
python and other typeless languages. It's very hard to reason about an
old bit of code because you don't know what the valid operations or
data range is of a type, which especially if it a named well helps you
reason about the logic. So with kids I would say you want to be as
explicit as possible. Static typing helps with this.
The way I introduced numbers was subtle, but matches what they
typically see in maths at that age. So a number is an int type
initially. Only when we need fractions did I introduce float64, and I
only talked about those two numeric types (so no int8 or float32). And
I talk about numbers not int or float64, unless I have to be specific.
Words are simply strings, that's just a new name they have to learn and
associate with a sequence of characters/letters. They get this really
quickly.
The other approach I took was that I gave them partially completed Go
programs, where the level of completion tails off each session. So I
did this for two reasons. Firstly to cover a bit of boiler plate,
things like the import statements and the main() function header. I do
talk about these and the partial programs also explain these in the
comments but I don't expect the kids to type these lines. Secondly I
want them to focus on whatever was key to that session.
The programs are heavily commented to both explain what is there
already and what and where I want them to fill in the blanks.
And since the programs are incomplete they won't compile and run to
begin with. So they kids have to get he correct syntax from the get go.
That's just the same as in English, you have to have the correct
spelling and grammar, so the kids have a similar concept at that age.
If you do this they'll absorb things like main() and import just
because they will be familiar. So they'll spot it if you leave it out
after a few weeks. Or be able to complete an import statement (if you
tell them the package name) just by coping a previous example.
My last trick was as I kept things to keyboard IO, I had a little
wrapper package that hid the complexity of the text scanner class and
converting form strings to ints etc that the programs used.
So to give you an idea of what I had them doing, they where printing
"Hello " after inputting their name, working out how fast the
ISS goes in orbit and the orbital period and comparing that to
geostationary satellites, doing ROT13 encryption (so A becomes  N) (in
the UK they have to learn about Caesar ciphers at this age), getting
them to print hello world in non-Latin languages (again works well with
a 

[go-nuts] [Help] Seeing an occasional data race on a closed channel

[Owen Waller]

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 high frequency timer (order of tens of
milliseconds) as a data pump to push runes into a channel. That channel
is then read and displayed to the terminal. This code that the example
is derived from is a simulation of data being written to/read from a
i2c data bus. Hence the high data rate.

My understanding is that when a key is pressed that will terminate the
program. This closes the quit channel, which causes the deferred
closeChans() to be called. That in turn closes the done and the bus
channels in that order. Closing the done channel causes the select in
simBus() to complete in the <-done case. This causes the bus channel to
drain. The next call to writeToBus, which is triggered by the timer
going off - should then fail. The cancelled() function should return
true at this point so no attempt should be made to write to the bus
channel.

As I understand the data race below, this logic is flawed. Attempts are
being made to write to the bus channel after it has been closed.

So far I can't work out why, so I'm hoping someone else can.

Many thanks

Owen

Go version 1.8.1 on Linux/AMD64

==
WARNING: DATA RACE
Write at 0x00c420074060 by main goroutine:
  runtime.closechan()
  /home/owen/golang/go/src/runtime/chan.go:320 +0x0
  main.closeChans()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:24 +0x6a
  runtime.call32()
  /home/owen/golang/go/src/runtime/asm_amd64.s:514 +0x47

Previous read at 0x00c420074060 by goroutine 7:
  runtime.chansend()
  /home/owen/golang/go/src/runtime/chan.go:128 +0x0
  main.writeToBus()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:49 +0x88
  main.dataPump()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:39 +0x11f

Goroutine 7 (running) created at:
  main.main()
  /home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellchanp
anic.go:87 +0x16e
==
panic: end of program - only one go routine

goroutine 1 [running]:
main.main()
/home/owen/go/src/github.com/owenwaller/tcellchanpanic/tcellcha
npanic.go:91 +0x21b

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Teaching Elementary/Middle School Kids?

[Owen Waller]

Sorry I forgot to also ask...

j) Can you tell us which country and educational system you are using?

My material is designed for the UK schools system at what is known as
Upper Key Stage 2 (Ages 10-11).
This will strongly influence what you need to cover and when, in terms
of the pupils ages.

So for example. Functions are not taught in the UK until Upper Key
Stage 3 (About Age 13-14) even though as a programmer you might think
they are pretty vital/easy/obvious :). That's why there is no
discussion about functions in my material. This also removes the need
to teach variable scope, parameters and arguments, return values and
Go's := declaration short-cut operator.

Please note that I am not saying that is correct (or it's how I would
do it, or even that I agree with it, or even that the kids can't master
this earlier) but is is what the UK Gov and therefore UK schools expect
the kids to know at these ages.

The UK Gov's guidelines are here:
https://www.gov.uk/government/publications/national-curriculum-in-engla
nd-computing-programmes-of-study
If you have a equivalent link to the educational system if your country
that would help me give you some more tailored 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/BFiHYVN
CwzUJ
> 
> > So, I can tell you that you can do this with 10/11 year olds and
upwards.
> 
> > It would help enormously if you can us some idea of what your
situation is. Things like:
> 
> a) How old are they
> b) How much time you/they have
> c) Is this in class or after school
> d) Are you taking the class or not
> e) what's your background 
> f) How much the pupils know about programming (and computers)
> g) What environment are you in (Windows/MacOS/Linux)
> h) Do you have control over the PC's or does the school/pupil
> i) How hard do will it be to  Go Dev environment
> 
> > > I'm not currently running any after-school clubs at the minute (due
to other commitments) but some of my teaching material publicly
available at:
> http://gophercoders.com
> and there is some code on github at:
> https://github.com/gophercoders
> 
> > > I have a whole stack more than is currently publicly available. I'm
(very) slowly turning that material into lessons that will eventually
appear on gophercoders.com.
> 
> If I can be of any help just ask.
> 
> Owen
> 
> On Tue, 2017-04-11 at 10:31 -0700, Caleb Spare wrote:
> > I don't think it's off-topic. This ML is about pretty much anything
> > Go-related. We've had discussions about teaching Go to kids before.
> > 
> > On Tue, Apr 11, 2017 at 10:26 AM, Bala Natarajan
> > > > <bala.natarajan.p...@gmail.com> wrote:
> > > I did not realize that this was off-topic. My mistake.
> > > 
> > > Thanks David and Konstantin for the suggestions
> > > 
> > > Thanks
> > > 
> > > 
> > > > > > On Tuesday, April 11, 2017 at 6:29:21 AM UTC-7, David Peacock
wrote:
> > > > 
> > > > > > > > This is firmly off-topic for this list, but I too am interested
in this
> > > > > > > > area, having recently formed a chapter of CodeClub in my small
town.
> > > > 
> > > > I'd suggest you start at https://www.codeclubworld.org/
> > > > 
> > > > I'm happy to speak with you off-list.
> > > > 
> > > > Good luck!
> > > > 
> > > > Cheers,
> > > > David
> > > > 
> > > > > > > > On Tue, Apr 11, 2017 at 8:24 AM, Bala Natarajan <bala.nata...@g
mail.com>
> > > > wrote:
> > > > > 
> > > > > Hi
> > > > > 
> > > > > > > > > > I am trying to put together material to teach go to
elementary/middle
> > > > > > > > > > school kids. Does anyone have public material that I could
use as a guide to
> > > > > > > > > > prepare this material? Any suggestions on small projects 
> > > > > > > > > > that
I could give
> > > > > these kids? Thanks for your suggestions.
> > > > > 
> > > > > Thanks
> > > > > bala
> > > > > 
> > > > > --
> > > > > > > > > > You received this message because you are subscribed to the
Google Groups
> > > > > "golang-nuts" group.
> > > > > > > > > > To unsubscribe from this group and stop receivi

Re: [go-nuts] Teaching Elementary/Middle School Kids?

[Owen Waller]

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 can us some idea of what your situation
is. Things like:

a) How old are they
b) How much time you/they have
c) Is this in class or after school
d) Are you taking the class or not
e) what's your background 
f) How much the pupils know about programming (and computers)
g) What environment are you in (Windows/MacOS/Linux)
h) Do you have control over the PC's or does the school/pupil
i) How hard do will it be to  Go Dev environment

I'm not currently running any after-school clubs at the minute (due to
other commitments) but some of my teaching material publicly available
at:
http://gophercoders.com
and there is some code on github at:
https://github.com/gophercoders

I have a whole stack more than is currently publicly available. I'm
(very) slowly turning that material into lessons that will eventually
appear on gophercoders.com.

If I can be of any help just ask.

Owen

On Tue, 2017-04-11 at 10:31 -0700, Caleb Spare wrote:
> I don't think it's off-topic. This ML is about pretty much anything
> Go-related. We've had discussions about teaching Go to kids before.
> 
> On Tue, Apr 11, 2017 at 10:26 AM, Bala Natarajan
> >  wrote:
> > I did not realize that this was off-topic. My mistake.
> > 
> > Thanks David and Konstantin for the suggestions
> > 
> > Thanks
> > 
> > 
> > > > On Tuesday, April 11, 2017 at 6:29:21 AM UTC-7, David Peacock
wrote:
> > > 
> > > > > > This is firmly off-topic for this list, but I too am interested
in this
> > > > > > area, having recently formed a chapter of CodeClub in my small
town.
> > > 
> > > I'd suggest you start at https://www.codeclubworld.org/
> > > 
> > > I'm happy to speak with you off-list.
> > > 
> > > Good luck!
> > > 
> > > Cheers,
> > > David
> > > 
> > > > > > On Tue, Apr 11, 2017 at 8:24 AM, Bala Natarajan 
> > > wrote:
> > > > 
> > > > Hi
> > > > 
> > > > > > > > I am trying to put together material to teach go to
elementary/middle
> > > > > > > > school kids. Does anyone have public material that I could use
as a guide to
> > > > > > > > prepare this material? Any suggestions on small projects that I
could give
> > > > these kids? Thanks for your suggestions.
> > > > 
> > > > Thanks
> > > > bala
> > > > 
> > > > --
> > > > > > > > You received this message because you are subscribed to the
Google Groups
> > > > "golang-nuts" group.
> > > > > > > > To unsubscribe from this group and stop receiving emails from
it, send an
> > > > > > > > email to golang-nuts...@googlegroups.com.
> > > > > > > > For more options, visit https://groups.google.com/d/optout.
> > > 
> > > 
> > --
> > > > You received this message because you are subscribed to the Google
Groups
> > "golang-nuts" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
send an
> > > > email to golang-nuts+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Support for the race detector on ARM

[Owen Waller]

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 new 
memory map, rebuild things and then try it against some sort of hello world 
example.

I do not want to be changing any code beyond this if a can avoid it.

> > 
> > 
and do you want
to take a stab at what the mappings might be for a 32 bit system?


I don't have time to work on this.


I understand that. But at the minute, I don't understand how the
numbers in the memory map are arrived at. Is the process documented
somewhere so I can work this out for myself?

> 
You need clang as it contains the master copy of tsan runtime. Here
are some building instructions:
https://github.com/google/sanitizers/wiki/AddressSanitizerHowToBuild


Thank you for this. It looks like I'll need to set up clang etc first.

Owen
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Support for the race detector on ARM

[Owen Waller]

> > > > 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 load and store operations are
required?
> > > > I am of course assuming that gcc or clang on these platforms can
make use of
> > these instructions.
> 
> Yes, it needs just atomic loads and stores.

Good, so in theory almost any modern processor architecture can be
supported.

> > > 
If all that is needed are atomic loads and stores then that leads to the
second question. Why hasn't a 32-bit port (with a reduced memory map) of the
thread sanitizer already appeared? There are lots of other 32 bit cores with
atomic load sores - MIPS32, PPC, SPARC etc...

At the minute I feel I am missing something _very_ important. Otherwise this
looks like it should be a solved problem.



A 32-bit version would be quite restrictive wrt the amount of memory
an app can use. Tsan can have up to 10x overhead, with Go's GC
overhead this goes to up to 20x.

But I think the real reason is that nobody was interested enough in it
to implement it.

There can also be some hidden problems that I don't see (we never
seriously considered porting tsan to 32-bits).

So next dumb question.

How did you work out the memory mappings for 64-bit systems and do you
want to take a stab at what the mappings might be for a 32 bit system?
I know the memory map will be smaller and it will restrict things but
it might be enough for what I need (and possibly others working on
small embedded hardware).

But this seems to be heading towards a conclusion of. "Somebody just
needs to try it, and see what happens." 
So in that case:

a) What do I need to do to rebuild the lib? So I need clang or will gcc
do?
b) Is the library difficult to rebuild? Is there anything special I
need to know?
c) The memory maps are laid out using "unsigned long long!" types (as
would be expected). I am assuming that in a 32 bit world I can just
leave these alone- rather than convert them to unsigned long, and take
the overhead or both size and performance?
d) Can you think of anything else I might have to change in the code?

Owen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Support for the race detector on ARM

[Owen Waller]

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), 0.5X for another shadow memory, 1TB for heap
and
> > 128GB for thread info. You can see the details in
> > llvm/projects/compiler-rt/lib/tsan/rtl/tsan_platform.h.
> > 
> > 
> > > > Those ranges are well beyond the 32-bit address space. But, having
had a
> > > > quick look at the tsan_platform.h file. It looks like the file
contains
> > > > memory layouts for hardware with 39, 42, 44, 46 and 64 bit address
spaces,
> > at least for C/C++ programs if not Go.
> > 
> > > > Given that these ranges are just defined as constants in the code
is there a
> > > > fundamental reason why these ranges could not be shrunk to fit into
a 32 bit
> > > > address space? Does the tread sanitizer require some (assembly)
instructions
> > that are only found in 64 bit hardware for example?
> 
> No fundamental reason.
> Tsan requires 64-bit atomic loads and stores.

This leads me to ask two things.

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 load and
store operations are required? I am of course assuming that gcc or
clang on these platforms can make use of these instructions.

If all that is needed are atomic loads and stores then that leads to
the second question. Why hasn't a 32-bit port (with a reduced memory
map) of the thread sanitizer already appeared? There are lots of other
32 bit cores with atomic load sores - MIPS32, PPC, SPARC etc...

At the minute I feel I am missing something _very_ important. Otherwise
this looks like it should be a solved problem. 

[1] http://infocenter.arm.com/help/topic/com.arm.doc.dht0008a/DHT0008A_
arm_synchronization_primitives.pdf Section 1.2

Owen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Support for the race detector on ARM

[Owen Waller]

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 continuous chunks of address space for various
> > things.
> > 
> > 
> 
> Tsan reserves 4X for shadow memory (where X is amount of memory where
> user data resides), 0.5X for another shadow memory, 1TB for heap and
> 128GB for thread info. You can see the details in
> llvm/projects/compiler-rt/lib/tsan/rtl/tsan_platform.h.
> 

Those ranges are well beyond the 32-bit address space. But, having had
a quick look at the tsan_platform.h file. It looks like the file
contains memory layouts for hardware with 39, 42, 44, 46 and 64 bit
address spaces, at least for C/C++ programs if not Go.

Given that these ranges are just defined as constants in the code is
there a fundamental reason why these ranges could not be shrunk to fit
into a 32 bit address space? Does the tread sanitizer require some
(assembly) instructions that are only found in 64 bit hardware for
example?

> 
Maybe it's possible to stub the i2c part? That would make testing much
simpler regardless of tsan.


In this specific case, maybe, yes. It's not my i2c drier so just how
much work and how much change would be required I'd need to
investigate.

Owen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Support for the race detector on ARM

[Owen Waller]

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? or any of the other
platforms that Go supports (at least on linux) - SPARC64?

> ThreadSanitizer does not work on any 32-bit platforms. It assumes that
it can reserve huge continuous chunks of address space for various
things.

I have no idea how the ThreadSanitizer works, but can you clarify what
you mean by "huge"?
I'm coming at this from am embedded angle, So huge
to me is a program that swallows 10's of Megs of RAM.

32bit support would potentially also allow support on Android - on current 
hardware.


> ThreadSanitizer is not dependend on underlying hardware memory model,
it check against abstract language memory model. So even if you
production code runs on arm32, you can well test it for races on
x86_64.


Unfortunately I'm in a case where this isn't possible. I'm trying to
make sure that an library I am writing is go routine safe. The library
itself  writes directly to the i2c bus on a Raspberry Pi to control an
IC. The code isn't ARM only (per say) but the hardware element means it
is.

Owen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Support for the race detector on ARM

[Owen Waller]

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 the help. 

After a little digging, the best I can come up with is that there might
be an AARCH64 port. That would cover ARM8 64-bit at least.
The reference I've found is on the thread sanitizer google group is,
here:
https://groups.google.com/forum/#!searchin/thread-sanitizer/Port$20to$2
0ARMv7|sort:relevance/thread-sanitizer/14rRfPAr8vE/dJJ1fzrYAAAJ [1]
Which leads to a discussion on llvm.org which suggests it's done(
maybe...)
https://reviews.llvm.org/D11484

What would be the best way to confirm if the AArch64 support exists, as
that seems to be a prerequisite for at least an ARM8 race detector?

I can't find any existing solution to the 32bit ARMs - v5, v6, v7.
Thread Sanitizer seems to need a whole heap of memory so there is a
very real risk out running out of RAM. But then the typical program
sizes that these cores run are much smaller. If we were talking in
terms of programs that only used 10s to 100's of Megs of RAM - you'd
have a reasonably good chance of x5-10 those amounts being free. So
maybe there would be a case to try and port it to 32 bit platforms, but
I admit that is a much bigger question.

Owen

[1] This post may also be related as it discusses getting the thread
sanitizer running on a AMD AArch64 board with a 42 bit VA space.
https://groups.google.com/forum/#!searchin/thread-sanitizer/mips$20supp
ort%7Csort:relevance/thread-sanitizer/QQ3fOtA7qcM/tycOcC1jq3AJ
[2] There also seems to be PPC64 port too
https://groups.google.com/forum/#!searchin/thread-sanitizer/ppc$20suppo
rt|sort:relevance/thread-sanitizer/D-ku2r5cDtU/BbFcY2Gf8qAJ
If this is also true then it also opens up using the race detector on
the PPC64 go ports.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Support for the race detector on ARM

[Owen Waller]

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 anybody have an idea of when (or even if) support for the race
detector on ARM will arrive? In my case specifically for ARM6/6K. If
not should I open a Github issue to at least track this?

Ideally, I'd like support via cross compiling, but I can certainly live
with it in the short term if I had to rebuild on ARM hardware.

Thanks

Owen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [Gobot v1.2] - I2C PiGlow [SN3218] driver help

[Owen Waller]

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/Xma_6zBtT2

Owen

On Mon, 2017-02-20 at 02:37 -0800, Ron Evans wrote:
> Hi, Owen
> 
> Thanks for doing some work on this, it look cool.
> 
> > > The current set of Gobot i2c drivers all use the sysfs Read() and
Write() interface. The new SMBLOCK based interface is an experimental
interface, and seems like it seems some additional work on Raspi.
> 
> > > I will take a look into it, if you don't mind entering an issue on
our GH tracker it would be appreciated: https://github.com/hybridgrou
p/gobot/issues
> 
> Thanks!
> 
> Regards,
> Ron
> 
> > 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, but I can't get it to drive
the PiGlow at all.
> > 
> > My stab at getting this to work is here:
> > https://play.golang.org/p/_DDEiwZqt1
> > 
> > > > The code is in the style of a "metal bot" as I want to reuse this
code as part of a small project to replace some python code.
> > > > > > The code should turn on LED zero. But when the code runs nothing
happens. There's no terminal output indicating a non-nil error and
there are lights on the PiGlow.
> > 
> > > > > > > > The code is based on the existing PiGlow library, by Toon
Schoenmakers[1] - which does not use GoBots i2c subsystem. That
libraries test code runs fine on the board, so the PiGlow itself is
working ok. My initialisation code is based on Toon's.  
> > 
> > > > Can a friendly Gopher who has more experience of GoBot and a
similar hardware set-up, spot what I might be doing wrong?
> > 
> > Thanks
> > 
> > Owen
> > 
> > [1]https://github.com/schoentoon/piglow
> > 
> > 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [Gobot v1.2] - I2C PiGlow [SN3218] driver help

[Owen Waller]

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, but I can't get it to drive the
PiGlow at all.

My stab at getting this to work is here:
https://play.golang.org/p/_DDEiwZqt1

The code is in the style of a "metal bot" as I want to reuse this code
as part of a small project to replace some python code.
The code should turn on LED zero. But when the code runs nothing
happens. There's no terminal output indicating a non-nil error and
there are lights on the PiGlow.

The code is based on the existing PiGlow library, by Toon
Schoenmakers[1] - which does not use GoBots i2c subsystem. That
libraries test code runs fine on the board, so the PiGlow itself is
working ok. My initialisation code is based on Toon's.  

Can a friendly Gopher who has more experience of GoBot and a similar
hardware set-up, spot what I might be doing wrong?

Thanks

Owen

[1]https://github.com/schoentoon/piglow

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.