Re: [go-nuts] lock for assigning to different elements of an array

[Dave Cheney]

I'm not really sure what you are asking. I think your second paragraph got 
eaten by autocorrect at the critical point. Could try maybe asking your 
question in a different way?

-- 
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] lock for assigning to different elements of an array

[Henrik Johansson]

How should I know when it is safe to omit using locks? What I have drilled
into my head is "yes you not only need a lock but every read of shared data
has to have a corresponding write that uses a lock". Lock meaning anything
that results in the proper memory effects.

I can sort of get that this example with only writers that operate on a
properly initialized slice can work but in general what is safe to do? Is
it in the memory model? Assignment to a position in a slice seems very much
like assignment of an interesting but for that we have the sync/atomic
package so why is this safe? Is it simply because there are no readers?

On Thu, 3 Aug 2017, 01:14 Dave Cheney,  wrote:

> No, but anything reading from that array which is not the original writer
> will have to coordinate via a lock or channel to ensure a proper happens
> before relationship exists.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] look for a example: call a DLL's function on Windows by CGO

[Fino]

yesterday I just found that, the syscall way to use DLL on Windows cannot 
use float32 as parameters, 

so I am look for a example:  call a DLL's function on Windows in the  CGO 
way, 

the DLL is not Windows' own DLL, but a third-party DLL which have a lot of 
double parameters, 

thanks in advance, 

BR fino 

-- 
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: gobind generated constructor for struct containing []byte sometimes corrupts data

[Antonio Marcedone]

My intuition above seems to contrast with 
https://godoc.org/golang.org/x/mobile/cmd/gobind:

Avoid reference cycles
> The language bindings maintain a reference to each object that has been 
> proxied. When a proxy object becomes unreachable, its finalizer reports 
> this fact to the object's native side, so that the reference can be 
> removed, potentially allowing the object to be reclaimed by its native 
> garbage collector. The mechanism is symmetric.

 

On Wednesday, August 2, 2017 at 5:30:16 PM UTC-7, Antonio Marcedone wrote:
>
> I am not sure I understand what is going on here.
> For reference, the relevant code is:
>
> String s = "This is a test string";
>
> MyStruct struct = new MyStruct(s.getBytes("UTF-8"));
> //struct.setE(s.getBytes("UTF-8"));
> tv.append("\nFirst time: "+ new String(struct.getE(), "UTF-8"));
>
>
> with corresponding go part:
>
> package test
>
> type MyStruct struct{
> E []byte}
>
> func NewMyStruct(e []byte) *MyStruct{
> return {e}}
>
>
> so s.getBytes allocates a new byte[] (in Java). Then the MyStruct 
> constructor is called, and it gets a reference to such byte[]. 
> Are you saying that since the Java garbage collector is not aware that a 
> reference to that array is stored in some variable in the go code, then it 
> just deletes it as soon as the constructor returns? 
> And then the getE method just reads whatever happens to be in memory where 
> the old array was without throwing any error despite the fact that the old 
> byte[] has been garbage collected and might have been overwritten by 
> arbitrary data?
>
> Thanks a lot for your response!
> Antonio
>
> On Wednesday, August 2, 2017 at 3:30:06 PM UTC-7, Elias Naur wrote:
>>
>> []byte arguments are passed by reference, not copied. You need to copy 
>> any byte slices you retain after the function or method call.
>>
>>  - elias
>>
>

-- 
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: gobind generated constructor for struct containing []byte sometimes corrupts data

[Antonio Marcedone]

I am not sure I understand what is going on here.
For reference, the relevant code is:

String s = "This is a test string";

MyStruct struct = new MyStruct(s.getBytes("UTF-8"));
//struct.setE(s.getBytes("UTF-8"));
tv.append("\nFirst time: "+ new String(struct.getE(), "UTF-8"));


with corresponding go part:

package test

type MyStruct struct{
E []byte}

func NewMyStruct(e []byte) *MyStruct{
return {e}}


so s.getBytes allocates a new byte[] (in Java). Then the MyStruct 
constructor is called, and it gets a reference to such byte[]. 
Are you saying that since the Java garbage collector is not aware that a 
reference to that array is stored in some variable in the go code, then it 
just deletes it as soon as the constructor returns? 
And then the getE method just reads whatever happens to be in memory where 
the old array was without throwing any error despite the fact that the old 
byte[] has been garbage collected and might have been overwritten by 
arbitrary data?

Thanks a lot for your response!
Antonio

On Wednesday, August 2, 2017 at 3:30:06 PM UTC-7, Elias Naur wrote:
>
> []byte arguments are passed by reference, not copied. You need to copy any 
> byte slices you retain after the function or method call.
>
>  - elias
>

-- 
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: gobind generated constructor for struct containing []byte sometimes corrupts data

[amarcedone via golang-nuts]

I am not sure I understand what is going on here.
For reference, the relevant code is:

String s = "This is a test string";

MyStruct struct = new MyStruct(s.getBytes("UTF-8"));
//struct.setE(s.getBytes("UTF-8"));
tv.append("\nFirst time: "+ new String(struct.getE(), "UTF-8"));


with corresponding go part:

package test

type MyStruct struct{
E []byte}

func NewMyStruct(e []byte) *MyStruct{
return {e}}


so s.getBytes allocates a new byte[] (in Java). Then the MyStruct 
constructor is called, and it gets a reference to such byte[]. 
Are you saying that since the Java garbage collector is not aware that a 
reference to that array is stored in some variable in the go code, then it 
just deletes it as soon as the constructor returns? 
And then the getE method just reads whatever happens to be in memory where 
the old array was without throwing any error despite the fact that the old 
byte[] has been garbage collected and might have been overwritten by 
arbitrary data?

Thanks a lot for your response!
Antonio

On Wednesday, August 2, 2017 at 3:30:06 PM UTC-7, Elias Naur wrote:
>
> []byte arguments are passed by reference, not copied. You need to copy any 
> byte slices you retain after the function or method call.
>
>  - elias
>

-- 
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] lock for assigning to different elements of an array

[Dave Cheney]

No, but anything reading from that array which is not the original writer will 
have to coordinate via a lock or channel to ensure a proper happens before 
relationship exists. 

-- 
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] gobind generated constructor for struct containing []byte sometimes corrupts data

[Elias Naur]

[]byte arguments are passed by reference, not copied. You need to copy any byte 
slices you retain after the function or method call.

 - elias

-- 
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] lock for assigning to different elements of an array

[Ian Lance Taylor]

On Wed, Aug 2, 2017 at 2:12 PM, rabiee via golang-nuts
 wrote:
>
> Do we need a lock for assigning to different elements of an array while
> running parallel functions?

No.

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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] lock for assigning to different elements of an array

[rabiee via golang-nuts]

Hi All,

Do we need a lock for assigning to different elements of an array while 
running parallel functions? For example is lock needed in the following 
code or not.

var rm sync.Mutex
var ts [2]stringfor i, s := range []string{"first", "second"} { i, s := i, s
go func(){  rm.Lock()   ts[i] = s   
rm.Unlock() }()}



Many thanks,
Ladan

-- 
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: HTTP/2 multiplexing

[James Abley]

A goroutine making each request, passing in the http.Client should work.

Something like http://blog.narenarya.in/concurrent-http-in-go.html

On Wed, 2 Aug 2017 at 18:58  wrote:

> Parallel in the sense of HTTP/2 multiplexing, i.e. sending the next
> request without having to wait for the reply of the previous one.
>
> --
> 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/5T5aiDRl_cw/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.

Re: [go-nuts] How to judge error in golang?

[Ian Lance Taylor]

On Wed, Aug 2, 2017 at 11:36 AM, yihao yang  wrote:
>
> I found it is very difficult to judge an error in golang. For example, if I
> want to judge a specific error returned by a function, but sometimes the
> error is just newed by errors.New(xxx).
> In those situations, should I just compare the error string to know what's
> the exact error? Is that a go-way to do so? I'm a little confused.

I don't think there is any one answer at this point.  A couple of
things to read:

https://blog.golang.org/errors-are-values
https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to judge error in golang?

[Jakob Borg]

On 2 Aug 2017, at 20:40, yihao yang  wrote:
> 
> What is the philosophy in golang error? I also saw a lot of packages have 
> their own Error override error interface. Why there is no shared Error 
> structure with a shareable error code?
> 
> 在 2017年8月2日星期三 UTC-7上午11:36:11，yihao yang写道：
> Hi,
> 
> I found it is very difficult to judge an error in golang. For example, if I 
> want to judge a specific error returned by a function, but sometimes the 
> error is just newed by errors.New(xxx).
> In those situations, should I just compare the error string to know what's 
> the exact error? Is that a go-way to do so? I'm a little confused.

In most cases you just care whether something succeeded or failed. If it failed 
you report the error and abort or continue down an alternative path. What the 
error was, exactly, might not matter.

For the cases where it does matter, the package should provide a way to 
distinguish those errors. Typical ways to do this are comparisons against an 
example error (... == io.EOF), usage of a package level function 
(os.IsNotExist(...)), or asserting to an interface that provides additional 
methods (net.OpError#IsTemporary() for example).

Having to care but not getting anything better to go on than the error string 
is a package design error.

//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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to judge error in golang?

[yihao yang]

What is the philosophy in golang error? I also saw a lot of packages 
have their own Error override error interface. Why there is no shared Error 
structure with a shareable error code?

在 2017年8月2日星期三 UTC-7上午11:36:11，yihao yang写道：
>
> Hi,
>
> I found it is very difficult to judge an error in golang. For example, if 
> I want to judge a specific error returned by a function, but sometimes the 
> error is just newed by errors.New(xxx).
> In those situations, should I just compare the error string to know what's 
> the exact error? Is that a go-way to do so? I'm a little confused.
>
> Thanks,
> Yihao
>

-- 
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] How to judge error in golang?

[yihao yang]

Hi,

I found it is very difficult to judge an error in golang. For example, if I 
want to judge a specific error returned by a function, but sometimes the 
error is just newed by errors.New(xxx).
In those situations, should I just compare the error string to know what's 
the exact error? Is that a go-way to do so? I'm a little confused.

Thanks,
Yihao

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

Re: [go-nuts] Re: GO Vs D

[Michael Jones]

If I was unclear...I do not mean that Go is the ultimate answer to those
questions, or that D (or whatever) is the anthesis of them. I wish Go was
different in various ways too.

On Wed, Aug 2, 2017 at 8:39 AM,  wrote:

> I'm still not convinced that using a language which is especially limited
> by design always helps in implementing the simplest solution, that will be
> the easiest to maintain.
>
> Maybe it's the case most of the time, but from my personal experience, you
> can only get that result by using the right tool for the right job.
>
> And by "right" I mean the simplest tool which gets you the right result.
>
> Fortunately, that doesn't happen all the time, but sometimes Go doesn't
> give gou that simplest tool, and in that case I severely regret I wasn't
> trusted enough so that they let me choose that appropriate tool.
>
> Le mercredi 2 août 2017 15:26:09 UTC+1, Michael Jones a écrit :
>>
>> I've often found it helpful to consider extreme limit cases.
>>
>> In solo/school/hobby programming, you code and test more than you debug
>> and you understand intent implicitly because you are coding it as you go.
>> As a professional at work, as part of a team, in a code review regime,
>> using third-party libraries, evolving large systems, the time distribution
>> between coding, testing, debugging, and understanding are different. What
>> is the limit case?
>>
>> The (hypothetical) limit would be no coding and all testing, debugging,
>> and understanding. Make it theatrical--the meteor will destroy the Earth
>> unless you alone can find the bugs in the billion-line space shield
>> software system during the next few days or hours. Now, in such a case,
>> think what language and ecosystem features might be helpful. Which are
>> neutral? Which might hurt?
>>
>> I have my own answers, but I raise this to encourage to consider the
>> question for themselves. If you do, I expect that you'll see matters at
>> issue from a different point of view, from a new perspective that will
>> bring a different concept of value. Even though the situation is rather
>> extreme, it has much in common with most programming in the large.
>>
>> On Wed, Aug 2, 2017 at 3:43 AM Egon  wrote:
>>
>>> Yes, I would agree -- the type declarations won't bother you in
>>> real-world, because when they become unreadable, then you would use
>>> additional types to clarify them... in any language.
>>>
>>> *And, I have nothing against either languages -- I used D in my BSc
>>> thesis and Go in my MSc thesis.*
>>>
>>> The main difference, as I see, is that Go is much more restricted, which
>>> means you have to work harder to fit your code into that model, leading to
>>> better structures overall. Over time you will learn the simpler ways of
>>> structuring your code. With D you have a tons of flexibility, which means
>>> often your first idea, what to write, succeeds -- which means the design
>>> will be less polished. Also this means that you won't tacitly learn to
>>> simplify your code.
>>>
>>> Yes, you can also write as simple code in D as in Go; the caveat is that
>>> Go forces you more into that direction... at the cost of flexibility of the
>>> language. So you can write more complex and complected code in D -- for
>>> better and worse.
>>>
>>> + Egon
>>>
>>> On Wednesday, 2 August 2017 13:25:06 UTC+3, ecstati...@gmail.com wrote:

 Ok I understand you now. Maybe I'm biased because I like both
 languages, but I'm not convinced that this example illustrates well Go's
 simplicity compared to D.

 For 99% of my *personal* daily use of both languages, very honestly,
 I've never felt that using types, functions, arrays, etc etc was simpler in
 Go compared to D.

 Even for more complex stuff like concurrency, I think that both
 languages still remain quite close, despite I think that Go's channel
 system is the best approach to the problem.

 On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote:
>
> The example contained 3 versions, C, D and Go.
>
> function pointer tables aren't that uncommon, maybe the []error part
> is uncommon
>
> Examples from real world code:
>
> https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
> https://github.com/ethereum/go-ethereum/blob/master/crypto/
> sha3/sha3_test.go#L40
> https://github.com/jteeuwen/go-bindata/blob/master/testdata/
> out/compress-memcopy.go#L205
> https://github.com/golang/net/blob/master/proxy/proxy.go#L57
> https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
> https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
> https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23
>
> And I've used it in Go, Java, C#, JavaScript, Delphi, C...
>
> The main reason you don't see these one-liners often in C, D et. al.
> is because they are hard to read.

[go-nuts] Re: Problems buildding go from source, tests "hangs"

['Bryan C. Mills' via golang-nuts]

What is the output of `$(go env CC) --version` on your machine?`

On Wednesday, August 2, 2017 at 8:31:37 AM UTC-4, SauliusGurklys wrote:
>
> Hi,
>
> while building go from source:
>
> cd /usr/local/src/go
> ./clean.bash
> ./all.bash
>
> build succeeds without any problem and then when tests are started then 
> they just "hangs"
>
> ...
> # ../misc/cgo/testplugin
> PASS
> something
>
> # ../misc/cgo/testasan
>
> # ../misc/cgo/testsanitizers
>
> after this point nothing happens (tried to wait for a couple of days).
> I tried many times, but "hanging" happens at this test(s).
>
> I building go, the same way, on several machines, and this problem happens 
> only on one of them.
>
> The "problem" machine is
>
> $ lsb_release -a
> LSB Version:n/a
> Distributor ID: ManjaroLinux
> Description:Manjaro Linux
> Release:17.0.2
> Codename:   Gellivara
>
> $ uname -a
> Linux bubo 4.12.3-1-MANJARO #1 SMP PREEMPT Fri Jul 21 09:37:31 UTC 2017 
> x86_64 GNU/Linux
>
> Maybe somebody had and solved such problem?
> Any thoughts?
>
> Kind regards,
> --
> Saulius
>
>
>

-- 
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: HTTP/2 multiplexing

[pala . daniele]

Parallel in the sense of HTTP/2 multiplexing, i.e. sending the next request 
without having to wait for the reply of the previous one.

-- 
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] Problems buildding go from source, tests "hangs"

[Ian Lance Taylor]

On Wed, Aug 2, 2017 at 5:17 AM, SauliusGurklys  wrote:
>
> while building go from source:
>
> cd /usr/local/src/go
> ./clean.bash
> ./all.bash
>
> build succeeds without any problem and then when tests are started then they
> just "hangs"
>
> ...
> # ../misc/cgo/testplugin
> PASS
> something
>
> # ../misc/cgo/testasan
>
> # ../misc/cgo/testsanitizers
>
> after this point nothing happens (tried to wait for a couple of days).
> I tried many times, but "hanging" happens at this test(s).
>
> I building go, the same way, on several machines, and this problem happens
> only on one of them.
>
> The "problem" machine is
>
> $ lsb_release -a
> LSB Version:n/a
> Distributor ID: ManjaroLinux
> Description:Manjaro Linux
> Release:17.0.2
> Codename:   Gellivara
>
> $ uname -a
> Linux bubo 4.12.3-1-MANJARO #1 SMP PREEMPT Fri Jul 21 09:37:31 UTC 2017
> x86_64 GNU/Linux
>
> Maybe somebody had and solved such problem?

I've sent https://golang.org/cl/52790 to try to avoid this build problem.

This seems to be another version of https://golang.org/issue/21196.

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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: HTTP/2 multiplexing

[Tamás Gulácsi]

Parallel, on the same connection? How?
Which byte shall be sent next?
TCP is essentially sequential, sorry.

-- 
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] [ANN] Gokoban - 3D Puzzle Game written in Go!

[Ian Lance Taylor]

On Mon, Jul 31, 2017 at 6:04 PM, Daniel Salvadori 
wrote:

> Hi everyone,
>
> I made an open-source 3D puzzle game with Go. It's called Gokoban
> !
> You control the Go gopher, and your objective in each level is to push
> the boxes until they are all on top of the yellow pads.
> There are elevators that help you reach high places and move boxes up and
> down.
> It was created using G3N  for the April-July
> 2017 Gopher Game Jam .
>

Nice game, thanks.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: GO Vs D

[eric . pelzer]

I'm still not convinced that using a language which is especially limited 
by design always helps in implementing the simplest solution, that will be 
the easiest to maintain.

Maybe it's the case most of the time, but from my personal experience, you 
can only get that result by using the right tool for the right job. 

And by "right" I mean the simplest tool which gets you the right result.

Fortunately, that doesn't happen all the time, but sometimes Go doesn't 
give gou that simplest tool, and in that case I severely regret I wasn't 
trusted enough so that they let me choose that appropriate tool.

Le mercredi 2 août 2017 15:26:09 UTC+1, Michael Jones a écrit :
>
> I've often found it helpful to consider extreme limit cases. 
>
> In solo/school/hobby programming, you code and test more than you debug 
> and you understand intent implicitly because you are coding it as you go. 
> As a professional at work, as part of a team, in a code review regime, 
> using third-party libraries, evolving large systems, the time distribution 
> between coding, testing, debugging, and understanding are different. What 
> is the limit case?
>
> The (hypothetical) limit would be no coding and all testing, debugging, 
> and understanding. Make it theatrical--the meteor will destroy the Earth 
> unless you alone can find the bugs in the billion-line space shield 
> software system during the next few days or hours. Now, in such a case, 
> think what language and ecosystem features might be helpful. Which are 
> neutral? Which might hurt? 
>
> I have my own answers, but I raise this to encourage to consider the 
> question for themselves. If you do, I expect that you'll see matters at 
> issue from a different point of view, from a new perspective that will 
> bring a different concept of value. Even though the situation is rather 
> extreme, it has much in common with most programming in the large.
>
> On Wed, Aug 2, 2017 at 3:43 AM Egon  
> wrote:
>
>> Yes, I would agree -- the type declarations won't bother you in 
>> real-world, because when they become unreadable, then you would use 
>> additional types to clarify them... in any language.
>>
>> *And, I have nothing against either languages -- I used D in my BSc 
>> thesis and Go in my MSc thesis.*
>>
>> The main difference, as I see, is that Go is much more restricted, which 
>> means you have to work harder to fit your code into that model, leading to 
>> better structures overall. Over time you will learn the simpler ways of 
>> structuring your code. With D you have a tons of flexibility, which means 
>> often your first idea, what to write, succeeds -- which means the design 
>> will be less polished. Also this means that you won't tacitly learn to 
>> simplify your code.
>>
>> Yes, you can also write as simple code in D as in Go; the caveat is that 
>> Go forces you more into that direction... at the cost of flexibility of the 
>> language. So you can write more complex and complected code in D -- for 
>> better and worse.
>>
>> + Egon
>>
>> On Wednesday, 2 August 2017 13:25:06 UTC+3, ecstati...@gmail.com wrote:
>>>
>>> Ok I understand you now. Maybe I'm biased because I like both languages, 
>>> but I'm not convinced that this example illustrates well Go's simplicity 
>>> compared to D.
>>>
>>> For 99% of my *personal* daily use of both languages, very honestly, 
>>> I've never felt that using types, functions, arrays, etc etc was simpler in 
>>> Go compared to D.
>>>
>>> Even for more complex stuff like concurrency, I think that both 
>>> languages still remain quite close, despite I think that Go's channel 
>>> system is the best approach to the problem.
>>>
>>> On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote:

 The example contained 3 versions, C, D and Go.

 function pointer tables aren't that uncommon, maybe the []error part is 
 uncommon

 Examples from real world code:

 https://github.com/egonelbre/fedwiki/blob/master/action.go#L59

 https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40

 https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
 https://github.com/golang/net/blob/master/proxy/proxy.go#L57
 https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
 https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
 https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23

 And I've used it in Go, Java, C#, JavaScript, Delphi, C...

 The main reason you don't see these one-liners often in C, D et. al. is 
 because they are hard to read.

 For common C, C++ examples, see signal and interrupt vector tables.

 On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:
>
> Still waiting the Go version of this very useful D code...
>
> I'm not asking you to browse the web to find to find most complex 

Re: [go-nuts] Re: GO Vs D

[Michael Jones]

I've often found it helpful to consider extreme limit cases.

In solo/school/hobby programming, you code and test more than you debug and
you understand intent implicitly because you are coding it as you go. As a
professional at work, as part of a team, in a code review regime, using
third-party libraries, evolving large systems, the time distribution
between coding, testing, debugging, and understanding are different. What
is the limit case?

The (hypothetical) limit would be no coding and all testing, debugging, and
understanding. Make it theatrical--the meteor will destroy the Earth unless
you alone can find the bugs in the billion-line space shield software
system during the next few days or hours. Now, in such a case, think what
language and ecosystem features might be helpful. Which are neutral? Which
might hurt?

I have my own answers, but I raise this to encourage to consider the
question for themselves. If you do, I expect that you'll see matters at
issue from a different point of view, from a new perspective that will
bring a different concept of value. Even though the situation is rather
extreme, it has much in common with most programming in the large.

On Wed, Aug 2, 2017 at 3:43 AM Egon  wrote:

> Yes, I would agree -- the type declarations won't bother you in
> real-world, because when they become unreadable, then you would use
> additional types to clarify them... in any language.
>
> *And, I have nothing against either languages -- I used D in my BSc thesis
> and Go in my MSc thesis.*
>
> The main difference, as I see, is that Go is much more restricted, which
> means you have to work harder to fit your code into that model, leading to
> better structures overall. Over time you will learn the simpler ways of
> structuring your code. With D you have a tons of flexibility, which means
> often your first idea, what to write, succeeds -- which means the design
> will be less polished. Also this means that you won't tacitly learn to
> simplify your code.
>
> Yes, you can also write as simple code in D as in Go; the caveat is that
> Go forces you more into that direction... at the cost of flexibility of the
> language. So you can write more complex and complected code in D -- for
> better and worse.
>
> + Egon
>
> On Wednesday, 2 August 2017 13:25:06 UTC+3, ecstati...@gmail.com wrote:
>>
>> Ok I understand you now. Maybe I'm biased because I like both languages,
>> but I'm not convinced that this example illustrates well Go's simplicity
>> compared to D.
>>
>> For 99% of my *personal* daily use of both languages, very honestly,
>> I've never felt that using types, functions, arrays, etc etc was simpler in
>> Go compared to D.
>>
>> Even for more complex stuff like concurrency, I think that both languages
>> still remain quite close, despite I think that Go's channel system is the
>> best approach to the problem.
>>
>> On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote:
>>>
>>> The example contained 3 versions, C, D and Go.
>>>
>>> function pointer tables aren't that uncommon, maybe the []error part is
>>> uncommon
>>>
>>> Examples from real world code:
>>>
>>> https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
>>>
>>> https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40
>>>
>>> https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
>>> https://github.com/golang/net/blob/master/proxy/proxy.go#L57
>>> https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
>>> https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
>>> https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23
>>>
>>> And I've used it in Go, Java, C#, JavaScript, Delphi, C...
>>>
>>> The main reason you don't see these one-liners often in C, D et. al. is
>>> because they are hard to read.
>>>
>>> For common C, C++ examples, see signal and interrupt vector tables.
>>>
>>> On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:

 Still waiting the Go version of this very useful D code...

 I'm not asking you to browse the web to find to find most complex
 declaration you can ever do in D, Go or C++ for instance.

 I've never used such ridiculous code in my Go/D/C++/Java/C#
 applications, and neither will you.

 I'm just asking you show me how *simple* code in Go will become much
 more complicated in D, as this is what you seem to think.

 And I mean something we will all use all day long (ex: declaring or
 using functions/types/arrays/slices/references/loops/etc etc), not the most
 complicated code you can come up with.

 THAT would be useful, and also a fair comparison between both languages.

 Because from what I see below, I may think you couldn't manage to find
 such an example

 But maybe I'm wrong, I don't know...

 On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:

Re: [go-nuts] Ellipse use error

[Ian Lance Taylor]

On Wed, Aug 2, 2017 at 6:30 AM, Mandolyte  wrote:
> This line of code:
> retrTarget := path.Join(maindir, ss[0], pathparts[npp:]...)
>
> produces this error:
> .\xxx.go:131: too many arguments in call to path.Join
> have (string, string, []string...)
> want (...string)
>
> Easy to work around, but I don't understand why it doesn't work...

The declaration of path.Join is `Join(elem ...string) string`.  When a
function has a `...string` parameter, you can either pass a sequence
of strings, or you can pass a slice as `s...`.  If you pass a slice,
the slice is passed directly as an ordinary slice parameter: if the
function changes any elements, those changes will be reflected in the
caller's slice.  If you just pass a sequence of strings, a new slice
is constructed and the caller will not see any changes.

Because of this difference in behavior, the language does not support
passing both a sequence of arguments and a slice, as that would make
it harder to understand when a slice is passed by reference and when a
new slice is constructed.

Also, the language generally avoids constructs that look simple but do
not take linear time  Passing a sequence of strings takes time (and
space) proportional to the number of arguments.  Passing a slice takes
constant time.  Passing a sequence of string plus a slice would
require creating a new slice to hold all the arguments, and as such
would take time proportional to the number of string arguments plus
the size of the slice, which is only known at run time.  In other
words, a simple seeming language construct would require an
unpredictable amount of run time.  The language avoids such cases in
general, other than cases like the predeclared copy and append
functions where the unpredictable time is fairly obvious.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Background reader in an HTTP server's connection serving loop

[Ian Lance Taylor]

On Wed, Aug 2, 2017 at 5:55 AM, Konstantin Khomoutov  wrote:
>
> The "conn" type from net/http/server.go, in its serve() method contains
> a "for" loop which is supposed -- as I understand it -- to keep reading
> requests from the connected socket if the client wished to reuse the
> connection.
>
> That loop reads the request's header and then starts a background
> goroutine which tries to read a single byte from the underlying
> connection and does other cryptic stuff.
>
> After that, the user-installed request handler is run to process the request.
>
> I fail to comprehend what's the purpose of starting that background
> goroutine.  Can anyone please shed some light on what is that "trick"
> really accomplishes.  IOW, what would be wrong with simply attempting to
> read from the client's connection after the handler has finished with
> the current request?

I believe it's to support the Hijack method, which is used by net/rpc
to implement an HTTP server that handles RPC requests.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Socket Priority affect Read Deadline?

[Konstantin Khomoutov]

On Wed, Aug 02, 2017 at 05:41:15AM -0700, jlu@gmail.com wrote:

> I wrapped some code to do listen UDP port and set priority,  like this
> 
> func ListenUDP(t string, laddr *net.UDPAddr, priority int) (*net.UDPConn, 
> error) {
> conn, err := net.ListenUDP(t, laddr)
[...]
> err = syscall.SetsockoptInt(int(file.Fd()), syscall.SOL_SOCKET, 
> syscall.SO_PRIORITY, priority)
[...]

To cite the socket(7) manual page:

| SO_PRIORITY
|Set the protocol-defined priority for all packets to be sent on this
|socket. Linux uses this value to order the networking queues: packets
|with a higher priority may be processed first depending on the selected
|device queueing discipline. For ip(7), this also sets the IP
|type-of-service (TOS) field for outgoing packets.

So basically that means that on a supposedly congested link, or with a
busy receiving process which hardly keeps up, there may exist queues
of packets, and setting this option could make the kernel prefer packets 
sent over this socket to be processed first -- if there exist other
sockets sending packets which end up in the same queue(s).

> And, read data from that port with timeout
> 
> conn.SetReadDeadline(time.Now().Add(time.Second * 5))
> n, addr, err = conn.ReadFromUDP(buf)
> 
> But, i found the deadline not work...

Hence, two questions:

- How exactly does it not work.

  When you make such statement, it should go like this:
  1) I did such and such preparations.
  2) I observe such and such behaviour.
  3) I would instead expect another behaviour; you then describe it.

- I doubt sessing SO_PRIORITY on a socket has something to do with read
  deadline on it (which is merely a timeout which measures how much time
  the read operation on a socket is allowed to take (and if it fails to
  complete in the defined timespan, it's aborted).

-- 
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 one-line installer

[mhhcbon]

Hi,

As you at this kind of work, have you considered a reliable one-liner to 
install dependencies ?

I got that own, just today, from a gae repo (?), anyways here it is,

go get -u -v $(go list -f '{{join .Imports "\n"}}{{"\n"}}{{join 
.TestImports "\n"}}' ./... | sort | uniq | grep -v golang-samples)

Problem is, it did not quiet work for me when i put that into my travis :x
https://travis-ci.org/mh-cbon/dht/jobs/260206514

even when i restart the job.

Do you have any ideas how to fix that ?


thanks

On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:
>
> Greetings Gophers,
>
> I've been working on a "one line installer" for Go with Jess Frazelle and 
> Chris Broadfoot and we think it's ready to share a bit more broadly.
>
> The installer is designed to both install Go as well as do the initial 
> configuration of setting up the right environment variables and paths.
> It will install the Go distribution (tools & stdlib) to "/.go" inside your 
> home directory by default.
> It will setup "$HOME/go" as your GOPATH. 
>
> If Go is already installed *via this installer* it will upgrade it to the 
> latest version of Go.
>
> Currently supported systems:
>   linux, darwin, windows / amd64, 386 / bash, zsh, powershell
>
>
> *Usage*
> Windows Powershell:
> (New-Object System.Net.WebClient).DownloadFile('
> https://get.golang.org/installer.exe', 'installer.exe'); Start-Process 
> -Wait -NonewWindow installer.exe; Remove-Item installer.exe
>
> Shell (Linux/macOS/Windows):
> curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x 
> go_installer && ./go_installer && rm go_installer
>
>
> As we discovered developing this, installers are really all edge cases. 
> We're certain we've not found many of them. 
> *Our goal is that this becomes the primary mechanism to install Go. *
> *To do that, we need your help testing, improving and fixing it. *
>
> The source can be found at 
> https://go.googlesource.com/tools/+/master/cmd/getgo/
> If you find any issues please report them on Github 
> https://github.com/golang/go/issues/new?title=tools/cmd/getgo:
>
> Thanks,
> Steve
>

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

[go-nuts] Re: Socket Priority affect Read Deadline?

[Dave Cheney]

http://godoc.org/net#UDPConn.File

"The returned os.File's file descriptor is different from the connection's. 
Attempting to change properties of the original using this duplicate may or 
may not have the desired effect."

On Wednesday, 2 August 2017 23:34:16 UTC+10, jlu...@gmail.com wrote:
>
> Hi guys,
>
> I wrapped some code to do listen UDP port and set priority,  like this
>
> func ListenUDP(t string, laddr *net.UDPAddr, priority int) (*net.UDPConn, 
> error) {
> conn, err := net.ListenUDP(t, laddr)
> if err != nil {
> return nil, err
> }
>
> if priority < 0 {
> return conn, nil
> }
>
> file, err := conn.File()
> if err != nil {
> conn.Close()
> return nil, fmt.Errorf("error in getting file for the connection")
> }
> defer file.Close()
>
> err = syscall.SetsockoptInt(int(file.Fd()), syscall.SOL_SOCKET, 
> syscall.SO_PRIORITY, priority)
> if err != nil {
> return nil, fmt.Errorf("error in setting priority option on 
> socket: %s", err)
> }
>
> return conn, nil
> }
>
> And, read data from that port with timeout
>
> conn.SetReadDeadline(time.Now().Add(time.Second * 5))
> n, addr, err = conn.ReadFromUDP(buf)
>
> But, i found the deadline not work...
>
> Any good suggestions?
>

-- 
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] Socket Priority affect Read Deadline?

[jlu . xzp]

Hi guys,

I wrapped some code to do listen UDP port and set priority,  like this

func ListenUDP(t string, laddr *net.UDPAddr, priority int) (*net.UDPConn, 
error) {
conn, err := net.ListenUDP(t, laddr)
if err != nil {
return nil, err
}

if priority < 0 {
return conn, nil
}

file, err := conn.File()
if err != nil {
conn.Close()
return nil, fmt.Errorf("error in getting file for the connection")
}
defer file.Close()

err = syscall.SetsockoptInt(int(file.Fd()), syscall.SOL_SOCKET, 
syscall.SO_PRIORITY, priority)
if err != nil {
return nil, fmt.Errorf("error in setting priority option on socket: 
%s", err)
}

return conn, nil
}

And, read data from that port with timeout

conn.SetReadDeadline(time.Now().Add(time.Second * 5))
n, addr, err = conn.ReadFromUDP(buf)

But, i found the deadline not work...

Any good suggestions?

-- 
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] Ellipse use error

[Mandolyte]

This line of code:
retrTarget := path.Join(maindir, ss[0], pathparts[npp:]...)

produces this error:
.\xxx.go:131: too many arguments in call to path.Join
have (string, string, []string...)
want (...string)

Easy to work around, but I don't understand why it doesn't work... 

Thanks for insights!
Cecil

-- 
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 one-line installer

[Igor Maznitsa]

I also had interest for such installer about year ago and developed mvn-golang 
plugin  (which can download and 
install go sdk and tune environment during build process) but it works in 
maven environment of course

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

Re: [go-nuts] Go one-line installer

[roger peppe]

On 2 August 2017 at 12:16, Jan Mercl <0xj...@gmail.com> wrote:
> On Wed, Aug 2, 2017 at 12:47 PM Florin Pățan  wrote:
>
>> I would never put anyone to the trouble of compiling Go themselves, so
>> it's not clear why you are suggesting that.
>
> From where comes the assumption that it's a trouble? I was not suggesting
> anything, but while we are at it, I think that installing from sources is by
> far the easiest way how to install Go. Precompiled binaries are inevitably
> depending on assumptions about the target system that can never be true
> across everyone's box - even when targeting the proper arch/platform/distro
> and release (and then you have to maintain a lot of targets). And if the
> assumptions don't hold, then that's what I'd call frustrating, provided it's
> usually not immediately clear where the problem is because there was no
> compiling/buildind/testing peformed locally making it much easier to figure
> out what went wrong.
>
>> I also don't do that myself and cannot see the value on doing it.
>
> Well, by definition you can't if you haven't tried. Anyway, above quoted
> says it's a trouble. Why?
>
>> Go has installers available for Windows/macOS and a tarball for Linux,
>> already precompiled and ready to Go (pun intended), why would I spend the
>> time compiling Go myself?
>
> To avoid the frustration and confusion you are talking about? I have always
> installed Go from sources and I never experienced any frustration when doing
> that (modulo me not reading or following the instructions and similar cases
> of being silly.)

When I've suggested that people install Go from source, I have encountered
problems because go1.4 no longer compiles from source on some platforms.

-- 
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] xml namespaces - encoding ok, decoding result not ok

[roger peppe]

It seems to me like your unmarshaling isn't actually working
(look inside the decoded data).

Here's an alternative version:
https://play.golang.org/p/CAChEa4-Kp

It's still not exactly right, as the DID tag is in the empty namespace
in the original XML, but is in os.xsd.v1 in the encoded version.
Does that cause your decoders to fail?
That's a bug in the encoding/xml package, as I don't think it's
possible to explicitly specify the empty namespace in a struct tag.

In your code, I believe that struct tags like `xml:"os:QUERYResponse"`
are only working by accident, because encoding/xml isn't interpreting
it as a namespace-prefixed tag name but instead just treating it as
a whole tag, so just printing it as is. That's probably why unmarshaling
isn't working.

BTW, I'd suggest trying a fork of encoding/xml that gets namespaces
somewhat more right: github.com/juju/xml. It was in the standard library
at some point, and hopefully will get there again when I have some
energy to do it.

  cheers,
rog.

On 2 August 2017 at 12:08, Marcin Jurczuk  wrote:
>
> Here is fully working/not working/not working example with whole SOAP
> envelope I'm getting from server:
> If I use different structs for encoding/decoding it works.
>
> https://play.golang.org/p/hVzB0lh2WH
>
> Change line:
> rx := new(SOAPEnvelope2)
>
> to:
> rx := new(SOAPEnvelope)
>
> And you will get error that shouldn't exists since serialization suppose to
> be symmetric.
>
>
>
> data varibable is copy/paste Encode output from .Encode()
>
> I have exact the same problem like here:
> https://github.com/golang/go/issues/9519
> When I use different struct for Unmarshaling and Marshalling it works.
>
> But this is a lot of boilerplate code and IMO serialization/deserialization
> to xml for the same struct should give exactly the same outuput :)
>
> Your solution gives different output.
>
>
>
> W dniu środa, 2 sierpnia 2017 11:56:09 UTC+2 użytkownik Konstantin Khomoutov
> napisał:
>>
>> On Tue, Aug 01, 2017 at 10:48:23AM -0700, Marcin Jurczuk wrote:
>>
>> > Your example is returning xml that is wrong from system I'm talking to.
>> > My SOAP service requires tags in few different namespaces.
>> > My code returns:
>> >
>> > *  *
>> >
>> > Your code returns:
>> >
>> > **
>> [...]
>> > > > https://play.golang.org/p/hE7vcXbymg
>> [...]
>>
>> I'm with roger on this: in your example, your sample XML document's text
>> begins with
>>
>>   
>>   
>>   ...
>>
>> which does not define that "os:" bit to denote an XML namespace prefix
>> anywhere.  This means the parser does not treat it as such -- it merely
>> considers it to be an integral part of the so-called "local names" of
>> the elements in that XML document.
>>
>> To add to the confusion, you have used those prefixes verbating in the
>> tags of the fields of the types intended to work with the corresponding
>> XML elements.  That's why the parser worked: you told it to, say, parse
>> an element literally named "os:QUERYResponse" and so it did that.
>>
>> If you really need to interpret that "os:" bit as an XML namespace
>> prefix, you have to do two things:
>>
>>  * Have that prefix defined in your XML document.
>>  * Use the full namespace name when you refer to the names of your XML
>>elements - separated by a single space character from their local
>>parts.
>>
>> Hence, say, your XML document should go like
>>
>>
>>   
>>   http://foo.bar/baz;>
>>   ...
>>
>> and you use the full namespace name in your tags like in
>>
>>   type QueryResponse struct {
>> XMLName  xml.Name `xml:"http://foo.bar/baz QUERYResponse"`
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Background reader in an HTTP server's connection serving loop

[Konstantin Khomoutov]

The "conn" type from net/http/server.go, in its serve() method contains
a "for" loop which is supposed -- as I understand it -- to keep reading
requests from the connected socket if the client wished to reuse the
connection.

That loop reads the request's header and then starts a background
goroutine which tries to read a single byte from the underlying
connection and does other cryptic stuff.

After that, the user-installed request handler is run to process the request.

I fail to comprehend what's the purpose of starting that background
goroutine.  Can anyone please shed some light on what is that "trick"
really accomplishes.  IOW, what would be wrong with simply attempting to
read from the client's connection after the handler has finished with
the current request?

-- 
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] Problems buildding go from source, tests "hangs"

[SauliusGurklys]

Hi,

while building go from source:

cd /usr/local/src/go
./clean.bash
./all.bash

build succeeds without any problem and then when tests are started then 
they just "hangs"

...
# ../misc/cgo/testplugin
PASS
something

# ../misc/cgo/testasan

# ../misc/cgo/testsanitizers

after this point nothing happens (tried to wait for a couple of days).
I tried many times, but "hanging" happens at this test(s).

I building go, the same way, on several machines, and this problem happens 
only on one of them.

The "problem" machine is

$ lsb_release -a
LSB Version:n/a
Distributor ID: ManjaroLinux
Description:Manjaro Linux
Release:17.0.2
Codename:   Gellivara

$ uname -a
Linux bubo 4.12.3-1-MANJARO #1 SMP PREEMPT Fri Jul 21 09:37:31 UTC 2017 
x86_64 GNU/Linux

Maybe somebody had and solved such problem?
Any thoughts?

Kind regards,
--
Saulius


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

Re: [go-nuts] Go one-line installer

[Jan Mercl]

On Wed, Aug 2, 2017 at 12:47 PM Florin Pățan  wrote:

> I would never put anyone to the trouble of compiling Go themselves, so
it's not clear why you are suggesting that.

>From where comes the assumption that it's a trouble? I was not suggesting
anything, but while we are at it, I think that installing from sources is
by far the easiest way how to install Go. Precompiled binaries are
inevitably depending on assumptions about the target system that can never
be true across everyone's box - even when targeting the proper
arch/platform/distro and release (and then you have to maintain a lot of
targets). And if the assumptions don't hold, then that's what I'd call
frustrating, provided it's usually not immediately clear where the problem
is because there was no compiling/buildind/testing peformed locally making
it much easier to figure out what went wrong.

> I also don't do that myself and cannot see the value on doing it.

Well, by definition you can't if you haven't tried. Anyway, above quoted
says it's a trouble. Why?

> Go has installers available for Windows/macOS and a tarball for Linux,
already precompiled and ready to Go (pun intended), why would I spend the
time compiling Go myself?

To avoid the frustration and confusion you are talking about? I have always
installed Go from sources and I never experienced any frustration when
doing that (modulo me not reading or following the instructions and similar
cases of being silly.)

-- 

-j

-- 
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] xml namespaces - encoding ok, decoding result not ok

[Marcin Jurczuk]

Here is fully working/not working/not working example with whole SOAP 
envelope I'm getting from server:
If I use different structs for encoding/decoding it works.

https://play.golang.org/p/hVzB0lh2WH

Change line:
rx := new(SOAPEnvelope2)

to:
rx := new(SOAPEnvelope)

And you will get error that shouldn't exists since serialization suppose to 
be symmetric.



data varibable is copy/paste Encode output from .Encode()

I have exact the same problem like here:
https://github.com/golang/go/issues/9519
When I use different struct for Unmarshaling and Marshalling it works.

But this is a lot of boilerplate code and IMO serialization/deserialization 
to xml for the same struct should give exactly the same outuput :)

Your solution gives different output.



W dniu środa, 2 sierpnia 2017 11:56:09 UTC+2 użytkownik Konstantin 
Khomoutov napisał:
>
> On Tue, Aug 01, 2017 at 10:48:23AM -0700, Marcin Jurczuk wrote: 
>
> > Your example is returning xml that is wrong from system I'm talking to. 
> > My SOAP service requires tags in few different namespaces. 
> > My code returns: 
> > 
> > *  * 
> > 
> > Your code returns: 
> > 
> > ** 
> [...] 
> > > > https://play.golang.org/p/hE7vcXbymg 
> [...] 
>
> I'm with roger on this: in your example, your sample XML document's text 
> begins with 
>
>
>
>   ... 
>
> which does not define that "os:" bit to denote an XML namespace prefix 
> anywhere.  This means the parser does not treat it as such -- it merely 
> considers it to be an integral part of the so-called "local names" of 
> the elements in that XML document. 
>
> To add to the confusion, you have used those prefixes verbating in the 
> tags of the fields of the types intended to work with the corresponding 
> XML elements.  That's why the parser worked: you told it to, say, parse 
> an element literally named "os:QUERYResponse" and so it did that. 
>
> If you really need to interpret that "os:" bit as an XML namespace 
> prefix, you have to do two things: 
>
>  * Have that prefix defined in your XML document. 
>  * Use the full namespace name when you refer to the names of your XML 
>elements - separated by a single space character from their local 
>parts. 
>
> Hence, say, your XML document should go like 
>
>
>
>   http://foo.bar/baz;> 
>   ... 
>
> and you use the full namespace name in your tags like in 
>
>   type QueryResponse struct { 
> XMLName  xml.Name `xml:"http://foo.bar/baz QUERYResponse"` 
>
>

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

Re: [go-nuts] Go one-line installer

[Florin Pățan]

On Wednesday, August 2, 2017 at 11:34:33 AM UTC+1, Jan Mercl wrote:
>
> On Wed, Aug 2, 2017 at 12:27 PM Florin Pățan  > wrote:
>
> > I speak from the experience of trying to help people get Go running on 
> Linux, macOS and Windows, this is a terribly frustrating step and unknown 
> for most of them.
>
> Please share what's frustrating and not clear about the step-by-step 
> instructions , so they can be 
> improved.
>
> -- 
>
> -j
>

I would never put anyone to the trouble of compiling Go themselves, so it's 
not clear why you are suggesting that. I also don't do that myself and 
cannot see the value on doing it. Go has installers available for 
Windows/macOS and a tarball for Linux, already precompiled and ready to Go 
(pun intended), why would I spend the time compiling Go myself?

Back on track.

People have problems with following this 
page: https://golang.org/doc/code.html . I don't know how it can be 
improved because I cannot understand the problem myself. Whenever I explain 
it to those that fail to read, it suddenly becomes clear and following the 
same steps there makes it magically work. And it's even funnier when I 
solve it for the people working on macOS because I never used that OS but 
people that have been using it for years seem unable to change environment 
variables :)

Maybe simple, clear, videos on how to set GOPATH, PATH and so on on the 
various operating systems would help as it's usually easier for anyone to 
just follow the instructions provided in a visual way (but I don't have any 
data/facts to back this up).

-- 
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 Vs D

[Egon]

Yes, I would agree -- the type declarations won't bother you in real-world, 
because when they become unreadable, then you would use additional types to 
clarify them... in any language.

*And, I have nothing against either languages -- I used D in my BSc thesis 
and Go in my MSc thesis.*

The main difference, as I see, is that Go is much more restricted, which 
means you have to work harder to fit your code into that model, leading to 
better structures overall. Over time you will learn the simpler ways of 
structuring your code. With D you have a tons of flexibility, which means 
often your first idea, what to write, succeeds -- which means the design 
will be less polished. Also this means that you won't tacitly learn to 
simplify your code.

Yes, you can also write as simple code in D as in Go; the caveat is that Go 
forces you more into that direction... at the cost of flexibility of the 
language. So you can write more complex and complected code in D -- for 
better and worse.

+ Egon

On Wednesday, 2 August 2017 13:25:06 UTC+3, ecstati...@gmail.com wrote:
>
> Ok I understand you now. Maybe I'm biased because I like both languages, 
> but I'm not convinced that this example illustrates well Go's simplicity 
> compared to D.
>
> For 99% of my *personal* daily use of both languages, very honestly, I've 
> never felt that using types, functions, arrays, etc etc was simpler in Go 
> compared to D.
>
> Even for more complex stuff like concurrency, I think that both languages 
> still remain quite close, despite I think that Go's channel system is the 
> best approach to the problem.
>
> On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote:
>>
>> The example contained 3 versions, C, D and Go.
>>
>> function pointer tables aren't that uncommon, maybe the []error part is 
>> uncommon
>>
>> Examples from real world code:
>>
>> https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
>>
>> https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40
>>
>> https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
>> https://github.com/golang/net/blob/master/proxy/proxy.go#L57
>> https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
>> https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
>> https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23
>>
>> And I've used it in Go, Java, C#, JavaScript, Delphi, C...
>>
>> The main reason you don't see these one-liners often in C, D et. al. is 
>> because they are hard to read.
>>
>> For common C, C++ examples, see signal and interrupt vector tables.
>>
>> On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:
>>>
>>> Still waiting the Go version of this very useful D code...
>>>
>>> I'm not asking you to browse the web to find to find most complex 
>>> declaration you can ever do in D, Go or C++ for instance.
>>>
>>> I've never used such ridiculous code in my Go/D/C++/Java/C# 
>>> applications, and neither will you.
>>>
>>> I'm just asking you show me how *simple* code in Go will become much 
>>> more complicated in D, as this is what you seem to think.
>>>
>>> And I mean something we will all use all day long (ex: declaring or 
>>> using functions/types/arrays/slices/references/loops/etc etc), not the most 
>>> complicated code you can come up with.
>>>
>>> THAT would be useful, and also a fair comparison between both languages.
>>>
>>> Because from what I see below, I may think you couldn't manage to find 
>>> such an example 
>>>
>>> But maybe I'm wrong, I don't know...
>>>   
>>> On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:

 On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>
> For all the common parts with Go (functions, methods, reference 
> classes, strings, arrays, slices, ranges, foreach, etc), honestly I don't 
> know why you say it's simpler in Go.
>
> Can you show me two examples of code side by side, and tell me "look 
> how much simpler it's with Go's" ?
>
> Because from what I read, I'm sometimes wondering if you really know 
> that the type declarations in D are MUCH simpler than in C/C++.
>

 error* (**callbacks)(int);

 Error[] function(int)[][string] callbacks;

 var callbacks map[string]func(int) []error


> For instance :
>
> int[]
> first_array_of_ints,
> second_array_of_ints;
>
> int[string]
> first_map_of_ints_indexed_by_a_string,
> second_map_of_ints_indexed_by_a_string;
>
> TYPE
> first_reference_to_an_object_of_this_type,
> second_reference_to_an_object_of_this_type;
>
> So, with all due respect, how many applications have you already 
> programmed in D before telling me that Go's syntax is so simpler to use 
> and 
> to learn ?
>
> I agree there are much *less* possibilities in Go, but that 

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

As I said, it's not because something sophisticated exists in a language 
that you have to use it.

It's quite the opposite. But indeed, with Go you don't have the problem, 
because these features were removed from the language to avoid the 
temptation to use them.

I can understand that, because many developers have no enough discipline or 
taste for simplicity, but the unfortunate price to pay is that in the few 
cases where it REALLY helps in making clear code that is easier to 
understand and to maintain, that is sad.

There are many possibilities in D which are not needed in Go, but I don't 
think why you think that genericity (ex: Pool, etc) and 
polymorphism (same method name for a similar argument of a different type) 
are considered as evil.

Properly used, they have their use place in any modern language like Go.

I personally that using interfaces when genericity was a simle and obvious 
solution is what requires more cleverness.

And I'm not saying that using interfaces for this is a bad solution, I'm 
just saying that I don't see the simplicity advantage in it.

Because everytime I have to use interfaces or duplicate implementation for 
such situations, I don't feel at all that Go is helping me implementing 
easier or simpler code.

On Wednesday, August 2, 2017 at 10:47:36 AM UTC+1, Chris Hopkins wrote:
>
>
>
> On Wednesday, 2 August 2017 09:46:08 UTC+1, ecstati...@gmail.com wrote:
>>
>> And btw, this doesn't mean that just because there are genericity and 
>> polymorphism in D, that I must use them.
>>
>> No, but the person reading your code must understand them.  Not only that 
> but they must understand the "clever" way you have used them.
> I came to go for the concurrency, I stayed for the fact that I have yet to 
> come across a piece of code I can't quickly understand.
>
> Every other language I come across that has "advanced" features seems to 
> be an exercise in programmer vanity showing off how clever they are. I 
> spend way more time & brain power trying to reverse engineer someone either 
> showing off their "clever" use of an obscure part of the language than they 
> could ever save with a few less keystrokes.
> The trouble with gerericity and polymorphism and operator overload and all 
> the others are they hide functionality which is great from an academic 
> perpective; when it comes down to debugging what on earth is going wrong 
> they are IME a nightmare.
>
> I think this is why this is turning into a holy war on this list, they are 
> without a doubt great ideas that in theory hide complexity and provide 
> better abstraction and lots of other good things that we should all strive 
> for. The trouble is, in practice many find them to be too powerful for real 
> world use except in certain carefully controlled examples.
>
> I get the impression you want them to make writing code quicker, do you 
> not then share the opinion that in practice for large poorly understood 3rd 
> party systems they make comprehension harder?
>
> Regards
>

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

Re: [go-nuts] Go one-line installer

[Jan Mercl]

On Wed, Aug 2, 2017 at 12:27 PM Florin Pățan  wrote:

> I speak from the experience of trying to help people get Go running on
Linux, macOS and Windows, this is a terribly frustrating step and unknown
for most of them.

Please share what's frustrating and not clear about the step-by-step
instructions , so they can be
improved.

-- 

-j

-- 
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 one-line installer

[Florin Pățan]

On Wednesday, August 2, 2017 at 3:14:07 AM UTC+1, Steve Francia wrote:
>
> On Tuesday, August 1, 2017 at 7:49:32 PM UTC-4, Florin Pățan wrote:
>>
>> Hi,
>>
>> The idea is good but:
>> - it needs to modify the path to add GOROOT/bin and GOPATH/bin to it
>>
> It does. If it didn't do this you've found a bug. Please report it.
>

I'll have a look at it again. Thank you.
 

> - it should allow for multiple versions of Go to be installed 
>> simultaneously (including 1.x.y vs 1.x.z versions) 
>>
> Out of scope for this tool, though it can do it with passing along flag 
> arguments
>

If you want this to become the de facto way to install Go, then it's a 
must, not out of scope.
Many people want to test a newer version of Go before switching to it, 
being forced to run a single version of Go because of this "installer" will 
not make anyone happy and will only serve to complicate things further.
 

> - it should change the PATH on all three OSes regardless of the shell 
>> used, which is the hardest part I guess (as this is the part that trips 
>> over most of the people, along with the GOPATH requirement)
>>
> There's no such thing. ENV variables are shell specific. The PATH is 
> defined in the shell initialization script on *nix. It literally tells the 
> shell what directories to look in. On Windows it does this as the PATH is 
> set by an OS call directly. Unfortunately bash on Windows ignores it.  
>

I meant, it has to provide support for changing the bash.rc, zsh.rc and 
other popular shells.
 

> Thank you.
>>
>  

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

Re: [go-nuts] Go one-line installer

[Florin Pățan]

On Wednesday, August 2, 2017 at 1:37:48 AM UTC+1, Tyler Compton wrote:
>
> > I was quite happy that the era of executable "installers" died once we
> > got package managers.
>
> This seems to come from a purely Linux perspective. I suspect that people 
> who use Linux are quite a bit less likely to benefit from this solution 
> anyway, because most Linux users are used to setting environment variables 
> and installing from tarballs. The era of executable installers has not died 
> on Windows or on Mac.
>
> > If something is to be improved, perhaps the
> > quality of packages for various distributions could be improved
> > instead. That is what the users want anyway, to use their distro
> > package manager.
>
> Trying to improve every distro's Go version is a substantially more 
> difficult problem, and even worse, it's a bureaucratic one. I think it 
> would be a lot more productive to spend that time working on the technical 
> problem of security than giving up and tackling a much harder one.
>
> On Tue, Aug 1, 2017 at 4:49 PM Florin Pățan  > wrote:
>
>> Hi,
>>
>> The idea is good but:
>> - it needs to modify the path to add GOROOT/bin and GOPATH/bin to it
>> - it should allow for multiple versions of Go to be installed 
>> simultaneously (including 1.x.y vs 1.x.z versions)
>> - it should change the PATH on all three OSes regardless of the shell 
>> used, which is the hardest part I guess (as this is the part that trips 
>> over most of the people, along with the GOPATH requirement)
>>
>> Thank you.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
I speak from the experience of trying to help people get Go running on 
Linux, macOS and Windows, this is a terribly frustrating step and unknown 
for most of them.

Please don't dismiss this based on what you think but rather on actual 
facts. I can show you countless questions that come up in Slack on: how do 
I install this and people being frustrated with the setup process.

-- 
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 Vs D

[ecstatic . coder]

Ok I understand you now. Maybe I'm biased because I like both languages, 
but I'm not convinced that this example illustrates well Go's simplicity 
compared to D.

For 99% of my *personal* daily use of both languages, very honestly, I've 
never felt that using types, functions, arrays, etc etc was simpler in Go 
compared to D.

Even for more complex stuff like concurrency, I think that both languages 
still remain quite close, despite I think that Go's channel system is the 
best approach to the problem.

On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote:
>
> The example contained 3 versions, C, D and Go.
>
> function pointer tables aren't that uncommon, maybe the []error part is 
> uncommon
>
> Examples from real world code:
>
> https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
>
> https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40
>
> https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
> https://github.com/golang/net/blob/master/proxy/proxy.go#L57
> https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
> https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
> https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23
>
> And I've used it in Go, Java, C#, JavaScript, Delphi, C...
>
> The main reason you don't see these one-liners often in C, D et. al. is 
> because they are hard to read.
>
> For common C, C++ examples, see signal and interrupt vector tables.
>
> On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:
>>
>> Still waiting the Go version of this very useful D code...
>>
>> I'm not asking you to browse the web to find to find most complex 
>> declaration you can ever do in D, Go or C++ for instance.
>>
>> I've never used such ridiculous code in my Go/D/C++/Java/C# applications, 
>> and neither will you.
>>
>> I'm just asking you show me how *simple* code in Go will become much 
>> more complicated in D, as this is what you seem to think.
>>
>> And I mean something we will all use all day long (ex: declaring or using 
>> functions/types/arrays/slices/references/loops/etc etc), not the most 
>> complicated code you can come up with.
>>
>> THAT would be useful, and also a fair comparison between both languages.
>>
>> Because from what I see below, I may think you couldn't manage to find 
>> such an example 
>>
>> But maybe I'm wrong, I don't know...
>>   
>> On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:
>>>
>>> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:

 For all the common parts with Go (functions, methods, reference 
 classes, strings, arrays, slices, ranges, foreach, etc), honestly I don't 
 know why you say it's simpler in Go.

 Can you show me two examples of code side by side, and tell me "look 
 how much simpler it's with Go's" ?

 Because from what I read, I'm sometimes wondering if you really know 
 that the type declarations in D are MUCH simpler than in C/C++.

>>>
>>> error* (**callbacks)(int);
>>>
>>> Error[] function(int)[][string] callbacks;
>>>
>>> var callbacks map[string]func(int) []error
>>>
>>>
 For instance :

 int[]
 first_array_of_ints,
 second_array_of_ints;

 int[string]
 first_map_of_ints_indexed_by_a_string,
 second_map_of_ints_indexed_by_a_string;

 TYPE
 first_reference_to_an_object_of_this_type,
 second_reference_to_an_object_of_this_type;

 So, with all due respect, how many applications have you already 
 programmed in D before telling me that Go's syntax is so simpler to use 
 and 
 to learn ?

 I agree there are much *less* possibilities in Go, but that doesn't 
 mean it's automatically a simpler language to learn for all the common 
 parts with D. Seriously.

 Because I had to learn both, and at least for a C++/Java/C# programmer 
 like me, D transition was almost immediate, really a matter of hours to 
 become comfortable with the language. Everything was alike, but much 
 simpler and easier than in C++.

 Believe me or not, I've taught programming with D to my two teenagers 
 with D. Really.

 I've chosen it because it was the only strongly-typed language close to 
 Javascript that was really easy to learn, while allowing them to quickly 
 switch to C++, Java or C# later if they wanted to.

 Go is much simpler than C++ too, I agree of course, but for having 
 learned both Go then D, again from the point of view of a former 
 C++/Java/C# programmer like me, I didn't feel that quickly at home with Go 
 than with D, mainly because Go diverged much more from its predecessors 
 than D from a syntactic point of view.

 So, again from a syntactic point of view, I don't think how you can 
 affirm that it's much easier in Go than in D to 

Re: [go-nuts] xml namespaces - encoding ok, decoding result not ok

[Konstantin Khomoutov]

On Tue, Aug 01, 2017 at 10:48:23AM -0700, Marcin Jurczuk wrote:

> Your example is returning xml that is wrong from system I'm talking to.
> My SOAP service requires tags in few different namespaces.
> My code returns:
> 
> *  *
> 
> Your code returns:
> 
> **
[...]
> > > https://play.golang.org/p/hE7vcXbymg 
[...]

I'm with roger on this: in your example, your sample XML document's text
begins with

  
  
  ...

which does not define that "os:" bit to denote an XML namespace prefix
anywhere.  This means the parser does not treat it as such -- it merely
considers it to be an integral part of the so-called "local names" of
the elements in that XML document.

To add to the confusion, you have used those prefixes verbating in the
tags of the fields of the types intended to work with the corresponding
XML elements.  That's why the parser worked: you told it to, say, parse
an element literally named "os:QUERYResponse" and so it did that.

If you really need to interpret that "os:" bit as an XML namespace
prefix, you have to do two things:

 * Have that prefix defined in your XML document.
 * Use the full namespace name when you refer to the names of your XML
   elements - separated by a single space character from their local
   parts.

Hence, say, your XML document should go like


  
  http://foo.bar/baz;>
  ...

and you use the full namespace name in your tags like in

  type QueryResponse struct {
XMLName  xml.Name `xml:"http://foo.bar/baz QUERYResponse"`

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

Re: [go-nuts] Re: GO Vs D

[Chris Hopkins]

On Wednesday, 2 August 2017 09:46:08 UTC+1, ecstati...@gmail.com wrote:
>
> And btw, this doesn't mean that just because there are genericity and 
> polymorphism in D, that I must use them.
>
> No, but the person reading your code must understand them.  Not only that 
but they must understand the "clever" way you have used them.
I came to go for the concurrency, I stayed for the fact that I have yet to 
come across a piece of code I can't quickly understand.

Every other language I come across that has "advanced" features seems to be 
an exercise in programmer vanity showing off how clever they are. I spend 
way more time & brain power trying to reverse engineer someone either 
showing off their "clever" use of an obscure part of the language than they 
could ever save with a few less keystrokes.
The trouble with gerericity and polymorphism and operator overload and all 
the others are they hide functionality which is great from an academic 
perpective; when it comes down to debugging what on earth is going wrong 
they are IME a nightmare.

I think this is why this is turning into a holy war on this list, they are 
without a doubt great ideas that in theory hide complexity and provide 
better abstraction and lots of other good things that we should all strive 
for. The trouble is, in practice many find them to be too powerful for real 
world use except in certain carefully controlled examples.

I get the impression you want them to make writing code quicker, do you not 
then share the opinion that in practice for large poorly understood 3rd 
party systems they make comprehension harder?

Regards

-- 
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 Vs D

[Egon]

The example contained 3 versions, C, D and Go.

function pointer tables aren't that uncommon, maybe the []error part is 
uncommon

Examples from real world code:

https://github.com/egonelbre/fedwiki/blob/master/action.go#L59
https://github.com/ethereum/go-ethereum/blob/master/crypto/sha3/sha3_test.go#L40
https://github.com/jteeuwen/go-bindata/blob/master/testdata/out/compress-memcopy.go#L205
https://github.com/golang/net/blob/master/proxy/proxy.go#L57
https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150
https://github.com/golang/go/blob/master/src/net/http/server.go#L2391
https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23

And I've used it in Go, Java, C#, JavaScript, Delphi, C...

The main reason you don't see these one-liners often in C, D et. al. is 
because they are hard to read.

For common C, C++ examples, see signal and interrupt vector tables.

On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com wrote:
>
> Still waiting the Go version of this very useful D code...
>
> I'm not asking you to browse the web to find to find most complex 
> declaration you can ever do in D, Go or C++ for instance.
>
> I've never used such ridiculous code in my Go/D/C++/Java/C# applications, 
> and neither will you.
>
> I'm just asking you show me how *simple* code in Go will become much more 
> complicated in D, as this is what you seem to think.
>
> And I mean something we will all use all day long (ex: declaring or using 
> functions/types/arrays/slices/references/loops/etc etc), not the most 
> complicated code you can come up with.
>
> THAT would be useful, and also a fair comparison between both languages.
>
> Because from what I see below, I may think you couldn't manage to find 
> such an example 
>
> But maybe I'm wrong, I don't know...
>   
> On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:
>>
>> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>>>
>>> For all the common parts with Go (functions, methods, reference classes, 
>>> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
>>> you say it's simpler in Go.
>>>
>>> Can you show me two examples of code side by side, and tell me "look how 
>>> much simpler it's with Go's" ?
>>>
>>> Because from what I read, I'm sometimes wondering if you really know 
>>> that the type declarations in D are MUCH simpler than in C/C++.
>>>
>>
>> error* (**callbacks)(int);
>>
>> Error[] function(int)[][string] callbacks;
>>
>> var callbacks map[string]func(int) []error
>>
>>
>>> For instance :
>>>
>>> int[]
>>> first_array_of_ints,
>>> second_array_of_ints;
>>>
>>> int[string]
>>> first_map_of_ints_indexed_by_a_string,
>>> second_map_of_ints_indexed_by_a_string;
>>>
>>> TYPE
>>> first_reference_to_an_object_of_this_type,
>>> second_reference_to_an_object_of_this_type;
>>>
>>> So, with all due respect, how many applications have you already 
>>> programmed in D before telling me that Go's syntax is so simpler to use and 
>>> to learn ?
>>>
>>> I agree there are much *less* possibilities in Go, but that doesn't 
>>> mean it's automatically a simpler language to learn for all the common 
>>> parts with D. Seriously.
>>>
>>> Because I had to learn both, and at least for a C++/Java/C# programmer 
>>> like me, D transition was almost immediate, really a matter of hours to 
>>> become comfortable with the language. Everything was alike, but much 
>>> simpler and easier than in C++.
>>>
>>> Believe me or not, I've taught programming with D to my two teenagers 
>>> with D. Really.
>>>
>>> I've chosen it because it was the only strongly-typed language close to 
>>> Javascript that was really easy to learn, while allowing them to quickly 
>>> switch to C++, Java or C# later if they wanted to.
>>>
>>> Go is much simpler than C++ too, I agree of course, but for having 
>>> learned both Go then D, again from the point of view of a former 
>>> C++/Java/C# programmer like me, I didn't feel that quickly at home with Go 
>>> than with D, mainly because Go diverged much more from its predecessors 
>>> than D from a syntactic point of view.
>>>
>>> So, again from a syntactic point of view, I don't think how you can 
>>> affirm that it's much easier in Go than in D to declare and use types, 
>>> references, functions, methods, slices, arrays, foreach, and all the common 
>>> stuff between both languages.
>>>
>>> Honestly, no offense intended.
>>>
>>> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:

 But from my personal experience, D is *at least* as easy to learn than 
> Go, if not easier.


 I seriously doubt, no offense. Go is so small and so intuitive, one can 
 argue that there are people out there who knows most of the Go unknowingly 
 :) 

 Just the fact that it doesn't break much with the familiar syntax of 
> C#, Java, C++, etc helps a lot in making the transition.
>

 Go's syntax is 

[go-nuts] Re: GO Vs D

[Doğan Kurt]

Let's not make it personal. I personally respect walter bright and andrei 
alexandrescu a lot and because of a very dear friend of mine 
, i started fiddling with D as early as 2010. 

Surely it's a great leap forward from C++. But someone who comes from a 
language as small as C, it's way harder to learn than Go. This is my 
personal experience. If you are already a C++ programmer, which i never was 
able to become one, it can be simple for your taste, but not for ours. 

I religiously believe in unix philosophy and D is not simple and certainly 
not small for my taste. 

Just because somebody is smart and capable doesn't mean he/she has a good 
taste. Let's not forget bjarne stroustrup created C++.

On Wednesday, August 2, 2017 at 9:51:43 AM UTC+2, ecstati...@gmail.com 
wrote:
>
> For all the common parts with Go (functions, methods, reference classes, 
> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
> you say it's simpler in Go.
>
> Can you show me two examples of code side by side, and tell me "look how 
> much simpler it's with Go's" ?
>
> Because from what I read, I'm sometimes wondering if you really know that 
> the type declarations in D are MUCH simpler than in C/C++.
>
> For instance :
>
> int[]
> first_array_of_ints,
> second_array_of_ints;
>
> int[string]
> first_map_of_ints_indexed_by_a_string,
> second_map_of_ints_indexed_by_a_string;
>
> TYPE
> first_reference_to_an_object_of_this_type,
> second_reference_to_an_object_of_this_type;
>
> So, with all due respect, how many applications have you already 
> programmed in D before telling me that Go's syntax is so simpler to use and 
> to learn ?
>
> I agree there are much *less* possibilities in Go, but that doesn't mean 
> it's automatically a simpler language to learn for all the common parts 
> with D. Seriously.
>
> Because I had to learn both, and at least for a C++/Java/C# programmer 
> like me, D transition was almost immediate, really a matter of hours to 
> become comfortable with the language. Everything was alike, but much 
> simpler and easier than in C++.
>
> Believe me or not, I've taught programming with D to my two teenagers with 
> D. Really.
>
> I've chosen it because it was the only strongly-typed language close to 
> Javascript that was really easy to learn, while allowing them to quickly 
> switch to C++, Java or C# later if they wanted to.
>
> Go is much simpler than C++ too, I agree of course, but for having learned 
> both Go then D, again from the point of view of a former C++/Java/C# 
> programmer like me, I didn't feel that quickly at home with Go than with D, 
> mainly because Go diverged much more from its predecessors than D from a 
> syntactic point of view.
>
> So, again from a syntactic point of view, I don't think how you can affirm 
> that it's much easier in Go than in D to declare and use types, references, 
> functions, methods, slices, arrays, foreach, and all the common stuff 
> between both languages.
>
> Honestly, no offense intended.
>
> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>>
>> But from my personal experience, D is *at least* as easy to learn than 
>>> Go, if not easier.
>>
>>
>> I seriously doubt, no offense. Go is so small and so intuitive, one can 
>> argue that there are people out there who knows most of the Go unknowingly 
>> :) 
>>
>> Just the fact that it doesn't break much with the familiar syntax of C#, 
>>> Java, C++, etc helps a lot in making the transition.
>>>
>>
>> Go's syntax is very familiar to C, i've never heard it was an issue. The 
>> only think you must get used to is declarations and i LOVE the Go way. I 
>> remember the days i was struggling with C's declaration model, the spiral 
>> rule etc. sure we use typedefs but it rather feels like a hack. 
>> I can write any declaration no matter how complex it is, with my eyes 
>> closed in Go. It's so great.
>>
>> And genericity and polymorphism are invaluable tools when optimizing code 
>>> reuse without reducing execution speed.
>>>
>>
>> I don't ever remember duplicating any code in C. I can't understand how 
>> people are unable to write reusable code with C, seriously.  Whenever i 
>> discuss this with a C++ programmer, they immediately share some generic Max 
>> function that works with int and double.  I admit i use macros in that 
>> case, but come on it's not even 1% of the serious programming you do in C. 
>>
>> If you are a competent C programmer (structured programming in general), 
>> you know how to write reusable code. 
>>
>

-- 
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: "fallthrough statement out of place" in `if` block inside `swicth` block

[Doğan Kurt]

In first snippet, i didn't get the second if. cond1 is true anyway.

Second snippet is equivalent to 

if (cond1) {
do_stuff() 
do_other_stuff() 
} else if cond2 {
do_other_stuff() 
}

which is more straightforward than using fallthrough imo.

On Wednesday, August 2, 2017 at 9:03:35 AM UTC+2, Konstantin Khomoutov 
wrote:
>
> On Tue, Aug 01, 2017 at 05:54:28AM -0700, kultig...@gmail.com 
>  wrote: 
>
> > i believe you should avoid fallthrough statement except for 
> auto-generated 
> > code. 
> > 
> > it's obscure what you are trying to accomplish with that piece of code, 
> but 
> > surely you can do it in a better way. 
>
> They have its valid use to avoid situations like this: 
>
> |  if cond1 && cond2 { 
> |if cond1 { 
> |  do_stuff() 
> |} 
> |do_other_stuff() 
> |  } 
>
> which can be rewritten like 
>
> |  switch { 
> |  case cond1: 
> |do_stuff() 
> |fallthrough 
> |  case cond2: 
> |do_other_stuff() 
> |  } 
>
> It's not quite visible due to cond* being short, but not so when they 
> involve comparisons against longish symbols exported from packages. 
>
>

-- 
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 Vs D

[ecstatic . coder]

Still waiting the Go version of this very useful D code...

I'm not asking you to browse the web to find to find most complex 
declaration you can ever do in D, Go or C++ for instance.

I've never used such ridiculous code in my Go/D/C++/Java/C# applications, 
and neither will you.

I'm just asking you show me how *simple* code in Go will become much more 
complicated in D, as this is what you seem to think.

And I mean something we will all use all day long (ex: declaring or using 
functions/types/arrays/slices/references/loops/etc etc), not the most 
complicated code you can come up with.

THAT would be useful, and also a fair comparison between both languages.

Because from what I see below, I may think you couldn't manage to find such 
an example 

But maybe I'm wrong, I don't know...
  
On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote:
>
> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>>
>> For all the common parts with Go (functions, methods, reference classes, 
>> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
>> you say it's simpler in Go.
>>
>> Can you show me two examples of code side by side, and tell me "look how 
>> much simpler it's with Go's" ?
>>
>> Because from what I read, I'm sometimes wondering if you really know that 
>> the type declarations in D are MUCH simpler than in C/C++.
>>
>
> error* (**callbacks)(int);
>
> Error[] function(int)[][string] callbacks;
>
> var callbacks map[string]func(int) []error
>
>
>> For instance :
>>
>> int[]
>> first_array_of_ints,
>> second_array_of_ints;
>>
>> int[string]
>> first_map_of_ints_indexed_by_a_string,
>> second_map_of_ints_indexed_by_a_string;
>>
>> TYPE
>> first_reference_to_an_object_of_this_type,
>> second_reference_to_an_object_of_this_type;
>>
>> So, with all due respect, how many applications have you already 
>> programmed in D before telling me that Go's syntax is so simpler to use and 
>> to learn ?
>>
>> I agree there are much *less* possibilities in Go, but that doesn't mean 
>> it's automatically a simpler language to learn for all the common parts 
>> with D. Seriously.
>>
>> Because I had to learn both, and at least for a C++/Java/C# programmer 
>> like me, D transition was almost immediate, really a matter of hours to 
>> become comfortable with the language. Everything was alike, but much 
>> simpler and easier than in C++.
>>
>> Believe me or not, I've taught programming with D to my two teenagers 
>> with D. Really.
>>
>> I've chosen it because it was the only strongly-typed language close to 
>> Javascript that was really easy to learn, while allowing them to quickly 
>> switch to C++, Java or C# later if they wanted to.
>>
>> Go is much simpler than C++ too, I agree of course, but for having 
>> learned both Go then D, again from the point of view of a former 
>> C++/Java/C# programmer like me, I didn't feel that quickly at home with Go 
>> than with D, mainly because Go diverged much more from its predecessors 
>> than D from a syntactic point of view.
>>
>> So, again from a syntactic point of view, I don't think how you can 
>> affirm that it's much easier in Go than in D to declare and use types, 
>> references, functions, methods, slices, arrays, foreach, and all the common 
>> stuff between both languages.
>>
>> Honestly, no offense intended.
>>
>> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>>>
>>> But from my personal experience, D is *at least* as easy to learn than 
 Go, if not easier.
>>>
>>>
>>> I seriously doubt, no offense. Go is so small and so intuitive, one can 
>>> argue that there are people out there who knows most of the Go unknowingly 
>>> :) 
>>>
>>> Just the fact that it doesn't break much with the familiar syntax of C#, 
 Java, C++, etc helps a lot in making the transition.

>>>
>>> Go's syntax is very familiar to C, i've never heard it was an issue. The 
>>> only think you must get used to is declarations and i LOVE the Go way. I 
>>> remember the days i was struggling with C's declaration model, the spiral 
>>> rule etc. sure we use typedefs but it rather feels like a hack. 
>>> I can write any declaration no matter how complex it is, with my eyes 
>>> closed in Go. It's so great.
>>>
>>> And genericity and polymorphism are invaluable tools when optimizing 
 code reuse without reducing execution speed.

>>>
>>> I don't ever remember duplicating any code in C. I can't understand how 
>>> people are unable to write reusable code with C, seriously.  Whenever i 
>>> discuss this with a C++ programmer, they immediately share some generic Max 
>>> function that works with int and double.  I admit i use macros in that 
>>> case, but come on it's not even 1% of the serious programming you do in C. 
>>>
>>> If you are a competent C programmer (structured programming in general), 
>>> you know how to write reusable code. 
>>>
>>

-- 
You received this message because you 

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

[Christoph Berger]

Good point. The same is true for the C-style for loop BTW. 
https://play.golang.org/p/58jwveiywB

Using an explicit boolean flag for signaling success avoids this trap.

> On 2. Aug 2017, at 10:30, tom.pa...@centralway.com wrote:
> 
> A side effect of this approach is that the index after the range loop will be 
> zero if slice contains zero or one elements:
>   https://play.golang.org/p/F7lLZ5wcuv
> 
> This means that code using the index after the range will need to re-test 
> whether the slice was empty to avoid a potential panic.
> 
> On Thursday, July 27, 2017 at 2:21:34 PM UTC+2, Christoph Berger wrote:
> That’s actually what I meant to indicate in the last paragraph (emphasis 
> added by me):
> 
> > The code in the Reddit post takes advantage of the fact that the last 
> > increment of the C-style loop can be observed outside the loop,
> 
> But thanks for providing a clarification. I see now it has not been clear to 
> everyone.
> 
>> On Wed, Jul 26, 2017 at 08:44:46AM -0700, Christoph Berger wrote:
>> 
 someone shared [this question](
 https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/
  
 )
  
 on reddit. I must say, that I'm surprised by the behavior myself. I would 
 have expected
 for i = range v
 to be semantically equivalent to
 for i = 0; i < len(v); i++
 and don't really understand the reasoning behind choosing different 
 semantics. Note, that the difference only exists, if i is declared outside 
 of the loop, that is, this is solely about the behavior after exiting the 
 loop-body.
 
 I'd greatly appreciate some explanation :)
>>> An attempt to explain this by looking at the C-style loop only:
>>> 
>>> The classic C-style for loop
>>> 
>>> for i:=0; i>> 
>>> is equivalent to
>>> 
>>> for i:=0; i>>// do something with i
>>>i++ // This is always the very last statement in the loop body
>>> }
>>> 
>>> The loop body runs from 0 to len(v)-1 only, because the last increment of i 
>>> to len(v) stops the loop, and no further iteration occurs. The code in the 
>>> loop body never sees i being set to len(v). 
>>> 
>>> And that's the same behavior as with the range operator. 
>>> 
>>> The code in the Reddit post takes advantage of the fact that the last 
>>> increment of the C-style loop can be observed outside the loop, for 
>>> detecting if the loop stopped early. This is a neat side effect that is not 
>>> possible with the range operator.
>> 
>> I would point out that both Axel and you are off a tiny bit from what
>> actually happens ;-)
>> 
>> In a for loop which uses a short variable declaration, that variable's
>> scope is confined to the for *statement* itself, and is also visible in
>> the loop's body because its scope is defined to be nested in that of the
>> loop statement.  This means in a loop like
>> 
>>  for i := 0; i < len(s); i++ {
>>  }
>> 
>> the variable "i" is not accessible after the closing brace.
>> 
>> The actual "problem" stated in that Reddit post is different: it uses a
>> variable defined outside the "for" loop:
>> 
>>  var i int
>>  for i = 0; i < len(v); i++ {
>>  }
>> 
>> As you can see, the loop merely uses that variable; it existed before
>> the loop and continued to live on after it finished executing.
>> 
>> To recap what others have already written, since the for loop's post
>> statement is defined to be executed after each execution of the body
>> (unless it was exited by means of executing `break` or `return`), that
>> 
>>  i++
>> 
>> statement gets executed, the condition evaluates to false, and the loop
>> exits -- with the variable "i" having the value equal to len(v).
>> 
>> One could do
>> 
>>  var x int
>> 
>>  for i := 0; i < len(v); i, x = i+1, x*2 {
>>  }
>> 
>> and get even more interesting effect on the variable "x" after the loop
>> finishes executing ;-)
>> 
>> -- 
>> 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/Xi6W3H5mlto/unsubscribe 
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> This message is for the attention of the intended recipient(s) only. It may 
> contain confidential, proprietary and/or legally privileged information. Use, 
> disclosure and/or retransmission of information contained in this email may 
> be prohibited. If you are not an intended recipient, you are kindly asked to 
> notify the sender immediately (by reply e-mail) and to permanently delete 
> this message. Thank you.
> 
> -- 
> You received this message because 

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

And btw, this doesn't mean that just because there are genericity and 
polymorphism in D, that I must use them.

Most of the time, I don't even need to use them, like in Go, so I simply 
don't use them.

What I'm saying is that, sometimes, you have to apply a similar function to 
different types for instance, and in this particular case, using genericiy 
OR polymorphism can get the job done quickly and in a cleaner way (DRY 
principle).

That doesn't happen all day long, but I'm occasionally in such situation, I 
really regret there is no native genericity and polymorphism in Go.

Using interfaces and stuff can indeed solve the problem in a way or 
another, but that's far from the simple, easy and obvious way to solve it.

At least that's what I feel each time I have to implement such code. 
Because for web-related development, 

Because despite I prefer D as a general purpose language, I'm still using 
Go to develop server side applications which interact with browsers and 
databases.

Its extensive standard library obviously makes it still the best tool for 
the job, no doubt about it.

On Wednesday, August 2, 2017 at 8:36:18 AM UTC+1, ohir wrote:
>
> On Tue, 1 Aug 2017 05:04:24 -0700 (PDT) 
> ecstati...@gmail.com  wrote: 
>
> > But D also gives you reference classes, genericity, function 
> polymorphism, 
> > conditional compilation, design by contract assertions, compile-time 
> meta 
> > programming, 
>
> All things above to be avoided in _maintainable_ software. 
>
> Mantra: every working line of code is written once by one person 
> then it is read hundreds/thousands of times by dozens of people. 
>
> Go spares your pair, then supervisor, from manually enforcing on 
> you hard local rules: "We use C++ but you are forbidden to use: 
> exceptions, overloading, auto, weak ... ". Go language by itself gives 
> you all that -do-not-use-this-and-that- checks for free ;) 
>
> > and many other features that are severely lacking in Go. 
> Luckily. These and many other features _luckily_ lacking in Go. 
> Something that can't be used also can't be abused. 
>
> From the software maintainer pov Go is both readable and debuggable. 
> In Go one may grasp execution path and functionality from the very 
> fragment of source s/he is reading now. With very few exceptions. 
>
> Throw in any level of meta programming, even simple function overload, 
> and suddenly reader of a fragment of code is forced to read entirety of 
> entangled sources then map it mentally - all that just to grasp importance 
> of that fragment s/he has read a while ago. Rinse and repeat on each level 
> deep. 
>
> Any business gain (man-hour wise) form higher level 'features' is null, 
> void 
> and negative at first bug hunt on production code. More so if said code 
> authors are long gone from the team. Many businesses learnt this 
> hard way and now they know better; now they go for Go. 
>
> > But for your command line or desktop developments, I think D could be 
> much 
> > more appropriate than Go... 
>
> Unless your CLI/desktop is supposed to be easily maintained for years to 
> come. 
>
> PS. If one want some joy and entertainment off writing, one may go for 
> Racket [https://racket-lang.org/]. Every program in it sooner than later 
> evolves into separate language of its own. Language only author can 
> understand. Even if just for a while ;). 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

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

Re: [go-nuts] Re: Go one-line installer

[Henrik Johansson]

At home on my Arch i really prefer pacman for everything and only as a last
resort do I ever exec any curlable installer.
The problem is usually that they don't get properly updated and the
packagemanager anyway pulls in Go since it is a dependency for
something else and it is a mess with two or more installations.

On my work Mac I have only ever installed one thing, "Oh my zsh", using
curl everything else have been installers or Homebrew.

My 2¢

I can see this to be beneficial when you pull up a VM and wants to quickly
and easily install but for Linux in general I am not sure.

ons 2 aug. 2017 kl 09:15 skrev Aram Hăvărneanu :

> > most Linux users are used to setting environment variables and
> > installing from tarballs.
>
> No, most Linux users are used to installing from package managers.
> Unless you were referring to installing Go in particular, where I
> conjecture that most Linux users who don't use some package manager
> to install Go, are installing from source.
>
> > The era of executable installers has not died on Windows or on Mac.
>
> I can't speak for Windows, but macOS (or OS X, or Mac OS X) never
> had executable installers like Windows had. It had .pkg installers,
> which are not the same thing at all, and even those are pretty rare
> today, restricted mostly to software that has to install kernel
> components and such. Most programs install by copying from zip/dng
> files or by installing from the App Store (a package manager).
>
> Mac users most certainly aren't used to executable installers.
>
> > I think it would be a lot more productive to spend that time working
> > on the technical problem
>
> The problem you are mentioning is the halting problem. There is no way
> reliably set configuration variables without solving the halting
> problem.
>
> I do not consider time spent on the halting problem to be productive
> time. Sorry.
>
>
> --
> Aram Hăvărneanu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 Vs D

[Egon]

On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com wrote:
>
> For all the common parts with Go (functions, methods, reference classes, 
> strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
> you say it's simpler in Go.
>
> Can you show me two examples of code side by side, and tell me "look how 
> much simpler it's with Go's" ?
>
> Because from what I read, I'm sometimes wondering if you really know that 
> the type declarations in D are MUCH simpler than in C/C++.
>

error* (**callbacks)(int);

Error[] function(int)[][string] callbacks;

var callbacks map[string]func(int) []error


> For instance :
>
> int[]
> first_array_of_ints,
> second_array_of_ints;
>
> int[string]
> first_map_of_ints_indexed_by_a_string,
> second_map_of_ints_indexed_by_a_string;
>
> TYPE
> first_reference_to_an_object_of_this_type,
> second_reference_to_an_object_of_this_type;
>
> So, with all due respect, how many applications have you already 
> programmed in D before telling me that Go's syntax is so simpler to use and 
> to learn ?
>
> I agree there are much *less* possibilities in Go, but that doesn't mean 
> it's automatically a simpler language to learn for all the common parts 
> with D. Seriously.
>
> Because I had to learn both, and at least for a C++/Java/C# programmer 
> like me, D transition was almost immediate, really a matter of hours to 
> become comfortable with the language. Everything was alike, but much 
> simpler and easier than in C++.
>
> Believe me or not, I've taught programming with D to my two teenagers with 
> D. Really.
>
> I've chosen it because it was the only strongly-typed language close to 
> Javascript that was really easy to learn, while allowing them to quickly 
> switch to C++, Java or C# later if they wanted to.
>
> Go is much simpler than C++ too, I agree of course, but for having learned 
> both Go then D, again from the point of view of a former C++/Java/C# 
> programmer like me, I didn't feel that quickly at home with Go than with D, 
> mainly because Go diverged much more from its predecessors than D from a 
> syntactic point of view.
>
> So, again from a syntactic point of view, I don't think how you can affirm 
> that it's much easier in Go than in D to declare and use types, references, 
> functions, methods, slices, arrays, foreach, and all the common stuff 
> between both languages.
>
> Honestly, no offense intended.
>
> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>>
>> But from my personal experience, D is *at least* as easy to learn than 
>>> Go, if not easier.
>>
>>
>> I seriously doubt, no offense. Go is so small and so intuitive, one can 
>> argue that there are people out there who knows most of the Go unknowingly 
>> :) 
>>
>> Just the fact that it doesn't break much with the familiar syntax of C#, 
>>> Java, C++, etc helps a lot in making the transition.
>>>
>>
>> Go's syntax is very familiar to C, i've never heard it was an issue. The 
>> only think you must get used to is declarations and i LOVE the Go way. I 
>> remember the days i was struggling with C's declaration model, the spiral 
>> rule etc. sure we use typedefs but it rather feels like a hack. 
>> I can write any declaration no matter how complex it is, with my eyes 
>> closed in Go. It's so great.
>>
>> And genericity and polymorphism are invaluable tools when optimizing code 
>>> reuse without reducing execution speed.
>>>
>>
>> I don't ever remember duplicating any code in C. I can't understand how 
>> people are unable to write reusable code with C, seriously.  Whenever i 
>> discuss this with a C++ programmer, they immediately share some generic Max 
>> function that works with int and double.  I admit i use macros in that 
>> case, but come on it's not even 1% of the serious programming you do in C. 
>>
>> If you are a competent C programmer (structured programming in general), 
>> you know how to write reusable code. 
>>
>

-- 
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] Reasoning behind behavior of range, when index is maintained

[tom . payne]

A side effect of this approach is that the index after the range loop will 
be zero if slice contains zero or one elements:
  https://play.golang.org/p/F7lLZ5wcuv

This means that code using the index after the range will need to re-test 
whether the slice was empty to avoid a potential panic.

On Thursday, July 27, 2017 at 2:21:34 PM UTC+2, Christoph Berger wrote:
>
> That’s actually what I meant to indicate in the last paragraph (emphasis 
> added by me):
>
> > The *code in the Reddit post* takes advantage of the fact that the last 
> increment of the C-style loop can be observed outside the loop,
>
> But thanks for providing a clarification. I see now it has not been clear 
> to everyone.
>
> On Wed, Jul 26, 2017 at 08:44:46AM -0700, Christoph Berger wrote:
>
> someone shared [this question](
>
> https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/)
>  
>
> on reddit. I must say, that I'm surprised by the behavior myself. I would 
> have expected
> for i = range v
> to be semantically equivalent to
> for i = 0; i < len(v); i++
> and don't really understand the reasoning behind choosing different 
> semantics. Note, that the difference only exists, if i is declared outside 
> of the loop, that is, this is solely about the behavior after exiting the 
> loop-body.
>
> I'd greatly appreciate some explanation :)
>
> An attempt to explain this by looking at the C-style loop only:
>
> The classic C-style for loop
>
> for i:=0; i
> is equivalent to
>
> for i:=0; i// do something with i
>i++ // This is always the very last statement in the loop body
> }
>
> The loop body runs from 0 to len(v)-1 only, because the last increment of 
> i 
> to len(v) stops the loop, and no further iteration occurs. The code in the 
> loop body never sees i being set to len(v). 
>
> And that's the same behavior as with the range operator. 
>
> The code in the Reddit post takes advantage of the fact that the last 
> increment of the C-style loop can be observed outside the loop, for 
> detecting if the loop stopped early. This is a neat side effect that is 
> not 
> possible with the range operator.
>
>
> I would point out that both Axel and you are off a tiny bit from what
> actually happens ;-)
>
> In a for loop which uses a short variable declaration, that variable's
> scope is confined to the for *statement* itself, and is also visible in
> the loop's body because its scope is defined to be nested in that of the
> loop statement.  This means in a loop like
>
>  for i := 0; i < len(s); i++ {
>  }
>
> the variable "i" is not accessible after the closing brace.
>
> The actual "problem" stated in that Reddit post is different: it uses a
> variable defined outside the "for" loop:
>
>  var i int
>  for i = 0; i < len(v); i++ {
>  }
>
> As you can see, the loop merely uses that variable; it existed before
> the loop and continued to live on after it finished executing.
>
> To recap what others have already written, since the for loop's post
> statement is defined to be executed after each execution of the body
> (unless it was exited by means of executing `break` or `return`), that
>
>  i++
>
> statement gets executed, the condition evaluates to false, and the loop
> exits -- with the variable "i" having the value equal to len(v).
>
> One could do
>
>  var x int
>
>  for i := 0; i < len(v); i, x = i+1, x*2 {
>  }
>
> and get even more interesting effect on the variable "x" after the loop
> finishes executing ;-)
>
> -- 
> 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/Xi6W3H5mlto/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
-- 
This message is for the attention of the intended recipient(s) only. It may 
contain confidential, proprietary and/or legally privileged information. 
Use, disclosure and/or retransmission of information contained in this 
email may be prohibited. If you are not an intended recipient, you are 
kindly asked to notify the sender immediately (by reply e-mail) and to 
permanently delete this message. Thank you.

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

[go-nuts] Re: GO Vs D

[ecstatic . coder]

For all the common parts with Go (functions, methods, reference classes, 
strings, arrays, slices, ranges, foreach, etc), honestly I don't know why 
you say it's simpler in Go.

Can you show me two examples of code side by side, and tell me "look how 
much simpler it's with Go's" ?

Because from what I read, I'm sometimes wondering if you really know that 
the type declarations in D are MUCH simpler than in C/C++.

For instance :

int[]
first_array_of_ints,
second_array_of_ints;

int[string]
first_map_of_ints_indexed_by_a_string,
second_map_of_ints_indexed_by_a_string;

TYPE
first_reference_to_an_object_of_this_type,
second_reference_to_an_object_of_this_type;

So, with all due respect, how many applications have you already programmed 
in D before telling me that Go's syntax is so simpler to use and to learn ?

I agree there are much *less* possibilities in Go, but that doesn't mean 
it's automatically a simpler language to learn for all the common parts 
with D. Seriously.

Because I had to learn both, and at least for a C++/Java/C# programmer like 
me, D transition was almost immediate, really a matter of hours to become 
comfortable with the language. Everything was alike, but much simpler and 
easier than in C++.

Believe me or not, I've taught programming with D to my two teenagers with 
D. Really.

I've chosen it because it was the only strongly-typed language close to 
Javascript that was really easy to learn, while allowing them to quickly 
switch to C++, Java or C# later if they wanted to.

Go is much simpler than C++ too, I agree of course, but for having learned 
both Go then D, again from the point of view of a former C++/Java/C# 
programmer like me, I didn't feel that quickly at home with Go than with D, 
mainly because Go diverged much more from its predecessors than D from a 
syntactic point of view.

So, again from a syntactic point of view, I don't think how you can affirm 
that it's much easier in Go than in D to declare and use types, references, 
functions, methods, slices, arrays, foreach, and all the common stuff 
between both languages.

Honestly, no offense intended.

On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote:
>
> But from my personal experience, D is *at least* as easy to learn than Go, 
>> if not easier.
>
>
> I seriously doubt, no offense. Go is so small and so intuitive, one can 
> argue that there are people out there who knows most of the Go unknowingly 
> :) 
>
> Just the fact that it doesn't break much with the familiar syntax of C#, 
>> Java, C++, etc helps a lot in making the transition.
>>
>
> Go's syntax is very familiar to C, i've never heard it was an issue. The 
> only think you must get used to is declarations and i LOVE the Go way. I 
> remember the days i was struggling with C's declaration model, the spiral 
> rule etc. sure we use typedefs but it rather feels like a hack. 
> I can write any declaration no matter how complex it is, with my eyes 
> closed in Go. It's so great.
>
> And genericity and polymorphism are invaluable tools when optimizing code 
>> reuse without reducing execution speed.
>>
>
> I don't ever remember duplicating any code in C. I can't understand how 
> people are unable to write reusable code with C, seriously.  Whenever i 
> discuss this with a C++ programmer, they immediately share some generic Max 
> function that works with int and double.  I admit i use macros in that 
> case, but come on it's not even 1% of the serious programming you do in C. 
>
> If you are a competent C programmer (structured programming in general), 
> you know how to write reusable code. 
>

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

Re: [go-nuts] Re: GO Vs D

[Wojciech S. Czarnecki]

On Tue, 1 Aug 2017 05:04:24 -0700 (PDT)
ecstatic.co...@gmail.com wrote:

> But D also gives you reference classes, genericity, function polymorphism, 
> conditional compilation, design by contract assertions, compile-time meta 
> programming, 

All things above to be avoided in _maintainable_ software.

Mantra: every working line of code is written once by one person
then it is read hundreds/thousands of times by dozens of people.

Go spares your pair, then supervisor, from manually enforcing on
you hard local rules: "We use C++ but you are forbidden to use:
exceptions, overloading, auto, weak ... ". Go language by itself gives
you all that -do-not-use-this-and-that- checks for free ;)

> and many other features that are severely lacking in Go.
Luckily. These and many other features _luckily_ lacking in Go.
Something that can't be used also can't be abused.

>From the software maintainer pov Go is both readable and debuggable.
In Go one may grasp execution path and functionality from the very
fragment of source s/he is reading now. With very few exceptions.

Throw in any level of meta programming, even simple function overload,
and suddenly reader of a fragment of code is forced to read entirety of
entangled sources then map it mentally - all that just to grasp importance
of that fragment s/he has read a while ago. Rinse and repeat on each level
deep.

Any business gain (man-hour wise) form higher level 'features' is null, void
and negative at first bug hunt on production code. More so if said code
authors are long gone from the team. Many businesses learnt this
hard way and now they know better; now they go for Go.

> But for your command line or desktop developments, I think D could be much 
> more appropriate than Go...

Unless your CLI/desktop is supposed to be easily maintained for years to come.

PS. If one want some joy and entertainment off writing, one may go for
Racket [https://racket-lang.org/]. Every program in it sooner than later
evolves into separate language of its own. Language only author can
understand. Even if just for a while ;).

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

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

Re: [go-nuts] Re: Go one-line installer

[Aram Hăvărneanu]

> most Linux users are used to setting environment variables and
> installing from tarballs.

No, most Linux users are used to installing from package managers.
Unless you were referring to installing Go in particular, where I
conjecture that most Linux users who don't use some package manager
to install Go, are installing from source.

> The era of executable installers has not died on Windows or on Mac.

I can't speak for Windows, but macOS (or OS X, or Mac OS X) never
had executable installers like Windows had. It had .pkg installers,
which are not the same thing at all, and even those are pretty rare
today, restricted mostly to software that has to install kernel
components and such. Most programs install by copying from zip/dng
files or by installing from the App Store (a package manager).

Mac users most certainly aren't used to executable installers.

> I think it would be a lot more productive to spend that time working
> on the technical problem

The problem you are mentioning is the halting problem. There is no way
reliably set configuration variables without solving the halting
problem.

I do not consider time spent on the halting problem to be productive
time. Sorry.


-- 
Aram Hăvărneanu

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

Re: [go-nuts] Re: "fallthrough statement out of place" in `if` block inside `swicth` block

[Konstantin Khomoutov]

On Tue, Aug 01, 2017 at 05:54:28AM -0700, kultigin@gmail.com wrote:

> i believe you should avoid fallthrough statement except for auto-generated 
> code.
> 
> it's obscure what you are trying to accomplish with that piece of code, but 
> surely you can do it in a better way.

They have its valid use to avoid situations like this:

|  if cond1 && cond2 {
|if cond1 {
|  do_stuff()
|}
|do_other_stuff()
|  }

which can be rewritten like

|  switch {
|  case cond1:
|do_stuff()
|fallthrough
|  case cond2:
|do_other_stuff()
|  }

It's not quite visible due to cond* being short, but not so when they
involve comparisons against longish symbols exported from packages.

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