Premake 5 gives you two functions to separate independent configuration variables in your projects: configurations and platforms. So for example, you might have:
configurations { "Debug", "Release" }
platform { "Windows", "Linux" }
The documentation refers to these as axes, which is a good way to describe them, since you can have independent settings for each axis:
Really, platforms are just another set of build configuration names, providing another axis on which to configure your project.
But what if I want another axis? For example, the data types used for particular calculations:
calctypes { "Long", "Default", "Short" }
Can I create this new axis, and if so, how?
I think tags (a new feature due to be released in the next alpha build) might be what you're looking for. Here is an example from the pull request where they were implemented:
workspace 'foobar'
configurations { 'release-std', 'debug-std', 'release-blz', 'debug-blz' }
filter { 'configuration:*-std' }
tags { 'use-std' }
filter { 'configuration:*-blz' }
tags { 'use-blz' }
project 'test'
filter { 'tags:use-blz' }
includedependencies { 'blz' }
defines { 'USE_BLZ' }
filter { 'tags:use-std' }
defines { 'USE_STD' }
Update: If you would like to see how to add custom fields (e.g. defines, configurations, etc.), have a look at the api.register() calls in _premake_init.lua. To see how to enable filtering on one of these fields, have a look at this pull request.
While adding new fields is trivial and can be done anywhere, we need to do some work before it will be as simple to enable those fields for filtering.
Related
It is possible to configure Cloudera Impala (5.12) to default to name instead of position for PARQUET_FALLBACK_SCHEMA_RESOLUTION?
My Parquet files don't always have the same set of columns so we need Impala to look them up by name rather than position, and its a bit of a pain to do this in Hue for every session:
set PARQUET_FALLBACK_SCHEMA_RESOLUTION=name;
I'm afraid this isn't configurable on Impala side.
case TImpalaQueryOptions::PARQUET_FALLBACK_SCHEMA_RESOLUTION: {
if (iequals(value, "position") ||
iequals(value, to_string(TParquetFallbackSchemaResolution::POSITION))) {
query_options->__set_parquet_fallback_schema_resolution(
TParquetFallbackSchemaResolution::POSITION);
} else if (iequals(value, "name") ||
iequals(value, to_string(TParquetFallbackSchemaResolution::NAME))) {
query_options->__set_parquet_fallback_schema_resolution(
TParquetFallbackSchemaResolution::NAME);
} else {
return Status(Substitute("Invalid PARQUET_FALLBACK_SCHEMA_RESOLUTION option: "
"'$0'. Valid options are 'POSITION' and 'NAME'.", value));
}
break;
}
Impala server doesn't set default query options. All options are set where client session is setting up. So you need to configure whatever the client you are using. See shell/impala_shell_config_defaults.py for instance.
However, you can still modify the code and recompile :)
in common/thrift/ImpalaInternalService.thrift
struct TQueryOptions {
....
// Determines how to resolve Parquet files' schemas in the absence of field IDs (which
// is always, since fields IDs are NYI). Valid values are "position" (default) and
// "name".
43: optional TParquetFallbackSchemaResolution parquet_fallback_schema_resolution = 0 <--- change it to 1
....
}
Thanks for the info Amos,
I posted the same question on the Cloudera forums and they pointed me to a way to configure this thru the Cloudera Manager.
http://community.cloudera.com/t5/Interactive-Short-cycle-SQL/PARQUET-FALLBACK-SCHEMA-RESOLUTION/m-p/62318#M3883
As I try to run nice Ip2Geo Importer to add geo functionality to my site, I noticed strange nginx 1.13.6 behavior. I'm in doubt if this is something intended, or I have a way out to use.
Here is the config sample:
geo $city {
ranges;
default $city_mm;
include geo/city.txt;
}
geo $city_mm {
ranges;
include geo/mm_city.txt;
}
that is, it should return content of $city_mm if value of $city can not be calculated/found, but as I run it with nginx, it returns just string $city_mm (exactly this string, not the content of the variable of that name), while $city_mm is defined at that time!
I can't see issues concerning this so just wanted to ask if I have a way to do that, maybe in different way?
So so summarize the solution from #alexander's external link, Nginx does not (currently) support dynamic defaults for geo maps, so you have to use the default feature of the regular map instead.
geo $city_geo {
ranges;
include geo/city.txt;
}
geo $city_mm {
ranges;
include geo/mm_city.txt;
}
map $city_geo $city {
"" $city_mm;
default $city_geo;
}
I have several instances of state where I need to support actions that duplicate some slice of state. For example, my product is a survey builder, so when I duplicate a question, I'd also like to duplicate its answers, rather than have multiple questions pointing to the same answer instances.
The state is normalized:
questionsById: {
q01: {
...
answers: ["a01"],
...
}
}
answersById: {
a01: {...}
}
When dispatching an action of QUESTION_DUPLICATE, I'd like to also duplicate any answers. Currently my QUESTION_DUPLICATE action creator also creates a mapped list of new answer keys, and then the answer reducer consumes this.
This pattern seems unwieldy to me, especially when considering the possibility of deeper duplications (for example, duplicating a Page, which contains Questions, which contain Answers...). Is there a better pattern for deeply duplicating normalized data?
The answer may revolve around how you normally handle normalizing and denormalizing your data. For example, in my blog post Practical Redux, Part 8: Form Draft Data Management, I reuse my existing normalization logic (which leverages the redux-orm library) to copy an item to be edited between the "current" and "draft" slices in my state. So, similarly, one approach would be to denormalize the question you want to duplicate, and then re-normalize it (in either the action creator or the reducer, as you see fit).
I settled on using normalizr & I came up with a recursive duplicator function. It accepts an entity, schema, and keygen function, & recursively updates any nested entities based on the schemata by giving them new ids. In the base case (when there are no further nested entities) it will return the basic thing with its key updated.
const duplicator = (entity, schema, keygen) => {
const newEntity = {
...entity,
[schema._idAttribute]: keygen(entity, schema)
};
if (Object.keys(schema.schema).length === 0) {
return newEntity;
}
return Object.keys(schema.schema).reduce(
(acc, nestedKey) => {
if (!entity.hasOwnProperty(nestedKey)) {
return acc;
}
if (!Array.isArray(schema.schema[nestedKey])) {
return {
...acc,
[nestedKey]: duplicator(
entity[nestedKey],
schema.schema[nestedKey],
keygen
)
};
}
return {
...acc,
[nestedKey]: acc[nestedKey].map((nestedEntity, index) =>
duplicator(nestedEntity, schema.schema[nestedKey][0], keygen)
)
};
},
{ ...newEntity }
);
};
export default duplicator;
This currently doesn't support the schema.Array setup of normalizr for multiple entity types in an array. I'm not currently using schema.Array and this case would be pretty non-trivial to support, but I'll consider it in the future.
I'm trying to get my head around the way meteor work.
I'm building a site prototype and I'd like to pre-populate it with data like site.title, site.logo, site.contact.number etc...
I've created a Settings collection:
Settings = new Meteor.Collection('settings');
Settings.insert(
{
logo: 'test logo',
contact: {
human: '01 01 01 01 01',
machine: '0101010101'
}
}
)
is it possible in the html markup to then retrieve this data across templates, as Meteor is subscribed to the collection?
I'm trying to do things like:
{{settings.logo}}
<a href="{{settings.contact.machine}}" class="logo url" rel="me" {{settings.contact.human}}</a>
Meteor is running on auto publish at the moment so I'm not sure if I need to do something in my main.js file. Can Meteor access all values automatically? at the moment it prints [object,object]
update
I've created a settings.json file:
{
"public" : {
"logo" : "my fancy company name",
"contact" : {
"human" : "01 01 01 01 01 ",
"machine" : "0044101010101"
}
}
}
Then I changed my Handlebars.registerHelper to
Handlebars.registerHelper('view', function(){
return Meteor.settings.public
});
I can now access all of the settings without creating a Collection for them, much more easily.
cheers
Your approach is wrong on several levels.
The handlebar expression {{settings.contact.machine}} will insert *currentContextObject*.settings.contact.machine into the HTML, where *currentContextObject* is the template's data context.
What is your template's data context? I don't know but it doesn't matter because settings.contact.machine won't make sense either way. Settings is a collection of documents but you are trying to use it as if it were a single object.
What would work in JS is Settings.findOne().contact.machine. To access this setting across templates you would need to create a global template helper like e.g.:
if (Meteor.isClient) {
Handlebars.registerHelper("getMachineContact", function() {
return Settings.findOne().contact.machine;
});
}
Then you could use {{getMachineContact}} in your HTML.
Still this solution wouldn't be nice and you should probably be using Meteor.settings instead of a Settings collection for solving your use case.
Similar to here you could then create a global template helper that returns arbitrary values from Meteor.settings given their path, meaning you could for example write {{getSetting "contact.machine"}}. This approach would involve converting a string in dot notation ("contact.machine") into an object reference so this question might be useful.
Say I have two view models that each have an observable property that represents different, but similar data.
function site1Model(username) {
this.username = ko.observable(username);
....
}
function site2Model(username) = {
this.username = ko.observable(username);
....
}
These view models are independent and not necessarily linked to each other, but in some cases, a third view model creates a link between them.
function site3Model(username) = {
this.site1 = new site1Model(username);
this.site2 = new site2Model(username);
// we now need to ensure that the usernames are kept the same between site1/2
...
}
Here are some options that I've come up with.
Use a computed observable that reads one and writes to both:
site3Model.username = ko.computed({
read: function() {
return this.site1.username(); // assume they are always the same
},
write: function(value) {
this.site1.username(value);
this.site2.username(value);
},
owner: site3Model
}
This will keep the values in sync as long as changes always come through the computed. But if an underlying observable is changed directly, it won't do so.
Use the subscribe method to update each from the other:
site3Model.site1.username.subscribe(function(value) {
this.site2.username(value);
}, site3Model);
site3Model.site2.username.subscribe(function(value) {
this.site1.username(value);
}, site3Model);
This works as long as the observables suppress notifications when the values are the same; otherwise you'd end up with an infinite loop. You could also do the check earlier: if (this.site1.username() !== value) this.site1.username(value); This also has a problem that the observables have to be simple (it won't work right if site1 and site2 themselves are observables).
Use computed to do the subscribe and updates:
site3Model.username1Updater = ko.computed(function() {
this.site1.username(this.site2.username());
}, site3Model);
site3Model.username2Updater = ko.computed(function() {
this.site2.username(this.site1.username());
}, site3Model);
This format allows us to have other dependencies. For example, we could make site1 and site2 observables and then use this.site1().username(this.site2().username()); This method also requires a check for equality to avoid an infinite loop. If we can't depend on the observable to do it, we could check within the computed, but would add another dependency on the observable we're updating (until something like observable.peek is available).
This method also has the downside of running the update code once initially to set up the dependencies (since that's how computed works).
Since I feel that all of these methods have a downside, is there another way to do this that would be simple (less than 10 lines of code), efficient (not run unnecessary code or updates), and flexible (handle multiple levels of observables)?
It is not exactly 10 lines of code (although you could strip it down to your liking), but I use pub/sub messages between view models for this situation.
Here is a small library that I wrote for it: https://github.com/rniemeyer/knockout-postbox
The basic idea is just to create a ko.subscribable and use topic-based subscriptions. The library extends subscribables to add subscribeTo, publishOn and syncWith (both publish and subscribe on a topic). These methods will set up the proper subscriptions for an observable to automatically participate in this messaging and stay synchronized with the topic.
Now your view models do not need to have direct references to each other and can communicate through the pubsub system. You can refactor your view models without breaking anything.
Like I said you could strip it down to less than 10 lines of code. The library just adds some extras like being able to unsubscribe, being able to have control over when publishing actually happens (equalityComparer), and you can specify a transform to run on incoming values.
Feel free to post any feedback.
Here is a basic sample: http://jsfiddle.net/rniemeyer/mg3hj/
Ryan and John, Thank you both for your answers. Unfortunately, I really don't want to introduce a global naming system that the pub/sub systems require.
Ryan, I agree that the subscribe method is probably the best. I've put together a set of functions to handle the subscription. I'm not using an extension because I also want to handle the case where the observables themselves might be dynamic. These functions accept either observables or functions that return observables. If the source observable is dynamic, I wrap the accessor function call in a computed observable to have a fixed observable to subscribe to.
function subscribeObservables(source, target, dontSetInitially) {
var sourceObservable = ko.isObservable(source)
? source
: ko.computed(function(){ return source()(); }),
isTargetObservable = ko.isObservable(target),
callback = function(value) {
var targetObservable = isTargetObservable ? target : target();
if (targetObservable() !== value)
targetObservable(value);
};
if (!dontSetInitially)
callback(sourceObservable());
return sourceObservable.subscribe(callback);
}
function syncObservables(primary, secondary) {
subscribeObservables(primary, secondary);
subscribeObservables(secondary, primary, true);
}
This is about 20 lines, so maybe my target of less than 10 lines was a bit unreasonable. :-)
I modified Ryan's postbox example to demonstrate the above functions: http://jsfiddle.net/mbest/vcLFt/
Another option is to create an isolated datacontext that maintains the models of observables. the viewmodels all look to the datacontext for their data and refer to the same objects, so when one updates, they all do. The VM's dependency is on the datacontext, but not on other VMs. I've been doing this lately and it has worked well. Although, it is much more complex than using pub/sub.
If you want simple pub/sub, you can use Ryan Niemyer's library that he mentioned or use amplify.js which has pub/sub messaging (basically a messenger or event aggregator) built in. Both are lightweight and decoupled.
In case anyone needed.
Another option is to create a reference object/observable.
This also handle object that contains multiple observable.
(function(){
var subscriptions = [];
ko.helper = {
syncObject: function (topic, obj) {
if(subscriptions[topic]){
return subscriptions[topic];
} else {
return subscriptions[topic] = obj;
}
}
};
})();
In your view models.
function site1Model(username) {
this.username = syncObject('username', ko.observable());
this.username(username);
....
}
function site2Model(username) = {
this.username = syncObject('username', ko.observable());
this.username(username);
....
}