[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.

[go-nuts] Go program generates stand-alone C code for AVX-512 neural nets

[37ef ced3]

Generated C code can be used in Go programs via Cgo: https://NN-512.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/9757b364-5158-4e2d-8681-6da1e3d07f93n%40googlegroups.com.

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

[Michael Jones]

Matt’s formatting example suggests interval arithmetic for time. That is a
nice idea.

On Sat, Nov 28, 2020 at 2:22 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> 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
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 

[go-nuts] Re: crypto/tls/generate_cert.go: Should it be used? And how can it be used?

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

On Sunday, 29 November 2020 at 21:09:24 UTC Jeroen N. Witmond wrote:

>  go run `locate generate_cert.go` --host 127.0.0.1 --rsa-bits=2048 --ca 
>
>
That will only work if there's exactly one instance of generate_cert.go on 
your filesystem.

A better command is:
go run "$(go env GOROOT)/src/crypto/tls/generate_cert.go" ...etc

Or you can just download generate_cert.go directly from github 

.

Or should crypto/tls/generate_cert.go not be referred to at all?
>
>
I think it's helpful to mention it.  It's not hard to find - after all, it 
does say it's in crypto/tls.

-- 
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/2984eada-27b1-4e59-82a5-e254e5caa91bn%40googlegroups.com.

[go-nuts] crypto/tls/generate_cert.go: Should it be used? And how can it be used?

[Jeroen N. Witmond]

Greetings,

The documentation https://golang.org/pkg/net/http/#example_ListenAndServeTLS
 states
(in the example's comment) "One can use generate_cert.go in crypto/tls to 
generate cert.pem and key.pem."

In trying to find out how to do this I came across (closed) 
https://github.com/golang/go/issues/19900 As a result I found another way 
to invoke it: go run `locate generate_cert.go` --host 127.0.0.1 
--rsa-bits=2048 --ca 

Should the comment in the example of 
https://golang.org/pkg/net/http/#example_ListenAndServeTLS be changed to be 
more exact in the way crypto/tls/generate_cert.go can be invoked? Or 
should crypto/tls/generate_cert.go not be referred to at all?

Should I open an issue about this?

Jeroen.

-- 
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/c4b07c10-cf7c-489b-8fc7-1f7720916968n%40googlegroups.com.

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

[peterGo]

On Saturday, November 28, 2020 at 3:59:21 PM UTC-5 Constantine Vassilev 
wrote:

> 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
>
 For the moment. The tip is constantly updated for development and bug 
fixes.

Go Build Dashboard

https://build.golang.org/

To test leading-edge features, update the tip regularly. For example, I 
perform a git pull and make.bash every day.

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/d30122e4-b79f-4bc3-a6d4-216f2dca2f11n%40googlegroups.com.

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

[Fino]

I see, thanks! 

it turns out I need a modern C.

TinyGo, Vlang are my list.  
Rust is too heavy for embedded system, and difficult for whole team to 
master.

maybe let Vlang do the real-time threads and Go do the non real-time 
threads, 
link them together into one process/uni-kernel is good balance in 
production.

BR fino

在2020年11月29日星期日 UTC+8 下午8:07:28 写道：

> You should review Java RTS for a similar design and it’s pros and cons. 
>
> It is definitely doable - but you end up writing C code as Java - or in 
> this case Go. 
>
> On Nov 29, 2020, at 1:45 AM, Fino  wrote:
>
>

-- 
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/b2daaffb-9ee8-4943-b2d7-bce34a7d10ccn%40googlegroups.com.

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

[Robert Engels]

You should review Java RTS for a similar design and it’s pros and cons. 

It is definitely doable - but you end up writing C code as Java - or in this 
case Go. 

> On Nov 29, 2020, at 1:45 AM, Fino  wrote:
> 
> 
> 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.

-- 
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/1FFF694B-EFBD-4B51-94C7-81B3FAB48977%40ix.netcom.com.