Re: [go-nuts] Should it panic when set a channel to nil concurrently

How about the main go compiler? Will the code generated by the main go compiler panic as you analyze? On Monday, March 2, 2020 at 2:11:47 PM UTC+8, Jan Mercl wrote: > > On Mon, Mar 2, 2020 at 6:56 AM burak serdar > wrote: > > > At this point, channel receive is still holding a reference to the

Re: [go-nuts] Should it panic when set a channel to nil concurrently

I'm not sure if the channel receive is atomic. I thought it would get a null pointer dereference error in chanrecv at runtime. On Monday, March 2, 2020 at 1:37:01 PM UTC+8, burak serdar wrote: > > On Sun, Mar 1, 2020 at 9:49 PM Yuan Ting > > wrote: > > > > I write a simple program likes below

Re: [go-nuts] Should it panic when set a channel to nil concurrently

On Mon, Mar 2, 2020 at 6:56 AM burak serdar wrote: > At this point, channel receive is still holding a reference to the > channel (right?), so GC cannot free it. Depends very much on what code the compiler for channel receive generates and on the code in the runtime that implements the channel

Re: [go-nuts] Should it panic when set a channel to nil concurrently

On Sun, Mar 1, 2020 at 10:49 PM Jan Mercl <0xj...@gmail.com> wrote: > > On Mon, Mar 2, 2020 at 6:36 AM burak serdar wrote: > > > Why should it panic? The first goroutine simply sets the channel to > > nil. The second goroutine will either block reading from a non-nil > > channel, or block reading

Re: [go-nuts] Should it panic when set a channel to nil concurrently

On Mon, Mar 2, 2020 at 6:36 AM burak serdar wrote: > Why should it panic? The first goroutine simply sets the channel to > nil. The second goroutine will either block reading from a non-nil > channel, or block reading from a nil channel. There is no code in this > program that would panic. It

Re: [go-nuts] Should it panic when set a channel to nil concurrently

On Sun, Mar 1, 2020 at 9:49 PM Yuan Ting wrote: > > I write a simple program likes below and it triggers a data race alarm with > -race flag. But no matter how I run, this program will not panic. I know it > is legal to receive messages from nil channels, but I don't quite understand > why

[go-nuts] Should it panic when set a channel to nil concurrently

I write a simple program likes below and it triggers a data race alarm with -race flag. But no matter how I run, this program will not panic. I know it is legal to receive messages from nil channels, but I don't quite understand why this program does not panic in the presence of data races. ch

Re: [go-nuts] How to handle EINTR from syscall.Dup2

Ian, It is unclear how to interpret the POSIX specification regarding dup2 returning EINTR. The POSIX specification [1] of dup2 says: "If the close operation fails to close *fildes2*, *dup2*() shall return -1 without changing the open file description to which *fildes2* refers." It appears

Re: [go-nuts] How to handle EINTR from syscall.Dup2

...and if true, this notion of “it’s atomic unless it’s not” deserves a name: the “subatomic operation.” On Sun, Mar 1, 2020 at 6:56 AM Ian Lance Taylor wrote: > On Sat, Feb 29, 2020 at 9:45 PM Philip Boampong > wrote: > > > > > And dup2 is not documented to return EINTR > > > > Yes, it is. In

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

On Mon, Mar 2, 2020 at 12:01 AM Robert Engels wrote: > Any decent compiler should in-line these private function calls in all > cases - so no function call overhead. > FTR, while I agree that any compiler *can* inline them, I wouldn't feel confident to make as broad an assertion as this -

Re: [go-nuts] help w/ therecipe/qt

Yes, thanks Justin.  It looks that's just what I need. --rob On 3/1/20 3:16 PM, Justin Israel wrote: On Mon, Mar 2, 2020 at 6:48 AM rob > wrote: The exact problem is one of the first in chapter 4 MainWindow::MainWindow() {    

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

Any decent compiler should in-line these private function calls in all cases - so no function call overhead. Give me a system with lots of small easily tested and documented methods over one with 1000 line methods any day. > On Mar 1, 2020, at 4:48 PM, 'Axel Wagner' via golang-nuts >

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

On Sun, Mar 1, 2020 at 11:35 PM Warren Stephens wrote: > Axel, > > I like your example. Var *e* would get re-declared -- so that is a > change. However, var *x* is not visible past the *with* statement -- > only var *a* is brought forward. > > So we need another attempt at breaking this. :-)

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

On Mon, Mar 2, 2020 at 8:06 AM Warren Stephens wrote: > It could made to look more Go-like... > >internal mystep2(lines, thing2): (mymap, err) Ian isn't talking about the particular syntax (e.g. punctuation or keywords). He is talking about the semantics (statements that hide scope, hidden

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

Axel, I like your example. Var *e* would get re-declared -- so that is a change. However, var *x* is not visible past the *with* statement -- only var *a* is brought forward. So we need another attempt at breaking this. :-) I will try to think of how to get a re-declaration to break

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

(uhm, nevermind that I didn't actually internalize the supposed syntax enough. Should be "step with: a", I guess?) On Sun, Mar 1, 2020 at 11:13 PM Axel Wagner wrote: > On Sun, Mar 1, 2020 at 3:17 PM Warren Stephens < > wsteph...@prognoshealth.com> wrote: > >> So the developer is in the

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

On Sun, Mar 1, 2020 at 3:17 PM Warren Stephens wrote: > So the developer is in the situation of *refactoring code that is known > to be working in order to write tests!* — which are rarely going to be > comprehensive anyway. The risk is breaking something that isn’t broken! > > With my

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

Also note that these *internal* pieces of code would eliminate the inefficiency of calls -- which is non-trivial as I am sometimes dealing with big-data of billions of records of data. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

No worries. It could made to look more Go-like... internal mystep2(lines, thing2): (mymap, err) or something like that. Where "internal" is like "func". The colon is already used for labels. And the results are like the values supplied after a return. -- You received this message

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

On Sun, Mar 1, 2020 at 8:21 AM Warren Stephens wrote: > > // I don't want to get into the specific syntax of the test code directly, > // but a test would start execution here, supplying "lines" and "thing2" > // > mystep2 with: lines, thing2 // <-- hide all local variables from >

Re: [go-nuts] help w/ therecipe/qt

On Mon, Mar 2, 2020 at 6:48 AM rob wrote: > The exact problem is one of the first in chapter 4 > > MainWindow::MainWindow() > { > setWindowTitle("SRM System"); > setFixedSize(500, 500); > QPixmap newIcon("new.png"); > QPixmap openIcon("open.png"); > QPixmap

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

Robert, To me, code broken up into smaller pieces can “seem” more maintainable, but (actually more importantly to me) often is far less comprehensible. And I must comprehend it in order to maintain it. I recently returned to a piece of code that someone else had refactored in order to write

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

If you need to test your code that way it needs a better design. If the internal code within the function under test is trivial then testing purely the outer function will suffice. If the internal code is that complex it should be its own non-exported function that can be documented and tested

Re: [go-nuts] help w/ therecipe/qt

The exact problem is one of the first in chapter 4 MainWindow::MainWindow() {    setWindowTitle("SRM System");    setFixedSize(500, 500);    QPixmap newIcon("new.png");    QPixmap openIcon("open.png");    QPixmap closeIcon("close.png");    // Setup File Menu    fileMenu =

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

// I don't want to get into the specific syntax of the test code directly, // but a test would start execution here, supplying "lines" and "thing2" // mystep2 with: lines, thing2 // <-- hide all local variables from above except for lines and thing2 mymap :=

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

On Sat, Feb 29, 2020 at 10:11 AM Warren Stephens wrote: > > The labelled with statements would allow for a test to be written > specifically for each step of a function. > > Each test would begin at the with statement, providing the variables and > values required, and end at the next with

Re: [go-nuts] Re: why would slice = slice[1:] allocate

On Sun, Mar 1, 2020 at 5:56 AM Jason E. Aten wrote: > > escape analysis is eliminating the allocation in the simplification. in > reality the slice is stored in a persistent struct. Can you show us a complete example program? It's possible that the allocation is getting attributed to the wrong

Re: [go-nuts] How to handle EINTR from syscall.Dup2

On Sat, Feb 29, 2020 at 9:45 PM Philip Boampong wrote: > > > And dup2 is not documented to return EINTR > > Yes, it is. In the same man page you quoted [1]. > | EINTR The dup2() or dup3() call was interrupted by a signal; see > | signal(7). > > > and the Linux kernel code shown above

[go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

All, Thanks for the advice, but I should have mentioned that I already know about Test Driven Development. I live in the real world of commercial software development (>3 decades). Here is the real world scenario: 1. Write some code quick — must stay on schedule, there is actually no

Re: [go-nuts] Re: why would slice = slice[1:] allocate

escape analysis is eliminating the allocation in the simplification. in reality the slice is stored in a persistent struct. On Sun, Mar 1, 2020 at 8:50 AM wrote: > Jason, > > Your example does not appear to support your claim. > > A benchmark: > > package main > > import ( > "strconv" >

[go-nuts] Re: why would slice = slice[1:] allocate

Jason, Your example does not appear to support your claim. A benchmark: package main import ( "strconv" "testing" ) type A struct { B string } func mycode(slice []A) { slice = slice[1:] } func BenchmarkMycode(b *testing.B) { a := make([]A, 256) for i := range a {

Re: [go-nuts] How to handle EINTR from syscall.Dup2

Thanks, now I understand the concerns better. For Linux I stay with my remark, if you get an error from dup2 nothing has happened. But this is not true for POSIX, which requires the error of the close to be reported. Linux doesn't do it, if you look carefully at the code that I have sent, the