[go-nuts] Re: Bulky (Payload) Structs in API

[dc0d]

BTW another approach that I've tried is to use Type Aliases. A third 
package created and type aliases (with the same names) defined for those 
POGO payloads.

Then type aliases (and interfaces) from this third package can be used in 
upper/other packages.

But I've not used it heavily because I still do not feel being confident 
that the approach is proper or not.

On Monday, November 13, 2017 at 11:18:07 AM UTC+3:30, dc0d wrote:
>
> Thanks!
>
> That's what I do, though not happy with it. I had to write some helper 
> apps and scripts (I'm not fluent in playing with Go ast yet).
>
> An example would be the API to Telegram Bot (package 
> ). Requests and 
> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
> Go structs are the one in question.
>
> As it can be seen, they are pretty big and bulky (can not be helped, it's 
> how the Telegram API is). But passing them up/out, makes other packages, 
> become dependent on *tgbotapi* package.
>
> As for functionality, interfaces work great. But for payloads that are 
> being passed between packages (even if they are POGOs) I can not find a 
> clean approach for sharing them.
>
> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>
>> One possibility is copy-paste the structure and convert at call 
>> boundaries.
>>
>> https://play.golang.org/p/5LFw6U3yi6
>>
>> But, can you show a real-world example to ground the conversation?
>>
>> + Egon
>>
>> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>>>
>>> It is a Go best practice to "accept interfaces, return concrete types". 
>>> Which helps greatly in implementing different architectures/designs (like 
>>> Clean Architecture or the like).
>>>
>>> There are times that a package is used which returns fat structs (as the 
>>> concrete type) - mostly POGO.
>>>
>>> Problem:
>>> Redefining some domain models for those payloads is cumbersome and 
>>> sometimes impractical. At the same time using them directly, exposes other 
>>> packages to that package that we want to abstract out it's functionality. 
>>> Some unwelcome dependency.
>>>
>>> Question:
>>> Should we redefined all those data types in upper layers for using them? 
>>> If no what is the solution?
>>>
>>

-- 
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: Bulky (Payload) Structs in API

[dc0d]

Thanks!

That's what I do, though not happy with it. I had to write some helper apps 
and scripts (I'm not fluent in playing with Go ast yet).

An example would be the API to Telegram Bot (package 
). Requests and 
responses from the API are big, fat JSONs; wrapped up in Go structs. These 
Go structs are the one in question.

As it can be seen, they are pretty big and bulky (can not be helped, it's 
how the Telegram API is). But passing them up/out, makes other packages, 
become dependent on *tgbotapi* package.

As for functionality, interfaces work great. But for payloads that are 
being passed between packages (even if they are POGOs) I can not find a 
clean approach for sharing them.

On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>
> One possibility is copy-paste the structure and convert at call boundaries.
>
> https://play.golang.org/p/5LFw6U3yi6
>
> But, can you show a real-world example to ground the conversation?
>
> + Egon
>
> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>>
>> It is a Go best practice to "accept interfaces, return concrete types". 
>> Which helps greatly in implementing different architectures/designs (like 
>> Clean Architecture or the like).
>>
>> There are times that a package is used which returns fat structs (as the 
>> concrete type) - mostly POGO.
>>
>> Problem:
>> Redefining some domain models for those payloads is cumbersome and 
>> sometimes impractical. At the same time using them directly, exposes other 
>> packages to that package that we want to abstract out it's functionality. 
>> Some unwelcome dependency.
>>
>> Question:
>> Should we redefined all those data types in upper layers for using them? 
>> If no what is the solution?
>>
>

-- 
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: OpenCL or CUDA bindings

[Ron Evans]

Hello, all

I've been working on some similar problems calling Windows APIs from Go.

This looks promising, in order to use .lib files from within MinGW:

https://stackoverflow.com/questions/11793370/how-can-i-convert-a-vsts-lib-to-a-mingw-a

Anyone tried this?

On Sunday, November 12, 2017 at 8:36:25 PM UTC+1, John Madison wrote:
>
> I've been having trouble with bindings because I use windows with go and 
> go compiler uses mingw.
> This means that even on windows, I need the ".a" files rather than the 
> ".lib" files for the linker.
> The problem is, the cuda-toolkit for windows does NOT give you the .a 
> files.
> The solution: Use the "syscall" package.
> So far I've been able to get a device and context and query properties of 
> the device and context.
> Now working on creating bindings for clBuildProgram to get my first 
> hello-world up and running.
>
> If anyone is interested: Email me: HeavyMetalCookies ＡＴ Gmail ＤＯＴ-ＣＯＭ
>
> On Thursday, June 14, 2012 at 6:41:30 PM UTC-7, Tharaneedharan Vilwanathan 
> wrote:
>>
>> Hi,
>>
>> I have shown interest off and on in using OpenCL in Go. I am still 
>> waiting for something that is usable and as easy as OpenGL in Go. In the 
>> recent time, I also got ATI 6850 card for this. So I am very interested.
>>
>> Thanks
>> dharani
>>
>> On Thu, Jun 14, 2012 at 5:02 PM, Nick Sarten  wrote:
>>
>>> From a quick search of Github I found  
>>> https://github.com/tones111/go-opencl. Bitbucket's seach is 
>>> frustratingly unhelpful, but I would bet there's other Go/OpenCL projects 
>>> on there other than just mine.
>>>
>>> I also made an attempt myself to create an interface between OpenCL and 
>>> Go, but admittedly it wasn't very well organised, and hasn't been updated 
>>> to work with the latest Go release. I also found the constantly changing 
>>> format and installation method of AMD's APP SDK to be a pain when it comes 
>>> to compiling anything for OpenCL (every version reorganises where it 
>>> installs to, and it doesn't install the libraries/headers to a standard 
>>> location like /usr/lib/).
>>>
>>> Hope this information helps,
>>>Nick
>>>
>>>
>>> On Wednesday, 13 July 2011 16:47:45 UTC+12, M. Yurko wrote:

 So, there are a number of older posts asking about OpenCL or CUDA 
 bindings. Has anyone made any significant progress? Does anyone have a 
 public repository with interface code? I'm consider go  for a project, 
 but I will need decent bindings to either OpenCL or CUDA. 

 Thanks for any help, 
 Mike Yurko
>>>
>>>
>>

-- 
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: Bulky (Payload) Structs in API

[Egon]

One possibility is copy-paste the structure and convert at call boundaries.

https://play.golang.org/p/5LFw6U3yi6

But, can you show a real-world example to ground the conversation?

+ Egon

On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>
> It is a Go best practice to "accept interfaces, return concrete types". 
> Which helps greatly in implementing different architectures/designs (like 
> Clean Architecture or the like).
>
> There are times that a package is used which returns fat structs (as the 
> concrete type) - mostly POGO.
>
> Problem:
> Redefining some domain models for those payloads is cumbersome and 
> sometimes impractical. At the same time using them directly, exposes other 
> packages to that package that we want to abstract out it's functionality. 
> Some unwelcome dependency.
>
> Question:
> Should we redefined all those data types in upper layers for using them? 
> If no what is the solution?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How to convert from []byte to []uint32?

[Christian LeMoussel]

I have a data stream of bytes and I'd like to get array of int32 (from four 
bytes).

func convertCharToInt32(buffer string) []uint32 {
const SIZEOF_INT32 = 4

var hh = make([]byte, 2)
var cbuffer = make([]byte, len(buffer)/2)
var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)

for i := 0; i < 28; i++ {
hh[0] = buffer[i*2]
hh[1] = buffer[i*2+1]
if s, err := strconv.ParseUint(string(hh[:]), 16, 64); err == nil {
cbuffer[i] = byte(s)
}
}

for i := range hbuffer {
hbuffer[i] = uint32(Endian.Uint32(cbuffer[i*SIZEOF_INT32 : (i+1)*
SIZEOF_INT32]))
}

return hbuffer
}

buffer := "83f982d600c1caca7a6"
hbuffer := convertCharToInt32(buffer)



The code above seems to work, but perhaps there is a built-in function in 
Go that I've missed or there is a super cool hack that does that in one 
instruction?


-- 
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] Bulky (Payload) Structs in API

[dc0d]

It is a Go best practice to "accept interfaces, return concrete types". 
Which helps greatly in implementing different architectures/designs (like 
Clean Architecture or the like).

There are times that a package is used which returns fat structs (as the 
concrete type) - mostly POGO.

Problem:
Redefining some domain models for those payloads is cumbersome and 
sometimes impractical. At the same time using them directly, exposes other 
packages to that package that we want to abstract out it's functionality. 
Some unwelcome dependency.

Question:
Should we redefined all those data types in upper layers for using them? If 
no what is the solution?

-- 
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: Simple exec.Command() program

[Nilsocket]

package main

import (
"os"
"os/exec"
)

func main() {
cmd := exec.Command("ls")
null, _ := os.Open(os.DevNull)
defer null.Close()
cmd.Stdout = null
cmd.Run()
}

What you were trying to do is, redirecting output of ls to /dev/null.
`ls` is the name of the command.
`>` is redirection operator.
`/dev/null` is a device or a file to which you are redirecting your output.
In your case `ls` doesn't have any arguments so, we don't provide any.
Inorder to write to `/dev/null`, we need to open it first.
Then we were redirecting cmd.Stdout to null.
(i.e., instead of writing commands ouput stdout, it will write to /dev/null)
cmd.Run() //runs the command.

-- 
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] Simple exec.Command() program

[Dan Kortschak]

exec.Command does not invoke a shell, the `>' you use in bash is a
shell function (https://www.gnu.org/software/bash/manual/bash.html#Redi
rections). Note that the example for CombinedOutput invokes "sh" as the
command with "-c", "ls... (https://golang.org/pkg/os/exec/#example_Cmd_
CombinedOutput).

On Sun, 2017-11-12 at 19:35 -0800, buc...@gmail.com wrote:
> package main
> 
> import(
> "fmt"
> "os/exec"
> )
> 
> func main ()
> cmd := exec.Command("ls", ">", "/dev/null")
> output, err := cmd.CombinedOutput()
> if err != nil {
> fmt.Println(fmt.Sprint(err) + ": " + string(output))
> }
> 
> 
> When I run this go program I get:
> exit status: 1: ls: >:No such file or directory
> /dev/null
> 
> When I do this from the (bash/sh) shell command line:
> |# ls > /dev/null
> it works correctly (no errors and exit status: 0
> 
> 
> I've stared at this code for several days now and am getting
> nowhere.  Any 
> thoughts?



-- 
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] Simple exec.Command() program

[Caleb Spare]

ls is a bash builtin. You can probably invoke the ls command with /bin/ls.

But also, passing ">" as an argument to exec.Command doesn't do what
you want. > is a redirection for a shell and exec.Command is not a
shell.

I'm not sure what you're trying to accomplish, but here are two things
you could do that may be helpful:

(1) If you just do exec.Command("ls"), cmd.Stdout is automatically
discarded (like doing '> /dev/null' in your shell). See the docs for
exec.Cmd.Stdout:

   // If either is nil, Run connects the corresponding file descriptor
   // to the null device (os.DevNull).

(2) If you want to invoke a shell, you can do something like
exec.Command("/bin/bash", "-c", "ls > /dev/null"). (I'm not sure what
the point of that particular invocation would be, though.)

On Sun, Nov 12, 2017 at 7:35 PM,   wrote:
> package main
>
> import(
> "fmt"
> "os/exec"
> )
>
> func main ()
> cmd := exec.Command("ls", ">", "/dev/null")
> output, err := cmd.CombinedOutput()
> if err != nil {
> fmt.Println(fmt.Sprint(err) + ": " + string(output))
> }
>
>
> When I run this go program I get:
> exit status: 1: ls: >:No such file or directory
> /dev/null
>
> When I do this from the (bash/sh) shell command line:
> |# ls > /dev/null
> it works correctly (no errors and exit status: 0
>
>
> I've stared at this code for several days now and am getting nowhere.  Any
> thoughts?
>
> --
> 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] Simple exec.Command() program

[andrey mirtchovski]

">" is a special character interpreted by your shell.

On Sun, Nov 12, 2017 at 8:35 PM,   wrote:
> package main
>
> import(
> "fmt"
> "os/exec"
> )
>
> func main ()
> cmd := exec.Command("ls", ">", "/dev/null")
> output, err := cmd.CombinedOutput()
> if err != nil {
> fmt.Println(fmt.Sprint(err) + ": " + string(output))
> }
>
>
> When I run this go program I get:
> exit status: 1: ls: >:No such file or directory
> /dev/null
>
> When I do this from the (bash/sh) shell command line:
> |# ls > /dev/null
> it works correctly (no errors and exit status: 0
>
>
> I've stared at this code for several days now and am getting nowhere.  Any
> thoughts?
>
> --
> 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] Simple exec.Command() program

[bucarr]

package main

import(
"fmt"
"os/exec"
)

func main ()
cmd := exec.Command("ls", ">", "/dev/null")
output, err := cmd.CombinedOutput()
if err != nil {
fmt.Println(fmt.Sprint(err) + ": " + string(output))
}


When I run this go program I get:
exit status: 1: ls: >:No such file or directory
/dev/null

When I do this from the (bash/sh) shell command line:
|# ls > /dev/null
it works correctly (no errors and exit status: 0


I've stared at this code for several days now and am getting nowhere.  Any 
thoughts?

-- 
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: network programming about go

[2891132love]

I know your meaning.But I still can't get the result I want. 
this is the server program:
package main

import (
"fmt"
"net"
"os"
"strings"
)

func main() {

listener, err := net.Listen("tcp", "0.0.0.0:400")
checkError(err)
for i := 0; i < 10; i++ {
conn, err := listener.Accept()
if err != nil {
continue
}
handleClient(conn)
conn.Close()
}
}
func handleClient(conn net.Conn) {
var buf [512]byte
for {
n, err := conn.Read(buf[0:])
if err != nil {
return
}
rAddr := conn.RemoteAddr()
fmt.Println("receive from client:", rAddr.String(), string(buf[0:n]))
aa := string("nice to meet you")
_, err2 := conn.Write([]byte("welcome client!"))
if strings.Contains(string(buf[0:n]), aa) {
_, err2 = conn.Write([]byte("nice to meet you too"))
}
checkError(err2)
n, err = conn.Read(buf[0:])
if err != nil {
return
}
}
}
func checkError(err error) {
if err != nil {
fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
os.Exit(1)
}
}


this is the client program:
package main

import (
"fmt"
"net"
"os"
)

func main() {
var buf [512]byte
if len(os.Args) != 2 {
fmt.Fprintf(os.Stderr, "usage:%s host:port\n", os.Args[0])
}
_, err := net.ResolveTCPAddr("tcp", "127.0.0.1:400")
checkError(err)
conn, err := net.Dial("tcp", "127.0.0.1:400")
checkError(err)
rAddr := conn.RemoteAddr()
for {
n, err := conn.Write([]byte("hello server!"))
n, err = conn.Write([]byte(" nice to meet you"))
checkError(err)
n, err = conn.Read(buf[0:])
if err != nil {
return
}
fmt.Println("reply from server:", rAddr.String(), string(buf[0:n]))
n, err = conn.Read(buf[0:])
if err != nil {
return
}
conn.Close()
os.Exit(0)
}
}
func checkError(err error) {
if err != nil {
fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
os.Exit(1)
}
}


The program still don't print "nice to meet you too". Can you help me 
modifying and writing down for me??



在 2017年11月13日星期一 UTC+8上午2:32:47，Justin Israel写道：
>
>
>
> On Sun, Nov 12, 2017, 10:11 PM <28911...@gmail.com > wrote:
>
>> So how to modify my program correctly??I try to add read in different 
>> place but it still can't get the result I want.
>>
>
> Make sure your server is doing:
>  read, write, read, write
>
> And your client is doing:
>  write, read, write, read 
>
> But honestly it becomes hard to keep track and line up the two when you 
> are complicating the server handler loop. Why not just simplify the server 
> so that it always just reads, checks the value and writes something back, 
> then loops again? And the client would make sure to always write and then 
> read. 
> You have a conditional write on the server so that means if a client 
> doesn't say the correct phrase, it won't know if reading afterwards is 
> going to block forever. 
>
>
>> 在 2017年11月12日星期日 UTC+8上午5:05:49，Justin Israel写道：
>>>
>>>
>>>
>>> On Sun, Nov 12, 2017, 10:03 AM Justin Israel  
>>> wrote:
>>>
>>

 On Sat, Nov 11, 2017, 9:55 PM <28911...@gmail.com> wrote:

>  this is the server program： 
>
>> package main
>>
>> import (
>> "fmt"
>> "net"
>> "os"
>>
> "strings"
>> )
>>
>> func main() {
>>
>> listener, err := net.Listen("tcp", "0.0.0.0:400")
>>
> checkError(err)
>> for i := 0; i < 10; i++ {
>> conn, err := listener.Accept()
>> if err != nil {
>> continue
>> }
>> handleClient(conn)
>> conn.Close()
>> }
>> }
>> func handleClient(conn net.Conn) {
>> var buf [512]byte
>> for {
>> n, err := conn.Read(buf[0:])
>> if err != nil {
>> return
>> }
>> rAddr := conn.RemoteAddr()
>> fmt.Println("receive from client", rAddr.String(), string(buf[0:n]))
>>
> n, err2 := conn.Write([]byte("welcome client!"))
>>
> if err2 != nil {
>> return
>> }
>>
> aa := string("nice to meet you")
>> if strings.Contains(string(buf[0:n]), aa) {
>> n, err2 = conn.Write([]byte("nice to meet you too"))
>>
> if err2 != nil {
>> return
>> }
>> }
>> }
>> }
>> func checkError(err error) {
>> if err != nil {
>> fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
>> os.Exit(1)
>> }
>> }
>>
>
>>
> this is the client program:
>  package main
>
> import (
> "fmt"
> "net"
> "os"
> )
>
> func main() {
> var buf [512]byte
> if len(os.Args) != 2 {
> fmt.Fprintf(os.Stderr, "usage:%s host:port\n", os.Args[0])
> }
> _, err := net.ResolveTCPAddr("tcp", "127.0.0.1:400")
> checkError(err)
> conn, err := net.Dial("tcp", "127.0.0.1:400")
> checkError(err)
> rAddr := conn.RemoteAddr()
> n, err := conn.Write([]byte("hello server!"))
> checkError(err)
> n, err = conn.Write([]byte(" nice to meet you"))
> checkError(err)
> n, err = conn.Read(buf[0:])
> if err != nil {
> return
> }
> checkError(err)
> fmt.Println("reply from server", rAddr.String(), string(buf[0:n]))
> conn.Close()
> os.Exit(0)
> }

Re: [go-nuts] what's new with Go in the past year?

[Michael Jones]

In the rear view mirror:
https://golang.org/doc/go1.8
https://golang.org/doc/go1.9

through the windscreen:
go 1.10 approaching rapifdly

On Sun, Nov 12, 2017 at 2:40 PM, JM  wrote:

> Unfortunately, I have been out of Go land for about a year and want to get
> back into it.  What has added/changed over the past year?
>
> 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.
>



-- 
Michael T. Jones
michael.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.

[go-nuts] Why doesn't sync.Cond embed sync.Locker?

[T L]

.

-- 
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] A task runner / simpler Make alternative written in Go

[Andrey Nering]

https://github.com/go-task/task

I created this in the start of the year because Make is a mess on Windows 
and I dislike how complicated/obscure is the syntax.

It started as a very simple way of running a bunch commands, but then came 
the feature requests and contributions and it become a little more powerful 
than that.

It's also worth taking a look at the "Alternatives" section on the repo's 
README.

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

[roger peppe]

That's really interesting. I'd always assumed (without really thinking
more deeply about it) that amortised appending to a slice was
O(n*log(n)). Here's an empirical demonstration, FWIW:
https://play.golang.org/p/iLGiyexo1A

On 12 November 2017 at 17:56, Bakul Shah  wrote:
> On Sun, 12 Nov 2017 17:41:18 + Jesper Louis Andersen 
>  wrote:
>>
>> I haven't tried it out, but I think it will work because each new slot is
>> hit twice: it is filled with data, and it is copied away again. So when you
>> expand from n to 2*n, you may be able to arrange that you have exactly n
>> credits in the bank which can be used to pay for the copy. This might
>> require you to have 2 credits per slot though. If it works out, I'm pretty
>> sure this is the way to attack them problem.
>
> You're right. I was going by the observation that earlier
> values will be copied more times than later values but
> reallocs happen less and less frequently as can be seen
> in the following:
>
>   0 1 2 3 4 5 6 7
> 1 +
> 2 + +
> 4 + + + +
> 8 + + + + + + + +
>
> So 2n-1 writes.
>
> --
> 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] what's new with Go in the past year?

[JM]

Unfortunately, I have been out of Go land for about a year and want to get 
back into it.  What has added/changed over the past year?

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] Re: Can/should the SSA optimizer cross package boundaries?

[Dave Cheney]

In the gc compiler inlining occurs early on in the parse and import phase, it’s 
is independent of the ssa passes later. Gccgo may handle this differently. 

Can the gc compiler handle 10 functions in a package. I’m going to go with yes, 
but you’ll probably need an enormous amount of memory. The linker time will 
probably be extreme. 

-- 
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] Efficient to copy Hash?

[roger peppe]

Ah, thanks, I missed that. I think the individual packages should
mention it too.
I just created https://go-review.googlesource.com/c/go/+/77251
to address that.

On 12 November 2017 at 18:17, andrey mirtchovski  wrote:
>> Is there anything in the Go docs that indicates that?
>
> https://tip.golang.org/pkg/hash/#Hash
>
> (from https://go-review.googlesource.com/c/go/+/66710)

-- 
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] Can/should the SSA optimizer cross package boundaries?

[Petar Maymounkov]

Yep, eventually it will come down to experiments. Or I might end up
implementing an optimizer before the Go compiler. Thanks!

On Sun, Nov 12, 2017 at 4:01 PM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Sun, Nov 12, 2017 at 9:15 PM Petar Maymounkov  wrote:
>
>> This is an interesting suggestion. But it makes me wonder how this
>> compares against generating directly a bag of LLVM statically-typed
>> functions
>> and trying the intelligence of the LLVM SSA optimizer. Do you know if
>> this one resorts to global analysis?
>>
>>
> My major concern with LLVM is the same as the Go compiler. Does it do
> global optimizations well? A whole-program compiler, on the other hand, is
> forced by construction to be efficient at this problem: either there is no
> need for whole-program compilation, or you run out of memory, whichever
> comes first :)
>
> Another concern, if you are not doing tail-calls, but rather static calls
> that really do have a valid return, is that the inliner almost have to be
> polyvariant (it needs to determine inlining at each call site and not at a
> global enable/disable level). Some compilers simply disable inlining for
> any function which is called too often. Some times this is the correct
> *optimization* as it alleviates Instruction cache pressure. Other times,
> however, the inlining triggers vast simplifications if it is done, so the
> overhead in instruction expansion (and thus insn cache pressure) is worth
> the faster execution.
>
> OTOH: modern hardware is excellent at making funcalls fast. Hardware
> engineers tend to optimize for C-like programs and fix obvious mistakes
> compiler engineers make :)
>
> In short: Make some small experiments. Try to scale them up. Who is
> fastest on a carry-lookahead adder?
>

-- 
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] Can/should the SSA optimizer cross package boundaries?

[Jesper Louis Andersen]

On Sun, Nov 12, 2017 at 9:15 PM Petar Maymounkov  wrote:

> This is an interesting suggestion. But it makes me wonder how this
> compares against generating directly a bag of LLVM statically-typed
> functions
> and trying the intelligence of the LLVM SSA optimizer. Do you know if this
> one resorts to global analysis?
>
>
My major concern with LLVM is the same as the Go compiler. Does it do
global optimizations well? A whole-program compiler, on the other hand, is
forced by construction to be efficient at this problem: either there is no
need for whole-program compilation, or you run out of memory, whichever
comes first :)

Another concern, if you are not doing tail-calls, but rather static calls
that really do have a valid return, is that the inliner almost have to be
polyvariant (it needs to determine inlining at each call site and not at a
global enable/disable level). Some compilers simply disable inlining for
any function which is called too often. Some times this is the correct
*optimization* as it alleviates Instruction cache pressure. Other times,
however, the inlining triggers vast simplifications if it is done, so the
overhead in instruction expansion (and thus insn cache pressure) is worth
the faster execution.

OTOH: modern hardware is excellent at making funcalls fast. Hardware
engineers tend to optimize for C-like programs and fix obvious mistakes
compiler engineers make :)

In short: Make some small experiments. Try to scale them up. Who is fastest
on a carry-lookahead adder?

-- 
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] Garbage collection and multi-purpose pointers

[Jakob Borg]

As you guessed, you can’t do this. You’re not allowed to store a pointer as 
uintptr for any time span longer than a single expression, essentially. 
Instead, have a real pointer (or interface) field that is nil when not used.

//jb

On 12 Nov 2017, at 16:49, gitul...@gmail.com wrote:

Hi guys,

Go gurus, please, help me with the following problem.

I want to build a simple calculator for algebraic expression, aka computer 
algebra system. In this calculator every object has a `type Ex uintptr` 
(expression). An optimization I want to introduce is that atomic objects, like 
small numbers and symbols, are encoded by a single 64-bit integer, while more 
complicated objects, like polynomials are stored separately in larger pieces of 
data, e.g., arrays. To implement that I want 3 lower bits of my Ex to decode a 
type of every expression. So that if I see 000 then I know it is a pointer to a 
Container (assuming that every pointer is aligned to 8 bits), if 001 then it is 
a 61-bit integer, if 010 then it is a symbol, etc.

With such a notation, I am not sure if my Containers are safe of GC, because 
currently Ex is defined as uintptr, which is not a real pointer in Go, so GC 
may think that there are no references to a given Container. Can anyone comment 
on that and suggest some correct implementation of the idea above?

Best regards,
Oleksandr.

--
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] Can/should the SSA optimizer cross package boundaries?

[Petar Maymounkov]

On Sunday, November 12, 2017 at 12:33:11 PM UTC-5, Jesper Louis Andersen 
wrote:
>
> In addition to tail-call optimization, you also need a "contification" 
> pass, which removes intermediate functions in the SSA basic blocks where 
> possible. The observation is that if a function always returns to the same 
> point, then it can be turned into a continuation, which is exactly what an 
> SSA block is. Such a chain can then in certain situations be fused which in 
> turn makes it easier to expose loop information in the SSA graph.
>
> However, considering Go's balance of producing fast compile times, 
> extensive CF/DF analysis is probably out of bounds.
>
> My personal solution would be:
>
> 1. Get a machine with MASSIVE amounts of memory (initial bet: 128Gig and 
> up)
> 2. CodeGen to the MLton compiler (mlton.org 
> 
> )
> 3. Do a whole-program compilation. This might take several coffee breaks.
> 4. Enjoy the fastest simulator ever.
>
> However, for development you probably want something like SML/NJ because 
> your lead time could be measured in hours.
>
> This is an interesting suggestion. But it makes me wonder how this 
compares against generating directly a bag of LLVM statically-typed 
functions
and trying the intelligence of the LLVM SSA optimizer. Do you know if this 
one resorts to global analysis?

The SSA basically has to catch all cycles in the call graph. So this is a 
global optimization process, but real world call graphs have "narrow width"
which makes global analysis fast over them in practice.
 

> Another path is to cheat in the simulator. Replace circuitry with 
> hand-coded blocks (i.e., VLSI blocks) which doesn't simulate as much as 
> they run. I remember we did this at university some 15 years ago in order 
> to simulate circuits, because they would otherwise be too slow (mind you, 
> 2000 hardware). 
>
>
> On Sun, Nov 12, 2017 at 6:12 PM Bakul Shah  > wrote:
>
>> On Nov 11, 2017, at 5:33 AM, Petar Maymounkov > > wrote:
>> >
>> > Generally, such a chain of statically-typed invocations will fall 
>> within the domain of the SSA optimizer and will be rewritten 
>> (theoretically) optimally.
>> >
>> >
>> >
>> > The issue arises when the invocation chain is recursive, e.g.
>> >
>> >
>> >
>> >   func f1(x X) { ... f2(y) ... }
>> >   func f2(y Y) { ... f3(z) ... }
>> >   func f3(z Z) { ... f1(x) ... }
>>
>> Are you building a state-machine?
>>
>> Looks like what you really want is tail-call optimization
>> I don't think Go implements this. I tested this with two
>> mutually recursive functions and the program ran out of stack
>> space. IMHO you are better off using another language or a
>> different scheme.  For example, each function returns a
>> function and its args as a struct to a driver routine.
>>
>> func f1(x X)(Fn, Arg) { ... return f2, {y} ... }
>>
>> A driver (much like an interpreter main loop) based approch
>> will be somewhat slower.
>>
>> > (b) Is there any technical consideration prohibiting go packages from 
>> importing each other.
>>
>> When I needed this I defined a common package that declared a
>> table and common types.  Then each individual package added
>> its own entries to this table via their init() function. The
>> table can be a map or an array (in the latter case you'd have
>> to define a constant for each package globally, which makes it
>> less flexible).
>>
>> --
>> 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] Can/should the SSA optimizer cross package boundaries?

[Petar Maymounkov]

On Sunday, November 12, 2017 at 12:13:11 PM UTC-5, Bakul Shah wrote:
>
> On Nov 11, 2017, at 5:33 AM, Petar Maymounkov  > wrote: 
> > 
> > Generally, such a chain of statically-typed invocations will fall within 
> the domain of the SSA optimizer and will be rewritten (theoretically) 
> optimally. 
> > 
> > 
> > 
> > The issue arises when the invocation chain is recursive, e.g. 
> > 
> > 
> > 
> >   func f1(x X) { ... f2(y) ... } 
> >   func f2(y Y) { ... f3(z) ... } 
> >   func f3(z Z) { ... f1(x) ... } 
>
> Are you building a state-machine? 
>
> No. Each individual call to the top-level processor go function
is a stateless/context-free transformation of the input. 
State is represented as arguments to the function calls.
 

> Looks like what you really want is tail-call optimization 
> I don't think Go implements this. I tested this with two 
> mutually recursive functions and the program ran out of stack   
> space. 


This is an interesting observation. However, I don't require
tail recursion. The stack depth is controlled from our technology.
What I am interested in is optimization of chains and cycles of
static invocations. (This is different than tail recursion, I believe.)
 

> IMHO you are better off using another language or a 
> different scheme.  For example, each function returns a 
> function and its args as a struct to a driver routine. 
>
> func f1(x X)(Fn, Arg) { ... return f2, {y} ... } 
>
> A driver (much like an interpreter main loop) based approch 
> will be somewhat slower. 
>
>
This approach (or equivalently using an interface) escapes from the SSA 
semantic. (dynamic func pointers)
 

> > (b) Is there any technical consideration prohibiting go packages from 
> importing each other. 
>
> When I needed this I defined a common package that declared a 
> table and common types.  Then each individual package added 
> its own entries to this table via their init() function. The 
> table can be a map or an array (in the latter case you'd have 
> to define a constant for each package globally, which makes it   
> less flexible). 
>
> Again: dynamic function values or interfaces break the SSA call chains. So 
this does not resolve my problem
of exposing the chains to the compiler. It does resolve the mutual package 
import problem though, I agree.
 

-- 
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] Garbage collection and multi-purpose pointers

[gituliar]

Hi guys,

Go gurus, please, help me with the following problem.

I want to build a simple calculator for algebraic expression, aka computer 
algebra system. In this calculator every object has a `type Ex uintptr` 
(expression). An optimization I want to introduce is that atomic objects, 
like small numbers and symbols, are encoded by a single 64-bit integer, 
while more complicated objects, like polynomials are stored separately in 
larger pieces of data, e.g., arrays. To implement that I want 3 lower bits 
of my Ex to decode a type of every expression. So that if I see 000 then I 
know it is a pointer to a Container (assuming that every pointer is aligned 
to 8 bits), if 001 then it is a 61-bit integer, if 010 then it is a symbol, 
etc.

With such a notation, I am not sure if my Containers are safe of GC, 
because currently Ex is defined as uintptr, which is not a real pointer in 
Go, so GC may think that there are no references to a given Container. Can 
anyone comment on that and suggest some correct implementation of the 
idea above?

Best regards,
Oleksandr.

-- 
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: OpenCL or CUDA bindings

[heavymetalcookies]

I've been having trouble with bindings because I use windows with go and go 
compiler uses mingw.
This means that even on windows, I need the ".a" files rather than the 
".lib" files for the linker.
The problem is, the cuda-toolkit for windows does NOT give you the .a files.
The solution: Use the "syscall" package.
So far I've been able to get a device and context and query properties of 
the device and context.
Now working on creating bindings for clBuildProgram to get my first 
hello-world up and running.

If anyone is interested: Email me: HeavyMetalCookies ＡＴ Gmail ＤＯＴ-ＣＯＭ

On Thursday, June 14, 2012 at 6:41:30 PM UTC-7, Tharaneedharan Vilwanathan 
wrote:
>
> Hi,
>
> I have shown interest off and on in using OpenCL in Go. I am still waiting 
> for something that is usable and as easy as OpenGL in Go. In the recent 
> time, I also got ATI 6850 card for this. So I am very interested.
>
> Thanks
> dharani
>
> On Thu, Jun 14, 2012 at 5:02 PM, Nick Sarten  > wrote:
>
>> From a quick search of Github I found  
>> https://github.com/tones111/go-opencl. Bitbucket's seach is 
>> frustratingly unhelpful, but I would bet there's other Go/OpenCL projects 
>> on there other than just mine.
>>
>> I also made an attempt myself to create an interface between OpenCL and 
>> Go, but admittedly it wasn't very well organised, and hasn't been updated 
>> to work with the latest Go release. I also found the constantly changing 
>> format and installation method of AMD's APP SDK to be a pain when it comes 
>> to compiling anything for OpenCL (every version reorganises where it 
>> installs to, and it doesn't install the libraries/headers to a standard 
>> location like /usr/lib/).
>>
>> Hope this information helps,
>>Nick
>>
>>
>> On Wednesday, 13 July 2011 16:47:45 UTC+12, M. Yurko wrote:
>>>
>>> So, there are a number of older posts asking about OpenCL or CUDA 
>>> bindings. Has anyone made any significant progress? Does anyone have a 
>>> public repository with interface code? I'm consider go  for a project, 
>>> but I will need decent bindings to either OpenCL or CUDA. 
>>>
>>> Thanks for any help, 
>>> Mike Yurko
>>
>>
>

-- 
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: network programming about go

[Justin Israel]

On Sun, Nov 12, 2017, 10:11 PM <2891132l...@gmail.com> wrote:

> So how to modify my program correctly??I try to add read in different
> place but it still can't get the result I want.
>

Make sure your server is doing:
 read, write, read, write

And your client is doing:
 write, read, write, read

But honestly it becomes hard to keep track and line up the two when you are
complicating the server handler loop. Why not just simplify the server so
that it always just reads, checks the value and writes something back, then
loops again? And the client would make sure to always write and then read.
You have a conditional write on the server so that means if a client
doesn't say the correct phrase, it won't know if reading afterwards is
going to block forever.


> 在 2017年11月12日星期日 UTC+8上午5:05:49，Justin Israel写道：
>>
>>
>>
>> On Sun, Nov 12, 2017, 10:03 AM Justin Israel  wrote:
>>
>
>>>
>>> On Sat, Nov 11, 2017, 9:55 PM <28911...@gmail.com> wrote:
>>>
  this is the server program：

> package main
>
> import (
> "fmt"
> "net"
> "os"
>
 "strings"
> )
>
> func main() {
>
> listener, err := net.Listen("tcp", "0.0.0.0:400")
>
 checkError(err)
> for i := 0; i < 10; i++ {
> conn, err := listener.Accept()
> if err != nil {
> continue
> }
> handleClient(conn)
> conn.Close()
> }
> }
> func handleClient(conn net.Conn) {
> var buf [512]byte
> for {
> n, err := conn.Read(buf[0:])
> if err != nil {
> return
> }
> rAddr := conn.RemoteAddr()
> fmt.Println("receive from client", rAddr.String(), string(buf[0:n]))
>
 n, err2 := conn.Write([]byte("welcome client!"))
>
 if err2 != nil {
> return
> }
>
 aa := string("nice to meet you")
> if strings.Contains(string(buf[0:n]), aa) {
> n, err2 = conn.Write([]byte("nice to meet you too"))
>
 if err2 != nil {
> return
> }
> }
> }
> }
> func checkError(err error) {
> if err != nil {
> fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
> os.Exit(1)
> }
> }
>

>
 this is the client program:
  package main

 import (
 "fmt"
 "net"
 "os"
 )

 func main() {
 var buf [512]byte
 if len(os.Args) != 2 {
 fmt.Fprintf(os.Stderr, "usage:%s host:port\n", os.Args[0])
 }
 _, err := net.ResolveTCPAddr("tcp", "127.0.0.1:400")
 checkError(err)
 conn, err := net.Dial("tcp", "127.0.0.1:400")
 checkError(err)
 rAddr := conn.RemoteAddr()
 n, err := conn.Write([]byte("hello server!"))
 checkError(err)
 n, err = conn.Write([]byte(" nice to meet you"))
 checkError(err)
 n, err = conn.Read(buf[0:])
 if err != nil {
 return
 }
 checkError(err)
 fmt.Println("reply from server", rAddr.String(), string(buf[0:n]))
 conn.Close()
 os.Exit(0)
 }
 func checkError(err error) {
 if err != nil {
 fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
 os.Exit(1)
 }
 }


 Just a little change and I run it successfully.But I am doubt why it
 can't print "nice to meet you too"?？And how to solve it??

>>>
>>> Your server does the following on a new connection
>>>
>>> n, err := conn.Read(buf[0:])
>>> ...
>>> n, err2 := conn.Write([]byte("welcome client!"))
>>>
>>> Then your client is doing the following on the start of the connection
>>>
>>> n, err := conn.Write([]byte("hello server!"))
>>> ...
>>>
>>> n, err = conn.Write([]byte(" nice to meet you"))
>>>
>>> Both the client and server are blocking on writing and no one is doing
>>> any reading. Make sure your client does a read after elderly
>>>
>>
>> Thanks autocorrect. I have no problem with the elderly, but it has no
>> business here in this response.
>>
>> successful write, if you are choosing to do a request/reply pattern.
>>>
>> --
 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.

Re: [go-nuts] Efficient to copy Hash?

[andrey mirtchovski]

> Is there anything in the Go docs that indicates that?

https://tip.golang.org/pkg/hash/#Hash

(from https://go-review.googlesource.com/c/go/+/66710)

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

[Bakul Shah]

On Sun, 12 Nov 2017 17:41:18 + Jesper Louis Andersen 
 wrote:
> 
> I haven't tried it out, but I think it will work because each new slot is
> hit twice: it is filled with data, and it is copied away again. So when you
> expand from n to 2*n, you may be able to arrange that you have exactly n
> credits in the bank which can be used to pay for the copy. This might
> require you to have 2 credits per slot though. If it works out, I'm pretty
> sure this is the way to attack them problem.

You're right. I was going by the observation that earlier
values will be copied more times than later values but
reallocs happen less and less frequently as can be seen
in the following:

  0 1 2 3 4 5 6 7
1 +
2 + +
4 + + + +
8 + + + + + + + +

So 2n-1 writes.

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

[Jesper Louis Andersen]

I haven't tried it out, but I think it will work because each new slot is
hit twice: it is filled with data, and it is copied away again. So when you
expand from n to 2*n, you may be able to arrange that you have exactly n
credits in the bank which can be used to pay for the copy. This might
require you to have 2 credits per slot though. If it works out, I'm pretty
sure this is the way to attack them problem.

(Mind you, I haven't done it with rigor, so I might be wrong).

On Sun, Nov 12, 2017 at 5:01 PM Bakul Shah  wrote:

> On Sun, 12 Nov 2017 15:45:40 + Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
> >
> > To elaborate on Jan's point:
> >
> > If you extended capacity every time you called append, then you will have
> > to reallocate and copy data quite a lot. So a clever system pushes a
> little
> > bit more capacity in at the end to avoid such copies whenever an append
> > happens. It is a trade-off between space usage and processing time. From
> a
> > complexity-point of view, you are amortizing the capacity allocation over
> > several appends which yields better (amortized) complexity, turning
> O(n^2)
> > into O(n). A proof sketch:  associate a credit invariant (or potential)
> > with the excess capacity and note it never goes below 0.
>
> It will be worse than O(n), right? Old elements have to be
> likely copied the new bigger slice.
>
> > Typically, systems runs exponentially up to a point and then start using
> > something different, when the added power of two becomes too large.
> Either
> > you extend by a constant amount, or you extend by a fibonacci factor,
> > depending on runtime. In short: you start trading the other way once the
> > space usage grow too large. The optimization is there to handle the
> common
> > case: extend a slice with a small set of data in some loop.
>
> If you allocate 50% more space each time (or use fibonacci
> factor), allocation is still exponential in nature but wastes
> less space. For the loop case it is better to use loop count
> as an allocation hint.  [For expanding a map similar
> considerations but you have to expand it at 2/3 full capacity
> or so]
>

-- 
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] Can/should the SSA optimizer cross package boundaries?

[Jesper Louis Andersen]

In addition to tail-call optimization, you also need a "contification"
pass, which removes intermediate functions in the SSA basic blocks where
possible. The observation is that if a function always returns to the same
point, then it can be turned into a continuation, which is exactly what an
SSA block is. Such a chain can then in certain situations be fused which in
turn makes it easier to expose loop information in the SSA graph.

However, considering Go's balance of producing fast compile times,
extensive CF/DF analysis is probably out of bounds.

My personal solution would be:

1. Get a machine with MASSIVE amounts of memory (initial bet: 128Gig and up)
2. CodeGen to the MLton compiler (mlton.org)
3. Do a whole-program compilation. This might take several coffee breaks.
4. Enjoy the fastest simulator ever.

However, for development you probably want something like SML/NJ because
your lead time could be measured in hours.

Another path is to cheat in the simulator. Replace circuitry with
hand-coded blocks (i.e., VLSI blocks) which doesn't simulate as much as
they run. I remember we did this at university some 15 years ago in order
to simulate circuits, because they would otherwise be too slow (mind you,
2000 hardware).


On Sun, Nov 12, 2017 at 6:12 PM Bakul Shah  wrote:

> On Nov 11, 2017, at 5:33 AM, Petar Maymounkov  wrote:
> >
> > Generally, such a chain of statically-typed invocations will fall within
> the domain of the SSA optimizer and will be rewritten (theoretically)
> optimally.
> >
> >
> >
> > The issue arises when the invocation chain is recursive, e.g.
> >
> >
> >
> >   func f1(x X) { ... f2(y) ... }
> >   func f2(y Y) { ... f3(z) ... }
> >   func f3(z Z) { ... f1(x) ... }
>
> Are you building a state-machine?
>
> Looks like what you really want is tail-call optimization
> I don't think Go implements this. I tested this with two
> mutually recursive functions and the program ran out of stack
> space. IMHO you are better off using another language or a
> different scheme.  For example, each function returns a
> function and its args as a struct to a driver routine.
>
> func f1(x X)(Fn, Arg) { ... return f2, {y} ... }
>
> A driver (much like an interpreter main loop) based approch
> will be somewhat slower.
>
> > (b) Is there any technical consideration prohibiting go packages from
> importing each other.
>
> When I needed this I defined a common package that declared a
> table and common types.  Then each individual package added
> its own entries to this table via their init() function. The
> table can be a map or an array (in the latter case you'd have
> to define a constant for each package globally, which makes it
> less flexible).
>
> --
> 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] Can/should the SSA optimizer cross package boundaries?

[Bakul Shah]

On Nov 11, 2017, at 5:33 AM, Petar Maymounkov  wrote:
> 
> Generally, such a chain of statically-typed invocations will fall within the 
> domain of the SSA optimizer and will be rewritten (theoretically) optimally.
> 
> 
> 
> The issue arises when the invocation chain is recursive, e.g.
> 
> 
> 
>   func f1(x X) { ... f2(y) ... }
>   func f2(y Y) { ... f3(z) ... }
>   func f3(z Z) { ... f1(x) ... }

Are you building a state-machine?

Looks like what you really want is tail-call optimization
I don't think Go implements this. I tested this with two 
mutually recursive functions and the program ran out of stack   
space. IMHO you are better off using another language or a
different scheme.  For example, each function returns a
function and its args as a struct to a driver routine.

func f1(x X)(Fn, Arg) { ... return f2, {y} ... }

A driver (much like an interpreter main loop) based approch
will be somewhat slower.

> (b) Is there any technical consideration prohibiting go packages from 
> importing each other.

When I needed this I defined a common package that declared a 
table and common types.  Then each individual package added
its own entries to this table via their init() function. The
table can be a map or an array (in the latter case you'd have
to define a constant for each package globally, which makes it  
less flexible).

-- 
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: Can/should the SSA optimizer cross package boundaries?

[Petar Maymounkov]

And thanks!

On Sunday, November 12, 2017 at 11:40:51 AM UTC-5, Petar Maymounkov wrote:
>
> Inline:
>
> On Saturday, November 11, 2017 at 2:52:30 PM UTC-5, Dave Cheney wrote:
>>
>> Hi,
>>
>> Thanks for following up here.
>>
>>
>>
>> On Sunday, 12 November 2017 03:35:27 UTC+11, Petar Maymounkov wrote:
>>>
>>> Consider a chain of functions that call each other:
>>>
>>>
>>>   func f1(x X) { ... f2(y) ... }
>>>   func f2(y Y) { ... f3(z) ... }
>>>   and so on.
>>>
>>>
>>> Assume also that their arguments and return values are static Go types 
>>> (no interfaces).
>>>
>>>
>>> Generally, such a chain of statically-typed invocations will fall within 
>>> the domain of the SSA optimizer and will be rewritten (theoretically) 
>>> optimally.
>>>
>>
>> What do these functions do? Can how show some working examples? What do 
>> you mean by rewritten?
>>
>
>
> We have a system that code-generates a Go simulator for large 
> microprocessor circuits (> 1M gates and subsystems).
> Both hardware gates and subsystems are represented as Go functions with 
> statically-typed arguments and return values.
> Subsystems use/call each other (the recursion).
>
> As is, if we want to benefit from code optimization, we need to 
> code-generate the whole micro-processor in one package.
> This produces millions of functions per package. 
>  
>
>>  
>>
>>>
>>> The issue arises when the invocation chain is recursive, e.g.
>>>
>>>
>>>   func f1(x X) { ... f2(y) ... }
>>>   func f2(y Y) { ... f3(z) ... }
>>>   func f3(z Z) { ... f1(x) ... }
>>>
>>>
>>> and the user desires to implement f1 and f3 in different packages.
>>>
>>>
>>> This is not possible due to the design of the packaging system (as the 
>>> packages of f1 and f3 would have to import each other).
>>>
>>> Consequently, large amounts of recursive code cannot be spread across 
>>> packages.
>>>
>>>
>>> This situation has arisen in practice for us at a pretty large scale 
>>> (many/long recursive chains).
>>>
>>>
>>> I am wondering a couple of things:
>>>
>>> (a) Is there any technical consideration prohibiting large-scale SSA,
>>>
>>
>> There are lots of phases in the compiler, SSA occurs relatively late in 
>> the process, and the one that's probably more relevant here is inlining. 
>> Inlining does work across package boundaries, exported functions from one 
>> package aren't supposed to be treated differently from functions in 
>> another, although there could always be a bug. This is where a practical 
>> example of what problem you're facing would be really helpful.
>>
>
> SSA as an algorithmic technology applies to chains of static calls 
> regardless of packaging considerations. (Inlining is a special case of SSA.)
> Whether Go/LLVM implement/apply SSA to its full potential is something I 
> don't know. Hence the question.
>  
>
>>  
>>
>>> (b) Is there any technical consideration prohibiting go packages from 
>>> importing each other.
>>>
>>
>> The prohibition on import loops exists because it would significantly 
>> complicate the type checking of the compiler and the package import/export 
>> mechanism. it's also just not a good idea from a program design point of 
>> view as circular imports often denote high coupling which limit isolation 
>> and effective code reuse. 
>>
>
> I personally disagree with all considerations stated. But to keep my 
> question practical:
>
> I am simply wondering whether the Go compiler is designed to handle 
> packages with ~10M static functions,
> which invoke each other in cyclical ways. 
>  
>
>>  
>>
>>>
>>>
>>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Can/should the SSA optimizer cross package boundaries?

[Petar Maymounkov]

Inline:

On Saturday, November 11, 2017 at 2:52:30 PM UTC-5, Dave Cheney wrote:
>
> Hi,
>
> Thanks for following up here.
>
>
>
> On Sunday, 12 November 2017 03:35:27 UTC+11, Petar Maymounkov wrote:
>>
>> Consider a chain of functions that call each other:
>>
>>
>>   func f1(x X) { ... f2(y) ... }
>>   func f2(y Y) { ... f3(z) ... }
>>   and so on.
>>
>>
>> Assume also that their arguments and return values are static Go types 
>> (no interfaces).
>>
>>
>> Generally, such a chain of statically-typed invocations will fall within 
>> the domain of the SSA optimizer and will be rewritten (theoretically) 
>> optimally.
>>
>
> What do these functions do? Can how show some working examples? What do 
> you mean by rewritten?
>


We have a system that code-generates a Go simulator for large 
microprocessor circuits (> 1M gates and subsystems).
Both hardware gates and subsystems are represented as Go functions with 
statically-typed arguments and return values.
Subsystems use/call each other (the recursion).

As is, if we want to benefit from code optimization, we need to 
code-generate the whole micro-processor in one package.
This produces millions of functions per package. 
 

>  
>
>>
>> The issue arises when the invocation chain is recursive, e.g.
>>
>>
>>   func f1(x X) { ... f2(y) ... }
>>   func f2(y Y) { ... f3(z) ... }
>>   func f3(z Z) { ... f1(x) ... }
>>
>>
>> and the user desires to implement f1 and f3 in different packages.
>>
>>
>> This is not possible due to the design of the packaging system (as the 
>> packages of f1 and f3 would have to import each other).
>>
>> Consequently, large amounts of recursive code cannot be spread across 
>> packages.
>>
>>
>> This situation has arisen in practice for us at a pretty large scale 
>> (many/long recursive chains).
>>
>>
>> I am wondering a couple of things:
>>
>> (a) Is there any technical consideration prohibiting large-scale SSA,
>>
>
> There are lots of phases in the compiler, SSA occurs relatively late in 
> the process, and the one that's probably more relevant here is inlining. 
> Inlining does work across package boundaries, exported functions from one 
> package aren't supposed to be treated differently from functions in 
> another, although there could always be a bug. This is where a practical 
> example of what problem you're facing would be really helpful.
>

SSA as an algorithmic technology applies to chains of static calls 
regardless of packaging considerations. (Inlining is a special case of SSA.)
Whether Go/LLVM implement/apply SSA to its full potential is something I 
don't know. Hence the question.
 

>  
>
>> (b) Is there any technical consideration prohibiting go packages from 
>> importing each other.
>>
>
> The prohibition on import loops exists because it would significantly 
> complicate the type checking of the compiler and the package import/export 
> mechanism. it's also just not a good idea from a program design point of 
> view as circular imports often denote high coupling which limit isolation 
> and effective code reuse. 
>

I personally disagree with all considerations stated. But to keep my 
question practical:

I am simply wondering whether the Go compiler is designed to handle 
packages with ~10M static functions,
which invoke each other in cyclical ways. 
 

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

Re: [go-nuts] Golang capacity

[Bakul Shah]

On Sun, 12 Nov 2017 15:45:40 + Jesper Louis Andersen 
 wrote:
> 
> To elaborate on Jan's point:
> 
> If you extended capacity every time you called append, then you will have
> to reallocate and copy data quite a lot. So a clever system pushes a little
> bit more capacity in at the end to avoid such copies whenever an append
> happens. It is a trade-off between space usage and processing time. From a
> complexity-point of view, you are amortizing the capacity allocation over
> several appends which yields better (amortized) complexity, turning O(n^2)
> into O(n). A proof sketch:  associate a credit invariant (or potential)
> with the excess capacity and note it never goes below 0.

It will be worse than O(n), right? Old elements have to be
likely copied the new bigger slice.

> Typically, systems runs exponentially up to a point and then start using
> something different, when the added power of two becomes too large. Either
> you extend by a constant amount, or you extend by a fibonacci factor,
> depending on runtime. In short: you start trading the other way once the
> space usage grow too large. The optimization is there to handle the common
> case: extend a slice with a small set of data in some loop.

If you allocate 50% more space each time (or use fibonacci
factor), allocation is still exponential in nature but wastes
less space. For the loop case it is better to use loop count
as an allocation hint.  [For expanding a map similar
considerations but you have to expand it at 2/3 full capacity
or so]

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

[Jesper Louis Andersen]

To elaborate on Jan's point:

If you extended capacity every time you called append, then you will have
to reallocate and copy data quite a lot. So a clever system pushes a little
bit more capacity in at the end to avoid such copies whenever an append
happens. It is a trade-off between space usage and processing time. From a
complexity-point of view, you are amortizing the capacity allocation over
several appends which yields better (amortized) complexity, turning O(n^2)
into O(n). A proof sketch:  associate a credit invariant (or potential)
with the excess capacity and note it never goes below 0.

Typically, systems runs exponentially up to a point and then start using
something different, when the added power of two becomes too large. Either
you extend by a constant amount, or you extend by a fibonacci factor,
depending on runtime. In short: you start trading the other way once the
space usage grow too large. The optimization is there to handle the common
case: extend a slice with a small set of data in some loop.

On Sun, Nov 12, 2017 at 1:31 PM Lucio  wrote:

> One could lie about it, I suppose, but then you'd need to have an
> additional (hidden) value and that certainly does not seem worth it.
>
> Lucio.
>
> On Sunday, 12 November 2017 13:39:59 UTC+2, Jan Mercl wrote:
>
>> On Sun, Nov 12, 2017 at 12:00 PM  wrote:
>>
>> > The question is capacity.
>> > Why not : 0,1,2,3,4,5 as length ?
>>
>> Because O(n) is better than O(n^2).
>>
>> --
>>
>> -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.
>

-- 
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] Efficient to copy Hash?

[roger peppe]

On 12 November 2017 at 00:49,   wrote:
> Go 1.10 adds MarshalBinary and UnmarshalBinary to each of the hash.Hash
> implementations. You can use those to effectively copy the hash structure.

Wow, that's interesting (and potentially very useful)! Is there anything in the
Go docs that indicates that? It seems a pity that you have to dig
around in the source
to find that out.

-- 
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: How can I convert an byte array into int array?

[Jan Mercl]

On Sun, Nov 12, 2017 at 2:41 PM Christian LeMoussel 
wrote:

> byte array come from GPU card.
> Why this question?

See https://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html

-- 

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

Re: [go-nuts] Re: How can I convert an byte array into int array?

[Christian LeMoussel]

byte array come from GPU card.
Why this question?


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2017-11-12 12:36 GMT+01:00 Jan Mercl <0xj...@gmail.com>:

> On Sun, Nov 12, 2017 at 11:48 AM Christian LeMoussel 
> wrote:
>
> > To detect byte order for golang, I find this package GoEndian
> 
>
> Where does the byte array come from? Depending on that information you may
> find you don't need to know the byte order at all.
>
> --
>
> -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] Re: Zip file created by archive/zip can't be opened on Windows machine

[Klaus Post]

Hi!

Windows cannot extract password protected ZIP files without third party 
software. Sorry, but it a beef you need to take with Microsoft.

ref: 
https://social.technet.microsoft.com/Forums/en-US/981168e8-512d-4515-aada-8c94adf9187e/error-0x800041005-trying-to-unzip-a-password-protected-file?forum=win10itprogeneral


/Klaus


On Sunday, 12 November 2017 07:24:01 UTC+1, Jimmy 99 wrote:
>
> Dear Joe
> Thanks for your gracious offer!
> Please see the attached.
> I have added the go code, a shortened data file , the pdf and zipped pdf 
> output file
> Please let me know if you need anything else
> Regards
> Jimmy
>
>
> On Sunday, November 12, 2017 at 2:27:54 AM UTC+2, Joe Tsai wrote:
>>
>> If you can provide a minimal reproduction in Go code, then I can take a 
>> look at it. I fixed a number of zip issues for the upcoming Go1.10 release.
>>
>> JT
>>
>> On Friday, November 10, 2017 at 4:25:45 PM UTC-8, Donovan wrote:
>>>
>>> its not totally clear the exact issue you're dealing with - a minimal 
>>> example would go a long way.
>>>
>>> If I had to guess, I would say your zip entries are using characters not 
>>> supported by windows file systems. windows has more reserved characters 
>>> than you might expect, and even reserved filenames you have to avoid like 
>>> nul, ptr, etc. See 
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#naming_conventions
>>>
>>>
>>> On Friday, November 10, 2017 at 4:40:40 PM UTC-5, Jimmy 99 wrote:

 Is anyone familiar with the archive/zip package? 
 I am experiencing the following problem:
 When I create the Zip file on Ubuntu the file can be extracted no 
 problem.
 When I try and extract the zip file on a windows machine I get an error 
 saying the file cannot be created.

 I have tried compiling the go app on the windows machine, and same 
 problem - Windows file explorer cannot extract the zipped file.

 Interestingly enough, 7zip on the windows machine can extract the zip 
 file, but obviously I cannot ask the user community to install 7zip just 
 to 
 extract a zip file:(

 Any help or pointers will 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] Golang capacity

[Lucio]

One could lie about it, I suppose, but then you'd need to have an 
additional (hidden) value and that certainly does not seem worth it.

Lucio.

On Sunday, 12 November 2017 13:39:59 UTC+2, Jan Mercl wrote:
>
> On Sun, Nov 12, 2017 at 12:00 PM  wrote:
>
> > The question is capacity.
> > Why not : 0,1,2,3,4,5 as length ?
>
> Because O(n) is better than O(n^2).
>
> -- 
>
> -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.

Re: [go-nuts] Golang capacity

[Jan Mercl]

On Sun, Nov 12, 2017 at 12:00 PM  wrote:

> The question is capacity.
> Why not : 0,1,2,3,4,5 as length ?

Because O(n) is better than O(n^2).

-- 

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

Re: [go-nuts] Re: How can I convert an byte array into int array?

[Jan Mercl]

On Sun, Nov 12, 2017 at 11:48 AM Christian LeMoussel 
wrote:

> To detect byte order for golang, I find this package GoEndian


Where does the byte array come from? Depending on that information you may
find you don't need to know the byte order at all.

-- 

-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] ACCU 2018 Call for Session Proposals

[Russel Winder]

Last five days to submit proposals for #ACCUConf 2018. Goto

 https://cfp.conference.accu.org.

Gen Ashley, Hadi Hariri, Seb Rose, and Lisa Lippincott will be the keynote
speakers.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

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


signature.asc
Description: This is a digitally signed message part

[go-nuts] Re: How can I convert an byte array into int array?

[Christian LeMoussel]

To detect byte order for golang, I find this package* GoEndian 
* 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How can I convert an byte array into int array?

[Christian LeMoussel]

I find this solution :

const SIZEOF_INT32 = 4

var cbuffer = make([]byte, 28)
var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)

for i := range hbuffer {
hbuffer[i] = uint32(binary.LittleEndian.Uint32(cbuffer[i*SIZEOF_INT32 
: (i+1)*SIZEOF_INT32]))
}

By default, I specifying the endianness LittleEndian 


but I do not know how to findi the native byte order, 


-- 
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 can I convert an byte array into int array?

[Jan Mercl]

On Sun, Nov 12, 2017 at 10:37 AM Christian LeMoussel 
wrote:

> I have []byte, How can I convert this to []int?

What encoding is used for those integers?


-- 

-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] How can I convert an byte array into int array?

[Christian LeMoussel]

I have []byte, How can I convert this to []int?

var cbuffer = make([]byte, 28)
var hbuffer = [8]int{0, 0, 0, 0, 0, 0, 0}


-- 
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: network programming about go

[2891132love]

So how to modify my program correctly??I try to add read in different place 
but it still can't get the result I want.

在 2017年11月12日星期日 UTC+8上午5:05:49，Justin Israel写道：
>
>
>
> On Sun, Nov 12, 2017, 10:03 AM Justin Israel  > wrote:
>
>>
>>
>> On Sat, Nov 11, 2017, 9:55 PM <28911...@gmail.com > wrote:
>>
>>>  this is the server program： 
>>>
 package main

 import (
 "fmt"
 "net"
 "os"

>>> "strings"
 )

 func main() {

 listener, err := net.Listen("tcp", "0.0.0.0:400")

>>> checkError(err)
 for i := 0; i < 10; i++ {
 conn, err := listener.Accept()
 if err != nil {
 continue
 }
 handleClient(conn)
 conn.Close()
 }
 }
 func handleClient(conn net.Conn) {
 var buf [512]byte
 for {
 n, err := conn.Read(buf[0:])
 if err != nil {
 return
 }
 rAddr := conn.RemoteAddr()
 fmt.Println("receive from client", rAddr.String(), string(buf[0:n]))

>>> n, err2 := conn.Write([]byte("welcome client!"))

>>> if err2 != nil {
 return
 }

>>> aa := string("nice to meet you")
 if strings.Contains(string(buf[0:n]), aa) {
 n, err2 = conn.Write([]byte("nice to meet you too"))

>>> if err2 != nil {
 return
 }
 }
 }
 }
 func checkError(err error) {
 if err != nil {
 fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
 os.Exit(1)
 }
 }

>>>

>>> this is the client program:
>>>  package main
>>>
>>> import (
>>> "fmt"
>>> "net"
>>> "os"
>>> )
>>>
>>> func main() {
>>> var buf [512]byte
>>> if len(os.Args) != 2 {
>>> fmt.Fprintf(os.Stderr, "usage:%s host:port\n", os.Args[0])
>>> }
>>> _, err := net.ResolveTCPAddr("tcp", "127.0.0.1:400")
>>> checkError(err)
>>> conn, err := net.Dial("tcp", "127.0.0.1:400")
>>> checkError(err)
>>> rAddr := conn.RemoteAddr()
>>> n, err := conn.Write([]byte("hello server!"))
>>> checkError(err)
>>> n, err = conn.Write([]byte(" nice to meet you"))
>>> checkError(err)
>>> n, err = conn.Read(buf[0:])
>>> if err != nil {
>>> return
>>> }
>>> checkError(err)
>>> fmt.Println("reply from server", rAddr.String(), string(buf[0:n]))
>>> conn.Close()
>>> os.Exit(0)
>>> }
>>> func checkError(err error) {
>>> if err != nil {
>>> fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
>>> os.Exit(1)
>>> }
>>> }
>>>
>>>
>>> Just a little change and I run it successfully.But I am doubt why it 
>>> can't print "nice to meet you too"?？And how to solve it??
>>>
>>
>> Your server does the following on a new connection 
>>
>> n, err := conn.Read(buf[0:])
>> ... 
>> n, err2 := conn.Write([]byte("welcome client!"))
>>
>> Then your client is doing the following on the start of the connection 
>>
>> n, err := conn.Write([]byte("hello server!"))
>> ... 
>>
>> n, err = conn.Write([]byte(" nice to meet you"))
>>
>> Both the client and server are blocking on writing and no one is doing 
>> any reading. Make sure your client does a read after elderly 
>>
>
> Thanks autocorrect. I have no problem with the elderly, but it has no 
> business here in this response. 
>
> successful write, if you are choosing to do a request/reply pattern. 
>>
>>> -- 
>>> 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.