[go-nuts] proxy.golang.org has inconsistent versions with git repo for golang.zx2c4.com/wireguard

[Ben Strauss]

Hi,

I'm trying to build a Go module that has a transitive dependency on 
golang.zx2c4.com/wireguard [1].  My organization requires me to use 
GOPROXY=direct.  I get the following error when running any go command:

go: github.com/influxdata/telegraf@v0.0.0-0001010100- 
requires
golang.zx2c4.com/wireguard/wgctrl@v0.0.0-20200205215550-e35592f146e4 
requires
golang.zx2c4.com/wireguard@v0.0.20200121: reading 
golang.zx2c4.com/wireguard/go.mod at revision v0.0.20200121: unknown 
revision v0.0.20200121

However, if I switch to GOPROXY=https://proxy.golang.org,direct, then 
everything works fine.

I tracked it down to the fact that the git repo for 
golang.zx2c4.com/wireguard has tags without leading v's: 
https://git.zx2c4.com/wireguard-go/refs/tags

But proxy.golang.org somehow has versions with leading v's:
$ curl 'https://proxy.golang.org/golang.zx2c4.com/wireguard/@v/list'
v0.0.20200320
v0.0.20181001
v0.0.20180531
v0.0.20200121
v0.0.20180613
v0.0.20201118
v0.0.20180519
v0.0.20180524
v0.0.20191012
v0.0.20190409
v0.0.20180514
v0.0.20190517
v0.0.20190805
v0.0.20181222
v0.0.20190908
v0.0.20181018

Is proxy.golang.org doing something weird here?  How did it end up with 
those versions?  I reached out to the owner of golang.zx2c4.com/wireguard 
and it doesn't sound like he has changed his git tags.

I can work around this by adding the following replace directive to my main 
package's go.mod:

replace golang.zx2c4.com/wireguard v0.0.20200121 => 
golang.zx2c4.com/wireguard v0.0.0-20200121152719-05b03c675090

Or I can ask the maintainers of golang.zx2c4.com/wireguard/wgctrl to do 
it.  But neither of us should need to do that.

A further piece of information is that a member of my team who joined 6 
months ago didn't have this problem, but when he cleaned his module cache, 
he reproduced it.  So something with the module mirror or go command must 
have changed between then and now.

Thanks for your help!

-Ben

[1]
https://github.com/aws/amazon-cloudwatch-agent/blob/master/go.mod#L5 ->
https://github.com/aws/telegraf/blob/4470de2d306b340739eb3f25fa20d63d9c115bb3/go.mod#L135
 
->
https://github.com/WireGuard/wgctrl-go/blob/e35592f146e40ce8057113d14aafcc3da231fbac/go.mod#L12

-- 
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/1cb5e769-f473-4fe7-be90-831ee104fac3n%40googlegroups.com.

Re: [go-nuts] string matching

['wagner riffel' via golang-nuts]

On Thu Apr 1, 2021 at 4:45 PM -03, Sharan Guhan wrote:
> r := regexp.MustCompile(`Core Count: [0-9]+`)
> match := r.FindAllStringSubmatch(cmd_output, -1)

As of the "efficiently" part, you should compile the regexp once
instead of each call to ParseFillCpuInfo, a common practice is to use
a package-level scoped variable but even better (for efficiency) would
be keep it with strings.Index approach, as such:

count := -1
const substr = "Core Count: "
if i := strings.Index(input, substr); i >= 0 {
countStart := i + len(substr)

const digits = "0123456789"
j := 0
for strings.ContainsRune(digits, rune(input[countStart+j])) {
j++
}
count, err := strconv.Atoi(input[countStart : countStart+j])
// handle err
}

You can benchmark both approaches using testing.B, have fun.

https://golang.org/pkg/testing/#B

-- 
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/CACXYA0GSJR6.UVYEID10NHU0%40pampas.

Re: [go-nuts] Re: [golang-dev] Go 1.16.3 and Go 1.15.11 are released

['Michael Pratt' via golang-nuts]

mgcsweepbuf.go was deleted in 1.16, so it seems you still have files from
1.15 sitting around in /usr/local/go/.

On Fri, Apr 2, 2021 at 4:13 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Apr 1, 2021 at 11:52 PM Dmitri Shuralyov 
> wrote:
>
> > We have just released Go versions 1.16.3 and 1.15.11, minor point
> releases.
>
> Cleared everything ($ go clean -cache -modcache -testcache ; rm -rf ~/pkg
> ~/.cache/go-build) and upgraded from 1.15.10 to 1.16.3. Now I am seeing
> while hacking some current project:
>
> jnml@3900x:~/src/modernc.org/qbe$ go test
> # runtime
> /usr/local/go/src/runtime/mgcsweepbuf.go:87:80: memstats.gc_sys undefined
> (type mstats has no field or method gc_sys)
> /usr/local/go/src/runtime/mgcsweepbuf.go:106:102: memstats.gc_sys
> undefined (type mstats has no field or method gc_sys)
> FAIL modernc.org/qbe [build failed]
> jnml@3900x:~/src/modernc.org/qbe$ go version
> go version go1.16.3 linux/amd64
> jnml@3900x:~/src/modernc.org/qbe$ go env
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/jnml/.cache/go-build"
> GOENV="/home/jnml/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GOMODCACHE="/home/jnml/pkg/mod"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/home/jnml"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct;
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GOVCS=""
> GOVERSION="go1.16.3"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/home/jnml/src/modernc.org/qbe/go.mod"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build1728759906=/tmp/go-build
> -gno-record-gcc-switches"
> jnml@3900x:~/src/modernc.org/qbe$
>
> Any ideas what's wrong? Thanks in advance.
>
> --
> 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/CAA40n-XUw%3D_SBa-dTVNFVuKKWdDreBjScwMxpHk4DGR7MyK-YQ%40mail.gmail.com
> 
> .
>

-- 
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/CALoThU86odpTdo8oFatbpyc%3Dc-o%3Di6%3DHToxrDuTF03zEeafm_A%40mail.gmail.com.

Re: [go-nuts] Re: [golang-dev] Go 1.16.3 and Go 1.15.11 are released

[Jan Mercl]

On Fri, Apr 2, 2021 at 4:40 PM Michael Pratt  wrote:

> mgcsweepbuf.go was deleted in 1.16, so it seems you still have files from 
> 1.15 sitting around in /usr/local/go/.

I would swear I've deleted those files, but doing all the steps once
again from scratch proves you are right and I can no more reproduce
the failure.

Thank you.

-- 
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/CAA40n-V0deQrJmb68_KZVDFTUm71AEERfrQk17f_Bzr%2BWPT3Dg%40mail.gmail.com.

Re: [go-nuts] Cover report in multiple packages

[Kn]

 Add option `-coverpkg=$(go list ./...|sed 's/ /,/g')` works.

On Tuesday, May 24, 2016 at 9:31:52 PM UTC+8 Dave MacFarlane wrote:

> If all you're trying to do is get coverage of all your subpackages for a 
> CI and aren't concerned about downstream packages or manually toggling 
> which ones are one/off at runtime, I've used this script:
>
> https://github.com/codecov/example-go/blob/master/go.test.sh
>
> with Travis, and it seems to work fine.
>
>
> On Mon, May 23, 2016 at 2:15 AM,  wrote:
>
>> > My unit tests run against the code in package A which depends on 
>>> package 
>>> > B which depends on package C. When running with "-cover" I only get a 
>>> > report of the coverage in package A. Is there a way to get the 
>>> coverage 
>>> > report for all the packages in the project based on the tests that are 
>>> run? 
>>>
>>> From go test -help: 
>>> -coverpkg pkg1,pkg2,pkg3 
>>> Apply coverage analysis in each test to the given list of 
>>> packages. The default is for each test to analyze only the package being 
>>> tested. Packages are specified as import paths. 
>>>
>>> E.g. in the directory for package A, run "go test -coverpkg A,B,C". 
>>>
>>>
>> Is it possible to do the same at run-time?
>> When running tests recursively from a root directory, it is kind of weird 
>> to make such coverpkg list... It would be much cleaner to write this list 
>> in the test file instead or to offer better `-coverpkg` values...
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> - Dave
>

-- 
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/50bd7944-e59a-4cb3-8de7-2b4ca6f90990n%40googlegroups.com.

[go-nuts] Re: Alternate implementations of regular expression matching?

[Amnon]

*Some people, when confronted with a problem, think "I know, I'll use 
regular expressions." Now they have two problems.*

I would tend to agree with this statement. Regular expressions are much 
abused and over-used in situations where 
simpler parsing techniques would be more appropriate. Beyond a certain 
length regular expressions are hard to read,
and easy to get wrong.

But when you do need to use a regular expression, then it the 
implementation in the standard library is usually a good choice.
Its most important feature is O(n) runtime - runtime proportional to the 
input length, irrespective of the complexity of 
the regular expression. This prevents denial of service attacks based on 
sending regular expression which cause 
catastrophic backtracking and exponential runtime. The standard library 
omits some of the bells and whistles 
provided by PCRE and other libraries - but often for the good reason that 
these require backtracking, so are impossible
to implement while guaranteeing reasonable runtimes. 

So I would certainly consider using the standard library version, and 
rewriting your regular expressions to remove the use
of features not supported in the standard library.
On Friday, 2 April 2021 at 01:43:00 UTC+1 dlc...@gmail.com wrote:

> You can try my regexp2 engine that's based on the .NET engine: 
> https://github.com/dlclark/regexp2
>
> It supports atomic groups, has no dependencies, and doesn't need cgo. 
> Unfortunately it doesn't support Possessive Quantifier syntax, but 
> supposedly that may be serving as syntactic sugar for atomic groups and 
> look-ahead assertions (which it does support).
>
> Thanks,
> Doug
>
> On Thursday, April 1, 2021 at 2:54:35 PM UTC-5 bobj...@gmail.com wrote:
>
>> I have a use of regular expressions where I need the "atomic" matching 
>> features that I can get for several other languages, such as atomic 
>> matching groups and "possessive" quantifiers. I'm willing to forego the 
>> blazing performance of Go's standard library dfa matcher for this 
>> particular case. I cannot write an equivalent regexp for Go's "regexp", and 
>> the additional code I would have to write for equivalent functionality is 
>> prohibitive.
>>
>> I did find such an implementation in the ether, importable as "
>> github.com/h2so5/goback/regexp", It kind of works, but fails for my use 
>> case.
>>
>> Is there any reason to believe that downloaded modules such as this are 
>> well-tested and reliable?
>>
>> To pursue this problem,, I wrote small programs that perform the same 
>> operation in isolation in some other languages that have regular expression 
>> implementations the have the features I want, in particular
>>Java, whose java.util.regex module provides the desired features
>>Python, which has a module "regex" downloadable from the PyPI (Python 
>> program index) that replaces the standard "re" module but has my desired 
>> features
>>Also Go, using the downloaded module I mentioned
>>
>> Only the Go version fails. Of course, it's the fault of the downloaded 
>> library, not Go itself :)
>>
>> Anyone know of any other Go nfa implementations with the aforementioned 
>> features?
>>
>> As much as I appreciate the advantages Go's dfa "regexp" module, there 
>> are times when a more full-featured nfa implementation is useful. (And, a 
>> well-written regexp for nfa can be pretty fast if the aforementioned 
>> features are used to prevent excessive backtracking.)
>>
>> If anyone is interested in looking into the failure I experienced, I'd be 
>> happy to send the little programs I wrote to investigate this.
>>
>>
>>

-- 
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/d08ed242-fdef-4954-ab66-c1a7c479b9a6n%40googlegroups.com.

[go-nuts] Re: [golang-dev] Go 1.16.3 and Go 1.15.11 are released

[Jan Mercl]

On Thu, Apr 1, 2021 at 11:52 PM Dmitri Shuralyov 
wrote:

> We have just released Go versions 1.16.3 and 1.15.11, minor point
releases.

Cleared everything ($ go clean -cache -modcache -testcache ; rm -rf ~/pkg
~/.cache/go-build) and upgraded from 1.15.10 to 1.16.3. Now I am seeing
while hacking some current project:

jnml@3900x:~/src/modernc.org/qbe$ go test
# runtime
/usr/local/go/src/runtime/mgcsweepbuf.go:87:80: memstats.gc_sys undefined
(type mstats has no field or method gc_sys)
/usr/local/go/src/runtime/mgcsweepbuf.go:106:102: memstats.gc_sys undefined
(type mstats has no field or method gc_sys)
FAIL modernc.org/qbe [build failed]
jnml@3900x:~/src/modernc.org/qbe$ go version
go version go1.16.3 linux/amd64
jnml@3900x:~/src/modernc.org/qbe$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jnml/.cache/go-build"
GOENV="/home/jnml/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jnml/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jnml"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct;
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jnml/src/modernc.org/qbe/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build1728759906=/tmp/go-build
-gno-record-gcc-switches"
jnml@3900x:~/src/modernc.org/qbe$

Any ideas what's wrong? Thanks in advance.

-- 
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/CAA40n-XUw%3D_SBa-dTVNFVuKKWdDreBjScwMxpHk4DGR7MyK-YQ%40mail.gmail.com.