[go-nuts] Re: Go predicts the end of the universe

[Gabriel Aszalos]

Seems time is on our side.

On Friday, 10 November 2017 09:38:37 UTC+1, Hal wrote:
>
> Go predicts the end of the time, i.e. the end of the universe 😂
>
> https://play.golang.org/p/THHvbdo_IS
>
> package main
>
>
> import (
>  "fmt"
>  "math"
>  "time"
> )
>
>
> func main() {
>  endOfTheTime := time.Unix(math.MaxInt64,81394542089).UTC()
>  fmt.Println(endOfTheTime.String())
> }
>
> Hal
>
>

-- 
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: Go predicts the end of the universe

[andrey mirtchovski]

>
> Seems time is on our side.
>

yes it is.

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

[2891132love]

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

-- 
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: Go predicts the end of the universe

[Michael Banzon]

Remember to flush your buffers!

--
Michael Banzon
https://michaelbanzon.com/

> Den 11. nov. 2017 kl. 09.32 skrev andrey mirtchovski :
> 

> Seems time is on our side.

yes it is.
-- 
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: gRPC golang server and client testing

[Simon Ritchie]

Not everybody in the Go community favours the use of mocking tools, so many 
published solutions don't have any tests of that kind.   Maybe you should 
write the tests yourself.

I use pegomock for mocking.  (I tried gomock but I found issues that were 
not fixed.  I also found a couple of issues with pegomock too, but the 
author fixed them.)

Pegomock tool is a fairly conventional mocking tool.  Given an interface, 
it produces a concrete class that implements the interface and can be told 
at runtime how to respond to a method call.  So anything you test has to be 
defined by an interface.  Of course, if you only have a concrete class, Go 
allows you to create your own interface that matches it, so that's not a 
big problem.

If you want some worked examples of pegomock, see my 
scaffolder https://github.com/goblimey/scaffolder.  It generates a web 
server with pegomock tests for some of the components.

Regards

Simon  

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

Re: [go-nuts] How to Upload a file using angular4 for browsing and api created in golang?

[Marcus Franke]

>
> I am working on an application in which I need to upload a file using
> Golang and Angular 4.Suppose I have an input type file and an upload button
> on the screen. When I browse a file from my system and clicks upload
> button.Now following are my queries regarding file upload:
>
> 1. How will angular process the file at front end?
>

Why should your angular frontend process the file at all?

2. If it processes the file then what it will return to the rest api as
> data.
>

The easiest way, I guess, will be a simple form based upload. The file will
be uploaded to the endpoint you specify. Thats a POST action.

The handler responsible for the upload can copy the request body in a file
object and you are done.

```
r *http.Request
file, handler, err := r.FormFile("fileupload")
f, err := os.OpenFile(somePath+"/"+handler.Filename, os.O_WRONLY|os.O_CREATE
, 0644)
_, err = io.Copy(f, file)
```

4. Can file be uploaded via angular script and it will give download url to
> rest api?
>

Its upon your code what you write into the response. Of course could you
return the file location where you did save the file.

5. The uploaded file should not be executable.
>

Look at the flags I set in os.Open(). There you control if a file will be
executable or not. But that is only relevant for the server you save your
files.

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

[Petar Maymounkov]

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.


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,

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



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?

[Dave Cheney]

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?
 

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

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

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

[Justin Israel]

On Sat, Nov 11, 2017, 9:55 PM <2891132l...@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 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: network programming about go

[Justin Israel]

On Sun, Nov 12, 2017, 10:03 AM Justin Israel  wrote:

>
>
> On Sat, Nov 11, 2017, 9:55 PM <2891132l...@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+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: warning: "std" matched no packages (hello world works)

[peterGo]

If you had removed all remnants of gccgo and followed these installation 
instructions

Getting Started
https://golang.org/doc/install

I would have expected to see something like this:

$ go version
go version go1.9.2 linux/amd64
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/me/gocode"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build872524400=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
$

and /usr/local/go/bin in your PATH.

However, you have this entry

GOTOOLDIR="/usr/lib/gccgo/tool"

which is clearly a remnant of gccgo.

There may be gccgo remnants elsewhere, like your PATH.

Peter

On Friday, November 10, 2017 at 11:29:21 PM UTC-5, Rorschach Rev wrote:
>
> Platform is x86_64 kernel 4.4.0 Ubuntu flavored Linux Mint. I had the 
> golang package installed but it was too old to run newer code. Removed 
> package and proceeded with install.
> Downloaded static version of go 1.9.2 (104247844 bytes) from website, 
> moved folder into /usr/local/go. gopath is set. and I followed the hello 
> world example in the docs/install.html.  
>
> go list std
> warning: "std" matched no packages
>
> go get github.com/dvyukov/go-fuzz/go-fuzz
> gocode/src/github.com/dvyukov/go-fuzz/go-fuzz/hub.go:35:5: error: 
> reference to undefined identifier ‘atomic.Value’
> (plus many more errors)
>
> go get github.com/dvyukov/go-fuzz/go-fuzz-build
> package go/constant: unrecognized import path "go/constant"
> package go/types: unrecognized import path "go/types"
>
> go env
> GOARCH="amd64"
> GOBIN=""
> GOCHAR="6"
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/me/gocode"
> GORACE=""
> GOROOT="/usr"
> GOTOOLDIR="/usr/lib/gccgo/tool"
> TERM="dumb"
> CC="gcc"
> GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"
> CXX="g++"
> CGO_ENABLED="1"
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+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

[thebrokentoaster]

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

[thebrokentoaster]

Go 1.10 adds MarshalBinary and UnmarshalBinary to each of the hash.Hash 
implementations. You can use those to effectively copy the hash structure.

However, I doubt you would get a performance benefit for a string only 64 
bytes long.

JT

On Wednesday, November 8, 2017 at 9:47:33 AM UTC-8, Christian LeMoussel 
wrote:
>
> I found why.. hash.Hash  interface 
> does not have a .Copy,
>
>

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