Re: [go-nuts] Go 1.16 and modules

[Jon Reiter]

i think it's gentler to look at this in the context of c's "hello world"
program.  the first version was missing both #include and void.  then it
got #include. then it got void.  i recall void issues with code from k v1
on my compiler in the mid 80s (i do not predate include statements).  i
recall a brian kernighan talk where he comments on precisely this point as
well.  for me it's not so much "it's easy just do it" but rather "it's
fairly easy and worth it for the clarity."

yes i know those are code changes while this is the build process -- this
is about quantum of effort required.  having said that: something to help
with missing modules in dependencies would be helpful as that is
significantly harder.  i was able to adjust c even as a novice.  a
casual/beginner today is likely not able to fork-and-update a dependency.


On Tue, Mar 30, 2021 at 7:56 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I understand many criticisms of modules, but I honestly don't really get
> this one.
> You can just do `go mod init foo` in an empty directory, if all you want
> is some throwaway Go code. It doesn't actually seem very complicated to me,
> I must say.
>
> On Tue, Mar 30, 2021 at 1:52 AM Rich  wrote:
>
>> I really WANT to use go modules on all my projects, but there are times I
>> just want to write a quick piece of code that I can 'go run'. Its usually
>> just 20 lines, just used to test something out like a rest call to an
>> internal server (can't do that on go playground) and for me go modules just
>> makes it more complex. So what I do is what Reto stated above, set an
>> environment variable for GO111MODULE=OFF.  Now at the command line I can
>> write a quick code sample and just type 'go run sample.go' and it runs.
>> For my projects where I want go modules I use a Make file:
>>
>> GO111MODULE=on GOOS=linux GOARCH=amd64 go build $(compilerFlag) -o
>> mygoproject mygoproject.go othergofiles.go...
>>
>>
>>
>> On Monday, March 29, 2021 at 12:33:57 AM UTC-4 amits...@gmail.com wrote:
>>
>>> On Mon, Mar 29, 2021 at 12:15 PM Reto  wrote:
>>> >
>>> > On Mon, Mar 29, 2021 at 11:18:28AM +1100, Amit Saha wrote:
>>> > > "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 GO111MODULE
>>> to
>>> > > auto. "
>>> > > Is that implying the above behavior?
>>> >
>>> > Yes: https://golang.org/ref/mod#mod-commands
>>> >
>>> > Note that you can still run the hello world programs via `go run`
>>> without
>>> > having a module.
>>>
>>> Thanks.
>>>
>>> >
>>> > --
>>> > 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/20210329011453.3dddpz3syc6wv636%40feather.localdomain.
>>>
>>>
>> --
>> 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/c62dd3f2-da7f-494a-8bdc-f7c7f1c4b308n%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/CAEkBMfGk52HwKmX3Oj_%2B5yiCi%3Dk6VTvihi4rBbqSdXr1M67UCw%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/CABZtUk4mCuSSZW9Ci6DJBCYisJL1iKbDPKKqky7uY6GxHC1wXw%40mail.gmail.com.

Re: [go-nuts] Go 1.16 and modules

[Eli Bendersky]

On Mon, Mar 29, 2021 at 4:52 PM Rich  wrote:

> I really WANT to use go modules on all my projects, but there are times I
> just want to write a quick piece of code that I can 'go run'. Its usually
> just 20 lines, just used to test something out like a rest call to an
> internal server (can't do that on go playground) and for me go modules just
> makes it more complex. So what I do is what Reto stated above, set an
> environment variable for GO111MODULE=OFF.  Now at the command line I can
> write a quick code sample and just type 'go run sample.go' and it runs.
> For my projects where I want go modules I use a Make file:
>
> GO111MODULE=on GOOS=linux GOARCH=amd64 go build $(compilerFlag) -o
> mygoproject mygoproject.go othergofiles.go...
>

I may have missed it, but could you clarify why you can't just create your
sample.go and 'go run' it with Go 1.16? No need to create a module for
this.


/tmp$ ls go.mod
ls: cannot access 'go.mod': No such file or directory

/tmp$ cat sample.go
package main

import "fmt"

func main() {
   fmt.Println("hello")
}

/tmp$ go version
go version go1.16 linux/amd64

/tmp$ go run sample.go
hello


Or is your 'sample.go' importing code from outside the standard library?

Eli





>
>
>
> On Monday, March 29, 2021 at 12:33:57 AM UTC-4 amits...@gmail.com wrote:
>
>> On Mon, Mar 29, 2021 at 12:15 PM Reto  wrote:
>> >
>> > On Mon, Mar 29, 2021 at 11:18:28AM +1100, Amit Saha wrote:
>> > > "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 GO111MODULE
>> to
>> > > auto. "
>> > > Is that implying the above behavior?
>> >
>> > Yes: https://golang.org/ref/mod#mod-commands
>> >
>> > Note that you can still run the hello world programs via `go run`
>> without
>> > having a module.
>>
>> Thanks.
>>
>> >
>> > --
>> > 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/20210329011453.3dddpz3syc6wv636%40feather.localdomain.
>>
>>
> --
> 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/c62dd3f2-da7f-494a-8bdc-f7c7f1c4b308n%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/CAF-Rda-awCfWXD6aRCVw4Qd2PpFxe3pBgiMW9_iTQC7j9Rg_2A%40mail.gmail.com.

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

[JX Zhang]

> The Go runtime and standard library has a public, exported API; this sort 
of use of go:linkname to reach into the internals of a standard package (in 
this case, calling an unexported function) is not supported.
The limitation to access private functions in std package sounds reasonable.

> You can run the tag 'codec.safe' to run tests or build in safe mode. e.g.
>  go test -tags codec.safe -run Json
>  go test -tags "alltests codec.safe" -run Suite
 
thanks for your advice, but I'm not aiming at this project. I just wonder 
whether gollvm is adaptable to large-scale projects and why this case fails 
is enough
^ _ ^

The problem cause by reflect.unsafe_New can be seen solved. Welcome to add 
something if anyone has a better answer~
---

Then I wonder why gollvm work failed with pthread_join which is a C lib 
function
I wrote  a demo:

```
package main

/*
#cgo CFLAGS: -I./
#cgo LDFLAGS: -L./
#include "ccode.h"
*/
import "C"
import (
"fmt"
)

func main() {
v := C.try_pthread()
fmt.Println(v)
}
```

```
# include 
# include "ccode.h"
# include 

int try_pthread(){
pthread_t id;
int ret, i = 0;
ret = pthread_create(,NULL,(void *)thread,NULL);
for(i=0;i<=5;i++)
{
printf("This is main thread %d\n",i);
//sleep(1);
}
pthread_join(id,NULL);
//gets();
return 0;
}

void thread()
{
int i=0;
for(i=0;i<=5;i++)
{
printf("this is thread %d\n",i);
// sleep();
}
}
```

pthread_create() works well in gollvm but pthread_join() failed...
在2021年3月29日星期一 UTC+8 下午8:40:34 写道：

> On Monday, March 29, 2021 at 8:32:53 AM UTC-4 peterGo wrote:
>
>> You haven't said whether you followed the "safe" instructions for 
>> github.com/ugorji/go/codec to avoid building code/helper_unsafe.go, 
>> which uses go:linkname.
>>
>>
> s/code/helper_unsafe.go/codec/helper_unsafe.go/
>
> Peter
>

-- 
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/93edfaf0-2d32-4496-aaa5-9b3b60cf23b6n%40googlegroups.com.

Re: [go-nuts] Go 1.16 and modules

['Axel Wagner' via golang-nuts]

I understand many criticisms of modules, but I honestly don't really get
this one.
You can just do `go mod init foo` in an empty directory, if all you want is
some throwaway Go code. It doesn't actually seem very complicated to me, I
must say.

On Tue, Mar 30, 2021 at 1:52 AM Rich  wrote:

> I really WANT to use go modules on all my projects, but there are times I
> just want to write a quick piece of code that I can 'go run'. Its usually
> just 20 lines, just used to test something out like a rest call to an
> internal server (can't do that on go playground) and for me go modules just
> makes it more complex. So what I do is what Reto stated above, set an
> environment variable for GO111MODULE=OFF.  Now at the command line I can
> write a quick code sample and just type 'go run sample.go' and it runs.
> For my projects where I want go modules I use a Make file:
>
> GO111MODULE=on GOOS=linux GOARCH=amd64 go build $(compilerFlag) -o
> mygoproject mygoproject.go othergofiles.go...
>
>
>
> On Monday, March 29, 2021 at 12:33:57 AM UTC-4 amits...@gmail.com wrote:
>
>> On Mon, Mar 29, 2021 at 12:15 PM Reto  wrote:
>> >
>> > On Mon, Mar 29, 2021 at 11:18:28AM +1100, Amit Saha wrote:
>> > > "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 GO111MODULE
>> to
>> > > auto. "
>> > > Is that implying the above behavior?
>> >
>> > Yes: https://golang.org/ref/mod#mod-commands
>> >
>> > Note that you can still run the hello world programs via `go run`
>> without
>> > having a module.
>>
>> Thanks.
>>
>> >
>> > --
>> > 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/20210329011453.3dddpz3syc6wv636%40feather.localdomain.
>>
>>
> --
> 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/c62dd3f2-da7f-494a-8bdc-f7c7f1c4b308n%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/CAEkBMfGk52HwKmX3Oj_%2B5yiCi%3Dk6VTvihi4rBbqSdXr1M67UCw%40mail.gmail.com.

Re: [go-nuts] Go 1.16 and modules

[Rich]

I really WANT to use go modules on all my projects, but there are times I 
just want to write a quick piece of code that I can 'go run'. Its usually 
just 20 lines, just used to test something out like a rest call to an 
internal server (can't do that on go playground) and for me go modules just 
makes it more complex. So what I do is what Reto stated above, set an 
environment variable for GO111MODULE=OFF.  Now at the command line I can 
write a quick code sample and just type 'go run sample.go' and it runs.  
For my projects where I want go modules I use a Make file:

GO111MODULE=on GOOS=linux GOARCH=amd64 go build $(compilerFlag) -o 
mygoproject mygoproject.go othergofiles.go...

   

On Monday, March 29, 2021 at 12:33:57 AM UTC-4 amits...@gmail.com wrote:

> On Mon, Mar 29, 2021 at 12:15 PM Reto  wrote:
> >
> > On Mon, Mar 29, 2021 at 11:18:28AM +1100, Amit Saha wrote:
> > > "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 GO111MODULE to
> > > auto. "
> > > Is that implying the above behavior?
> >
> > Yes: https://golang.org/ref/mod#mod-commands
> >
> > Note that you can still run the hello world programs via `go run` without
> > having a module.
>
> Thanks.
>
> >
> > --
> > 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/20210329011453.3dddpz3syc6wv636%40feather.localdomain
> .
>

-- 
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/c62dd3f2-da7f-494a-8bdc-f7c7f1c4b308n%40googlegroups.com.

Re: [go-nuts] How to wait for HTTP server to start?

[roger peppe]

I often call net.Listen directly before calling Serve in a goroutine. That
way you can connect to the server's socket immediately even though the
server might take a while to get around to serving the request.

Look at how net/http/httptest does it.

On Sat, 27 Mar 2021, 14:13 cpu...@gmail.com,  wrote:

> The typical Go tutorials pattern for starting a server is something like
>
> log.Fatal(http.ListenAndServe(":8080"))
>
> But what if the application needs to do other things after the server is
> started? It seems there is virtually no method to wait for the server
> actually start listening to requests?
>
> I'm probably missing something and would appreciate a hint.
>
> Thanks,
> Andi
>
> --
> 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/a40222e3-e4b3-4996-8232-045fcff43b77n%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/CAJhgaciragnS9HXQ%3Dy4MbKGDQD2k2S9ADwQt7eh9y%3DBgLJ1Ccw%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

On Mon, Mar 29, 2021, 17:46 Wojciech S. Czarnecki  wrote:

> Dnia 2021-03-29, o godz. 15:17:42
> "'Axel Wagner' via golang-nuts"  napisał(a):
>
> > I still don't understand how you think we should provide this
> explanation without solving SAT.
> ...
> > What is "builtconstraint_1" and how is it determined by the go tool? My
> > first impression was that it is supposed to be a build tag (like "cgo"),
> > which opens up the problems I asked - it's not clear which tag is "at
> > fault" or how to figure that out.
>
> As I understood the OP, it would be nice to have build -n and -v messaging
> us
> with short info about the constraint that excluded given file from under
> build.
>
> And I concur.
>

Since the build constraint language is equivalent to a first order logic
language, no guaranteed useful information can be provided in the general
case in a limited time.
I also thought that predicates would be useful, but only the terms in a
normal form could be useful, but that would provide - most probably - "too
much".

grep should be good enough :)

-- 
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%2BctqrrA32J2UhZYoQL5qsJ4Op3UXFaPZQfv1%3DwjgYJ3QkeXaw%40mail.gmail.com.

Re: [go-nuts] How to wait for HTTP server to start?

[Jesper Louis Andersen]

On Sat, Mar 27, 2021 at 3:19 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The best way to do it is probably by making an HTTP request and see if it
> succeeds. In production, it's always a good idea to have a health check
> endpoint anyways. So some service manager can check if it's alive and
> restart it if necessary. Or so that a load balancer doesn't send traffic
> until the service is healthy.
>

In addition, if a server relies on other parts/systems to work, you can end
up in a situation where those parts fail, but the server doesn't. This
means it is hard to have a "barrier" in the program after which something
is safe to start, since that assumption might fail later on when the
program is running. It's yet another argument why Alex' suggestion of
having a health check is beneficial. You can fail and report why you don't
provide service right now (I need access to a database, but it's timing
out, etc...). Systems which can analyze their own state and report back on
known errors are far easier to maintain.

-- 
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/CAGrdgiWApvJv3RkRR%3DMWxE7-T-Woq6FY0qq%3Dd9TsGSbfec4H2A%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[Wojciech S. Czarnecki]

Dnia 2021-03-29, o godz. 15:17:42
"'Axel Wagner' via golang-nuts"  napisał(a):

> I still don't understand how you think we should provide this explanation 
> without solving SAT.
... 
> What is "builtconstraint_1" and how is it determined by the go tool? My
> first impression was that it is supposed to be a build tag (like "cgo"),
> which opens up the problems I asked - it's not clear which tag is "at
> fault" or how to figure that out.

As I understood the OP, it would be nice to have build -n and -v messaging us
with short info about the constraint that excluded given file from under build.

And I concur.

-- 
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/20210329174615.2aeb6dc9%40xmint.

Re: [go-nuts] what is asm6 and span6 for?

[Andy Balholm]

It is likely a code for GOARCH=amd64. Back in the distant past, there 
were separate Go compilers for different CPU architectures. The one for 
amd64 was 6g, for 386 it was 8g, etc.


It looks like the x86 directory is code that was originally written for 
amd64, and then generalized to cover 386 as well.


Andy

On 3/29/21 7:45 AM, xie cui wrote:

https://github.com/golang/go/blob/master/src/cmd/internal/obj/x86/asm6.go
this file named asm6, and there is a func named span6, what is 6 for here?
--
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/a31873c7-15c3-4260-81b1-cec57ebe3867n%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/fa3389da-d69a-7ec2-a896-efa619a8ece3%40gmail.com.

[go-nuts] what is asm6 and span6 for?

[xie cui]

https://github.com/golang/go/blob/master/src/cmd/internal/obj/x86/asm6.go
this file named asm6, and there is a func named span6, what is 6 for here?

-- 
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/a31873c7-15c3-4260-81b1-cec57ebe3867n%40googlegroups.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

On 3/29/21, Axel Wagner  wrote:
> On Mon, Mar 29, 2021 at 2:57 PM  wrote:
...
> An "explanation" like I described in my 2nd email would be very
>> helpful and that isn't more complex than P. (If it is, please provide
>> a hint.)
>>
>
> I still don't understand how you think we should provide this explanation
> without solving SAT.
> For example, you write
>
> buildconstraint_1 excludes:
> file1.go
> file2.go
> file3.go
>
> What is "builtconstraint_1" and how is it determined by the go tool? My
> first impression was that it is supposed to be a build tag (like "cgo"),
> which opens up the problems I asked - it's not clear which tag is "at
> fault" or how to figure that out.
I assumed (ha!) buildconstraint_1 as a parsed predicate (e.g. "//
+build linux") would be helpful. In a more complex case it isn't.
Thanks again!

>
> Or even just the identified and relevant build constraints in CNF is
>> most probably enough to take a look at and go like nah, I can see
>> buildconstraintX and buildconstraintY, I can give up _quickly_ and not
>> waste _more_ time trying to get the package to build.
>>
>
> Sure. That's certainly easy enough to do. FWIW, currently you can get an
> approximation of that via
>
> grep -R "// +build" .
>
> After #41184  that would give an
> even clearer result, as the build constraints are actually guaranteed to be
> in DNF with at most one line per file (AIUI).
>
> It is certainly possible to build a version of this into the Go tool for go
> 1.17 already. That is, we could build in a command that just recursively
> looks for and parses build constraints and prints them out per-file in CNF
> or DNF. Personally, I feel like I would rarely use it though, because I'd
> find just a plain grep easier to remember, given that I use it daily. But
> my personal feelings shouldn't deter you from proposing this :)
agreed :)

Still the experience is very much non-go like, though with such a
power build constraint language it'll stay like that.

-- 
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%2Bctqrps942fEXSJF_LvJ11FWoQD%3DExkV-nqUr6pHyZDwYoYDw%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

['Axel Wagner' via golang-nuts]

On Mon, Mar 29, 2021 at 2:57 PM  wrote:

> Thanks, fully agree on everything.
>
> Please consider this workflow:
> 1. find package on pkg.go.dev (currently there is no build constraint
> specific information listed beside the result, cf. issue #39195)
> 2. get package (go get, git clone, cp etc.)
> 3. "build constraints exclude all Go files in ..."
> 4. wat? (pkg.go.dev did not "promise" this)
> 5. let's visit _each_file manually (or try to grep for some hints) to
> try to identify all failing build constraints and think about how to
> satisfy them or give up failing.
>
> Please also note, if step 1 or 2 or 3 provided more information on
> build constraints, the failing step 3 wouldn't be surprising. Now it
> is and I believe some tooling support (either in step 1, 2 or 3) would
> be helpful.
>

I agree. I'm not saying the problem is not worth solving and I'm not saying
we can't do *something* to try and address it. I just don't know what,
because I don't know an answer that seems "obviously right".

An "explanation" like I described in my 2nd email would be very
> helpful and that isn't more complex than P. (If it is, please provide
> a hint.)
>

I still don't understand how you think we should provide this explanation
without solving SAT.
For example, you write

buildconstraint_1 excludes:
file1.go
file2.go
file3.go

What is "builtconstraint_1" and how is it determined by the go tool? My
first impression was that it is supposed to be a build tag (like "cgo"),
which opens up the problems I asked - it's not clear which tag is "at
fault" or how to figure that out.

Or even just the identified and relevant build constraints in CNF is
> most probably enough to take a look at and go like nah, I can see
> buildconstraintX and buildconstraintY, I can give up _quickly_ and not
> waste _more_ time trying to get the package to build.
>

Sure. That's certainly easy enough to do. FWIW, currently you can get an
approximation of that via

grep -R "// +build" .

After #41184  that would give an
even clearer result, as the build constraints are actually guaranteed to be
in DNF with at most one line per file (AIUI).

It is certainly possible to build a version of this into the Go tool for go
1.17 already. That is, we could build in a command that just recursively
looks for and parses build constraints and prints them out per-file in CNF
or DNF. Personally, I feel like I would rarely use it though, because I'd
find just a plain grep easier to remember, given that I use it daily. But
my personal feelings shouldn't deter you from proposing this :)

If you agree the workflow above is not ideal, what do you think about
> the "build constraint explanation" or the build constraints in CNF?
>
> On 3/29/21, Axel Wagner  wrote:
> > FWIW, you might be assuming that a build tag always has the form `//
> +build
> > linux` or `// +build !cgo` - in which case it's indeed clear what the
> > "correct" answer is and how to determine it. But you can't assume that
> > build tags only take that form, you can express *any* boolean formula,
> > using any amount of variables with them.
> >
> > On Mon, Mar 29, 2021 at 12:47 PM Axel Wagner
> > 
> > wrote:
> >
> >> I might not understand what you are intending.
> >>
> >> My understanding is that you want, given a set of .go files, know "why"
> >> they are excluded. Which, to me, means finding a configuration of build
> >> tags that would allow at least one of them to be built. A file can be
> >> built
> >> with a set of tags, if the boolean formula expressed by the build
> >> constraints 
> evaluates
> >> to true. Therefore, determining why a file is excluded by a set of build
> >> tags is the boolean assignability problem.
> >>
> >> It is trivial, given a set of build tags, to find out if a given file
> >> builds. So, it is easy to say "this file does not build given the build
> >> tags I have". But it's NP-complete, to find out what build tags must be
> >> set
> >> for a file to build. So it's hard to say "this file does not build, but
> >> it
> >> *would* if I changed the build tags to that".
> >>
> >> It's even harder to determine what the "intuitively right" answer is.
> For
> >> example, a package might require cgo when built on Windows/arm, but not
> >> when built on Linux/amd64. So both the answer "you need cgo" and the
> >> answer
> >> "you need to amd64" would be correct, if you are trying to build on
> >> Windows/arm and it's not obvious which is correct. Or, a more trivial
> >> example: What about a build tag like `// +build foo,!foo`? Should the
> >> report say `foo` has to be set, or that it has to not be set, or do we
> >> need
> >> additional logic to detect cases like this?
> >>
> >> Again, none of this means we can't do *something*. But without a clear,
> >> efficient algorithm and without an obviously correct answer to
> >> ambiguities,
> >> we'd first have to decide on what we'd 

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Thanks, fully agree on everything.

Please consider this workflow:
1. find package on pkg.go.dev (currently there is no build constraint
specific information listed beside the result, cf. issue #39195)
2. get package (go get, git clone, cp etc.)
3. "build constraints exclude all Go files in ..."
4. wat? (pkg.go.dev did not "promise" this)
5. let's visit _each_file manually (or try to grep for some hints) to
try to identify all failing build constraints and think about how to
satisfy them or give up failing.

Please also note, if step 1 or 2 or 3 provided more information on
build constraints, the failing step 3 wouldn't be surprising. Now it
is and I believe some tooling support (either in step 1, 2 or 3) would
be helpful.

(I agree the answer to "what build tags must be set for a file to
build" is NP complete.)

An "explanation" like I described in my 2nd email would be very
helpful and that isn't more complex than P. (If it is, please provide
a hint.)

Or even just the identified and relevant build constraints in CNF is
most probably enough to take a look at and go like nah, I can see
buildconstraintX and buildconstraintY, I can give up _quickly_ and not
waste _more_ time trying to get the package to build.

If you agree the workflow above is not ideal, what do you think about
the "build constraint explanation" or the build constraints in CNF?

On 3/29/21, Axel Wagner  wrote:
> FWIW, you might be assuming that a build tag always has the form `// +build
> linux` or `// +build !cgo` - in which case it's indeed clear what the
> "correct" answer is and how to determine it. But you can't assume that
> build tags only take that form, you can express *any* boolean formula,
> using any amount of variables with them.
>
> On Mon, Mar 29, 2021 at 12:47 PM Axel Wagner
> 
> wrote:
>
>> I might not understand what you are intending.
>>
>> My understanding is that you want, given a set of .go files, know "why"
>> they are excluded. Which, to me, means finding a configuration of build
>> tags that would allow at least one of them to be built. A file can be
>> built
>> with a set of tags, if the boolean formula expressed by the build
>> constraints  evaluates
>> to true. Therefore, determining why a file is excluded by a set of build
>> tags is the boolean assignability problem.
>>
>> It is trivial, given a set of build tags, to find out if a given file
>> builds. So, it is easy to say "this file does not build given the build
>> tags I have". But it's NP-complete, to find out what build tags must be
>> set
>> for a file to build. So it's hard to say "this file does not build, but
>> it
>> *would* if I changed the build tags to that".
>>
>> It's even harder to determine what the "intuitively right" answer is. For
>> example, a package might require cgo when built on Windows/arm, but not
>> when built on Linux/amd64. So both the answer "you need cgo" and the
>> answer
>> "you need to amd64" would be correct, if you are trying to build on
>> Windows/arm and it's not obvious which is correct. Or, a more trivial
>> example: What about a build tag like `// +build foo,!foo`? Should the
>> report say `foo` has to be set, or that it has to not be set, or do we
>> need
>> additional logic to detect cases like this?
>>
>> Again, none of this means we can't do *something*. But without a clear,
>> efficient algorithm and without an obviously correct answer to
>> ambiguities,
>> we'd first have to decide on what we'd specifically like to do :)
>>
>> On Mon, Mar 29, 2021 at 12:29 PM  wrote:
>>
>>> Thanks for thinking about the issue!
>>> I should have asked for something more explicit, probably something like
>>> this:
>>> ; go build listconstraintexclusions
>>> buildconstraint_1 excludes:
>>> file1.go
>>> file2.go
>>> file3.go
>>> buildconstraint_2 excludes:
>>> file4.go
>>> file5.go
>>> No go files left to build.
>>> ;
>>>
>>> Iiuc the complexity of creating this list is in P.
>>> (I understand my original question was different.)
>>>
>>>
>>> On 3/29/21, Axel Wagner  wrote:
>>> > In general, answering that question is NP-complete. It's the boolean
>>> > satisfiability
>>> > problem
>>> > .
>>> It
>>> > would be possible to implement *some* solution and maybe stop after a
>>> > timeout or something. But even then, the answer will not be unique and
>>> > might sometimes be less than helpful.
>>> >
>>> > This doesn't mean we *can't* do it, but the problem is harder than it
>>> might
>>> > seem. You could file an issue (after searching if someone else
>>> suggested it
>>> > already, of course :) ).
>>> >
>>> > On Mon, Mar 29, 2021 at 10:49 AM  wrote:
>>> >
>>> >> Is there some functionality to list each build constraint that is not
>>> >> satisfied when the result of go get is "build constraints exclude all
>>> >> Go files in ..."?
>>> >>
>>> >> go mod why is very helpful when module dependencies are to be
>>> explained.
>>> 

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

[peterGo]

On Monday, March 29, 2021 at 8:32:53 AM UTC-4 peterGo wrote:

> You haven't said whether you followed the "safe" instructions for 
> github.com/ugorji/go/codec to avoid building code/helper_unsafe.go, which 
> uses go:linkname.
>
>
s/code/helper_unsafe.go/codec/helper_unsafe.go/

Peter

-- 
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/cb6ec6ca-c82e-4c9a-be47-751162ba7386n%40googlegroups.com.

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

[peterGo]

You haven't said whether you followed the "safe" instructions for 
github.com/ugorji/go/codec to avoid building code/helper_unsafe.go, which 
uses go:linkname.

Package Documentation for github.com/ugorji/go/codec
https://github.com/ugorji/go/blob/master/codec/README.md

This package will carefully use 'package unsafe' for performance reasons in 
specific places. You can build without unsafe use by passing the safe or 
appengine tag i.e. 'go install -tags=codec.safe 

You can run the tag 'codec.safe' to run tests or build in safe mode. e.g.

go test -tags codec.safe -run Json
go test -tags "alltests codec.safe" -run Suite

Peter

On Monday, March 29, 2021 at 3:34:44 AM UTC-4 f011...@gmail.com wrote:

> >  go:linkname to refer directly to functions that are defined but not 
> exported by the standard library. 
> > This is not supported and is likely to break with any new release. It 
> evidently breaks with GoLLVM.
>
> Thanks for your attention, but I tried to write a demo with go:linkname.
> In fact, it works well with gollvm...So maybe it is not the exact cause 
> for the problem
>
> Herei is my code:
>
> hello/hello.go
> ```
> package hello
>
> import (
> "fmt"
> _ "unsafe"
> )
> //go:linkname hellox hello.hellox
> func hellox(x string) {
> fmt.Println(x)
> }
> ```
>
> main.go
> ```
> package main
>
> import (
> _ "mypackage/hello"
> _ "unsafe"
> )
>
> //go:linkname hel hello.hellox
> func hel(x string)
>
> func main() {
> hel("aaa")
> //println("")
> }
> ```
>
> 在2021年3月29日星期一 UTC+8 上午12:37:49 写道：
>
>> On Sun, Mar 28, 2021 at 9:28 AM 张嘉熙  wrote: 
>> > 
>> > For s2-geojson, I meet: 
>> > ``` 
>> > # github.com/pantrif/s2-geojson/cmd/s2-geojson 
>> > 
>> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>>  
>> github_0com_1ugorji_1go_1codec.intf2impls.intf2impl: error: undefined 
>> reference to 'reflect.unsafe_New' 
>> > 
>> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>>  
>> github_0com_1ugorji_1go_1codec.Decoder.interfaceExtConvertAndDecode: error: 
>> undefined reference to 'reflect.unsafe_New' 
>> > decode.go:509: error: undefined reference to 'reflect.unsafe_New' 
>> > decode.go:14935: error: undefined reference to 'reflect.unsafe_New' 
>>
>> This is a problem with github.com/ugorji/go. The file 
>> code/helper_unsafe.go uses go:linkname to refer directly to functions 
>> that are defined but not exported by the standard library. This is 
>> not supported and is likely to break with any new release. It 
>> evidently breaks with GoLLVM. 
>>
>> 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/f12e94e5-9968-48fb-9ce6-d9899a3796e2n%40googlegroups.com.

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

['Than McIntosh' via golang-nuts]

Hi,

*>Thanks for your attention, but I tried to write a demo with go:linkname.*
*>In fact, it works well with gollvm...So maybe it is not the exact cause
for the problem*

The problem is not that gollvm fails to implement go:linkname-- the problem
is the way that this package (http://github.com/ugorji/go)  is using
go:linkname.

The Go runtime and standard library has a public, exported API; this sort
of use of go:linkname to reach into the internals of a standard package (in
this case, calling an unexported function) is not supported.

Folks who write such code should understand that it can break at any time
from release to release or across Go implementations.

Than




On Mon, Mar 29, 2021 at 3:35 AM JX Zhang  wrote:

> >  go:linkname to refer directly to functions that are defined but not
> exported by the standard library.
> > This is not supported and is likely to break with any new release. It
> evidently breaks with GoLLVM.
>
> Thanks for your attention, but I tried to write a demo with go:linkname.
> In fact, it works well with gollvm...So maybe it is not the exact cause
> for the problem
>
> Herei is my code:
>
> hello/hello.go
> ```
> package hello
>
> import (
> "fmt"
> _ "unsafe"
> )
> //go:linkname hellox hello.hellox
> func hellox(x string) {
> fmt.Println(x)
> }
> ```
>
> main.go
> ```
> package main
>
> import (
> _ "mypackage/hello"
> _ "unsafe"
> )
>
> //go:linkname hel hello.hellox
> func hel(x string)
>
> func main() {
> hel("aaa")
> //println("")
> }
> ```
>
> 在2021年3月29日星期一 UTC+8 上午12:37:49 写道：
>
>> On Sun, Mar 28, 2021 at 9:28 AM 张嘉熙  wrote:
>> >
>> > For s2-geojson, I meet:
>> > ```
>> > # github.com/pantrif/s2-geojson/cmd/s2-geojson
>> >
>> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>> github_0com_1ugorji_1go_1codec.intf2impls.intf2impl: error: undefined
>> reference to 'reflect.unsafe_New'
>> >
>> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>> github_0com_1ugorji_1go_1codec.Decoder.interfaceExtConvertAndDecode: error:
>> undefined reference to 'reflect.unsafe_New'
>> > decode.go:509: error: undefined reference to 'reflect.unsafe_New'
>> > decode.go:14935: error: undefined reference to 'reflect.unsafe_New'
>>
>> This is a problem with github.com/ugorji/go. The file
>> code/helper_unsafe.go uses go:linkname to refer directly to functions
>> that are defined but not exported by the standard library. This is
>> not supported and is likely to break with any new release. It
>> evidently breaks with GoLLVM.
>>
>> 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/5d763cdf-1147-4abe-aea7-9f6efa39e930n%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%2BUr55H4Q4%2BoztZjm3ZcrsFdQ-gBvy_V9WE%3D-Y3CnoTHWLFuqg%40mail.gmail.com.

[go-nuts] Re: How to stream across json-seq RFC-7464

[Sean Liao]

If you can guarantee your input is always pretty printed like that, you 
could use bufio with a custom splitfunc to match `\n{`, no need to double 
parse json

On Sunday, March 28, 2021 at 11:35:20 PM UTC+2 greg.sa...@gmail.com wrote:

>
> I've tried this suggestion and although its certainly a bit more 
> refactoring then I expected - the outcome looks to be exactly as you 
> described here.
>
> Thank you so much for the suggestion, take a bow!
>
> - Greg
>
>
> On Sunday, March 28, 2021 at 12:15:34 PM UTC-7 Brian Candler wrote:
>
>> No, it's even simpler than that:
>>
>> * The first call to decoder.Decode() will return the first object in the 
>> stream.
>> * The second call to decoder.Decode() will return the second object in 
>> the stream.
>> * And so on...
>>
>> By "object" I mean top-level object: everything between the opening "{" 
>> and its matching closing "}", including all its nested values.  (Define a 
>> struct which contains all the nested attributes, for it to be deserialized 
>> into).
>>
>> If an io.Reader stream consists of a series of separate JSON objects - as 
>> yours does - then you get one object at a time.  They don't have to be 
>> separated by whitespace or newlines, but they can be.
>>
>> Don't think about seeking.  I don't know the internals of 
>> decoder.Decode(), but I would expect that it reads in chunks from the 
>> io.Reader.  This means it will likely overshoot the object boundaries, but 
>> will buffer the excess and process it on the next call to Decode.
>>
>

-- 
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/d813c500-bde7-4df3-a623-f179ff02ceaan%40googlegroups.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

['Axel Wagner' via golang-nuts]

FWIW, you might be assuming that a build tag always has the form `// +build
linux` or `// +build !cgo` - in which case it's indeed clear what the
"correct" answer is and how to determine it. But you can't assume that
build tags only take that form, you can express *any* boolean formula,
using any amount of variables with them.

On Mon, Mar 29, 2021 at 12:47 PM Axel Wagner 
wrote:

> I might not understand what you are intending.
>
> My understanding is that you want, given a set of .go files, know "why"
> they are excluded. Which, to me, means finding a configuration of build
> tags that would allow at least one of them to be built. A file can be built
> with a set of tags, if the boolean formula expressed by the build
> constraints  evaluates
> to true. Therefore, determining why a file is excluded by a set of build
> tags is the boolean assignability problem.
>
> It is trivial, given a set of build tags, to find out if a given file
> builds. So, it is easy to say "this file does not build given the build
> tags I have". But it's NP-complete, to find out what build tags must be set
> for a file to build. So it's hard to say "this file does not build, but it
> *would* if I changed the build tags to that".
>
> It's even harder to determine what the "intuitively right" answer is. For
> example, a package might require cgo when built on Windows/arm, but not
> when built on Linux/amd64. So both the answer "you need cgo" and the answer
> "you need to amd64" would be correct, if you are trying to build on
> Windows/arm and it's not obvious which is correct. Or, a more trivial
> example: What about a build tag like `// +build foo,!foo`? Should the
> report say `foo` has to be set, or that it has to not be set, or do we need
> additional logic to detect cases like this?
>
> Again, none of this means we can't do *something*. But without a clear,
> efficient algorithm and without an obviously correct answer to ambiguities,
> we'd first have to decide on what we'd specifically like to do :)
>
> On Mon, Mar 29, 2021 at 12:29 PM  wrote:
>
>> Thanks for thinking about the issue!
>> I should have asked for something more explicit, probably something like
>> this:
>> ; go build listconstraintexclusions
>> buildconstraint_1 excludes:
>> file1.go
>> file2.go
>> file3.go
>> buildconstraint_2 excludes:
>> file4.go
>> file5.go
>> No go files left to build.
>> ;
>>
>> Iiuc the complexity of creating this list is in P.
>> (I understand my original question was different.)
>>
>>
>> On 3/29/21, Axel Wagner  wrote:
>> > In general, answering that question is NP-complete. It's the boolean
>> > satisfiability
>> > problem .
>> It
>> > would be possible to implement *some* solution and maybe stop after a
>> > timeout or something. But even then, the answer will not be unique and
>> > might sometimes be less than helpful.
>> >
>> > This doesn't mean we *can't* do it, but the problem is harder than it
>> might
>> > seem. You could file an issue (after searching if someone else
>> suggested it
>> > already, of course :) ).
>> >
>> > On Mon, Mar 29, 2021 at 10:49 AM  wrote:
>> >
>> >> Is there some functionality to list each build constraint that is not
>> >> satisfied when the result of go get is "build constraints exclude all
>> >> Go files in ..."?
>> >>
>> >> go mod why is very helpful when module dependencies are to be
>> explained.
>> >> A similar functionality would be helpful and maybe a message to refer
>> >> to this functionality when "build constraints exclude all Go files in
>> >> ..." is the conclusion.
>> >>
>> >> (For a random package I've found on pkg.go.dev it took a few confusing
>> >> minutes until I realized that cgo requirement is the build
>> >> constraint.)
>> >>
>> >> On a tangential note: would anybody else be interested to help with
>> >> issue https://github.com/golang/go/issues/39195 ? (Probably all build
>> >> constraints should be searchable.)
>> >>
>> >> --
>> >> 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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%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/CAEkBMfGvyTKAMzJS7bsRmkzcMqm00FYFTD67BD2UQSfvpUpHNg%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

['Axel Wagner' via golang-nuts]

I might not understand what you are intending.

My understanding is that you want, given a set of .go files, know "why"
they are excluded. Which, to me, means finding a configuration of build
tags that would allow at least one of them to be built. A file can be built
with a set of tags, if the boolean formula expressed by the build
constraints  evaluates to
true. Therefore, determining why a file is excluded by a set of build tags
is the boolean assignability problem.

It is trivial, given a set of build tags, to find out if a given file
builds. So, it is easy to say "this file does not build given the build
tags I have". But it's NP-complete, to find out what build tags must be set
for a file to build. So it's hard to say "this file does not build, but it
*would* if I changed the build tags to that".

It's even harder to determine what the "intuitively right" answer is. For
example, a package might require cgo when built on Windows/arm, but not
when built on Linux/amd64. So both the answer "you need cgo" and the answer
"you need to amd64" would be correct, if you are trying to build on
Windows/arm and it's not obvious which is correct. Or, a more trivial
example: What about a build tag like `// +build foo,!foo`? Should the
report say `foo` has to be set, or that it has to not be set, or do we need
additional logic to detect cases like this?

Again, none of this means we can't do *something*. But without a clear,
efficient algorithm and without an obviously correct answer to ambiguities,
we'd first have to decide on what we'd specifically like to do :)

On Mon, Mar 29, 2021 at 12:29 PM  wrote:

> Thanks for thinking about the issue!
> I should have asked for something more explicit, probably something like
> this:
> ; go build listconstraintexclusions
> buildconstraint_1 excludes:
> file1.go
> file2.go
> file3.go
> buildconstraint_2 excludes:
> file4.go
> file5.go
> No go files left to build.
> ;
>
> Iiuc the complexity of creating this list is in P.
> (I understand my original question was different.)
>
>
> On 3/29/21, Axel Wagner  wrote:
> > In general, answering that question is NP-complete. It's the boolean
> > satisfiability
> > problem .
> It
> > would be possible to implement *some* solution and maybe stop after a
> > timeout or something. But even then, the answer will not be unique and
> > might sometimes be less than helpful.
> >
> > This doesn't mean we *can't* do it, but the problem is harder than it
> might
> > seem. You could file an issue (after searching if someone else suggested
> it
> > already, of course :) ).
> >
> > On Mon, Mar 29, 2021 at 10:49 AM  wrote:
> >
> >> Is there some functionality to list each build constraint that is not
> >> satisfied when the result of go get is "build constraints exclude all
> >> Go files in ..."?
> >>
> >> go mod why is very helpful when module dependencies are to be explained.
> >> A similar functionality would be helpful and maybe a message to refer
> >> to this functionality when "build constraints exclude all Go files in
> >> ..." is the conclusion.
> >>
> >> (For a random package I've found on pkg.go.dev it took a few confusing
> >> minutes until I realized that cgo requirement is the build
> >> constraint.)
> >>
> >> On a tangential note: would anybody else be interested to help with
> >> issue https://github.com/golang/go/issues/39195 ? (Probably all build
> >> constraints should be searchable.)
> >>
> >> --
> >> 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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%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/CAEkBMfFHTz8Q1CaF3NiQo4bZYzYBr5AMmTqFCw%2Bov2tLFcLvZA%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Thanks for thinking about the issue!
I should have asked for something more explicit, probably something like this:
; go build listconstraintexclusions
buildconstraint_1 excludes:
file1.go
file2.go
file3.go
buildconstraint_2 excludes:
file4.go
file5.go
No go files left to build.
;

Iiuc the complexity of creating this list is in P.
(I understand my original question was different.)


On 3/29/21, Axel Wagner  wrote:
> In general, answering that question is NP-complete. It's the boolean
> satisfiability
> problem . It
> would be possible to implement *some* solution and maybe stop after a
> timeout or something. But even then, the answer will not be unique and
> might sometimes be less than helpful.
>
> This doesn't mean we *can't* do it, but the problem is harder than it might
> seem. You could file an issue (after searching if someone else suggested it
> already, of course :) ).
>
> On Mon, Mar 29, 2021 at 10:49 AM  wrote:
>
>> Is there some functionality to list each build constraint that is not
>> satisfied when the result of go get is "build constraints exclude all
>> Go files in ..."?
>>
>> go mod why is very helpful when module dependencies are to be explained.
>> A similar functionality would be helpful and maybe a message to refer
>> to this functionality when "build constraints exclude all Go files in
>> ..." is the conclusion.
>>
>> (For a random package I've found on pkg.go.dev it took a few confusing
>> minutes until I realized that cgo requirement is the build
>> constraint.)
>>
>> On a tangential note: would anybody else be interested to help with
>> issue https://github.com/golang/go/issues/39195 ? (Probably all build
>> constraints should be searchable.)
>>
>> --
>> 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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%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/CA%2BctqrrBXbCkJSnTLHYggTv8k%2BhJ6FgDnun%3DFrYNRoM6kCKx2w%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

['Axel Wagner' via golang-nuts]

In general, answering that question is NP-complete. It's the boolean
satisfiability
problem . It
would be possible to implement *some* solution and maybe stop after a
timeout or something. But even then, the answer will not be unique and
might sometimes be less than helpful.

This doesn't mean we *can't* do it, but the problem is harder than it might
seem. You could file an issue (after searching if someone else suggested it
already, of course :) ).

On Mon, Mar 29, 2021 at 10:49 AM  wrote:

> Is there some functionality to list each build constraint that is not
> satisfied when the result of go get is "build constraints exclude all
> Go files in ..."?
>
> go mod why is very helpful when module dependencies are to be explained.
> A similar functionality would be helpful and maybe a message to refer
> to this functionality when "build constraints exclude all Go files in
> ..." is the conclusion.
>
> (For a random package I've found on pkg.go.dev it took a few confusing
> minutes until I realized that cgo requirement is the build
> constraint.)
>
> On a tangential note: would anybody else be interested to help with
> issue https://github.com/golang/go/issues/39195 ? (Probably all build
> constraints should be searchable.)
>
> --
> 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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%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/CAEkBMfE-UfRCPvS046CNbMSpoaVOEvwf2Y-_83UuSaS%3DvxpUpA%40mail.gmail.com.

Re: [go-nuts] Re: error in testcode

[Brian Candler]

Sorry, but that is not a complete, self-contained piece of code that I can 
run.

-- 
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/00be17d4-2108-4690-a06d-ee04ab953630n%40googlegroups.com.

[go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Is there some functionality to list each build constraint that is not
satisfied when the result of go get is "build constraints exclude all
Go files in ..."?

go mod why is very helpful when module dependencies are to be explained.
A similar functionality would be helpful and maybe a message to refer
to this functionality when "build constraints exclude all Go files in
..." is the conclusion.

(For a random package I've found on pkg.go.dev it took a few confusing
minutes until I realized that cgo requirement is the build
constraint.)

On a tangential note: would anybody else be interested to help with
issue https://github.com/golang/go/issues/39195 ? (Probably all build
constraints should be searchable.)

-- 
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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%40mail.gmail.com.

Re: [go-nuts] Re: error in testcode

[Dr. Lincy Jim]

I did

func TestProvisionhistory(t *testing.T) {

type fields struct {

StatusStatus

Type  BookingType

Updated   time.Time

History   []BookingHistory



}

type args struct {

b *Booking

}

tests := []struct {

name   string

fields fields

args   args

for _, tt := range tests {

t.Run(tt.name, func(t *testing.T) {
bl := {
Status:tt.fields.Status}
if bl.Status == StatusExpired && bl.Status != StatusCancelled {

t.Error("expecting status of bookinglisting to be active")

}



bl.provisionHistory(tt.args.b)

})

}
}

now i am getting  ok in the terminal

is this all that is required from writing If b1.status test code

Thanks and Regards/-
*Dr.Lincy Elizebeth Jim,*



On Mon, Mar 29, 2021 at 6:20 PM Brian Candler  wrote:

> Can you make a complete, runnable example which demonstrates the problem,
> on play.golang.org, and post the link here?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/gxtF2eEzjLI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/dabb8639-fec8-4c28-bab2-9d4484dd7716n%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/CAMcLrA85rraSxLuw7CnF4gg1nphqOhu%3D%3DNm68DzQWG_oh8XU0Q%40mail.gmail.com.

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

[JX Zhang]

>  go:linkname to refer directly to functions that are defined but not 
exported by the standard library. 
> This is not supported and is likely to break with any new release. It 
evidently breaks with GoLLVM.

Thanks for your attention, but I tried to write a demo with go:linkname.
In fact, it works well with gollvm...So maybe it is not the exact cause for 
the problem

Herei is my code:

hello/hello.go
```
package hello

import (
"fmt"
_ "unsafe"
)
//go:linkname hellox hello.hellox
func hellox(x string) {
fmt.Println(x)
}
```

main.go
```
package main

import (
_ "mypackage/hello"
_ "unsafe"
)

//go:linkname hel hello.hellox
func hel(x string)

func main() {
hel("aaa")
//println("")
}
```

在2021年3月29日星期一 UTC+8 上午12:37:49 写道：

> On Sun, Mar 28, 2021 at 9:28 AM 张嘉熙  wrote:
> >
> > For s2-geojson, I meet:
> > ```
> > # github.com/pantrif/s2-geojson/cmd/s2-geojson
> > 
> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>  
> github_0com_1ugorji_1go_1codec.intf2impls.intf2impl: error: undefined 
> reference to 'reflect.unsafe_New'
> > 
> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>  
> github_0com_1ugorji_1go_1codec.Decoder.interfaceExtConvertAndDecode: error: 
> undefined reference to 'reflect.unsafe_New'
> > decode.go:509: error: undefined reference to 'reflect.unsafe_New'
> > decode.go:14935: error: undefined reference to 'reflect.unsafe_New'
>
> This is a problem with github.com/ugorji/go. The file
> code/helper_unsafe.go uses go:linkname to refer directly to functions
> that are defined but not exported by the standard library. This is
> not supported and is likely to break with any new release. It
> evidently breaks with GoLLVM.
>
> 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/5d763cdf-1147-4abe-aea7-9f6efa39e930n%40googlegroups.com.

[go-nuts] Re: error in testcode

[Brian Candler]

Can you make a complete, runnable example which demonstrates the problem, 
on play.golang.org, and post the link here?

-- 
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/dabb8639-fec8-4c28-bab2-9d4484dd7716n%40googlegroups.com.

[go-nuts] error in testcode

[Dr. Lincy Jim]

Hi all,

I have included the following lines of code
if b.ConsentProvided {
var t string
if bl.Status != StatusExpired && bl.Status != StatusCancelled {

t = fmt.Sprintf("Consent to share information by %s", 
bl.RequestedBy) //lchangetest1
if len(bl.RequestedBy) == 0 {
t = "Consent to share information"

}

} else {
t = "Consent to share information"
}
how to write a test code for this 

I wrote
func TestProvisionhistory(t *testing.T) {
bl := BookingListing {
Status:"Expired"}
var thh = b1.provisionHistory(t.Booking)

if thh.Status != StatusExpired && thh.Status != StatusCancelled {
t.Error("Fail")
} else {
t.Error("True")
}
Booking listing is a struct

What am  I doing wrong?

thanking 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/f09f16a0-5718-4d19-8f37-ba1eaabc723dn%40googlegroups.com.