I think that's the question. Here's a simpler example,
https://play.golang.org/p/9Kv3PhlM-OF
That is, is 00 an expected %02x representation of a zero-length byte
slice?
The answer to that is yes; the 02 forces leading zeros. The %x verb
essentially renders bit strings as hex, so a zero-length
It's expected behavior.
Your for loop runs once for l=0, since your condition is <=0 because
len([]byte{}) is 0.
-- Marcin
On Fri, Dec 18, 2020 at 3:28 PM Jochen Voss wrote:
> Hello,
>
> I can print slices of bytes as hex strings, using code like the following:
>
> x := []byte{0, 1, 2, 3}
>
Hello,
I can print slices of bytes as hex strings, using code like the following:
x := []byte{0, 1, 2, 3}
fmt.Printf("%02x", x[:l])
This gives the output "00010203" as expected. But this fails for the empty
slice: running
x := []byte{}
fmt.Printf("%02x", x[:l])
gives "00" instead of
On Sat, 19 Dec 2020, 5:45 am Ian Lance Taylor, wrote:
> On Fri, Dec 18, 2020 at 4:50 AM Amit Saha wrote:
> >
> > On Fri, 18 Dec 2020, 11:44 pm Volker Dobler,
> wrote:
> >>
> >> Use
> >>
> >> import _ "embed" // note the _
> >>
> >> Your code does not use package embed. A comment does
>
Hi,
I have GOFLAGS=-mod=readonly in my environment to avoid unnoticed changes
to go.mod and go.sum. However, I'm getting a weird error from the new in
1.16 "go install p@version" form to install a Go program:
$ go version
go version devel +2de7866470 Fri Dec 18 18:25:14 2020 + darwin/amd64
On Wed, Dec 16, 2020 at 8:49 AM Sean wrote:
> i have a project I have to work with CGo. I want to disable some
> controls as they are not good enough right now.
> It works when I write "set godebug=cgocheck=0" on Windows in console.
> However, this is a GUI program. Console should not open.
>
>
On Fri, Dec 18, 2020 at 4:50 AM Amit Saha wrote:
>
> On Fri, 18 Dec 2020, 11:44 pm Volker Dobler,
> wrote:
>>
>> Use
>>
>> import _ "embed" // note the _
>>
>> Your code does not use package embed. A comment does
>> not qualify as usage. As yous must import it for //go:embed
>> comments
On Fri, 18 Dec 2020, at 4:18 PM, Sean wrote:
> My previous reply was sent to Ian. Sorry.
> The point I don't understand is "os.Args".
> I think the parameter here is the name of my program. So like "program.exe".
>
Args is a variable in the os package. Go ensures that the the first element
My previous reply was sent to Ian. Sorry.
The point I don't understand is "os.Args".
I think the parameter here is the name of my program. So like "program.exe".
Can support be added to Golang so that these variables can be accessed
from in-program sources such as "os.Environ"?
Unfortunately
On Fri, 18 Dec 2020, 11:44 pm Volker Dobler,
wrote:
> Use
>
> import _ "embed" // note the _
>
> Your code does not use package embed. A comment does
> not qualify as usage. As yous must import it for //go:embed
> comments to work you have to use a "side-effects-only"-import.
>
Ah yes.
Use
import _ "embed" // note the _
Your code does not use package embed. A comment does
not qualify as usage. As yous must import it for //go:embed
comments to work you have to use a "side-effects-only"-import.
V.
On Friday, 18 December 2020 at 13:38:10 UTC+1 amits...@gmail.com wrote:
>
Hi all,
The release notes has this:
Module-aware mode is enabled by default, regardless of whether a go.mod file is
present in the current working directory or a parent directory. More precisely,
the GO111MODULE environment variable now defaults to on. To switch to the
previous behavior, set
Hi all, has anyone tried using the “embed” package in the 1.16 beta 1 release?
My data.go file looks as:
package main
import "embed"
//go:embed templates/main.go.tmpl
var tmplMainGo []byte
When I build the program, I get this:
~/go/bin/go1.16beta1 build
Just to followup here: in the company I work for we discarded usage of
Alpine and settled on Debian because:
* Alpine has no process for handling CVEs
* Alpine's musl libc has subtle differences to glibc which led to strange
problems (we use Java a lot)
* When building images for Python or Ruby
14 matches
Mail list logo
