--- layout: post esbma_id: 3037 title: Announcing the release of Zumero for SQL Server date: 2013-12-11 12:00:00 ---
So, as we say here in the Midwest, I'm as giddy as a fox in the hen house while the dog ain't home.
Today we released version 1.0 of Zumero for SQL Server.
Zumero for SQL Server. I mentioned it here on my blog a few weeks ago.
"Zumero" -- "replication and sync of SQL data for mobile devices"
"for SQL Server" -- "it uses Microsoft SQL Server on the backend"
Yes, you can do that. And if that solution meets your requirements, then you may not need Zumero. But there are some pretty big benefits to the "replicate and sync" approach, including performance and offline support.
There's some info about this on our website.
Or you could check out Sync is the Future of Mobile Data, by Couchbase co-founder J. Chris Anderson. Most of Chris' preaching tends to be compatible with Zumero, except of course that he is of the NoSQL religion and we practice the SQL doctrine.
Or you could take a look at offlinefirst.org. These guys are also sort-of a competitor to Zumero, but they're singing the same tune we are, and they're singing it pretty darn well in my opinion.
ZSS consists of three parts:
ZSS Server is a module for Internet Information Services (IIS). Simply point it at your SQL Server database (which need not be on the same machine) using an ODBC connection string. We include an easy-to-use installer as well as instructions for people who prefer to do the installation manually.
ZSS Manager is a desktop application used to setup your data for sync. You can specify which tables you want your mobile devices to see and/or modify.
ZSS Client SDK is a collection of libraries which allow you to sync on mobile devices.
By golly I do!
Lots more of them on the Zumero website, BTW.
Actually, we've also got sync libraries for MacOS, Linux and Windows. The focus of the product is mobile, so we sometimes list them in the supporting cast.
SQLite (see www.sqlite.org)
Certainly not.
The world's population divides very cleanly into two groups:
If you write code and you're in group 2, regardless of whether you become our customer or not, for your own sake, get yourself into group 1. It's a better way to live.
Yes. ZSS is designed to be added into an existing environment without screwing up anything already there. If you've already got a SQL db which is serving a website or a bunch of desktop apps, ZSS will play nicely with your existing stuff while giving you the ability to replicate your data so it can be used with SQLite on mobile devices.
No. ZSS does not require you to make any changes to your existing schema, but it does need to install some new housekeeping tables and triggers and views. The ZSS Manager application generates the T-SQL for these items and displays it so that you can review everything before any changes to your database are made.
It's one function. At the C level, it looks like this:
int zumero_sync( const char *zFilename, const char *zCipherKey, const char *zServerUrl, const char *zDbfile, const char *zAuthScheme, const char *zUser, const char *zPassword, const char *zTempDir, char **pzErrorDetails );
Much of the Client SDK is wrappers to make this friendlier. For example, in C#, it looks like this:
namespace Zumero { public static class ZumeroClient { public static void Sync( string filename, string cipherkey, string server_url, string dbfile, string auth_scheme, string user, string password ) } }
And so on...
Oh, and by the way, I exaggerated. It's not one function, it's actually eight. But the other seven don't matter very often. Mostly.
Yep.
Currently, no, although you are obviously free to install your licensed ZSS Server in your own cloud instance if you like.
Sorry for the confusion. We're working to clean all this up.
ZSS and Zumero Cloud are actually quite different. Zumero Cloud was first launched back in March 2013. We think of it as "version 0" of the Zumero architecture. ZSS is built on a very different architecture, which we might call "version 1". Simply put, the overall design of ZSS is just better. We will be upgrading the Zumero Cloud service to the new architecture, but that will involve some compatibility-breaking changes, so we need to do the transition carefully.
Whatever you like. ZSS doesn't care.
When you ask the sync library to bring down a copy of the prepared data from the ZSS Server, you provide it with the path name of a SQLite database file. Once that file is on your mobile device, you can interact with it using whatever SQLite API or wrapper that you like.
For example, on Android/Java you would probably use android.data.sqlite.
On iOS/ObjC, you could perhaps use FMDB.
On WinRT, there's a SQLite component. And there's one for Windows Phone 8 as well. The samples in our Client SDK make use of these.
On Cordova (Phonegap), everybody seems to be using this SQLite plugin. Well actually, the link in the previous sentence is to our Github fork of that plugin, containing one little tiny change. Because Zumero needs to know the full path name of the SQLite database file, we tweaked the API to provide that info back to the app.
On Xamarin, sqlite-net is quite popular. Or you could use Mono.Data.SQLite, an ADO.NET-style API which is built into the Xamarin toolset.
The list above is not complete.
Short answer: no
Longer answer:
We haven't tried that yet. If you're not going to be crushingly disappointed when it doesn't work, please try it and let us know.
But I'd bet a dollar that this is going to require some additional effort. Core Data isn't really a general-purpose SQLite wrapper. It's a big, thick abstraction which happens to [sometimes] use SQLite under the hood.
There is some progress in this area. Joel Grasmeyer has done some Core Data support for Zumero Cloud. This code is not compatible with ZSS right now, but we're talking with him. About stuff.
Yes.
ZSS Manager allows you to configure permissions at fine granularity, allowing you to assign SELECT, UPDATE or DELETE rights to users on a per-table basis.
For ZSS 1.0, the authentication support is fairly basic, allowing you to authenticate users against a password list in a SQL table, with support for either plaintext passwords (ick) or bcrypt. Things like Active Directory and OAuth2 are on the way.
In ZSS 1.0, no. This feature is under development for inclusion in a 1.1 release, planned for January.
No.
See http://zumero.com/pricing/.
Yep. We've been getting plenty of requests for other backends. PostgreSQL is perhaps the most often heard. Email<EMAIL_ADDRESS>to cast your vote.


Class TaskGroup
| Defined in: | src/lib/taskgroup.coffee |
| Inherits: | Interface |
Overview
Class Method Summary
- TaskGroup .create(args...) Creates a new TaskGroup instance.
- Boolean .isTaskGroup(group) A helper method to check if the passed argument is an instanceof a TaskGroup.
Instance Method Summary
- ::addGroup(args...) Add a TaskGroup with some configuration to ourself, create it if needed.
- ::addGroups(items, args...) Add TaskGroups with some configuration to ourself, create it if needed.
- ::addTask(args...) Add a Task with some configuration to ourself, create it if needed.
- ::addTasks(items, args...) Add Tasks with some configuration to ourself, create it if needed.
- ::clear() Clear remaning items.
- ::constructor(args...) Initialize our new TaskGroup instance.
- TaskGroup ::createGroup(args...) Create a TaskGroup instance from some configuration.
- Task ::createTask(args...) Create a Task instance from some configuration.
- ::destroy() Destroy all remaining items and remove listeners.
- Object ::getItemNames() Gets the names of the items, the total number of items, and their results for the purpose of debugging.
- Object ::getItemTotals() Gets the total number count of each of our item lists.
- Number ::getItemsTotal() Gets the total number of items
- Boolean ::hasExited() Have we finished its execution yet?
- Boolean ::hasItems() Whether or not we have any items
- Boolean ::hasRemaining() Whether or not we have any items that are yet to execute
- Boolean ::hasRunning() Whether or not we have any running items
- Boolean ::hasStarted() Have we started execution yet?
- Boolean ::isComplete() Have we completed its execution yet? Completion of executed is determined of whether or not we have started, and whether or not we are currently paused or have no remaining and running items left
- Boolean ::isEmpty() Whether or not we have no items left
- ::onceDone(handler) Once Done Promise.
- ::run(args...) Start the execution.
- ::setConfig(opts = {}) Set the configuration for our instance.
- ::setNestedConfig(config = {}) Set Nested Config
- ::setNestedTaskConfig(config = {}) Set Nested Task Config
- ::whenDone(handler) When Done Promise.
Inherited Method Summary
Methods inherited from Interface
.whenDone, .onceDone, .done, .getNames, .getName, .getConfig
Class Method Details
TaskGroup .create(args...) Source
Constructor Details
::constructor(args...) Source
Instance Method Details
::addGroup(args...) Source
::addGroups(items, args...) Source
::addTask(args...) Source
::addTasks(items, args...) Source
::clear() Source
TaskGroup ::createGroup(args...) Source
Task ::createTask(args...)  Source
::setConfig(opts = {}) Source
::setNestedConfig(config = {}) Source
::setNestedTaskConfig(config = {}) Source


This page belongs to Barclaycard GTL
GTL Loan Application
Your application is now complete!
Next Steps:
No next steps. Barclaycard will now process your loan application!
Thank you!
Start Over


Sun Tzu was a military strategist and author of The Art of War. He was born in the Eastern Zhou period of china 544 BC in Qi. His birth name is Sun Wu (孙武) but he is also referred as Sun Tzu (孙子) meaning "Master Sun" (they put 子 after his surname (孙) to show him respect).
In 515 BC, Sun Tzu advised Wu Zixu (伍子胥), a general of Wu, to ask Helü (闔閭) to assassinate the current king of Wu (Wu Wangliu (吳王僚)) and let Helü take the throne. In 512 BC, Wu Zixu asked the uncle of Helü to recommend Sun Tzu to Helü and presented him The Art of War. After reading the book Helü thinks highly of Sun Tzu and ask him to serve him but some are doubtful of his ability because he is very young and doesn't come from a well-known family, so Helü ask Sun Tzu so his training ability to him.
Helü tested Sun Tzu's ability by asking him to train of 360 maids, including two of the favoured concubines into soldiers. Sun Tzu then divided them into two groups, appointing the two concubines as the leaders of the group. Sun Tzu then ordered the groups to face right, they giggled. Sun Tzu responded saying, "That the general, was responsible for ensuring that soldiers understood the commands given to them." Then he repeated the command, but again they laughed. Sun Tzu then ordered the beheading of the king's two favoured concubines, against the king's orders. He said, "If the soldiers understood their commands but did not obey, it was the fault of the soldiers." Sun Tzu then said, "Once a general was appointed, it was his duty to carry out his mission, even if the king protested." They then chose new leaders to replace the now beheaded the concubines. Afterward, both groups, now very aware of the costs of disobey, they performed his orders flawlessly.
Sun Tzu Died in Gusu, Wu 496 BC Aged 47–48
In 512 BC, when Sun Tzu became general, he helped Helü eliminate two protectors of Chu (the of State Zhong Wu and Xu State) Helü wanted to attack Chu State, but Sun Tzu stopped him, thinking that Wu was exhausted and should not fight again. Helü led his soldiers back to Wu. Then, Wu Zixu harassed Chu State for six years, making Chu believe that Wu only dared to harass and did not dare to attack.
506 BC, Chu attacked Cai, so Cai asked Wu for help, Wu attacked Chu. Helü led his brother Fu Gai (夫概）, Wu Zixu, Sun Tzu, Bo Pi（伯嚭）and 30,000 soldiers to attack Chu. Sun Tzu believes that speed is precious in war, so he led 3,500 soldiers to adopt a circuitous strategy to avoid the actual attack. They conquered three Chu cities in the northern part. King Chu was shocked and sent two generals to lead his troops to support the Chu Army. After fierce fighting, the Chu army was defeated, Wu successfully conquered Chu. Sun Tzu defeated the 200,000 Chu army with 30,000 Wu army, because of that he became famous and shocked the other countries.
Because of Qin's attack, Wu withdrew its troops from Chu to defend Qin's attack. However, Chu was already injured and it could not threaten Wu. In 496 BC, Helü refused to listen to Sun Tzu's advice, and sent troops to attack the newly enthroned king of Yue (Goujian 勾践). However, Wu was defeated and Helü died after being seriously injured from the war. Sun Tzu and Wu Zixu helped Helü's son Fucha (夫差) govern the country and train the army, and helped Fucha defeat Goujian and get revenge. Afterwards, Fucha sought dominance over other countries up northward with the help of Sun Tzu's well-trained soldiers. However, in 482 BC, after Fucha became increasingly bossy after his dominance, Sun Tzu returned to Qi to concentrate on compiling The Art of War. Sun Tzu asked Wu Zixu to retire with him, but Wu Zixu did not agree, and he regretted not leaving with Sun Wu until the moment Fucha killed him.


| alternatingRowColors |
boolean |
true |
When set to true every other row shows a background color. |
| actions.title |
string |
none |
The column header string to display above the actions column. If this string corresponds with a
translation key, ngx-translate will translate it. |
| actions.add.include |
boolean |
true |
Whether or not to display the add button. |
| actions.add.label |
string |
add |
By default, the add button will display the add icon. If a string
is passed, a button with this string as its label will be displayed instead of the icon.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.add.position |
string |
header |
The position at which to display the button. If set to "header", the button will appear in
the table header, to the right of the table's title (if it exists). Otherwise, the button
will appear in the actions column of the filter row (if visible).
|
| actions.add.tip |
string |
'Add New' |
The text to display in the tooltip when the user mouses over the
button/icon. Note that if add.label is overridden to include a
string to display as a button label, an icon is not displayed and this property will do nothing.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.add.confirm |
boolean |
false |
Whether or not to confirm new item creation before the item is added. |
| actions.edit.include |
boolean |
true |
Whether or not to display the edit button. |
| actions.edit.label |
string |
edit |
By default, the edit button will display the edit icon. If a string
is passed, a button with this string as its label will be displayed instead of the icon.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.edit.position |
string |
right |
The position at which to display the button. Can be one of "left", "right", or "header". |
| actions.edit.tip |
string |
'Add New' |
The text to display in the tooltip when the user mouses over the
button/icon. Note that if edit.label is overridden to include a
string to display as a button label, an icon is not displayed and this property will do nothing.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.edit.confirm |
boolean |
false |
Whether or not to display a confirmation dialog before allowing a user save changes to an item. |
| actions.delete.include |
boolean |
true |
Whether or not to display the delete button. |
| actions.delete.label |
string |
delete |
By default, the delete button will display the delete icon. If a string
is passed, a button with this string as its label will be displayed instead of the icon.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.delete.position |
string |
right |
The position at which to display the button. Can be one of "left", "right", or "header". |
| actions.delete.tip |
string |
'Edit' |
The text to display in the tooltip when the user mouses over the
button/icon. Note that if delete.label is overridden to include a
string to display as a button label, an icon is not displayed and this property will do nothing.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.delete.confirm |
boolean |
false |
Whether or not to display a confirmation dialog before deleting an item. |
| actions.save.include |
boolean |
true |
Whether or not to display the save button shown when editing an exiting item. |
| actions.save.label |
string |
done |
By default, the save button will display the save icon. If a string
is passed, a button with this string as its label will be displayed instead of the icon.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.save.position |
string |
right |
The position at which to display the button. Can be one of "left", "right", or "header". |
| actions.save.tip |
string |
'Save' |
The text to display in the tooltip when the user mouses over the
button/icon. Note that if save.label is overridden to include a
string to display as a button label, an icon is not displayed and this property will do nothing.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.cancel.include |
boolean |
true |
Whether or not to display the cancel button. |
| actions.cancel.label |
string |
close |
By default, the cancel button will display the close icon. If a string
is passed, a button with this string as its label will be displayed instead of the icon.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.cancel.position |
string |
right |
The position at which to display the button. Can be one of "left", "right", or "header". |
| actions.cancel.tip |
string |
'Cancel' |
The text to display in the tooltip when the user mouses over the
button/icon. Note that if cancel.label is overridden to include a
string to display as a button label, an icon is not displayed and this property will do nothing.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.create.include |
boolean |
true |
Whether or not to display the create button. |
| actions.create.label |
string |
done |
By default, the create button will display the done icon. If a
string is passed, a button with this string as its label will be displayed instead of the icon.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| actions.create.position |
string |
right |
The position at which to display the button. Can be one of "left", "right", or "header". |
| actions.create.tip |
string |
'Create' |
The text to display in the tooltip when the user mouses over the
button/icon. Note that if create.label is overridden to include a
string to display as a button label, an icon is not displayed and this property will do nothing.
If this string corresponds with a translation key, ngx-translate will translate it.
|
| filterByLabel |
string |
'filter by' |
The text prefixed to the input name appearing in the filter input as
placeholder text. If this string corresponds with a translation key, ngx-translate will
translate it.
|
| hover |
boolean |
false |
Whether or not to display a highlight color on the row when the user's
mouse passes over the row.
|
| noDataMessage |
string |
'No data found' |
The text to display when no data is loaded into the table. |
| title |
string |
none |
If a title is included, a title bar will appear in the header to show this string.
If this string corresponds with a translation key, ngx-translate will translate it. |
| valign |
string |
'middle' |
Sets the vertical alignment of every cell in the table. Possible values
are top, middle, bottom.
|
| width |
string |
'100%' |
Takes any valid CSS values for the width property. By
default the table will stetch to 100% width of its parent container. By setting the value to
"auto" or an empty string ("") the table width will be determined by the contents. Note that if
the contents of the table or the number of columns requires the table to stretch wider than 100%
of available width of the containing element, the table will be as wide as it needs to be
regardless of the value of this setting.
|


2007-10-31
© OldMansBeard 2006, 2007
CleanModels 3 is a stand-alone program for detecting and repairing some commonplace faults in NWN tileset models. It works on uncompiled (ascii) models. It imports the models from a folder you specify, checks for about forty known types of fault, fixes those it can fix and exports the fixed models into an output folder. At the same time, it writes log files in the output folder listing all the faults it has identified, the fixes it has done and things that remain unfixed.
If there are any *_edge.2da files in the import folder, the program will read them to determine which tiles are edge tiles.
When it exports a fixed model, it also exports a fixed .wok file (unless it is an edge tile). The walkmesh aabb data is rebuilt using a similar algorithm to the one in Joco's NWmax, that is in turn based on the Bioware one.
The program is meant to be used in addition to all the other ways of checking and fixing tile models. It does not replace the sanity checks in NWmax nor the time-honoured procedure of running the models through nwnmdlcomp to see if they break. It checks for things that they do not do. It does not do anything that cannot be done manually; it just does it a lot faster and more reliably, thereby saving you time and trouble. See below for a detailed list of the things it checks and fixes.
Copy cleanmodels311.exe and the five .dll files to a convenient folder. Those five .dll files need to stay with the .exe. That's all you need to do to install it.
The program is written in SWI-Prolog (available free from www.swi-prolog.org) but is packaged as a stand-alone executable. The five dll files are a part of the SWI-Prolog package that can be redistributed freely with applications such as this.
Note that, if you are updating from Beta Version 1.1 of this program, you must use the five dll files from the updated package - the executable will not work with the older dll's.
Double-click the .exe.
Two windows will open. One is a console window and the other is a GUI panel.
The GUI allows you to specify the input and output directories, a filename pattern, names for two log files and some other options. The first time you run the program they will have default values that you will want to change. After that, each time you run the program it will offer the values you used last time, as a starting point.
If the output directory you specify does not exist, it will be created. It is unwise to set the output directory to be the same as the input because your original models will be over-written but the program will not prevent you doing it, if that's what you want to do.
Changing the filename pattern allows you to focus on part of a tileset or just a few models at a time it you want to. Wildcards work in the usual way. For example, setting it to tcxy0_a*.mdl would just process files in the "a" series in that set.
The first log file will record details of all the faults the program has identified and all the fixes it has done. It may be quite long but it is there so that you can see what kinds of faults the tileset had in it, that needed fixing. The second log file is a summary that only lists the remaining, unfixed faults that will need to be investigated and repaired manually. Serious errors that prevented a tile being exported at all are flagged in the summary file with "****" so that they can be found quickly.
When you click OK the GUI will disappear, the program will start running and a trace of what it is doing will appear in the other window. It will probably scroll past faster than you can read it - don't worry, it is all being copied into the detailed log file.
If the GUI does not disappear when you click OK, it probably means that you have specified an input directory that does not exist. Check and try again.
When the program finishes it will wait for you to hit the ENTER key before it closes the console window.
On a large tileset with many faults it may take several hours to complete but you can see how it is progressing because it processes the models in the input directory in alphabetical order. If you are cleaning up a raw tileset, don't be surprised if you see a lot of tverts being welded or deleted. This is a relatively slow process - a few thousand fixes a minute is about the best it will do.
If a tile model is very corrupt, it is possible for the import to hang. If this happens, note the last model file that is listed as having been exported and take a hard look inside the next one in alphabetical order. There's something very wrong with it.
If you want to kill the program abruptly, there are two ways. One is to type CTRL-C to interrupt it and then "e" to exit. The other way is just to click the [X] button on the window but you need to know that you have to click it twice. If you kill the program while it is exporting a model, that file may be incomplete and the last parts of the log files may not be written.
There are some menus along the top of the console window. Ignore them. They mostly won't do anything useful but I haven't worked out how to stop them appearing.
The program is quite demanding of processor power. If you find that you need to leave it running for a long time and you want to be able to use your computer for other things in the meantime, try this: open the Windows task manager, find the task cleanmodels311.exe, right click and set its priority to "below normal". It will continue to run at much the same speed, but your other applications will respond more normally. You would need to do this every time you run the program (Windows won't remember the setting).
The following conditions are pre-requisite
If a tile fails any of these, checking will continue but the model will not be exported and will need to be fixed manually before trying again.
The file must contain a tile model with the same name as the file.
The model must contain exactly one dummy node (the Aurora Base) with the same name as the model.
The Aurora Base must not be offset from the zero position or rotated.
The node hierarchy within the model must not be broken. Every node below the Aurora base must have exactly one parent.
If there are danglymesh nodes, they must have the right number of constraints.
There must not be more than two main lights and three source lights.
There must not be more than one walkmesh in the tile.
The walkmesh geometry must not have unrepairable colliding faces that prevent the aabb data being built.
The following conditions are checked and fixed automatically if necessary
The Aurora Base exists and has parent NULL but has no other parameters and no animation keys.
Edge tiles have no walkmeshes, lights, emitters or animations.
The 'a' node exists if it needs to, is correctly named for its tile, is parented directly to the Aurora Base, has position 0 0 0, orientation 0 0 0 0 and has no animation keys of its own.
Emitters descend from the 'a' node.
Main lights and source lights are parented directly to the Aurora Base, are correctly named for the tile, have distinct numbers in the allowed ranges and have no animation keys.
'D' and 'U' dummies are correctly named for the tile and have distinct numbers in the allowed ranges.
The walkmesh (if present) is parented directly to the Aurora Base, centred and snapped to the tile edges, has no animation keys and has a null bitmap and no tverts.
Main lights, source lights and walkmeshes have no child nodes. If they do, the child nodes will be moved onto newly-created dummy nodes in the same position.
Every node has a distinct name. Name clashes will be resolved, if possible, by adding numerical suffixes. This is not attempted if the duplicated nodes have child nodes (because the child nodes' parents would be ambiguous) or animation keys (because the keys might or might not apply to both).
Trimesh nodes with no faces are redefined as dummy nodes if they have descendants, otherwise they are deleted. Dummy nodes (other than 'U' and 'D' nodes) that have no descendants are likewise deleted.
Duplicate animations are combined and have their keys merged.
Animations are animrooted to the Aurora Base and have their lengths and transtimes defined. If not, a default length of 0 and transtime of 0.25 will be added.
Animations should only try to change parameters that can actually be animated (any extraneous parameters will be deleted).
If an imported tile model has fixed parameter values in animations (which is acceptable to the NWN engine) they will nevertheless be converted to the corresponding keys so that they will not be lost if the tile is subsequently re-imported into NWMax. If an animated node has both keys and a fixed value for the same parameter in the same animation, the fixed value will be ignored and the keys used.
Emitters (other than lightning emitters) should be correctly turned on/off by animations. If necessary, they will have birthratekeys of 0 added to a tiledefault or default animation and non-zero birthratekeys, derived from the value defined in the geometry, inserted into an animloop animation.
Lightning emitters are not animated (because turning them off and on again can cause toolset crashes) and if they have birthratekeys, those keys will be deleted.
If a node (other than an emitter) has animation keys for a particular parameter but none of the keys actually changes that parameter from the value defined in the geometry, all of those keys will be deleted.
Except for emitter birthratekeys, if animloop animations have keys that change a particular parameter away from the value defined in the geometry, the tiledefault or default animation must restore it. Keys will be added or corrected if necessary to enforce this.
If an animloop03 animation exists but animloop02 does not, an empty animloop02 will be created. Likewise, if animloop02 exists but animloop01 does not, an empty animloop01 will be created.
If any non-empty day, night, night2day or day2night animations exist, CM3 will ensure that all four exist by creating empty ones if necessary. If some exist but they are all empty, however, the whole group will be deleted together.
Otherwise, empty animations that have no remaining useful keys will be deleted.
If a day2night or night2day has a length less than 1 frame (0.0333333), its length will increased to that minimum value.
Missing end keys (for the time equal to the length of the animation) are fixed to keep the compiler happy. They are looped back to time zero in animloops otherwise they are equated to the last value given.
Nodes that have valid animation keys are re-parented if necessary to descend from the 'a' node.
Unrendered nodes should have NULL bitmaps and no tverts except that shadow meshes have their bitmaps set to 'black'. Rendered nodes that have NULL or missing bitmaps or bitmaps equal to their node names are also set to bitmap 'black'.
Black objects have ambient/diffuse set to 0 0 0. Optionally (set in the GUI), non-black objects can be forced to ambient/diffuse 1 1 1.
In trimesh, aabb and danglymesh nodes, after possible snapping (as selected in the GUI), co-incident mesh vertices are welded. Null and duplicate faces are then deleted followed by any unused vertices.
After possible snapping (as selected in the GUI), tverts are welded (except in animmesh nodes), UVW normalized relative to the origin and unused ones deleted.
Walkmeshes have inverted and degenerate faces deleted and (optionally) undercut faces repaired if possible before the aabb data is rebuilt.
Warnings
The following conditions are detected and a warning issued but no attempt to fix them is made. They should be checked manually.
Emitters with null or missing textures (may be wrong)
Lights with null or missing texturenames (may be wrong)
Lensflares with wrong numbers of parameters
Trimeshes that cannot be repivoted
Nodes (other than dummy nodes) with centroids outside the tile
Walkmeshes that project outside their tile boundaries
In the GUI, there is a radio button for "Snap" with options "Binary", "Decimal" and "None". The default is whatever you used, last time you ran the program.
If you choose "Binary", all mesh vertices and positions will be snapped to exact multiples of 1/128 metres (0.0078125) and exported to 7 decimal places. The ascii value exported will exactly represent the binary one and, whether you import the resulting tile into NWN or nwnmdlcomp or Gmax or back into CleanModels 3, the binary value inside that program will exactly correspond to it. So there is no loss of precision.
If you choose "Decimal", vertices and positions will be snapped to multiples of 0.01 metres and exported values will use only as many decimal places as necessary (thus saving characters in the ascii file).
The "Decimal" style corresponds to the behaviour of Gmax and NWmax. Although they work in binary floats internally, they can't export in binary precision. (Even if you select the "compile exported model" option, nwmax exports it in ascii first, discarding the precision, and then compiles it from that).
Which one is best, really depends on what you are going to do with the exported tiles. If you are going to load them straight into NWN or run them through nwnmdlcomp, binary precision is best. If you are going to re-import them into Gmax, you might as well use decimal precision (and save a few bytes of file size) because that is all you will get back out again anyway.
You should use the same precision across an entire tileset, otherwise you may get geometry mismatches between one tile and its neighbours in an area.
Snapping is done after orientations are reset and before repivoting. Vertices are held fixed in absolute position while node positions are snapped, then they themselves are snapped.
Note a change introduced in Beta 1.2 : snapping is not now applied to the positions of the parents of animmesh nodes, nor to the parents of nodes which have animated positions or positionkeys.
Bad pivots are one of the causes of shadow errors in tiles. The pivot of a mesh is regarded as "bad" if the mesh has any faces whose outward normals are directed towards the pivot rather than away from it.
Unless you set the Repivot option to "none" in the GUI, the program checks the pivots of all trimesh nodes that are set to shadow 1. If the program finds a bad pivot, it will try to fix it by moving the pivot to a position inside the mesh where it is no longer "bad". If it succeeds, it will say so in the detailed log. However, this is not always possible. A common example is a door frame or window frame where the sides are facing each other inwards. Wherever you put the pivot, it would be in front of at least one of the sides Often, these situations can be resolved by splitting the mesh into suitable pieces, each of which can be successfully pivoted. There is an option to allow the program to try to do this automatically for you.
The program will not attempt to repivot a node whose position or orientation is changed in an animation.
The program will not move a pivot to a position outside the XY boundaries of the tile. If it cannot find a place for the pivot within these limits, it will not move it.
The program will first compute the centroid of the centroids of the faces of the object, and test to see if that would be a satisfactory pivot. If it is, it will use it. Otherwise, it will compute the polyhedron within which the pivot must lie. If that polyhedron is convex it will use the centre of its bounding box as a pivot.
If snap is being used, the new position of the pivot will be snapped if possible. Sometimes, if the pivoting is critical, this is not possible. For example, if the program has calculated that the only possible position for a pivot is between 1.234 and 1.235, snapping it to 1.23 is not going to work. In this case, the pivot will be set to 1.2345 and the vertex co-ordinates, which are expressed relative to the pivot, will be released so that their absolute positions (relative to the rest of the tile geometry) can remain exact.
If you set the Repivot option to "all", the program will repivot nodes to conform to its own algorithms, even if their existing position is not actually "bad". This may be useful on a first pass through a raw tileset.
The memory needed to find the bounding polyhedron increases as the third power of the number of faces. For trimesh nodes of up to 150 faces, the program will use an exact algorithm that will certainly succeed in fixing the pivot if it is geometrically possible. Beyond 150 faces and up to 400 faces it will use a looser algorithm that is less memory-intensive and will usually succeed (about 99% of the time) but may occasionally fail. Beyond 400 faces it will not even try.
Occasionally, repositioning a difficult pivot may be achieved by exploiting rounding errors in the calculation of very small distances and the pivot may be placed the "wrong side" of a face by a microscopic distance. If this happens, a warning will be printed in the detailed log file.
If you turn on the "splitting" option, when the program fails to find a satisfactory pivot position for an object, it will split the object into parts that can each be pivoted separately. It creates new names for the parts by adding suffix numbers to the original node name (having checked that they are not already in use) and it randomises the wirecolors of the new objects. If it fails to repivot one of the parts (which can happen with a really twisted geometry) it will set its wirecolor to red (1 0 0).
When splitting an object, the program first separates isolated objects that are not connected to each other by common edges. If that isn't enough, it tries splitting objects into distinct smoothing group. Then it tries detaching pieces of floor and anything below them. After that, it looks for pieces that are entirely convex or entirely concave and detaches those. Finally it looks for groups of faces that form plane polygons. When it separates a piece, it checks to see if that piece and the remaining part can be pivoted. If they can, it need go no further. Otherwise, it will try splitting them again in another way.
There are some options in the GUI to control the splitting process. You can tell it to use smoothing groups, as described above, or to totally ignore them (if you think the tiles are not well smoothed anyway) or to protect smoothing groups and not allow them to be split further even if the pivot is still bad.
There is also a spinner to set the minimum size (number of faces) of pieces after splitting. Setting it to 4 is often a good choice but you might need to try different values on problematic tiles.
Usually, it works better for concave pieces to be identified before convex ones. For some geometries, however, it may be better to do it the other way around. The radio button in the GUI lets you to choose which way you want the program to do it. If you find a particular tile is problematic and the program seems to generate a large number of pieces which it can't repivot, try changing this option and running the original file through the program again.
Note a change introduced in Beta 1.5 : when splitting shadow meshes (trimesh nodes set to render 0 shadow 1), the option to protect smoothing groups is ignored for that node (because smoothing is meaningless if the node is not rendered) and the minimum piece size of 2 is used, regardless of GUI options. This is so that, if a node is so convoluted that it cannot be pivoted without breaking smoothing, you can try creating a shadow mesh for it that can be repivoted.
Another change introduced in Beta 1.5 : if a trimesh node cannot be successfully repivoted, even with splitting, the pivot is moved to the centroid of the bottom-most vertices of the mesh. This quite often, but not always, resolves remaining shadow errors but a warning is still printed in the log because visual inspection of the shadows on the tile will still be needed.
There is an option in the GUI to "Repair Walkmesh Overhangs". If you enable it, the program will attempt to adjust walkmesh vertices horizontally to remove tucks and folds and re-align overhanging faces to have positive slopes. It will typically succeed in about 90% of cases but sometimes the mesh may be too badly twisted for it to know what to do and you will get a warning that the walkmesh still has mis-oriented faces. This feature should be regarded as still somewhat experimental and if you do use this option, you are advised to check the walkmesh visually afterwards in case it has been distorted inappropriately.
When repairing overhangs, the program straightens any zigzag lines of vertices down tile edges first, before adjusting interior vertices. It will straighten identical zigzigs in identical ways on all tiles so that if the walkmesh was continuous across certain tile boundaries before the repairs, it will still be continuous afterwards. This continuity may be lost, however, if not all tiles in the tileset are processed or if the meshing of the tile edges was already inconsistent. In such cases, the "Interior only" option should be used. This will ensure that tile-edge vertices are not moved at all. This may mean that fewer face overhangs can be repaired by the program and more work will have to be done by hand-crafting, but it does avoid the risk of causing disjunctions in the walkmesh between tiles that had not been present before.
When reporting inverted aabb faces that it could not fix, the program lists their face numbers. Note that faces in NWN are numbered from zero. If you look for those faces in GMax, you have to add 1 because GMax numbers faces from 1. Inverted faces are sometimes very small or hidden behind other faces and hard to see, so this may help to track them down.
An option to "Apply Water Fixups" was introduced in Beta 1.5. The program recognises water surfaces by their bitmap names. It has some Bioware texture names built-in but it will also look for a special substring (the "key") in every bitmap name. By default the key is "water" and this works for most tilesets but you can change this in the GUI if your tileset uses some other convention. There are two sub-options:
(1) The "Dynamic Water" sub-option means that you want the program to ensure that water surfaces descend from the tile's 'a' node. The program will create the 'a' node if it needs to and move water meshes up and across the hierarchy as appropriate. You should enable this option if there is walkable water (such as stream and pools) in the tileset. Note, however, that this fix will only be applied to trimesh nodes, not animmesh nodes, and will not be applied to edge tiles.
(2) When water connects across tile boundaries, it tends to look better if the bitmap keeps the same compass orientation regardless of rotations of the tiles. You can achieve this by setting rotatetexture to 1 on all the water surface meshes. The program can do this for you automatically if you wish. Otherwise, you can set it to 0 (not recommended) or leave it alone.
The dynamic water sub-option can also be used to force nodes rendered with other semi-transparent bitmaps to the 'a' node. For example, if the key is set to "treefol", it will catch the leafy umbrellas of trees in most tilesets.
#comments are discarded.
Spurious tokens at the ends of data lines are tolerated but ignored.
Embedded spaces in node names are removed.
The filedependency is reset to "Unknown".
Mis-spelt parameters are interpreted if possible. e.g 'sahdow' is understood as 'shadow', 'coclor' as 'color' and the widespread 'setfillumcolor' as 'selfillumcolor'. "n_Dynamic_Type" is understood to mean "nDynamicType".
Parameters that are not relevant to the current node are discarded, e.g. danglymesh tightness on a trimesh node.
In animations, empty lists of keys are discarded, as are references to nodes that were not defined in the geometry.
In animations for animmesh nodes, repeated verts, faces and tverts are discarded.
Orthogonal orientations are snapped to exact multiples of π/2. The snap zone is ±0.9 degrees.
If a parameter is defined more than once, the last value is taken and the preceding ones are ignored.
If a line is not understood at all it is printed out and the loading continues but the file is flagged as "load failed".
Spurious lines at the end of the file after the "donemodel" line are ignored but a warning is printed in the log.
Minimal comments are added.
setanimationscale is set to 1 if not defined otherwise.
Nodes are output in depth-first order descending from the NULL parent.
Emitter parameter names are output in "camel" capitalisation, e.g. colorStart, alphaEnd.
The aabb data in walkmesh nodes is rebuilt. Multimaterial lists on walkmesh nodes are discarded.
In animmesh node animations the verts, faces and tverts, taken from the modelgeom data, are repeated before the animvert and animtvert data.
If binary precision is chosen, floating-point numbers are output to 7 decimal places.
If decimal precision is chosen, floats are output in short form with up 6 significant figures.


Rice EMS operates as a branch of the Rice University Police
Department. The RUPD Chief also serves as the Director of Public
Safety for Rice University.
Chief Whitehead is a graduate of the FBI National Academy,
the Federal Executive Institute and the Harvard University
Kennedy School of Government Crisis Leadership in Higher
Education Program. He has a bachelor's degree in political
science from the University of Baltimore and a master's in
applied behavioral science from Johns Hopkins University.
Our Medical Directors are Emergency Physicians committed to
excellence in Emergency Medicine and EMS. Some of them are
alumni of Rice University and Rice EMS. They are available
around the clock to provide emergency medical direction
for the On-Duty Campus Crew.
The EMS Director is responsible for supporting REMS
administration needs (budgeting, special projects, etc.)
and ensures long-term projects are completed.
Lisa is a Licensed Paramedic, with more that fifteen years
experience in EMS. She served as a paramedic, EMS Educator,
and EMS Administrator in the Greater Philadelphia area
prior to moving to Houston. She is a graduate of Marquette
University ('93) and Villanova University ('05).
The Rice EMS Captain is the highest-ranking student in Rice
EMS. The Captain is responsible for all patient care and
operational aspects of the department, overseeing the works
of the Lieutenants.
The Senior Lieutenant is the second-in-command of Rice EMS.
The Senior Lieutenant assists the captain in overseeing all
aspects of patient care, operations, and education offered
by Rice EMS.
Several alumni of Rice EMS, physicians in the Texas Medical
Center, and EMS providers in Houston area contribute their time
and expertise to help Rice EMS Education and Special Event
programs.
The InCharge is an operational rank referring to the EMT who is
in command of a scene. The On-Duty InCharge responds in the
marked Rice EMS vehicle that carries advanced medical equipment.
The InCharge approves all patient care decisions during his/her
shift. The InCharge is an EMT-Intermediate with Advanced Life
Support training.
The rank of Lieutenant is given to members of the department
who are responsible to managing different administrative areas
of the organization, and have additional responsibilities which
include everything from scheduling special events coverage to
running the EMS Education Program.
Duty Crew members are the backbone of Rice EMS, and include both
EMT-Basics (BLS - Basic Life Support training) and
EMT-Intermediates (ALS - Advanced Life Support training).
Duty Crew members respond to campus emergencies along with the
InCharges. Duty Crew members can also be cleared to work Special
Events (athletic events, Baker Institute events, public parties,
etc.) and become BLS Instructors (teach CPR/First Aid classes).


{load href="__STATIC__/layui/css/layui.css"} {load href="__STATIC__/index/js/jquery-1.11.1.min.js"} {load href="__STATIC__/layui/layui.js"} {block name="css"}{/block} {block name="script"}{/block}
{//include file="public::header" /} {//include file="public:header" /} {//include file="public:top" /} {include file="public/nav" /} {block name="body"}{/block} {include file="public:footer" /} {block name="js"}{/block}


settings
User Profile
Username
Email
Phone Number
Priority
Normal
Urgent
Critical
send
search
Add User
Sample User 1
Sample User 2
Sample User 3
Sample User 4
Sample User 5


--- layout: post status: publish published: true title: 'SPListAnalysis: A sample DebugDiag v2.0 Analysis Rule' author: display_name: Tomas Restrepo login: tomasr email<EMAIL_ADDRESS>url: http://winterdom.com/ author_login: tomasr author_email<EMAIL_ADDRESS>author_url: http://winterdom.com/ wordpress_id: 1370 wordpress_url: http://winterdom.com/?p=1370 date: '2013-10-06 20:25:39 +0000' date_gmt: '2013-10-06 20:25:39 +0000' categories: - Tools tags: [] comments: - id: 27134 author: 'The Morning Brew - Chris Alcock » The Morning Brew #1457' author_email: '' author_url: http://blog.cwa.me.uk/2013/10/07/the-morning-brew-1457/ date: '2013-10-07 07:54:31 +0000' date_gmt: '2013-10-07 07:54:31 +0000' content: "[…] SPListAnalysis: A sample DebugDiag v2.0 Analysis Rule - Tomas Restrepo takes a look at the creation of custom analysis rules for the newly released DebugDiag 2.0, discussing a sample rule code sample. […]" ---
DebugDiag is a tool for collecting and
analyzing memory dumps. Version 2.0 was just
released and makes it extremely easy to write your own custom analysis rules using any language
that target the CLR.
SPListAnalysis is a sample analysis rule I implemented to show the basic steps involved in the process.
The rule does the following:
The code for this sample can be found here.
This particular sample if very simple, consisting of a single class called SPListAnalysis
,
which implements the IHangDumpRule
interface to process one dump at a time. It also implements the
IAnalysisRuleMetadata
interface to define the category and description for this analysis.
[caption id="attachment_1371" align="alignnone" width="755"] DebugDiag Analysis[/caption]
The basis for the analysis is looking at all threads that contain a significant function in the
call stack, and then looking for a matching object in the stack frames (similar to doing a !DumpStackObjects
)
command):
private void RunSPListAnalysis(NetDbgObj debugger)
{
// initialize report
foreach ( var thread in debugger.Threads )
{
AnalyzeThread(thread);
}
// report findings
}
private void AnalyzeThread(NetDbgThread thread)
{
// ...
if ( ContainsFrame(thread, SPLIST_FILL_FRAME) )
{
//...
dynamic obj = thread.FindFirstStackObject("Microsoft.SharePoint.SPListItemCollection");
if ( obj != null )
{
String viewXml = (string)obj.m_Query.m_strViewXml;
//...
XDocument doc = XDocument.Parse(viewXml);
AnalyzeViewXml(thread, doc);
//...
}
PrintThreadStack(thread);
}
}
Reporting the results is mostly a matter of generating HTML. However, we can also generate
warnings that are included at the top of the report, allowing us to quickly alert the user
that something of interest was found in the dump:
private void ReportThreadsWithLargeSPQueries()
{
if ( threadsWithLargeSPQueries.Count > 0 )
{
StringBuilder sb = new StringBuilder();
sb.Append("The following threads appear to be executing SPList queries requesting many fields.");
sb.Append("
"
);
foreach ( int threadId in threadsWithLargeSPQueries.Keys )
{
sb.AppendFormat("
{0} ({1} fields) ",
threadId, threadsWithLargeSPQueries[threadId]);
}
sb.Append("");
this.manager.ReportWarning(sb.ToString(), "");
}
}
The resulting report will look like this:
[caption id="attachment_1372" align="alignnone" width="691"] DebugDiag Warnings[/caption]
Enjoy!


Search by Street address or latitude and longitude, if you enter a address search will prefer that
Cheese and rice


{{user?.ShippingAddress?.Fname}} {{user?.ShippingAddress?.Lname}}
{{user?.ShippingAddress?.Street}} {{user?.ShippingAddress?.aptNo}}
{{user?.ShippingAddress?.City}} {{user?.ShippingAddress?.Province}}
{{user?.ShippingAddress?.Country}} {{user?.ShippingAddress?.PostalCode}}
{{user?.BillingAddress?.Fname}} {{user?.BillingAddress?.Lname}}
{{user?.BillingAddress?.Street}} {{user?.BillingAddress?.aptNo}}
{{user?.BillingAddress?.City}} {{user?.BillingAddress?.Province}}
{{user?.BillingAddress?.Country}} {{user?.BillingAddress?.PostalCode}}
| Product | QTY | Price | Total |
|---|---|---|---|
|
{{prod.listingName}} (Stock: {{ prod.listingStock }}) by: {{prod.listingUsername}} |
{{ amount }} Update Missing quantity of order No Viable Quantity Entered Not Enough Stock |
${{displayPricePer}} | ${{displayPretax}} |
Order Summary
Make sure your selected quantity is correct.
Secure Checkout
Shopping is always safe and secure.


. Instances of log4cxx::logstream are not designedfor use by multiple threads and in general should be short-lived function scoped objects. Using log4cxx::basic_logstream as a class member or static instance should be avoided in the same manner as you would avoid placing a std::ostringstream in those locations. Insertion operations are generally short-circuited if the level for the stream is not the same of higher that the level of the associated logger.
Public Member Functions | |
| wlogstream (const log4cxx::LoggerPtr &logger, const log4cxx::LevelPtr &level) | |
| Constructor. | |
| wlogstream (const Ch *loggerName, const log4cxx::LevelPtr &level) | |
| Constructor. | |
| wlogstream (const std::basic_string< Ch > &loggerName, const log4cxx::LevelPtr &level) | |
| Constructor. | |
| ~wlogstream () | |
| wlogstream & | operator<< (std::ios_base &(*manip)(std::ios_base &)) |
| Insertion operator for std::fixed and similar manipulators. | |
| wlogstream & | operator<< (logstream_manipulator manip) |
| Insertion operator for logstream_base::endmsg. | |
| wlogstream & | operator<< (const log4cxx::LevelPtr &level) |
| Insertion operator for level. | |
| wlogstream & | operator<< (const log4cxx::spi::LocationInfo &location) |
| Insertion operator for location. | |
| wlogstream & | operator>> (const log4cxx::spi::LocationInfo &location) |
| Alias for insertion operator for location. | |
| operator std::basic_ostream () | |
| Cast operator to provide access to embedded std::basic_ostream. | |
| template<class V> | |
| log4cxx::wlogstream & | operator<< (const V &val) |
| Template to allow any class with an std::basic_ostream inserter to be applied to this class. | |
Protected Member Functions | |
| virtual void | log (LoggerPtr &logger, const LevelPtr &level, const log4cxx::spi::LocationInfo &location) |
| Dispatches the pending log request. | |
| virtual void | erase () |
| Erase any content in the message construction buffer. | |
| virtual void | get_stream_state (std::ios_base &base, std::ios_base &mask, int &fill, bool &fillSet) const |
| Copy state of embedded stream (if any) to value and mask instances of std::ios_base and return fill character value. | |
| virtual void | refresh_stream_state () |
|
|
Constructor.
|
|
|
Constructor.
|
|
|
Constructor.
|
|
|
|
|
|
Erase any content in the message construction buffer.
Implements logstream_base. |
|
|
Copy state of embedded stream (if any) to value and mask instances of std::ios_base and return fill character value.
Implements logstream_base. |
|
|
Dispatches the pending log request.
Implements logstream_base. |
|
|
Cast operator to provide access to embedded std::basic_ostream.
|
|
|
Template to allow any class with an std::basic_ostream inserter to be applied to this class.
|
|
|
Insertion operator for location.
|
|
|
Insertion operator for level.
|
|
|
Insertion operator for logstream_base::endmsg.
|
|
|
Insertion operator for std::fixed and similar manipulators.
|
|
|
Alias for insertion operator for location. Kludge to avoid inappropriate compiler ambiguity. |
|
|
Implements logstream_base. |


Our Mission
Programs
Who We Are
Contact Us
Register Now
Our Mission
Programs
The Teachers
Contact Us
Register Now
Register
We are currently setting up the online registration form. If you wish to register for one of our outstanding programs, do not hesitate to
contact us!

Programs
Take a look at our selection of effective tutoring programs
Meet the Teachers
Meet the stars who will make your student a superstar!
FAQs
Get quick, clear answers to the most common questions


Home
Work
Contact
T4F Kit
Assistive Products
MKplayer 360
Immersive Technology
Camera T4F
Wearable Assistive Device
Metal Brand
Origami Home Furniture
Trimmer 1
Beauty & Personal Care
Track One
Autonomous Driving Challenge


Mayor Hylan, accompanied by the
heads of many of the city departments,
yesterday formally opened the munici-
pally owned and operated ferry from
East Ninety-second Street to Astoria.
Civic and business organizations of
Yorkville and Astoria, including 3,000
school children, joined in the celebra-
tion.
Members of the Chambers of Com-
merce of Yorkville and Astoria and a
deligation from the Real Estate Own-
er's Association of the 12th and 19th
Wards met the Mayor and his official
party at Pier A, Battery, and escorted
them on board the sea-going tug John
F. Hylan and the police boat Patrol.
Accompanied by the reconstructed
ferryboats Bowery Bay and Harlem,
which are to be used in the new serv-
ice, the official flotilla sailed around
the end of Manhatten Island and up
the East River to Ninety-second Street.
All the way up the boats were greeted
with the blasts of whistles from the
river craft and the fire gongs along
the shore were sounded.
A parade was formed, headed by the
Mayor, which marched through the
Yorkville section to the ferry house,
where the Mayor brought the first ticket
on the reëstablished ferry line. Prior
to the procession the city officials were
welcomed by a committee of citizens
and were the guests at luncheon of the
Yorkville Chamber of Commerce. Jus-
tice Robert F. Wagner, of the Supreme
Court, delivered a speech of welcome
to the city officials. Ralph A. Brown,
president of the Yorkville Chamber of
Commerce, presided at the luncheon.
The Yorkville section was gaily
decorated. School children along the
line of march sang as the procession
passed. The Mayor, Commissioner
Grover A. Whalen of the Department
of Plant and Structures who has
charge of the ferry operation; Borough
President Maurice E. Connolly of
Queens and other city officials dropped
out of the parade at Eighty-sixth
Street and Lexington Avenue and took
places in the reviewing stand erected
at that point. The parade reformed
after luncheon and marched to the
ferry house, over which Mayor Hylan
raised the flag of the City of New
York. He and his guests then went
on board the ferryboat Bowery Bay,
which made the first trip in the re-
sumption of ferry service between
Manhatten and Astoria.
The ferry was previously operated
by the East River Ferry Company
which ceased operation on December
31, 1918. The city bought the old boats,
reconstructed them, put the ferry
slips in good condition and is resuming
the service as a municipal undertaking.
This is a link to my annotated Markdown page that transcribes the first few paragraphs of the article and includes
a link to an image of the article as it appearned in the New York Times.


An exception in Java is, as defined by Oracle, an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions.
As such, exceptions are used to provide relevant information to the developper and recover or crash nicely after an unwanted states has been reached.
Practically, exceptions are objects which are instantiated, like new NullPointerException()
, and thrown when the unexpected event occurs, after which instructions are ignored and the exception-related information propagated, leading usually to some rich display in the console for debugging.
In this post, we will see that throwing an exception involves two fundamental actions, instantiation and throwing, which both relate to different requirements and, consequently, should not systematically be done together.
In this post, we will work on an example inspired from the jMetal framework, which provides various algorithms to solve various kinds of problems. In this framework, built initially in a research environment, one may want to experiment several algorithms on several problems, to compare the algorithms and see which is more efficient in which context. Following this idea, programming an experiment may go as follows:
In this context, a standardised procedure can be implemented to help the experimenter focus on the relevant stuff only. In particular, such a framework can provide an experiment builder which takes from the experimenter \(N\) algorithms, \(M\) problems, and combine them automatically into \(N \times M\) pairs to run. However, we cannot naively reuse algorithm and problem instances in each pair, like running an algorithm on one problem and then on another, until we have run it on each problem. Such a constraint can occur because algorithms should be runnable in parallel, or because algorithms may not have as a requirement to be reusable. This means that we need to create several instances of each, like 3 instances of the same algorithm to solve 3 different problems. Such an experiment builder might look like this:
// Create the experiment builder
ExperimentBuilder builder = new ExperimentBuilder();
// Tell which problem to solve
builder.addProblem(() -> new Problem1());
builder.addProblem(() -> new Problem2());
builder.addProblem(() -> new Problem3());
// Tell which algorithm to use for that
builder.addAlgorithm(() -> new Algorithm1());
builder.addAlgorithm(() -> new Algorithm2());
builder.addAlgorithm(() -> new Algorithm3());
// Configure various actions to do with the data
...
// Instantiate the experiment and run it
Experiment experiment = builder.build();
experiment.run();
This code is significantly simplified for the sake of this post, but the important point here is that, in order to let the builder manage the instantiation of the (algorithm, problem) pairs, we do not add algorithm and problem instances directly but suppliers (through lambda expressions), which are pieces of code providing instances on demand.
Since Java 7, it can be implemented through the functional interface java.util.function.Supplier
, although it could be done already before through custom interfaces, minus the convenient format of lambda expressions.
This Supplier
interface looks like this:
public interface Supplier<T> {
T get();
}
As such, it is rather simple: it simply allows to access a ressource of a given type.
In our code, each supplier generates a new instance, leading to provide a supplier for each algorithm and problem (\(N + M\)) in order to let the builder produce all the needed pairs (\(N \times M\)) without reusing the same instances.
Depending on the implementation of the builder, these instantiations could be done when calling builder.build()
or experiment.run()
, but for the sake of simplicity, we will say that it is done in the former.
Then, we take the perspective of the framework, which implements the builder. This builder receives suppliers from the experimenter and should use them to generate the (algorithm, problem) pairs, which can be done with the following code:
Collection<Supplier<Problem>> problemSuppliers = new LinkedList<>();
Collection<Supplier<Algorithm>> algorithmSuppliers = new LinkedList<>();
public void addProblem(Supplier<Problem> supplier) {
problemSuppliers.add(supplier);
}
public void addAlgorithm(Supplier<Algorithm> supplier) {
algorithmSuppliers.add(supplier);
}
public Experiment build() {
// Create independent (algorithm, problem) pairs
Collection<Pair<Algorithm, Problem>> pairs = new LinkedList<>();
for(Supplier<Problem> supP : problemSuppliers) {
Problem problem = supP.get();
for(Supplier<Algorithm> supA : algorithmSuppliers) {
Algorithm algorithm = supA.get;
pairs.add(new Pair(algorithm, problem));
}
}
// Create the experiment based on them
Experiment experiment = ...
return experiment;
}
The code above is minimal, and the goal now is to identify unwanted cases to manage through exceptions. We will look at them separately in the next sections.
One potential issue is receiving null
suppliers for algorithms or problems.
This is a usual case, which can be solved by throwing a NullPointerException
in the corresponding method.
In the case of the algorithms, we would replace this:
public void addAlgorithm(Supplier<Algorithm> supplier) {
algorithmSuppliers.add(supplier);
}
by this:
public void addAlgorithm(Supplier<Algorithm> supplier) {
if (supplier == null) {
throw new NullPointerException("No supplier provided");
} else {
algorithmSuppliers.add(supplier);
}
}
Since Java 7, we can also use some helpers to do the same in a shorter way:
public void addAlgorithm(Supplier<Algorithm> supplier) {
Objects.requireNonNull(supplier, "No supplier provided")
algorithmSuppliers.add(supplier);
}
In the following, we won't consider using this facility to remain with an explicit exception. The important point here, however, is to notice that we instantiate our exception on the fly, and only if it is required. We will see later that it is not the only relevant use, though.
A second unwanted case is when the supplier itself returns null
.
We need a supplier, but when we call it we also need to obtain a proper problem or algorithm instance.
In the case of a problem, we may argue that such guarantee is not required for some cases, so we will ignore it and focus on the algorithms.
Indeed, an algorithm must be a runnable thing, and thus cannot be null
by definition.
To check this, we can do it in several manners.
The first solution is, like the first exception, to check it immediately, like this:
public void addAlgorithm(Supplier<Algorithm> supplier) {
if (supplier.get() == null) {
throw new NullPointerException("The supplier cannot return null");
} else {
algorithmSuppliers.add(supplier);
}
}
The problem of this solution is that it is over-constrained.
Indeed, nothing forbids the experimenter to provide a supplier which takes its instances from another source, not yet initialised at the time we use the builder.
In this case, the supplier won't be able to provide an instance yet, and thus throw an exception or return null
.
The point is that we impose on the experimenter to guarantee that the suppliers can be used immediately, although we initially need them to be usable only when instantiating the pairs, thus when we build or run the experiment.
So we need to find a better choice.
A second choice is, instead of checking the source, checking the usage, which moves us to the build()
method.
We may replace this:
public Experiment build() {
// Create independent (algorithm, problem) pairs
Collection<Pair<Algorithm, Problem>> pairs = new LinkedList<>();
for(Supplier<Problem> supP : problemSuppliers) {
Problem problem = supP.get();
for(Supplier<Algorithm> supA : algorithmSuppliers) {
Algorithm algorithm = supA.get;
pairs.add(new Pair(algorithm, problem));
}
}
// Create the experiment based on them
Experiment experiment = ...
return experiment;
}
by this:
public Experiment build() {
// Create independent (algorithm, problem) pairs
Collection<Pair<Algorithm, Problem>> pairs = new LinkedList<>();
for(Supplier<Problem> supP : problemSuppliers) {
Problem problem = supP.get();
for(Supplier<Algorithm> supA : algorithmSuppliers) {
Algorithm algorithm = supA.get;
if (algorithm == null) {
throw new NullPointerException("The supplier cannot return null");
} else {
pairs.add(new Pair(algorithm, problem));
}
}
}
// Create the experiment based on them
Experiment experiment = ...
return experiment;
}
Now, we really check it at the right time, but several criticisms can be made.
We may criticise the elegance of this code, which becomes heavier, especially if we have to do it with problems too, but this check will anyway have to be done, so it is not relevant.
A practical criticism is a matter of responsibility: this is normally the method addAlgorithm()
which should ensure that we obtain a valid supplier, but here we delegate this responsibility to build()
, which is not recommended.
It might seem useless here, because we only move a piece of code, but this choice means that, if we need to use these suppliers in other places of the builder, we need to repeat the same check there, and thus to write redundant code.
It would be preferable to have it in one place, and the most relevant place to factor it is where we receive it.
Second, the help provided by the exception is diminished, but to understand that we need to see what would be the consequence of such an implementation.
An exception is not just a way to interrupt the program cleanly, it is also an important source of information for debugging.
This information is composed of 2 fundamental pieces.
The first one is the message of the exception, which tells what went wrong, like "No supplier provided" or "The supplier cannot return null" in the code we wrote previously.
If we know that something wrong occurs in addAlgorithm()
, descriptions like these allow to understand clearly what we did wrong with it, and fix it properly.
But again, only if we know that it went wrong in this method, which is what provides the second piece of information.
This one is the stack trace, which tells which method has generated the exception, by being called from which method, which has been called by which method, and so on until the root main()
method (or thread).
If the message can be easily adapted in the code, and thus is mainly a matter of linguistic skill, the stack trace however depends on where the exception has been instantiated.
In particular, instantiating the exception in addAlgorithm()
would have lead to this kind of stack trace:
java.lang.NullPointerException: The supplier cannot return null
at ExperimentBuilder.addAlgorithm(ExperimentBuilder.java:157)
at ExperimentBuilder.main(ExperimentBuilder.java:322)
while moving it to build()
lead to have something more like this:
java.lang.NullPointerException: The supplier cannot return null
at ExperimentBuilder.build(ExperimentBuilder.java:183)
at ExperimentBuilder.main(ExperimentBuilder.java:322)
Knowing that a supplier returns null
in build()
is, however, not as helpful: the issue could come from a faulty supplier in addAlgorithm()
, or because we did something wrong with other methods used before build()
.
The faulty one is indeed the call to addAlgorithm()
, which received an invalid supplier, and thus the best stack trace is the one leading to this method.
As opposed to a usual case (if condition, throw new exception), this check on the returned value of the supplier requires us to properly decompose our exception management.
Indeed, if we remain with the current structure, whether we do it in the right method (addAlgorithm()
) but with an over-constrained parameter, whether we move it elsewhere but with a stack trace which does not help to spot the actual source of the mistake and a potential need of redundant code.
In order to have both advantages, we can adopt an adaptive strategy, where we choose one of the two to have its advantage, and enforce somehow the second through some tricks.
If we choose to put it in build()
, we need to enforce the stack trace to lead to addAlgorithm()
in its last line, but we also need to adapt the rest of the stack trace to spot the right call of the method.
Indeed, an experimenter usually add several algorithms, and thus call several times the method, so we need to find which call is faulty in order to help at best the debugging, which seems clearly cumbersome with the need of manual traces and so on.
With the addition of potential redundant code, which means that we should try to factor it in a dedicated method to reuse, it seems that such a solution is a no go for managing a single kind of exception.
Rather, we may choose to instantiate the exception in addAlgorithm()
to have the right stack trace from the start, the challenge being to check the returned value and throw the exception in build()
.
Instantiation is straightforward, we just need to have this line somewhere in addAlgorithm()
:
NullPointerException exception = new NullPointerException("The supplier cannot return null");
In order to check and throw in build()
, we may need to store this exception in a field of the class and use it in build()
at check time.
However, as we said earlier, addAlgorithm()
need to be called several times, and each call needs its own exception to have the right stack trace, which leads precisely to this call.
Instead of a single field, we may use a Map<Supplier<Algorithm>, NullPointerException>
to assign to each supplier (and thus each call) its own exception.
Such a solution works, but we remain with an issue: the check is still done in build()
, and thus the potential need to reproduce the check elsewhere through a redundant code occurs again.
One way to factor it is to create a dedicated method to reuse, which is only partially satisfying because we still need to think about calling this method when we add a piece of code needing it.
As we said earlier, this is addAlgorithm()
which is responsible of obtaining a valid supplier, and as such the best solution is to implement the check in this method, in such a way that the check is actually done wherever it might be useful, automatically.
Is it only possible? Yes, it is, and here we do it by using a decorator, which consists in wrapping the supplier we get into another supplier which does something more than just returning the instance.
Here is the code:
public void addAlgorithm(Supplier<Algorithm> supplier) {
NullPointerException exception = new NullPointerException("The supplier cannot return null");
Supplier<Algorithm> decoratedSupplier = new Supplier<Algorithm>() {
@Override
public Algorithm get() {
Algorithm algorithm = supplier.get();
if (algorithm == null) {
throw exception;
} else {
return algorithm;
}
}
};
algorithmSuppliers.add(decoratedSupplier);
}
Here, we only create an auto-checking supplier which builds on the supplier provided in argument.
In other words, we create a supplier which calls the one provided, checks whether or not the value is valid, and returns it or throws an exception depending on the answer.
This way, every time it is called, it checks by itself its own value and throw our exception if required, or return the instance as usual if all is fine.
Because we replace the provided supplier by the decorated one, any other piece of code using the supplier will necessarily pass through the auto-check, without even knowing about it.
An important point, however, is to keep the exception instantiation directly in addAlgorithm()
, out of the decorator definition, otherwise it will take the stack trace at the time it will be called, which means the stack trace of the user, like build()
, which is not what we want.
In other words, even now the instanciation of the exception is separated from throwing it.
With this solution, we preserve all the code into addAlgorithm()
, so the responsibility is fully managed by this method, and satisfy both our requirements of having a relevant stack trace and a just-on-time check.
However, this solution comes with a cost too: instead of instantiating the exception only when it is required, we need to do it in advance.
Here, the exception is created anyway, as soon as we call addAlgorithm()
, and it is done every time we call it, even if the supplier is valid.
This means that we take additional space in memory to improve debugging, leading this solution to be worth few instances, but costly with a growing amount of calls to manage.
We can conclude from this example that instanciating the exception and throwing it are 2 different responsibilities.
The instanciation should be done by the method which is in charge of validating the data, independently of when this data will be checked.
Here, the data we provide is a supplier, and the method which should ensure that it is valid is addAlgorithm()
, so we instantiate the exception there.
This method then should validate the supplier in 2 ways: ensuring that it is not null
, and ensuring that the value it returns is not null
.
Whether we use a single exception or two different exceptions is a matter of design choice, but in any case they should all be instantiated by addAlgorithm()
to drive the programmer to the actual faulty method.
Throwing the exception, however, should be done as soon as the data to check is available, and thus by the one receiving it.
The one receiving the supplier is addAlgorithm()
, thus it should be the one throwing an exception if the supplier is null
.
The one receiving the value of the supplier, however, is build()
, which requests the instances to create the pairs.
This is the one which should throw the exception if the supplier returns a null
value.
Here, we were able to factor this code in addAlgorithm()
, but whether or not such factoring is always possible is a different topic.


Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever.
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever.
Created by BlackTie.co - Attribution License 3.0 - 2013


62.0.3202.94-2: Binaries for macOS 64-bit x86
Navigation: Front page / Releases / macOS / 64-bit x86 / 62.0.3202.94-2
Release Information
- Author: tectiv3 (view all releases from user)
- Publication time (in UTC):
2017-12-19 01:23:48.515949+00:00
- Installation instructions: (unspecified)
- Notes: There are no code changes between this build's source code and the tag 62.0.3202.94-2. NOTICE: This build has been removed due to stability issues. See #315 for more details.
Downloads


CALCULATE YOUR PRICE
1. Choose a category for your video:
Wedding
Corporate
Travel
2. What is the length of the raw footage you will be providing?
< 30 min
31-60 min
61-90 min
91-120 min
121-180 min
> 180 min
3. Would you like to add some pictures?
Yes
No
4. When do you want us to send the first cut of your video?
48 hours
7 days
Calculate


Overview
How It works
- The Browser connects to the desired url which is in the form of http://localhost:3000 (if you're in a development environment) or the site name.
The Connection is handled by Express which uses the consolidate.js library to render the server side application markup (the default templating engine is swig).
- Page is returned to browser - The page rendered contains the inclusion of the angular.js library(among others). The markup contains an "ng-view" tag which is where the angular app initializes.
Directory Structure
Overview placeholder
Directory Structure
system
auth
articles


Settings
Profile
Configure
Logout
Back
Home
Baby
Tips
Settings
Log Out
Are You Sure want to log Out?
Yes
No


Money Play. How should Red play 42?
pips Red=141 White=117
(CorrectAnswer= 0/0, ErrorScore= 0)
Everyone got this right. Red just doesn't have the timing for a back game and bar/21, 23/21 is clearly correct. Only an optimist would play bar/23, 6/2.
Interestingly at DMP the optimist would be tied with everyone else as bar/23, 6/2 is just as good as bar/21, 23/21.
Interestingly at DMP the optimist would be tied with everyone else as bar/23, 6/2 is just as good as bar/21, 23/21.
1. Cubeful 2-ply bar/21 23/21 Eq.: -0.662 0.172 0.011 0.000 - 0.828 0.075 0.001 2. Cubeful 2-ply bar/21 7/5 Eq.: -0.700 (-0.038) 0.171 0.018 0.000 - 0.829 0.117 0.002 3. Cubeful 2-ply bar/21 6/4 Eq.: -0.703 (-0.040) 0.172 0.018 0.000 - 0.828 0.122 0.002 4. Cubeful 2-ply bar/21 4/2 Eq.: -0.710 (-0.047) 0.172 0.018 0.000 - 0.828 0.127 0.002 5. Cubeful 2-ply bar/23 6/2 Eq.: -0.713 (-0.050) 0.187 0.021 0.000 - 0.813 0.167 0.003


Cultural Blog - Triggers
How did the trigger training exercises feel?
As this stuff is quite new to me, I won't pretend that I fully understand the details of the process. I generally find it quite hard to try to relax and focus, while at the same time having to read instructions for what should happen next. I am sure that many people who are new to this find the same thing. With time and practice this is likely to become easier and more effective. That said, it was interesting to experience a little of the emotions relating to a previous event.
Did you notice any responses in yourself?
I sensed a mild change in breathing - breaths became shorter and shallower - a tensing of the stomach, and an increase in blood pressure around my head and neck.
What emotion do you want to befriend?
It would be nice if I could befriend "Irritation"! As I am frequently interrupted when doing a task, it would be very useful to be able to ignore interruptions without being agitated by "Irritation". I hope I could then quickly regain my train of thought and resume work!


Home
About
PASSWORD!
Your password: {{ password }}
50
20
18
16
12
10
Uppercase
Numbers
Special Characters


You're Killing me Smalls - About | Facebook
Have you ever watched "The Sandlot"? "You're killing me,Smalls" is my favorite quote. How many times have you used that quote? Why? Do you have another .
http://www.facebook.com/pages/Youre-Killing-me-Smalls/166211283415072?sk=info
Treatment for Herniated or Bulging Discs
You're killin me Smalls! - Search Quotes
About: Movie quotes. favorite. Suggest Revision: You're killin me Smalls! Meaning Share your thoughts on what this quote means to you.
http://www.searchquotes.com/quotation/You're_killin_me_Smalls!/327185/
The 25 Greatest Sports Movie Quotes Of All Time (With Video ...
May 24, 2010 . The most memorable moments in movies are always the quotable ones. . tell everyone if they did something wrong "you're killing me smalls" .
http://bleacherreport.com/articles/395972-the-25-greatest-sports-movie-quotes-of-all-time-with-video
quote you're killing me smalls Herniated or Bulging Discs
"YOU'RE KILLING ME SMALLS!" Who would've thought that quote ...
Jun 29, 2011. a VIDEO item: over 1 year ago. Tweet · "YOU'RE KILLING ME SMALLS!" Who would've thought that quote would've become so popular?
http://www.moviefancentral.com/wallcrawler383/videos/19433
you're killin me smalls | Tumblr
you're killin' me smalls. on Erika · #ryan bailey #ryan #sandlot tattoo . 192021. whereallthewatertribeboysat. Hide video. Hiddles you are trying to kill me .
http://www.tumblr.com/tagged/you're-killin-me-smalls
The Sandlot (1993) - Memorable quotes
The Sandlot Quotes on IMDb: Movies, TV, Celebs, and more... . Smalls: You were all leaving, so I thought I'd hop the. .  You're Killing Me, Smalls! Sandlot If you are like me, then you recognize the title of this article from The Sandlot and if not, you just think I'm an .
http://www.culturefeast.com/youre-killing-me-smalls/
- home (narrowing of the spine)
Smalls - YouTube
Mar 24, 2006 . Possibly THE best quote of any? movie. ever. that and the . can we get a three second clip of just the "you're killing me Smalls" line? I'd like? to .
http://www.youtube.com/watch?v=bc7t_ET6SNQThe Sandlot - Wikiquote
Ham Porter: You're killing me, Smalls! These are s'mores stuff. Now pay attention. First you take the graham. You stick the chocolate on the graham.  Direct quote from the 1993 film "Sandlot". After being asked by Ham Porter if he wanted a s'more, Scotty Smalls replies several times .
http://www.urbandictionary.com/define.php?term=You're%20killing%20me%20smalls
you're killing me smalls | Tumblr
How old are you?years oldyears young . #you're killing me smalls · #i just read a 15 page thread on the debated hotness of you jon · #never doubt that i love .
http://www.tumblr.com/tagged/you're-killing-me-smalls
Medical-Vocational Allowance for Herniated Disc
ham porter | Tumblr
Ham Porter: No, do you wanna s'more? Smalls: I haven't had anything yet, so how can I have some more of nothing?  - Quotes - You're killing me, Smalls ...
Here's where I post my quotes cauz I think they're cool. deal with it. These are movie quotes, book quotes, etc. You're kill'in me Smalls! -Ham The Sandlot <3 .
http://ilovehogwarts.edublogs.org/quotes/
What movie are the following quotes from: "You're killing me Smalls ...
What movie are the following quotes from Youre killing me Smalls and How can I have some more of nothing - trivia question /questions answer .
http://www.funtrivia.com/askft/Question56914.html
Appealing a Denial of Benefits
Oh No They Didn't! - "The Sandlot": Where Are They Now?
I say "You're killing me, Smalls" at least every other day. Sadly no one remembers . This quote with that pic is killing me.  These are s'more's stuff! Ok, pay attention. First you take the graham, you stick the chocolate on the graham. Then you roast the 'mallow .
http://www.quotefully.com/movie/The+Sandlot/Ham+Porter