Re: [go-nuts] What happens when you call another method within a method set at the end of a method
You are correct, but I think an explicit stack is faster than most function
calls, but it depends on number of parameters needed, etc. but maybe not...:)
> On Apr 6, 2019, at 12:20 PM, Ian Denhardt wrote:
>
> Quoting Robert Engels (2019-04-06 08:00:02)
>
>> But yes, similar to how all recursive functions can be rewritten using
>> loops, which are more efficient, that is essentially what tail call
>> optimization does - just that the process it automatic.
>
> Not all recursive functions -- just tail calls. If you do stuff after
> the call then you need to save state, which is what the call stack is
> for.
>
> You *could* use an explicit stack instead of using the call stack, but
> whether this is more or less efficient is highly dependent on your
> language implementation and the stack data structure you're using; I see
> no reason to believe it would necessarily be more efficient in general.
>
> ---
>
> Adding tail calls also has a few gotchas depending on how it interacts
> with other parts of the language. For example, in the case of:
>
>
> ```
>func foo () {
>...
>defer x.Close()
>...
>return bar()
>}
> ```
>
> The call to `bar()` is *NOT* a tail call, because `x.Close()` must be
> called before the function actually returns. So this means they interact
> in non-obvious ways with other parts of the language. One of the things
> I like about Go is that most of the features interact in ways that are
> easy to predict.
>
> --
> 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] Some issues with UDP and Go
On Sun, 7 Apr 2019, 04:24 John Dreystadt, wrote:
> I wrote some sample code (at the end of this message) to see how UDP
> worked in the Go environment. And I wound up with some issues because
> things did not seem to work as I expected. I am running go1.11.2 on both a
> Windows box and a Ubuntu box.
>
> Issue 1, when I call WriteMsgUDP with both a regular buffer and an out of
> band buffer, I get back the length as I expected. But I never see any out
> of band data on the read side. Is this a known error or am I just missing
> something?
>
> Issue 2, when I send a UDP message longer than the buffer at the receiving
> end I get an error on the Windows side along with a bit set in flags. The
> Ubuntu side does not report an error but does set a bit (but a different
> one). Even more odd, the Windows side does not return the address of the
> sending machine when this error occurs. While having one report an error
> while not the other is not unreasonable, losing the address of the sending
> machine seems really bad unless it just is not there on Windows.
>
> Issue 3, the documentation for the flags return from ReadMsgUDP just says
> "the flags set on the message" which is pretty short and does not even
> indicate who set the flags. Maybe something like "the flags are set on the
> message by the network stack and are operating system dependent".
>
> I used two copies of the following program running to see the issues. To
> replicate, first run one without any flags and then run the second with
> -mode=wr .
>
> package main
>
> import (
> "errors"
> "flag"
> "fmt"
> "net"
> )
>
> var rfserver = flag.String("RFS", "127.0.0.1:6000", "Read First Server
> Name:Port Number")
> var wfserver = flag.String("WFS", "127.0.0.1:6001", "Write First Server
> Name:Port Number")
>
> type modeValue string
>
> func (mode *modeValue) String() string {
> return string(*mode)
> }
>
> func (mode *modeValue) Set(s string) error {
> switch s {
> case "rw":
> *mode = modeValue(s)
> return nil
> case "wr":
> *mode = modeValue(s)
> return nil
> default:
> return errors.New("Mode must be rw or wr")
> }
> }
>
> var mode modeValue
>
> func main() {
> mode = modeValue("rw")
> flag.Var(, "mode", "rw for read then write and wr for the reverse")
> flag.Parse()
> fmt.Println("Parameters", *rfserver, *wfserver, mode)
>
> rfudpaddr, err := net.ResolveUDPAddr("udp", *rfserver)
> if err != nil {
> panic(err)
> }
> wfudpaddr, err := net.ResolveUDPAddr("udp", *wfserver)
> if err != nil {
> panic(err)
> }
> var rudpaddr, wudpaddr *net.UDPAddr
> if mode == "rw" {
> rudpaddr, wudpaddr = rfudpaddr, wfudpaddr
> } else {
> wudpaddr, rudpaddr = rfudpaddr, wfudpaddr
> }
> pc, err := net.ListenUDP("udp", rudpaddr)
> if err != nil {
> panic(err)
> }
>
> if mode == "rw" {
> buffer := make([]byte, 5)
> oobbuffer := make([]byte, 5)
> n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer)
> fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
> n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
>
Just quick note, I think you should reset both buffer and oobbuffer on
subsequence read.
--
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] Some issues with UDP and Go
I wrote some sample code (at the end of this message) to see how UDP worked
in the Go environment. And I wound up with some issues because things did
not seem to work as I expected. I am running go1.11.2 on both a Windows box
and a Ubuntu box.
Issue 1, when I call WriteMsgUDP with both a regular buffer and an out of
band buffer, I get back the length as I expected. But I never see any out
of band data on the read side. Is this a known error or am I just missing
something?
Issue 2, when I send a UDP message longer than the buffer at the receiving
end I get an error on the Windows side along with a bit set in flags. The
Ubuntu side does not report an error but does set a bit (but a different
one). Even more odd, the Windows side does not return the address of the
sending machine when this error occurs. While having one report an error
while not the other is not unreasonable, losing the address of the sending
machine seems really bad unless it just is not there on Windows.
Issue 3, the documentation for the flags return from ReadMsgUDP just says
"the flags set on the message" which is pretty short and does not even
indicate who set the flags. Maybe something like "the flags are set on the
message by the network stack and are operating system dependent".
I used two copies of the following program running to see the issues. To
replicate, first run one without any flags and then run the second with
-mode=wr .
package main
import (
"errors"
"flag"
"fmt"
"net"
)
var rfserver = flag.String("RFS", "127.0.0.1:6000", "Read First Server
Name:Port Number")
var wfserver = flag.String("WFS", "127.0.0.1:6001", "Write First Server
Name:Port Number")
type modeValue string
func (mode *modeValue) String() string {
return string(*mode)
}
func (mode *modeValue) Set(s string) error {
switch s {
case "rw":
*mode = modeValue(s)
return nil
case "wr":
*mode = modeValue(s)
return nil
default:
return errors.New("Mode must be rw or wr")
}
}
var mode modeValue
func main() {
mode = modeValue("rw")
flag.Var(, "mode", "rw for read then write and wr for the reverse")
flag.Parse()
fmt.Println("Parameters", *rfserver, *wfserver, mode)
rfudpaddr, err := net.ResolveUDPAddr("udp", *rfserver)
if err != nil {
panic(err)
}
wfudpaddr, err := net.ResolveUDPAddr("udp", *wfserver)
if err != nil {
panic(err)
}
var rudpaddr, wudpaddr *net.UDPAddr
if mode == "rw" {
rudpaddr, wudpaddr = rfudpaddr, wfudpaddr
} else {
wudpaddr, rudpaddr = rfudpaddr, wfudpaddr
}
pc, err := net.ListenUDP("udp", rudpaddr)
if err != nil {
panic(err)
}
if mode == "rw" {
buffer := make([]byte, 5)
oobbuffer := make([]byte, 5)
n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
}
n, oobn, err := pc.WriteMsgUDP([]byte("1234"), []byte("1"), wudpaddr)
fmt.Println("n, oobn, err", n, oobn, err)
n, oobn, err = pc.WriteMsgUDP([]byte("12345"), nil, wudpaddr)
fmt.Println("n, err", n, oobn, err)
n, oobn, err = pc.WriteMsgUDP([]byte("123456"), nil, wudpaddr)
fmt.Println("n, err", n, oobn, err)
if mode == "wr" {
buffer := make([]byte, 5)
oobbuffer := make([]byte, 5)
n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
}
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Help wanted - ReferenceError: Go is not defined error
Solved! Thank you so much, can't believe I missed that. On Saturday, April 6, 2019 at 2:12:45 PM UTC-5, Agniva De Sarker wrote: > > Remove the async attribute from your script tag. > > On Saturday, 6 April 2019 23:38:17 UTC+5:30, jon.ki...@gmail.com wrote: >> >> I am new to Go programming. I stumbled across a project for using >> WeAssembly at https://github.com/golang/go/wiki/WebAssembly and decided >> to give it a try. So I'm running a test website on the Google App Engine, >> and the website is running on Go. I created all the objects according to >> the documentation provided on the page, but every time I run the website, I >> get this error in the console: Uncaught ReferenceError: Go is not defined >> >> I'm expecting to see "Hello World" in the console of the browser, but >> instead I get the above error. I'm sure it's pointing to the section >> "const go = new Go();", but I'm not sure why I'm getting this error. I'm >> running the latest version on Chrome on Win10. The test website is at >> https://test-rest-api-236401.appspot.com/ currently running the code >> giving me the error. I've tried simplifying it based on other pages also >> pointing to WASM documentation, but I keep getting the same error. I've >> done extensive searching and I've not seen anyone get this particular >> error. Please help. What am I missing? >> >> Here's how the source is laid out on the page: >> I'm currently running Go 1.12 >> >> /app.yaml --used to run the website >> /index.html -- used to run the website and init the wasm go code >> /main.go -- used to run the website >> /static/cmd/test.wasm -- my compiled wasm hello world go code >> /static/cmd/test.go -- I don't believe I actually need this here since I >> have the .wasm file there. I've tried it with and without it and still get >> the error. >> /static/scripts/wasm_exec.js -- version is the latest from the 1.12 >> source, but I've alternatively tried older versions from 1.11.x >> >> >> >> -- 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] What happens when you call another method within a method set at the end of a method
The opportunity to optimize yb tail-call elimination comes up in my coding
from time to time. It is generally trivial to do but sometimes less so, and
this example by Ian Denhardt is one I'd never considered and one that would
make doing the rewrite yourself impossible.
Generally though it is very simple. The basic recipe is this:
func name(arg1, arg2, argN) (result) {
code // first line of body
:
x = name(a,b,c) // optional recursive body call of function
:
if (j = y) {
return
}
result = name(d, e, f) // tail-call of function
return
}
becomes
func name(arg1, arg2, argN) (result) {
*for { // added forever loop head before first line*
code // first line of body
:
x = name(a,b,c) // optional recursive body call of function
if (j = y) {
* break // return changes to break*
}
* // result = name(d, e, f) // tail-call of function*
*arg1, arg2, argN = d, e, f // tail-call becomes simple argument
assignment*
*} // added forever loop close after last line*
return
}
On Sat, Apr 6, 2019 at 10:23 AM Ian Denhardt wrote:
> Quoting Robert Engels (2019-04-06 08:00:02)
>
> >But yes, similar to how all recursive functions can be rewritten using
> >loops, which are more efficient, that is essentially what tail call
> >optimization does - just that the process it automatic.
>
> Not all recursive functions -- just tail calls. If you do stuff after
> the call then you need to save state, which is what the call stack is
> for.
>
> You *could* use an explicit stack instead of using the call stack, but
> whether this is more or less efficient is highly dependent on your
> language implementation and the stack data structure you're using; I see
> no reason to believe it would necessarily be more efficient in general.
>
> ---
>
> Adding tail calls also has a few gotchas depending on how it interacts
> with other parts of the language. For example, in the case of:
>
>
> ```
> func foo () {
> ...
> defer x.Close()
> ...
> return bar()
> }
> ```
>
> The call to `bar()` is *NOT* a tail call, because `x.Close()` must be
> called before the function actually returns. So this means they interact
> in non-obvious ways with other parts of the language. One of the things
> I like about Go is that most of the features interact in ways that are
> easy to predict.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com *
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Help wanted - ReferenceError: Go is not defined error
Remove the async attribute from your script tag. On Saturday, 6 April 2019 23:38:17 UTC+5:30, jon.ki...@gmail.com wrote: > > I am new to Go programming. I stumbled across a project for using > WeAssembly at https://github.com/golang/go/wiki/WebAssembly and decided > to give it a try. So I'm running a test website on the Google App Engine, > and the website is running on Go. I created all the objects according to > the documentation provided on the page, but every time I run the website, I > get this error in the console: Uncaught ReferenceError: Go is not defined > > I'm expecting to see "Hello World" in the console of the browser, but > instead I get the above error. I'm sure it's pointing to the section > "const go = new Go();", but I'm not sure why I'm getting this error. I'm > running the latest version on Chrome on Win10. The test website is at > https://test-rest-api-236401.appspot.com/ currently running the code > giving me the error. I've tried simplifying it based on other pages also > pointing to WASM documentation, but I keep getting the same error. I've > done extensive searching and I've not seen anyone get this particular > error. Please help. What am I missing? > > Here's how the source is laid out on the page: > I'm currently running Go 1.12 > > /app.yaml --used to run the website > /index.html -- used to run the website and init the wasm go code > /main.go -- used to run the website > /static/cmd/test.wasm -- my compiled wasm hello world go code > /static/cmd/test.go -- I don't believe I actually need this here since I > have the .wasm file there. I've tried it with and without it and still get > the error. > /static/scripts/wasm_exec.js -- version is the latest from the 1.12 > source, but I've alternatively tried older versions from 1.11.x > > > > -- 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] Help wanted - ReferenceError: Go is not defined error
I am new to Go programming. I stumbled across a project for using WeAssembly at https://github.com/golang/go/wiki/WebAssembly and decided to give it a try. So I'm running a test website on the Google App Engine, and the website is running on Go. I created all the objects according to the documentation provided on the page, but every time I run the website, I get this error in the console: Uncaught ReferenceError: Go is not defined I'm expecting to see "Hello World" in the console of the browser, but instead I get the above error. I'm sure it's pointing to the section "const go = new Go();", but I'm not sure why I'm getting this error. I'm running the latest version on Chrome on Win10. The test website is at https://test-rest-api-236401.appspot.com/ currently running the code giving me the error. I've tried simplifying it based on other pages also pointing to WASM documentation, but I keep getting the same error. I've done extensive searching and I've not seen anyone get this particular error. Please help. What am I missing? Here's how the source is laid out on the page: I'm currently running Go 1.12 /app.yaml --used to run the website /index.html -- used to run the website and init the wasm go code /main.go -- used to run the website /static/cmd/test.wasm -- my compiled wasm hello world go code /static/cmd/test.go -- I don't believe I actually need this here since I have the .wasm file there. I've tried it with and without it and still get the error. /static/scripts/wasm_exec.js -- version is the latest from the 1.12 source, but I've alternatively tried older versions from 1.11.x -- 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] what does p stand for in io.Reader.Read argument
now it makes sense. thanks Santhosh On Sat, Apr 6, 2019 at 11:20 PM andrey mirtchovski wrote: > It may help to note that in the earliest references to the Read > interface in the history of the language it accepted a *[]byte, hence > 'p' may indeed stand for pointer. > > > https://github.com/golang/go/commit/7c9e2c2b6c2e0aa3090dbd5183809e1b2f53359b#diff-bf734f53a84f388bf39699d291b06b1d > -- 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] what does p stand for in io.Reader.Read argument
It may help to note that in the earliest references to the Read interface in the history of the language it accepted a *[]byte, hence 'p' may indeed stand for pointer. https://github.com/golang/go/commit/7c9e2c2b6c2e0aa3090dbd5183809e1b2f53359b#diff-bf734f53a84f388bf39699d291b06b1d -- 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] what does p stand for in io.Reader.Read argument
ok. got it my thinking is 'b' is obvious choice, then why invent new name 'p' ? On Sat, Apr 6, 2019 at 11:15 PM Jan Mercl <0xj...@gmail.com> wrote: > It can be whatever you like: passedBuf, payload, putBuffer, param, > pointer, ... > > It does not have to represent any word after all. Naming is hard, but in > the case of a single argument it does not matter that much, so it could be > just a case of author's C habits: void *p for buffers. > > On Sat, Apr 6, 2019, 19:34 Santhosh T wrote: > >> seems my question is not clear. >> my question is regarding naming of variables. >> i know that single name variables in go is idiomatic. >> >> r for reader >> w for writer >> etc... >> >> Read(p []byte) (n int, err error) >> >> i dont get why argument is named 'p' instead of 'b'. >> there should be some reasoning. >> I dont get why 'p' is chosen as argument name instead of 'b'. >> >> thanks >> Santhosh >> >> >> On Sat, Apr 6, 2019 at 9:54 PM Philip Chapman wrote: >> >>> p is the array of bytes that you want to fill with data read. The >>> method returns the count of the number of bytes read which may be any value >>> from zero to p's length. You must make multiple reads if the thing being >>> read from holds more data than your buffer array can hold. >>> >>> On Sat, Apr 6, 2019 at 9:16 AM Santhosh T >>> wrote: >>> Hi, method in io.Reader interface is: Read(p []byte) (n int, err error) what does `p` stands for ? thanks Santhosh -- 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. >>> >>> >>> -- >>> Philip A. Chapman >>> Java Software Development >>> Enterprise, Web, and Desktop >>> >> -- >> 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] what does p stand for in io.Reader.Read argument
seems my question is not clear. my question is regarding naming of variables. i know that single name variables in go is idiomatic. r for reader w for writer etc... Read(p []byte) (n int, err error) i dont get why argument is named 'p' instead of 'b'. there should be some reasoning. I dont get why 'p' is chosen as argument name instead of 'b'. thanks Santhosh On Sat, Apr 6, 2019 at 9:54 PM Philip Chapman wrote: > p is the array of bytes that you want to fill with data read. The method > returns the count of the number of bytes read which may be any value from > zero to p's length. You must make multiple reads if the thing being read > from holds more data than your buffer array can hold. > > On Sat, Apr 6, 2019 at 9:16 AM Santhosh T > wrote: > >> Hi, >> >> method in io.Reader interface is: >> Read(p []byte) (n int, err error) >> >> what does `p` stands for ? >> >> thanks >> Santhosh >> >> -- >> 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. >> > > > -- > Philip A. Chapman > Java Software Development > Enterprise, Web, and Desktop > -- 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] What happens when you call another method within a method set at the end of a method
Quoting Robert Engels (2019-04-06 08:00:02)
>But yes, similar to how all recursive functions can be rewritten using
>loops, which are more efficient, that is essentially what tail call
>optimization does - just that the process it automatic.
Not all recursive functions -- just tail calls. If you do stuff after
the call then you need to save state, which is what the call stack is
for.
You *could* use an explicit stack instead of using the call stack, but
whether this is more or less efficient is highly dependent on your
language implementation and the stack data structure you're using; I see
no reason to believe it would necessarily be more efficient in general.
---
Adding tail calls also has a few gotchas depending on how it interacts
with other parts of the language. For example, in the case of:
```
func foo () {
...
defer x.Close()
...
return bar()
}
```
The call to `bar()` is *NOT* a tail call, because `x.Close()` must be
called before the function actually returns. So this means they interact
in non-obvious ways with other parts of the language. One of the things
I like about Go is that most of the features interact in ways that are
easy to predict.
--
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] what does p stand for in io.Reader.Read argument
p is the array of bytes that you want to fill with data read. The method returns the count of the number of bytes read which may be any value from zero to p's length. You must make multiple reads if the thing being read from holds more data than your buffer array can hold. On Sat, Apr 6, 2019 at 9:16 AM Santhosh T wrote: > Hi, > > method in io.Reader interface is: > Read(p []byte) (n int, err error) > > what does `p` stands for ? > > thanks > Santhosh > > -- > 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. > -- Philip A. Chapman Java Software Development Enterprise, Web, and Desktop -- 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 does p stand for in io.Reader.Read argument
Hi, method in io.Reader interface is: Read(p []byte) (n int, err error) what does `p` stands for ? thanks Santhosh -- 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: Persistent memory support for Go
Out of curiosity what HW/OS is this being developed on? I need new HW and might as well get the same since it will make playing around with this smoother. On Wednesday, April 3, 2019 at 6:35:13 PM UTC-4, Jerrin Shaji George wrote: > > Hi, > > > > I am part of a small team at VMware working on projects related to > persistent > > memory (others in CC). We have recently been working on adding persistent > memory > > support to the Go programming language, and I wanted to spread the word > about > > couple of these projects. > > > > 1) Go-pmem-transaction > > The go-pmem-transaction project introduces a new programming model for > > developing applications in Go for persistent memory. It consists of two > packages > > - pmem and transaction. > > > > The pmem package provides methods to initialize persistent memory and an > > interface to set and retrieve objects in persistent memory. The transaction > > package provides undo and redo transaction logging APIs to support > > crash-consistent updates to persistent memory data. > > > > Project page - https://github.com/vmware/go-pmem-transaction > > > > 2) Go-pmem > > The Go-pmem project adds native persistent memory support to Go. > > Some of the features of the persistent memory support added to Go are: > > * Support for persistent memory allocations > > * Garbage collector now collects objects from persistent > heap and volatile > > heap > > * Runtime automatically swizzles pointers if the memory > mapping address > > changes on an application restart > > * The persistent memory heap is dynamically sized and > supports automatic > > heap growth depending on memory demand > > > > Project page - https://github.com/jerrinsg/go-pmem > > > > The project pages contains links to further documentation. We welcome the > > community to try out these projects and send any feedback our way! > > > > Also see the blog post at > https://blogs.vmware.com/opensource/2019/04/03/persistent-memory-with-go/ > > > > Thanks, > > Jerrin > -- 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: [golang-dev] does net.Conn.SetDeadLine makes syscall ?
In this case it looks like to be correct you must set the deadline
before reading from the network, and given reading from the network
can block, the cost of setting the deadline is small.
On Sat, 6 Apr 2019 at 21:47, Santhosh T wrote:
>
> Hi Dave,
>
> my mistake, bufr is backed by net.Conn
>
> bufr := bufio.newReader(netConn)
> for numEntries >0 {
> numEntries--
> netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> entry.decode(bufr)
> process(entry)
> }
>
> thanks
> Santhosh
>
> On Sat, Apr 6, 2019 at 4:09 PM Dave Cheney wrote:
>>
>> Thanks for the explanation. Two things
>>
>> 1. As this is a question about how to write a Go program, you should
>> move this thread to golang-nuts, golang-dev is only for the
>> development of Go.
>> 2. From the sample code you provided, there is no call to
>> netConn.Read, so setting the deadline is unnecessary. Please move the
>> discussion to golang-nuts and consider posting a larger piece of
>> sample code that shows the interaction with the network.
>>
>> On Sat, 6 Apr 2019 at 21:27, Santhosh T wrote:
>> >
>> > Hi Dave,
>> >
>> > I am implementing raft protocol, where leader sends bunch of entries over
>> > net.Conn to follower.
>> >
>> > leader can send large number of entries in single net.Conn.write.
>> > if follower does not hear from leader within configured heartbeatTimeout,
>> > it has to start election.
>> >
>> > currently follower implementation is something like this:
>> >
>> > for numEntries >0 {
>> > numEntries--
>> > netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
>> > entry.decode(bufr)
>> > process(entry)
>> > }
>> >
>> > if numEntries is say 1, i would be spending significant time in
>> > makeing syscalls for setReaddeadline
>> > btw, i have not done any benchmark yet. I asked the question our of
>> > curiosity.
>> >
>> > What i was planning to do to optimize it is:
>> > as i am reading entry from bufr, in most cases the entry might be
>> > already in the buffer. in such case
>> > i can avoid setting readDeadline. so set deadline, only when bufr calls
>> > read on underlaying reader.
>> >
>> > hope i am clear...
>> >
>> > thanks
>> > Santhosh
>> >
>> > On Sat, Apr 6, 2019 at 2:53 PM Dave Cheney wrote:
>> >>
>> >> Hi Santhosh,
>> >>
>> >> Calling SetDeadline does not _directly_ trigger a syscall, but it does
>> >> have several other observable side effects. What is the problem you
>> >> are facing that lead you to ask this question?
>> >>
>> >> Thanks
>> >>
>> >> Dave
>> >>
>> >> On Sat, 6 Apr 2019 at 20:20, Santhosh Kumar T
>> >> wrote:
>> >> >
>> >> > does net.Conn.SetDeadLine makes syscall ?
>> >> >
>> >> > thanks
>> >> > santhosh
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "golang-dev" group.
>> >> > To unsubscribe from this group and stop receiving emails from it, send
>> >> > an email to golang-dev+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] What happens when you call another method within a method set at the end of a method
But yes, similar to how all recursive functions can be rewritten using loops, which are more efficient, that is essentially what tail call optimization does - just that the process it automatic. > On Apr 6, 2019, at 5:21 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Sat, Apr 6, 2019 at 9:34 AM Louki Sumirniy > wrote: > > A tail call is in the first approximation just what it says: > > call foo > ret > > Nothing other is really that much special about 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. -- 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: [golang-dev] does net.Conn.SetDeadLine makes syscall ?
Hi Dave,
I agree with you
thanks
Santhosh
On Sat, Apr 6, 2019 at 4:22 PM Dave Cheney wrote:
> In this case it looks like to be correct you must set the deadline
> before reading from the network, and given reading from the network
> can block, the cost of setting the deadline is small.
>
> On Sat, 6 Apr 2019 at 21:47, Santhosh T wrote:
> >
> > Hi Dave,
> >
> > my mistake, bufr is backed by net.Conn
> >
> > bufr := bufio.newReader(netConn)
> > for numEntries >0 {
> > numEntries--
> > netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> > entry.decode(bufr)
> > process(entry)
> > }
> >
> > thanks
> > Santhosh
> >
> > On Sat, Apr 6, 2019 at 4:09 PM Dave Cheney wrote:
> >>
> >> Thanks for the explanation. Two things
> >>
> >> 1. As this is a question about how to write a Go program, you should
> >> move this thread to golang-nuts, golang-dev is only for the
> >> development of Go.
> >> 2. From the sample code you provided, there is no call to
> >> netConn.Read, so setting the deadline is unnecessary. Please move the
> >> discussion to golang-nuts and consider posting a larger piece of
> >> sample code that shows the interaction with the network.
> >>
> >> On Sat, 6 Apr 2019 at 21:27, Santhosh T
> wrote:
> >> >
> >> > Hi Dave,
> >> >
> >> > I am implementing raft protocol, where leader sends bunch of entries
> over net.Conn to follower.
> >> >
> >> > leader can send large number of entries in single net.Conn.write.
> >> > if follower does not hear from leader within configured
> heartbeatTimeout, it has to start election.
> >> >
> >> > currently follower implementation is something like this:
> >> >
> >> > for numEntries >0 {
> >> > numEntries--
> >> > netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> >> > entry.decode(bufr)
> >> > process(entry)
> >> > }
> >> >
> >> > if numEntries is say 1, i would be spending significant time in
> makeing syscalls for setReaddeadline
> >> > btw, i have not done any benchmark yet. I asked the question our of
> curiosity.
> >> >
> >> > What i was planning to do to optimize it is:
> >> > as i am reading entry from bufr, in most cases the entry might
> be already in the buffer. in such case
> >> > i can avoid setting readDeadline. so set deadline, only when bufr
> calls read on underlaying reader.
> >> >
> >> > hope i am clear...
> >> >
> >> > thanks
> >> > Santhosh
> >> >
> >> > On Sat, Apr 6, 2019 at 2:53 PM Dave Cheney wrote:
> >> >>
> >> >> Hi Santhosh,
> >> >>
> >> >> Calling SetDeadline does not _directly_ trigger a syscall, but it
> does
> >> >> have several other observable side effects. What is the problem you
> >> >> are facing that lead you to ask this question?
> >> >>
> >> >> Thanks
> >> >>
> >> >> Dave
> >> >>
> >> >> On Sat, 6 Apr 2019 at 20:20, Santhosh Kumar T <
> santhosh.tek...@gmail.com> wrote:
> >> >> >
> >> >> > does net.Conn.SetDeadLine makes syscall ?
> >> >> >
> >> >> > thanks
> >> >> > santhosh
> >> >> >
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google
> Groups "golang-dev" group.
> >> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to golang-dev+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: [golang-dev] does net.Conn.SetDeadLine makes syscall ?
Hi Dave,
my mistake, bufr is backed by net.Conn
bufr := bufio.newReader(netConn)
for numEntries >0 {
numEntries--
netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
entry.decode(bufr)
process(entry)
}
thanks
Santhosh
On Sat, Apr 6, 2019 at 4:09 PM Dave Cheney wrote:
> Thanks for the explanation. Two things
>
> 1. As this is a question about how to write a Go program, you should
> move this thread to golang-nuts, golang-dev is only for the
> development of Go.
> 2. From the sample code you provided, there is no call to
> netConn.Read, so setting the deadline is unnecessary. Please move the
> discussion to golang-nuts and consider posting a larger piece of
> sample code that shows the interaction with the network.
>
> On Sat, 6 Apr 2019 at 21:27, Santhosh T wrote:
> >
> > Hi Dave,
> >
> > I am implementing raft protocol, where leader sends bunch of entries
> over net.Conn to follower.
> >
> > leader can send large number of entries in single net.Conn.write.
> > if follower does not hear from leader within configured
> heartbeatTimeout, it has to start election.
> >
> > currently follower implementation is something like this:
> >
> > for numEntries >0 {
> > numEntries--
> > netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> > entry.decode(bufr)
> > process(entry)
> > }
> >
> > if numEntries is say 1, i would be spending significant time in
> makeing syscalls for setReaddeadline
> > btw, i have not done any benchmark yet. I asked the question our of
> curiosity.
> >
> > What i was planning to do to optimize it is:
> > as i am reading entry from bufr, in most cases the entry might be
> already in the buffer. in such case
> > i can avoid setting readDeadline. so set deadline, only when bufr calls
> read on underlaying reader.
> >
> > hope i am clear...
> >
> > thanks
> > Santhosh
> >
> > On Sat, Apr 6, 2019 at 2:53 PM Dave Cheney wrote:
> >>
> >> Hi Santhosh,
> >>
> >> Calling SetDeadline does not _directly_ trigger a syscall, but it does
> >> have several other observable side effects. What is the problem you
> >> are facing that lead you to ask this question?
> >>
> >> Thanks
> >>
> >> Dave
> >>
> >> On Sat, 6 Apr 2019 at 20:20, Santhosh Kumar T <
> santhosh.tek...@gmail.com> wrote:
> >> >
> >> > does net.Conn.SetDeadLine makes syscall ?
> >> >
> >> > thanks
> >> > santhosh
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups "golang-dev" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to golang-dev+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] What happens when you call another method within a method set at the end of a method
On Sat, Apr 6, 2019 at 9:34 AM Louki Sumirniy < louki.sumirniy.stal...@gmail.com> wrote: A tail call is in the first approximation just what it says: call foo ret Nothing other is really that much special about 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.
[go-nuts] What happens when you call another method within a method set at the end of a method
I have become quite interested in tail-call optimisation and more distantly in code that assembles trees of closures all tied to the same scope through parameters to reduce stack management for complex but not always predictable input. As I have learned from some reading, tail call optimisation is a fairly frequently requested feature that is not planned to go into Go 2, so I am just wondering what actually happens when you end functions with a call, especially that shares the same receiver as the calling function. I figure it changes the procedure a little compared to calling before, since the compiler knows no more variables in the caller are going to be changed except the return value. I also figure that it reduces the rate at which the stack expands since the first function does not need to save its state to resume. Does or can it have a performance impact? What I'm thinking is that it works like a trampoline, in that it means the stack doesn't grow so even if you change nothing else when using a recursive algorithm, moving it to tail calls - does it reduce the stack growth rate, and if so, how can this be exploited to reduce overhead? -- 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.
