Re: [go-nuts] Makefiles for Go Programs

[Reto]

On Mon, Aug 23, 2021 at 06:12:43PM -0700, Michael Ellis wrote:
> Three cheers for mage .  It's more verbose than make 
> but it's pure Go. I use it to build and test projects that include 
> generated html/css/js supported by a Web Assembly clients communicating 
> with a server.

It may be nicer, however the beauty of make is that it is ubiquitous,
everybody already has it.

With mage, your installation instructions now need to contain how /
where to get mage in the first place, leaving the user with a random
binary somewhere which they probably never ever need nor update again.

-- 
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/20210824055435.eg46zvnazct7m7dh%40feather.

Re: [go-nuts] Makefiles for Go Programs

[Michael Ellis]

Three cheers for mage .  It's more verbose than make 
but it's pure Go. I use it to build and test projects that include 
generated html/css/js supported by a Web Assembly clients communicating 
with a server.

On Monday, August 23, 2021 at 7:33:10 PM UTC-4 Connor Kuehl wrote:

>
>
> > On Aug 22, 2021, at 10:11 PM, jlfo...@berkeley.edu  
> wrote:
> > 
> > 
> > I've noticed that few, if any, Go programs use Makefiles. Is that 
> because the overhead of using make is greater than the overhead of just 
> always compiling and linking everything?
> > One piece of evidence for this is that the Go compiler leaves no 
> artifacts, like object files, so as is make wouldn't fit into the current 
> build method.
> > 
>
> I started using a Makefile for my Go project so that I could inject a 
> version string at build time without having to remember what to pass to go 
> binaries.
>
> I made a Discord bot to use in a server with my friends, and since I have 
> some automation in place to automatically deploy the tip of my main branch, 
> I thought it’d be convenient to be able to ask the bot what build it’s 
> running so we can see which commits are “live."
>
> So while it’s not a “traditional” use of make, it certainly is convenient.
>
> Connor
>
> P.S., here’s the Makefile. The important bits are the lines that mention 
> “LD_FLAGS"
>
> VERSION := v2.2.0+dev
> BUILD := $(shell git describe --tags 2>/dev/null || echo "$(VERSION)")
>
> LD_FLAGS := "-X 'main.Version=$(BUILD)'"
>
> SOURCES := $(shell find . -type f -name '*.go')
> SOURCES += go.mod go.sum
>
> .PHONY: build clean test
>
> all: popple
>
> popple: build
>
> build: $(SOURCES)
> @go build -v -ldflags=$(LD_FLAGS) ./...
>
> test: popple
> @go test -v -ldflags=$(LD_FLAGS) ./...
>
> clean:
> @rm -rf popple

-- 
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/6b2116b0-b6e1-4d60-bd88-ee71f011035en%40googlegroups.com.

Re: [go-nuts] Makefiles for Go Programs

[Connor Kuehl]

> On Aug 22, 2021, at 10:11 PM, jlfo...@berkeley.edu  
> wrote:
> 
> 
> I've noticed that few, if any, Go programs use Makefiles. Is that because the 
> overhead of using make is greater than the overhead of just always compiling 
> and linking everything?
> One piece of evidence for this is that the Go compiler leaves no artifacts, 
> like object files, so as is make wouldn't fit into the current build method.
> 

I started using a Makefile for my Go project so that I could inject a version 
string at build time without having to remember what to pass to go binaries.

I made a Discord bot to use in a server with my friends, and since I have some 
automation in place to automatically deploy the tip of my main branch, I 
thought it’d be convenient to be able to ask the bot what build it’s running so 
we can see which commits are “live."

So while it’s not a “traditional” use of make, it certainly is convenient.

Connor

P.S., here’s the Makefile. The important bits are the lines that mention 
“LD_FLAGS"

VERSION := v2.2.0+dev
BUILD := $(shell git describe --tags 2>/dev/null || echo "$(VERSION)")

LD_FLAGS := "-X 'main.Version=$(BUILD)'"

SOURCES := $(shell find . -type f -name '*.go')
SOURCES += go.mod go.sum

.PHONY: build clean test

all: popple

popple: build

build: $(SOURCES)
@go build -v -ldflags=$(LD_FLAGS) ./...

test: popple
@go test -v -ldflags=$(LD_FLAGS) ./...

clean:
@rm -rf popple

-- 
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/06427CFB-1F08-43F3-8971-A095E8D47C30%40gmail.com.

[go-nuts] Re: A question about Type Sets

[Scott Cotton]

Great to see you playing with generics.

I'll leave it up to the experts to reply about whether the compilation 
problems are bugs.

But I have a suggestion:  don't try to define Vec in an interface with a 
type set.  Just use T[] -- looks like it might simplify things.

Scott
On Tuesday, August 24, 2021 at 12:55:55 AM UTC+2 Changkun Ou wrote:

> Hi golang-nuts,
>
> I am trying out the latest type parameter and type sets design.
> The purpose is to implement a Clamp function that works for numbers and 
> vectors.
>
> The version for numbers is straightforward and easy:
>
> ```go
> // Number is a type set of numbers.
> type Number interface {
> ~int | ~int8 | ~int32 | ~int64 | ~float32 | ~float64
> }
>
> // Clamp clamps a given value in [min, max].
> func Clamp[N Number](n, min, max N) N {
> if n < min { return min }
> if n > max { return max }
> return n
> }
> ```
>
> Everything is good so far. Then, let's define vector types:
>
> ```go
> // Vec2 represents a 2D vector (x, y).
> type Vec2[N Number] struct {
> X, Y N
> }
>
> // Vec3 represents a 3D vector (x, y, z).
> type Vec3[N Number] struct {
> X, Y, Z N
> }
>
> // Vec4 represents homogeneous coordinates (x, y, z, w) that defines
> // either a point (W=1) or a vector (W=0). Other case of W need to apply
> // a perspective division to get the actual coordinates of X, Y, Z.
> type Vec4[N Number] struct {
> X, Y, Z, W N
> }
> ```
>
> However, in order to declare a type set of all possible vectors, I tried
> two possibilities:
>
> ```go
> // Vec is a type set of vectors.
> type Vec[N Number] interface {
> Vec2[N] | Vec3[N] | Vec4[N] // ERROR: interface cannot have type 
> parameters
> }
> ```
>
> ```go
> type Vec interface {
> Vec2[N Number] | Vec3[N Number] | Vec4[N Number] // ERROR: interface 
> cannot have type parameters
> }
> ```
>
> Let's just enumerates all possibilities for the Vec type set:
>
> ```go
> // Vec is a type set of vectors.
> type Vec interface {
> Vec2[float32] | Vec3[float32] | Vec4[float32] |
> Vec2[float64] | Vec3[float64] | Vec4[float64]
> }
> ```
>
> However, with this definition, it remains very tricky to construct a
> generic implementation for a clamp function:
>
> ```go
> // ERROR: this function does not compile
> func ClampVec[V Vec, N Number](v V, min, max N) V {
> switch (interface{})(v).(type) {
> case Vec2[float32]:
> return Vec2[float32]{
> Clamp[float32](v.X, min, max),
> Clamp[float32](v.Y, min, max),
> }
> case Vec2[float64]:
> return Vec2[float64]{
> Clamp[float64](v.X, min, max),
> Clamp[float64](v.Y, min, max),
> }
> case Vec3[float32]:
> return Vec3[float32]{
> Clamp[float32](v.X, min, max),
> Clamp[float32](v.Y, min, max),
> Clamp[float32](v.Z, min, max),
> }
> case Vec3[float64]:
> return Vec3[float64]{
> Clamp[float64](v.X, min, max),
> Clamp[float64](v.Y, min, max),
> Clamp[float64](v.Z, min, max),
> }
> case Vec4[float32]:
> return Vec4[float32]{
> Clamp[float32](v.X, min, max),
> Clamp[float32](v.Y, min, max),
> Clamp[float32](v.Z, min, max),
> Clamp[float32](v.W, min, max),
> }
> case Vec4[float64]:
> return Clamp[float64]{
> Clamp[float64](v.X, min, max),
> Clamp[float64](v.Y, min, max),
> Clamp[float64](v.Z, min, max),
> Clamp[float64](v.W, min, max),
> }
> default:
> panic(fmt.Sprintf("unexpected type %T", v))
> }
> }
> ```
>
> I wish I could converge to a version similar like this:
>
> ```go
> func Clamp[N Number](n, min, max N) N {
> if n < min { return min }
> if n > max { return max }
> return n
> }
>
> // ERROR: this functions does not compile
> func ClampVec[N Number, V Vec[N]](v V[N], min, max N) V[N] {
> switch (interface{})(v).(type) {
> case Vec2[N]: // If V is Vec2[N], then return a Vec2[N].
> return Vec2[N]{
> Clamp[N](v.X, min, max),
> Clamp[N](v.Y, min, max),
> }
> case Vec3[N]: // Similar
> return Vec3[N]{
> Clamp[N](v.X, min, max),
> Clamp[N](v.Y, min, max),
> Clamp[N](v.Z, min, max),
> }
> case Vec4[N]: // Similar
> return Vec4[N]{
> Clamp[N](v.X, min, max),
> Clamp[N](v.Y, min, max),
> Clamp[N](v.Z, min, max),
> Clamp[N](v.W, min, max),
> }
> default:
> panic(fmt.Sprintf("unexpected type %T", v))
> }
> }
>
> // caller side:
>
> Clamp[float32](256, 0, 255) // 255
> Clamp[float64, Vec2[float64]]({1, 2, 3}, 0, 1) // Vec2[float32]{1, 1, 1}
> ...
> ```
>
> I found myself trapped and not able to further proceed. Is the above code 
> legal
> with the current design but just because the compiler has not implemented 
> it yet?
> Any ideas on how could the current design be able to produce something 
> even simpler?
>
> Thank you in advance for your read and help.
>

-- 
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/d4aa1117-f6f1-4260-b6c2-72211ac771c0n%40googlegroups.com.

Re: [go-nuts] Re: Problem with 0MQ and goLang on Windows

[Amit Saha]

On Tue, Aug 24, 2021 at 8:55 AM Dominique Kande Vita
 wrote:
>
> Hi All,
>
> this is a kind of old problem. I am dropping here my solution, just in case 
> someone will search for as crazy all over the net.
> 1. add in your PATH (environement variable) the bin folder where vcpkg has 
> compiled the dll
> 2. install libsodium via vcpkg
> 3. copy the dll : libczmq.dll, libsodium.dll, libzmq-mt-4_3_4.dll in the 
> folder where your golang .exe application is compiled.
>
> and it should work

Thanks.


>
> On Tuesday, December 29, 2015 at 6:09:58 AM UTC+2 chow...@gmail.com wrote:
>>
>> Hi Rene，
>>How did you solve it? I also met the problem "exit status -107374181".
>> Thanks.
>>
>> 在 2014年11月30日星期日 UTC+8下午5:03:55，rene marxis写道：
>>>
>>> Hello Jason
>>>
>>> thanks for your answer.
>>> Of course i tried
>>>   worker, err := zmq.NewSocket(zmq.REQ)
>>> but with no success and no error message...
>>>
>>> The problem seems to be related to the libzmq somehow.
>>>
>>> I tried "go run main.go" from inside a VS-Console and got an error "The 
>>> program could not be started, because libzmq-v120-mt-gd-4_0_4.dll is 
>>> missing".
>>> The application exitied with: "exit status -1073741515"
>>>
>>> After also adding the bin directory from libzmq to the PATH and restarting 
>>> the app, the message did not show up againe and the app exists with:
>>> "exit status -107374181"
>>>
>>> What i don't understand is, why the application is trying to load the 
>>> libzmq-v120-mt-gd-4_0_4.dll. As i wrote in my first question, i had to 
>>> copy/rename that dll in order to be able to do the 'go get 
>>> github.com/pebbe/zmq4'
>>>
>>> Independently from this behavior, for me it seems to be wrong to have to 
>>> rename that dll at all.
>>> Isn't there any possibility to tell 'go get' to use that 
>>> libzmq-v120-mt-gd-4_0_4.dll instead of libzmq.dll ?
>>> I got that "tip" to rename from
>>> https://gist.github.com/michfield/4686876
>>> ...
>>>
>>>
>>>
> --
> 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/373686ad-80ce-4b8b-a500-c5ba6f5fd6f0n%40googlegroups.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/CANODV3nKYvdLjrLOc3DsLXzQBLRqdE3YtZY%3DWVMySrL6iZr1LQ%40mail.gmail.com.

[go-nuts] A question about Type Sets

[Changkun Ou]

Hi golang-nuts,

I am trying out the latest type parameter and type sets design.
The purpose is to implement a Clamp function that works for numbers and
vectors.

The version for numbers is straightforward and easy:

```go
// Number is a type set of numbers.
type Number interface {
~int | ~int8 | ~int32 | ~int64 | ~float32 | ~float64
}

// Clamp clamps a given value in [min, max].
func Clamp[N Number](n, min, max N) N {
if n < min { return min }
if n > max { return max }
return n
}
```

Everything is good so far. Then, let's define vector types:

```go
// Vec2 represents a 2D vector (x, y).
type Vec2[N Number] struct {
X, Y N
}

// Vec3 represents a 3D vector (x, y, z).
type Vec3[N Number] struct {
X, Y, Z N
}

// Vec4 represents homogeneous coordinates (x, y, z, w) that defines
// either a point (W=1) or a vector (W=0). Other case of W need to apply
// a perspective division to get the actual coordinates of X, Y, Z.
type Vec4[N Number] struct {
X, Y, Z, W N
}
```

However, in order to declare a type set of all possible vectors, I tried
two possibilities:

```go
// Vec is a type set of vectors.
type Vec[N Number] interface {
Vec2[N] | Vec3[N] | Vec4[N] // ERROR: interface cannot have type parameters
}
```

```go
type Vec interface {
Vec2[N Number] | Vec3[N Number] | Vec4[N Number] // ERROR: interface cannot
have type parameters
}
```

Let's just enumerates all possibilities for the Vec type set:

```go
// Vec is a type set of vectors.
type Vec interface {
Vec2[float32] | Vec3[float32] | Vec4[float32] |
Vec2[float64] | Vec3[float64] | Vec4[float64]
}
```

However, with this definition, it remains very tricky to construct a
generic implementation for a clamp function:

```go
// ERROR: this function does not compile
func ClampVec[V Vec, N Number](v V, min, max N) V {
switch (interface{})(v).(type) {
case Vec2[float32]:
return Vec2[float32]{
Clamp[float32](v.X, min, max),
Clamp[float32](v.Y, min, max),
}
case Vec2[float64]:
return Vec2[float64]{
Clamp[float64](v.X, min, max),
Clamp[float64](v.Y, min, max),
}
case Vec3[float32]:
return Vec3[float32]{
Clamp[float32](v.X, min, max),
Clamp[float32](v.Y, min, max),
Clamp[float32](v.Z, min, max),
}
case Vec3[float64]:
return Vec3[float64]{
Clamp[float64](v.X, min, max),
Clamp[float64](v.Y, min, max),
Clamp[float64](v.Z, min, max),
}
case Vec4[float32]:
return Vec4[float32]{
Clamp[float32](v.X, min, max),
Clamp[float32](v.Y, min, max),
Clamp[float32](v.Z, min, max),
Clamp[float32](v.W, min, max),
}
case Vec4[float64]:
return Clamp[float64]{
Clamp[float64](v.X, min, max),
Clamp[float64](v.Y, min, max),
Clamp[float64](v.Z, min, max),
Clamp[float64](v.W, min, max),
}
default:
panic(fmt.Sprintf("unexpected type %T", v))
}
}
```

I wish I could converge to a version similar like this:

```go
func Clamp[N Number](n, min, max N) N {
if n < min { return min }
if n > max { return max }
return n
}

// ERROR: this functions does not compile
func ClampVec[N Number, V Vec[N]](v V[N], min, max N) V[N] {
switch (interface{})(v).(type) {
case Vec2[N]: // If V is Vec2[N], then return a Vec2[N].
return Vec2[N]{
Clamp[N](v.X, min, max),
Clamp[N](v.Y, min, max),
}
case Vec3[N]: // Similar
return Vec3[N]{
Clamp[N](v.X, min, max),
Clamp[N](v.Y, min, max),
Clamp[N](v.Z, min, max),
}
case Vec4[N]: // Similar
return Vec4[N]{
Clamp[N](v.X, min, max),
Clamp[N](v.Y, min, max),
Clamp[N](v.Z, min, max),
Clamp[N](v.W, min, max),
}
default:
panic(fmt.Sprintf("unexpected type %T", v))
}
}

// caller side:

Clamp[float32](256, 0, 255) // 255
Clamp[float64, Vec2[float64]]({1, 2, 3}, 0, 1) // Vec2[float32]{1, 1, 1}
...
```

I found myself trapped and not able to further proceed. Is the above code
legal
with the current design but just because the compiler has not implemented
it yet?
Any ideas on how could the current design be able to produce something even
simpler?

Thank you in advance for your read and help.

-- 
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/CAP%2BmWpJO3xE4Wwg22cXAeY-JKFxk%3D3uneOTEKwLrWjcqLt_Y9A%40mail.gmail.com.

Re: [go-nuts] Makefiles for Go Programs

[Iago Rubio]

> On 23 Aug 2021, at 05:11, jlfo...@berkeley.edu  wrote:
> 
> 
> I've noticed that few, if any, Go programs use Makefiles. Is that because the 
> overhead of using make is greater than the  of just always compiling and 
> linking everything?
Most likely, it’s because go comes with it’s own build system built-in.

Just using “go build whatever.go” will do the job.

Even the cross-compilation is built -in.

-- 
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/4063D63C-2BD9-408A-B85C-F70E3BE51A92%40gmail.com.

[go-nuts] Re: Problem with 0MQ and goLang on Windows

[Dominique Kande Vita]

Hi All, 

this is a kind of old problem. I am dropping here my solution, just in case 
someone will search for as crazy all over the net. 
1. add in your PATH (environement variable) the bin folder where vcpkg has 
compiled the dll
2. install libsodium via vcpkg
3. copy the dll : libczmq.dll, libsodium.dll, libzmq-mt-4_3_4.dll in the 
folder where your golang .exe application is compiled.

and it should work

On Tuesday, December 29, 2015 at 6:09:58 AM UTC+2 chow...@gmail.com wrote:

> Hi Rene，
>How did you solve it? I also met the problem "exit status -107374181".
> Thanks.
>
> 在 2014年11月30日星期日 UTC+8下午5:03:55，rene marxis写道：
>
>> Hello Jason
>>
>> thanks for your answer.
>> Of course i tried 
>>   worker, err := zmq.NewSocket(zmq.REQ)
>> but with no success and no error message...
>>
>> The problem seems to be related to the libzmq somehow.
>>
>> I tried "go run main.go" from inside a VS-Console and got an error "The 
>> program could not be started, because libzmq-v120-mt-gd-4_0_4.dll is 
>> missing". 
>> The application exitied with: "exit status -1073741515"
>>
>> After also adding the bin directory from libzmq to the PATH and 
>> restarting the app, the message did not show up againe and the app exists 
>> with:
>> "exit status -107374181"
>>
>> What i don't understand is, why the application is trying to load the 
>> libzmq-v120-mt-gd-4_0_4.dll. 
>> As i wrote in my first question, i had to copy/rename that dll in order to 
>> be able to do the 'go get github.com/pebbe/zmq4 
>> 
>> '
>>
>> Independently from this behavior, for me it seems to be wrong to have to 
>> rename that dll at all. 
>> Isn't there any possibility to tell 'go get' to use that 
>> libzmq-v120-mt-gd-4_0_4.dll 
>> instead of libzmq.dll ?
>> I got that "tip" to rename from
>> https://gist.github.com/michfield/4686876
>> ... 
>>
>>
>>
>>

-- 
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/373686ad-80ce-4b8b-a500-c5ba6f5fd6f0n%40googlegroups.com.

[go-nuts] A Question About Type Set and Parameter Design

[changkun]

Hi golang-nuts,

I am trying out the latest type parameter, and type sets design.
The purpose is to implement a Clamp function that works for numbers and vectors.

The version for numbers is straightforward and easy:

```go
// Number is a type set of numbers.
type Number interface {
~int | ~int8 | ~int32 | ~int64 | ~float32 | ~float64
}

// Clamp clamps a given value in [min, max].
func Clamp[N Number](n, min, max N) N {
if n < min { return min }
if n > max { return max }
return n
}
```

Everything is good so far. Then, let's define vector types:

```go
// Vec2 represents a 2D vector (x, y).
type Vec2[N Number] struct {
X, Y N
}

// Vec3 represents a 3D vector (x, y, z).
type Vec3[N Number] struct {
X, Y, Z N
}

// Vec4 represents homogeneous coordinates (x, y, z, w) that defines
// either a point (W=1) or a vector (W=0). Other cases of W need to apply
// a perspective division to get the actual coordinates of X, Y, Z.
type Vec4[N Number] struct {
X, Y, Z, W N
}
```

However, to declare a type set of all possible vectors, I tried
two possibilities:

```go
// Vec is a type set of vectors.
type Vec[N Number] interface {
Vec2[N] | Vec3[N] | Vec4[N] // ERROR: interface cannot have type parameters
}
```

```go
type Vec interface {
Vec2[N Number] | Vec3[N Number] | Vec4[N Number] // ERROR: interface cannot 
have type parameters
}
```

Let's enumerates all possibilities for the Vec type set:

```go
// Vec is a type set of vectors.
type Vec interface {
Vec2[float32] | Vec3[float32] | Vec4[float32] |
Vec2[float64] | Vec3[float64] | Vec4[float64]
}
```

However, with this definition, it remains very tricky to construct a
generic implementation for a clamp function:

```go
// ERROR: this function does not compile
func ClampVec[V Vec, N Number](v V, min, max N) V {
switch (interface{})(v).(type) {
case Vec2[float32]:
return Vec2[float32]{
Clamp[float32](v.X, min, max),
Clamp[float32](v.Y, min, max),
}
case Vec2[float64]:
return Vec2[float64]{
Clamp[float64](v.X, min, max),
Clamp[float64](v.Y, min, max),
}
case Vec3[float32]:
return Vec3[float32]{
Clamp[float32](v.X, min, max),
Clamp[float32](v.Y, min, max),
Clamp[float32](v.Z, min, max),
}
case Vec3[float64]:
return Vec3[float64]{
Clamp[float64](v.X, min, max),
Clamp[float64](v.Y, min, max),
Clamp[float64](v.Z, min, max),
}
case Vec4[float32]:
return Vec4[float32]{
Clamp[float32](v.X, min, max),
Clamp[float32](v.Y, min, max),
Clamp[float32](v.Z, min, max),
Clamp[float32](v.W, min, max),
}
case Vec4[float64]:
return Clamp[float64]{
Clamp[float64](v.X, min, max),
Clamp[float64](v.Y, min, max),
Clamp[float64](v.Z, min, max),
Clamp[float64](v.W, min, max),
}
default:
panic(fmt.Sprintf("unexpected type %T", v))
}
}
```

I wish I could converge to a version similar like this:

```go
func Clamp[N Number](n, min, max N) N {
if n < min { return min }
if n > max { return max }
return n
}

// ERROR: this functions does not compile
func ClampVec[N Number, V Vec[N]](v V[N], min, max N) V[N] {
switch (interface{})(v).(type) {
case Vec2[N]: // If V is Vec2[N], then return a Vec2[N].
return Vec2[N]{
Clamp[N](v.X, min, max),
Clamp[N](v.Y, min, max),
}
case Vec3[N]: // Similar
return Vec3[N]{
Clamp[N](v.X, min, max),
Clamp[N](v.Y, min, max),
Clamp[N](v.Z, min, max),
}
case Vec4[N]: // Similar
return Vec4[N]{
Clamp[N](v.X, min, max),
Clamp[N](v.Y, min, max),
Clamp[N](v.Z, min, max),
Clamp[N](v.W, min, max),
}
default:
panic(fmt.Sprintf("unexpected type %T", v))
}
}

// caller side:

Clamp[float32](256, 0, 255) // 255
Clamp[float64, Vec2[float64]]({1, 2, 3}, 0, 1)  // Vec2[float32]{1, 1, 1}
...
```

I found myself trapped and not able to proceed further. 

- Is the above code legal with the current design but 
because the compiler has not implemented it yet?
- Any ideas on how could the current design be able to produce something even 
simpler?
- If it is impossible to archive a similar implementation, what could be the 
best practices to implement a generic clamp function?

Thank you in advance for your read and help.

-- 
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/073b7b40-7505-49ae-963d-83441b9d766dn%40googlegroups

Re: [go-nuts] Re: Makefiles for Go Programs

[Amnon]

I think the basic idea is that Go projects do not have makefiles because 
they do not need makefiles.
Ideally the Go command does the right thing, including fetching and 
building dependencies, and building 
entire trees of projects. Go is opinionated, and dictates where each 
package can be found on the filesystem.
Having a fixed convention means that configuration is not necessary. And 
the Go command usually does this 
better than hacked together make-files. The dependency analysis and object 
caching just work, so we don't 
spend our lives running `make clean; make distclean; make cleanall; make 
archconfig; make` 
each time our build fails to pick up the latest changes.

In the real world we do need to build docker images, and non-Go artifacts, 
so we do often have to fall back on some
sort of Makefile. But it is refreshing not to having each time to re-invent 
how to build a project spanning multiple directories.

On Monday, 23 August 2021 at 18:58:21 UTC+1 frave...@gmail.com wrote:

> On Aug 23, 2021, at 12:48, Roland Müller  wrote:
>
>
> What are the alternatives to Makefile that are used by Go developers? 
> Please comment :-)
>
>
> Well, there’s mage, which aims to more or less replace the functionality 
> of Make for Go. I’m not really sold on *needing* a replacement for Make, 
> and if you’re doing CI builds, it still adds an external dependency, but it 
> is an interesting project: https://magefile.org/
>
> I know Make from old C/C++ times. Therefore, my picture is that it is not 
> very portable and requires for quite many operations the usage of external 
> tools that again differ between the platforms. Basically Makefiles are 
> somehow enhanced shell scripts (Linux/Unix) or batch files (Windows).
>
>
> Makefiles are quite portable, at least assuming you’re using GNU Make 
> (which is at least available nearly everywhere). It may not be the most 
> ideal option with Windows, but nearly everywhere else it’s pretty solid.
>
> If you have problems with external tools behaving differently across 
> platforms (the behavior of “which” on Solaris vs. Linux or BSD being a 
> particular sticking point I’ve run across in scripts), I would argue that 
> there’s not much out there that’s going to solve that problem.
>
> Currently, at work I deal a lot with Maven, that is a bit too Java 
> -oriented in spite of being capable in principle to build and compile other 
> things too. Another, issue is the XML syntax that's makes editing without 
> tool support very hard.
>
>
> Most of the newer build tools like Maven, Gradle and Bazel seem to be more 
> oriented towards either IDEs or large-scale projects. Make scales quite 
> nicely to small, and moderately well to large. Recursive builds tend to be 
> a problem, but fortunately with Go, you don’t tend to need those.
>
> I would say Go tooling goes along rather well with Make if you’re 
> following the semi-canonical repo structure, because you can tell Go to 
> just build a list of executables from the ./cmd directory and the build 
> tool takes care of caching, figuring out dependencies, etc. Not much in the 
> way of portability issues there.
>
> Gradle would be another candidate. I am just began to explore it. It's a 
> bit like Maven with human syntax, but lacks again on lifecycle support that 
> I like with Maven.
>
>
> I feel like Gradle is another very Java-oriented tool, and as a 
> consequence seems to have inherited the very Byzantine nature of nearly 
> every other Java ecosystem tool. I haven’t tried to use it for non-Java 
> stuff, but I wouldn’t, personally. Not least because in a CI environment, I 
> tend to try to stick to things either native to the language I’m using (so, 
> the native Go build tools, *maybe* mage), or things present or easily 
> installed in the host Docker image (both Bourne shell and Make fit this 
> bill nicely).
>
> The other benefit here is that in the projects I work on for work, not 
> everyone wants to use Make (some folks have a pathological aversion to it), 
> but it’s easy for us to make sure that Make is only ever a convenience 
> method for things that can otherwise be easily done from the command-line 
> (e.g. “go test ./…”). Make then becomes a) a convenience for running basic 
> things (e.g. make test, make cover, make docker-test-race, that sort of 
> thing) and b) a method for making sure our developers are running the same 
> commands locally that the CI process does (don’t underestimate the 
> importance of that for avoiding difficult-to-diagnose problems).
>
> It’s also nothing you can’t do with plain shell scripts, but you’ll find 
> yourself reinventing a lot of things that Make does for you quite nicely 
> out of the box, like default parameters, list handling, target 
> dependencies, etc.
>
>
> - 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

Re: [go-nuts] Re: Makefiles for Go Programs

[David Riley]

On Aug 23, 2021, at 12:48, Roland Müller  wrote:
> 
> What are the alternatives to Makefile that are used by Go developers? Please 
> comment :-)

Well, there’s mage, which aims to more or less replace the functionality of 
Make for Go. I’m not really sold on *needing* a replacement for Make, and if 
you’re doing CI builds, it still adds an external dependency, but it is an 
interesting project: https://magefile.org/

> I know Make from old C/C++ times. Therefore, my picture is that it is not 
> very portable and requires for quite many operations the usage of external 
> tools that again differ between the platforms. Basically Makefiles are 
> somehow enhanced shell scripts (Linux/Unix) or batch files (Windows).

Makefiles are quite portable, at least assuming you’re using GNU Make (which is 
at least available nearly everywhere). It may not be the most ideal option with 
Windows, but nearly everywhere else it’s pretty solid.

If you have problems with external tools behaving differently across platforms 
(the behavior of “which” on Solaris vs. Linux or BSD being a particular 
sticking point I’ve run across in scripts), I would argue that there’s not much 
out there that’s going to solve that problem.

> Currently, at work I deal a lot with Maven, that is a bit too Java -oriented 
> in spite of being capable in principle to build and compile other things too. 
> Another, issue is the XML syntax that's makes editing without tool support 
> very hard.

Most of the newer build tools like Maven, Gradle and Bazel seem to be more 
oriented towards either IDEs or large-scale projects. Make scales quite nicely 
to small, and moderately well to large. Recursive builds tend to be a problem, 
but fortunately with Go, you don’t tend to need those.

I would say Go tooling goes along rather well with Make if you’re following the 
semi-canonical repo structure, because you can tell Go to just build a list of 
executables from the ./cmd directory and the build tool takes care of caching, 
figuring out dependencies, etc. Not much in the way of portability issues there.

> Gradle would be another candidate. I am just began to explore it. It's a bit 
> like Maven with human syntax, but lacks again on lifecycle support that I 
> like with Maven.

I feel like Gradle is another very Java-oriented tool, and as a consequence 
seems to have inherited the very Byzantine nature of nearly every other Java 
ecosystem tool. I haven’t tried to use it for non-Java stuff, but I wouldn’t, 
personally. Not least because in a CI environment, I tend to try to stick to 
things either native to the language I’m using (so, the native Go build tools, 
*maybe* mage), or things present or easily installed in the host Docker image 
(both Bourne shell and Make fit this bill nicely).

The other benefit here is that in the projects I work on for work, not everyone 
wants to use Make (some folks have a pathological aversion to it), but it’s 
easy for us to make sure that Make is only ever a convenience method for things 
that can otherwise be easily done from the command-line (e.g. “go test ./…”). 
Make then becomes a) a convenience for running basic things (e.g. make test, 
make cover, make docker-test-race, that sort of thing) and b) a method for 
making sure our developers are running the same commands locally that the CI 
process does (don’t underestimate the importance of that for avoiding 
difficult-to-diagnose problems).

It’s also nothing you can’t do with plain shell scripts, but you’ll find 
yourself reinventing a lot of things that Make does for you quite nicely out of 
the box, like default parameters, list handling, target dependencies, etc.


- 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/6FC5892A-BB6A-4A59-93CC-942C2AA5105F%40gmail.com.

Re: [go-nuts] Re: Makefiles for Go Programs

[Sergey Matveev]

*** Roland Müller [2021-08-23 19:47]:
>What are the alternatives to Makefile that are used by Go developers?
>Please comment :-)

The best thing I saw, that literally completely changed my life is DJB's
redo build system. I replaced everything related to Makefile in all my
projects, gaining simplicity, reliable builds, huge convenience,
portability, good parallelizability and so on, so on. There are various
redo's implementation and redo-inspired creations, but I have created my
own, written on Go, the best one I saw from features and performance
point of view: http://www.goredo.cypherpunks.ru/
https://fzakaria.com/2020/06/08/my-love-letter-to-redo.html
https://apenwarr.ca/log/20101214
https://redo.readthedocs.io/en/latest/
http://jdebp.uk/FGA/introduction-to-redo.html
https://habr.com/ru/post/517490/ (my post on russian)
Nothing compares to its simplicity and still covering *all* Makefile's
use-cases and many more. However Go takes over much work out-of-box, so
there is not need to make rules for .o/.h/CFLAGS/whatever targets.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

-- 
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/YSPhKXBIvjDHs%2BEi%40stargrave.org.

Re: [go-nuts] Re: Makefiles for Go Programs

[Wojciech S. Czarnecki]

Dnia 2021-08-23, o godz. 19:47:47
Roland Müller  napisał(a):

> What are the alternatives to Makefile that are used by Go developers?

https://github.com/magefile/mage

yw.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210823193838.75db5e3a%40xmint.

Re: [go-nuts] Re: Makefiles for Go Programs

[Roland Müller]

Am Mo., 23. Aug. 2021 um 18:48 Uhr schrieb jake...@gmail.com <
jake6...@gmail.com>:

> On Sunday, August 22, 2021 at 11:11:23 PM UTC-4 jlfo...@berkeley.edu
> wrote:
>
>>
>> I've noticed that few, if any, Go programs use Makefiles. Is that because
>> the overhead of using make is greater than the overhead of just always
>> compiling and linking everything?
>>
>
> Go had built in build caching. So it will not have to "always compile and
> link everything." In addition, Go builds tend to be much, much faster than
> most other compiled languages. As a result, Makefiles are only useful if
> you have other operations to perform that are not part of the normal go
> tooling.
>
>
>> One piece of evidence for this is that the Go compiler leaves no
>> artifacts, like object files, so as is make wouldn't fit into the current
>> build method.
>>
>
What are the alternatives to Makefile that are used by Go developers?
Please comment :-)

I know Make from old C/C++ times. Therefore, my picture is that it is not
very portable and requires for quite many operations the usage of external
tools that again differ between the platforms. Basically Makefiles are
somehow enhanced shell scripts (Linux/Unix) or batch files (Windows).

Currently, at work I deal a lot with Maven, that is a bit too Java
-oriented in spite of being capable in principle to build and compile other
things too. Another, issue is the XML syntax that's makes editing without
tool support very hard.

Gradle would be another candidate. I am just began to explore it. It's a
bit like Maven with human syntax, but lacks again on lifecycle support that
I like with Maven.

BR,
Roland



>
>> Cordially,
>> Jon Forrest
>>
>>
>> --
> 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/449781bc-1605-4acf-b03c-dab98cf710efn%40googlegroups.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/CA%2B8p0G2dZGsL6RXTvc0m2_8_9MVUt_R1U3JFdhdHm8v3PwywNw%40mail.gmail.com.

[go-nuts] Re: How much longer

['Applied Go' via golang-nuts]

Hi DR,

If your students see the web site only through your stream, or if you are 
in control of the students' browsers (because, for example, it is a live 
classroom training with computers provided by the school), you can use a 
browser plugin like uBlock Origin that lets you block specific content 
permanently. I just tried it with the banner on golang.org and it works.

Of course, this does not hide the banner from your students when they visit 
the site directly from their own devices, but you can tell them to do the 
above at their end, too, if they feel distracted by the banner.

Best,
Christoph

On Friday, August 20, 2021 at 7:10:09 PM UTC+2 DR Hayden wrote:

> How much longer are we going to have to endure this political noise on 
> Go's otherwise helpful web site?
>
> Now that I have begun teaching after-school programming classes again, it 
> so far has been a source of constant distraction in my classes, causing 
> some students to posture one way or another, and just ruining all the fun 
> of teaching (and learning) programming, and Go.
>
> Additionally, the message seems utterly unrelated to Go.
>
> Thank you.
>
> --
> DR
>

-- 
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/3174dd98-e700-4b79-a407-0ca29bd04bc3n%40googlegroups.com.

[go-nuts] Re: Makefiles for Go Programs

[jake...@gmail.com]

On Sunday, August 22, 2021 at 11:11:23 PM UTC-4 jlfo...@berkeley.edu wrote:

>
> I've noticed that few, if any, Go programs use Makefiles. Is that because 
> the overhead of using make is greater than the overhead of just always 
> compiling and linking everything?
>
 
Go had built in build caching. So it will not have to "always compile and 
link everything." In addition, Go builds tend to be much, much faster than 
most other compiled languages. As a result, Makefiles are only useful if 
you have other operations to perform that are not part of the normal go 
tooling. 
 

> One piece of evidence for this is that the Go compiler leaves no 
> artifacts, like object files, so as is make wouldn't fit into the current 
> build method.
>
> Cordially,
> Jon Forrest
>
>
>

-- 
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/449781bc-1605-4acf-b03c-dab98cf710efn%40googlegroups.com.

Re: [go-nuts] Makefiles for Go Programs

[David Riley]

On Aug 22, 2021, at 23:11, jlfo...@berkeley.edu  wrote:
> 
> 
> I've noticed that few, if any, Go programs use Makefiles. Is that because the 
> overhead of using make is greater than the overhead of just always compiling 
> and linking everything?
> One piece of evidence for this is that the Go compiler leaves no artifacts, 
> like object files, so as is make wouldn't fit into the current build method.

I use Makefiles in our own internal projects because it allows me to establish 
a lot of good tooling around them, especially for repos which build a lot of 
binaries, Dockerize them, etc. It’s quite useful, despite the lack of 
intermediate files which Make tends to rely on to determine whether to rebuild 
things. Among other things, Make deals a lot better with lists of files and the 
concept of prerequisite steps than e.g. Bourne shell, and the Make package is 
actually considerably smaller than Bash in most tiny distros like Alpine, which 
is a consideration for Dockerfiles.

Unfortunately, to make Make worth the effort in Go projects, you need to 
understand it, otherwise you’ll just wind up with a lot of independent targets 
with a lot of repetitive code. Many developers these days (especially newer 
ones) have never been exposed to Make other than just running it and aren’t 
aware of what it can do, and so tend not to understand why you might not use it 
instead of e.g. Bash (they also tend not to understand why it might not be a 
good idea to use Bashisms instead of vanilla Bourne shell, but that’s a 
conversation for another time).

Basically, Make can make your Go projects a lot more intuitive to build, 
especially when it comes to things like default flags and consistency with CI, 
but you do have to put some effort into it, and you have to get people over the 
“Make is hard” mindset or they will “fix” your project by getting rid of it, 
IME.

FWIW, our default “make test” target generally just does “go test -race ./…”, 
with some optional coverage arguments spliced in when you “make cover”. “make 
cover-report” is where Make starts to shine; there’s a file prerequisite rule 
defined for the coverage file as well as for the HTML coverage report, and 
“make cover-report” just says to build the report file and Make’s dependency 
resolution magically takes care of the rest. It’s actually a pretty good basic 
demonstration of capabilities that used to be considered standard knowledge.


- 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/052168C4-EFE0-49AA-AEDC-8B3557025C81%40gmail.com.

[go-nuts] Re: Coverage Reports

[Henry]

See 
https://kenanbek.medium.com/go-tests-with-html-coverage-report-f977da09552d

On Saturday, August 21, 2021 at 3:26:41 AM UTC+7 ivan.rosal...@gmail.com 
wrote:

> Hi,
>
>  
>
>   Anybody knows how I can get a coverage report, ever if the 
> unit test was failed, when run go test command with -coverprofile flag 
> always get a one line file with mode: set value inside.
>
>  
>
>  
>
> Regards.
>

-- 
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/a9bf8045-4e6f-415c-8d0b-5cda2de8afden%40googlegroups.com.