[go-nuts] go gtk3 simple text editor

[Oleg Puchinin]

Hello !
Can you help me wirte subj ? I use "glade" and gotk3. I need scrollbars for
textedit widget.

Oleg.

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[Dave Cheney]

On Tuesday, 12 September 2017 15:23:56 UTC+10, Shivaram Lingamneni wrote:
>
> So this proves it: "happens-after Listener.Close()" is not a sufficient 
> condition for being able to rebind the address. If another goroutine is in 
> a Listener.Accept() call, the new bind must happen-after the return of both 
> the Listener.Close() and the Listener.Accept() calls.
>

Please see this code https://play.golang.org/p/j7ZxGbf4py
 

>
> So the question is: are there any other conditions that can prevent 
> Listener.Close() from resulting in close(2)? Is code that waits for the 
> completion of both Close() and Accept() correct code?
>

Not for network sockets.
 

>
> I don't understand the polling layer of the runtime to say whether it 
> would be feasible for `Accept()` not to hold a reference during 
> `WaitRead()` --- but it seems like that would be preferable.
>

Once Accept has returned, the readLock is returned. Accept returns when it 
receives a connection, or its underlying socket is closed via l.Close()
 

>
> On Tuesday, September 12, 2017 at 12:39:11 AM UTC-4, Dave Cheney wrote:
>>
>> Yup, and when l.Close is called, Accept returns, releasing the readLock.
>>
>>
>> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L321
>>
>> On Tuesday, 12 September 2017 14:30:54 UTC+10, Shivaram Lingamneni wrote:
>>>
>>>
>>>
>>> On Tuesday, September 12, 2017 at 12:13:15 AM UTC-4, Dave Cheney wrote:



 On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni 
 wrote:
>
> On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote:
>>
>> The already in use is probably coming from the TCP stack which waits 
>> a certain time before allowing the address to be reused. However I 
>> thought 
>> that the net package already used SO_REUSEADDR to avoid the delay in 
>> close 
>> to reopen.
>>
>>
>>> The question I'm really asking is not so much how to write code that 
>>> works in practice (or, rather, appears to do so), but how to be certain 
>>> (on 
>>> the basis of the specification and API documentation) that the code is 
>>> correct.
>>>
>>
>> As written the code is correct. Once the listener is closed, you can 
>> reopen it, modulo TCP stack vagaries. 
>>
>
> The net package is indeed setting SO_REUSEADDR, which allows re-bind 
> on the address immediately after close(2). The problem is that close(2) 
> is 
> not guaranteed to occur as a result of Listener.Close(), because of 
> reference counting of file descriptors. This is not an issue with the TCP 
> stack; the runtime is simply failing to issue the required system call.
>

 I've had a look through the code for the TCPListener and I cannot see 
 where the reference count is being bumped by accept. As far as I 
 understand 
 the *netFD returned from Accept is unassociated with the *netFD that is 
 bound to a listening socket. 

>>>
>>> On the one hand, I am more confident in the claim that "close(2) is not 
>>> guaranteed to occur as a result of Listener.Close()" than I am in the 
>>> specific explanation of `Accept()` holding a reference. On the other hand, 
>>> I think I found the relevant line of code:
>>>
>>>
>>> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L318
>>>  
>>>
>>> If I'm reading this correctly, this layer of Accept() acquires a 
>>> readLock() on the file, which includes a reference acquire:
>>>
>>>
>>> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_mutex.go#L216
>>>
>>> and then continues holding this reference when it "blocks" on 
>>> `fd.pd.WaitRead`.
>>>
>>

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[shivaram]

So this proves it: "happens-after Listener.Close()" is not a sufficient 
condition for being able to rebind the address. If another goroutine is in 
a Listener.Accept() call, the new bind must happen-after the return of both 
the Listener.Close() and the Listener.Accept() calls.

So the question is: are there any other conditions that can prevent 
Listener.Close() from resulting in close(2)? Is code that waits for the 
completion of both Close() and Accept() correct code?

I don't understand the polling layer of the runtime to say whether it would 
be feasible for `Accept()` not to hold a reference during `WaitRead()` --- 
but it seems like that would be preferable.

On Tuesday, September 12, 2017 at 12:39:11 AM UTC-4, Dave Cheney wrote:
>
> Yup, and when l.Close is called, Accept returns, releasing the readLock.
>
>
> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L321
>
> On Tuesday, 12 September 2017 14:30:54 UTC+10, Shivaram Lingamneni wrote:
>>
>>
>>
>> On Tuesday, September 12, 2017 at 12:13:15 AM UTC-4, Dave Cheney wrote:
>>>
>>>
>>>
>>> On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni wrote:

 On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote:
>
> The already in use is probably coming from the TCP stack which waits a 
> certain time before allowing the address to be reused. However I thought 
> that the net package already used SO_REUSEADDR to avoid the delay in 
> close 
> to reopen.
>
>
>> The question I'm really asking is not so much how to write code that 
>> works in practice (or, rather, appears to do so), but how to be certain 
>> (on 
>> the basis of the specification and API documentation) that the code is 
>> correct.
>>
>
> As written the code is correct. Once the listener is closed, you can 
> reopen it, modulo TCP stack vagaries. 
>

 The net package is indeed setting SO_REUSEADDR, which allows re-bind on 
 the address immediately after close(2). The problem is that close(2) is 
 not 
 guaranteed to occur as a result of Listener.Close(), because of reference 
 counting of file descriptors. This is not an issue with the TCP stack; the 
 runtime is simply failing to issue the required system call.

>>>
>>> I've had a look through the code for the TCPListener and I cannot see 
>>> where the reference count is being bumped by accept. As far as I understand 
>>> the *netFD returned from Accept is unassociated with the *netFD that is 
>>> bound to a listening socket. 
>>>
>>
>> On the one hand, I am more confident in the claim that "close(2) is not 
>> guaranteed to occur as a result of Listener.Close()" than I am in the 
>> specific explanation of `Accept()` holding a reference. On the other hand, 
>> I think I found the relevant line of code:
>>
>>
>> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L318
>>  
>>
>> If I'm reading this correctly, this layer of Accept() acquires a 
>> readLock() on the file, which includes a reference acquire:
>>
>>
>> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_mutex.go#L216
>>
>> and then continues holding this reference when it "blocks" on 
>> `fd.pd.WaitRead`.
>>
>

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[Dave Cheney]

Yup, and when l.Close is called, Accept returns, releasing the readLock.

https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L321

On Tuesday, 12 September 2017 14:30:54 UTC+10, Shivaram Lingamneni wrote:
>
>
>
> On Tuesday, September 12, 2017 at 12:13:15 AM UTC-4, Dave Cheney wrote:
>>
>>
>>
>> On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni wrote:
>>>
>>> On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote:

 The already in use is probably coming from the TCP stack which waits a 
 certain time before allowing the address to be reused. However I thought 
 that the net package already used SO_REUSEADDR to avoid the delay in close 
 to reopen.


> The question I'm really asking is not so much how to write code that 
> works in practice (or, rather, appears to do so), but how to be certain 
> (on 
> the basis of the specification and API documentation) that the code is 
> correct.
>

 As written the code is correct. Once the listener is closed, you can 
 reopen it, modulo TCP stack vagaries. 

>>>
>>> The net package is indeed setting SO_REUSEADDR, which allows re-bind on 
>>> the address immediately after close(2). The problem is that close(2) is not 
>>> guaranteed to occur as a result of Listener.Close(), because of reference 
>>> counting of file descriptors. This is not an issue with the TCP stack; the 
>>> runtime is simply failing to issue the required system call.
>>>
>>
>> I've had a look through the code for the TCPListener and I cannot see 
>> where the reference count is being bumped by accept. As far as I understand 
>> the *netFD returned from Accept is unassociated with the *netFD that is 
>> bound to a listening socket. 
>>
>
> On the one hand, I am more confident in the claim that "close(2) is not 
> guaranteed to occur as a result of Listener.Close()" than I am in the 
> specific explanation of `Accept()` holding a reference. On the other hand, 
> I think I found the relevant line of code:
>
>
> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L318
>  
>
> If I'm reading this correctly, this layer of Accept() acquires a 
> readLock() on the file, which includes a reference acquire:
>
>
> https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_mutex.go#L216
>
> and then continues holding this reference when it "blocks" on 
> `fd.pd.WaitRead`.
>

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[shivaram]

On Tuesday, September 12, 2017 at 12:13:15 AM UTC-4, Dave Cheney wrote:
>
>
>
> On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni wrote:
>>
>> On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote:
>>>
>>> The already in use is probably coming from the TCP stack which waits a 
>>> certain time before allowing the address to be reused. However I thought 
>>> that the net package already used SO_REUSEADDR to avoid the delay in close 
>>> to reopen.
>>>
>>>
 The question I'm really asking is not so much how to write code that 
 works in practice (or, rather, appears to do so), but how to be certain 
 (on 
 the basis of the specification and API documentation) that the code is 
 correct.

>>>
>>> As written the code is correct. Once the listener is closed, you can 
>>> reopen it, modulo TCP stack vagaries. 
>>>
>>
>> The net package is indeed setting SO_REUSEADDR, which allows re-bind on 
>> the address immediately after close(2). The problem is that close(2) is not 
>> guaranteed to occur as a result of Listener.Close(), because of reference 
>> counting of file descriptors. This is not an issue with the TCP stack; the 
>> runtime is simply failing to issue the required system call.
>>
>
> I've had a look through the code for the TCPListener and I cannot see 
> where the reference count is being bumped by accept. As far as I understand 
> the *netFD returned from Accept is unassociated with the *netFD that is 
> bound to a listening socket. 
>

On the one hand, I am more confident in the claim that "close(2) is not 
guaranteed to occur as a result of Listener.Close()" than I am in the 
specific explanation of `Accept()` holding a reference. On the other hand, 
I think I found the relevant line of code:

https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_unix.go#L318
 

If I'm reading this correctly, this layer of Accept() acquires a readLock() 
on the file, which includes a reference acquire:

https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/internal/poll/fd_mutex.go#L216

and then continues holding this reference when it "blocks" on 
`fd.pd.WaitRead`.

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[Dave Cheney]

On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni wrote:
>
> On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote:
>>
>> The already in use is probably coming from the TCP stack which waits a 
>> certain time before allowing the address to be reused. However I thought 
>> that the net package already used SO_REUSEADDR to avoid the delay in close 
>> to reopen.
>>
>>
>>> The question I'm really asking is not so much how to write code that 
>>> works in practice (or, rather, appears to do so), but how to be certain (on 
>>> the basis of the specification and API documentation) that the code is 
>>> correct.
>>>
>>
>> As written the code is correct. Once the listener is closed, you can 
>> reopen it, modulo TCP stack vagaries. 
>>
>
> The net package is indeed setting SO_REUSEADDR, which allows re-bind on 
> the address immediately after close(2). The problem is that close(2) is not 
> guaranteed to occur as a result of Listener.Close(), because of reference 
> counting of file descriptors. This is not an issue with the TCP stack; the 
> runtime is simply failing to issue the required system call.
>

I've had a look through the code for the TCPListener and I cannot see where 
the reference count is being bumped by accept. As far as I understand the 
*netFD returned from Accept is unassociated with the *netFD that is bound 
to a listening socket. 
 

>
> The original test case:
>
> https://gist.github.com/slingamn/f1f2ef4a8d004e67a9b0f27b698a5b13
>
> demonstrates that the use of SO_REUSEADDR allows re-bind to succeed as 
> soon as the close(2) call has been issued (most likely, as James Bardin 
> suggested, at the point when the listener goroutine resumes execution after 
> the interruption of `Accept()`).
>

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[shivaram]

On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote:
>
> The already in use is probably coming from the TCP stack which waits a 
> certain time before allowing the address to be reused. However I thought 
> that the net package already used SO_REUSEADDR to avoid the delay in close 
> to reopen.
>
>
>> The question I'm really asking is not so much how to write code that 
>> works in practice (or, rather, appears to do so), but how to be certain (on 
>> the basis of the specification and API documentation) that the code is 
>> correct.
>>
>
> As written the code is correct. Once the listener is closed, you can 
> reopen it, modulo TCP stack vagaries. 
>

The net package is indeed setting SO_REUSEADDR, which allows re-bind on the 
address immediately after close(2). The problem is that close(2) is not 
guaranteed to occur as a result of Listener.Close(), because of reference 
counting of file descriptors. This is not an issue with the TCP stack; the 
runtime is simply failing to issue the required system call.

The original test case:

https://gist.github.com/slingamn/f1f2ef4a8d004e67a9b0f27b698a5b13

demonstrates that the use of SO_REUSEADDR allows re-bind to succeed as soon 
as the close(2) call has been issued (most likely, as James Bardin 
suggested, at the point when the listener goroutine resumes execution after 
the interruption of `Accept()`).

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[Dave Cheney]

The already in use is probably coming from the TCP stack which waits a 
certain time before allowing the address to be reused. However I thought 
that the net package already used SO_REUSEADDR to avoid the delay in close 
to reopen.


> The question I'm really asking is not so much how to write code that works 
> in practice (or, rather, appears to do so), but how to be certain (on the 
> basis of the specification and API documentation) that the code is correct.
>

As written the code is correct. Once the listener is closed, you can reopen 
it, modulo TCP stack vagaries. 

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[shivaram]

On Monday, September 11, 2017 at 10:24:39 PM UTC-4, Dave Cheney wrote:
>
> What about this ?
>
> https://play.golang.org/p/qmi1MvLBm8
>
>
I believe this code is incorrect. Here's a demonstration:

https://gist.github.com/slingamn/1467b1bafc613aec7ca0276c31a7a37f/revisions

The original revision is taken from the Go Playground snippet, the second 
revision makes the code compile, and the third revision adds a sleep (which 
should not make correct code into incorrect code) and a re-bind after the 
`Close()` call. On my system (Go 1.9 on Linux x86_64), the third revision 
reliably panics with:

`panic: listen tcp :6502: bind: address already in use`

The question I'm really asking is not so much how to write code that works 
in practice (or, rather, appears to do so), but how to be certain (on the 
basis of the specification and API documentation) that the code is correct.

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[Dave Cheney]

What about this ?

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

On Tuesday, 12 September 2017 10:07:48 UTC+10, Shivaram Lingamneni wrote:
>
>
>
> On Monday, September 11, 2017 at 11:36:33 AM UTC-4, James Bardin wrote:
>>
>>
>> Rather than waiting for just the `Listener.Close` call to return, try 
>> waiting for the call to `Listener.Accept()` to return with a non-Temporary 
>> error. That should error as the result of the file descriptor being closed, 
>> and give you the ordering you need.
>>
>>
> Thanks, this was very helpful. I found these links:
>
> https://github.com/golang/go/issues/4373
> https://github.com/golang/go/issues/11219
>
> https://github.com/golang/go/commit/fb4b4342fe298fda640bfa74f24b7bd58519deba
>
> It should in fact be possible to test either `err.Temporary()` or the 
> actual error string (as in #19252), and then any execution that 
> happens-after a successful test will be able to rebind.
>
> Here's what I'm still uncertain about: it's not clear on the basis of the 
> API that the main() goroutine needs to coordinate with any other goroutines 
> in the first place. So it's clear that a goroutine blocking (so to speak) 
> on Accept() requires this coordination, but could there be others? Are 
> there more potential situations in which another goroutine is holding 
> references to the underlying file descriptor?
>

-- 
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] Doing "C-like" things in Go

[Michael Jones]

That said:

int(boolvalue) could mean 0 for false and 1 otherwise
bool(intvalue) could mean false for 0 an true otherwise

quite a useful notion

On Mon, Sep 11, 2017 at 5:12 PM, Shawn Milochik 
wrote:

> Go is more explicit than C. Mistakes won't compile. Perfectly valid syntax
> in C could be a subtle logic bug; Go tries to avoid these.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] Doing "C-like" things in Go

[Shawn Milochik]

Go is more explicit than C. Mistakes won't compile. Perfectly valid syntax
in C could be a subtle logic bug; Go tries to avoid these.

-- 
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 : Philosophy

[tiagovdberg]

One perception I have about Go philosophy: 
 - Don't create futile abstractions;
 - Prefer not create abstractions if they will increase the quantity of 
code needed for the problem.

Example of these are the missing generic type system. People from other 
schools of thought (eg: Java) tend to prefer generic abstractions like 
collections. I not saying specificaly collections abstractions are futile, 
I just saying in Golang they are considered unecessary.

A common case example:

Golang:

index := 4
list = append(list[0:index], newItem, list[index:])

Java:

int index = 4;
list.insert(4, newItem);

Seeing that code shows exactly what the Golang is doing to insert the item 
in the list. In java code that implementation is dependent.

One example of futile abstractions are tests:

On Java, JUnit have tons of methods to assert an infinite possibilities of 
types. Eg: assertEquals, assertNotEquals, etc.

assertEquals("expected", result);

In Go, the standard test library has only the Fail (and some few others) 
method. The testing by itself are made of "if"s structures. Eg: 

if result != "expected {
t.Fail("result " + result + " not expected") 
}

Even if Java style is somewhat smaller (in fact, there is as miracle code 
black hole in golang where all projects are commonly 30% smaller than Java 
counterparts), the Golang style is immediately readable as something 
obvious without the need to navigate in the inner classes of a framework 
like JUnit.

Once you get  the philosophy stuck in your head, there is no way back.  

Annotations, Context injection and configuration files are considered evil 
in Golang, where lambda-receiving-functions, Normal "constructors" (I know 
there is no real constructor, just common functions that play that role), 
and simple go code used for configurations are considered the norm. Eg:

Java:

@Transaction
public void savePerson(Person person) {
  persistence.save(person)
}

Golang:

func savePerson(p model.Person) {
  tr = transaction.NewTransaction()
  tr.OnTransaction(func() {
persistence.save(p)
  });
}

The Golang code is easier to debug. Just need to browse to OnTransaction 
function. In Java is somewhat more dificult to know where the call is 
intercepted and the transaction is inserted.

Java: 

@WebServlet(name="myServlet", urlPatterns="/myServlet")

Golang:

http.Handle("/myPath", myHandler)

So in golang magic configuration are not well received. Its not that easy 
to see how a Servlet is configurated in a Java container, that knowlegde is 
given as granted by an framework/container. In Golang it is easily common 
to see how the things work under the hood.

In Golang a balance between performance and readability tends more to the 
side of performance than in other languages.

Eg: In Java abstraction and readability are the norm above all other 
things. Only when things get really ugly, tunning and performance are 
dealed on. Don't let me start about Hibernate/JPA!!

I use Java as a counter example because is what I work with. I love both 
languages with their strenghts and weakenesses. They are fundamentally 
contrary in terms of philosophy. 

Java = formality, abstractions, frameworks always that IS possible.

Golang = simplicity, economy of resources, speed, NOT use frameworks always 
that is possible.


Em segunda-feira, 28 de junho de 2010 10:43:48 UTC-3, Mayuresh Kathe 
escreveu:
>
> Like the UNIX philosophy (below);
> Write programs that do one thing and do it well.
> Write programs to work together.
> Write programs to handle text streams, because that is a universal 
> interface.
>
> Is there a philosophy to writing Go programs?
>

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[shivaram]

On Monday, September 11, 2017 at 11:36:33 AM UTC-4, James Bardin wrote:
>
>
> Rather than waiting for just the `Listener.Close` call to return, try 
> waiting for the call to `Listener.Accept()` to return with a non-Temporary 
> error. That should error as the result of the file descriptor being closed, 
> and give you the ordering you need.
>
>
Thanks, this was very helpful. I found these links:

https://github.com/golang/go/issues/4373
https://github.com/golang/go/issues/11219
https://github.com/golang/go/commit/fb4b4342fe298fda640bfa74f24b7bd58519deba

It should in fact be possible to test either `err.Temporary()` or the 
actual error string (as in #19252), and then any execution that 
happens-after a successful test will be able to rebind.

Here's what I'm still uncertain about: it's not clear on the basis of the 
API that the main() goroutine needs to coordinate with any other goroutines 
in the first place. So it's clear that a goroutine blocking (so to speak) 
on Accept() requires this coordination, but could there be others? Are 
there more potential situations in which another goroutine is holding 
references to the underlying file descriptor?

-- 
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] Doing "C-like" things in Go

[CampNowhere]

I am a C developer and am trying to pick up Go.

My question is this. C doesn't "care" about truthfulness, it just cares 
about zero and non-zero when evaluating a logical AND operator. So 
something like the following in C is totally kosher:

int a = 10;
int b = 20;

while(a && b)
{
do_something();
}

However, Go requires blloean values used with the logical AND operator ... 
so my necessary code change for Go implementation becomes the following: 

var a,b int = 10,20

for (a != 0) && (b != 0) {
do_something()
}

Is doing things this way absolutely necessary? It seems a lot clunkier and 
less elegant.

-- 
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: bufio.Writer and timeouts

[Sangjin Lee]

Is extending the deadline right before flushing an option? If your deadline 
is based on a relative duration, you could apply the same delay on Flush() 
too because Flush() may incur write, no?

On Saturday, September 9, 2017 at 8:17:24 AM UTC-7, Juliusz Chroboczek 
wrote:
>
> > bufio.Writer is about 200 lines, and you probably don't even need all 
> > of them.  Just copy it and modify it for your purposes. 
>
> Ok, thanks. 
>
> -- Juliusz 
>
>

-- 
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: Do you guys use ORMs when working with SQL?

[Simon Ritchie]

> Why would someone want to switch from PostgreSQL to MySQL?

It's fairly common to use one database for production and another (often in 
memory) for testing, with an ORM hiding the differences.

-- 
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: net: unclear how to confirm synchronously that a net.TCPListener is closed

[James Bardin]

On Monday, September 11, 2017 at 5:53:10 AM UTC-4, Shivaram Lingamneni 
wrote:
>
>
> 1. Using `Listener.Close()` to interrupt the `Listener.Accept()` call 
> on the other goroutine 
> 2. Using a channel to tell the other goroutine that it should call 
> `Listener.Close()` itself and exit 
> 3. Using a channel to wait for the other goroutine to complete its 
> call to `Listener.Close()` 
>
>

Rather than waiting for just the `Listener.Close` call to return, try 
waiting for the call to `Listener.Accept()` to return with a non-Temporary 
error. That should error as the result of the file descriptor being closed, 
and give you the ordering you need.

-- 
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: error handling needs syntactical sugar

[Konstantin Khomoutov]

On Mon, Sep 11, 2017 at 08:49:30PM +1200, Tim Uckun wrote:

> | However, what's great for avoiding straightforward failures becomes a
> | nightmare when your goal is to guarantee that no undefined behaviour
> | happens
> 
> It seems to me that if this is your goal other languages are more suitable.
> Erlang for example is famous for it's error handling capability,
> elm guarantees no runtime errors, and some other functional languages can
> be proven mathematically at compile time.

That's not what the author used the term "no undefined behaviour" for;
he referred to the simpler idea of having all possible code paths in the
program flow being handled.

When you have exceptions, you have two problems:

* When they are handled not right at the spot where they are generated, you
  - Lose track of the points where they may be generated;
  - Have hard time distinguishing between exceptions occured in
different places in the control flow (unless you use super-shallow
and super-wide type hierarchy or encode this information in the
exceptions).
* When new exceptions are added, you have to identify and modify all
  places where they're handled.

That's why typically "exception handling" indeed means having try/catch
somewhere at the top level and displaying an error message dialog box
(or a HTTP 500 Internal Error page) to the user which is not error
handling but "avoiding straightforward failures".

As to your particular examples, I'm not familiar with Elm but Erlang
stands out for two reasons:

- It has the so-called "pattern matching" which, coupled with
  Erlang's typelessness, allows to implement something which works like
  "algebraic types".  That is, it's easy to write code which asserts
  specific "shapes" and contents of the values at runtime, and crashes
  when these expectatiosn are not met.  While this is very neat, pretty
  much of this is covered by Go's static types.

- It implements the so-called "supervision trees" which allow you to
  construct hierarchies of "processes" in which parents get notified
  when the children crash, and policies for restarting those processes
  which crashed.

  While, again, being very neat, their ultimate usefullness is something
  disputable: when you have a panic in your Go code, this means you
  have a bug, and given the fact Go is a compiled language, this may
  mean your whole runtime is an unknown state.

  All in all, implementation of supervision trees for Go do exist.

-- 
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] if condition in html template

[Shawn Milochik]

On Mon, Sep 11, 2017 at 7:32 AM, Jakob Borg  wrote:

> The clean way to do this, in my opinion, is to make your item/element a
> type that knows whether it's failed or not.
>
> https://play.golang.org/p/K_t8iEZvUc
>
> You can also inject strings.Contains or similar using
> https://golang.org/pkg/html/template/#Template.Funcs
>
>
Or return the strings in two separate slices -- one for the "good" and the
other for the failed. It would not only solve this problem, but allow you
to separate the failed ones visually.

-- 
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] if condition in html template

[Jakob Borg]

The clean way to do this, in my opinion, is to make your item/element a type 
that knows whether it's failed or not.

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

You can also inject strings.Contains or similar using 
https://golang.org/pkg/html/template/#Template.Funcs

//jb

> On 11 Sep 2017, at 09:25, ivo.hechm...@gmail.com wrote:
> 
> Hello golang-nuts,
> 
> My problem: in a html page, I iterate over a list (of strings). the items are 
> names of backupfiles. Sometimes, a backup has failed, in this case, the 
> backupfilename contains the token .FAILED. 
> when i print the list of items, I would like to check if I have to print a 
> restore-link or not. Obviously, I should not print a restore link for backups 
> that contains the token .FAILED.
> 
> 
>   {{ range $element := .Items }}
>   
> {{ $element }}
> {{ if CONDITION }}
>href="javascript:action('restore','{{$element}}');">Restore
> {{ end }}
>   
>   {{ end }}
> 
> 
> So i need a regex or -contains- function for CONDITION. But I only found the  
> eq, ne, lt, le, gt, and ge, functions. Is there a way to check a String in 
> the condition?
> 
> Thank you very much for any hints...
> 
> Ivo
> 
> -- 
> 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] net: unclear how to confirm synchronously that a net.TCPListener is closed

[Shivaram Lingamneni]

I'm having trouble understanding an aspect of the `Listener` API.
Specifically, when using `net.Listen` to bind to an address, how can
one close the listener in such a way that the address is guaranteed to
be available for binding again?

Here's a test case for Go 1.9:

https://gist.github.com/slingamn/f1f2ef4a8d004e67a9b0f27b698a5b13

This is a simple TCP ping-pong server that uses channels for
connection handoff. The wrinkle is that I'm trying to periodically
close the connection from a separate goroutine, then open a new
connection that rebinds to the address. (The non-toy use case for this
is implementing reload of configuration files in a long-running
server.) This is implemented by:

1. Using `Listener.Close()` to interrupt the `Listener.Accept()` call
on the other goroutine
2. Using a channel to tell the other goroutine that it should call
`Listener.Close()` itself and exit
3. Using a channel to wait for the other goroutine to complete its
call to `Listener.Close()`

Observed behavior:

1. As written, the code appears to work (it runs correctly, and no
races are reported under stress testing with `-race`)
2. When step 3 above (waiting for the other goroutine to call
`Listener.Close`) is omitted (by running the test case with the
command-line argument `--waitforstop=false`), the program crashes
with: `listen error: listen tcp :: bind: address already in use`.

According to `strace`, the problem is that the `close(2)` call on the
underlying socket has not executed by the time the goroutine executing
`main()` tries to create the new listener; therefore the `bind(2)`
call fails with `EADDRINUSE`. Based on my reading of the runtime's
source code, this is because the underlying file descriptor is
reference-counted, and `close(2)` is not called until the reference
count drops to 0. The first `Close()` call merely results in a decref,
and the second call closes the file descriptor.

The problem I'm having is that based on my reading of the
documentation, I'm unable to either prove that step 3 makes the code
safe (i.e., that by the time `<-wrapper.HasStopped` finishes, the
underlying socket has definitely been closed), or understand why the
omission of step 3 makes the code unsafe (i.e., why the reference
count does not immediately go to 0 after the `main()` goroutine calls
`Listener.Close()`). Is there any way to get a synchronous guarantee
that the underlying socket has been closed?

Thanks very much for your time.

-- 
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] CodeBlocks dependencies management

[aasdelat via golang-nuts]

Hello, all:

I want, firstly, to congratulate Damar for the great job he is doing by 
providing the Fortran community with this great tool.

Lastly, I have a question about the usage that I have not found in the 
documentation. The threads in this Forum do not address exactly the 
question that I have.

The question is:

Does CodeBlocks take care of the dependency between two projects?.

Documentation says: yes. I only have to go to Project -> Properties 
->Project's depencencies , and mark the project on which the active one 
depends.

Suppose that we have two opened projects: one are libraries and the other 
one is a program that uses those libraries.

I have the project of the program as the active project and I follow the 
steps stated above to mark the other project as the one on which the active 
one depends.

Then, I link the current project (the program, not the libraries) and I get 
a lot of error messages saying that it does not find a lot of functions: 
the ones defined in the libraries.

When I check the command line that Codeblocks has issued to make the link, 
I can see that it din not specify the libraries of the other project.

So, the CodeBlocks takes care of dependencies just to compile one project 
before another, but not to include the compiled libraries of one project, 
in the project that depends on it.

Is this the spected behavior?. If yes, how do I include the needed 
libraries?.

Thanks a lot.

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

[go-nuts] if condition in html template

[ivo . hechmann]

Hello golang-nuts,

My problem: in a html page, I iterate over a list (of strings). the items 
are names of backupfiles. Sometimes, a backup has failed, in this case, the 
backupfilename contains the token .FAILED. 
when i print the list of items, I would like to check if I have to print a 
restore-link or not. Obviously, I should not print a restore link for 
backups that contains the token .FAILED.


  {{ range $element := .Items }}
  
{{ $element }}
{{ if CONDITION }}
  Restore
{{ end }}
  
  {{ end }}


So i need a regex or -contains- function for CONDITION. But I only found 
the  eq, ne, lt, le, gt, and ge, functions. Is there a way to check a 
String in the condition?

Thank you very much for any hints...

Ivo

-- 
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: error handling needs syntactical sugar

[Tim Uckun]

| However, what's great for avoiding straightforward failures becomes a
| nightmare when your goal is to guarantee that no undefined behaviour
| happens

It seems to me that if this is your goal other languages are more suitable.
Erlang for example is famous for it's error handling capability, elm
guarantees no runtime errors, and some other functional languages can be
proven mathematically at compile time.

Go doesn't take that route which is one of the reasons why it's more
popular than those languages :)

-- 
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: error handling needs syntactical sugar

[Konstantin Khomoutov]

On Wed, Sep 06, 2017 at 11:00:08PM -0700, Tim Uckun wrote:

> Totally not a go programmer but here are my worthless two cents.
> 
> I don't see anything wrong with the try catch paradigm, you can choose your 
> granularity. If you want to check every call then you can, if you want to 
> let a few cluster together you can. You guys make is sound like go style 
> error handling is the only way to catch errors at every step. That's not 
> true at all.  
[...]

Actually, I do think there are cases when you don't care which error has
actually happened, and where -- you just want to abort processing and
quit.  Unfortunately, this only works for "batch-style" processing, like
shell scripts -- where you want the whole thing to be done, or to fail
ASAP should any problem be detected (well, sometimes, though quite much
more rarely, you'd even want to merely log errors and continue to chug
away with the operations).

I have a goto writeup on exceptions bookmarked, which I invite you to
read [1].

The key point from it, which pretty much summarizes the idea behind how
error handing is done in Go, is:

| C++ exceptions … are great for guaranteeing that program doesn't
| fail — just wrap the main function in try/catch block and you can
| handle all the errors in a single place.
|
| However, what's great for avoiding straightforward failures becomes a
| nightmare when your goal is to guarantee that no undefined behaviour
| happens. The decoupling between raising of the exception and handling
| it, that makes avoiding failures so easy in C++, makes it virtually
| impossible to guarantee that the program never runs info undefined
| behaviour.

1. http://250bpm.com/blog:4

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