Contributing to Octave help function.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Contributing to Octave help function.

Sergey Dudoladov


  Hello,

  I've been using Octave for quite a while, and now I would like to contribute some code to the project. 
  I want to start with an easy mini-contribution, just to understand how things work. 

  My first suggestion is to improve 'help' function by adding a 'dot' option to it.
  MIT OCW Course on Matlab  mentions that in Matlab command ' help . ' , that is help + dot, lists a detailed list of operators (logical, relational etc.)
  See the 11th slide of the lecture titled  "Visualization and programming".
  
  I use Octave version 3.6.1 , and it responds to this command with an error message. So, I want to add this functionality.

  Any feedback  is welcome. In particular, I have two questions
  1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
  2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
      I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.
 
  

   
  
Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

bpabbott
Administrator
On Jul 19, 2012, at 9:02 AM, Sergey Dudoladov wrote:

>   Hello,
>
>   I've been using Octave for quite a while, and now I would like to contribute some code to the project.
>   I want to start with an easy mini-contribution, just to understand how things work.
>
>   My first suggestion is to improve 'help' function by adding a 'dot' option to it.
>   MIT OCW Course on Matlab  mentions that in Matlab command ' help . ' , that is help + dot, lists a detailed list of operators (logical, relational etc.)
>   See the 11th slide of the lecture titled  "Visualization and programming".
>  
>   I use Octave version 3.6.1 , and it responds to this command with an error message. So, I want to add this functionality.
>
>   Any feedback  is welcome. In particular, I have two questions
>   1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
>   2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
>       I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.

You can start with the info below.

        http://www.gnu.org/software/octave/doc/interpreter/Contributing-Guidelines.html#Contributing-Guidelines

The help() function is an m-file, so it should be possible to make this change using m-files only.

Ben

Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Michael Godfrey
In reply to this post by Sergey Dudoladov
On 07/19/2012 09:02 AM, Sergey Dudoladov wrote:
  Any feedback  is welcome. In particular, I have two questions
  1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
help is an m file, so that is a place to start.  In Octave type which help.
  2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
Here is a start:
To report a new bug go to
http://savannah.gnu.org/bugs/?func=additem&group=octave

If you have a patch to fix it, you should create a changeset. See
http://www.gnu.org/software/octave/doc/interpreter/Basics-of-Generating-a-Changeset.html#Basics-of-Generating-a-Changeset


It is a good idea to enter this as a bug.  This way it will get attention.  Most (but not all) incompatibilities
with Matlab can be considered as bugs.

      I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.
Octave is under quite active development.  You will get the idea soon.  Look around the Octave web page
and wiki.

Thanks for your interest.
 mdg


Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Sergey Dudoladov


On Thu, Jul 19, 2012 at 5:20 PM, Michael D Godfrey <[hidden email]> wrote:
On 07/19/2012 09:02 AM, Sergey Dudoladov wrote:
  Any feedback  is welcome. In particular, I have two questions
  1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
help is an m file, so that is a place to start.  In Octave type which help.

  2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
Here is a start:
To report a new bug go to
http://savannah.gnu.org/bugs/?func=additem&group=octave

If you have a patch to fix it, you should create a changeset. See
http://www.gnu.org/software/octave/doc/interpreter/Basics-of-Generating-a-Changeset.html#Basics-of-Generating-a-Changeset


It is a good idea to enter this as a bug.  This way it will get attention.  Most (but not all) incompatibilities
with Matlab can be considered as bugs.

      I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.
Octave is under quite active development.  You will get the idea soon.  Look around the Octave web page
and wiki.

Thanks for your interest.
 mdg



 I've just had a look at help.m file.   It can list all operators, functions and keywords with the command "help --list"
 However, the output of this command is rather big.

 I suggest I add four more options, namely --operators , --keywords, --builtins and --functions, abbreviated as -o,  -k ,  -b and -f  respectively. For instance, invoking   "help -k" or "help --keywords" will show keywords in the format similar to "help --list"       I  will also give "help --list"  its own shortcut "help -l" 

Any comments before I start coding ?

  

Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Michael Godfrey
On 07/21/2012 03:19 AM, Sergey Dudoladov wrote:
Any comments before I start coding ?

Remember the Matlab compatible option, and file a bug report.
And, get to work!

mdg

Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

bpabbott
Administrator
In reply to this post by Sergey Dudoladov

On Jul 21, 2012, at 3:19 AM, Sergey Dudoladov wrote:

>
>
> On Thu, Jul 19, 2012 at 5:20 PM, Michael D Godfrey <[hidden email]> wrote:
> On 07/19/2012 09:02 AM, Sergey Dudoladov wrote:
>>   Any feedback  is welcome. In particular, I have two questions
>>   1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
> help is an m file, so that is a place to start.  In Octave type which help.
>
>>   2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
> Here is a start:
> To report a new bug go to
>
> http://savannah.gnu.org/bugs/?func=additem&group=octave
>
>
> If you have a patch to fix it, you should create a changeset. See
>
> http://www.gnu.org/software/octave/doc/interpreter/Basics-of-Generating-a-Changeset.html#Basics-of-Generating-a-Changeset
>
>
>
> It is a good idea to enter this as a bug.  This way it will get attention.  Most (but not all) incompatibilities
> with Matlab can be considered as bugs.
>
>
>>       I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.
> Octave is under quite active development.  You will get the idea soon.  Look around the Octave web page
> and wiki.
>
> Thanks for your interest.
>  mdg
>
>
>
>  I've just had a look at help.m file.   It can list all operators, functions and keywords with the command "help --list"
>  However, the output of this command is rather big.
>
>  I suggest I add four more options, namely --operators , --keywords, --builtins and --functions, abbreviated as -o,  -k ,  -b and -f  respectively. For instance, invoking   "help -k" or "help --keywords" will show keywords in the format similar to "help --list"       I  will also give "help --list"  its own shortcut "help -l"
>
> Any comments before I start coding ?

For abbreviations, please allow any incomplete but unique  options. For example, "-o", "-op", "-operat", etc.   There is more than one way to do that, but I tend to favor the using the function strncmpi().

Ben

Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Sergey Dudoladov


On Sat, Jul 21, 2012 at 6:43 PM, Ben Abbott <[hidden email]> wrote:

On Jul 21, 2012, at 3:19 AM, Sergey Dudoladov wrote:

>
>
> On Thu, Jul 19, 2012 at 5:20 PM, Michael D Godfrey <[hidden email]> wrote:
> On 07/19/2012 09:02 AM, Sergey Dudoladov wrote:
>>   Any feedback  is welcome. In particular, I have two questions
>>   1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
> help is an m file, so that is a place to start.  In Octave type which help.
>
>>   2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
> Here is a start:
> To report a new bug go to
>
> http://savannah.gnu.org/bugs/?func=additem&group=octave
>
>
> If you have a patch to fix it, you should create a changeset. See
>
> http://www.gnu.org/software/octave/doc/interpreter/Basics-of-Generating-a-Changeset.html#Basics-of-Generating-a-Changeset
>
>
>
> It is a good idea to enter this as a bug.  This way it will get attention.  Most (but not all) incompatibilities
> with Matlab can be considered as bugs.
>
>
>>       I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.
> Octave is under quite active development.  You will get the idea soon.  Look around the Octave web page
> and wiki.
>
> Thanks for your interest.
>  mdg
>
>
>
>  I've just had a look at help.m file.   It can list all operators, functions and keywords with the command "help --list"
>  However, the output of this command is rather big.
>
>  I suggest I add four more options, namely --operators , --keywords, --builtins and --functions, abbreviated as -o,  -k ,  -b and -f  respectively. For instance, invoking   "help -k" or "help --keywords" will show keywords in the format similar to "help --list"       I  will also give "help --list"  its own shortcut "help -l"
>
> Any comments before I start coding ?

For abbreviations, please allow any incomplete but unique  options. For example, "-o", "-op", "-operat", etc.   There is more than one way to do that, but I tend to favor the using the function strncmpi().

Ben

 Ok, I've done several things so far:

 1) Change my local help.m file. It now handles 'help .'  correctly;
 2) Tested it in my version of Octave 3.6.1.
      It seems to be OK, because 'help .' lists all operators, and function "help" still passes 'test help'.
 3) Created a relevant bug report #36920;
 4) Created a cset and exported it to a file;

Two questions:
  1) Is it OK to submit the patch if "hg import" rejects it ? Or should I try to eliminate any conflicts?
  2) Should I attach the patch to the bug report or submit it separately through a patch tracker ?

 
Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

bpabbott
Administrator
On Jul 23, 2012, at 5:09 AM, Sergey Dudoladov wrote:

> On Sat, Jul 21, 2012 at 6:43 PM, Ben Abbott <[hidden email]> wrote:
>
> On Jul 21, 2012, at 3:19 AM, Sergey Dudoladov wrote:
>
> >
> > On Thu, Jul 19, 2012 at 5:20 PM, Michael D Godfrey <[hidden email]> wrote:
> > On 07/19/2012 09:02 AM, Sergey Dudoladov wrote:
> >>   Any feedback  is welcome. In particular, I have two questions
> >>   1) Is it possible to do it using m-scripts only?  I currently don't know C or C++.
> > help is an m file, so that is a place to start.  In Octave type which help.
> >
> >>   2) Is there any detailed description of a code contribution workflow ( besides contributors guide ) I can follow ?
> > Here is a start:
> > To report a new bug go to
> >
> > http://savannah.gnu.org/bugs/?func=additem&group=octave
> >
> >
> > If you have a patch to fix it, you should create a changeset. See
> >
> > http://www.gnu.org/software/octave/doc/interpreter/Basics-of-Generating-a-Changeset.html#Basics-of-Generating-a-Changeset
> >
> >
> >
> > It is a good idea to enter this as a bug.  This way it will get attention.  Most (but not all) incompatibilities
> > with Matlab can be considered as bugs.
> >
> >
> >>       I interested in things like "When and how often to build sources ?", "What things should be changed in configuration files when I change a function?" etc.
> > Octave is under quite active development.  You will get the idea soon.  Look around the Octave web page
> > and wiki.
> >
> > Thanks for your interest.
> >  mdg
> >
> >  I've just had a look at help.m file.   It can list all operators, functions and keywords with the command "help --list"
> >  However, the output of this command is rather big.
> >
> >  I suggest I add four more options, namely --operators , --keywords, --builtins and --functions, abbreviated as -o,  -k ,  -b and -f  respectively. For instance, invoking   "help -k" or "help --keywords" will show keywords in the format similar to "help --list"       I  will also give "help --list"  its own shortcut "help -l"
> >
> > Any comments before I start coding ?
>
> For abbreviations, please allow any incomplete but unique  options. For example, "-o", "-op", "-operat", etc.   There is more than one way to do that, but I tend to favor the using the function strncmpi().
>
> Ben
>
>  Ok, I've done several things so far:
>
>  1) Change my local help.m file. It now handles 'help .'  correctly;
>  2) Tested it in my version of Octave 3.6.1.
>       It seems to be OK, because 'help .' lists all operators, and function "help" still passes 'test help'.
>  3) Created a relevant bug report #36920;
>  4) Created a cset and exported it to a file;
>
> Two questions:
>   1) Is it OK to submit the patch if "hg import" rejects it ? Or should I try to eliminate any conflicts?
>   2) Should I attach the patch to the bug report or submit it separately through a patch tracker ?
The attached make_changeset.sh (I assumed you're running a Unix variant) and the accompanying ChangeLog.txt.  This script is intended to create a hg changeset using your new help.m and a local mercurial archive.  Note: you'll need to change the $ARCHIVE variable in the script to point to your local hg archive.

You may attach the patch to either the bug tracker or the patch tracker.  If the latter, please provide a link in the bug tracker.

Ben


make_changeset.m (519 bytes) Download Attachment
ChangeLog.txt (152 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Jordi Gutiérrez Hermoso-2
In reply to this post by Sergey Dudoladov
On 23 July 2012 05:09, Sergey Dudoladov <[hidden email]> wrote:
>   1) Is it OK to submit the patch if "hg import" rejects it ? Or
> should I try to eliminate any conflicts?

The whole point of "hg export" is that this gives the patch metadata
that says *where* the patch is applied (i.e. at which hg revision).
Unless this is a private commit that is not in the Savannah
repository, it is then impossible for your patch to not apply (well,
impossible unless you found a way to exploit a hash collision in
sha1).

>   2) Should I attach the patch to the bug report or submit it
> separately through a patch tracker ?

Attached to the bug report is fine. I'll look at it now.

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Fwd: Contributing to Octave help function.

Sergey Dudoladov


On Mon, Jul 23, 2012 at 5:28 PM, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
On 23 July 2012 05:09, Sergey Dudoladov <[hidden email]> wrote:
>   1) Is it OK to submit the patch if "hg import" rejects it ? Or
> should I try to eliminate any conflicts?

The whole point of "hg export" is that this gives the patch metadata
that says *where* the patch is applied (i.e. at which hg revision).
Unless this is a private commit that is not in the Savannah
repository, it is then impossible for your patch to not apply (well,
impossible unless you found a way to exploit a hash collision in
sha1).

>   2) Should I attach the patch to the bug report or submit it
> separately through a patch tracker ?

Attached to the bug report is fine. I'll look at it now.

- Jordi G. H.


1) I've just added a potential patch to the bug report . Bug #36920  ;  file #26264
    
2) I didn't get the point about 'hg export' .  Basically,  I don't understand the sentence beginning "Unless this is a private .... "
    Please give me a clue where to find more information about it.

    Probably I should go into more detail about my problem with rejections.
    a) I have a few clones of  an Octave repo on my machine and I use one of them specifically to play with function "help"
    b) I added a few lines of code to help.m and commited it to one of my local repos.
    c) After that  just to make sure it really works I run modified help.m in local Octave installation
    d) It worked, so I exported my tip revision into a file called  help_mod.diff (this extension was used in contributor's guide)
    e) As a last check, I applied this patch with "hg -import" to another local repo. The patch got rejected.
       However, the sequence "hg pull + hg update" worked fine


    At this point, I skimmed through HG manual and though the patch rejection must be resolved manually.
    My initial question was "Is it appropriate to submit a patch that someone else will have to apply manually" ?

   
   
    

Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Jordi Gutiérrez Hermoso-2
On 26 July 2012 15:03, Sergey Dudoladov <[hidden email]> wrote:

>
>
> On Mon, Jul 23, 2012 at 5:28 PM, Jordi Gutiérrez Hermoso
> <[hidden email]> wrote:
>>
>> On 23 July 2012 05:09, Sergey Dudoladov <[hidden email]>
>> wrote:
>> >   1) Is it OK to submit the patch if "hg import" rejects it ? Or
>> > should I try to eliminate any conflicts?
>>
>> The whole point of "hg export" is that this gives the patch metadata
>> that says *where* the patch is applied (i.e. at which hg revision).
>> Unless this is a private commit that is not in the Savannah
>> repository, it is then impossible for your patch to not apply (well,
>> impossible unless you found a way to exploit a hash collision in
>> sha1).
>>
>> >   2) Should I attach the patch to the bug report or submit it
>> > separately through a patch tracker ?
>>
>> Attached to the bug report is fine. I'll look at it now.
>
> 1) I've just added a potential patch to the bug report . Bug #36920  ;  file
> #26264

Yes, thanks, I just rebased it and applied it:

    http://hg.savannah.gnu.org/hgweb/octave/graph/ae42d5a67ed9

> 2) I didn't get the point about 'hg export' . Basically, I don't
> understand the sentence beginning "Unless this is a private .... "
> Please give me a clue where to find more information about it.

This is a good explanation of hg:

    http://hginit.com/

You can have patches in your local machine privately. You can make as
many commits as you want, and you don't have to show them to anyone.
When you do "hg export", hg records the parent of the commit you're
exporting. So when I apply your patch, hg knows which commit to apply
it to (i.e. which node in this graph):

    http://hg.savannah.gnu.org/hgweb/octave/graph/

Now, if you base your patch on a node that is not in the Savannah repo
above (i.e. a "private commit"), I will be unable to apply your patch
exactly where you based it, since I won't have this base. The base
will be in your local repo.

If you just do "diff" without export, then I don't know relative to
which hg revision to apply your patch. This is frequently not a
problem, but it's nice to know exactly *where* to apply your patch,
and "hg export" has this information.

>     e) As a last check, I applied this patch with "hg -import" to
>        another local repo. The patch got rejected.

Yes, this is what I just explained above. "hg import" may fail if you
don't use the information about *where* to apply the patch. Try

    hg import --exact

to apply the patch at the node (commit, changeset; all synonyms) that
is recorded in the patch.

If you prefer to avoid patches, you can also just host your repository
in a public server (e.g. bitbucket) and tell me which commit to pull.

I hope this wasn't confusing. Please ask again if it was.

HTH,
- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Sergey Dudoladov


On Thu, Jul 26, 2012 at 11:31 PM, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
On 26 July 2012 15:03, Sergey Dudoladov <[hidden email]> wrote:
>
>
> On Mon, Jul 23, 2012 at 5:28 PM, Jordi Gutiérrez Hermoso
> <[hidden email]> wrote:
>>
>> On 23 July 2012 05:09, Sergey Dudoladov <[hidden email]>
>> wrote:
>> >   1) Is it OK to submit the patch if "hg import" rejects it ? Or
>> > should I try to eliminate any conflicts?
>>
>> The whole point of "hg export" is that this gives the patch metadata
>> that says *where* the patch is applied (i.e. at which hg revision).
>> Unless this is a private commit that is not in the Savannah
>> repository, it is then impossible for your patch to not apply (well,
>> impossible unless you found a way to exploit a hash collision in
>> sha1).
>>
>> >   2) Should I attach the patch to the bug report or submit it
>> > separately through a patch tracker ?
>>
>> Attached to the bug report is fine. I'll look at it now.
>
> 1) I've just added a potential patch to the bug report . Bug #36920  ;  file
> #26264

Yes, thanks, I just rebased it and applied it:

    http://hg.savannah.gnu.org/hgweb/octave/graph/ae42d5a67ed9

> 2) I didn't get the point about 'hg export' . Basically, I don't
> understand the sentence beginning "Unless this is a private .... "
> Please give me a clue where to find more information about it.

This is a good explanation of hg:

    http://hginit.com/

You can have patches in your local machine privately. You can make as
many commits as you want, and you don't have to show them to anyone.
When you do "hg export", hg records the parent of the commit you're
exporting. So when I apply your patch, hg knows which commit to apply
it to (i.e. which node in this graph):

    http://hg.savannah.gnu.org/hgweb/octave/graph/

Now, if you base your patch on a node that is not in the Savannah repo
above (i.e. a "private commit"), I will be unable to apply your patch
exactly where you based it, since I won't have this base. The base
will be in your local repo.

If you just do "diff" without export, then I don't know relative to
which hg revision to apply your patch. This is frequently not a
problem, but it's nice to know exactly *where* to apply your patch,
and "hg export" has this information.

>     e) As a last check, I applied this patch with "hg -import" to
>        another local repo. The patch got rejected.

Yes, this is what I just explained above. "hg import" may fail if you
don't use the information about *where* to apply the patch. Try

    hg import --exact

to apply the patch at the node (commit, changeset; all synonyms) that
is recorded in the patch.

If you prefer to avoid patches, you can also just host your repository
in a public server (e.g. bitbucket) and tell me which commit to pull.

I hope this wasn't confusing. Please ask again if it was.

HTH,
- Jordi G. H.


1) Thank you for the clear explanation, Jordi. Now I understand, or at least I hope so.

2) I am going to extend Octave "help" function a little bit by adding following options :

     Option                          Description

    --operators                 Lists operators. A synonym for "help ." 
    --keywords                 Lists keywords.
    --builtins                    Lists built-in functions
    --functions                 Lists other functions 
                                         
     Incomplete, but unique versions like "help --ope" (see discussion above) will also be supported.

   Questions:
   0) Is there any difference  in handling options "double-dash + word"  vs. "single dash + letter"?
   1) Do I have to provide a possibility to use several options simultaneously, e.g. as in  "help --keywords --operators" ? 
       I doubt someone will use it frequently, but what is Octave policy ?
   2) Which documentation should I alter ? Is a Texinfo comment in m-file enough ?  
   3) Any other comments before I start?
Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Sergey Dudoladov


On Sun, Jul 29, 2012 at 1:00 AM, Sergey Dudoladov <[hidden email]> wrote:


On Thu, Jul 26, 2012 at 11:31 PM, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
On 26 July 2012 15:03, Sergey Dudoladov <[hidden email]> wrote:
>
>
> On Mon, Jul 23, 2012 at 5:28 PM, Jordi Gutiérrez Hermoso
> <[hidden email]> wrote:
>>
>> On 23 July 2012 05:09, Sergey Dudoladov <[hidden email]>
>> wrote:
>> >   1) Is it OK to submit the patch if "hg import" rejects it ? Or
>> > should I try to eliminate any conflicts?
>>
>> The whole point of "hg export" is that this gives the patch metadata
>> that says *where* the patch is applied (i.e. at which hg revision).
>> Unless this is a private commit that is not in the Savannah
>> repository, it is then impossible for your patch to not apply (well,
>> impossible unless you found a way to exploit a hash collision in
>> sha1).
>>
>> >   2) Should I attach the patch to the bug report or submit it
>> > separately through a patch tracker ?
>>
>> Attached to the bug report is fine. I'll look at it now.
>
> 1) I've just added a potential patch to the bug report . Bug #36920  ;  file
> #26264

Yes, thanks, I just rebased it and applied it:

    http://hg.savannah.gnu.org/hgweb/octave/graph/ae42d5a67ed9

> 2) I didn't get the point about 'hg export' . Basically, I don't
> understand the sentence beginning "Unless this is a private .... "
> Please give me a clue where to find more information about it.

This is a good explanation of hg:

    http://hginit.com/

You can have patches in your local machine privately. You can make as
many commits as you want, and you don't have to show them to anyone.
When you do "hg export", hg records the parent of the commit you're
exporting. So when I apply your patch, hg knows which commit to apply
it to (i.e. which node in this graph):

    http://hg.savannah.gnu.org/hgweb/octave/graph/

Now, if you base your patch on a node that is not in the Savannah repo
above (i.e. a "private commit"), I will be unable to apply your patch
exactly where you based it, since I won't have this base. The base
will be in your local repo.

If you just do "diff" without export, then I don't know relative to
which hg revision to apply your patch. This is frequently not a
problem, but it's nice to know exactly *where* to apply your patch,
and "hg export" has this information.

>     e) As a last check, I applied this patch with "hg -import" to
>        another local repo. The patch got rejected.

Yes, this is what I just explained above. "hg import" may fail if you
don't use the information about *where* to apply the patch. Try

    hg import --exact

to apply the patch at the node (commit, changeset; all synonyms) that
is recorded in the patch.

If you prefer to avoid patches, you can also just host your repository
in a public server (e.g. bitbucket) and tell me which commit to pull.

I hope this wasn't confusing. Please ask again if it was.

HTH,
- Jordi G. H.


1) Thank you for the clear explanation, Jordi. Now I understand, or at least I hope so.

2) I am going to extend Octave "help" function a little bit by adding following options :

     Option                          Description

    --operators                 Lists operators. A synonym for "help ." 
    --keywords                 Lists keywords.
    --builtins                    Lists built-in functions
    --functions                 Lists other functions 
                                         
     Incomplete, but unique versions like "help --ope" (see discussion above) will also be supported.

   Questions:
   0) Is there any difference  in handling options "double-dash + word"  vs. "single dash + letter"?
   1) Do I have to provide a possibility to use several options simultaneously, e.g. as in  "help --keywords --operators" ? 
       I doubt someone will use it frequently, but what is Octave policy ?
   2) Which documentation should I alter ? Is a Texinfo comment in m-file enough ?  
   3) Any other comments before I start?



 I've created a simple patch. Please, have a quick look through it. 

help_expand.diff (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributing to Octave help function.

Carnë Draug-2
On 3 August 2012 16:54, Sergey Dudoladov <[hidden email]> wrote:
>  I've created a simple patch. Please, have a quick look through it.

Hi Sergey

like the other patch you have sent before, the best is really to leave
it on a bug report. Things get lost very easily on mailing lists.
Either reopen your previous bug report if it's the same thing
https://savannah.gnu.org/bugs/?func=detailitem&item_id=36920 or submit
a new one https://savannah.gnu.org/bugs/?func=additem&group=octave

No need to say on the mailing that you have attached a new patch to
the bug report, maintainers will already receive notifications from
the bug tracker.

Carnë