[go-nuts] Re: why the binary generated by go test has no symbol table

2020-09-07 Thread buaa...@gmail.com 
There is no ldflags provided, so why the symbol table is stripped

在2020年9月8日星期二 UTC+8 上午10:05:33 写道：

> And only on Linux, there is no symbol section in test binary unless I 
> generate it by go test -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/d8840e17-63c6-4f32-af1d-5d73d12dfbd4n%40googlegroups.com.

[go-nuts] why the binary generated by go test has no symbol table

2020-09-07 Thread buaa...@gmail.com 
And only on Linux, there is no symbol section in test binary unless I 
generate it by go test -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/9eaa469e-4d87-4e03-9b9e-58c9288d023cn%40googlegroups.com.

Re: [go-nuts] Asynchronous preemption

2020-09-07 Thread Yonatan Gizachew 
Got it. Thank you!

On Saturday, September 5, 2020 at 12:01:03 PM UTC+9 Ian Lance Taylor wrote:

> On Wed, Sep 2, 2020 at 9:11 PM Yonatan Gizachew  wrote:
> >
> > I see. If that is so, what is the job of sysmon thread?
>
> The sysmon thread is not related to asynchronous preemption. The
> sysmon thread does a few different things. One of the things it does
> is notice threads that have been stuck in a system call for a while,
> and detach them from their P, and start running a new thread
> associated with that P. This is scheduler activity, and it permits
> additional parallelism in the program, but it's not preemption.
>
> Ian
>
> > On Thursday, September 3, 2020 at 12:35:26 PM UTC+9 Ian Lance Taylor 
> wrote:
> >>
> >> On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew  
> wrote:
> >> >
> >> > Is it possible to stop the asynchronous preemption like:
> >> > GODEBUG=asyncpreemptoff=1 go build -o libgotest.so 
> -buildmode=c-shared -compiler=gccgo test.go
> >> >
> >> > I am using gccgo compiler.
> >>
> >> Note that executables built by the gccgo compiler don't use
> >> asynchronous preemption.
> >>
> >> 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2b865dc9-7992-4239-9d5f-09c0ba1fa369n%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/f8593be3-4000-4e75-811a-8ac63e3eb558n%40googlegroups.com.

Re: [go-nuts] cgo cross compilation to arm failed

2020-09-07 Thread Ian Lance Taylor 
On Sun, Sep 6, 2020 at 1:53 PM 'Hubert Hirtz' via golang-nuts
 wrote:
>
> I am trying to cross-compile a project that depends on sqlite3 on a
> amd64 machine (host) for an armhf machine (target), using clang with the
> appropriate "--target" flag.
>
> The build fails on runtime/cgo with the following errors:
>
> ```
> # runtime/cgo
> In file included from gcc_libinit.c:8:
> /usr/include/pthread.h:672:6: error: 'regparm' is not valid on this platform
> /usr/include/bits/pthreadtypes-arch.h:52:50: note: expanded from macro
> '__cleanup_fct_attribute'
> In file included from gcc_libinit.c:8:
> /usr/include/pthread.h:684:3: error: 'regparm' is not valid on this platform
> /usr/include/bits/pthreadtypes-arch.h:52:50: note: expanded from macro
> '__cleanup_fct_attribute'
> In file included from gcc_libinit.c:8:
> /usr/include/pthread.h:725:6: error: 'regparm' is not valid on this platform
> /usr/include/bits/pthreadtypes-arch.h:52:50: note: expanded from macro
> '__cleanup_fct_attribute'
> ```
>
> Here is the `go env` and the full build output (run with `-x`):
> 
>
> Do you have any idea why it fails or if I missed something?

In order to cross-compile a Go program that uses cgo, you need a
complete C cross-compiler.  In this case your C cross-compiler appears
to be using the native header files, which can't work.  It needs to
use the cross-compiler header files.

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/CAOyqgcUf-oJQGRcs%3D_kwVRATD4%2B6jRS1hsJUZdPu%2BnznKYLHRA%40mail.gmail.com.

Re: [go-nuts] zombie parent scenario with golang

2020-09-07 Thread Ian Lance Taylor 
On Mon, Sep 7, 2020 at 12:03 AM Uday Kiran Jonnala  wrote:
>
> Thanks for the reply, I get the point on zombie, I do not think the issue 
> here is parent not reaping child, seems like go process has not finished 
> execution of some
> internal threads (waiting on some futex) and causing SIGCHILD not to be sent 
> to parent.
>
> go process named  hit with panic and I see this went into zombie 
> state
>
> $ ps -ef | grep replicator
> root  87548  87507  0 Aug23 ?00:00:00 [replicator] 
>
> Now looking at the tasks within the process
>
> I see the stack trace of the threads within the process still stuck on 
> following
>
> bash-4.2# cat /proc/87548/task/87561/stack
> [] futex_wait_queue_me+0xc4/0x120
> [] futex_wait+0x10a/0x250
> [] do_futex+0x35e/0x5b0
> [] SyS_futex+0x13b/0x180
> [] do_syscall_64+0x79/0x1b0
> [] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [] 0x
>
> From the above example if we are creating some internal threads and main 
> thread is excited due to panic and left some detached threads, process will 
> be in zombie state until the threads
> within the process completes.
>
> It appears there is some run away threads hung state scenario causing this. I 
> am not able to reproduce it with main go routine explict panic and some go 
> routine still executing.
>
> Does the above stack trace sound familiar wrt internal threads of Go runtime ?

If the process is defunct, then none of the thread stacks matter.
They are just where the thread happened to be when the process exited.

What is the real problem you are seeing?

Ian




> On Thursday, August 27, 2020 at 1:43:39 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Thu, Aug 27, 2020 at 10:01 AM Uday Kiran Jonnala
>>  wrote:
>> >
>> > I have a situation on zombie parent scenario with golang
>> >
>> > A process (in the case replicator) has many goroutines internally
>> >
>> > We hit into panic() and I see the replicator process is in Zombie state
>> >
>> > <<>>>:~$ ps -ef | grep replicator
>> >
>> > root 87548 87507 0 Aug23 ? 00:00:00 [replicator] 
>> >
>> >
>> >
>> > Main go routine (or the supporting P) excited, but panic left the other P 
>> > thread to be still in executing state (main P could be 87548 and 
>> > supporting P thread 87561 is still there) in blocked state
>> >
>> > bash-4.2# ls -Fl /proc/87548/task/87561/fd | grep 606649l-wx--. 1 root 
>> > root 64 Aug 25 10:59 1 -> pipe:[606649]l-wx--. 1 root root 64 Aug 25 
>> > 10:59 2 -> pipe:[606649]
>> >
>> > Stack trace
>> >
>> > bash-4.2# cat /proc/87548/task/87561/stack[] 
>> > futex_wait_queue_me+0xc4/0x120[] 
>> > futex_wait+0x10a/0x250[] 
>> > do_futex+0x35e/0x5b0[] 
>> > SyS_futex+0x13b/0x180[] 
>> > do_syscall_64+0x79/0x1b0[] 
>> > entry_SYSCALL_64_after_hwframe+0x3d/0xa2[] 
>> > 0x
>> >
>> >
>> >
>> > We have panic internally from main go routine
>> >
>> > fatal error: concurrent map writes
>> >
>> > goroutine 666359 [running]:
>> > runtime.throw(0x101d6ae, 0x15)
>> > /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/panic.go:608
>> >  +0x72 fp=0xc00374b6f0 sp=0xc00374b6c0 pc=0x42da62
>> > runtime.mapassign_faststr(0xdb71c0, 0xc00023f5f0, 0xc000aca990, 0x83, 
>> > 0xc0009d03c8)
>> > /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/map_faststr.go:275
>> >  +0x3bf fp=0xc00374b758 sp=0xc00374b6f0 pc=0x41527f
>> > github.eng.nutanix.com/xyz/abc/metadata.UpdateRecvInProgressFlag(0xc000aca990,
>> >  0x83, 0x0)
>> >
>> > ...
>> >
>> > goroutine 665516 [chan receive, 2 minutes]:
>> > zeus.(*Leadership).LeaderValue.func1(0xc003d5c120, 0x0, 0xc002e906c0, 
>> > 0x52, 0xc00302ec60, 0x29)
>> > /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:244 +0x34
>> > created by zeus.(*Leadership).LeaderValue
>> > /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:243 +0x277
>> > 2020-08-03 00:35:04 rolled over log file
>> > ERROR: logging before flag.Parse: I0803 00:35:04.426906 196123 
>> > dataset.go:26] initialize zfs linking
>> > ERROR: logging before flag.Parse: I0803 00:35:04.433296 196123 
>> > dataset.go:34] completed zfs linking successfully
>> > I0803 00:35:04.433447 196123 main.go:86] Gflags passed NodeUuid: 
>> > c238e584-0eeb-48bd-b299-2a25b13602f1, External Ip: 10.15.96.163
>> > I0803 00:35:04.433460 196123 main.go:99] Component name using for this 
>> > process : abc-c238e584-0eeb-48bd-b299-2a25b13602f1
>> > I0803 00:35:04.433467 196123 main.go:120] Trying to initialize DB
>> >
>> > If there is panic() from main P thread, as I understand we exit() and 
>> > cleanup all P threads of the process.
>> >
>> > Are we hitting into the following scenario, I did not look into M-P-G 
>> > implantation in detail.
>> >
>> > Example:
>> >
>> > #include 
>> > #include 
>> > #include 
>> > #include 
>> >
>> > void *thread_function(void *args)
>> > {
>> > printf("The is new thread! Sleep 20 seconds...\n");
>> > sleep(100);
>> > printf("Exit from thread\n");
>> >

[go-nuts] Re: Anyone successfully connecting to Oracle (11g) from Go?

2020-09-07 Thread Tamás Gulácsi 
Wow, have you reverse-engineered the Oracle SQL.NET connection? Or the Java 
thin client?
Is this legal at all?
Though I'd pay a limb for a C-less native, pure Go client...

Samy Sultan a következőt írta (2020. szeptember 7., hétfő, 20:01:46 UTC+2):

> I make a new package go-ora it is pure go oracle client no need for 
> instant client at all no need for environmental vars just 
> go-get the package and run you program
>
> https://github.com/sijms/go-ora.git
>
> في الخميس، 5 يونيو 2014 في تمام الساعة 12:03:05 ص UTC+3، كتب ‪Ron Gidron‬‏ 
> رسالة نصها:
>
>> OK so after a long debugging session I ened up finding that there are 
>> type mismatches happening when running go 1.3. I have (for now) updated my 
>> oci8 driver and filed a report here 
>> https://github.com/mattn/go-oci8/issues/27
>>
>> Solved for me.
>>
>> Thanks,
>> --Ron
>>
>>
>> On Thursday, May 29, 2014 8:18:31 PM UTC+3, Ron Gidron wrote:
>>
>>> I am running OS X 10.9.3 and attempting to work with an amazon RDS 
>>> instance. I have instantclient installed and working properly but am 
>>> hitting walls trying to setup basic connectivity to it from my Go 
>>> environment. I tried using both an ODBC driver (failed to install with 
>>> missing .h files complaints) and also tried 
>>> https://github.com/tgulacsi/goracle with no luck. 
>>> Is anyone out these setup with Go server connected to Oracle (from a 
>>> Mac?) and willing to share some code snippets / install directions?
>>>
>>> Thanks!
>>> --Ron
>>>
>>

-- 
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/d5b13267-d5f2-4838-a218-690144524c57n%40googlegroups.com.

[go-nuts] Re: Anyone successfully connecting to Oracle (11g) from Go?

2020-09-07 Thread Samy Sultan 
I make a new package go-ora it is pure go oracle client no need for instant 
client at all no need for environmental vars just 
go-get the package and run you program

https://github.com/sijms/go-ora.git

في الخميس، 5 يونيو 2014 في تمام الساعة 12:03:05 ص UTC+3، كتب ‪Ron Gidron‬‏ 
رسالة نصها:

> OK so after a long debugging session I ened up finding that there are type 
> mismatches happening when running go 1.3. I have (for now) updated my oci8 
> driver and filed a report here https://github.com/mattn/go-oci8/issues/27
>
> Solved for me.
>
> Thanks,
> --Ron
>
>
> On Thursday, May 29, 2014 8:18:31 PM UTC+3, Ron Gidron wrote:
>
>> I am running OS X 10.9.3 and attempting to work with an amazon RDS 
>> instance. I have instantclient installed and working properly but am 
>> hitting walls trying to setup basic connectivity to it from my Go 
>> environment. I tried using both an ODBC driver (failed to install with 
>> missing .h files complaints) and also tried 
>> https://github.com/tgulacsi/goracle with no luck. 
>> Is anyone out these setup with Go server connected to Oracle (from a 
>> Mac?) and willing to share some code snippets / install directions?
>>
>> Thanks!
>> --Ron
>>
>

-- 
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/4aa5dfd9-fbaa-4535-8004-9efc240cdf84n%40googlegroups.com.

Re: [go-nuts] zombie parent scenario with golang

2020-09-07 Thread Uday Kiran Jonnala 
Hi Ian,

Thanks for the reply, I get the point on zombie, I do not think the issue 
here is parent not reaping child, seems like go process has not finished 
execution of some
internal threads (waiting on some futex) and causing SIGCHILD not to be 
sent to parent.

go process named  hit with panic and I see this went into 
zombie state

$ ps -ef | grep replicator
root  87548  87507  0 Aug23 ?00:00:00 [replicator]   

Now looking at the tasks within the process

I see the stack trace of the threads within the process still stuck on 
following

bash-4.2# cat /proc/87548/task/87561/stack
[] futex_wait_queue_me+0xc4/0x120
[] futex_wait+0x10a/0x250
[] do_futex+0x35e/0x5b0
[] SyS_futex+0x13b/0x180
[] do_syscall_64+0x79/0x1b0
[] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[] 0x  

>From the above example if we are creating some internal threads and main 
thread is excited due to panic and left some detached threads, process will 
be in zombie state until the threads
within the process completes.
It appears there is some run away threads hung state scenario causing this. 
I am not able to reproduce it with main go routine explict panic and some 
go routine still executing.

Does the above stack trace sound familiar wrt internal threads of Go 
runtime ?

Thanks,
Uday

On Thursday, August 27, 2020 at 1:43:39 PM UTC-7 Ian Lance Taylor wrote:

> On Thu, Aug 27, 2020 at 10:01 AM Uday Kiran Jonnala
>  wrote:
> >
> > I have a situation on zombie parent scenario with golang
> >
> > A process (in the case replicator) has many goroutines internally
> >
> > We hit into panic() and I see the replicator process is in Zombie state
> >
> > <<>>>:~$ ps -ef | grep replicator
> >
> > root 87548 87507 0 Aug23 ? 00:00:00 [replicator] 
> >
> >
> >
> > Main go routine (or the supporting P) excited, but panic left the other 
> P thread to be still in executing state (main P could be 87548 and 
> supporting P thread 87561 is still there) in blocked state
> >
> > bash-4.2# ls -Fl /proc/87548/task/87561/fd | grep 606649l-wx--. 1 
> root root 64 Aug 25 10:59 1 -> pipe:[606649]l-wx--. 1 root root 64 Aug 
> 25 10:59 2 -> pipe:[606649]
> >
> > Stack trace
> >
> > bash-4.2# cat /proc/87548/task/87561/stack[] 
> futex_wait_queue_me+0xc4/0x120[] 
> futex_wait+0x10a/0x250[] 
> do_futex+0x35e/0x5b0[] 
> SyS_futex+0x13b/0x180[] 
> do_syscall_64+0x79/0x1b0[] 
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2[] 
> 0x
> >
> >
> >
> > We have panic internally from main go routine
> >
> > fatal error: concurrent map writes
> >
> > goroutine 666359 [running]:
> > runtime.throw(0x101d6ae, 0x15)
> > 
> /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/panic.go:608
>  
> +0x72 fp=0xc00374b6f0 sp=0xc00374b6c0 pc=0x42da62
> > runtime.mapassign_faststr(0xdb71c0, 0xc00023f5f0, 0xc000aca990, 0x83, 
> 0xc0009d03c8)
> > 
> /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/map_faststr.go:275
>  
> +0x3bf fp=0xc00374b758 sp=0xc00374b6f0 pc=0x41527f
> > 
> github.eng.nutanix.com/xyz/abc/metadata.UpdateRecvInProgressFlag(0xc000aca990,
>  
> 0x83, 0x0)
> >
> > ...
> >
> > goroutine 665516 [chan receive, 2 minutes]:
> > zeus.(*Leadership).LeaderValue.func1(0xc003d5c120, 0x0, 0xc002e906c0, 
> 0x52, 0xc00302ec60, 0x29)
> > /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:244 +0x34
> > created by zeus.(*Leadership).LeaderValue
> > /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:243 +0x277
> > 2020-08-03 00:35:04 rolled over log file
> > ERROR: logging before flag.Parse: I0803 00:35:04.426906 196123 
> dataset.go:26] initialize zfs linking
> > ERROR: logging before flag.Parse: I0803 00:35:04.433296 196123 
> dataset.go:34] completed zfs linking successfully
> > I0803 00:35:04.433447 196123 main.go:86] Gflags passed NodeUuid: 
> c238e584-0eeb-48bd-b299-2a25b13602f1, External Ip: 10.15.96.163
> > I0803 00:35:04.433460 196123 main.go:99] Component name using for this 
> process : abc-c238e584-0eeb-48bd-b299-2a25b13602f1
> > I0803 00:35:04.433467 196123 main.go:120] Trying to initialize DB
> >
> > If there is panic() from main P thread, as I understand we exit() and 
> cleanup all P threads of the process.
> >
> > Are we hitting into the following scenario, I did not look into M-P-G 
> implantation in detail.
> >
> > Example:
> >
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > void *thread_function(void *args)
> > {
> > printf("The is new thread! Sleep 20 seconds...\n");
> > sleep(100);
> > printf("Exit from thread\n");
> > pthread_exit(0);
> > }
> >
> > int main(int argc, char **argv)
> > {
> > pthread_t thrd;
> > pthread_attr_t attr;
> > int res = 0;
> > res = pthread_attr_init();
> > res = pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
> > res = pthread_create(, , thread_function, NULL);
> > res = pthread_attr_destroy();
> > printf("Main thread. Sleep 5 seconds\n");
> > sleep(5);
> > printf("Exit from main

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

2020-09-07 Thread targe...@gmail.com 
Sorry for interfering. I've gathered statements and expressions which look 
like candidates for interface-based generalization. Interface and method 
names are just placeholders. Generic interfaces for collections like slice 
or map are different beasts. Will post thoughts on them later. 

I personally think that most used interface wrappers for predefined types 
would be range support and generalized collections. Maybe custom key types 
for maps and custom map hasher.

*Comparison operators*

 "==", "!=", "<", ">", "<=", ">="

These can be split into two groups - equatable and ordered. Not all types 
which may be compared equals can be ordered

type Equatable[T] interface {
Equals(T, T) bool
}
type Ordered[T] interface {
Compare(T, T) int // < 0 if less, > 0 if greater, 0 if equals
}

Equals can be easily implemented through Ordered via

func[T] (Ordered[T]* self) Equals(left, right T) bool {
return self.Compare(left right) == 0
}

Possible application for default interface methods but off-topic here

*Arithmetic operators*

*Unary operators "+", "-", "^"*

type UnaryOp[T] interface {
Op(T) T
}

where Op can be Plus, Minus, BitwiseComplement

*Binary operators "+", "-", "*", "/", "%", "&", "|", "^", "&^"*

type BinaryOp[T] interface {
Op(T, T) T
}

where Op is "Add", "Sub", "Mul", "Div", "Mod", "BitAnd", "BitOr", "BitXor", 
"BitAndNot"

Bit-shift operators look almost the same except having different second 
argument

type BinaryOp[T] interface {
Op(T, uint) T
}

where "Op" is "ShiftLeft" or "ShiftRight"

*Assign-op operators "+=", "-=", "*=", "/=", "%=", "&=", "|=", "^=", "&^="*

type BinaryOpAssign[T] interface {
OpAssign(T)
}

where Op is "Add", "Sub", "Mul", "Div", "Mod", "BitAnd", "BitOr", "BitXor", 
"BitAndNot"

Default implementation through normal operation would  look like

func[T] (BinaryOp[T]* self) OpAssign(right T) {
*self = self.Op(*self, right)
}

Except shift operators which would look like

type BinaryOpAssign[T] interface {
OpAssign(uint)
}

where "Op" is "ShiftLeft" or "ShiftRight"

*String concatenation*

Uses interfaces "BinaryAdd" and "BinaryAddAssign"

*Logical operators*

Applied only to booleans, so I see no good reason to add generic interfaces 
for them

*Address operators*

Should not have their own interface since they don't assume any kind of 
type-specific behavior

*Receive operator and send statement*

May be considered in future. ATM I don't see good application for 
channel-like types except channels themselves

*Increment and decrement*

type Incrementable[T] interface {
Increment()
}
type Decrementable[T] interface {
Decrement()
}

*Assignment*

Not subject for generalization since it shouldn't be overridden

*For statements with range clause*

type Range[K, V] interface {
Next() K, V, bool
}

Slice's or string's key would be respective index
Channel looks more like exception here since it introduces asynchronous 
iteration and produces single value.



On Saturday, August 15, 2020 at 3:14:30 PM UTC+3 rog wrote:

> On Sat, 15 Aug 2020 at 04:57, Patrick Smith  wrote:
>
>> On Thu, Aug 13, 2020 at 11:25 PM Patrick Smith  
>> wrote:
>> > I tried out a few different implementations, evaluating the polynomial
>> > instead of finding roots,
>> > at https://go2goplay.golang.org/p/g8bPHdg5iMd . As far as I can tell,
>> > there is no sensible way to
>> > do it with an interface that is implemented directly by *big.Float; we
>> > need to wrap *big.Float
>> > in a wrapper type in any case.
>>
>> After looking at the draft again, and seeing the Settable example
>> there, I realized we can do it using big.Float directly, but it needs
>> two interfaces, one matching big.Float and one matching *big.Float. I
>> have updated my examples at https://go2goplay.golang.org/p/auSkvhWSNHn
>
>
> I think that works pretty well, and seems to be the direction that things 
> are going in.
> Here's your example cleaned up a bit to show just that latest example, and 
> also
> showing how it looks when adapting a built-in type:
>
> https://go2goplay.golang.org/p/eFIvHocOC75
>
> It's possible to build a generic adaptor type from the value-style 
> interface to the pointer-style interface, which you might find interesting:
>
>   https://go2goplay.golang.org/p/NiQY_-kWvu8
>
> This could *almost* work on image.Point, except that Point.Mul has the 
> wrong signature.
>
>   cheers,
> rog.
>
>>
>> .
>
>
>>
>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAADvV_vxU7nUJ16X5xwBYhiOPVrzp%3DzrX%3DU4UTgBsOQJ2RnMuQ%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