Thu 17 Jul 2014 08:13:22 PM UTC, comment #15:
The latest syntax doesn't produce a warning and seems to run all the demos correctly so I committed it here (http://hg.savannah.gnu.org/hgweb/octave/rev/961ecaf9fb57).
|
Wed 16 Jul 2014 05:23:26 PM UTC, comment #14:
I've got the same warning, but what is strange is that this warning disappears if you change the code this way:
I'm not sure how get(hax,"units") works, but it seems the output is always a column vector. In that case we don't even need the first line in the code above.
|
Wed 16 Jul 2014 04:28:38 PM UTC, comment #13:
Maybe things have changed since this was coded because your example seems to work now. However, If I make the change and then run demo ('legend') I now have warnings. So something with the new syntax still isn't perfect.
|
Wed 16 Jul 2014 04:20:04 PM UTC, comment #12:
Look at the comment above the line in question. It is Octave weirdness that is forcing this issue.
|
Wed 16 Jul 2014 04:18:11 PM UTC, comment #11:
I mean that the following works in Octave (at least for me):
|
Wed 16 Jul 2014 03:56:18 PM UTC, comment #10:
But then.. why not:
Sorry if this is obvious. I've just supplied a patch for the bug #42554 where we need to take into account the same possibility.
|
Wed 16 Jul 2014 03:23:39 PM UTC, comment #9:
Because there may be more than one value in the variable "units" and Octave was not auto-expanding the property {"units"} to match the number af values in the variable.
This works
because Octave loops internally over every handle in hax and applies the one-to-one mapping of Property/Value pair.
This doesn't work
because the number of properties doesn't match the number of values. At some point it would be nice to update the set routine in C++ to deal with this. But it doesn't happen very often so the workaround of repmat is okay for now.
|
Wed 16 Jul 2014 10:00:47 AM UTC, comment #8:
Just out of interest.. Why did you use repmat() when changing "units" back? Are there any drawback in writing line 1093 as simple as:
|
Thu 15 May 2014 07:11:14 AM UTC, comment #7:
If patch for bug #42362 is applied, this works for me too.
|
Thu 15 May 2014 03:30:09 AM UTC, comment #6:
This changeset fixes the problem with plotyy for me (http://hg.savannah.gnu.org/hgweb/octave/rev/5f37573a6868).
|
Wed 14 May 2014 10:26:58 PM UTC, comment #5:
As mentioned in bug 42362 this bug should be reopened, since it's not possible to call plotyy again after setting legend.
|
Wed 09 Apr 2014 04:16:44 AM UTC, comment #4:
I was working along similar lines to Pantxo and created a changeset that solves the problem. I checked it in here (http://hg.savannah.gnu.org/hgweb/octave/rev/8c0646dd9e5a). Closing report.
|
Tue 08 Apr 2014 08:49:10 PM UTC, comment #3:
I attached a patch.
(file #31142)
|
Thu 27 Mar 2014 03:17:10 PM UTC, comment #2:
plotyy and legend are both complicated functions that put multiple axes objects on the same figure so I'm not surprised that there's a bit of a problem with interactions between the two. I overhauled plotyy on the development branch so any fixes should be done on that branch which uses the newest versions of plotyy.m and legend.m. I'm marking the release as "dev" to encourage that.
|
Thu 27 Mar 2014 01:02:24 PM UTC, comment #1:
Confirmed, and for completeness, here is the error I see with 3.8.1:
This didn't work under 3.6.4 either, although with a different error:
|
Thu 27 Mar 2014 10:43:12 AM UTC, original submission:
For some reason I wasn't able to change neither loacation nor orientation of legend created for plotyy chart.
Just check out the following piece of code:
|