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 Oct 29 18:56:49 2012  
 
Category: LibrariesSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: Originator Email: -unavailable-
Open/Closed: ClosedRelease: 3.6.3
Operating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Thu Nov 12 18:13:48 2015, 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 Nov 6 11:55:39 2014, 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.

http://hg.savannah.gnu.org/hgweb/octave/rev/ff820f92cbb5

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

For those of you -- like me -- stuck with
Matlab/Octave cross-compatibility requirements:
<https://github.com/fgnievinski/inputParser2>
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 Jan 14 13:21:48 2014, comment #20:

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

Carnë Draug <carandraug>
Project Member
Mon Jan 13 19:22:52 2014, 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 Jan 13 18:23:03 2014, comment #18:

In the example given in the function reference:

<http://octave.sourceforge.net/general/function/@inputParser/inputParser.html>

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

Felipe G. Nievinski <fgnievinski>
Tue Jan 7 12:21:48 2014, 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 Jan 7 05:33:18 2014, 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 Jan 6 14:09:50 2014, comment #15:

this is easily taken care of with a dispose method for @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 Jan 6 08:07:33 2014, 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 Jan 6 05:22:52 2014, 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.:

let me know if anything is unclear.

(file #30200, file #30201)

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

Jordi,

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
Octave.

Michael Godfrey <godfrey>
Mon Jan 6 04:09:55 2014, 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 Jan 6 04:06:39 2014, 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 Jan 6 03:33:39 2014, 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 Jan 6 03:10:26 2014, 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 Jan 5 23:32:08 2014, 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 Jan 5 22:10:04 2014, 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

instead of the Matlab compatible

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

any chance of having this patch incorporated?

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

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

p = inputParser();
p.addRequired("req",@isnumeric);
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 Dec 18 11:58:34 2013, 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 Dec 18 03:40:28 2013, comment #2:

should this be closed?

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

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

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon Oct 29 18:56:49 2012, 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.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Nov 6 11:55:39 2014carandraugStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Mon Jan 13 19:22:52 2014fgnievinskiAttached File-=>Added inputParser.m.diff, #30263
    Mon Jan 6 05:22:52 2014fgnievinskiAttached File-=>Added inputParser.diff, #30200
      Attached File-=>Added inputParser.zip, #30201
    Thu Dec 19 05:48:53 2013fgnievinskiAttached File-=>Added inputParser.zip, #30044
    Wed Dec 18 03:51:56 2013rik5Carbon-CopyRemoved 72865=>-
    Thu Mar 14 19:37:43 2013rik5Severity3 - Normal=>1 - Wish
      Item GroupNone=>Matlab Compatibility
    Mon Oct 29 19:00:30 2012jordighStatusNone=>In Progress

    Back to the top


    Powered by Savane 3.1-cleanup