It seems you are right.
I'm not sure if my understanding is correct:
I guess that this problem occured because gollvm just exposes the interface
of exported functions in the lib, so the private function can't be accessed.
I want to know if there is any way to make the internal functions of the
s
> then I guess you mean that interface { MyInt } will accept any type
> argument whose underlying type is the same as the underlying type of
> MyInt. But that seems strange. There is no connection between MyInt
> and MyInt2, except that they happen to be defined in terms of the same
> underlying t
I'm still struggling w/ modules to get my code to compile. This example
is on Win10 using go 1.16.3
~/go/src/rpng/rpng.go
~/go/src/tokenize/tokenize.go
~/go/src/hpcalc2/hpcalc2.go
I'm logged into ~/go/src and I type this, like I used to do in the "old"
days:
go install rpng
Now I get
On Mon, Apr 5, 2021 at 3:02 PM yiyus wrote:
>
> > More generally, if we omit approximation elements, it's a bit odd that
> > if I write "int" I mean "an infinite set of types including int". It
> > seems clearer to require people to explicitly indicate that they want
> > to match the infinite set
On Mon, 5 Apr 2021, 21:58 yiyus, wrote:
> A type and its underlying type support exactly the same operations
>
FWIW I don't believe that's the case. A type may have methods (each with at
least one corresponding operation) that its underlying type does not.
--
You received this message because
> More generally, if we omit approximation elements, it's a bit odd that
> if I write "int" I mean "an infinite set of types including int". It
> seems clearer to require people to explicitly indicate that they want
> to match the infinite set of types.
What I propose is not that "int means an in
On Mon, Apr 5, 2021 at 1:58 PM yiyus wrote:
>
> I may have missed something, but I have problems to understand what is the
> goal of the proposal. It says:
>
> > The purpose of introducing type lists in the generics proposal was to
> > specify the operations available to type parameters in param
I may have missed something, but I have problems to understand what is the
goal of the proposal. It says:
> The purpose of introducing type lists in the generics proposal was to
specify the operations available to type parameters in parameterized
functions.
I do not see how approximation eleme
Just dropping here for reference the link to the Github issue:
https://github.com/golang/go/issues/45300
On Sunday, 28 March 2021 at 03:55:03 UTC+2 RP Junior wrote:
>
> May want to check out this setting on your issue:
> "cmd/internal/obj: reject splittable ABIInternal functions without
> more
You can write such a function yourself. For that reason and since it would
be rarely useful, I don't think it's likely to become part of the standard
library.
On Thursday, April 1, 2021 at 9:02:34 AM UTC-4 Michael Schaller wrote:
> Roger, I think you slightly misunderstood me. ;-)
>
> It is tru
I'm guessing you want to know where the behavior is documented? That I do
not know.
But in case you literally want to know where it is defied, look at :
https://github.com/golang/net/blob/0fccb6fa2b5ce302a9da5afc2513d351bd175889/idna/idna10.0.0.go#L265
On Sunday, April 4, 2021 at 9:03:10 AM UT
On Mon, Apr 5, 2021 at 5:17 PM peterGo wrote:
> Held: Google’s copying of the Java SE API, which included only those lines of
> code that were needed to allow programmers to put their accrued talents to
> work in a new and transformative program, was a fair use of that material as
> a matter o
FYI:
SUPREME COURT OF THE UNITED STATES
GOOGLE LLC v. ORACLE AMERICA, INC.
Held: Google’s copying of the Java SE API, which included only those lines
of code that were needed to allow programmers to put their accrued talents
to work in a new and transformative program, was a fair use of that
Thanks everyone for the insights and suggestions.
On Monday, 5 April 2021 at 13:47:20 UTC+8 Amnon wrote:
> I would agree with Axel, that while gob is convenient, it never claims to
> be optimal.
> And if you care about size and speed of encoding then it may be worth
> looking at
> other serial
14 matches
Mail list logo
