The comment in the file explains that it' was used to generate test cases,
used:
https://go.googlesource.com/go/+/e3b793004fe9fb169099026e8c8d732913ec2ffa/src/lib/hash/sha1_test.go#20
A variant of the test still exists,
https://go.googlesource.com/go/+/refs/heads/master/src/crypto/sha1/sha1_test.g
>
> galileo:/home/galileo# free
>
> totalusedfree shared buff/cache
> available
>
> Mem: 209592 20612 34620 76 154360
> 180376
>
> Swap: 1048572 0 1048572
>
> galileo:/home/galileo# ./hugo
>
> panic: runtime e
There is src/hash/test_gen.awk in Go's source code repo. It was added
back in 2008. It's not called anywhere, at least directly, go binary
can be built successfully after removing it and 'git log --all -S
test_gen' finds only the commit that added it. Also, I'm not sure what
'cmd = "echo -n `9 sha1
Can you add a swapfile? That could rule out low RAM as the problem, even
if it's very inefficient.
Aside: 127MB does sound like a very large binary, compared to what the
standard go toolchain produces. The official hugo amd64 binary is about
44MB:
$ tar -tvzf hugo_0.82.0_Linux-64bit.tar.gz
Thanks for the reply!
After recompiling gcc-go and libgo with the " -Wa,-momit-lock-prefix=yes
-march=i586" flags and compiling hugo with:
go build -gccgoflags="-Wa,-momit-lock-prefix=yes -march=i586"
Still getting an error, but a more terse version:
./hugo
panic: runtime error: invalid memory
Hello all,
I use the XML package from the standard library (encoding/xml) and I wonder
why the line attribute of the decoder is not exposed such as
func (d *Decoder) InputLine() int {
return d.line
}
The offset for example is exposed:
func (d *Decoder) InputOffset() int64 {
return d.of
Since I haven't generated the various ztypes_nsx_GOARCH.go files, I think I
need to use +build nsx and not ignore the build for types_nsx.go.
I found a way to run bootstrap.bat on windows but I was told that I had to
run make.bat instead, so I did. I had to add "nsx" to the array 'okgoos' in
c
thanks to both of you for your response!
I was indeed able to solve the problem, by going back to one of Jasper's
suggestions.
the bucket needed to be a single value, not a path.
the item then contained the full sub-path even with the "=".
hopefully this saves someone else.
thanks again!
On Frid
Hi,
Quoth nonnikcm:
> i am struggling with using the s3manager to create files on S3. the file names
> need to be in the following format "set=2012-04-3", containing an "=".
> uploading with out the "=" works perfectly...
It would probably be worth submitting a bug to the AWS SDK for Go
issue tr
