Re: [go-nuts] Advice, please

You may be better off maintaining two state *arrays*: one that has the current values as input and one for writing the computed outputs. At "negtive" clock edge you swap the arrays. Since the input array is never modified during the half clock cycle when you compute, you can divide it up in N

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

I think it is simpler to create a SyncPoint with Wait and Release methods - it is easily implemented with a WaitGroup and a Semaphore. > On Jan 16, 2021, at 9:31 PM, Pete Wilson wrote: > > By ‘at the same time’ I would understand that none of them are able to see > the counter in the wait

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

By ‘at the same time’ I would understand that none of them are able to see the counter in the wait group after one member had triggered release. That is, I believed that “release by any go routine (that is, a Wait() done by any collaborating goroutine which saw a zero counter) " happened before

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

It does release them all at once. They all become ready to run at the “same time” - the scheduler has to get them to run. Even if the release was atomic it would make no difference in the race condition. > On Jan 16, 2021, at 7:35 PM, Pete Wilson wrote: > > Makes sense. > Thanks very much.

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

Makes sense. Thanks very much. Simpler than a double waitgroup, same overall effect. I may have a weird use case, but maybe this might be worth adding to the examples. — P > On Jan 16, 2021, at 6:14 PM, Robert Engels wrote: > > WaitGroups are deterministic in that sense. Whether they are all

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

Brian Thanks for advice. I’ll take a look — P > On Jan 16, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote: > > Brian Candler mailto:b.cand...@pobox.com>>: Jan 16 > 01:02PM -0800 > > On Saturday, 16 January 2021 at 16:28:59 UTC Pete Wilson wrote: > > > In short, what I want to do is

[go-nuts] Godoc as gh-pages

Dear gophers, Anybody have experience in creating gh-pages and hosting godoc generated static pages on it? I have created godoc locally and downloaded the html files. But still could not host on gh-pages (reference I found here -

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

WaitGroups are deterministic in that sense. Whether they are all released at once (there is no such thing as “at once” in practice) you have a race. You can restructure this to avoid the race. You should Add() to to the stage 1 and 2 wait groups after the Wait() returns and before you Wait()

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

Jake Thanks for thoughts My approach made the assumption that Wait() worked as advertised - all the goroutines are released when the Wait() hits zero. What you’re pointing out is that Wait() is in some sense racy itself. I had assumed that no goroutine in a waitgroup was ‘released' until they

[go-nuts] Re: Waitgroup problem

On Saturday, 16 January 2021 at 16:28:59 UTC Pete Wilson wrote: > In short, what I want to do is to have a controller goroutine (main) plus > some number of worker goroutines > This doesn't answer your question, but if you haven't seen it already I recommend this video about concurrency

Re: [go-nuts] possible inconsistency in the embed package documentation

In general, embedding files from directories starting with dot ("hidden directories") works fine. But you must take care, to either mention the hidden directory explicitly, or the file you want to exclude, as otherwise, the hidden directory will be skipped by embed (see

Re: [go-nuts] possible inconsistency in the embed package documentation

It gets pretty subtle. The ".git" directories aren't included in module zips by the go command (I don't know if this is documented anywhere, but it's very sensible behavior), but they aren't disallowed. A custom module zip may include a ".foo", "_foo", or even ".git" directory with files. In

Re: [go-nuts] possible inconsistency in the embed package documentation

https://golang.org/ref/mod#zip-path-size-constraints prevents directories that begin with a dot, but only because the directory is interpreted as a package. It is not clear, to me, if `.git` is ignored by the `embed` directive because it is the private directory of the VCS or because it starts

Re: [go-nuts] possible inconsistency in the embed package documentation

Directories named testdata are included in the module; they're needed for tests to run. The most important thing that's left out are subdirectories that contain a go.mod file, since the content of such directories is a different module. Some good places to look for full details include

Re: [go-nuts] possible inconsistency in the embed package documentation

I think this is the best doc about what is included in a module: https://golang.org/ref/mod#zip-path-size-constraints Everything not in that list is "outside" that module. On Sat, Jan 16, 2021 at 9:02 PM Manlio Perillo wrote: > Thanks. I was only considering the parent of the module's root

Re: [go-nuts] possible inconsistency in the embed package documentation

As an example: is testdata outside the package's module? Thanks Manlio Il giorno sabato 16 gennaio 2021 alle 21:02:25 UTC+1 Manlio Perillo ha scritto: > Thanks. I was only considering the parent of the module's root directory. > Is the concept of "outside the module" defined somewhere? > >

Re: [go-nuts] possible inconsistency in the embed package documentation

Thanks. I was only considering the parent of the module's root directory. Is the concept of "outside the module" defined somewhere? Manlio Perillo Il giorno sabato 16 gennaio 2021 alle 19:30:05 UTC+1 axel.wa...@googlemail.com ha scritto: > To put it another way: > > The second phrase is a

Re: [go-nuts] possible inconsistency in the embed package documentation

To put it another way: The second phrase is a lexical requirement about the pattern. It must not contain a . or .. element - whether or not the result is included in the module (e.g. "foo/../foo/bar" is not allowed either, even though it's equivalent to "foo/bar"). But, a lexical path *in* the

[go-nuts] Re: possible inconsistency in the embed package documentation

I think both are needed, they don't overlap. Note that the second phrase says "must not contain '.' or '..' path *elements*", emphasis them being a complete path element. So "./git" is disallowed by the second phrase, but ".git" is not. On Saturday, January 16, 2021 at 1:10:47 PM UTC-5

Re: [go-nuts] possible inconsistency in the embed package documentation

I don't think they do. There are two examples in the first phrase, which are not excluded by the second - the ".git" directory and a symbolic link (pointing outside of the module). On Sat, Jan 16, 2021 at 7:11 PM Manlio Perillo wrote: > I'm reading the https://tip.golang.org/pkg/embed/ package

[go-nuts] possible inconsistency in the embed package documentation

I'm reading the https://tip.golang.org/pkg/embed/ package documentation and I found a possible inconsistency. At the end of https://tip.golang.org/pkg/embed/#hdr-Directives: "Patterns must not match files outside the package's module, such as ‘.git/*’ or symbolic links" and "Patterns must not

[go-nuts] Re: Waitgroup problem

There may be other problems as well, but the WaitGroup.Add documentation says: " If a WaitGroup is reused to wait for several independent sets of events, new Add calls must happen after all previous Wait calls have *returned*." You have a race

[go-nuts] Waitgroup problem

Gentlepersons I asked for advice on how to handle a problem a few days ago, and have constructed a testbed of what I need to do, using WaitGroups in what seems to be a standard manner. But the code fails and I don’t understand why. The (simple version of) the code is at

[go-nuts] GODOC: how to create a reference to another definition in a comment?

Hello, Just wondering if there is a way to create references to other fields in go comments. If it does not exist, wouldn't it be something valuable, for easier navigation in godoc and its new iteration? (I would assume that we would have to check comments for broken references on code change)

Re: [go-nuts] `go list` across multiple modules?

Is the slowness here related to https://github.com/golang/go/issues/29427 ? I'm not sure the earlier fix for that actually fixed the issues I was having (and the issue remains open) -- I need to do more research for my situation, but just in case this might be another reason to revisit the