On Wednesday, 15 November 2023 at 21:25:37 UTC Def Ceb wrote:
I downloaded and ran `go env` with both the 32-bit and 64-bit Go
toolchains from go.dev, and the GOGCCFLAGS results were:
Since you're on a newer Raspberry Pi with a 64-bit ARM environment, you
should download the 64-bit Go toolchai
I downloaded and ran `go env` with both the 32-bit and 64-bit Go
toolchains from go.dev, and the GOGCCFLAGS results were:
64-bit: GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections
-fmessage-length=0
-ffile-prefix-map=/tmp/go-build2828356582=/tmp/go-build
-gno-record-gcc-switches'
32-bit: GOGC
On Wed, Nov 15, 2023 at 9:59 PM Stephen Illingworth
wrote:
>
> That works better although not perfectly for my purposes. More work required
> from me.
>
> I'm curious though, about the -marm flag. How can I remove it from the
> GOGCCFLAGS variable? Or are we saying we can't use the aarch64 compi
That works better although not perfectly for my purposes. More work
required from me.
I'm curious though, about the -marm flag. How can I remove it from the
GOGCCFLAGS variable? Or are we saying we can't use the aarch64 compiler in
conjunction with cgo?
Thanks for the help
On Wednesday, 15 No
> On Nov 15, 2023, at 7:08 AM, 'Brian Candler' via golang-nuts
> wrote:
>
> On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote:
> 1. A value variable and multiple value receivers <--- compiles
> 2. A pointer variable and multiple value receivers <--- compiles
> 3. A pointer varia
On Wed, Nov 15, 2023 at 8:30 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
> I'm trying to build a project on the Raspberry Pi, natively.
>
> Using "go env" I can see that Go has the following value for GOGCCFLAGS
>
> GOGCCFLAGS='-fPIC -marm -Wl,--no-gc-sections -fmessage-length=0
Hello,
I'm trying to build a project on the Raspberry Pi, natively.
Using "go env" I can see that Go has the following value for GOGCCFLAGS
GOGCCFLAGS='-fPIC -marm -Wl,--no-gc-sections -fmessage-length=0
-ffile-prefix-map=/tmp/go-build745518569=/tmp/go-build
-gno-record-gcc-switches'
However,
* Robert Engels [231115 12:29]:
> What I’m suggesting is that imagine a dev changes that code and has
> version() access the request property…
Okay, that makes sense.
> This is why if you are sharing data in a concurrent way you need to be
> very careful of all usages.
Absolutely.
> The safes
edit: The `App` interface has just one implementation which adds the ~4
builtin "Runnables". It is used to implement 5-10 different services each
of which adds its custom "Runnables".
On Wednesday, November 15, 2023 at 7:06:08 AM UTC-5 grant wrote:
> I've stumbled upon a set of interfaces that
On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote:
1. A value variable and multiple value receivers <--- compiles
2. A pointer variable and multiple value receivers <--- compiles
3. A pointer variable and multiple pointer receivers. <--- compiles
4. A value variable and multiple
What I’m suggesting is that imagine a dev changes that code and has version()
access the request property…
This is why if you are sharing data in a concurrent way you need to be very
careful of all usages.
The safest solution is to use immutable objects - of which the non pointer are.
So say
* Robert Engels [231114 21:55]:
>Switching to pointer receivers everywhere actually makes this worse. Any
>access is potentially a data race.
>It stills seems like this is a compiler issue. There needs to be a way to
>synchronize the pointer to value copy in conjunction with other
* burak serdar [231114 19:09]:
> I do not agree that this is because how the compiler works. A value
> receiver is equivalent to pass-by-value argument, that is:
>
> rcp.version()
>
> is equivalent to:
>
> RPC.version(rpc)
>
> thus, creating the copy of the rpc variable. So, the compiler may
>
I've stumbled upon a set of interfaces that doesn't feel quite right, but I
can't say why exactly.
```
type (
Named interface {
Name() string
}
App interface {
Named
Run() error
Shutdown()
}
// Runnable typically represents a MQTT or HTTP listener
Runnable interface {
Named
Run(ctx context.Contex
14 matches
Mail list logo
