Re: [go-nuts] Bug? go/src/all.bash on master branch fails in go/build test with Go1.18

[tenkoh]

I have heard about build dashboard for the first time. Thanks! I will check 
it.

2022年4月7日木曜日 14:45:39 UTC+9 axel.wa...@googlemail.com:

> The master branch is used for the active development and not for general 
> consumption. It is not unusual for builds/tests to fail on it occasionally. 
> You can always check the build dashboard  to 
> see if that's currently the case.
> Generally, I would tend to assume that there is something wrong with your 
> setup, especially if it also happens on the release-branch.go1.18 branch. 
>
> On Thu, Apr 7, 2022 at 12:25 AM tenkoh  wrote:
>
>> I'm unsure whether this is a bug or not, so let me ask here.
>>
>> *### What version of Go are you using (`go version`)?*
>> go version go1.18 linux/arm64
>>
>> *### Does this issue reproduce with the latest release?*
>> Yes
>>
>> *### What operating system and processor architecture are you using (`go 
>> env`)?*
>> using docker image: golang:1.18
>>
>> GO111MODULE=""
>> GOARCH="arm64"
>> GOBIN=""
>> GOCACHE="/root/.cache/go-build"
>> GOENV="/root/.config/go/env"
>> GOEXE=""
>> GOEXPERIMENT=""
>> GOFLAGS=""
>> GOHOSTARCH="arm64"
>> GOHOSTOS="linux"
>> GOINSECURE=""
>> GOMODCACHE="/go/pkg/mod"
>> GONOPROXY=""
>> GONOSUMDB=""
>> GOOS="linux"
>> GOPATH="/go"
>> GOPRIVATE=""
>> GOPROXY="https://proxy.golang.org,direct";
>> GOROOT="/usr/local/go"
>> GOSUMDB="sum.golang.org"
>> GOTMPDIR=""
>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm64"
>> GOVCS=""
>> GOVERSION="go1.18"
>> GCCGO="gccgo"
>> AR="ar"
>> CC="gcc"
>> CXX="g++"
>> CGO_ENABLED="1"
>> GOMOD="/go.mod"
>> GOWORK=""
>> CGO_CFLAGS="-g -O2"
>> CGO_CPPFLAGS=""
>> CGO_CXXFLAGS="-g -O2"
>> CGO_FFLAGS="-g -O2"
>> CGO_LDFLAGS="-g -O2"
>> PKG_CONFIG="pkg-config"
>> GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 
>> -fdebug-prefix-map=/tmp/go-build2526966007=/tmp/go-build 
>> -gno-record-gcc-switches"
>> GOROOT/bin/go version: go version go1.18 linux/arm64
>> GOROOT/bin/go tool compile -V: compile version go1.18
>> uname -sr: Linux 5.10.47-linuxkit
>> /lib/aarch64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 
>> 2.31-13+deb11u2) stable release version 2.31.
>>
>> *### What did you do?*
>> Get master branch, then run build & test using "all.bash"
>>
>> ```
>> $ cd /
>> $ mkdir build
>> $ cd build
>> $ git clone https://go.googlesource.com/go
>> $ cd go/src
>> $ ./all.bash 
>> ```
>>
>> *### What did you expect to see?*
>> Success in build and all tests.
>>
>>
>> *### What did you see instead?*
>> --- FAIL: TestImportPackageOutsideModule (0.00s)
>> build_test.go:647: error when importing package when no go.mod is 
>> present: got "no required module provides package example.com/p; to add 
>> it:\n\tgo get example.com/p"; want "go.mod file not found in current 
>> directory or any parent directory"
>> FAIL
>> FAILgo/build0.948s
>>
>>
>> The error occurs in go/src/go/build/build_test.go.
>> The same test passed with go 1.17.8.
>>
>> Best 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a5ae452c-c991-4a95-8ccb-c698672447bdn%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/49a87842-35e8-45b8-bf89-4a2e1784816dn%40googlegroups.com.

Re: [go-nuts] Why is it forbidden to add methods to an existing type?

[Sam Hughes]

Like, I get that the extra type-pointer for a declared struct of 
float64+bool isn't that big of a deal, I do wish we could express tuple 
types naturally. What you suggest is probably the closest we get for now. 
For `if v, ok := value.(bool); ok && v`, the value is tuly 0. For `if v, ok 
:= value.(bool); ok && !v`, the value is truly nil. For `if v, ok := 
value.(float64); ok`, the value can be known to be properly and truly the 
value, even if `0.0`. This would extend to any other type I can think of, 
excepting, naturally, bools.

Meanwhile, did you see the half-serious sigma-type proposal? I'm pretty 
sure that would effectively resolve this question, as little hope as I have 
for it to be accepted.

On Wednesday, April 6, 2022 at 4:01:32 AM UTC-5 Brian Candler wrote:

> I agree, and there's a clear benefit that it's harder to dereference a nil 
> interface than a nil pointer, when that interface has no methods.  The 
> problem is that statically it doesn't tell you anything about the possible 
> contained type.
>
> In comparison, a pointer tells you exactly the type contained, but it must 
> be exactly one type, and there's always a risk of accidentally deferencing 
> a nil pointer. 
>
> If one day, generics type-constraint interfaces could be used as regular 
> interface types, that would be powerful: you could have a variable of type 
> "interface { float64 | Status }" and know for sure that the value *must* be 
> either nil, float64 or Status. Furthermore, you wouldn't be able to use the 
> contained value without an explicit type assertion.
>
> On Wednesday, 6 April 2022 at 01:10:23 UTC+1 sam.a@gmail.com wrote:
>
>> I get what you're saying, and for what it's worth, you're absolutely 
>> correct. Something like above is a set of tradeoffs, and I guess all I can 
>> assert is that it works for me. I do think it's a good design, given Go's 
>> lack of a None type to enforce well-defined behavior on a nil pointer 
>> dereference, but it's an example of a well-designed API from the days 
>> before generics, which safely respects nil/null values in the appropriate 
>> context.
>>
>> For most of my use of the model, the types offered by the pgtype pacakge 
>> are A. total overkill, and B. just an intermediate type to hold a value 
>> between two boundaries that do understand null values, such as bridging an 
>> RPC frontend and a SQL backend.
>>
>> If anything, it proves that Generics do simplify codebases, and that 
>> well-defined, graceful null/nil handling is worth the effort.
>> On Tuesday, April 5, 2022 at 5:13:04 AM UTC-5 Brian Candler wrote:
>>
>>> I did look at the code briefly.  The main thing I noticed was that the 
>>> return type of float8.Get() was an interface{} - so it's up to the caller 
>>> to check at runtime whether the value is nil, a float64, or a Status.
>>>
>>> So you're right, it's not that they are compile-time unsafe, but rather 
>>> that you have to write type matching code at each use site. Within a given 
>>> switch branch, it's safe.
>>>
>>> On Tuesday, 5 April 2022 at 07:29:09 UTC+1 sam.a@gmail.com wrote:
>>>
 Uh, you should check the code: 
 github.com/jackc/pgtype/blob/master/float8.go If you know what you 
 have and what you're dealing with, and if you actually check the error 
 result, you do get safety. If you don't know what you've got, or if you're 
 iterating through the values, then you end up hitting the sad, sad, 
 reflective path...for now.
 On Saturday, April 2, 2022 at 4:37:36 AM UTC-5 Brian Candler wrote:

> Correct repository path is: https://github.com/jackc/pgtype
>
> Interesting.  These structs generally contain a Status value as well:
>
> type Int8 struct {
>Int int64
>Status Status
> }
>
> where pgtype.go has:
>
> type Status byte
>
> const (
>Undefined Status = iota
>Null
>Present
> )
>
> They also have Set() and Get() methods, although these are not 
> compiled-time type safe as they accept and return interface{}
>
> On Friday, 1 April 2022 at 17:40:42 UTC+1 sam.a@gmail.com wrote:
>
>>
>> Thanks for clarifying that, @Brian. Yeah. It took a bit to warm up to 
>> that approach, but the github.com/jackc/pgtypes convinced me that 
>> the results were worth it. The benefits:  A, package interpretation 
>> methods 
>> with a piece of data, B, lazily valuate data when needed, and C, gain 
>> introspective capability specific to the type and not using reflect
>> On Friday, April 1, 2022 at 4:47:32 AM UTC-5 Brian Candler wrote:
>>
>>> That wasn't literal code with anglebrackets - you're supposed to 
>>> fill that in yourself.  I think he meant something like:
>>>
>>> type fooString struct{ string }
>>>
>>> https://go.dev/play/p/4Q94xMZDciV
>>>
>>> What this is doing is *embedding* a string value into a struct; if 
>>> you have no

[go-nuts] Generics: Self Referencing Constraint Types

[jfcg...@gmail.com]

Hi, please take a look .

The aim is to write a HaveLess constraint that will work with any type like 
Large, without any reflection / traditional interfaces / dictionaries etc., 
just plain method calls.

How would you write this? Keep in mind that type Large is large :)

-- 
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/e79c4f92-4508-4ecd-ab32-c47b2d679f78n%40googlegroups.com.

[go-nuts] Re: Execution of goroutines

[golf_mike]

Ok, thanks that makes sense!
On Wednesday, April 6, 2022 at 6:56:42 PM UTC+2 Brian Candler wrote:

> > Is there maybe something blocking involved in http.Get()?
>
> Yes of course - first establishing a TCP connection across the network, 
> then sending data over it and waiting for the response.
>
> Each of these is a point where the goroutine gets descheduled because it 
> has nothing more to do; it's waiting for an external event which may not 
> come for several milliseconds (an aeon in computer time).
>
> On Wednesday, 6 April 2022 at 14:43:15 UTC+1 golf_mike wrote:
>
>> Hi,
>>
>> As a fun way of getting into Go I decided to create a "random" number 
>> generator by timing a number of requests to a specific URL, and reducing 
>> the results to one number. For practice pusposes I made a  "naive" version 
>> with just a for loop and a version that uses goroutines.
>> As I am interested in the timings for each individual request, there was 
>> an interesting result. Implemented in the for loop, each request was timed 
>> as expected. For the goroutines however the timings incremented for each 
>> individual timing, where the last timing was equal or a microsecond or so 
>> below the total timing for all requests.
>> Upon further inspection, it seems that the time.Now() for the startTime 
>> is called almost immediately for all, but the time.Now() for the stopSub is 
>> called much later.
>> How is it possible that all goroutines start execution at the same time, 
>> but finish not at the same time? Is there maybe something blocking involved 
>> in http.Get()?
>> I posted all code for this on Stackoverflow a couple of days ago but no 
>> answers there yet (go - Unexpected behaviour of time.Now() in goroutine 
>> - Stack Overflow 
>> ).
>>  
>> See below for the goroutine and how it is called.
>>
>> Execution of goroutines:
>> *start := time.Now()*
>> *ch := make(chan int64, 100)*
>> *url := "https://www.nu.nl "*
>> *for i := 0; i < len(timings_parallel); i++ {*
>> *wg.Add(1)*
>> *go func() {*
>> *defer wg.Done()*
>> *doGet(url, ch)*
>> *}()*
>> *}*
>> *wg.Wait()*
>> *close(ch)*
>> *// feed the results from the channel into the result array*
>> *count := 0*
>> *for ret := range ch {*
>> *timings_parallel[count] = ret*
>> *count++*
>> *}*
>> *// get total running time for this part*
>> *time_parallel := time.Since(start).Milliseconds()*
>> Goroutine:
>> *func doGet(address string, channel chan int64) {*
>> *startTime := time.Now()*
>> *startSub := startTime.UnixMilli()*
>>
>> *_, err := http.Get(address)*
>> *if err != nil {*
>> *log.Fatalln(err)*
>> *}*
>> *stopSub := time.Now().UnixMilli()*
>> *delta := stopSub - startSub*
>>
>> *channel <- delta*
>> *}*
>>
>>
>>

-- 
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/be3bb29b-1924-4586-8208-3d25f29e7816n%40googlegroups.com.

Re: [go-nuts] Generics: Self Referencing Constraint Types

['Axel Wagner' via golang-nuts]

At its core, this is this restriction of the current generics design:
https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-way-to-require-pointer-methods
That is, there is no real "nice" way to do it.

If you are willing to require a pointer receiver, you can do constraint
type inference:
https://go.dev/play/p/L2NiAAM8qE4
Alternatively, it might be appropriate to do away with methods and pass a
comparison function:
https://go.dev/play/p/XRoD70UFbzi
This has the advantage of being able to use types which you don't control
as well.


On Thu, Apr 7, 2022 at 10:07 AM jfcg...@gmail.com 
wrote:

> Hi, please take a look .
>
> The aim is to write a HaveLess constraint that will work with any type
> like Large, without any reflection / traditional interfaces /
> dictionaries etc., just plain method calls.
>
> How would you write this? Keep in mind that type Large is large :)
>
> --
> 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/e79c4f92-4508-4ecd-ab32-c47b2d679f78n%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/CAEkBMfFhuwgy4HM%3DP7vRYyUDfsnj1ZhdnvctKqQFNkiVprFCYA%40mail.gmail.com.

Re: [go-nuts] Generics: Self Referencing Constraint Types

[jfcg...@gmail.com]

>
> If you are willing to require a pointer receiver, you can do constraint 
> type inference:
> https://go.dev/play/p/L2NiAAM8qE4
>

A single cast worked nicely , 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/0e357953-d602-4324-bc32-5aee3a1ab3ban%40googlegroups.com.

[go-nuts] Re: Java to Go converter - 2

[alex-coder]

Thanks for the comments about generating code to handle exceptions. . Here 
it is a new version.
package main

import (
"fmt"
"os"
)

type CatchException struct{}

func main() {

var args []string = os.Args

var ce CatchException = CatchException{}
ce.CatchException_main(args)
}

/** generated method **/
func (catchException *CatchException) CatchException_main(args []string) {
defer func() {
if err := recover(); err != nil {
exc := err.(Exception)
switch exc.msg {
case "Exception":
fmt.Println("yes, I caught it")
default:
fmt.Println("No, something is not right")
}
}
fmt.Println("finally processing")
}()

(&ThrowException{}).runme()
}

type ThrowException struct{}

func (throwException *ThrowException) runme() {
panic(Exception{"Exception"})
}

type Exception struct {
msg string
}

понедельник, 4 апреля 2022 г. в 14:12:37 UTC+3, alex-coder: 

>
>
>
>
> *Another use case for automatically translating codewritten in Java to 
> Golang is Exception Handling.The next example is likely to be about 
> multithreading.Example in Java:*
> package com.builder.start.here;
>
> public class CatchException {
>
> public static void main(String[] args) {
> try {
> new ThrowException().runme();
> } catch (Exception e) {
> System.out.println("yes, I caught it");
> } finally {
> System.out.println("finally processing");
> }
>
> }
>
> }
>
> class ThrowException{
> public void runme() throws Exception{
> throw new Exception();
> }
> }
>
> *Converter gave out:*
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type CatchException struct{}
>
>
> func main() {
>
> var args []string = os.Args
>
> var ce CatchException = CatchException{}
> ce.CatchException_main(args)
> }
>
> /** generated method **/
> func (catchException *CatchException) CatchException_main(args []string) {
> defer func() {
> if err := recover(); err != nil {
> str := err.(string)
> switch str {
> case "Exception":
> fmt.Println("yes, I caught it")
> default:
> fmt.Println("No, something is not right")
> }
> }
> fmt.Println("finally processing")
> }()
>
> (&ThrowException{}).runme()
> }
>
> type ThrowException struct{}
>
> func (throwException *ThrowException) runme() {
> panic("Exception")
> }
> воскресенье, 27 марта 2022 г. в 15:11:48 UTC+3, alex-coder: 
>
>> After several months of switching from Java to Golang, it seemed to me 
>> that
>> it would be interesting to make the translation of Java code into Golang 
>> automatically.
>> The text below shows what has been done so far.
>>
>> The work is not a prototype, but rather indicates the possibility of 
>> achieving a result.
>> Therefore, I deliberately simplify the development context of the 
>> Converter where it was 
>> possible. 
>>
>> At first it seemed important to me that between Java and Go there is a 
>> difference 
>> between the implementation of the Dynamic Dispatching, more precisely, 
>> there is no 
>> Dynamic Dispatching in Go. The applied solution in the current 
>> implementation 
>> looks not only ugly but even violates the several very important rules of 
>> the OO design, 
>> I'm not kidding here. But this option looks like that it will be working. 
>>
>> Onward I will provide the 4 code samples in Java, followed by the 
>> automatically 
>> generated Golang code and comments as needed. 
>>
>> *1. Of course, I started with the most popular program: "Hello World".*
>>
>> package main;
>>
>> public class HelloWorld {
>>   public static void main(  String[] args){
>> System.out.println("Hello World");
>>   }
>> }
>>
>> *Converter gave out:*
>>
>> package main
>>
>> import (
>> "fmt"
>> "os"
>> )
>>
>> type HelloWorld struct{}
>>
>> func main() {
>>
>> var args []string = os.Args
>>
>> var hw HelloWorld = HelloWorld{}
>> hw.HelloWorld_main(args)
>> }
>>
>> /** generated method **/
>> func (helloWorld *HelloWorld) HelloWorld_main(args []string) {
>> fmt.Println("Hello World")
>> }
>>
>> *2. Next, it was interesting to deal with the problem of a simple 
>> inheritance.*
>>
>> package main;
>>
>> public class TestInheritance {
>>   public static void main(  String[] args){
>> Inheritance inh=null;
>> inh=new Second();
>> inh.hello();
>> inh=new Third();
>> inh.hello();
>>   }
>> }
>> public interface Inheritance {
>>   public void hello();
>> }
>> class Second implements Inheritance {
>>   public void hello(){
>> System.out.println("Second");
>>   }
>> }
>> class Third implements Inheritance {
>>   public void hello(){
>> System.out.println("Third");
>>   }
>> }
>>  
>> *Converter gave out:*
>>
>> package main
>>
>> impo

[go-nuts] Re: [security] Go 1.18.1 and Go 1.17.9 pre-announcement

[Carlos Amedee]

Hello gophers,

Due to an issue with release tooling, this release is now planned for 
Tuesday, April 12th.

Sorry for the inconvenience.

Carlos on behalf of the Go team
On Monday, April 4, 2022 at 11:25:43 AM UTC-4 Julie Qiu wrote:

> Hello gophers,
>
> We plan to issue Go 1.18.1 and Go 1.17.9 on Thursday, April 7th.
>
> These minor releases include a PRIVATE security fix to the standard 
> library.
>
> Following our security policy, this is the pre-announcement of those 
> releases.
>
> Thanks,
> Julie on behalf of the Go team
>

-- 
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/856fcb34-c7ed-4dca-aab6-c42001492d93n%40googlegroups.com.

[go-nuts] why the opendefer optimization will close when my function's named return value escape

[ワタナベハルキ]

GOARCH="amd64"
GOHOSTOS="linux"
GOVERSION="go1.17.2"

*Here is my test code*

var sink *int

func main(){
escape()
}

// named return value r
func escape() (r int) {
defer func(){
recover()
}()
sink = &r // escape r
panic("qOeOp")
return
}

jokoi@ubuntu:~/GoProJ/test$ go build -gcflags "-d defer" main.go
./main.go:11:2: stack-allocated defer

and i find something comment may be useful in package 
cmd/compile/internel/ssagen

if s.hasOpenDefers {
..
// Similarly, skip if there are any heap-allocated result
// parameters that need to be copied back to their stack 
slots.
for _, f := range s.curfn.Type().Results().FieldSlice() {
if !f.Nname.(*ir.Name).OnStack() {
s.hasOpenDefers = false
break
}
}
}
..
}

but i cannot understand why ? As far as i know , coping heap-allocated 
result parameter back just need a small piece of code like mov rax [rax] at 
the exit point of one function , why compiler cannot generate  it .

-- 
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/a8212173-c664-4f48-93dc-528a8d8391bcn%40googlegroups.com.

[go-nuts] Why does Go not have intrinsic functions?

[Arthur Comte]

Intrinsic functions (functions that compile down to one hardware 
instruction) are common in (relatively) low-level languages. Go even 
supports embed ASM (though a weird flavour of it)
Can someone explain why we do not have an intrinsic function package? This 
seems like it would greatly ease the use of SIMD
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/7d95b9b9-9b94-48c1-9784-c5b7c54bc6b9n%40googlegroups.com.

[go-nuts] MaxDiskSize MaxLogCount for glog?

['Jack Li' via golang-nuts]

Hi group,


I only find MaxSize in glog which sets the size of each log file. 


Can glog support the options like how many disk size (ie. 10%, 1.8G, etc.) all 
the log files may use in total, and the count (ie. 10) of log files it can 
save. For example, logfile1.txt, logfile2.txt, ..., logfile10.txt. These 10 
files is 18G in total. And there is no logfile11.txt, its content will 
overwrite logfile1.txt.

-- 
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/tencent_6149C23CC8588B219B7C94E0188C24E3E007%40qq.com.

Re: [go-nuts] Why does Go not have intrinsic functions?

['Axel Wagner' via golang-nuts]

Go does have them.
math/big compiles down to single instructions on platforms where it's
supported. sync/atomic does as well.

On Thu, Apr 7, 2022 at 8:03 PM Arthur Comte  wrote:

> Intrinsic functions (functions that compile down to one hardware
> instruction) are common in (relatively) low-level languages. Go even
> supports embed ASM (though a weird flavour of it)
> Can someone explain why we do not have an intrinsic function package? This
> seems like it would greatly ease the use of SIMD
> 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/7d95b9b9-9b94-48c1-9784-c5b7c54bc6b9n%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/CAEkBMfG9cChWw5gmSQ%3DM78GBjn_4Tcbh869yT1BZZKM%3DT0sOdg%40mail.gmail.com.

Re: [go-nuts] Why does Go not have intrinsic functions?

[Ian Lance Taylor]

On Thu, Apr 7, 2022 at 11:03 AM Arthur Comte  wrote:
>
> Intrinsic functions (functions that compile down to one hardware instruction) 
> are common in (relatively) low-level languages. Go even supports embed ASM 
> (though a weird flavour of it)
> Can someone explain why we do not have an intrinsic function package? This 
> seems like it would greatly ease the use of SIMD

Go does have a couple of intrinsic function packages: sync/atomic and
math/bits.  Many of the functions in those packages are implemented
directly in the compiler.

What Go does not have is a generalized way to write intrinsic
functions apart from implementing them in the compiler.  That was
https://go.dev/issue/17373, which was declined.

Go also does not have a SIMD package, but that is more because nobody
has figured out the right approach for such a thing in Go.  There was
at least one attempt at https://go.dev/issue/35307, but that too was
declined.

Ian

-- 
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/CAOyqgcUikzqimNsLwqzqjbCHHMOhWOehC4sHF5a3CXKdcRWwuQ%40mail.gmail.com.

[go-nuts] Missing /usr/lib/go/pkg/include/ for native binaries

[Tong Sun]

This might be the first go package that I do `go get` and which requires 
native binaries:

$ go get -v go.opentelemetry.io/otel/exporters/stdout/stdouttrace
golang.org/x/sys/unix
# golang.org/x/sys/unix
/.../Go/pkg/mod/golang.org/x/sys@v0.0.0-20210423185535-09eb48e85fd7/unix/asm_linux_amd64.s:9:
 
#include: open /usr/lib/go-1.17/pkg/include/textflag.h: no such file or 
directory

I checked and found that I'm missing the 
whole /usr/lib/go-1.17/pkg/include/ directory.

How can I get them so that my `go get` can be successful?

Thanks

$ go version
go version go1.17.6 linux/amd64

$ lsb_release -a 
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bullseye/sid
Release:   10.12
Codename:  buster

$ apt-cache policy golang-1.17-src
golang-1.17-src:
  Installed: 1.17.6-1~bpo11+1
  Candidate: 1.17.8-1~bpo11+1
  Version table:
 1.17.8-1~bpo11+1 100
100 http://deb.debian.org/debian bullseye-backports/main amd64 
Packages
 *** 1.17.6-1~bpo11+1 100
100 /var/lib/dpkg/status

-- 
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/fb6dfce0-98ef-4b9f-ab3b-d14055f39c53n%40googlegroups.com.

Re: [go-nuts] Missing /usr/lib/go/pkg/include/ for native binaries

[Ian Lance Taylor]

On Thu, Apr 7, 2022 at 2:35 PM Tong Sun  wrote:
>
> This might be the first go package that I do `go get` and which requires 
> native binaries:
>
> $ go get -v go.opentelemetry.io/otel/exporters/stdout/stdouttrace
> golang.org/x/sys/unix
> # golang.org/x/sys/unix
> /.../Go/pkg/mod/golang.org/x/sys@v0.0.0-20210423185535-09eb48e85fd7/unix/asm_linux_amd64.s:9:
>  #include: open /usr/lib/go-1.17/pkg/include/textflag.h: no such file or 
> directory
>
> I checked and found that I'm missing the whole /usr/lib/go-1.17/pkg/include/ 
> directory.
>
> How can I get them so that my `go get` can be successful?
>
> Thanks
>
> $ go version
> go version go1.17.6 linux/amd64
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux bullseye/sid
> Release:   10.12
> Codename:  buster
>
> $ apt-cache policy golang-1.17-src
> golang-1.17-src:
>   Installed: 1.17.6-1~bpo11+1
>   Candidate: 1.17.8-1~bpo11+1
>   Version table:
>  1.17.8-1~bpo11+1 100
> 100 http://deb.debian.org/debian bullseye-backports/main amd64 
> Packages
>  *** 1.17.6-1~bpo11+1 100
> 100 /var/lib/dpkg/status

That's odd.  File a bug report against Debian?  I don't know why they
are missing.

You can of course get the header files you need by installing Go
yourself (https://go.dev/doc/install).

Ian

-- 
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/CAOyqgcUG%3DbHnYq4qGCC6ZTqhQX0WknDwvqZBTnEhm8tJ3Sbh9w%40mail.gmail.com.

Re: [go-nuts] Why does Go not have intrinsic functions?

[Sam Hughes]

FWIW, I took a stab at a SIMD-oriented feature 
(https://go.dev/issue/48499), but as @Ian%20Lance%20Taylor put it, it's 
about the right approach. I skewed too far towards convenience in what I 
proposed, gaining significant maintainability concerns.
On Thursday, April 7, 2022 at 3:35:35 PM UTC-5 Ian Lance Taylor wrote:

> On Thu, Apr 7, 2022 at 11:03 AM Arthur Comte  
> wrote:
> >
> > Intrinsic functions (functions that compile down to one hardware 
> instruction) are common in (relatively) low-level languages. Go even 
> supports embed ASM (though a weird flavour of it)
> > Can someone explain why we do not have an intrinsic function package? 
> This seems like it would greatly ease the use of SIMD
>
> Go does have a couple of intrinsic function packages: sync/atomic and
> math/bits. Many of the functions in those packages are implemented
> directly in the compiler.
>
> What Go does not have is a generalized way to write intrinsic
> functions apart from implementing them in the compiler. That was
> https://go.dev/issue/17373, which was declined.
>
> Go also does not have a SIMD package, but that is more because nobody
> has figured out the right approach for such a thing in Go. There was
> at least one attempt at https://go.dev/issue/35307, but that too was
> declined.
>
> Ian
>

-- 
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/92bb2a89-b2ec-46ea-9223-294e963ebbb4n%40googlegroups.com.

Re: [go-nuts] Missing /usr/lib/go/pkg/include/ for native binaries

['Jack Li' via golang-nuts]

Yes, I download the latest go 1.18 installer for macOS from golang.google.cn. 
There's no problem with the installer from the official site.




-- Original --
From: "Ian Lance Taylor"http://deb.debian.org/debian bullseye-backports/main amd64 Packages
>  *** 1.17.6-1~bpo11+1 100
> 100 /var/lib/dpkg/status

That's odd.  File a bug report against Debian?  I don't know why they
are missing.

You can of course get the header files you need by installing Go
yourself (https://go.dev/doc/install).

Ian

-- 
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/CAOyqgcUG%3DbHnYq4qGCC6ZTqhQX0WknDwvqZBTnEhm8tJ3Sbh9w%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/tencent_4192200F2E967CA8269F31780D23C4D87D05%40qq.com.