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 c
| 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
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 h
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
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/slin
Hello All,
I do apologise for Interrupting your Technical Group with Recruitment.
However, i am seeking a GoLang developer with 5 years of commercial
experience. I'll attach a job spec below.
If you or you know anyone who would be interested in this role, any help
you could give would be much
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,
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/ht
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.
> Why would someone want to switch from PostgreSQL to MySQL?
I recently switched a project from PostgreSQL to MySQL. But I sure can’t say I
*wanted* to. We were integrating a dependency that only supports MS SQL Server
and MySQL.
--
You received this message because you are subscribed to the G
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. Us
> 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
On Mon, Sep 11, 2017 at 1:09 PM, Simon Ritchie
wrote:
> > 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.
>
>
Yes, and this is a bad idea, for reas
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 abo
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_somethi
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 pref
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
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
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 s
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
>> waiti
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
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 cod
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
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 th
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 w
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
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
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 retur
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
29 matches
Mail list logo
