[Pdl-porters] #pdl discussion re PDL development

Discussion:

Chris Marshall

2014-08-30 15:07:43 UTC

Permalink

FYI-

We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30

--Chris

Ed .

2014-08-30 16:04:14 UTC

Permalink

Dear PDL Porters,

Further to the git-rights addition process proposal I made on the IRC log
below, here is my proposal of me.

I submit that I should gain git "push" rights to the pdl-code repo. I am a
member of the Perl Toolchain Gang, and have made a number of changes to
ExtUtils::MakeMaker, some of which are (not all my work - some I got ready
for inclusion as they'd been lying around as pull requests for many months):
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/140
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/135
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/125
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/116
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/109

I am also part of the Inline team (https://github.com/ingydotnet/inline-pm),
I'm the new maintainer for dmake (https://github.com/mohawk2/dmake/), and
I'm the maintainer for Gimp-Perl (https://git.gnome.org/browse/gimp-perl/).

In line with my proposed process, I submit that any objections should be
made (in private if necessary to Chris) within 7 days, i.e. before 23:59 UTC
on 6 Sep.

Best regards,
Ed J

-----Original Message-----
From: Chris Marshall
Sent: Saturday, August 30, 2014 4:07 PM
To: pdl-porters
Subject: [Pdl-porters] #pdl discussion re PDL development

FYI-

We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30

--Chris

Chris Marshall

2014-08-31 19:19:28 UTC

Permalink

Bringing some #pdl discussion into pdl-porters. This is the
list where PDL developers discussions and support happens.

Ed-

Thanks for the git-rights proposal but I don't think we need to
change the current approach which is basically:

- Developer starts to contribute to PDL actively in a number
of ways: bug reports, fixing bugs, feature requests, implementing
features, ...

- Developer demonstrates the ability to constructively work
with PDL team and the PDL code base. Of specific importance
is that he/she recognizes and understands the different context
for PDL development: PDL is used by researchers to do real
work. As such, we've been working consistently toward the goal
of PDL building out of the box on all the main perl platforms,
maintaining backwards compatibility as much as possible, but
still evolving and improving the utility and features of PDL for
computation.

N.B. The need for stability and consistency is why the goals for
PDL3 and its significant refactoring are planned to be done in an
independent development stream while leaving PDL-2.x as the
reliable work-horse for PDL computation until the new PDL3
comes on-line.

- Developer is then generally granted git write permissions to
support their ability to contribute to PDL.

--Chris

Post by Ed .
Dear PDL Porters,
Further to the git-rights addition process proposal I made on the IRC log
below, here is my proposal of me.
I submit that I should gain git "push" rights to the pdl-code repo. I am a
member of the Perl Toolchain Gang, and have made a number of changes to
ExtUtils::MakeMaker, some of which are (not all my work - some I got ready
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/140
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/135
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/125
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/116
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/109
I am also part of the Inline team (https://github.com/ingydotnet/inline-pm),
I'm the new maintainer for dmake (https://github.com/mohawk2/dmake/), and
I'm the maintainer for Gimp-Perl (https://git.gnome.org/browse/gimp-perl/).
In line with my proposed process, I submit that any objections should be
made (in private if necessary to Chris) within 7 days, i.e. before 23:59 UTC
on 6 Sep.
Best regards,
Ed J
-----Original Message----- From: Chris Marshall
Sent: Saturday, August 30, 2014 4:07 PM
To: pdl-porters
Subject: [Pdl-porters] #pdl discussion re PDL development
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Zakariyya Mughal

2014-08-31 16:28:39 UTC

Permalink

Post by Chris Marshall
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris

Hello,

I'm sivoais from the IRC conversation.

I'm new to the PDL codebase and before I start making further
contributions, I would like to improve the tests.

I plan to tackle the conversion of all the tests to Test::More (as
outlined in TODO). That's about 60 files. Changing so many files at once
will maybe make merging a bit difficult as I will be making the code
considerably shorter.

How should I approach this? Should I make a commit for every file
changed? There are some patterns to the usage that can be fixed across
multiple files in one go (e.g., moving `tapprox` to a shared .pm file in
t/).

I don't think I need git access as I will be working on a forked branch
(pushing to both Sourceforge and Github).

Regards,
- Zaki Mughal

Post by Chris Marshall
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Chris Marshall

2014-08-31 16:59:44 UTC

Permalink

Thanks for the introduction and *thanks* for
taking this on!

I would just commit as they're done (simpler to
keep track). For wholesale verification, we can
push a special CPAN developers release with
side-by-side old and new tests to verify the results
are the same.

--Chris

On Sun, Aug 31, 2014 at 12:28 PM, Zakariyya Mughal

Post by Zakariyya Mughal

Post by Chris Marshall
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris

Hello,
I'm sivoais from the IRC conversation.
I'm new to the PDL codebase and before I start making further
contributions, I would like to improve the tests.
I plan to tackle the conversion of all the tests to Test::More (as
outlined in TODO). That's about 60 files. Changing so many files at once
will maybe make merging a bit difficult as I will be making the code
considerably shorter.
How should I approach this? Should I make a commit for every file
changed? There are some patterns to the usage that can be fixed across
multiple files in one go (e.g., moving `tapprox` to a shared .pm file in
t/).
I don't think I need git access as I will be working on a forked branch
(pushing to both Sourceforge and Github).
Regards,
- Zaki Mughal

Post by Chris Marshall
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Ed .

2014-08-31 17:08:07 UTC

Permalink

Surely you know all the results for the current tests already? Wouldn't it
make sense to put out a dev release with identical code but with the new
tests? That would also stop any accidental cross-dependency on old test
code/data.

-----Original Message-----
From: Chris Marshall
Sent: Sunday, August 31, 2014 5:59 PM
To: Zakariyya Mughal
Cc: pdl-porters
Subject: Re: [Pdl-porters] #pdl discussion re PDL development

Thanks for the introduction and *thanks* for
taking this on!

I would just commit as they're done (simpler to
keep track). For wholesale verification, we can
push a special CPAN developers release with
side-by-side old and new tests to verify the results
are the same.

--Chris

On Sun, Aug 31, 2014 at 12:28 PM, Zakariyya Mughal

Post by Zakariyya Mughal

Post by Chris Marshall
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris

Hello,
I'm sivoais from the IRC conversation.
I'm new to the PDL codebase and before I start making further
contributions, I would like to improve the tests.
I plan to tackle the conversion of all the tests to Test::More (as
outlined in TODO). That's about 60 files. Changing so many files at once
will maybe make merging a bit difficult as I will be making the code
considerably shorter.
How should I approach this? Should I make a commit for every file
changed? There are some patterns to the usage that can be fixed across
multiple files in one go (e.g., moving `tapprox` to a shared .pm file in
t/).
I don't think I need git access as I will be working on a forked branch
(pushing to both Sourceforge and Github).
Regards,
- Zaki Mughal

Post by Chris Marshall
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Chris Marshall

2014-08-31 18:38:01 UTC

Permalink

The idea is to verify the tests on all the PDL platforms
via CPAN testers and the only way to ensure that the
same tests are run in the same environment is to run
the two test suites (before and after) together.

--Chris

Post by Ed .
Surely you know all the results for the current tests already? Wouldn't it
make sense to put out a dev release with identical code but with the new
tests? That would also stop any accidental cross-dependency on old test
code/data.
-----Original Message----- From: Chris Marshall
Sent: Sunday, August 31, 2014 5:59 PM
To: Zakariyya Mughal
Cc: pdl-porters
Subject: Re: [Pdl-porters] #pdl discussion re PDL development
Thanks for the introduction and *thanks* for
taking this on!
I would just commit as they're done (simpler to
keep track). For wholesale verification, we can
push a special CPAN developers release with
side-by-side old and new tests to verify the results
are the same.
--Chris
On Sun, Aug 31, 2014 at 12:28 PM, Zakariyya Mughal

Post by Zakariyya Mughal

Post by Chris Marshall
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris

Hello,
I'm sivoais from the IRC conversation.
I'm new to the PDL codebase and before I start making further
contributions, I would like to improve the tests.
I plan to tackle the conversion of all the tests to Test::More (as
outlined in TODO). That's about 60 files. Changing so many files at once
will maybe make merging a bit difficult as I will be making the code
considerably shorter.
How should I approach this? Should I make a commit for every file
changed? There are some patterns to the usage that can be fixed across
multiple files in one go (e.g., moving `tapprox` to a shared .pm file in
t/).
I don't think I need git access as I will be working on a forked branch
(pushing to both Sourceforge and Github).
Regards,
- Zaki Mughal

Post by Chris Marshall
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

Zakariyya Mughal

2014-09-01 23:00:43 UTC

Permalink

Post by Chris Marshall
Thanks for the introduction and *thanks* for
taking this on!
I would just commit as they're done (simpler to
keep track). For wholesale verification, we can
push a special CPAN developers release with
side-by-side old and new tests to verify the results
are the same.

An update on where I am with this: I have consolidated all the custom
ok() subroutines to a single .pm file. I will do the same with the
variants of tapprox() (285 calls). Consolidation standardises the
changes for refactoring later.

Commits on GitHub and SF:

<https://github.com/zmughal/pdl/compare/zmughal:master...test-cleanup>

<https://sourceforge.net/u/zsmughal/pdl/ci/test-cleanup/log/>

Regards,
- Zaki Mughal

Post by Chris Marshall
--Chris
On Sun, Aug 31, 2014 at 12:28 PM, Zakariyya Mughal

Post by Zakariyya Mughal

Post by Chris Marshall
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris

Hello,
I'm sivoais from the IRC conversation.
I'm new to the PDL codebase and before I start making further
contributions, I would like to improve the tests.
I plan to tackle the conversion of all the tests to Test::More (as
outlined in TODO). That's about 60 files. Changing so many files at once
will maybe make merging a bit difficult as I will be making the code
considerably shorter.
How should I approach this? Should I make a commit for every file
changed? There are some patterns to the usage that can be fixed across
multiple files in one go (e.g., moving `tapprox` to a shared .pm file in
t/).
I don't think I need git access as I will be working on a forked branch
(pushing to both Sourceforge and Github).
Regards,
- Zaki Mughal

Post by Chris Marshall
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

David Mertens

2014-09-02 11:19:09 UTC

Permalink

By the way, PDL::Core has the approx function. I remember being annoyed,
and somewhat astounded, that some (all?) of the implementations of tapprox
did not use this function:

http://pdl.perl.org/?docs=Core&title=PDL::Core#approx

David

Post by Zakariyya Mughal

An update on where I am with this: I have consolidated all the custom
ok() subroutines to a single .pm file. I will do the same with the
variants of tapprox() (285 calls). Consolidation standardises the
changes for refactoring later.
<https://github.com/zmughal/pdl/compare/zmughal:master...test-cleanup>
<https://sourceforge.net/u/zsmughal/pdl/ci/test-cleanup/log/>
Regards,
- Zaki Mughal

Post by Chris Marshall
--Chris
On Sun, Aug 31, 2014 at 12:28 PM, Zakariyya Mughal

Post by Zakariyya Mughal

Post by Chris Marshall
FYI-
We have some new developers interested in PDL
development, http://irclog.perlgeek.de/pdl/2014-08-30
--Chris

once

Post by Chris Marshall

Post by Zakariyya Mughal
will maybe make merging a bit difficult as I will be making the code
considerably shorter.
How should I approach this? Should I make a commit for every file
changed? There are some patterns to the usage that can be fixed across
multiple files in one go (e.g., moving `tapprox` to a shared .pm file

Post by Chris Marshall

Post by Zakariyya Mughal
t/).
I don't think I need git access as I will be working on a forked branch
(pushing to both Sourceforge and Github).
Regards,
- Zaki Mughal

Post by Chris Marshall
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan