I seek to override a default setting in Octave concerning plots. For instance, I always set box off; when plotting, so I would like to set the box off by default. Perhaps factoryaxesbox is the involved setting (are those factory settings documented anywhere?).
When I see a setting returned by get(0, "factory"), how can I assign a new default to override this?
I have been through this section of the Octave manual, section 15.3.5: Managing Default Properties, but it says little and I find it rather confusing. Object type, root object, child object, … Huh?
Figured it out after some amount of trial and error.
The name of available properties for plots are those returned by get(0, "factory"), without the factory prefix. In order to override any of these, you must prefix the property name with default, in the format set(0, "defaultNameOfProperty", "newsetting").
To set box off by default for all plots:
set(0, "defaultaxesbox", "off")
Before doing this, if you check for the existence of this property defaultaxesbox, using get(0, "default"), you will find nothing, making you wonder if you can set a setting which does not seem to exist. After the assignment has been made with set(), it will show up in get(0, "default").
If the first argument of set() was gca() or some other number, then replace zero with that in the above get().
Related
I mean to set the default legend font size (and other properties as well) in my Octave script.
Both set (activated separately)
legend_fontsize = 14;
set(0, "defaultlegendlocation", "northoutside");
set(0, "defaultlegendfontsize", legend_fontsize);
produce error: invalid default property specification.
What is the correct syntax?
In Matlab, this suggests it should not throw any error, and it should possibly work.
In theory you are right that this should also work in octave, since according to the manual, octave supports the same syntax, for all kinds of graphical object 'types'.
However, legend is a special case, because it is not implemented as its own graphical object 'type' in octave; instead, as stated in the documentation:
A legend is implemented as an additional axes object with the 'tag'
property set to "legend". Properties of the legend object may be
manipulated directly by using 'set'.
Therefore, this means that the defaultlegendfontsize strategy won't work.
It also means that, since in principle a 'legend' object is an 'axes' object in disguise, set( 0, 'defaultaxesfontsize', 30 ) will work ... but obviously with unintended consequences affecting all axes objects.
You could point that out in the octave bug tracker if you'd like.
In the meantime, you could always do something like the following in your .octaverc as a workaround:
function h = legend( varargin )
% Wrapper to builtin legend function, also setting font to default size of 30
h = builtin( 'legend', varargin{:} )
set( h, 'fontsize', 30 )
endfunction
This effectively shadows the builtin 'legend' command with a custom one, that applies 'default' values as an extra step before returning the handle.
PS: Having said this, one needs to be careful with setting such defaults, in the case of code dissemination and re-use which assumes such defaults are preset in all environments.
This is a common point of caution in R users against creating elaborate .Rprofile files, for instance.
PS 2: Alternatively, a nice approach when you have lots of defaults to apply would be to create a function applydefaults( handle ) which applies all your preferences in one go, and call it at the end of whatever object you want to apply these to. This is what I used to do in my thesis. It may sound like slightly more effort, but you end up thanking yourself 1 month down the line when it's 100% clear what is happening and where the formatting changes came from!
How is setted the property descriptor for the built-in method? For example for isPrototypeOf? I did not find such a place in the specification. Rather found, but there is no description of the attribute [[Value]]. It sounds like this:
"Every other data property is described in clauses 18 through 26 and
in Annex B.2 has the attributes {[[Writable]]: true, [[Enumerable] ]:
false, [[Configurable]]: true} unless otherwise specified"
Now we know what the other attributes will have, but we do not know what value will be set in [[Value]]. You can say that the value in [[Value]] will be set to the function object and you will be right. However, I want to know by specification where this is the place where for built-in properties is set [[Value]]
However, I want to know by specification where this is the place where for built-in properties is set [[Value]]
The specification doesn't have algorithmic steps for initializing the global objects, which makes sense since they are expected to exist before execution of any code actually begins.
Instead of simply states what structure should exist, so for instance in 19.2.3 Properties of the Function Prototype Object, it simply states
19.2.3.1 Function.prototype.apply ( thisArg, argArray )
in the header with the expectation that it is clear that it means the apply function is a property of the %FunctionPrototype% global object. Given that, there are only two types of properties,
Accessor properties
Data properties
Data properties are explicitly simple properties that contain a value. Function.prototype.apply doesn't have get or set prefix, or use an ## prefix), which means that this statement is specifying a data string-keyed data property. By definition, this means that it is clear that the [[Value]] is the function object itself, because there is nowhere else to put it, and [[Value]] is the clear correct choice.
The section you linked in 17 ECMAScript Standard Built-in Objects states
Every other data property described in clauses 18 through 26 and in Annex B.2 has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } unless otherwise specified.
is just filling in the rest of the data property fields, since it wouldn't make sense to repeat them for every single method.
I need to set the Xaml property of a RichTextBox user control via a binding expression in Windows Phone 8, and I found that it is not a DP, so I have decided to inherit from a RichTextBox and add a DP that will change the Xaml property with PropertyChanged event, anyways the code looks like this, stripped out irrelevant parts.
public class RichTextBoxWithBindableXaml : RichTextBox
{
public string BindableXaml
{
get { return (string)GetValue(BindableXamlProperty); }
set { SetValue(BindableXamlProperty, value); }
}
public static readonly DependencyProperty BindableXamlProperty =
DependencyProperty.Register("BindableXaml",
typeof(string),
typeof(RichTextBoxWithBindableXaml),
new PropertyMetadata(0));
}
//xaml code
<local:RichTextBoxWithBindableXaml BindableXaml="{Binding PageContent , Mode=OneWay}"> </local:RichTextBoxWithBindableXaml>
And I get the following dreaded exception message:
Object of type 'System.Windows.Data.Binding' cannot be converted to type 'System.String'.
I have checked many solutions to these exceptions and similar problems with data binding, and still going through the suggested similar questions on the right, and still cannot see why a simple thing wont work for me. The code I listed above is just the simplest implementations of a DP with a binding expression. Btw, the source PageContent is from a INotifyPropertyChanged object, and it works, I know because, it can bind to TextBlock's Text property.
Am I missing out something so obvious? I wouldn't want to post question for such a straightforward thing, but I cant seem to solve in any way.
EDIT:
Following P.S note turned out to be completely irrelevant.
P.S. My final doubt was on the way xmlns namespace local is loaded. It is loaded as clr assembly, could xaml parser think my custom inherited class as clr-only and confuse since clr properties are not dependency properties. Hope it doesnt sound stupid, i'm desperate. It is as such :
xmlns:local="clr-namespace:RumCli"
I found out that I should either provide a null PropertyMetadata (new PropertyMetadata(null) instead of 0), or a metadata with a default value type if the DP is supposed to be used in Xaml. For my sceneario, since I will make use of the PropertyChangedCallback, the propertymetadata that will passed to the Register method looks like this.
new PropertyMetadata(default(string), new PropertyChangedCallback(OnBindableXamlChanged))
hope, it helps to others.
For each dependency property one must supply a non subscribed value (not a C# term here) which suites the type of object which the consumer will access.
To quote MSDN Dependency Property Metadata
Dependency property metadata exists as an object that can be queried to examine the characteristics of a dependency property.
So for the value type results, a default for the different value types, such as a double is to use double.NaN. A decimal use decimal.Zero. While a string, string.empty is good as a base.
That allows whatever operation which may blindly reflect off of the property, it can determine what its true property type is and access it accordingly.
So assigning 0 to a string makes no sense in identifying that the property is a string which 0 identifies it as an integer. So the int as string is setting up a future runtime failures when objects try to assign bindings, styles and other items to it.
Just getting started with using chef recently. I gather that attributes are stored in one large monolithic hash named node that's available for use in your recipes and templates.
There seem to be multiple ways of defining attributes
Directly in the recipe itself
Under an attributes file - e.g. attributes/default.rb
In a JSON object that's passed to the chef-solo call. e.g. chef-solo -j web.json
Given the above 3, I'm curious
Are those all the ways attributes can be defined?
What's the order of precedence here? I'm assuming one of these methods supercedes the others
Is #3 (the JSON method) only valid for chef-solo ?
I see both node and default hashes defined. What's the difference? My best guess is that the default hash defined in attributes/default.rb gets merged into the node hash?
Thanks!
Your last question is probably the easiest to answer. In an attributes file you don't have to type 'node' so that this in attributes/default.rb:
default['foo']['bar']['baz'] = 'qux'
Is exactly the same as this in recipes/whatever.rb:
node.default['foo']['bar']['baz'] = 'qux'
In retrospect having different syntaxes for recipes and attributes is confusing, but this design choice dates back to extremely old versions of Chef.
The -j option is available to chef-client or chef-solo and will both set attributes. Note that these will be 'normal' attributes which are persistent in the node object and are generally not recommended to use. However, the 'run_list', 'chef_environment' and 'tags' on servers are implemented this way. It is generally not recommended to use other 'normal' attributes and to avoid node.normal['foo'] = 'bar' or node.set['foo'] = 'bar' in recipe (or attribute) files. The difference is that if you delete the node.normal line from the recipe the old setting on a node will persist, while if you delete a node.default setting out of a recipe then when your run chef-client on the node that setting will get deleted.
What happens in a chef-client run to make this happen is that at the start of the run the client issues a GET to get its old node document from the server. It then wipes the default, override and automatic(ohai) attributes while keeping the 'normal' attributes. The behavior of the default, override and automatic attributes makes the most sense -- you start over at the start of the run and then construct all the state, if its not in the recipe then you don't see a value there. However, normally the run_list is set on the node and nodes do not (often) manage their own run_list. In order to make the run_list persist it is a normal attribute.
The choice of the word 'normal' is unfortunate, as is the choice of 'node.set' setting 'normal' attributes. While those look like obvious choices to use to set attributes users should avoid using those. Again the problem is that they came first and were and are necessary and required for the run_list. Generally stick with default and override attributes only. And typically you can get most of your work done with default attributes, those should be preferred.
There's a big precedence level picture here:
https://docs.chef.io/attributes.html#attribute-precedence
That's the ultimate source of truth for attribute precedence.
That graph describes all the different ways that attributes can be defined.
The problem with Chef Attributes is that they've grown organically and sprouted many options to try to help out users who painted themselves into a corner. In general you should never need to touch automatic, normal, force_default or force_override levels of attributes. You should also avoid setting attributes in recipe code. You should move setting attributes in recipes to attribute files. What this leaves is these places to set attributes:
in the initial -j argument (sets normal attributes, you should limit using this to setting the run_state, over using this is generally smell)
in the role file as default or override precedence levels (careful with this one though because roles are not versioned and if you touch these attributes a lot you will cause production issues)
in the cookbook attributes file as default or override precedence levels (this is where you should set most of your attributes)
in environment files as default or override precedence levels (can be useful for settings like DNS servers in a datacenter, although you can use roles and/or cookbooks for this as well)
You also can set attributes in recipes, but when you do that you invariably wind up getting your next lesson in the two-phase compile-converge parser that runs through the Chef Recipes. If you have recipes that need to communicate with each other its better to use the node.run_state which is just a hash that doesn't get written as node attributes. You can drop node.run_state[:foo] = 'bar' in one recipe and read it in another. You probably will see recipes that set attributes though so you should be aware of that.
Hope That Helps.
When writing a cookbook, I visualize three levels of attributes:
Default values to converge successfully -- attributes/default.rb
Local testing override values -- JSON or .kitchen.yml (have you tried chef_zero using ChefDK and Kitchen?)
Environment/role override values -- link listed in lamont's answer: https://docs.chef.io/attributes.html#attribute-precedence
When defining bindings for types that requires ctor arguments for the default instance it's pretty clear how to do it. However, when I want to create alternative profiles it gets a bit more difficult.
This is how it's done for a default instance:
ForRequestedType(typeof (IRepository<>))
.TheDefaultIsConcreteType(typeof (SpRepository<>))
.CtorDependency<Uri>("sourceWeb")
.Is(new Uri("http://localhost"));
This is where I'm stuck with a profile:
CreateProfile("wss")
.For(typeof(IRepository<>))
.UseConcreteType(typeof(SpRepository<>))
// I'd expect to be able to insert this here...
//.CtorDependency<Uri>("sourceWeb")
.Is(new Uri("http://localhost")))
How can I set up the typemapping for this profile?
Am I forced to use instance binding (where I can pass default values to the ctor arguments)?