profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ulikunitz/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Ulrich Kunitz ulikunitz Germany Go developer interested in compression; DevOps manager for identity & authentication

ulikunitz/xz 342

Pure golang package for reading and writing xz-compressed files

ulikunitz/unixtime 8

Go Package providing Unix time conversions

ulikunitz/damm 3

Golang package for computing a decimal check digit

ulikunitz/xio 1

Go package providing a wrapper for a Writer supporting WriteString and WriteByte.

ulikunitz/fiboheap 0

Go implementation of Fibonacci Heaps

created repositoryulikunitz/docker-debian-systemd

created time in 18 days

create barnchulikunitz/cli

branch : main

created branch time in a month

created repositoryulikunitz/cli

A simple package to support command line interfaces.

created time in a month

created repositoryulikunitz/gcpdemo

created time in a month

issue commentgolang/go

proposal: cmd/go: add a workspace mode

I agree with @rsc that such a mechanism is needed. To me the concept of a super-module appears to be misguided. I still want the go.mod file of the module for the package that is compiled define the actual module set. I could accept that only the replace statements in the go.work file are applied and the replace statements in the go.mod files being ignored.

This approach means we don't have a super module but a module set, but it avoids complex merging semantics of go.mod files that goes beyond the logic that is already implemnted. It means however that gopls would need to have one virtual instances of itself per module.

matloob

comment created time in 2 months

issue commentgolang/go

proposal: cmd/go: add a workspace mode

@matloob Many thanks for your answers. It clarifies the semantics sufficiently for me.

As @ChrisHines remarked a GOPATH-like approach would address the speed concerns. So the go tool and gopls would look for example for <workspace>/github.com/peterbourgon/ff/v3/. I was quite surprised when I came to the same conclusion independently.

The explicit approach could still be supported though by the simple form of the replace clause in the go.work file. Adding an ignore clause that prevents the GOPATH-mode for a directory and all subdirectories. would allow a purely explicit approach.

go 1.18

ignore .

replace (
     github.com/peterbourgoun/ff/v3 ff/v3 => ./ff/v3
     github.com/klauspost/compress/zstd => ./zstd
)

The directory clause is not required.

An empty go.work file would only use GOPATH mode.

matloob

comment created time in 2 months

issue commentgolang/go

proposal: cmd/go: add a workspace mode

@nohir: A file is better than an environment variable. You want to be able to switch workspaces. Sure an environment variable could be a list of workspaces. But I cannot see how you could support ignore and replace clauses with environment variables in a sane manner. Multiple workspaces mean multiple contexts and a set of environment variables is per definition a single context.

matloob

comment created time in 2 months

issue commentgolang/go

proposal: cmd/go: add a workspace mode

I have still some questions regarding the contents and handling of the go.work file.

  • Must all locations of go.mod files be listed explicitly?
  • Must v2, v3, ... modules be listed explicitly?
  • Will gopls or the go tool update the file? What are the semantics for the updates?

How about the assumption that subdirectories of the workspace directory contain source code repositories and all modules included are part of the workspace? The go.work file could still contain ignore and replace clauses, but the need would be very limited.

In the ideal case an empty go.work file would be sufficient and creating a workspace would be as simple as

$ touch go.work

The go.work file will not be part of a source code repository and I would like to keep it simple. And it cannot become simpler than an empty file.

matloob

comment created time in 2 months

issue commentgolang/go

proposal: slices: new package to provide generic slice functions

EqualFunc appears to me unfortunately named because the eq function could be any boolean operator.

f := slices.EqualFunc[int](a, b, func(x,y int) bool { return x < y })

would make sense and be useful code, but doesn't compute equality. BoolOp may be a better name.

ianlancetaylor

comment created time in 3 months

issue commentgolang/go

cmd/compile: slower bit operations (regression in go 1.16.3)

Agree with both points, I have been wrong regarding the AND.

rayjcwu

comment created time in 3 months

issue commentulikunitz/xz

[SECURITY] Implementation of readUvarint vulnerable to CVE-2020-16845

I got the following information:

GitHub has issued CVE-2021-29482 for this Security Advisory after reviewing it for compliance with CVE rules. Since you've already published this Security Advisory, we'll publish this CVE to the CVE List.

0xdecaf

comment created time in 3 months

issue commentulikunitz/xz

[SECURITY] Implementation of readUvarint vulnerable to CVE-2020-16845

You are right. Because the xz module is not the golang stdlib the advisory should have its own CVE. I have now requested a CVE through the Github Security Advisory interface. I was not aware of that option.

0xdecaf

comment created time in 3 months

issue commentgolang/go

cmd/compile: slower bit operations (regression in go 1.16.3)

https://www.agner.org/optimize/optimizing_assembly.pdf states that BTS with a memory operand should be avoided on Intel. So moving the result into a register and writing it might be faster.

rayjcwu

comment created time in 3 months

issue commentgolang/go

cmd/compile: slower bit operations (regression in go 1.16.3)

One observation: the ANDQ is not required, it is done by BTSQ itself.

Another: BTSQ is probably multiple micro-ops including a write of the CF flag. The upper sequence is probably translated 1-to-1 into micro-ops and will have a smaller micro-op count.

rayjcwu

comment created time in 3 months