simran | 29 May 09:31 2016

Asserting a slice of one type to another...

Hi All, 

Is there an easy way to cast / assert that a slice of one type is an slice of another equivalent type? 

eg. 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
package main

import "fmt"

type Word string

func main() {
    words := []Word{"one", "two", "three"}
    printStrings(words)
}


func printStrings(stringSlice []string) {
    for _, str := range stringSlice {
        fmt.Println("String is:", str)
    }
}
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Code also located at: https://play.golang.org/p/HEPDRuUemw
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The above produces the error:
./main.go:9: cannot use words (type []Word) as type []string in argument to printStrings

As we can see though, a "Word" is a "string", although a part of me appreciates why the above is now allowed, my question is - is there an easy "one line" sort of way to do something like:
strs := words.([]string)
The above doesn't work of course, if i try that, it gives the error:
./main.go: invalid type assertion: words.([]string) (non-interface type []Word on left)

I would write a func like this (and incorporate it into the above code to make it work):
func wordsToStrings(words []Word) []string {
  str := []string{}
  for _, w := range words {
    str = append(str, string(w))
  }
  return str
}

However, i suspect there is a quicker, shorter, one-line type of way that i'm not aware of that hopefully the community can enlighten me to :) 

thanks,

simran.







--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Maxim Kupriianov | 28 May 20:11 2016
Gravatar

[ANN] android-go: Full Golang Bindings for Android NDK API with Examples

The android-go project aims to provide a platform (namely an SDK) for
writing native Android apps in Go programming language. All things here were
designed to be less coupled as possible, thus maintaining a great level of
flexibility while keeping things simple and easy to use. The approach and tools
are different from gomobile, but the latter has inspired me a lot.

https://github.com/xlab/android-go

Comments and ideas are welcome!
There are two example apps and one demo:
https://www.youtube.com/watch?v=H2cafzATUEw

--
Regards,
Maxim Kupriianov

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Tong Sun | 28 May 19:42 2016
Picon

go get: You are not currently on a branch

How to fix the "You are not currently on a branch" error for `go get`?

$ go get -u github.com/mattn/go-sqlite3
# cd .../src/github.com/mattn/go-sqlite3; git pull --ff-only
From https://github.com/mattn/go-sqlite3
 * [new branch]      gh-pages   -> origin/gh-pages
   bbd33c0..38ee283  master     -> origin/master
 * [new branch]      systemlib  -> origin/systemlib
 * [new tag]         v1.0.0     -> v1.0.0
 * [new tag]         v1.1.0     -> v1.1.0
You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

package github.com/mattn/go-sqlite3: exit status 1


--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Tong Sun | 28 May 16:53 2016
Picon

golang how to specify empty array

Sorry I just can't make it work myself:

parameters := struct {
From    mail.Address
To      []mail.Address
Subject string
Body    string
}{
{},
[]mail.Address, // []mail.Address{}
subject,
body,
}

How to initialize `parameters.To` to an empty array? 

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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
krupal shah | 28 May 08:15 2016
Picon

Nil Safety in Go

Are there any plans for including nil aware operators in Go. Like swift's optional and Dart's null aware operators (?,?.)

f, err := os.Open(fileName) if err != nil { return err }........
This would make rror handling very easy and consice:
f, err := os.Open(fileName) if err? return err........
Also this would bring nil safety in a language.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Tong Sun | 28 May 15:15 2016
Picon

Go variables override at compile time

The link option -X allows us to override Go variables at compile time. 

Is there any way to provide values with spaces?

I've prepared a test sample file, at
https://github.com/suntong/blob/master/lang/Go/src/sys/VarOverride.go

I.e., while `go run -ldflags="-X main.name=Fred" VarOverride.go` works,
the following don't:

    go run -ldflags="-X main.name='John Doe'" VarOverride.go
    go run -ldflags="-X main.name='John\ Doe'" VarOverride.go
    go run -ldflags="-X main.name=John\ Doe" VarOverride.go
    go run -ldflags="-X main.name=\"John Doe\"" VarOverride.go


Is it possible to make it work? 

Thanks

On Fri, Jan 15, 2016 at 5:25 PM, Caleb Spare <cespare-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
The link option -X is probably what you want.

https://golang.org/cmd/link/

This blog post is one description of how it works:
https://blog.cloudflare.com/setting-go-variables-at-compile-time/

On Fri, Jan 15, 2016 at 2:21 PM, Tong Sun <suntong001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I think having a constant of build-time would ease my attempt to keep track
> of my version-ing. Many of tools I built myself don't following a rigid
> versioning scheme, because I use the `rcs` auto-version-increase previously,
> but since switching to git, I lost that automatic versioning feature, and I
> really don't want to maintain a separated file, and/or any extra effort on
> it. But I still need to know if an executable if the latest or not, how old
> it was, etc, so it'd be good to know when an executable was built. And a
> constant of build-time would be the best answer.
>
> What's the simplest way to identify an executable's "build-version", if a
> constant of build-time is/will-not-be not available?
>
> 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

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Paulo Coutinho | 28 May 05:49 2016
Gravatar

My HTML5 game open-source using Go as websocket server

Hi,

I want share my two new projects using Golang. 

A HTML5 bomberman like game and his multiplayer server using golang and websocket.

https://github.com/prsolucoes/golandy-server
and
https://github.com/prsolucoes/golandy-web

The game is registered in: www.golandy.com

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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Kyle Stanly | 27 May 21:46 2016
Picon

How would I go about adding my own builtin type for compatibility with make(...) and existing syntax

I would like to open up this question by stating: Yes, I know you cannot do this normally, and yes I know this would require making internal modifications to the Go language and compiler. That's exactly what I am planning on doing. My reasoning for doing so is purely academic and hopefully to make a contribution to the Go programming language as well. I'm in an R.E.U (Research Experience for Undergraduates) program, and for the next 10 weeks, this will be my research. However, even for 10 weeks, if I just made various changes to the source code, without needing to mention massive time needed to rebuild source (Unless it only rebuilds files which were changed like a Makefile) could easily eat up a week or two of frustration. Not to mention that the Go source code is HUGE.

I've managed to pinpoint usage of `makeslice` and `makemap` in cmd\compile\internal\*, so at least I can see how the compiler goes about converting `make(...)` into it's appropriate function call. I was thinking of merely adding my own `make*` stuff where it normally looks for that kind of stuff, however I'm assuming a simple Find across all files for patterns I THINK are used just might not cut it. Hence, I'm inquiring, hopefully from an actual developer or maintainer of the source code, as to how the builtin type for `make(...)` works and how the compiler converts it at runtime, and how I can go about modifying that.

Finally, if I did manage to do so, would this somehow break Go's compatibility policy? I wouldn't think that it would break old code, unless you attempted to use the new type with an old compiler. I'm asking because I want to know if this is a fruitless task (although personally I definitely will learn a LOT about the language internally even if it doesn't get accepted) and if I should think smaller. This more of a prerequisite for the real, actual end-goal however, and this would be an huge indicator in to whether or not that goal was possible.

To give a bit of a hint for the first improvement to the Go language that is planned:

Adding an actual concurrent hashmap, without modifying the normal map. Modifying the hashmap would break the compatibility requirement, and its already been stated that they do not want to add a concurrent map because most uses wouldn't need to use locks, however I'm thinking... why not just give an option? A simple `make(cmap[string]string)` with support for normal map syntax, `cm["Hello"] = "World"`. If I emulate what the original map does, would this be possible, and more importantly, would this break anything? 

Any help would be appreciated, preferably a list of files that need to be modified to make this happen (I can easily figure out the rest... or rather I hope so). Narrowing the research down to a few select files would help IMMENSELY.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Christoph Berger | 27 May 19:56 2016
Picon

New blog: Applied Go

Hi everyone,

I keep it short - I started a new Go blog. The intent behind this is to help me and others getting more proficient with Go. Find more about it in the About and FAQ sections.

https://appliedgo.net

The first post is a quick and very basic introduction to messaging. Enjoy and let me know what you think! 

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
solignac.t | 27 May 19:37 2016
Picon

About "this" usage and good practices

Hello, I would like to discuss with you about the use of "this" in Golang, for the name of a method's receiver .
type User struct {
name string
} func (this User) GetName() string {
return this.name
}
Instead of that, you can see in the tool for go code review : "The name of a method's receiver should be a reflection of its identity; often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client"). Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that place more emphasis on methods as opposed to functions. The name need not be as descriptive as a that of a method argument, as its role is obvious and serves no documentary purpose. " (Source : https://github.com/golang/go/wiki/CodeReviewComments) So, it should be :
func (u User) GetName() string {
return this.name
}
I browsed the web, and I have not found any convincing reason for this. Rather than very abstract, I propose to study the issue through the criteria for assessing the quality of a code. Let's go : "this" vs "u' First let's eliminate the the unrelated criteria : ->Accuracy : Wanted results in normal conditions ->Robustness : Ability to respond well when deviates from normal use ->Portability : Easiness to use software in different environments ->Efficiency : Execution time , memory size ... ->Extensibility : Ability to be adapted to another problem No effect on these points. Good. Let's move . -> Readable code : Easiness to understand a code quickly Software evolve, and several teams work on it ; it must be quick to word on a old code or something done by someone else. Once again, it does nothing more, for the same reasons as extensibility. We could argue here that "u" may be more clear than "this". The good point for "u" is that it's shorter. Understand code is time consuming, and can be misleading. Anyway, it's redundant this the struct name, so it does nothing more.
-> Maintainability : Easiness to fix bugs or to do light behavior modifications

The use of "this" is very standard. It's necessary, of course, to make an official choice between "this" and "self". Maintainability is about design (no effect here) and readability. We could add here, that "u" asks the reader to read the declaration and remembers one more variable. Referring to previous points : nothing new. I think this quick tour is enough. Let's summarize : This : Standard so readable, universal meaning "u" : No new information, add a new variable to remember, possibly misleading Thank you for reading, I woud like to know your opinions.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
苏沛 | 27 May 12:57 2016
Picon
Gravatar

weird encoding/json.Unmarshal behavior

type Parent struct {
    ID    int
    Child interface{}
}

type ChildT struct {
    ID int
}


json string {"ID":2,"Child":{"ID":3}}

When field Child has value ChildT{}, field Child unmarshals into type map[string]int
When field Child has value &ChildT{}, field Child unmarshals into type *ChildT.

https://play.golang.org/p/LkbbOz0ytb


-- 
苏沛

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Gmane