Re: [go-nuts] I want to set the position of the window in GUI display of golang

[kato masa]

thank you for the advice!

2018年12月5日水曜日 12時26分03秒 UTC+9 Robert Engels:
>
> You should probably file an issue at 
>
> http://github.com/lxn/walk
>
> They don’t seem to have a community forum, but I think the author could 
> help you easily. Also you could try stack overflow as there are a few 
> questions about this library there. 
>
> On Dec 4, 2018, at 7:44 PM, mdi@gmail.com  wrote:
>
> Hi
> I'm Japanese, so sorry if my English is wrong.
>
> I'm try to display GUI window with WALK(github.com/lxn/walk).
> But there is a problem dose not go well.
>
> If you run this code, maybe the window displayed upper left of screen.
> I want to set the position of the window in center of screen.
> What should i do?
>
>
> import ( "github.com/lxn/walk" . "github.com/lxn/walk/declarative" ) type 
> MyLoadWindow struct { *walk.MainWindow progressBar *walk.ProgressBar } 
> func Main() { mw := &MyLoadWindow{} // 画面情報設定 MW := MainWindow{ AssignTo: 
> &mw.MainWindow, // Widgetを実体に割り当て Title: "コンピュータの情報を取得中", Size: Size{ 
> 300, 100}, Font: Font{PointSize: 12}, Layout: VBox{}, Children: []Widget{ // 
> ウィジェットを入れるスライス ProgressBar{ AssignTo: &mw.progressBar, MarqueeMode: true, 
> }, }, } if _, err := MW.Run(); err != nil { println("Error") return } }
>
>
> If someone know solution, please show me.
> thank you.
>
> -- 
> 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 .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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: Starlight - run python inside Go to extend your applications - easily

[michal]

On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>
> I’d like to announce starlight - https://github.com/starlight-go/starlight
> .
>
>
> Starlight wraps google’s Go implementation of the starlark python dialect 
>  (most notably found in the Bazel 
> build tool). Starlight makes it super easy for users to extend your 
> application by writing simple python scripts that interact seamlessly with 
> your current Go code… with no boilerplate on your part.
>

Do you think it is suitable for porting python applications?
Usually you go through cgo like 
this https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be 
an interesting alternative. 
 

>
> *Parser by google*
>
> The parser and runner are maintained by google’s bazel team, which write 
> starlark-go. Starlight is a wrapper on top of that, which makes it so much 
> easier to use starlark-go. The problem with the starlark-go API is that it 
> is more built to be a used as configuration, so it assumes you want to get 
> information out of starlark and into Go. It’s actually pretty difficult to 
> get Go information into a starlark script…. unless you use starlight.
>
> *Easy two-way interaction*
>
>
> Starlight has adapters that use reflection to automatically make any Go 
> value usable in a starlark script. Passing an *http.Request into a 
> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in the 
> python without any work on your part.
>
> Starlight is built to *just work* the way you hope it’ll work. You can 
> access any Go methods or fields, basic types get converted back and forth 
> seamlessly… and even though it uses reflection, it’s not as slow as you’d 
> think. A basic benchmark wrapping a couple values and running a starlark 
> script to work with them runs in a tiny fraction of a millisecond.
>
> The great thing is that the changes made by the python code are reflected 
> in your go objects, just as if it had been written in Go. So, set a field 
> on a pointer to a struct? Your go code will see the change, no additional 
> work needed.
>
> *100% Safe*
>
>
> The great thing about starlark and starlight is that the scripts are 100% 
> safe to run. By default they have no access to other parts of your project 
> or system - they can’t write to disk or connect to the internet. The only 
> access they have to the outside is what you give them. Because of this, 
> it’s safe to run untrusted scripts (as long as you’re not giving them 
> dangerous functions to run, like os.RemoveAll). But at the same time, if 
> you’re only running trusted scripts, you can give them whatever you want (
> http.Get? Sure, why not?)
>
> *Caching*
>
>
> In a production environment, you probably want to only read a script once 
> and parse it once. You can do that with starlight’s Cache. This cache 
> takes a list of directories to look in for scripts, which it will read and 
> parse on-demand, and then store the parsed object in memory for later use. 
> It also uses a cache for any load() calls the scripts use to load scripts 
> they depend on.
>
> *Work Ongoing*
>
>
> Starlight is still a work in progress, so don’t expect the API to be 
> perfectly stable quite yet. But it’s getting pretty close, and there 
> shouldn’t be any earth shattering changes, but definitely pin your imports. 
> Right now it’s more about finding corner cases where the starlight wrappers 
> don’t work quite like you’d expect, and supporting the last few things that 
> aren’t implemented yet (like channels).
>
>
> *Example*
>
>
> Here's a simple example of how easy it is to extend the behavior of your 
> application with a python script.  Just pass starlight whatever go values 
> you want your python script to act on, and any changes the python code 
> makes get reflected in your go code.  
>
>
> package main
>
> import (
> "fmt"
> "log"
> "time"
>
> "github.com/starlight-go/starlight"
> )
>
> // Starlight makes it easy to get values in and out of your starlark 
> scripts.
> // Just pass in pointers to values that you want changed, or callback 
> functions
> // that propagate data.
>
> // In theory, starlight also returns all global variables set by the 
> script, but
> // in real programs, you need well-defined outputs for your calling code 
> to act on.
> // If I write a script that creates a variable called nate_is_awesome = 
> 1337 ... your
> // go code probably isn't going to care that the variable exists.
>
> // The best way to do it is to write a "results" struct that you pass in, 
> just
> // as you would for any other function.
>
> type Page struct {
> Name string
> Date time.Time
> Contents string
> IsDraft bool
> }
>
> const code = `
> def run():
> if "nate" in page.Name:
>  # capitalize words
>  page.Name = page.Name.title()
> page.Name += " " + page.Date.Format("2006/01/02")
> page.IsDraft = False
> run()
> `
>
> func main() {
> p := &Page{
> N

Re: [go-nuts] Re: Starlight - run python inside Go to extend your applications - easily

[Justin Israel]

On Mon, Dec 10, 2018, 9:39 PM  wrote:

>
>
> On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>>
>> I’d like to announce starlight -
>> https://github.com/starlight-go/starlight.
>>
>>
>> Starlight wraps google’s Go implementation of the starlark python dialect
>>  (most notably found in the Bazel
>> build tool). Starlight makes it super easy for users to extend your
>> application by writing simple python scripts that interact seamlessly with
>> your current Go code… with no boilerplate on your part.
>>
>
> Do you think it is suitable for porting python applications?
> Usually you go through cgo like this
> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be an
> interesting alternative.
>
>

The documentation for Starlark says it is a subset of python, originally
targeted at being a configuration language for Bazel. So it wouldn't be
complete enough to straight port full Python applications, unless you
really backed alot of it with Go code. The cgo approach gives you full
access to the CPython API and to embed an interpreter.

Starlight does sound interesting though for allowing specific extension
scripts for a Go application.


>> *Parser by google*
>>
>> The parser and runner are maintained by google’s bazel team, which write
>> starlark-go. Starlight is a wrapper on top of that, which makes it so much
>> easier to use starlark-go. The problem with the starlark-go API is that it
>> is more built to be a used as configuration, so it assumes you want to get
>> information out of starlark and into Go. It’s actually pretty difficult to
>> get Go information into a starlark script…. unless you use starlight.
>>
>> *Easy two-way interaction*
>>
>>
>> Starlight has adapters that use reflection to automatically make any Go
>> value usable in a starlark script. Passing an *http.Request into a
>> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in the
>> python without any work on your part.
>>
>> Starlight is built to *just work* the way you hope it’ll work. You can
>> access any Go methods or fields, basic types get converted back and forth
>> seamlessly… and even though it uses reflection, it’s not as slow as you’d
>> think. A basic benchmark wrapping a couple values and running a starlark
>> script to work with them runs in a tiny fraction of a millisecond.
>>
>> The great thing is that the changes made by the python code are reflected
>> in your go objects, just as if it had been written in Go. So, set a field
>> on a pointer to a struct? Your go code will see the change, no additional
>> work needed.
>>
>> *100% Safe*
>>
>>
>> The great thing about starlark and starlight is that the scripts are 100%
>> safe to run. By default they have no access to other parts of your project
>> or system - they can’t write to disk or connect to the internet. The only
>> access they have to the outside is what you give them. Because of this,
>> it’s safe to run untrusted scripts (as long as you’re not giving them
>> dangerous functions to run, like os.RemoveAll). But at the same time, if
>> you’re only running trusted scripts, you can give them whatever you want (
>> http.Get? Sure, why not?)
>>
>> *Caching*
>>
>>
>> In a production environment, you probably want to only read a script once
>> and parse it once. You can do that with starlight’s Cache. This cache
>> takes a list of directories to look in for scripts, which it will read and
>> parse on-demand, and then store the parsed object in memory for later use.
>> It also uses a cache for any load() calls the scripts use to load
>> scripts they depend on.
>>
>> *Work Ongoing*
>>
>>
>> Starlight is still a work in progress, so don’t expect the API to be
>> perfectly stable quite yet. But it’s getting pretty close, and there
>> shouldn’t be any earth shattering changes, but definitely pin your imports.
>> Right now it’s more about finding corner cases where the starlight wrappers
>> don’t work quite like you’d expect, and supporting the last few things that
>> aren’t implemented yet (like channels).
>>
>>
>> *Example*
>>
>>
>> Here's a simple example of how easy it is to extend the behavior of your
>> application with a python script.  Just pass starlight whatever go values
>> you want your python script to act on, and any changes the python code
>> makes get reflected in your go code.
>>
>>
>> package main
>>
>> import (
>> "fmt"
>> "log"
>> "time"
>>
>> "github.com/starlight-go/starlight"
>> )
>>
>> // Starlight makes it easy to get values in and out of your starlark
>> scripts.
>> // Just pass in pointers to values that you want changed, or callback
>> functions
>> // that propagate data.
>>
>> // In theory, starlight also returns all global variables set by the
>> script, but
>> // in real programs, you need well-defined outputs for your calling code
>> to act on.
>> // If I write a script that creates a variable called nate_is_awesome =
>> 1337 ... your
>> // 

[go-nuts] Re: navigating through interface calls

[David Wahlstedt]

Hi, and thanks for your answers!
Yes, I realize that the possible results of calling an interface method 
depends on runtime. But in many cases there is only one possible 
alternative, or just a few ones, dependent of the state of the program. It 
should still be possible for the tool to compute the possible candidates, 
and omit irrelevant matches. In my example there was only one possible 
alternative, although go-guru showed a list of many other alternatives.
By the way, I also tried IntelliJ(goland) as well as visual studio and  
LiteIDE X X35.2, and none of them gave more information than go-guru in 
this matter. 

/David

Den fredag 7 december 2018 kl. 17:53:03 UTC+1 skrev David Wahlstedt:
>
> Hi,
> I am still quite inexperienced in go programming, and I find it quite 
> frustrating, sometimes, to find what will actually be executed by a call to 
> an interface method found in some arbitrary code.
> Here I have traced the process of finding the definition of "conn.Close()" 
> an instance of an interface method call. This is what I would like to have 
> automatized by godef, for instance.
> Is there anything like that out there that does it with one command / key 
> stroke, etc, automagically ?
> Godef and go-guru does not, as far as I know.
>
> BR,
> David
>
> Here follows some anonymized code:
> (please forgive me if I've made some errors, I hope you get the idea 
> anyway)
>
> In the file file1.go:1234 in the library lib1, I found a call:
> : _ = conn.Close()
> How do i figure out what happens when this line is executed?
> Here is a list of steps to find it "mechanically", so to say:
> 1. file1.go:1234
>: func returnConn(conn lib2.Conn) {
>: _ = conn.Close()
>: }
>
>Using godef-jump on the Close() will just give me the interface
>declaration. I can use go-guru-implements, and get a list of
>possible implementations of Close, but how do I know which one will
>actually be used? So, let's figure out the actual type of conn.
>I use go-guru-referrers on returnConn, and choose one of the hits,
>which is file1.go:206
>
> 2. file1.go:206
>: func (r *Record) Release(foo bar.T1) error {
>: ...
>: var conn lib2.Conn
>: if conn, err = r.foo.getConn(baz); err != nil {
>: return err
>: }
>: defer returnConn(conn)
>conn gets its value from getConn, so I end up in file1.go:1074
>
> 3. file1.go:1074
>: func (foo *FOO) getConn(mu T2) (lib2.Conn, error) {
>: ...
>: conn := foo.connBax.Get()
>: ...
>: return conn, nil
>conn gets its value from Get(), so I go to file3.go:178
>
> 4. file3.go:178
>: func (p *Bax) Get() Conn {
>: ...
>: return &xooConn{x: p, xc: xc}
>I find the return value and go to its definition in file3.go:371
>
> 5. file3.go:371
>: type xooConn struct {
>: x *Bax
>: xc*baxConn
>: s T3
>: }
>Aaah! This is the type of conn at file1.go:1234!
>
> 6. file1.go:1234
>: _ = conn.Close()
>Now I can follow the "definition" of Close() using godef-jump, and
>end up in file1.go:30:
>
> 7. file1.go:30
>: type Conn interface {
>: Close() error
>
>I use go-guru-implements to see a list of possible implementations:
>: PATH1/lib2/dir1/file1.go:30.2-30.6: abstract method func 
> (ConnWithTimeout).Close() error
>: PATH1/lib2/dir1/file3.go:394.23-394.27: is implemented by method 
> (*xooConn).Close
>: PATH1/lib2/dir1/conn.go:304.16-304.20: is implemented by method 
> (*conn).Close
>: PATH1/lib2/dir1/boo.go:12.3-45.6: is implemented by method 
> (*booingConn).Close
>: PATH1/lib2/dir1/file3.go:510.21-510.25: is implemented by method 
> (errorConn).Close
>: PATH1/lib2/dir1/file1.go:30.2-30.6: implements method (Conn).Close
>: PATH2/bah.go:78.9-101.2: implements method (bah.Closer).Close
>Now, since I know the type is *xooConn, I can jump to the right hit,
>and go to file3.go:394.
> 8. file3.go:394
>: func (ac *xooConn) Close() error {
>: pc := ac.pc
>: ...
>: return nil
>Yes, here it is, at step 8
>
>

-- 
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: navigating through interface calls

[Robert Engels]

When using IntelliJ, did you restrict the search to “project files”? Otherwise 
you will get implantations anywhere in the standard library or other projects. 

> On Dec 10, 2018, at 6:21 AM, David Wahlstedt  
> wrote:
> 
> Hi, and thanks for your answers!
> Yes, I realize that the possible results of calling an interface method 
> depends on runtime. But in many cases there is only one possible alternative, 
> or just a few ones, dependent of the state of the program. It should still be 
> possible for the tool to compute the possible candidates, and omit irrelevant 
> matches. In my example there was only one possible alternative, although 
> go-guru showed a list of many other alternatives.
> By the way, I also tried IntelliJ(goland) as well as visual studio and  
> LiteIDE X X35.2, and none of them gave more information than go-guru in this 
> matter. 
> 
> /David
> 
>> Den fredag 7 december 2018 kl. 17:53:03 UTC+1 skrev David Wahlstedt:
>> Hi,
>> I am still quite inexperienced in go programming, and I find it quite 
>> frustrating, sometimes, to find what will actually be executed by a call to 
>> an interface method found in some arbitrary code.
>> Here I have traced the process of finding the definition of "conn.Close()" 
>> an instance of an interface method call. This is what I would like to have 
>> automatized by godef, for instance.
>> Is there anything like that out there that does it with one command / key 
>> stroke, etc, automagically ?
>> Godef and go-guru does not, as far as I know.
>> 
>> BR,
>> David
>> 
>> Here follows some anonymized code:
>> (please forgive me if I've made some errors, I hope you get the idea anyway)
>> 
>> In the file file1.go:1234 in the library lib1, I found a call:
>> :_ = conn.Close()
>> How do i figure out what happens when this line is executed?
>> Here is a list of steps to find it "mechanically", so to say:
>> 1. file1.go:1234
>>: func returnConn(conn lib2.Conn) {
>>: _ = conn.Close()
>>: }
>> 
>>Using godef-jump on the Close() will just give me the interface
>>declaration. I can use go-guru-implements, and get a list of
>>possible implementations of Close, but how do I know which one will
>>actually be used? So, let's figure out the actual type of conn.
>>I use go-guru-referrers on returnConn, and choose one of the hits,
>>which is file1.go:206
>> 
>> 2. file1.go:206
>>: func (r *Record) Release(foo bar.T1) error {
>>: ...
>>: var conn lib2.Conn
>>: if conn, err = r.foo.getConn(baz); err != nil {
>>: return err
>>: }
>>: defer returnConn(conn)
>>conn gets its value from getConn, so I end up in file1.go:1074
>> 
>> 3. file1.go:1074
>>: func (foo *FOO) getConn(mu T2) (lib2.Conn, error) {
>>: ...
>>: conn := foo.connBax.Get()
>>: ...
>>: return conn, nil
>>conn gets its value from Get(), so I go to file3.go:178
>> 
>> 4. file3.go:178
>>: func (p *Bax) Get() Conn {
>>: ...
>>: return &xooConn{x: p, xc: xc}
>>I find the return value and go to its definition in file3.go:371
>> 
>> 5. file3.go:371
>>: type xooConn struct {
>>: x *Bax
>>: xc*baxConn
>>: s T3
>>: }
>>Aaah! This is the type of conn at file1.go:1234!
>> 
>> 6. file1.go:1234
>>: _ = conn.Close()
>>Now I can follow the "definition" of Close() using godef-jump, and
>>end up in file1.go:30:
>> 
>> 7. file1.go:30
>>: type Conn interface {
>>: Close() error
>> 
>>I use go-guru-implements to see a list of possible implementations:
>>: PATH1/lib2/dir1/file1.go:30.2-30.6: abstract method func 
>> (ConnWithTimeout).Close() error
>>: PATH1/lib2/dir1/file3.go:394.23-394.27: is implemented by 
>> method (*xooConn).Close
>>: PATH1/lib2/dir1/conn.go:304.16-304.20:  is implemented by method 
>> (*conn).Close
>>: PATH1/lib2/dir1/boo.go:12.3-45.6:   is implemented by method 
>> (*booingConn).Close
>>: PATH1/lib2/dir1/file3.go:510.21-510.25: is implemented by 
>> method (errorConn).Close
>>: PATH1/lib2/dir1/file1.go:30.2-30.6: implements method (Conn).Close
>>: PATH2/bah.go:78.9-101.2:implements method (bah.Closer).Close
>>Now, since I know the type is *xooConn, I can jump to the right hit,
>>and go to file3.go:394.
>> 8. file3.go:394
>>: func (ac *xooConn) Close() error {
>>: pc := ac.pc
>>: ...
>>: return nil
>>Yes, here it is, at step 8
>> 
> 
> -- 
> 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.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
T

[go-nuts] Http server, async tasks and gracefully shutdown.

[Jérôme LAFORGE]

 

Hello World,

In order to manage async tasks with callback on http , I have to reply to 
my customer for example with 202 Accepted, and keep some works with a new 
goroutine. I habitually use server.Shutdown() and sync.Waitgroup in order 
to gracefully shutdown the application when all requests and jobs are 
correctly over (plz see below for example). Can I consider the usage of 
Waitgroup.Wait() and Waitgroup.Add() not into the same goroutine safe? 
(i.e. no race)



thx in adv 

Jerome


package main

import (
"context"
"log"
"net/http"
"os"
"os/signal"
"sync"
"syscall"
)

func main() {
var (
wg = &sync.WaitGroup{}
s  = http.Server{
Addr:":8080",
Handler: myHandler(wg),
}
)

go func() {
if err := s.ListenAndServe(); err != nil && err != 
http.ErrServerClosed {
panic(err)
}
}()

sig := make(chan os.Signal, 1)
signal.Notify(sig, os.Interrupt, syscall.SIGTERM)
<-sig

if err := s.Shutdown(context.Background()); err != nil {
log.Println(err)
}

wg.Wait()
}

func myHandler(wg *sync.WaitGroup) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
wg.Add(1)
go func() {
defer wg.Done()
// do some async job w/ response by callback
// ...
}()

w.WriteHeader(http.StatusAccepted)
}
}


-- 
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] Http server, async tasks and gracefully shutdown.

[Robert Engels]

>From the docs:

Note that calls with a positive delta that occur when the counter is zero must 
happen before a Wait. Calls with a negative delta, or calls with a positive 
delta that start when the counter is greater than zero, may happen at any time. 
Typically this means the calls to Add should execute before the statement 
creating the goroutine or other event to be waited for. If a WaitGroup is 
reused to wait for several independent sets of events, new Add calls must 
happen after all previous Wait calls have returned. See the WaitGroup example.

> On Dec 10, 2018, at 8:21 AM, Jérôme LAFORGE  wrote:
> 
> Hello World,
> In order to manage async tasks with callback on http , I have to reply to my 
> customer for example with 202 Accepted, and keep some works with a new 
> goroutine. I habitually use server.Shutdown() and sync.Waitgroup in order to 
> gracefully shutdown the application when all requests and jobs are correctly 
> over (plz see below for example). Can I consider the usage of 
> Waitgroup.Wait() and Waitgroup.Add() not into the same goroutine safe? (i.e. 
> no race)
> 
> 
> thx in adv
> Jerome
> 
> package main
> 
> import (
> "context"
> "log"
> "net/http"
> "os"
> "os/signal"
> "sync"
> "syscall"
> )
> 
> func main() {
> var (
> wg = &sync.WaitGroup{}
> s  = http.Server{
> Addr:":8080",
> Handler: myHandler(wg),
> }
> )
> 
> go func() {
> if err := s.ListenAndServe(); err != nil && err != 
> http.ErrServerClosed {
> panic(err)
> }
> }()
> 
> sig := make(chan os.Signal, 1)
> signal.Notify(sig, os.Interrupt, syscall.SIGTERM)
> <-sig
> 
> if err := s.Shutdown(context.Background()); err != nil {
> log.Println(err)
> }
> 
> wg.Wait()
> }
> 
> func myHandler(wg *sync.WaitGroup) http.HandlerFunc {
> return func(w http.ResponseWriter, r *http.Request) {
> wg.Add(1)
> go func() {
> defer wg.Done()
> // do some async job w/ response by callback
> // ...
> }()
> 
> w.WriteHeader(http.StatusAccepted)
> }
> }
> 
> -- 
> 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.

-- 
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: invalid recursive type alias

['Bryan Mills' via golang-nuts]

The compiler is behaving as designed in both cases.

See https://golang.org/issue/25187 (and the 
associated https://golang.org/issue/25141).


On Saturday, December 8, 2018 at 12:33:48 PM UTC-5, Jan Mercl wrote:
>
> This code compiles fine
>
> package main
> 
> type node struct {
> next *node
> }
> 
> func main() {}
>
> (https://play.golang.org/p/ZYg0EciQnOQ)
>
> This code does not
>
> package main
> 
> type node = struct {
> next *node
> }
> 
> func main() {}
>
> (https://play.golang.org/p/gWWX8ngPsS6)
>
> The error is
>
> prog.go:3:6: invalid recursive type alias node
> prog.go:3:6: node uses 
> prog.go:3:13:  uses node
>
> The specification remains silent about what is considered "invalid 
> recursive type alias" so I'm not sure, but it seems to me the first and 
> second programs should both compile fine. In both cases, so to say "the 
> pointer breaks the cycle" while type checking. But maybe/probably I'm 
> mistaken.
>
> Can anybody enlighten me please and explain if the compiler is right or if 
> it's a bug?
>
> Thanks in advance.
>
> -- 
>
> -j
>

-- 
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] Is there a good approach to abstraction of DB access including transactions and forupdate?

[bonpi bonpi]

I would like to abstract DB access of certain server programs like GCP 
bookshelf sample.
However, in this example transactions are not handled.
https://github.com/GoogleCloudPlatform/golang-samples/tree/master/getting-started/bookshelf

When dealing with transactions, adding APIs to the interface complicates 
the API
When one request is handled as a transaction, since it is necessary to 
start a transaction for each request
The Server itself can not have an abstracted data source.
Am I wrong something fundamental?

What kind of approach can be seen in actual projects?
Also, how do you deal with the lock function such as ForUpdate?

-- 
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 there a good approach to abstraction of DB access including transactions and forupdate?

[Robert Engels]

Distributed transactions are difficult in cloud computing. See GCP Spanner. 
Also read up on “saga” pattern. If you have multiple sources participating in 
the transaction, saga seems to be the preferred method for highly scalable 
solutions. 

> On Dec 10, 2018, at 8:55 AM, bonpi bonpi  wrote:
> 
> I would like to abstract DB access of certain server programs like GCP 
> bookshelf sample.
> However, in this example transactions are not handled.
> https://github.com/GoogleCloudPlatform/golang-samples/tree/master/getting-started/bookshelf
> 
> When dealing with transactions, adding APIs to the interface complicates the 
> API
> When one request is handled as a transaction, since it is necessary to start 
> a transaction for each request
> The Server itself can not have an abstracted data source.
> Am I wrong something fundamental?
> 
> What kind of approach can be seen in actual projects?
> Also, how do you deal with the lock function such as ForUpdate?
> -- 
> 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.

-- 
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: pass interface

[Mark Volkmann]

Yes, this is what I'm trying to do!
Perhaps this is not possible.

On Sun, Dec 9, 2018 at 10:34 PM Robert Engels  wrote:

> I think what the OP wants is:
>
> type A interface{}
> type B interface{}
>
> ...
> PrintInterface(A)
>
> Meaning they want to pass the interface definition to some method.
>
> At least that’s what I am guessing.
>
> On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
>
> reflect/* is a bit tricky. Use pointer to get interface itself.
>
> package main
>
> import (
> "fmt"
> "reflect"
> )
>
> func main() {
> test := interface{}("test")
> printInterfaceValue(test)
> }
>
> func printInterfaceValue(i interface{}) {
> switch testing := i.(type) {
> case interface{}:
> fmt.Println("is interface, with value:", testing)
> case string:
> fmt.Println("is not interface")
> }
>
> fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> }
>
> Output:
>
> is interface, with value: test
> reflect.Type is interface {}
>
>
>
>
>
>
> понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert Engels
> написал:
>>
>> I mean reflect.Type not a type that is an interface.
>>
>> On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
>>
>> Of course. When you "pass a value whose type implements the interface" as
>> an interface argument to a function, you in fact pass an *interface*.
>>
>>
>> воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark Volkmann
>> написал:
>>>
>>> Is it possible to pass an interface to a function in Go? I don’t want to
>>> pass a value whose type implements the interface, I want to pass the
>>> interface.
>>>
>>> --
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> 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.
>
> --
> 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.
>


-- 
R. Mark Volkmann
Object Computing, Inc.

-- 
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: Starlight - run python inside Go to extend your applications - easily

[Raffaele Sena]

If you want a full python interpreter, you should look at
https://github.com/go-python/gpython, but gpython also doesn't have a full
standard library implemented.

-- Raffaele


On Mon, Dec 10, 2018 at 1:58 AM Justin Israel 
wrote:

>
>
> On Mon, Dec 10, 2018, 9:39 PM  wrote:
>
>>
>>
>> On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>>>
>>> I’d like to announce starlight -
>>> https://github.com/starlight-go/starlight.
>>>
>>>
>>> Starlight wraps google’s Go implementation of the starlark python
>>> dialect  (most notably found in
>>> the Bazel build tool). Starlight makes it super easy for users to extend
>>> your application by writing simple python scripts that interact seamlessly
>>> with your current Go code… with no boilerplate on your part.
>>>
>>
>> Do you think it is suitable for porting python applications?
>> Usually you go through cgo like this
>> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be
>> an interesting alternative.
>>
>>
>
> The documentation for Starlark says it is a subset of python, originally
> targeted at being a configuration language for Bazel. So it wouldn't be
> complete enough to straight port full Python applications, unless you
> really backed alot of it with Go code. The cgo approach gives you full
> access to the CPython API and to embed an interpreter.
>
> Starlight does sound interesting though for allowing specific extension
> scripts for a Go application.
>
>
>>> *Parser by google*
>>>
>>> The parser and runner are maintained by google’s bazel team, which write
>>> starlark-go. Starlight is a wrapper on top of that, which makes it so much
>>> easier to use starlark-go. The problem with the starlark-go API is that it
>>> is more built to be a used as configuration, so it assumes you want to get
>>> information out of starlark and into Go. It’s actually pretty difficult to
>>> get Go information into a starlark script…. unless you use starlight.
>>>
>>> *Easy two-way interaction*
>>>
>>>
>>> Starlight has adapters that use reflection to automatically make any Go
>>> value usable in a starlark script. Passing an *http.Request into a
>>> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in
>>> the python without any work on your part.
>>>
>>> Starlight is built to *just work* the way you hope it’ll work. You can
>>> access any Go methods or fields, basic types get converted back and forth
>>> seamlessly… and even though it uses reflection, it’s not as slow as you’d
>>> think. A basic benchmark wrapping a couple values and running a starlark
>>> script to work with them runs in a tiny fraction of a millisecond.
>>>
>>> The great thing is that the changes made by the python code are
>>> reflected in your go objects, just as if it had been written in Go. So, set
>>> a field on a pointer to a struct? Your go code will see the change, no
>>> additional work needed.
>>>
>>> *100% Safe*
>>>
>>>
>>> The great thing about starlark and starlight is that the scripts are
>>> 100% safe to run. By default they have no access to other parts of your
>>> project or system - they can’t write to disk or connect to the internet.
>>> The only access they have to the outside is what you give them. Because of
>>> this, it’s safe to run untrusted scripts (as long as you’re not giving them
>>> dangerous functions to run, like os.RemoveAll). But at the same time,
>>> if you’re only running trusted scripts, you can give them whatever you want
>>> (http.Get? Sure, why not?)
>>>
>>> *Caching*
>>>
>>>
>>> In a production environment, you probably want to only read a script
>>> once and parse it once. You can do that with starlight’s Cache. This
>>> cache takes a list of directories to look in for scripts, which it will
>>> read and parse on-demand, and then store the parsed object in memory for
>>> later use. It also uses a cache for any load() calls the scripts use to
>>> load scripts they depend on.
>>>
>>> *Work Ongoing*
>>>
>>>
>>> Starlight is still a work in progress, so don’t expect the API to be
>>> perfectly stable quite yet. But it’s getting pretty close, and there
>>> shouldn’t be any earth shattering changes, but definitely pin your imports.
>>> Right now it’s more about finding corner cases where the starlight wrappers
>>> don’t work quite like you’d expect, and supporting the last few things that
>>> aren’t implemented yet (like channels).
>>>
>>>
>>> *Example*
>>>
>>>
>>> Here's a simple example of how easy it is to extend the behavior of your
>>> application with a python script.  Just pass starlight whatever go values
>>> you want your python script to act on, and any changes the python code
>>> makes get reflected in your go code.
>>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "log"
>>> "time"
>>>
>>> "github.com/starlight-go/starlight"
>>> )
>>>
>>> // Starlight makes it easy to get values in and out of your starlark
>>> scripts.
>>> // Just pass in pointers to

[go-nuts] How to build gollvm on arm platform

[morefun . fang]

 I try to compile gollvm on arm platform according to 
https://go.googlesource.com/gollvm/, but error is reported as following

CMake Error at tools/gollvm/cmake/modules/GoVars.cmake:12 (message):
  Arch aarch64 not yet supported

https://go.googlesource.com/gollvm/ tells that Gollvm is currently 
supported only for x86_64 Linux. 

Is there any way to compile gollvm on arm platform?

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] Plan9 reborn as a guest OS atop of Golang runtime

[Dmitry Ponyatov]

Can Plan9 reborn as a *guest* OS atop of Golang runtime?

Maybe somebody works on a clustering system can expand Go runtime to 
natively and transparently run over Beowulf-style message passing clusters?

-- 
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: Go 1.11.1 is released

[amank8686]

Can you please share what you did to clear everything out, I am running 
into the same issue.

Did you uninstall and reinstall?

On Tuesday, October 2, 2018 at 2:29:08 PM UTC-5, sc28 wrote:
>
> My bad --
>
> Had installs in both /usr/local/bin and /usr/local/bin/go -- cleared 
> everything and reinstalled -- sorry!
>
>
>
> On Tuesday, October 2, 2018 at 3:20:52 PM UTC-4, sc28 wrote:
>>
>> Just installed (Mac pkg version):
>>
>> Tried to compile simple "hello, world"
>>
>>
>> # errors
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # internal/race
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # unicode/utf8
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # runtime/internal/atomic
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # math/bits
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # runtime/internal/sys
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # sync/atomic
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # internal/cpu
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>> # unicode
>> compile: version "go1.11.1" does not match go tool version "go1.11"
>>
>>
>>
>>
>> On Tuesday, October 2, 2018 at 1:15:19 PM UTC-4, Katie Hockman wrote:
>>>
>>> Hello gophers,
>>>
>>> We have just released Go version 1.11.1, a minor point release.
>>>
>>> This release includes fixes to the compiler, documentation, go command, 
>>> runtime, and the crypto/x509, encoding/json, go/types, net, net/http, and 
>>> reflect packages.
>>>
>>> View the release notes for more information:
>>> https://golang.org/doc/devel/release.html#go1.11.minor
>>>
>>> You can download binary and source distributions from the Go web site:
>>> https://golang.org/dl/
>>>
>>> To compile from source using a Git clone, update to the release with "git 
>>> checkout 1.11.1" and build as usual.
>>>
>>> Thanks to everyone who contributed to the release.
>>>
>>> Cheers,
>>> Katie for the Go Team
>>>
>>>

-- 
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: Starlight - run python inside Go to extend your applications - easily

[Nate Finch]

Justin got this 100% correct.  Starlight and Starlark are not intended to 
be used to just run existing python code.  there's a ton they don't 
support, so pretty much any non-trivial python program would not be 
compatible.

It's really more of a way to give users the ability to write small to 
moderately sized scripts to customize behavior of your application without 
having to recompile and potentially without even having to restart the 
application.

On Monday, December 10, 2018 at 4:58:48 AM UTC-5, Justin Israel wrote:
>
>
>
> On Mon, Dec 10, 2018, 9:39 PM > wrote:
>
>>
>>
>> Do you think it is suitable for porting python applications?
>> Usually you go through cgo like this 
>> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be 
>> an interesting alternative. 
>>  
>>
>
> The documentation for Starlark says it is a subset of python, originally 
> targeted at being a configuration language for Bazel. So it wouldn't be 
> complete enough to straight port full Python applications, unless you 
> really backed alot of it with Go code. The cgo approach gives you full 
> access to the CPython API and to embed an interpreter. 
>
> Starlight does sound interesting though for allowing specific extension 
> scripts for a Go application.
>

-- 
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] How to build gollvm on arm platform

['Than McIntosh' via golang-nuts]

Hello,

As things stand, gollvm isn't usable for Arm (32 or 64); the cmake error
you are hitting is intentional.

The main obstacle for enabling Arm is enhancing the Gollvm bridge to
support the Arm ABI, e.g. the rules for passing parameters (in memory vs
register) depending on the signature of the called routine.  Adding ARM
support is something that's on the Gollvm "to do" list, but hasn't reached
the top. Once the ABI support is there it should not be a lot of additional
work.

If you are interested in contributing code to help fix the problem, we can
point you in the right direction and provide guidance, but it will take a
bit of doing.

Thanks, Than


On Mon, Dec 10, 2018 at 12:54 PM  wrote:

>  I try to compile gollvm on arm platform according to
> https://go.googlesource.com/gollvm/, but error is reported as following
>
> CMake Error at tools/gollvm/cmake/modules/GoVars.cmake:12 (message):
>   Arch aarch64 not yet supported
>
> https://go.googlesource.com/gollvm/ tells that Gollvm is currently
> supported only for x86_64 Linux.
>
> Is there any way to compile gollvm on arm platform?
>
> 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.
>

-- 
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] Plan9 reborn as a guest OS atop of Golang runtime

[Michael Jones]

Read about Biscuit:
https://pdos.csail.mit.edu/papers/biscuit.pdf
https://www.usenix.org/sites/default/files/conference/protected-files/osdi18_slides_cutler.pdf

This is encouraging--smart people making the most of Go in a new area, as
it is today, without an active iterative feedback loop. Several ideas they
want could be changed in Go with sufficient will (the reservation notion
for example).

This says to me that that what you want could happen.


On Mon, Dec 10, 2018 at 9:53 AM Dmitry Ponyatov  wrote:

> Can Plan9 reborn as a *guest* OS atop of Golang runtime?
>
> Maybe somebody works on a clustering system can expand Go runtime to
> natively and transparently run over Beowulf-style message passing clusters?
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Plan9 reborn as a guest OS atop of Golang runtime

[Michael Jones]

oops. left out a key link:

https://github.com/mit-pdos/biscuit

On Mon, Dec 10, 2018 at 1:23 PM Michael Jones 
wrote:

> Read about Biscuit:
> https://pdos.csail.mit.edu/papers/biscuit.pdf
>
> https://www.usenix.org/sites/default/files/conference/protected-files/osdi18_slides_cutler.pdf
>
> This is encouraging--smart people making the most of Go in a new area, as
> it is today, without an active iterative feedback loop. Several ideas they
> want could be changed in Go with sufficient will (the reservation notion
> for example).
>
> This says to me that that what you want could happen.
>
>
> On Mon, Dec 10, 2018 at 9:53 AM Dmitry Ponyatov 
> wrote:
>
>> Can Plan9 reborn as a *guest* OS atop of Golang runtime?
>>
>> Maybe somebody works on a clustering system can expand Go runtime to
>> natively and transparently run over Beowulf-style message passing clusters?
>>
>> --
>> 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.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>


-- 

*Michael T. jonesmichael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: pass interface

[Dan Kortschak]

No, it is possible, but you need to pass the pointer to the interface.
You can then use reflect to interrogate the interface value.

The bigger question, and one that would help here would be what is it
that you are actually trying to achieve.

On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> Yes, this is what I'm trying to do!
> Perhaps this is not possible.
> 
> On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
> wrote:
> 
> > 
> > I think what the OP wants is:
> > 
> > type A interface{}
> > type B interface{}
> > 
> > ...
> > PrintInterface(A)
> > 
> > Meaning they want to pass the interface definition to some method.
> > 
> > At least that’s what I am guessing.
> > 
> > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
> > 
> > reflect/* is a bit tricky. Use pointer to get interface itself.
> > 
> > package main
> > 
> > import (
> > "fmt"
> > "reflect"
> > )
> > 
> > func main() {
> > test := interface{}("test")
> > printInterfaceValue(test)
> > }
> > 
> > func printInterfaceValue(i interface{}) {
> > switch testing := i.(type) {
> > case interface{}:
> > fmt.Println("is interface, with value:", testing)
> > case string:
> > fmt.Println("is not interface")
> > }
> > 
> > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> > }
> > 
> > Output:
> > 
> > is interface, with value: test
> > reflect.Type is interface {}
> > 
> > 
> > 
> > 
> > 
> > 
> > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
> > Engels
> > написал:
> > > 
> > > 
> > > I mean reflect.Type not a type that is an interface.
> > > 
> > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
> > > 
> > > Of course. When you "pass a value whose type implements the
> > > interface" as
> > > an interface argument to a function, you in fact pass an
> > > *interface*.
> > > 
> > > 
> > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
> > > Volkmann
> > > написал:
> > > > 
> > > > 
> > > > Is it possible to pass an interface to a function in Go? I
> > > > don’t want to
> > > > pass a value whose type implements the interface, I want to
> > > > pass the
> > > > interface.
> > > > 
> > > > --
> > > > R. Mark Volkmann
> > > > Object Computing, Inc.
> > > > 
> > > --
> > > 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.
> > > For more options, visit https://groups.google.com/d/optout.
> > > 
> > > --
> > 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.
> > 
> > --
> > 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.
> > 
> 
> -- 
> R. Mark Volkmann
> Object Computing, Inc.
> 

-- 
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: pass interface

[Tyler Compton]

If my interpretation of the question is correct, I think it boils down to
whether or not it's possible to get the reflect.Type of a type in order to
pass it to a function without first creating an instance of that type. I
don't think it's possible but I would be interested to hear from someone
who knows more.

On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak  wrote:

> No, it is possible, but you need to pass the pointer to the interface.
> You can then use reflect to interrogate the interface value.
>
> The bigger question, and one that would help here would be what is it
> that you are actually trying to achieve.
>
> On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > Yes, this is what I'm trying to do!
> > Perhaps this is not possible.
> >
> > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
> > wrote:
> >
> > >
> > > I think what the OP wants is:
> > >
> > > type A interface{}
> > > type B interface{}
> > >
> > > ...
> > > PrintInterface(A)
> > >
> > > Meaning they want to pass the interface definition to some method.
> > >
> > > At least that’s what I am guessing.
> > >
> > > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
> > >
> > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > >
> > > package main
> > >
> > > import (
> > > "fmt"
> > > "reflect"
> > > )
> > >
> > > func main() {
> > > test := interface{}("test")
> > > printInterfaceValue(test)
> > > }
> > >
> > > func printInterfaceValue(i interface{}) {
> > > switch testing := i.(type) {
> > > case interface{}:
> > > fmt.Println("is interface, with value:", testing)
> > > case string:
> > > fmt.Println("is not interface")
> > > }
> > >
> > > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> > > }
> > >
> > > Output:
> > >
> > > is interface, with value: test
> > > reflect.Type is interface {}
> > >
> > >
> > >
> > >
> > >
> > >
> > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
> > > Engels
> > > написал:
> > > >
> > > >
> > > > I mean reflect.Type not a type that is an interface.
> > > >
> > > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
> > > >
> > > > Of course. When you "pass a value whose type implements the
> > > > interface" as
> > > > an interface argument to a function, you in fact pass an
> > > > *interface*.
> > > >
> > > >
> > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
> > > > Volkmann
> > > > написал:
> > > > >
> > > > >
> > > > > Is it possible to pass an interface to a function in Go? I
> > > > > don’t want to
> > > > > pass a value whose type implements the interface, I want to
> > > > > pass the
> > > > > interface.
> > > > >
> > > > > --
> > > > > R. Mark Volkmann
> > > > > Object Computing, Inc.
> > > > >
> > > > --
> > > > 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.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > > --
> > > 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.
> > >
> > > --
> > > 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.
> > >
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
>
> --
> 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.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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: pass interface

[Ian Lance Taylor]

On Mon, Dec 10, 2018 at 1:43 PM Tyler Compton  wrote:
>
> If my interpretation of the question is correct, I think it boils down to 
> whether or not it's possible to get the reflect.Type of a type in order to 
> pass it to a function without first creating an instance of that type. I 
> don't think it's possible but I would be interested to hear from someone who 
> knows more.

It depends on what you mean by "creating an instance".  For example,
it suffices to create an instance of a pointer to the type, not an
instance of the type itself.  But, yes, reflect.TypeOf requires a
value of some type.  There is no way to get a reflect.Type without
starting with some value of some type.

Ian


> On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak  wrote:
>>
>> No, it is possible, but you need to pass the pointer to the interface.
>> You can then use reflect to interrogate the interface value.
>>
>> The bigger question, and one that would help here would be what is it
>> that you are actually trying to achieve.
>>
>> On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
>> > Yes, this is what I'm trying to do!
>> > Perhaps this is not possible.
>> >
>> > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
>> > wrote:
>> >
>> > >
>> > > I think what the OP wants is:
>> > >
>> > > type A interface{}
>> > > type B interface{}
>> > >
>> > > ...
>> > > PrintInterface(A)
>> > >
>> > > Meaning they want to pass the interface definition to some method.
>> > >
>> > > At least that’s what I am guessing.
>> > >
>> > > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
>> > >
>> > > reflect/* is a bit tricky. Use pointer to get interface itself.
>> > >
>> > > package main
>> > >
>> > > import (
>> > > "fmt"
>> > > "reflect"
>> > > )
>> > >
>> > > func main() {
>> > > test := interface{}("test")
>> > > printInterfaceValue(test)
>> > > }
>> > >
>> > > func printInterfaceValue(i interface{}) {
>> > > switch testing := i.(type) {
>> > > case interface{}:
>> > > fmt.Println("is interface, with value:", testing)
>> > > case string:
>> > > fmt.Println("is not interface")
>> > > }
>> > >
>> > > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
>> > > }
>> > >
>> > > Output:
>> > >
>> > > is interface, with value: test
>> > > reflect.Type is interface {}
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
>> > > Engels
>> > > написал:
>> > > >
>> > > >
>> > > > I mean reflect.Type not a type that is an interface.
>> > > >
>> > > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
>> > > >
>> > > > Of course. When you "pass a value whose type implements the
>> > > > interface" as
>> > > > an interface argument to a function, you in fact pass an
>> > > > *interface*.
>> > > >
>> > > >
>> > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
>> > > > Volkmann
>> > > > написал:
>> > > > >
>> > > > >
>> > > > > Is it possible to pass an interface to a function in Go? I
>> > > > > don’t want to
>> > > > > pass a value whose type implements the interface, I want to
>> > > > > pass the
>> > > > > interface.
>> > > > >
>> > > > > --
>> > > > > R. Mark Volkmann
>> > > > > Object Computing, Inc.
>> > > > >
>> > > > --
>> > > > 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.
>> > > > For more options, visit https://groups.google.com/d/optout.
>> > > >
>> > > > --
>> > > 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.
>> > >
>> > > --
>> > > 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.
>> > >
>> >
>> > --
>> > R. Mark Volkmann
>> > Object Computing, Inc.
>> >
>>
>> --
>> 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.
>
>
>
> --
> Tyler Compton
> Student of Software Engineering
> Arizona State University
>
> --
> 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

Re: [go-nuts] \n new line feed

[Ian Lance Taylor]

On Sun, Dec 9, 2018 at 10:19 AM 伊藤和也  wrote:
>
> In fmt.Println function, \n is used. Is \n safe to use in different platforms?

Yes.

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

[go-nuts] timeout with bufio.Scanner & Scanner.Scan()

[Trig]

I'm currently reading ASCII data from a serial port using the bufio.Scanner 
(since what's coming back is a line at a time, it's convenient w/ reading 
using the Scanner.Text()).  Problem is, the for loop I use to process the 
reads lock at the Scanner.Scan() call.  Is there a to implement some for 
loop that utilized the scanner while utilizing a timeout?

I've tried:

for {
   select {
  case <- time.After(time.Second * 3):
 response <- &Response{
Error: fmt.Errorf("command call took to long for a response"),
 }

 break
  default:
 myScanner.Scan()

 if myScanner.Text() == "OK" {
response <- &Response{
   Content: []responseLines,
}

break
 }
  
 responseLines = append(responseLines, myScanner.Text())
   }
}

Of course, after looking at it... it makes sense why it's not working as 
the loop locks at myScanner.Scan() if there is nothing further to Scan.  
Any help or examples would be appreciated.

-- 
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] timeout with bufio.Scanner & Scanner.Scan()

[robert engels]

You need to use multiple go routines and channels - one routine calls Scan() 
and when it gets the result it writes it to a channel, then the reader can 
timeout on the channel.

> On Dec 10, 2018, at 4:26 PM, Trig  wrote:
> 
> I'm currently reading ASCII data from a serial port using the bufio.Scanner 
> (since what's coming back is a line at a time, it's convenient w/ reading 
> using the Scanner.Text()).  Problem is, the for loop I use to process the 
> reads lock at the Scanner.Scan() call.  Is there a to implement some for loop 
> that utilized the scanner while utilizing a timeout?
> 
> I've tried:
> 
> for {
>select {
>   case <- time.After(time.Second * 3):
>  response <- &Response{
> Error: fmt.Errorf("command call took to long for a response"),
>  }
> 
>  break
>   default:
>  myScanner.Scan()
> 
>  if myScanner.Text() == "OK" {
> response <- &Response{
>Content: []responseLines,
> }
> 
> break
>  }
>   
>  responseLines = append(responseLines, myScanner.Text())
>}
> }
> 
> Of course, after looking at it... it makes sense why it's not working as the 
> loop locks at myScanner.Scan() if there is nothing further to Scan.  Any help 
> or examples would be appreciated.
> 
> -- 
> 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 
> .

-- 
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: pass interface

[Dan Kortschak]

Oh! Yeah, that's never going to work. How could it?

On Mon, 2018-12-10 at 13:43 -0800, Tyler Compton wrote:
> If my interpretation of the question is correct, I think it boils
> down to
> whether or not it's possible to get the reflect.Type of a type in
> order to
> pass it to a function without first creating an instance of that
> type. I
> don't think it's possible but I would be interested to hear from
> someone
> who knows more.
> 
> On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak 
> wrote:
> 
> > 
> > No, it is possible, but you need to pass the pointer to the
> > interface.
> > You can then use reflect to interrogate the interface value.
> > 
> > The bigger question, and one that would help here would be what is
> > it
> > that you are actually trying to achieve.
> > 
> > On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > > 
> > > Yes, this is what I'm trying to do!
> > > Perhaps this is not possible.
> > > 
> > > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels  > > com>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > I think what the OP wants is:
> > > > 
> > > > type A interface{}
> > > > type B interface{}
> > > > 
> > > > ...
> > > > PrintInterface(A)
> > > > 
> > > > Meaning they want to pass the interface definition to some
> > > > method.
> > > > 
> > > > At least that’s what I am guessing.
> > > > 
> > > > On Dec 9, 2018, at 9:22 PM, Space A. 
> > > > wrote:
> > > > 
> > > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > > > 
> > > > package main
> > > > 
> > > > import (
> > > > "fmt"
> > > > "reflect"
> > > > )
> > > > 
> > > > func main() {
> > > > test := interface{}("test")
> > > > printInterfaceValue(test)
> > > > }
> > > > 
> > > > func printInterfaceValue(i interface{}) {
> > > > switch testing := i.(type) {
> > > > case interface{}:
> > > > fmt.Println("is interface, with value:", testing)
> > > > case string:
> > > > fmt.Println("is not interface")
> > > > }
> > > > 
> > > > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> > > > }
> > > > 
> > > > Output:
> > > > 
> > > > is interface, with value: test
> > > > reflect.Type is interface {}
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь
> > > > Robert
> > > > Engels
> > > > написал:
> > > > > 
> > > > > 
> > > > > 
> > > > > I mean reflect.Type not a type that is an interface.
> > > > > 
> > > > > On Dec 9, 2018, at 6:53 PM, Space A. 
> > > > > wrote:
> > > > > 
> > > > > Of course. When you "pass a value whose type implements the
> > > > > interface" as
> > > > > an interface argument to a function, you in fact pass an
> > > > > *interface*.
> > > > > 
> > > > > 
> > > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь
> > > > > Mark
> > > > > Volkmann
> > > > > написал:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Is it possible to pass an interface to a function in Go? I
> > > > > > don’t want to
> > > > > > pass a value whose type implements the interface, I want to
> > > > > > pass the
> > > > > > interface.
> > > > > > 
> > > > > > --
> > > > > > R. Mark Volkmann
> > > > > > Object Computing, Inc.
> > > > > > 
> > > > > --
> > > > > 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.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > > > > 
> > > > > --
> > > > 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.
> > > > 
> > > > --
> > > > 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.
> > > > 
> > > --
> > > R. Mark Volkmann
> > > Object Computing, Inc.
> > > 
> > --
> > 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.
> > 
> 

-- 
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://gro

Re: [go-nuts] Re: pass interface

[Robert Engels]

Well, you can switch on a type, so you would think the case expression might be 
able to be used elsewhere. Since the types can be created at runtime via 
reflect it would seem you should be able to get a reference to the compile time 
type definition as well. Seems logical to me. 


> On Dec 10, 2018, at 4:34 PM, Dan Kortschak  wrote:
> 
> Oh! Yeah, that's never going to work. How could it?
> 
>> On Mon, 2018-12-10 at 13:43 -0800, Tyler Compton wrote:
>> If my interpretation of the question is correct, I think it boils
>> down to
>> whether or not it's possible to get the reflect.Type of a type in
>> order to
>> pass it to a function without first creating an instance of that
>> type. I
>> don't think it's possible but I would be interested to hear from
>> someone
>> who knows more.
>> 
>> On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak 
>> wrote:
>> 
>>> 
>>> No, it is possible, but you need to pass the pointer to the
>>> interface.
>>> You can then use reflect to interrogate the interface value.
>>> 
>>> The bigger question, and one that would help here would be what is
>>> it
>>> that you are actually trying to achieve.
>>> 
 On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
 
 Yes, this is what I'm trying to do!
 Perhaps this is not possible.
 
 On Sun, Dec 9, 2018 at 10:34 PM Robert Engels >>> com>
 wrote:
 
> 
> 
> I think what the OP wants is:
> 
> type A interface{}
> type B interface{}
> 
> ...
> PrintInterface(A)
> 
> Meaning they want to pass the interface definition to some
> method.
> 
> At least that’s what I am guessing.
> 
> On Dec 9, 2018, at 9:22 PM, Space A. 
> wrote:
> 
> reflect/* is a bit tricky. Use pointer to get interface itself.
> 
> package main
> 
> import (
> "fmt"
> "reflect"
> )
> 
> func main() {
> test := interface{}("test")
> printInterfaceValue(test)
> }
> 
> func printInterfaceValue(i interface{}) {
> switch testing := i.(type) {
> case interface{}:
> fmt.Println("is interface, with value:", testing)
> case string:
> fmt.Println("is not interface")
> }
> 
> fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> }
> 
> Output:
> 
> is interface, with value: test
> reflect.Type is interface {}
> 
> 
> 
> 
> 
> 
> понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь
> Robert
> Engels
> написал:
>> 
>> 
>> 
>> I mean reflect.Type not a type that is an interface.
>> 
>> On Dec 9, 2018, at 6:53 PM, Space A. 
>> wrote:
>> 
>> Of course. When you "pass a value whose type implements the
>> interface" as
>> an interface argument to a function, you in fact pass an
>> *interface*.
>> 
>> 
>> воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь
>> Mark
>> Volkmann
>> написал:
>>> 
>>> 
>>> 
>>> Is it possible to pass an interface to a function in Go? I
>>> don’t want to
>>> pass a value whose type implements the interface, I want to
>>> pass the
>>> interface.
>>> 
>>> --
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>> 
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
> 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.
> 
> --
> 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.
> 
 --
 R. Mark Volkmann
 Object Computing, Inc.
 
>>> --
>>> 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.
>>> 
>> 
> 
> -- 
> 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-nu

Re: [go-nuts] Re: pass interface

[Mark Volkmann]

Here is some code that shows a part of what I'm trying to do.
https://goplay.space/#8piYtjsqveZ

package main

import (
"fmt"
"reflect"
)

type Shape interface {
Area() float64
Rotate(angle float64)
Translate(x, y float64)
}

func ReportInterface(intfPtr interface{}) {
fmt.Println("type is", reflect.TypeOf(intfPtr)) // *main.Shape
value := reflect.ValueOf(intfPtr)
fmt.Println("value is", value)// 
fmt.Println("method count is", value.NumMethod()) // 0, Why not 3?
}

func main() {
var ptr *Shape
ReportInterface(ptr)
}

On Mon, Dec 10, 2018 at 3:28 PM Dan Kortschak  wrote:

> No, it is possible, but you need to pass the pointer to the interface.
> You can then use reflect to interrogate the interface value.
>
> The bigger question, and one that would help here would be what is it
> that you are actually trying to achieve.
>
> On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > Yes, this is what I'm trying to do!
> > Perhaps this is not possible.
> >
> > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
> > wrote:
> >
> > >
> > > I think what the OP wants is:
> > >
> > > type A interface{}
> > > type B interface{}
> > >
> > > ...
> > > PrintInterface(A)
> > >
> > > Meaning they want to pass the interface definition to some method.
> > >
> > > At least that’s what I am guessing.
> > >
> > > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
> > >
> > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > >
> > > package main
> > >
> > > import (
> > > "fmt"
> > > "reflect"
> > > )
> > >
> > > func main() {
> > > test := interface{}("test")
> > > printInterfaceValue(test)
> > > }
> > >
> > > func printInterfaceValue(i interface{}) {
> > > switch testing := i.(type) {
> > > case interface{}:
> > > fmt.Println("is interface, with value:", testing)
> > > case string:
> > > fmt.Println("is not interface")
> > > }
> > >
> > > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> > > }
> > >
> > > Output:
> > >
> > > is interface, with value: test
> > > reflect.Type is interface {}
> > >
> > >
> > >
> > >
> > >
> > >
> > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
> > > Engels
> > > написал:
> > > >
> > > >
> > > > I mean reflect.Type not a type that is an interface.
> > > >
> > > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
> > > >
> > > > Of course. When you "pass a value whose type implements the
> > > > interface" as
> > > > an interface argument to a function, you in fact pass an
> > > > *interface*.
> > > >
> > > >
> > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
> > > > Volkmann
> > > > написал:
> > > > >
> > > > >
> > > > > Is it possible to pass an interface to a function in Go? I
> > > > > don’t want to
> > > > > pass a value whose type implements the interface, I want to
> > > > > pass the
> > > > > interface.
> > > > >
> > > > > --
> > > > > R. Mark Volkmann
> > > > > Object Computing, Inc.
> > > > >
> > > > --
> > > > 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.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > > --
> > > 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.
> > >
> > > --
> > > 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.
> > >
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
>


-- 
R. Mark Volkmann
Object Computing, Inc.

-- 
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: pass interface

[Dan Kortschak]

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

On Mon, 2018-12-10 at 20:14 -0600, Mark Volkmann wrote:
> Here is some code that shows a part of what I'm trying to do.
> https://goplay.space/#8piYtjsqveZ
> 
> package main
> 
> import (
> "fmt"
> "reflect"
> )
> 
> type Shape interface {
> Area() float64
> Rotate(angle float64)
> Translate(x, y float64)
> }
> 
> func ReportInterface(intfPtr interface{}) {
> fmt.Println("type is", reflect.TypeOf(intfPtr)) // *main.Shape
> value := reflect.ValueOf(intfPtr)
> fmt.Println("value is", value)// 
> fmt.Println("method count is", value.NumMethod()) // 0, Why not 3?
> }
> 
> func main() {
> var ptr *Shape
> ReportInterface(ptr)
> }
> 
> On Mon, Dec 10, 2018 at 3:28 PM Dan Kortschak 
> wrote:
> 
> > 
> > No, it is possible, but you need to pass the pointer to the
> > interface.
> > You can then use reflect to interrogate the interface value.
> > 
> > The bigger question, and one that would help here would be what is
> > it
> > that you are actually trying to achieve.
> > 
> > On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > > 
> > > Yes, this is what I'm trying to do!
> > > Perhaps this is not possible.
> > > 
> > > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels  > > com>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > I think what the OP wants is:
> > > > 
> > > > type A interface{}
> > > > type B interface{}
> > > > 
> > > > ...
> > > > PrintInterface(A)
> > > > 
> > > > Meaning they want to pass the interface definition to some
> > > > method.
> > > > 
> > > > At least that’s what I am guessing.
> > > > 
> > > > On Dec 9, 2018, at 9:22 PM, Space A. 
> > > > wrote:
> > > > 
> > > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > > > 
> > > > package main
> > > > 
> > > > import (
> > > > "fmt"
> > > > "reflect"
> > > > )
> > > > 
> > > > func main() {
> > > > test := interface{}("test")
> > > > printInterfaceValue(test)
> > > > }
> > > > 
> > > > func printInterfaceValue(i interface{}) {
> > > > switch testing := i.(type) {
> > > > case interface{}:
> > > > fmt.Println("is interface, with value:", testing)
> > > > case string:
> > > > fmt.Println("is not interface")
> > > > }
> > > > 
> > > > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> > > > }
> > > > 
> > > > Output:
> > > > 
> > > > is interface, with value: test
> > > > reflect.Type is interface {}
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь
> > > > Robert
> > > > Engels
> > > > написал:
> > > > > 
> > > > > 
> > > > > 
> > > > > I mean reflect.Type not a type that is an interface.
> > > > > 
> > > > > On Dec 9, 2018, at 6:53 PM, Space A. 
> > > > > wrote:
> > > > > 
> > > > > Of course. When you "pass a value whose type implements the
> > > > > interface" as
> > > > > an interface argument to a function, you in fact pass an
> > > > > *interface*.
> > > > > 
> > > > > 
> > > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь
> > > > > Mark
> > > > > Volkmann
> > > > > написал:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Is it possible to pass an interface to a function in Go? I
> > > > > > don’t want to
> > > > > > pass a value whose type implements the interface, I want to
> > > > > > pass the
> > > > > > interface.
> > > > > > 
> > > > > > --
> > > > > > R. Mark Volkmann
> > > > > > Object Computing, Inc.
> > > > > > 
> > > > > --
> > > > > 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.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > > > > 
> > > > > --
> > > > 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.
> > > > 
> > > > --
> > > > 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.
> > > > 
> > > --
> > > R. Mark Volkmann
> > > Object Computing, Inc.
> > > 

> 

-- 
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: Starlight - run python inside Go to extend your applications - easily

[Jason E. Aten]

For full, actual python inside Go, one could combine:

(a) https://github.com/iodide-project/pyodide  has the python scientific 
stack compiled to wasm (python + numpy + scipy + numplotlib)

and

(b) either https://github.com/go-interpreter/wagon or 
https://github.com/perlin-network/life: each provide a wasm byte-code 
interpreter as a Go library.


On Monday, December 10, 2018 at 2:39:09 AM UTC-6, mic...@scylladb.com wrote:
>
>
>
> On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>>
>> I’d like to announce starlight - 
>> https://github.com/starlight-go/starlight.
>>
>>
>> Starlight wraps google’s Go implementation of the starlark python dialect 
>>  (most notably found in the Bazel 
>> build tool). Starlight makes it super easy for users to extend your 
>> application by writing simple python scripts that interact seamlessly with 
>> your current Go code… with no boilerplate on your part.
>>
>
> Do you think it is suitable for porting python applications?
> Usually you go through cgo like this 
> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be an 
> interesting alternative. 
>  
>
>>
>> *Parser by google*
>>
>> The parser and runner are maintained by google’s bazel team, which write 
>> starlark-go. Starlight is a wrapper on top of that, which makes it so much 
>> easier to use starlark-go. The problem with the starlark-go API is that it 
>> is more built to be a used as configuration, so it assumes you want to get 
>> information out of starlark and into Go. It’s actually pretty difficult to 
>> get Go information into a starlark script…. unless you use starlight.
>>
>> *Easy two-way interaction*
>>
>>
>> Starlight has adapters that use reflection to automatically make any Go 
>> value usable in a starlark script. Passing an *http.Request into a 
>> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in the 
>> python without any work on your part.
>>
>> Starlight is built to *just work* the way you hope it’ll work. You can 
>> access any Go methods or fields, basic types get converted back and forth 
>> seamlessly… and even though it uses reflection, it’s not as slow as you’d 
>> think. A basic benchmark wrapping a couple values and running a starlark 
>> script to work with them runs in a tiny fraction of a millisecond.
>>
>> The great thing is that the changes made by the python code are reflected 
>> in your go objects, just as if it had been written in Go. So, set a field 
>> on a pointer to a struct? Your go code will see the change, no additional 
>> work needed.
>>
>> *100% Safe*
>>
>>
>> The great thing about starlark and starlight is that the scripts are 100% 
>> safe to run. By default they have no access to other parts of your project 
>> or system - they can’t write to disk or connect to the internet. The only 
>> access they have to the outside is what you give them. Because of this, 
>> it’s safe to run untrusted scripts (as long as you’re not giving them 
>> dangerous functions to run, like os.RemoveAll). But at the same time, if 
>> you’re only running trusted scripts, you can give them whatever you want (
>> http.Get? Sure, why not?)
>>
>> *Caching*
>>
>>
>> In a production environment, you probably want to only read a script once 
>> and parse it once. You can do that with starlight’s Cache. This cache 
>> takes a list of directories to look in for scripts, which it will read and 
>> parse on-demand, and then store the parsed object in memory for later use. 
>> It also uses a cache for any load() calls the scripts use to load 
>> scripts they depend on.
>>
>> *Work Ongoing*
>>
>>
>> Starlight is still a work in progress, so don’t expect the API to be 
>> perfectly stable quite yet. But it’s getting pretty close, and there 
>> shouldn’t be any earth shattering changes, but definitely pin your imports. 
>> Right now it’s more about finding corner cases where the starlight wrappers 
>> don’t work quite like you’d expect, and supporting the last few things that 
>> aren’t implemented yet (like channels).
>>
>>
>> *Example*
>>
>>
>> Here's a simple example of how easy it is to extend the behavior of your 
>> application with a python script.  Just pass starlight whatever go values 
>> you want your python script to act on, and any changes the python code 
>> makes get reflected in your go code.  
>>
>>
>> package main
>>
>> import (
>> "fmt"
>> "log"
>> "time"
>>
>> "github.com/starlight-go/starlight"
>> )
>>
>> // Starlight makes it easy to get values in and out of your starlark 
>> scripts.
>> // Just pass in pointers to values that you want changed, or callback 
>> functions
>> // that propagate data.
>>
>> // In theory, starlight also returns all global variables set by the 
>> script, but
>> // in real programs, you need well-defined outputs for your calling code 
>> to act on.
>> // If I write a script that creates a variable called nate_is_awesome = 
>> 1337 ... your
>> // 

Re: [go-nuts] Re: pass interface

[Mark Volkmann]

Thanks so much Dan!

---
R. Mark Volkmann
Object Computing, Inc.

> On Dec 10, 2018, at 8:34 PM, Dan Kortschak  wrote:
> 
> https://play.golang.org/p/VWPb_AcgUrl
> 
>> On Mon, 2018-12-10 at 20:14 -0600, Mark Volkmann wrote:
>> Here is some code that shows a part of what I'm trying to do.
>> https://goplay.space/#8piYtjsqveZ
>> 
>> package main
>> 
>> import (
>> "fmt"
>> "reflect"
>> )
>> 
>> type Shape interface {
>> Area() float64
>> Rotate(angle float64)
>> Translate(x, y float64)
>> }
>> 
>> func ReportInterface(intfPtr interface{}) {
>> fmt.Println("type is", reflect.TypeOf(intfPtr)) // *main.Shape
>> value := reflect.ValueOf(intfPtr)
>> fmt.Println("value is", value)// 
>> fmt.Println("method count is", value.NumMethod()) // 0, Why not 3?
>> }
>> 
>> func main() {
>> var ptr *Shape
>> ReportInterface(ptr)
>> }
>> 
>> On Mon, Dec 10, 2018 at 3:28 PM Dan Kortschak 
>> wrote:
>> 
>>> 
>>> No, it is possible, but you need to pass the pointer to the
>>> interface.
>>> You can then use reflect to interrogate the interface value.
>>> 
>>> The bigger question, and one that would help here would be what is
>>> it
>>> that you are actually trying to achieve.
>>> 
 On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
 
 Yes, this is what I'm trying to do!
 Perhaps this is not possible.
 
 On Sun, Dec 9, 2018 at 10:34 PM Robert Engels >>> com>
 wrote:
 
> 
> 
> I think what the OP wants is:
> 
> type A interface{}
> type B interface{}
> 
> ...
> PrintInterface(A)
> 
> Meaning they want to pass the interface definition to some
> method.
> 
> At least that’s what I am guessing.
> 
> On Dec 9, 2018, at 9:22 PM, Space A. 
> wrote:
> 
> reflect/* is a bit tricky. Use pointer to get interface itself.
> 
> package main
> 
> import (
> "fmt"
> "reflect"
> )
> 
> func main() {
> test := interface{}("test")
> printInterfaceValue(test)
> }
> 
> func printInterfaceValue(i interface{}) {
> switch testing := i.(type) {
> case interface{}:
> fmt.Println("is interface, with value:", testing)
> case string:
> fmt.Println("is not interface")
> }
> 
> fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> }
> 
> Output:
> 
> is interface, with value: test
> reflect.Type is interface {}
> 
> 
> 
> 
> 
> 
> понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь
> Robert
> Engels
> написал:
>> 
>> 
>> 
>> I mean reflect.Type not a type that is an interface.
>> 
>> On Dec 9, 2018, at 6:53 PM, Space A. 
>> wrote:
>> 
>> Of course. When you "pass a value whose type implements the
>> interface" as
>> an interface argument to a function, you in fact pass an
>> *interface*.
>> 
>> 
>> воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь
>> Mark
>> Volkmann
>> написал:
>>> 
>>> 
>>> 
>>> Is it possible to pass an interface to a function in Go? I
>>> don’t want to
>>> pass a value whose type implements the interface, I want to
>>> pass the
>>> interface.
>>> 
>>> --
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>> 
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
> 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.
> 
> --
> 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.
> 
 --
 R. Mark Volkmann
 Object Computing, Inc.
 
> 
>> 

-- 
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] How to build gollvm on arm platform

[morefun . fang]

@Than, Thank you for your detailed answer.

I am interested in contributing code to enable ARM port. I plan to spend 
some times on learning gofrontend firstly, then the bridge. What I want to 
learn about are

1, Is there any arch-specific code/IR in gofrontend?
2, What's the missing to support ARM ABI in gollvm bridge, anything else 
besides of passing parameters?
3, What can we do on runtime for arm?
4, How to test what we do on arm without building support?

I would be appreciated if you can give me suggestion and guidance.

Thanks


在 2018年12月11日星期二 UTC+8上午2:46:47，Than McIntosh写道：
>
> Hello,
>
> As things stand, gollvm isn't usable for Arm (32 or 64); the cmake error 
> you are hitting is intentional.
>
> The main obstacle for enabling Arm is enhancing the Gollvm bridge to 
> support the Arm ABI, e.g. the rules for passing parameters (in memory vs 
> register) depending on the signature of the called routine.  Adding ARM 
> support is something that's on the Gollvm "to do" list, but hasn't reached 
> the top. Once the ABI support is there it should not be a lot of additional 
> work.
>
> If you are interested in contributing code to help fix the problem, we can 
> point you in the right direction and provide guidance, but it will take a 
> bit of doing.
>
> Thanks, Than
>
>
> On Mon, Dec 10, 2018 at 12:54 PM > 
> wrote:
>
>>  I try to compile gollvm on arm platform according to 
>> https://go.googlesource.com/gollvm/, but error is reported as following
>>
>> CMake Error at tools/gollvm/cmake/modules/GoVars.cmake:12 (message):
>>   Arch aarch64 not yet supported
>>
>> https://go.googlesource.com/gollvm/ tells that Gollvm is currently 
>> supported only for x86_64 Linux. 
>>
>> Is there any way to compile gollvm on arm platform?
>>
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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: pass interface

[Dan Kortschak]

Nice is a very strong word.

This is the alternative approach that doesn't require a value:

https://play.golang.org/p/FoA-GHcr56s

(now to the whole list)

On Tue, 2018-12-11 at 10:39 +0800, Huiqiang Li wrote:
> Nice! i think this is the right answer.
> 
> Dan Kortschak  于2018年12月11日周二 上午10:34写道：
> 
> > 
> > https://play.golang.org/p/VWPb_AcgUrl

-- 
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] Generics

[Tharaneedharan Vilwanathan]

Hi All,

I have a quick question.

What is the best choice for writing generic code till Go officially
supports generics? Just looking for some guidance.

Regards
dharani

-- 
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] Generics

[Ian Denhardt]

It would be easier to help if you gave us a more concrete picture of
what you're trying to achieve; if there were a nice drop-in alternative
to generics in all circumstances already in the language, we probably
wouldn't be talking about adding them in the first place :P.

Quoting Tharaneedharan Vilwanathan (2018-12-10 22:00:24)
>Hi All,
>I have a quick question.
>What is the best choice for writing generic code till Go officially
>supports generics? Just looking for some guidance.
>Regards
>dharani
>
>--
>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 [1]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [2]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:golang-nuts+unsubscr...@googlegroups.com
>2. https://groups.google.com/d/optout

-- 
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: Plan9 reborn as a guest OS atop of Golang runtime

[Jason E. Aten]

check out/related:

https://github.com/Harvey-OS/harvey which is a modern 64-bit descendant of 
plan9. While not written in Go itself, it does support Go according to 
https://harvey-os.org/2016/10/20/go-programming-language-on-harvey.html

http://lsub.org/ls/clive.html used a modified version of Go for a research 
project. Not currently maintained, but may still be of interest.

On Monday, December 10, 2018 at 11:54:05 AM UTC-6, Dmitry Ponyatov wrote:
>
> Can Plan9 reborn as a *guest* OS atop of Golang runtime?
>
> Maybe somebody works on a clustering system can expand Go runtime to 
> natively and transparently run over Beowulf-style message passing clusters?
>

-- 
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: pass interface

[David Riley]

Ah! No, that is not possible, because interfaces (and other types) are not 
first-class objects in Go like they are in some other languages (such as 
Python).  You can work around it, to some extent, by passing a zero-valued 
instance of such an interface (e.g. PrintInterface(A{})) and using some 
reflection magics to do what you need based on the reflect.Type and similar. 
That's how a number of libraries like Resty determine how to e.g. deserialize 
JSON to a specific type requested by users. It's got its warts, but it works.


- Dave


> On Dec 10, 2018, at 9:53 AM, Mark Volkmann  wrote:
> 
> Yes, this is what I'm trying to do!
> Perhaps this is not possible.
> 
> On Sun, Dec 9, 2018 at 10:34 PM Robert Engels  wrote:
> I think what the OP wants is:
> 
> type A interface{}
> type B interface{}
> 
> ...
> PrintInterface(A)
> 
> Meaning they want to pass the interface definition to some method. 
> 
> At least that’s what I am guessing. 

-- 
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: pass interface

[Jason E. Aten]

Last but not least, for debugging a value x, this gets you type and value 
quickly:

fmt.Printf("type is %T and value is %#v\n", x, x) 

On Monday, December 10, 2018 at 8:14:47 PM UTC-6, Mark Volkmann wrote:
>
> Here is some code that shows a part of what I'm trying to do.
> https://goplay.space/#8piYtjsqveZ
>
> package main
>
> import (
> "fmt"
> "reflect"
> )
>
> type Shape interface {
> Area() float64
> Rotate(angle float64)
> Translate(x, y float64)
> }
>
> func ReportInterface(intfPtr interface{}) {
> fmt.Println("type is", reflect.TypeOf(intfPtr)) // *main.Shape
> value := reflect.ValueOf(intfPtr)
> fmt.Println("value is", value)// 
> fmt.Println("method count is", value.NumMethod()) // 0, Why not 3?
> }
>
> func main() {
> var ptr *Shape
> ReportInterface(ptr)
> }
>
>

-- 
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] [ANN] THUMBAI v1.0.0-beta Released! - A Go Mod Repository, Go Vanity and Simple Proxy Server

[Jeevanandam M.]

Website: https://thumbai.app
Documentation: https://thumbai.app/get-started

Your feedback is very valuable. Thanks.

Cheers,
Jeeva

-- 
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.