Re: [go-nuts] Unsupported File Format error while building for linux-amd64 on mac os

[Matt Joiner]

I found this, which worked without GOPATH assumptions: 
https://blog.filippo.io/easy-windows-and-linux-cross-compilers-for-macos/

On Monday, 1 October 2018 at 7:32:23 pm UTC+10 Ankit Gupta wrote:

> Tamas,
>
> I installed docker on mac and cross compiled using xgo like you suggested. 
> Worked perfectly. Thanks a lot!
>
>
> On Saturday, September 29, 2018 at 1:58:20 AM UTC+5:30, Tamás Gulácsi 
> wrote:
>>
>> 2018. szeptember 28., péntek 15:59:14 UTC+2 időpontban Ankit Gupta a 
>> következőt írta:
>>>
>>> Thanks Ian for responding. Can you point me as to how to get the cross 
>>> compiler. I am farely new to Mac.
>>>
>>> On Fri, 28 Sep 2018, 19:23 Ian Lance Taylor,  wrote:
>>>
 On Fri, Sep 28, 2018 at 2:08 AM, Ankit Gupta
  wrote:
 >
 > I am working with confluent-kafka-go library
 > (https://github.com/confluentinc/confluent-kafka-go) which builds 
 fine on
 > the mac machine (mac OS 10.13.6) along with the code files I wrote. 
 In order
 > to deploy it on Linux server (Ubuntu 64 bit), I try this -
 >
 > $> CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build program.go
 >
 >
 > I get below linking error -
 >
 >
 > /usr/local/go/pkg/tool/darwin_amd64/link: running clang failed: exit 
 status
 > 1
 >
 > ld: warning: ignoring file
 > 
 /var/folders/fy/9ph54yjs6cq1kyxgs6cc9rvjvs6t0m/T/go-link-060577916/go.o,
 > file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 
 0x01
 > 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the
 > architecture being linked (x86_64):
 > 
 /var/folders/fy/9ph54yjs6cq1kyxgs6cc9rvjvs6t0m/T/go-link-060577916/go.o
 >
 > Undefined symbols for architecture x86_64:
 >
 >   "__cgo_topofstack", referenced from:
 >
 >   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_conf_new in 03.o
 >
 >   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_conf_set in 03.o
 >
 >   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_topic_conf_new in 03.o
 >
 >   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_topic_conf_set in 03.o
 >
 >   __cgo_f2fa82ea8f11_Cfunc__c_rdkafka_topic_partition_list_entry 
 in
 > 04.o
 >
 >   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_assign in 04.o
 >
 >   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_assignment in 04.o
 >
 >   ...
 >
 >   "_main", referenced from:
 >
 >  implicit entry/start for main executable
 >
 >  (maybe you meant: 
 __cgo_f2fa82ea8f11_Cfunc_rd_kafka_queue_get_main)
 >
 > ld: symbol(s) not found for architecture x86_64
 >
 > clang: error: linker command failed with exit code 1 (use -v to see
 > invocation)
 >
 >
 > It points to /var/folders which I am given to understand is a temp 
 location
 > in mac.
 >
 >
 > Any ideas on how to fix it?

 When cross-compiling a Go program that uses cgo, you need to be using
 a C cross-compiler.  It looks like you are using the native Darwin C
 compiler.  You need a cross-compiler from Darwin to GNU/Linux.

 Ian

>>>
>> Native compilation is much easier.
>> If you have Docker installed, https://github.com/karalabe/xgo can help 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/0f0528b6-6e6f-45d1-8b3a-ddd674e24f00n%40googlegroups.com.

Re: [go-nuts] [generics] combining different instances of the same generic type

[Matt Joiner]

The conversation has drifted a little from generics, I've replied inline
below:

On Wed, 2 Dec 2020 at 20:56, roger peppe  wrote:

> On Wed, 2 Dec 2020 at 09:15, roger peppe  wrote:
>
>> Also your delayed blocks don't wait for the preceding set of futures to
>>> be exhausted before proceeding, I think they're all triggered once the
>>> initial set is completed
>>
>>
>> Each delayed block is triggered when its associated delay has elapsed.
>> Once the initial set is completed, it returns immediately. Isn't that what
>> you want? As I said, I'm finding it hard to imagine a scenario where these
>> particular semantics are useful, so it's not easy to decide how to treat
>> the edge cases.
>>
> Specifically if there are no pending futures at a given instant, those in
the block of delayed futures next due are "unlocked". AsCompletedDelayed is
designed to allow prioritizing some futures over others, with timeouts
occurring if those that shouldn't be delayed anymore haven't returned in a
reasonable time (the next block are unlocked and can compete with the
higher priority ones).

> I'm talking rubbish there, I'm afraid. It's entirely possible to do this,
> albeit at the cost of an extra goroutine:
>
> func Map[A, B any](f *F[A], fn func(A) B) *F[B] {
> return Start(func() (B, error) {
> a, err := f.Result()
> if err != nil {
> return *new(B), err
> }
> return fn(a), nil
> })
> }
>
This is a great observation, 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/CAB4yi1OGANBsoDLbouoG2XfA4R3ZPYmcn_MpBtX6N%2B38N2n4xA%40mail.gmail.com.

Re: [go-nuts] [generics] combining different instances of the same generic type

[Matt Joiner]

Thanks very much for taking a look at this Roger. I think your attempt
differs from mine in that you don't make use of the future type F in
implementing the waiting for the blocks of delayed futures, which means you
don't have to deal with combining different instances of F (F[A], F[B]
etc.). Also your delayed blocks don't wait for the preceding set of futures
to be exhausted before proceeding, I think they're all triggered once the
initial set is completed. I also remade use of AsCompleted, which was an
extra complication, since I had the difficulty I mentioned regarding
passing Fs of different types to it easily.

Now I've had more time to process it, I think my issue comes down to being
unsure about how to easily/consistently perform mappings between generic
types (like F[A] -> F[B]). A second thing that's not clear is how to handle
the type F when I don't care about what type it's been instantiated with
(say I wanted to retain the existing code, but I know that if F is in the
original map[F[struct{}]struct{}] timeouts that it's a F[struct{}],
otherwise it's F[T] (and I'm happy to type-assert at that point)). It's
clearly not F[interface{}], for lack of better notation, I'll call it F[*].

On Wed, 2 Dec 2020 at 10:07, roger peppe  wrote:

> And again (no need to make a cancelable context)
> https://go2goplay.golang.org/p/3UFUaXijuX9
>
> On Tue, 1 Dec 2020 at 22:59, roger peppe  wrote:
>
>> Slightly simpler again: https://go2goplay.golang.org/p/mKdishv4nhT
>>
>> On Tue, 1 Dec 2020 at 18:44, roger peppe  wrote:
>>
>>> I'm having difficulty understanding exactly what your code is trying to
>>> do (and why), and that makes it hard to understand what
>>> generic solution might be appropriate.
>>>
>>> However, here's one alternative implementation that doesn't seem to run
>>> into the same kind of issues that you did.
>>> It changes the contract a little bit, but it's still within the spirit,
>>> I think and it's somewhat simpler:
>>>
>>> https://go2goplay.golang.org/p/cEWEUrvfZBl
>>>
>>> FWIW when I've implemented this kind of logic in the past, the aim is
>>> usually to obtain at most one result. I don't really understand the use
>>> case being implemented here.
>>>
>>> To address the actual question you raised:
>>>
>>> I ran into the situation where I need to "map" the futures of type
>>>> *F[int], and *F[T] to *F[timeoutOrResult[T]].
>>>
>>>
>>> There's no reason why interface types won't still play a large role in
>>> the future where Go has generics, and that's
>>> how I'd probably represent timeoutOrResult there, with a dynamic type
>>> switch to decide which one you've got.
>>>
>>>   cheers,
>>> rog.
>>>
>>> On Mon, 30 Nov 2020 at 02:09, Matt Joiner  wrote:
>>>
>>>> I had a muck around with go2 generics with my toy-ish futures package
>>>> https://github.com/anacrolix/futures. The go1 implementation is in
>>>> master, and a working go2 implementation in the go2 branch (using channels
>>>> of different types instead of the attempt that follows). The package
>>>> provides one function AsCompletedDelayed, that allows to favour futures
>>>> over others with timeouts. The timeouts are implemented using the future
>>>> type *F[int], where as the futures the user provides as arguments are
>>>> *F[T]. In the implementation for AsCompletedDelayed I need to pass both
>>>> types of futures to another function AsCompleted[T](fs ...*F[T]) <-chan
>>>> *F[T], then differentiate them when they're returned: I could get back a
>>>> "timeout" future, or a user/argument future. To do this I created another
>>>> type timeoutOrResult[T] struct { timeout bool; timeoutIndex int; result T
>>>> }, however now I ran into the situation where I need to "map" the futures
>>>> of type *F[int], and *F[T] to *F[timeoutOrResult[T]]. This seems
>>>> non-trivial: I believe in another language I would make F a Functor, and
>>>> map the timeouts to something like `Either int T`. It is possible to write
>>>> an Fmap on my *F type, but now I need to create new types, and break out an
>>>> interface, and the implementation quickly increases in complexity.
>>>>
>>>> This seems like a situation where the go1 style of doing this was
>>>> easier albeit without enforcing the result types of the futures in the
>>>> return chan for AsCompleted and AsCompletedDelayed: I could pass arbitrary
>>>> *Fs to AsComplete

[go-nuts] [generics] combining different instances of the same generic type

[Matt Joiner]

I had a muck around with go2 generics with my toy-ish futures package 
https://github.com/anacrolix/futures. The go1 implementation is in master, 
and a working go2 implementation in the go2 branch (using channels of 
different types instead of the attempt that follows). The package provides 
one function AsCompletedDelayed, that allows to favour futures over others 
with timeouts. The timeouts are implemented using the future type *F[int], 
where as the futures the user provides as arguments are *F[T]. In the 
implementation for AsCompletedDelayed I need to pass both types of futures 
to another function AsCompleted[T](fs ...*F[T]) <-chan *F[T], then 
differentiate them when they're returned: I could get back a "timeout" 
future, or a user/argument future. To do this I created another type 
timeoutOrResult[T] struct { timeout bool; timeoutIndex int; result T }, 
however now I ran into the situation where I need to "map" the futures of 
type *F[int], and *F[T] to *F[timeoutOrResult[T]]. This seems non-trivial: 
I believe in another language I would make F a Functor, and map the 
timeouts to something like `Either int T`. It is possible to write an Fmap 
on my *F type, but now I need to create new types, and break out an 
interface, and the implementation quickly increases in complexity.

This seems like a situation where the go1 style of doing this was easier 
albeit without enforcing the result types of the futures in the return chan 
for AsCompleted and AsCompletedDelayed: I could pass arbitrary *Fs to 
AsCompleted, and then compare the returning *F against a map[*F]struct{} 
that tracked which ones were timeouts.

-- 
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/adb04bb6-bdda-41a9-a168-2541dd912171n%40googlegroups.com.

Re: [go-nuts] 2016 Go User Survey results

[Matt Joiner]

Thanks Dave

On 13 February 2017 at 08:30, Dave Cheney  wrote:

> I raised https://github.com/golang/go/issues/19050 to track this.
>
> --
> 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/LNdbk97fBiA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Extracting link to earlier panic

[Matt Joiner]

^

On Friday, 25 November 2016 14:02:29 UTC+11, Matt Joiner wrote:
>
> I can't see anyway to extract earlier panics per runtime's _panic.link. 
> This makes it difficult to print stack traces in the way that the default 
> handler does if a panic is not recovered.
>
> I want to recover a panic, print its stack trace, and all earlier panic 
> values in the way shown here:
>
> panic: zip: not a valid zip file [recovered]
>
> panic: some context [recovered]
>
> panic: more context
>
>
> goroutine 1 [running]:
>
> 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Extracting link to earlier panic

[Matt Joiner]

I can't see anyway to extract earlier panics per runtime's _panic.link. 
This makes it difficult to print stack traces in the way that the default 
handler does if a panic is not recovered.

I want to recover a panic, print its stack trace, and all earlier panic 
values in the way shown here:

panic: zip: not a valid zip file [recovered]

panic: some context [recovered]

panic: more context


goroutine 1 [running]:



-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Deleting the /r/golang subreddit

[Matt Joiner]

I don't believe technical forum moderators should be abusing their position 
to project their ethical standpoints onto users. If users don't like 
Reddit, they can just not participate. If the moderators don't like it, 
step down.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Persistent http TLS connections despite timeout

[Matt Joiner]

All of the following goroutines have a corresponding file descriptor open.

515 @ 0x434c9a 0x4301d7 0x42f819 0x536fe8 0x537054 0x5387a7 0x54c0e0
0x5d5ed8 0x5d6444 0x5da116 0x691720 0x4fdd57 0x4fecbb 0x4feea7 0x61701f
0x616e1f 0x68b895 0x692afa 0x696d7a 0x460f61
# 0x42f818 net.runtime_pollWait+0x58 /root/src/go/src/runtime/netpoll.go:164
# 0x536fe7 net.(*pollDesc).wait+0x37
/root/src/go/src/net/fd_poll_runtime.go:75
# 0x537053 net.(*pollDesc).waitRead+0x33
/root/src/go/src/net/fd_poll_runtime.go:80
# 0x5387a6 net.(*netFD).Read+0x1b6 /root/src/go/src/net/fd_unix.go:250
# 0x54c0df net.(*conn).Read+0x6f /root/src/go/src/net/net.go:180
# 0x5d5ed7 crypto/tls.(*block).readFromUntil+0x97
/root/src/go/src/crypto/tls/conn.go:488
# 0x5d6443 crypto/tls.(*Conn).readRecord+0xc3
/root/src/go/src/crypto/tls/conn.go:590
# 0x5da115 crypto/tls.(*Conn).Read+0x115
/root/src/go/src/crypto/tls/conn.go:1134
# 0x69171f net/http.(*connReader).Read+0x13f
/root/src/go/src/net/http/server.go:740
# 0x4fdd56 bufio.(*Reader).fill+0x116 /root/src/go/src/bufio/bufio.go:97
# 0x4fecba bufio.(*Reader).ReadSlice+0xba
/root/src/go/src/bufio/bufio.go:338
# 0x4feea6 bufio.(*Reader).ReadLine+0x36 /root/src/go/src/bufio/bufio.go:367
# 0x61701e net/textproto.(*Reader).readLineSlice+0x5e
/root/src/go/src/net/textproto/reader.go:55
# 0x616e1e net/textproto.(*Reader).ReadLine+0x2e
/root/src/go/src/net/textproto/reader.go:36
# 0x68b894 net/http.readRequest+0xa4
/root/src/go/src/net/http/request.go:871
# 0x692af9 net/http.(*conn).readRequest+0x219
/root/src/go/src/net/http/server.go:920
# 0x696d79 net/http.(*conn).serve+0x499
/root/src/go/src/net/http/server.go:1726

Here's the specifics for just one of these goroutines:

goroutine 968618 [IO wait, 160 minutes]:
net.runtime_pollWait(0x7f6a402d2770, 0x72, 0x156)
/root/src/go/src/runtime/netpoll.go:164 +0x59
net.(*pollDesc).wait(0xc422f48d88, 0x72, 0xfbb160, 0xfb66d8)
/root/src/go/src/net/fd_poll_runtime.go:75 +0x38
net.(*pollDesc).waitRead(0xc422f48d88, 0xc421fd4000, 0x800)
/root/src/go/src/net/fd_poll_runtime.go:80 +0x34
net.(*netFD).Read(0xc422f48d20, 0xc421fd4000, 0x800, 0x800, 0x0, 0xfbb160,
0xfb66d8)
/root/src/go/src/net/fd_unix.go:250 +0x1b7
net.(*conn).Read(0xc420baf018, 0xc421fd4000, 0x800, 0x800, 0x0, 0x0, 0x0)
/root/src/go/src/net/net.go:180 +0x70
crypto/tls.(*block).readFromUntil(0xc4209ee270, 0x7f6a45f4d1c0,
0xc420baf018, 0x5, 0xc420baf018, 0x0)
/root/src/go/src/crypto/tls/conn.go:488 +0x98
crypto/tls.(*Conn).readRecord(0xc42290a700, 0xadc817, 0xc42290a820,
0x690fda)
/root/src/go/src/crypto/tls/conn.go:590 +0xc4
crypto/tls.(*Conn).Read(0xc42290a700, 0xc427867000, 0x1000, 0x1000, 0x0,
0x0, 0x0)
/root/src/go/src/crypto/tls/conn.go:1134 +0x116
net/http.(*connReader).Read(0xc429001bc0, 0xc427867000, 0x1000, 0x1000,
0xc43c11f918, 0x0, 0x0)
/root/src/go/src/net/http/server.go:740 +0x140
bufio.(*Reader).fill(0xc4202b7800)
/root/src/go/src/bufio/bufio.go:97 +0x117
bufio.(*Reader).ReadSlice(0xc4202b7800, 0xa, 0x0, 0x0, 0x0, 0x0,
0xc43c11f9f0)
/root/src/go/src/bufio/bufio.go:338 +0xbb
bufio.(*Reader).ReadLine(0xc4202b7800, 0xc42b252e00, 0x100, 0xf8, 0xaa52a0,
0xc43c11fa58, 0x474652)
/root/src/go/src/bufio/bufio.go:367 +0x37
net/textproto.(*Reader).readLineSlice(0xc42037d0e0, 0xc43c11fac0,
0xc43c11fac0, 0x418b88, 0x100, 0xaa52a0)
/root/src/go/src/net/textproto/reader.go:55 +0x5f
net/textproto.(*Reader).ReadLine(0xc42037d0e0, 0xc42b252e00, 0xc4,
0x0, 0x72)
/root/src/go/src/net/textproto/reader.go:36 +0x2f
net/http.readRequest(0xc4202b7800, 0x0, 0xc42b252e00, 0x0, 0x0)
/root/src/go/src/net/http/request.go:871 +0xa5
net/http.(*conn).readRequest(0xc428b8b180, 0xfbfba0, 0xc429001b80, 0x0,
0x0, 0x0)
/root/src/go/src/net/http/server.go:920 +0x21a
net/http.(*conn).serve(0xc428b8b180, 0xfbfba0, 0xc429001b80)
/root/src/go/src/net/http/server.go:1726 +0x49a
created by net/http.(*Server).Serve
/root/src/go/src/net/http/server.go:2608 +0x2ce

I'm running the http.Server with ConnState: timeoutIdleConns

func timeoutIdleConns(nc net.Conn, cs http.ConnState) {

switch cs {
case http.StateIdle, http.StateNew:

nc.SetReadDeadline(time.Now().Add(time.Minute))

default:

nc.SetReadDeadline(time.Time{})

}

}

>From what I can tell, this callback is triggered with StateNew, prior to
conn.serve() being created, so the ReadDeadline should be present in the
stalled goroutine calls.

What's going on?

-- 
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.
For more options, visit https://groups.google.com/d/optout.