Release - Come With Us...
This was my first experience with Salvia Divinorum. I had been told about it by a friend and had read a lot about it on the internet. A friend who was travelling in Australia found some in an herb shop and sent me about a gram. He said that he had smoked it with some weed and had felt nothing.
Although I've tried most substances, illegal or otherwise, I was a little nervous about taking it as I really didn't know quite what to expect. I headed into it with a reverential attitude, knowing that the plant has been known to turn on the ignorant. I arranged for a friend to be my sitter, but really he was just in the room with me as he was busy playing video games.
I packed a bowl full in my regular weed pipe and sat down on the couch. I took a huge haul and held it in for as long as possible, exhaled, and took another smaller haul.
Immediately I felt something. A strange tingling sensation unlike anything I'd felt before.  I felt really strange and had to lie down on the couch. As I was laying down I began to hear music in my head. I can't remember if I made it up or if it was a song I had heard before. At this point I closed my eyes and could see fractal type patterns dancing in sync with the music. They moved in a clockwise direction until they completely filled my field of vision.
During this, I could feel a distinct pulling sensation on the right side of my body, which would have been south. I sensed the presence of 3 beings as well, one male and two female. The male seemed the most dominant, and they were urging me to 'release' and 'come with us'. I couldn't hear them per se, but these words somehow came to me. They weren't frightening at all, but rather welcomed me into their world. They obviously wanted to show me something, but I was unable to 'release' due to being distracted; I could hear my friend tapping buttons while playing games (he had headphones on) and I could feel the couch pressing against me and was rather uncomfortable.
By this time, I realized that I wasn't going to be able to 'release' and I opened my eyes for the first time. I was a little overwhelmed and decided it was best not to move for a while. I closed my eyes again, but the visuals were waning and I was coming down. As soon as I felt comfortable, I opened my eyes and stood up. All this had lasted no more than 5 minutes, but wherever I had been, there was no time.  I felt an overwhelming need to step out into the sunshine and feel something 'real'.
One of my friends just happened to be coming up to my house, and we went inside and smoked some weed. This lengthened the comedown and I didn't feel sober for about another hour and a half. But even the next day I could feel something different. Hard to put my finger on, but different nonetheless. On the whole it was a positive experience. Salvia is truly like no other drug I've tried. I look forward to being able to 'release'. And I know there is much that can be learned from this plant.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


--- title: "Research Projects" layout: archive excerpt: "Introduction to Karthik's research projects" sitemap: false permalink: /projects/ author_profile: true --- {% include base_path %}


Blocks, Procs, and Lambdas
A lot better than lions, tigers, and bears
This is the first time I’ve gotten the opportunity to teach you about a concept that I didn’t know existed before Dev Bootcamp. That’s not to say I haven’t learned anything at DBC, I’ve learned more about Ruby than I have about any other coding language I’ve ever worked on. However, the concepts of methods, objects, classes, variables, constants, globals, arrays, hashes, etc. were all something I’ve worked with before when learning Python, Java, Basic, C++, or Cache. I picked this topic because I had literally no idea what it was about and I am excited to explore the world of everything in the coding world that I don’t yet know.
I’ve been using blocks of code for awhile now without knowing what they were called. Below is an example of a block:
array.map! { |x| x+10 }
Everything inside of the curly brackets is a block of code. You can also use the do … end
combination to identify the start and end of the block. They work exactly the same as the curly brackets. In this relatively simple example a block works perfectly fine, but in some cases you will want to put significantly more code to pass into a method or even create methods that take multiple blocks of code! To do all of these fancy things we can use Procs or Lambdas.
Below is an example of a Proc.
p = Proc.new{ |x| x+10 }
Essentially, what we are doing is taking the block of code and storing it in a special kind of object called a Proc. Proc is short for Procedure. Ok, now that we have a Proc, what do we do with it? Well, we can use it anywhere we would normally use a block such as:
array.map! { p }
Doesn’t that look simple?! Amazing, right? Taking it a step further, we can create a Lambda using the syntax:
lam = lambda{ |x| x + 10 }
As you can see, the syntax is even simpler than using a Proc. Although, we don’t explicitly create a new object with the Object.new
command we’re used to, we are creating a new object. We are actually creating a Proc object! We can then use the lam
anywhere we could use a block or a Proc.


I am a
From Rajasthan,doing gym is good for healthy life. it helps our body to fit. it release stress from our mind.
I am a Gym Trainer
From Rajasthan,doing gym is good for healthy life. it helps our body to fit. it release stress from our mind.From Rajasthan,doing gym is good for healthy life. it helps our body to fit. it release stress from our mind.
From Rajasthan,doing gym is good for healthy life.
What we Provide
From Rajasthan,doing gym is good for healthy life.
From Rajasthan,doing gym is good for healthy life.
From Rajasthan,doing gym is good for healthy life.
From Rajasthan,doing gym is good for healthy life.
From Rajasthan,doing gym is good for healthy life.
From Rajasthan,doing gym is good for healthy life.
What our gym member says
From Rajasthan,doing gym is good for healthy life. it helps our body to fit. it release stress from our mind.From Rajasthan,doing gym is good for healthy life. it helps our body to fit. it release stress from our mind.
What we Provide
We are Available
<EMAIL_ADDRESS>823944147, 823944140
Near Shyam Mandir
Ward no.5, Laxmangarh (Sikar), Rajasthan


Control panel displaying all event your are organizaing, attending or speaking at.
Whenever you are interested in a specific resource, you can bookmark it and come back later trougth the bookmar menu
All your ticket are available directly on the panel. You will have the chance to validate, pay or just print any of your tickets


WorldBuilder - Code Overview
Introduction
This is an introduction to and overview of the code for the WorldBuilder application.
The intended audience is (ideally Java) programmers who are interested in understanding
the design and operation of this tool.
The descriptions are presented in three parts:
History
The development of this tool was motivated by
Christopher Kampe's
observation that, in RPG development, the creation of the underlying maps had
a relatively poor cost/value performance. He wanted to make it easy for
game developers to start with realistic maps, atop of which they could
add their more creative and interesting features and encounters.
This program is majorly inspired by the
Martin O'Leary's
Uncharted Atlas project.
His
Terrain Builder is a
JavaScript Web-app to synthesize pages of a fantasy Atlas.
The
WorldBuilder
is Java application to enable game designers
to create 3D regional landscapes that can be exported as maps for a
variety of computer-based Role Playing Games (starting with RPG Maker).
While these goals have very different scopes, calling for rather
different approaches, this program still draws heavily on several of
O'Leary's insights:
- defining a large Cartesian landscape by
interpolations of the altitudes of (randomly
placed) points in a Voronoi mesh.
- defining (satisfyingly irregular) topographic
features by imposing vertical displacements associated
with regular (e.g. conical) geometric figures
on the random Voronoi mesh.
- simplifying the simulation of water-flow by
restricing all flow to the paths between
(the few) points in the Voronoi mesh
- using that flow to compute erosion as a
downards deformation of the points through
which water flowed.
- defining geo-political borders as the points
where the cost of travel from two adjacent
capitals are equal.
The evolution of this tool has been driven by a combination of
Mark Kampe's
architectural thoughts (about how to structure geo-physics simulations
and plug-in RPG-map exporters) and
Christopher Kampe's experiences (with how to make a more usable tool
for creating satisfying worlds).
After studying O'Leary's work, I came up with my own (surely personal) prime directive:
The only attributes of any consequence are associated with the points of
the (sparse) Voronoi mesh. All finer grained models (e.g. Cartesian exports or
2D displays) should be deterministic (e.g. distance-weighted
interpolations) functions of those per MeshPoint attributes.
I will not attempt to defend this decision, but it strongly guided all subsequent
decisions.
High-Level Overview
To greatly over-simplify, this program can be divided into:
- a set of points (in a Voronoi, triangluar, mesh) each of which has
a variety of attributes (e.g. altitude, soil type, water flow).
- a collection of graphical renderers to display 2D maps to illustrate
those attributes (e.g. topography and water, erosion and deposition, etc.).
- a collection of exporters, to translate such maps into a form that can be
imported into another program (e.g. RPGMaker, Foundation).
- a collection of engines for making updates to the topography, water
flow, plant cover, and other attributes of map points.
- a collection of dialogs/editors and a script interpreter
that use those engines to update those attributes (e.g.
creating mountains or changing water flow) of map points.
- a collection of menus, dialog widgets for accepting and executing commands.
- a collection of parsers to read program parameters, maps,
and export generation rules from (mostly JSON) configuration files.
The classes that create and operate on Meshes of Voronoi points are
Mesh.java,
Mesh.Pointjava and
MeshPointHasher.java.
The set of MeshPoints that define the world are stored in a Mesh array.
Their attributes (e.g. altitude, soil type, water flow) are stored in parallel arrays
(e.g. Map.heightMap, Map.soilMap, Map.fluxMap) ...
all of which are accessed through their common MeshPoint index.
There are several different map renderers, one for each major attribute:
- AltitudeMap.java, rendering altitudes as shades of gray
- TopoMap.java, rendering topographic lines
- WaterMap.java, rendering water and shorelines
- RiverMap.java, tracing rivers/streams through MeshPoints
- RainMap.java, showing regional rainfall
- ErodeMap.java, showing erosion and sedimentation
- SoilMap.java, showing soil types and mineral deposits
- FloraMap.java, showing plant distributions
- FaunaMap.java, showing animal/fish distributions
- CityMap.java, showing identified cities and the
trade-routes between them
The mapping from a (sparse and irregular) Voronoi mesh to a
(dense and continuous) 2D map is greatly facilitated by the
Cartesian.java
interpolation of values from surrounding MeshPoints
as chosen by (sub-classes of)
Vicinity.java.
The overall orchestration of creating a display from all of these
independent layers is managed by (the largest and most important class in the program)
Map.java.
Many decisions about resource placement or which (exporter) tiles to use to represent a region are
based on MeshPoint (or tile) based bidding rules. The base class for these rules (used for
Mineral, Flora, and Fauna placement) is
ResourceRule.java,
which can be extended by exporter-specific sub-classes like
RPGMRule.java and
OverlayRule.java.
All Exporters implement a
standard interface,
and a common
export orchestrater
creates a series of 2D per-tile maps which it pushes to the
output-format-specific implementations.
- The simplest of these,
RawExport.java
and
JsonExporter.java,
simply write (and read) a collection of per-point attribute descriptions.
- More interesting is
RPGMexport.java,
which uses tile placement rules (managed by
RPGMRule.java)
to drive a very RPG-Maker-savvy
RPGMTiler.java
to reproduce the map in tiles, and cause the (RPG Maker map) output to be written by
RPGMwriter.java.
- Another Exporter is
FoundExporter.java,
which creates the appropriate altitude and resource bit-maps, and uses
LuaWriter.java to
create the index that describes them.
- Another Exporter is
ObjectExporter.java,
which uses
ObjectExport.java to
examine the topography and choose hill/mountain tiles, and then
outputs a simple json description of per-tile altitudes
and water depth, followed by a list of larger (e.g. hill/mountain) tiles
(chosen by
OverlayRule.java)
to be overlayed on that simple map.
The main-screen menus and controls are put-up and responded to by the main class
(WorldBuilder.java).
Simple operations like saving updated maps and loading new ones, it handles
directly. But display and update operations are handled by creating new
interactive dialogs in one of the sub-dialog managers:
- MeshDialog.java,
- WorldDialog.java,
- MountainDialog.java,
- LandDialog.java,
- RainDialog.java,
- RegionDialog.java,
- RiverDialog.java,
- MineralDialog.java
(most of the work done by
ResourceDialog.java),
- FloraDialog.java
(most of the work done by
ResourceDialog.java),
- FaunaDialog.java
(most of the work done by
ResourceDialog.java),
- PointDebug.java,
- SlopeDialog.java,
- CityDialog.java,
- POIDialog.java,
- ZoomDialog.java,
- RuleDebug.java.
These put-up and respond to their own widgets, but on-map selection
(e.g. of lines, rectangles or groups of MeshPoints) is handled by
Map.java.
The actual map/attribute updates are made by the update engines
(TerrainEngine.java,
AttributeEngine.java,
TerritoryEngine.java),
which update the per MeshPoint arrays and use Map.set functions
(e.g. Map.setHeightMap() or Map.setSoilMap())
to give effect to the new values.
Most of the same operations can be initiated through the script interpreter
(Script.java).
The most complex (and only barely under control) modules are probably the
Drainage and
WaterFlow classes,
which use rainfall and topology to compute water flow, erosion,
deposition, and lake boundaries.
Most program parameters are read-in and accessed through the Singleton
implemented by
Parameters.java.
When a map is read in (or written out), this is done by
the read() and write() functions in
Map.java.
Key Classes and Operations
The worldBuilder application is moderately large
(over 10,000 lines of code spread over a few dozen modules).
The high level class structure can be (crudely) summarized by
a few UML class diagrams.
Mesh and Map-related Classes
The first class diagram shows the main WorldBuilder class,
the awt and swing GUI classes it builds on,
and the Map and Mesh classes that support
the MeshPoints on which the map is based.
Note that the only Map methods shown in this
figure are those involved in basic map creation.
Mesh Creation
O'Leary observed that if we create map points in a rectilinear grid,
deformations tend to retain that (unnatural) rectilinearity. This
problem is elimnated if the map points are placed at random.
Truly random points exhibit unattractive degrees of sparse-ness
and clumpy-ness. O'Leary evens this out by a few iterations
of connecting points into a Voronoi mesh and then choosing,
as new points, the centroids of those Voronoi polygons.
We use a Voronoi library to assign three neighbors to
each point and create the desired Mesh.
Simple Dialog Classes
The second class diagram shows the simpler (non-point-attribute-editing)
dialogs and the primary Map class functions they use.
These are all very simple dialogs. Some of them
(e.g. PointDebug) simply display the attributes of
a selected point.
Others simply update parameters (e.g. WorldDialog
adjusts the latitude, longitude and size of the world map).
The most complex is probably the ZoomDialog, which
allows a sub-region of the world map to be selected, and
uses the Map.setWindow function to cause the
displayed map to zoom into the selected sub-region.
Point and Region Selection
The Map class is a Mouse and MouseMotion
Listener, interprets mouse actions as selection attempts,
and indicates the selected points/areas on the currently displayed
map. Any dialog that needs to know about point or region selections
can register as a
MapListener
and receive call-backs in response to selection actions. They can
also use the Map.selectMode() and Map.checkSelection()
operations to enable the desired selection mode (e.g. point, line, region)
and query any selections that may have already been made.
Terrain Editing Dialog Classes
The third class diagram shows the attribute-editing dialogs and the
Map selection and get/set functions they use to update
the MeshPoint attribute maps.
The operations in this richer set of dialogs (a) update point attributes and
(b) drive refreshes of the displayed map to show the updated information.
Attribute Maps
As random points in a 2D space MeshPoints are not very exciting.
What makes them interesting is the collection of attributes associated
with each point. As mentioned previously, each MeshPoint has
a stable index in the Mesh array, and the MeshPoint
attributes are stored in series of parallel arrays:
- heightMap stores the altitude (in -0.5 to +0.5 map coordinates)
of each MeshPoint
- waterLevel stores the altitude (in -0.5 to +0.5 map coordinates)
of the nearest water level to each MeshPoint
- soilMap stores the soil and mineral types
(sedimentary, metamorphic, igneous, alluvial, iron, copper, precious, ...)
of each MeshPoint
- rainMap stores the annual rainfall (in cm)
for each MeshPoint
- fluxMap stores the flow of water (in cubic meters/year)
into each MeshPoint
- erodeMap stores the net (negative) erosion or (positive) sedimentation
of each MeshPoint
- floraMap stores a flora ecotope class
for each MeshPoint
- faunaMap stores a dominant animal (including birds and fish) class
for each MeshPoint
- nameMap stores the types/names of cities, towns, aand villages
for each MeshPoint
The attribute update engines load the appropriate attribute maps from the Map
class, update them according to the specified operations, and then pass the
updated values back to the Map class.
Displayed Map(s)
Whenenver attributes are changed the awt.repaint() method invoked,
causing a call to Map.paintComponent().
There are many different
attributes for each MeshPoint. Which will be displayed is controlled
by calls to Map.setDisplay().
When the call is made to repaint the map, Map.PaintComponent will:
- decide on the dimensions of the (to be updated) map.
- create a Cartesian interpolation matrix to compute
the values at every pixel from the nearest/surrounding
MeshPoints.
- go through the display-enabled attributes, using the
appropriate map-rendering class
(e.g. AltitudeMap or RiverMap) to compute
the attribute values for every pixel on the map and generate
the appropriate display updates.
- if any selection areas are to be highlighted, add appropriate
rectangles, lines or point-halos to indicate them.
Export Classes
The final class diagram shows the Export related classes.
(that handle raw JSON, RPG Maker, Object and Foundation maps).
Notes on hydrological simulations
The classes involved in hydrological simulation are:
- Drainage ... figure out how water would flow between the mesh points:
- mark all sub-sea-level points on the edge of the map as oceanic.
- determine the most down-hill (steepest) neighbor or each land point.
- identify the lowest point in each depression (sink).
- identify the lowest escape point for each depression (sink) if it fills with water ...
and if the escape is into a larger depression, combine them.
- create a source-to-sink ordered list of non-oceanic points
(to be used in the next pass).
- WaterFlow ... compute water velocity, erosion, deposition, and lake boundaries:
- compute the incoming rainfall and flow, vs evaporation to determine
whether or not there is net water (flowing or lake) on each point.
- use the down-hill slope to compute the velocity of flow through each point.
- if the velocity is high enough to cause erosion, compute the amount of
soil removed from this point and added to the flow.
- if the velocity is low enough to cause sedimentation, compute how
much soil is removed from the flow and deposited on this point.
- if this point is in a depression, compute the water depth
(as the altitude difference between this point and its escape point identified
in the drainage pass).
- erosion ... return the (number of meters of) erosion for
a specified mesh point (based on the waterFlow computations).
- sedimentation ... return the (number of meters of) sedimentation for
a specified mesh point (based on the waterFlow computations).
I started out trying to use real physics for erosion and sedimentation:
- the Manning formula to compute water velocity from slope.
- suspended concentration studies to estimate how much soil could be carried
by water at a given speed.
- the Hjulstrom curves to distinguish erosion and deposition ranges.
but the results were disappointing:
- Fantasy maps seem to have a wider vertical range than real topographies,
so the water would always be moving too fast for any sedimentation to happen.
I dealt with this by changing the velocity computation to simply interpolate a
reasonable range of water speeds (0.005m/s - 3m/s) from a wide range of
slopes (1/1000 - 1/1).
- The Hjulstrom curves tell us what sized particles are being eroded
or deposited at a given velocity, but not the rate at which these
processes proceed.
Based on my experience with other such processes, I asserted
that erosion and deposition were exponential processes,
with some fraction of the possible erosion/deposition happening
at each mesh point. The possible erosion was proportional to
the water velocity, and the deposition inversely proportional to
the water velocity. The fraction of possible erosion/deposition
that happens per MeshPoint is controlled by two tunable parameters:
Ce and Cd.
- Silt has not been dug out of the river-bed, but washed off the top
of the entire watershed. Consequently, the amount of silt
deposition should greatly exceed the amount of river-bed
erosion.
I dealt with this by making silt deposition a distinct process
from the deposition of eroded rock, and making the simplifying
assumption that sufficently slow moving water always has more
silt to deposit.
I have seen much higher resolution erosion/deposition simulations,
performed by GPUs on a much denser Cartesian grid. The results were
very beautiful, but require many orders of magnitude more computer
power (to do anything), and lack the (very satisfying) irregularity
that emerges from points on our (very sparse) Voronoi mesh.
The erosion/deposition models used by those simulations were much
simpler than mine:
- velocity is a simple function of slope, and the allowable
amount of sediment carried by water is directly proportional
to its velocity.
- erosion is the shortfall (amount of allowable sediment not
yet carried) divided by the hardness of the rock.
- deposition is the surplus (amount of carried sediment
beyond what is currently allowed for that water).
I was impressed by the simplicity of these models, and incorporated
some of those lessons into the above solutions. But (O'Leary's insight)
performing all topographic operations on a (manageably small number of
points) Voronoi grid is fundamental to how this program works, and
moving to an entirely (much finer grained) Cartesian model is a
different program.
Issues
MeshPoint to Cartesian Conversion
A Cartesian map
specifies, for each square in a Cartesian grid, a list of surrounding
MeshPoints and
their distances from this square.
This enables us to interpolate per-Cartesian-square values
from a list of per-MeshPoint values.
The interpolation process is trivial (simply the inverse-distance-weighted
average of the values for the surrounding MeshPoints).
The hard part is figuring out which MeshPoints are the surrounding ones.
The most obvious answer, the nearest N points, works well for
(relatively continuous) functions like altitude and rain-fall,
but poorly for lake boundaries (which are a discontinous
function of altitude). For these, a better result is obtained
by using those MeshPoints that define the Voronoi polygon within
which the Cartesian point lies. But, sadly, values inferred
from the enclosing polygon experience significant discontinuities
at the polygon boundaries. After considerable frustration I
decided to:
- Make
Vicinity a
super-class that implements interpolation but does not
actually decide which the neighboring MeshPoints are.
- Create a
Polygon
sub-class that attempts to enumerate the MeshPoints
that define the enclosing Voronoi polygon ... starting
with the nearest.
- Provide two means of using a Vicinity to
populate a Cartesian map:
- interpolate using the inverse-distance-weighted
values of all points in the surrounding Polygon.
- nearestValid using the value of the nearest
MeshPoint.
The interpolate method works well for relatively continuous
attributes like altitude or rainfall. The nearestValid method
is more appropriate for discrete attributes (like mineral and flora
classes).
The Polygon constructor and nextPoint methods
attempt to enumerate the surrounding points by:
- starting with the MeshPoint nearest to the desired Cartesian square
- choosing, at each successive point, the path that seems most likely
to be enclosing the desired polygon.
A human would use a simple heuristic (like always turn
to the right).
I compute, for each possible (non-reversing) path,
the derivative of radius (distance from the Cartesian center) with
respect to circumference (distance from the previous
vertex). Minimizing this ratio tends to keep us on
the most concave path.
This works reasonably for points that are within the Voronoi mesh.
But for points outside the edges of the mesh, there is no surrounding
polygon, so the above works badly. This results in attempting to
interpolate values from (poorly chosen) non-neighbors, giving rise
to strange altutudes and water bodies near the edges of the map.
If we knew that a point was outside of the mesh, we could probably
interpolate reasonable values by considering only the one or two nearest
MeshPoints. But how can we know whether or not a point is outside
the mesh (or inside a computed polygon)? The problem of
point in polygon determination turns out to be a fairly
expensive one ... and we need to solve it for a very large number
of points (every time we zoom, sub-region, export, or define a new mesh).
The Vicnity.outsideMesh function uses a few cheap
heuristics to recognize more obvious cases ... but there
are points near non-convex outer borders that are not
recognized, and therefore still interpolate badly.
The problem is relatively minor, in that it only happens to non-ocean
points at the outer-most edges of the map ... and is only then noticable
if there is wide range of altitude and land/water variation among the dozen
nearest MeshPoints. Most people will never encounter it, and those who do are
unlikely to notice it. But, in the interests of correctness ...
- If we simply limit the displayed (and exportable) map to
be entirely within the Voronoi mesh, this problem ceases
to happen.
- The only thing I wanted from the Voronoi package was the
MeshPoint connections (which drive water flow)
... but the Voronoi analysis had actually identified all
of the polygons. If we kept the polygon definitions
and exploited more of the Voronoi package services
we might be able to greatly improve the efficiency of
finding the surrounding MeshPoints for Cartesian translation,
and perhaps solve this problem as well.
Musings
A reasonable map will be based on thousands of MeshPoints.
Computations on those (relatively few) points are simple and efficient
(thank you Martin O'Leary). But ...
- creating the (much larger) Cartesian grids for display and export,
where many contenders bid on every tile is much more expensive.
- for reasons having to do with zooming and exports of bordering
regions, I wanted the derivation of sub-maps to be a deterministic
function of the MeshPoint attributes ... so that all maps would
agree where the hills, creeks (and even trees) were.
- Chris asked for affinity/antipathy rules to create realistic
flora clustering. I had simiilar thoughts about resources,
population, and trade routes. These would easily add another
order of magnitude to those computations, and (to my mind)
best have been implemented as multi-generational evolutionary
sequences. A very compelling approach, that would surely
yield interesting worlds ... but very expensive.
A lesson I seem to have learned (from a cruel Hydrological master) is
that more realistic world simulations add a level of detail that will
(in most cases) never be noticed when the resulting world is exported
for use in an RPG. Would this really justify another few thousand lines of
code, making the rule-sets even more complicated, and making rendering
and export even slower? The answer surely depends on our audience and
their goals ... which at the moment, are purely hypothetical :-)
My greatest regret about the current code is the combination of
complexity and difficulty of testing ... which often results in
unexpected consequences of seemingly simple changes:
- a map is comprised of thousands of MeshPoints,
each of which has a dozen floating-point attributes.
- any operation on the map (e.g. change of rain-fall or
creation of a new ridge) will have complex implications
for many attributes of many points.
- it is not practical to compute or confirm correct values
for a few thousand point-attributes.
- we have always tested new features by
performing operations on a few different maps and seeing
if the resulting changes "looked right".
But ...
- by decoupling the actual map/attribute updating from the
editing dialogs, we can cause most manual-editing operations
to be driven by scripts.
- given my Prime Directive that all exported or
graphically rendered information should be a deterministic
function of the per MeshPoint Attributes,
most of what we could need to check is likely to be present
(in a relatively compact form) in a saved map.
Thus, we can do a fairly reasonable job of base engine testing by:
- writing scripts to perform all of the various types of
terrain and attribute editing operations.
- save the resulting map, and then read it back in.
- carefully examine the graphical output and point attributes
resulting from each of these tests to ensure that the
correctness of the restored map.
- use that saved map as Golden Output, against which we
compare the results of future test runs.
- divide tests across multiple scripts so that the addition
of a new test does not invalidate golden output for
previous tests.
We can similarly test exports, by starting with a fixed and content-rich
map, exporting it in various formats, and manually confirming the correctness
of each export.
This process isn't ideal, but it will warn us whenever code changes result
in a different set of per MeshPoint attributes, or a different
translation of those attributes into a Cartesian grid.


| Package | com.flashdynamix.motion.guides |
| Class | public class Orbit2D |
| Property | Defined by | ||
|---|---|---|---|
| autoRotate : Boolean = false
Whether the Object will directionally rotate.
| Orbit2D | ||
| centerX : Number | Orbit2D | ||
| centerY : Number | Orbit2D | ||
| degree : Number
Sets and returns the angle in degrees on the orbit path for your object.
| Orbit2D | ||
| item : Object
The Object you wish to be updated with x,y values of the orbit path.
| Orbit2D | ||
| radiusX : Number | Orbit2D | ||
| radiusY : Number | Orbit2D | ||
| rotation : Number
Sets and returns the rotation in radians on the orbit path for your object.
| Orbit2D |
| Method | Defined by | ||
|---|---|---|---|
|
Orbit2D(item:Object, radiusX:Number, radiusY:Number, centerX:Number, centerY:Number, autoRotate:Boolean = false)
| Orbit2D |
| autoRotate | property |
public var autoRotate:Boolean = false
Whether the Object will directionally rotate.
| centerX | property |
centerX:Number
[read-write]Implementation
public function get centerX():Number
public function set centerX(value:Number):void
| centerY | property |
centerY:Number
[read-write]Implementation
public function get centerY():Number
public function set centerY(value:Number):void
| degree | property |
degree:Number
[read-write]Sets and returns the angle in degrees on the orbit path for your object.
Implementation public function get degree():Number
public function set degree(value:Number):void
| item | property |
public var item:Object
The Object you wish to be updated with x,y values of the orbit path.
| radiusX | property |
radiusX:Number
[read-write]Implementation
public function get radiusX():Number
public function set radiusX(value:Number):void
| radiusY | property |
radiusY:Number
[read-write]Implementation
public function get radiusY():Number
public function set radiusY(value:Number):void
| rotation | property |
rotation:Number
[read-write]Sets and returns the rotation in radians on the orbit path for your object.
Implementation public function get rotation():Number
public function set rotation(value:Number):void
| Orbit2D | () | constructor |
public function Orbit2D(item:Object, radiusX:Number, radiusY:Number, centerX:Number, centerY:Number, autoRotate:Boolean = false)
Parameters
item:Object — The Object you wish to be updated with x,y values.
|
|
radiusX:Number — The x radius of the orbit path in pixels.
|
|
radiusY:Number — The y radius of the orbit path in pixels.
|
|
centerX:Number — The center x of the orbit path in pixels.
|
|
centerY:Number — The center y of the orbit path in pixels.
|
|
autoRotate:Boolean (default = false ) — Whether the Object will directionally rotate.
|


:q[uit] Quit Vim. This fails when changes have been made.
:q[uit]! Quit without writing.
:cq[uit] Quit always, without writing.
:wq Write the current file and exit.
:wq! Write the current file and exit always.
:wq {file} Write to {file}. Exit if not editing the last
:wq! {file} Write to {file} and exit always.
:[range]wq[!] [file] Same as above, but only write the lines in [range].
ZZ Write current file, if modified, and exit.
ZQ Quit current file and exit (same as “:q!”).
:e[dit] Edit the current file. This is useful to re-edit the current file, when it has been changed outside of Vim.
:e[dit]! Edit the current file always. Discard any changes to the current buffer. This is useful if you want to start all over again.
:e[dit] {file} Edit {file}.
:e[dit]! {file} Edit {file} always. Discard any changes to the current buffer.
gf Edit the file whose name is under or after the cursor. Mnemonic: “goto file”.
a Append text after the cursor [count] times.
A Append text at the end of the line [count] times.
i Insert text before the cursor [count] times.
I Insert text before the first non-blank in the line [count] times.
gI Insert text in column 1 [count] times.
o Begin a new line below the cursor and insert text, repeat [count] times.
O Begin a new line above the cursor and insert text, repeat [count] times.
:r[ead] [name] Insert the file [name] below the cursor.
:r[ead] !{cmd} Execute {cmd} and insert its standard output below the cursor.
or x Delete [count] characters under and after the cursor
X Delete [count] characters before the cursor
d{motion} Delete text that {motion} moves over
dd Delete [count] lines
D Delete the characters under the cursor until the end of the line
{Visual}x or {Visual}d Delete the highlighted text (for {Visual} see [Selecting Text][1]).
{Visual}CTRL-H or {Visual} When in Select mode: Delete the highlighted text
{Visual}X or {Visual}D Delete the highlighted lines
:[range]d[elete] Delete [range] lines (default: current line)
:[range]d[elete] {count} Delete {count} lines, starting with [range]
r{char} replace the character under the cursor with {char}.
R Enter Insert mode, replacing characters rather than inserting
~ Switch case of the character under the cursor and move the cursor to the right. If a [count] is given, do that many characters.
~{motion} switch case of {motion} text.
{Visual}~ Switch case of highlighted text
:[range]s[ubstitute]/{pattern}/{string}/[c][e][g][p][r][i][I] [count] For each line in [range] replace a match of {pattern} with {string}.
:[range]s[ubstitute] [c][e][g][r][i][i] [count] :[range]&[c][e][g][r][i][i] [count] Repeat last :substitute with same search pattern and substitute string, but without the same flags. You may add extra flags
The arguments that you can use for the substitute commands:
[c] Confirm each substitution. Vim positions the cursor on the matching
string. You can type:
'y' to substitute this match
'n' to skip this match
to skip this match
'a' to substitute this and all remaining matches {not in Vi}
'q' to quit substituting {not in Vi}
CTRL-E to scroll the screen up {not in Vi}
CTRL-Y to scroll the screen down {not in Vi}.
[e] When the search pattern fails, do not issue an error message and, in
particular, continue in maps as if no error occurred.
[g] Replace all occurrences in the line. Without this argument,
replacement occurs only for the first occurrence in each line.
[i] Ignore case for the pattern.
[I] Don't ignore case for the pattern.
[p] Print the line containing the last substitute.
“{a-zA-Z0-9.%#:-”} Use register {a-zA-Z0-9.%#:-"} for next delete, yank or put (use uppercase character to append with delete and yank) ({.%#:} only work with put).
:reg[isters] Display the contents of all numbered and named registers.
:reg[isters] {arg} Display the contents of the numbered and named registers that are mentioned in {arg}.
:di[splay] [arg] Same as :registers.
["x]y{motion} Yank {motion} text [into register x].
["x]yy Yank [count] lines [into register x]
["x]Y yank [count] lines [into register x] (synonym for yy).
{Visual}["x]y Yank the highlighted text [into register x] (for {Visual} see [Selecting Text][1]).
{Visual}["x]Y Yank the highlighted lines [into register x]
:[range]y[ank] [x] Yank [range] lines [into register x].
:[range]y[ank] [x] {count} Yank {count} lines, starting with last line number in [range] (default: current line), [into register x].
["x]p Put the text [from register x] after the cursor [count] times.
["x]P Put the text [from register x] before the cursor [count] times.
["x]gp Just like “p”, but leave the cursor just after the new text.
["x]gP Just like “P”, but leave the cursor just after the new text.
:[line]pu[t] [x] Put the text [from register x] after [line] (default current line).
:[line]pu[t]! [x] Put the text [from register x] before [line] (default current line).
u Undo [count] changes.
:u[ndo] Undo one change.
CTRL-R Redo [count] changes which were undone.
:red[o] Redo one change which was undone.
U Undo all latest changes on one line. {Vi: while not moved off of it}
. Repeat last change, with count replaced with [count].
Basic motion commands:
k
h l
j
h or
[count] characters to the left (exclusive).
l or or
[count] characters to the right (exclusive).
k or or CTRL-P [count] lines upward
j or or CTRL-J or or CTRL-N [count] lines downward (linewise).
0 To the first character of the line (exclusive).
To the first character of the line (exclusive).
^ To the first non-blank character of the line
$ or
To the end of the line and [count - 1] lines downward
g0 or g When lines wrap (‘wrap on): To the first character of the screen line (exclusive). Differs from “0” when a line is wider than the screen. When lines don’t wrap (’wrap’ off): To the leftmost character of the current line that is on the screen. Differs from “0” when the first character of the line is not on the screen.
g^ When lines wrap (‘wrap’ on): To the first non-blank character of the screen line (exclusive). Differs from “^” when a line is wider than the screen. When lines don’t wrap (‘wrap’ off): To the leftmost non-blank character of the current line that is on the screen. Differs from “^” when the first non-blank character of the line is not on the screen.
g$ or g shift right
v start Visual mode per character.
V start Visual mode linewise.
exit Visual mode without making any changes
CTRL-Z Suspend Vim, like “:stop”. Works in Normal and in Visual mode. In Insert and Command-line mode, the CTRL-Z is inserted as a normal character.
:sus[pend][!] or :st[op][!] Suspend Vim. If the ‘!’ is not given and ‘autowrite’ is set, every buffer with changes and a file name is written out. If the ‘!’ is given or ‘autowrite’ is not set, changed buffers are not written, don’t forget to bring Vim back to the foreground later!


WITNESS LIST Defense Affairs & State-Federal Relations Committee February 24, 2005-8:00A HB 18 Registering, but not testifying: For: Carter, Janis (Texas Funeral Directors Association) DeBeauvoir, Dana (Dana DeBeauvoir - Travis County Clerk) Rodriguez, Jennifer (County & District Clerks Association of Texas) HB 25 For: Surles, Stephanie (Military Child Education Coalition) On: Jackson, Sharon (Texas Education Agency) HB 685 Registering, but not testifying: For: Mica, Tara (NRA - Natl Rifle Association) Trepp, Alice (TX State Rifle Assoc.)


Hello world!
Note: This example uses DOM ranges and will only work in browsers that support DOM ranges. This example will fail in Internet Explorer < 9.


Several years of hard work summarized in a few sentences.
A research project conducted with the Stoeckert Lab in the Pereleman School of Medicine.
Teaching new or beginning programmers how to become hackathon experts in 20 hours.
Top secret project in the works. (Or it would be, if the code weren't already online).
By Brynn Claypoole, with help from Bootstrap.


Login
Stock Forecaster
Predict the stock market . Invest smart !
Stock Forecaster
Home
Service
Project
Technology
Welcome to
Stock Forecaster
Buy the stocks
worth investing
Present Market
Yahoo! Finance
Quote for ^IXIC


Lets Explore API
Start exploring the world..
Version: 1.0.0
BasePath:/api
All rights reserved
http://apache.org/licenses/LICENSE-2.0.html
Access
[ Jump to Models ]
Table of Contents
Get details for a place (placeDetailsGet)
The API gets the details for a place. The place is identified by its reference. The place reference is available from the thindstodo API.
Query parameters
ref (required)
Query Parameter — Place reference string for the sight
Return type
Example data
Content-Type: application/json
{
"country" : "aeiou",
"country_code" : "aeiou",
"offset" : 1.3579000000000001069366817318950779736042022705078125,
"city" : "aeiou",
"location" : {
"lng" : 1.3579000000000001069366817318950779736042022705078125,
"lat" : 1.3579000000000001069366817318950779736042022705078125
},
"state" : "aeiou",
"state_code" : "aeiou",
"url" : "aeiou"
}
Produces
This API call produces the following media types according to the request header;
the media type will be conveyed by the
Content-Type response header.
Responses
200
An object with details for the place
PlaceDetails
0
Unexpected error
Error
Get the events for a place (placeEventsGet)
The API gets the events happening in the place of interest.
Query parameters
city (required)
Query Parameter — Name of the city
Return type
Example data
Content-Type: application/json
{
"events" : [ {
"venue" : {
"address" : "aeiou",
"name" : "aeiou",
"url" : "aeiou"
},
"city" : "aeiou",
"title" : "aeiou",
"url" : "aeiou"
} ]
}
Produces
This API call produces the following media types according to the request header;
the media type will be conveyed by the
Content-Type response header.
Responses
200
An object with events happening in the place
Events
0
Unexpected error
Error
Get the URL for a photo (placePhotosGet)
The API gets the URL for the photo reference. The URL can be set as the src attribute for an img tag to see the photo for the reference.
Query parameters
photo_reference (required)
Query Parameter — Photo reference string for the sight
Return type
Example data
Content-Type: application/json
{
"src" : "aeiou"
}
Produces
This API call produces the following media types according to the request header;
the media type will be conveyed by the
Content-Type response header.
Responses
200
An object with src of the photo
PhotoSrc
0
Unexpected error
Error
List of sights to see for a given place (placeThingstodoGet)
The thingstodo endpoint returns information about the sights to see for a given place name. The name can be a city name or to get more specific results, one can provide the city, state, country name also.
Query parameters
place (required)
Query Parameter — Name of the place
Return type
Example data
Content-Type: application/json
{
"place" : "aeiou",
"list" : [ {
"formatted_address" : "aeiou",
"name" : "aeiou",
"geometry" : "{}",
"photos" : [ {
"photo_reference" : "aeiou"
} ]
} ]
}
Produces
This API call produces the following media types according to the request header;
the media type will be conveyed by the
Content-Type response header.
Responses
200
An object containing the place and list of sights to visit
Sights
0
Unexpected error
Error
Get the weather for a place (placeWeatherGet)
The API gets the weather for a place. The place can be the name of a city of a complete address of a place.
Query parameters
city (required)
Query Parameter — Name of the city
Return type
Example data
Content-Type: application/json
{
"weather" : {
"main" : {
"temp" : 1.3579000000000001069366817318950779736042022705078125
}
}
}
Produces
This API call produces the following media types according to the request header;
the media type will be conveyed by the
Content-Type response header.
Responses
200
An object with weather of the place
Weather
0
Unexpected error
Error
[ Jump to Methods ]
Table of Contents
Error
Event
Events
Location
Photo
PhotoSrc
PlaceDetails
Sight
Sights
Venue
Weather
weather_main
weather_weather
code (optional)
message (optional)
fields (optional)
url (optional)
city (optional)
String Name of the city in which the event is
title (optional)
venue (optional)
lat (optional)
lng (optional)
photo_reference (optional)
String The reference of the photo for the sight. Use this in the photos API to get the URL for the photo
url (optional)
offset (optional)
location (optional)
city (optional)
state (optional)
state_code (optional)
String Postal code for the state
country (optional)
String Name of the country the place is in
country_code (optional)
formatted_address (optional)
String The address for the place
geometry (optional)
Object Contains latitude and longitude for the location
name (optional)
String The name of the sight to visit
photos (optional)
array[Photo] Array of photo references that can be furnished to photos API to get the photo URL for the sight.
place (optional)
String The input name of the place
list (optional)
Venue of the event
name (optional)
address (optional)
url (optional)
Temperature information for the place


gdbserver(1) GNU Development Tools gdbserver(1) NAME gdbserver - Remote Server for the GNU Debugger SYNOPSIS gdbserver tty prog [args...] gdbserver tty --attach PID DESCRIPTION GDBSERVER is a program that allows you to run GDB on a different machine than the one which is running the program being debugged. Usage (server (target) side): First, you need to have a copy of the program you want to debug put onto the target system. The program can be stripped to save space if needed, as GDBserver doesn't care about symbols. All symbol handling is taken care of by the GDB running on the host system. To use the server, you log on to the target system, and run the `gdb‐ server' program. You must tell it (a) how to communicate with GDB, (b) the name of your program, and (c) its arguments. The general syntax is: target> gdbserver COMM PROGRAM [ARGS ...] For example, using a serial port, you might say: target> gdbserver /dev/com1 emacs foo.txt This tells gdbserver to debug emacs with an argument of foo.txt, and to communicate with GDB via /dev/com1. Gdbserver now waits patiently for the host GDB to communicate with it. To use a TCP connection, you could say: target> gdbserver host:2345 emacs foo.txt This says pretty much the same thing as the last example, except that we are going to communicate with the host GDB via TCP. The `host:2345' argument means that we are expecting to see a TCP connection from `host' to local TCP port 2345. (Currently, the `host' part is ignored.) You can choose any number you want for the port number as long as it does not conflict with any existing TCP ports on the target system. This same port number must be used in the host GDBs `target remote' command, which will be described shortly. Note that if you chose a port number that conflicts with another service, gdbserver will print an error message and exit. On some targets, gdbserver can also attach to running programs. This is accomplished via the --attach argument. The syntax is: target> gdbserver COMM --attach PID PID is the process ID of a currently running process. It isn't necessary to point gdbserver at a binary for the running process. Usage (host side): You need an unstripped copy of the target program on your host system, since GDB needs to examine it's symbol tables and such. Start up GDB as you normally would, with the target program as the first argument. (You may need to use the --baud option if the serial line is running at any‐ thing except 9600 baud.) Ie: `gdb TARGET-PROG', or `gdb --baud BAUD TAR‐ GET-PROG'. After that, the only new command you need to know about is `target remote'. It's argument is either a device name (usually a serial device, like `/dev/ttyb'), or a HOST:PORT descriptor. For example: (gdb) target remote /dev/ttyb communicates with the server via serial line /dev/ttyb, and: (gdb) target remote the-target:2345 communicates via a TCP connection to port 2345 on host `the-target', where you previously started up gdbserver with the same port number. Note that for TCP connections, you must start up gdbserver prior to using the `target remote' command, otherwise you may get an error that looks something like `Connection refused'. OPTIONS You have to supply the name of the program to debug and the tty to commu‐ nicate on; the remote GDB will do everything else. Any remaining argu‐ ments will be passed to the program verbatim. SEE ALSO `gdb' entry in info; Using GDB: A Guide to the GNU Source-Level Debugger, Richard M. Stallman and Roland H. Pesch, July 1991. COPYING Copyright (c) 1993 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this man‐ ual provided the copyright notice and this permission notice are pre‐ served on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permis‐ sion notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original Eng‐ lish. Cygnus Support 2 November 1993 gdbserver(1)