Wed 07 May 2014 10:02:15 PM UTC, comment #14:
Yes, looks like the hydra build is working again too. Thanks!
|
Wed 07 May 2014 03:56:16 PM UTC, comment #13:
I checked in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/9fbb254c09e6) which changes the new routines from inline functions in graphics.h to regular class methods stored in graphics.cc. This fixes the problem for me.
|
Wed 07 May 2014 01:20:30 PM UTC, comment #12:
The changeset applied to the default branch is failing to build. For some reason the built header file "builtin-defun-decls.h" is not yet built by the time that graphics.cc is compiled. Perhaps a dependency is needed in the Makefile to force it to be built first? I'm not sure, but the full build log shows that mkbuiltins has not run by the time graphics.cc is compiled:
http://hydra.nixos.org/build/10854596/log/raw
|
Wed 07 May 2014 08:47:49 AM UTC, comment #11:
Rik, thanks for the review and implementation example. Using this approach it will probably be easy to fix the other orphan root properties. I will fill a more general bug report for all those properties left.
|
Wed 07 May 2014 05:32:10 AM UTC, comment #10:
I pushed your changeset without modification here (http://hg.savannah.gnu.org/hgweb/octave/rev/28eab2d84190). For the original reporter, the fix will be part of the 4.2 release. If you need it sooner you must build from the development version source code.
|
Tue 06 May 2014 10:05:35 PM UTC, comment #9:
Thanks Rik, here is a second patch for "format" and "formatspacing". I mostly followed your approach for both properties.
(file #31326)
|
Tue 06 May 2014 04:22:48 PM UTC, comment #8:
@Pantxo: I think for data encapsulation it is better to keep the format variables where they currently reside; They don't have anything to do with graphic properties. I suggested using a get/set bridge to the variable. I've attached an example that shows how it can be done for the FormatSpacing variable.
(file #31322)
|
Tue 29 Apr 2014 07:52:39 AM UTC, comment #7:
What should I do?
My intention was to replace Vcompactformat by a function
bool compactformat (void)
{
Fget (ovl (0, "formatspacing"));
}
I admit there is no valuable advantage to follow matlab's weird design here but that is a way to avoid duplicated information.
|
Thu 24 Apr 2014 03:28:06 PM UTC, comment #6:
I don't like Matlab's approach to putting interpreter configuration variables in the graphics root object. Conceptually the two are unrelated, and I suspect they did this early on not through infinite wisdom, but because they didn't have another place to store this kind of data.
In terms of data encapsulation I think it is better to keep Vcompact_format together with the other format related configuration variables in pr-output.cc. For Matlab compatibility, a get/set bridge from the root object properties to pr-output.cc is necessary. But my vote would be to go no further than that.
|
Sun 20 Apr 2014 09:16:25 AM UTC, comment #5:
Yes, you are right it's a chance to eliminate a global variable. I'll look into this next week.
|
Sat 19 Apr 2014 01:59:11 PM UTC, comment #4:
Pantxo:
Thanks for looking at this problem. Your solution seems to work OK, but I'm not sure I like the fact that we have duplication of the property information now. It seems like it would be better to eliminate variables like Vcompact_format and only store the state of the formatspacing as a root property.
|
Sat 19 Apr 2014 01:33:57 PM UTC, comment #3:
I attached a patch that fixes both "format" and "formatspacing" root properties, but also "diary" and "diaryfile". If the approach I have chosen is validated, I can probably also fix the other unused root properties.
(file #31212)
|
Thu 17 Apr 2014 04:35:10 PM UTC, comment #2:
Confirmed. This is a known issue (see the comment in root properties definition in graphics.in.h).
There is currently no connection between root's "format" and "formatspacing" properties and the actual internal state of those features.
|
Thu 17 Apr 2014 03:48:59 PM UTC, comment #1:
Just to add, perhaps there is some other way to query this setting (I couldn't find anything on mathworks.com about it).
Even if this isn't supported, it probably shouldn't just say 'loose' all the time.
|
Thu 17 Apr 2014 03:27:38 PM UTC, original submission:
Whether "format loose" or "format compact", get(0,'FormatSpacing') always says 'loose'.
Same behaviour in 3.6.4 and 3.8.1.
## Example
octave:8> format loose
octave:9> a = rand(2,3)
a =
0.450011 0.999027 0.011445
0.563668 0.175056 0.285459
octave:10> get(0,'FormatSpacing')
ans = loose
## Now
octave:11> format compact
octave:12> a
a =
0.450011 0.999027 0.011445
0.563668 0.175056 0.285459
octave:13> get(0,'FormatSpacing')
ans = loose
octave:14>
I learned about this at http://nf.nci.org.au/facilities/software/Matlab/techdoc/ref/format.html and have confirmed that it works in that product.
|