[go-nuts] [ generics ] Added constraint type inference to the design draft

[Ian Lance Taylor]

I just added a new section to the generics design draft describing
constraint type inference.  This is a generalization and
simplification of the earlier pointer method approach, which has now
been removed.  I would be happy to hear any comments.  Thanks.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference

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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com.

Re: [go-nuts] Seperate debuginfo?

['Ethan Pailes' via golang-nuts]

Wow, that works perfectly! Thank you so much!

The --add-gnu-debuglink=x.debug bit was what I was missing.

Unfortunately, it doesn't seem like delve supports separate debug info yet, 
so I'll have to stick with gdb in these situations.

Also, it seems that upx[1] breaks the debuglink, which doesn't seem 
entirely unreasonable (I'm mostly including this tidbit in case someone 
else in a similar situation to mine finds this post)

[1]: https://upx.github.io/

On Wednesday, August 12, 2020 at 12:26:24 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Aug 12, 2020 at 8:43 AM ethan.pailes via golang-nuts 
> > wrote: 
> > 
> > The C ecosystem allows one to generate a separate file containing debug 
> info so that you can initially install a stripped library or binary and 
> then only pull in the debug info as needed. I'm interested in doing the 
> same for go, but I have not been able to find an equivalent to the 
> -gsplit-dwarf compiler flag. I've tried using `objcopy --only-keep-debug` 
> to generate a .debug file, but it didn't seem to take. 
> > 
> > Has anyone else gone down this road? I would also be glad to hear that 
> this is just known not to be possible at this point so that I can stop 
> digging. 
> > 
> > For a little context as to why I want to do this, we are using go on 
> embedded devices and we would like to keep our payload size down for OTA 
> updates so we would rather avoid shipping debug info that will only be used 
> rarely. 
>
> I would expect the objcopy approach to work. 
>
> go build x 
> objcopy --only-keep-debug x x.debug 
> objcopy --strip-debug --add-gnu-debuglink=x.debug x x.stripped 
>
> Where does that go wrong? 
>
> 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/b6d292e8-8dd6-432b-8f99-6ed87ae0d321o%40googlegroups.com.

[go-nuts] Re: Pipe multiple commands in golang

[Tamás Gulácsi]

cmdStrings := exec.Command("strings", dynamicFilePath)
cmdRegex := exec.Command("grep", "regex")
cmdRegex.Stdin = cmdStrings.Stdout
if err := cmdRegex.Start(); ...
if err := cmdStrings.Run(); ...
if err := cmdRegex.Wait();...


Or use http://labix.org/pipe 

santhoshth...@gmail.com a következőt írta (2020. augusztus 12., szerda, 
17:41:39 UTC+2):

> Hi all,
>
> I have requirement to execute a command like cmd : *strings 
> dynamic_file_path | grep regex*
>
> I don't know what is the best way to do this like any well known library 
> or standard way.
>
> Can you please help here?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b679e9f0-5ed0-46ca-a4e2-11785df7d5c6n%40googlegroups.com.

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

On Mon, Aug 10, 2020 at 8:30 PM Ian Lance Taylor  wrote:

> On Mon, Aug 10, 2020 at 6:07 AM Markus Heukelom
>  wrote:
> >
> > For what it is worth: for non-exported functions/types all operations
> could be allowed, possibly leading to infamous C++-level error messages but
> as you are the author of the package, those error messages would make sense
> to you anyway.
> >
> > For example, I could really use to be able to write things like this:
> >
> > func sibling[type t](node *t) *t {
> > if node.parent == nil {
> > return nil
> > }
> > if node.parent.left == node {
> > return node.parent.right
> >   }
> >   return node.parent.left
> > }
> >
> > This is not really possible with the current design. Of course I could
> specify an interface with getters/setters, but that feels a bit silly and
> cumbersome as everything is local to the package anyway.
> >
> > I don't have better a solution, but all contracts/constraints do is
> prevent long, unreadable error messages while inside a package there's no
> real problem with those error messages to begin with.
>
> Go is a strictly typed languages, and constraints are the meta-types
> of type parameters.


I just realised there might be a distinction between strictly typed and
strongly typed languages. Would it be correct to say C++ is strongly typed,
but not strictly typed wrt templates (up C++20 at least)? Did you mean it
in that sense?

You are suggesting that we should have an escape
> hatch for that meta-type system when using unexported types.  I
> suppose that is possible.  It seems like something we could add later
> if it brings a big benefit.
>
>
I'm not sure when your example would really arise.  It looks like you
> have a tree type; why not make that a parameterized type and make
> sibling a method on the type?
>
>
Mainly for intrusive containers, see for example
https://www.boost.org/doc/libs/1_73_0/doc/html/intrusive.html

In my case I have two multi-index containers that are only used internally.
They use the same rebalancing algorithm and some other stuff for
adding/removing nodes, but I couldn't factor that out with the current
generics design. Well tbh I could define an interface maybe with getters
/setters for the fields but it feels a bit silly for internally used only
stuff. I do agree that it's very niche probably and it does not warrant the
addition of fields to interface constraints.



> 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/CAMoB8rWscmR3vQA5LFHpTPV4KhJzggUszF2HKUA-LoMFNfkoHA%40mail.gmail.com.

Re: [go-nuts] Seperate debuginfo?

[Ian Lance Taylor]

On Wed, Aug 12, 2020 at 8:43 AM ethan.pailes via golang-nuts
 wrote:
>
> The C ecosystem allows one to generate a separate file containing debug info 
> so that you can initially install a stripped library or binary and then only 
> pull in the debug info as needed. I'm interested in doing the same for go, 
> but I have not been able to find an equivalent to the -gsplit-dwarf compiler 
> flag. I've tried using `objcopy --only-keep-debug` to generate a .debug file, 
> but it didn't seem to take.
>
> Has anyone else gone down this road? I would also be glad to hear that this 
> is just known not to be possible at this point so that I can stop digging.
>
> For a little context as to why I want to do this, we are using go on embedded 
> devices and we would like to keep our payload size down for OTA updates so we 
> would rather avoid shipping debug info that will only be used rarely.

I would expect the objcopy approach to work.

go build x
objcopy --only-keep-debug x x.debug
objcopy --strip-debug --add-gnu-debuglink=x.debug x x.stripped

Where does that go wrong?

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/CAOyqgcU-_Jw_Zk%2BWksxNB9T2t02hTzNQuURwSzuxi97TLknLPw%40mail.gmail.com.

Re: [go-nuts] Pipe multiple commands in golang

[Marcin Romaszewicz]

You have two options here.

One, is you execute a shell, and just tell the shell to run your command,
eg bash -c "strings dynamic_file_path | grep regex".

The other option is that you exec strings and grep independently, and
connect the two of them using an os.pipe, but it's a lot more work to do
this and get exiting working properly - you must close the pipe when either
side has an error, etc.



On Wed, Aug 12, 2020 at 8:41 AM thatipelli santhosh <
santhoshthatipelli...@gmail.com> wrote:

> Hi all,
>
> I have requirement to execute a command like cmd : *strings
> dynamic_file_path | grep regex*
>
> I don't know what is the best way to do this like any well known library
> or standard way.
>
> Can you please help here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAN1Sb7y2DdZJP30cfxRKr%3DFKgFsc1Kp%2Bdzqe0pd3qAt4JDg6LQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LsnJHJrULbeb9VJjMh2mbLaArWM4uvuBH6fqLCAs0B8_A%40mail.gmail.com.

[go-nuts] Seperate debuginfo?

[ethan.pailes via golang-nuts]

The C ecosystem allows one to generate a separate file containing debug 
info so that you can initially install a stripped library or binary and 
then only pull in the debug info as needed. I'm interested in doing the 
same for go, but I have not been able to find an equivalent to the 
-gsplit-dwarf compiler flag. I've tried using `objcopy --only-keep-debug` 
to generate a .debug file, but it didn't seem to take.

Has anyone else gone down this road? I would also be glad to hear that this 
is just known not to be possible at this point so that I can stop digging.

For a little context as to why I want to do this, we are using go on 
embedded devices and we would like to keep our payload size down for OTA 
updates so we would rather avoid shipping debug info that will only be used 
rarely.

Thanks!
Ethan

-- 
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/e6fcd75b-ebdd-4a05-ad76-0db739806f46o%40googlegroups.com.

Re: [go-nuts] "Interfaces" with type lists are a strange beast

[李晓辉]

Maybe `type list` equals to `sum type`

type SignedInteger interface {
   type int, int8, int16, int32, int64
}

can replaced by 

type SignedInteger int|int8|int16|int32|int64


func max[type I SignedInteger](a I, b I) I {
   if a > b { return a }
   return b
}


在2020年8月9日星期日 UTC+8 下午11:54:38 写道：

> On second thought, that would lead to ‘operator overloading’ and the 
> abuses it invites - so oh well - I guess we write duplicate methods based 
> on types - which is pretty much what you can do now - write a base 
> implementation using interface{} and then a small wrapper struct that types 
> it. Given that, based on the current proposal, I go back to the position 
> that Go doesn’t need generics.
>
> > On Aug 8, 2020, at 11:43 AM, Robert Engels  wrote:
> > 
> > Understood. Even if you keep operators they could be mapped to certain 
> built in interface methods. C++ has operator loading, Java does not (except 
> for auto-boxing) It seems Go generics are trying to play in the middle and 
> I think the end result is going to lead to confusing code, but we shall 
> see. 
> > 
> >> On Aug 8, 2020, at 11:16 AM, Ian Lance Taylor  wrote:
> >> 
> >> On Fri, Aug 7, 2020 at 6:54 PM Robert Engels  
> wrote:
> >>> 
> >>> I’d really like to see an example of generic code that takes both 
> string and numeric types that uses operators. Sorting/searching is one but 
> as I already said the built in string operators are not sufficient for 
> collation cases.
> >>> 
> >>> Even generic code that “only works on unsigned types”.
> >>> 
> >>> More than 90% of all generic code is collections. Operators are not 
> needed for these.
> >> 
> >> I don't think I have anything useful to add to what I've said already
> >> on this topic.
> >> 
> >> I believe that being able to write a Min function in ordinary Go is an
> >> absolute requirement for generics in Go. Full stop.
> >> 
> >> It would be great to hear about any fatal problems that type lists
> >> have. It would be great to hear about alternative approaches that
> >> support operators. I don't think it's useful to debate whether we
> >> need to be able to use operators in generic code.
> >> 
> >> Ian
> >> 
> >> 
> >> 
> > On Aug 6, 2020, at 2:45 PM, burak serdar  
> wrote:
>  
>  On Thu, Aug 6, 2020 at 1:17 PM Ian Lance Taylor  
> wrote:
> > 
> >> On Thu, Aug 6, 2020 at 12:10 PM Robert Engels  
> wrote:
> >> 
> >> We’ll probably agree to disagree there. Java has a lot of generic 
> code written and it’s never been a problem (using methods). Rarely can you 
> write code that treats + the same no matter if passed a string or numeric.
> >> 
> >> Even operators like < with strings don’t really make a lot of sense 
> because different collations are used.
> >> 
> >> I think having a higher bar for Go generic implementations is fine 
> - writing generic code properly is harder than regular Go - there’s much 
> more to resin about.
> > 
> > I hope that is not the case.
> > 
> > Also, it's important that it be easy to read generic code. We can put
> > extra burdens on writers of generic code if necessary, but we must
> > make the burden on readers of generic code as small as we possibly
> > can.
> > 
> > And again: is the complexity from requiring methods rather than
> > operators really less than the complexity of using type lists?
>  
>  There are things you can do with type lists that you cannot do with
>  operators. You can limit a function to run on unsigned numbers, for
>  instance. I think it also makes it explicit to the reader that
>  a.Add(b) is possibly more complicated than a+b.
>  
> > 
> > Ian
> > 
> > 
> > 
> >>> On Aug 6, 2020, at 1:53 PM, Ian Lance Taylor  
> wrote:
> >>> 
> >>> On Wed, Aug 5, 2020 at 8:52 PM Robert Engels <
> ren...@ix.netcom.com> wrote:
>  
>  I understand your point, but I think a few minor corrections Make 
> a difference - it does not matter that String supports + and not - , a 
> string would not be a Number. String concatenation is not addition.
> >>> 
> >>> My point wasn't that a string is a number. My point was that the
> >>> current design draft permits writing a function that uses + and 
> works
> >>> with both strings and numbers. If we adopt something along the 
> lines
> >>> of what you are suggesting, we must either define a name for "types
> >>> that support +" or we must say "you can't write a generic function
> >>> that uses + and works with both strings and numbers."
> >>> 
> >>> 
>  There are also several ways to implement “ordering” with complex 
> numbers, even between complex and rational - it’s all a matter of 
> definition. There is also the possibility to make complex not a Comparable 
> (compile time failure).
> >>> 
> >>> In Go, the types complex64 and complex128 do not support the < <= 
> >= >
> >>> 

[go-nuts] Pipe multiple commands in golang

[thatipelli santhosh]

Hi all,

I have requirement to execute a command like cmd : *strings
dynamic_file_path | grep regex*

I don't know what is the best way to do this like any well known library or
standard way.

Can you please help here?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN1Sb7y2DdZJP30cfxRKr%3DFKgFsc1Kp%2Bdzqe0pd3qAt4JDg6LQ%40mail.gmail.com.

[go-nuts] Re: Raw http2 with TLS

[Ian Gudger]

I figured it out. ServeConn expects Handshake to have been called on the
tls.Conn.

It is unclear to me what an appropriate fix would be. Maybe just update the
documentation for http2.(*Server).ServeConn?

On Tue, Aug 11, 2020 at 11:06 AM Ian Gudger  wrote:

> I am trying to use the http2.Server directly. I can't use the standard
> library http.Server because it has a hard dependency on receiving a
> *tls.Conn for http2 and I would like to use a wrapper. For now though, I am
> trying to get http2.Server working with the bare tls types. I am using what
> seems like the simplest way to use it, but it doesn't work and I am having
> trouble figuring out why. It seems that my handler is never executed and my
> browser returns ERR_CONNECTION_CLOSED.
>
> Usage that doesn't work:
>
>> l, err := net.Listen("tcp", ":8443")
>> if err != nil {
>> panic(err)
>> }
>> l = tls.NewListener(l, {NextProtos:
>> []string{http2.NextProtoTLS}, Certificates: []tls.Certificate{rootTLSCert}})
>> var srv http2.Server
>> opts := http2.ServeConnOpts{Handler: http.HandlerFunc(func(w
>> http.ResponseWriter, r *http.Request) {
>> w.Write([]byte("hello world"))
>> })}
>> for {
>> c, err := l.Accept()
>> // TODO: Handle temporary errors.
>> if err != nil {
>> panic(err)
>> }
>> go srv.ServeConn(c, )
>> }
>
>
>
>

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