I have just completed filling my public application for GSoC 2017. I was hoping if someone can spend some time reading it and give feedback upon that if possible. (Constructive criticism would be very helpful)
Please, mention your university and major also there.
On Tue, Mar 21, 2017 at 11:09 AM, NVS Abhilash <[hidden email]> wrote:
I have just completed filling my public application for GSoC 2017. I was
hoping if someone can spend some time reading it and give feedback upon that
if possible. (Constructive criticism would be very helpful)
On 20/03/17 10:39 PM, NVS Abhilash wrote:
> I have just completed filling my public application for GSoC 2017. I was
> hoping if someone can spend some time reading it and give feedback upon that
> if possible. (Constructive criticism would be very helpful)
I sent some comments privately. Overall, my general suggestions are:
1. focus more on Pytave as that will have the biggest impact on Octave;
2. be specific on your timeline, especially at first: later months can
be a bit more vague, but first month should be a very specific;
3. I think anything involving classdef will need some core Octave
On 24/03/17 05:12 AM, NVS Abhilash wrote:
> Thank you for your valuable suggestions. I have tried to incorporate the
> same in the application. Please do have a look.
> http://wiki.octave.org/User:Nvs-abhilash >
> I would be very thankful if you can give further feedback. :)
Thanks NVS, that is much improved by the additional details.
In addition to the various patches you've been doing, a helpful next
step would be to address this comment, by tracking down the relevant
On Mar 27, 2017 1:39 PM, "NVS Abhilash" <[hidden email]> wrote:
> Thank you again for your valuable feedback.
> I have tried to add some bug numbers to the application. Please verify are
> they the correct ones which are needed to be resolved first.
> I was not able to find exact bug report in core Octave for this: "indexing
> constants with a classdef object". Can you help me with that?
I think there's no bug report for that. You can open a new bug report.
I think that PR is completely okay in itself, which means if you start from scratch you will eventually end up doing something similar and have the same blockers as this PR. It would be better if we resolve the 3 issues in core which are blocking this PR from getting merged. That would save duplicate effort too.
> Because then it means I have to work on the existing implementation of @sym
> and when that PR gets ready to be merged will there be more conflicts not
> only merge conflicts but implementation wise?
> I think it will depend on how much of the upstream issues are resolved in
> the GSoC. But is there some other problems that I am missing?
Please fetch the PRs code and run the tests. There might be a couple of failing tests which may be resolved. Also you might optimize the existing code.
Other than that I think you can base your work on that PR.