Re: [go-nuts] [gollvm] compiling error of libgo/runtime/aeshash.c on ARM

[xiangdong...@gmail.com]

Thanks a lot, Ian, I can build it with clang now with a few minor changes. 
 
On Tuesday, July 16, 2019 at 5:40:24 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Jul 15, 2019 at 7:39 AM Xiangdong Ji  > wrote: 
> > 
> > I am trying to build gollvm on ARM with a few experimental changes, 
> looks like some ARM Neon intrinsics in 
> > libgo/runtime/aeshash.c are not supported by GCC 7/8, wondering if it 
> could be solved by any additional compile 
> > options, or should the latest gcc-9 or clang be used? 
>
> The arm64 support in aeshash.c was added in GCC 9.  In general there 
> is no expectation that the files in GCC 9 can be compiled by earlier 
> versions of GCC.  Many times it will work, but not always, and this 
> may be a case where it fails (I haven't checked).  It's not feasible 
> for us to ensure that files distributed with GCC 9 can be compiled by 
> earlier versions of GCC. 
>
> In any case, if your goal is to build GoLLVM, then you should be 
> compiling this file with clang.  And it sounds like you can do that. 
> So there doesn't seem to be much reason to compile it with GCC.  I 
> understand that you are having trouble building GoLLVM, but it's not 
> clear to me why building this file with GCC rather than clang will 
> help with that. 
>
> 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/acc6b2b7-4998-4059-aa75-bc5cf7c5fc8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [gollvm] compiling error of libgo/runtime/aeshash.c on ARM

[xiangdong...@gmail.com]

Hi Ian,

Could you please share some code pointers or documents about how 'go' 
functions calling 'c' functions is implemented,
I'm looking into the following function 
at gofrontend/libgo/go/bytes/bytes.go:102, where c-function IndexByte in 
bytealg.c/bytealg.c:90
is called but with wrong argument bindings, the issue is sort of expected 
as a bunch of changes on arm are not in place now.
Thanks a lot. 

// IndexByte returns the index of the first instance of c in b, or -1 if c 
is not present in b.
func IndexByte(b []byte, c byte) int {
return bytealg.IndexByte(b, c)
}


On Tuesday, July 16, 2019 at 5:40:24 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Jul 15, 2019 at 7:39 AM Xiangdong Ji  > wrote: 
> > 
> > I am trying to build gollvm on ARM with a few experimental changes, 
> looks like some ARM Neon intrinsics in 
> > libgo/runtime/aeshash.c are not supported by GCC 7/8, wo

 

> ndering if it could be solved by any additional compile 
> > options, or should the latest gcc-9 or clang be used? 
>
> The arm64 support in aeshash.c was added in GCC 9.  In general there 
> is no expectation that the files in GCC 9 can be compiled by earlier 
> versions of GCC.  Many times it will work, but not always, and this 
> may be a case where it fails (I haven't checked).  It's not feasible 
> for us to ensure that files distributed with GCC 9 can be compiled by 
> earlier versions of GCC. 
>
> In any case, if your goal is to build GoLLVM, then you should be 
> compiling this file with clang.  And it sounds like you can do that. 
> So there doesn't seem to be much reason to compile it with GCC.  I 
> understand that you are having trouble building GoLLVM, but it's not 
> clear to me why building this file with GCC rather than clang will 
> help with that. 
>
> 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/954aea89-c6ad-422a-9599-47336f0bec53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [gollvm] compiling error of libgo/runtime/aeshash.c on ARM

[xiangdong...@gmail.com]

Hi Than,

Thank you for the prompt reply, my apologies for not being descriptive of 
the context. 
Yes, it's a gollvm-compiled program on arm and we just started 
investigating the ABI part, I'm wondering if any documents about go's 
internals are available to help understand it and related areas more 
deeply. 

On Wednesday, July 17, 2019 at 12:12:54 AM UTC+8, Than McIntosh wrote:
>
> Hi,
>
> Just to make sure I understand the context for the question -- this is a 
> gollvm-compiled program that you are talking about, not something compiled 
> with the main Go compiler?
>
> If so, then there isn't anything special happening when Go calls into C, 
> both will share the same ABI / calling convention. 
>
> Also wanted to make sure you are aware that for Gollvm to work on Arm, the 
> compiler has to implement the ARM C ABI properly (which at the moment is 
> not implemented). See this thread for context:
>
> https://groups.google.com/d/msg/golang-nuts/Tf0BOTtEpOs/0Wdol4pMDgAJ
>
> Cheers, Than
>
>
> On Tue, Jul 16, 2019 at 12:01 PM xiang...@gmail.com  <
> xiang...@gmail.com > wrote:
>
>> Hi Ian,
>>
>> Could you please share some code pointers or documents about how 'go' 
>> functions calling 'c' functions is implemented,
>> I'm looking into the following function 
>> at gofrontend/libgo/go/bytes/bytes.go:102, where c-function IndexByte in 
>> bytealg.c/bytealg.c:90
>> is called but with wrong argument bindings, the issue is sort of expected 
>> as a bunch of changes on arm are not in place now.
>> Thanks a lot. 
>> 
>> // IndexByte returns the index of the first instance of c in b, or -1 if 
>> c is not present in b.
>> func IndexByte(b []byte, c byte) int {
>> return bytealg.IndexByte(b, c)
>> }
>>
>>
>> On Tuesday, July 16, 2019 at 5:40:24 AM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Mon, Jul 15, 2019 at 7:39 AM Xiangdong Ji  
>>> wrote: 
>>> > 
>>> > I am trying to build gollvm on ARM with a few experimental changes, 
>>> looks like some ARM Neon intrinsics in 
>>> > libgo/runtime/aeshash.c are not supported by GCC 7/8, wo
>>
>>  
>>
>>> ndering if it could be solved by any additional compile 
>>> > options, or should the latest gcc-9 or clang be used? 
>>>
>>> The arm64 support in aeshash.c was added in GCC 9.  In general there 
>>> is no expectation that the files in GCC 9 can be compiled by earlier 
>>> versions of GCC.  Many times it will work, but not always, and this 
>>> may be a case where it fails (I haven't checked).  It's not feasible 
>>> for us to ensure that files distributed with GCC 9 can be compiled by 
>>> earlier versions of GCC. 
>>>
>>> In any case, if your goal is to build GoLLVM, then you should be 
>>> compiling this file with clang.  And it sounds like you can do that. 
>>> So there doesn't seem to be much reason to compile it with GCC.  I 
>>> understand that you are having trouble building GoLLVM, but it's not 
>>> clear to me why building this file with GCC rather than clang will 
>>> help with that. 
>>>
>>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/954aea89-c6ad-422a-9599-47336f0bec53%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/1559c121-67db-402c-a8be-6674645cfdb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Any way to print a 'struct g' within delve/gdb

[xiangdong...@gmail.com]

Hi Derek,

Say I have the pointer value of a specific G struct, how to convert it to 
'struct g' (or any other form) in delve so that I can check 
the details of its fields?

For example (simply utilized runtime.m0.curg to get a pointer value here)

(dlv) p &runtime.m0.curg
(**runtime.g)(0x56a140)

Just tried a few commands to convert the value back to 'struct g' or a 
pointer to 'struct g'

(dlv) p (runtime.g*)(0x56b140)
Command failed: 1:12: expected operand, found ')'
(dlv) p ('runtime.g'*)(0x56b140)
Command failed: 1:2: illegal rune literal
(dlv) p ("runtime.g"*)(0x56b140)
Command failed: 1:14: expected operand, found ')'
(dlv) p ("runtime".g*)(0x56b140)
Command failed: 1:14: expected operand, found ')'

Thanks.
On Tuesday, November 12, 2019 at 2:28:12 AM UTC+8, Derek Parker wrote:
>
> Can you reply with a gist showing the exact Delve commands you are 
> attempting to use and what errors are being returned?
>
> There is some more information on the expression parser here 
> . 
> You can also open an issue on the Delve Github repo and we can help you out 
> over there as well.
>
> On Sunday, November 10, 2019 at 11:58:24 PM UTC-8, Xiangdong JI wrote:
>>
>> Given a valid goroutine structure's pointer, say retrieving from the 
>> register 'g', how can I convert it to 'struct g' in delve or gdb?
>>
>> gdb usually reports "A syntax error in expression ...", and delve issues 
>> various "Command failed" message (failed to figure the proper way of 
>> converting a literal, I guess).
>>
>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/79996295-2b84-4ddc-93fe-22f826564d04%40googlegroups.com.

Re: [go-nuts] How to clean cache for 'go tool dist test'

[xiangdong...@gmail.com]

I always got a timeout when running all.bash (synced to the latest commit 
cbd421f75b0770c3534d1b641e7770bf1878004f),
it's not reproducible with 'go test -run=. crypto/tls', no GOARCH and GOOS 
were set previously. Thanks.


*02:58:18* panic: test timed out after 9m0s*02:58:18* *02:58:18* goroutine 474 
[running]:*02:58:18* testing.(*M).startAlarm.func1()*02:58:18*   
/home/root/ci-scripts/golang/src/testing/testing.go:1492 +0xc8*02:58:18* 
created by time.goFunc*02:58:18*   
/home/root/ci-scripts/golang/src/time/sleep.go:169 +0x40*02:58:18* *02:58:18* 
goroutine 1 [chan receive, 8 minutes]:*02:58:18* testing.(*T).Run(0x4000592000, 
0x353e41, 0x11, 0x3742c8, 0x5e73be01)*02:58:18*   
/home/root/ci-scripts/golang/src/testing/testing.go:1045 +0x2e0*02:58:18* 
testing.runTests.func1(0x40003ca360)*02:58:18*
/home/root/ci-scripts/golang/src/testing/testing.go:1313 +0x74*02:58:18* 
testing.tRunner(0x40003ca360, 0x40008e1c48)*02:58:18*  
/home/root/ci-scripts/golang/src/testing/testing.go:993 +0xdc*02:58:18* 
testing.runTests(0x40008e2360, 0x612880, 0x87, 0x87, 0xbf950e12a0c70f0b, 
0x7dbd29bde6, 0x6167a0, 0x0)*02:58:18* 
/home/root/ci-scripts/golang/src/testing/testing.go:1311 +0x294*02:58:18* 
testing.(*M).Run(0x40003f8180, 0x0)*02:58:18* 
/home/root/ci-scripts/golang/src/testing/testing.go:1221 +0x1b4*02:58:18* 
crypto/tls.runMain(0x40003f8180, 0x0)*02:58:18*   
/home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:389 
+0x55c*02:58:18* crypto/tls.TestMain(0x40003f8180)*02:58:18*  
/home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:335 
+0x8c*02:58:18* main.main()*02:58:18* _testmain.go:321 +0x160*02:58:18* 
*02:58:18* goroutine 246 [IO wait, 8 minutes]:*02:58:18* 
internal/poll.runtime_pollWait(0x5bccbf78, 0x72, 0x0)*02:58:18*  
/home/root/ci-scripts/golang/src/runtime/netpoll.go:203 +0x44*02:58:18* 
internal/poll.(*pollDesc).wait(0x40003f8218, 0x72, 0x0, 0x0, 
0x3505d4)*02:58:18*
/home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:87 
+0x38*02:58:18* internal/poll.(*pollDesc).waitRead(...)*02:58:18*  
/home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:92*02:58:18* 
internal/poll.(*FD).Accept(0x40003f8200, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0)*02:58:18*/home/root/ci-scripts/golang/src/internal/poll/fd_unix.go:384 
+0x184*02:58:18* net.(*netFD).accept(0x40003f8200, 0x37e11d600, 0x0, 
0x40003823b8)*02:58:18*  
/home/root/ci-scripts/golang/src/net/fd_unix.go:238 +0x2c*02:58:18* 
net.(*TCPListener).accept(0x4000853ae0, 0x400053dfa8, 0x1, 0x222884)*02:58:18*  
/home/root/ci-scripts/golang/src/net/tcpsock_posix.go:139 +0x2c*02:58:18* 
net.(*TCPListener).Accept(0x4000853ae0, 0x400053dfa8, 0x4000646020, 0x0, 
0x0)*02:58:18*   /home/root/ci-scripts/golang/src/net/tcpsock.go:261 
+0x5c*02:58:18* crypto/tls.localServer(0x3e0880, 0x4000853ae0)*02:58:18*
/home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:249 
+0x5c*02:58:18* created by crypto/tls.runMain*02:58:18*   
/home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:361 
+0x21c*02:58:18* *02:58:18* goroutine 411 [semacquire, 8 minutes]:*02:58:18* 
internal/poll.runtime_Semacquire(0x40003f85a8)*02:58:18* 
/home/root/ci-scripts/golang/src/runtime/sema.go:61 +0x38*02:58:18* 
internal/poll.(*FD).Close(0x40003f8580, 0x40003f8580, 0x0)*02:58:18*
/home/root/ci-scripts/golang/src/internal/poll/fd_unix.go:109 +0x84*02:58:18* 
net.(*netFD).Close(0x40003f8580, 0x0, 0x0)*02:58:18*  
/home/root/ci-scripts/golang/src/net/fd_unix.go:184 +0x48*02:58:18* 
net.(*conn).Close(0x410040, 0x0, 0x0)*02:58:18* 
/home/root/ci-scripts/golang/src/net/net.go:208 +0x58*02:58:18* 
crypto/tls.TestHostnameInSNI(0x4000592000)*02:58:18*
/home/root/ci-scripts/golang/src/crypto/tls/handshake_client_test.go:1349 
+0x264*02:58:18* testing.tRunner(0x4000592000, 0x3742c8)*02:58:18*
/home/root/ci-scripts/golang/src/testing/testing.go:993 +0xdc*02:58:18* created 
by testing.(*T).Run*02:58:18*   
/home/root/ci-scripts/golang/src/testing/testing.go:1044 +0x2c4*02:58:18* 
*02:58:18* goroutine 317 [IO wait, 8 minutes]:*02:58:18* 
internal/poll.runtime_pollWait(0x5bccbb18, 0x72, 
0x)*02:58:18*   
/home/root/ci-scripts/golang/src/runtime/netpoll.go:203 +0x44*02:58:18* 
internal/poll.(*pollDesc).wait(0x40003f8598, 0x72, 0x200, 0x205, 
0x)*02:58:18*  
/home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:87 
+0x38*02:58:18* internal/poll.(*pollDesc).waitRead(...)*02:58:18*  
/home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:92*02:58:18* 
internal/poll.(*FD).Read(0x40003f8580, 0x4000494480, 0x205, 0x205, 0x0, 0x0, 
0x0)*02:58:18*  
/home/root/ci-scripts/golang/src/internal/poll/fd_unix.go:169 +0x158*02:58:18* 
net.(*netFD).Read(0x40003f8580, 0x4000494480, 0x205, 0x205, 0x40004938b8, 
0x82991c28, 0x4000493958)*02:58:18*
/home/root/ci-scripts/golang/src/net/fd_unix.g

Re: [go-nuts] How to clean cache for 'go tool dist test'

[xiangdong...@gmail.com]

Update: I cannot reproduce the time-out issue any longer. Thanks all.

Still curious to know if there is any way to clean the cache, there used to 
be GOCACHE=off, but seems that it's not supported now.

On Friday, March 20, 2020 at 2:01:48 PM UTC+8, xiang...@gmail.com wrote:
>
> I always got a timeout when running all.bash (synced to the latest commit 
> cbd421f75b0770c3534d1b641e7770bf1878004f),
> it's not reproducible with 'go test -run=. crypto/tls', no GOARCH and GOOS 
> were set previously. Thanks.
>
>
> *02:58:18* panic: test timed out after 9m0s*02:58:18* *02:58:18* goroutine 
> 474 [running]:*02:58:18* testing.(*M).startAlarm.func1()*02:58:18* 
> /home/root/ci-scripts/golang/src/testing/testing.go:1492 +0xc8*02:58:18* 
> created by time.goFunc*02:58:18*   
> /home/root/ci-scripts/golang/src/time/sleep.go:169 +0x40*02:58:18* *02:58:18* 
> goroutine 1 [chan receive, 8 minutes]:*02:58:18* 
> testing.(*T).Run(0x4000592000, 0x353e41, 0x11, 0x3742c8, 
> 0x5e73be01)*02:58:18*   
> /home/root/ci-scripts/golang/src/testing/testing.go:1045 +0x2e0*02:58:18* 
> testing.runTests.func1(0x40003ca360)*02:58:18*
> /home/root/ci-scripts/golang/src/testing/testing.go:1313 +0x74*02:58:18* 
> testing.tRunner(0x40003ca360, 0x40008e1c48)*02:58:18*  
> /home/root/ci-scripts/golang/src/testing/testing.go:993 +0xdc*02:58:18* 
> testing.runTests(0x40008e2360, 0x612880, 0x87, 0x87, 0xbf950e12a0c70f0b, 
> 0x7dbd29bde6, 0x6167a0, 0x0)*02:58:18* 
> /home/root/ci-scripts/golang/src/testing/testing.go:1311 +0x294*02:58:18* 
> testing.(*M).Run(0x40003f8180, 0x0)*02:58:18* 
> /home/root/ci-scripts/golang/src/testing/testing.go:1221 +0x1b4*02:58:18* 
> crypto/tls.runMain(0x40003f8180, 0x0)*02:58:18*   
> /home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:389 
> +0x55c*02:58:18* crypto/tls.TestMain(0x40003f8180)*02:58:18*  
> /home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:335 
> +0x8c*02:58:18* main.main()*02:58:18* _testmain.go:321 
> +0x160*02:58:18* *02:58:18* goroutine 246 [IO wait, 8 minutes]:*02:58:18* 
> internal/poll.runtime_pollWait(0x5bccbf78, 0x72, 0x0)*02:58:18*  
> /home/root/ci-scripts/golang/src/runtime/netpoll.go:203 +0x44*02:58:18* 
> internal/poll.(*pollDesc).wait(0x40003f8218, 0x72, 0x0, 0x0, 
> 0x3505d4)*02:58:18*
> /home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:87 
> +0x38*02:58:18* internal/poll.(*pollDesc).waitRead(...)*02:58:18*  
> /home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:92*02:58:18*
>  internal/poll.(*FD).Accept(0x40003f8200, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0)*02:58:18*
> /home/root/ci-scripts/golang/src/internal/poll/fd_unix.go:384 
> +0x184*02:58:18* net.(*netFD).accept(0x40003f8200, 0x37e11d600, 0x0, 
> 0x40003823b8)*02:58:18*  
> /home/root/ci-scripts/golang/src/net/fd_unix.go:238 +0x2c*02:58:18* 
> net.(*TCPListener).accept(0x4000853ae0, 0x400053dfa8, 0x1, 
> 0x222884)*02:58:18*  
> /home/root/ci-scripts/golang/src/net/tcpsock_posix.go:139 +0x2c*02:58:18* 
> net.(*TCPListener).Accept(0x4000853ae0, 0x400053dfa8, 0x4000646020, 0x0, 
> 0x0)*02:58:18*   /home/root/ci-scripts/golang/src/net/tcpsock.go:261 
> +0x5c*02:58:18* crypto/tls.localServer(0x3e0880, 0x4000853ae0)*02:58:18*
> /home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:249 
> +0x5c*02:58:18* created by crypto/tls.runMain*02:58:18*   
> /home/root/ci-scripts/golang/src/crypto/tls/handshake_test.go:361 
> +0x21c*02:58:18* *02:58:18* goroutine 411 [semacquire, 8 minutes]:*02:58:18* 
> internal/poll.runtime_Semacquire(0x40003f85a8)*02:58:18* 
> /home/root/ci-scripts/golang/src/runtime/sema.go:61 +0x38*02:58:18* 
> internal/poll.(*FD).Close(0x40003f8580, 0x40003f8580, 0x0)*02:58:18*
> /home/root/ci-scripts/golang/src/internal/poll/fd_unix.go:109 +0x84*02:58:18* 
> net.(*netFD).Close(0x40003f8580, 0x0, 0x0)*02:58:18*  
> /home/root/ci-scripts/golang/src/net/fd_unix.go:184 +0x48*02:58:18* 
> net.(*conn).Close(0x410040, 0x0, 0x0)*02:58:18* 
> /home/root/ci-scripts/golang/src/net/net.go:208 +0x58*02:58:18* 
> crypto/tls.TestHostnameInSNI(0x4000592000)*02:58:18*
> /home/root/ci-scripts/golang/src/crypto/tls/handshake_client_test.go:1349 
> +0x264*02:58:18* testing.tRunner(0x4000592000, 0x3742c8)*02:58:18*
> /home/root/ci-scripts/golang/src/testing/testing.go:993 +0xdc*02:58:18* 
> created by testing.(*T).Run*02:58:18*   
> /home/root/ci-scripts/golang/src/testing/testing.go:1044 +0x2c4*02:58:18* 
> *02:58:18* goroutine 317 [IO wait, 8 minutes]:*02:58:18* 
> internal/poll.runtime_pollWait(0x5bccbb18, 0x72, 
> 0x)*02:58:18*   
> /home/root/ci-scripts/golang/src/runtime/netpoll.go:203 +0x44*02:58:18* 
> internal/poll.(*pollDesc).wait(0x40003f8598, 0x72, 0x200, 0x205, 
> 0x)*02:58:18*  
> /home/root/ci-scripts/golang/src/internal/poll/fd_poll_runtime.go:87 
> +0x38*02:58:18* internal/poll.(*pollDesc).waitRead(...)*02:5

[go-nuts] random test failure of TestScript/mod_indirect in 'cmd/go'

[xiangdong...@gmail.com]

I got the following test error from time to time, even with a freshly 
checkout repo., when running './all.bash',
but 'go test -run=TestScript/mod_indirect cmd/go' works fine, can anyone 
please help here? Thanks.


go test proxy running at GOPROXY=http://127.0.0.1:57425/mod
go proxy: no archive rsc.io v1.5.2: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.1.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.5.1: file does not exist
go proxy: no archive rsc.io v1.5.2: file does not exist
go proxy: no archive example.com/newcycle v1.0.0: file does not exist
--- FAIL: TestScript (0.03s)
--- FAIL: TestScript/mod_indirect (0.33s)
script_test.go:205:
# golang.org/issue/31248: module requirements imposed by 
dependency versions
# older than the selected version must still be taken into 
account. (0.000s)
# Indirect dependencies required via older-than-selected 
versions must exist in
# the module graph, but do not need to be listed explicitly in 
the go.mod file
# (since they are implied). (0.065s)
# The modules must also appear in the build list, not just the 
graph. (0.196s)
# The packages provided by those dependencies must resolve. 
(0.038s)
> go list all
[stderr]
package main: cannot find package "." in:
/home/xiaji01/src/go.bm.fix/src/main
[exit status 1]
FAIL: testdata/script/mod_indirect.txt:19: unexpected command 
failure

--- FAIL: TestScript/mod_indirect_tidy (0.04s)
script_test.go:205:
# golang.org/issue/31248: loading the build list must not add 
explicit entries
# for indirect dependencies already implied by 
older-than-selected versions
# already in the build list. (0.017s)
> cp go.mod.orig go.mod
> go mod tidy
[stderr]
main: readdirent: not a directory
[exit status 1]
FAIL: testdata/script/mod_indirect_tidy.txt:8: unexpected 
command failure

FAIL
FAILcmd/go  83.159s

-- 
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/9b888584-8c33-487a-aa8e-dfaeccb10ebc%40googlegroups.com.

[go-nuts] multiple-line 'expression' of if-statement not supported?

[xiangdong...@gmail.com]

Hi all,

Wondering if the 'expression' part of an if-statement should be in one line 
only, given the following case, 'go tool compile' will report a syntax error

Enter code here...
package p

func cf1() int {
return 0
}

func cf2() int {
return 10
}

func f() {
*if cf2() - 1*
*< cf1()* {
println("tested")
}
}


ss.go:13:3: syntax error: unexpected <, expecting expression

Guess there might be syntax specification rules but I failed to find out. 

Thanks a lot.

-- 
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/6887bd7f-5344-47b6-91ad-2960d2f67b33o%40googlegroups.com.

Re: [go-nuts] multiple-line 'expression' of if-statement not supported?

[xiangdong...@gmail.com]

Thanks a lot, Ian, it works now.

On Thursday, June 11, 2020 at 2:17:23 PM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Jun 10, 2020 at 11:05 PM xiang...@gmail.com  
> > wrote: 
> > 
> > Wondering if the 'expression' part of an if-statement should be in one 
> line only, given the following case, 'go tool compile' will report a syntax 
> error 
> > 
> > Enter code here... 
> > package p 
> > 
> > func cf1() int { 
> > return 0 
> > } 
> > 
> > func cf2() int { 
> > return 10 
> > } 
> > 
> > func f() { 
> > if cf2() - 1 
> > < cf1() { 
> > println("tested") 
> > } 
> > } 
> > 
> > 
> > ss.go:13:3: syntax error: unexpected <, expecting expression 
> > 
> > Guess there might be syntax specification rules but I failed to find 
> out. 
>
> It's because of automatic semicolon insertion.  You need to put the 
> "<" at the end of the "if" line, not at the start of the next line. 
> See https://golang.org/ref/spec#Semicolons . 
>
> 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/b06a5576-6d9b-4066-9017-b6aeb61a665do%40googlegroups.com.

[go-nuts] Any way to exclude testcase(s) from 'go test'?

[xiangdong...@gmail.com]

Hi,

I'm looking for a way to exclude one specific testcase (perhaps multiple in 
the future) from 'go test' and wondering how to define a 'negation' pattern?

For example, how to run all testcases of misc/cgo/test except for a 
specific one, say Test7978? 

Thanks a lot.

-- 
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/56d87527-cdd4-4b86-a86a-5549dd972245n%40googlegroups.com.

Re: [go-nuts] Any way to exclude testcase(s) from 'go test'?

[xiangdong...@gmail.com]

The issue happens at building time of 'go test' for misc/cgo/test, I was 
expecting 'go test' is powerful enough to skip building a specific case 
given a negation pattern and without involving tags, but just realized it's 
a wrong way, 'go test' always builds all dependency stuff.

Now the requirements are:
1. not building Test7978 on arm64 when running the 'dist' test, and
2. minimize the change so that it could be reverted easily when the link 
issue gets fixed later.

To disable the testing to misc/cgo/test for several 'internal linking' 
cases on arm64 is an option, but that means other 90 tests are skipped 
meanwhile.

On Tuesday, September 1, 2020 at 12:43:57 PM UTC+8 Kurtis Rader wrote:

> On Mon, Aug 31, 2020 at 9:03 PM xiangd...@arm.com  
> wrote:
>
>> Thanks for replying, background is the github issue 39466 
>> and its potential fix 
>> under reviewing, we 
>> are trying not to introduce any additional test files and tags but seeking 
>> for a change to test command line only,
>> other opinions are welcome.
>>
>
> Okay, those links are helpful (and should have been in your first 
> message). I only skimmed each of them but I don't understand why being able 
> to "define a 'negation' pattern" is preferable to using `-tags` to define a 
> "positive pattern" for tests to be run.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/b909a788-a4b3-4e97-b1c3-0c319eae497en%40googlegroups.com.

[go-nuts] Linter for checking 'MVS' of go module

[xiangdong...@gmail.com]

Hi all,

I'm wondering if any linter, or is it practical to make one, checks whether 
a go module's code change conforms the minimal version selection rules, say 
linter warns a v2 is needed if incompatible changes to APIs are introduced 
in the current change under linting?

-- 
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/a57bad3b-a4bb-4507-ada3-95df46606bf3n%40googlegroups.com.

Re: [go-nuts] Linter for checking 'MVS' of go module

[xiangdong...@gmail.com]

Thanks a lot, Shulhan.

On Wednesday, December 9, 2020 at 1:03:01 PM UTC+8 Shulhan wrote:

>
>
> On Wed, 9 Dec 2020, 11:42 xiangd...@gmail.com,  
> wrote:
>
>> Hi all,
>>
>> I'm wondering if any linter, or is it practical to make one, checks 
>> whether a go module's code change conforms the minimal version selection 
>> rules, say linter warns a v2 is needed if incompatible changes to APIs are 
>> introduced in the current change under linting?
>>
>
> There is an experiment on tooling called gorelease [1]. I believe its in 
> working-in-progress [2].
>
> [1] golang.org/x/exp/cmd/gorelease
> [2] https://github.com/golang/go/issues/26420
>
>

-- 
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/25a1ca42-c910-45f4-91d7-14f6866e6538n%40googlegroups.com.

[go-nuts] heapdump viewer

[xiangdong...@gmail.com]

Hi all,

I'm looking for a viewer for the heapdump file generated by WriteHeapDump, 
can anyone shed a light here? 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/896444a5-6a66-40a4-9e68-74b0bfb7596an%40googlegroups.com.