The Grimoire Extension Pack, or short Grimex, is a set of tools that integrates nicely into Grimoire/Jass NewGen. These tools can also be used standalone by calling them from the command line, batch scripts or custom programs. Included in this documentation are also a bunch of core Grimoire hacks, that many people might not know about.
This section contains a list of expected parameters for each tool that is part of the Grim Extension pack. People who are using the tools from command line will need these parameters. Also the arguments for a vJASS external call can be derived from these usage instructions. So whoever is familiar with command line will probably find this section enough to get started.
map.w3x lookuppaths ( directory | { diskfilepath archivefilename } )
map.w3x lookuppaths (checkflags | checktiles) applyflags [checkmode] [applymode]
map.w3x lookuppaths tileset tilelist
map.w3x lookuppaths [targetdir]
map.w3x lookuppaths [ m | r | i ] mergefile { moremergefiles }
map.w3x lookuppaths ( w3u | w3t | w3b | w3d | w3a | w3h | w3q ) originalid newid { changeid [ level | variation ] value }
map.w3x lookuppaths mergefile { moremergefiles }
map.w3x lookuppaths { war3map.wtg | war3map.wct }
script.lua lookuppaths patchname { flags }
For all tools the first argument is the path of the map being modified and the second parameter is a list of lookup directories that is used to resolve relative paths of other files passed in. You can pass "" if you're not using relative paths. Otherwise this is a string of all the paths separated by a ; and with \ replaced by /. If any of the paths contains a space then simply put the whole list in brackets. For example the lookup paths could be "C:/MyMap/;./jass/".
Remember that all this is beta software, there may still be bugs. In case something goes wrong, simply make use of JassHelper's backups and report bugs at the forums at www.wc3campaigns.net!
Since the version 1.0 of Grim Extensions all included tools can now be controlled with lua-scripts as well. This makes them even more powerful, flexible and usually a lot faster. To make use of this feature, instead of the usual parameters you have to pass one or more lua files (with the extension .lua) to the tool:
map.w3x lookuppaths script.lua { more.lua }
Check out the LUA scripts in the grimext/samples/ folder to find out how the scripting language works and which functions are available.
The File Importer plugin enables you to import a list of files or simply a folder including all subdirectories into your map. It can also auto-convert images to BLP format and MDL files to MDX due to its integration of BLPaletter and MDLXConverter. Additionally it will add appropriate icon borders and resize icons based on a naming convention.
When working on a map it is useful to keep all imports that are still being worked on in a folder that gets auto-imported by the File Importer tool as soon as the map is saved. That way the map always contains an up-to-date version of all your custom files. While working on a model or texture you can test your work ingame within seconds, without the hassle of having to convert and import the files manually. When distributing a system that requires imported files, an external call to the File Importer in the system's script will make sure that the required files are properly imported. An example would be the Dummy.mdx model from the caster system.
There are two ways to use the File Importer. From the menu you can click Extensions/Import Directory and select the directory that you want to import or you add a vJASS external call to your JASS script. The selected directory will then be imported into the map including the directory structure of all subdirectories. The imported files wil generally use the same path that they have inside the imported folder. The second option is using a vJASS external call, here's an example that will import the contents of C:\MyMap:
These external calls are evaluated whenever the map is saved, so the up-to-date files from that directory will always replace older imported files in the map. Relative paths to the map's directory and the lookup paths defined under [lookupfolders] in mapcompiler.conf (the JassHelper configuration file) are automatically resolved:
//! external FileImporter ..\MyMap
If you don't want to import a whole directory, but only a few files, then you can use Extensions\Import Files from the menu and select the files you want to import. When using an external call to import specific files you'll have to specify a list of pairs of source file and target file names. The target file name is the name that it should have inside the map:
Note how you only need to change the file extension of the imported path to make use of the auto-convert function:
When importing a whole directory, auto-convert will attempt to convert all files with a .jpg, .bmp, .tga or .mdl extension. If the conversion is successful the resulting file will be imported using the same path with only the extension changed to .blp or .mdx. Otherwise the original file is imported using its original path. You can explicitely overrule this attempt by keeping the same extension in the imported path, although it doesn't make much sense:
//! external FileImporter ..\MyMap\DiscoStu.mdl Models\DiscoStu.mdl
Finally there's a naming convention that will add icon borders to images with a certain prefix in the filename.
The icons in the following example will get a normal/autocast/passive icon border:
//! external FileImporter CMDBTNMyIcon.bmp MyIcon.blp AUTBTNOtherIcon.tga OtherIcon.blp PASBTNNewIcon.jpg NewIcon.blp
The imported path for icons doesn't matter, they will end up in ReplaceableTextures\CommandButtons\BTNMyIcon.blp, ReplaceableTextures\AutocastButtons\BTNOtherIcon.blp and ReplaceableTextures\PassiveButtons\BTNNewIcon.blp and a disabled version will automatically be put in ReplaceableTextures\CommandButtonsDisabled\DISIconName.blp. Now let's combine the prefixes to make use of a shared disabled icon:
//! external FileImporter AUTPASCMDSharedIcon.tga SharedIcon.blp
This will create a normal, a passive and an autocast version of the same icon and put the shared disabled version in ReplaceableTextures\CommandButtonsDisabled\DISSharedIcon.blp. Finally we can put attack/armor type borders and caster upgrade borders around our icons:
//! external FileImporter ..\MyMap\infocard-chaos-damage.tga InterfaceTextures\infocard-chaos-damage.blp ..\MyMap\level-infocard-undead-caster.tga InterfaceTextures\level-infocard-undead-caster.blp
As you can see, the infocard- and level-infocard- prefixes do the magic here. Since infocard icons do not have disabled versions, the imported path will not be changed in this case. If an icon doesn't have the appropriate size, it will be resized automatically by the tool. If you use a custom icon style in your map or mod, you can customize the borders and overlays used by the tool. You'll find them as TGA files inside the directory where the Extensions are installed to. Also remember that the tool will never try to modify BLP files, the auto-bordering and resizing is only applied to BMP, TGA and JPG images.
If you want the imported files to show up in the import manager you need to close and reopen the map WITHOUT manually saving it. When using the tool from the menu this step is MANDATORY.
You can specify a callback function which provides the compression details for each auto-converted image. And of course you can speed up single file imports a lot, because this is now just one external call.
The Path Mapper plugin enables you to post-process the pathing map of your map after saving it. It's good for changing the walkability/flyability/buildability of specific tiles or of terrain cells that meet some other certain creteria. This allows for a number of tricks like making cliffs walkable or for example in Project Revolution we used it in combination with the 'Placement Prevented By' field to make refineries only buildable on geysirs.
The following example makes the map unwalkable where Lordaeron Summer Dirt, Lordaeron Summer Grass or Lordaeron Summer Dark Grass is:
Here is another example that sets the pathing to normal ground where tiles other than Lordaeron Summer Dirt are:
To be able to use it you'll need a bit more information. First of all you'll need to know the tile ids, which you can obtain from TerrainArt\Terrain.slk or from this list. Then you'll need the pathability flag table to determine which values you want to apply to the pathing map.
The flag values here are hexadecimal and need to be added up to combine the flags, the mask argument for the tool also needs to be hexadecimal. Internally the pathing map is stored in a grid of 32x32 cells. That means that the smallest unit in the editor, a 128x128 cell is split up into 16 pathing cells, each of which is assigned a value from the above flag table. With this tool you're able to change this value for each of the cells. Here are some examples that you will typically find in a pathing map.
Now to modify the pathing map, you'll need a way to specify which cells will be changed and a way to apply flag values to the existing value of each cell. For the latter there are four different apply modes that you can use.
So in the first example only the no-walk-bit is set with a binary or and nothing else is changed. If you don't specify an apply mode, the old values are completely replaced by the value you specify. Like in the second example where it's set to normal ground. Check modes here can be either match or mismatch.
In the first example ! is used to change the pathing for all tiles that are not Lordaeron Summer Dirt. If you don't set this parameter the normal mode will apply the change for all specified tiles.
Instead of the tile of each cell you can also compare the current pathability value to decide which cell needs to be updated. When comparing to a pathability mask, the following compare modes can be specified.
Apply modes in this case are again |, &, and ^. In the next example map boundaries are made walkable by removing the no-walk-bit with a binary and:
In this next example areas that have either the no-walk or the no-fly bit set, are made walkable and flyable:
If you ever decide to add walkability to a tile that is normally unwalkable, please note that this will update ALL cells that have this tile. That means that units will also be able to walk over cliffs, doodads and possibly water and the camera bounds when those are covered with the specified tile. In such cases can use the pathing configuration that is part of UMSWE instead of this tool.
You can specify callback functions for the condition that a cell needs to meet to be updated and for the update action, making it a lot more flexible and faster. Also the tool becomes a lot more user friendly, because you can save yourself the hassle of bitwise flag operations.
The Tile Setter plugin allows you to edit the tileset of your maps similar to the already existing option in the world editor. The only major difference is that this tool extends the tile limit to 16. This will make the old tileset editor of WEU obsolete. You can also change the base tileset with this tool, in case you want to switch to a different water/cliff look.
Using it is quite simple, just click Extensions\Edit Tileset from the menu, then a graphical tile picker will pop up. At the bottom it shows the base tileset of your map and a list tiles currently present in your map like so:
By clicking on the tile icons you can add/remove it to/from your map. The max is 16 tiles for each map. When you're satisfied with your changes click the ok button to apply them, then close and reopen your map without resaving it, and your new tiles should show up in the terrain palette.
The configuration dialog might spit out a warning if you removed or replaced cliff tiles with non-cliff tiles. This can only cause problems if the removed/replaced tile has actually been used for cliffs in your map, otherwise it's safe to ignore the warning.
You shouldn't ever need to use the Tile Setter from a vJASS external call, but in case you can think of any situation where this could be useful, here's an example that changes the terrain of your map into the Lordaeron Summer tileset. Use this tileset list and this this list of tiles as a reference for your calls:
//! external TileSetter L LdrtLdroLdrgLrokLgrsLgrd
Do NOT replace cliff tiles that are actually used as cliffs in your map. Please remove those cliffs from your terrain before exchanging the tile to prevent possible problems, unless you know what you're doing.
You can edit your tile list programmatically and use several functions to query details about each tile.
The File Exporter plugin simply exports all files inside a map to a specified folder. It will also rebuild the folder structure from inside the map in the specified target directory. That way the target directory can the again be used as the source directory for the File Importer plugin. This can be useful to copy the files from a system that is distributed through a demo map to your own map. For example one could export all contents of the Ultimate Terraining Map and import them all into a custom map using the File Importer and Object Merger plugins with just a few clicks. Or it can be used to copy the terrain, units, doodads, sounds, regions, or cameras from one map to another map.
To get all files extracted simply click Extensions\Export Files in the menu and select the target directory. This will essentially extract all files listed in the import manager, but also some internal files that contain special data. For each category of files the tool creates a separate subdirectory in the target directory, here's the list:
On a final note, all files that are used as input for the Object Merger, Trigger Merger or Constant Merger plugins should have been exported using this File Exporter plugin or by the export function of the WE before. That is because it takes care of inlinig TRIGSTR references when exporting the files, which prevents strings from getting lost when importing those files into other maps. If the files however had been exported using a normal MPQ viewer, the strings will not be inlined properly and may get lost. Also if you ever want to use the File Exporter in a vJASS external call, here's an example that exports all files to C:\MyMap:
//! external FileExporter C:\MyMap
None so far.
You can also export single files to specific directories.
There are two basic use cases for the Object Merger plugin. First of all it can import object editor data, but it won't replace the existing data, instead it will merge the existing and the imported data, there are different modes available that control how collisions of object ids are handled. This can be useful for distributing systems that require certain objects, like for example the caster unit from the caster system. A vJASS external call to this tool will make sure that the required unit exists in the map. Also in a team people can work separately on certain aspects of the map and later merge their work this way. The other use case is generating larger amounts of similar objects using vJASS external calls. Again this is useful to distribute systems that require object data. I'm thinking of systems like Bonus Mod which requires a number of bonus abilites. Finally it allows you to specify custom rawcodes for your objects, although this is conveniently possible with a Grimoire hack already.
When merging or generating object data, the first thing you'll have to know is what type of objects each file extension is associated with. Here's the list:
To merge object data there are three different modes available how collisions can be handled. Each of them is available from the menu as well as from vJASS external calls.
When using one of the menu entries a popup wil ask you to select all input files that you want to add to the map. All the input files need to be of the sime type of course, you cannot mix unit and ability definitions for example. Our first example shows how to import custom unit data that was previously exported by the File Exporter plugin using a vJASS external call:
The above is the same as the following call that explicitely defines how collisions should be handled, because m is the default mode:
//! external ObjectMerger m Objects\war3map.w3u
It's important that the merged files have been exported with the WE's export function or the File Exporter tool and not using an MPQ viewer, because otherwise string references may get lost. The second example shows how to import several files of the same type (extension) with one call. In case of collisions the existing object will be completely replaced (r parameter):
Ok, with this tool you can also create new objects using a vJASS external call instead of the object editor. I'll start with a few examples and then explain the parameters. This one creates a copy of the glaive upgrade with 2 levels and a different icon on the second level:
Here's one that creates a new armor bonus ability that gives a bonus of 64 at level 1, the second call then creates a new item based on the existing protective ring item. It is assigned the new ability and a new name:
This next example makes a copy of the fence doodad (NOfl), changes it so it has three variations and then tints the first variation all blue, the second variation all green and the third variation red:
This last example creates a chaos ability to morph into a peasant. Apparently Warcraft doesn't mind abilities having the same id as units, so I gave the ability hpea as id:
Now let's use the last example to take a closer look at the parameters. First of all you'll need to specify the type of object that you want to create. This is done by putting the file extension of this type as the first parameter, use this table as a reference. The example has w3a which means we're creating an ability. The next parameter is the rawcode of the base object that we want to copy, this can be a standard object or also a custom object that you previously created in the object editor or with a previous call to this Object Merger tool. To find out the rawcode of an object use View/Display Values as Raw Data from the object editor menu. The third parameter is the id that the created object should have, you're free to choose any 4-letter-id that isn't already used by an object of the same type. Then follows a list of pairs or triples that specifies the changes you want to apply to the base object. The first pair here is anam "My Chaos" which sets the name of the created ability to My Chaos. The left part of such pairs is a 4-letter-change-id that determines which field should be updated, the right side is the new value. The next one sets the editor suffix, as you can see the quotes are not needed if the string doesn't contain spaces. Then the check tech dependencies flag is set to false. You'll notice that booleans are simply represented by 1 (true) and 0 (false). Finally there's also an example for a change triple. This is needed for fields that can be changed per level. In this case the target unit id for the chaos morph is set to hpea for level 1. If you're not sure if a field requires a pair or a triple, you can test it by increasing the level of the base ability in the object editor and looking if the field repeats for multiple levels. Upgrades also use levels for some fields as you can see in the first example where the icon is changed for level 2 of the upgrade. Doodad variations work similar. In the third example such triples are used to change the tinting values of the 3 variations of the created doodad. All other object types like units, items, buffs and destructables only use pairs and never triples because they don't have levels.
At this point you may wonder where to look up all those change ids. The answer is that with Grimoires object editor hack the ids of each change will be shown in brackets. Make sure that View\Display Values as Raw Data is disabled when you want to view these ids. Alternatively you can look up the ids in the appropriate MetaData.slk file for the respective object type. On a note about the inner workings, all vJASS external calls get evaluated whenever the map is saved. That means whenever you save the Object Merger will create the same objects that will overwrite each other over and over again, which isn't necessary, so after the first time you save you can technically remove the external call again.
Be careful when choosing the ids of your generated objects. Don't use ids that already exist, this can overwrite your existing objects. If you want the new objects to show up in the object editor you need to close and reopen the map WITHOUT manually saving it. When using the tool from the menu this step is MANDATORY. Also do only merge object files that have been exported with the File Exporter tool to Objects\ or the export object data function of the world editor. Otherwise TRIGSTR references could be missing.
First of all you can speed it up a lot, because you can create all your objects in a single external call. Then there are some additional functions available which you can use to reset objects, reset changes and apply changes to specific objects, all custom, all original, all modified original, or all unmodified original objects with a single script call. Also you can use LUA to program custom formulas to generate your object ids and for autofill-like needs.
The Constant Merger plugin works quite similar to the Object Merger tool, but instead of object editor data it imports customizations to the gameplay constants, the game interface settings and certain test map settings. If one of your system requires a specific change to the game interface or gameplay constants you can use a vJASS external call to this tool so that the required changes are automatically applied to a map that uses your system when it is saved. For example you might want to change the chat recipient prefixes for a chat system or you might want to customize the experience gain table for a levelup system.
Usually you will want to import customizations that were exported previously from another map by using the File Exporter tool. All files that it places inside the Constants\ folder after the export can be handled by the Constant Merger. There are three types of files that can be handled:
You can merge several files of the same type with a single Constant Merger call, but do NOT mix different types in a single call. This tool is also available from the menu Extensions\Merge Constants Data which pops up a file selection dialog. The other option is a vJASS external call like in this example:
//! external ConstantMerger C:\MyMap\Constants\war3mapSkin.txt ..\otherInterfaceStuff.txt
If you want your changes to show up in the editor you need to close and reopen the map WITHOUT manually saving it. When using the tool from the menu this step is MANDATORY. Also do only merge files that have been exported with the File Exporter tool to the Constants\ folder. Otherwise TRIGSTR references could be missing.
It's also possible to set values from within the LUA script, not only by merging files.
The Trigger Merger plugin is capable of adding the trigger data form another map to your map. That means it can import variables, GUI triggers and also the custom text triggers and header. So technically it is now possible to distribute GUI trigger systems that are easy to import into any map.
Use it with caution though, since variables and triggers that have the same name like existing variables/triggers will overwrite them. So if you're developing a system that you want to distribute this way you'd better use a unique prefix for your variables and triggers to prevent possible conflicts. Also the custom text header of the imported trigger data will be put into a new custom text trigger, so that the existing custom text header of your map won't be touched. The input for the tool is pair of wtg and wct files. You only need to specify one of the two as the input file, the tool will look for a file with the same path and name and only the extension changed and use it as the second input file. The easiest way to obtain a wtg and wct file is by using the File Exporter tool which will put the trigger data into the Triggers\ subfolder of the export target folder. Trigger files that have been exported using a MPQ viewer shouldn't be used as input files, because they will be missing TRIGSTR references.
Again it's possible to use it from the menu using Extensions\Merge Trigger Data and then selecting one of the two input files in the file browser, or from a vJASS external call. Here's an example that will add the triggers from an external file to your map:
//! external TriggerMerger C:\MyMap\Triggers\war3map.wtg
You can also merge the trigger data of several maps with a single call, simply list all the files that you want to merge as parameters of the external call. However you should always only list one file of a wtg/wct pair, never both in the same call:
//! external TriggerMerger C:\MyMap\Triggers\war3map.wtg C:\OtherMap\Triggers\war3map.wct
If you want the imported triggers to show up in the editor you need to close and reopen the map WITHOUT manually saving it. When using the tool from the menu this step is MANDATORY. Also do only merge files that have been exported with the File Exporter tool to the Triggers\ folder. Otherwise TRIGSTR references will be missing. The tool also doesn't check for duplicate JASS functions, so if two imported custom text headers both contain the H2I function this will of course cause compile errors and needs to be manually fixed. Also if the imported data contains references to generated unit, destructable, item, sound, region or camera variables those will be lost in the target map.
You can register global GUI variables from within the script without having to merge files.
The Patch Generator has been created to produce World Editor patches, specifically to port UMSWE to NewGen. UMSWE has been implemented entirely in LUA scripts which are interpreted by this Patch Generator tool. This means you can use the Patch Generator to produce your own MPQ patches for the World Editor or the Warcraft 3 game. Check out the LUA scripts in the umswe\ subfolder of your NewGen directory for sample scripts. Here's how you call the tool from the command line:
script.lua lookuppaths patchname { flags }
The first parameter is the script you want to run, the second as usual is a list of directories used to lookup file paths that cannot be resolved. The third parameter is the name of your patch, a txt file with this name is created in the logs/ subfolder of NewGen when you run this tool. Then you can pass a list of options which will be registered as global boolean variables in the LUA space. This is useful so you can use the same LUA script to turn a patch on and off with only the passed option changed. For example you could pass in "enable=1" or "enable=0" and in the script you can use if enable then to act depending on that option. Again, the UMSWE scripts are good samples to learn from.
Via Extensions\Enable Local Files you can enable and disable local files on your system. When it's on Warcraft will load files from local folders with a higher priority than the files from the mpqs. This enables you to override war3patch.mpq with your own files, without messing with the mpq for rapid testing purposes. Local files means that inside your Warcraft directory you could place a Units\ subfolder and for example put a custom AbilityMetaData.slk file in there that will be loaded instead of the file from the mpqs. This way it's also possible to override files that normally don't load when imported into a map (like all the meta data files or CliffTypes.slk).
Using Extensions\Register Shell Extensions you can add items to the context menu of Warcraft maps and campaigns. When this is enabled and you right click a map or campaign the context menu that pops up will show a Play Fullscreen and Play Windowed option:
This is an improved version of the old No Limits patch that is integrated in Grimoire that removes unit, item, doodad and map size limits. With the menu entry Grimoire\Disable WE Limits you can enable and disable this feature.
Additionally the possibility to create epic 480 x 480 maps has been added to the editor. But watch out, some people have told me about blight not working properly in maps that large. As you can see the hack is directly integrated into the create map dialog:
The menu entry Grimoire\Customize Test Map Settings will show the following configuration dialog:
As you can see it allows to speed up the game speed for your tests (just like you normally speed up replays) by a factor of up to 25. It can also disable fog of war and the victory and defeat conditions for your test runs in case you are testing a melee map. Additionally you can play around with player colors, add computer controlled players for your tests and assign custom handicaps and even ai scripts.
However make sure that Use Custom Forces is disabled in the force properties of your map, otherwise the test map settings will not work. With the upper left checkbox you can also enable and disable the custom test map settings. When it's disable the map starts as usual when clicking the test map button, otherwise the custom settings will be applied.
Finally there's a new hack that allows you to specify custom rawcodes for new objects in the object editor. It can be enabled and disabled with the Grimoire\Enable Object Editor Hack menu entry. Additionally all object properties will also show their internal rawcode in brackets. You will need those if you want to use the Object Merger tool in your map. Here's a screenshot of the hack in action:
By the way this hack can be used to create copies of non-hero units and even buildings which are heros. This is done by simply capitalizing the first character of the new unit id.
Here I'd like to thank everyone who has contributed in the creation and testing of the Grim Extension Pack and the Jass NewGen Pack as a whole. Special thanks go to the following people:
Have fun, PitzerMike


Enter the patient's last and first name, or first initial of the last name and last four digits of SSN to display results.
Enter the patient's last name and at least one other field to display results.
| DOB: | 04/07/1935 |
|---|---|
| Age: | 80y |
| Gender: | Male |
| SSN: | 666-00-0008 |


A class about organization
March 27, 2015
The thrust of the programming language 'Ruby' is that it is object-oriented which means all language associated terminology is an object. These objects relate to one another in some way. This orientation lays the foundation for a solid provision for data containment. Object-oriented Ruby makes a great effort to supply the tools to store and organize data and save time in the process. This can be accomplished through the use of 'classes' which assist with the structure of code in programming. Through a class several objects, or instances of the class can be created using the tools the of class that Class provides while minimizing the effort to do so through shared methods. So when a programmer has a project that requires providing information to a computer user they will often rely on 'classes' to ensure concise containment and distribution of that data.
Classes are at the top of the heap of objects in Ruby. They act as the team manager. The programmer is the team captain and the classes help the team captain select the most talented team players. Here these team players are the 'attribute techniques' and 'methods'. The attribute techniques are a powerful coding shortcut that have the effect of writing one or more get and/or set methods. Under the guidance of the class understanding, the attributes support the methods, and the methods work together efficiently to optimize their abilities and maximize results. This means the team can be smaller and get the job done better. This is accomplished through a good balance of cohesiveness and communication. And all of it is the intent of the creator of the Ruby programming language Yukihiro Matsumoto and his idea that programmers should have a clearer pathway to telling a computer what to do and how to do it.
class Bear
attr_reader :breed, :color
attr_accessor :name
def initialize(breed, color, name)
@breed = breed
@color = color
@name = name
end
def bear_details
return "This is a #{@breed} bear, its #{"@color}, and somehow its name is<EMAIL_ADDRESS>end
end
grb = Bear.new("Grizzly", "brown", "nice Bobo")
pob = Bear.new("Polar", "white", "go away Beatrice")
pab = Bear.new("Panda", "black and white", "no biting Ben")
p grb.bear_details
p pob.bear_details
p pab.bear_details
Above is a block of code in which I have created a class for 'Bear'. I have used two attribute techniques, 'reader', and 'accessor'. attr_reader was selected because it has been established that we all agree what a bear and a color are and that won't change. The name of an animal is open for change because some people change there own names and some change the name of an animal so the better choice is attr_accessor which allows for modification. I have chosen to be liberal with the use of this attribute to emphasize flexibility. There are recognized breeds of bear and colors associated with that breed. Generally, there are not usually names associated with class bear but sometimes people do own bears and give them names, or they are in a zoo and have been given a name. Then using the 'initialize' method we can bundle breed, color, and name and not have to separately define a method for each. This shortens the code necessary and makes it more readable.
Then I chose some variable names to access the information about the the bear breeds and provide it for the user to see. This conveys that attr_reader provides for one of the existing class Bear breeds and its associated color. And attr_accessor shows this particular bear of that breed and color may have a name, that can be changed. Object-oriented Ruby has enabled a programmer to use his time and skills well and give the user a better experience.


If you want you can contact us by GitHub, Twitter, Telegram, Slack or e-mail — The BCD Team


Understanding and learning a new system happens best with examples. Fortunately Specification by Example and Behavior Driven Design both create many great examples that we can use to teach. All that needs to be done is to glue them together with magic words.


Some personal reflections on PerconaLive 2015: Percona acquires Tokutek Well done! Tokutek develops the TokuDB storage engine for MySQL and TokuMX engine for MongoDB. I will discuss the MySQL aspect only. TokuDB was released as open source in 2013. It has attained a lot of traction and I have used it myself for some time. I met issues with locking or otherwise operational difficulties which I reported, and otherwise was fascinated by such features as great compression, online schema changes, and more.
During our experiments I came upon a few TokuDB variables of interest; if you are using TokuDB you might want to look into these:
This is a boundary on the number of seconds an ANALYZE TABLE will operate on each index on each partition on a TokuDB table.
That is, if tokudb_analyze_time = 5, and your table has 4 indexes (including PRIMARY) and 7 partitions, then the total runtime is limited to 5*4*7 = 140 seconds.
Default in 7.1.0: 5 seconds
Similar to innodb_buffer_pool_size, this variable sets the amount of memory allocated by TokuDB for caching pages. Like InnoDB the table is clustered within the index, so the cache includes pages for both indexes and data.
Default: 50% of total memory
Boolean, values are 0/1. Setting tokudb_directio = 1 is like specifying innodb_flush_method = O_DIRECT. Which in turn means the OS should not cache pages requested by TokuDB. Default: 0.
Now here’s the interesting part: we are used to tell InnoDB to get the most memory we can provide (because we want it to cache as much as it can) and to avoid OS caching (because that would mean a page would appear both in the buffer pool and in OS memory, which is a waste). So the following setup is common:
This is the third post in a series of posts describing our experience in migrating a large DWH server to TokuDB (see 1st and 2nd parts). This post discusses operations; namely ALTER TABLE operations in TokuDB. We ran into quite a few use cases by this time that we can shed light on.
Quick recap: we’ve altered one of out DWH slaves to TokuDB, with the goal of migrating most of out servers, including the master, to TokuDB.
Adding an index
Shortly after migrating our server to TokuDB we noticed an unreasonably disproportionate slave lag on our TokuDB slave (red line in chart below) as compared to other slaves.
Quick investigation led to the fact that, coincidentally, a manual heavy-duty operation was just taking place, which updated some year’s worth of data retroactively. OK, but why so slow on TokuDB? Another quick investigation led to an apples vs. oranges problem: as depicted in part 1, our original setup included MONTHly partitioning on our larger tables, whereas we could not do the same in TokuDB, where we settled for YEARly partitioning.
The heavy-duty operation included a query that was relying on the MONTHly partitioning to do reasonable pruning: a WHERE condition on a date column did the right partition pruning; but where on InnoDB that would filter 1 month’s worth of data, on TokuDB it would filter 1 year.
Wasn’t it suggested that TokuDB has online table operations? I decided to give it a shot, and add a proper index on our date column (I actually created a compound index, but irrelevant).
It took 13 minutes to add an index on a 1GB TokuDB table (approx. 20GB InnoDB uncompressed equivalent):
- The ALTER was non blocking: table was unlocked at that duration
- The client issuing the ALTER was blocked (I thought it would happen completely in the background) – but who cares?
- I would say 13 minutes is fast
Not surprisingly adding the index eliminated the problem altogether.
Modifying a PRIMARY KEY
It was suggested by our DBA that there was a long time standing need to modify our PRIMARY KEY. It was impossible to achieve with our InnoDB setup (not enough disk space for the operation, would take weeks to complete if we did have the disk space). Would it be possible to modify our TokuDB tables? On some of our medium-sized tables we issued an ALTER of the form:
This is a second in a series of posts describing our experience in migrating a large DWH server to TokuDB. This post discusses the process of migration itself.
As a quick recap (read part 1 here), we have a 2TB compressed InnoDB (4TB uncompressed) based DWH server. Space is running low, and we’re looking at TokuDB for answers. Early experiments show that TokuDB’s compression could make a good impact on disk space usage. I’m still not discussing performance – keeping this till later post.
Those with weak hearts can skip right to the end, where we finally have a complete conversion. You can also peek at the very end to find out how much 4TB uncompressed InnoDB data is worth in TokuDB. But you might want to read through. The process was not smooth, and not as expected (it’s a war story thing). Throughout the migration we got a lot of insight on TokuDB’s behaviour, limitations, conveniences, inconveniences and more.
Disclosure: I have no personal interests and no company interests; throughout the process we were in touch with Tokutek engineers, getting free, friendly & professional advice and providing with input of our own. Most of this content has already been presented to Tokutek throughout the process. TokuDB is open source and free to use, though commercial license is also available.
How do you convert 4TB worth of data to TokuDB?
Obviously one table at a time. But we had another restriction: you may recall I took a live slave for the migration process. And we wanted to end the process with a live slave. So the restriction was: keep it replicating!
How easy would that be? Based on our initial tests, I extrapolated over 20 days of conversion from InnoDB to TokuDB. Even with one table at a time, our largest table was expected to convert in some 12-14 days. Can we retain 14 days of binary logs on a server already running low on disk space? If only I knew then what I know today :)
This is the first in a series of posts describing my impressions of converting a large OLAP server to TokuDB. There’s a lot to tell, and the experiment is not yet complete, so this is an ongoing blogging. In this post I will describe the case at hand and out initial reasons for looking at TokuDB.
Disclosure: I have no personal interests and no company interests; we did get friendly, useful and free advice from Tokutek engineers. TokuDB is open source and free to use, though commercial license is also available.
The case at hand
We have a large and fast growing DWH MySQL setup. This data warehouse is but one component in a larger data setup, which includes Hadoop, Cassandra and more. For online dashboards and most reports, MySQL is our service. We populate this warehouse mainly via Hive/Hadoop. Thus, we have an hourly load of data from Hive, as well as a larger daily load.
There are some updates on the data, but the majority of writes are just mysqlimports of Hive queries.
Usage of this database is OLAP: no concurrency issues here; we have some should-be-fast-running queries issued by our dashboards, as well as ok-to-run-longer queries issued for reports.
Our initial and most burning trouble is with size. Today we use COMPRESSED InnoDB tables (KEY_BLOCK_SIZE is default, i.e. 8). Our data volume sums right now at about 2TB. I happen to know this translates as 4TB of uncompressed data.
However growth of data is accelerating. A year ago we would capture a dozen GB per month. Today it is a 100GB per month, and by the end of this year it may climb to 150GB per month or more.
Our data is not sharded. We have a simple replication topology of some 6 servers. Machines are quite generous as detailed following. And yet, we will be running out of resources shortly: disk space (total 2.7TB) is now running low and is expected to run out in about six months. One of my first tasks in Outbrain is to find a solution to our DWH growth problem. The solution could be sharding; it could be a commercial DWH product; anything that works.
Or: how to make it work in TokuDB version 7.0.1. This is a follow up on a discussion on the tokudb-user group.
Background
I wanted to test TokuDB’s compression. I took a staging machine of mine, with production data, and migrated it from Percona Server 5.5 To MariaDB 5.5+TokuDB 7.0.1. Migration went well, no problems.
To my surprise, when I converted tables from InnoDB to TokuDB, I saw an increase in table file size on disk. As explained by Tim Callaghan, this was due to TokuDB interpreting my compressed table’s “KEY_BLOCK_SIZE=4” as an instruction for TokuDB’s page size. TokuDB should be using 4MB block size, but thinks it’s being instructed to use 4KB. Problem is, you can’t get rid of table options. When one converts a table to InnoDB in ROW_FORMAT=COMPACT, or even to MyISAM, the KEY_BLOCK_SIZE option keeps lurking in the dark.
So until this is hopefully resolved in TokuDB’s next version, here’s a way to go around the problem.
Sharing my experience of compiling TokuDB + MariaDB 5.5. Why? Because I must have this patch to Sphinx 2.0.4.
Note: I was using what seems to be the “old” method of compiling; quoting Leif Walsh:
… We are looking at deprecating that method of building (MariaDB source plus binary fractal tree handlerton). It only really needed to be that complex when we were closed source.
I also tried the “new” method of compiling, which I couldn’t work out.
Here’s how it goes: TokuDB is newly released as open source. As such, it got a lot of attention, many downloads and I hope it will succeed.
However as stable as the product may be, it’s new to open source, which means anyone compiling it from source is an early adopter (at least for the compilation process).
Installation process
This is an unorthodox, and actually weird process. See section 6 on the Tokutek docs. In order to compile the project you must download:
- The source code tar.gz
- And the binary (?!) tar.gz
- And the binary checksum
- And the Tokutek patches
- And the patches checksum


How Urlaubsglück works?
Meet a partner for your best holiday
Bradley Hunter
Based in Chicago. I love playing tennis and loud music.
Heather Walker
I'm a happy person that loves cats and climbing on mountains.
Lucas Marsha
I get my inspiration from nature and objects around me. I have a passion to colours, typography and skateboards.
Heather Walker
I'm a happy person that loves cats and climbing on mountains.
Discover holiday activity ideas
Discover holiday activity ideas
Hi! What are your holiday interests?
Request error or not enough images found


{% extends '_layouts/layout.html' %} {% block page_title %}Index : {{serviceName}}{% endblock %} {% block content %}
Private beta, v1.1
Split flow into two sections: ‘details’ and ‘health info’
Private beta, v1.0
(Change to way we're associating ‘current GP’ with ‘address at that GP’)
MVP, v1.4
See register-flow-v3.1
(Incorporates tweaks and journey changes from lab day on 5th January 2017)
MVP, v1.3
See register-flow-v2.1.1
(GP details page included for lab on 5th January 2017)
MVP, v1.0
Initial proposition, minimum viable product
GMS1 form, v1.1
Added GP lookup functionality
Reduced hinting where it was duplicated
GMS1 form, v1.0
GMS1 form translated into online journey


Welcome
Currently toppings:
Protein
Click on picture of protein to add to your pizza: $1.50 per protein
Bacon
Beef
Chicken
Pepperoni
Pork
Sausage
Veggies
Click on picture of veggie to add to your pizza: $1.00 per veggie
Mushrooms
Olives
Onions
Peppers
Spinach
Tomatoes


npm, the awesome source code package manager for JavaScript and stuff, publishes a specification for license metadata in package.json
files. The spec asks maintainers to use the SPDX standard’s license expression syntax to show how their work is licensed in a machine-readable way. You will get a warning if you don’t.
In most cases, that's as easy as setting your license
property (not licenses
, as for RubyGems) to MIT
, ISC
, BSD-2-Clause
, Apache-2.0
, or some other string on SPDX' official list. You can even Unlicense
or WTFPL
, you rebel, you.
The following is a list of packages among the 1,000 most-depended-upon (the “npm1K”) that aren't yet part of that better world. There are handy links for making quick pull requests to fix package.json
if you’d like to help them out. Given how vital these packages are, each one with a good license
property helps make Node easier to adopt in new and different teams, many of which are dipping timid corporate toes into open-source for the very first time.
Who cares? Nobody cares! Until they have to do a license check. Then, thanks to how amazing npm is, you’re left staring down a bottomless well of node_modules
directories you must search, manually, for LICENSE
files and hints in README
. But shouldn’t some lousy program do that kind of work for you? Of course! And it would sure help if the npm ecosystem offered good, clean metadata to chew on.
Special thanks to @beaugunderson and @tunnckoCore.
Mon, 05 Mar 2018 00:02:59 GMT
| № | Package | Latest | Maintainers | Fix It! | Warnings |
|---|---|---|---|---|---|
| 66 | node-uuid | 1.4.8 | broofa defunctzombie |
|
|
| 77 | optimist | 0.6.1 | substack |
"MIT/X11"
|
|
| 136 | gulp-rename | 1.2.2 | hparra contra shinnn fractal |
|
|
| 211 | cli-table | 0.3.1 | rauchg |
|
|
| 224 | querystring | 0.2.0 | gozala |
|
|
| 267 | passport-local | 1.0.0 | jaredhanson |
|
|
| 274 | xmldom | 0.1.27 | jindw yaron bigeasy kethinov jinjinyun |
|
|
| 333 | raw-loader | 0.5.1 | sokra |
|
|
| 349 | react-tap-event-plugin | 3.0.2 | s0meone |
|
|
| 376 | wrench | 1.5.9 | ryanmcgrath |
|
|
| 379 | walk | 2.3.9 | coolaj86 |
|
|
| 381 | adm-zip | 0.4.7 | cthackers |
|
|
| 428 | ssh2 | 0.5.5 | mscdex |
|
|
| 465 | newrelic | 2.9.0 | lykkin |
|
|
| 528 | passport-oauth | 1.0.0 | jaredhanson |
|
|
| 537 | valid-url | 1.0.9 | odysseas sagens |
|
|
| 542 | connect-flash | 0.1.1 | jaredhanson |
|
|
| 560 | tv4 | 1.3.0 | geraintluff bartvds |
[{"type":"Public Domain","url":"http://geraintluff.github.io/tv4/LICENSE.txt"},{"type":"MIT","url":"http://jsonary.com/LICENSE.txt"}]
|
|
| 563 | hogan.js | 3.0.2 | fat sayrer |
|
|
| 580 | markdown | 0.5.0 | ashb dom |
|
|
| 582 | clear | 0.1.0 | bahamas10 |
|
|
| 606 | btoa | 1.1.2 | coolaj86 |
"Apache2"
|
|
| 608 | passport-strategy | 1.0.0 | jaredhanson |
|
|
| 612 | express-jwt | 5.3.0 | dschenkelman hzalaz jaredhanson jfromaniello pose woloski |
|
|
| 615 | babel-preset-lfdoherty | 1.0.6 | lfdoherty |
|
|
| 623 | base-64 | 0.1.0 | mathias |
|
|
| 636 | keymirror | 0.1.1 | strml |
|
|
| 650 | iniparser | 1.0.5 | shockie |
|
|
| 670 | source-map-loader | 0.2.3 | ericclemmons bebraw jhnns thelarkinn sokra jtangelder d3viant0ne |
|
|
| 714 | readline | 1.3.0 | craigbrookes |
"BSD"
|
|
| 717 | argv | 0.0.2 | codenothing |
|
|
| 727 | busboy | 0.2.14 | mscdex |
|
|
| 731 | pg-hstore | 2.3.2 | scarney |
|
|
| 734 | clui | 0.3.6 | artokun nathanpeck |
|
|
| 737 | callsite | 1.0.0 | tjholowaychuk |
|
|
| 755 | async-validator | 1.8.2 | yiminghe |
|
|
| 761 | slush | 1.1.1 | joakimbeng |
|
|
| 780 | fastclick | 1.0.6 | ftlabs mcg georgecrawfordft mattandrews |
|
|
| 791 | angular-material | 1.1.7 | angularcore |
|
|
| 813 | log | 1.4.0 | tjholowaychuk |
|
|
| 845 | passport-http-bearer | 1.0.1 | jaredhanson |
|
|
| 848 | entities | 1.1.1 | feedic |
"BSD-like"
|
|
| 851 | mandrill-api | 1.0.45 | mailchimp |
|
|
| 864 | docopt | 0.6.2 | stuartcarnie |
|
|
| 869 | rethinkdb | 2.3.3 | rethinkdb |
|
|
| 880 | ftp | 0.3.10 | mscdex |
|
|
| 885 | hat | 0.0.3 | substack |
"MIT/X11"
|
|
| 904 | gsap | 1.20.4 | greensock |
"Standard 'no charge' license: https://greensock.com/standard-license. Club GreenSock members get more: https://greensock.com/licensing/. Why GreenSock doesn't employ an MIT license: https://greensock.com/why-license/"
|
|
| 922 | i | 0.3.6 | pksunkara |
|
|
| 934 | fuse.js | 3.2.0 | krisk |
"Apache"
|
|
| 949 | rc-util | 4.4.0 | benjycui yesmeck yiminghe |
|
|
| 957 | merge2 | 1.2.1 | zensh |
|


Profile
Friends
Aditional information
Additional information about Shrek
Student at
Telerik Academy
Born in
Somewhere
Living in
Sofia
Working at
Company


Home
About
Introduction
Team
Contact
Register / Login
New York University Campus Transportation Itinerary Planner
Your destination to navigating NYU
Try Now
Enter your trip information below and then click or press
Find Itinerary
.
Where
Origin
Destination
When
Depart at
Arrive by
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Walking
Unlimited walking
Limit to
minutes at a time
No walking
Reset
Option 1
Option 2
Option 3
Itineraries
47 minutes
Walk 0.1 mi to Irving Pl & E 14th St, New York, NY 10003, USA.
04:20 PM on Monday:
Depart from
40.733134199999995,-73.98695459999999
.
04:22 PM on Monday:
Arrive at
14th Street At Irving Place
.
Take Route E.
04:35 PM on Monday:
Depart from
14th Street At Irving Place
.
04:40 PM on Monday:
Arrive at
715 Broadway
.
Walk.
04:40 PM on Monday:
Depart from
715 Broadway
.
04:40 PM on Monday:
Arrive at
721 Broadway
.
Take Route A.
04:45 PM on Monday:
Depart from
721 Broadway
.
Intermediate stops:
04:52 PM on Monday:
Canal At Lafayette Street
05:05 PM on Monday:
MetroTech Roadway At Bridge Street
05:07 PM on Monday:
Arrive at
6 MetroTech
.
48 minutes
Walk 0.1 mi to Irving Pl & E 14th St, New York, NY 10003, USA.
04:20 PM on Monday:
Depart from
40.733134199999995,-73.98695459999999
.
04:22 PM on Monday:
Arrive at
14th Street At Irving Place
.
Take Route E.
04:35 PM on Monday:
Depart from
14th Street At Irving Place
.
04:40 PM on Monday:
Arrive at
715 Broadway
.
Walk.
04:40 PM on Monday:
Depart from
715 Broadway
.
04:40 PM on Monday:
Arrive at
721 Broadway
.
Take Route A. Signal driver to stop.
04:45 PM on Monday:
Depart from
721 Broadway
.
Intermediate stops:
04:52 PM on Monday:
Canal At Lafayette Street
05:05 PM on Monday:
Arrive at
MetroTech Roadway At Bridge Street
.
Walk.
05:05 PM on Monday:
Depart from
MetroTech Roadway At Bridge Street
.
05:08 PM on Monday:
Arrive at
6 MetroTech
.
47 minutes
Walk 0.2 mi to E 17th St & 3rd Ave, New York, NY 10003, USA.
04:20 PM on Monday:
Depart from
40.733134199999995,-73.98695459999999
.
04:23 PM on Monday:
Arrive at
3rd Avenue At 17th Street
.
Take Route E.
04:33 PM on Monday:
Depart from
3rd Avenue At 17th Street
.
Intermediate stops:
04:35 PM on Monday:
14th Street At Irving Place
04:40 PM on Monday:
Arrive at
715 Broadway
.
Walk.
04:40 PM on Monday:
Depart from
715 Broadway
.
04:40 PM on Monday:
Arrive at
721 Broadway
.
Take Route A.
04:45 PM on Monday:
Depart from
721 Broadway
.
Intermediate stops:
04:52 PM on Monday:
Canal At Lafayette Street
05:05 PM on Monday:
MetroTech Roadway At Bridge Street
05:07 PM on Monday:
Arrive at
6 MetroTech
.


The DB->close function is the standard function for closing the database. By default, the close function also flushes all modified records from the database cache to disk.
There is one flag that you can set to customize the returned statistics:
It is important to understand that flushing cached information to disk only minimizes the window of opportunity for corrupted data.
While unlikely, it is possible for database corruption to happen if a system or application crash occurs while writing data to the database. To ensure that database corruption never occurs, applications must either: use transactions and logging with automatic recovery, use logging and application-specific recovery, or edit a copy of the database, and, once all applications using the database have successfully called DB->close, use system operations (e.g., the POSIX 1003.1 rename system call) to atomically replace the original database with the updated copy.


Just In: Troops Clash With Boko Haram In Borno
by George OgboluTroops of the Nigeria Army have successfully dislodged Boko Haram/Islamic State of West Africa Province (ISWAP) terrorists at Malam Fatori in Abadam LGA of Borno.
This was made known in a statement on Saturday by the Nigerian Army Operations Media Coordinator, Col. Aminu Iliyasu.
Col. Iliyasu said the terrorists were dislodged when they attempted to launch an attack on the location of the troops of 64 and 98 Task Force Battalions and elements of the Armed Forces Special Forces Battalion on Friday.
He disclosed that the Boko Haram/ISWAP insurgents had on Wednesday been humiliated by the troops in their attempt to infiltrate the troops’ location by launching an unsuccessful attack.
“Within less than 24 hours of their devastating defeat, however, the outgunned criminal insurgents launched another desperate attack on the highly spirited troops of Mallam Fatori in the wee hours of Friday,” Col. Iliyasu said.
“In a swift and highly coordinated response, the gallant and relentless troops at the location once again handed them another crushing defeat.
“At the end of this particular encounter, one Boko Haram Gun Truck was completely burnt along with 3 of the criminal insurgents that were trapped in it.
“Apparently, the vehicle was gutted by fire as a result of the high volume of fire delivered by the troops.”
Iliyasu also stated that equipment, which included AK 47 Riffles, Anti-Aircraft Gun, were recovered from the terrorists.
“These include one Anti-Aircraft Gun, one Anti-Aircraft Gun barrel, eight AK47 Riffles and one Rocket Propelled Gun tube, three AK 47 magazines, one bandolier, two rounds of Anti-Aircraft Gun ammunition and one Rocket Propelled Grenade bomb.
“Subsequently, the Air Task Force, Operation LAFIYA DOLE went on the trail of the routed remnants of the insurgents to ensure their total obliteration.
“Regrettably, two gallant soldiers sustained gunshot wounds during this encounter. Both of them have already been stabilized and are already responding positively to treatment at a military hospital,” he added.


You requested a reset to your Upstream Academy event password. Please go to our password reset page to choose a new password.
If the above link does not work, try navigating to this address manually: http://event.upstreamacademy.com/reset.php?hash={{HASH}}
If you do not reset your password within three days, the link will expire and you will need to restart the password reset process.
If you have any questions or concerns, please feel free to contact me.


| # | Who | = | Penalty | * | A | B | C | D | E1 | E2 | F |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Alice_Synthesis_Thirty | 7 | 206 | + 00:01 | + 00:04 | + 00:08 | + 00:14 | + 00:29 | +1 00:34 | + 01:46 | |
| 2 | Nasko | 7 | 245 | + 00:01 | + 00:03 | + 00:11 | + 00:19 | + 00:33 | +2 00:48 | + 01:50 | |
| 3 | lengpi6685 | 7 | 274 | + 00:06 | + 00:12 | + 00:17 | + 00:21 | + 01:02 | + 01:01 | + 01:35 | |
| 4 | rush69 | 6 | 103 | + 00:02 | + 00:05 | + 00:14 | + 00:26 | + 00:28 | + 00:28 | ||
| 5 | kyaa | 6 | 118 | + 00:01 | + 00:06 | + 00:12 | + 00:21 | + 00:31 | + 00:47 | ||
| 6 | WO_OD | 6 | 140 | + 00:03 | + 00:09 | + 00:17 | + 00:23 | + 00:44 | + 00:44 | ||
| 7 | nanhtu | 6 | 144 | + 00:02 | + 00:05 | +1 00:09 | + 00:34 | + 00:36 | +1 00:38 | ||
| 8 | NEXUS02 | 6 | 146 | + 00:01 | + 00:04 | + 00:09 | + 00:21 | + 00:56 | + 00:55 | -1 | |
| 9 | GsuICPCDevourer | 6 | 157 | + 00:01 | + 00:11 | + 00:15 | + 00:23 | + 00:54 | + 00:53 | ||
| 10 | Guan233 | 6 | 167 | + 00:03 | + 00:06 | + 00:14 | + 00:18 | + 01:05 | + 01:01 | ||
| 11 | Sxy_Limit | 6 | 168 | + 00:02 | + 00:09 | +1 00:17 | + 00:25 | + 00:53 | + 00:52 | ||
| 11 | alkil | 6 | 168 | + 00:02 | + 00:09 | + 00:15 | + 00:31 | + 00:55 | + 00:56 | -2 | |
| 13 | Chaska | 6 | 169 | + 00:03 | + 00:07 | +1 00:15 | + 00:31 | + 00:52 | + 00:51 | ||
| 14 | Co0per | 6 | 171 | + 00:03 | + 00:09 | + 00:24 | + 00:58 | + 00:39 | + 00:38 | ||
| 15 | wcwac | 6 | 172 | + 00:02 | + 00:10 | + 00:15 | + 00:27 | + 00:53 | +1 00:55 | ||
| 15 | _HossamYehia_ | 6 | 172 | + 00:02 | + 00:05 | + 00:14 | + 00:31 | + 00:53 | + 01:07 | ||
| 17 | deepanshupal000 | 6 | 175 | + 00:03 | + 00:09 | + 00:20 | + 00:31 | + 00:56 | + 00:56 | ||
| 18 | xiaoyaowudi | 6 | 178 | + 00:02 | + 00:08 | + 00:18 | + 00:27 | + 01:02 | + 01:01 | ||
| 19 | one_tech | 6 | 179 | + 00:02 | + 00:08 | + 00:17 | + 00:36 | + 00:58 | + 00:58 | ||
| 20 | yspm | 6 | 180 | + 00:01 | + 00:07 | + 00:12 | + 00:17 | +1 00:51 | +1 01:12 | ||
| 21 | mohaned2014 | 6 | 181 | -3 | + 00:02 | + 00:11 | + 00:18 | + 00:34 | + 00:58 | + 00:58 | |
| 22 | PraneyR | 6 | 184 | + 00:03 | + 00:07 | + 00:13 | + 00:25 | + 00:59 | +1 01:07 | ||
| 23 | Pallove | 6 | 186 | + 00:02 | + 00:08 | +1 00:17 | + 00:32 | + 00:52 | +1 00:55 | ||
| 24 | cwcszzh | 6 | 187 | + 00:02 | + 00:05 | + 00:11 | + 00:20 | + 01:10 | +1 01:09 | -4 | |
| 25 | iLoveIOI | 6 | 188 | + 00:01 | + 00:08 | + 00:10 | + 00:17 | +1 00:36 | +1 01:36 | ||
| 26 | kiviad | 6 | 191 | + 00:01 | + 00:06 | + 00:12 | + 00:20 | +1 00:45 | +2 01:17 | ||
| 26 | Angel_Demon | 6 | 191 | + 00:02 | + 00:10 | + 00:18 | + 00:24 | + 01:08 | + 01:09 | ||
| 28 | OutragedOmar | 6 | 196 | + 00:02 | + 00:04 | + 00:13 | +1 00:38 | + 01:05 | + 01:04 | ||
| 29 | cpt | 6 | 197 | + 00:03 | + 00:08 | + 00:13 | + 00:37 | + 01:09 | + 01:07 | ||
| 30 | nishantc279m | 6 | 201 | + 00:02 | + 00:09 | + 00:14 | + 00:32 | + 00:48 | +1 01:26 | ||
| 30 | SoSmart | 6 | 201 | + 00:02 | + 00:08 | + 00:13 | + 00:29 | + 01:10 | +1 01:09 | ||
| 30 | jonathan.shifman | 6 | 201 | + 00:03 | + 00:07 | + 00:14 | + 00:20 | + 01:18 | + 01:19 | ||
| 30 | Tianwell | 6 | 201 | + 00:02 | +1 00:15 | + 00:32 | + 00:19 | + 01:03 | + 01:00 | ||
| 34 | anhacker | 6 | 203 | + 00:01 | + 00:05 | + 00:15 | +1 00:35 | + 01:02 | + 01:15 | ||
| 35 | kresna | 6 | 204 | + 00:02 | + 00:06 | + 00:22 | + 00:30 | +1 01:00 | +1 01:04 | ||
| 35 | KB2.0 | 6 | 204 | + 00:02 | + 00:16 | + 00:23 | + 00:38 | + 01:02 | + 01:03 | ||
| 35 | majra | 6 | 204 | + 00:03 | + 00:14 | + 00:22 | + 00:33 | + 01:05 | + 01:07 | ||
| 38 | Himangshu | 6 | 207 | + 00:02 | + 00:13 | + 00:22 | + 00:35 | + 01:08 | + 01:07 | ||
| 39 | arjunbangari | 6 | 208 | + 00:02 | + 00:09 | +1 00:22 | + 00:37 | +1 00:56 | + 01:02 | ||
| 39 | loulingli | 6 | 208 | + 00:07 | + 00:11 | + 00:17 | + 01:31 | + 00:42 | + 00:40 | ||
| 39 | timav | 6 | 208 | + 00:01 | + 00:08 | + 00:14 | + 00:29 | + 01:02 | +1 01:24 | ||
| 42 | walkher8 | 6 | 209 | + 00:03 | + 00:09 | + 00:15 | + 00:51 | + 01:05 | + 01:06 | ||
| 42 | bl4ckfr05t | 6 | 209 | + 00:03 | + 00:09 | + 00:18 | + 00:30 | + 01:00 | + 01:29 | ||
| 42 | Incognito_Mode_On | 6 | 209 | + 00:04 | + 00:12 | + 00:18 | + 00:38 | + 01:08 | + 01:09 | ||
| 45 | dogatekin | 6 | 211 | + 00:03 | + 00:10 | + 00:22 | + 00:34 | + 01:03 | + 01:19 | ||
| 45 | shurlibek | 6 | 211 | + 00:02 | + 00:11 | + 00:18 | + 00:31 | + 01:02 | + 01:27 | ||
| 47 | adman | 6 | 212 | + 00:03 | + 00:07 | + 00:14 | +1 00:43 | + 01:02 | +1 01:03 | ||
| 48 | bovvlet | 6 | 213 | -2 | + 00:02 | + 00:07 | +1 00:17 | + 01:02 | +1 00:52 | + 00:53 | |
| 48 | bhabyajain_brj | 6 | 213 | + 00:02 | + 00:10 | + 00:21 | + 00:41 | + 01:11 | + 01:08 | ||
| 48 | Micc | 6 | 213 | + 00:02 | + 00:10 | + 00:21 | + 00:34 | + 01:02 | + 01:24 | ||
| 48 | jeeva2812 | 6 | 213 | + 00:05 | + 00:11 | + 00:18 | + 00:25 | + 01:01 | +2 01:13 | ||
| 52 | tarush | 6 | 214 | + 00:02 | + 00:11 | + 00:24 | + 00:36 | + 01:10 | + 01:11 | ||
| 53 | man_of_learning | 6 | 215 | + 00:02 | + 00:08 | + 00:15 | + 00:28 | + 01:22 | + 01:20 | ||
| 54 | Mooshroom | 6 | 216 | + 00:04 | + 00:15 | + 00:25 | + 00:29 | + 01:12 | + 01:11 | ||
| 54 | 00101010 | 6 | 216 | + 00:03 | + 00:10 | +1 00:23 | + 00:31 | + 01:04 | + 01:15 | ||
| 54 | upset | 6 | 216 | + 00:03 | + 00:09 | +1 00:24 | + 00:27 | + 00:38 | +1 01:35 | ||
| 54 | sandy999 | 6 | 216 | + 00:03 | + 00:12 | + 00:19 | + 00:25 | + 00:56 | + 01:41 | ||
| 58 | pawmro | 6 | 218 | + 00:02 | + 00:08 | + 00:20 | + 00:23 | + 01:23 | + 01:22 | ||
| 59 | rijndael | 6 | 219 | + 00:02 | + 00:06 | + 00:13 | + 00:23 | + 00:49 | +2 01:46 | ||
| 59 | chef_lsn | 6 | 219 | + 00:04 | + 00:14 | + 00:26 | + 00:33 | + 01:10 | + 01:12 | ||
| 61 | himkha_100 | 6 | 220 | + 00:02 | + 00:06 | + 00:14 | + 00:19 | +2 01:19 | + 01:20 | ||
| 62 | Amplifier. | 6 | 221 | -1 | + 00:03 | + 00:07 | + 00:14 | +1 00:33 | +1 01:11 | + 01:13 | |
| 62 | aayush_bhat1999 | 6 | 221 | + 00:04 | + 00:12 | + 00:19 | +1 00:42 | + 01:07 | + 01:07 | ||
| 64 | henu_jjl | 6 | 222 | + 00:04 | + 00:10 | + 00:17 | + 00:34 | + 00:54 | + 01:43 | ||
| 64 | manish_98 | 6 | 222 | + 00:02 | + 00:08 | +1 00:37 | + 00:29 | + 00:51 | +1 01:15 | ||
| 66 | ErfanMirshams | 6 | 223 | + 00:03 | + 00:09 | + 00:21 | + 00:26 | + 01:14 | +1 01:20 | ||
| 66 | TAI_zJack1342 | 6 | 223 | + 00:03 | + 00:10 | + 00:19 | + 00:42 | + 01:15 | + 01:14 | ||
| 68 | boboshka | 6 | 225 | + 00:02 | + 00:17 | + 00:11 | + 00:34 | + 00:47 | + 01:54 | ||
| 68 | sajjad.h | 6 | 225 | + 00:04 | + 00:13 | + 00:24 | + 00:42 | + 01:11 | + 01:11 | ||
| 68 | JARVIS99 | 6 | 225 | + 00:02 | + 00:07 | + 00:18 | + 00:34 | + 00:52 | +2 01:32 | ||
| 71 | osmium | 6 | 226 | + 00:03 | + 00:07 | +2 00:25 | + 00:40 | + 01:07 | + 01:04 | ||
| 71 | localhost_<IP_ADDRESS> | 6 | 226 | + 00:03 | + 00:11 | + 00:22 | + 00:35 | + 01:18 | + 01:17 | ||
| 73 | rebel_2020 | 6 | 227 | + 00:03 | + 00:09 | + 00:16 | + 00:28 | + 00:45 | +4 01:26 | ||
| 73 | steam_giant | 6 | 227 | + 00:02 | + 00:06 | + 00:14 | +1 00:27 | + 00:53 | +3 01:25 | ||
| 73 | chon | 6 | 227 | + 00:02 | + 00:11 | + 00:19 | + 00:37 | + 01:18 | + 01:20 | ||
| 73 | rpkv | 6 | 227 | + 00:02 | + 00:10 | + 00:18 | + 00:44 | + 01:02 | + 01:31 | ||
| 77 | PPPOE | 6 | 228 | + 00:02 | + 00:06 | +1 00:15 | + 00:26 | +1 01:17 | + 01:22 | ||
| 77 | Darko | 6 | 228 | + 00:03 | + 00:08 | +1 00:29 | + 00:38 | + 01:08 | + 01:12 | ||
| 79 | zm1999 | 6 | 229 | + 00:03 | + 00:11 | + 00:20 | + 00:34 | + 00:59 | + 01:42 | ||
| 79 | The_Flash_ | 6 | 229 | + 00:03 | + 00:10 | + 00:19 | + 00:33 | + 01:12 | + 01:32 | ||
| 79 | AswatthaFei | 6 | 229 | -1 | + 00:01 | + 00:06 | + 00:13 | + 00:24 | + 00:58 | +4 01:27 | |
| 82 | redming | 6 | 230 | + 00:01 | + 00:18 | + 00:24 | + 00:34 | + 01:17 | + 01:16 | ||
| 82 | JUSIAR | 6 | 230 | + 00:04 | + 00:07 | + 00:12 | + 00:24 | + 00:52 | +4 01:31 | ||
| 82 | wannaak | 6 | 230 | + 00:02 | + 00:12 | + 00:12 | + 00:33 | + 01:11 | + 01:40 | ||
| 85 | Linear__ | 6 | 231 | + 00:02 | + 00:14 | + 00:23 | + 00:42 | + 01:06 | + 01:24 | ||
| 86 | FYG | 6 | 233 | + 00:02 | + 00:07 | + 00:11 | + 00:48 | +1 01:17 | + 01:18 | ||
| 86 | fengquyoumo | 6 | 233 | + 00:03 | + 00:09 | + 00:18 | + 00:38 | + 01:09 | +1 01:26 | ||
| 86 | Mr.Erdal | 6 | 233 | + 00:02 | + 00:06 | + 00:10 | + 00:27 | + 01:24 | +2 01:24 | ||
| 89 | Desmond_528 | 6 | 236 | + 00:03 | + 00:09 | + 00:32 | + 00:35 | + 00:55 | + 01:42 | ||
| 90 | SphericalPotatoInVacuum | 6 | 237 | + 00:05 | + 00:12 | + 00:27 | + 00:38 | + 01:01 | + 01:34 | ||
| 90 | PandaIsTheBest | 6 | 237 | + 00:02 | + 00:10 | + 00:18 | + 00:34 | + 01:08 | + 01:45 | ||
| 90 | wpst | 6 | 237 | + 00:03 | + 00:09 | + 00:16 | + 00:59 | + 01:15 | + 01:15 | ||
| 90 | valkyire | 6 | 237 | + 00:03 | + 00:10 | + 00:17 | + 00:24 | +1 01:17 | + 01:36 | ||
| 94 | vrishinvv | 6 | 238 | + 00:02 | + 00:08 | + 00:24 | + 00:36 | + 00:59 | +1 01:39 | ||
| 95 | Molukhyyeh | 6 | 239 | + 00:01 | + 00:06 | +1 00:16 | + 00:24 | +1 01:12 | +1 01:30 | ||
| 96 | _OvO | 6 | 240 | + 00:07 | + 00:09 | + 00:10 | + 00:23 | + 01:07 | +1 01:54 | ||
| 96 | dapingguo8 | 6 | 240 | -11 | + 00:00 | + 00:04 | +1 00:17 | + 00:28 | + 01:25 | + 01:36 | |
| 98 | northsky0307 | 6 | 241 | + 00:02 | + 00:06 | + 00:13 | + 00:17 | + 01:42 | + 01:41 | ||
| 99 | NotIdeal | 6 | 242 | + 00:02 | + 00:08 | + 00:17 | + 00:37 | +1 01:17 | +1 01:21 | ||
| 99 | MasterTaster | 6 | 242 | + 00:02 | + 00:07 | + 00:16 | +1 00:36 | + 00:57 | + 01:54 | ||
| 99 | h1dd3n_c0d3r | 6 | 242 | + 00:03 | + 00:11 | + 00:25 | + 00:42 | + 01:04 | + 01:37 | ||
| 102 | icesaver | 6 | 243 | + 00:03 | + 00:10 | + 00:19 | + 00:28 | + 00:57 | +3 01:36 | ||
| 103 | Decayed | 6 | 244 | + 00:01 | + 00:04 | + 00:13 | + 01:00 | + 00:33 | +3 01:43 | ||
| 104 | JakubLap | 6 | 245 | + 00:03 | + 00:06 | + 00:12 | + 00:34 | +1 01:30 | + 01:30 | ||
| 105 | gerasikov.fml31 | 6 | 246 | + 00:02 | +1 00:12 | + 00:30 | + 00:21 | + 00:57 | +3 01:24 | ||
| 106 | Ankit__ | 6 | 247 | + 00:02 | + 00:06 | +2 00:16 | + 00:34 | + 00:55 | + 01:54 | ||
| 106 | mapleaves | 6 | 247 | + 00:04 | + 00:12 | + 00:22 | + 00:37 | + 01:27 | + 01:25 | ||
| 108 | vijasi | 6 | 248 | + 00:02 | + 00:11 | +1 00:17 | + 00:45 | + 01:11 | + 01:32 | ||
| 108 | ozy1220 | 6 | 248 | + 00:04 | + 00:12 | + 00:23 | + 00:38 | + 01:20 | + 01:31 | ||
| 108 | vaibhavnandan | 6 | 248 | + 00:03 | + 00:11 | + 00:22 | + 00:35 | + 01:13 | + 01:44 | ||
| 111 | UnderDog_2199 | 6 | 249 | + 00:03 | + 00:16 | + 00:24 | + 00:40 | + 01:18 | + 01:28 | ||
| 112 | PeekyBlinders | 6 | 250 | + 00:01 | + 00:06 | +4 00:26 | + 00:39 | + 01:02 | +1 01:06 | ||
| 113 | pratyush_1605 | 6 | 251 | + 00:03 | + 00:10 | + 00:19 | + 00:29 | + 01:20 | + 01:50 | ||
| 114 | liagol | 6 | 252 | + 00:04 | + 00:11 | + 00:19 | + 00:43 | + 01:28 | + 01:27 | ||
| 114 | allisyonok | 6 | 252 | + 00:02 | + 00:10 | + 00:19 | + 00:37 | +1 01:10 | + 01:44 | ||
| 114 | Not_So_Cool | 6 | 252 | + 00:05 | + 00:16 | + 00:25 | + 00:48 | + 01:08 | + 01:30 | ||
| 117 | FedorX | 6 | 253 | + 00:01 | + 00:09 | + 00:21 | + 00:40 | + 01:28 | + 01:34 | ||
| 117 | _Ani | 6 | 253 | + 00:02 | + 00:10 | + 00:22 | + 00:37 | + 01:29 | + 01:33 | ||
| 117 | maclin726 | 6 | 253 | + 00:04 | + 00:08 | + 00:27 | + 00:18 | + 01:38 | + 01:38 | ||
| 120 | BlackWidow. | 6 | 255 | + 00:04 | + 00:20 | + 00:27 | + 00:37 | + 01:20 | + 01:27 | ||
| 120 | Georgiy_Ulanov | 6 | 255 | + 00:02 | + 00:09 | + 00:15 | + 00:18 | + 01:08 | +3 01:53 | ||
| 122 | shree_01 | 6 | 256 | + 00:03 | + 00:10 | + 00:19 | + 00:33 | + 01:35 | + 01:36 | ||
| 122 | Shajib_ | 6 | 256 | + 00:02 | + 00:12 | + 00:21 | + 00:37 | + 01:32 | + 01:32 | ||
| 124 | brenner1 | 6 | 258 | + 00:02 | + 00:09 | + 00:19 | + 00:29 | +2 01:24 | + 01:35 | ||
| 124 | NumberFreak | 6 | 258 | + 00:02 | + 00:09 | +1 00:23 | + 00:37 | + 01:22 | +1 01:25 | ||
| 124 | wooyaggo | 6 | 258 | + 00:03 | + 00:16 | + 00:29 | + 00:42 | + 01:25 | + 01:23 | ||
| 124 | IWMG | 6 | 258 | + 00:01 | + 00:05 | + 00:18 | + 00:44 | + 01:22 | +2 01:28 | ||
| 128 | Horcrux1729 | 6 | 259 | + 00:02 | + 00:06 | + 00:11 | + 00:24 | + 01:25 | +3 01:41 | ||
| 128 | Bruteforcer101 | 6 | 259 | + 00:02 | + 00:07 | + 00:20 | + 00:36 | + 01:05 | +2 01:49 | ||
| 130 | tmsaad | 6 | 260 | + 00:02 | + 00:07 | + 00:20 | + 00:43 | + 01:24 | + 01:44 | ||
| 130 | Aman_j1 | 6 | 260 | + 00:03 | + 00:29 | + 00:20 | + 00:45 | + 01:02 | +1 01:31 | ||
| 130 | Carlos_Ecos3 | 6 | 260 | + 00:05 | + 00:11 | +1 00:21 | + 00:47 | + 01:11 | + 01:35 | ||
| 133 | Boboge | 6 | 261 | + 00:02 | + 00:09 | + 00:20 | + 00:31 | +1 01:25 | + 01:44 | ||
| 134 | kadom | 6 | 262 | + 00:02 | + 00:10 | + 00:19 | + 00:36 | + 01:08 | +1 01:57 | ||
| 134 | TTNhan | 6 | 262 | + 00:03 | + 00:10 | + 00:26 | + 00:40 | +2 01:13 | + 01:30 | ||
| 134 | xterrafunny | 6 | 262 | + 00:02 | + 00:14 | + 00:24 | + 00:32 | +2 01:20 | +1 01:20 | ||
| 134 | N3RDSLQYER84 | 6 | 262 | + 00:04 | + 00:14 | + 00:18 | + 00:42 | +2 01:15 | +1 01:19 | ||
| 138 | ionanghelina | 6 | 263 | + 00:02 | + 00:11 | +1 00:21 | + 00:46 | + 00:35 | +4 01:38 | ||
| 138 | jshx | 6 | 263 | + 00:04 | + 00:14 | + 00:24 | + 00:33 | + 01:04 | +2 01:44 | ||
| 138 | vxpsn | 6 | 263 | + 00:01 | + 00:18 | +3 00:31 | + 00:40 | + 00:58 | +1 01:15 | ||
| 138 | SadraRide | 6 | 263 | + 00:45 | +1 00:52 | + 00:39 | + 01:02 | + 00:27 | + 00:28 | ||
| 138 | NeoZap | 6 | 263 | +3 | + 00:01 | + 00:05 | +2 00:25 | + 00:37 | +1 01:03 | +2 01:22 | |
| 143 | ManavJ07 | 6 | 264 | + 00:01 | + 00:07 | + 00:11 | + 00:20 | + 00:47 | +7 01:48 | ||
| 144 | qwerty190 | 6 | 265 | + 00:04 | + 00:13 | +2 00:27 | + 00:49 | + 01:15 | + 01:17 | ||
| 144 | aniket.shrimal | 6 | 265 | + 00:02 | + 00:06 | + 00:12 | + 00:26 | + 01:40 | +1 01:49 | ||
| 144 | fmwviormv | 6 | 265 | + 00:04 | + 00:12 | + 00:21 | + 00:53 | + 01:27 | + 01:28 | ||
| 147 | Patrusheva_Anna | 6 | 266 | + 00:04 | + 00:09 | + 00:27 | + 00:48 | + 01:23 | +1 01:25 | ||
| 147 | omega07 | 6 | 266 | + 00:03 | + 00:07 | + 00:15 | + 00:35 | +1 01:36 | + 01:40 | ||
| 147 | shivam2298 | 6 | 266 | + 00:04 | + 00:12 | + 00:23 | + 00:42 | + 01:32 | + 01:33 | ||
| 147 | nicholasnovakovic | 6 | 266 | + 00:02 | + 00:05 | +1 00:29 | + 00:32 | +1 01:24 | +1 01:24 | ||
| 147 | nihal77 | 6 | 266 | + 00:02 | + 00:16 | +1 00:27 | + 00:45 | + 01:16 | +1 01:20 | ||
| 152 | learnjava | 6 | 267 | + 00:03 | + 00:09 | + 00:16 | +1 00:41 | + 01:29 | +1 01:29 | ||
| 152 | iq10 | 6 | 267 | + 00:04 | + 00:16 | +1 00:25 | + 00:48 | + 01:07 | +2 01:17 | ||
| 154 | gustavo0votagus | 6 | 268 | + 00:02 | + 00:07 | + 00:13 | + 00:36 | + 01:26 | +2 01:44 | ||
| 154 | MartyByrde | 6 | 268 | -1 | + 00:03 | + 00:11 | + 00:17 | + 00:38 | + 01:05 | +2 01:54 | |
| 156 | Gj2 | 6 | 269 | + 00:01 | +1 00:24 | + 00:17 | + 00:54 | +2 00:47 | +1 01:26 | ||
| 156 | IonicBlade | 6 | 269 | + 00:01 | + 00:04 | + 00:10 | +1 00:21 | + 01:52 | + 01:51 | ||
| 156 | Anatoly.ig | 6 | 269 | + 00:04 | + 00:14 | + 00:28 | + 00:47 | + 01:22 | +1 01:24 | ||
| 159 | _Muhammad | 6 | 270 | + 00:04 | + 00:11 | + 00:19 | + 00:52 | + 01:15 | +1 01:39 | ||
| 160 | ayush_hazard | 6 | 271 | + 00:02 | +1 00:17 | +1 00:31 | + 00:35 | +2 01:12 | + 01:14 | ||
| 160 | hardShoft | 6 | 271 | + 00:04 | + 00:10 | + 00:16 | + 00:26 | + 01:21 | +4 01:34 | ||
| 160 | AshrafEzz | 6 | 271 | + 00:03 | + 00:09 | + 00:21 | + 00:41 | + 01:19 | +2 01:38 | ||
| 160 | js9556 | 6 | 271 | + 00:03 | + 00:14 | + 00:22 | + 00:47 | + 01:31 | + 01:34 | ||
| 160 | AmDer | 6 | 271 | + 00:02 | + 00:07 | + 00:17 | + 00:29 | +2 01:08 | +1 01:58 | ||
| 165 | kartik19 | 6 | 272 | + 00:02 | + 00:08 | + 00:17 | + 00:40 | + 01:10 | +2 01:55 | ||
| 165 | zhouxiansheng | 6 | 272 | + 00:05 | + 00:11 | + 00:18 | + 00:41 | + 01:39 | + 01:38 | ||
| 165 | _------_ | 6 | 272 | + 00:03 | + 00:11 | + 00:21 | + 01:41 | + 01:04 | +1 01:02 | ||
| 165 | Peton | 6 | 272 | + 00:03 | + 00:15 | + 00:25 | + 00:49 | +1 01:24 | + 01:26 | ||
| 169 | teju1 | 6 | 274 | + 00:08 | + 00:16 | + 00:30 | + 00:49 | + 01:22 | + 01:29 | ||
| 169 | caiocandido | 6 | 274 | + 00:05 | + 00:10 | + 00:22 | + 00:41 | + 01:30 | +1 01:36 | ||
| 169 | shafinalam | 6 | 274 | + 00:03 | + 00:13 | + 00:22 | + 00:33 | + 01:41 | + 01:42 | ||
| 172 | Kiona0405 | 6 | 275 | + 00:05 | + 00:11 | + 00:22 | + 00:45 | + 01:36 | + 01:36 | ||
| 173 | vankata089 | 6 | 276 | + 00:02 | +1 00:12 | + 00:18 | + 00:36 | +1 01:07 | +1 01:51 | ||
| 173 | kevin19984 | 6 | 276 | + 00:05 | + 00:11 | + 00:22 | + 00:35 | + 01:32 | + 01:51 | ||
| 173 | quandum | 6 | 276 | + 00:05 | + 00:14 | +1 00:33 | + 00:41 | + 01:26 | + 01:27 | ||
| 176 | singhaldiksha1 | 6 | 277 | + 00:02 | + 00:11 | +1 00:26 | + 00:41 | +1 01:17 | +1 01:30 | ||
| 177 | lizzzzzzzzzz | 6 | 278 | + 00:03 | + 00:11 | + 00:27 | +1 00:48 | + 01:20 | + 01:39 | ||
| 177 | Plalyy | 6 | 278 | + 00:03 | + 00:13 | + 00:26 | + 00:47 | + 01:17 | +2 01:32 | ||
| 177 | zeus_orz1 | 6 | 278 | + 00:03 | + 00:09 | + 00:16 | +1 00:44 | + 01:39 | + 01:37 | ||
| 177 | vikas132success | 6 | 278 | + 00:05 | + 00:13 | + 00:21 | + 00:47 | + 01:20 | +1 01:42 | ||
| 177 | Alex_3102 | 6 | 278 | + 00:03 | + 00:09 | + 00:19 | + 00:28 | +1 01:37 | +1 01:42 | ||
| 182 | forcabarca | 6 | 279 | + 00:03 | + 00:08 | + 00:22 | + 00:38 | + 01:14 | +3 01:44 | ||
| 182 | johnsourour | 6 | 279 | + 00:03 | + 00:09 | + 00:20 | + 00:28 | +1 01:29 | +2 01:40 | ||
| 182 | grass_lin | 6 | 279 | + 00:16 | + 00:27 | + 00:12 | + 00:48 | + 01:27 | + 01:29 | ||
| 182 | _alpinist_ | 6 | 279 | + 00:02 | + 00:12 | + 00:19 | + 01:00 | + 01:33 | + 01:33 | ||
| 182 | ghosh.arkapravo | 6 | 279 | + 00:02 | + 00:14 | +1 00:25 | + 00:37 | + 01:04 | +1 01:57 | ||
| 182 | _bacali | 6 | 279 | -1 | + 00:02 | + 00:09 | +1 00:19 | + 00:33 | + 01:42 | + 01:44 | |
| 188 | parth_07 | 6 | 280 | + 00:03 | + 00:09 | + 00:16 | + 00:39 | +2 01:36 | + 01:37 | ||
| 188 | random_chemical | 6 | 280 | + 00:03 | + 00:08 | + 00:31 | + 00:52 | + 01:29 | +1 01:27 | ||
| 190 | YingLi_ZW | 6 | 281 | + 00:01 | + 00:08 | + 00:20 | + 00:33 | + 01:38 | +1 01:51 | ||
| 190 | JOF | 6 | 281 | + 01:01 | + 00:56 | + 01:11 | + 00:45 | + 00:25 | + 00:23 | -1 | |
| 190 | farzi.coder | 6 | 281 | + 00:05 | + 00:15 | + 00:30 | + 00:44 | + 01:31 | + 01:36 | ||
| 190 | suun_ | 6 | 281 | + 00:05 | + 00:08 | + 00:14 | + 00:46 | + 01:19 | +1 01:59 | ||
| 190 | Dream.to | 6 | 281 | + 00:04 | + 00:10 | + 00:18 | + 01:35 | + 01:17 | + 01:17 | ||
| 195 | neganega | 6 | 282 | + 00:04 | + 00:23 | + 00:40 | + 00:43 | + 00:15 | +5 01:47 | ||
| 195 | little_finger | 6 | 282 | + 00:04 | + 00:16 | + 00:30 | + 00:49 | + 01:29 | + 01:34 | ||
| 197 | aurora_ | 6 | 283 | + 00:04 | + 00:09 | + 00:16 | + 00:43 | + 01:38 | +1 01:43 | ||
| 197 | Hikiri | 6 | 283 | + 00:04 | + 00:09 | + 00:20 | + 00:34 | + 01:38 | +1 01:48 | ||
| 199 | cboy | 6 | 284 | + 00:03 | + 00:11 | + 00:19 | + 01:45 | + 00:54 | + 01:32 | ||
| 199 | Sabamak | 6 | 284 | + 00:03 | + 00:12 | +1 00:26 | + 00:40 | + 01:35 | + 01:38 | ||
|
Accepted
Tried |
11648 11665 |
9845 10408 |
8673 10262 |
6308 6661 |
1499 2649 |
368 1059 |
6 15 |


One by One
Source of witness transcribed: Daily American Organ (Washington, D.C.)
Date of witness transcribed: 24 May 1855
Notes about this poem: "One by One" was printed in at least 201 newspapers during the nineteenth century. It can be found using ID 2073537 in this table of most widely-reprinted poems.
It was also a popular hymn, as can be seen here.
§
- One by one the sands are flowing,
- One by one the moments fall;
- Some are coming, some are going,
-
Do not strive to grasp them all.
- One by one thy duties wait thee,
- Let the whole strength go to each,
- Let not future dreams elate thee,
-
Learn thou first what these can teach.
- One by one (bright gifts from Heaven,)
- Joys are sent thee here below;
- Take them readily when given,
-
Ready, too, to let them go.
- One by one thy griefs shall meet thee,
- Do not fear an armed band;
- One will fade as others greet thee,
-
Shadows passing through the land.
- Do not look at life’s long sorrow;
- See how small each movement’s pain;
- God will help thee for to-morrow:
-
Every day begin again.
- Every hour that fleets so slowly,
- Has its task to do or bear;
- Luminous the crown, and holy,
-
If thou set each gem with care.
- Do not linger with regretting,
- Or for passion hours despond;
- Nor, the daily toil forgetting,
-
Look too eagerly beyond.
- Hours are golden links, God’s token,
- Reaching Heaven; but one by one,
- Take them lest the chain be broken
- Ere the pilgrimage be done.


Traffic Portal Administration¶
The following are requirements to ensure an accurate set up:
- CentOS 6.7 or 7
- Node.js 6.0.x or above
Installing Traffic Portal
- Download the Traffic Portal RPM from Apache Jenkins or build the Traffic Portal RPM from source (./pkg -v traffic_portal_build).
- Copy the Traffic Portal RPM to your server
- curl –silent –location https://rpm.nodesource.com/setup_6.x | sudo bash -
- sudo yum install -y nodejs
- sudo yum install -y <traffic_portal rpm>
Configuring Traffic Portal
- update /etc/traffic_portal/conf/config.js (if upgrade, reconcile config.js with config.js.rpmnew and then delete config.js.rpmnew)
- update /opt/traffic_portal/public/traffic_portal_properties.json (if upgrade, reconcile traffic_portal_properties.json with traffic_portal_properties.json.rpmnew and then delete traffic_portal_properties.json.rpmnew)
- [OPTIONAL] update /opt/traffic_portal/public/resources/assets/css/custom.css (to customize traffic portal skin)
Starting Traffic Portal
- sudo service traffic_portal start
Stopping Traffic Portal
- sudo service traffic_portal stop


---
layout: page
title: Science Tourist
image: family.jpg
---
{% for post in site.categories.sample %}
Science Tourist
{% endfor %}
Science Tourist
What?
A family science travel series
Who?
The Holbrook-Davé Family loves to travel and explore science & technology in exotic places like Cape Town and in our own backyard like Washington D.C.!
Romeel Davé explores history of science, physics, mechanics, and scientific breakthroughs. Jarita Holbrook explores astronomy, women in science, diversity, and enjoys interviewing scientists excited about their research. Mirabai explores water, aquaculture, plants, and cool places like aquariums. Jasmina, the youngest explores restaurants, local culture, local & ancient textiles, and she cooks for the family.
Where?
You can see our explorations of Edinburgh, United Kingdom, Washington D.C., USA, and Cape Town, South Africa! Next we explore Tenerife, Spain, and Glasgow, United Kingdom.
Follow us!
Our episodes are found on the series YouTube Channel https://www.youtube.com/channel/UCvR_8tSJ-UoonGUMvUOvn7w


DOCTYPE html>
10 minutes| Serves 4|
A bowl of Peanut Butter Cup Chia Seed Pudding will have you feeling like you're eating candy. This chocolatey recipe makes a nutritious breakfast or snack!
Ingredients:
1/2 cup chia seeds
2 cups almond milk
1/4 cup cocoa powder
2-3 tablespoons maple syrup or agave nectar
1 1/2 teaspoons vanilla extract, divided
1/4 teaspoon salt
2 tablespoons natural peanut butter
1/8 teaspoons cinnamon
Instructions:
n a medium bowl, add 5½ tablespoons chia seeds, 1⅓ cups milk, cocoa powder, 1-2 tablespoons maple syrup, 1 teaspoon vanilla, and ¼ teaspoon salt. Whisk until all ingredients are combined. In a small bowl, add 2½ tablespoons chia seeds, ⅔ cup milk, peanut butter, 1 tablespoon maple syrup, ½ teaspoon vanilla, ⅛ teaspoon salt, and cinnamon. Whisk until all ingredients are combined. Place both bowls in the fridge. Let them sit overnight, or at least 3 hours. To arrange, scoop desired amount of chocolate chia seed pudding into a cup or bowl, top with a scoop of peanut butter chia seed pudding, then another chocolate layer. Top with whatever you'd like!