Bug Fix Phase Only

[alexborro]

I think we should start a bugfix phase only.

We have had many massive changes in core parts like stepper, planner and temperature controllers.

It is time to start a bugfix phase, I mean, avoid more massive changes until we have bugs fixed. Otherwise it will be hard to track down those issues.

What do you guys think about it?

Cheers.

Alex.

[Natealus]

Agreed it'll be easier to track down if we stick to current features we have that need fine tuning. I got the delta leveling stuff going now we're trying to test and track down odd behaviors.

[Sniffle]

Marlin has definitely come a long way towards a future of expandability with everything @thinkyhead has been doing as far as maintainability for the future, I'm not sure what else he has planned but it's definitely time to get a rock solid code base to start expanding upon again. Things are getting to the point of breaking other things.

I'm no C(or the variant of C that arduino uses) expert in the slightest and if I had time i would put more effort into learning so i could help more... but could this be taken in a more OO type direction, taking things like bed leveling and just making it it's own object that once fixed isn't touched anymore, to add a feature we just change a constructor to override the default constructor etc. that might be more of a thing for the future after a solid base to start from, but having a lot of black boxes that have an API for inputs and returns, would make the code even further maintainable in the future.

Just thoughts and opinions here but a highly stable code base with the current feature set will make a lot of users happy IMO.

[Natealus]

Yeah that's somewhat the way the coding has been going to be standardized and some features and subsystems having their own files so as to make configuration not such a mess. Delta bed leveling was one of the last features I was hoping for. Hard to think of something else to do with my printer that isn't in here yet lol. I've been very happy with the progress and now we just need to test and verify and fix. :)

[thinkyhead]

🔧

[thinkyhead]

Lots of bugs fixed this weekend, hopefully well on the way to a solid release. I'm all for a phase of bug-fixes only, with no new features for a few weeks. We'll just mark any issues that need to be put off with a special tag, On Hold During Bugfix and make a note in the issue queue that new features are on hold for a little while.

[boelle]

+1 from me..... it has always been my idea with the milestones to focus on bugs only...

as its easter holidays here in DK i can be arround much of the time...

my printer is also near ready for testing, but it want to reprint all the parts on it as the old ones are in lees than perfect shape and i also want to have the parts for auto bed level (or whatever its called)

are google hangout the preferfed method to chat about dev?

[boelle]

btw... this on hold thing... shout that be put on all the improvements and feature request?

[boelle]

currently i'm putting all the feature requests etc in milestone labeled very differently and adding the latest verified issues in to milestones also...

it will be very simple to do bugfixing... just take the lowest numbered bugfix milestone and take the first open issue... fix it and mark it closed and go on to the next one

or i could assign issues to a person so they have a list of things to do... and avoid that people are working on the same issue

[boelle]

added the new tag to all feature requests and improvements...

[boelle]

@ErikZalm @galexander1 @stv0g @tmilker @alexborro @thinkyhead @nothinman

Q: are any of you able to dedicate some time on fixing bugs? and if so should i just distribute the current list of bugs evenly?

we have 10 open issues left... most of them are assigned to @thinkyhead, but they could be fixed much faster if they are distributed more evenly

[thinkyhead]

@boelle I'm keen to get auto-leveling fixed up, so I will be focusing my attention there.

[boelle]

oki... will go thourgh the milestones and anything that smells like auto level gets your name on it....

the rest i'm not sure.... i could risk getting a written arse kick and just delegate the work :-D

[daid]

@boelle Sorry, don't have the time :(

[boelle]

np... you are of the "list"

[boelle]

@ErikZalm @galexander1 @stv0g @tmilker @alexborro @thinkyhead @nothinman

any of you have time to pitch in on fixing issues?

[thinkyhead]

If Ultimaker hires us all, none of us will have the time. 😉

[Natealus]

Why not join my company and we make our own printer? ;)

[thinkyhead]

@Natealus That sounds fun! By the way, what is your timezone relative to GMT? I'm trying to figure out when would be reasonable times to do a Google Hangout, when most developers are awake and available for an hour or so.

[Natealus]

I'm in Mountain Time UTC -07:00. We're in based in Ogden, Utah.

[thinkyhead]

@Natealus Ah good, you're in my time zone, that makes it easier to coordinate.

[boelle]

@Natealus Just curious... but can i glue some of the bugs on you?

[thinkyhead]

Take note everyone, that the Coding Standards documentation is finally ready for prime time.

[AnHardt]

@thinkyhead
Example 1 in the wiki looks wrong to me.

if (...) {

}

should be indented.

[alexborro]

I don't like this formatting as well.

I prefer:

if (..)
{
commands;
}

[thinkyhead]

Everyone has a preference, so I'm inclined to say this should not be put up for a vote or a religious war. This is how the majority of the code is now, and I strongly advocate for learning to appreciate the end-of-line usage, and to apply it with rare exceptions. Why?

• More code on the screen, especially in deeply nested situations.
• Removes superfluous extra lines as a requirement.
• Makes intentional blank lines stand out.
• Makes code-folding more compact - more information on-screen.
• Encourages more attention to consistent indentation and formatting.
• Encourages a pragmatic over a pedantic coding style.
• Allows aging and weary coders to use larger fonts.

Stylistically, I feel that compacting the code vertically encourages code-writers to utilize blank lines more in the role of a clarifying feature, to make code units stand out in cases where it's not so obvious from indentation alone. Extra white-space around individual code units within a loop block will have blank lines around them, preferably with a heading comment, making them stand out as "fuzzy" units, then as you focus in on the code unit its structure is made clear through indentation and well-named variables. I feel there are very few points in the code where an extra hanging brace will improve clarity or better reveal structure. (Code that I haven't fixed the formatting in yet doesn't count!)

[emartinez167]

+1 for keeping the coding standards.

Regards,

Ernesto

On 5 Apr 2015, at 08:49, Scott Lahteine notifications@github.com wrote:

Everyone has a preference, so I'm inclined to say this should not be put up for a vote or a religious war. This is how the majority of the code is now, and I strongly advocate for learning to appreciate the end-of-line usage, and to apply it with rare exceptions. Why?

More code on the screen, especially in deeply nested situations.
Removes superfluous extra lines as a requirement.
Makes intentional blank lines stand out.
Makes code-folding more compact - more information on-screen.
Encourages more attention to consistent indentation and formatting.
Encourages a pragmatic over a pedantic coding style.
Allows aging and weary coders to use larger fonts.
Stylistically, I feel that compacting the code vertically encourages code-writers to utilize blank lines more in the role of a clarifying feature, to make code units stand out in cases where it's not so obvious from indentation alone. Extra white-space around individual code units within a loop block will have blank lines around them, preferably with a heading comment, making them stand out as "fuzzy" units, then as you focus in on the code unit its structure is made clear through indentation and well-named variables. I feel there are very few points in the code where an extra hanging brace will improve clarity or better reveal structure. (Code that I haven't fixed the formatting in yet doesn't count!)

—
Reply to this email directly or view it on GitHub.

[tmilker]

The formatting the existing code uses should be the standard. Making dramatic changes to formatting creates superfluous and confusing commits. It doesn't fall under any kind of category of bug fixing but definitely has a strong chance of creating them.

[Sniffle]

the current code base doesnt have a coding standard that's why one is being implemented, file to file code block to code block the formatting changes

[thinkyhead]

@Sniffle You should compare Marlin from a year ago to the current code-base if the direction that it's been moving is not obvious just from looking at its current state. Sweeping changes to formatting are generally disliked, so I have resisted the urge to redo everything, but as code gets attention the updated standards are being faithfully applied.

[Sniffle]

@thinkyhead I agree sweeping changes are bad, and often cause lots of trouble, but as you have done, by implementing the standards as you've gone it's a slow gradual change, to a higher coding standard to make marlin more survivable longterm. I understand what you are doing and how you are going about it. I just wish i had more time to spend learning the syntax of C++ so that i could help more. All i am good for right now is higher level code planning.

[thinkyhead]

@Sniffle The hard part was, up to now, no one could "assert" any coding standard because there just wasn't one. There were some good de-facto standards from Arduino libraries and the Sprinter / Grbl origins, and those have been kept and expanded upon. But the code was (is) far from readable or maintainable, especially where features have inserted code with no consistent formatting. So, forget about code-folding most sources with a naïve editor at the moment – you have to have a syntax-aware editor. XCode and VisualStudio can parse the syntax and do it right, but lightweight editors like TextMate and Sublime will choke. But that will be fixed in due time….

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.