Kunal Mahajan: Dev BootCamp
"The tale of my journey on becoming a Junior Web Developer..."
DBC-Cultural Blog:
Date: 08.14.15
Entry #: 5
Commentary:
I wanted to talk about something called 'Stereotype Threat'. The gist of what stereotype threat is, "Stereotype threat refers to being at risk of confirming, as self-characteristic, a negative stereotype about one's group." (Steele & Aronson, 1995). The long-term effect of one who accepts these threats is educational and social inequality. These threats pose danger especially when one is relatively new to circumstances -whether a new job or a new social environment like school where one tries their best to 'fit in'. During these times, one can be made most vulnerable and as such will oft be willing to let go of stereotypes in order to fit into their niche's. The dangers of conforming to these stereotypes are obviously negative and pressure to avoid threats by cutting them off at the bud are tricky situations to overcome.
The best way to avoid these tricky situations is to be honest with yourself and present your self-goals during times of wanting to fit in. Being open and honest with yourself with your goals presents a much stronger argument than wanting to fit in socially. For instance, a social injustice -stereotypically, is found that women aren't as good in Maths as their male counterparts. Well, if you're a female and want to pursue Maths, succombing to the notion that you're not 'supposed' to be in the field will not only demotivate you, but also harm you in the long-run with the possibility of male counterparts being able to walk over you and you not being able to stand up for yourself. Knowing what you want, knowing who you are, and knowing what's important will help overcome threats that will likely bombard you...simply because of your gender/race/or skin color. Make sure you arm yourself with knowledge, as it will pull you out of the darkest of holes!


Removing a Deleted a User Account
How to remove a "soft" deleted user account using the User Accounts module. This removes all information related to this account from your site's database.
- Navigate to Admin > User Accounts - OR - Go to a User Accounts module.
- Find the user to be deleted using a filter or by searching.
- Click the Remove button beside their record.
- Click the OK button to confirm.


The animation-iteration-count property specifies the number of times an animation should be played.The animation-play-state property specifies whether the animation is running or paused. Note: Use this property in a JavaScript to pause an animation in the middle of a cycle.
Excercise: change the elements play state.
Solution: Solution code


vignettes/troubleshooting-lines-between-polygons.Rmd
troubleshooting-lines-between-polygons.Rmd
When using geom_polygon
, you might get lines between the polygons. These artifacts don’t happen all the time and seem to occur more often between shapes of the same color and on macOS. This vignette walks through different attempts to resolve them.
This section sets up the data set and output image.
tiles <- return_rhombus(0, 0, -90 + 36, 100, 'T') %>%
substitution() %>%
substitution() %>%
substitution() %>%
substitution() %>%
substitution() %>%
substitution() %>%
substitution() %>%
pivot_down()
ggplot(tiles) +
geom_polygon(aes(x = x,
y = y,
fill = shape,
group = triangle)) +
coord_equal()
Saving this image as a png file and then zooming in shows the following image. We can see the lines between polygons.
The following code snippets attempt to solve this issue. They only show the zoomed-in output. So, the code won’t match the image but does start the process.
color
to aesthetic mapping.
ggplot(tiles) +
geom_polygon(aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle)) +
coord_equal()
Unfortunately, the corners won’t match based on the order shapes are drawn.
color = NA
ggplot(tiles) +
geom_polygon(aes(x = x,
y = y,
fill = shape,
group = triangle),
color = NA) +
coord_equal()
Again, the lines still show.
lwd
ggplot(tiles) +
geom_polygon(aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle),
lwd = .5) +
coord_equal()
If lwd
is too large, the output looks messy. If lwd
is too small, the lines show. Unfortunately, there isn’t always an in-between option that fits.
ggplot(tiles) +
geom_polygon(aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle)) +
geom_polygon(aes(x = x,
y = y,
fill = shape,
group = triangle),
color = NA) +
coord_equal()
This option works sometimes and looks fine in this case.
The following output changed from png to jpeg.
ggplot(tiles) +
geom_polygon(aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle)) +
geom_polygon(aes(x = x,
y = y,
fill = shape,
group = triangle),
color = NA) +
coord_equal()
No lines, but there’s also a loss in resolution.
ggplot() +
geom_polygon(data = tiles[tiles$shape == 'T', ],
aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle)) +
geom_polygon(data = tiles[tiles$shape == 't', ],
aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle)) +
coord_equal()
Since this draws all of one shape on top, they display a little chunky. However, it could work if you have few colors and like that style.
The following code increases the polygons’ sizes in new variables, graphs the new larger shapes to cover up the lines, then places the original polygons on top to clean up the corners.
tiles_background <- tiles %>%
group_by(triangle) %>%
mutate(center_x = mean(x),
center_y = mean(y)) %>%
mutate(new_x = (x - center_x) + sign(x) * .075 + center_x,
new_y = (y - center_y) + sign(y) * .075 + center_y)
ggplot(data = tiles_background) +
geom_polygon(aes(x = new_x,
y = new_y,
fill = shape,
group = triangle)) +
geom_polygon(aes(x = x,
y = y,
fill = shape,
group = triangle)) +
coord_equal()
This one works out sometimes, but you’ll have to play around with the size increase.
ragg
packageThis code saves the image using the ragg
package with setting up background shapes.
library(ragg)
agg_png(filename = here::here("third_example", "img.png"),
width = 1500, height = 1500)
ggplot(data = tiles) +
geom_polygon(aes(x = x,
y = y,
color = shape,
fill = shape,
group = triangle)) +
geom_polygon(aes(x = x,
y = y,
fill = shape,
group = triangle),
color = NA) +
coord_equal()
invisible(dev.off())
This one tends to look great.


src/app/interfaces.ts
Standard Error object with a status property
Properties |
| message |
message:
|
Type : string
|
| name |
name:
|
Type : string
|
| stack |
stack:
|
Type : string
|
| Optional |
| status |
status:
|
Type : string
|
import { FormGroup } from '@angular/forms';
import { OptionModel } from './classes';
/**
* Interface for an option used for a tool's discovery mode.
* Displayed on the options page for the tool.
*/
export interface DiscoverOption {
/** The title of the option */
title: string;
/** The description to display to the user for the option */
description: string;
/** The key used to identify the option in the form */
key: string;
/** The input type. Available types are "text", "dropdown", and "multiselect." */
type: string;
/** The available choices for the option (not applicable to "text" type) */
choices?: object[];
/** The default text for "text" type options */
defaultText?: string;
/** Whether or not it is a required option on the form */
required: boolean;
}
/**
* Interface for an option used for a tool's fix mode.
* Displayed on each issue discovered by the tool.
*/
export interface FixOption {
/** The title for the option */
title: string;
/** The description to display to the user */
description: string;
/** The key used to identify the option in the form */
key: string;
/** The input type. Available types are "text", "dropdown", and "multiselect." */
type: string;
/** The available choices for the option (not applicable to "text" type) */
choices?: object[];
/** Default text for "text" type options */
defaultText?: string;
/** Whether or not the option is required in the form */
required: boolean;
}
/**
* Interface for a tab to be generated on the HTML editor
*/
export interface EditorTab {
/** The title of the tab */
title: string;
/** The key to use to grab the html string off the issue */
htmlKey: string;
/** Determines if the user can edit the code */
readOnly: boolean;
}
/**
* Interface for a tool available from the server.
*/
export interface Tool {
/** The ID used to identify the tool */
id: string;
/** The title of the tool (displayed to the user) */
title: string;
/** Description of the tool's uses */
description: string;
/** The tool's type - Determines some of the actions available to the user */
toolType: string;
/** MCIcon used to represent the tool in the {@link ToolSelectionComponent} */
icon: string;
/** Categories this tool will affect in Canvas (Pages, Discussions, Quizzes, etc.)*/
categories: string[];
/** The category this tool belongs to and will display in through the {@link CategoriesComponent} */
toolCategory: string;
/** {@link DiscoverOption}s for this tool, used to generate the options page */
discoverOptions: DiscoverOption[];
/** {@link FixOption}s for this tool, used to generate the options on each {@link IssueContainerComponent} */
fixOptions?: FixOption[];
/** The message to display at the bottom of each {@link IssueContainerComponent} when the issue has been fixed */
fixMessage?: string;
/** The tabs to go into the HTML editor on the issue, if needed */
editorTabs?: EditorTab[];
}
/**
* Interface for a category. Tools are categorized based
* on their purpose. Each category is displayed on the
* home page.
*/
export interface Category {
/** The MDIcon used to represent the category in the {@link CategoriesComponent} */
icon: string;
/** The title of the category */
title: string;
/** The string used by tools to identify the category they belong to */
toolCategory: string;
}
/** Represents a single issue in an {@link IssueItem}. */
export interface Issue {
/** The title of the issue */
title: string;
/** The status of the issue (untouched, approved, skipped, fixed, failed) */
status: string;
/** The HTML string used to display the contents of the issue in its {@link IssueContainerComponent} */
display: string;
/** An object containing issue-specific details */
details: object;
/** If included, this is the HTML for the issue */
html: object;
/** The {@link OptionModel} used to generated any {@link FixOption}s used by the tool */
optionModel?: OptionModel;
/** The {@link FormGroup} generated for the issue's {@link FixOption}s */
formGroup?: FormGroup;
/** The results of form generated by the above {@link OptionModel} */
optionValues?: any;
/** Used to store the current state of the form to restore it on page reload */
tempValues?: any;
}
/** Represents an item in Canvas, such as a page or quiz. */
export interface IssueItem {
/** The title of the item in Canvas */
title: string;
/** The course ID the item belongs to in Canvas */
course_id: number;
/** The content ID of the item in Canvas */
item_id: number;
/** The API path to the item in Canvas */
item_path: string;
/** The category the item belongs to (pages, quizzes, moduleItems, etc.) */
category: string;
/** Link to view the item in Canvas */
link: string;
/** {@link Issue}s discovered by a tool within this item */
issues: Issue[];
}
/** Represents a single course */
export interface Course {
/** The course's ID in Canvas */
id: number;
/** The name of the course in Canvas */
course_name: string;
/** The code for the course in Canvas */
course_code: string;
/** The platform it belongs to (online, campus, pathway) */
platform: string;
/** The current instructor for the course */
instructor: string;
/** The {@link IssueItem}s for this course */
issueItems: IssueItem[];
/** URL to the course in Canvas */
url: string;
/** The sub-account the course is under in Canvas */
account?: string;
/** The term the course is set to in Canvas */
term?: string;
/** Whether or not the course is a Blueprint course */
blueprint?: boolean;
/** Whether the course is currently be processed through a tool */
processing?: boolean;
/** If an error is returned by a tool, it is attached to the course here */
error?: string;
}
/** Standard Error object with a status property */
export interface Error {
name: string;
message: string;
stack?: string;
status: string;
}


Coding Strategies
Objective
In this chapter, you will examine techniques for writing large JavaScript applications within the Titanium environment. You'll look also at some coding strategies that will help you organize your code, reduce repetition, and ease development and maintenance.
Contents
For many programmers, their first Titanium app is also their first experience with a large JavaScript project. While most have experience with browser-based Javascript for adding client side interactivity, few have built entire applications using it. As you grow as a Titanium developer, you will find that a bevy of globally scoped functions and variables will quickly become unmanageable.
Let's take a look at the coding principles and application structures to which you should adhere to create high quality Titanium apps. you should follow. In addition, we'll take a brief look at some community-supplied frameworks that are available to improve the structure and scalability of your Titanium projects.
Coding principles
When writing JavaScript for your Titanium apps, you should strive to achieve these programming principles:
-
Protect the global scope
-
Keep your code DRY
-
Use a single execution context
Global scope
JavaScript has a limited notion of scope, with variables too often being dumped into one global context. In fact, the only scope besides global that JavaScript supports is functional scope. This means that the scope of your variables and functions can be contained within other functions. For example, here's a simple case where functional scope is used to keep temporary variables from polluting the global scope. We make use of an immediate function to execute our code:
var sum = (function() {
var tmpValue = 0;
for (var i = 0; i < 100; i++) {
tmpValue += i;
}
return tmpValue;
})();
Now we have the computed value in our sum variable, and the tmpValue and i variables are no longer part of the scope as they were contained within the functional scope of our immediate function.
In addition to its concept of scope, JavaScript is also quite flexible in that it is loosely typed. This means that you can repurpose objects, including variables and functions, at any time in your code via assignment. But as I'm sure you've heard before, with great power comes great responsibility. If we are not careful with the management of our code, the power of Javascript's expressive code can cause just as many problems as it solves.
We touched on protecting the global scope in the JavaScript Development Primer chapter. As we stated there, a much better approach than global variables/functions is to enclose all your application's API functions and properties into a single variable (namespace). This will minimize the chances of your code colliding with other code or libraries.
To refresh your memory on creating namespaces to protect the global scope, here's the example we gave back in the Primer chapter:
// Define a single namespace to hold all your variables, it's the only global variable
var myapp = {};
myapp.key = 'value';
/* Or, define the namespace and a few variables all at once with
var myapp = {
key: 'value',
foo: 'bar',
charlie: 'horse'
};
*/
// add a function to your namespace
myapp.dosomething = function(foo) {
// do something
};
// extend and encapsulate by using self-calling functions
(function() {
function helper() {
// this is a private function not directly accessible from the global scope
}
myapp.info = function(msg) {
// added to the app's namespace, so a public function
helper(msg);
Ti.API.info(msg)
};
})();
// you could then call your function with
myapp.info('Hello World');
Stay DRY
By DRY, we mean "don't repeat yourself." The less you repeat code, the easier it is to write, maintain, and fix that code. There are many techniques that will help you keep your code DRY. Among these are creating factory methods for instantiating program components, capitalizing on JavaScript's inheritance model, and creating libraries of reusable modules.
Execution contexts
If you've ever created web pages, you know that JavaScript variables on one page have no access to the JavaScript variables on another. You have to take special steps – setting and getting POST or GET parameters, using cookies, or some similar measure – to get data from one page to another. Each page has its own global variable, which is cut off from that of any other page. We say each page runs in its own "execution context."
By default, a Titanium Mobile application has a single execution context in which it runs. Your application's app.js file bootstraps your application and serves as the root context. Your application can have multiple execution contexts (but as we'll show, you generally don't want it to). New execution contexts are typically created by opening a new window that points to an external URL in its url property:
Ti.UI.createWindow({
url:'window.js'
}).open();
When the window is opened, the script window.js is immediately run in a new execution context. If the preceding code were run in app.js, any variables or function declarations made in app.js would be unavailable within window.js. Try it:
-
Create a new Titanium Mobile project.
-
In app.js, cut the following text and paste it into a new file named win1.js:
var label1 = Titanium.UI.createLabel({ color:'#999', text:'I am Window 1', font:{fontSize:20,fontFamily:'Helvetica Neue'}, textAlign:'center', width:'auto' }); win1.add(label1);
-
Then, update the code that defines win1, like this:
var win1 = Titanium.UI.createWindow({ title:'Tab 1', backgroundColor:'#fff', url:'win1.js' });
-
Build your project for the simulator/emulator. You'll receive an error that win1 is undefined in the win1.js file. The win1 variable is defined in app.js, which is a separate context. Let's fix that.
-
In win1.js, add this statement at the top:
var win1 = Ti.UI.currentWindow;
-
Build your project for the simulator/emulator and this time it will run without errors. To pass data into a separate context, you can add custom properties to your window object.
-
In app.js, update the code to read:
var win1 = Titanium.UI.createWindow({ title:'Tab 1', backgroundColor:'#fff', url:'win1.js', mylabel:'Hello from app.js' });
-
Then, in win1.js, update the code to read:
var label1 = Titanium.UI.createLabel({ color:'#999', text:win1.mylabel, font:{fontSize:20,fontFamily:'Helvetica Neue'}, textAlign:'center', width:'auto' });
-
Build your project for the simulator/emulator. The custom window property you set in app.js is available within the win1.js context and is used as the label's text.
It is possible to communicate across execution contexts using application-level events. Using Titanium's custom event API, arbitrary JavaScript data structures can be sent and received in different execution contexts. Note that the 'payload' of your event must be JSON serializable, so business objects will not preserve any instance methods associated with them. The APIs used to fire and receive events are in the Ti.App namespace.
Let's modify the project you just used to demonstrate multiple contexts.
-
In win1.js, add this code:
label1.addEventListener('click', function() { Ti.App.fireEvent('app:labelclicked', {newlabel:'Sent from win1.js'}); });
-
Back in app.js, scroll down to find the label2 code. This code is in the app.js context, walled off from the win1.js context. We'll add an event listener here to update the text of label2 when label1 is clicked. Add this code after label2:
Ti.App.addEventListner('app:labelclicked', function(e) { label2.text = e.newlabel; });
-
Build your project for the simulator/emulator. Switch to tab 2 and click the label. Switch back to tab 1 and the label should now read 'Sent from win1.js'.
Should I use a single context or multiple contexts?
As is often the case in software development, the answer is "that depends". Most of the time, we recommend you use a single execution context for these reasons:
-
You can pass complex objects easily within your app's single context — With events, you can pass JSON-serializable objects, but not objects with methods.
-
You include your libraries/dependencies only once, since there's only one context — With multiple contexts, each file would need to include your libraries/dependencies, increasing memory usage.
-
In most of the projects done by Appcelerator's own Professional Services team on Titanium Mobile, a single execution context with multiple included external files is used. However, there are instances where having multiple execution contexts is useful. For example, in our Kitchen Sink application, it is advantageous to have a 'clean slate' for every API usage example, so we don't have to worry about polluting the global scope and can keep the examples easy.
Creating High Quality Javascript Based Apps
Let's recap: keep your code DRY, don't pollute the global scope, and strive for a single context app. We offer a couple of techniques you can use to meet these goals:
-
Module pattern with self-calling functions
-
CommonJS modules
(These aren't formal design patterns, but important development concepts for Javascript and Titanium developers.)
Module pattern with self-calling functions
A technique we teach in our classroom training sessions involves breaking your app into modular pieces, each constructed using self-calling functions which modify a single app namespace. (If you want to be semantically-correct, these are Immediately Invoked Function Expressions, or IIFEs.)This technique lets you divide code into multiple files, each focused on an discrete purpose. As each library is loaded, it modifies the app's namespace object, which is the only variable added to the global namespace. Let's demonstrate this with code:
// create an object literal to be your app's namespace
var myapp = {};
// include necessary libraries
Ti.include('ui.js', 'other_library.js');
// instantiate and open the main UI component of our app
myapp.mainWindow = myapp.ui.createApplicationWindow();
myapp.mainWindow.open();
The ui.js library file contains the code that constructs your app's user interface.
// create a self-calling function
(function(){
myapp.ui = {}; // this sub-namespace extends the app's namespace object
myapp.ui.createApplicationWindow() {
var win = Ti.UI.createWindow({
backgroundColor:'white'
});
var header = Ti.UI.createLabel({
text: 'My App Heading',
top: 10,
height:'auto',
width:'auto'
});
win.add(header);
return win;
};
})();
You would add other libraries, as necessary, to round out the functionality of your app. For example, you might put all your database code in a db.js file, your network code in a network.js, and so forth. We recommend you keep namespace variable names short: you'll be typing them a lot. Use function names that describe their purpose and return value. Take createApplicationWindow() as an example. It "creates" a "window" and the middle part describes what type of window it's creating. The purpose of the function is clear just by reading its name.
A good example of an app that uses this module pattern with self-calling functions is Tweetanium Mobile. We encourage you to download that and study the way that app is put together. The "finished" code we supply for our classroom labs generally follow this module/self-calling pattern as well.
(As presented here, this is not officially an implementation of the formal modular pattern. But it would not be too difficult to adapt the code presented here to match that design pattern.)
CommonJS modules
CommonJS is a JavaScript API that defines a common way to handle typical application needs. According to the project, it's goal is to provide a library "as rich as those of Python, Ruby and Java" and enable developers to write applications that run across different JavaScript interpreters and host environments. Titanium implements a portion of CommonJS, namely the capability to build modules using require().
Platform Evangelist Kevin Whinnery provides a great overview to creating CommonJS modules in Forging Titanium Episode 1: CommonJS Modules. Let's dive right into code, looking first at how to create our module.
// variables defined in this files are private
var win = Ti.UI.createWindow({
backgroundColor:'white'
});
var header = Ti.UI.createLabel({
text: 'My App Heading',
top: 10,
height:'auto',
width:'auto'
});
win.add(header);
// we make objects, variables, functions available to the
// calling context by adding them to the exports object
exports.win = win;
// we can assign other objects, functions, and variables to
// exports and they will be available to the calling context
exports.updateHeading = function(str) {
header.text = str;
}
Let's see how we would use that module in our app.js file.
var myapp = {}; // the app namespace
// here we'll require() our module
myapp.ui = require('ui'); // don't include the '.js' extension!
// instantiate and open the main UI component of our app
myapp.ui.win.open();
myapp.ui.win.addEventListener('click', function() {
// click the window to update the heading
myapp.ui.updateHeading('A new heading');
});
Kevin's technique, as shown in the video, differs slightly. Instead of returning predefined objects, his code returns an "instantiatable" class. His technique is useful when you need to create copies of a common object (many views, for example) each with custom functionality.
CommonJS is being rapidly and widely adopted by professional JavaScript programmers. It is implemented in high-profile projects like Node.js, NarwhalJS, SproutCore, and more. Much of the code currently being written by our team members follows the CommonJS require() module pattern. You should get comfortable with this pattern, as it will become our recommended coding style in the future.
MVC and other techniques
The techniques we list above might not suit every need, nor satisfy everyone's requirements. Community members have contributed various frameworks and coding techniques. Without endorsing any of them, here's a few of the frameworks you might consider using:
Hands-on Practice
Goal
In this activity, you will create a project in which you first implement the self-calling function pattern. Then, you'll refactor the code to implement the CommonJS module pattern.
Steps
Part A
-
In Studio, create a new project. Delete the default content of app.js.
-
Using the module/self-calling technique outlined above, write an app that:
-
Defines a single, hierarchical namespace such that only one variable is added to the global namespace
-
Opens a window with a red background.
-
Includes a single label with white text, centered at the top of the window. Use the label text of your choice.
-
Includes a method to update the label's text. Use setTimeout() to update the label with new text after a few second delay.
-
If you implement this app in multiple files, add the necessary Ti.include() statement to import them all.
-
-
Build and test your app in the simulator/emulator.
Part B
-
Refactor the code to use the CommonJS require() technique. Your app should still only define a single, hierarchical namespace such that only one variable is added to the global namespace.
-
Build and test your app in the simulator/emulator.
References and Further Reading
Summary
In this chapter, you examined techniques for writing large JavaScript applications within the Titanium environment. You also looked at some coding patterns that can help you organize your code, reduce repetition, and ease development and maintenance. Next we'll look at how we can developer Titanium apps for multiple mobile platforms with a single code base.


Luke Skywalker was a Tatooine farmboy who rose from humble beginnings to become one of the greatest Jedi the galaxy has ever known. Along with his friends Princess Leia and Han Solo, Luke battled the evil Empire, discovered the truth of his parentage, and ended the tyranny of the Sith. A generation later, the location of the famed Jedi master was one of the galaxy’s greatest mysteries.  But his solitude would be interrupted – and Luke Skywalker had one final, momentous role to play in the struggle between good and evil.
Committed to the cause of the Resistance, Finn fights alongside his closest friends in the struggle to defeat the First Order, the evil regime he once served as a stormtrooper. As FN-2187, he was trained from birth to serve the First Order, but a skirmish on Jakku awakened his conscience and drove him down a different path, one that proved both heroic and dangerous.
Han Solo rose from an impoverished childhood on the mean streets of Corellia to become one of the heroes of the Rebel Alliance. As captain of the Millennium Falcon, Han and his co-pilot Chewbacca came to believe in the cause of galactic freedom, joining Luke Skywalker and Princess Leia Organa in the fight against the Empire. After the Battle of Endor, Han faced difficult times in a chaotic galaxy, leading to a shattering confrontation with his estranged son Ben.
A Resistance starfighter ace, Poe Dameron is one of Leia Organa’s most-trusted operatives. He can fly anything – which is fortunate given how often his headstrong nature leads him into trouble. Poe leads the attack that destroys Starkiller Base, but soon finds himself on the run from the First Order. Sidelined without his beloved X-wing, he learns tough lessons about leadership, heroism and sacrifice. Those lessons will prove essential in rebuilding the Resistance before a showdown with the forces of evil at Exegol.
The son of Han Solo and Leia Organa, Ben Solo was seduced by the dark side of the Force and renamed himself Kylo Ren: leader of the Knights of Ren, champion of the First Order, and apprentice to Supreme Leader Snoke.  But he remained haunted by his father’s death, his connection with the mysterious Rey, and the pull of the good in himself. In time, all three would help Ben Solo return to the light.
C-3PO longs for more peaceful times, but his continued service to the Resistance — and his knowledge of more than seven million forms of communication — keeps the worry-prone droid in the frontlines of galactic conflict. Programmed for etiquette and protocol, Threepio was built by a young Anakin Skywalker, and has been a constant companion to astromech R2-D2. Over the years, he was involved in some of the galaxy’s most defining moments and thrilling battles. Since the Empire’s defeat, C-3PO has served Leia Organa, head of a Resistance spy ring aimed at undermining the First Order.
Seemingly abandoned by her parents on Jakku, Rey grew up a scavenger amid the wreckage of war. Her life changed when she agreed to help a droid on an urgent mission for the Resistance. Rey discovered she was powerful in the Force, and sought out the vanished Jedi Master Luke Skywalker to train her. That ended in disappointment, as did her attempt to bring Kylo Ren back to the light. But the resilient Rey continued her training and learned the truth about her parentage and her mysterious connection with Kylo. She then faced her greatest test: a confrontation with fear and evil that would determine the galaxy’s fate.
A legendary Wookiee warrior and Han Solo’s longtime co-pilot, Chewbacca continues to serve as faithful first mate to carry out daring missions against the First Order behind the controls of the Millennium Falcon. Known as Chewie to his closest friends, he was part of a core group of rebels who restored freedom to the galaxy during the reign of the Galactic Empire. Known for his short temper and accuracy with a bowcaster, Chewie also has a big heart and unwavering loyalty to his friends.


Rodrigo
Home
Blog
Games
About Me
Contact
My articles
Learning Plan
Bootcamp Update
Identity and Values
Emotional Intelligence
Neuroplasticity and Growth Mindset
Problem Solving
Foundations Reflection
Relative Units
JavaScript and DOM


Help make Deltacloud better
All development of Deltacloud takes place in the open. Communication is run through the mailing list and all source code changes are tracked publicly.
-
Mailing Lists
For Deltacloud API<EMAIL_ADDRESS>To subscribe to it, send an email to<EMAIL_ADDRESS>You can also view Archive in case you are missing something.
-
IRC
You can also join us on the Freenode IRC channel #deltacloud. Deltacloud developers are generally available on the IRC channel
-
Bugs
We track bugs in Apache JIRA. You can [view open bugs][view-bugs] or file a new one there.
-
Patches
Patches are very welcome. Please send them to the development list. Patches should be generated with
git
format-patch
and sent to the list withgit
send-email
.
Getting the sources
Then Deltacloud Core gives you the API and drivers to various cloud providers. It also provides a client library and a commandline interface.
The Deltacloud Core repository is hosted on Apache Incubator. Apache uses Subversion, but there is a git mirror available:
$ mkdir deltacloud
$ cd deltacloud
$ git clone git://git.apache.org/deltacloud.git core
You can find the Subversion repository at: https://svn.apache.org/repos/asf/incubator/deltacloud.
Required packages
In order to make the Deltacloud components work, you'll need to have the following packages installed (on Fedora 12; the names may vary on your distro):
ruby
ruby-devel
gcc-c++
libxml2-devel
libxslt-devel
Note: these packages are necessary for building all the required ruby gems that Deltacloud requires. If you want to install the gems using your system's package manager (yum, apt, ports, etc.) you won't need to install these packages manually.
Installing the Deltacloud Core
First, you need to install the server that will give you the Deltacloud API:
$ cd path/to/deltacloud/core/server
$ rake package
$ sudo gem install pkg/deltacloud-core-<version>.gem
Then install the client library:
$ cd path/to/deltacloud/core/client
$ rake package
$ sudo gem install pkg/deltacloud-client-<version>.gem
Once you have the client installed, run the following command:
$ cd path/to/deltacloud/core/client
$ rake fixtures


curveto
curveto(h1x, h1y, h2x, h2y, x, y)
The curveto() command must be called between beginpath() and endpath(). Draws a curve between the current point in the path and a new destination point. The last two parameters, x and y, set the location of the new destination point. The first and second, and the third and fourth parameters set the location of the two control points of the curve. These control points, or handles, define the edge and slant of the curve.
|
beginpath(0,0)
curveto(100,100,50,0,100,100)
endpath() |


UniController has menu sections titled Apache Utilities and MySQL Utilities which provide useful features, such as single button access to phpMyAdmin and server documentation. The image on the right shows the available menu options. If a menu button is greyed out, it means that that option is currently unavailable. This can be for a number of reasons, such as that a related server (or servers) is not running or the appropriate plugin has not been installed. Utility option buttons (opt1-opt3)
Parameter btntext allows you to set the button text to display. Parameter page allows you to define a page (and paramters) to run when the button is clicked. Server ConsoleThe Server Console opens a command window with environment variables preset and paths configured for Uniform Server utilities. Apart from cosmetics, it is identical to a standard command window (cmd). Note: Full server console details; see Server Console page View wwwView www is a pre-configured button to display the root folder index page in the default/portable browser. It is equivalent to typing the following into a browsers address bar:
Apache searches for an index page in the following order: index.html index.shtml index.html.var index.htm index.php3 index.php index.pl index.cgi Displays the first index page it finds. If an index page is not found a directory (folder) listing is produced. The list of indexes is defined in the Apache configuration file httpd.conf using directive DirectoryIndex Note: Substitute the domain name (localhost) and port (80) as appropriate for the values configured. View sslView ssl is a pre-configured button to display the root folder index page in the default/portable browser. It is equivalent to typing the following into a browsers address bar:
Apache searches for an index page in the following order: index.html index.shtml index.html.var index.htm index.php3 index.php index.pl index.cgi Displays the first index page it finds. If an index page is not found a directory (folder) listing is produced. Note: Substitute the domain name (localhost) and port (443) as appropriate for the values configured. DocumentationThe Documentation button opens the index.html page from which the pages you are reading can be accessed. It follows the structure of the UniController menus. The top level describes commonly used functionality while sub-menus detail the next level of functionality and provide more detailed information. It is self-contained, requiring no external references. This notwithstanding, there is quite a bit of additional information available at The Uniform Server's Wiki site wiki.uniformserver.com MySQL ConsoleThe MySQL utility is a very popular admin tool; Uniform Server Zero XIII provides a dedicated menu button (MySQL Console) that directly runs this utility in a console window, commonly refered to as the MySQL prompt. From this window the MySQL server can be administered. Note: Full MySQL console details; see MySQL Console page phpMyAdminphpMyAdmin is a MySQL admininstration tool written in PHP. It allows you to perform tasks such as creating, modifying or deleting databases. You can execute SQL statements and manage users and their permissions. The phpMyAdmin menu button opens the phpMyAdmin index page in the default/portable browser.
Note 1: phpMyAdmin access. By default is accessible only to localhost. AdminerAdminer is a MySQL admininstration tool written in PHP. It allows you to perform tasks such as creating, modifying or deleting databases. You can execute SQL statements and manage users and their permissions. The Adminer menu button opens the Adminer index page in the default/portable browser.
Note 1: Adminer access. By default is accessible only to localhost. phpMyBackupProAlthough the above two admininstration tools allow you to export database data as an SQL query, a dedicated MySQL backup tool may be preferable such as phpMyBackupPro. phpMyBackupPro is a MySQL admininstration tool written in PHP. It allows you to quickly perform database backups. You can create scheduled backups, manage and restore them, download or email them. Installation:
The phpMyBackupPro menu button opens the phpMyBackupPro index page in the default/portable browser.
Note 1: phpMyBackupPro access. By default is accessible only to localhost. Sypex Dumper - Alterntive to phpMyBackupProSypex Dumper is an open source web application for creating and restoring MySQL database backups. The application can work with huge (gigabytes) databases. This is acheived by bypassing the PHP timeout limits using a method that pauses and re-starts the backup job. The Uniform Server Zero Sypex Dumper plugin has been configured for automatic login as admin user and is fully portable. Installation:
Note The Sypex Dumper menu button opens the Sypex Dumper index page in the default/portable browser.
|


{% extends "base.html" %} {% load staticfiles %} {% block jumbotron %}
Easy system monitoring
No servers were found in the database.


Home
Art
Gingi's Games
About Us
Contact Us
Congradulations you cracked the code!
Select the game you wish to play
Guess the Bracha
Start
Parsha Questions
Start
Tzdaka Chase
Start


Return to Catherine & Brent
Alden Castle 20 Chapel St Brookline, MA 02446
Saturday June 9, 2018 5pm
TBD


You must grant this site access to your private Bungie API's for the site to access this info on your account (like what you might be doing with Destiny Item Manager today). Click the "Sign In" button on the upper right if you want to continue.
This user hasn't enabled viewing their non-equipped inventory.
They'd need to
check the "Show my non-equipped Inventory" at Bungie.net.
[Hiding non-equipped inventory is the default privacy setting]


| TEP: | 134 |
|---|---|
| Group: | Core Working Group |
| Type: | Documentary |
| Status: | Draft |
| TinyOS-Version: | 2.x |
| Author: | Kevin Klues, Chieh-Jan Liang, Jeongyeup Paek, Razvan Musaloiu-E, Ramesh Govindan, Andreas Terzis, Philip Levis |
| Draft-Created: | 13-May-2008 |
| Draft-Version: | 1.1 |
| Draft-Modified: | 2008-06-12 |
| Draft-Discuss: | TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu> |
Note
This memo documents a part of TinyOS for the TinyOS Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.
This memo documents the TOSThreads thread library for TinyOS
TOSThreads is an attempt to combine the ease of a threaded programming model with the efficiency of a fully event-based OS. Unlike earlier threads packages designed for TinyOS, TOSThreads supports fully-preemptive application level threads, does not require explicit continuation management, and neither violates TinyOS's concurrency model nor limits its concurrency. Additionally, adding support for TOSThreads requires minimal changes to the existing TinyOS code base, and bringing up a new platform to support the use of TOSThreads is a fairly easy process.
In TOSThreads, TinyOS runs inside a single high priority kernel thread, while all application logic is implemented using user-level threads, which execute whenever the TinyOS core becomes idle. This approach is a natural extension to the existing TinyOS concurrency model, adding support for long-running computations while preserving the timing-sensitive nature of TinyOS itself.
In this model, application threads access underlying TinyOS services using a kernel API of blocking system calls. The kernel API defines the set of TinyOS services provided to applications (e.g. time-sync [TEP133], collection [TEP119], and dissemination [TEP118]). Each system call in the API is comprised of a thin blocking wrapper built on top of one of these services. TOSThreads allows systems developers to re-define the kernel API by appropriately selecting (or implementing their own) custom set of blocking system call wrappers.
The following section describes the details of how TOSThreads interacts with TinyOS to provide each of the features described above.
The existing TinyOS concurrency model has two execution contexts: synchronous (tasks) and asynchronous (interrupts). These two contexts follow a strict priority scheme: asynchronous code can preempt synchronous code but not vice-versa. TOSThreads extends this concurrency model to provide a third execution context in the form of user-level application threads. Application threads run at the lowest priority, with the ability to only preempt one another. They are preemptable at any time by either synchronous code or asynchronous code, and synchronize amongst each other using standard synchronization primitives such as mutexes, semaphores, barriers, condition variables, and blocking reference counters (a custom mechanism we have developed ourselves). Take a look in tos/lib/tosthreads/interfaces to see the interfaces providing these primitives.
The basic TOSThreads architecture, consists of five key elements: the TinyOS task scheduler, a single kernel-level TinyOS thread, a thread scheduler, a set of user-level application threads, and a set of system call APIs and their corresponding implementations. Any number of application threads can concurrently exist (barring memory constraints), while a single kernel thread runs the TinyOS task scheduler. The thread scheduler manages concurrency between application threads, while a set of system calls provides them access to the TinyOS kernel.
In order to preserve the timing-sensitive operation of TinyOS, the kernel thread has higher priority than application threads. This TinyOS thread therefore always takes precedence over application threads as long as the TinyOS task queue is non-empty. Once the TinyOS task queue empties, control passes to the thread scheduler and application threads can run. The processer goes to sleep only when either all application threads have run to completion, or when all threads are waiting on synchronization primitives or blocked on I/O operations.
There are two ways in which posted events can cause the TinyOS thread to wake up. First, an application thread can issue a blocking system call into the TinyOS kernel. This call internally posts a task, implicitly waking up the TinyOS thread to process it. Second, an interrupt handler can post a task for deferred computation. Since interrupt handlers have higher priority than the TinyOS thread, the TinyOS thread will not wake up to process the task until after the interrupt handler has completed. Because interrupts can arrive at anytime, it is important to note that waking up the TinyOS thread may require a context switch with an interrupted application thread. Control eventually returns to the application thread after the TinyOS thread has emptied the task queue.
Only two changes to the existing TinyOS code base are required to support TOSThreads: a modification to the boot sequence and the addition of a post-amble for every interrupt handler. Changes to the boot sequence only need to be made once and are independent of any platforms supported by TinyOS. Changes to the interrupt handlers MUST be handled on a microcontroller to microntroller basis. Additionally, a custom chip_thread.h file MUST be created for each microcontroller and place in its top level directory, e.g. tos/chips/msp430
Instead of directly running the TinyOS boot sequence inside of main() as done previously, main() now calls out to a Boot.booted() event associated with booting up the thread scheduler.:
event void ThreadSchedulerBoot.booted() { //Thread sceduler specific init stuff ... ... //Encapsulate TinyOS inside a thread tos_thread = call ThreadInfo.get[TOSTHREAD_TOS_THREAD_ID](); tos_thread->id = TOSTHREAD_TOS_THREAD_ID; //Set the TinyOS thread as the current thread and activate it current_thread = tos_thread; current_thread->state = TOSTHREAD_STATE_ACTIVE; //Signal the boot sequence signal TinyOSBoot.booted(); }
This change is made in order to encapsulate TinyOS inside the single kernel-level thread and set it as the initial thread that starts running. Once this is done, the normal TinyOS boot sequence is ran by signaling the TinyOSBoot.booted() event.
At the bottom of the existing TinyOS boot sequence, we enter an infinite loop that continuously checks the TinyOS task scheduler to see if it has any tasks to run. If it does, it runs the next task in its queue. If it does not, it puts the microcontroller into its lowest possible power state and goes to sleep [TEP112].:
command void Scheduler.taskLoop() { for (;;) { uint8_t nextTask; atomic { while ((nextTask = popTask()) == NO_TASK) call McuSleep.sleep(); } signal TaskBasic.runTask[nextTask](); } }
By adding threads as a lowest priority execution context, we need to change these semantics slightly. Instead of going directly to sleep, we want to allow the thread scheduler to take control of the microcontroller and start scheduling any threads it has to run. Only once all application threads have run to completion, or when all threads are waiting on synchronization primitives or blocked on I/O operations is the microcontroller put to sleep.
We achieve such functionality by replacing the call to McuSleep.sleep() shown above, by a call that signals the thread scheduler to suspend the currently running thread (the TinyOS kernel thread).:
command void TaskScheduler.taskLoop() { for (;;) { uint8_t nextTask; atomic { while((nextTask = popTask()) == NO_TASK) call ThreadScheduler.suspendCurrentThread(); } signal TaskBasic.runTask[nextTask](); } }
Once the TinyOS thread has been suspended, the thread scheduler is free to begin scheduling application level threads however it sees fit.
With the changes described above, the only other non-self-contained TinyOS code necessary to support TOSThreads is the addition of a post-amble at the bottom of every interrupt handler. Since the number and type of interrupt handlers, as well as the semantics required for implementing them, differ from platform to platform, the way in which this post-amble is is added is highly dependent on the microcontroller in use. The post-amble itself, however, is completely platform-independent, and is provided via a postAmble() command included in the PlatformInterrupt interface.:
command void PlatformInterrupt.postAmble() { atomic { if(call ThreadScheduler.wakeupThread(TOSTHREAD_TOS_THREAD_ID) == SUCCESS) if(call ThreadScheduler.currentThreadId() != TOSTHREAD_TOS_THREAD_ID) call ThreadScheduler.interruptCurrentThread(); } }
As described in the following section, the call to wakeupThread() returns SUCCESS iff the TinyOS task queue has any tasks to process (i.e. the interrupt handler posted some tasks), otherwise it returns FAIL. Upon FAIL, we simply return from this function, and continue execution from the point at which the currently running thread was interrupted. Upon SUCCESS, we preempt the current thread, immediately scheduling the TinyOS thread for execution. The check to make sure that the current thread isn't already the TinyOS thread is simply an optimization used to bypass ''rescheduling'' the already running thread.
This postAmble() command MUST be called at the bottom of EVERY interrupt handler provided by a platform. This interface is provided by the PlatformInterruptC component, and MUST be wired into every component which implements an interrupt handler. Calls to postAmble() MUST then be made just before any return points in the given interrupt handler.
Note
Attempts were made to try and simplify / automate the inclusion of the post amble through the use of MACROS and other means. It was determined in the end, however, that this was the simplest and most readable way to keep the implementation of the post-amble platform independent, while allowing it to be included on a platform by platform basis for differing interrrupt handler implementations.
As an example, consider the case of the interrupt handlers for the TIMERA0_VECTOR and ADC_VECTOR on the msp430 microcontroller:
TOSH_SIGNAL(TIMERA0_VECTOR) { //Body of interrupt handler ... ... call PlatformInterrupt.postAmble(); } TOSH_SIGNAL(ADC_VECTOR) { //Body of interrupt handler ... ... call PlatformInterrupt.postAmble(); }
The component in which each of these handlers is defined MUST wire in the PlatformInterrupt interface provided by PlatformInterruptC and call postAmble() at the bottom of their interrupt handlers.
A chip_thread.h MUST be created in the chips directory for each microcontroller supporting the TOSThreads library. This file MUST contain definitions of the following:
(1) A structure containing space for saving any microcontroller specific registers needed to save state when doing a context switch.:
typedef struct thread_regs { ... } thread_regs_t;
(2) A typedef of a stack_ptr_t type. For example, the msp430 microconroller has 16 bit memory addresses, so stack_prt_t is typedefed as follows.:
typedef uint16_t* stack_ptr_t;
(3) Definitions of the following MACROS for use by the TOSThreads thread scheduler.:
PREPARE_THREAD(thread, start_function) SWITCH_CONTEXTS(current_thread, next_thread) RESTORE_TCB(next_thread) STACK_TOP(stack, size)
As explained in Section 4.2, state manipulated by these MACROS is carried around by a thread as part of its Thread Control Block (TCB), defined as type 'thread_t'.
PREPARE_THREAD() takes two parameters: 'thread' and 'start_function'. The 'thread' parameter MUST be of type thread_t, and 'start_function' MUST be of type void (*start_function)(void). The purpose of PREPARE_THREAD() is to get a thread ready for the first time it starts to execute. Primarily, it is used to set the top of the stack associated with 'thread' to its 'start_function'. When it comes time for the thread to begin executing, the address pointed to by 'start_function' will be popped off and it will start executing.
As an example, consider the definition of PREPARE_THREAD() for the msp430 microcontroller:
#define PREPARE_THREAD(t, thread_ptr) \ *((t)->stack_ptr) = (uint16_t)(&(thread_ptr)); \ SAVE_STATUS(t)
In this case, the status register is also saved with its initial setup, but this may not be necessary for all microcontrollers.
SWITCH_CONTEXTS() takes two parameters: current_thread and next_thread. Both parameters MUST be of type 'thread_t'.The purpose of SWITCH_CONTEXTS() is to store the state of the thread associated with the 'current_thread', and swap it out with the state of the 'next_thread'. The amount and type of state saved, and how it is actually swapped out varies from microcontroller to microcontroller.
RESTORE_TCB() takes just one parameter: next_thread. This parameter MUST be of type 'thread_t'. RESTORE_TCB() is similar to SWITCH_CONTEXTS() except that no state is stored about the current thread before swapping in the state associated with 'next_thread'. This MACRO is primarily called at the time a thread is either killed or has run to completion.
STACK_TOP() takes two parameters: 'stack' and 'size'. The 'stack' parameter MUST be of type stack_ptr_t and 'size' MUST be an integer type (i.e. uint8_t, uint16_t, etc). As explained in Section 4.2, whenever a thread is created, it is allocated its own stack space with a given size. As a thread executes, local variables, register values, and the return address of procedure calls are pushed onto this stack. Depending on the microcontroller in use, the top of a thread's stack might exist at either the highest address (stack grows down) or lowest address (stack grows up) of the data structure allocated to the stack. The purpose of STACK_TOP() is to return a pointer of type uint8_t* to the location of the top of the stack. STACK_TOP() is only called once at the time a thread is first initialized.
There are only two choices for the definition of this MACRO, and both are shown below.:
//Stack grows down (i.e. need to return pointer to bottom of structure (highest address)) #define STACK_TOP(stack, size) \ (&(((uint8_t*)stack)[size - sizeof(stack_ptr_t)]))
//Stack grows up (i.e. need to return pointer to top of structure (lowest address)) #define STACK_TOP(stack, size) \ (&(((uint8_t*)stack)[0]))
As an example, consider the msp430 and atmega128 microcontrollers. On both of these microcontrollers, a thread's stack grows down as it executes, so STACK_TOP() is defined using the first macro.
This section describes the implementation of TOSThreads, including the internals of the thread scheduler, the thread and system call data structures, and their corresponding interfaces.
The thread scheduler is the first component to take control of the microcontroller during the boot process. As mentioned previously, its job is to encapsulate TinyOS inside a thread and trigger the normal TinyOS boot sequence. Once TinyOS boots and processes all of its initial tasks, control returns to the thread scheduler which begins scheduling application threads. The scheduler keeps threads ready for processing on a ready queue, while threads blocked on I/O requests or waiting on a lock are kept on different queues.
The default TOSThreads scheduler implements a fully preemptive round-robin scheduling policy with a time slice of 5 msec. We chose this value to achieve low latency across multiple application-level computing tasks. While application threads currently run with the same priority, one can easily modify the scheduler to support other policies.
As explained in the following section, TOSThreads exposes a relatively standard API for creating and manipulating threads: create(), destroy(), pause() and resume(). These functions form part of the system call API, and can be invoked by any application program.
Internally, TOSThreads library components use the following ThreadScheduler interface to interact with a thread.:
interface ThreadScheduler { async command uint8_t currentThreadId(); async command thread_t* currentThreadInfo(); async command thread_t* threadInfo(thread_id_t id); command error_t initThread(thread_id_t id); command error_t startThread(thread_id_t id); command error_t stopThread(thread_id_t id); async command error_t interruptCurrentThread(); async command error_t suspendCurrentThread(); async command error_t wakeupThread(thread_id_t id); }
The thread scheduler itself does not exist in any particular execution context (i.e., it is not a thread and does not have its own stack). Instead, any TOSThreads library component that invokes one of the above commands executes in the context of the calling thread. Due to the sensitive nature of these commands, ONLY the interrupt handler post-ambles and blocking system call API wrappers invoke them directly.
The first three commands are used to get information associated with an instance of a thread. Calling currentThreadId() returns a unique identifier associated with the currently running thread. Calling currentThreadInfo() or threadInfo() on a particular thread returns a pointer to the complete Thread Control Block (TCB) associated with a thread. Details about the TCB structure returned by these comamnds are given in section 4.2.
The rest of the commands in this interface are used to manipulate the state of a thread, putting it into one of 4 distinct states and starting / stopping its execution as necessary. At any given time, a thread may exist in one of the following states (INACTIVE, ACTIVE, READY, SUSPENDED).
Threads are initialized into the INACTIVE state via a call to initThread(). This command MUST only be called once at the time a thread is first created. A call to initThread() MUST be followed by a call to startThread() at some point later in order to start the actual execution of the thread. Calls to initThread() always return SUCCESS;
Calls to startThread() return either SUCCESS or FAIL, depending on the state a thread is in when it is called. If a thread is in the INACTIVE state, calling this command puts a thread into the READY state and places it on a ready queue. Threads are scheduled for execution by puling threads off this ready queue in FCFS order. If a thread is in any state other than INACTIVE, FAIL is returned, and no other side effects occur.
Calls to stopThread() only return SUCCESS if called on a thread that is in the READY state (and thereby implicitly on the ready queue) and currently holds no mutexes. The mutex_count field in a thread's TCB is used to determine if any mutexes are currently held. If both of these conditions are met, a thread is removed from the READY queue and its state is set to INACTIVE. If either of these conditions are not met, calling stopThread() returns FAIL and no other side effects occur.
Calls to interruptCurrentThread() are made in order to preempt a currently running thread. Calling interruptCurrentThread() returns SUCCESS if the currently running thread is in the ACTIVE state (SHOULD always be true), otherwise it returns FAIL. Upon FAIL no side effects occur. Upon SUCCESS, the currently running thread is put into the READY state and placed on the thread scheduler's ready queue. Threads in the READY state are not blocked, and will be scheduled for execution again the next time their turn comes up. The interruptCurrentThread() function is currently only called in two places. At the bottom of the interrupt postAmble() (as shown before), and in the code implementing the round-robin preemption scheme.
Calls to suspendCurrentThread() return SUCCESS if the currently running thread is in the ACTIVE state (SHOULD always be true), otherwise they return FAIL. Upon SUCCESS, the currently running thread is put into the SUSPEND state and its execution is stopped. A thread in the SUSPEND state will not be scheduled for execution again until a call to wakeupThread() is made at some later point in time. Calls to suspendCurrentThread() SHOULD only be made from within the body of blocking system call API wrappers or synchronization primitives.
Calls to wakeupThread() take one parameter: 'thread_id'. wakeupThread() returns SUCCESS if the thread associated with 'thread_id' is successfully woken up and returns FAIL otherwise. For all threads other than the TinyOS thread, SUCCESS will only be returned if the thread being woken up is in the SUSPEND state. For the TinyOS thread, it must be both in the SUSPEND state and have tasks waiting on it task queue. Upon SUCCESS, a thread is put in the READY state and placed on the ready queue. Upon FAIL, no side effects occur.
Note
Most times calls to suspendCurrentThread()` are paired with placing the suspended thread on a queue. Calls to wakeupThread() are then paired with removing a thread from that queue. The queue used is matianed externally by the component issuing the suspend and wakeup. For example, every mutex variable has its own queue associated with it. Everytime a thread calls the lock() function associated with a mutex, it is placed onto the queue associated with that mutex if someone already holds the lock. When the owner of the lock eventually calls unlock() this queue is then checked and requesters are removed from the queue in FCFS order.
Section 4 discusses the API provided to an application that allows it to create and destroy theads, as well as invoke blocking system calls. This section details the internals of the thread implementation itself, focusing on the data structure used to actually represent threads.
Regardless of the API used to create a thread (either statically or dynamically as discussed in the following section), TOSThreads allocates a Thread Control Block (TCB) and stack memory for each thread at the time it is created. Each thread has a fixed stack size that does not grow over time. The code snippet below shows the structure of a TOSThreads TCB.:
struct thread { thread_id_t thread_id; init_block_t* init_block; struct thread* next_thread; //thread_state uint8_t state; uint8_t mutex_count; thread_regs_t regs; //start_function void (*start_ptr)(void*); void* start_arg_ptr; stack_ptr_t stack_ptr; syscall_t* syscall; };
thread_id: This field stores a thread's unique identifier. It is used primarily by system call implementations and synchronization primitives to identify the thread that should be blocked or woken up.
init_block: Applications implemented using the TOSThreds library have the ability to be dynamically loaded onto a mote at runtime. It is beyond the scope of this TEP to go into the details of this process, but applications use this field whenever they are dynamically loaded onto a mote. Whenever the system dynamically loads a TOSThreads application, the threads it creates must all receive the state associated with its global variables. An initialization block structure stores these global variables and 'init_block' points to this structure.
next_thread: TOSThreads uses thread queues to keep track of threads waiting to run. These queues are implemented as linked lists of threads connected through their next_thread' pointers. By design, a single pointer suffices: threads are always added to a queue just before they are interrupted and are removed form a queue just before they wake up. This approach conserves memory.
thread_state This set of fields store information about the thread's current state. It contains a count of the number of mutexes the thread currently holds; a state variable indicating the state the thread is in (INACTIVE, READY, SUSPENDED, or ACTIVE); and a set of variables that store a processor's register state whenever a context switch occurs.
stack_pointer This field points to the top of a thread's stack. Whenever a context switch is about to occur, the thread scheduler calls a switch_threads() function, pushing the return address onto the current thread's stack. This function stores the current thread's register state, replaces the processor's stack pointer with that of a new thread, and finally restores the register state of the new thread. Once this function returns, the new thread resumes its execution from the point it was interrupted.
start_function This field points to a thread's start function along with a pointer to a single argument. The application developer must ensure that the structure the argument points to is not deallocated before the thread's start function executes. These semantics are similar to those that Unix pthreads define.
system_call_block This field contains a pointer to a structure used when making system calls into a TOSThreads kernel. This structure is readable by both a system call wrapper implementation and the TinyOS kernel thread. The section that follows explains how this structure is used.
TOSThreads implements blocking system calls by wrapping existing TinyOS services inside blocking APIs. These wrappers are responsible for maintaining state across the non-blocking split-phase operations associated with the underlying TinyOS services. They also transfer control to the TinyOS thread whenever a user thread invokes a system call. All wrappers are written in nesC with an additional layer of C code layered on top of them. We refer to the TOSThreads standard C API as the API providing system calls to standard TinyOS services such as sending packets, sampling sensors, and writing to flash. Alternative API's (potentially also written in C) can be implemented as well (e.g. the Tenet API).
A user thread initiates a system call by calling a function in one of the blocking API wrappers. This function creates a local instance of a system call block (SCB) structure which contains: a unique 'syscall_id' associated with the system call; a pointer to the 'thread' invoking the call; a pointer to the function that TinyOS should call once it assumes control, and the set of parameters this function should receive. The SCB is used to exchange data with the TinyOS thread.:
struct syscall { syscall_id_t syscall_id; thread_t* thread; void (*syscall_ptr)(struct syscall*); void* params; };
All variables associated with a system call (i.e., the pointer to the SCB and the parameters passed to the system call itself) can all be allocated on the local stack of the calling thread at the time of the system call. This is possible because once the calling thread invokes a system call, it will not return from the function which instantiates these variables until after the blocking system call completes. These variables remain on the local thread's stack throughout the duration of the system call and can therefore be accessed as necessary.
As discussed in Section 2, making a system call implicitly posts a TinyOS task, causing the TinyOS thread to immediately wake up and the calling thread to block. In this way, there can only be one outstanding system call at any given time. Thus, only a single TinyOS task is necessary to perform an applications' system calls. The body of this task simply invokes the function the 'system_call_block' points to.
The important interfaces and components that implement the functionality described in this section can be found in tos/lib/tosthreads/system and tos/lib/tosthreads/interfaces. The important ones to look at are the SystemCall interface, and the SystemCallC and SystemCallP components. Example system call wrappers themselves include BlockingStdControlC, BlockingAMSenderC, etc.
Application written using TOSThreads can be programmed in either nesC or standard C. In nesC, threads can either be created statically or dynamically as a TOSThreads application executes. The primary difference between the two is that statically allocated threads have their TCB allocated for them at compile time while dynamic threads have them allocated at run time.
Static threads are created by wiring in an instance of a ThreadC component as shown below. As a parameter to ThreadC, we pass in the desired stack size for the thread.
configuration ExampleAppC { } implementation { components MainC, ExampleC; components new ThreadC(STACK_SIZE); MainC.Boot <- ExampleC; ExampleC.Thread -> ThreadC; }
The ThreadC component provides a Thread interface for creating and manipulating static threads from within a nesC module.:
interface Thread { command error_t start(void* arg); command error_t stop(); command error_t pause(); command error_t resume(); command error_t sleep(uint32_t milli); event void run(void* arg); }
Calling start() on a thread signals to the TOSThreads thread scheduler that that thread should begin executing. start() takes as an argument a pointer to a data structure to pass to a thread once it starts executing. Calls to start() return either SUCCESS or FAIL. Upon SUCCESS, the thread is scheduled for execution, and at some point later the run() event is signaled. The body of the run event implements the logic of the thread.
Calling stop() on a thread signals to the TOSThreads thread scheduler that that thread should stop executing. Once a thread is stopped it cannot be restarted. Calls to stop() return SUCESS if a thread was successfully stopped, and FAIL otherwise. stop() MUST NOT be called from within the thread being stopped; it MUST be called from either the TinyOS thread or another application thread.
Calling pause() on a thread signals to the TOSThreads thread scheduler that that thread should be paused. Pausing a thread is different than stopping it in that a paused thread can be restarted again later by calling resume() on it. Underneath, the pause() command is implemented by calling the thread scheduler's suspendCurrentThread() command. Calls to pause() return SUCCESS if a thread is paused, and FAIL otherwise. Essentially, pause() is used to perform an explicit suspension of the currently running thread. pause() MUST ONLY be called from within the thread itself that is being paused. Note that these are exactly the opposite semantics than those used for stop().
Calling resume() wakes up a thread previously suspended via the pause() command. SUCCESS is returned if the thread was successfully resumed, FAIL otherwise.
Calling sleep() puts a thread to sleep for the interval specified in its single 'milli' parameter. sleep() MUST ONLY be called from within the thread itself that is being put to sleep. SUCCESS is returned if the thread was successfully put to sleep, FAIL otherwise.
Dynamic threads are created by wiring in an instance of a DynamicThreadC component as shown below.:
configuration ExampleAppC { } implementation { components MainC, ExampleC; components DynamicThreadC; MainC.Boot <- ExampleC; BlinkC.DynamicThread -> DynamicThreadC; }
The nesC interface for creating and manipulating dynamic threads is.:
interface DynamicThread { command error_t create(tosthread_t* t, void (*start_routine)(void*), void* arg, uint16_t stack_size); command error_t destroy(tosthread_t* t); command error_t pause(tosthread_t* t); command error_t resume(tosthread_t* t); }
create() is used to create a new dynamic thread. It takes 4 parameters: 't', 'start_routine', 'arg', and 'stack_size'. 't' is pointer to a unique handler associated with the thread being created. 'start_routine' is the start function associated with the thread. 'arg' is a pointer to a structure passed to the start function once the thread has begun executing. 'stack_size' is the size of the stack to be dynamicaly allocated for the thread. Calls to create() return either SUCCESS, FAIL, or EALREADY. SUCCESS indiactes that the thread has been successfully created, FAIL means it could not be created, and EALREADY indicates that the handler assocaited with the 't' parameter is associated with an already running thread. Upon SUCCESS, a dynamic thread's TCB and stack memory are dynamically allocated, and the thread is scheduled for execution. Its 'start_routine' whill be called once it begins running. UPON FAIL or EALREADY, no side effects occur.
''destroy()`` is similar to stop() from a static thread's Thread interface. It follows all the same semantics as this command, except that it deallocates the TCB and stack memory associated with a thread before returning.
pause() and resume() are identical to their counterparts in the Thread interface.
The API allowing TOSThreads applications to be written in standard C includes a set of functions that simply wrap the commands provided by the DynamicThread interface. The following section shows an example of how these functions are used.
As mentioned previously, TinyOS services are presented to TOSThreads applications by wrapping their functionality inside blocking system calls. The number and type of standard services provided is constantly growing so it doesn't make sense to try and list them all out. Browse through tos/lib/tosthreads/system/ and tos/lib/tosthreads/lib to see what services are currently available. Also, take a look at the various applications found in apps/tosthreads to see how these services are used. There are applications written in nesC using both static and dynamic threads, as well as applications written in standard C.
| [TEP112] | TEP 112: Microcontroller Power Management. |
| [TEP118] | TEP 118: Dissemination. |
| [TEP119] | TEP 119: Collection. |
| [TEP133] | TEP 133: Packet Level Time Synchronization. |


Telegram ·
Telegram is a library for opaque data routing.
- Simple: Telegram allows you to easily start opaquely routing payloads.
- Flexible: With support for both the Publish/Subscribe pattern as well as the Request/Response pattern, you can passively receive updates or actively acquire data.
- Loose Coupling Never tightly couple your consumer code with the provider again. Whether acquiring data via HTTP, WebSockets, or an HTML5 postMessage, never have to modify you consumer code again just because the data source changed.
Installation
Telegram is available on npm as @lannuttia/telegram.
Documentation
Documentation can be found here.
Examples
Coming soon...
Contributing
If you have any type of feature request or bugfix, feel free to open an issue or submit a pull request.
License
Telegram is MIT Licensed.


Adding Event Locations
How to add one or more locations to the Events module. In the below example, the URL for the map location has been generated by searching for and choosing a map using Google Maps. The link to the map is generated by clicking the Link button and then copying the link.
- Select Edit Locations from the module actions menu.
- In the Location text box, enter the location name.
- Optional. In the Map URL text box, enter the URL which will link to a map of the location.
- Click the Add link. This displays the location in the Location Name list.
- Repeat Steps 2-4 to add additional locations.
- Click the Return link to return to the module.
The newly added Event Location


--- layout: post title: Episode 091 | Basel Farag - Persistent Fire link: http://traffic.libsyn.com/developeronfire/DeveloperOnFire-91-BasalFarag.mp3.mp3 length: 45088768 speaker: Dave Rael duration: '46:51' subtitle: 'Developer On Fire: Basel Farag' guest_name: Basel Farag image: /assets/images/BaselFarag.png guest_blog: http://www.garglingwithrazorblades.com/ guest_twitter: baselnotbasil disqus_url: http://developeronfire.com/Podcast/Episodes/basel-farag-persistent-fire episode_number: 91 book_recommendations: - { url: "https://pragprog.com/book/cfcar2/the-passionate-programmer", title: "The Passionate Programmer: Creating a Remarkable Career in Software Development", author: "Chad Fowler"} - { url: "http://www.amazon.com/dp/020161622X/?tag=devonfir-20", title: "The Pragmatic Programmer: From Journeyman to Master", author: "Andrew Hunt and David Thomas"} tags: - { url: "https://pragprog.com/book/cfcar2/the-passionate-programmer", title: "The Passionate Programmer: Creating a Remarkable Career in Software Development", author: "Chad Fowler"} - { url: "http://www.amazon.com/dp/020161622X/?tag=devonfir-20", title: "The Pragmatic Programmer: From Journeyman to Master", author: "Andrew Hunt and David Thomas"} redirect_from: - "/91/" - "/091/" - "/0091/" - "/basel-farag-persistent-fire/" - "/Basel-Farag/" - "/BaselFarag/" - "/Podcast/Episodes/91/" - "/Podcast/Episodes/091/" - "/Podcast/Episodes/0091/" - "/Podcast/Episodes/basel-farag-persistent-fire/" - "/Podcast/Episodes/Basel-Farag/" - "/Podcast/Episodes/BaselFarag/" guid: http://developeronfire.com:80/Podcast/Episodes/basel-farag-persistent-fire ---
Basel Farag is a software developer and data geek with proven experience in web/mobile development and Agile methodologies utilizing languages like JavaScript and Objective-C. Lately, however, he's been OBSESSED with Swift. It's awesome. He's lectured on Swift for various organizations, including Women Who Code. He also regularly writes for http://www.garglingwithrazorblades.com/ -- a website dedicated to explaining Apple's new programming language Swift and concepts in Cocoa. Sometimes he's interviewed by tech podcasts. He's also the organizer of the Denver Swift Heads meetup crew.


Current exam links:
Type
Language
Link
Is active
{% for p in all_problems %}
{% for l in levels %}
{{l}}
{% endfor %}
{% for l in languages%}
{{l}}
{% endfor %}
Edit
Save
{% endfor %}
Add new:
Test name:
{% for l in levels %}
{{l}}
{% endfor %}
Language:
{% for l in languages%}
{{l}}
{% endfor %}
Link:


ValidationListener Class
A mixin to be used in the component parent of the ValidatableElement
Item Index
Methods
Methods
addBroadcaster
-
broadcasterElement
Used by the ChildBroadcaster to subscribe itself as a broadcaster. Check if the field has an error already in the system and mark it as field with error.
Parameters:
-
broadcasterElement
ObjectThe ChildBroadcaster/broadcasterElement:property of the ChildBroadcaster
addError
-
element
-
message
Method used to add an error to the system
Parameters:
-
element
HTMLElementThe DOM element with error
-
message
StringThe error message
buildError
-
element
-
message
Build the error store in ParentListener/errors:property
Parameters:
-
element
HTMLElementThe DOM element with error
-
message
StringThe error message
initializeListener
()
private
Initialization of component. Listen to 'init' event
initializeValidationListener
()
private
Initialization of component. Listen to 'init' event
processAction
-
action
-
params
An override of method processAction
Parameters:
-
action
StringThe name of the action triggered by the ChildBroadcaster
-
params
MixedThe paremters needed to handle this action
removeBroadcaster
-
broadcasterElement
Used by the ChildBroadcaster to unsubscribe itself as a broadcaster.
Parameters:
-
broadcasterElement
ObjectThe ChildBroadcaster/broadcasterElement:property of the ChildBroadcaster
removeError
-
element
Method used to remove its error from the system
Parameters:
-
element
HTMLElementThe DOM element with error
validateAllElements
()
Boolean
public
Trigger the validation on all elements.
Returns:
True when all elements were valid
Properties
broadcasters
Array
An array of ChildBroadcaster/broadcasters:property with the subscribed ChildBroadcaster instances
Default: []
errors
Array
Array of current errors. Every error is an object like follow:
error: {
id: [id of the element with error],
prefix: [the prefix of the error message in this priority: (label - element.name - Error)]
element: [the DOM element with error],
message: [the current error message]
}
Default: []
hasElementWithError
Boolean
public
Computed property. Usage: this.get('hasElementWithError')
True if there is any child with error
isParentListener
Boolena
private
Property read by every ChildBroadcaster in order to know if this parent is a listener or not
Default: true
listener
Object
An read only abstraction of this class only with the methods we would like to provide to our ChildBroadcaster
wereAllElementsValidated
Boolean
public
Computed property. Usage: this.get('wereAllElementsValidated')
True if all the ValidatableElement were validated at least once


 When you push your body to a limit it’s not supposed to physically go, and complement this lunacy with a mental punishment that hurts more than an axe kick to the face.
The toughest woman in Denver runs and hides in a far corner of a gym locker room. She crumbles. Tears pour out like blood.
It’s Jan. 14, 2015, one year and one day after the worst day of Cat Zingano’s life. The mixed martial arts fighter is preparing for what could be one of the best days of her life, when she contends for the Ultimate Fighting Championship title. But on this day she’s suffocated by emotions — of loved ones lost — and concern about her upcoming fight after a sloppy sparring session. She’s not herself, so she hides.
A stranger saunters into the locker room, spots her curled up and sobbing and says, “It’s OK, it’s OK.”
“And I’m thinking, ‘It’s not OK! She didn’t fight. She doesn’t know what I’m doing,” Zingano said later. “All she sees is me crying. Clearly she was trying to be helpful, but I needed her to go away, now. So I just said, ‘Thank you’ and put my head against the wall.”
Saturday night, the 32-year-old Zingano (9-0) will fight for the UFC women’s bantamweight title, the headline bout on a pay-per-view card at Staples Center in Los Angeles. Her opponent, reigning champion Ronda Rousey (10-0), is an Olympic bronze medalist in judo, a star of action movies, a Sports Illustrated swimsuit model. She’s a giant in the sport.
Zingano, by contrast, is a relative unknown, having built a career that has been both rocky and “Rocky,” from her modest start wrestling at Boulder’s Fairview High School.
In her corner on fight night she will have two coaches and two close friends. But the one man she most wanted by her side won’t be there, and it’s one reason she was balled up and bawling in the locker room on this January night.
“Sometimes I have to break,” Zingano said. “But I won’t stay broken.”
Mauricio Zingano gave her a quick kiss and a bro hug before the massacre. No mascara here.
An accomplished Brazilian jiu jitsu coach, Mauricio guided Cat’s transformation from wrestler to mixed martial artist out of the gym they co-owned in Broomfield. Now, on April 13, 2013 , they’re in the spotlight at the Mandalay Bay arena in Las Vegas for her biggest fight yet, against Miesha Tate.
As she walked into the frenzied venue, leading her team’s procession to the cage, Zingano started sobbing. A national TV audience tweeted about her tears. Crying before a fight? They must have wondered if Zingano was in over her head.
But this is who she is — raw and real, no apologies.
 “But once that door is closed and you’re in there, it’s like, ‘Screw it, you’ve gotta go, now.’”
But when the cage door closes behind her, she’s all alone.
“What’s up, stud!” Zingano’s coach, Leister Bowling, hollered to Brayden Zingano.
An hour before Cat’s Jan. 14 breakdown, she walked into MusclePharm gym in the Montbello neighborhood of Denver, greeted by a family of fighters of all shapes and sizes, many with cauliflower ears, tattoos crawling down their arms and T-shirts screaming outrageous mantras (“FIGHTING IS IN MY DNA”).
She was the only athlete on the mats who brought a child, her bubbly son Brayden, 8. Within minutes, Brayden climbed inside the black-wired Octagon, playfully sparring with a professional fighter twice his height. At MusclePharm, it’s as if everyone is Brayden’s fun uncle.
Soon, Brayden was swinging on nearby gymnast rings as a sparring partner slammed his mom around a cage. It was ugly. When Cat’s four five-minute practice rounds ended, she escaped to the women’s locker room.
About 45 minutes later, she emerged and sat on a bench near the Octagon, her eyes weathered and red. A jovial visitor tried to get her to loosen up, but she wasn’t having any of it. Cat’s friend and fellow fighter, Brandon Thatch, began rubbing her shoulders.
“I love you. You know we all love you,” he told her.
Love.
She grapples with love. She loves her son, her sport and her support. But love also took her for a ride.
“When it all comes down to it, he had my heart, all wrapped up,” Zingano said recently, while Sam Smith’s “Stay With Me” played faintly in the background at the gym. “I never felt like that about anybody. And I don’t imagine feeling like that about anybody again.”
Miesha Tate waited for Cat that April 2013 night in Vegas as Mauricio peered into the Octagon. Tate, a former champion in the Strikeforce series. Tate, an overwhelming favorite.
And there was more on the line than a shiny belt. Zingano vs. Tate was an elimination bout, with the winner earning a title shot against Rousey. It would be the first UFC women’s championship. It also meant a fat TV contract to coach a team in the 18th season of “The Ultimate Fighter,” the UFC’s reality TV competition show.
One woman would get a career break. So who would break first?
Tate sprinted out when the horn sounded, grabbed Zingano around the waist and, just five seconds in, slammed Cat to the mat.
With her back flat under Tate’s barrage, Zingano slipped a perfect escape to regain her feet. Within a minute, Zingano seized control. She folded Tate’s head under the crook of her elbow, working toward a guillotine choke, with all her leverage in the legs, a tenet of wrestling.
She was the only girl on the boys’ team. At Fairview High, Zingano — then Cathilee Albert — wrestled at 130 and 135 pounds. Her parents hated the idea.
“I loved it,” she said.
She devoured the sport. In the offseason, she showed up at gyms looking to learn. She pushed her way into a practice session at nearby Lyons High, where some of the area’s top prep wrestlers worked out. She wanted to wrestle the best.
Leister Bowling, on his way to becoming a three-time Colorado champion, didn’t want Zingano anywhere near his mat. This was a boys’ club. In a practice session, he intentionally shattered her cheekbone.
“He tried to make me quit all the time,” Zingano said of the wrestler who, sure enough, would one day become one of her coaches. “They were like: ‘Oh, this chick thinks she’s going to go with us? She’s never going to wrestle again after this.’”
Cat returned the next day.
“I got beat up a lot, but it made me really tough,” she said.
Wrestling defined Zingano. It gave her a purpose through high school. It propelled her to college. It allowed her to dream of making the 2004 U.S. women’s Olympic team.
Then her world fell apart.
Cat was a freshman at the University of the Cumberlands in Williamsburg, Ky., when one of her closest friends back home, 17-year-old Mary Rogers, was found tortured and killed in Westminster. Rogers’ boyfriend was later convicted of first-degree murder.
“I don’t feel like I recovered from that,” Zingano said of her time in college in the early 2000s. “She was one of my best friends since I was 8 years old. It was really traumatic. Now I look back, and I just feel — a lot of my drive for what I wanted to do with wrestling was smoldered by that.”
She came home from college. Her Olympic dream now faded, she stepped away from the wrestling mats. It would be years before she got back on. In 2007, now a new mother, Cat walked into Zingano Brazilian Jiu Jitsu gym in Broomfield.
She saw Mauricio, one of the instructors. He suggested she take a jiu jitsu class. It was love at first fight — with the sport and the instructor.
“I was in awe of him, how strong he was, how talented he was,” Cat said of Mauricio, twice a national Brazilian jiu jitsu champ. “The presence he carried, he was just so bold and impressive. And he really made me laugh.”
On a gym trip to Water World, Cat recalled in a soft voice, “He held my hand.” Though she was wary of dating her coach, these feelings were new and exciting.
“Finally, I went back to a class,” she said. “And he said, ‘All right, you and me are (sparring)!’ After class, he pulled me aside, and we were connected at the hip after. Always, forever.
“At first, it was perfect. I was so gung-ho on impressing him, being his prodigy, winning every tournament. Everything I did, I wanted to keep handing him trophies: ‘This is for you. I won this.’ I felt like I couldn’t do any wrong. And he was so proud of me.”
They became addicted — to each other, to success. Work hard, fight hard, win hard. But the dynamic was toxic. Her new boyfriend, whom she married in 2010, was also her coach. And her business partner, running multiple gyms. Oh, and they were parents, raising her son, Brayden.
But Mauricio saw greatness in her fists and constantly challenged her to make sacrifices — to eat certain foods, to go for an extra run at night, to learn from criticism at all hours. It became too much.
“I didn’t know who I was talking to,” she said. “I had so much respect for him, I would never say anything. I would look at him as my coach and my boss, but I needed to be able to talk to him like my husband.
“There was depression,” she said of Mauricio. “I feel like we would’ve figured it out eventually, but he made some bad choices to make things worse, and I couldn’t put up with it and have my son around it. I had to do something, but I didn’t know what to do.
“So I left him.”
Record: 9-0-0; No. 2 bantamweight
Pro since: 2008
Nickname: Alpha
Fights out of: Broomfield
Age: 32
Height: 5-foot-6
Weight: 135 pounds
Jun. 13, 2008: W vs. Karina Taylor (submission)
Jan. 10, 2009: W vs. Angela Samaro (submission)
Jan. 30, 2010: W vs. Barb Honchak (decision)
June 5, 2010: W vs. Ivana Coleman (TKO)
Dec. 10, 2010: W vs. Carina Damm (TKO)
May 14, 2011: W vs. Takayo Hashi (KO)
Oct. 6, 2012: W vs. Raquel Pennington (submission)
April 13, 2013: W vs. Miesha Tate (TKO)
Sept. 27, 2014: W vs. Amanda Nunes (TKO)
Tate wriggled out of the guillotine. She flung a rigid jab that landed on Zingano’s chin, stunning Cat. Tate would land 23 significant strikes, 21 at Zingano’s head.
As she weathered Tate’s blows, Cat grew more aggressive. This is her great trait in the cage: Hit me and I’ll hit you harder.
Mauricio taught her how to do so in a brutal introduction to a vicious sport.
“He stood me in the corner of a boxing ring and just teed off on me — on my face, everything,” she said. “He was trying to teach me to not turn when I was being hit.  I would be crying, bawling. He had another student doing it to me too.
“I yelled, ‘Stop hitting me!’ It happens every fight. Nobody likes getting hit. But when somebody gets a good one off on me, it makes me really mad. I just want to make it stop. I want to punish them.”
Tate was about to be punished.
Now living apart and in marriage counseling, the Zinganos agreed to meet at the play area at FlatIron Crossing mall in Broomfield. It was Jan. 12, 2014. They could share some quality Brayden time. A chance to be a family again.
Mauricio never showed.
Cat called. She called again. Mauricio never missed a meeting with Brayden. She called again. Where is this guy? She drove to his home, saw his car out front.
“I was afraid to go in,” she said, “because I didn’t know what that meant I was going to find.”
So she drove home and kept dialing his number, deep into the night. Each time there was a simultaneous feeling of hope and hopelessness. Just answer and everything will be all right, won’t it?
The following day, she asked one of their jiu jitsu students to go by Mauricio’s home. But the student never called back. So Cat finally went to the house.
Cop cars.
“Are you Cat?” a detective asked her.
She didn’t know what to say.
“I can only tell you what happened if you’re Cat,” the detective said.
“Fine, I’m Cat.”
Reflecting back at that moment, Cat recalled how she didn’t realize she was screaming, as if she wasn’t in control of her body.
But she was indeed screaming, incessantly, the same three words, over and over: “WHAT THE (EXPLETIVE)?”
Mauricio was dead. Suicide. Age 37.
When she won the biggest fight of her life, Cat screamed, “I love you Brayden!” into a camera lens while her husband lifted her like a trophy inside the cage.
Cat unleashed a primal scream and one final punch into the air, while Mauricio shouted “No. 1!” with his wife in his arms.
 TKO 2:55, third round.
It was all falling into place.
But one month later, right before the May 2013 filming began for “The Ultimate Fighter,” Cat tore the anterior cruciate ligament in her left knee. Cat’s title shot with Rousey was canceled. The UFC replaced her with, of all people, Tate.
And Mauricio’s downward spiral began.
How do you tell a boy his dad is dead?
Cat opened the bedroom door that night, and there was her innocent child, sleeping in bed.
“I had to wake him up,” she said. “I feel like every catastrophe in our lives you remember exactly where you were, what you were doing, who you were with, almost down to what you were wearing. I get one shot at this.”
The detective told her to speak directly. Trying to soften the moment only makes it worse.
He’s dead. Gone. Dad is gone.
“That,” she recalled, “was the hardest thing I’ve ever done in my life.”
How do you teach a boy to cope with death, when you don’t know how?
Cat and Brayden often visit Judi’s House to meet with a group of people who have also lost a loved one to suicide. Founded by former Broncos quarterback Brian Griese, who lost his mother when he was 12, Judi’s House is a haven for grieving kids who lost a parent, so they don’t have to feel alone.
Alone. A haunting theme in Cat’s life. Alone in the ring. Alone as a parent. Alone as a wife. A widow. She’s often surrounded — by fans and coaches and Brayden and friends — but she can’t always cover herself from emotions.
“Catch me any time of the day, I’m either (upset) at him, happy with him, in love with him, mad at him,” Cat said of Mauricio, whom she still refers to as “my husband” in conversations.
“I want to get all of this (fighting success) for us, and everything that we’ve done, and all the work we’ve put into it. He lost his damn mind. And that sucks, because he was a very strong, very smart, very intense and awesome person.
“For my son to lose his dad and in that kind of way, I don’t know how to put this, but — I don’t want to quit, because I don’t want that to be embedded in him from more than one angle.”
Now Brayden is hiding.  He’s playing hide-and-seek. A woman looks for him, and soon other fighters join in the playful search.
The obvious hiding spot is under the cage, where his mom, in padded headgear, is sparring. After recovering from the knee injury, Cat finally got her shot at Rousey — a chance to bloody the female face of the UFC.
The cage at MusclePharm gym is really a stage, and underneath is a space a few feet high, covered by a curtain. Someone flips up the curtain — he’s gotta be under here, right? — but he’s not. Where did Brayden go?
Finally, he pops out of the giant tire, and he flashes a mischievous smile.
This gym, this community, is his comfort zone. Mom’s too. Here, you can be alone in the tire, or alone in the cage, but you’re surrounded by warmth.
“To be honest,” Cat said, “I think part of the connection with Brayden and all of my teammates is that every fighter has gone through hell at some point in their life.
“With Brayden, they all know what happened, and they see a kid that is going through something — and whatever color it is of what they’ve gone through, they can identify with him, and they want to be there for him. It’s really sweet. And it’s really cool and comforting.


Jonathan George Lorem ipsum dolor sit amet, conse adipiscing. dolor sit amet,
+ 16,582,00
NEW
LAST WEEK
NEW
LAST WEEK
NEW
LAST WEEK
Dnim eiusmod high life accusamus terry richardson ado squid. 3 wolfmoon officia aute, non cupidatat
Dnim eiusmod high life accusamus terry richardson ado squid. 3 wolfmoon officia aute, non cupidatat
9,580
10,361
BALANCE
000 Street
City, Country 0000
0-000-000000
(0-000-000-0000)
000 Street
Headquarters Staff Directory
Working AJAX contact form. Give it a try..


Unfortunately, I can not reproduce articles models 2 and 3 in NWChem too.
I have the impression that there is a problem with the units of “weight”.
Both the article and the documentation of NWChem says that it is the atomic units.
However, if you increase the hyperbolic constant in 50 times, and harmonic constant in 30 times, the results agree with the article.
Similarly, if the increase is 30 times the constant of my implementation (model 1), the results agree with the article.
So, I think that my (model 1) code is working properly, but it is necessary to deal with the input constants in all models.
The input file for methanol can be found
here. Here are also modified sources. No binaries.
I allow the user defined target charges not only for harmonic functions, but for the hyperbolic too.
Quote:Bert
Oct 17th 7:44 pmBefore you start coding it is key to understand the code, how it solves the equations you are interested in. You should not make guesses. What I recommend you do is to take the RESP paper and match up the coded equations to those in the paper. This will give you an understanding of what the code does and how it relates to the paper. Using the "q0" parameter should give you equation 1, at least when I match up the code. The b variable seems to match up with your b-variable in your equation 3.
I am not going to open files with binaries because of security issues. Have you done some tests that allow you to compare to the published data? This will allow you to test for correctness.
Bert