Re: [go-nuts] Elphaba Chess

On Friday, December 1, 2017 at 8:47:50 PM UTC-7, Bakul Shah wrote: > There seem to be many chess related packages: > https://golanglibs.com/top?q=chess > I'll look into these --- thanks --- I was not aware of this golanglibs website. -- You received this message because you are

Re: [go-nuts] Elphaba Chess

On Fri, 01 Dec 2017 18:35:34 -0800 hughaguila...@gmail.com wrote: hughaguila...@gmail.com writes: > > On Friday, December 1, 2017 at 5:54:44 PM UTC-7, Bakul Shah wrote: > > > > You should consider writing a chess program from scratch. It could be a > > lot of fun! > > > > If you start with a

Re: [go-nuts] Elphaba Chess

On Friday, December 1, 2017 at 5:54:44 PM UTC-7, Bakul Shah wrote: > > You should consider writing a chess program from scratch. It could be a > lot of fun! > > If you start with a mature chess playing engine, you wouldn't learn as > much and you would spend time fighting/interfacing with the

Re: [go-nuts] Elphaba Chess

You should consider writing a chess program from scratch. It could be a lot of fun! If you start with a mature chess playing engine, you wouldn't learn as much and you would spend time fighting/interfacing with the engine. Since your chess is not quite the same as a regular chess, you may find

Re: [go-nuts] Re: Elphaba Chess

On Friday, December 1, 2017 at 4:45:39 PM UTC-7, matthe...@gmail.com wrote: > > Hugh, > > Go is a general purpose programming language that is open source and > permissively licensed, and there is no obvious reason for Google or other > contributors to change this. I strongly recommend it for

Re: [go-nuts] Re: Elphaba Chess

On Fri, Dec 1, 2017 at 3:44 PM, wrote: > > Here’s an explanation behind my assumptions about Go: > > Recently I encountered a crash in the latest stable version of Go that > blocked my development and was root caused to a mistake in how pointers are > handled as map keys

Re: [go-nuts] Re: Elphaba Chess

Here's the golang-nuts topic and it has a link to the github issue: https://groups.google.com/forum/#!topic/golang-nuts/7lcongdGOMM The fix code is quite involved in the map implementation. Matt On Friday, December 1, 2017 at 5:52:24 PM UTC-6, andrey mirtchovski wrote: > > > Recently I

Re: [go-nuts] Re: Elphaba Chess

> Recently I encountered a crash in the latest stable version of Go that > blocked my development and was root caused to a mistake in how pointers are > handled as map keys by the runtime. can you share this bug? perhaps by making it more visible we can, as a team, solve any nascent dependancies

Re: [go-nuts] Re: Elphaba Chess

Hugh, Go is a general purpose programming language that is open source and permissively licensed, and there is no obvious reason for Google or other contributors to change this. I strongly recommend it for your project, although Clownfish is a robust existing project. Maybe I’ll have a mature

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

This would add a branch to the interface dispatch semantics, and while the branch is probably predictable, it would increase the size of every call site. Some benchmarking would be needed to demonstrate that the branch is less costly than a jump and immediate return sequence. The correct

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

I don’t have specific knowledge about how this works - but wouldn’t it be fairly easy to test by having the compiler emit the assembly code? -- Michael Banzon https://michaelbanzon.com/ > Den 1. dec. 2017 kl. 19.42 skrev Ugorji Nwoke : > > Thanks Ian. > > This is not so

[go-nuts] New easy to use testing (+http testing) library

go get -u github.com/alexbyk/ftest import (   "testing"   "github.com/alexbyk/ftest" ) func TestFoo(t *testing.T) {   ftest.New(t).Eq(2, 2).     Contains("FooBarBaz", "Bar").     PanicsSubstr(func() { panic("Foo") }, "Foo") } -- You received this message because you are subscribed to the

Re: [go-nuts] Re: Elphaba Chess

Go is an open-source language. It's not "tied" to anything. Yes, Google invests in its development but so do other companies and many, many open source developers. It has a strong place in modern data centers but it is being used in just about every place imaginable now; some have even done kernel

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

Yes. Fundamentally, I'm asking if step #2 in your calling sequence can be optimized. 1. load a function pointer from the itab 2. call the function pointer. *However, if the function pointer to is empty, just do a NOP here and skip the function-call-dance. This should be possible as the i-tab

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

On Fri, Dec 1, 2017 at 10:42 AM, Ugorji Nwoke wrote: > > This is not so much about de-virtualization. It's about not making a call to > an empty function i.e. I expect that interface calls come down to > 1. dereference the pointer to the i-tab, > 2. jump to the appropriate

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

I did, but couldn't infer my answer out of the assembly. I see the following below, but it's not clear if the call is made, or if the linker does some optimization after the compiler step. See below: "".T1.Do STEXT nosplit size=1 args=0x8 locals=0x0 0x 0 (check-interface-noop-call.go:15)

[go-nuts] Using visual C++ as the c compiler for CGo

Hi - I know this has been asked before, but I can't find a recent answer. Is it possible to use the visual studio compiler for cgo instead of gcc? If not, is there a project underway? If not, can someone point me to how I might contribute such a thing? Thanks -- You received this message

[go-nuts] Re: The "declared and not used" error

Go will throw an error when a variable isnt 'used' ( which is often the case when developing ), but will not throw errors if the code has unnecessary loops, logical errors, or other more serious problems. This does not make the code better, nor the coder magically reflect on how their code can

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

Thanks Ian. This is not so much about de-virtualization. It's about not making a call to an empty function i.e. I expect that interface calls come down to 1. dereference the pointer to the i-tab, 2. jump to the appropriate function in the i-tab, 3. call that function. If that function is a

[go-nuts] Re: profiling webserver with pprof and router middleware

Specifically, I wanted to see heap allocations generated by incoming requests, so I can optimize my handler functions I will write a more basic webserver example to see if I can produce the result I am expecting Am Donnerstag, 30. November 2017 14:39:56 UTC+1 schrieb Karan Chaudhary: > >

[go-nuts] Re: Elphaba Chess

On Friday, December 1, 2017 at 7:41:24 AM UTC-7, matthe...@gmail.com wrote: > > I don't speak for the language developers but as far as I can tell Go is > always going to be tied to Google's business of datacenter-based network > and web services, so if you want your game as something other

Re: [go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

On Fri, Dec 1, 2017 at 2:40 AM, Ugorji Nwoke wrote: > > I know that a no-op function call is optimized away, as it is inlined to > nothing. > > However, what about a no-op interface call? > > See sample code: > > type I interface { Do(int) } > type T1 struct{} > func (_ T1) Do(i

[go-nuts] Re: Elphaba Chess

The code isn't licensed for use (please don't modify it for your variation) but it's posted on github publicly, feel free to read my HTTP server with database backend for inspiration of how such a thing could work: https://github.com/pciet/wichess There's a web client that works on smartphones

Re: [go-nuts] Re: network programming about go

TCP doesn't preserve message delimiters. There is no guarantee that one write will be one read on the remote side even if they appear to be reading and writing in lockstep. On Monday, November 13, 2017 at 1:57:33 PM UTC-8, Justin Israel wrote: > > > > On Mon, Nov 13, 2017 at 4:00 PM

[go-nuts] are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

I know that a no-op function call is optimized away, as it is inlined to nothing. However, what about a no-op interface call? See sample code: type I interface { Do(int) } type T1 struct{} func (_ T1) Do(i int) {} func main() { var v I v = T1{} v.Do(1) } Is it safe to assume the following

Re: [go-nuts] Re: Sort a huge slice of data around 2GB

If you know keys distribution, you may first split data on N non-intersecting buckets, where N is number of CPU cores, and then use Sort on each bucket in parallel. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group