[go-nuts] Re: Golang and the mobile framework

[husam alkdary]

which one react-native or Flutter ? and how ?

On Thursday, March 26, 2020 at 8:56:14 AM UTC+2, husam alkdary wrote:
>
> It's possible to use Golang with to design mobile app with react-native or 
> Flutter ? 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f0ac780b-a13c-4816-8102-7c56b9e30940%40googlegroups.com.

[go-nuts] Re: Golang and the mobile framework

[husam alkdary]

which one react-native or Flutter ? and how ?

On Thursday, March 26, 2020 at 9:46:40 AM UTC+2, Brian Candler wrote:
>
> Yes.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1aa3427d-6dd1-4902-bcc8-8575e18a7d6e%40googlegroups.com.

[go-nuts] Re: Print something while read message from server with websocket

[洪嘉鴻]

Thanks for your replying.
I'm sorry that I didn't remind that my Client code does not compile.
I've tried your example  with 
SetReadDeadline 
().
It seems like what I want to do.
However, I want to edit "spinner" message instead of "busy" message, as the 
followings:
Server  code is the same.
Here is the new Client  code.

I only want to show "Wait..." message before reading "Hello!" message.
Nevertheless, the results would be a little mess.
I have no idea what's wrong with the codes. 

Thank you very much!
  Max

Jake Montgomery於 2020年3月27日星期五 UTC+8上午1時12分07秒寫道：
>
> Your Client  code does not 
> compile. As a courtesy to those trying to help, it is always good to test 
> your code before posting it. A working example, without your "busy" 
> messages would be something like: https://play.golang.org/p/cvgwd8GDobc . 
> The Read() method documentation 
>  says "Read 
> implements the io.Reader interface." So I suggest you *carefully *read 
> the io.Reader documentation , because 
> it requires very specific handling to be done correctly. 
>
> Also, I did note that golang.org/x/net/websocket documentation 
>  states that: "This package 
> currently lacks some features found in alternative and more actively 
> maintained WebSocket packages." So you may want to consider using one of 
> those. 
>
> I have not actually used golang.org/x/net 
> /websocket myself, but there is a 
> SetReadDeadline 
> () 
> function. Because I have not used the package before, there may be some 
> hidden pitfalls that I am missing, but this code seems to do what you want, 
> using SetReadDeadline 
> (): 
> https://play.golang.org/p/ISUR7c_Mtqb
>
> Good luck
>
> On Wednesday, March 25, 2020 at 8:56:57 PM UTC-4, 洪嘉鴻 wrote:
>>
>> I'm sorry.
>> The followings are the complete codes of server and client:
>> Server 
>> Client 
>>
>> Thank you very much!
>>   Max
>>
>> Jake Montgomery於 2020年3月25日星期三 UTC+8下午9時28分37秒寫道：
>>>
>>> You do not provide enough information to give a really good answer. 
>>> There are a number of ways to achieve this, but they depend on the details. 
>>> A more complete example would help. 
>>>
>>> What is the type of `ws`? If it is something on which you can set a read 
>>> timeout, then one way would be to set a timeout, and loop.
>>>
>>> On Wednesday, March 25, 2020 at 4:10:19 AM UTC-4, 洪嘉鴻 wrote:

 Hello everyone:
   The version of the golang which I am using is 1.12.9 with Win10.
   I want to print something while the client is waiting for server.
   The following are the partial code of server and client.

   Server:
   time.Sleep(time.Second * 100)
   ws.Write([]byte("Hello!"))
   
   Client:
   while(!ws.Read(msg)){
   fmt.Println("Please wait because server is busy.")  
   }

   Can anyone suggest how to fix the code?

   Any help is appreciated.
   Thank you very much!
   Max

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d3652a2e-13e0-4374-a098-e0c092f77b62%40googlegroups.com.

[go-nuts] Re: Print something while read message from server with websocket

[洪嘉鴻]

I'm sorry that I didn't remind that my Client code does not compile.
I've tried your example  with 
SetReadDeadline 
().
It seems like what I want to do.

Thank you very much!
  Max

Jake Montgomery於 2020年3月27日星期五 UTC+8上午1時12分07秒寫道：
>
> Your Client  code does not 
> compile. As a courtesy to those trying to help, it is always good to test 
> your code before posting it. A working example, without your "busy" 
> messages would be something like: https://play.golang.org/p/cvgwd8GDobc . 
> The Read() method documentation 
>  says "Read 
> implements the io.Reader interface." So I suggest you *carefully *read 
> the io.Reader documentation , because 
> it requires very specific handling to be done correctly. 
>
> Also, I did note that golang.org/x/net/websocket documentation 
>  states that: "This package 
> currently lacks some features found in alternative and more actively 
> maintained WebSocket packages." So you may want to consider using one of 
> those. 
>
> I have not actually used golang.org/x/net 
> /websocket myself, but there is a 
> SetReadDeadline 
> () 
> function. Because I have not used the package before, there may be some 
> hidden pitfalls that I am missing, but this code seems to do what you want, 
> using SetReadDeadline 
> (): 
> https://play.golang.org/p/ISUR7c_Mtqb
>
> Good luck
>
> On Wednesday, March 25, 2020 at 8:56:57 PM UTC-4, 洪嘉鴻 wrote:
>>
>> I'm sorry.
>> The followings are the complete codes of server and client:
>> Server 
>> Client 
>>
>> Thank you very much!
>>   Max
>>
>> Jake Montgomery於 2020年3月25日星期三 UTC+8下午9時28分37秒寫道：
>>>
>>> You do not provide enough information to give a really good answer. 
>>> There are a number of ways to achieve this, but they depend on the details. 
>>> A more complete example would help. 
>>>
>>> What is the type of `ws`? If it is something on which you can set a read 
>>> timeout, then one way would be to set a timeout, and loop.
>>>
>>> On Wednesday, March 25, 2020 at 4:10:19 AM UTC-4, 洪嘉鴻 wrote:

 Hello everyone:
   The version of the golang which I am using is 1.12.9 with Win10.
   I want to print something while the client is waiting for server.
   The following are the partial code of server and client.

   Server:
   time.Sleep(time.Second * 100)
   ws.Write([]byte("Hello!"))
   
   Client:
   while(!ws.Read(msg)){
   fmt.Println("Please wait because server is busy.")  
   }

   Can anyone suggest how to fix the code?

   Any help is appreciated.
   Thank you very much!
   Max

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c283ad5f-52e9-4666-8bd4-c205300ed21f%40googlegroups.com.

Re: [go-nuts] Re: Slice reuse + GC

['Keith Randall' via golang-nuts]

It's common practice to *write* to elements between the length and capacity 
of a slice.  Usually, you use append to do that.
It's bad practice to *read* elements between the length and capacity. Which 
you can't do with a simple indexing op, of course. You would have to 
reslice larger and then index.
In that sense, it would be nice to have the GC not trace elements between 
len and cap. They should be dead if you never read them, only write them. 
It's hard to do in the GC, it requires a language change, etc. But it would 
be nice.


On Thursday, March 26, 2020 at 12:29:04 PM UTC-7 leszek...@gmail.com wrote:

>
>
>
>> I disagree. I do that all the time. It's also how `append` was 
>> implemented before it existed as a predeclared function. It's also, FWIW, 
>> used in bytes.Buffer . I 
>> agree that unless your API is very clear about it, you shouldn't really 
>> access a slice past the length for one of your arguments. But there *are* 
>> APIs where it's clear that's happening (e.g. anything having "append" in 
>> it's doc-string) and there are use-cases where you control the slice for 
>> its entire lifetime and where it can make code more readable.
>>
>
>  I didn't even know that append wasn't there, but since we have it isn't 
> it meant to be used in the first place?
> Of course if we check the capacity, expanding past len is safe, like 
> s[:cap(s)]. I would check the capacity only in case when I really don't 
> want to end with a new slice buffer as a result of appending more than the 
> available space.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/aeb6767a-0807-462a-a2d5-0b066299a5d0%40googlegroups.com.

Re: [go-nuts] Go course

[Amnon Baron Cohen]

The println and print builtin may be removed from the language in the 
future.

On Thursday, 26 March 2020 19:18:50 UTC, David Riley wrote:
>
> And since I'm a fan of lifelong learning, I have to admit to not having 
> known that println() was a builtin until this post. Thanks! That does 
> un-complicate it somewhat. 
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1c6c8ed3-1b2c-4d51-a34d-09d2056fc18c%40googlegroups.com.

Re: [go-nuts] Re: Slice reuse + GC

[Leszek Kubik]

> I disagree. I do that all the time. It's also how `append` was implemented 
> before it existed as a predeclared function. It's also, FWIW, used in 
> bytes.Buffer . I agree that 
> unless your API is very clear about it, you shouldn't really access a slice 
> past the length for one of your arguments. But there *are* APIs where it's 
> clear that's happening (e.g. anything having "append" in it's doc-string) 
> and there are use-cases where you control the slice for its entire lifetime 
> and where it can make code more readable.
>

 I didn't even know that append wasn't there, but since we have it isn't it 
meant to be used in the first place?
Of course if we check the capacity, expanding past len is safe, like 
s[:cap(s)]. I would check the capacity only in case when I really don't 
want to end with a new slice buffer as a result of appending more than the 
available space.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/26396fdd-543d-4af0-be95-154d36a505c1%40googlegroups.com.

Re: [go-nuts] Go course

[David Riley]

And since I'm a fan of lifelong learning, I have to admit to not having known 
that println() was a builtin until this post. Thanks! That does un-complicate 
it somewhat.

> On Mar 26, 2020, at 10:34 AM, Sebastien Binet  wrote:
> 
> On Thu, Mar 26, 2020 at 3:29 PM David Riley  wrote:
> [...]
> But:
> 
> - You still need to import something just to print a line, and it is 
> confusingly (to the novice) named "fmt"
> - You still need to declare a function called main(), and most brand-new 
> programmers don't understand functions yet, so this becomes a "wave the dead 
> chicken at it just right" thing
> - Semicolons are still there under the surface, but they're inserted by the 
> lexer, and when they get inserted can be really mysterious and trip a lot of 
> people up
> 
> In contrast, in Python (3, in this case), it is:
> 
> print("Hello, world!")
> 
> to be fair, in Go, "hello world" can be reduced to:
> 
> package main
> func main() {
> println("hello world")
> }
> 
> that's usually how I start my Go-based lecture.
> (and then, 2-3 lectures/hands-on sessions after that, I do introduce 'import 
> "foo"')
> 
> -s

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D503437D-FA3F-4388-973D-4DF4BC1F73A8%40gmail.com.

Re: [go-nuts] Re: Slice reuse + GC

['Axel Wagner' via golang-nuts]

On Thu, Mar 26, 2020 at 6:57 PM Leszek Kubik  wrote:

> AFAIK it is allowed to re-slice past the len but it's rather not the way
> slices should be ever used.
>

I disagree. I do that all the time. It's also how `append` was implemented
before it existed as a predeclared function. It's also, FWIW, used in
bytes.Buffer . I agree that
unless your API is very clear about it, you shouldn't really access a slice
past the length for one of your arguments. But there *are* APIs where it's
clear that's happening (e.g. anything having "append" in it's doc-string)
and there are use-cases where you control the slice for its entire lifetime
and where it can make code more readable.

You missed the point about slices, I guess.
>

What you describe as "their point" certainly is one important point about
slices. But it's not "the" point. Amortized O(1) append is definitely also
an important aspect and it requires being able to use them past their
length (and it's why they carry a capacity, as opposed to strings, for
example).

Many slices can refer to the same internal buffer, giving you sort of
> window view of the data, thus as long as any slice still refer to the
> internal buffer GC won't collect it.
>
>
> On Thursday, March 26, 2020 at 6:39:50 PM UTC+1, robfig wrote:
>>
>> Reducing a slice's length makes the elements unreachable, but the GC
>> appears to still treat them as live, based on this snippet:
>> https://play.golang.org/p/SvsE-nXi-JA
>>
>> I would have expected the HeapInUse to go down in the second measurement.
>>
>> Why is that?
>>
>> I presume that the GC is traversing the slice's capacity rather than
>> length, but I'm not sure why this is necessary. Is there a way (without
>> using unsafe) to access slice elements past the length?
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/27be27b0-5b55-4035-9953-072809fc7932%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFvhsSV_Bgj_hxr%2B5hqbzbHtKR-p8f78PjWbEka%2BH_F%2Bw%40mail.gmail.com.

Re: [go-nuts] Slice reuse + GC

[Leszek Kubik]

Actually *T was not a good example to make my point, as we can start 
debating about the GC walking the references and freeing the data pointed 
to. However when you have []T, and you refer to some continuous buffer of 
memory with some chunks [0:5] (gap) [50:100], etc there's not much benefit 
of "freeing" the elements in-between. Anyway, I assume slices are meant to 
be an abstract pointers to arrays and thus they should only change the 
visibility not the array


On Thursday, March 26, 2020 at 7:19:16 PM UTC+1, Leszek Kubik wrote:
>
> I let you consider an example:
>
> s := make([]*T, 100)
> s1, s2, s3 := s[:50], s[50:], s[:]
> ( x lines of code)
> s1 = s1[:5]
>
> Would you like the GC to free the elements past the last s1 slice len? 
> What if s2, s3 are still used somewhere...
>
>
> On Thursday, March 26, 2020 at 7:01:34 PM UTC+1, robfig wrote:
>>
>> I see, thank you.
>>
>> RE reducing the capacity, I want to distinguish freeing the memory (1) 
>> used for the slice and (2) referred to by the slice elements. I can easily 
>> see that freeing (1) is hard and not so beneficial, but I can't see why (2) 
>> would be difficult, and the benefit seems potentially much larger. In our 
>> case, each slice element has a handle to a sizable []byte, so that's why I 
>> was interested to know if they would remain live. 
>>
>> As an aside, (1) was addressed by Ian here:
>> https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57d4b27d-c650-492c-b931-aab0fbf39c68%40googlegroups.com.

Re: [go-nuts] Slice reuse + GC

[Ian Lance Taylor]

On Thu, Mar 26, 2020 at 11:02 AM robfig  wrote:
>
> RE reducing the capacity, I want to distinguish freeing the memory (1) used 
> for the slice and (2) referred to by the slice elements. I can easily see 
> that freeing (1) is hard and not so beneficial, but I can't see why (2) would 
> be difficult, and the benefit seems potentially much larger. In our case, 
> each slice element has a handle to a sizable []byte, so that's why I was 
> interested to know if they would remain live.
>
> As an aside, (1) was addressed by Ian here:
> https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ

It's kind of the same problem for (2).  The garbage collector would
have to find every slice that referred to the memory in question and
check the capacity.  This is hard because the GC has no natural way to
go from the backing array pointer to the capacity associated with that
pointer.  In particular when slices are stored on the stack, there is
no requirement that the capacity be near the backing array pointer or
even to exist at all.  I suppose the GC could simply assume that all
backing array pointers on the stack referred to the entire array, but
then compiler optimizations would affect which elements were freed,
and the behavior would be somewhat unintuitive.

All in all, if you want to make sure that the slice elements are
cleared, you'll have to clear them yourself.  Or use a slice copy
rather than a simple slice expression.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUhApbqw_Zcsa0cJ2ZjGz8Ov4gz0Zx-2BjqNXxgd5JjHQ%40mail.gmail.com.

Re: [go-nuts] runtime error: invalid memory address

[Ian Lance Taylor]

Check the error returned by template.ParseFiles.

Always check error returns.

Ian


On Thu, Mar 26, 2020 at 10:53 AM  wrote:
>
> Hey guys,
>
> I'm pretty new to Golang and encountering a runtime error which I'm not able 
> to fix.
>
> Need help guys!
>
> Error***
> 020/03/26 22:55:04 http: panic serving [::1]:41498: runtime error: invalid 
> memory address or nil pointer dereference
> goroutine 6 [running]:
> net/http.(*conn).serve.func1(0xc99040)
> /usr/local/go/src/net/http/server.go:1767 +0x139
> panic(0x7815e0, 0xabef60)
> /usr/local/go/src/runtime/panic.go:679 +0x1b2
> text/template.errRecover(0xc54b30)
> /usr/local/go/src/text/template/exec.go:164 +0x1cb
> panic(0x7815e0, 0xabef60)
> /usr/local/go/src/runtime/panic.go:679 +0x1b2
> text/template.(*Template).execute(0x0, 0x867380, 0xcd20e0, 0x7a01e0, 
> 0xc0e2e0, 0x0, 0x0)
> /usr/local/go/src/text/template/exec.go:218 +0x1c1
> text/template.(*Template).Execute(...)
> /usr/local/go/src/text/template/exec.go:204
> main.Index(0x86d0c0, 0xcd20e0, 0xc000114000)
> /home/dave/Go_workstation/src/web_calss/main.go:22 +0x11d
> net/http.HandlerFunc.ServeHTTP(0x802840, 0x86d0c0, 0xcd20e0, 0xc000114000)
> /usr/local/go/src/net/http/server.go:2007 +0x44
> net/http.(*ServeMux).ServeHTTP(0xaceda0, 0x86d0c0, 0xcd20e0, 0xc000114000)
> /usr/local/go/src/net/http/server.go:2387 +0x1bd
> net/http.serverHandler.ServeHTTP(0xcd2000, 0x86d0c0, 0xcd20e0, 
> 0xc000114000)
> /usr/local/go/src/net/http/server.go:2802 +0xa4
> net/http.(*conn).serve(0xc99040, 0x86d980, 0xc68380)
> /usr/local/go/src/net/http/server.go:1890 +0x875
> created by net/http.(*Server).Serve
> /usr/local/go/src/net/http/server.go:2928 +0x384
> 2020/03/26 22:55:04 http: panic serving [::1]:41500: runtime error: invalid 
> memory address or nil pointer dereference
> goroutine 18 [running]:
> net/http.(*conn).serve.func1(0xcee000)
> /usr/local/go/src/net/http/server.go:1767 +0x139
> panic(0x7815e0, 0xabef60)
> /usr/local/go/src/runtime/panic.go:679 +0x1b2
> text/template.errRecover(0xc000107b30)
> /usr/local/go/src/text/template/exec.go:164 +0x1cb
> panic(0x7815e0, 0xabef60)
> /usr/local/go/src/runtime/panic.go:679 +0x1b2
> text/template.(*Template).execute(0x0, 0x867380, 0xc000148000, 0x7a01e0, 
> 0xcfc020, 0x0, 0x0)
> /usr/local/go/src/text/template/exec.go:218 +0x1c1
> text/template.(*Template).Execute(...)
> /usr/local/go/src/text/template/exec.go:204
> main.Index(0x86d0c0, 0xc000148000, 0xc00011)
> /home/dave/Go_workstation/src/web_calss/main.go:22 +0x11d
> net/http.HandlerFunc.ServeHTTP(0x802840, 0x86d0c0, 0xc000148000, 0xc00011)
> /usr/local/go/src/net/http/server.go:2007 +0x44
> net/http.(*ServeMux).ServeHTTP(0xaceda0, 0x86d0c0, 0xc000148000, 0xc00011)
> /usr/local/go/src/net/http/server.go:2387 +0x1bd
> net/http.serverHandler.ServeHTTP(0xcd2000, 0x86d0c0, 0xc000148000, 
> 0xc00011)
> /usr/local/go/src/net/http/server.go:2802 +0xa4
> net/http.(*conn).serve(0xcee000, 0x86d980, 0xcf2000)
> /usr/local/go/src/net/http/server.go:1890 +0x875
> created by net/http.(*Server).Serve
> /usr/local/go/src/net/http/server.go:2928 +0x384
> 2020/03/26 22:55:04 http: panic serving [::1]:41502: runtime error: invalid 
> memory address or nil pointer dereference
> goroutine 8 [running]:
> net/http.(*conn).serve.func1(0xc99180)
> /usr/local/go/src/net/http/server.go:1767 +0x139
> panic(0x7815e0, 0xabef60)
> /usr/local/go/src/runtime/panic.go:679 +0x1b2
> text/template.errRecover(0xc54b30)
> /usr/local/go/src/text/template/exec.go:164 +0x1cb
> panic(0x7815e0, 0xabef60)
> /usr/local/go/src/runtime/panic.go:679 +0x1b2
> text/template.(*Template).execute(0x0, 0x867380, 0xc0001480e0, 0x7a01e0, 
> 0xcfc060, 0x0, 0x0)
> /usr/local/go/src/text/template/exec.go:218 +0x1c1
> text/template.(*Template).Execute(...)
> /usr/local/go/src/text/template/exec.go:204
> main.Index(0x86d0c0, 0xc0001480e0, 0xc000114100)
> /home/dave/Go_workstation/src/web_calss/main.go:22 +0x11d
> net/http.HandlerFunc.ServeHTTP(0x802840, 0x86d0c0, 0xc0001480e0, 0xc000114100)
> /usr/local/go/src/net/http/server.go:2007 +0x44
> net/http.(*ServeMux).ServeHTTP(0xaceda0, 0x86d0c0, 0xc0001480e0, 0xc000114100)
> /usr/local/go/src/net/http/server.go:2387 +0x1bd
> net/http.serverHandler.ServeHTTP(0xcd2000, 0x86d0c0, 0xc0001480e0, 
> 0xc000114100)
> /usr/local/go/src/net/http/server.go:2802 +0xa4
> net/http.(*conn).serve(0xc99180, 0x86d980, 0xc68500)
> /usr/local/go/src/net/http/server.go:1890 +0x875
> created by net/http.(*Server).Serve
> /usr/local/go/src/net/http/server.go:2928 +0x384
>
>
> Please see the following code
> ***Code
> 

Re: [go-nuts] Slice reuse + GC

[Leszek Kubik]

I let you consider an example:

s := make([]*T, 100)
s1, s2, s3 := s[:50], s[50:], s[:]
( x lines of code)
s1 = s1[:5]

Would you like the GC to free the elements past the last s1 slice len? What 
if s2, s3 are still used somewhere...


On Thursday, March 26, 2020 at 7:01:34 PM UTC+1, robfig wrote:
>
> I see, thank you.
>
> RE reducing the capacity, I want to distinguish freeing the memory (1) 
> used for the slice and (2) referred to by the slice elements. I can easily 
> see that freeing (1) is hard and not so beneficial, but I can't see why (2) 
> would be difficult, and the benefit seems potentially much larger. In our 
> case, each slice element has a handle to a sizable []byte, so that's why I 
> was interested to know if they would remain live. 
>
> As an aside, (1) was addressed by Ian here:
> https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/179c7a55-80a6-497c-9a82-5e2c6db628af%40googlegroups.com.

Re: [go-nuts] Slice reuse + GC

[robfig]

I see, thank you.

RE reducing the capacity, I want to distinguish freeing the memory (1) used 
for the slice and (2) referred to by the slice elements. I can easily see 
that freeing (1) is hard and not so beneficial, but I can't see why (2) 
would be difficult, and the benefit seems potentially much larger. In our 
case, each slice element has a handle to a sizable []byte, so that's why I 
was interested to know if they would remain live. 

As an aside, (1) was addressed by Ian here:
https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ef48dc4d-ff17-4648-8fb9-4302f43ff5ae%40googlegroups.com.

[go-nuts] Re: Slice reuse + GC

[Leszek Kubik]

AFAIK it is allowed to re-slice past the len but it's rather not the way 
slices should be ever used. The word slice implies taking a portion from a 
bigger thing and that's always safe. When you append to the slice however, 
there's no new allocation if the underlying buffer still has place past the 
current slice len.

You missed the point about slices, I guess. Many slices can refer to the 
same internal buffer, giving you sort of window view of the data, thus as 
long as any slice still refer to the internal buffer GC won't collect it.


On Thursday, March 26, 2020 at 6:39:50 PM UTC+1, robfig wrote:
>
> Reducing a slice's length makes the elements unreachable, but the GC 
> appears to still treat them as live, based on this snippet:
> https://play.golang.org/p/SvsE-nXi-JA
>
> I would have expected the HeapInUse to go down in the second measurement. 
>
> Why is that? 
>
> I presume that the GC is traversing the slice's capacity rather than 
> length, but I'm not sure why this is necessary. Is there a way (without 
> using unsafe) to access slice elements past the length? 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/27be27b0-5b55-4035-9953-072809fc7932%40googlegroups.com.

[go-nuts] runtime error: invalid memory address

[davetweetlive]

Hey guys,

I'm pretty new to Golang and encountering a runtime error which I'm not 
able to fix.

Need help guys!

Error***
020/03/26 22:55:04 http: panic serving [::1]:41498: runtime error: invalid 
memory address or nil pointer dereference
goroutine 6 [running]:
net/http.(*conn).serve.func1(0xc99040)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x7815e0, 0xabef60)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
text/template.errRecover(0xc54b30)
/usr/local/go/src/text/template/exec.go:164 +0x1cb
panic(0x7815e0, 0xabef60)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
text/template.(*Template).execute(0x0, 0x867380, 0xcd20e0, 0x7a01e0, 
0xc0e2e0, 0x0, 0x0)
/usr/local/go/src/text/template/exec.go:218 +0x1c1
text/template.(*Template).Execute(...)
/usr/local/go/src/text/template/exec.go:204
main.Index(0x86d0c0, 0xcd20e0, 0xc000114000)
/home/dave/Go_workstation/src/web_calss/main.go:22 +0x11d
net/http.HandlerFunc.ServeHTTP(0x802840, 0x86d0c0, 0xcd20e0, 
0xc000114000)
/usr/local/go/src/net/http/server.go:2007 +0x44
net/http.(*ServeMux).ServeHTTP(0xaceda0, 0x86d0c0, 0xcd20e0, 
0xc000114000)
/usr/local/go/src/net/http/server.go:2387 +0x1bd
net/http.serverHandler.ServeHTTP(0xcd2000, 0x86d0c0, 0xcd20e0, 
0xc000114000)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc99040, 0x86d980, 0xc68380)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2928 +0x384
2020/03/26 22:55:04 http: panic serving [::1]:41500: runtime error: invalid 
memory address or nil pointer dereference
goroutine 18 [running]:
net/http.(*conn).serve.func1(0xcee000)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x7815e0, 0xabef60)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
text/template.errRecover(0xc000107b30)
/usr/local/go/src/text/template/exec.go:164 +0x1cb
panic(0x7815e0, 0xabef60)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
text/template.(*Template).execute(0x0, 0x867380, 0xc000148000, 0x7a01e0, 
0xcfc020, 0x0, 0x0)
/usr/local/go/src/text/template/exec.go:218 +0x1c1
text/template.(*Template).Execute(...)
/usr/local/go/src/text/template/exec.go:204
main.Index(0x86d0c0, 0xc000148000, 0xc00011)
/home/dave/Go_workstation/src/web_calss/main.go:22 +0x11d
net/http.HandlerFunc.ServeHTTP(0x802840, 0x86d0c0, 0xc000148000, 
0xc00011)
/usr/local/go/src/net/http/server.go:2007 +0x44
net/http.(*ServeMux).ServeHTTP(0xaceda0, 0x86d0c0, 0xc000148000, 
0xc00011)
/usr/local/go/src/net/http/server.go:2387 +0x1bd
net/http.serverHandler.ServeHTTP(0xcd2000, 0x86d0c0, 0xc000148000, 
0xc00011)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xcee000, 0x86d980, 0xcf2000)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2928 +0x384
2020/03/26 22:55:04 http: panic serving [::1]:41502: runtime error: invalid 
memory address or nil pointer dereference
goroutine 8 [running]:
net/http.(*conn).serve.func1(0xc99180)
/usr/local/go/src/net/http/server.go:1767 +0x139
panic(0x7815e0, 0xabef60)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
text/template.errRecover(0xc54b30)
/usr/local/go/src/text/template/exec.go:164 +0x1cb
panic(0x7815e0, 0xabef60)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
text/template.(*Template).execute(0x0, 0x867380, 0xc0001480e0, 0x7a01e0, 
0xcfc060, 0x0, 0x0)
/usr/local/go/src/text/template/exec.go:218 +0x1c1
text/template.(*Template).Execute(...)
/usr/local/go/src/text/template/exec.go:204
main.Index(0x86d0c0, 0xc0001480e0, 0xc000114100)
/home/dave/Go_workstation/src/web_calss/main.go:22 +0x11d
net/http.HandlerFunc.ServeHTTP(0x802840, 0x86d0c0, 0xc0001480e0, 
0xc000114100)
/usr/local/go/src/net/http/server.go:2007 +0x44
net/http.(*ServeMux).ServeHTTP(0xaceda0, 0x86d0c0, 0xc0001480e0, 
0xc000114100)
/usr/local/go/src/net/http/server.go:2387 +0x1bd
net/http.serverHandler.ServeHTTP(0xcd2000, 0x86d0c0, 0xc0001480e0, 
0xc000114100)
/usr/local/go/src/net/http/server.go:2802 +0xa4
net/http.(*conn).serve(0xc99180, 0x86d980, 0xc68500)
/usr/local/go/src/net/http/server.go:1890 +0x875
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2928 +0x384


Please see the following code 
***Code
package main

import (
"net/http"
"text/template"
"web_calss/controllers/demo_controller"
)

func main() {
http.HandleFunc("/", Index)
// http.HandleFunc("/demo/index", Index)
http.ListenAndServe(":8000", nil)
}

func Index(w http.ResponseWriter, r *http.Request) {

tmplt, _ := 

Re: [go-nuts] Slice reuse + GC

['Axel Wagner' via golang-nuts]

By the way, I don't think your snippet shows what you think it's showing.
In particular, the output stays the same, even if you reduce the capacity
to 0: https://play.golang.org/p/r2YvnDNsoBg
I also always assumed the GC wouldn't do this optimization (throwing away
memory if it's past the capacity of a slice) anyway. Not because it can't
(I think), but just because I didn't think anyone built it to.

On Thu, Mar 26, 2020 at 6:47 PM Axel Wagner 
wrote:

>
>
> On Thu, Mar 26, 2020 at 6:41 PM robfig  wrote:
>
>> Reducing a slice's length makes the elements unreachable, but the GC
>> appears to still treat them as live, based on this snippet:
>> https://play.golang.org/p/SvsE-nXi-JA
>>
>> I would have expected the HeapInUse to go down in the second measurement.
>>
>> Why is that?
>>
>> I presume that the GC is traversing the slice's capacity rather than
>> length, but I'm not sure why this is necessary. Is there a way (without
>> using unsafe) to access slice elements past the length?
>>
>
> Yes. https://play.golang.org/p/HhZWkGvR37L
>
>
>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c2bea525-0636-4365-b551-59d1fceb5959%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEWDfT8syfWM_n-9%2Be9tcs61xUgQoJ8EJzisUZCJEqLNA%40mail.gmail.com.

Re: [go-nuts] Slice reuse + GC

['Axel Wagner' via golang-nuts]

On Thu, Mar 26, 2020 at 6:41 PM robfig  wrote:

> Reducing a slice's length makes the elements unreachable, but the GC
> appears to still treat them as live, based on this snippet:
> https://play.golang.org/p/SvsE-nXi-JA
>
> I would have expected the HeapInUse to go down in the second measurement.
>
> Why is that?
>
> I presume that the GC is traversing the slice's capacity rather than
> length, but I'm not sure why this is necessary. Is there a way (without
> using unsafe) to access slice elements past the length?
>

Yes. https://play.golang.org/p/HhZWkGvR37L



> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c2bea525-0636-4365-b551-59d1fceb5959%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF-GzA%2BEOEANFZTpAZ_CXTNJhLTyY%2B4xZs%2BVa505CGYoQ%40mail.gmail.com.

[go-nuts] Slice reuse + GC

[robfig]

Reducing a slice's length makes the elements unreachable, but the GC 
appears to still treat them as live, based on this snippet:
https://play.golang.org/p/SvsE-nXi-JA

I would have expected the HeapInUse to go down in the second measurement. 

Why is that? 

I presume that the GC is traversing the slice's capacity rather than 
length, but I'm not sure why this is necessary. Is there a way (without 
using unsafe) to access slice elements past the length? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c2bea525-0636-4365-b551-59d1fceb5959%40googlegroups.com.

[go-nuts] Re: Print something while read message from server with websocket

[Jake Montgomery]

Your Client  code does not compile. 
As a courtesy to those trying to help, it is always good to test your code 
before posting it. A working example, without your "busy" messages would be 
something like: https://play.golang.org/p/cvgwd8GDobc . The Read() method 
documentation  says 
"Read implements the io.Reader interface." So I suggest you *carefully *read 
the io.Reader documentation , because it 
requires very specific handling to be done correctly. 

Also, I did note that golang.org/x/net/websocket documentation 
 states that: "This package 
currently lacks some features found in alternative and more actively 
maintained WebSocket packages." So you may want to consider using one of 
those. 

I have not actually used golang.org/x/net 
/websocket myself, but there is a 
SetReadDeadline 
() 
function. Because I have not used the package before, there may be some 
hidden pitfalls that I am missing, but this code seems to do what you want, 
using SetReadDeadline 
(): 
https://play.golang.org/p/ISUR7c_Mtqb

Good luck

On Wednesday, March 25, 2020 at 8:56:57 PM UTC-4, 洪嘉鴻 wrote:
>
> I'm sorry.
> The followings are the complete codes of server and client:
> Server 
> Client 
>
> Thank you very much!
>   Max
>
> Jake Montgomery於 2020年3月25日星期三 UTC+8下午9時28分37秒寫道：
>>
>> You do not provide enough information to give a really good answer. There 
>> are a number of ways to achieve this, but they depend on the details. A 
>> more complete example would help. 
>>
>> What is the type of `ws`? If it is something on which you can set a read 
>> timeout, then one way would be to set a timeout, and loop.
>>
>> On Wednesday, March 25, 2020 at 4:10:19 AM UTC-4, 洪嘉鴻 wrote:
>>>
>>> Hello everyone:
>>>   The version of the golang which I am using is 1.12.9 with Win10.
>>>   I want to print something while the client is waiting for server.
>>>   The following are the partial code of server and client.
>>>
>>>   Server:
>>>   time.Sleep(time.Second * 100)
>>>   ws.Write([]byte("Hello!"))
>>>   
>>>   Client:
>>>   while(!ws.Read(msg)){
>>>   fmt.Println("Please wait because server is busy.")  
>>>   }
>>>
>>>   Can anyone suggest how to fix the code?
>>>
>>>   Any help is appreciated.
>>>   Thank you very much!
>>>   Max
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c1e09631-eea3-40e2-bb5a-246906e17508%40googlegroups.com.

Re: [go-nuts] Go course

[Sebastien Binet]

On Thu, Mar 26, 2020 at 3:29 PM David Riley  wrote:
[...]

> But:
>
> - You still need to import something just to print a line, and it is
> confusingly (to the novice) named "fmt"
> - You still need to declare a function called main(), and most brand-new
> programmers don't understand functions yet, so this becomes a "wave the
> dead chicken at it just right" thing
> - Semicolons are still there under the surface, but they're inserted by
> the lexer, and when they get inserted can be really mysterious and trip a
> lot of people up
>
> In contrast, in Python (3, in this case), it is:
>
> print("Hello, world!")
>

to be fair, in Go, "hello world" can be reduced to:

package main
func main() {
println("hello world")
}

that's usually how I start my Go-based lecture.
(and then, 2-3 lectures/hands-on sessions after that, I do introduce
'import "foo"')

-s


> There are no functions to create (you call one, which is universal in all
> these examples, but a lot easier to explain), execution just proceeds from
> top to bottom, variables are created much more easily (explaining the
> difference between = and := to someone who has never programmed before is
> quite a task), loops are far less complex, etc.
>
> I'm not claiming Python is a better language, or less confusing overall.
> Once it gets more complex, Python starts to get in the way a bit more (I've
> never particularly liked the indent-based block structure, though actually
> students got a lot less tripped up by that than by brace matching, so
> there's that).  But I steadfastly maintain that Go is not an ideal language
> to learn as a *first* programming language, simply because the amount of
> arcana you have to get right just to get simple things off the ground is
> far more than other languages like Python.  And I have a substantial amount
> of experience with students which indicates where the trouble spots would
> be that cause people to give up and decide programming isn't for them
> instead of realizing that they're not starting at the right level.
>
> This isn't a call for Go to change, because I'm totally fine with it being
> a second language after the basics of programming have been mastered.  You
> don't start driving in a Porsche unless you want a very expensive and
> hazardous learning experience.  Similarly, I think most of us could agree
> that teaching Java as a first programming language should be a felony,
> because it takes all these early-learning challenges and amplifies them
> (not only does main() have to be a function, it has to be in a class
> (what's a class?) and it has to specifically be "public static int
> main(String[] args)").
>
> My only contention, and my intent in answering the original question, is
> that there is a great first-party Tour of Go that is going to be great if
> you already know how to program, but somewhat opaque if you don't already
> understand the basic concepts. Python's own first-party tutorial is the
> same, actually; it's good, but it's set up as an intro to Python assuming
> you already know the basics and I wouldn't recommend it to a new
> programmer.  Since the OP didn't specify what level they were looking for,
> I provided both sides of my opinion.
>
>
> - Dave
>
>
> > On Mar 26, 2020, at 4:51 AM, Amnon Baron Cohen 
> wrote:
> >
> > Go is not C. C programmers have to master explicit memory management,
> which is a challenge to new and experience programmers alike.
> > C is a beautiful language. But very low level.
> >
> > Having spent several years programming in Python, I would say that it is
> much more complicated than Go.
> > It has a large and growing number of expressive features which add to
> the cognitive load of those attempting
> > to get up to speed on the language. When you learn Go, you don't need to
> understand dict comprehensions,
> > decorators, metaclasses, asyncio etc. Compare the breathtaking
> simplicity of launching a Go routine
> > with the convoluted mess of python threading.
> >
> > The lack of strong static typing and a separate compilation phase means
> that errors which in Go would
> > cause a compilation error result in run-time exceptions, when a
> particular code path gets executed.
> >
> > Python also has the "feature" that changes in invisible whitespace
> characters change the programme semantics.
> > I never really understood the rationale for the feature.
> >
> > The Go 1 compatibility promise is also helpful. This means that course
> materials or online code examples written
> > 8 years ago will still work today. The python community broke most
> existing code when they moved from Python 2 to Python 3.
> > (A decade on this transition is still ongoing).
> >
> > On Wednesday, 25 March 2020 23:04:58 UTC, David Riley wrote:
> > It’s just my opinion, and I’m willing to be wrong. :-)
> >
> > But having TAed a university introductory computer science course that
> was first in C and then in Python (and having had several students who
> failed when it was 

Re: [go-nuts] Go course

[David Riley]

I'm aware that Go is not C, and memory management was not one of the points I 
mentioned. Memory management is a thing that trips up even extremely skilled 
developers. But I've been programming in C since 1997 and Python since 2010, 
and I've been working in Go long enough (and teaching new programmers) that I'm 
still pretty confident in my assessment, especially after having run dozens of 
labs with hundreds of students at varying skill levels.

New programmers often have a lot of trouble being bombarded with lots of new 
things off the bat. We tend to think of "Hello, world!" as pretty easy, but in 
C, there are a number of "magic" things in even that which have to be in place 
to even work which don't get explained until much later:

#include 

int main(void) {
printf("Hello, world!\n");

return 0;
}

To wit:

- What does #include do?
- What on earth does stdio mean?
- Why does our program need to be a function (if they know what functions are, 
which is not a given)?
- Why does it need to return an int?
- What's with the semicolons?
- Why printf, not print?
- What is \n?

That's not even considering what happens when they inevitably transcribe things 
wrong and have to figure out why it's breaking several lines from where they 
left out a semicolon.

Go's intro is somewhat simpler:

package main

import "fmt"

func main() {
fmt.Println("Hello, world!")
}

This simplifies:

- "import thing" is less arcane than "#include "
- No explicit newline needed with fmt.Println
- No explicit semicolons
- No return from main()

But:

- You still need to import something just to print a line, and it is 
confusingly (to the novice) named "fmt"
- You still need to declare a function called main(), and most brand-new 
programmers don't understand functions yet, so this becomes a "wave the dead 
chicken at it just right" thing
- Semicolons are still there under the surface, but they're inserted by the 
lexer, and when they get inserted can be really mysterious and trip a lot of 
people up

In contrast, in Python (3, in this case), it is:

print("Hello, world!")

There are no functions to create (you call one, which is universal in all these 
examples, but a lot easier to explain), execution just proceeds from top to 
bottom, variables are created much more easily (explaining the difference 
between = and := to someone who has never programmed before is quite a task), 
loops are far less complex, etc.

I'm not claiming Python is a better language, or less confusing overall.  Once 
it gets more complex, Python starts to get in the way a bit more (I've never 
particularly liked the indent-based block structure, though actually students 
got a lot less tripped up by that than by brace matching, so there's that).  
But I steadfastly maintain that Go is not an ideal language to learn as a 
*first* programming language, simply because the amount of arcana you have to 
get right just to get simple things off the ground is far more than other 
languages like Python.  And I have a substantial amount of experience with 
students which indicates where the trouble spots would be that cause people to 
give up and decide programming isn't for them instead of realizing that they're 
not starting at the right level.

This isn't a call for Go to change, because I'm totally fine with it being a 
second language after the basics of programming have been mastered.  You don't 
start driving in a Porsche unless you want a very expensive and hazardous 
learning experience.  Similarly, I think most of us could agree that teaching 
Java as a first programming language should be a felony, because it takes all 
these early-learning challenges and amplifies them (not only does main() have 
to be a function, it has to be in a class (what's a class?) and it has to 
specifically be "public static int main(String[] args)").

My only contention, and my intent in answering the original question, is that 
there is a great first-party Tour of Go that is going to be great if you 
already know how to program, but somewhat opaque if you don't already 
understand the basic concepts. Python's own first-party tutorial is the same, 
actually; it's good, but it's set up as an intro to Python assuming you already 
know the basics and I wouldn't recommend it to a new programmer.  Since the OP 
didn't specify what level they were looking for, I provided both sides of my 
opinion.


- Dave


> On Mar 26, 2020, at 4:51 AM, Amnon Baron Cohen  wrote:
> 
> Go is not C. C programmers have to master explicit memory management, which 
> is a challenge to new and experience programmers alike.
> C is a beautiful language. But very low level.
> 
> Having spent several years programming in Python, I would say that it is much 
> more complicated than Go.
> It has a large and growing number of expressive features which add to the 
> cognitive load of those attempting
> to get up to speed on the language. When you learn Go, you don't need to 
> understand 

Re: [go-nuts] Re: json to golang struct definition lib

[sanye]

On 3/26/20 4:29 PM, Amnon Baron Cohen wrote:

An interesting approach.

Slightly surprised you did not use "encodeing/json" to parse the json 
input,

which would have been much easier.
Thank you for your advice, I have removed 3rd dependencies, and it is 
indeed much easier


On Thursday, 26 March 2020 00:05:01 UTC, sanye wrote:

Hello gophers,

I found an interesting project:
https://github.com/mholt/json-to-go
 ,
which translate given json data into golang struct definition,
it's very
useful when dealing with complex json

It's written in javascript, but maybe a golang version is useful when
doing some works like code generation, so I ported it to golang:
https://github.com/kumakichi/json-to-go


Any feedback are appreciated.

sanye

--
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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d8b41228-2b54-41f6-bfc5-9adef9e46722%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/edd0c81c-2947-35c3-210b-c4b0f324fe0d%40gmail.com.

Re: [go-nuts] Re: Mem-Leak in Go method

[Nitish Saboo]

Hi Tamas,

1) There is no such option '--heap_inuse'. We have an -*-inuse_space*
option. Is this what you are talking about?

nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof --inuse_space main mem3.prof
Fetched 1 source profiles out of 2
File: main
Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
Type: inuse_space
Time: Mar 22, 2020 at 6:32am (PDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) o
  call_tree = false
  compact_labels= true
  cumulative= flat //: [cum | flat]
  divide_by = 1
  drop_negative = false
  edgefraction  = 0.001
  focus = ""
  granularity   = filefunctions//: [addresses |
filefunctions | files | functions | lines]
  hide  = ""
  ignore= ""
  mean  = false
  nodecount = -1   //: default
  nodefraction  = 0.005
  noinlines = false
  normalize = false
  output= ""
  prune_from= ""
  relative_percentages  = false
  sample_index  = inuse_space  //: [alloc_objects |
alloc_space | inuse_objects | inuse_space]
  show  = ""
  show_from = ""
  tagfocus  = ""
  taghide   = ""
  tagignore = ""
  tagshow   = ""
  trim  = true
  trim_path = ""
  unit  = minimum

 2) When I don't pass the flag it defaults to *--inuse_space*:

File: main
Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
Type: inuse_space
Time: Mar 22, 2020 at 6:32am (PDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 3303.21kB, 100% of 3303.21kB total
Showing top 10 nodes out of 28
  flat  flat%   sum%cum   cum%
 1762.94kB 53.37% 53.37%  1762.94kB 53.37%  runtime/pprof.StartCPUProfile
  516.01kB 15.62% 68.99%   516.01kB 15.62%  runtime/pprof.(*profMap).lookup
  512.19kB 15.51% 84.50%   512.19kB 15.51%  runtime.malg
  512.08kB 15.50%   100%   512.08kB 15.50%
 crypto/x509/pkix.(*Name).FillFromRDNSequence
 0 0%   100%   512.08kB 15.50%  crypto/tls.(*Conn).Handshake
 0 0%   100%   512.08kB 15.50%
 crypto/tls.(*Conn).clientHandshake
 0 0%   100%   512.08kB 15.50%
 crypto/tls.(*Conn).verifyServerCertificate
 0 0%   100%   512.08kB 15.50%
 crypto/tls.(*clientHandshakeState).doFullHandshake
 0 0%   100%   512.08kB 15.50%
 crypto/tls.(*clientHandshakeState).handshake
 0 0%   100%   512.08kB 15.50%
 crypto/x509.(*CertPool).AppendCertsFromPEM

Please correct me if I am missing something here.

Thanks,
Nitish


On Wed, Mar 25, 2020 at 12:16 AM Tamás Gulácsi  wrote:

> You've requested the total allocated space (--alloc_space), not only the
> heap used (--heap_inuse, or no flag).
> So that 17GiB is the total allocated size, does NOT include the released!
>
> 2020. március 24., kedd 15:16:46 UTC+1 időpontban Nitish Saboo a
> következőt írta:
>>
>> Hi,
>>
>> I have already gone through those links. They helped me to gather the mem
>> profile and while analyzing the data(as given in those links) I have come
>> across the following issue:
>>
>> While I was running the service for 100 minutes the 'top' command output
>> was showing Mem% as 11.1. There was no increase in mem usage since I had
>> not called 'LoadPatternDB()' method. I have 8GB of memory on the node where
>> I am running the service. My issue is :
>>
>>
>>- Why is it showing memory accounting for around 17GB?  11.1 % of 8GB
>>is .88GB and my node is only of 8GB. I feel the way I gathered the mem
>>profiling was not correct ..is it ?
>>
>> Please let me know where am I going wrong?
>>
>> Thanks,
>> Nitish
>>
>> On Tue, Mar 24, 2020 at 5:32 PM Nitish Saboo  wrote:
>>
>>> Hi,
>>>
>>> >>There is no root analysis available in Go. Read the paper I linked to.
>>>
>>> Sorry I did not get you. Which paper are you referring to?
>>>
>>> While I was running the service for 100 minutes the 'top' command output
>>> was showing Mem% as 11.1. There was no increase in mem usage since I had
>>> not called 'LoadPatternDB()' method.I have 8GB of memory on the node where
>>> I am running the service. My issue is :
>>>
>>>
>>>- Why is it showing memory accounting for around 17GB?  11.1 % of
>>>8GB is .88GB and my node is only of 8GB. I feel the way I gathered the 
>>> mem
>>>profiling was not correct ..is it ?
>>>
>>> Please advise me what am I missing?
>>>
>>> Thanks,
>>> Nitish
>>>
>>> On Tue, Mar 24, 2020 at 1:28 AM Robert Engels 
>>> wrote:
>>>
 Yes. You have a leak in your Go code. It shows you the object types
 that are taking up all of the space. There is no root analysis available in
 Go. Read the 

Re: [go-nuts] Why golang allocated memory space increases?

[Henrik Johansson]

Isn't this because of the GC tracking these and treating then as
effectively weak references to borrow a Java term?
If they are not pointers they are not tracked by the GC and I guess they
could all be removed at every scan?
Just guessing though, I haven't in any way checked it.

On Thu, Mar 26, 2020 at 11:34 AM Jakob Borg  wrote:

> On 26 Mar 2020, at 09:51, Tamás Gulácsi  wrote:
>
>
> sync.Pool MUST use pointers (*[]byte)
>
>
> I've seen this a lot but I confess I don't understand it. A []byte is
> essentially a fat pointer, what does it matter if we put that or a *[]byte
> into the pool? I understand that putting a []byte will result in an
> allocation of a new []byte, but probably the purpose is to preserve and
> avoid reallocating the backing array, which might be large.
>
> Is there something fundamental about the sync.Pool that means that a put
> *must* be zero-allocation for it to function? Likely the calling code
> around the puts/gets are not zero-allocation either.
>
> //jb
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/DB9E8E73-10B0-451B-BE66-13AF2930BB74%40kastelo.net
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF6942VjqZ21b5ztW6wn6FTuk_MZDNz%2B3p1v2Njr_RAwRO4w%40mail.gmail.com.

Re: [go-nuts] Why golang allocated memory space increases?

[Jakob Borg]

On 26 Mar 2020, at 09:51, Tamás Gulácsi 
mailto:tgulacs...@gmail.com>> wrote:

sync.Pool MUST use pointers (*[]byte)

I've seen this a lot but I confess I don't understand it. A []byte is 
essentially a fat pointer, what does it matter if we put that or a *[]byte into 
the pool? I understand that putting a []byte will result in an allocation of a 
new []byte, but probably the purpose is to preserve and avoid reallocating the 
backing array, which might be large.

Is there something fundamental about the sync.Pool that means that a put *must* 
be zero-allocation for it to function? Likely the calling code around the 
puts/gets are not zero-allocation either.

//jb

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/DB9E8E73-10B0-451B-BE66-13AF2930BB74%40kastelo.net.

Re: [go-nuts] Go course

[Amnon Baron Cohen]

Go is not C. C programmers have to master explicit memory management, which 
is a challenge to new and experience programmers alike.
C is a beautiful language. But very low level.

Having spent several years programming in Python, I would say that it is 
much more complicated than Go.
It has a large and growing number of expressive features which add to the 
cognitive load of those attempting
to get up to speed on the language. When you learn Go, you don't need to 
understand dict comprehensions,
decorators, metaclasses, asyncio etc. Compare the breathtaking simplicity 
of launching a Go routine
with the convoluted mess of python threading.

The lack of strong static typing and a separate compilation phase means 
that errors which in Go would 
cause a compilation error result in run-time exceptions, when a particular 
code path gets executed.

Python also has the "feature" that changes in invisible whitespace 
characters change the programme semantics.
I never really understood the rationale for the feature.

The Go 1 compatibility promise is also helpful. This means that course 
materials or online code examples written 
8 years ago will still work today. The python community broke most existing 
code when they moved from Python 2 to Python 3.
(A decade on this transition is still ongoing).

On Wednesday, 25 March 2020 23:04:58 UTC, David Riley wrote:
>
> It’s just my opinion, and I’m willing to be wrong. :-) 
>
> But having TAed a university introductory computer science course that was 
> first in C and then in Python (and having had several students who failed 
> when it was in C retake in Python and pass with flying colors), I will say 
> that a lot of the elements that tripped beginners up in C which were absent 
> in Python are present in Go. 
>
> Most of those (e.g. separate compilation, static typing, a few other bits 
> of arcana) are features that make Go a much more effective systems language 
> than Python, but I do feel like it’s probably best to “take the bumpers 
> off” AFTER the student knows about loops, variables, functions, etc. 
>
> Again, it’s only my point of view, and I do have some biases, but they do 
> have some basis. 
>
>
> - Dave 
>
> > On Mar 25, 2020, at 17:08, Dan Kortschak  > wrote: 
> > 
> > I don't agree that Go is intrinsically harder than python as a beginner 
> > programming language. There are things that are subtle, but these can 
> > largely be avoided in the beginner setting. 
> > 
> > Note that there have been discussions here about using Go as a language 
> > for teaching beginners, notably this one 
> > https://groups.google.com/d/topic/golang-nuts/FIRSDBehb3g/discussion 
> > 
> > Dan 
> > 
> >> On Wed, 2020-03-25 at 13:34 -0400, David Riley wrote: 
> >> If you are already a programmer in another language, the Tour of Go 
> >> (tour.golang.org) is absolutely the best. 
> >> 
> >> If you are not already a programmer in another language, I personally 
> >> don't recommend Go as a first language; it's an excellent language, 
> >> but I feel that people will do better with it once they already grasp 
> >> the fundamentals of programming and are ready for something with 
> >> slightly more arcana.  Python makes a pretty good first language. 
> >> 
> >> 
> >> - Dave 
> >> 
> >> 
> >>> On Mar 25, 2020, at 6:07 AM, Renato Marcandier < 
> >>> renato.m...@gmail.com > wrote: 
> >>> 
> >>> Hello guys, 
> >>> 
> >>> What's the best course to start with Go? 
> >>> 
> >>> 
> >>> 
> >>> Regards 
> >>> RG 
> >>> 
> >>> -- 
> >>> 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 golan...@googlegroups.com . 
> >>> To view this discussion on the web visit 
> >>> 
> https://groups.google.com/d/msgid/golang-nuts/b2aa0e9a-921f-49de-a0be-729a6ca35f5f%40googlegroups.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 golan...@googlegroups.com . 
> >> To view this discussion on the web visit 
> >> 
> https://groups.google.com/d/msgid/golang-nuts/18B2AF64-4888-4730-B282-FCB4C00AB697%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b43ecb5a-c043-44d4-92d6-f8c046dda7ff%40googlegroups.com.

Re: [go-nuts] Why golang allocated memory space increases?

[Tamás Gulácsi]

2020. március 26., csütörtök 7:58:59 UTC+1 időpontban steve tang a 
következőt írta:
>
> Thanks,  I used sync.Pool to allocate a byte.Buffer,  and response.Body  
> isn't constant size in program, I find golang will grow the byte.Buffer 
> space against to initial space. I changed code as follows:
>
> type SyncPool struct{ Pool sync.Pool }
>
> func (s *SyncPool) Get(n int) []byte {
>//比n大，不需要slice增长时，使用buffer pool
>if b, ok := s.Pool.Get().([]byte); ok && cap(b) >= n {
>   return b[:n]
>} else {
>   //miss size
>   s.Put(b)
>   return make([]byte, n)
>}
> }
>
> func (s *SyncPool) Put(b []byte) {
>s.Pool.Put(b)
> }
>
>
>
> const FourMB = 4 * 1024 * 1024
>
> var pool = {
>sync.Pool{
>   New: func() interface{} {
>  return make([]byte, FourMB)
>   },
>},
> }
>
>
>
>
> On Thursday, March 26, 2020 at 12:22:01 PM UTC+8, robert engels wrote:
>>
>> If the pool is a sync.Pool:
>>
>> Any item stored in the Pool may be removed automatically at any time without 
>>18  // notification. If the Pool holds the only reference when this 
>> happens, the19  // item might be deallocated.
>>
>> So placing an object in the pool does not guarantee it won’t be collected 
>> - causing a future allocation.
>>
>> On Mar 25, 2020, at 10:22 PM, steve tang  wrote:
>>
>> chunkCrc32Hash := crc32.NewIEEE()
>> chunkBuf := bufferpool.GetInstance().Get()
>> //回收buffer
>> defer bufferpool.GetInstance().Put(chunkBuf)
>> writer := io.MultiWriter(chunkBuf, chunkCrc32Hash)
>> _, copyErr := io.Copy(writer, chunkResp.RawResponse.Body)
>> if copyErr != nil && copyErr != io.EOF {
>>logmgr.ErrorLogger(ctx, "fail to write chunk data to crc32 or buffer, 
>> req: %s, err: %s", originReq.PrettyPrint(), copyErr)
>>return false, exception.OEFException(nil, 
>> http.StatusInternalServerError, CopyChunkError, "internal server exception")
>> }
>>
>> In above codes,  it writes chunk data to buffer pool, and the chunk data 
>> size is 4MB.  When I used golang tool pprof to export memory pprof, there 
>> about 8MB space has been allocated.  Could somebody help me why golang 
>> allocated 
>> memory space increases?
>>
>>
>> <20200326-111844.png>
>>
>>
>>
>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6dbe93e6-9bb7-4112-87cb-085e68d9d393%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/6dbe93e6-9bb7-4112-87cb-085e68d9d393%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> <20200326-111844.png>
>>
>>
>>
1. sync.Pool MUST use pointers (*[]byte)
2. what is `chunkBuf := bufferpool.GetInstance().Get()` ? it must be an 
io.Writer, but you should Reset/Truncate it when you Put it back to the 
pool!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e6e65488-d105-4880-bc61-90dd0ee9c7e2%40googlegroups.com.

[go-nuts] Re: json to golang struct definition lib

[Amnon Baron Cohen]

An interesting approach.

Slightly surprised you did not use "encodeing/json" to parse the json input,
which would have been much easier.

On Thursday, 26 March 2020 00:05:01 UTC, sanye wrote:
>
> Hello gophers, 
>
> I found an interesting project: https://github.com/mholt/json-to-go , 
> which translate given json data into golang struct definition, it's very 
> useful when dealing with complex json 
>
> It's written in javascript, but maybe a golang version is useful when 
> doing some works like code generation, so I ported it to golang: 
> https://github.com/kumakichi/json-to-go 
>
> Any feedback are appreciated. 
>
> sanye 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d8b41228-2b54-41f6-bfc5-9adef9e46722%40googlegroups.com.

[go-nuts] Re: Golang and the mobile framework

[Brian Candler]

Yes.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1398913d-6700-4da1-a88c-fda3401bd249%40googlegroups.com.

Re: [go-nuts] Why golang allocated memory space increases?

[steve tang]

Thanks,  I used sync.Pool to allocate a byte.Buffer,  and response.Body  
isn't constant size in program, I find golang will grow the byte.Buffer 
space against to initial space. I changed code as follows:

type SyncPool struct{ Pool sync.Pool }

func (s *SyncPool) Get(n int) []byte {
   //比n大，不需要slice增长时，使用buffer pool
   if b, ok := s.Pool.Get().([]byte); ok && cap(b) >= n {
  return b[:n]
   } else {
  //miss size
  s.Put(b)
  return make([]byte, n)
   }
}

func (s *SyncPool) Put(b []byte) {
   s.Pool.Put(b)
}



const FourMB = 4 * 1024 * 1024

var pool = {
   sync.Pool{
  New: func() interface{} {
 return make([]byte, FourMB)
  },
   },
}




On Thursday, March 26, 2020 at 12:22:01 PM UTC+8, robert engels wrote:
>
> If the pool is a sync.Pool:
>
> Any item stored in the Pool may be removed automatically at any time without  
>   18  // notification. If the Pool holds the only reference when this 
> happens, the19  // item might be deallocated.
>
> So placing an object in the pool does not guarantee it won’t be collected 
> - causing a future allocation.
>
> On Mar 25, 2020, at 10:22 PM, steve tang > 
> wrote:
>
> chunkCrc32Hash := crc32.NewIEEE()
> chunkBuf := bufferpool.GetInstance().Get()
> //回收buffer
> defer bufferpool.GetInstance().Put(chunkBuf)
> writer := io.MultiWriter(chunkBuf, chunkCrc32Hash)
> _, copyErr := io.Copy(writer, chunkResp.RawResponse.Body)
> if copyErr != nil && copyErr != io.EOF {
>logmgr.ErrorLogger(ctx, "fail to write chunk data to crc32 or buffer, 
> req: %s, err: %s", originReq.PrettyPrint(), copyErr)
>return false, exception.OEFException(nil, 
> http.StatusInternalServerError, CopyChunkError, "internal server exception")
> }
>
> In above codes,  it writes chunk data to buffer pool, and the chunk data 
> size is 4MB.  When I used golang tool pprof to export memory pprof, there 
> about 8MB space has been allocated.  Could somebody help me why golang 
> allocated 
> memory space increases?
>
>
> <20200326-111844.png>
>
>
>
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/6dbe93e6-9bb7-4112-87cb-085e68d9d393%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/6dbe93e6-9bb7-4112-87cb-085e68d9d393%40googlegroups.com?utm_medium=email_source=footer>
> .
> <20200326-111844.png>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e3c0f5b2-700a-49eb-9593-b4f936bb93e1%40googlegroups.com.

[go-nuts] Golang and the mobile framework

[husam alkdary]

It's possible to use Golang with to design mobile app with react-native or 
Flutter ? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/581b3906-15e8-44ff-b521-edbe82fab378%40googlegroups.com.