[go-nuts] http request blocked on futex .

[Dave Cheney]

Go programs are multi threaded, you should use the -f flag with strace to watch 
all threads servicing goroutines. 

-- 
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] http request blocked on futex .

[yikang zhuo]

hi all,

iI write a simple golang program below and build a execute file.

package main

import (
"fmt"
"io/ioutil"
"net/http"
"strings"
)

func main() {
data := "line=ls"
// resp, err := http.Post("http://127.0.0.1:3202/run;, 
"application/x-www-form-urlencoded",
resp, err := http.Post("http://192.168.1.109:3202/run;, 
"application/x-www-form-urlencoded",
strings.NewReader(data))
if err != nil {
fmt.Println(err)
}

defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
if err != nil {
fmt.Printf("remote run error\n")
}

fmt.Printf("%s", body)
}

when I compile and execute the program, it will block for almost 1 minutes 
and return , but the   err  whch in red color code above  is nil 
in the same time, the server which serves on 3202 doesn't get any request.

but if I execute it with sudo.  it works fine.  

I think it's not golang's  problem because I get the same performance with 
curl

blocked:curl  http://192.168.1.109:3202/run
works fine:sudo http://192.168.1.109:3202/run


so I  strace it without sudo . and get such stack:


➜  tr strace ./tr 
execve("./tr", ["./tr"], [/* 116 vars */]) = 0
brk(NULL)   = 0xe9c000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4dc7982000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=138563, ...}) = 0
mmap(NULL, 138563, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4dc796
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260`\0\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=138696, ...}) = 0
mmap(NULL, 2212904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f4dc7542000
mprotect(0x7f4dc755a000, 2093056, PROT_NONE) = 0
mmap(0x7f4dc7759000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f4dc7759000
mmap(0x7f4dc775b000, 13352, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dc775b000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
mmap(NULL, 3967392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f4dc7179000
mprotect(0x7f4dc7338000, 2097152, PROT_NONE) = 0
mmap(0x7f4dc7538000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7f4dc7538000
mmap(0x7f4dc753e000, 14752, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dc753e000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4dc795f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4dc795e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4dc795d000
arch_prctl(ARCH_SET_FS, 0x7f4dc795e700) = 0
mprotect(0x7f4dc7538000, 16384, PROT_READ) = 0
mprotect(0x7f4dc7759000, 4096, PROT_READ) = 0
mprotect(0x7f4dc7984000, 4096, PROT_READ) = 0
munmap(0x7f4dc796, 138563)  = 0
set_tid_address(0x7f4dc795e9d0) = 31710
set_robust_list(0x7f4dc795e9e0, 24) = 0
rt_sigaction(SIGRTMIN, {0x7f4dc7547b50, [], SA_RESTORER|SA_SIGINFO, 
0x7f4dc7553390}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f4dc7547be0, [], 
SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f4dc7553390}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(NULL)   = 0xe9c000
brk(0xebd000)   = 0xebd000
sched_getaffinity(0, 8192, [f, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...]) = 64
mmap(0xc0, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xc0
munmap(0xc0, 65536) = 0
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f4dc791d000
mmap(0xc42000, 1048576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc42000
mmap(0xc41fff8000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0xc41fff8000
mmap(0xc0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0xc0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4dc7972000
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f4dc7962000
rt_sigprocmask(SIG_SETMASK, 

[go-nuts] Re: a productive simple conf loader

[wanghuidev]

Excellent

On Friday, 28 April 2017 12:15:44 UTC+8, zsou...@gmail.com wrote:
>
> goconf 
>
>- Read configuration automatically based on the given struct's field 
>name.
>- Load configuration from multiple sources
>- multiple file inherit
>
>

-- 
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] x/term: go-keycodes

[Nigel Tao]

On Fri, May 12, 2017 at 3:11 AM, anatoly techtonik  wrote:
> I am new to Go and I need a cross-platform value for keyboard key codes to
> make sure I can react to user key presses regardless of operating system
> layer.

FYI, there's already the key.Code type defined in
https://github.com/golang/mobile/blob/master/event/key/key.go

-- 
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: Delve v1.0.0-rc.1 release

[Derek Parker]

Hey,

Currently that is on our roadmap, but we do not have anybody committed to 
hacking on it. Ideally, either myself of my co-maintainer will have some 
time to tackle that, but we absolutely encourage help from the community 
for such a feature. If somebody would like to help with that work, myself 
or my co-maintainer would be happy to point them in the right direction of 
where to get started.

On Thursday, May 11, 2017 at 11:18:56 AM UTC-7, Christian LeMoussel wrote:
>
> Hi,
>
> When can we expect the release for 32 bit system ?
>

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

[go-nuts] Re: Go not available after installing via MSI on windows. Paths are configured

[wcorbett36]

Mcafee is deleting go.exe immediately I have worked around it but that was 
the issue. 
On Thursday, May 11, 2017 at 2:19:02 PM UTC-4, William Corbett wrote:
>
> hello,  
>
> I installed on 64 bit windows via .msi and can get go to call in my 
> terminal.  My paths are set and returning via echo.  
>
> Thanks for advising, 
>
>
> C:\Users\u390982
> λ echo %GOROOT%
> C:\Go\
>
> C:\Users\u390982
> λ echo %GOPATH%
> %GOPATH%
>
> C:\Users\u390982
> λ echo %PATH%
>
> C:\Users\u390982\Desktop\utilities\cmder\cmder\bin;C:\Users\u390982\Desktop\utilities\cmder\cmder\vendor\conemu-maximus5
>
> \ConEmu\Scripts;C:\Users\u390982\Desktop\utilities\cmder\cmder\vendor\conemu-maximus5;C:\Users\u390982\Desktop\utilities
>
> \cmder\cmder\vendor\conemu-maximus5\ConEmu;C:\ProgramData\Oracle\Java\javapath;c:\Oracle\64\product\11.2.0\client_1\bin;
> c:\Oracle\32\product\11.2.0\client_1\bin;C:\Program Files 
> (x86)\CA\SC\CAWIN\;C:\windows\system32;C:\windows;C:\windows\S
> ystem32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files 
> (x86)\CA\SC\Csam\SockAdapter\bin;C:\Program Fi
> les (x86)\CA\SC\Csam\SockAdapter\bin64;C:\Program Files 
> (x86)\CA\DSM\bin;C:\Program Files (x86)\CA\SC\CBB\;C:\PROGRA~2\C
> A\SC\CAM\bin;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files 
> (x86)\Enterprise Vault\EVClient\;C:\Program Fi
> les\Intel\WiFi\bin\;C:\Program Files\Common 
> Files\Intel\WirelessCommon\;C:\Program Files\Git\cmd;C:\Program Files\nodejs
>
> \;C:\Users\u390982\Desktop\utilities\maven\apache-maven-3.3.9\bin;%GOPATH%bin
> *;C:\Go\bin;*C:\Users\u390982\AppData\Roaming
> \npm;C:\Users\u390982\AppData\Local\atom\bin;;C:\Program 
> Files\Git\usr\bin;C:\Program Files\Git\usr\share\vim\vim74;C:\U
> sers\u390982\Desktop\utilities\cmder\cmder\
>
> C:\Users\u390982
> λ go
> 'go' is not recognized as an internal or external command,
> operable program or batch file.
>

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

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

One more try : )
 

> I think what you're saying is that it's more natural and obvious that when 
> you have a function that changes something it would be more obvious and 
> simple if it actually did modify the thing you gave it.
>

That the receiver always act as a ref to a value stored /wherever/
That only the consumer decides where that value is stored using 
pointer/not.,
unless the declarer installed a barrier.



On Thursday, May 11, 2017 at 1:10:21 PM UTC+2, Chris Hopkins wrote:
>
> I think what you're saying is that it's more natural and obvious that when 
> you have a function that changes something it would be more obvious and 
> simple if it actually did modify the thing you gave it.
> Having to jump through hoops to actually make the change you asked for 
> stick is annoying.
>
> Yes? Is that what you mean? Is this a commentary on the effect this has on 
> ease of code read and writability?
>
> What I have come to realise recently by working on ever larger projects is 
> that no that's not annoying. When debugging code I don't understand often 
> half the challenge is working out how a piece of data has changed that 
> shouldn't have been. 
>

 

> In the world you describe anything that touched that variable could be to 
> blame for my problems. If instead you have to jump through hoops to make 
> modifications and those modifications are really obvious where they are 
> happening you make debugging easier.
>
same as today with pointer no ?
 

> Forcing the behaviour that "functions/methods don't modify their 
> associated structures" means people structure their code differently that 
> in my experience means instead of code that reads:
> foo.DoUsefulStuff(i) // has foo become corrupted? changed, who knows?
>
> if foo is not referencable, then the method DoUsefulStuff() 
necessarily provides an out param such DoUsefulStuff() 
That you did not copied back the returned value in your scope
is already an error today.

 

> you instead see code like:
> fred = foo.Lookup(i) // Complex function that changes nothing in foo
> foo = foo.ReturnUsefulStuff(fred) // This returns a corrupted structure
>

I dont get it, to return a corrupted state shall we not use an extra error 
parameter?
Still, that situation will apply if you use pointer.
 

For a start you look at the function definitions and see quickly that they 
> are not modifying the underlying structures so it's quick to discount a 
> large chunk of code as the a source of the problem. This is not so much of 
> a problem in your examples but in large undocumented projects where you 
> don't understand 99% of the code the small things make it much faster to 
> isolate where things could be going wrong.
>

because you focus on the type definition to lookup for possible suspects.
yes i argue its all about var definition and func in params.
yes it looks like they way i think multiply the place of errors.
 

>
> Please don't take this though as anything other than a commentary on the 
> code I like to read. "Code is written for humans to read and only 
> incidentally for machines to execute". I believe code is read by humans way 
> more times than it is written, so anything at all that isolates the code 
> and makes it easier to understand is worth putting time and effort into. 
>
> YMMV
>
>
I sincerely thanks everyone on the thread,
not easy task.

After all,
Happy we kindly disagree  :) 


On Thursday, 11 May 2017 11:39:18 UTC+1, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> thanks again!
>>
>> I m not the one to validate a perfect answer,
>> i can simply tell that from my go learning and understanding,
>> i agree top notch 200% no question there 
>> on this description,
>> which is weird in fact.
>>
>> I d only remark about this,
>> > so there are actually just two cases: Method is on pointer receiver or 
>> not. 
>>
>> From the declarer side, 
>> there is indeed only 2 cases, 
>> which accounts for 50% of the whole,
>> declaration + consumption,
>> the consumer is still accountable for the remaining
>> 50% of the instance consumption and usage.
>>
>> Does it make it less dead simple ?
>>
>> In my example i might have named the method as `whatever`,
>> still there is an explicit value set on a receiver property.
>> I don t feel like i have assumed anything from the method name.
>>
>>
>> On Thursday, May 11, 2017 at 12:17:00 PM UTC+2, Volker Dobler wrote:
>>>
>>> On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:

 //defined
> var x {} // put on heap
> var x T // put on stack
>
> This is definitely a misconception: Allocation on heap vs stack is
> totaly unrelated to value methods vs pointer methods. Both examples
> might be allocated on the stack or on the heap and this depends
> on other factors than methods of T.
>

 what are other factors ? 

>>>
>>> Roughly: If the compiler cannot prove that x *can* be safely put on the
>>> stack then it must go to the heap. Values cannot go safely 

[go-nuts] Re: Delve v1.0.0-rc.1 release

[cnhx27]

Hi,

When can we expect the release for 32 bit system ?

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

[go-nuts] Go not available after installing via MSI on windows. Paths are configured

[wcorbett36]

hello,  

I installed on 64 bit windows via .msi and can get go to call in my 
terminal.  My paths are set and returning via echo.  

Thanks for advising, 


C:\Users\u390982
λ echo %GOROOT%
C:\Go\

C:\Users\u390982
λ echo %GOPATH%
%GOPATH%

C:\Users\u390982
λ echo %PATH%
C:\Users\u390982\Desktop\utilities\cmder\cmder\bin;C:\Users\u390982\Desktop\utilities\cmder\cmder\vendor\conemu-maximus5
\ConEmu\Scripts;C:\Users\u390982\Desktop\utilities\cmder\cmder\vendor\conemu-maximus5;C:\Users\u390982\Desktop\utilities
\cmder\cmder\vendor\conemu-maximus5\ConEmu;C:\ProgramData\Oracle\Java\javapath;c:\Oracle\64\product\11.2.0\client_1\bin;
c:\Oracle\32\product\11.2.0\client_1\bin;C:\Program Files 
(x86)\CA\SC\CAWIN\;C:\windows\system32;C:\windows;C:\windows\S
ystem32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files 
(x86)\CA\SC\Csam\SockAdapter\bin;C:\Program Fi
les (x86)\CA\SC\Csam\SockAdapter\bin64;C:\Program Files 
(x86)\CA\DSM\bin;C:\Program Files (x86)\CA\SC\CBB\;C:\PROGRA~2\C
A\SC\CAM\bin;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files 
(x86)\Enterprise Vault\EVClient\;C:\Program Fi
les\Intel\WiFi\bin\;C:\Program Files\Common 
Files\Intel\WirelessCommon\;C:\Program Files\Git\cmd;C:\Program Files\nodejs
\;C:\Users\u390982\Desktop\utilities\maven\apache-maven-3.3.9\bin;%GOPATH%bin
*;C:\Go\bin;*C:\Users\u390982\AppData\Roaming
\npm;C:\Users\u390982\AppData\Local\atom\bin;;C:\Program 
Files\Git\usr\bin;C:\Program Files\Git\usr\share\vim\vim74;C:\U
sers\u390982\Desktop\utilities\cmder\cmder\

C:\Users\u390982
λ go
'go' is not recognized as an internal or external command,
operable program or batch file.

-- 
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] Java to Golang converter

[Dimitrios Trechas]

Java has vast number of libraries.

Good thing is Golang is catching up with its own style.

There are cases though where there is no equivalent libraries ( PDF reading 
/ writing, TIFF reading writing, Office File formats)

There were a few attempts for Java to Go conversions but not complete (if 
ever can be complete).

github.com/dglo/java2go (converter but not with UTF-8 capabilities)

https://github.com/timob/javaparser (java parser)

github.com/tinycedar/class-parser  (java class parser)

github.com/tinylcy/SmallVM (Java VM interpreter)

github.com/tinycedar/vanilla

All of these projects show the need to read from Java.

Is there any other project or effort to map java functions --> go or even a 
decent converter?

Any plans to make a decent converter from somebody?


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

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

I honestly don t know.

Seems my example is OK for you,
i really thought it was demonstrative 
of some confusion,
seems not.

If i m correct in following your understanding and comparisons,
in those two cases,

x := valueType{}
> x.SetName("yo!")
> fmt.Println(x.Name)
>
> y := {}
> y.SetName("yo!")
> fmt.Println(y.Name)
>

that the instance (x or y) is pointer or value 
does not matter because the receiver is a dictator.
And indeed it behaves so on the play.

I admit i never noticed before... 

Whatever, 
i did not understand, 
its flawed,
i failed to express appropriately,
no idea.

Most people do not
> think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
> for basically all natural usage these four things are just
> one, the number 3
>

i m a bit chocked, but ok, 
i can t find words to convince you that 
you mixed results and expression.

That is an error to think those 
4 different ways to express the same results
are identical in their form and identical in their result.
Some have identical parameters, ultimately,
they only share the same result.

Its typically a reasoning from mathematics, 
btw, just thinking.


On Thursday, May 11, 2017 at 1:08:30 PM UTC+2, Volker Dobler wrote:
>
> On Thursday, 11 May 2017 12:39:18 UTC+2, mhh...@gmail.com wrote:
>>
>>
>> I d only remark about this,
>> > so there are actually just two cases: Method is on pointer receiver or 
>> not. 
>>
>> From the declarer side, 
>> there is indeed only 2 cases, 
>> which accounts for 50% of the whole,
>> declaration + consumption,
>> the consumer is still accountable for the remaining
>> 50% of the instance consumption and usage.
>>
>>
> I do not agree. Your "other 50%" are indistinguishable,
> they have no observable difference. Most people do not
> think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
> for basically all natural usage these four things are just
> one, the number 3. It is the same here:
>
> var p *T
> p.M(), (*p).T, (&(*p)).T and so forth might be formally
> different but they are not.
>
> There a two things. Methods on pointer receivers and
> method on values and it does not matter in reasoning about
> the behaviour of the code on how the method is invoked.
>
> V.
>
>
>  
>

-- 
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] x/term: go-keycodes

[anatoly techtonik]

I am new to Go and I need a cross-platform value for keyboard key codes to 
make sure I can react to user key presses regardless of operating system 
layer.

Thanks to the feedback from other projects, 
namely https://github.com/eiannone/keyboard 
and https://github.com/depp/keycode I was able to compile a package with 
key codes at https://github.com/yakshaveinc/go-keycodes which I'd like to 
make more "pythonic" for Go, and ideally merge into x/term. I need help 
with reviewing the code for best practices so that it could be included in 
stdlib.

-- 
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: Runtime code generation?

[David Collier-Brown]

I've doen generate-and-execute in C that way, at the cost of using 
LD_PRELOAD and having to restart the program.  Go plugins should be better, 
as long as you don't have to drop one. Can you supercede one? It sort of 
looks like you could...  If so, Go could do theequivalent of unload.

--dave

-- 
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] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[ojucie]

Maybe a 100µs GC would be fast enough for you to be at easy with your game 
FPS.

https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ

On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:
>
> ARC would be a better option for game apps than GC, to keep the fps stable.
>

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

[go-nuts] Re: why received can be defined with/without pointer?

[Chris Hopkins]

I think what you're saying is that it's more natural and obvious that when 
you have a function that changes something it would be more obvious and 
simple if it actually did modify the thing you gave it.
Having to jump through hoops to actually make the change you asked for 
stick is annoying.

Yes? Is that what you mean? Is this a commentary on the effect this has on 
ease of code read and writability?

What I have come to realise recently by working on ever larger projects is 
that no that's not annoying. When debugging code I don't understand often 
half the challenge is working out how a piece of data has changed that 
shouldn't have been. In the world you describe anything that touched that 
variable could be to blame for my problems. If instead you have to jump 
through hoops to make modifications and those modifications are really 
obvious where they are happening you make debugging easier.
Forcing the behaviour that "functions/methods don't modify their associated 
structures" means people structure their code differently that in my 
experience means instead of code that reads:
foo.DoUsefulStuff(i) // has foo become corrupted? changed, who knows?

you instead see code like:
fred = foo.Lookup(i) // Complex function that changes nothing in foo
foo = foo.ReturnUsefulStuff(fred) // This returns a corrupted structure

For a start you look at the function definitions and see quickly that they 
are not modifying the underlying structures so it's quick to discount a 
large chunk of code as the a source of the problem. This is not so much of 
a problem in your examples but in large undocumented projects where you 
don't understand 99% of the code the small things make it much faster to 
isolate where things could be going wrong.

Please don't take this though as anything other than a commentary on the 
code I like to read. "Code is written for humans to read and only 
incidentally for machines to execute". I believe code is read by humans way 
more times than it is written, so anything at all that isolates the code 
and makes it easier to understand is worth putting time and effort into. 

YMMV

On Thursday, 11 May 2017 11:39:18 UTC+1, mhh...@gmail.com wrote:
>
> Hi,
>
> thanks again!
>
> I m not the one to validate a perfect answer,
> i can simply tell that from my go learning and understanding,
> i agree top notch 200% no question there 
> on this description,
> which is weird in fact.
>
> I d only remark about this,
> > so there are actually just two cases: Method is on pointer receiver or 
> not. 
>
> From the declarer side, 
> there is indeed only 2 cases, 
> which accounts for 50% of the whole,
> declaration + consumption,
> the consumer is still accountable for the remaining
> 50% of the instance consumption and usage.
>
> Does it make it less dead simple ?
>
> In my example i might have named the method as `whatever`,
> still there is an explicit value set on a receiver property.
> I don t feel like i have assumed anything from the method name.
>
>
> On Thursday, May 11, 2017 at 12:17:00 PM UTC+2, Volker Dobler wrote:
>>
>> On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:
>>>
>>> //defined
 var x {} // put on heap
 var x T // put on stack

 This is definitely a misconception: Allocation on heap vs stack is
 totaly unrelated to value methods vs pointer methods. Both examples
 might be allocated on the stack or on the heap and this depends
 on other factors than methods of T.

>>>
>>> what are other factors ? 
>>>
>>
>> Roughly: If the compiler cannot prove that x *can* be safely put on the
>> stack then it must go to the heap. Values cannot go safely to the stack
>> if they might outlive the scope of this stack frame / the current 
>> function.
>> This can happen if e.g. a pointer to such value leaves the function, e.g.
>> in a return or a channel send. Search for escape analysis if you are 
>> interested in the gory details, but I'd urge you not to until the basic 
>> stuff
>> is total clear.
>>  
>>
>>> (let s keep it short, optimized code is not a topic for me)
>>> I understood that the next func call (might be method) 
>>> will decide how the instance (to not say value here) is passed.
>>>
>>> is it ?
>>>
>>
>> Each and every function --- be it a normal function, a function literal,
>> a closure, a method, whatever --- completely determines its arguments.
>> This includes the receiver of a method which technical is just a normal
>> (the first) function argument.
>> A func f(int) is called with an argument of type int and a func g(*int) is
>> called with a *int. The same is true for receivers. There is *no* magic 
>> here! 
>>
>> The only thing "magical" with methods and their special receiver
>> argument that the compiler automatically (automagically) takes the
>> address of a value or dereferences a pointer to match the method
>> signature. That's all. That's convenience only. A bit less typing, a bit
>> fewer braces, it reads nicer.
>>
>> So: 

[go-nuts] Re: why received can be defined with/without pointer?

[Volker Dobler]

On Thursday, 11 May 2017 12:39:18 UTC+2, mhh...@gmail.com wrote:
>
>
> I d only remark about this,
> > so there are actually just two cases: Method is on pointer receiver or 
> not. 
>
> From the declarer side, 
> there is indeed only 2 cases, 
> which accounts for 50% of the whole,
> declaration + consumption,
> the consumer is still accountable for the remaining
> 50% of the instance consumption and usage.
>
>
I do not agree. Your "other 50%" are indistinguishable,
they have no observable difference. Most people do not
think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
for basically all natural usage these four things are just
one, the number 3. It is the same here:

var p *T
p.M(), (*p).T, (&(*p)).T and so forth might be formally
different but they are not.

There a two things. Methods on pointer receivers and
method on values and it does not matter in reasoning about
the behaviour of the code on how the method is invoked.

V.


 

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

Re: [go-nuts] Re: adding context.Context to new code

[mhhcbon]

thanks,

..integrating Context into the runtime..


50% runtime, 50% syntax with explicit contextualization.

..The flow of request processing in Go may include multiple goroutines and 
may move across channels;


yes big ? mark here. might the 50% of an handy and explicit syntax help 
with it?

C++ and Java use thread-local Contexts, and while this is convenient, it is 
often a source of mysterious bugs.

thanks! I don't know them, 

I quickly checked according to this 
https://dzone.com/articles/painless-introduction-javas-threadlocal-storage 
I may have totally wrong, the syntax does not look like, not even from a 
100km,
to how i represent go contexts in my head.

This is more like the actor pattern dave cheney talks about in
https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions
(search for  Let’s talk about actors)

Is the dzone link correctly describe 
what you mentioned as being go context equivalent in java ?

sorry my questions are so basic.

On Thursday, May 11, 2017 at 12:29:11 PM UTC+2, Sameer Ajmani wrote:
>
> I think you are asking whether we considered integrating Context into the 
> runtime, so that it does not need to be passed explicitly. Yes, we 
> discussed this, but decided against it. The flow of request processing in 
> Go may include multiple goroutines and may move across channels; we decided 
> an explicit Context made this much easier to get right. C++ and Java use 
> thread-local Contexts, and while this is convenient, it is often a source 
> of mysterious bugs.
> On Thu, May 11, 2017 at 4:08 AM  wrote:
>
>> Thanks a lot!
>>
>> Might i guess and try to generalize your explanations into
>> "we tried to write a plumber for all cases possible"
>>
>> Which matters a lot, in my humble opinion.
>>
>> At least for the various reasons you put there,
>> simply put,
>> because it seems not technically achievable.
>>
>> Still i m happy you gave me those details, they are of interest indeed.
>>
>> I rather intent to solve the problem on a smaller surface
>> with more predictability, less impossible solution to find.
>> I hope so.
>> And if it saves 90% of the time, that s already a win, imho.
>>
>> May i ask another question, 
>> have you considered to create the plumbing 
>> at runtime rather than statically ?
>> With some intents from the syntax, necessarily 
>> (and yeah go 1 compat will be a problem, let s forget it for 1 minute).
>>
>> I suspect in some aspects in might be handier, 
>> because it might be all about chained func calls and not type system 
>> handling,
>> and it might be easier to interleave the ctx.check in the flaw of ops,
>> I don t know enough to realize for sure.
>>
>>
>>
>> On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:
>>
>>> Our approach was to identify function calls that consume a Context 
>>> (indicated by a call to context.TODO in the function body) and function 
>>> calls that provide a Context (such as RPC and HTTP handlers). Then we use 
>>> the guru callgraph tool to find all call paths from context providers to 
>>> context consumers. These are the call paths that need to have a context 
>>> plumbed through them. 
>>>
>>> Starting from a context consumer, we can work upward to the context 
>>> provider, adding a context parameter to reach intervening function 
>>> signature. Replace context.TODO in the consumer function body with the new 
>>> ctx parameter, then update all the places that call the consumer to pass 
>>> context.TODO. Now we have a new set of context consumers. Repeat until you 
>>> reach the context providers (if you reach main or a Test function, pass 
>>> context.Background instead).
>>>
>>> This works OK for static function calls but gets messy for dynamic 
>>> calls. If you need to add a context parameter to an interface method, now 
>>> you have to update all implementations of that method, too (guru can find 
>>> these for you). And if that interface is outside your control (like 
>>> io.Writer), you cannot change its signature, so you have to pass the 
>>> context some other way (such as via the method receiver).
>>>
>>> This gets yet more complicated if you cannot make atomic changes to all 
>>> callers of your functions, because callers may be in other repositories. In 
>>> this case, you must do an incremental refactoring in multiple steps: each 
>>> change to a function signature involves adding a new function that has the 
>>> context parameter, then changing all existing calls to use the new 
>>> function, while preventing new calls to the old function, so that you can 
>>> finally delete it.
>>>
>>> Inside Google, we ended up not needing to build all this: Context was 
>>> introduced early enough that Go users could plumb it manually where needed. 
>>> I think a context plumbing tool could still be interesting and useful to 
>>> other Go users. I'd love to see someone build it! 
>>>
>>> S
>>>
>>> On Tue, May 9, 2017 at 10:54 AM  wrote:
>>>
 > 

Re: [go-nuts] strings and when to use them

[Ilya Kostarev]

On Wed, 10 May 2017 10:05:56 -0700 (PDT)
Zachary Kaplan  wrote:

> can somebody please explain to me when a function
> should to return a string as opposed to, say a []byte? thanks
> 
Just a few examples.
Strings can be keys in map[string]something, []byte can't be a key due
to them are non comparable.
You can loop over letters/rune in word with "for range string".  

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

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

Hi,

thanks again!

I m not the one to validate a perfect answer,
i can simply tell that from my go learning and understanding,
i agree top notch 200% no question there 
on this description,
which is weird in fact.

I d only remark about this,
> so there are actually just two cases: Method is on pointer receiver or 
not. 

>From the declarer side, 
there is indeed only 2 cases, 
which accounts for 50% of the whole,
declaration + consumption,
the consumer is still accountable for the remaining
50% of the instance consumption and usage.

Does it make it less dead simple ?

In my example i might have named the method as `whatever`,
still there is an explicit value set on a receiver property.
I don t feel like i have assumed anything from the method name.


On Thursday, May 11, 2017 at 12:17:00 PM UTC+2, Volker Dobler wrote:
>
> On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:
>>
>> //defined
>>> var x {} // put on heap
>>> var x T // put on stack
>>>
>>> This is definitely a misconception: Allocation on heap vs stack is
>>> totaly unrelated to value methods vs pointer methods. Both examples
>>> might be allocated on the stack or on the heap and this depends
>>> on other factors than methods of T.
>>>
>>
>> what are other factors ? 
>>
>
> Roughly: If the compiler cannot prove that x *can* be safely put on the
> stack then it must go to the heap. Values cannot go safely to the stack
> if they might outlive the scope of this stack frame / the current function.
> This can happen if e.g. a pointer to such value leaves the function, e.g.
> in a return or a channel send. Search for escape analysis if you are 
> interested in the gory details, but I'd urge you not to until the basic 
> stuff
> is total clear.
>  
>
>> (let s keep it short, optimized code is not a topic for me)
>> I understood that the next func call (might be method) 
>> will decide how the instance (to not say value here) is passed.
>>
>> is it ?
>>
>
> Each and every function --- be it a normal function, a function literal,
> a closure, a method, whatever --- completely determines its arguments.
> This includes the receiver of a method which technical is just a normal
> (the first) function argument.
> A func f(int) is called with an argument of type int and a func g(*int) is
> called with a *int. The same is true for receivers. There is *no* magic 
> here! 
>
> The only thing "magical" with methods and their special receiver
> argument that the compiler automatically (automagically) takes the
> address of a value or dereferences a pointer to match the method
> signature. That's all. That's convenience only. A bit less typing, a bit
> fewer braces, it reads nicer.
>
> So: Yes, it is. 
>
>
>>
>>> What can i do with `func (x *T)...` i can not do with `func (x T)`,
 except checking for T==nil ?

>>>
>>> Like explained several times in this thread:
>>> func (x *T) lets you modify *x 
>>>
>>
>> yes, i really want not to question
>>  the ability to modify a value in place.
>>
>> its really about its form.
>>
>> In this code,
>> starting at 0,
>> is case 1 not an aberration,
>> is case 3 is useless
>> https://play.golang.org/p/VyOfZyt7rw
>>
>> Note case 0 is expected to fail and might be detected.
>>
>> ?
>>
>
> All four cases a perfectly fine and useful.
> The problem here is *not* the language construct but probably
> your prejudice that a method called "SetName" should
> modify the x it is "applied" to in any case as it does e.g.
> in Java where there are no (non-primitive) value types.
>
> Let's use abstract function names and let's add some real
> code (as setters and getter in Go are a bit funny).
>
> type T { s string }
> func (t T) M(s string) {
>   if t.s == "" { t.s = "GET" }  // default HTTP method used if nothing 
> else selected
>   foo(t, s)
> }
>
> default := T{}
> default.M("bar")
> post := T{s: "POST"}
> post.M("bar")
>
> Can you see it? M operates on a copy of the value it is invoked
> on. Both default and post will be copied. The copy of default is
> modified and this modification is passed foo. This is nice and
> useful and there is no reason the disallow this type of code.
>
> It is really dead simple: If your methods intend to modify the receiver,
> the receiver must be a pointer. This is one simple rule, clear and
> straightforward, easy to remember and easy to derive in case one
> forgets it.
>
> Again. This all does not depend on what the x in x.M is. it can
> be a pointer or a value, the compiler will take the address or dereference
> as needed, so there are actually just two cases: Method is on
> pointer receiver or not. As I said. Dead simple.
>  
>
>>
>> Probably i miss some understanding about why i can do that,
>> - handle value handling in two places of the program
>> - at initialization, at consumption
>>
>> does it help ?
>>
>
> I'm sorry I do not understand the question.
>
>
> V. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 

Re: [go-nuts] Re: adding context.Context to new code

[Sameer Ajmani]

I think you are asking whether we considered integrating Context into the
runtime, so that it does not need to be passed explicitly. Yes, we
discussed this, but decided against it. The flow of request processing in
Go may include multiple goroutines and may move across channels; we decided
an explicit Context made this much easier to get right. C++ and Java use
thread-local Contexts, and while this is convenient, it is often a source
of mysterious bugs.
On Thu, May 11, 2017 at 4:08 AM  wrote:

> Thanks a lot!
>
> Might i guess and try to generalize your explanations into
> "we tried to write a plumber for all cases possible"
>
> Which matters a lot, in my humble opinion.
>
> At least for the various reasons you put there,
> simply put,
> because it seems not technically achievable.
>
> Still i m happy you gave me those details, they are of interest indeed.
>
> I rather intent to solve the problem on a smaller surface
> with more predictability, less impossible solution to find.
> I hope so.
> And if it saves 90% of the time, that s already a win, imho.
>
> May i ask another question,
> have you considered to create the plumbing
> at runtime rather than statically ?
> With some intents from the syntax, necessarily
> (and yeah go 1 compat will be a problem, let s forget it for 1 minute).
>
> I suspect in some aspects in might be handier,
> because it might be all about chained func calls and not type system
> handling,
> and it might be easier to interleave the ctx.check in the flaw of ops,
> I don t know enough to realize for sure.
>
>
>
> On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:
>
>> Our approach was to identify function calls that consume a Context
>> (indicated by a call to context.TODO in the function body) and function
>> calls that provide a Context (such as RPC and HTTP handlers). Then we use
>> the guru callgraph tool to find all call paths from context providers to
>> context consumers. These are the call paths that need to have a context
>> plumbed through them.
>>
>> Starting from a context consumer, we can work upward to the context
>> provider, adding a context parameter to reach intervening function
>> signature. Replace context.TODO in the consumer function body with the new
>> ctx parameter, then update all the places that call the consumer to pass
>> context.TODO. Now we have a new set of context consumers. Repeat until you
>> reach the context providers (if you reach main or a Test function, pass
>> context.Background instead).
>>
>> This works OK for static function calls but gets messy for dynamic calls.
>> If you need to add a context parameter to an interface method, now you have
>> to update all implementations of that method, too (guru can find these for
>> you). And if that interface is outside your control (like io.Writer), you
>> cannot change its signature, so you have to pass the context some other way
>> (such as via the method receiver).
>>
>> This gets yet more complicated if you cannot make atomic changes to all
>> callers of your functions, because callers may be in other repositories. In
>> this case, you must do an incremental refactoring in multiple steps: each
>> change to a function signature involves adding a new function that has the
>> context parameter, then changing all existing calls to use the new
>> function, while preventing new calls to the old function, so that you can
>> finally delete it.
>>
>> Inside Google, we ended up not needing to build all this: Context was
>> introduced early enough that Go users could plumb it manually where needed.
>> I think a context plumbing tool could still be interesting and useful to
>> other Go users. I'd love to see someone build it!
>>
>> S
>>
>> On Tue, May 9, 2017 at 10:54 AM  wrote:
>>
>>> > I've done a limited form of this using awk ;-)
>>>
>>> if you have a minute,
>>>
>>> can you tell more about what limited you
>>> in your attempts and which trade made you stop (guessing),
>>> if any ?
>>>
>>> Do you still think it be awesome ?
>>> Or have you made your mind to an opposite position ?
>>> if so, For which reasons?
>>>
>>> My tool is very poor, consider it as on going, a place for inspiration
>>> to get started from absolutely no idea to lets get a dirty prototype.
>>> not sure yet how long is going to be the road, still digging :)
>>>
>>>
>>> On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote:
>>>
 The eg tool can execute simple refactoring steps, but automating
 context plumbing through a chain of calls is an open problem. Alan Donovan
 put some thought into this a few years ago, and I've done a limited form of
 this using awk ;-)

>>> On Tue, May 9, 2017 at 6:10 AM  wrote:

>>> I want something similar too.
>
> Automatic and smart insertion of context args in a chain of calls.
>
> Methods signature updates are easy, but how to appropriately insert
> context check in the ast 

[go-nuts] Re: why received can be defined with/without pointer?

[Volker Dobler]

On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:
>
> //defined
>> var x {} // put on heap
>> var x T // put on stack
>>
>> This is definitely a misconception: Allocation on heap vs stack is
>> totaly unrelated to value methods vs pointer methods. Both examples
>> might be allocated on the stack or on the heap and this depends
>> on other factors than methods of T.
>>
>
> what are other factors ? 
>

Roughly: If the compiler cannot prove that x *can* be safely put on the
stack then it must go to the heap. Values cannot go safely to the stack
if they might outlive the scope of this stack frame / the current function.
This can happen if e.g. a pointer to such value leaves the function, e.g.
in a return or a channel send. Search for escape analysis if you are 
interested in the gory details, but I'd urge you not to until the basic 
stuff
is total clear.
 

> (let s keep it short, optimized code is not a topic for me)
> I understood that the next func call (might be method) 
> will decide how the instance (to not say value here) is passed.
>
> is it ?
>

Each and every function --- be it a normal function, a function literal,
a closure, a method, whatever --- completely determines its arguments.
This includes the receiver of a method which technical is just a normal
(the first) function argument.
A func f(int) is called with an argument of type int and a func g(*int) is
called with a *int. The same is true for receivers. There is *no* magic 
here! 

The only thing "magical" with methods and their special receiver
argument that the compiler automatically (automagically) takes the
address of a value or dereferences a pointer to match the method
signature. That's all. That's convenience only. A bit less typing, a bit
fewer braces, it reads nicer.

So: Yes, it is. 


>
>> What can i do with `func (x *T)...` i can not do with `func (x T)`,
>>> except checking for T==nil ?
>>>
>>
>> Like explained several times in this thread:
>> func (x *T) lets you modify *x 
>>
>
> yes, i really want not to question
>  the ability to modify a value in place.
>
> its really about its form.
>
> In this code,
> starting at 0,
> is case 1 not an aberration,
> is case 3 is useless
> https://play.golang.org/p/VyOfZyt7rw
>
> Note case 0 is expected to fail and might be detected.
>
> ?
>

All four cases a perfectly fine and useful.
The problem here is *not* the language construct but probably
your prejudice that a method called "SetName" should
modify the x it is "applied" to in any case as it does e.g.
in Java where there are no (non-primitive) value types.

Let's use abstract function names and let's add some real
code (as setters and getter in Go are a bit funny).

type T { s string }
func (t T) M(s string) {
  if t.s == "" { t.s = "GET" }  // default HTTP method used if nothing else 
selected
  foo(t, s)
}

default := T{}
default.M("bar")
post := T{s: "POST"}
post.M("bar")

Can you see it? M operates on a copy of the value it is invoked
on. Both default and post will be copied. The copy of default is
modified and this modification is passed foo. This is nice and
useful and there is no reason the disallow this type of code.

It is really dead simple: If your methods intend to modify the receiver,
the receiver must be a pointer. This is one simple rule, clear and
straightforward, easy to remember and easy to derive in case one
forgets it.

Again. This all does not depend on what the x in x.M is. it can
be a pointer or a value, the compiler will take the address or dereference
as needed, so there are actually just two cases: Method is on
pointer receiver or not. As I said. Dead simple.
 

>
> Probably i miss some understanding about why i can do that,
> - handle value handling in two places of the program
> - at initialization, at consumption
>
> does it help ?
>

I'm sorry I do not understand the question.


V. 

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

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

to be honest, i m killed because i agree 100% with that explanation.

I friendly scratch my head too because 
i m less interested by the implementation 
than by the packaging you put on it, 
and the effects that it produces on the end user,
if i can say so.

In that regards the explanation you gave can t 
help me to get that idea out of my head,
i think.


On Thursday, May 11, 2017 at 11:53:37 AM UTC+2, Chris Hopkins wrote:
>
>
>>
>> In this code,
>> starting at 0,
>> is case 1 not an aberration,
>> is case 3 is useless
>> https://play.golang.org/p/VyOfZyt7rw
>>
>> Note case 0 is expected to fail and might be detected.
>>
>>>
>>> As a dumb hardware engineer I too have struggled with this in the past.
> 2 rules I find helped:
> 1) Everything into a function is passed as a copy
> 2) If you need to modify something passed to you in a function then you 
> need not a copy of the thing but the address of the thing you want to modify
> so taking your code for both cases 0 & 1:
>  func (v valueType) SetName(n string) {
> v.Name = n
> }
> when this function runs a local bit of storage is created (probably on the 
> stack as escape analysis would determine that the value can't escape the 
> scope) and the current value of the data is copied into that storage. That 
> storage is then modified. The function then returns. The local storage goes 
> out of scope and you are left with your original data unchanged.
>
> for cases 2&3
> func (v *refType) SetName(n string) {
> v.Name = n
> }
> This time again the function runs and there is a local piece of storage 
> created (again called v) this time the local storage (probably on the stack 
> as v cannot escape the scope of that function) and v gets the pointer to 
> the variable it was called on copied into it instead of the value.
> So when you set the name it uses the local copy of the pointer to access 
> the Name field. Because this is pointing to the underlying storage for the 
> original structure that structure is modified. 
> What might be causing confusion here (because it used to confuse me with 
> go) is that go is doing something automatically under the hood. When you 
> type v.Name it knows that *refType does not have a field Name. It knows 
> that you're trying to access the structure addressed by the pointer and so 
> automatically de-references the pointer for you i.e. takes the address held 
> in v, works out what offset from that address it has to use to get at the 
> Name field and then directs the assignment to that new address.
>
> At least that's how I think it works. I'm sure someone will correct me, as 
> this would otherwise be the first time I had this low level detail of 
> software correct ;-)
>
> HTH
>
> Chris
>

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

[go-nuts] Re: why received can be defined with/without pointer?

[Chris Hopkins]

>
>
>
> In this code,
> starting at 0,
> is case 1 not an aberration,
> is case 3 is useless
> https://play.golang.org/p/VyOfZyt7rw
>
> Note case 0 is expected to fail and might be detected.
>
>>
>> As a dumb hardware engineer I too have struggled with this in the past.
2 rules I find helped:
1) Everything into a function is passed as a copy
2) If you need to modify something passed to you in a function then you 
need not a copy of the thing but the address of the thing you want to modify
so taking your code for both cases 0 & 1:
 func (v valueType) SetName(n string) {
v.Name = n
}
when this function runs a local bit of storage is created (probably on the 
stack as escape analysis would determine that the value can't escape the 
scope) and the current value of the data is copied into that storage. That 
storage is then modified. The function then returns. The local storage goes 
out of scope and you are left with your original data unchanged.

for cases 2&3
func (v *refType) SetName(n string) {
v.Name = n
}
This time again the function runs and there is a local piece of storage 
created (again called v) this time the local storage (probably on the stack 
as v cannot escape the scope of that function) and v gets the pointer to 
the variable it was called on copied into it instead of the value.
So when you set the name it uses the local copy of the pointer to access 
the Name field. Because this is pointing to the underlying storage for the 
original structure that structure is modified. 
What might be causing confusion here (because it used to confuse me with 
go) is that go is doing something automatically under the hood. When you 
type v.Name it knows that *refType does not have a field Name. It knows 
that you're trying to access the structure addressed by the pointer and so 
automatically de-references the pointer for you i.e. takes the address held 
in v, works out what offset from that address it has to use to get at the 
Name field and then directs the assignment to that new address.

At least that's how I think it works. I'm sure someone will correct me, as 
this would otherwise be the first time I had this low level detail of 
software correct ;-)

HTH

Chris

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

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

yeah i totally admit i don t master the subject at all,
and i would prefer not have to talk about heap/stack thing, 
by incidence what, still, bugs me is on the intersection
of many topics which make it difficult to talk about.

thanks again for your attempts even though i lost you 
and, i guess, hurt your love for English grammar, 
if you have any.

in this

//defined
> var x {} // put on heap
> var x T // put on stack
>
> This is definitely a misconception: Allocation on heap vs stack is
> totaly unrelated to value methods vs pointer methods. Both examples
> might be allocated on the stack or on the heap and this depends
> on other factors than methods of T.
>

what are other factors ? 
(let s keep it short, optimized code is not a topic for me)
I understood that the next func call (might be method) 
will decide how the instance (to not say value here) is passed.

is it ?


> What can i do with `func (x *T)...` i can not do with `func (x T)`,
>> except checking for T==nil ?
>>
>
> Like explained several times in this thread:
> func (x *T) lets you modify *x 
>

yes, i really want not to question
 the ability to modify a value in place.

its really about its form.

In this code,
starting at 0,
is case 1 not an aberration,
is case 3 is useless
https://play.golang.org/p/VyOfZyt7rw

Note case 0 is expected to fail and might be detected.

?

Probably i miss some understanding about why i can do that,
- handle value handling in two places of the program
- at initialization, at consumption

does it help ?

if not, no worries, i ll learn more and try again later.

On Saturday, May 6, 2017 at 9:39:56 AM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> Question about the receiver of a func.
>
> It can be defined as star/no star, and consumed as star/nostar.
>
> The understanding i have so far is,
> it let the developer define the memory model he d like to use.
>
> It leads to cases such as 
> - define start/nostar on a type
> - consume a stared type as a value
> - consume a value type as a pointer
>
> Which is quiet confusing for beginners, and me.
>
> While i understand that someone would like to declare
> a type is consumed by value, I do not understand the last two cases.
> when why they might happen.
>
> Can you explain their value added ?
>
> Thinking further more,
>
> Not speaking about dereferencing a pointer,
> but initialization of a type in a way that is undesired to the provider.
>
> The way a type is consumed by value or reference,
> is an act of design rules (i add a property on the type that make sure it 
> is never copied/referenced)
> or an act of consumption, 
> the designer did not enforce any rule on the type, i might initialize it 
> as star/nostar at convenience.
>
> The fact it is let possible today 
> - to not enforce the way a type is manipulated, 
>leads to confusion and error (famous one is https://godoc.org/sync)
> - to define at both declaration / usage the star/nostar,
>is confusing, again
>
> so yeah, wondering quiet a lot about that,
> and given the fact i do not understand few use cases,
> i think this could be better handled.
>
> For example, 
>
> if a new keyword appear to ensure a type is 
> consumed by value, that might be helpful to provide
> a function to make sure that type won t exceed the stack size
> and escape to the heap.
> that keyword would help api designer to avoid consumption problems.
> nop ?
>
> If a new keyword would appear to ensure a type is initialized by reference,
> might help to detect value copy and warn/error when that case is met.
> That would helped consumers to avoid problems.
> nop ?
>
> If the receiver type was not able to be star/nostar,
> that d probably help to get ride of confusion,
> nop ?
>

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

Re: [go-nuts] Re: [ANN] scaffolder - web application servers to order

[Simon Ritchie]

> PS: i remember you talked about it earlier, shame i missed it at that
time.

I've given a couple of talks that mention the scaffolder.  One was recorded
for posterity.  It was to the Linuxing in London meetup and it was about
running Go on a single board computer.  I used the scaffolder as an
example:  https://skillsmatter.com/skillscasts/9622-go-lang-on-linux

Regards

Simon

On Thu, May 11, 2017 at 9:37 AM,  wrote:

> It s awesome,
> in my opinion, this is the way i want to consume go in the future.
>
> pragmatic, correct, fast, repeatable.
>
> in additions to what go provides,
> fast build, cross platform, easy to package
>
> Although, my very personal opinion,
> lets do smaller program that combines together,
> in the spirit of unix tooling, rather than a
> big boiler plate thing in the spirit of symfony
> or alike (really just an example sorry i cited your project).
>
> A big Yes for such projects!
>
> Let s generate all the thing and get drinks to talk about it :D
>
> PS: i remember you talked about it earlier, shame i missed it at that time.
>
> On Wednesday, May 10, 2017 at 6:31:22 PM UTC+2, Simon Ritchie wrote:
>>
>> Given a JSON description of some database tables, the scaffolder tool
>> creates the database and generates a web application server to manage it.
>> The resulting app server implements the Create, Read, Update and Delete
>> (CRUD) operations on the tables.
>>
>> The idea for the scaffolder comes from the Ruby-on-Rails scaffold
>> generator.
>>
>> The app server is presented as Go source code and HTML templates, plus
>> some unit and integration tests.  The design follows the Model, View
>> Controller (MVC) pattern.  The HTTP requests follow the REST pattern.
>>
>> The tool is here:  https://github.com/goblimey/scaffolder
>>
>> There are some screen shots of the resulting web pages here:
>> http://www.goblimey.com/scaffolder/2.4.running.the.server.html
>>
>> Producing any web application involves a lot of boilerplate work, and
>> this tool aims to automate some of that without imposing too many design
>> decisions on the result.
>>
>> The generated web pages are fairly primitive, with very little styling.
>> This is deliberate - if you want to use the result as a basis for building
>> your own application, you will want to define your own styling, and the
>> pages are structured to allow that.
>>
>> The material produced by the scaffolder is defined by a set of text
>> templates.  For each table it produces from these templates a model, a
>> controller and set of HTML templates to produce the views.  (So we have
>> templates producing templates.)
>>
>> The scaffolder tool itself is very simple.  It just reads the JSON
>> specification into a data structure, enhances that data a little and then
>> iterates through it, supplying it to the templates.   This approach makes
>> the tool very flexible - if it doesn't do quite what you want, it's very
>> easy to tweak it.
>>
>> This idea of using a simple driver program, JSON data and templates to
>> generate a result is very powerful.  It can be used to produce all sorts of
>> material that follows a prototypical pattern.
>>
>> All comment on this project are welcome.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/_WxygmYF1F8/unsubscribe.
> To unsubscribe from this group and all its topics, 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: [ANN] scaffolder - web application servers to order

[mhhcbon]

It s awesome, 
in my opinion, this is the way i want to consume go in the future.

pragmatic, correct, fast, repeatable.

in additions to what go provides, 
fast build, cross platform, easy to package

Although, my very personal opinion,
lets do smaller program that combines together,
in the spirit of unix tooling, rather than a
big boiler plate thing in the spirit of symfony 
or alike (really just an example sorry i cited your project).

A big Yes for such projects!

Let s generate all the thing and get drinks to talk about it :D

PS: i remember you talked about it earlier, shame i missed it at that time.

On Wednesday, May 10, 2017 at 6:31:22 PM UTC+2, Simon Ritchie wrote:
>
> Given a JSON description of some database tables, the scaffolder tool 
> creates the database and generates a web application server to manage it.  
> The resulting app server implements the Create, Read, Update and Delete 
> (CRUD) operations on the tables.
>
> The idea for the scaffolder comes from the Ruby-on-Rails scaffold 
> generator.
>
> The app server is presented as Go source code and HTML templates, plus 
> some unit and integration tests.  The design follows the Model, View 
> Controller (MVC) pattern.  The HTTP requests follow the REST pattern.
>
> The tool is here:  https://github.com/goblimey/scaffolder
>
> There are some screen shots of the resulting web pages here:   
> http://www.goblimey.com/scaffolder/2.4.running.the.server.html
>
> Producing any web application involves a lot of boilerplate work, and this 
> tool aims to automate some of that without imposing too many design 
> decisions on the result.  
>
> The generated web pages are fairly primitive, with very little styling.  
> This is deliberate - if you want to use the result as a basis for building 
> your own application, you will want to define your own styling, and the 
> pages are structured to allow that.
>
> The material produced by the scaffolder is defined by a set of text 
> templates.  For each table it produces from these templates a model, a 
> controller and set of HTML templates to produce the views.  (So we have 
> templates producing templates.)
>
> The scaffolder tool itself is very simple.  It just reads the JSON 
> specification into a data structure, enhances that data a little and then 
> iterates through it, supplying it to the templates.   This approach makes 
> the tool very flexible - if it doesn't do quite what you want, it's very 
> easy to tweak it.
>
> This idea of using a simple driver program, JSON data and templates to 
> generate a result is very powerful.  It can be used to produce all sorts of 
> material that follows a prototypical pattern.
>
> All comment on this project are welcome.
>

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

Re: [go-nuts] Re: adding context.Context to new code

[mhhcbon]

Thanks a lot!

Might i guess and try to generalize your explanations into
"we tried to write a plumber for all cases possible"

Which matters a lot, in my humble opinion.

At least for the various reasons you put there,
simply put,
because it seems not technically achievable.

Still i m happy you gave me those details, they are of interest indeed.

I rather intent to solve the problem on a smaller surface
with more predictability, less impossible solution to find.
I hope so.
And if it saves 90% of the time, that s already a win, imho.

May i ask another question, 
have you considered to create the plumbing 
at runtime rather than statically ?
With some intents from the syntax, necessarily 
(and yeah go 1 compat will be a problem, let s forget it for 1 minute).

I suspect in some aspects in might be handier, 
because it might be all about chained func calls and not type system 
handling,
and it might be easier to interleave the ctx.check in the flaw of ops,
I don t know enough to realize for sure.


On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:
>
> Our approach was to identify function calls that consume a Context 
> (indicated by a call to context.TODO in the function body) and function 
> calls that provide a Context (such as RPC and HTTP handlers). Then we use 
> the guru callgraph tool to find all call paths from context providers to 
> context consumers. These are the call paths that need to have a context 
> plumbed through them. 
>
> Starting from a context consumer, we can work upward to the context 
> provider, adding a context parameter to reach intervening function 
> signature. Replace context.TODO in the consumer function body with the new 
> ctx parameter, then update all the places that call the consumer to pass 
> context.TODO. Now we have a new set of context consumers. Repeat until you 
> reach the context providers (if you reach main or a Test function, pass 
> context.Background instead).
>
> This works OK for static function calls but gets messy for dynamic calls. 
> If you need to add a context parameter to an interface method, now you have 
> to update all implementations of that method, too (guru can find these for 
> you). And if that interface is outside your control (like io.Writer), you 
> cannot change its signature, so you have to pass the context some other way 
> (such as via the method receiver).
>
> This gets yet more complicated if you cannot make atomic changes to all 
> callers of your functions, because callers may be in other repositories. In 
> this case, you must do an incremental refactoring in multiple steps: each 
> change to a function signature involves adding a new function that has the 
> context parameter, then changing all existing calls to use the new 
> function, while preventing new calls to the old function, so that you can 
> finally delete it.
>
> Inside Google, we ended up not needing to build all this: Context was 
> introduced early enough that Go users could plumb it manually where needed. 
> I think a context plumbing tool could still be interesting and useful to 
> other Go users. I'd love to see someone build it! 
>
> S
>
> On Tue, May 9, 2017 at 10:54 AM  wrote:
>
>> > I've done a limited form of this using awk ;-)
>>
>> if you have a minute,
>>
>> can you tell more about what limited you 
>> in your attempts and which trade made you stop (guessing), 
>> if any ?
>>
>> Do you still think it be awesome ? 
>> Or have you made your mind to an opposite position ? 
>> if so, For which reasons?
>>
>> My tool is very poor, consider it as on going, a place for inspiration to 
>> get started from absolutely no idea to lets get a dirty prototype.
>> not sure yet how long is going to be the road, still digging :)
>>
>>
>> On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote:
>>
>>> The eg tool can execute simple refactoring steps, but automating context 
>>> plumbing through a chain of calls is an open problem. Alan Donovan put some 
>>> thought into this a few years ago, and I've done a limited form of this 
>>> using awk ;-)
>>>
>> On Tue, May 9, 2017 at 6:10 AM  wrote:
>>>
>> I want something similar too.

 Automatic and smart insertion of context args in a chain of calls.

 Methods signature updates are easy, but how to appropriately insert 
 context check in the ast  ?
 I m not sure yet.


 >The difficulty here seems to differentiate intra package calls from 
 calls to standard/3rd party libraries which shouldn't be having new param.

 That does not sound too difficult, from the pkg identifier, lookup for 
 the import path, for every import path, exists in GOROOT ?

 Please put updates here anything you want to share.

 At that moment i m using this package to help me with ast, 
 https://github.com/mh-cbon/astutil

 might be a start even though it needs refactoring.


 On Monday, May 8,