[go-nuts] TCP Listen in windows to recieve data

[golang user]

I am bringing up TCP listener in windows OS, not sure how to recieve data 
from listener and send to command line 


IN UNIX WE DO AS FOLLOWS

service := ":1200"
tcpAddr, err := net.ResolveTCPAddr("tcp", service)
listener, err := net.ListenTCP("tcp",tcpAddr)
if err != nil {
return "", err
}

defer listener.Close()
* file, err := listener.File()   --> unix supports file descriptor / how 
about in windows ??*
if err != nil {  
return "", err
}

cmd := exec.Command( execname)

cmd.ExtraFiles = []*os.File{*file*}  --> in unix it support / how about in 
windows to add data ???

cmd.Start()



kindly need help to bring up in windows to listen on tcp ipaddress and send 
to executable file

-- 
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: Best way to handle database transactions? (commit, or rollback on error)

['Eric Johnson' via golang-nuts]

On Thu, Dec 6, 2018 at 4:37 PM roger peppe  wrote:

> How would generics help you here? The WithTxn function is already generic
> (courtesy of closures) and there's no reason it couldn't be put in a
> publicly importable package somewhere.
>

When I use the equivalent functionality, I tie it to an interface
specifically for the database changes / queries allowed. Makes for great
separation between the database layer and the business logic. That means,
however, every time I have a new database API, there's a new interface, and
a new implementation of the function.

Eric.


> On Thu, 6 Dec 2018, 10:26 pm Eric Johnson 
>>
>>
>> On Thu, Dec 6, 2018 at 12:16 AM roger peppe  wrote:
>>
>>>
>>>
>>> On Wed, 5 Dec 2018 at 18:55, 'Eric Johnson' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
 I always go with the approach that uses the equivalent of the
 "Transact()" method.

 On top of that, rather than use a generic *sql.Tx parameter to the
 "txFunc" function, I pass an interface that is specific to the operations
 of the database layer for my application.

>>>
>>> That's an interesting idea. For the record, this is the code we use:
>>>
>>
>> This is one of *the* places in my code where I'd probably immediately
>> take advantage of "generics" in Go. This function to wrap transactions
>> could be written generically, and then not have to be copied from
>> application to application. While I could go with the work-around to leave
>> the function in the *sql.Tx parameter form, the other approach is *so*
>> useful that I copy the function instead.
>>
>> Eric
>>
>>
>>>
>>> package transaction
>>>
>>> import (
>>> "context"
>>> "database/sql"
>>> "fmt"
>>>
>>> "gopkg.in/errgo.v1"
>>> )
>>>
>>> // WithTxn executes a function inside a transaction context.
>>> func WithTxn(db *sql.DB, ctx context.Context, f func(*sql.Tx) error)
>>> error {
>>> txn, err := db.BeginTx(ctx, nil)
>>> if err != nil {
>>> return errgo.Mask(err)
>>> }
>>> if err := f(txn); err != nil {
>>> return rollback(txn, err)
>>> }
>>> return rollback(txn, txn.Commit())
>>> }
>>>
>>> func rollback(txn *sql.Tx, err error) error {
>>> if err == nil {
>>> return nil
>>> }
>>> errRollback := txn.Rollback()
>>> if errRollback != nil {
>>> return errgo.NoteMask(err, fmt.Sprintf("failed to roll back
>>> (error: %v) after", errRollback), errgo.Any)
>>> }
>>> return err
>>> }
>>>



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

[Nate Finch]

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.

*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 := {
Name: "a story about nate",
Date: time.Now(),
Contents: "I like to write go code.",
IsDraft: true,
}
globals := map[string]interface{}{
"page": p,
}
_, err := starlight.Eval([]byte(code), globals, nil)
if err != nil {
log.Fatal(err)
}
fmt.Printf("%v is draft: %v\n", p.Name, p.IsDraft)
}

// Running it:
// $ go run inout.go
// A Story About Nate 2018/12/07 is draft: false

-- 
You received this message because you are subscribed to 

[go-nuts] [security] Go 1.11.3 and Go 1.10.6 pre-announcement

[Dmitri Shuralyov]

Hello gophers,

We plan to issue Go 1.11.3 and Go 1.10.6 on Wednesday, December 12 at
approximately 8 pm UTC (12 pm PST, 3 pm EST). These are minor releases to
fix a security issue.

Following our policy at https://golang.org/security, this is the
pre-announcement of those releases.

Thanks,
Dmitri on behalf of 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] navigating through interface calls

[Robert Engels]

IntelliJ has “show implementations” which will do what you want. 

> On Dec 7, 2018, at 11:13 AM, Burak Serdar  wrote:
> 
> On Fri, Dec 7, 2018 at 9:53 AM David Wahlstedt
>  wrote:
>> 
>> 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 ?
> 
> That is not possible in general. This is not unique to go either.
> Consider a function like:
> 
> type Shape interface {
>   Draw()
> }
> 
> func draw(shapes []Shape) {
>   for _,x:=range shapes {
>   x.Draw()
>  }
> }
> 
> 
> Each element of 'shapes' can be a different type, with a different
> Draw() implementation.
> 
> What I do in these situations is to either backtrack calls as you did,
> or simply use grep, and find a list of candidate implementations, and
> work from there.
> 
> This is somewhat easier with languages like Java because you can look
> for classes implementing that interface, but then you still have to
> work with a list of candidates.
> 
> 
> 
> 
>> 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 {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.
> 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 

Re: [go-nuts] navigating through interface calls

[Burak Serdar]

On Fri, Dec 7, 2018 at 9:53 AM David Wahlstedt
 wrote:
>
> 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 ?

That is not possible in general. This is not unique to go either.
Consider a function like:

type Shape interface {
   Draw()
}

func draw(shapes []Shape) {
   for _,x:=range shapes {
   x.Draw()
  }
}


Each element of 'shapes' can be a different type, with a different
Draw() implementation.

What I do in these situations is to either backtrack calls as you did,
or simply use grep, and find a list of candidate implementations, and
work from there.

This is somewhat easier with languages like Java because you can look
for classes implementing that interface, but then you still have to
work with a list of candidates.




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

[howardcshaw]

It is rather the point of interfaces that there IS no fixed definition of 
an instance of an Interface call. The definition could be that of ANY 
struct that matches that interface, depending on what is passed.

So yes, you have to find AN instance of a call to the function that accepts 
an interface, to find out what it is calling. Because if you call it with a 
different struct, it calls that struct's implementation. Kind of the point. 
And finding that implementation for that call does not guarantee that the 
next call may not be calling a different implementation, because it is 
being passed a different struct.

Your steps after 5 seemed a bit unnecessary - just go to the definition of 
xooConn, your step 5, and search for Close. While it is possible to 
implement a function on a struct elsewhere, the likelihood is pretty low, 
and if you don't find it, then you can go on to your other steps. 

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

[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 {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] convert *byte to []byte

['Bryan C. Mills' via golang-nuts]

On Fri, Dec 7, 2018 at 10:50 AM roger peppe  wrote:

> On Fri, 7 Dec 2018, 3:26 pm 'Bryan Mills' via golang-nuts <
> golang-nuts@googlegroups.com wrote:
>
>> On Monday, December 3, 2018 at 12:02:07 AM UTC-5, Ian Lance Taylor wrote:
>>>
>>> On Sat, Dec 1, 2018 at 9:39 AM  wrote:
>>> >
>>> > I am using swig wrap a c++ module , the generated go code is like
>>> this:
>>> >
>>> > type  MediaFrame interface {
>>> >  GetLength()  uint
>>> >  GetData()  (*byte)
>>> > }
>>> >
>>> > I want to convert the *byte  to []byte,  How to do this?
>>>
>>> One approach is
>>>
>>> s :=
>>> (*[1<<30]byte)(unsafe.Pointer(mf.GetData())[:mf.GetLength():mf.GetLength()]
>>>
>>> Ian
>>>
>>
>> If you need to handle slices larger than 2³⁰ bytes, a more robust version
>> of this same approach is described in
>> https://golang.org/issue/13656#issuecomment-303216308.
>>
>>
>
> Unfortunately this approach is vulnerable to a memory leak due to
> https://golang.org/issue/28783 (and I suspect it will be quite a bit
> slower too, if performance is important). I wonder if it might be better to
> use reflect.SliceHeader guarded with some suitable regression checks.
>

Check the code at the link: it uses only one array type per element type,
so as long as the set of element types is fixed (as it usually is) it
introduces only a constant number of new types.

(It is indeed somewhat slower, but compared to the overhead of the C/Go
transition it's not terrible.)

-- 
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] convert *byte to []byte

[roger peppe]

On Fri, 7 Dec 2018, 3:26 pm 'Bryan Mills' via golang-nuts <
golang-nuts@googlegroups.com wrote:

> On Monday, December 3, 2018 at 12:02:07 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Sat, Dec 1, 2018 at 9:39 AM  wrote:
>> >
>> > I am using swig wrap a c++ module , the generated go code is like this:
>> >
>> > type  MediaFrame interface {
>> >  GetLength()  uint
>> >  GetData()  (*byte)
>> > }
>> >
>> > I want to convert the *byte  to []byte,  How to do this?
>>
>> One approach is
>>
>> s :=
>> (*[1<<30]byte)(unsafe.Pointer(mf.GetData())[:mf.GetLength():mf.GetLength()]
>>
>> Ian
>>
>
> If you need to handle slices larger than 2³⁰ bytes, a more robust version
> of this same approach is described in
> https://golang.org/issue/13656#issuecomment-303216308.
>
>

Unfortunately this approach is vulnerable to a memory leak due to
https://golang.org/issue/28783 (and I suspect it will be quite a bit slower
too, if performance is important). I wonder if it might be better to use
reflect.SliceHeader guarded with some suitable regression checks.


-- 
> 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] convert *byte to []byte

['Bryan Mills' via golang-nuts]

On Monday, December 3, 2018 at 12:02:07 AM UTC-5, Ian Lance Taylor wrote:
>
> On Sat, Dec 1, 2018 at 9:39 AM > wrote: 
> > 
> > I am using swig wrap a c++ module , the generated go code is like this: 
> > 
> > type  MediaFrame interface { 
> >  GetLength()  uint 
> >  GetData()  (*byte) 
> > } 
> > 
> > I want to convert the *byte  to []byte,  How to do this? 
>
> One approach is 
>
> s := 
> (*[1<<30]byte)(unsafe.Pointer(mf.GetData())[:mf.GetLength():mf.GetLength()] 
>
> Ian 
>

If you need to handle slices larger than 2³⁰ bytes, a more robust version 
of this same approach is described 
in https://golang.org/issue/13656#issuecomment-303216308.
 

-- 
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] golang.org/x/oauth2 bug???

[Burak Serdar]

On Fri, Dec 7, 2018 at 6:46 AM Harald Fuchs  wrote:
>
> I think there's something fishy about clientcredentials.  Having
> trouble with client_secrets containig special chars, first I modified
> clientcredentials_test.go like this:
>
> > func TestTokenRequest(t *testing.T) {
> > cfg := newConf("")
> > data := fmt.Sprintf("%s:%s", cfg.ClientID, cfg.ClientSecret)
> > sEnc := base64.StdEncoding.EncodeToString([]byte(data))
> > ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r 
> > *http.Request) {
> > if r.URL.String() != "/token" {
> > t.Errorf("authenticate client request URL = %q; want %q", r.URL, "/token")
> > }
> > headerAuth := r.Header.Get("Authorization")
> > if headerAuth != "Basic "+sEnc {
> > ...
>
> "go test ." succeeded, obviously.
>
> Then I modified the client_secret:
>
> > ClientSecret:   "CLIENT_SECRET=",
>
> Now "go test ." failed!
>
> Changing internal/token.go like this:
>
> > if !bustedAuth {
> > //req.SetBasicAuth(url.QueryEscape(clientID), url.QueryEscape(clientSecret))
> > req.SetBasicAuth(clientID, clientSecret)
> > }

IIRC, Oauth spec requires clientId and clientSecret passed as query
params. There is some code in go oauth implementation to work around
some servers that require clientId/clientSecret in different places,
like Auth header. You are passing the clientId/clientSecret in auth
header, but your servers implementation is not one of the "busted"
ones, so it is expecting to see them in the query, and escaping them
correctly. So you should either send those to in the query, or somehow
convince the library that your test is one of the busted servers.

>
> made "go test ." succeed again.
>
> --
> 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] golang.org/x/oauth2 bug???

[Harald Fuchs]

I think there's something fishy about clientcredentials.  Having
trouble with client_secrets containig special chars, first I modified
clientcredentials_test.go like this:

> func TestTokenRequest(t *testing.T) {
> cfg := newConf("")
> data := fmt.Sprintf("%s:%s", cfg.ClientID, cfg.ClientSecret)
> sEnc := base64.StdEncoding.EncodeToString([]byte(data))
> ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r 
*http.Request) {
> if r.URL.String() != "/token" {
> t.Errorf("authenticate client request URL = %q; want %q", r.URL, "/token")
> }
> headerAuth := r.Header.Get("Authorization")
> if headerAuth != "Basic "+sEnc {
> ...

"go test ." succeeded, obviously.

Then I modified the client_secret:

> ClientSecret:   "CLIENT_SECRET=",

Now "go test ." failed!

Changing internal/token.go like this:

> if !bustedAuth {
> //req.SetBasicAuth(url.QueryEscape(clientID), 
url.QueryEscape(clientSecret))
> req.SetBasicAuth(clientID, clientSecret)
> }

made "go test ." succeed again.

-- 
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] windows TCP listen bind to loopback address and get data and spawn through application request

[phanee1712]

Looking for sample  in  windows

a) TCP listener with loop back address on 127.0.0.2/8844

b) read data  and spawn child process to execute  listener data

one more notice, in unix we read listener file descripter, how about in 
windows? ( i know windows does not support file descripters

By the way child process will run listener data as arguments to a exe file .

-- 
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] Why is this code runs sequentially?

[roger peppe]

You want to run it concurrently, but you also need the results in order so
that you can concatenate them together in the right order (I'm assuming).
Something like this would do the trick:
https://play.golang.org/p/lMI8rmEBJ-d

On Thu, 6 Dec 2018 at 23:40, Alex Dvoretskiy 
wrote:

> Hi Golangnuts,
>
> I'm trying to run SignerCrc32() concurently, but instead it runs
> sequentially. Can you explain why?
>
> https://play.golang.org/p/l5A3tBSqfs1
>
> --
> 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.