Help wanted: Code cleanup sweeper (GitHub issue 6589)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Help wanted: Code cleanup sweeper (GitHub issue 6589)

Joseph Lee

Hi all, especially fellow Core committers,

 

As 2016 is winding to a close, I thought it would be a good time to plan ahead for 2017, especially when it comes to source code maintenance. Specifically, I believe that this is a good time for us to sweep the source code clean (remove deprecated code paths, making variable names consistent and others).

 

Relevant issue can be found at:

https://github.com/nvaccess/nvda/issues/6589

 

Some issues I found:

 

·         Blank lines that are really tabs.

·         Removing truly deprecated code paths (e.g. config.save).

·         Making variable names consistent.

·         Undocumented functions that are crucial for add-ons.

·         Missing copyright headers.

·         Other things here and there.

 

As this is a huge undertaking, I need help from the coding community as to areas we should look at, specializations and combining our investigations and work into a pull request. Please let me know if you are interested in helping out with sweeping the NVDA source code. Thanks.

Cheers,

Joseph


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help wanted: Code cleanup sweeper (GitHub issue 6589)

Brian's Mail list account BY
Although I do understand why, I'd be very wary since its going to be very
easy to introduce obscure bugs this way, if something is altered which is
used elsewhere but not documented as the same writer  wrote both, for
example.

Just saying.
 Brian

[hidden email]
Sent via blueyonder.
Please address personal email to:-
[hidden email], putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <[hidden email]>
To: "'NVDA screen reader development'" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, November 24, 2016 7:36 AM
Subject: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue 6589)


> Hi all, especially fellow Core committers,
>
>
>
> As 2016 is winding to a close, I thought it would be a good time to plan
> ahead for 2017, especially when it comes to source code maintenance.
> Specifically, I believe that this is a good time for us to sweep the
> source
> code clean (remove deprecated code paths, making variable names consistent
> and others).
>
>
>
> Relevant issue can be found at:
>
> https://github.com/nvaccess/nvda/issues/6589
>
>
>
> Some issues I found:
>
>
>
> *         Blank lines that are really tabs.
>
> *         Removing truly deprecated code paths (e.g. config.save).
>
> *         Making variable names consistent.
>
> *         Undocumented functions that are crucial for add-ons.
>
> *         Missing copyright headers.
>
> *         Other things here and there.
>
>
>
> As this is a huge undertaking, I need help from the coding community as to
> areas we should look at, specializations and combining our investigations
> and work into a pull request. Please let me know if you are interested in
> helping out with sweeping the NVDA source code. Thanks.
>
> Cheers,
>
> Joseph
>
>


--------------------------------------------------------------------------------


> ------------------------------------------------------------------------------
>


--------------------------------------------------------------------------------


> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>


------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help wanted: Code cleanup sweeper (GitHub issue 6589)

Sarah Alawami
Which is why  I suggest doing the code clean up one thing at a time and test test test and don't commit the code until it's fixed and the admin approves the patch.

> On Nov 24, 2016, at 3:48 AM, Brian's Mail list account BY <[hidden email]> wrote:
>
> Although I do understand why, I'd be very wary since its going to be very
> easy to introduce obscure bugs this way, if something is altered which is
> used elsewhere but not documented as the same writer  wrote both, for
> example.
>
> Just saying.
> Brian
>
> [hidden email]
> Sent via blueyonder.
> Please address personal email to:-
> [hidden email], putting 'Brian Gaff'
> in the display name field.
> ----- Original Message -----
> From: "Joseph Lee" <[hidden email]>
> To: "'NVDA screen reader development'" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Thursday, November 24, 2016 7:36 AM
> Subject: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue 6589)
>
>
>> Hi all, especially fellow Core committers,
>>
>>
>>
>> As 2016 is winding to a close, I thought it would be a good time to plan
>> ahead for 2017, especially when it comes to source code maintenance.
>> Specifically, I believe that this is a good time for us to sweep the
>> source
>> code clean (remove deprecated code paths, making variable names consistent
>> and others).
>>
>>
>>
>> Relevant issue can be found at:
>>
>> https://github.com/nvaccess/nvda/issues/6589
>>
>>
>>
>> Some issues I found:
>>
>>
>>
>> *         Blank lines that are really tabs.
>>
>> *         Removing truly deprecated code paths (e.g. config.save).
>>
>> *         Making variable names consistent.
>>
>> *         Undocumented functions that are crucial for add-ons.
>>
>> *         Missing copyright headers.
>>
>> *         Other things here and there.
>>
>>
>>
>> As this is a huge undertaking, I need help from the coding community as to
>> areas we should look at, specializations and combining our investigations
>> and work into a pull request. Please let me know if you are interested in
>> helping out with sweeping the NVDA source code. Thanks.
>>
>> Cheers,
>>
>> Joseph
>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>> ------------------------------------------------------------------------------
>>
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help wanted: Code cleanup sweeper (GitHub issue 6589)

Joseph Lee
Hi,
At the moment I'm looking at least impactful fix, namely adding headers to
modules with missing headers. Here, "impact" refers to code paths that has
potential to break. We'll not work on impactful ones until I and others
receive word from add-on authors and other devs that these can be looked at
i.e. no regressions, no add-ons using it anymore and so forth. As noted by
Jamie in a comment for issue 6589, each issue found will be a separate
ticket, with separate yet related PR's addressing various issues, one per
issue found (this also allows specialists to work on their area of specialty
and commit needed fixes; in my case, I'm interested in missing headers and
deprecated code paths, with Derek expressing interest in headers and other
stuff, and Leonard has shown interest in helping out).

The proposed workflow then is as follows:
1. Issues with source code will be submitted as individual issues.
2. There should be a way to examine overall impact of the issue, namely
regression possibilities if a deprecated code path is removed.
3. One or more devs will work on issues identified and submit PR's,
preferably each person working on a separate issue or a group of related
ones. In case of related issues, these should be separate from one another
in order to avoid commit conflicts.
4. When working on issues, devs and/or one or more users should test it to
make sure NVDA's functionality isn't compromised.
5. If the commit involves removing deprecated code path, this must be
documented.

I estimate the overall project to take at least two months, with at least
two or three devs working on it (I'm looking at NVDA 2017.2 as the earliest
release where some of these fixes could end up in Core).

Cheers,
Josehp

-----Original Message-----
From: Sarah Alawami [mailto:[hidden email]]
Sent: Thursday, November 24, 2016 10:01 AM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue
6589)

Which is why  I suggest doing the code clean up one thing at a time and test
test test and don't commit the code until it's fixed and the admin approves
the patch.
> On Nov 24, 2016, at 3:48 AM, Brian's Mail list account BY
<[hidden email]> wrote:

>
> Although I do understand why, I'd be very wary since its going to be
> very easy to introduce obscure bugs this way, if something is altered
> which is used elsewhere but not documented as the same writer  wrote
> both, for example.
>
> Just saying.
> Brian
>
> [hidden email]
> Sent via blueyonder.
> Please address personal email to:-
> [hidden email], putting 'Brian Gaff'
> in the display name field.
> ----- Original Message -----
> From: "Joseph Lee" <[hidden email]>
> To: "'NVDA screen reader development'"
> <[hidden email]>
> Cc: <[hidden email]>
> Sent: Thursday, November 24, 2016 7:36 AM
> Subject: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue
> 6589)
>
>
>> Hi all, especially fellow Core committers,
>>
>>
>>
>> As 2016 is winding to a close, I thought it would be a good time to
>> plan ahead for 2017, especially when it comes to source code maintenance.
>> Specifically, I believe that this is a good time for us to sweep the
>> source code clean (remove deprecated code paths, making variable
>> names consistent and others).
>>
>>
>>
>> Relevant issue can be found at:
>>
>> https://github.com/nvaccess/nvda/issues/6589
>>
>>
>>
>> Some issues I found:
>>
>>
>>
>> *         Blank lines that are really tabs.
>>
>> *         Removing truly deprecated code paths (e.g. config.save).
>>
>> *         Making variable names consistent.
>>
>> *         Undocumented functions that are crucial for add-ons.
>>
>> *         Missing copyright headers.
>>
>> *         Other things here and there.
>>
>>
>>
>> As this is a huge undertaking, I need help from the coding community
>> as to areas we should look at, specializations and combining our
>> investigations and work into a pull request. Please let me know if
>> you are interested in helping out with sweeping the NVDA source code.
Thanks.

>>
>> Cheers,
>>
>> Joseph
>>
>>
>
>
> ----------------------------------------------------------------------
> ----------
>
>
>> ---------------------------------------------------------------------
>> ---------
>>
>
>
> ----------------------------------------------------------------------
> ----------
>
>
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>
>
>
> ----------------------------------------------------------------------
> -------- _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


----------------------------------------------------------------------------
--
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help wanted: Code cleanup sweeper (GitHub issue6589)

Brian's Mail list account BY
The think is though, this is a lot of work for no discernable changes for
the user. OK I'm playing devils advocate here, as I fully realise that
making everything the same format should help in the future as new coders
have to get to grips with the source.
 I mean if Jamie got kidnapped by Aliens tomorrow... etc.



Is there  a tool for  mixed python/c software like nvda to trace
exactlywhich code routines are used by what other parts? One of the biggest
issues often is the old, damn I did not think anything used that any more.
 Indeed the current problem Dropbox has with their 14 version not running on
some processors seems to revolve around some floating point code that has
now been written using sse2 which said processor does not actually have!
 Brian

[hidden email]
Sent via blueyonder.
Please address personal email to:-
[hidden email], putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <[hidden email]>
To: "'NVDA screen reader development'" <[hidden email]>
Sent: Thursday, November 24, 2016 6:25 PM
Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
issue6589)


> Hi,
> At the moment I'm looking at least impactful fix, namely adding headers to
> modules with missing headers. Here, "impact" refers to code paths that has
> potential to break. We'll not work on impactful ones until I and others
> receive word from add-on authors and other devs that these can be looked
> at
> i.e. no regressions, no add-ons using it anymore and so forth. As noted by
> Jamie in a comment for issue 6589, each issue found will be a separate
> ticket, with separate yet related PR's addressing various issues, one per
> issue found (this also allows specialists to work on their area of
> specialty
> and commit needed fixes; in my case, I'm interested in missing headers and
> deprecated code paths, with Derek expressing interest in headers and other
> stuff, and Leonard has shown interest in helping out).
>
> The proposed workflow then is as follows:
> 1. Issues with source code will be submitted as individual issues.
> 2. There should be a way to examine overall impact of the issue, namely
> regression possibilities if a deprecated code path is removed.
> 3. One or more devs will work on issues identified and submit PR's,
> preferably each person working on a separate issue or a group of related
> ones. In case of related issues, these should be separate from one another
> in order to avoid commit conflicts.
> 4. When working on issues, devs and/or one or more users should test it to
> make sure NVDA's functionality isn't compromised.
> 5. If the commit involves removing deprecated code path, this must be
> documented.
>
> I estimate the overall project to take at least two months, with at least
> two or three devs working on it (I'm looking at NVDA 2017.2 as the
> earliest
> release where some of these fixes could end up in Core).
>
> Cheers,
> Josehp
>
> -----Original Message-----
> From: Sarah Alawami [mailto:[hidden email]]
> Sent: Thursday, November 24, 2016 10:01 AM
> To: NVDA screen reader development <[hidden email]>
> Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue
> 6589)
>
> Which is why  I suggest doing the code clean up one thing at a time and
> test
> test test and don't commit the code until it's fixed and the admin
> approves
> the patch.
>> On Nov 24, 2016, at 3:48 AM, Brian's Mail list account BY
> <[hidden email]> wrote:
>>
>> Although I do understand why, I'd be very wary since its going to be
>> very easy to introduce obscure bugs this way, if something is altered
>> which is used elsewhere but not documented as the same writer  wrote
>> both, for example.
>>
>> Just saying.
>> Brian
>>
>> [hidden email]
>> Sent via blueyonder.
>> Please address personal email to:-
>> [hidden email], putting 'Brian Gaff'
>> in the display name field.
>> ----- Original Message -----
>> From: "Joseph Lee" <[hidden email]>
>> To: "'NVDA screen reader development'"
>> <[hidden email]>
>> Cc: <[hidden email]>
>> Sent: Thursday, November 24, 2016 7:36 AM
>> Subject: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue
>> 6589)
>>
>>
>>> Hi all, especially fellow Core committers,
>>>
>>>
>>>
>>> As 2016 is winding to a close, I thought it would be a good time to
>>> plan ahead for 2017, especially when it comes to source code
>>> maintenance.
>>> Specifically, I believe that this is a good time for us to sweep the
>>> source code clean (remove deprecated code paths, making variable
>>> names consistent and others).
>>>
>>>
>>>
>>> Relevant issue can be found at:
>>>
>>> https://github.com/nvaccess/nvda/issues/6589
>>>
>>>
>>>
>>> Some issues I found:
>>>
>>>
>>>
>>> *         Blank lines that are really tabs.
>>>
>>> *         Removing truly deprecated code paths (e.g. config.save).
>>>
>>> *         Making variable names consistent.
>>>
>>> *         Undocumented functions that are crucial for add-ons.
>>>
>>> *         Missing copyright headers.
>>>
>>> *         Other things here and there.
>>>
>>>
>>>
>>> As this is a huge undertaking, I need help from the coding community
>>> as to areas we should look at, specializations and combining our
>>> investigations and work into a pull request. Please let me know if
>>> you are interested in helping out with sweeping the NVDA source code.
> Thanks.
>>>
>>> Cheers,
>>>
>>> Joseph
>>>
>>>
>>
>>
>> ----------------------------------------------------------------------
>> ----------
>>
>>
>>> ---------------------------------------------------------------------
>>> ---------
>>>
>>
>>
>> ----------------------------------------------------------------------
>> ----------
>>
>>
>>> _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>>
>>
>>
>> ----------------------------------------------------------------------
>> -------- _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel 


------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help wanted: Code cleanup sweeper (GitHub issue6589)

Joseph Lee
Hi,
Actually, it does have some impact for end users. Suppose a really old
add-on that people like found itself running on NVDA 2017.x with certain
things removed that the add-on depends on. If we know who wrote it and when,
it would be possible to reduce (not minimize) impact by letting the author
know that this and that will be removed (provided that it was marked as
deprecated), and with many add-ons floating around, inviting these authors
to a "conference"  where we talk about this is tedious and time consuming.
Thus my statement below: least impactful fixes first, and then more
impactful ones once we know for sure that we can safely proceed.
Another reason to consider is from communication and rhetorical perspective:
after studying rhetoric and communication for a while, I came to realize
that source code is a rhetorical text. In it, assumptions, arguments,
evidence and outcome from authors are spelled out. I believe that one way to
make NVDA community whole again is making source code consistent. Some of us
would argue that having different coding styles would lend credibility to
the argument of community contributions; but professional organizations such
as NV Access and the NVDA community in general has a set of guidelines and
principles such as coding style, and one way to unite members is let them
learn what's expect of them when it comes to writing the next hit feature,
thereby setting up the overall tone of the message we're sending: unity and
consistency.
In regards to resource allocation and community efforts: a few months ago, I
wrote on a forum or somewhere, telling folks that it is time for the
community to rise up and help make NVDA great. In this context, making NVDA
great doesn't have to be blowing trumpets and say that NVDA has one or two
cool features that'll win hearts of people; making NVDA great means source
code maintenance and other things that majority of us would say is
unimportant yet has long-term impact. This is the reason why I offered
third-party snapshots for various things, and have proposed a project to
experiment with wxPython Phoenix back in summer, in hopes that the
development community can assist NV Access by stepping up and researching
things on their behalf, experimenting with new routes and collaborating on
writing features and fixes. I believe that this code cleanup project is an
excellent opportunity for us all to think about what we, the global
community of NVDA users, developers, enthusiasts and promoters, can do to
help NVDA become even better; we do now have folks who are ready to answer
the call to step up to help out. In other words, NV Access could be
confident in that there is an international community of developers who are
ready to help and collaborate. But there is one important thing to remember:
the community itself (or members within) must have willingness to step up on
their own (not being told by someone who have become familiar with NVDA
source code for the past four years, but to truly rise up on their own to
plan, coordinate, help and collaborate, and in the end, celebrate with NV
Access, knowing that we can achieve great things and more). Personally, what
counts most in terms of resource allocation isn't just money or personnel -
it is willingness, effort and perseverance, vision, and collaboration.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: Brian's Mail list account BY [mailto:[hidden email]]
Sent: Thursday, November 24, 2016 10:58 AM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
issue6589)

The think is though, this is a lot of work for no discernable changes for
the user. OK I'm playing devils advocate here, as I fully realise that
making everything the same format should help in the future as new coders
have to get to grips with the source.
 I mean if Jamie got kidnapped by Aliens tomorrow... etc.



Is there  a tool for  mixed python/c software like nvda to trace
exactlywhich code routines are used by what other parts? One of the biggest
issues often is the old, damn I did not think anything used that any more.
 Indeed the current problem Dropbox has with their 14 version not running on
some processors seems to revolve around some floating point code that has
now been written using sse2 which said processor does not actually have!
 Brian

[hidden email]
Sent via blueyonder.
Please address personal email to:-
[hidden email], putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <[hidden email]>
To: "'NVDA screen reader development'" <[hidden email]>
Sent: Thursday, November 24, 2016 6:25 PM
Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
issue6589)


> Hi,
> At the moment I'm looking at least impactful fix, namely adding
> headers to modules with missing headers. Here, "impact" refers to code
> paths that has potential to break. We'll not work on impactful ones
> until I and others receive word from add-on authors and other devs
> that these can be looked at i.e. no regressions, no add-ons using it
> anymore and so forth. As noted by Jamie in a comment for issue 6589,
> each issue found will be a separate ticket, with separate yet related
> PR's addressing various issues, one per issue found (this also allows
> specialists to work on their area of specialty and commit needed
> fixes; in my case, I'm interested in missing headers and deprecated
> code paths, with Derek expressing interest in headers and other stuff,
> and Leonard has shown interest in helping out).
>
> The proposed workflow then is as follows:
> 1. Issues with source code will be submitted as individual issues.
> 2. There should be a way to examine overall impact of the issue,
> namely regression possibilities if a deprecated code path is removed.
> 3. One or more devs will work on issues identified and submit PR's,
> preferably each person working on a separate issue or a group of
> related ones. In case of related issues, these should be separate from
> one another in order to avoid commit conflicts.
> 4. When working on issues, devs and/or one or more users should test
> it to make sure NVDA's functionality isn't compromised.
> 5. If the commit involves removing deprecated code path, this must be
> documented.
>
> I estimate the overall project to take at least two months, with at
> least two or three devs working on it (I'm looking at NVDA 2017.2 as
> the earliest release where some of these fixes could end up in Core).
>
> Cheers,
> Josehp
>
> -----Original Message-----
> From: Sarah Alawami [mailto:[hidden email]]
> Sent: Thursday, November 24, 2016 10:01 AM
> To: NVDA screen reader development <[hidden email]>
> Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
> issue
> 6589)
>
> Which is why  I suggest doing the code clean up one thing at a time
> and test test test and don't commit the code until it's fixed and the
> admin approves the patch.
>> On Nov 24, 2016, at 3:48 AM, Brian's Mail list account BY
> <[hidden email]> wrote:
>>
>> Although I do understand why, I'd be very wary since its going to be
>> very easy to introduce obscure bugs this way, if something is altered
>> which is used elsewhere but not documented as the same writer  wrote
>> both, for example.
>>
>> Just saying.
>> Brian
>>
>> [hidden email]
>> Sent via blueyonder.
>> Please address personal email to:-
>> [hidden email], putting 'Brian Gaff'
>> in the display name field.
>> ----- Original Message -----
>> From: "Joseph Lee" <[hidden email]>
>> To: "'NVDA screen reader development'"
>> <[hidden email]>
>> Cc: <[hidden email]>
>> Sent: Thursday, November 24, 2016 7:36 AM
>> Subject: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue
>> 6589)
>>
>>
>>> Hi all, especially fellow Core committers,
>>>
>>>
>>>
>>> As 2016 is winding to a close, I thought it would be a good time to
>>> plan ahead for 2017, especially when it comes to source code
>>> maintenance.
>>> Specifically, I believe that this is a good time for us to sweep the
>>> source code clean (remove deprecated code paths, making variable
>>> names consistent and others).
>>>
>>>
>>>
>>> Relevant issue can be found at:
>>>
>>> https://github.com/nvaccess/nvda/issues/6589
>>>
>>>
>>>
>>> Some issues I found:
>>>
>>>
>>>
>>> *         Blank lines that are really tabs.
>>>
>>> *         Removing truly deprecated code paths (e.g. config.save).
>>>
>>> *         Making variable names consistent.
>>>
>>> *         Undocumented functions that are crucial for add-ons.
>>>
>>> *         Missing copyright headers.
>>>
>>> *         Other things here and there.
>>>
>>>
>>>
>>> As this is a huge undertaking, I need help from the coding community
>>> as to areas we should look at, specializations and combining our
>>> investigations and work into a pull request. Please let me know if
>>> you are interested in helping out with sweeping the NVDA source code.
> Thanks.
>>>
>>> Cheers,
>>>
>>> Joseph
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> ----------
>>
>>
>>> --------------------------------------------------------------------
>>> -
>>> ---------
>>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> ----------
>>
>>
>>> _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ----------------------------------------------------------------------
> ------
> --
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ----------------------------------------------------------------------
> -------- _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


----------------------------------------------------------------------------
--
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help wanted: Code cleanup sweeper(GitHub issue6589)

Brian's Mail list account BY
Well since you did not really answer my question, I can only comment on what
you say. In an ideal world I'd agree, but it has been my experience that
just as styles of writing articles vary and  so do styles of programming.
There are many intuitive programmers out there who are bad programmers in
the sense that they seldom document things in a way that others can
understand.
  and see that some people could be upset if things they have written get
altered. I'm not saying that this is right, but one has to be careful and
sensitive  if you want to keep such people on side.

Observationally, I feel for example that Mick has a kind of really describe
what and why everything is done  to the minutist detail, if that is a word,.
Jamie is more of a get it to work then add comments and tidy it up later
type of programmer, but sometimes the code lacks clarity to others. Its all
down to the way one or another person thinks things through. Its about
planning ahead or about streams of consciousness to me.
 Anyway,this is probably boring the brain cells of most of the readers, so
I'll apologise, admit I'd like to help but my brain is not as good as it
used to be and hide behind my sofa.
 Brian

[hidden email]
Sent via blueyonder.
Please address personal email to:-
[hidden email], putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <[hidden email]>
To: "'NVDA screen reader development'" <[hidden email]>
Sent: Thursday, November 24, 2016 7:44 PM
Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper(GitHub
issue6589)


> Hi,
> Actually, it does have some impact for end users. Suppose a really old
> add-on that people like found itself running on NVDA 2017.x with certain
> things removed that the add-on depends on. If we know who wrote it and
> when,
> it would be possible to reduce (not minimize) impact by letting the author
> know that this and that will be removed (provided that it was marked as
> deprecated), and with many add-ons floating around, inviting these authors
> to a "conference"  where we talk about this is tedious and time consuming.
> Thus my statement below: least impactful fixes first, and then more
> impactful ones once we know for sure that we can safely proceed.
> Another reason to consider is from communication and rhetorical
> perspective:
> after studying rhetoric and communication for a while, I came to realize
> that source code is a rhetorical text. In it, assumptions, arguments,
> evidence and outcome from authors are spelled out. I believe that one way
> to
> make NVDA community whole again is making source code consistent. Some of
> us
> would argue that having different coding styles would lend credibility to
> the argument of community contributions; but professional organizations
> such
> as NV Access and the NVDA community in general has a set of guidelines and
> principles such as coding style, and one way to unite members is let them
> learn what's expect of them when it comes to writing the next hit feature,
> thereby setting up the overall tone of the message we're sending: unity
> and
> consistency.
> In regards to resource allocation and community efforts: a few months ago,
> I
> wrote on a forum or somewhere, telling folks that it is time for the
> community to rise up and help make NVDA great. In this context, making
> NVDA
> great doesn't have to be blowing trumpets and say that NVDA has one or two
> cool features that'll win hearts of people; making NVDA great means source
> code maintenance and other things that majority of us would say is
> unimportant yet has long-term impact. This is the reason why I offered
> third-party snapshots for various things, and have proposed a project to
> experiment with wxPython Phoenix back in summer, in hopes that the
> development community can assist NV Access by stepping up and researching
> things on their behalf, experimenting with new routes and collaborating on
> writing features and fixes. I believe that this code cleanup project is an
> excellent opportunity for us all to think about what we, the global
> community of NVDA users, developers, enthusiasts and promoters, can do to
> help NVDA become even better; we do now have folks who are ready to answer
> the call to step up to help out. In other words, NV Access could be
> confident in that there is an international community of developers who
> are
> ready to help and collaborate. But there is one important thing to
> remember:
> the community itself (or members within) must have willingness to step up
> on
> their own (not being told by someone who have become familiar with NVDA
> source code for the past four years, but to truly rise up on their own to
> plan, coordinate, help and collaborate, and in the end, celebrate with NV
> Access, knowing that we can achieve great things and more). Personally,
> what
> counts most in terms of resource allocation isn't just money or
> personnel -
> it is willingness, effort and perseverance, vision, and collaboration.
> Hope this helps.
> Cheers,
> Joseph
>
> -----Original Message-----
> From: Brian's Mail list account BY [mailto:[hidden email]]
> Sent: Thursday, November 24, 2016 10:58 AM
> To: NVDA screen reader development <[hidden email]>
> Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
> issue6589)
>
> The think is though, this is a lot of work for no discernable changes for
> the user. OK I'm playing devils advocate here, as I fully realise that
> making everything the same format should help in the future as new coders
> have to get to grips with the source.
> I mean if Jamie got kidnapped by Aliens tomorrow... etc.
>
>
>
> Is there  a tool for  mixed python/c software like nvda to trace
> exactlywhich code routines are used by what other parts? One of the
> biggest
> issues often is the old, damn I did not think anything used that any more.
> Indeed the current problem Dropbox has with their 14 version not running
> on
> some processors seems to revolve around some floating point code that has
> now been written using sse2 which said processor does not actually have!
> Brian
>
> [hidden email]
> Sent via blueyonder.
> Please address personal email to:-
> [hidden email], putting 'Brian Gaff'
> in the display name field.
> ----- Original Message -----
> From: "Joseph Lee" <[hidden email]>
> To: "'NVDA screen reader development'" <[hidden email]>
> Sent: Thursday, November 24, 2016 6:25 PM
> Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
> issue6589)
>
>
>> Hi,
>> At the moment I'm looking at least impactful fix, namely adding
>> headers to modules with missing headers. Here, "impact" refers to code
>> paths that has potential to break. We'll not work on impactful ones
>> until I and others receive word from add-on authors and other devs
>> that these can be looked at i.e. no regressions, no add-ons using it
>> anymore and so forth. As noted by Jamie in a comment for issue 6589,
>> each issue found will be a separate ticket, with separate yet related
>> PR's addressing various issues, one per issue found (this also allows
>> specialists to work on their area of specialty and commit needed
>> fixes; in my case, I'm interested in missing headers and deprecated
>> code paths, with Derek expressing interest in headers and other stuff,
>> and Leonard has shown interest in helping out).
>>
>> The proposed workflow then is as follows:
>> 1. Issues with source code will be submitted as individual issues.
>> 2. There should be a way to examine overall impact of the issue,
>> namely regression possibilities if a deprecated code path is removed.
>> 3. One or more devs will work on issues identified and submit PR's,
>> preferably each person working on a separate issue or a group of
>> related ones. In case of related issues, these should be separate from
>> one another in order to avoid commit conflicts.
>> 4. When working on issues, devs and/or one or more users should test
>> it to make sure NVDA's functionality isn't compromised.
>> 5. If the commit involves removing deprecated code path, this must be
>> documented.
>>
>> I estimate the overall project to take at least two months, with at
>> least two or three devs working on it (I'm looking at NVDA 2017.2 as
>> the earliest release where some of these fixes could end up in Core).
>>
>> Cheers,
>> Josehp
>>
>> -----Original Message-----
>> From: Sarah Alawami [mailto:[hidden email]]
>> Sent: Thursday, November 24, 2016 10:01 AM
>> To: NVDA screen reader development <[hidden email]>
>> Subject: Re: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub
>> issue
>> 6589)
>>
>> Which is why  I suggest doing the code clean up one thing at a time
>> and test test test and don't commit the code until it's fixed and the
>> admin approves the patch.
>>> On Nov 24, 2016, at 3:48 AM, Brian's Mail list account BY
>> <[hidden email]> wrote:
>>>
>>> Although I do understand why, I'd be very wary since its going to be
>>> very easy to introduce obscure bugs this way, if something is altered
>>> which is used elsewhere but not documented as the same writer  wrote
>>> both, for example.
>>>
>>> Just saying.
>>> Brian
>>>
>>> [hidden email]
>>> Sent via blueyonder.
>>> Please address personal email to:-
>>> [hidden email], putting 'Brian Gaff'
>>> in the display name field.
>>> ----- Original Message -----
>>> From: "Joseph Lee" <[hidden email]>
>>> To: "'NVDA screen reader development'"
>>> <[hidden email]>
>>> Cc: <[hidden email]>
>>> Sent: Thursday, November 24, 2016 7:36 AM
>>> Subject: [Nvda-devel] Help wanted: Code cleanup sweeper (GitHub issue
>>> 6589)
>>>
>>>
>>>> Hi all, especially fellow Core committers,
>>>>
>>>>
>>>>
>>>> As 2016 is winding to a close, I thought it would be a good time to
>>>> plan ahead for 2017, especially when it comes to source code
>>>> maintenance.
>>>> Specifically, I believe that this is a good time for us to sweep the
>>>> source code clean (remove deprecated code paths, making variable
>>>> names consistent and others).
>>>>
>>>>
>>>>
>>>> Relevant issue can be found at:
>>>>
>>>> https://github.com/nvaccess/nvda/issues/6589
>>>>
>>>>
>>>>
>>>> Some issues I found:
>>>>
>>>>
>>>>
>>>> *         Blank lines that are really tabs.
>>>>
>>>> *         Removing truly deprecated code paths (e.g. config.save).
>>>>
>>>> *         Making variable names consistent.
>>>>
>>>> *         Undocumented functions that are crucial for add-ons.
>>>>
>>>> *         Missing copyright headers.
>>>>
>>>> *         Other things here and there.
>>>>
>>>>
>>>>
>>>> As this is a huge undertaking, I need help from the coding community
>>>> as to areas we should look at, specializations and combining our
>>>> investigations and work into a pull request. Please let me know if
>>>> you are interested in helping out with sweeping the NVDA source code.
>> Thanks.
>>>>
>>>> Cheers,
>>>>
>>>> Joseph
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> ----------
>>>
>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> ---------
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> ----------
>>>
>>>
>>>> _______________________________________________
>>>> Nvda-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> -------- _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>
>>
>> ----------------------------------------------------------------------
>> ------
>> --
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>
>>
>> ----------------------------------------------------------------------
>> -------- _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel 


------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Loading...