Are you referring to go.dev/learn? If so, I think this is a great idea.
Could you create an issue (https://github.com/golang/go/issues) with
potential books to include?
Cheers,
Todd
On Tuesday, July 20, 2021 at 8:44:24 PM UTC-7 Ian Lance Taylor wrote:
> On Mon, Jul 12, 2021 at 8:12 AM
Maybe the object itself has circular references - so it fails at the first
level.
> On Jul 21, 2021, at 11:25 AM, Brian Candler wrote:
>
> I had a brief look at the code and it doesn't appear to do that. As far as
> I can see, it indents as it goes: where you start is the "top" level, and
Hi Folks,
Apologies if this is clearly stated somewhere, but various searches didn't
turn anything up.
We're trying to make a rudimentary first cut at risk assessment for using
Go 1.16+ on RISC-V. I see that 1.14 lists it as experimental but I don't
see any subsequent "ready for prime time"
I had a brief look at the code and it doesn't appear to do that. As far as
I can see, it indents as it goes: where you start is the "top" level, and
it increases the indentation for each level of children.
The individual dump functions write directly to the writer, not to a buffer
(except
> If anyone would kindly help me find what I'm doing wrong, or at least
point me to useful resources
> explaining how to fix my problem, I would be reaally delighted.
Maybe a look at *typex* [1,2] helps.
[1] https://github.com/dtgorski/typex
[2]
Hi all,
As far as I understand, gollvm uses a Go specific frontend that emits
Go specific IR, then a bridge that converts that to LLVM IR, and a driver
to drive the backend?
My question is:
1. How often do you need to update the bridge to support the changing
Go specific IR? Which
If it is pretty printing it may need to determine the lowest level for
indentation - so a depth first search - causing the entire tree to be traversed
and retained before it can output anything.
> On Jul 21, 2021, at 9:40 AM, Brian Candler wrote:
>
> But AFAICT, it should generate output as
Not at all... I think this is a nice reproducible case that you should
raise as an issue in the Litter repo.
On Wednesday, 21 July 2021 at 16:31:17 UTC+1 mlevi...@gmail.com wrote:
> Thx all for the response!
>
> Giving myself a (tremendous) facepalm, it was _indeed_ the use of litter
> that
Thx all for the response!
Giving myself a (tremendous) facepalm, it was _indeed_ the use of litter
that destroyed my machine memory. Everything's working fine now.
Sorry for the unnecessary noise guys. *retreating in shame*
Have a great day!
Le mer. 21 juil. 2021 à 16:40, Brian Candler a écrit
But AFAICT, it should generate output as it runs. The fact that it doesn't
generate any output at all is suspicious.
On Wednesday, 21 July 2021 at 13:50:37 UTC+1 ren...@ix.netcom.com wrote:
> Since litter checks for circular references it needs to keep a ref to
> every object it sees.
>
>
Since litter checks for circular references it needs to keep a ref to every
object it sees.
With a large tree you will run out of memory.
> On Jul 21, 2021, at 7:19 AM, jake...@gmail.com wrote:
>
>
> The first thing I would do is remove the call to litter, and see if that
> solved the
The first thing I would do is remove the call to litter, and see if that
solved the issue. That would tell you immediately if the problem was the
litter package or the packages package. I have so specific knowledge, but
it is not impossible to imagine that you are simply trying to print
The problem appears to be with litter, not with x/tools/go/packages
On my machine, this hangs after "Stage B":
https://play.golang.com/p/N2MTQszvnRN
On Wednesday, 21 July 2021 at 11:41:39 UTC+1 mlevi...@gmail.com wrote:
> Hi all,
>
> I'm having a very hard time with
Hi all,
I'm having a very hard time with golang.org/x/tools/go/packages. Spent most
of my evening yesterday trying to understand what's happening here.
Here's my code: https://play.golang.com/p/5L1N0lSaetB
With this very simple code I would expect that the program prints detailed
information
On Wednesday, 21 July 2021 at 10:05:10 UTC+2 Brian Candler wrote:
> Channels are almost always better than low-level primitives like condition
> variables, which have various pitfalls.
Almost always. :) Sure, there are alternatives, but sync.Cond makes sense
once you use it properly. And it
Channels are almost always better than low-level primitives like condition
variables, which have various pitfalls.
This video by Bryan C Mills explains some of the issues, and shows
channel-based alternatives:
https://www.youtube.com/watch?v=5zXAHh5tJqQ
On Wednesday, 21 July 2021 at 07:04:27
Hi,
1. Where are the transactions? I see only "up" and "down", and each can
fail - even the "down" after a failed "up".
2. You spawn goroutines, and collect errors using append - that's racy. Run
the tests with "-race" and see for yourself!
Tamás
dtmi...@gmail.com a következőt írta (2021.
I think this is a perfect scenario for sync.Cond
https://pkg.go.dev/sync#Cond.
On Tuesday, 20 July 2021 at 21:21:27 UTC+2 prawira.d...@gmail.com wrote:
> I personally like to use range channel to "break out" process in
> goroutine, for example :
>
> package main
> import (
> "fmt"
>
18 matches
Mail list logo
