[go-nuts] use Go in RTOS, for real-time, deterministic, (industry control) software?

[Fino]

Although Go is a GC language, 
is it any chance to use Go in Preempt_RT Linux (Xenomai, or other RTOS), 
for real-time, deterministic, (industry control) software? 
RTOS can offer a <50us schedule latency, it's the delay from hardware 
timer's interrupt triggered to real-time thread being re-scheduled.
which means if GC occupies the CPU for more than 50us, then the re-schedule 
latency cannot be guaranteed < 50us, especially for a single core CPU.
if the CPU have more than 2 cores, maybe the real-time thread can stay on 
one core, and GC work on another core, I am not sure.

the idea is attractive because the dev speed of writing C is slower than a 
GC language. and C have too much history burden,  header files for 
examples.  

would like to read your thinking, thanks! 

BR fino


-- 
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/c2cb3eb6-b753-42af-be88-f70beb4ff0c9n%40googlegroups.com.

Re: [go-nuts] Re: draft designs for file system interfaces & file embedding

[Constantine Vassilev]

I generated it from the source. I that the version I need?

go version devel +4ce0a7cea6 Sat Nov 28 18:42:44 2020 + darwin/amd64

On Saturday, November 28, 2020 at 12:08:29 PM UTC-8 Ian Lance Taylor wrote:

> On Sat, Nov 28, 2020 at 10:27 AM Constantine Vassilev
>  wrote:
> >
> > I would like to test it. How to install the go 1.16 tip version?
>
> See https://golang.org/doc/install/source .
>
> 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/0f4b0d5f-b611-4d72-8a1b-ac2c19c1483cn%40googlegroups.com.

Re: [go-nuts] Re: draft designs for file system interfaces & file embedding

[Ian Lance Taylor]

On Sat, Nov 28, 2020 at 10:27 AM Constantine Vassilev
 wrote:
>
> I would like to test it. How to install the go 1.16 tip version?

See https://golang.org/doc/install/source .

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

[go-nuts] Re: draft designs for file system interfaces & file embedding

[Constantine Vassilev]

I would like to test it. How to install the go 1.16 tip version?

On Tuesday, July 21, 2020 at 8:22:30 AM UTC-7 Russ Cox wrote:

> Hi all,
>
> I've posted two draft designs: one introducing general-purpose file system 
> interfaces, with Rob Pike; and one for embedding files into Go programs, 
> with Brad Fitzpatrick. These are draft designs we're circulating for 
> feedback, not official proposals. (We certainly hope they will be well 
> received and can be made into proposals, but that's not where we are today.)
>
> If you are interested, there are docs and videos linked below. Because it 
> worked well for the //go:build draft design, we're using Reddit again for 
> the discussion, also linked below. Reddit's proper threading support scales 
> better than GitHub or a single large mail thread. But for those who don't 
> want to use Reddit, I will keep an eye on this thread as well and reply as 
> best I can.
>
> io/fs draft design
>  - Video: https://golang.org/s/draft-iofs-video
>  - Design: https://golang.org/s/draft-iofs-design
>  - Q: https://golang.org/s/draft-iofs-reddit
>
> //go:embed draft design
>  - Video: https://golang.org/s/draft-embed-video
>  - Design: https://golang.org/s/draft-embed-design
>  - Q: https://golang.org/s/draft-embed-reddit
>
> Thanks!
>
> Best,
> Russ
>

-- 
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/30a90339-bd65-496b-bd91-98e8a271133cn%40googlegroups.com.

Re: [go-nuts] Estimating blockers for supporting gollvm on RISC-V (qemu). Fedora 33

[Ian Lance Taylor]

On Sat, Nov 28, 2020 at 12:40 AM Ivan Serdyuk
 wrote:
>
> Jim,
> adding you to the discussion.
>
> I was not able to build gold, by configuring binutils, using
>>
>> ./configure --enable-gold
>
> did not allow GNU make tool to build gold: many sub-directories were 
> processed, to compile the sources/generate files - but not the sub-dir. for 
> gold.
> When I entered the "gold" dir. and ran "configure" script - it failed with an 
> error, which reported an unsupported arch. , under qemu.
>
> Is there any way to compile gold?
> Perhaps I have improper identification of the arch.?
> Perhaps there is a working Makefile, for this (until "configure" would be 
> patched properly)?
>
> What about cross-compiling (Linux x86_64 -> Linux 64bit RISC-V ) ?

The gold linker does not yet support RISC/V.  The --enable-gold
configure option won't work for that target.

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/CAOyqgcVW78LVCC_toOGL4NgXg9KGk%3DP-PZBcyY9O5Tj1%2BNjhdA%40mail.gmail.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[Amit Saha]

> On 28 Nov 2020, at 11:22 pm, b.ca...@pobox.com  wrote:
> 
> > My actual query was to learn how the removal of the broken connection is 
> > done.
> 
> Ah OK.  I'm not familiar with this code (net/http/transport.go), and you've 
> already shown that the PutIdleConn trace action isn't called.  Maybe this 
> comment is helpful:

No worries at all. The PutIdleConn is not called for HTTP/2 connections which I 
found to be the case for https://godoc.org , but when I used 
http://godoc.org  (in my example that I shared), it was 
called and the error was nil.
> 
> if pconn.isBroken() || tooOld {
> // If either persistConn.readLoop has marked 
> the connection
> // broken, but Transport.removeIdleConn has 
> not yet removed it
> // from the idle list, or if this persistConn 
> is too old (it was
> // idle too long), then ignore it and look 
> for another. In both
> // cases it's already in the process of being 
> closed.
> list = list[:len(list)-1]
> continue
> }
> 
> Otherwise someone else can answer more specifically.

No problems. I did start looking at the above isBroken() method, but sort of 
got lost.



> 
> -- 
> 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/613e3778-7892-4ab9-8cc8-6db1a3e8f966n%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/2FAC9A9D-BF72-4566-9981-CA74233E8917%40gmail.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[b.ca...@pobox.com]

> My actual query was to learn how the removal of the broken connection is 
done.

Ah OK.  I'm not familiar with this code (net/http/transport.go), and you've 
already shown that the PutIdleConn trace action isn't called.  Maybe this 
comment is helpful:

if pconn.isBroken() || tooOld {
// If either persistConn.readLoop has 
marked the connection
// broken, but Transport.removeIdleConn has 
not yet removed it
// from the idle list, or if this 
persistConn is too old (it was
// idle too long), then ignore it and look 
for another. In both
// cases it's already in the process of 
being closed.
list = list[:len(list)-1]
continue
}

Otherwise someone else can answer more specifically.

-- 
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/613e3778-7892-4ab9-8cc8-6db1a3e8f966n%40googlegroups.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[Amit Saha]

> On 28 Nov 2020, at 10:36 pm, b.ca...@pobox.com  wrote:
> 
> Unless you timestamp those log lines, I don't see any evidence that the DNS 
> query is done when the godoc server shuts down.  Could it not just be that 
> after the 2 second sleep, when it's time to make a new connection, it finds 
> that the pool is empty so has to do a lookup to establish a new connection?

Yes, that’s correct. I inferred the same. What I wanted to learn was to see the 
code where the detection that the remote server had gone/connection had gone 
bad and it was removed from the pool.
> 
> I've tested this myself, using your code and apache running on the local 
> server.
> 
> $ go run httpclient.go http://localhost:80/
> DNS Start Info: {Host:localhost}
> DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
> Got Conn: {Conn:0xc10070 Reused:false WasIdle:false IdleTime:0s}
> Put Idle Conn Error: 
> Resp protocol: "HTTP/1.1"
> Sleeping now
> 
> Got Conn: {Conn:0xc10070 Reused:true WasIdle:true IdleTime:2.000554686s}
> Put Idle Conn Error: 
> Resp protocol: "HTTP/1.1"
> Sleeping now
> << at this point I "systemctl stop apache2" in another terminal >>
> << nothing happens until the 2 seconds is up, and then I see: >>
> 
> DNS Start Info: {Host:localhost}
> DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
> Got error in making request: Get "http://localhost:80/": dial tcp 
> 127.0.0.1:80: connect: connection refused
> Sleeping now
> 
> DNS Start Info: {Host:localhost}
> DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
> Got error in making request: Get "http://localhost:80/": dial tcp 
> 127.0.0.1:80: connect: connection refused
> Sleeping now
> ^Csignal: interrupt
> 
> So as far as I can tell, the client tries to re-use the existing connection 
> from the pool, finds there isn't one (or it's broken), and therefore tries to 
> establish a new connection - which of course requires a lookup of the 
> hostname in the URL.

That’s correct and matches my understanding which is great. My actual query was 
to learn how the removal of the broken connection is done.

> 
> Aside: I'd say the trace hooks "DNSStart" and "DNSDone" are somewhat 
> misnamed, because the hostname resolution isn't necessarily done via DNS - in 
> both your example and mine it's done via /etc/hosts.  But the intention is 
> clear.

Agree.

> 
> -- 
> 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/bb366eb5-c7df-452a-9549-281543b1b6d4n%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/DB179F0B-155F-4E09-9646-6F94F9933B15%40gmail.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[b.ca...@pobox.com]

Unless you timestamp those log lines, I don't see any evidence that the DNS 
query is done when the godoc server shuts down.  Could it not just be that 
after the 2 second sleep, when it's time to make a new connection, it finds 
that the pool is empty so has to do a lookup to establish a new connection?

I've tested this myself, using your code and apache running on the local 
server.

$ go run httpclient.go http://localhost:80/
DNS Start Info: {Host:localhost}
DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
Got Conn: {Conn:0xc10070 Reused:false WasIdle:false IdleTime:0s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now

Got Conn: {Conn:0xc10070 Reused:true WasIdle:true IdleTime:2.000554686s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now
*<< at this point I "systemctl stop apache2" in another terminal >>*
*<< nothing happens until the 2 seconds is up, and then I see: >>*

DNS Start Info: {Host:localhost}
DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
Got error in making request: Get "http://localhost:80/": dial tcp 
127.0.0.1:80: connect: connection refused
Sleeping now

DNS Start Info: {Host:localhost}
DNS Done Info: {Addrs:[{IP:127.0.0.1 Zone:}] Err: Coalesced:false}
Got error in making request: Get "http://localhost:80/": dial tcp 
127.0.0.1:80: connect: connection refused
Sleeping now
^Csignal: interrupt

So as far as I can tell, the client tries to re-use the existing connection 
from the pool, finds there isn't one (or it's broken), and therefore tries 
to establish a new connection - which of course requires a lookup of the 
hostname in the URL.

Aside: I'd say the trace hooks "DNSStart" and "DNSDone" are somewhat 
misnamed, because the hostname resolution isn't necessarily done via DNS - 
in both your example and mine it's done via /etc/hosts.  But the intention 
is clear.

-- 
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/bb366eb5-c7df-452a-9549-281543b1b6d4n%40googlegroups.com.

Re: [go-nuts] Trying to understand HTTP connection pooling behaviour - new DNS lookup

[Amit Saha]

> On 28 Nov 2020, at 8:14 pm, b.ca...@pobox.com  wrote:
> 
> Do you see a forward or reverse DNS lookup being made?
> 
> Can you provide a standalone program which demonstrates this behaviour?
> 
> I am wondering if either (a) something is logging when the connection is 
> terminated, or (b) a new connection is automatically being made and put into 
> a pool.

Sure, please find my code here: 
https://gist.github.com/amitsaha/3963207e77f7537a5dcc3b3afa8e57ee

My experiment scenario:

1. Modify /etc/hosts to have this entry:

# 216.239.38.21 godoc.org #one of the actual IP addresses
 godoc.org

2. Run godoc locally as: sudo ~/go/bin/godoc -http=:80

3. Build and run the above program:

$ go build -o application
$ ./application http://godoc.org
DNS Start Info: {Host:godoc.org}
DNS Done Info: {Addrs:[{IP:192.168.1.109 Zone:} {IP:2001:4860:4802:38::15 
Zone:} {IP:2001:4860:4802:36::15 Zone:} {IP:2001:4860:4802:32::15 Zone:} 
{IP:2001:4860:4802:34::15 Zone:}] Err: Coalesced:false}
Got Conn: {Conn:0xc000186000 Reused:false WasIdle:false IdleTime:0s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now

Got Conn: {Conn:0xc000186000 Reused:true WasIdle:true IdleTime:2.00444722s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now



…

In a new terminal:

1. Update /etc/hosts to have:

216.239.38.21 godoc.org
#192.168.1.109 godoc.org

2. Kill the godoc server

Then in the terminal you had the application running, you should see:

Got Conn: {Conn:0xc000186000 Reused:true WasIdle:true IdleTime:2.001646523s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now


# This is where the switch to the new IP happens

DNS Start Info: {Host:godoc.org}
DNS Done Info: {Addrs:[{IP:216.239.38.21 Zone:} {IP:2001:4860:4802:32::15 
Zone:} {IP:2001:4860:4802:36::15 Zone:} {IP:2001:4860:4802:38::15 Zone:} 
{IP:2001:4860:4802:34::15 Zone:}] Err: Coalesced:false}
Got Conn: {Conn:0xcb40b8 Reused:false WasIdle:false IdleTime:0s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now

Got Conn: {Conn:0xcb40b8 Reused:true WasIdle:true IdleTime:2.002040265s}
Put Idle Conn Error: 
Resp protocol: "HTTP/1.1"
Sleeping now

….


My go version:
$ go version
go version go1.15 darwin/amd64


Thank you,
Amit



> 
> On Saturday, 28 November 2020 at 01:27:32 UTC amits...@gmail.com wrote:
> Hi, it seems that the http client automatically performs a DNS lookup when an 
> existing connection is terminated by the server. I simulated it via changing 
> the IP address in /etc/hosts.
> 
> Can someone point me to the code where this logic is checked?
> 
> I am looking at https://golang.org/src/net/http/transport.go but haven’t 
> found something yet - quite a beginner here.
> 
> Thanks,
> Amit.
> 
> 
> -- 
> 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/86f347d0-862f-4922-b2e4-e8835858ae90n%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/8CC6C1E1-BA1C-46C7-A564-E5A9E7D5AA52%40gmail.com.

Re: [go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

['Axel Wagner' via golang-nuts]

It would also be possible to implement `json.Marshaler` to use a different
time format. In particular, it might be reasonable to encode the zero
value of time.Time as `null`, instead of a string (though mixed types in
json messages are… icky).

Personally, I'm always very cautious about encoding and decoding times.
There isn't really a standard way to transmit timezone information,
especially as timezone definitions can even change over time, AIUI. So,
even if you specify which timezone a point in time should be in, you can't
rely on the receiver of the message having the same understanding of that
timezone.

Using UTC for storage and transmission is probably a better option. You
essentially treat the stored data purely as "a point in time", while
timezone info is specific to the presentation. A time.Time isn't just a
point in time, though, so if you really marshal "a time.Time", you have to
somehow include timezone info - so I kinda understand why the default
MarshalJSON method doesn't convert it to UTC first.

On Sat, Nov 28, 2020 at 10:35 AM Matt Harden  wrote:

>
>
> On Fri, Nov 27, 2020 at 4:14 PM 'Robert Ma' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Is this because the 2-second offset of LMT gets lost in RFC 3339
>> representation?
>>
>
> Yes, that's exactly it.
>
>
>> On Fri, Nov 27, 2020 at 6:33 PM Robert Ma  wrote:
>>
>>> Hi all,
>>>
>>> Time is complicated.
>>>
>>
> Wibbly-wobbly, even.
>
> Today I found myself in a rabbit hole. For some unrelated reason, I got a
>>> time value in a non-UTC location that's otherwise zero (IsZero=true). This
>>> value doesn't seem to survive a roundtrip to JSON. See this playground for
>>> a minimal reproduction: https://play.golang.org/p/QdglfKYkstS
>>>
>>> Is this expected, a bug, or an undefined behaviour? I checked RFC 3339,
>>> which time uses as the JSON serialization format, and it seems to support
>>> AD to AD, but I have to admit I know little about time.
>>>
>>
> RFC 3339 doesn't support sub-minute timezone offsets, so it's not possible
> to format the LMT zone precisely.
>
> I am concerned that the time printed is incorrect by 2 seconds in this
> case, and (I imagine) could be anywhere from 0 to 59 seconds off depending
> on the particular sub-minute timezone offset used. That seems like a real
> bug, and I don't know what a proper fix would look like. Perhaps when the
> timezone is formatted in numeric form, the printed time should be adjusted
> to account for the loss of precision in the zone info. In your case this
> would print "-12-31T19:04:00-04:56" instead
> of "-12-31T19:03:58-04:56". That solution has its own issues though.
>
> You probably should only use IsZero() to detect uninitialized time values;
> never on a value that's been parsed from any source, even JSON.
>
> To get arbitrary time values to survive a JSON round trip, I think using
> UTC exclusively would be the best option.
>
>
>>> Cheers,
>>> Robert
>>>
>> --
>> 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/CAOPAaN%2BWvZ73Z-oMVaGmDt-Gr5DEk7ZtQeU43x5fKrCFW42%3DqQ%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/CALRNMm0VN8030%2BQLY0sLr%2BuHfz4WoG7NfWe1RUHj-d2Zqh393Q%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/CAEkBMfFx13J%3DiSx7y_hPKNFd8WPO9gVSUz9H_PKsNKjfgnNMPA%40mail.gmail.com.

Re: [go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

[Matt Harden]

On Fri, Nov 27, 2020 at 4:14 PM 'Robert Ma' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Is this because the 2-second offset of LMT gets lost in RFC 3339
> representation?
>

Yes, that's exactly it.


> On Fri, Nov 27, 2020 at 6:33 PM Robert Ma  wrote:
>
>> Hi all,
>>
>> Time is complicated.
>>
>
Wibbly-wobbly, even.

Today I found myself in a rabbit hole. For some unrelated reason, I got a
>> time value in a non-UTC location that's otherwise zero (IsZero=true). This
>> value doesn't seem to survive a roundtrip to JSON. See this playground for
>> a minimal reproduction: https://play.golang.org/p/QdglfKYkstS
>>
>> Is this expected, a bug, or an undefined behaviour? I checked RFC 3339,
>> which time uses as the JSON serialization format, and it seems to support
>> AD to AD, but I have to admit I know little about time.
>>
>
RFC 3339 doesn't support sub-minute timezone offsets, so it's not possible
to format the LMT zone precisely.

I am concerned that the time printed is incorrect by 2 seconds in this
case, and (I imagine) could be anywhere from 0 to 59 seconds off depending
on the particular sub-minute timezone offset used. That seems like a real
bug, and I don't know what a proper fix would look like. Perhaps when the
timezone is formatted in numeric form, the printed time should be adjusted
to account for the loss of precision in the zone info. In your case this
would print "-12-31T19:04:00-04:56" instead
of "-12-31T19:03:58-04:56". That solution has its own issues though.

You probably should only use IsZero() to detect uninitialized time values;
never on a value that's been parsed from any source, even JSON.

To get arbitrary time values to survive a JSON round trip, I think using
UTC exclusively would be the best option.


>> Cheers,
>> Robert
>>
> --
> 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/CAOPAaN%2BWvZ73Z-oMVaGmDt-Gr5DEk7ZtQeU43x5fKrCFW42%3DqQ%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/CALRNMm0VN8030%2BQLY0sLr%2BuHfz4WoG7NfWe1RUHj-d2Zqh393Q%40mail.gmail.com.

[go-nuts] Re: Trying to understand HTTP connection pooling behaviour - new DNS lookup

[b.ca...@pobox.com]

Do you see a forward or reverse DNS lookup being made?

Can you provide a standalone program which demonstrates this behaviour?

I am wondering if either (a) something is logging when the connection is 
terminated, or (b) a new connection is automatically being made and put 
into a pool.

On Saturday, 28 November 2020 at 01:27:32 UTC amits...@gmail.com wrote:

> Hi, it seems that the http client automatically performs a DNS lookup when 
> an existing connection is terminated by the server. I simulated it via 
> changing the IP address in /etc/hosts.
>
> Can someone point me to the code where this logic is checked?
>
> I am looking at https://golang.org/src/net/http/transport.go but haven’t 
> found something yet - quite a beginner here.
>
> Thanks,
> Amit.
>
>

-- 
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/86f347d0-862f-4922-b2e4-e8835858ae90n%40googlegroups.com.

[go-nuts] Re: Give the zero time value a location, and it won't survive a roundtrip to JSON?

[b.ca...@pobox.com]

I didn't think that AD was a thing, even though RFC 3339 says it is.

Wikipedia says that dates in Common Era 
 and Dionysius BC/AD 
 are equivalent,  and that 1BC 
led straight onto 1AD.

-- 
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/540a6f0f-df1a-4e0f-9b74-a216e8e0fb45n%40googlegroups.com.

Re: [go-nuts] Estimating blockers for supporting gollvm on RISC-V (qemu). Fedora 33

[Ivan Serdyuk]

Jim,
adding you to the discussion.

I was not able to build gold, by configuring binutils, using

> ./configure --enable-gold
>
did not allow GNU make tool to build gold: many sub-directories were
processed, to compile the sources/generate files - but not the sub-dir. for
gold.
When I entered the "gold" dir. and ran "configure" script - it failed with
an error, which reported an unsupported arch. , under qemu.

Is there any way to compile gold?
Perhaps I have improper identification of the arch.?
Perhaps there is a working Makefile, for this (until "configure" would be
patched properly)?

What about cross-compiling (Linux x86_64 -> Linux 64bit RISC-V ) ?


 Ivan

On Tue, Nov 24, 2020 at 4:20 PM Ian Lance Taylor  wrote:

> On Tue, Nov 24, 2020 at 6:14 AM Richard W.M. Jones 
> wrote:
> >
> > One thing I'm missing: Why does golang need gold?
>
> The gccgo and GoLLVM compilers (which are not the most widely used Go
> compilers) require the gold linker for full support of stack
> splitting.  Stack splitting is used to ensure that goroutines do not
> run out of stack space.  Stack splitting is supported by gold and lld,
> but, as far as I know, is not supported by the GNU linker.
>
> However, the bulk of stack splitting support is in the compiler,   At
> least for GCC, stack splitting is only supported on x86, PPC, and
> S/390.  So at least until stack splitting support is added for RISC/V,
> there is no particular reason to require the gold linker for RISC/V.
>
> (It does seem a shame that people are thinking of deprecating gold,
> but it's certainly true that I have not had time to maintain it.)
>
> 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/CANFCsz9EdJWL87oX%2BeLrzBbK5m%3DFzwVs6Z8RQ55feJ34v%2BH42Q%40mail.gmail.com.