[go-nuts] Re: Shiny examples don't work on macOS Sierra 10.12.4

[Dmitry Kravchenko]

OK, thanks.
The workaround mentioned in that thread is to use go run -ldflags -s

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Shiny examples don't work on macOS Sierra 10.12.4

[James Bardin]

See https://golang.org/issue/19734


On Saturday, April 1, 2017 at 1:39:36 PM UTC-4, Dmitry Kravchenko wrote:
>
> After update to macOS Sierra 10.12.4 Shiny examples don't work anymore.
>
> iMac-Dmitry:~ dmitrykravchenko$ go env
>
> GOARCH="amd64"
>
> GOBIN="/Users/dmitrykravchenko/gowsp/bin"
>
> GOEXE=""
>
> GOHOSTARCH="amd64"
>
> GOHOSTOS="darwin"
>
> GOOS="darwin"
>
> GOPATH="/Users/dmitrykravchenko/gowsp"
>
> GORACE=""
>
> GOROOT="/usr/local/go"
>
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
>
> GCCGO="gccgo"
>
> CC="clang"
>
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/go-build413428417=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common"
>
> CXX="clang++"
>
> CGO_ENABLED="1"
>
> PKG_CONFIG="pkg-config"
>
> CGO_CFLAGS="-g -O2"
>
> CGO_CPPFLAGS=""
>
> CGO_CXXFLAGS="-g -O2"
>
> CGO_FFLAGS="-g -O2"
>
> CGO_LDFLAGS="-g -O2"
>
> iMac-Dmitry:~ dmitrykravchenko$ go run gowsp/src/
> golang.org/x/exp/shiny/example/basic/main.go
>
> signal: killed
>
> iMac-Dmitry:~ dmitrykravchenko$ go run gowsp/src/
> golang.org/x/exp/shiny/example/basicgl/main.go
>
> signal: killed
>
>
>
> Starting a program in IDEA Golang plugin also fails.
>
> "/private/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/Build gui.go and 
> rungo"
>
> GOROOT=/usr/local/go
>
> GOPATH=/Users/dmitrykravchenko/gowsp
>
> /usr/local/go/bin/go build -o 
> "/private/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/Build gui.go and 
> rungo" /Users/dmitrykravchenko/gowsp/src/ideprj/main/gui.go
>
>
> Process finished with exit code 137 (interrupted by signal 9: SIGKILL)
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: I cannot understand this channel behavior, is one channel ops affect another channel ops

[James Bardin]

Wasn't this already answered for you 
here? 
https://stackoverflow.com/questions/43152776/is-it-one-channel-ops-affect-another-channel-ops

On Saturday, April 1, 2017 at 1:35:12 PM UTC-4, Khalid Adisendjaja wrote:
>
> I made this simple script, trying to understand how is channel working, 
> somehow if channel "c" is sent after channel "b" is sent the last routine 
> is not being proceed,
> please see the runner function
>
> package main
>
> import (
>  "fmt"
>  "strconv"
>  "time"
> )
>
> func runner(idx int, c chan []int, b chan []int) {
>  var temp []int
>  fmt.Println("runner " + strconv.Itoa(idx))
>  bucket := <-b
>  for k, v := range bucket {
>   if v != 0 {
>temp = append(temp, v)
>bucket[k] = 0
>   }
>   if len(temp) == 5 {
>break
>   }
>  }
>
>  //Strange condition if channel c is sent after channel b is sent,
>  //somehow the last runner is not being proceed
>  b <- bucket
>  c <- temp
>
>  //All runner ara all proceed if c is sent first
>   // c <- temp
>   // b <- bucket
>
> }
>
> func printer(c chan []int) {
>  for {
>   select {
>   case msg := <-c:
>fmt.Println(msg)
>time.Sleep(time.Second * 1)
>   }
>  }
> }
>
> func main() {
>
>  c := make(chan []int, 5)
>  bucket := make(chan []int)
>
>  go runner(1, c, bucket)
>  go runner(2, c, bucket)
>  go runner(3, c, bucket)
>  go runner(4, c, bucket)
>
>  bucket <- []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 
> 16, 17, 18, 19, 20}
>
>  go printer(c)
>
>  var input string
>  fmt.Scanln()
>
> }
>
>
>  
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: package, files at build (in relation to plugins, -linkshared, -buildmode=shared, ....)

[Basile Starynkevitch]

On Saturday, April 1, 2017 at 6:38:23 PM UTC+2, Basile Starynkevitch wrote:

> Is there a way to understand where the mandatory 
> go install -buildmode=shared std
> is installing its stuff?
>
> Is there a way to check that the above command has been previously and 
> successfully run?
>


I found some way, see my monimelt/get-monimelt-dependencies.sh 
 
script:


mygoarch=$(go env GOARCH)  ## e.g. amd64
mygoos=$(go env GOOS)  ## e.g. linux
mygoroot=$(go env GOROOT)  ## e.g. /usr/local/go


## check that go install -buildmode=shared std has been run once
if [ -f $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/fmt.shlibname ]; then
myfmtshlibname=$(head -1 $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/fmt
.shlibname)
if [ ! -f $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/$myfmtshlibname ]; 
then
echo 1>&2
echo you should have done: go install -buildmode=shared std 1>&2
echo ... but $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/$myfmtshlibname 
is missing 1>&2
echo ... using content of $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/
$myfmtshlibname
echo >&2
exit 1
else
echo you did run: go install -buildmode=shared std
echo ... because we got: $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/fmt
.shlibname
echo ... pointing to: $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/
$myfmtshlibname
fi

else
echo 1>&2
echo you should have done: go install -buildmode=shared std 1>&2
echo ... but $mygoroot/pkg/${mygoos}_${mygoarch}_dynlink/fmt.shlibname 
is missing 1>&2
echo >&2
exit 1
fi


Now, I have to understand how to use go tool compile (probably with make). 
It looks that the go command is not suitable for me.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

[Val]

Alex, this thread may be lost but please don't give up beyond this thread.
I read all of it and agree 100% to everything you said.

In short: what you suggest has exactly the same implications and same benefits 
as the "often randomized order of map iteration" implementation detail. I think 
it is useful and goes in the right direction.

Val

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Shiny examples don't work on macOS Sierra 10.12.4

[Dmitry Kravchenko]

After update to macOS Sierra 10.12.4 Shiny examples don't work anymore.

iMac-Dmitry:~ dmitrykravchenko$ go env

GOARCH="amd64"

GOBIN="/Users/dmitrykravchenko/gowsp/bin"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH="/Users/dmitrykravchenko/gowsp"

GORACE=""

GOROOT="/usr/local/go"

GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"

GCCGO="gccgo"

CC="clang"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 
-fdebug-prefix-map=/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/go-build413428417=/tmp/go-build
 
-gno-record-gcc-switches -fno-common"

CXX="clang++"

CGO_ENABLED="1"

PKG_CONFIG="pkg-config"

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

iMac-Dmitry:~ dmitrykravchenko$ go run 
gowsp/src/golang.org/x/exp/shiny/example/basic/main.go

signal: killed

iMac-Dmitry:~ dmitrykravchenko$ go run 
gowsp/src/golang.org/x/exp/shiny/example/basicgl/main.go

signal: killed



Starting a program in IDEA Golang plugin also fails.

"/private/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/Build gui.go and 
rungo"

GOROOT=/usr/local/go

GOPATH=/Users/dmitrykravchenko/gowsp

/usr/local/go/bin/go build -o 
"/private/var/folders/v1/6r0pb6213g5b76xwgwp35b20gn/T/Build gui.go and 
rungo" /Users/dmitrykravchenko/gowsp/src/ideprj/main/gui.go


Process finished with exit code 137 (interrupted by signal 9: SIGKILL)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: package, files at build (in relation to plugins, -linkshared, -buildmode=shared, ....)

[Basile Starynkevitch]

On Saturday, April 1, 2017 at 2:59:16 AM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Mar 31, 2017 at 9:28 AM, Basile Starynkevitch 
>  wrote: 
> > 
> > On Friday, March 31, 2017 at 4:14:19 PM UTC+2, Ian Lance Taylor wrote: 
> >> 
> >> On Fri, Mar 31, 2017 at 6:49 AM, Ian Lance Taylor  
> >> wrote: 
> >> > 
> >> > It depends.  The main command that generates output is `go install`, 
> >> > and it stores the output under $GOROOT/pkg. 
> >> 
> >> Whoops, I meant $GOPATH/pkg.  $GOROOT/pkg is only used for the standard 
> >> library. 
> > 
> > 
> > 
> > I'm still really confused by getting quite often a very cryptic message: 
> > 
> >  multiple roots /home/basile/go/pkg/linux_amd64 & 
> > /usr/lib/go-1.8/pkg/linux_amd64_dynlink 
> > 
> > the funny thing is that both of these are directories, not files. In my 
> > understanding that message means a conflict between two files for the 
> same 
> > package. And I have no idea about what files have been conflicting. If 
> the 
> > message is a conflict between files, why does not it name these files? 
>
> That error message means that the go tool does not know where to 
> install a file.  It may mean that you are trying to use 
> -buildmode=shared with some standard library packages and some 
> packages from your GOPATH.  It's not a conflict between different 
> files; it's talking about which directory it should put the shared 
> library in. 
>
> Ian 
>


Is there a way to understand where the mandatory 
go install -buildmode=shared std
is installing its stuff?

Is there a way to check that the above command has been previously and 
successfully run?

Is there a way to avoid the cryptic message:
multiple roots /home/basile/go/pkg/linux_amd64 &  
/usr/lib/go-1.8/pkg/linux_amd64_dynlink 

perhaps by forcing in which directory a file should be installed?

(If there is some way to avoid that multiple roots message, I would suggest 
that the error message would mention it; giving only the two words multiple 
roots as an explanation is really not enough)

Cheers.

Basile Starynkevitch
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to abort the http ResponseWriter

[Song Liu]

Finally I added a Close function into the ResponseWriter, sadly.

On Saturday, April 1, 2017 at 8:12:55 PM UTC+8, Song Liu wrote:
>
>
> I am implementing a file server, so http.ServerFile used to write back the 
> file content to remote client:
>
>
> func downloadFile(w http.ResponseWriter, r *http.Request, p 
> httprouter.Params) {
> ...
>
> http.ServeFile(w, r, filePath)
> }
>
>
> But sometimes the server want to abort the downloading, so what's the way 
> to abort the ResponseWriter ?
>
>
> Any information would be very appreciated, 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How to abort the http ResponseWriter

[Song Liu]

I am implementing a file server, so http.ServerFile used to write back the file 
content to remote client:


func downloadFile(w http.ResponseWriter, r *http.Request, p httprouter.Params) {
...

http.ServeFile(w, r, filePath)
}


But sometimes the server want to abort the downloading, so what's the way 
to abort the ResponseWriter ?


Any information would be very appreciated, 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] gomobile: communicated between apps on Android and IOS

[Ged Wed]

Hello nuztiens !

So i have gomobile apps, but they share some data that is common.

How best to get them to share data between each other. For example say 
there is a list of users.
Al the apps need that list
when one app changes a user it issues a mutation "userchanged" on a quasi 
messagw queue (NATS for example).
The other apps subscribe and the world is well.

BUT on mobile there is no message queue. There is URL scheme / Intents 
sharing BUT that is for GUI level. I need data level events between apps.
On Android there is some sort of mechanism and on IOS.

I know i wil need to write a bit of golang code with some java and 
objective c mied in, but i was hoping some people can advise about this.

The project is open source here:

https://github.com/gu-io/gu-x#architecture

See nice diagram to see whats going on.

thank Ged

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

[Dave Cheney]

On Saturday, 1 April 2017 22:26:20 UTC+11, Axel Wagner wrote:
>
> Ian:
> Re your question: See my example given above (or the one below, which is 
> probably more authentic). For example, you might be allocating the returned 
> struct, and piece by piece filling in the fields. If there can be errors, 
> the natural expression might be, to just return the allocated struct, 
> whereas to then return nil, you need to explicitly branch. For example, say 
> I'd want to have a type which operates on some file:
>
> type Foo struct {
> file *os.File
> }
>
> func NewFoo(fname string) (*Foo, error) {
> f, err := os.Open(fname)
> return {
> file: f,
> }, err
> }
>
> vs.
>
> func NewFoo(fname string) (*Foo, error) {
> f, err := os.Open(fname)
> if err != nil {
> return nil, err
> }
> return {
> file: f,
> }, nil
> }
>
> I would usually write the latter version, even if the former is shorter 
> and the extra branch isn't necessary, because people shouldn't rely on the 
> first return if there's an error anyway.
> Because I do feel like people might not be so careful and then 
> dereferencing a nil *Foo will be a clearer symptom to debug, than debugging 
> whatever weird value Open might theoretically return being used 
> accidentally.
>
> On Sat, Apr 1, 2017 at 2:26 AM, Dave Cheney  > wrote:
>
>> On 1 Apr 2017, at 11:02, Axel Wagner > > wrote:
>>
>> On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney > > wrote:
>>
>>>
>>>
>>> On 1 Apr 2017, at 10:41, Axel Wagner >> > wrote:
>>>
>>> So… Given that I'm *not* talking about modifying any contract - see a) 
>>> in my previous message - but just making an effort that I'm not contractual 
>>> bound by, I am not sure how I am supposed to read this. Is this an argument 
>>> for not being helpful? Because I don't quite see how your point invalidates 
>>> that. Or is it an argument for being hurtful? Which I also don't really 
>>> see, as I'm not talking about any change in contract.
>>>
>>> Like, I legit starting to doubt my sanity here; I don't see how I can 
>>> actually be any clearer about how I do not intend to change anything about 
>>> the "if a non-nil error is returned, assume the returns are invalid" rule. 
>>> The question is "how is it hurtful, if I then also add an extra layer of 
>>> defense against people violating that contract"?
>>>
>>>
>>> But why? Why encourage people to be reckless. IMO this is difference 
>>> between map ordering during iteration being undefined, which it is, rather 
>>> than guaranteed to be random, which is not.
>>>
>>
>> Great point. Why does gc implement it that way, then? And does it hurt, 
>> that gc implement it that way? The contract does not contain anything about 
>> the iteration order, so why did we add that code and CPU time to explicitly 
>> randomize it, instead of just letting buggy code be buggy and blow up at 
>> some point with hard to debug errors? This seems to be essentially the 
>> argument you are making, so why does it, seemingly, not apply to randomized 
>> map iteration in gc?
>>
>>
>> Map ordering is undefined by the spec, some implementations choose to 
>> randomise the order but this is an implementation detail.
>>
>
> But that is what I'm saying. The equivalency of the spec here is the API 
> contract and I am not changing that, but I'm changing an implementation 
> detail (and also reserve the right to change that later). It is incredibly 
> frustrated that you seem to continue to suppose I'm trying to somehow make 
> this a guarantee or part of the API contract, when I said so often that I'm 
> not.
>

But you are. I've been very clear that if there is an error the caller can 
assume nothing about the state of an other variable; they are, like the 
floor, lava.
 

>  
>
>> Both are contracts with the same result to the casual user -- map 
>>> iteration is unpredictable, but by not guaranteeing that the order will be 
>>> random, it prevents people relying on the side effect.
>>>
>>> This is the argument I'm making now, yes, you could go to effort to make 
>>> sure that some of the values you return are nil so that they explode as 
>>> soon as someone forgets to check an error, but you probably shouldn't 
>>> because
>>>
>>> A, this is providing a stronger contract than necessary.
>>>
>>
>> No, it is not. The contract is the same. I'm sorry to be a stickler here, 
>> but I really don't see why this point is so elusive. I am not suggesting 
>> adding a "if an error is returned, the other return values will have their 
>> zero value" to my godoc.
>>
>>
>> No, it's not. One is "in the presence of an error, the other values 
>> returned are undefined", your contract is "in the presence of an error, the 
>> others values returned will be their respective zero value"
>>
>
> No, this is categorically not what I'm suggesting and I have been very 
> explicit about 

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

[Dave Cheney]

On Saturday, 1 April 2017 22:26:20 UTC+11, Axel Wagner wrote:
>
> Ian:
> Re your question: See my example given above (or the one below, which is 
> probably more authentic). For example, you might be allocating the returned 
> struct, and piece by piece filling in the fields. If there can be errors, 
> the natural expression might be, to just return the allocated struct, 
> whereas to then return nil, you need to explicitly branch. For example, say 
> I'd want to have a type which operates on some file:
>
> type Foo struct {
> file *os.File
> }
>
> func NewFoo(fname string) (*Foo, error) {
> f, err := os.Open(fname)
> return {
> file: f,
> }, err
> }
>

You mustn't do this version because you don't know the state of f without 
checking err first.
 

>
> vs.
>
> func NewFoo(fname string) (*Foo, error) {
> f, err := os.Open(fname)
> if err != nil {
> return nil, err
> }
> return {
> file: f,
> }, nil
> }
>
> I would usually write the latter version, even if the former is shorter 
> and the extra branch isn't necessary, because people shouldn't rely on the 
> first return if there's an error anyway.
> Because I do feel like people might not be so careful and then 
> dereferencing a nil *Foo will be a clearer symptom to debug, than debugging 
> whatever weird value Open might theoretically return being used 
> accidentally.
>
> On Sat, Apr 1, 2017 at 2:26 AM, Dave Cheney  > wrote:
>
>> On 1 Apr 2017, at 11:02, Axel Wagner > > wrote:
>>
>> On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney > > wrote:
>>
>>>
>>>
>>> On 1 Apr 2017, at 10:41, Axel Wagner >> > wrote:
>>>
>>> So… Given that I'm *not* talking about modifying any contract - see a) 
>>> in my previous message - but just making an effort that I'm not contractual 
>>> bound by, I am not sure how I am supposed to read this. Is this an argument 
>>> for not being helpful? Because I don't quite see how your point invalidates 
>>> that. Or is it an argument for being hurtful? Which I also don't really 
>>> see, as I'm not talking about any change in contract.
>>>
>>> Like, I legit starting to doubt my sanity here; I don't see how I can 
>>> actually be any clearer about how I do not intend to change anything about 
>>> the "if a non-nil error is returned, assume the returns are invalid" rule. 
>>> The question is "how is it hurtful, if I then also add an extra layer of 
>>> defense against people violating that contract"?
>>>
>>>
>>> But why? Why encourage people to be reckless. IMO this is difference 
>>> between map ordering during iteration being undefined, which it is, rather 
>>> than guaranteed to be random, which is not.
>>>
>>
>> Great point. Why does gc implement it that way, then? And does it hurt, 
>> that gc implement it that way? The contract does not contain anything about 
>> the iteration order, so why did we add that code and CPU time to explicitly 
>> randomize it, instead of just letting buggy code be buggy and blow up at 
>> some point with hard to debug errors? This seems to be essentially the 
>> argument you are making, so why does it, seemingly, not apply to randomized 
>> map iteration in gc?
>>
>>
>> Map ordering is undefined by the spec, some implementations choose to 
>> randomise the order but this is an implementation detail.
>>
>
> But that is what I'm saying. The equivalency of the spec here is the API 
> contract and I am not changing that, but I'm changing an implementation 
> detail (and also reserve the right to change that later). It is incredibly 
> frustrated that you seem to continue to suppose I'm trying to somehow make 
> this a guarantee or part of the API contract, when I said so often that I'm 
> not.
>  
>
>> Both are contracts with the same result to the casual user -- map 
>>> iteration is unpredictable, but by not guaranteeing that the order will be 
>>> random, it prevents people relying on the side effect.
>>>
>>> This is the argument I'm making now, yes, you could go to effort to make 
>>> sure that some of the values you return are nil so that they explode as 
>>> soon as someone forgets to check an error, but you probably shouldn't 
>>> because
>>>
>>> A, this is providing a stronger contract than necessary.
>>>
>>
>> No, it is not. The contract is the same. I'm sorry to be a stickler here, 
>> but I really don't see why this point is so elusive. I am not suggesting 
>> adding a "if an error is returned, the other return values will have their 
>> zero value" to my godoc.
>>
>>
>> No, it's not. One is "in the presence of an error, the other values 
>> returned are undefined", your contract is "in the presence of an error, the 
>> others values returned will be their respective zero value"
>>
>
> No, this is categorically not what I'm suggesting and I have been very 
> explicit about that.
> I'm saying "I'll try to do X, because I think it's sometimes 

[go-nuts] Re: [POC] gigo: go generate on steroids!

[mhhcbon]

Hi!

Just an update to tell i cleaned up the code and added a cli to ease usage 
and demo it!

Since last post i added parameters to type mutators, for example you write

type Todos implements<:Mutexed (Slice .Todo "Name")>




The Slice Type will handle the extra params to generate a FindByName method.

// range over args to produce new FindBy methods
<:range $a := .Args> func (m <:$.Name>Slice) FindBy<:$a>(<:$a> <:$.ArgType $a>) 
(<:$.Name>,bool) {
  for i, items := range s.items {
if item.<:$a> == <:$a> {
  return item, true
}
  }
  return <:$.Name>{}, false
}


I also updated error reporting,

For a decl like this,

package tomate

type tomate struct qsdqd{} // bad


It outputs

unexpected token
In file= At=3:19
Found=wordToken wanted=[bracketOpenToken]

...
5  package tomate
6  type tomate struct qsdqd{}
   -↑
...


BTW, if template.Template could report position of the error within the 
line it would be better ;)
See an error reported from a template execution
0  
1  type Todos implements<:Mutexed (Slice, .Todo "Name"):> {
✘- ↑↑↑ ???
2// it reads as a mutexed list of todo.
3  }
...

panic: in gigo template: gigo:3: unexpected "," in operand at line 3:-1 [
recovered]
panic: in gigo template: gigo:3: unexpected "," in operand at line 3:-1


And finally the cli was added so you can gen/dump/str an input file,
check the readme 
https://github.com/mh-cbon/gigo#-go-run-maingo--symbol-push-gen-demogigogo

~~Happy coding!





On Wednesday, March 29, 2017 at 10:29:56 PM UTC+2, mhh...@gmail.com wrote:
>
> Hi !
>
> I m very happy to share with you gigo
>
> Its a go generate on steroids, Its more close to something like babel than 
> go generate, see,
>
> in input it takes
>
>
> type Todo struct {
>   Name string
>   Done bool
> }
>
> type Todos implements {
>   // it reads as a mutexed list of todo.
> }
>
> func (t *Todos) Hello(){fmt.Println("Hello")}
>
>
> template Mutexed<.Name> struct {
>   lock *sync.Mutex
>   embed <.Name>
> }
>
>  func (m Mutexed<$.Name>) <$m.Name>(<$m.Params>) <$m
> .Out> {
>   lock.Lock()
>   defer lock.Unlock()
>   m.embed.<$m.GetName>(<$m.Args>)
> }
>
> template <.Name>Slice struct {
>   items []<.Name>
> }
>
> func (s <.Name>Slice) Push(item <.Name>) int {
>   s.items = append(s.items, item)
>   return len(s.items)
> }
>
> func (s <.Name>Slice) Index(item <.Name>) int {
>   for i, items := range s.items {
> if item == search {
>   return i
> }
>   }
>   return -1
> }
>
> func (s <.Name>Slice) RemoveAt(i index) int {
> s.items = append(s.items[:i], s.items[i+1:]...)
> }
>
> func (s <.Name>Slice) Remove(item <.Name>) int {
>   if i:= s.Index(item); i > -1 {
> s.RemoveAt(i)
> return i
>   }
>   return -1
> }
>
>
>
> It produces
>
>
>
>
> type Todo struct {
>   Name string
>   Done bool
> }
>
>
> type TodoSlice struct {
>   items []Todo
> }
>
>
> func (s TodoSlice) Push(item Todo) int {
>   s.items = append(s.items, item)
>   return len(s.items)
> }
>
>
> func (s TodoSlice) Index(item Todo) int {
>   for i, items := range s.items {
> if item == search {
>   return i
> }
>   }
>   return -1
> }
>
>
> func (s TodoSlice) RemoveAt(i index) int {
> s.items = append(s.items[:i], s.items[i+1:]...)
> }
>
>
> func (s TodoSlice) Remove(item Todo) int {
>   if i:= s.Index(item); i > -1 {
> s.RemoveAt(i)
> return i
>   }
>   return -1
> }
> // while this is compatible with its local contracts,
> // it will work and still takes advantages of concrete types exported by 
> consumed package.
>
> type MutexedTodoSlice struct {
>   lock *sync.Mutex
>   embed TodoSlice
> }
>
>
>  func (m MutexedTodoSlice)  Push((item Todo))  int {
>   lock.Lock()
>   defer lock.Unlock()
>   m.embed.<$m.GetName>(<$m.Args>)
> }
>  func (m MutexedTodoSlice)  Index((item Todo))  int {
>   lock.Lock()
>   defer lock.Unlock()
>   m.embed.<$m.GetName>(<$m.Args>)
> }
>  func (m MutexedTodoSlice)  RemoveAt((i index))  int {
>   lock.Lock()
>   defer lock.Unlock()
>   m.embed.<$m.GetName>(<$m.Args>)
> }
>  func (m MutexedTodoSlice)  Remove((item Todo))  int {
>   lock.Lock()
>   defer lock.Unlock()
>   m.embed.<$m.GetName>(<$m.Args>)
> }
>
>
> type Todos struct {
> MutexedTodoSlice
>   // it reads as a mutexed list of todo.
> }
>
> func (t *Todos) Hello(){fmt.Println("Hello")}
>
> Still some work to be done, but you got the idea!
>
>
>
> It implements a whole tokenizer/interpreter  of go code (almost), 
>
> a bit like go/ast, but its way more lighter(so far), 
>
> the idea being to be able add more customization based on that.
>
>
> The package currently tokenize a source code,
>
> interprets it into declarations,
>
> manipulates nodes to use a regular go template.Template
>
> to execute the generation,
>
> finally it builds a go file and output its.
>
>
> It adds new syntaxes such as
>
>
> implements, which produces a struct
>
> type Todos implements 
>
>
> template, to define virutal structs type
>
> template Mutexed<.Name>