|
extras
C++ Functions and Classes that make writing mex functions easier
|
group of thread-safe mxArray pointers useful for capturing all of the arguments passed to a mex function and storing them in a list or queue More...
#include <mxArrayGroup.hpp>
Public Types | |
| typedef std::vector< mxArray * >::iterator | iterator |
| typedef std::vector< mxArray * >::const_iterator | const_iterator |
Public Member Functions | |
| mxArrayGroup () | |
| default constructor | |
| mxArrayGroup (size_t n) | |
| construct with certain size array pointers will be nullptr | |
| mxArrayGroup (size_t n, mxArray **pArrays) | |
| construct by taking ownership of array of mxarray* after calling the arrays in pArrays will be managed by the arraygroup do not delete the pArrays after calling | |
| mxArrayGroup (size_t n, const mxArray *prhs[]) | |
| construct by making copy of array of const mxarray* | |
| mxArrayGroup (const mxArrayGroup &src) | |
| Copy Construction. | |
| mxArrayGroup & | operator= (const mxArrayGroup &src) |
| copy assignment | |
| mxArrayGroup (mxArrayGroup &&src) | |
| move Construction | |
| mxArrayGroup & | operator= (mxArrayGroup &&src) |
| move assignment | |
| void | copyTo (size_t nlhs, mxArray **plhs) |
| Copy arrays to destination array or mxarray* the copied arrays will not be managed by the mxarraygroup so it is YOUR job to delete them when you're done if nlhs > size() then the extra mxArray* will be nullptr Resulting mxarray* will not be persistent. | |
| void | moveFrom (size_t nrhs, mxArray **prhs) |
| Take ownership of array of mxarray* after calling, the arrays will be managed by mxArraygroup. | |
| void | copyFrom (size_t nrhs, const mxArray *prhs[]) |
| Create a copy of the arrays. | |
| void | move_back (mxArray *pA) |
| push (non-const) mxArray* to back will take ownership of array; | |
| void | push_back (const mxArray *pA) |
| push const mxArray* to back makes copy of array | |
| void | resize (size_t n) |
| void | clear () |
| const mxArray * | getBack () const |
| size_t | size () const |
| return number of contained arrays | |
| mxArray * | operator[] (size_t n) |
| get array at index n does not release array from mxarraygroup control so DO NOT DELETE, also ptr will not live past the mxarraygroup | |
| const mxArray * | operator[] (size_t n) const |
| get const mxarray* at index n | |
| mxArray * | getArray (size_t n) |
| get array at index n does not release array from mxarraygroup control so DO NOT DELETE, also ptr will not live past the mxarraygroup | |
| const mxArray * | getConstArray (size_t n) const |
| get array at index n does not release array from mxarraygroup control | |
| void | setArray (size_t i, const mxArray *psrc) |
| copy mxArray* to index i | |
| void | ownArray (size_t i, mxArray *psrc) |
| move mxArray* to index i | |
| operator const mxArray ** () const | |
| get array of const mxArray* | |
| iterator | begin () |
| iterator | end () |
| const_iterator | begin () const |
| const_iterator | end () const |
group of thread-safe mxArray pointers useful for capturing all of the arguments passed to a mex function and storing them in a list or queue


ethan.ws
Ethan's super sick website
My topest top secrets
Filler Game (WIP)
APUSH Helper
Tanks Game for APUSH
Cylinder Game (Ideal Game)
This page's source
A canvas is supposed to go here


Reports
System.gc()
or
Runtime.gc()
calls. While occasionally useful in testing, explicitly triggering garbage collection via
System.gc()
is almost never recommended in production code and can result in serious performance issues.


Created by Landon Noss / @landongn
We work on PlayStation Now.
We're Hiring Ember Developers!
Introduce yourself to Reine and Rhea!
I work in the User Experience department
Our team built PlayStation Now for PS4 using Ember 1.x
Prototype to release was about 8 months
Learning the framework was easy
Learning how to work with the framework was hard
We had big problems with a mouseless environment
Relied heavily on the concept of a harness of services
Services became the backbone of our business logic
Drastic complexity reduction
Pub/Sub -> Delegation
Pub/Sub Cont. -> Observers and Computed Properties
State Management -> Route and View Lifecycles
Globals -> Services
PS Now is 3 Views
2 of those, are nested in the first.
75% of our codebase is services
the rest is components, hbs, and light controllers
Hollywood Principle: "Don't call us, We'll call you."
"A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points."
- Martin Fowler
Build your app around the lifecycle
Extend Ember with your own, bespoke, lifecycles
If it's not in the lifecycle, put it in a service instead.
Utilize attribute bindings and class bindings
Utilize didInsert and willInsert appropriately
didInsertElement() {
Ember.run.scheduleOnce('afterRender', () => {
// do stuff now
//
})
}
Doing too much in didInsert can thrash glimmer so wrap if you have to do things on insert!
Ember.Component.extend({
willInsertElement: function () {
// services injected, prior to insertion in the dom
// parse data, load animations pre-flight, whatever.
}
});
willInsertElement isn't used enough.
query services, pre-set animation states
synchronous and blocking, so be smart
import shoppingCart from 'app/components/cart/component';
Ember.Component.extend({
willInsertElement: function () {
this.nearestOfType(shoppingCart).sendAction('name', args...);
}
});
nearestOfType will return the nearest ancestor of the given class definition.
this is recursive, so ANY ancestor at a given level in the data will get returned if parallel.
Ember.Component.extend({
propName: true,
actions: {
name: function () {
// etc..
}
}
});
Ember.Component.extend({
willInsertElement: function () {
this.nearestWithProperty('propName').sendAction('name', args...);
}
});
nearestOfProperty() is interesting because it allows you to delegate-by-contract
Building a reusable thing? implement a yield based component that just has actions for handling the data of it's children!
{{#cart-delegate}}
{{#shopping-cart}}
{{/shopping-cart}}
{{coupon-redemption}}
{{discounts-applied}}
{{/cart-delegate}}
This pattern can be helpful when coordinating multiple components from a single parent.
Here's another option:
{{#cart-delegate cart as |cart| }}
{{#shopping-cart cart=cart}}
{{/shopping-cart}}
{{coupon-redemption cart=cart}}
{{discounts-applied cart=cart}}
{{/cart-delegate}}
Which approach is better?
Ember.Service.extend({
products: Ember.A(),
init: function () {
this.set('products', await someAPICall());
},
onSale: Ember.computed('products.[]', function () {
return this.get('products').filterBy('sale', true);
})
});
Ember.Component.extend({
products: Ember.inject.service(),
onSale: Ember.computed.alias('products.onSale')
});
// hbs
{{#each onSale as |product| }}
{{sale-product product=product}}
{{/each}}
var ToDoList = Ember.Object.extend({
isDone: Ember.computed.empty('todos')
});
var todoList = ToDoList.create({
todos: ['Unit Test', 'Documentation', 'Release']
});
todoList.get('isDone'); // false
todoList.get('todos').clear();
todoList.get('isDone'); // true
var Hamster = Ember.Object.extend({
remainingChores: Ember.computed.filter('chores', function(chore, index, array) {
return !chore.done;
})
});
var hamster = Hamster.create({
chores: [
{ name: 'cook', done: true },
{ name: 'clean', done: true },
{ name: 'write more unit tests', done: false }
]
});
hamster.get('remainingChores'); // [{name: 'write more unit tests', done: false}]
isolate extensions and behaviors of the framework
animation is a good example
springs are a solver loop (in rAF), and a factory method
creating a component could have it's own spring
consumers can override any defaults
use lifecycle methods to trigger and animate
Ember.Component.extend(Springable, {
willInsertElement: function () {
this.spring.createSpring(
this.springConfig.tension,
this.springConfig.friction
);
},
click: function (e) {
this.spring.setEndValue(e.clientOffsetX);
},
onSpringUpdate: function (spring) {
this.element.style.transform = 'translate3d(' + spring.currentValue() + 'px, 0, 0)';
}
});
Ember.Route.extend(Transitionable, {
transitionIn: function (done) {
done();
},
transitionOutTo: function (done) {
}
});