Unapplied patches

[Charles]

@kobi7, no worries. There's good points on all sides here.

--

ticket:34 is prime example of something undecided. Do we want to continue to overload the "is" keyword? Do we want to tell people that in the middle of an expression "is" will mean object identity if they are implementing a method, but it will mean member visibility if they are implementing a var, but back to object identity if it's a property...

Well actually "is" still means "visibility" outside the method or property body.

I guess since no one has come up with a proposal to split "is" up into two words that we actually like, so I'll go with the last patch on the ticket.

But note that when I reviewed the ticket from top to bottom, I loved your comments here (emphasis mine):
"""
When I finished what I was doing and stopped fuming I had another pass over this report and the patches to date - both of which I now dislike nearly as much as I dislike the current status quo
"""

If I had applied the first patches, which I bounced with stated reasons, you would have ended up with something you didn't even like!

Btw I don't think I ever feel the weight of what ticket:34 addresses because I have a habit of always putting my "shared" members in a "shared" section, plus I use the underscores for protected and private. ... In case you were wondering why this never bothered me. Unlike Cobra internal exceptions, it just doesn't halt my app development.

--

Regarding these bugs you didn't know about, are you developing applications with Cobra? That's how I'm finding these things.

And being in the middle of building whatever app, I don't have time to post the ticket and wait an unspecified number of days to see if they'll be fixed. When you see me push a fix straight in that usually means I was building something in Cobra when I got interrupted by the bug. I make the fix and continue development.

--

And yes ticket:356 "silent contract on streams" is pretty bad. About 100 X worse than deprecating the old for-statement (ticket:8). Contracts throw exceptions when their conditions are not met. So when you don't get that exception, you know the conditions were met and now you're reasoning about a bug with false information. You can waste a lot of time in that way and I did.

--

You asked about throughput of patch applications, which is a fair question. I have been hoping for some time that by (1) reducing the addition of new features, (2) not implementing pet projects and (3) focusing on fixes that are showstoppers during app development... that the showstoppers would go away.

To some extent they have. I did a web app recently and ran into 3 problems which is fewer than I have run into on previous projects that had less code.

--

@nerdzero: I don't see how a megapatch would fix your issue with testify. And yes patches are more work than they would seem upfront. And no, I don't think one unified patch will be helpful.

--

Going forward, I will budget time in my week, every week (sans vacation or illness), to look at patches. ticket:34 is now in.

[hopscc]

Do we want to continue to overload the "is" keyword?

That is the most backward compatible solution after all...
Its unfortunate that 'is' ended up overloaded in 2 different places for 2 different purposes
- Object identity in a statement vs declared item visibility in a declaration
but the uses their are reasonable in both cases so its a matter of making sure (or resolving) they dont collide....

you would have ended up with something you didn't even like!

No, totally Incorrect - would have ended up with removal of a pain point and correction of a stupid little ankle-tapping gotcha
- the dislike of the 2 solutions already given (I didnt specify the grounds) was on stylistic grounds and the idea that could do better....
If either of the previous 2 solutions had actually been actioned the result would have been more than acceptable because the
entire problem would have gone away

are you developing applications with Cobra ?

Some, minor and not very large - when I do I stay away from things that might lead me into murky/problem compiler implementation areas on the grounds that at that point I'm doing an app not testing/exercising the compiler - If I find any I ticket them and use some other construct (you'll note few tkts for these sorts of things from me)

... I make the fix and continue development
Fine but you can hardly complain that your time is taken up fixing these 'show-stopper bugs' if
a) you are the only one that finds/exercises/sees them and b) you set things up so no-one else is able to help fix them.

You can waste a lot of time in that way and I did.

Cool - you suffer so we dont have to ...
Me I would just tkt the problem (and hopefully provide a sample) and not use streams for that so as to get my app done... I've worked on large systems with compilers broken in various ways - as you say you can waste a lot of time and effort in trying to beat on or around a compiler bug in which effort your app is not advancing - your choice.

... that the showstoppers would go away.... to some extent they have

Seems to me that the showstoppers arent mainly in new code ( old subterranean lurkers indicative of missed situations or unintended generic complications)
so I'm not sure how well 1) is addressing that issue beyond maybe not allowing any new (obvious) bugs in ( or anything else tho')....

Maybe a better approach is allowing a window at some point for features/enhancements followed by a stabilisation phase ???
or better forshadowing suggested/proposed enhancements...

I will budget time in my week, every week (sans vacation or illness), to look at patches.

look -> action
This is still the "Chuck must work harder" solution... ( 2x )
The worry I (still) have is - is that sustainable/fair though, given that you will have other more interesting things (pet projects) to do with your time?

ticket:34 is now in.

Thank you.

(next choice is ticket:230

[Charles]

Fine but you can hardly complain that your time is taken up fixing these 'show-stopper bugs' if
a) you are the only one that finds/exercises/sees them and b) you set things up so no-one else is able to help fix them.

Well I can complain that it's disappointing.

You can waste a lot of time in that way and I did.

Cool - you suffer so we dont have to ...
Me I would just tkt the problem (and hopefully provide a sample) and not use streams for that so as to get my app done... I've worked on large systems with compilers broken in various ways - as you say you can waste a lot of time and effort in trying to beat on or around a compiler bug in which effort your app is not advancing - your choice.

You misunderstand this particular situation with the contracts bug. First, I did as you suggest, ticketed the item when I discovered it and moved on in my app development. Second, the time that was wasted was prior to realizing that the contracts for a given method weren't executing at all. It wasn't wasted because I fixed the bug (which wouldn't have been a waste anyway).

The worry I (still) have is - is that sustainable/fair though, given that you will have other more interesting things (pet projects) to do with your time?

Well, we'll start with giving it a try. I'm getting into weekly time budgets now.

[Charles]

(next choice is ticket:230

I worked on 230 today. New comments and fresh patch.

[Charles]

I reopened ticket:34 since the patch breaks the Cobra IDE add-in:

Project\!CobraCompilerParameters.cobra(100,3): error: Expecting DEDENT, but got "has" instead.
Project\!CobraProjectParameters.cobra(21,3): error: Expecting DEDENT, but got "has" instead.

var _performanceQualityOption = PerfQualOption.Default
        has ItemProperty("PerformanceQualityOption", defaultValue = PerfQualOption.Default)

Reverting to 0.9.6 restores the compilation of the add-in.

[Charles]

Hops, nerdzero has patched and commented on the ticket. I commented. Let us know if you have any comments yourself.

[hopscc]

Sorry hadn't answered - been away last week...

That failing test was to for completeness to exercise a case with all the possible clauses (nicely laid out on separate lines) and with the changed positioning of the initialisation clause - its distinct from the cases with the clauses joined on (a) single line(s)
Its a reasonably logical layout that should be valid...

The coding of the patch is a better approach than the previously more rigorous position dependent probing for clauses in expected orders..
Leave it as is FTM and I'll take a task to look at whats needed to support the failing case...

[hopscc]

new fixup patches for both
ticket:34
and ticket:230

[Charles]

ticket:34 is done

[hopscc]

So - two months on , hows progress on the bug/un-applied patch backlog ?