Re: [go-nuts] A value saved in an interface{} field in a struct not usable in func with interace{} arg

[Steve Murphy]

Many thanks, Ian, I appreciate your suggestions!

I added your code snippet to my program, and got:

panic: interface conversion: interface {} is nil, not *interface {} 
[recovered]
panic: interface conversion: interface {} is nil, not *interface {}

According to the trace, it looks like it's crashing while trying to 
evaluate the valDeref := line.

Looking at the trace provided:

genBox: arg type=*int64 argval=0xc1a150, val type=, val 
val= offset=0
genBox: box=
--- FAIL: TestKd1 (0.09s)
panic: interface conversion: interface {} is nil, not *interface {} 
[recovered]
panic: interface conversion: interface {} is nil, not *interface {}

goroutine 6 [running]:
testing.tRunner.func1(0xc20200)
/usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
panic(0x523360, 0xcbc330)
/usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
parsetree.com/kdtree.genBox(0x50eec0, 0xc1a150, 0x0, 0x0, 0x0, 0x2)
/home/murf/go/kdtree/kdtree1_test.go:43 +0x43e

It kinda looks like the %T and %v aren't working for val; but the stack 
trace shows 0xc1a150 in the second argument to genBox.

Uh, wait a minute! According to the stack, the first arg (called arg) is 
0x50eec0; but the debug output from genbox shows arg's val is 0xc1a150,
which is what the second arg should be. So it looks like the args have 
shifted to the left one position! And no errors on compilation?

I don't know what to think.

BTW, I'm on ubuntu 20.04, and the version of go is 1.13.

murf

On Monday, January 11, 2021 at 10:45:29 AM UTC-7 Ian Davis wrote:

> In genBox your code is saying that val contains a pointer to interface{}. 
> In other words its an interface{} that contains a *interface{}. That is a 
> weird but valid construct.
>
> I suggest you dereference it and see what the contained interface holds. 
> Something like:
>
> valDeref := val.(*interface{})
>
>  fmt.Printf("val contains=%T", valDeref)
>
> You may find that valDeref contains the *int64 you are looking for.
>
> As an aside, *interface{} is usually an indication that someone somewhere 
> is passing the wrong value to the function since it almost never makes 
> sense to pass a pointer to interface{}.
>
>
>
>
>
> On Mon, 11 Jan 2021, at 4:03 PM, Steve Murphy wrote:
>
> Hello!
>
> I keep getting:
> panic: interface conversion: interface {} is *interface {}, not *int64 
> [recovered]
> panic: interface conversion: interface {} is *interface {}, not *int64
>
> I *suspect* what is happening is that the KDElem struct has an item field 
> whose 
> type is interface{}, so that you can store a pointer to some struct (of 
> your own making),
> or an index into an array of structs, or... *whatever*, but in my case, 
> it's an index into an array
> of objects. The itemfunc (or genBox in my test code) is supposed to set 
> the item field in 
> the KDElem struct to the proper index, as the struct has just been 
> created, and the job
> of the itemfunc is to make it point to the right object, and set the 
> bounds info in the new struct.
>
> type KdElem struct {
> item   interface{} // a ptr to a particular struct, or an index 
> into an array of objects, or
> ...
> }
>
> And the func that calls the itemfunc (genBox) looks like this:
>
> func loadItems(itemfunc func(arg interface{}, val interface{}, size 
> *KdBox) int, arg interface{}, extent KdBox, length *int64, mean *float64) 
> *KdElem {
>  ...
>  newItem = new(KdElem)
>  if itemfunc(arg, , newItem.size) != 0 {
>  ...
>
>
> And, in this case the itemfunc declaration looks like this:
>
> func genBox(arg interface{}, val interface{}, box *KdBox) int {
>  var offsetp = arg.(*int64) // successful
>  var offset = *offsetp // successful
>  // fmt.Printf("genBox: offset=%v offsetp=%v\n", offset, offsetp)
>  fmt.Printf("genBox: arg type=%T argval=%v, val type=%T, val 
> val=%v\n", arg, arg, val, val)
>  if offset < KDBoxes {
>   fmt.Printf("genBox: val=%v  *int64=%v\n", val, val)
>   var realval *int64 = val.(*int64) //  <<-- This is line 
> 43!  Compiles but... Crash!!!
>   *realval = offset + 1
> ...
>
> Now, I get this from a go test:
>
> KdBuild: arg type=*int64  argval=0xcd2078; 
> genBox: arg type=*int64 argval=0xcd2078, val type=*interface {}, 
> val val=0xcba640
> genBox: val=0xcba640  *int64=0xcba640
> --- FAIL: TestKd1 (0.08s)
> panic: interface conversion: interface {} is *interface {}, not *int64 
> [recovered]
> panic: interface conversion: interface {} is *interface {}, not *int64
>
> goroutine 19 [running]:
> testing.tRunner.func1(0xc000108100)
> /usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
> panic(0x523360, 0xcc2360)
> /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
> parsetree.com/kdtree.genBox(0x50eec0, 0xcd2078, 0x50ef40, 
> 0xcba640, 0x0, 0x0)
> /home/murf/go/kdtree/kdtree1_test.go:43 +0x270
> parsetree.com/kdtree.loadItems(0x5570f8, 0x50eec0, 0xcd2078, 
> 

Re: [go-nuts] Need to read file in double loop

[Kurtis Rader]

You should start by asking yourself why your program outputs "1", "2" and
"S". Hint: after seeing "S" you don't break out of the inner loop until
another "S" is seen which your sample data does not include.

On Mon, Jan 11, 2021 at 6:59 PM Tong Sun  wrote:

> Hi,
>
> I need to read file in double loop --
>
> - reading file line by line until a special KW is met, say "S"
> - When it happens, need to collect content line by line until another
> special KW is met, say "E"
>
> For e.g., if processing the following content line by line, then
> the content from S 3 till 6 E need to be processed as a *single group*:
>
> 1
> 2
> S
> 3
> 4
> 5
> 6
> E
> 7
> 8
> 9
>
> How can I do that?
>
> I've prepared a starter
> https://play.golang.org/p/brdLtyjt-L2
>
> but it is not working as I expected
>
> Why 7 8 9 are not processed?
> How to fix it?
>
> Thx!
>
>
> --
> 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/db7e8fee-11f7-4e7a-8743-c6e3096342e4n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD_oYHhikzFGBT1csDnThVPTDsudi0NL%2BWZ1PQv7Jb1zhQ%40mail.gmail.com.

[go-nuts] Need to read file in double loop

[Tong Sun]

Hi, 

I need to read file in double loop -- 

- reading file line by line until a special KW is met, say "S"
- When it happens, need to collect content line by line until another 
special KW is met, say "E"

For e.g., if processing the following content line by line, then 
the content from S 3 till 6 E need to be processed as a *single group*:

1
2
S
3
4
5
6
E
7
8
9

How can I do that?

I've prepared a starter
https://play.golang.org/p/brdLtyjt-L2

but it is not working as I expected

Why 7 8 9 are not processed?
How to fix it?

Thx!


-- 
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/db7e8fee-11f7-4e7a-8743-c6e3096342e4n%40googlegroups.com.

[go-nuts] Using fetch() for HTTP requests?

[Nv7]

I am making a WebAssembly app with Go. Currently, it is 8.1MB uncompressed 
and 2MB gzipped. This is too much. I want to use TinyGo, but I need to send 
HTTP GET requests. TinyGo currently doesn't support net/http. But, TinyGo 
has syscall/js which allows you to do fetch(). But I couldn't find out how 
to use JS await using syscall/js. I also tried using channels from handlers 
and returning the value of channels, but this gave me fatal error: All 
goroutines are asleep. Deadlock!.

Are there any alternatives for net/http that work with tinygo or ways to 
use fetch and return values instead of having callbacks?

-- 
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/c9da6d9d-06b2-43ef-8d82-f820e616be1en%40googlegroups.com.

Re: [go-nuts] Using go tool with third-party Go implementations

[Alexander Zhirov]

  > I suspect this will give you trouble over time.

That's the question I've been pondering a lot lately. I know for sure that
trying to keep up with the go tool evolution *is* a lot of trouble. I'm
trying to experiment with alternatives to get some sense for how they
actually compare. Using go/build is what GopherJS currently does and it
lacks feature parity with the go tool (which I think is intentional?).
go/packages is a bit better and works reasonably for code analysis/editor
support purposes, but doesn't lend itself
 for
third-party compilers, and things like file embedding would still most
likely require rebuilding from scratch (not 100% sure here, I only briefly
skimmed the proposal at this point). Hijacking toolchain calls is the last
option I haven't explored and in theory it sidesteps pretty much go
tool-level problems.

> For example, it expects cmd/link to create a build ID that can be
recognized by cmd/internal/buildid.  It expects to be able to pack
additional objects into archive files (see packInternal in
cmd/go/internal/work/gc.go).

This is a useful data point. Currently GopherJS uses its own bespoke format
for intermediate artifacts, maybe it's one more reason to actually switch
to proper object files. It works for WebAssembly, so we could probably make
it work for JS as well. Is it worth the trouble? Maybe not, one way to find
out :)

Another way to approach this is to implement a generic "third-party"
toolchain with a simplified set of assumptions for all other compilers to
use. From that perspective posing as gccgo would've been ideal if not for
1) gcc flags are a pain to parse in Go and 2) it doesn't produce calls to
build standard library, since gccgo has it pre-built (as far as I
understand).

пн, 11 янв. 2021 г. в 19:14, Ian Lance Taylor :

> On Mon, Jan 11, 2021 at 11:03 AM Alexander Zhirov 
> wrote:
> >
> > At the moment there are at least three alternative implementations of Go
> that I know of (and there are probably some I don't): gccgo, tinygo and
> gopherjs. Of the three, only gccgo is supported by the go tool out of box.
> Looking at the source code, gc ang gccgo have their own implementations of
> the toolchain interface.
> >
> > The other two essentially reimplement the built system using go/build
> package, and, based on my experience with GopherJS, keeping up with changes
> to the upstream Go build tooling (modules, file embedding, etc.) is a lot
> of effort.
> >
> > Out of interest, I was investigating what would it take for GopherJS to
> delegate build system details to the Go tool and only provide alternative
> implementations of compile/link tools. For prototyping purposes -toolexec
> flag allows me to insert a proxy that intercepts compiler/linker
> invocations and invokes GopherJS as required. The nice thing is that no
> GopherJS-specific code needs to exist in the cmd/go codebase.
> >
> >  I'm currently at a very early stage, but it seems to be working out.
> Before I spend too much time though, I'd like to probe people's opinions of
> a few questions:
> >
> > 1) Is the idea of treating cmd/compile, cmd/link (and so on) interfaces
> as an extension point a reasonable one? I expect that they are going to
> change between releases, but probably fewer than the build system as a
> whole.
>
> I suspect this will give you trouble over time.  When the go tool
> invokes cmd/compile and cmd/link, it expects them to behave just like
> the ordinary cmd/compile and cmd/link commands.  For example, it
> expects cmd/link to create a build ID that can be recognized by
> cmd/internal/buildid.  It expects to be able to pack additional
> objects into archive files (see packInternal in
> cmd/go/internal/work/gc.go).  There may be other complex dependencies,
> and certainly more will be added over 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/CALFPu54Po-SNooeKXuy%3DHKdxgbUv%2BnU3mRpMwUC7UFgJDCBk%2Bw%40mail.gmail.com.

Re: [go-nuts] Using go tool with third-party Go implementations

[Ian Lance Taylor]

On Mon, Jan 11, 2021 at 11:03 AM Alexander Zhirov  wrote:
>
> At the moment there are at least three alternative implementations of Go that 
> I know of (and there are probably some I don't): gccgo, tinygo and gopherjs. 
> Of the three, only gccgo is supported by the go tool out of box. Looking at 
> the source code, gc ang gccgo have their own implementations of the toolchain 
> interface.
>
> The other two essentially reimplement the built system using go/build 
> package, and, based on my experience with GopherJS, keeping up with changes 
> to the upstream Go build tooling (modules, file embedding, etc.) is a lot of 
> effort.
>
> Out of interest, I was investigating what would it take for GopherJS to 
> delegate build system details to the Go tool and only provide alternative 
> implementations of compile/link tools. For prototyping purposes -toolexec 
> flag allows me to insert a proxy that intercepts compiler/linker invocations 
> and invokes GopherJS as required. The nice thing is that no GopherJS-specific 
> code needs to exist in the cmd/go codebase.
>
>  I'm currently at a very early stage, but it seems to be working out. Before 
> I spend too much time though, I'd like to probe people's opinions of a few 
> questions:
>
> 1) Is the idea of treating cmd/compile, cmd/link (and so on) interfaces as an 
> extension point a reasonable one? I expect that they are going to change 
> between releases, but probably fewer than the build system as a whole.

I suspect this will give you trouble over time.  When the go tool
invokes cmd/compile and cmd/link, it expects them to behave just like
the ordinary cmd/compile and cmd/link commands.  For example, it
expects cmd/link to create a build ID that can be recognized by
cmd/internal/buildid.  It expects to be able to pack additional
objects into archive files (see packInternal in
cmd/go/internal/work/gc.go).  There may be other complex dependencies,
and certainly more will be added over 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/CAOyqgcXpU6A0K5w%3DgN5B_UBtxMXBzpdhu9-UDo55%3Dzab8Jfj-w%40mail.gmail.com.

[go-nuts] Using go tool with third-party Go implementations

[Alexander Zhirov]

Hi all,

At the moment there are at least three alternative implementations of Go 
that I know of (and there are probably some I don't): gccgo, tinygo and 
gopherjs. Of the three, only gccgo is supported by the go tool out of box. 
Looking at the source code, gc ang gccgo have their own implementations of 
the toolchain interface 

.

The other two essentially reimplement the built system using go/build 
package, and, based on my experience with GopherJS, keeping up with changes 
to the upstream Go build tooling (modules, file embedding, etc.) is a lot 
of effort.

Out of interest, I was investigating what would it take for GopherJS to 
delegate build system details to the Go tool and only provide alternative 
implementations of compile/link tools. For prototyping purposes -toolexec 
flag allows me to insert a proxy that intercepts compiler/linker 
invocations and invokes GopherJS as required. The nice thing is that no 
GopherJS-specific code needs to exist in the cmd/go codebase.

 I'm currently at a very early stage 
, but it seems to 
be working out. Before I spend too much time though, I'd like to probe 
people's opinions of a few questions:

1) Is the idea of treating cmd/compile, cmd/link (and so on) interfaces as 
an extension point a reasonable one? I expect that they are going to change 
between releases, but probably fewer than the build system as a whole.
2) Using toolexec to intercept the calls works, but I assume this isn't 
it's intended purpose. I see no problem with using it, maybe I'm missing 
something?
3) Sort of related to #2, go tool would still check for supported 
GOOS/GOARCH pair, which is irrelevant to third-party compilers.

Cheers,
Alex.

-- 
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/4163ac21-435b-4186-966e-5d1f8f20d200n%40googlegroups.com.

Re: [go-nuts] A value saved in an interface{} field in a struct not usable in func with interace{} arg

[Ian Davis]

In genBox your code is saying that val contains a pointer to interface{}. In 
other words its an interface{} that contains a *interface{}. That is a weird 
but valid construct.

I suggest you dereference it and see what the contained interface holds. 
Something like:

valDeref := val.(*interface{})

 fmt.Printf("val contains=%T", valDeref)

You may find that valDeref contains the *int64 you are looking for.

As an aside, *interface{} is usually an indication that someone somewhere is 
passing the wrong value to the function since it almost never makes sense to 
pass a pointer to interface{}.





On Mon, 11 Jan 2021, at 4:03 PM, Steve Murphy wrote:
> Hello!
> 
> I keep getting:
> panic: interface conversion: interface {} is *interface {}, not *int64 
> [recovered]
> panic: interface conversion: interface {} is *interface {}, not *int64
> 
> I *suspect* what is happening is that the KDElem struct has an item field 
> whose 
> type is interface{}, so that you can store a pointer to some struct (of your 
> own making),
> or an index into an array of structs, or... *whatever*, but in my case, it's 
> an index into an array
> of objects. The itemfunc (or genBox in my test code) is supposed to set the 
> item field in 
> the KDElem struct to the proper index, as the struct has just been created, 
> and the job
> of the itemfunc is to make it point to the right object, and set the bounds 
> info in the new struct.
> 
> type KdElem struct {
> item   interface{} // a ptr to a particular struct, or an index into 
> an array of objects, or
> ...
> }
> 
> And the func that calls the itemfunc (genBox) looks like this:
> 
> func loadItems(itemfunc func(arg interface{}, val interface{}, size *KdBox) 
> int, arg interface{}, extent KdBox, length *int64, mean *float64) *KdElem {
>  ...
>  newItem = new(KdElem)
>  if itemfunc(arg, , newItem.size) != 0 {
>  ...
> 
> 
> And, in this case the itemfunc declaration looks like this:
> 
> func genBox(arg interface{}, val interface{}, box *KdBox) int {
>  var offsetp = arg.(*int64) // successful
>  var offset = *offsetp // successful
>  // fmt.Printf("genBox: offset=%v offsetp=%v\n", offset, offsetp)
>  fmt.Printf("genBox: arg type=%T argval=%v, val type=%T, val 
> val=%v\n", arg, arg, val, val)
>  if offset < KDBoxes {
>   fmt.Printf("genBox: val=%v  *int64=%v\n", val, val)
>   var realval *int64 = val.(*int64) //  <<-- This is line 43!  
> Compiles but... Crash!!!
>   *realval = offset + 1
> ...
> 
> Now, I get this from a go test:
> 
> KdBuild: arg type=*int64  argval=0xcd2078; 
> genBox: arg type=*int64 argval=0xcd2078, val type=*interface {}, val 
> val=0xcba640
> genBox: val=0xcba640  *int64=0xcba640
> --- FAIL: TestKd1 (0.08s)
> panic: interface conversion: interface {} is *interface {}, not *int64 
> [recovered]
> panic: interface conversion: interface {} is *interface {}, not *int64
> 
> goroutine 19 [running]:
> testing.tRunner.func1(0xc000108100)
> /usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
> panic(0x523360, 0xcc2360)
> /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
> parsetree.com/kdtree.genBox(0x50eec0, 0xcd2078, 0x50ef40, 0xcba640, 
> 0x0, 0x0)
> /home/murf/go/kdtree/kdtree1_test.go:43 +0x270
> parsetree.com/kdtree.loadItems(0x5570f8, 0x50eec0, 0xcd2078, 
> 0x7fff, 0x7fff, 0x8000, 
> 0x8000, 0xc00096ab38, 0xc00096ab30, 0x0)
> /home/murf/go/kdtree/kdtree.go:683 +0xec
> parsetree.com/kdtree.KdBuild(0x5570f8, 0x50eec0, 0xcd2078, 0x0)
> /home/murf/go/kdtree/kdtree.go:168 +0x17e
> parsetree.com/kdtree.TestKd1(0xc000108100)
> /home/murf/go/kdtree/kdtree1_test.go:72 +0x13a
> testing.tRunner(0xc000108100, 0x5570f0)
> /usr/lib/go-1.13/src/testing/testing.go:909 +0
> 
> How do I set realval to the (*int64) value that's in val?
> 
> murf
> 
> 
> -- 
> 
> Steve Murphy
> ParseTree Corporation
> 57 Lane 17
> Cody, WY 82414
> ✉  murf at parsetree dot com
> ☎ 307-899-0510
> 

> -- 
> 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/CAPPCp8HGQAcdw7J_vFLW8NKsXqfh5kgUtCrQn41dBLRamQggNA%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 

[go-nuts] A value saved in an interface{} field in a struct not usable in func with interace{} arg

[Steve Murphy]

Hello!

I keep getting:
panic: interface conversion: interface {} is *interface {}, not *int64
[recovered]
panic: interface conversion: interface {} is *interface {}, not *int64

I *suspect* what is happening is that the KDElem struct has an item field
whose
type is interface{}, so that you can store a pointer to some struct (of
your own making),
or an index into an array of structs, or... *whatever*, but in my case,
it's an index into an array
of objects. The itemfunc (or genBox in my test code) is supposed to set the
item field in
the KDElem struct to the proper index, as the struct has just been created,
and the job
of the itemfunc is to make it point to the right object, and set the bounds
info in the new struct.

type KdElem struct {
item   interface{} // a ptr to a particular struct, or an index
into an array of objects, or
...
}

And the func that calls the itemfunc (genBox) looks like this:

func loadItems(itemfunc func(arg interface{}, val interface{}, size *KdBox)
int, arg interface{}, extent KdBox, length *int64, mean *float64) *KdElem {
 ...
 newItem = new(KdElem)
 if itemfunc(arg, , newItem.size) != 0 {
 ...


And, in this case the itemfunc declaration looks like this:

func genBox(arg interface{}, val interface{}, box *KdBox) int {
 var offsetp = arg.(*int64) // successful
 var offset = *offsetp // successful
 // fmt.Printf("genBox: offset=%v offsetp=%v\n", offset, offsetp)
 fmt.Printf("genBox: arg type=%T argval=%v, val type=%T, val
val=%v\n", arg, arg, val, val)
 if offset < KDBoxes {
  fmt.Printf("genBox: val=%v  *int64=%v\n", val, val)
  var realval *int64 = val.(*int64) //  <<-- This is line 43!
Compiles but... Crash!!!
  *realval = offset + 1
...

Now, I get this from a go test:

KdBuild: arg type=*int64  argval=0xcd2078;
genBox: arg type=*int64 argval=0xcd2078, val type=*interface {},
val val=0xcba640
genBox: val=0xcba640  *int64=0xcba640
--- FAIL: TestKd1 (0.08s)
panic: interface conversion: interface {} is *interface {}, not *int64
[recovered]
panic: interface conversion: interface {} is *interface {}, not *int64

goroutine 19 [running]:
testing.tRunner.func1(0xc000108100)
/usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
panic(0x523360, 0xcc2360)
/usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
parsetree.com/kdtree.genBox(0x50eec0, 0xcd2078, 0x50ef40, 0xcba640,
0x0, 0x0)
/home/murf/go/kdtree/kdtree1_test.go:43 +0x270
parsetree.com/kdtree.loadItems(0x5570f8, 0x50eec0, 0xcd2078,
0x7fff, 0x7fff, 0x8000,
0x8000, 0xc00096ab38, 0xc00096ab30, 0x0)
/home/murf/go/kdtree/kdtree.go:683 +0xec
parsetree.com/kdtree.KdBuild(0x5570f8, 0x50eec0, 0xcd2078, 0x0)
/home/murf/go/kdtree/kdtree.go:168 +0x17e
parsetree.com/kdtree.TestKd1(0xc000108100)
/home/murf/go/kdtree/kdtree1_test.go:72 +0x13a
testing.tRunner(0xc000108100, 0x5570f0)
/usr/lib/go-1.13/src/testing/testing.go:909 +0

How do I set realval to the (*int64) value that's in val?

murf

-- 

Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉  murf at parsetree dot com
☎ 307-899-0510

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

Re: [go-nuts] Golang vs Python: Complete Comparison with their Top Frameworks

[Nikolay Dubina]

I would expected to see at these two things:

1. That most of the serious solutions in "Python" are actually wrappers for 
highly optimized machinery in C/C++. If you look at just basic ML stack: 
Pytorch, Tensorflow, OpenCV, numpy, scipy, XGBoost, so on. all is in C/C++ 
with wrapper in Python.
2. Language itself. Go syntax is unusable for data-wrangling and data 
science, while Python is very friendly. I am talking about things like: 
multi-dimensional arrays and indexing; standard library data structures 
like sets; short lambdas notation; ternary; errors vs try-catch semantics; 
operator overloading...

Python is not just webservers, as opposed to Go. Lastly, pure "Python" is 
slow. But given a lot of serious code is in C/C++ underneath, uses 
green-treads (like gunicorn), does batch processing, makes lots of GPU 
calls (which Go has no support at all)... it is debatable if Python is 
slower than Go. It depends on application.

- Nikolay

-- 
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/1dcc8d41-23e6-44f3-bf42-da3656500f56n%40googlegroups.com.