On 19 February 2018 at 14:40, sharry gill <sharrygill5656@gmail.com> wrote:
Hello,
Hi Sharry,
I created a draft of GSoC Proposal: Link To Proposal.
In the proposal is have a project idea:
Title: Tool to create Automatic Module test writer in Python
Description of the idea :
1) First, there is an option of entering the name of module
2) After that, there will some options regarding which test the user wants
to write. (for eg:assertMinMax, RasterFitsUnivar etc)
3)Then there will be options for selecting flags and maps.
4)Then the user will click "create the test" then a python file will be
provided to the user which contains the test.
SAMPLE MOCKUP: Link to image
please you should improve your description, it could be useful to
create test automatically from each modules or execute test from
manuals [0]
Please ask if you have questions.
Can I know which mentor will be mentoring me?
If the description will be improved I could co-mentoring
There will be a tool, in which the user enters the name of the module, and select the flags and parameters of the modules, and select which test to be done.
after selecting these option, the user click “Create Test”, then their will be a python file generated on the desktop, by using the python file user can test the module.
And When the user will enter the module name, the window will extend and at the side it will show manual of the module.
I created a draft of GSoC Proposal: Link To Proposal.
In the proposal is have a project idea:
Title: Tool to create Automatic Module test writer in Python
Description of the idea :
First, there is an option of entering the name of module
After that, there will some options regarding which test the user wants
to write. (for eg:assertMinMax, RasterFitsUnivar etc)
3)Then there will be options for selecting flags and maps.
4)Then the user will click “create the test” then a python file will be
provided to the user which contains the test.
SAMPLE MOCKUP: Link to image
please you should improve your description, it could be useful to
create test automatically from each modules or execute test from
manuals [0]
Please ask if you have questions.
Can I know which mentor will be mentoring me?
If the description will be improved I could co-mentoring
On 27 February 2018 at 10:29, sharry gill <sharrygill5656@gmail.com> wrote:
Hello Luca,
Hi,
There will be a tool, in which the user enters the name of the module, and
select the flags and parameters of the modules, and select which test to be
done.
after selecting these option, the user click "Create Test", then their
will be a python file generated on the desktop, by using the python file
user can test the module.
And When the user will enter the module name, the window will extend and
at the side it will show manual of the module.
ok, but since there are a lot of modules in GRASS it is better if the tool
will be able to work without the user choses. It should be more automatic
possible.
There will be a tool, in which the user enters the name of the module, and select the flags and parameters of the modules, and select which test to be done.
after selecting these option, the user click “Create Test”, then their will be a python file generated on the desktop, by using the python file user can test the module.
And When the user will enter the module name, the window will extend and at the side it will show manual of the module.
ok, but since there are a lot of modules in GRASS it is better if the tool will be able to work without the user choses. It should be more automatic possible.
I see that you have indicated in the first week: to design the tool, actually you should be doing this now, as well as compiling the source code, which you put in the bonding period. Rationale: how do you/we know that you will be able to develop such tool if you haven’t neither designed it, nor compiled the source code and studied basic documentation.
After designing the tool, you should spend some time and reconsider what you have written in the timeline, which currently says absolutely nothing about the actual implementation, as you use generic sentences about writing “the code” and compiling “the code”.
Please, take a look at former years student proposals to get a hint of how to structure a meaningful proposal, how to design your project and how to split up the project in milestones for your timeline.
Thanks for suggestions!
Here is the draft proposal with improvements: Link to proposal
···
On Sat, Mar 10, 2018 at 2:09 PM, Margherita Di Leo <diregola@gmail.com> wrote:
After designing the tool, you should spend some time and reconsider what you have written in the timeline, which currently says absolutely nothing about the actual implementation, as you use generic sentences about writing “the code” and compiling “the code”.
Please, take a look at former years student proposals to get a hint of how to structure a meaningful proposal, how to design your project and how to split up the project in milestones for your timeline.
Thanks and regards,
On Sat, 10 Mar 2018 at 09:21, Margherita Di Leo <diregola@gmail.com> wrote:
Hi,
I see that you have indicated in the first week: to design the tool, actually you should be doing this now, as well as compiling the source code, which you put in the bonding period. Rationale: how do you/we know that you will be able to develop such tool if you haven’t neither designed it, nor compiled the source code and studied basic documentation.
