Re: [go-nuts] Re: Go : Philosophy

[Henry]

I think pretty much of Python philosophy is transferrable to Go as the two 
languages seem to share a similar outlook.

-- 
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: Question regarding compiler internals

['Keith Randall' via golang-nuts]

On Wednesday, September 20, 2017 at 7:51:28 AM UTC-7, Jacob McCollum wrote:
>
> All,
>
> This is my first time posting to the golang-nuts mailing list, but I've 
> hit a wall and I'm not sure where else to reach out for some assistance.
>
> I'm knee-deep in a research implementation of parameterized types for Go. 
> It started out as an experiment, but I really enjoyed working on it and it 
> has turned into a toy project for me.
>
> To clarify, this is not (necessarily) something I intend to submit as a 
> PR, nor do I intend to release it as a fork or in any way use it to 
> fracture the community. This is simply a project I undertook to develop a 
> better understanding of the technical challenges facing the team when it 
> comes to implementation of generic types, and to potentially bring some new 
> ideas to that discussion (eventually). I don't have future plans for this 
> beyond learning at this point.
>
> That being said, I'm to a point where I've got a formalized set of rules, 
> the syntax is parsing correctly this information is stored in the parse 
> tree. The next step is type checking & concrete type generation/replacement.
>
> I am considering 2 possible implementations for this phase. One possible 
> plan is to augment the existing type checking logic with new functionality. 
> Another is to re-implement a lightweight type checker that gathers only the 
> information it needs to modify the parse tree, before dropping that down to 
> the cmd/compile/internal/gc package's processing logic. Right now, I don't 
> feel that I understand the existing type-checking flow well enough to make 
> that call.
>
>
I'd lean toward modifying the existing typechecker.  It's hard to tell from 
a 2-sentence description of your algorithm, but generally I suspect generic 
type checking and regular type checking to be tightly coupled.  How would 
you do one if the other hadn't been done yet?
 

> Would it be a reasonable request to ask for a high-level overview of the 
> process that gc uses to get from syntax's parse tree to the node DAG that 
> is type-checked? I can fill in a lot of the blanks on my own once I have a 
> better high-level understanding, but right now I'm struggling to determine 
> the exact relationship between processing the syntax tree with *noder, 
> typecheck, the order in which those two processes should occur, etc. I've 
> seen the different phases as presented in gc's Main method, but trying to 
> understand the high level intent via the code feels like I'm failing to see 
> the forest through the trees. A little cognitive glue would go a long way 
> in helping me coalesce my understanding.
>
>
I don't think we have any docs about this at the moment, the comments in 
Main are as good as it gets.  But to your question, almost nothing happens 
between parsing and typechecking.  The input to the type checker is exactly 
the output of the parser.

Please, please, add comments to Main as you figure things out.  It will 
help the next person who comes along.
 

> Thanks,
>
> Jacob R. McCollum
>
>
>
>
>
>

-- 
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] Go jobs in Canada

[Totoro W]

Hi there,

I'm now software developer in China and looking for a job in Canada. And I 
have worked with go for at least 5 years.
Is there any opportunity there (i could relocate there if possible). I'd 
like to hear about them. 

My github: https://github.com/tw4452852
My blog: https://totorow.xyz

Thanks a lot.

-- 
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] Proposal: Just Use GitHub

[Nate Finch]

https://github.com/golang/go/issues/21956

Wherein I suggest that not using GitHub for PRs and Reviews for the Go 
Project itself is hurting the language and the community.

-- 
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: glog log rotate not working correctly

[alexguo123]

glog library does not delete log files. It only creates new log files.

Btw, not sure if you actually modified that "line", but note that you only 
need to modify the variable.

Here's a rough example

import (
  "github.com/golang/glog"
)

func main() {
  glog.MaxFileSize = 250MB
}

On Wednesday, September 28, 2016 at 9:51:10 PM UTC-7, Ramkumar Gowrishankar 
wrote:
>
> Hi,
>
> I am using the glog to log for my golang program and I have changed the 
> package to limit maximum file size to 250MB by changing this line (
> https://github.com/golang/glog/blob/master/glog_file.go#L34).
>
> The log rotate seems to be working as intended and the file size gets 
> limited to 250MB but somehow there seems to be a bug in file close/open and 
> the log directory keeps filling up until it runs out of space. df -h 
> command shows that the used space is close to 100% but if I look using du 
> -h or ls and add up the file sizes it is not close to 100%. My platform is 
> CentOS7.
>
> Thanks,
>
> Ramkumar
>

-- 
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] Go on ARM 32bit and 64bit resources and groups

[Mandolyte]

Slightly different question... would this ARM approach work on a Samsung 
Chromebook Plus which uses OP1 ARM, with Crouton installed?

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

[go-nuts] Golang, Google App Engine, Windows 10

[Rob Shelby]

Hi all.

I'm having to make 2 transitions in my coding life. 

>From PHP to Go, which I'm happy about.

>From Linux desktop to Windows 10, which I'm not as happy about.

I love using Google's App Engine so I don't need to worry about servers 
etc. (Not Compute Engine)

Anyways, any steps, advice, etc to easily code in Go and deploy to GAE.

So far, I've figured that installing and running Go in Bash On Linux, but 
coding in an IDE in Windows, is the easiest. Then deploy from Bash On 
Windows.

Does anyone else have a better way?

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.

Re: [go-nuts] Monads for Go Programmers

[Walter Schulze]

Thank you so much.  That is great to hear :)

On Wed, 20 Sep 2017 at 22:30 Nyah Check  wrote:

> Nice article, I love it
>
> On Wed, Sep 20, 2017 at 1:32 PM, Walter Schulze 
> wrote:
>
>> https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/
>>
>> --
>> 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.
>>
>
>
>
> --
> "The heaviest penalty for declining to rule is to be ruled by someone
> inferior to yourself." --*Plato*
>

-- 
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] Monads for Go Programmers

[Nyah Check]

Nice article, I love it

On Wed, Sep 20, 2017 at 1:32 PM, Walter Schulze 
wrote:

> https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/
>
> --
> 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.
>



-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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] Monads for Go Programmers

[Walter Schulze]

https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/

-- 
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: Why bytes Buffer's ReadFrom method blocked when read from a UDP connection?

[James Bardin]

You shouldn't use bufio around a UDP connection. The reads are a fixed 
size, so there's no "batching" of reads that could happen, and you can't do 
a partial read of a UDP packet, so you're going to lose data as soon if the 
buffer attempts to top off with a read smaller than the next packet size. 

-- 
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] Question regarding compiler internals

[Jacob McCollum]

All,

This is my first time posting to the golang-nuts mailing list, but I've hit 
a wall and I'm not sure where else to reach out for some assistance.

I'm knee-deep in a research implementation of parameterized types for Go. 
It started out as an experiment, but I really enjoyed working on it and it 
has turned into a toy project for me.

To clarify, this is not (necessarily) something I intend to submit as a PR, 
nor do I intend to release it as a fork or in any way use it to fracture 
the community. This is simply a project I undertook to develop a better 
understanding of the technical challenges facing the team when it comes to 
implementation of generic types, and to potentially bring some new ideas to 
that discussion (eventually). I don't have future plans for this beyond 
learning at this point.

That being said, I'm to a point where I've got a formalized set of rules, 
the syntax is parsing correctly this information is stored in the parse 
tree. The next step is type checking & concrete type generation/replacement.

I am considering 2 possible implementations for this phase. One possible 
plan is to augment the existing type checking logic with new functionality. 
Another is to re-implement a lightweight type checker that gathers only the 
information it needs to modify the parse tree, before dropping that down to 
the cmd/compile/internal/gc package's processing logic. Right now, I don't 
feel that I understand the existing type-checking flow well enough to make 
that call.

Would it be a reasonable request to ask for a high-level overview of the 
process that gc uses to get from syntax's parse tree to the node DAG that 
is type-checked? I can fill in a lot of the blanks on my own once I have a 
better high-level understanding, but right now I'm struggling to determine 
the exact relationship between processing the syntax tree with *noder, 
typecheck, the order in which those two processes should occur, etc. I've 
seen the different phases as presented in gc's Main method, but trying to 
understand the high level intent via the code feels like I'm failing to see 
the forest through the trees. A little cognitive glue would go a long way 
in helping me coalesce my understanding.

Thanks,

Jacob R. McCollum





-- 
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] Implementing a custom TCP client

[Tamás Gulácsi]

I don't see anything obviously wrong, but using length-prefixed messages would 
simplify reading (no need to buffer) and wouldn't complicate writing.
My 2¢

-- 
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 bytes Buffer's ReadFrom method blocked when read from a UDP connection?

[Ricky Zhang]

UDP Server's code:

package main
import (
   "fmt"
   "net"
)
func main() {
   listener, err := net.ListenUDP("udp", {IP: 
net.ParseIP("127.0.0.1"), Port: 9981})
   if err != nil {
  fmt.Println(err)
  return
   }
   fmt.Printf("Local: <%s> \n", listener.LocalAddr().String())
   data := make([]byte, 1024)
   for {
  n, remoteAddr, err := listener.ReadFromUDP(data)
  if err != nil {
 fmt.Printf("error during read: %s", err)
  }
  fmt.Printf("<%s> %s\n", remoteAddr, data[:n])
  _, err = listener.WriteToUDP(data[0:n], remoteAddr)
  _, err = listener.WriteToUDP([]byte("world"), remoteAddr)
  if err != nil {
 fmt.Printf(err.Error())
  }
   }
}


UDP Client's Code:

package main
import (
   "fmt"
   "net"
   "bytes"
)
func main() {
   ip := net.ParseIP("127.0.0.1")
   srcAddr := {IP: net.IPv4zero, Port: 0}
   dstAddr := {IP: ip, Port: 9981}
   conn, err := net.DialUDP("udp", srcAddr, dstAddr)
   if err != nil {
  fmt.Println(err)
   }
   defer conn.Close()
   conn.Write([]byte("hello"))
   buff := bytes.NewBuffer(make([]byte, 3))
   fmt.Println(buff.ReadFrom(conn))
   fmt.Printf("<%s>\n", conn.RemoteAddr())   
}


Why the UDP client blocked using BuffReadFrom method when read from a UDP 
connection? 
However, using bufio's Reader(the code is below) is ok. 
I am a newbie, feel really confused, so can anybody give me some 
explanation, thanks!
My running environment is macOS Sierra and go version is go1.8.3 
darwin/amd64

package main
import (
   "fmt"
   "net"
   "bufio"
)
func main() {
   ip := net.ParseIP("127.0.0.1")
   srcAddr := {IP: net.IPv4zero, Port: 0}
   dstAddr := {IP: ip, Port: 9981}
   conn, err := net.DialUDP("udp", srcAddr, dstAddr)
   if err != nil {
  fmt.Println(err)
   }
   defer conn.Close()
   conn.Write([]byte("hello"))
   reader := bufio.NewReader(conn)
   rawbuff := make([]byte, 64)
   fmt.Println(reader.Read(rawbuff))
   fmt.Println(string(rawbuff))
   fmt.Printf("<%s>\n", conn.RemoteAddr())
   
}


 

-- 
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] Implementing a custom TCP client

[newbgopher]

Hi all!
I already asked this on reddit 
,
 
but I figured might as well ask it here.
Im trying to implement a custom TCP client. This protocol allows request 
from both the client and the server


Scenario 1:

Client ---REQUEST--> Server

Client <-RESPONSE--- Server


Scenario 2:

Client <--REQUEST Server

Client ---RESPONSE--> Server


Here's 

 simplified 
form of the client. This approach uses a goroutine to read the *net.Conn, 
*parse 
the string to determine the type, 
and send the string to the appropriate channel for that type. Typical usage 
of this client is as follows

c := client.New("localhost:")
c.Connect()
c.Send("message")

On small workloads, it works fine, however calling Send around 100 times a 
second times out. 
I can confirm using wireshark that the server indeed sent a response, 
however it seems like the readLoop wasn't able read it and send it to the 
channel.
I would like to ask if this approach is reasonable. Id like to ask anyone 
out there have implemented a client golang library thats able to both send 
and receive requests from  the server. Basically a bidirectional tcp 
client. I know *nats *is similar to this, however their protocol parsing is 
too complex for me. Any new approach/advise will be nice. 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: Go on ARM 32bit and 64bit resources and groups

[Norbert Fuhs]

Thanks for all the answers and replys it helped me a lot the thing that 
confuses me is that there are not many resources for using Go on Raspberry 
Pi although many Gophers seem to use Go on a Pi for pet projects... I will 
set up my own repo with resources and links I find it a bit hard for Go 
beginners using Go on Raspberry Pi 

Am Sonntag, 17. September 2017 02:45:24 UTC+2 schrieb Dave Cheney:
>
> I think it's fine to ask questions about 32bit implementations of Go here. 
> For Go specific things like interfacing with hardware https://gobot.io/ 
> or https://periph.io/ may be better choices.
>
> On Sunday, 17 September 2017 06:21:45 UTC+10, Norbert Fuhs wrote:
>>
>> Hi,
>>
>> since I'm running Go on an Rapberry Pi 3 I would like to know if there 
>> are more official resources / tutorials or even groups?
>>
>> Beside doing searching for arm on Github 
>> https://github.com/golang/go/search?utf8=%E2%9C%93=arm=
>>
>> Is the only offical resource I found is Go s wiki page: 
>> https://github.com/golang/go/wiki/GoArm 
>> ? 
>>
>> I'm not sure how up to this wiki is I still doesn't mention it it 
>> benchmarks the Raspberry Pi 3 which I use and it seems not mauch people are 
>> using Go on an Pi.
>>
>> I know its just a pet project by me but I wonder if there is a better 
>> place if I have specific go question I get now like
>> GC issuses with 32 Bit ARM ??
>>
>>
>>
>>
>>

-- 
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] Does golang support SystemTap well?

[Aram Hăvărneanu]

I would not use systemtap, its design is fundamentally flawed and
requires special kernels. Linux supports now eBPF in mainline, which
is a superior technical solution.

Note that NO TRACER can support function return tracing in Go
(including DTrace), for the reasons outlined above. In order to
support function return we would have to change the Go calling
convention.

-- 
Aram Hăvărneanu

-- 
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] Forcing multiple HTTP/2 connections to a single server?

[Steven Hartland]

We're looking to upgrade one of our services to enable TLS however as 
soon as we do that the services also going to switch to HTTP/2 which is 
good apart from for this service which requires multiple TCP connections 
to eliminate BDP issues when performing bulk downloads; think parallel 
downloads reassembled on the fly to a single stream.


Now with HTTP/2 I believe its going to try and multiplex all requests 
over the same TCP connection and hence the throughput for the download 
requests is going to plummet compared to HTTP/1 due to BDP.


We could disable HTTP/2 by setting Server.TLSNextProto to nil, but we 
would like to use HTTP/2 for all the other requests.


Prior to the following commit it looked like this was possible by 
setting MaxConcurrentStreams to 1 for the download requests, however 
after it the RoundTrip will just block until a scream is available, 
preventing any concurrency.

https://github.com/golang/net/commit/1c05540f6879653db88113bc4a2b70aec4bd491f

The issue which triggered this changes was originally raised by Brad here:
https://github.com/golang/go/issues/13774

I suspect this use case was never identified prior to making this change?

So the question is how do we force multiple HTTP/2 connections to a 
single server for a specific endpoint?


    Regards
    Steve

--
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: Why http header letter case changes?

[Volker Dobler]

The header keys are canonicalized.

Unfortunately the standard canonical form of "ETag" is "Etag".
The ETag header is the only HTTP header key which is not in
the standard canonical form. Fortunately any compliant implementation
will ignore capitalization of the header keys so this should never be
a problem. It is just a small inconsistency.

V.

On Wednesday, 20 September 2017 04:59:36 UTC+2, dc0d wrote:
>
> It is true that http header keys are case-nonsensitive. Then why the 
> letter case gets changed inside "*http.Response"?
>
> An "ETag" header added and in the response we had "Etag" (the letter T 
> converted to lowercase).
>
> I've encountered this when doing some testing and this behavior was 
> unpleasant and unexpected.
>

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