bugGNU Octave - Bugs: bug #41028, warning off shouldn't affect...

 
 

bug #41028: warning off shouldn't affect lastwarn

Submitter:  Felipe G. Nievinski <fgnievinski>
Submitted:  Sun 29 Dec 2013 07:38:18 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Release: 
Operating System:  * Any Fixed Release:  10.1.0 (current stable)
Planned Release:  10.1.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 01 Mar 2025 10:35:24 AM UTC, comment #30: 

The tests for the io and symbolic packages no longer failed in the last round of CI tests. And there aren't any regressions for any other tests that we are running as far as I can see.

Closing report as fixed.

Markus Mützel <mmuetzel>
Group administrator
Thu 27 Feb 2025 06:17:45 PM UTC, comment #29: 

Thanks for testing.

It looks like that failing test in the symbolic package isn't related to warnings. So, it is unrelated to this report.
Nice to know that the other tests are passing now. I'll still leave this report on "ready for test" status until we had a full CI cycle (i.e., probably on Saturday).

Markus Mützel <mmuetzel>
Group administrator
Thu 27 Feb 2025 06:14:10 PM UTC, comment #28: 

I have one failure with symbolic:

***** test
 % empty input
 A = sym([1 2]);
 C = intersect(A, []);
 assert (isequal (C, sym([])))
!!!!! test failed



octave:1> pkg load symbolic
octave:2> A = sym([1 2])
Symbolic pkg v3.2.1: Python communication link active, SymPy v1.14.dev.
A = (sym) [1  2]  (1×2 matrix)
octave:3> C = intersect(A, [])
C = (sym) []  (empty 1×0 matrix)
octave:4> isequal (C, sym([]))
ans = 0
octave:5> sym([])
ans = (sym) []  (empty 0×0 matrix)


But that probably unrelated. All other tests (and io package) passed.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 27 Feb 2025 05:47:30 PM UTC, comment #27: 

Implementing the idea from comment #25 was easy enough. So, I went ahead and made that change on the stable branch:
https://hg.savannah.gnu.org/hgweb/octave/rev/1daca7731704

After all, that fixes a "regression" in how our "test" function works.

I then followed up by reverting the changes to the warning tests because imho not failing in warning tests but checking whether the execution continues without errors has its merits:
https://hg.savannah.gnu.org/hgweb/octave/rev/12f080587182

That should probably be restoring the currently failing tests for the io and symbolic packages. We'll probably know that on Saturday if the CI plays along nicely.

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Wed 26 Feb 2025 10:50:14 AM UTC, comment #26: 

Thanks for the explanation, Markus.

Nevertheless I'm busy fixing the two 'offending' io package functions and even got some help, but it'll take a while.  Making a new io package release that I took up some time ago depends on yet more things so will come after Octave 10.1.
So I guess for at least Octave 10.1 we'll have to make do with these 'pkg test' FAILs for the io package; maybe/probably for symbolic and other packages as well ...

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 Feb 2025 10:14:03 AM UTC, comment #25: 

After yesterdays online meeting, I had another look at the `test.m` function.
Afaict, it does not enable all warnings. It does contain the undocumented (internal?) command `warning ("on", "quiet");`.

If I understand correctly, that command had the following meaning before this change:

  • Do not emit any warning messages to the command prompt even if the warning state is "on".
  • Still record warnings for which the state is "on" for `lastwarn`.


After the changes from here, `warning ("on", "quiet")` essentially is the same as `warning ("off", "all")`. For both, the behavior now is:

  • Do not emit any warning messages to the command prompt.
  • Still record any warning for `lastwarn`.


One way to "fix" the behavior of the `test.m` function for warning tests would be to restore the previous behavior of `warning ("on", "quiet")`. I.e.:

  • Do not emit any warning messages regardless of the warning state.
  • Only record warnings for which the state is set to "on" for `lastwarn`.


Since `warning ("on", "quiet")` is an (undocumented) Octave extension, the behavior of `lastwarn` could still be kept Matlab-compatible for the case with `warning ("off", "quiet")` (which is the default).

It's probably too late to fix this for Octave 10.1. But maybe we could consider fixing it for Octave 10.2.

Markus Mützel <mmuetzel>
Group administrator
Tue 18 Feb 2025 06:28:53 PM UTC, comment #24: 

@Rik:
Thanks, that code suggestion works for the warning BIST.

As to other warnings that are silenced in normal operation but activated for tests, another strategy is needed (apart from fixing the code, if at all possible for all imaginable situations).

Philip Nienhuis <philipnienhuis>
Group Member
Mon 17 Feb 2025 05:42:30 PM UTC, comment #23: 

A new function 'last_visible_warn' would not work in all cases.  A trivial test case is


warning ('Warn1');
warning ('Warn2');
warning ('Warn3');


How does one test for "Warn1" and "Warn2"?  In this case, a queue-based solution seems like the only way if we don't want user's to have to change their code.

I'd like to see how far we could get by correcting or modifying m-file code in packages, which is relatively easy, compared to adding additional functionality to core Octave.

If we are permitted to change m-file code and add a warning ID then the code above is testable with the current Octave core.

New code:


warning ('ID1', 'Warn1');
warning ('ID2', 'Warn2');
warning ('ID3', 'Warn3');


BIST test would change from


%!warning <Warn1> my_function (...)


to


%!error <Warn1>
%! warning ('error', 'ID1');
%! my_function (...)


What I did was convert the warning to an error which aborts further execution so there is no longer an issue with the last warning being overwritten by a new one.  And because it is an error, I switch to the %!error syntax.


Rik <rik5>
Group administrator
Mon 17 Feb 2025 02:22:00 PM UTC, comment #22: 

[ Slightly OT here:
I've started fixing the io package warning tests in the mean time.
But I still think that the mechanism for testing warning BISTs needs another solution. ]

Thinking a bit further about Markus' idea, would something like "last_visible_warn" be safe in all cases? I mean, is it always certain that BIST warning test are supposed to check the very last emitted warning?

In the documentation it could be outlined more clearly what is happening behind the scenes when BIST warnings are tested.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 14 Feb 2025 01:33:53 PM UTC, comment #21: 

Well, it emerges that the at first sight simple '%!warning ...' syntax behaves like an iceberg: only a few % is visible but the uninitiated don't see that there's a lot more going on in the underlying code.
So I searched the manual for documentation about turning on all warnings in the 'test', 'lastwarn', 'warning' and related sections but couldn't find it.
Yet I'm getting a vague idea what 'lastwarn' needs, incl. the idea that basing the '%!warning ...' syntax on 'lastwarn' might not be robust (but I may be very wrong). Like I wrote in comment #18, I can conceive valid reasons why some warning needs to remain silenced depending on the environment at hand, even while testing other warnings in the same or some other function in that environment.

Note that I'm not quite promoting making room for sloppy programming practices, e.g., in the code Arun showed in comment #15 (that indeed needs fixing).  It's just that I still don't follow why '%warning ...' needs to override silenced warnings in the first place. I can be enlightened though :-)

Therefore Markus' idea sounds good as far as I can judge. Is 'lastwarn' still needed at all then for the test suite?
Hopefully  implementing s/th like 'last_visible_warn' or so isn't too much work or too much of a maintenance burden.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 14 Feb 2025 08:46:15 AM UTC, comment #20: 


> It would be useful to know how many BIST tests are failing under the updated behavior of lastwarn() (none in core Octave), and see how the burden of recoding those tests compares to adding a new feature to Octave that will only ever be used for BIST tests.


See comment #12: So far, I noticed "regressions" in the test suites of the io package (bug #66790) and the symbolic package: https://github.com/gnu-octave/symbolic/issues/1321

I don't know if there are others. (There very well might be.)

> This could be a way out.  As jwe indicated, it would require coding up new functionality.  Right now only the last warning is stored.  Instead, a queue (of some set size such as 10) would need to be created and maintained.  There would also need to be a way to clear the queue.  Otherwise, the warning to be searched for might already exist in the queue from a previous test resulting in a %!warning test passing even though the warning wasn't issued.


That sounds like it could be a solution. But it also sounds like dealing with that queue could be complicated to manage.

Would it be easier to add a separate new function that behaves like the old "lastwarn" (e.g., "last_visible_warn")? I.e., save the info of the last emitted warning and the last visible warning.
If we used that new function for the test suite, the behavior wouldn't change for downstream users. And the behavior of "lastwarn" could still be kept Matlab-compatible.


Markus Mützel <mmuetzel>
Group administrator
Thu 13 Feb 2025 09:10:11 PM UTC, comment #19: 


> A suggestion for a way out: just check if the expected warning is in the list of emitted warnings at all, and if so, pass, and if not, fail.


This could be a way out.  As jwe indicated, it would require coding up new functionality.  Right now only the last warning is stored.  Instead, a queue (of some set size such as 10) would need to be created and maintained.  There would also need to be a way to clear the queue.  Otherwise, the warning to be searched for might already exist in the queue from a previous test resulting in a %!warning test passing even though the warning wasn't issued.

It would be useful to know how many BIST tests are failing under the updated behavior of lastwarn() (none in core Octave), and see how the burden of recoding those tests compares to adding a new feature to Octave that will only ever be used for BIST tests.

>> the author is testing for one warning when two warnings are being emitted.  Did they know about that second one?


> IMO it doesn't or even shouldn't matter whether an author knows about the other warnings, what counts if the one he/she wants to see is generated. See below:


>>  The current BIST code turns all warnings on before running the tests so that at least the environment is repeatable.


> I'm not sure I can follow why that would be required. I can imagine warnings to be conditional on a specific environment, or specific dependencies, or specific runtimes, or specific whatever, so undiscriminately turning on silenced warnings could even be detrimental.

IMO it's the responsibility of the author of the BIST warning to make sure that the relevant warning to be tested isn't silenced / can be generated at all.

> Since it is the responsibility of the BIST author to write a test that adequately checks for the functionality


> Similar probably holds for error BISTs, although those are quite a different beast.


The difference between error and warning BISTs is important.  It is the responsibility of the BIST author to write a test that verifies the functionality of their code.  If the BIST code would cause two errors then only the first one will ever be known because Octave aborts execution at the first error statement.  So if the BIST test was actually looking for the second error then it would be a failure.  One possible way out would be to recode the BIST test so the first error is not provoked.  Another possible way would be to create a queue of error messages, have error() not abort execution immediately but continue to execute a function, and at the end of the function look to see if the queue is non-empty and then process the first error in the queue.  To me, that seems harder than just recoding the BIST test and I have the same feeling about warning tests.  It feels simpler to modify either the BIST test or the underlying m-code to avoid the situation where more than one warning is generated during a function call.


Rik <rik5>
Group administrator
Thu 13 Feb 2025 06:48:48 PM UTC, comment #18: 

Thanks for the helpful discussion.
So a BIST warning test (temporarily) switches on all warnings, even silenced ones. I suspect that not many package maintainers / developers / contributors are aware of that.

A suggestion for a way out: just check if the expected warning is in the list of emitted warnings at all, and if so, pass, and if not, fail. After all, the BIST warning code as it stands, and as many coders perceive it, is meant to check for just one specifically provoked warning, not all warnings - isn't it?

> the author is testing for one warning when two warnings are being emitted.  Did they know about that second one?

IMO it doesn't or even shouldn't matter whether an author knows about the other warnings, what counts if the one he/she wants to see is generated. See below:

>  The current BIST code turns all warnings on before running the tests so that at least the environment is repeatable.

I'm not sure I can follow why that would be required. I can imagine warnings to be conditional on a specific environment, or specific dependencies, or specific runtimes, or specific whatever, so undiscriminately turning on silenced warnings could even be detrimental.
IMO it's the responsibility of the author of the BIST warning to make sure that the relevant warning to be tested isn't silenced / can be generated at all.

Similar probably holds for error BISTs, although those are quite a different beast.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 13 Feb 2025 06:00:24 PM UTC, comment #17: 

If we decide that tests for warnings should pass if the expected warning has been displayed and not that it must be the only warning or the last warning that has been displayed, then might be able to define a new function (or add an option to lastwarn) to return a list of all the previous warnings since the lastwarn state was cleared?  Maybe we would also want to limit the number of past warnings that Octave stores to avoid resource issues?  Then we could search the list of previous warnings for the one we expect to find.

John W. Eaton <jwe>
Group administrator
Thu 13 Feb 2025 04:48:51 PM UTC, comment #16: 

We want to keep the behavior that all calls to warning() set the warning ID and warning message.  The only question is whether that information is displayed immediately or not which is controlled by


warning ('on', 'XXX');
OR
warning ('off, 'XXXa');


This is Matlab-compatible which is desirable by itself.  But, it also gets back to least surprise.  The BIST test is failing because the author is testing for one warning when two warnings are being emitted.  Did they know about that second one?  They probably should re-code to avoid warnings.  The fact that code would behave differently on different systems based on which warnings were enabled would lead to a lot of headaches for maintainers.  The current BIST code turns all warnings on before running the tests so that at least the environment is repeatable.

For core Octave, I re-coded all of the BIST tests that I could (there were maybe 3 that couldn't be done).  In general, there is a way to either fix the second warning, or recode into an error test to check.

For the toJSON case, the code is tripping on the "Octave:array-as-logical" warning.  The function size() always returns at least a 2-element vector (rows, columns).  This code shows what is happening:


octave:3> diary on
octave:4> warning ('on', 'Octave:array-as-logical')
octave:5> sz = [1, 1];
octave:6> if (sz)
> endif
warning: Using an object of size 1x2 as a boolean value implies all().
octave:7> if (all (sz))
> endif
octave:8> diary off


As you can see, one option is to wrap the conditional with all().  However, in this case it seems it would be clearer to use isscalar().

Rik <rik5>
Group administrator
Thu 13 Feb 2025 03:46:33 PM UTC, comment #15: 

The problem is local to toJSON. This is what I did to trace it.


$ octave -q

octave:1> pkg load io

octave:2> warning on all

octave:3> toJSON (0, struct)
warning: toJSON.m: invalid PREC
warning: Using an object of size 1x2 as a boolean value implies all().
warning: called from
    toJSON>_tojson_ at line 208 column 11
    toJSON at line 118 column 5

ans = 0


The cause is this code in toJSON near line 118:

      ## bracket string
      if( size(obj) > 1 );


Changing "size(obj) > 1" to "numel(obj) > 1" eliminates the warning for me.

Arun Giridhar <arungiridhar>
Group Member
Thu 13 Feb 2025 10:13:49 AM UTC, comment #14: 

To clarify a bit about comment #13:

I expect BIST tests for warnings to fail only if a warning emitted by a function to be tested doesn't match the warning specified in the warning BIST.
Now, in the example (verbatim block) in comment #13:

  • the function to be tested just emits the expected warning when used in a "normal" context (see first line)
  • (forget the second line, it's commented out so does nothing)
  • in a test setting the warning test fails due to a completely different warning that isn't emitted in "normal" use of the tested function.


IMO that's against the principle of "least surprise".
Moreover, AFAICS the warning tests now behave differently than error tests.

As to interference by the bytecode interpreter (mentioned over in bug #66790), I guess the, or at least some, warnings generated but immediately silenced in the bytecode interpreter somehow get reanimated and screw up warning tests.  I assume there's nothing wrong with the bytecode interpreter itself in the context of this bug.

So, IMO the pushed cset has some unexpected / unwanted side effects.  Maybe the cset itself is OK but the code for testing warnings needs additional treatment.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 12 Feb 2025 09:50:17 PM UTC, comment #13: 

Indeed, see bug #66790, esp. the second verbatim block, repeated here:
(toJSON is a function in the io package)

>> toJSON(0,struct)
warning: toJSON.m: invalid PREC
ans = 0

>> %!warning <invalid PREC>   toJSON(0,struct)    ## no problems

>> test toJSON
***** warning <invalid PREC>   toJSON(0,struct);
!!!!! warning failed.
Expected <invalid PREC>, but got <Using an object of size 1x2 as a boolean value implies all().>
>>

I fail to see the problem in toJSON.  AFAIU this error is due to interference of the 'warning' code in a test setting context.

For the moment, reopening.  I'm reluctant to mark it as a regression.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 12 Feb 2025 04:29:08 PM UTC, comment #12: 

There might have been some fallout for Octave packages from this.
E.g.: bug #66790 or https://github.com/gnu-octave/symbolic/issues/1321

Is there general advice for downstream on how they could adapt to this change in behavior for Octave 10?

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jan 2025 09:53:11 PM UTC, comment #11: 

I went ahead and pushed the two changesets.  Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Thu 30 Jan 2025 12:52:28 AM UTC, comment #10: 

Attached is a changeset which fixes the BIST tests to pass under the Matlab-compatible lastwarn() behavior.  There were only two BIST tests that couldn't be translated and had to be commented out, which isn't bad.

If someone could review and give a blessing I'd like to go ahead and commit this before the 10.1 release.

(file #56832)

Rik <rik5>
Group administrator
Wed 29 Jan 2025 11:16:45 PM UTC, comment #9: 

I refreshed jwe's to apply to 10.1 development branch.

I feel we should apply this, and then do the best we can with updating the BIST tests.  I will make a changeset to update those, but if the code causes two warnings to be issued then there is no way to get them to work.  I would be fine with just eliminating those BIST tests.

(file #56831)

Rik <rik5>
Group administrator
Thu 28 Jul 2022 03:56:57 PM UTC, comment #8: 

Cross-linking related Bug #62829.

Arun Giridhar <arungiridhar>
Group Member
Tue 23 Jun 2020 04:35:19 PM UTC, comment #7: 

I updated the patch again (attached).

But this change causes a number of failures with the test suite because we expect to be able to check lastwarn but now can instead get the wrong info if there are disabled warnings (like for Octave language extensions) that happen between the code for the test case and our attempt to grab the last warning info.  So some other chages will be needed to handle that before we can apply this patch.

(file #49356)

John W. Eaton <jwe>
Group administrator
Fri 04 Dec 2015 01:40:19 AM UTC, comment #6: 

I have freshened the patch.

One caveat with changing the behaviour of "warning off" is that there are many warnings that are off by default but are thrown by core code like "help".

An alternative to this patch is simply to rename "quiet" to "off" and to rename "off" to something like "nothing".  That keeps Matlab compatibility and the current flexibility.

I have two related gripes.  Please let me know if they should be separate bug reports:

1) Is there a comand to reset the warning status to the original setting, with a dozen or so warnings "off"?  If not, I think there should be.

2) The documentation should not recommend "warning(error)", because it breaks commands like "help", without which it is hard to find out how to fix it.  I propose adding the keyword "active" as an alternative for "all", but that does not affect warnings that are off, and making that the default set of warnings when none is specified.

I'm happy to write patches for these if they are approved of.

(file #35639)

Lachlan Andrew <lachlan>
Mon 29 Dec 2014 04:19:44 AM UTC, comment #5: 

@jwe: The patch you submitted for warning is now almost exactly 1 year old.  Should it be committed and this bug closed?

Rik <rik5>
Group administrator
Mon 30 Dec 2013 10:00:37 PM UTC, comment #4: 

I'm okay with ditching warning quiet but warning on|off should be retained, to chose whether the message is displayed or not.

Felipe G. Nievinski <fgnievinski>
Mon 30 Dec 2013 09:47:40 PM UTC, comment #3: 

I think I would prefer something like the attached patch.

It seems to me that the "warning on|off|query quiet" feature is not needed if the warning id and message are still set when warning is "off".  I'm inclined to deprecate this feature and remove it in the future.  I don't think that it was ever documented, so maybe we could just remove it.


(file #30136)

John W. Eaton <jwe>
Group administrator
Mon 30 Dec 2013 08:00:34 PM UTC, comment #2: 

unfortunately the undocumented feature "warning quiet" wouldn't help with matlab compatibility, when a user wishes to check lastwarn.

I've submitting a tentative patch; could you please let me know if it's in the right direction or not.


(file #30134)

Felipe G. Nievinski <fgnievinski>
Mon 30 Dec 2013 05:00:31 PM UTC, comment #1: 

Have you tried "warning on quiet"? That will suppress the display of warnings but still record them in the background.


octave:1> lastwarn
ans =
octave:2> warning query quiet
ans =
  scalar structure containing the fields:
    identifier = quiet
    state = off
octave:3> warning on quiet
octave:4> warning query quiet
ans =
  scalar structure containing the fields:
    identifier = quiet
    state = on
octave:5> 1/0
ans = Inf
octave:6> lastwarn
ans = warning: division by zero


Arun Giridhar <arungiridhar>
Group Member
Sun 29 Dec 2013 07:38:18 PM UTC, original submission:  

contrast:

>> warning("on", "Octave:singular-matrix-div");  lastwarn("", "")
>> ones(2)  [1;1];  [msg, id] = lastwarn ()

warning: matrix singular to machine precision, rcond = 0
msg = warning: matrix singular to machine precision, rcond = 0
id = Octave:singular-matrix-div

to:

>> warning("off", "Octave:singular-matrix-div");  lastwarn("", "")
>> ones(2)  [1;1];  [msg, id] = lastwarn ()

{no warning displayed}
msg =
id =

it should do instead:

>> warning("off", "Octave:singular-matrix-div");  lastwarn("", "")
>> ones(2)  [1;1];  [msg, id] = lastwarn ()

{no warning displayed}
msg = warning: matrix singular to machine precision, rcond = 0
id = Octave:singular-matrix-div

Felipe G. Nievinski <fgnievinski>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #56832:  update_BIST.cset added by rik5 (6KiB - application/octet-stream)
file #56831:  bug41028.cset added by rik5 (2KiB - application/octet-stream)
file #49356:  bug-41028.txt added by jwe (2KiB - text/plain)
file #30136:  diffs.txt added by jwe (3KiB - text/plain)
file #30134:  lastwarn.diff added by fgnievinski (873B - application/octet-stream)

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by fgnievinski (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 26 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-03-01 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2025-02-27 mmuetzel StatusNone Ready For Test
    2025-02-13 philipnienhuis Carbon-Copy- Added philipnienhuis
    2025-02-12 philipnienhuis Dependencies- bugs #66790 is dependent
    2025-02-12 philipnienhuis StatusFixed None
        Open/ClosedClosed Open
    2025-01-30 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 10.1.0 (current stable)
    2025-01-30 rik5 Attached File- Added update_BIST.cset, #56832
        StatusPatch Reviewed Patch Submitted
    2025-01-29 rik5 Attached File- Added bug41028.cset, #56831
        StatusPatch Submitted Patch Reviewed
        Planned ReleaseNone 10.1.0 (current stable)
    2025-01-29 rik5 Dependencies- bugs #62829 is dependent
    2020-06-23 jwe Attached File- Added bug-41028.txt, #49356
        Assigned tolachlan None
    2016-03-31 mtmiller Release3.6.4 dev
        Operating SystemMicrosoft Windows Any
    2016-02-26 rik5 Assigned toNone lachlan
    2015-12-04 lachlan Attached File- Added bug_41028-warn-quiet-freshened.txt, #35639
    2014-01-19 mtmiller CategoryNone Octave Function
        StatusNone Patch Submitted
    2013-12-30 jwe Attached File- Added diffs.txt, #30136

    Back to the top

    Powered by Savane 3.14-7003.
    Corresponding source code