bugGNU Octave - Bugs: bug #37650, the `inputParser' function is not...


bug #37650: the `inputParser' function is not yet implemented

Submitted by:  None
Submitted on:  Mon 29 Oct 2012 06:56:49 PM UTC  
Category:  Libraries Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  3.6.3
Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 14 Mar 2017 05:54:17 AM UTC, comment #24: 
Felipe G. Nievinski <fgnievinski>
Thu 12 Nov 2015 06:13:48 PM UTC, comment #23: 

For anyone coming here, because the gui-release branch was merged with default, the inputParser class was actually released with Octave 4.0.0.

Carnë Draug <carandraug>
Project Member
Thu 06 Nov 2014 11:55:39 AM UTC, comment #22: 

A matlab compatible version of inputParser has been added to Octave core with cset ff820f92cbb5 now that classdef is mature enough to support it.  It is planned to be part of the 4.2 release.


Carnë Draug <carandraug>
Project Member
Tue 11 Feb 2014 03:25:07 PM UTC, comment #21: 

For those of you -- like me -- stuck with
Matlab/Octave cross-compatibility requirements:
This is a wrapper for Octave's and Matlab's inputParser routines,
so that m-code can be ran unmodified in both environments.  Code
originally written for Matlab need only append a "2" suffix to the
to the initial call to inputParser, i.e, p = inputParser2 (); it is
also recommended to add a call to dispose(p) just before the end of
the function using inputParser2(), to free up its memory resources.
Code originally written for Octave which wishes cross-compatiblity
with Matlab would need to be modified, adopting earlier the syntax
that will only become available in Octave after classdef is fully
implemented.  The input/output syntax of the inputParser2 wrapper
is intended to adhere to Matlab's syntax and remain stable despite
future changes in the Octave implementation called internally.

Felipe G. Nievinski <fgnievinski>
Tue 14 Jan 2014 01:21:48 PM UTC, comment #20: 

You're right, the example was not working. I have fixed it with r12500. Thank you

Carnë Draug <carandraug>
Project Member
Mon 13 Jan 2014 07:22:52 PM UTC, comment #19: 

there were more changes necessary to make the example run (with the original implementation);  here's a plain diff file.

(file #30263)

Felipe G. Nievinski <fgnievinski>
Mon 13 Jan 2014 06:23:03 PM UTC, comment #18: 

In the example given in the function reference:


"@val_mat" and "@val_verb" need to be replaced with "val_mat" and "val_verb"; context:

val_mat = @(x)isvector(x) && all( x <= 1) && all(x >= 0);
p = p.addOptional ("mat", [0 0], @val_mat);
val_verb = @(x) ischar(x) && any(strcmp(x, {"low", "medium", "high"});
p = p.addParamValue ("tolerance", "low", @val_verb);

Felipe G. Nievinski <fgnievinski>
Tue 07 Jan 2014 12:21:48 PM UTC, comment #17: 

We already have an almost compatible inputParser, why change it for another almost compatible version? I agree that with your changes, the almost compatible is bigger but let's consider that we apply them.

We apply your changes now and make a new release of the general package. We have to tell the current users of inputParser that we changed the API, and they must replace the current workaround with another one. Then, in a couple of months once Octave 4.2 is released with classdef, we fix inputParser so it's properly compatible. We have to tell all of them again to remove that workaround.

I guess that when we do it the second time, we can simply issue a warning that the the dispose method is deprecated, no big problem. But the worse part is that until the proper inputParser gets released in 4.2, we will have no way to find if dispose() is being called. We can document it now but what about the code that has already been written? I know that some Octave Forge functions already use.

I don't think it's worth the bother or risk. There's not many people crying out for inputParser, so I'd prefer to release a safe version once we get the possibility, i.e., for the version with classdef which has already been merged into the default branch.

Carnë Draug <carandraug>
Project Member
Tue 07 Jan 2014 05:33:18 AM UTC, comment #16: 

please let me know if there remains any outstanding contentions.  this brings an immediate benefit in terms of greater matlab compatibility in a concrete aspect that users have been inquiring about already.

Felipe G. Nievinski <fgnievinski>
Mon 06 Jan 2014 02:09:50 PM UTC, comment #15: 

this is easily taken care of with a dispose method for @inputParser:

function inPar = dispose (inPar)
  _inputParserStore_ ('push', inPar.counter, _inputParser_ ());

as a small price to play for greater matlab compatibility, this patch allows users to retain their calling code intact, except for a one-liner at the very end of their usage:

if is_octave (),  p.dispose ();  end

Felipe G. Nievinski <fgnievinski>
Mon 06 Jan 2014 08:07:33 AM UTC, comment #14: 

I'm not super sure about this. Is the data being removed when the object is removed?

It seems like you're keeping everything in memory. Because after doing parse() the data is kept in the object, you'll run out of memory very quickly if you're dealing with many large datasets.

Carnë Draug <carandraug>
Project Member
Mon 06 Jan 2014 05:22:52 AM UTC, comment #13: 

okay, here's the svn diff.
it took some moving around, I tried and kept the file histories.
I'm sending a zip with the result files, just in case.

as for the code design, the original @inputParser became @_inputParse_, which is used internally, e.g.:

function inPar = subsasgn (inPar, idx, rhs)
  _inPar_ = _inputParserStore_ ('pull', inPar.counter);
  _inPar_ = subsasgn (_inPar_, idx, rhs);
  _inputParserStore_ ('push', inPar.counter, _inPar_);

let me know if anything is unclear.

(file #30200, file #30201)

Felipe G. Nievinski <fgnievinski>
Mon 06 Jan 2014 04:38:21 AM UTC, comment #12: 


About your comment that Matlab users still run versions from
2009 or 2008: this is often not because they really prefer
old versions, but the cost and hassle of updating is not
worth it.

It is quite convenient that this is not such a problem with

Michael Godfrey <godfrey>
Project Member
Mon 06 Jan 2014 04:09:55 AM UTC, comment #11: 

I should also add, if you're in a rush due to some deadline at work or something, you can always patch and build your own Octave version and distribute it to whoever you want as long as you abide by the terms of the GPL.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon 06 Jan 2014 04:06:39 AM UTC, comment #10: 

> I'm looking at a time frame of the order of weeks not months.

What's the big rush? We are trying to release quickly, but there's no need to go that quickly. After all, people are still routinely running Matlab versions from 2009 or 2008, so it's not like the language implementation is in a huge rush to change.

> won't we have a 3.8.X before 4.0?

At the rate things are going, probably. But minor releases are just bug-fixing releases. New features don't get added there.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon 06 Jan 2014 03:33:39 AM UTC, comment #9: 

I'm looking at a time frame of the order of weeks not months.

won't we have a 3.8.X before 4.0?

and Octave-Forge general, which inputParser is part of, isn't part of the Octave base system yet, so that means even earlier update for that package.

the patch is not ugly, you'll see.  it leaves your original implementation mostly untouched and just adds a push/pull storage facility to keep the "class" state persistent.

Felipe G. Nievinski <fgnievinski>
Mon 06 Jan 2014 03:10:26 AM UTC, comment #8: 

3.8 is already out and the 4.0 is gui-release which is targeted to developing the GUI and other small fixes.

The current default branch will be 4.2 which already has classdef. One could argue that adding inputParser could fit in 4.0 because it couldn't possibly break what's already present but one version later we'd be fixing the hacks that were used to deal with the missing classdef.

I think it's better choice to just do it properly with classdef. Pick what's already written in the general package and make it work in core using classdef. It even has some tests already written so this will be a good thing to test development of classdef.

Carnë Draug <carandraug>
Project Member
Sun 05 Jan 2014 11:32:08 PM UTC, comment #7: 

okay, will merge into <http://sourceforge.net/p/octave/code/HEAD/tree/trunk/octave-forge/main/general/>

my goal would be for this to be included in the next release rather than waiting for release of classdef.

Felipe G. Nievinski <fgnievinski>
Sun 05 Jan 2014 10:10:04 PM UTC, comment #6: 

I wanted to take a look to see how you managed to workaround the missing classdef. Any chance you could merge your workaround with the implementation in the general package?

Also, this would probably be added to default which already has classdef so there would be no need for tricky business to work around it.

The general package already deals with all the things, there was no missing methods, and even had an extra one (addSwitch) not present in Matlab. The only problem it had was that one needed to do

obj = obj.method ()

instead of the Matlab compatible

obj.method ()

Carnë Draug <carandraug>
Project Member
Sun 05 Jan 2014 05:42:23 PM UTC, comment #5: 

any chance of having this patch incorporated?

Felipe G. Nievinski <fgnievinski>
Thu 19 Dec 2013 05:48:53 AM UTC, comment #4: 

here's a version compatible with matlab's -- it passes tests like:

p = inputParser();
p.addParamValue ("line", "tree");
p.parse(10, "line","circle");
assert(p.Results, struct("req",10, "line","circle"));

the two tests are
test @inputParser/inputParser
test @_inputParser/_inputParser

sorry it's a zip file -- I'm still getting used to mercurial...

(file #30044)

Felipe G. Nievinski <fgnievinski>
Wed 18 Dec 2013 11:58:34 AM UTC, comment #3: 

Not yet. The one in the general package is not 100% compatible and can only be when classdef is finished. Since that will happen for 4.2, I'm guessing it will be moved from the general package into Octave core then.

Carnë Draug <carandraug>
Project Member
Wed 18 Dec 2013 03:40:28 AM UTC, comment #2: 

should this be closed?

Felipe G. Nievinski <fgnievinski>
Mon 29 Oct 2012 07:00:30 PM UTC, comment #1: 

There's one in the general package from Octave-Forge.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon 29 Oct 2012 06:56:49 PM UTC, original submission:  

warning: the `inputParser' function is not yet implemented in Octave

Please read `http://www.octave.org/missing.html' to learn how you can
contribute missing functionality.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #30263:  inputParser.m.diff added by fgnievinski (944B - application/octet-stream)
file #30200:  inputParser.diff added by fgnievinski (69KiB - application/octet-stream)
file #30201:  inputParser.zip added by fgnievinski (22KiB - application/x-zip-compressed)
file #30044:  inputParser.zip added by fgnievinski (21KiB - application/x-zip-compressed)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by fgnievinski (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-11-06 carandraug StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2014-01-13 fgnievinski Attached File- => Added inputParser.m.diff, #30263
    2014-01-06 fgnievinski Attached File- => Added inputParser.diff, #30200
        Attached File- => Added inputParser.zip, #30201
    2013-12-19 fgnievinski Attached File- => Added inputParser.zip, #30044
    2013-12-18 rik5 Carbon-CopyRemoved 72865 => -
    2013-03-14 rik5 Severity3 - Normal => 1 - Wish
        Item GroupNone => Matlab Compatibility
    2012-10-29 jordigh StatusNone => In Progress

    Back to the top

    Powered by Savane 3.5