Re: [go-nuts] Generics: after type lists

[Ian Lance Taylor]

On Tue, Aug 11, 2020 at 8:47 PM robert engels  wrote:
>
> Isn’t the example with big.Float only a problem because of the pointer based 
> design - which is much harder to write code with than a immutable value based 
> one.
>
> Then you have
>
> D = A.Add(B).Add(C)
>
> with
>
> (Number n) func Add(a Number) Number
>
> Which is straightforward, and the compiler creates the temp storage on the 
> stack for intermediate results.
>
> To perform similar math using pointer based methods you have to use 
> ‘accumulator’ math, and most likely lots of temp variables - and the 
> resulting number of allocations on the stack is probably the same.

Sure, but my point is that there is a chain of hypotheticals here.
You are describing a possible type that as far as I know does not
exist in the wild.  I think that the overall argument that Patrick is
presenting only holds if at least one such type does exist, and if
that type is used widely enough that it's worth writing algorithms
that work both for that type and for builtin types.  It's definitely
possible.  But as far as I know at present it's an entirely
hypothetical situation.  That doesn't mean we shouldn't consider it.
But it does mean that we should also consider how likely it is to
arise.

Ian



> > On Aug 11, 2020, at 10:31 PM, Ian Lance Taylor  wrote:
> >
> > On Tue, Aug 11, 2020 at 4:19 PM Patrick Smith  wrote:
> >>
> >> On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor  wrote:
> >>> If we accept this argument, then in Go it wouldn't be appropriate to
> >>> write a single function that works on both builtin and user-defined
> >>> types.
> >>
> >> This I disagree with; what you regard as inappropriate, I see as a
> >> desirable goal. The question is whether there is a reasonable way to
> >> achieve it, one for which the benefits outweigh the costs.
> >>
> >> Before I explain why I disagree, let me mention that sorting was
> >> perhaps not the best example for me to have used. It is very common to
> >> sort things in an order different than the default (e.g. integers in
> >> reverse order), or to sort things that don't have a default order
> >> (e.g. countries by area, population, or date of formation). For this
> >> reason, sort functions in any language very often accept a comparison
> >> function.
> >>
> >> A better example might be a function that finds the roots of a
> >> polynomial with real-valued coefficients, where the coefficients are
> >> taken from a type F that might be float32, float64, or a user-defined
> >> type such as one based on big.Float. In this function, we want to use
> >> the default arithmetic operations provided by F. It would be very
> >> unusual to override those with a different choice of operations.
> >>
> >> But in the type lists approach, unless we write two distinct versions
> >> of the function, we must use an adaptor type or object (or multiple
> >> adaptor functions) to indicate to the function what arithmetic
> >> operations to use. There is no way for the function to access these
> >> operations otherwise (except reflection).
> >
> > Thanks, it's an interesting example.  big.Float isn't really the same
> > as float32 or float64.  For example, big.Float doesn't provide any way
> > to write "a = b + c + d".  You can only write, in effect, "a = b + c;
> > a += d".  And big.Float doesn't have == != < <= >= >.  Instead it has
> > expressions like "a.Cmp(b) == 0".  So if you want to write a generic
> > function that works on float32/float64/big.Float, you're going to need
> > adaptors no matter what.  You can't avoid them.
> >
> > So in practice I don't think we're going to write the root-finding
> > function using parametric polymorphism at all.  I think we're going to
> > write it using an interface type.  And I think we're going to base
> > that interface type on big.Float.  Then we need to write an
> > implementation of that interface for float32/float64.  And that
> > implementation is likely to use parametric polymorphism so that we
> > only have to write it once to handle both float32 and float64.  And
> > for that implementation, type lists work fine.
> >
> >
> > What you're looking for here, I think, is a case where there is a type
> > A that implements methods that are isomorphic to the basic arithmetic
> > and/or comparison operators.  And then you want an algorithm that can
> > be used with that type, as well as with the builtin types.  For such a
> > case, it might be nice to be able to write that algorithm only once.
> >
> > And, of course, with the current design draft, we can write the
> > algorithm only once, provided we write it using methods.  We will use
> > the methods defined by the type A.  And we will need an adapter for
> > builtin types to implement those methods.  And that adaptor can be
> > written using type lists.
> >
> > Now, I think your original argument is that in the future we might
> > decide to introduce operator methods.  And we might add those operator
> > methods to A.  And then we can 

Re: [go-nuts] Generics: after type lists

[robert engels]

Isn’t the example with big.Float only a problem because of the pointer based 
design - which is much harder to write code with than a immutable value based 
one.

Then you have

D = A.Add(B).Add(C)

with

(Number n) func Add(a Number) Number

Which is straightforward, and the compiler creates the temp storage on the 
stack for intermediate results.

To perform similar math using pointer based methods you have to use 
‘accumulator’ math, and most likely lots of temp variables - and the resulting 
number of allocations on the stack is probably the same.

> On Aug 11, 2020, at 10:31 PM, Ian Lance Taylor  wrote:
> 
> On Tue, Aug 11, 2020 at 4:19 PM Patrick Smith  wrote:
>> 
>> On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor  wrote:
>>> If we accept this argument, then in Go it wouldn't be appropriate to
>>> write a single function that works on both builtin and user-defined
>>> types.
>> 
>> This I disagree with; what you regard as inappropriate, I see as a
>> desirable goal. The question is whether there is a reasonable way to
>> achieve it, one for which the benefits outweigh the costs.
>> 
>> Before I explain why I disagree, let me mention that sorting was
>> perhaps not the best example for me to have used. It is very common to
>> sort things in an order different than the default (e.g. integers in
>> reverse order), or to sort things that don't have a default order
>> (e.g. countries by area, population, or date of formation). For this
>> reason, sort functions in any language very often accept a comparison
>> function.
>> 
>> A better example might be a function that finds the roots of a
>> polynomial with real-valued coefficients, where the coefficients are
>> taken from a type F that might be float32, float64, or a user-defined
>> type such as one based on big.Float. In this function, we want to use
>> the default arithmetic operations provided by F. It would be very
>> unusual to override those with a different choice of operations.
>> 
>> But in the type lists approach, unless we write two distinct versions
>> of the function, we must use an adaptor type or object (or multiple
>> adaptor functions) to indicate to the function what arithmetic
>> operations to use. There is no way for the function to access these
>> operations otherwise (except reflection).
> 
> Thanks, it's an interesting example.  big.Float isn't really the same
> as float32 or float64.  For example, big.Float doesn't provide any way
> to write "a = b + c + d".  You can only write, in effect, "a = b + c;
> a += d".  And big.Float doesn't have == != < <= >= >.  Instead it has
> expressions like "a.Cmp(b) == 0".  So if you want to write a generic
> function that works on float32/float64/big.Float, you're going to need
> adaptors no matter what.  You can't avoid them.
> 
> So in practice I don't think we're going to write the root-finding
> function using parametric polymorphism at all.  I think we're going to
> write it using an interface type.  And I think we're going to base
> that interface type on big.Float.  Then we need to write an
> implementation of that interface for float32/float64.  And that
> implementation is likely to use parametric polymorphism so that we
> only have to write it once to handle both float32 and float64.  And
> for that implementation, type lists work fine.
> 
> 
> What you're looking for here, I think, is a case where there is a type
> A that implements methods that are isomorphic to the basic arithmetic
> and/or comparison operators.  And then you want an algorithm that can
> be used with that type, as well as with the builtin types.  For such a
> case, it might be nice to be able to write that algorithm only once.
> 
> And, of course, with the current design draft, we can write the
> algorithm only once, provided we write it using methods.  We will use
> the methods defined by the type A.  And we will need an adapter for
> builtin types to implement those methods.  And that adaptor can be
> written using type lists.
> 
> Now, I think your original argument is that in the future we might
> decide to introduce operator methods.  And we might add those operator
> methods to A.  And then we can write our algorithm using operators.
> But we might have a chain of functions already built using (regular)
> methods, and we won't be able to use those with operator methods, so
> we will be discouraged from using operator methods.
> 
> So first let me observe that that seems to me like a pretty long chain
> of hypotheticals.  Is there any type out there today that has methods
> that correspond exactly to operators?  There is a reason that
> big.Float and friends don't have such methods: for any type that uses
> pointers, they are inefficient.  Is this possibility going to be a
> real problem, or will it always be a hypothetical one?
> 
> Second, let me observe that in this example it seems to me that we
> will already have the adapter types that add methods to the builtin
> types.  So the question would be: if we 

Re: [go-nuts] Generics: after type lists

[Ian Lance Taylor]

On Tue, Aug 11, 2020 at 4:19 PM Patrick Smith  wrote:
>
> On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor  wrote:
> > If we accept this argument, then in Go it wouldn't be appropriate to
> > write a single function that works on both builtin and user-defined
> > types.
>
> This I disagree with; what you regard as inappropriate, I see as a
> desirable goal. The question is whether there is a reasonable way to
> achieve it, one for which the benefits outweigh the costs.
>
> Before I explain why I disagree, let me mention that sorting was
> perhaps not the best example for me to have used. It is very common to
> sort things in an order different than the default (e.g. integers in
> reverse order), or to sort things that don't have a default order
> (e.g. countries by area, population, or date of formation). For this
> reason, sort functions in any language very often accept a comparison
> function.
>
> A better example might be a function that finds the roots of a
> polynomial with real-valued coefficients, where the coefficients are
> taken from a type F that might be float32, float64, or a user-defined
> type such as one based on big.Float. In this function, we want to use
> the default arithmetic operations provided by F. It would be very
> unusual to override those with a different choice of operations.
>
> But in the type lists approach, unless we write two distinct versions
> of the function, we must use an adaptor type or object (or multiple
> adaptor functions) to indicate to the function what arithmetic
> operations to use. There is no way for the function to access these
> operations otherwise (except reflection).

Thanks, it's an interesting example.  big.Float isn't really the same
as float32 or float64.  For example, big.Float doesn't provide any way
to write "a = b + c + d".  You can only write, in effect, "a = b + c;
a += d".  And big.Float doesn't have == != < <= >= >.  Instead it has
expressions like "a.Cmp(b) == 0".  So if you want to write a generic
function that works on float32/float64/big.Float, you're going to need
adaptors no matter what.  You can't avoid them.

So in practice I don't think we're going to write the root-finding
function using parametric polymorphism at all.  I think we're going to
write it using an interface type.  And I think we're going to base
that interface type on big.Float.  Then we need to write an
implementation of that interface for float32/float64.  And that
implementation is likely to use parametric polymorphism so that we
only have to write it once to handle both float32 and float64.  And
for that implementation, type lists work fine.


What you're looking for here, I think, is a case where there is a type
A that implements methods that are isomorphic to the basic arithmetic
and/or comparison operators.  And then you want an algorithm that can
be used with that type, as well as with the builtin types.  For such a
case, it might be nice to be able to write that algorithm only once.

And, of course, with the current design draft, we can write the
algorithm only once, provided we write it using methods.  We will use
the methods defined by the type A.  And we will need an adapter for
builtin types to implement those methods.  And that adaptor can be
written using type lists.

Now, I think your original argument is that in the future we might
decide to introduce operator methods.  And we might add those operator
methods to A.  And then we can write our algorithm using operators.
But we might have a chain of functions already built using (regular)
methods, and we won't be able to use those with operator methods, so
we will be discouraged from using operator methods.

So first let me observe that that seems to me like a pretty long chain
of hypotheticals.  Is there any type out there today that has methods
that correspond exactly to operators?  There is a reason that
big.Float and friends don't have such methods: for any type that uses
pointers, they are inefficient.  Is this possibility going to be a
real problem, or will it always be a hypothetical one?

Second, let me observe that in this example it seems to me that we
will already have the adapter types that add methods to the builtin
types.  So the question would be: if we add operator methods, can we
very easily shift those adaptor types from using type lists to using
operator methods instead?  And it seems to me that the answer is yes.
If we have operator methods, we will be able to write interface types
with operator methods.  And if we do that it would be very natural to
let the builtin types implement those interfaces.  And, of course, we
can use those interface types as constraints.  So we just have to
change the constraints that our adapter types use from type lists to
interface types with operator methods.  And everything else will work.
So, sure, operator methods might lead to some code tweaks.  But they
won't require a massive overhaul.

Or so it seems to me.  What am I missing?


> > I think this 

Re: [go-nuts] Generics: after type lists

[Patrick Smith]

Ian, thanks for taking the time to read and respond to my post.

On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor  wrote:
> If we accept this argument, then in Go it wouldn't be appropriate to
> write a single function that works on both builtin and user-defined
> types.

This I disagree with; what you regard as inappropriate, I see as a
desirable goal. The question is whether there is a reasonable way to
achieve it, one for which the benefits outweigh the costs.

Before I explain why I disagree, let me mention that sorting was
perhaps not the best example for me to have used. It is very common to
sort things in an order different than the default (e.g. integers in
reverse order), or to sort things that don't have a default order
(e.g. countries by area, population, or date of formation). For this
reason, sort functions in any language very often accept a comparison
function.

A better example might be a function that finds the roots of a
polynomial with real-valued coefficients, where the coefficients are
taken from a type F that might be float32, float64, or a user-defined
type such as one based on big.Float. In this function, we want to use
the default arithmetic operations provided by F. It would be very
unusual to override those with a different choice of operations.

But in the type lists approach, unless we write two distinct versions
of the function, we must use an adaptor type or object (or multiple
adaptor functions) to indicate to the function what arithmetic
operations to use. There is no way for the function to access these
operations otherwise (except reflection).

> I think this is open to question.  In C++, for example, std::sort
> takes an optional comparison class.  In effect, the default if no
> comparison class is provided is to use operator<.  That is a
> reasonable and appropriate choice for C++.  But Go does not have
> function overloading and does not have default values for arguments
> (https://golang.org/doc/faq#overloading).  So the natural way to write
> a sort function is to provide a comparison function.

That Go does not have default argument values is, I think, merely a distraction.
This is easily handled with multiple functions; one would like to write

func SortBy[type T](s []T, less func(T, T) bool) { ... }

func Sort[type T ...](s []T) {
SortBy(s, the_natural_order_on_T)
}

where the constraint on T in Sort expresses that T must have a natural ordering.

> If we accept this argument, then in Go it wouldn't be appropriate to
> write a single function that works on both builtin and user-defined
> types.  Writing such a function would be relying on some sort of
> default comparison function, which is not the typical Go approach.

But Go does have a default comparison for builtin types - the <
operator. This is used by sort.Ints, sort.Float64s, and sort.Strings.
With generics and type lists, it will be possible to combine these
into a single function that also works on other builtin types.

One can also give a user-defined type a default comparison, by
supplying a Less method (or Cmp, as in big.Int). The difficulty is
that without generics, there is no way to write a function
specification requiring the presence of such a method.

Generics with type lists simplify both of these cases, but do not give
us a way to unify them.

Another example - the String method of a type describes the default
way of displaying the type's values in text. For types with no String
method, there is a default builtin way.

And displaying values as text is so very useful that Go already
provides a family of functions to do this, and that work on both types
with a String method and types without String. This is the fmt
package, and it uses reflection internally to achieve this.

Try to imagine writing printing code if fmt.Print were replaced by
these two functions:

// Prints values in a fixed builtin way, ignoring any String method
that might exist.
func PrintB(a... interface{}) { ... }

type Stringer interface { String() string }

func PrintS(a... Stringer) { ... }

Or if fmt.Print became:

func Print[type T](func tostring(T) string, a ...T)

I think you will agree that it would be quite a bit more awkward than
with the existing fmt.Print.

> If we accept this argument, then in Go it wouldn't be appropriate to
> write a single function that works on both builtin and user-defined
> types.

And I must reply - not only is it appropriate, it is already done in
one of the most widely used packages in the standard library.

The question is, is there a reasonable way to make this easier in other cases?

-- 
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/CAADvV_sAfd%2Bx-Wu9WBP_2gGxJZcYX2acsAg4_w71Z5shebhvCA%40mail.gmail.com.

[go-nuts] [ANN] baraka: a library for handling file uploads memory-friendly

[Enes Furkan Olcay]

Hi,
I released a library for handling file uploads memory-friendly, simple than 
ParseMultipartForm.

You can block unwanted files from getting into memory.
You can get JSON data with files
check it out!

https://github.com/xis/baraka

-- 
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/de0904b4-d832-4b91-83c1-e2fb6ff457efn%40googlegroups.com.

[go-nuts] Go 1.15 is released

[Andrew Bonventre]

Hello gophers,

We just released Go 1.15

To find out what has changed in Go 1.15, read the release notes:
https://golang.org/doc/go1.15

You can download binary and source distributions from our download page:
https://golang.org/dl/

If you have Go installed already, an easy way to try go1.15
is by using the go command:
$ go get golang.org/dl/go1.15
$ go1.15 download

To compile from source using a Git clone, update to the release with
"git checkout go1.15" and build as usual.

Thanks to everyone who contributed to the release!

Cheers,
Andy and Dmitri for the Go Team

-- 
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/CAFPZzeQQ6o8M8u%2Bmvyf8DSyvhuFkVcY_jeuhE6LDYByCq8UBTw%40mail.gmail.com.

Re: [go-nuts] generics go2go Type List in Interface - Struct Type

['Axel Wagner' via golang-nuts]

Yes, it's intended. From the draft:

More precisely, the underlying type of the type argument must be identical
> to the underlying type of one of the types in the type list.


Type-lists match by underlying type of both argument and the types in the
type-list. As SantaHappy and SantaSad both have underlying type `struct{}`,
they are the same.

On Tue, Aug 11, 2020 at 10:59 PM Rich Moyse  wrote:

>
> Attempting to use a Type List in an Interface
> 
> to restrict the types allowed to instantiate a generic function (example
> in go2go ).  The Type List
> within the Constraint Interface (Santa) contains only one struct type
>  (SantaSad).  This struct type
> and a second, independent struct type (SantaHappy) both implement the
> Constraint Interface (Santa) specified as a type parameter for the generic
> function.  Given this situation, I expected the instantiation of the
> generic function with a type argument of the type (SantaSad), that appears
> in the Constraint's Interface Type List to succeed, which it does, and
> instantiating the generic function with the struct type, absent from the
> Type List (SantaHappy), to fail.  However, instead of failing, this second
> case succeeds.  Is this the intended behavior?
>
>
> --
> 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/44b6cb78-d143-437f-b4e0-f1cf8d642989n%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/CAEkBMfF5TThWSMZ4SEN_k79J5V1p6C-GD-uo96cM3Ud%3DkEybKA%40mail.gmail.com.

[go-nuts] generics go2go Type List in Interface - Struct Type

[Rich Moyse]

Attempting to use a Type List in an Interface 

 
to restrict the types allowed to instantiate a generic function (example in 
go2go ).  The Type List within 
the Constraint Interface (Santa) contains only one struct type 
 (SantaSad).  This struct type 
and a second, independent struct type (SantaHappy) both implement the 
Constraint Interface (Santa) specified as a type parameter for the generic 
function.  Given this situation, I expected the instantiation of the 
generic function with a type argument of the type (SantaSad), that appears 
in the Constraint's Interface Type List to succeed, which it does, and 
instantiating the generic function with the struct type, absent from the 
Type List (SantaHappy), to fail.  However, instead of failing, this second 
case succeeds.  Is this the intended behavior?


-- 
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/44b6cb78-d143-437f-b4e0-f1cf8d642989n%40googlegroups.com.

Re: [go-nuts] How do disable vDSO for i386 and use linker script?

[Ian Lance Taylor]

On Tue, Aug 11, 2020 at 12:26 PM  wrote:
>
> I also have a quick follow up question based on #1 here:
>
> >> 1. Is it possible to completely disable use of the vDSO for i386/Linux 
> >> programs? If so, is this done at build time, or automatically by the go 
> >> runtime?
>
> >There is no way to disable use of the VDSO if it is present on the system.
>
> The VDSO is not present on my target OS, but it is present on the OS building 
> the binary, which is amd64 Linux compiling for i386 Linux. To your knowledge, 
> is there anything that I need to do so that VDSO is not used by a pure go 
> program compiled with the standard toolchain? Will the go runtime detect the 
> absence of AT_SYSINFO_EHDR in the aux vector at runtime and use INT 0x80 
> instead?

Yes: if there is no AT_SYSINFO_EDHR at runtime, the Go runtime will
use int 0x80 for all system calls.  This is independent of whether the
VDSO exists at build time.

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/CAOyqgcVAkUQoyCqSxXHVJ32Kf-%2BtpSWcEVw%2BqpLibtE1Z5%3D5Pw%40mail.gmail.com.

Re: [go-nuts] How do disable vDSO for i386 and use linker script?

[evan . mesterhazy]

Thanks, Ian - this is very helpful.

To address your question - the VDSO references all appear to be associated 
with libc. There are 284 `call *%gs:0x10` instructions in the binary. I 
haven't looked at all of them, but the ones that I have reviewed are inside 
libc symbols. Stepping over the program, the first time the VDSO is used is 
inside __geteuid, which is called by __libc_init_secure. 

The call graph looks like this:

_start -> __libc_start_main -> __libc_init_secure -> __geteuid


I also have a quick follow up question based on #1 here:

>> 1. Is it possible to completely disable use of the vDSO for i386/Linux 
programs? If so, is this done at build time, or automatically by the go 
runtime? 

>There is no way to disable use of the VDSO if it is present on the system.

The VDSO is not present on my target OS, but it is present on the OS 
building the binary, which is amd64 Linux compiling for i386 Linux. To your 
knowledge, is there anything that I need to do so that VDSO is not used by 
a pure go program compiled with the standard toolchain? Will the go runtime 
detect the absence of AT_SYSINFO_EHDR in the aux vector at runtime and use 
INT 0x80 instead?

Thanks,
Evan

On Tuesday, August 11, 2020 at 2:05:46 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Aug 11, 2020 at 8:12 AM > 
> wrote: 
> > 
> > I am attempting to build a simple hello-world go program for a custom 
> operating system that provides compatibility with a subset of Linux 
> syscalls through the INT 0x80 syscall inferface. 
> > 
> > My understanding is that go uses the Linux vDSO for time functions, but 
> that otherwise it uses INT 0x80 for syscalls. What I am not 100% sure of is 
> whether go automatically uses INT 0x80 on i386 if the kernel does not 
> provide a pointer to the vDSO in the aux vector. I found this issue on the 
> tracker, but it addresses amd64 instead of i386. 
>
> The same thing happens on 386 GNU/Linux.  If the VDSO is not found at 
> program startup time, because there is no AT_SYSINFO_EHDR aux value, 
> then the runtime will fall back to using int 0x80. 
>
>
> > 1. Is it possible to completely disable use of the vDSO for i386/Linux 
> programs? If so, is this done at build time, or automatically by the go 
> runtime? 
>
> There is no way to disable use of the VDSO if it is present on the system. 
>
>
> > Secondly, I need to use a custom linking script to build my program so 
> that it can be loaded into the user address space designated by the OS. I 
> tried doing this with the following command, but this seems to have linked 
> my hello-world program with glibc code and introduced gratuitous usage of 
> the vDSO via CALL *%gs:0x10. 
> > 
> > 
> > CGO_ENABLED=0 GOARCH=386 go tool link -v -linkmode external -extldflags 
> "-static -Ti386.ld" hello.o 
>
> This will link against libc, but I wouldn't expect it to actually use 
> anything from libc.  Where are the VDSO references coming from? 
>
>
> > 2. Is it possible to feed a linker script into the default go linker 
> similar to gcc's "-T" option? 
>
> No.  You can use the -T option to set the text segment address, but 
> there is no support for general linker scripts. 
>
>
> > 3. Is it possible to link go programs using gcc without also linking in 
> glibc code? The command above generates the host link command below, which 
> seems to link lpthread. 
>
> I don't think so, at least not easily.  Once you invoke the external 
> linker, it's going to expect to use the glibc startup code. 
>
>
> > One idea I had for this is to use the gccgo front end to compile the 
> program under the assumption that I will be able to have more control over 
> the linker flags since the assembler will output a standard object file 
> instead of go's proprietary format. Is there merit to this approach? 
>
> Yes, that is likely true. 
>
> > I am also curious why lpthread is linked at all when using -linkmode 
> external. I thought that the go runtime provided its own threading 
> implementation, making lpthread unnecessary. It's also unclear to my why 
> glibc code would be linked in considering that CGO_ENABLED=0 is set. Am I 
> misunderstanding what the linker is doing here? 
>
> The external linker normally expects that you are using cgo.  When 
> using cgo, threads are created using pthread_create.  Only when not 
> using cgo, and not using glibc, does the Go runtime use the clone 
> system call directly. 
>
> 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/e4648041-b8c5-4de9-88a9-1ac5856d5f36o%40googlegroups.com.

[go-nuts] [generics] Violates beauty ethos

[Oliver Smith]

I recognize the hefty constraints in introducing generics, but for me the 
most egregious part is the cognitive and visual overhead it introduces by 
pushing more and more stuff off-screen-right and the processing overhead of 
so many sequences of parens on the same line.

My key thought is "the same line".

Could I suggest, to convert an extension of the 'type' construct:

go
func divide(a, b int) (int, error) {
if b == 0 {
return 0, DivideByZero
}
return a/b
}
```

becomes

```go
type divide generic { type V, type D }
func divide(a V, b D) (int, error) {
...
}
```

and potentially the ability to be selective about types:

type divide generic { type V union { type int, type uint, type float }, 
type D }
func divide ...

-- 
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/ef88da06-f993-4d98-a4ac-81e79b1fe775n%40googlegroups.com.

[go-nuts] Raw http2 with TLS

[Ian Gudger]

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

Re: [go-nuts] How do disable vDSO for i386 and use linker script?

[Ian Lance Taylor]

On Tue, Aug 11, 2020 at 8:12 AM  wrote:
>
> I am attempting to build a simple hello-world go program for a custom 
> operating system that provides compatibility with a subset of Linux syscalls 
> through the INT 0x80 syscall inferface.
>
> My understanding is that go uses the Linux vDSO for time functions, but that 
> otherwise it uses INT 0x80 for syscalls. What I am not 100% sure of is 
> whether go automatically uses INT 0x80 on i386 if the kernel does not provide 
> a pointer to the vDSO in the aux vector. I found this issue on the tracker, 
> but it addresses amd64 instead of i386.

The same thing happens on 386 GNU/Linux.  If the VDSO is not found at
program startup time, because there is no AT_SYSINFO_EHDR aux value,
then the runtime will fall back to using int 0x80.


> 1. Is it possible to completely disable use of the vDSO for i386/Linux 
> programs? If so, is this done at build time, or automatically by the go 
> runtime?

There is no way to disable use of the VDSO if it is present on the system.


> Secondly, I need to use a custom linking script to build my program so that 
> it can be loaded into the user address space designated by the OS. I tried 
> doing this with the following command, but this seems to have linked my 
> hello-world program with glibc code and introduced gratuitous usage of the 
> vDSO via CALL *%gs:0x10.
>
>
> CGO_ENABLED=0 GOARCH=386 go tool link -v -linkmode external -extldflags 
> "-static -Ti386.ld" hello.o

This will link against libc, but I wouldn't expect it to actually use
anything from libc.  Where are the VDSO references coming from?


> 2. Is it possible to feed a linker script into the default go linker similar 
> to gcc's "-T" option?

No.  You can use the -T option to set the text segment address, but
there is no support for general linker scripts.


> 3. Is it possible to link go programs using gcc without also linking in glibc 
> code? The command above generates the host link command below, which seems to 
> link lpthread.

I don't think so, at least not easily.  Once you invoke the external
linker, it's going to expect to use the glibc startup code.


> One idea I had for this is to use the gccgo front end to compile the program 
> under the assumption that I will be able to have more control over the linker 
> flags since the assembler will output a standard object file instead of go's 
> proprietary format. Is there merit to this approach?

Yes, that is likely true.

> I am also curious why lpthread is linked at all when using -linkmode 
> external. I thought that the go runtime provided its own threading 
> implementation, making lpthread unnecessary. It's also unclear to my why 
> glibc code would be linked in considering that CGO_ENABLED=0 is set. Am I 
> misunderstanding what the linker is doing here?

The external linker normally expects that you are using cgo.  When
using cgo, threads are created using pthread_create.  Only when not
using cgo, and not using glibc, does the Go runtime use the clone
system call directly.

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/CAOyqgcX%3DOTp%3D2DJK2jZJL37YCZSzUZ55wW-6Zn3Q1GE_Vgteyw%40mail.gmail.com.

Re: [go-nuts] Sum type experiment

[Sina Siadat]

Thanks for the link, Ian. I will have a look at it :)

-- 
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/81061d3b-419f-442c-a9a1-81d2d5db2896o%40googlegroups.com.

[go-nuts] How do disable vDSO for i386 and use linker script?

[evan . mesterhazy]

I am attempting to build a simple hello-world go program for a custom 
operating system that provides compatibility with a subset of Linux 
syscalls through the INT 0x80 syscall inferface.

My understanding is that go uses the Linux vDSO for time functions 
, but that otherwise 
 it uses INT 0x80 for syscalls. 
What I am not 100% sure of is whether go automatically uses INT 0x80 on 
i386 if the kernel does not provide a pointer to the vDSO in the aux 
vector. I found this issue  on 
the tracker, but it addresses amd64 instead of i386.


*1. Is it possible to completely disable use of the vDSO for i386/Linux 
programs? If so, is this done at build time, or automatically by the go 
runtime?*


Secondly, I need to use a custom linking script to build my program so that 
it can be loaded into the user address space designated by the OS. I tried 
doing this with the following command, but this seems to have linked my 
hello-world program with glibc code and introduced gratuitous usage of the 
vDSO via CALL *%gs:0x10.


CGO_ENABLED=0 GOARCH=386 go tool link -v -linkmode external -extldflags 
"-static -Ti386.ld" hello.o


*2. Is it possible to feed a linker script into the default go linker 
similar to gcc's "-T" option?*

*3. Is it possible to link go programs using gcc without also linking in 
glibc code? The command above generates the host link command below, which 
seems to link lpthread.*

One idea I had for this is to use the gccgo front end to compile the 
program under the assumption that I will be able to have more control over 
the linker flags since the assembler will output a standard object file 
instead of go's proprietary format. Is there merit to this approach?


I am also curious why lpthread is linked at all when using -linkmode 
external. I thought that the go runtime provided its own threading 
implementation, making lpthread unnecessary. It's also unclear to my why 
glibc code would be linked in considering that CGO_ENABLED=0 is set. Am I 
misunderstanding what the linker is doing here?


Thanks in advance,
Evan

-- 
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/8dde77a8-fd61-429c-abbf-96af6121e8c0o%40googlegroups.com.

Re: [go-nuts] Sum type experiment

[Ian Davis]

On Tue, 11 Aug 2020, at 3:38 PM, Sina Siadat wrote:
> Hi golang-dev :)
> 
> I was wondering what would be an idiomatic Go way
> to implement a basic sum type in Go. After several
> iterations I came up with 2 approaches I will share here.

You may be interested in the discussions on 
https://github.com/golang/go/issues/19412 if you haven't already seen them.

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/6e9619d0-d232-4d2b-85b9-1ef5e3bf2634%40www.fastmail.com.

[go-nuts] Sum type experiment

[Sina Siadat]

Hi golang-dev :)

I was wondering what would be an idiomatic Go way
to implement a basic sum type in Go. After several
iterations I came up with 2 approaches I will share here.

(1) Group types in an interface

The first approach does not require any new tools
and is statically checked by Go1 compilers.  In
this approach, I group several types by having
them implement a common interface whose sole
purpose is to group those types. Here is an
example:

type IPv4 [4]byte
type IPv6 [16]byte

type IP interface {
GroupTypes(IPv4, IPv6)
}

func (IPv4) GroupTypes(IPv4, IPv6) {}
func (IPv6) GroupTypes(IPv4, IPv6) {}

That's it. The GroupTypes method implementations
are no-op.  Their purpose is only to implement the
IP interface.

Now we can leverage Go's static type checking to
make sure we never assert an IP to anything other
than IPv4 and IPv6.  For example, this code will
error:

var ip IP
switch ip.(type) {
case string: // string does not implement IP
}

I wrote a simple generator and pushed in here:
http://github.com/siadat/implement-group-interface

(2) Type list

The second design is basically the same as the Sum
type (defined in dev.go2go). However, I wanted it
to work with Go1 code, so I decided to specify the
type list as a special comment (eg // #type T1, T2)
and forked dev.go2go to convert that commented type
list to an actual go2go type list.  The code is
available in
https://github.com/siadat/interface-type-check

Let me know what you think :)

sina

-- 
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/40617c13-f65c-49c8-b232-877bc509c46fo%40googlegroups.com.

Re: [go-nuts] Why gollvm not support race detector?

['Than McIntosh' via golang-nuts]

>>Could I simply add race.go to gofrontend then link the target programs by
the TSAN shared library to make the race detector enabled?

The race detector implementation also includes a compiler component (look
for flag_race in the cmd/compile source code), so that would have to be
ported to gccgo as well, since gccgo uses an entirely different compiler
implementation. There are probably other things as well that would have to
be pulled in.

Than

On Tue, Aug 11, 2020 at 5:02 AM Ting Yuan  wrote:

> Thanks for your reply,
>
> If I'm not confused, the implementation of Go race detector is written in
> go/src/runtime/race .go and its
> TSAN implementation (in C/C++) is dynamic linked to target programs by a
> shared library. Could I simply add race.go to gofrontend then link the
> target programs by the TSAN shared library to make the race detector
> enabled? I know integrating the race detector to gccgo/gollvm can't be done
> as easily as the aforementioned method, but what problems will I encounter
> when I do this.
>
> Thanks, Ting
>
> On Saturday, August 8, 2020 at 12:36:54 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 6, 2020 at 11:33 PM Yuan Ting  wrote:
>> >
>> > I know from README that gollvm does not support race detector. Is there
>> any technical problem? Is it possible to use ThreadSanitizer in LLVM to
>> implement a workaround race detector in gollvm?
>>
>> ThreadSanitizer knows a great deal about the behavior of C library
>> functions.  In order to use it with GoLLVM, it would be necessary to
>> teach it about the behavior of Go library functions.  This is not
>> impossible--the same work was done for the Go race detector--but
>> somebody would have to do the work.
>>
>> 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/c6d696b5-4918-4926-9068-ff3cd2ae1118o%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/CA%2BUr55GM1qvs6yaNFHqzGXSLYudFGxhRQusuO2X9jxwfo9T5Kw%40mail.gmail.com.

[go-nuts] Regarding this hash is worth solving, why is the result of shifting right by 5 bits better than the result of shifting right by 12 bits?

[Heisenberg]

The modification in this patch, why is the performance after shifting 5 
bits to the right better than the performance of shifting 12 bits to the 
right? Can someone tell me something for me?

https://go-review.googlesource.com/c/go/+/245177  

-- 
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/d805f363-31f9-4291-927d-db06d1fd3c09n%40googlegroups.com.

[go-nuts] Regarding this hash is worth solving, why is the result of shifting right by 5 bits better than the result of shifting right by 12 bits?

[Heisenberg]

The modification in this patch, why is the performance after shifting 5 
bits to the right better than the performance of shifting 12 bits to the 
right? Can someone tell me something for me?

https://go-review.googlesource.com/c/go/+/245177  

-- 
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/3aeeb90d-10a6-4517-a95a-47dadb62e5e3n%40googlegroups.com.

[go-nuts] Re: I made casual file transfer tool. and wana know your opinion.

[加藤泰隆]

Hi. 

I researched "syncthing" and analyze this.
My tool didn't have enough feature.

 - View synchronization status on both servers and clients
 - directory support
 - Synchronized settings can be saved.

I implemented that.

https://github.com/yasutakatou/andoukie2
https://github.com/yasutakatou/doukie2

Could you take a look at it?

But, GUIs, proprietary protocols and relay servers could not be 
implemented...

Thanks for the advice.
I've learned to think about UX!



2020年7月24日金曜日 8時41分53秒 UTC+9 加藤泰隆:
>
> I welcome your message.
>
> I didn't know this app and transfer details.
> Certainly, QR Code can send more informations.
> My app are not good enough.
>
> But, For example, My app is not support https.
> So,My app local network use case only.
> It's not flexible for improve.
> This problem depend used plugin on Apache cordova.
> I will search another plugin and will try to improve.
> many 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/d57e553a-0a1e-4d8f-9d13-8b965d3ad5b8o%40googlegroups.com.

Re: [go-nuts] Why gollvm not support race detector?

[Ting Yuan]

Thanks for your reply,

If I'm not confused, the implementation of Go race detector is written in 
go/src/runtime/race.go and its TSAN implementation (in C/C++) is dynamic 
linked to target programs by a shared library. Could I simply add race.go 
to gofrontend then link the target programs by the TSAN shared library to 
make the race detector enabled? I know integrating the race detector to 
gccgo/gollvm can't be done as easily as the aforementioned method, but what 
problems will I encounter when I do this.

Thanks, Ting

On Saturday, August 8, 2020 at 12:36:54 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Aug 6, 2020 at 11:33 PM Yuan Ting > 
> wrote: 
> > 
> > I know from README that gollvm does not support race detector. Is there 
> any technical problem? Is it possible to use ThreadSanitizer in LLVM to 
> implement a workaround race detector in gollvm? 
>
> ThreadSanitizer knows a great deal about the behavior of C library 
> functions.  In order to use it with GoLLVM, it would be necessary to 
> teach it about the behavior of Go library functions.  This is not 
> impossible--the same work was done for the Go race detector--but 
> somebody would have to do the work. 
>
> 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/c6d696b5-4918-4926-9068-ff3cd2ae1118o%40googlegroups.com.

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

[Markus Heukelom]

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

> On Mon, Aug 10, 2020 at 7:08 AM Markus Heukelom
>  wrote:
> >
> > Just a quick thought, instead of "comparable" (and type lists) maybe we
> could use a single operator to specify the required "operators" interface:
> >
> > type BiMap[type V, K ==] struct {
> > forward map[K]V
> > reverse map[V]K
> > }
> >
> > func Max[type T <](a, b T) T {
> >
> > }
> >
> > func ScanRowStruct[type T .](rows sql.Rows, dest *T) error {  //
> operator . ensures T is a struct
> >
> > }
>
> It could probably work, but we wind up with a bunch of special purpose
> syntax with only a tenuous connection to the way constraints work in
> general.  And you have to define connections between operators.  That
> is, comparable supports both == and !=, but you only mentioned ==;
> does == imply !=?
>
>
I would even be in favor of not allowing any operations in generic code on
T (besides what is possible on all types), allowing T to carry data only*.
However, that's admittelly being too restrictive. You really do need to be
able to specify the requirement of ==  to support maps in structs**. No way
around it. The case of "<" is also strong for functions like max etc.

So you could maybe even say: you can specify one operator to use with T and
that's it (not even allowing interface{}-d constraints and not implying
other operators). That's the simplest thing that could possibly make it
work for maps, and most generic algorithms that are really wanted. Of
course "==" and "<" are just shorter ways for "comparable" and "ordered"
and have the slight advantage of not introducing new names in the global
namespace. But both would work.

-Markus

* To me, constraints on T are really complex especially because now you
have to choose whether to just use plain old interfaces or generics with
interface constraints when designing a solution. But being able to use T
instead of interface{} really helps in writing clear and type safe code.
It's the constraints that make it tricky for me.

** Assuming maps don't use !=

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/CAMoB8rVQNXo242jaU-wMZOdfTscTm-z8OGfys8giytg-BgnSWw%40mail.gmail.com.

Re: [go-nuts] Gollvm failed to build hugo

[Yuan Ting]

Thanks for direction,

I think the root cause of this issue is exactly the same in #38728 but I 
afraid the patch in #38728 only fix the building of gollvm (i.e. add 
-fcd-branch=none to the build flags). In the above case, gollvm uses 
/usr/bin/cc to compile gccgo_c.o during the building of hugo without 
-fcd-branch=none and finally fails in linking time. So I guess we need also 
add this flag in somewhere gollvm calling /usr/bin/cc. This is only needed 
for newer linux distributions, I can't reproduce it in ubuntu 18.04.

Thanks, Ting

On Monday, August 10, 2020 at 9:30:45 PM UTC+8, Than McIntosh wrote:
>
> Hello,
>
> >># github.com/gohugoio/hugo
> >>/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
> split-stack sequence at section 1 offset 0
>
> This issue is https://github.com/golang/go/issues/38728, which should be 
> fixed at this point at tip. 
>
> Thanks, Than
>
>
> On Mon, Jul 20, 2020 at 2:33 PM Ian Lance Taylor  > wrote:
>
>> [ + thanm, cherryyz ]
>>
>> On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting > > wrote:
>> >
>> > Hi, I try to build hugo with fresh gollvm but the linker complains that:
>> >
>> > # github.com/gohugoio/hugo
>> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
>> split-stack sequence at section 1 offset 0
>> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
>> split-stack sequence at section 1 offset a6
>> >
>> > To reproduce:
>> >
>> > git clone https://github.com/gohugoio/hugo.git
>> > cd hugo && go build
>> >
>> > Platform: x86_64 ubuntu:20.04
>> > Gollvm build flags:
>> > cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 
>> -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G 
>> Ninja
>> >
>> > --
>> > 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/d722a1e8-d205-4c9e-8ae4-623c19dd2946o%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/263c45b3-597a-4cbb-878c-5d199defd6f7o%40googlegroups.com.