|
ActiveTcl User Guide
|
||
Tk_CreateOptionTable, Tk_DeleteOptionTable, Tk_InitOptions, Tk_SetOptions, Tk_FreeSavedOptions, Tk_RestoreSavedOptions, Tk_GetOptionValue, Tk_GetOptionInfo, Tk_FreeConfigOptions, Tk_Offset - process configuration options
#include <tk.h>
Tk_OptionTable
Tk_CreateOptionTable(interp, templatePtr)
Tk_DeleteOptionTable(optionTable)
int
Tk_InitOptions(interp, recordPtr, optionTable,
tkwin)
int
Tk_SetOptions(interp, recordPtr, optionTable, objc, objv,
tkwin, savePtr, maskPtr)
Tk_FreeSavedOptions(savedPtr)
Tk_RestoreSavedOptions(savedPtr)
Tcl_Obj *
Tk_GetOptionValue(interp, recordPtr, optionTable,
namePtr, tkwin)
Tcl_Obj *
Tk_GetOptionInfo(interp, recordPtr, optionTable, namePtr,
tkwin)
Tk_FreeConfigOptions(recordPtr, optionTable,
tkwin)
int
Tk_Offset(type, field)
These procedures handle most of the details of parsing configuration options such as those for Tk widgets. Given a description of what options are supported, these procedures handle all the details of parsing options and storing their values into a C structure associated with the widget or object. The procedures were designed primarily for widgets in Tk, but they can also be used for other kinds of objects that have configuration options. In the rest of this manual page ``widget'' will be used to refer to the object whose options are being managed; in practice the object may not actually be a widget. The term ``widget record'' is used to refer to the C-level structure in which information about a particular widget or object is stored.
Note: the easiest way to learn how to use these procedures is to look at a working example. In Tk, the simplest example is the code that implements the button family of widgets, which is an tkButton.c. Other examples are in tkSquare.c and tkMenu.c.
In order to use these procedures, the code that implements the widget must contain a static array of Tk_OptionSpec structures. This is a template that describes the various options supported by that class of widget; there is a separate template for each kind of widget. The template contains information such as the name of each option, its type, its default value, and where the value of the option is stored in the widget record. See TEMPLATES below for more detail.
In order to process configuration options efficiently, the static template must be augmented with additional information that is available only at runtime. The procedure Tk_CreateOptionTable creates this dynamic information from the template and returns a Tk_OptionTable token that describes both the static and dynamic information. All of the other procedures, such as Tk_SetOptions, take a Tk_OptionTable token as argument. Typically, Tk_CreateOptionTable is called the first time that a widget of a particular class is created and the resulting Tk_OptionTable is used in the future for all widgets of that class. A Tk_OptionTable may be used only in a single interpreter, given by the interp argument to Tk_CreateOptionTable. When an option table is no longer needed Tk_DeleteOptionTable should be called to free all of its resources. All of the option tables for a Tcl interpreter are freed automatically if the interpreter is deleted.
Tk_InitOptions is invoked when a new widget is created to set the default values for all of the widget's configuration options. Tk_InitOptions is passed a token for an option table (optionTable) and a pointer to a widget record (recordPtr), which is the C structure that holds information about this widget. Tk_InitOptions uses the information in the option table to choose an appropriate default for each option, then it stores the default value directly into the widget record, overwriting any information that was already present in the widget record. Tk_InitOptions normally returns TCL_OK. If an error occurred while setting the default values (e.g., because a default value was erroneous) then TCL_ERROR is returned and an error message is left in interp's result if interp isn't NULL.
Tk_SetOptions is invoked to modify configuration options based on information specified in a Tcl command. The command might be one that creates a new widget, or a command that modifies options on an existing widget. The objc and objv arguments describe the values of the arguments from the Tcl command. Objv must contain an even number of objects: the first object of each pair gives the name of an option and the second object gives the new value for that option. Tk_SetOptions looks up each name in optionTable, checks that the new value of the option conforms to the type in optionTable, and stores the value of the option into the widget record given by recordPtr. Tk_SetOptions normally returns TCL_OK. If an error occurred (such as an unknown option name or an illegal option value) then TCL_ERROR is returned and an error message is left in interp's result if interp isn't NULL.
Tk_SetOptions has two additional features. First, if the maskPtr argument isn't NULL then it points to an integer value that is filled in with information about the options that were modified. For each option in the template passed to Tk_CreateOptionTable there is a typeMask field. The bits of this field are defined by the code that implements the widget; for example, each bit might correspond to a particular configuration option. Alternatively, bits might be used functionally. For example, one bit might be used for redisplay: all options that affect the widget's display, such that changing the option requires the widget to be redisplayed, might have that bit set. Another bit might indicate that the geometry of the widget must be recomputed, and so on. Tk_SetOptions OR's together the typeMask fields from all the options that were modified and returns this value at *maskPtr; the caller can then use this information to optimize itself so that, for example, it doesn't redisplay the widget if the modified options don't affect the widget's appearance.
The second additional feature of Tk_SetOptions has to do with error recovery. If an error occurs while processing configuration options, this feature makes it possible to restore all the configuration options to their previous values. Errors can occur either while processing options in Tk_SetOptions or later in the caller. In many cases the caller does additional processing after Tk_SetOptions returns; for example, it might use an option value to set a trace on a variable and may detect an error if the variable is an array instead of a scalar. Error recovery is enabled by passing in a non-NULL value for the savePtr argument to Tk_SetOptions; this should be a pointer to an uninitialized Tk_SavedOptions structure on the caller's stack. Tk_SetOptions overwrites the structure pointed to by savePtr with information about the old values of any options modified by the procedure. If Tk_SetOptions returns successfully, the caller uses the structure in one of two ways. If the caller completes its processing of the new options without any errors, then it must pass the structure to Tk_FreeSavedOptions so that the old values can be freed. If the caller detects an error in its processing of the new options, then it should pass the structure to Tk_RestoreSavedOptions, which will copy the old values back into the widget record and free the new values. If Tk_SetOptions detects an error then it automatically restores any options that had already been modified and leaves *savePtr in an empty state: the caller need not call either Tk_FreeSavedOptions or Tk_RestoreSavedOptions. If the savePtr argument to Tk_SetOptions is NULL then Tk_SetOptions frees each old option value immediately when it sets a new value for the option. In this case, if an error occurs in the third option, the old values for the first two options cannot be restored.
Tk_GetOptionValue returns the current value of a configuration option for a particular widget. The namePtr argument contains the name of an option; Tk_GetOptionValue uses optionTable to lookup the option and extract its value from the widget record pointed to by recordPtr, then it returns an object containing that value. If an error occurs (e.g., because namePtr contains an unknown option name) then NULL is returned and an error message is left in interp's result unless interp is NULL.
Tk_GetOptionInfo returns information about configuration options in a form suitable for configure widget commands. If the namePtr argument is not NULL, it points to an object that gives the name of a configuration option; Tk_GetOptionInfo returns an object containing a list with five elements, which are the name of the option, the name and class used for the option in the option database, the default value for the option, and the current value for the option. If the namePtr argument is NULL, then Tk_GetOptionInfo returns information about all options in the form of a list of lists; each sublist describes one option. Synonym options are handled differently depending on whether namePtr is NULL: if namePtr is NULL then the sublist for each synonym option has only two elements, which are the name of the option and the name of the other option that it refers to; if namePtr is non-NULL and names a synonym option then the object returned is the five-element list for the other option that the synonym refers to. If an error occurs (e.g., because namePtr contains an unknown option name) then NULL is returned and an error message is left in interp's result unless interp is NULL.
Tk_FreeConfigOptions must be invoked when a widget is deleted. It frees all of the resources associated with any of the configuration options defined in recordPtr by optionTable.
The Tk_Offset macro is provided as a safe way of generating the objOffset and internalOffset values for entries in Tk_OptionSpec structures. It takes two arguments: the name of a type of record, and the name of a field in that record. It returns the byte offset of the named field in records of the given type.
The array of Tk_OptionSpec structures passed to Tk_CreateOptionTable via its templatePtr argument describes the configuration options supported by a particular class of widgets. Each structure specifies one configuration option and has the following fields:
typedef struct { Tk_OptionType type; char *optionName; char *dbName; char *dbClass; char *defValue; int objOffset; int internalOffset; int flags; ClientData clientData; int typeMask; } Tk_OptionSpec;
The type field indicates what kind of configuration option this is (e.g. TK_OPTION_COLOR for a color value, or TK_OPTION_INT for an integer value). Type determines how the value of the option is parsed (more on this below). The optionName field is a string such as -font or -bg; it is the name used for the option in Tcl commands and passed to procedures via the objc or namePtr arguments. The dbName and dbClass fields are used by Tk_InitOptions to look up a default value for this option in the option database; if dbName is NULL then the option database is not used by Tk_InitOptions for this option. The defValue field specifies a default value for this configuration option if no value is specified in the option database. The objOffset and internalOffset fields indicate where to store the value of this option in widget records (more on this below); values for the objOffset and internalOffset fields should always be generated with the Tk_Offset macro. The flags field contains additional information to control the processing of this configuration option (see below for details). ClientData provides additional type-specific data needed by certain types. For instance, for TK_OPTION_COLOR types, clientData is a string giving the default value to use on monochrome displays. See the descriptions of the different types below for details. The last field, typeMask, is used by Tk_SetOptions to return information about which options were modified; see the description of Tk_SetOptions above for details.
When Tk_InitOptions and Tk_SetOptions store the value of an option into the widget record, they can do it in either of two ways. If the objOffset field of the Tk_OptionSpec is greater than or equal to zero, then the value of the option is stored as a (Tcl_Obj *) at the location in the widget record given by objOffset. If the internalOffset field of the Tk_OptionSpec is greater than or equal to zero, then the value of the option is stored in a type-specific internal form at the location in the widget record given by internalOffset. For example, if the option's type is TK_OPTION_INT then the internal form is an integer. If the objOffset or internalOffset field is negative then the value is not stored in that form. At least one of the offsets must be greater than or equal to zero.
The flags field consists of one or more bits ORed together. At present only a single flag is supported: TK_OPTION_NULL_OK. If this bit is set for an option then an empty string will be accepted as the value for the option and the resulting internal form will be a NULL pointer, a zero value, or None, depending on the type of the option. If the flag is not set then empty strings will result in errors. TK_OPTION_NULL_OK is typically used to allow a feature to be turned off entirely, e.g. set a cursor value to None so that a window simply inherits its parent's cursor. Not all option types support the TK_OPTION_NULL_OK flag; for those that do, there is an explicit indication of that fact in the descriptions below.
The type field of each Tk_OptionSpec structure determines how to parse the value of that configuration option. The legal value for type, and the corresponding actions, are described below. If the type requires a tkwin value to be passed into procedures like Tk_SetOptions, or if it uses the clientData field of the Tk_OptionSpec, then it is indicated explicitly; if not mentioned, the type requires neither tkwin nor clientData.
If a field of a widget record has its offset stored in the objOffset or internalOffset field of a Tk_OptionSpec structure then the procedures described here will handle all of the storage allocation and resource management issues associated with the field. When the value of an option is changed, Tk_SetOptions (or Tk_FreeSavedOptions) will automatically free any resources associated with the old value, such as Tk_Fonts for TK_OPTION_FONT options or dynamically allocated memory for TK_OPTION_STRING options. For an option stored as an object using the objOffset field of a Tk_OptionSpec, the widget record shares the object pointed to by the objv value from the call to Tk_SetOptions. The reference count for this object is incremented when a pointer to it is stored in the widget record and decremented when the option is modified. When the widget is deleted Tk_FreeConfigOptions should be invoked; it will free the resources associated with all options and decrement reference counts for any objects.
However, the widget code is responsible for storing NULL or None in all pointer and token fields before invoking Tk_InitOptions. This is needed to allow proper cleanup in the rare case where an error occurs in Tk_InitOptions.
In most cases it is simplest to use the internalOffset field of a Tk_OptionSpec structure and not the objOffset field. This makes the internal form of the value immediately available to the widget code so the value doesn't have to be extracted from an object each time it is used. However, there are two cases where the objOffset field is useful. The first case is for TK_OPTION_PIXELS options. In this case, the internal form is an integer pixel value that is valid only for a particular screen. If the value of the option is retrieved, it will be returned as a simple number. For example, after the command .b configure -borderwidth 2m, the command .b configure -borderwidth might return 7, which is the integer pixel value corresponding to 2m. Unfortunately, this loses the original screen-independent value. Thus for TK_OPTION_PIXELS options it is better to use the objOffset field. In this case the original value of the option is retained in the object and can be returned when the option is retrieved. In most cases it is convenient to use the internalOffset field field as well, so that the integer value is immediately available for use in the widget code (alternatively, Tk_GetPixelsFromObj can be used to extract the integer value from the object whenever it is needed). Note: the problem of losing information on retrievals exists only for TK_OPTION_PIXELS options.
The second reason to use the objOffset field is in order to implement new types of options not supported by these procedures. To implement a new type of option, you can use TK_OPTION_STRING as the type in the Tk_OptionSpec structure and set the objOffset field but not the internalOffset field. Then, after calling Tk_SetOptions, convert the object to internal form yourself.
Applications can extend the built-in configuration types with additional configuration types by writing procedures to parse, print, free, and restore saved copies of the type and creating a structure pointing to those procedures:
typedef struct Tk_ObjCustomOption { char *name; Tk_CustomOptionSetProc *setProc; Tk_CustomOptionGetProc *getProc; Tk_CustomOptionRestoreProc *restoreProc; Tk_CustomOptionFreeProc *freeProc; ClientData clientData; } Tk_ObjCustomOption; typedef int Tk_CustomOptionSetProc( ClientData clientData, Tcl_Interp *interp, Tk_Window tkwin, Tcl_Obj **valuePtr, char *recordPtr, int internalOffset, char *saveInternalPtr, int flags); typedef Tcl_Obj *Tk_CustomOptionGetProc( ClientData clientData, Tk_Window tkwin, char *recordPtr, int internalOffset); typedef void Tk_CustomOptionRestoreProc( ClientData clientData, Tk_Window tkwin, char *internalPtr, char *saveInternalPtr); typedef void Tk_CustomOptionFreeProc( ClientData clientData, Tk_Window tkwin, char *internalPtr);
The Tk_ObjCustomOption structure contains six fields: a name for the custom option type; pointers to the four procedures; and a clientData value to be passed to those procedures when they are invoked. The clientData value typically points to a structure containing information that is needed by the procedures when they are parsing and printing options. RestoreProc and freeProc may be NULL, indicating that no function should be called for those operations.
The setProc procedure is invoked by Tk_SetOptions to convert a Tcl_Obj into an internal representation and store the resulting value in the widget record. The arguments are:
SetProc returns a standard Tcl result: TCL_OK to indicate successful processing, or TCL_ERROR to indicate a failure of any kind. An error message may be left in the Tcl interpreter given by interp in the case of an error.
The getProc procedure is invoked by Tk_GetOptionValue and Tk_GetOptionInfo to retrieve a Tcl_Obj representation of the internal representation of an option. The clientData argument is a copy of the clientData field in the Tk_ObjCustomOption structure. Tkwin is a copy of the tkwin argument to Tk_GetOptionValue or Tk_GetOptionInfo. RecordPtr is a pointer to the beginning of the widget record to query. InternalOffset is the offset in bytes from the beginning of the widget record to the location where the internal representation of the option value is stored. GetProc must return a pointer to a Tcl_Obj representing the value of the option.
The restoreProc procedure is invoked by Tk_RestoreSavedOptions to restore a previously saved internal representation of a custom option value. The clientData argument is a copy of the clientData field in the Tk_ObjCustomOption structure. Tkwin is a copy of the tkwin argument to Tk_GetOptionValue or Tk_GetOptionInfo. InternalPtr is a pointer to the location where internal representation of the option value is stored. SaveInternalPtr is a pointer to the saved value. RestoreProc must copy the value from saveInternalPtr to internalPtr to restore the value. RestoreProc need not free any memory associated with either internalPtr or saveInternalPtr; freeProc will be invoked to free that memory if necessary. RestoreProc has no return value.
The freeProc procedure is invoked by Tk_SetOptions and Tk_FreeSavedOptions to free any storage allocated for the internal representation of a custom option. The clientData argument is a copy of the clientData field in the Tk_ObjCustomOption structure. Tkwin is a copy of the tkwin argument to Tk_GetOptionValue or Tk_GetOptionInfo. InternalPtr is a pointer to the location where the internal representation of the option value is stored. The freeProc must free any storage associated with the option. FreeProc has no return value.
anchor, bitmap, boolean, border, color, configuration option, cursor, double, font, integer, justify, pixels, relief, screen distance, synonym
Copyright © 1998 Sun Microsystems, Inc. Copyright © 1995-1997 Roger E. Critchlow Jr.


Home
About us
Contact us
Sunday Worship
AMC Ministries Sholapur
@10 AM
Click the button to join now
Join


Common Directory Reference
|
Files |
| file | Exception.cpp |
| file | Exception.hpp |
| file | FileOperations.cpp |
| file | FileOperations.hpp |
| file | Logger.cpp |
| file | Logger.hpp |
| file | Math2D.cpp |
| file | Math2D.hpp |
| | 2D Math objects.
|
| file | MathColor.cpp |
| file | MathColor.hpp |
| file | MathMat.cpp |
| file | MathMat.hpp |
| file | MathQuat.cpp |
| file | MathQuat.hpp |
| file | MathScalar.cpp |
| file | MathScalar.hpp |
| file | MathVec.cpp |
| file | MathVec.hpp |
| file | pchCommon.cpp |
| file | pchCommon.hpp |
| file | Profiler.cpp |
| file | Profiler.hpp |
| file | Random.cpp |
| file | Random.hpp |
| file | Singleton.hpp |
| file | StdInt.hpp |
| file | StringOperations.cpp |
| file | StringOperations.hpp |
| file | Timer.cpp |
| file | Timer.hpp |
| file | Tokenizer.hpp |
Generated on Thu Jun 4 19:17:46 2009 for ::transfusion by
<IP_ADDRESS>


Temple Highlights
Newport Beach California Temple
The Newport temple was announced in April of 2001, and was dedicated in August of 2005. Members of the Church of Jesus Christ living particularly in Orange County were pleased to have a temple that they could get to within the hour. Prior to the Newport Beach Temple being built, the closest temple was either the Los Angeles, or the San Diego temple. Both temples being about a 2 hour drive one way. Having one close makes it easier for local families to make frequent visits and they couldn't be more grateful to have multiple temples so close to them.
The Newport temple had to be a shade of light tan because of it's location. The city would not let a white temple be built as it would not fit in the community. In order to build a temple the church agreed to paint the outside to work with the local city's color scheme.
Have Questions? Call Us At: 1-800-534-789


| Family Life | Past Work History |
|
My name is Christopher J. Stanton, I live in the Southern Metro Area of the Twin cities, where I was born and rasied, and absolutely love the state of Minnesota. I have many hobbys but find myself fishing, building fishing rods or coding in most of my free time. My Wife and I were recently married in St. Paul last October. We have a 11 year old Son, Gavin, that will be starting middle school next year. Gavin enjoys playing soccer and football where it consumes all of his time every summer and fall. We are also expecting a baby girl, July 19th, and cannot wait for the day to come! I would also consider myself a foodie. I enjoy going out to different and unique resturants, trying "strange" food and enjoying local beers with friends and family. Cooking is also a passion, where I like to learn new recipes and techniques, but mostly enjoyable teaching my son how to cook. |
I was an Electronics/Software Specialist that had been working in the Oil and Natural Resource Industry. For the last 3 years, I was a Supervisor and Traveling Tech for Det-Tronics where I built and completed onsite installation of hazardous location fire and gas industrial safety systems. My ability to think differently or “out side the box”, has allowed me to scale up through organizations fast and has made me an asset to all of my pervious employers. I enjoy being challenged and working on projects that require me to work outside my comfort and knowledge set. Continuous knowledge growth is something that I am passionate about. For example, I recently decided to take a new journey in life by attending Prime Digital Academy where I recently graduated with a Full Stack Software Engineering certificate. At the moment, I am currently working in full stack Web Development and am primarily writing code using the MEAN stack (MongoDb/SQL, Express.js, Angular.js and Node.js). I've found that I enjoy all aspects of computer developement, but my passion is in server side development. |


Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
Events
Cultural Events
Full Day Events
Karaoke
Zorbing
PUBG
Human Foosball
Main Events
Daastan-e-TV
Stand Up Comedy
Murder Mystery
Mr. and Ms. APSIT
Open Mic
IPL Auction
Fine Art
Nail Art
Brush Off
Face Painting
Tatoo Design
Comics Design
Charcoal Sketching
Digital Events
Picture Perfect
Director House
Developers
Our Amazing Team
Amey Mohite
UI Designer Backend Developer
Chinmay Dharap
Team Leader UI & UX Designer &
Developer Database Administrator
Nada Rajguru
UI Designer Backend Developer
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Aut eaque, laboriosam veritatis, quos non quis ad perspiciatis, totam corporis ea, alias ut unde.
Contact Us
Lorem ipsum dolor sit amet consectetur.
Karaoke
Description : How well do you know the lyrics to your favourite songs? Let’s sing out your favourite songs with the correct tempo and sync! It’s a singing event along with the lyrics being shown to you. So you don’t have to know the lyrics and come first off, which makes it an open event for everyone to sing their heart out! Let’s everyone join in the fun and cool-off things with the essence of music, in our life!
Number of participants : A maximum of 5 minutes per participant.
Rules :
Only Solo or Duet performances allowed.
Taking care of the equipment provided while singing is of utmost importance.
Getting to know newer and amazing voices of our college is the only motto.
Judging Criteria:
None! It’s a Fun Event Guys!
Date : September 2019
Zorbing
Description : Zorbing is a full day event where each of the participant has to get into a bubble like structure which covers half of your body known as “zorb”. Each participant will be wrestling with another one.
Number of participants : One on one wrestling match.
Rules :
No hitting from your leg.
Decision of referee would be final.
Date : September 2019
PUBG
Description :
It is a gaming event where people will get a chance to show off their gaming skills.
Number of participants : 4.
Rules :
• A team of 4 people with a unique squad name.
•Carry your phone with a good internet connection.
• Your squad will be given a chance to play purely on the basis of first come first serve.
•Use of abusive language during game is prohibited.
• Participants should be present on venue before time.
Mobile Joystick is not allowed.
Criteria of judging :
LAST MAN STANDING ON THE FIELD WINS THE GAME FOR HIS SQUAD.

Date : September 2019
Human Foosball
Description :
Human Foosball is like the classic table top Foosball, however, it is played with real people, a soccer ball and in a large enclosed arena. Two teams compete against each other to score the most goals in the allotted time.
Rules :
Players must keep both hands on their respective handles at all times, and one foot must be touching the ground. Shoulders must be kept above the rope at all times.
kept above the rope at all times. A goal will be awarded to the shooting team, if the opposing team deliberately takes their hands off the rope to prevent a shot on net.
When a goal is scored, the game is restarted by giving possession of the ball to the scored on team in the mid-field area.
When the ball goes out of bounds (sides or ends), the game is restarted by giving possession of the ball to the non-offending team in the mid-field area.
The game is over when the time expires.
Date: Sepptember 2019
Daastan-e-TV
Description :
Every time we hear the word "Quiz" the only thing matches with it in our mind is "BORING". But this time it's NOT. So here is the event "DAASTAN-E-TV" where you would be asked questions on "TV SERIES". So if you're TV series enthusiasts and if you have whole year Netflix subscription then this is your stage.
Number of participants :
4 Members per team.
The Competition will have Two Rounds:
First round will be an Elimination Round in which all the teams will be provided with a sheet having 30 MCQ type questions. Top 5 teams scoring maximum marks will be selected for the ‘Quiz round’.
The Quiz Round will have the following sub-rounds -
Buzzer Round
Questions based on Categories
Rapid Fire Round
Rules :
Use of internet,mobile phones,notepads,etc.will be strictly prohibited.
Decision of the event management team will be final and should be followed by the participants.
Any obscenity,vulgarity,profanity of any form will lead to direct disqualification.
Judging Criteria :
The Entire event will be a ‘Points Based Event’.
For 1st round, each question will carry equal weightage. There will be negative marking as well for every incorrect answer.
In Case of tie in 1st Round, the team which took lesser time to solve the questions will get qualified for the next round.
Points distribution for Round Two will be informed to the teams before the start of each sub-round.
The team having maximum points at the end of Round Two will be the winner.

Rules :
The Content should not offend anyone on religious, sentimental or cultural basis.
Time duration 5 minutes.
Cuss word should not be included in the Content.
The Judges decision will be Final.
Judging Criteria :
Response of the crowd.
The quality of the content.
Stage representation/performance.
Date : September 2019
Murder Mystery
Description :
The most awaited event and the highlight of Ojus 2019. A team of 5 detectives(members) will compete with other teams to unravel the murder mystery case.
“You see but you do not observe .The distinction is clear.”
-Sherlock Holmes There will be two rounds : Day 1:-
Round 1: Elimination Round
In this round every teams will be playing some tasks given to them.
This round will be mostly of either time based or points based.(It will be announced on the same day of the Event).
Tasks will be explained at the location where the teams will arrive.
Day 2:-
Round 2: Final Round
Teams will be running round to get the clues and one team who solves the mystery first will be declared as winner.
Rest of the rules will be explained on the spot.
No. of team members :
5 members per team.
Rules :
1. There has to be 5 members in the group.
2. Every individual of the team has to be present 10 mins before the event proceeds.
3. In the final round none of the team should touch the clue which does not belongs to them.
Date : September 2019
Mr. and Ms. APSIT
Description :
In chase of making dreams real??? The day has come to accomplish them after a millennium. Get ready to get an experience which kind of sparks in you a desire to go beyond, to wear the victorious crown with a pride. The most awaited event of 2019, ‘OJUS’ is here with full of exciting three rounds:
1. Introduction and Ramp Walk Round:
The contestants have to grab attention by introducing themselves with a ramp walk.
2) Talent Round:
The contestants have to show their talents to judges and they will be asked a few basic GK questions along with it. This round also has some twists and turns which will be declared on the spot.
3) Question And Answer Round (Final Round). No. of participants :
1.
Rules :
Any sort of arguments with judges and event co-ordinators would not be tolerated and can lead to on-spot disqualification.
Prop’s in talent round won’t be provided.
The decision of the judge and event in charge would be final.
Dress code should be descent.
Judging criteria :
The first round will be judged on the self-confidence with which the contestant carries himself/herself and overall appearance of the contestant. This will be the first time the crowd and judges will get to know the contestants.
The second round will be judged on the multitasking abilities of the contestants. This is the time when the crowd and judges will learn about the talents of the contestants.
The third round will be judged on the intelligence and communication abilities of the contestants which is one of the main factors contributing to full personal growth and development.
Material Requirements :
The contestants may bring prop’s for the second round.
Date : September 2019
Open Mic
Description :
An open mic is a live show at which performers try out new material & are given the opportunity to perform onstage . If you have something in you and have the urge to exhibit that to people, then open mic is the places to start out initially . Open mic as the name suggests is the first step for you to showcase your hidden talents to a small set of people which might be the stepping stone for a sold out auditorium .
Number of participants :
Single Performer OR
Group ( Max. 5 performers per group )
1. Perform Original Stuff ( in case if you are selecting poetry or story telling it must be written by performer himself / herself )
2. If your content is found copied , you will be disqualified immediately.
3. Use of abusive content is strictly prohibited.
4. Participants should be present on venue 15 min before the start of event.
Judging Criteria :
This is an open event in which there will be no winner , So all the performers feel free to perform without fear of getting judged.
Time Limit :
Max 5 min per performer / group.
Date : September 2019
IPL Auction
Description :
Ever fantasized of buying an IPL team and bidding for your favourite players? If Yes here are we to present a chance to live your Dream. An event for everyone who not only just loves the game of cricket, but also analyses it to the limit. This event makes you don the hat of a bidder. If you love cricket, if you have followed IPL and if you can mix common sense with passion into your bidding strategy, this event is a must for you.
Number of participants :
4 Members per Team.
Rules :
Round 1: Elimination Round
Preliminary Round will be Conducted on the Spot.
Round 2: On-Campus Auction
1. A purse of Rs 10 crores will be provided to each team and bidding should be done with this amount only.
2. Each team should bid for 6 players as 2 Batsman, 2 Bowlers, 1 All-Rounder, and a wicketkeeper. With the Ratio of 3 Indian and 3 Foreign Players. The above specifications are to be followed strictly.
3. Each team should appoint a Captain in their team.
4. Each Player will have a base price and a rating point. Judging Criteria :
1. The Winner will be decided on the basis of the ratings of the players they have bought and the amount they have left with a combination of both.
2. A Rating to the players has been given on the basis of the Player's International T20 performance including IPL and other Domestic Performances.
3. The Captain will be given extra credit points on his Captaincy Record.
The Decision made by the Auctioneer, Panelist and organizing team will be Final.
Date : September 2019
Nail Art
Description :
Nail Art is a creative way to paint , decorate & enhance the nails. It is type of an artwork associated with drawing or painting different types of patterns on nails or nail enhancements.
Number of participants :
1.
Rules :
Participants must create their artwork on the provided Nail enhancements in given time period (1hr 30mins).
Participants are not allowed to use their own accessories.
“Brush Off” is an event where you get to show off your artistic prowess by the means of your own thought out masterpiece drawn on a canvas, but of course if it was just that then we would’ve called it drawing…
The catch of this event is that everything is supposed to be done, but without a brush, just your hands!
So dip them in paint and make a masterpiece!
Number of participants :
Maximum 3.
Rules :
Only using your hands is allowed.
Finishing the given drawing in 1 hour 30 minutes.
No phones allowed.
Judging Criteria :
Creativity and originality.
Quality of artistic composition and overall design based on the theme.
Overall impression of your masterpiece.
Date : September 2019
Face Painting
Description :
Face Painting Is A Way To Express Your Creativity And Uniqueness. It Is A Fun Way To Dress Up No Costume Is Required.
Number of participants :
Participants Should Be In Pair
Rules :
Time Limit Is 1 Hour 30 Mins.
Complete Face Should Be Covered.
No Use Of Stencils.
Glitter, Jewels, Feathers And Other Embellishment Is Not Permitted.
Date : September 2019
Tatoo Design
Description :
To wear Tattoonies in one event, adds value and fun! Join and decorate those individuals who want to carry these marks of art and skills.
Number of participants :
1 or 2
Rules :
Time limit is 2 hours.
Bring your own necessary material for designing.
No use of any tattoo stencils.
Judging Criteria :
Creativity and appearance
Skillfully design
Date : September 2019
Comics Design
Description :
Comics is a medium used to express ideas by images, often combined with text or other visual information.
Number of participants :
Solo or group of maximum 3.
Rules :
Phone/Reference not allowed.
Time limit : 1 hr 30 mins.
Judging criteria :
Creativity and originality of the depicted theme.
Quality of artistic composition and overall design based on the theme.
Story and messages.
Date : September 2019
Charcoal Sketching
Description :
Charcoal sketching is an event where you have to show you artist skills using a Charcoal pencil. You have to sketch your masterpiece on the paper using a charcoal pencil.
Number of participants :
Solo Or Duo
Rules :
- Sketching Only With Charcoal Pencil Allowed
- Drawing Must Be Completed In 2 Hours
- No Use Of Mobiles
Date : September 2019
Picture Perfect
Goals for this year's Ojus?
Love. Laugh. Live.
And if those don't work?
AIM. FOCUS. SHOOT.
We invite you to show your best shot! Because this Ojus you've got a chance to be more Snappy!
Just a few easy steps: Click pictures during the Cultural Fest events.
Upload them with #OjusPicturePerfect.
Tag us @ojus_apsit and our sponsor Mumbai Times.
Also, don't forget that you need to upload one picture for each of the 8 days.
What's more? The best shots will get rewards and be featured on our Ojus' website !!
Date : September 2019
Director House
Description :
Photography captures a moment. But a film captures the life in those moments. You might not have the perfect spotlight but you've got a camera and we've got the awesome events at Ojus. So cut out the dull bits and capture some moments because you've got a film to make.
Just a few easy steps :
Make a short film.
Upload it with #OjusDirectorHouse
Tag us @ojus_apsit and our sponsor Mumbai Times.
Making a film? Easy.
A good one at that? A challenge.
But the best one? Surely a masterpiece.
Because the best film would be rewarded!


Controls
Stats
Generation
0
Cells alive
0
Evolution, ms
0
Render grid, ms
0
RLE browser
Fork me on GitHub


One way to tidy data is to reshape
it so that it adheres to the three rules of tidy data. While base R has several functions aimed at reshaping data, we will use the reshape2
package by Hadley Wickham, as it provides a simple and consistent set of functions to reshape data.
In the simplest terms, reshaping data is like doing a pivot table in excel, where you shuffle columns, rows and values. Let us start by tidying the pew
dataset.
pew <- read.delim(
file = "http://stat405.had.co.nz/data/pew.txt",
header = TRUE,
stringsAsFactors = FALSE,
check.names = F
)
We can tidy this data using the melt
function in the reshape2
package.
library(reshape2)
pew_tidy <- melt(
data = pew,
id = "religion",
variable.name = "income",
value.name = "frequency"
)
| religion | income | frequency |
|---|---|---|
| Agnostic | <$10k | 27 |
| Atheist | <$10k | 12 |
| Buddhist | <$10k | 27 |
| Catholic | <$10k | 418 |
| Don’t know/refused | <$10k | 15 |
| Evangelical Prot | <$10k | 575 |
Now that you know how to melt
a data frame, use the same idea to tidy the tb
dataset. Think about how you can split gender
and age
after melting the data
tb <- read.csv(
file = "http://stat405.had.co.nz/data/tb.csv",
header = TRUE,
stringsAsFactors = FALSE
)
library(reshape2)
# set column `new_sp` to NULL and clean up column names
tb$new_sp = NULL
names(tb) <- gsub("new_sp_", "", names(tb))
# Use na.rm = TRUE to remove missing observations
tb_tidy <- melt(
data = tb,
id = c("iso2", "year"),
variable.name = "gender_age",
value.name = "cases",
na.rm = TRUE
)
# split gender_age into gender and age group
library(plyr)
tb_tidy <- mutate(tb_tidy,
gender = sub("^([m|f])(.*)$", "\\1", gender_age),
age = sub("^([m|f])(.*)$", "\\2", gender_age),
gender_age = NULL
)
tb_tidy <- tb_tidy[c('iso2', 'year', 'gender', 'age', 'cases')]
There is one more step of cleaning required to assign the age
groups more meaningful names. For example, 04
stands for 0-4
.
weather <- read.delim(
file = "http://stat405.had.co.nz/data/weather.txt",
stringsAsFactors = FALSE
)
We first melt the data and convert the day
variable into numbers.
weather_tidy <- melt(
data = weather,
id = 1:4,
variable.name = "day",
value.name = "temparature",
na.rm = TRUE
)
weather_tidy <- mutate(weather_tidy,
day = sub("^d", "", day)
)
We still have the issue of variables TMAX
and TMIN
being present in rows. We can fix this using the dcast
function in reshape2
. Type ?dcast
to read up the documentation on this function.
weather_tidy2 <- dcast(
data = weather_tidy,
formula = id + year + month + day ~ element,
value.var = "temparature"
)
Tidy the dataset billboards.csv
! Note that this dataset suffers from messiness of other types. So you will need to think beyond what was done in the previous exercises.
We start by reading the dataset using read.csv
. I don't like using periods in column names, and so let us convert periods to underscores.
billboards <- read.csv(
file = "http://stat405.had.co.nz/data/billboard.csv",
stringsAsFactors = FALSE
)
names(billboards) <- gsub("\\.", "_", names(billboards))
billboards <- mutate(billboards,
artist_inverted = iconv(artist_inverted, "MAC", "UTF-8"),
)
billboards_tidy <- melt(billboards,
id = 1:7,
variable.name = "week",
value.name = "rank",
na.rm = TRUE
)
billboards_tidy <- mutate(billboards_tidy,
week = as.numeric(gsub("^x([[:digit:]]+).*", "\\1", week))
)


Basic
- $300 3-Day Package
- March through November
- Includes tour of Beaches and transportation
Premium
- $450 4-Day Package
- March through December
- Includes tour of 2 Beaches, Historic site, transportation, and meals
Deluxe
- $600 5-Day Package
- March through December
- Includes tour of 2 Beaches, 3 Historic sites, transportation, meals, and beverages.
Home Page


This is a sample HTML page. By default, JavaScript and link navigation is disabled. You can click the gear icon to enable it.
Right click - Inspect Element also works.


permafrost models soil carbon climate RCP. model changes Fig. northern dynamics region sensitivity vegetation net temperature atmospheric change NPP mitigation study {border-style losses px;} #ffffff;} University Yes loss projected response simulations CCSM air warming Model earth ecosystem important -Pg land projection, analysis models. precipitation responses used McGuire area boreal feedback increase substantial National Permafrost Res carbon–climate estimate gains projections simulated variability Clim Koven Land Lawrence Table gC⋅m global little mean production projection px; results sensitive {font-family −⋅y Biogeochem Chang Cycles Environ Global Lett Northern analyses annual did estimated estimates font-size future ii) indicate moss near-surface occur pathways primary simulation storage thaw −⋅°C (mean, CMIP Climate Research Sciences act aggressive analyzed areas century column) comparison depth double; emissions extent forcing gain generally high-latitude iii) include models, negative ranged recent region. (mean Alaska America Biol Carbon Data Environmental Geosci Glob Romanovsky Slater Version assess atmosphere border-color border-width conducted consequences consider considered data detrended effective feedback. fluxes ground includes indicated indicates limitation modeling organic pathways, productivity provided range release represent representative sink solid; structural temperature, trajectories tundra uncertainty {font-style {font-weight Arctic Biogeosciences Center Geophys Hemisphere Model, Nat Network North SD) Schaefer Schuur W⋅m active article associated atmosphere, attenuate based bold common compared concentration constrain coupled courier; datasets decades decomposition different driving dynamics. effect effort efforts em; enhanced evaluate explicitly historical included increased increases influence lateral layer likely models; nitrogen pools pt;} recognize regional sensitivities snow suggest surface syntheses synthesis thermal uptake vs. vulnerability


Student Chapter IIT Mandi
Home
Events
Why Join IEEE
Gallery
Executive Council
Resources
403 Access forbidden.


Please follow below two steps and see the doh test output in console: ( TEST SUMMARY )
1> click "Toggle Grid Programmatic" button, wait until grid created.
2> click "Toggle Grid Programmatic" button again to destroy Grid, all event connections, topics, and checkbox widgets should be destroyed, please check with debugging console, if there are no failures, means no leak. If there are one or more failures, means leak exist.


Last updated:
{{indiaData.lastupdatedtime | date:'medium'}}
{{country.country}} corona virus live data and stats about total number of cases, recovered cases and total death. Get all news and updates about COVID19 in {{country.country}}
{{todayCases}} today
{{todayDeaths}} today
{{activeCases | number}} remaining
{{casesPer1M | number}} per million
{{indiaData.deltaconfirmed}} today
{{indiaData.deltarecovered | number}} remaining
{{indiaData.deltadeaths}} today
Data is collected from various news channels and state goverments official social accounts.
| State/UT | Confirm | Recover | Death |
|---|---|---|---|
| {{state.state}} | {{state.deltaconfirmed}} {{state.confirmed}} | {{state.deltarecovered}} {{state.recovered}} | {{state.deltadeaths}} {{state.deaths}} |
Data source: ICMR website and MoH Press conference with Dr. Raman G
| Date | Samples tested | Positive cases |
|---|---|---|
| {{test.updatetimestamp}} | {{test.totalsamplestested}} | {{(test.totalpositivecases / test.totalsamplestested * 100) | number:'.1-2'}}% {{test.totalpositivecases}} |
Note: We are not a government organization, all the data which is displying is derived from various news channel reports and goverment websites.
| State/UT | Confirmed Cases |
|---|---|
| {{state.name}} | {{state.deltaconfirmed}} {{state.district.confirmed}} |
Data is collected from various news channels and state goverments official social accounts.


require 'java'
module XML
include_package 'javax.xml.parsers'
include_package 'org.w3c.dom'
end
An aAUTOMATOR Robot specifies steps for doing web scraping of a page or a set of pages. Each robot is built from several transformers connected in the shape of a graph. Each transformer type specifies some elemental operation to make. They are parametrized and combined to create a whole robot. This robot is specified in a XML format.
Here we define a DSL that we call minilanguage. It eases the creation of aAUTOMATOR robots, so no longer is needed to create verbose XML files. Instead we can use a minilanguage string to define it.
We can create a new aAUTOMATOR robot by feeding a minilanguage string to Language. Language class interprets it and creates a tree of Transformer objects. This Transformer‘s tree resembles aAUTOMATOR XML format so the latter is easy to generate.
Language interprets the minilanguage string by using the eval
capabilities of Ruby. At Language class there are methods for
creating transformers of each individual type. In order not to have
to define manually a method for each type of Transformer, we
generate them dynamically.
We include java packages for generating the XML.
require 'java'
module XML
include_package 'javax.xml.parsers'
include_package 'org.w3c.dom'
end
We define methods to ease the definition of new Transformer subclasses. These methods are called when the class is being constructed and parametrize the behavior of the generated subclass. Each generated Transformer subclass receives the values for the parameters it requires when its constructor is called. Transformer class will be reopened.
class Transformer
The @variables
used inside of class methods(self.method_name
)
are local to each subclass. They are instance variables of each
class metaclass.
This method is intended to be used inside the body of subclasses from Transformer. It stores the value of the class as a symbol.
def self.transformer_class value
@transformer_class = value.to_sym
end
def self.transformer_class_symbol
@transformer_class
end
Register a custom name for this Transformer subclass. By default, the generated method name is built from the class name. But sometimes that isn’t suitable and a custom name must be provided.
def self.custom_name name
@custom_name = name
end
def self.get_custom_name
@custom_name
end
It stores a new param definition. This method is intended to be used inside the body of subclasses from Transformer.
def self.param(name, hash)
params_definitions << ParamDefinition.new(name, hash)
end
def self.params_definitions
(@params_definitions||=[])
end
end
It stores a param definition. It has a name, if it’s required and a default value. Each Transformer subclass has some different ParamDefinition.
class ParamDefinition
def self.default_value paramDefinition
paramDefinition && paramDefinition.default_value
end
attr_accessor :name
attr_accessor :required
attr_accessor :default_value
def initialize(name, params)
self.name = name.to_sym
self.required = params[:required] && true
self.default_value = params[:default_value]
end
end
We reopen Transformer class to add a hook: self.inherited
is
called each time a new subclass of Transformer is defined.
This is a partial definition. Transformer class will be reopened.
class Transformer
Whenever a new subclass of Transformer is created, we tell Language. We also keep track of the subclasses added.
def self.inherited subclass
Language.new_type_of_transformer(subclass)
(@@subclasses ||= []) << subclass
end
The name of the method to be added to Language. It’s created from the name of the class with the first letter in lowercase, unless it’s has been customized.
def self.language_method_name
self.get_custom_name || self.lowercase_first(self.to_s)
end
def self.lowercase_first word
word[0, 1].downcase + word[1, word.length - 1]
end
end
In Language class an instance method is created for each of the subclasses of Transformer. This is a partial definition. Language class will be reopened.
class Language
@@pending_method_definitions = []
Once a transformer class is created, a method that creates a
transformer instance of that type is eventually added to
Language. The newly generated method will call
transformer_added_action
with the provided parameters.
We can’t define the new method immediately because when the
inherited
hook is called the body of the Transformer subclass has
not been executed yet. language_method_name
wouldn’t still be
defined.
def self.new_type_of_transformer transformer_klass
@@pending_method_definitions << lambda {
define_method_for transformer_klass
}
end
For example after defining the class PatternMatcher
a new method
patternMatcher
is defined on Language class, once the
register_pending_method_definitions
is called. The methods
generated receive some arguments that will be passed directly to the
class constructor. If a block is provided, it’s evaluated in a new
Language instance.
def self.define_method_for transformer_klass
define_method(transformer_klass.language_method_name) do |*args, &block|
transformer = transformer_klass.new(*args)
transformer_added_action(transformer)
if block
Language.new transformer, &block
end
self
end
end
It invokes all the pending method definitions causing the methods for each transformer to be defined.
def self.register_pending_method_definitions
This race condition doesn’t matter because all transformers are defined before languages are started to be instantiated.
pending = Array.new @@pending_method_definitions
@@pending_method_definitions = []
pending.each do |l|
l.call()
end
end
end
Now let’s define some Transformer subclasses that will cause
methods to be added to the minilanguage. Notice how we use
transformer_class
and param
methods defined before to simplify
the definition of Transformer classes.
It defines the patternMatcher
call on Language. It can be used as
patternMatcher('regexHere')
or
patternMatcher(:pattern=>'regexHere')
class PatternMatcher < Transformer
transformer_class :PatternMatcher
param :pattern, :required => true
param :dotAll, :default_value => false
end
It defines the xpath
call on Language. It can be used as
xpath('//a/@href')
or xpath(:Xpath->'//a/@href')
class Xpath < Transformer
transformer_class :HTMLMatcher
param :XPath, :required => true
end
This is not intended to be used as a direct call on Language. It
acts as a container of other transformers. For that you should use
the special calls pipe
and branch
that accept blocks.
class SimpleTransformer < Transformer
transformer_class :SimpleTransformer
end
It defines the appender
call on Language. It can be used as
appender('
')
or xpath(:append->'
')
class Appender < Transformer
transformer_class :Appender
param :append, :required => true
end
It defines the url
call on Language. @@custom_names
on
transformer class is used to customize the name. It’s used as url
or url(:description=>'whatever')
class URLRetriever < Transformer
custom_name "url"
transformer_class :URLRetriever
end
It defines the replacer
call on Language. It’s used as
replacer(:sourceRE=> '', :dest=>'')
class Replacer < Transformer
transformer_class :Replacer
param :sourceRE, :required => true
param :dest, :required => true
end
It defines the decorator
call on Language. It’s used as
decorator(:head=> '
', :dest=>'
')
.
class Decorator < Transformer
transformer_class :Decorator
param :head, :default_value => ''
param :tail, :default_value => ''
end
It defines the merger
call on Language. It’s used as
merger
. It has no required parameters.
class Merger < Transformer
transformer_class :Merger
end
We reopen the Transformer class to show how it’s instantiated. The initialize constructor is called when calling the method dynamically generated on Language class.
class Transformer
As you can see arguments
is a variable list of arguments. It can
have zero, one, two or three arguments. If branch parameters are
provided they are the first two. The params are the last one, but
it’s optional.
def self.split_parameters arguments
params = (arguments.length == 1 || arguments.length == 3) && arguments.last
branch parameters provided
if arguments.length >= 2
[arguments[0, 2], params]
no branch parameters
else
[[], params]
end
end
A transformer constructor. It’s called from Language when the concrete method associated to this class is called. Examples of calls on Language that can trigger this:
patternMatcher('(http://.*)')
decorator(:head=>"
", :tail=>"
", :description=>"wrapping")
def initialize *arguments
klass = self.class
Check that transformer_class
has been defined
unless klass.transformer_class_symbol
raise ArgumentError, "transformer_class must be defined in #{klass}"
end
branch_parameters, params = klass.split_parameters arguments
We ensure the params is in a Hash form, that the branch parameters are added, and that if a key is not found the value in default_values is returned.
params = klass.ensure_params_is_hash(params)
params = klass.with_branch_params(params, branch_parameters)
params = klass.with_defaults params
We set instance attributes from the params. Notice that if the value is not present, the default values are used.
@description = params[:description]
@branchtype = params[:branchtype].to_sym
@branchmergemode = params[:branchmergemode].to_sym
@loop = params[:loop]
We extract the values from the params for the param definitions and we generate the accessors.
@params = (klass.values_for_param_definitions params).freeze
klass.generate_named_accessors_for_parameters("params")
end
The default values used for the standard parameters. If the value are equal to these they don’t have to be provided.
@@default_values = {:branchtype => :CASCADE, :branchmergemode => :SCATTERED,
:loop => false}
Create a new hash with the contents of hash
and that fallbacks to
@@defaults_values
and the param definition if some key is not
found.
def self.with_defaults hash
result = Hash.new {|hash, key|
if key == :description
transformer_class_symbol.to_s
else
if @@default_values[key]
@@default_values[key]
else
ParamDefinition.default_value(find_param_definition(key))
end
end
}
result.merge! hash
result
end
def self.find_param_definition name
params_definitions.find{|p| p.name.to_sym == name.to_sym}
end
Add to the params hash the branch params if they exist.
def self.with_branch_params(hash, branch_params)
hash[:branchtype] = branch_params[0] if branch_params[0]
hash[:branchmergemode] = branch_params[1] if branch_params[1]
hash
end
If params is a Hash we return early.
def self.ensure_params_is_hash provided_params_values
return provided_params_values if Hash === provided_params_values
Otherwise we create a new Hash and if there is only one required param we set the value of that param for the single value provided.
single_argument = provided_params_values
result = {}
required = params_definitions.find_all {|x| x.required}
if required.size == 1
result[required[0].name] = single_argument
end
result
end
Extracts from the provided params hash, the actual values taking into account the default values. It also checks that all the required parameters without default values are set.
def self.values_for_param_definitions provided_params_values
result = provided_params_values.clone
params_definitions.each do |p|
if !result[p.name] && p.required && !p.default_value
raise ArgumentError, "#{p.name} parameter is required"
end
result[p.name] = result[p.name] || p.default_value
end
result
end
It generates dynamically accessors for the parameters definitions in
this instance, the values are the ones stored in
instance_variable_name
. For example for PatternMatcher
we
generate pattern
and dotAll
accessors.
def self.generate_named_accessors_for_parameters instance_variable_name
params_definitions.each do |param_definition|
module_eval <<-END
def #{param_definition.name}
@#{instance_variable_name}[:#{param_definition.name}]
end
END
end
end
Some accessors for properties common for all transformers.
attr_reader :branchtype
attr_reader :branchmergemode
attr_reader :description
def transformer_class
self.class.transformer_class_symbol
end
def children
Array.new(@children || [])
end
def loop?
@loop
end
def params
@params
end
end
We reopen Transformer to add the methods needed by Language to manipulate each created transformer.
class Transformer
aAUTOMATOR expects that the loop control is the first element.
def do_loop_with loop_control_transformer
(@children ||= []).insert(0, loop_control_transformer)
@loop = true
end
Append a child to this transformer
def add_child child
(@children ||= []) << child
end
end
Besides the methods presented here this class contains all the methods generated by the Transformer subclasses definitions. The Language uses Ruby blocks to create nested scopes.
class Language
This is the entering point for Language. A new Language instance
is created, against which the language_str
is evaluated. For
example if language_str
is url | xpath('//a/@href')
the methods
url
, |
and xpath
, |
are executed on the new Language
instance.
def self.language_eval language_str, filename=nil, lineno=nil
language = create_top_level
args = [language_str, filename, lineno].reject{|x| x.nil?}
language.instance_eval *args
We return the top level generated transformer
language.transformer
end
The root transformer is a SimpleTransformer that works in cascade mode.
def self.create_top_level &block
Language.new SimpleTransformer.new({}), &block
end
Method used in the tests. It’s mostly the same as language_eval but instead of a string to be evaled it receives a Ruby block of code.
def self.interpret &block
l = create_top_level &block
l.transformer
end
Method called when a new transformer is created using one of the
dynamically defined methods. It adds the created transformer
instance to the current transformer. For example, calling
patternMatcher('regexHere')
on some Language scope adds it as a
child to this Language’s instance @transformer
.
def transformer_added_action transformer
@transformer.add_child transformer
end
protected :transformer_added_action
This is syntactic sugar. Inside the top level scope or a pipe scope
the |
separator can be used to separate several transformer
instantiations. The Ruby statement separator ;
can be used too,
but |
gives it a ‘flowing’ look.
def > other
self | other
end
def | other
if @transformer.branchtype != :CASCADE
raise "| can't be used in a pipe branch"
end
self
end
Constructor for a Language. Both params and block are optional. It
creates a SimpleTransformer
as container. It interprets the
optionally provided block in the context of the Language being
created. It also registers the pending method definitions to ensure
that they are available.
def initialize transformer, &block
Language.register_pending_method_definitions
@transformer = transformer
instance_eval(&block) if block
end
The transformer that is being modified in this Language
instance.
def transformer
@transformer
end
With what we have shown so far we only could create transformers that don’t have other nested transformers. Now we define some methods that let us create nested scopes inside a Language. Each scope is a Language instance so more nested scopes can be created recursively. This scope methods receive Ruby blocks. Ruby blocks can be delimited with braces which is a very readable nesting construct.
It creates a new minilanguage scope with pipe semantics. For example a pipe could be:
url | pipe {xpath('//a/@href') |
patternMatcher('(http://.*)')}
A transformer with two children would be created: url and a SimpleTransformer with xpath and patternMatcher as children:
SimpleTransformer :branchtype => :CASCADE
- url
- SimpleTransformer :branchtype => :CASCADE
- xpath
- patternMatcher
def pipe &block
pipe = Language.new SimpleTransformer.new, &block
@transformer.add_child pipe.transformer
self
end
It creates a new minilanguage scope with branch semantics. A branch
requires that its type and merge mode are specified as params. The
provided block is interpreted with the newly created instance. The
children of a branch must be separated by newlines, never by |
. An
example of branch is:
branch(:BRANCH_DUPLICATED, :COLLAPSED) {
decorator(:head=>"
", :tail => "
")
url
}
It would generate:
SimpleTransformer :branchtype => :BRANCH_DUPLICATED
:branchmergemode => :SCATTERED
- decorator :head => "
", :tail => "
"
- url
def branch *params, &block
unless params[0] && params[1]
raise ArgumentError, "branchtype and branchmerge mode required"
end
branch = Language.new(SimpleTransformer.new(*params), &block)
@transformer.add_child branch.transformer
self
end
It tells that the last defined transformer is executed in a loop. The provided block is used as the loop control. For example:
url { patternMatcher(:pattern=>"somePattern")}.repeat? {
patternMatcher(:pattern=>"somePattern") |
decorator(:head=>"someURL")}
Notice how a transformer can receive other as children. By default
they are in cascade mode (the same as pipe
). This is specially
useful with repeat?
blocks.
def repeat? *params, &block
last_transformer = @transformer.children.last
unless last_transformer
raise "no transformer to which apply a repeat? clause"
end
clause = RepeatClause.new(SimpleTransformer.new(*params), &block)
if clause.transformer
last_transformer.do_loop_with clause.transformer
end
self
end
end
It interprets the parts inside of a repeat?
block.
class RepeatClause < Language
alias_method :standard_added_action, :transformer_added_action
Instead of adding the created transformer to the container the children of the repeat clause are stored.
def transformer_added_action transformer
(@transformers||=[]) << transformer
end
When we want to retrieve the transformer we look at the transformers that have been added.
def transformer
We add them to the implicit container first.
(@transformers || []).each do |t|
standard_added_action t
end
@transformers.clear if @transformers
If only one transformer instantiated on the repeat clause we return it. Otherwise we return the implicit container.
if super.children.size == 1
super.children[0]
else
super
end
end
end
It exposes methods to ease the creation of the XML for an aAUTOMATOR robot. New XMLBuilder instances are created for each transformer node.
class XMLBuilder
It creates a new XML Document
def self.create
factory = XML::DocumentBuilderFactory.newInstance
factory.setNamespaceAware false
XMLBuilder.new(factory.newDocumentBuilder.newDocument)
end
A XMLBuilder must have a reference to the document and the node it’s acting on. At the start that’s the root document.
def initialize(doc, node=doc)
@doc = doc
@node = node
end
When adding a new element a new XMLBuilder is created so that element can be subsequently modified.
def add_element name
element = @doc.createElement(name)
@node.appendChild(element)
XMLBuilder.new(@doc,element)
end
Using AttributesWrapper to simplify attribute modification
def attributes
@attributes_wrapper ||= AttributesWrapper.new(@node)
end
def document
@doc
end
def node
@node
end
protected :node
Add param element to transformer element with the provided value
def add_param(key, value)
param_element = self.add_element 'param'
param_element.attributes['key']= key.to_s
text = @doc.createTextNode(value.to_s)
param_element.node.appendChild(text)
param_element
end
end
It eases the way of setting attributes to an XML Element
class AttributesWrapper
def initialize(element)
@element = element
end
def []=(name,value)
@element.setAttribute(name.to_s,value)
end
end
Method to be called from the Java side with the language string. It’s interpreted by Language and the transformer generated along its children is converted to XML.
def get_xml str, filename=nil, lineno=nil
transformer = Language.language_eval(str, filename, lineno)
transformer.convert_to_xml
end
We reopen the Transformer class to define the methods needed to convert to xml.
class Transformer
def convert_to_xml
builder = XMLBuilder.create
robot = builder.add_element 'robot'
robot.attributes['version'] = '1.0'
self.fill_transformer_element(robot.add_element('transformer'))
builder.document
end
It fills the properties needed for an aAUTOMATOR transformer
def fill_transformer_element builder
We set the attributes.
builder.attributes['class'] = self.class.transformer_class_symbol.to_s
builder.attributes['branchtype'] = branchtype.to_s
builder.attributes['branchmergemode'] = branchmergemode.to_s
builder.attributes['loop'] = loop?.to_s
We add the params as elements.
params.each_pair do |key, value|
builder.add_param(key, value)
end
We apply this same method recursively to the children
children.each do |child|
child.fill_transformer_element(builder.add_element("transformer"))
end
builder
end
end
It takes an XML in aAUTOMATOR format and generates a minilanguage string that would generate it.
def to_minilanguage xml
The document element is robot and its children are the top level transformers
children_to_minilanguage(xml.getDocumentElement, " | ")
end
It converts the transformer children of an element to minilanguage.
def children_to_minilanguage parent, separator
result = ""
Lambda that converts an element to minilanguage taking into account its position.
generate_element = lambda do |element, index|
We retrieve the Transformer class associated to the element.
transformer_class = Transformer.get_class_for(element.getAttribute("class"))
unless transformer_class
raise "not found class for #{element.getAttribute('class')}"
end
result << separator if index > 0
The retrieved transformer_class knows how to convert itself to minilanguage. We provide a block that knows how to generate the children. It basically calls this method recursively.
result << transformer_class.to_minilanguage(element) {|sep|
children_to_minilanguage(element, sep)
}
loop_control = get_loop_control(element)
unless loop_control.empty?
result << ".repeat?{\n"
loop_control.each_with_index &generate_element
result << "}"
end
end
get_transformers(parent).each_with_index &generate_element
result
end
If the transformer has the loop property the first transformer will work as loop control. Otherwise all work as standard transformers.
def partition_transformers parent
all = children_list(parent).select_with_name("transformer").to_a
is_loop = parent.getAttribute('loop') =~ /true/
if is_loop
[all[0, 1], all[1, all.length - 1]]
else
[[], all]
end
end
def get_transformers parent
partition_transformers(parent)[1]
end
def get_loop_control parent
partition_transformers(parent)[0]
end
We reopen Transformer class to add the parts for converting XML to minilanguage.
class Transformer
For a given transformer class name (the one without the package) and present in the class attribute of the transformer element in aAUTOMATOR’s XML. It returns the appropriate subclass of Transformer
def self.get_class_for simple_java_class_name
subclasses_by_name[simple_java_class_name.to_sym]
end
def self.subclasses_by_name
@@subclasses.inject(Hash.new) {|acc, subclass|
acc[subclass.transformer_class_symbol] = subclass
acc
}
end
It converts the provided transformer element to a subpart of the
resulting minilanguage. For generating the children we use
children_content
.
def self.to_minilanguage element, &children_content
We extract the params to use.
params = with_defaults(extract_params_from_element(element))
If no further transformer children we generate the call.
loop_control, children = partition_transformers(element)
if children.empty?
as_call(params)
If both branch parameters are equal to the default values it’s a pipe.
else
is_pipe = [:branchtype, :branchmergemode].all?{|key|
params[key] == @@default_values[key]
}
if is_pipe
generate_pipe params, children_content
else
branch_parameters = [:branchtype, :branchmergemode].map {|key|
params[key].to_sym
}
generate_branch branch_parameters, params, children_content
end
end
end
It generates the string for a pipe. If the type is a
SimpleTransformer a pipe
call is generated. Otherwise we use the
Language method name for the class.
def self.generate_pipe params, children_content
result = ""
result << ((self != SimpleTransformer) && language_method_name || "pipe")
unless params.empty? || self == SimpleTransformer
result << "(" << as_named_arguments(params) << ")"
end
result << " {"
result << children_content.call(" | ") << "}"
result
end
It generates the string for a branch. If the type is a
SimpleTransformer a branch
call is generated. Otherwise we use
the Language method name for the class.
def self.generate_branch branch_parameters, params, children_content
result = ""
result << ((self != SimpleTransformer) && language_method_name || "branch")
result << "(#{branch_parameters[0].inspect}, #{branch_parameters[1].inspect}"
unless params.empty? || self == SimpleTransformer
result << "," << as_named_arguments(params)
end
result << ") {\n "
result << children_content.call("\n ")
result << "\n}"
result
end
def self.extract_params_from_element element
We extract the params that come from the transformer element attributes.
params = params_from_xml_attributes element
Each child param element have a key attribute and its value as text content.
children_list(element).select_with_name("param").each do |param_element|
key = param_element.getAttribute('key').to_sym
value = param_element.getTextContent.to_s.strip
If the parameter element value is different than the default we assign it to the params.
unless omitting_would_produce_same_value?(key, value)
params[key] = value
end
end
params
end
The parameters that come from the attributes are the ones defined in
@@default_values
: :branchtype
and :branchmergemode
.
def self.params_from_xml_attributes element
params = {}
@@default_values.each_pair do |key, default_value|
attrValue = element.getAttribute(key.to_s)
Only if the attribute value is different than the default value we assign it to the params. The loop attribute is ignored here too.
unless are_equal?(default_value, attrValue)
params[key] = attrValue if key != :loop
end
end
params
end
It produces the same value if it has the same value as the default value for the key.
def self.omitting_would_produce_same_value? key, value
default_value = with_defaults({})[key]
are_equal?(default_value, value)
end
def self.are_equal?(value, dom_value)
dom_value == value || dom_value == value.to_s
end
We strip the braces from the params hash. As the call only has one argument, we can provide the hash as named parameters. If params are empty only the method name is needed.
def self.as_call params
result = "#{language_method_name}"
unless params.empty?
result << "("
result << as_named_arguments(params)
result << ")"
end
result
end
def self.as_named_arguments params
/{(.*)}/.match(params.inspect)[1]
end
end
Factory method for easily generating the NodeList for an element.
def children_list element
NodeList.new(element.getChildNodes)
end
NodeList is a wrapper around a java NodeList that makes some operations less verbose.
class NodeList
We enrich this class with a lot of useful methods by including Enumerable.
include Enumerable
def initialize node_list
@node_list = node_list
end
We expose the wrapped object.
attr_reader :node_list
Needed method for supporting Enumerable module.
def each
(0...node_list.getLength()).each do |i|
yield node_list.item(i)
end
end
Return all children with the provided name.
def select_with_name name
select{|n| n.java_kind_of?(XML::Element) && name == n.nodeName}
end
end


| Stock | Change Percent | Change Volume | Refer | Close | Change Percent | Change Volume | Close Max | Close Min | Highest Max | Lowest Min | Volume Order Avg | Volume Total Avg | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| No fluctuate stock price | ||||||||||||||||||
| Stock | Change Percent | Change Volume | Refer | Close | Change Percent B | Change Volume B | Close Max | Close Min | Highest Max | Lowest Min | Volume Order Avg | Volume Total Avg |


Used for creating new databases, or querying/reading all databases.
Use .database(id)
to read, replace, or delete a specific, existing database by id.
Used for querying & reading all offers.
Use .offer(id)
to read, or replace existing offers.
Get information about the current DatabaseAccount (including which regions are supported, etc.)
Gets the currently used read endpoint. Useful for troubleshooting purposes.
The url may contain a region suffix (e.g. "-eastus") if we're using location specific endpoints.
Gets the currently used write endpoint url. Useful for troubleshooting purposes.
The url may contain a region suffix (e.g. "-eastus") if we're using location specific endpoints.
Used for reading, or updating a existing offer by id.
The id of the offer.
Generated using TypeDoc
Provides a client-side logical representation of the Azure Cosmos DB database account. This client is used to configure and execute requests in the Azure Cosmos DB database service.
Instantiate a client and create a new database
const client = new CosmosClient({endpoint: "<URL HERE>", auth: {masterKey: "<KEY HERE>"}}); await client.databases.create({id: "<datbase name here>"});
Instantiate a client with custom Connection Policy
const connectionPolicy = new ConnectionPolicy(); connectionPolicy.RequestTimeout = 10000; const client = new CosmosClient({ endpoint: "<URL HERE>", auth: {masterKey: "<KEY HERE>"}, connectionPolicy });


Organ Donation India
Eye Banks
Skin Banks
Body Donations
Organ donation hospitals
Transplant Centers
NGO's in Organ Donation
Counseller


|
s2n-doxygen-full
|
Go to the source code of this file.
Macros | |
| #define | AEPHKerr(f, r) ERR_AEPHK_error((f),(r),__FILE__,__LINE__) |
| #define | AEPHK_F_AEP_CTRL 100 |
| #define | AEPHK_F_AEP_FINISH 101 |
| #define | AEPHK_F_AEP_GET_CONNECTION 102 |
| #define | AEPHK_F_AEP_INIT 103 |
| #define | AEPHK_F_AEP_MOD_EXP 104 |
| #define | AEPHK_F_AEP_MOD_EXP_CRT 105 |
| #define | AEPHK_F_AEP_RAND 106 |
| #define | AEPHK_F_AEP_RSA_MOD_EXP 107 |
| #define | AEPHK_R_ALREADY_LOADED 100 |
| #define | AEPHK_R_CLOSE_HANDLES_FAILED 101 |
| #define | AEPHK_R_CONNECTIONS_IN_USE 102 |
| #define | AEPHK_R_CTRL_COMMAND_NOT_IMPLEMENTED 103 |
| #define | AEPHK_R_FINALIZE_FAILED 104 |
| #define | AEPHK_R_GET_HANDLE_FAILED 105 |
| #define | AEPHK_R_GET_RANDOM_FAILED 106 |
| #define | AEPHK_R_INIT_FAILURE 107 |
| #define | AEPHK_R_MISSING_KEY_COMPONENTS 108 |
| #define | AEPHK_R_MOD_EXP_CRT_FAILED 109 |
| #define | AEPHK_R_MOD_EXP_FAILED 110 |
| #define | AEPHK_R_NOT_LOADED 111 |
| #define | AEPHK_R_OK 112 |
| #define | AEPHK_R_RETURN_CONNECTION_FAILED 113 |
| #define | AEPHK_R_SETBNCALLBACK_FAILURE 114 |
| #define | AEPHK_R_SIZE_TOO_LARGE_OR_TOO_SMALL 116 |
| #define | AEPHK_R_UNIT_FAILURE 115 |
| #define AEPHKerr | ( | f, | |
| r | |||
| ) | ERR_AEPHK_error((f),(r),__FILE__,__LINE__) |
Definition at line 70 of file e_aep_err.h.
| #define AEPHK_F_AEP_CTRL 100 |
Definition at line 75 of file e_aep_err.h.
| #define AEPHK_F_AEP_FINISH 101 |
Definition at line 76 of file e_aep_err.h.
| #define AEPHK_F_AEP_GET_CONNECTION 102 |
Definition at line 77 of file e_aep_err.h.
| #define AEPHK_F_AEP_INIT 103 |
Definition at line 78 of file e_aep_err.h.
| #define AEPHK_F_AEP_MOD_EXP 104 |
Definition at line 79 of file e_aep_err.h.
| #define AEPHK_F_AEP_MOD_EXP_CRT 105 |
Definition at line 80 of file e_aep_err.h.
| #define AEPHK_F_AEP_RAND 106 |
Definition at line 81 of file e_aep_err.h.
| #define AEPHK_F_AEP_RSA_MOD_EXP 107 |
Definition at line 82 of file e_aep_err.h.
| #define AEPHK_R_ALREADY_LOADED 100 |
Definition at line 85 of file e_aep_err.h.
| #define AEPHK_R_CLOSE_HANDLES_FAILED 101 |
Definition at line 86 of file e_aep_err.h.
| #define AEPHK_R_CONNECTIONS_IN_USE 102 |
Definition at line 87 of file e_aep_err.h.
| #define AEPHK_R_CTRL_COMMAND_NOT_IMPLEMENTED 103 |
Definition at line 88 of file e_aep_err.h.
| #define AEPHK_R_FINALIZE_FAILED 104 |
Definition at line 89 of file e_aep_err.h.
| #define AEPHK_R_GET_HANDLE_FAILED 105 |
Definition at line 90 of file e_aep_err.h.
| #define AEPHK_R_GET_RANDOM_FAILED 106 |
Definition at line 91 of file e_aep_err.h.
| #define AEPHK_R_INIT_FAILURE 107 |
Definition at line 92 of file e_aep_err.h.
| #define AEPHK_R_MISSING_KEY_COMPONENTS 108 |
Definition at line 93 of file e_aep_err.h.
| #define AEPHK_R_MOD_EXP_CRT_FAILED 109 |
Definition at line 94 of file e_aep_err.h.
| #define AEPHK_R_MOD_EXP_FAILED 110 |
Definition at line 95 of file e_aep_err.h.
| #define AEPHK_R_NOT_LOADED 111 |
Definition at line 96 of file e_aep_err.h.
| #define AEPHK_R_OK 112 |
Definition at line 97 of file e_aep_err.h.
| #define AEPHK_R_RETURN_CONNECTION_FAILED 113 |
Definition at line 98 of file e_aep_err.h.
| #define AEPHK_R_SETBNCALLBACK_FAILURE 114 |
Definition at line 99 of file e_aep_err.h.
| #define AEPHK_R_SIZE_TOO_LARGE_OR_TOO_SMALL 116 |
Definition at line 100 of file e_aep_err.h.
| #define AEPHK_R_UNIT_FAILURE 115 |
Definition at line 101 of file e_aep_err.h.


The Last Supper
Summary Five liberal Iowa Graduate students share a house and carry on a tradition of a large Sunday dinner. For a year now they have been inviting a guest for dinner and discussion. On this occasion one of the roommates, Pete (Ron Eldard), brings home a stranger who picked him up when his car broke down. The stranger is Zack (Bill Paxton) who appears like a decent enough good Samaritan. Nothing could be further from the truth.  An argument escalates at the dinner table and leads to violence. After Zack assaults Marc (Jonathan Penner) and Pete, Zack is killed. The roommates are at odds with what to do. Marc, Pete and Paulie (Annabeth Gish) immediately wish to call the police. Luke (Courtney B. Vance) and Jude (Cameron Diaz) suggest something different. After more discussion they agree to dispose of the body and cover it up. They do not want to be sent to jail for what they feel was a justifiable homicide. When it is done the roommates realize that it was easier than they thought. So easy in fact that they decide that every Sunday their dinner guest would be someone who opposes of their views. If they all agree that the guest deserves to die, they will poison them and bury them in the back yard. The back yard fills up rather quickly, its' victims including (among others) a right to life extremist, an anti-environmentalist and a homophobe. By the time the roommates get to their tenth victim they begin to question their methods. Are they giving the guests a chance? Are they even giving them good food anymore?
Commentary
This film is what I like to call a "hidden treasure". This film is such a pleasant surprise. A well written, devilish satire that is funny, sexy and original. This film should be a hit, but I guess the fact that it apparently had no marketing wouldn't give it much of a chance. I had never heard of it until I saw a copy at my video store. Stacy Title does a wonderful job directing. She somehow finds the time to give all of the characters enough screen time to develop a distinct personality. >From the five members of the house to other key characters including Sheriff Stanley (Nora Dunn), the local law closing in on the truth, and the dream dinner guest, Norman Arbuthnot (Ron Perlman), a Rush Limbaugh clone who should be the roommates easiest kill. Perlman gives the films' best performance. He finds the right note as the right wing big mouth who simultaneously offends and gains followers, and may just inadvertently talk his way out of death. The other actors are convincing as well, as all of the roommates deal with their murderous ways. Some of the characters appear to be heading down the road towards insanity, while others grieve their decisions. When friends ask me to recommend a movie, this is usually the first one I think of. I am not saying that this is my favorite movie (although it is in my top ten), but because the film was such a wonderful surprise, I have a fondness for it. I also try to recommend films like this: ones that have not been seen by many people, but should.
The Last Supper ***** (out of five)
Directed by Stacy Title Jude........Cameron Diaz Pete.........Ron Eldard Paulie.........Annabeth Gish Marc.......Jonathan Penner Luke........Courtney P. Vance Norman Arbuthnot...Ron Perlman Sheriff Stanley....Nora Dunn
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Do you still shoplift alcohol
from your Mom's grocery store
as much as you did in high school?
you are a super super freak
somehow, that's worse
Some questions are better left unanswered.
Luckily, you can create a simple true|false|null
toggler for all those times when choosing NOT to
decide is still a choice.
tfxStyles.css alters the thumb, and other colors,
of a standard range type input to resemble a
common toggle switch - by setting the min to zero,
the max to two, and the step to one, the slider
will snap only to integer values.
tfxScript.js handles coloring the thumb to react to
its being used - getting jammed in to a pumpkin,
for instance, or perhaps simply sliding left and right.
The script and css alter all inputs of the type range
with the class "tfx tfx-slider"
Without any options, this HTML produces the following
default slider:
Several options, set in the data-options param,
allow customization of the true|false|null togglette.
Pronounced "tahg-luh-ZHAY".
Also, the script adjusts the slider and thumb
to match style sizing.
Watch your head on that data-options parameter;
it needs to be a well-formatted JSON string
The step option can be set to two, forcing the
slider in to a simple true|false toggle, and
allowing for this popular fiasco:
what is that even doing? is it on? is it off?
do I have to DE-select it to make it not un
active?
Better is, add some labels. The ynxStyles.css
and ynxScript.js create a customizable yes|no|null
toglette. You look good in that toglette!
May I remove unlimited quantities of MoNey
from your baNk account?
Most importantly, the ynx objects default to
having an unselected option, for all those
times you're at a loss for werds.
<link rel="stylesheet" type="text/css" href="tfxStyles.css">
<link rel="stylesheet" type="text/css" href="ynxStyles.css">

have you seen a chiropractor?
database entry:
All of the data-options values can be set using
calls to the tfxObject's various methods:
.setValue(int)
.setColor('nameColor', 'color');
.setTrans('cssTransitionString');
.iThink('youGet', 'thePicture');
I'm not even going to dignify that with a response!
~queviva


Advisors : Dr. Dhruv Batra, Dr. Devi Parikh
I am working at the intersection of computer vision and natural language processing; specifically, applying deep learning to Visual Question Answering.
[Joint first author] Making the V in VQA Matter: Elevating the Role of Image Understanding in Visual Question Answering
Accepted as a poster at CVPR 2017
We propose to counter language priors in the dataset for the task of Visual Question Answering (VQA) and make vision (the V in VQA) matter! Specifically, we balance the popular VQA dataset (Antol et al., ICCV 2015) by collecting complementary images such that every question in our balanced dataset is associated with not just a single image, but rather a pair of similar images that result in two different answers to the question. Our dataset is by construction more balanced than the original VQA dataset and has approximately twice the number of image-question pairs.
Our data collection protocol for identifying complementary images enables us to develop a novel interpretable model, which in addition to providing an answer to the given (image, question) pair also provides a counter-example based explanation - specifically, it identifies an image that is similar to the original image, but it believes has a different answer to the same question. This can help in building trust for machines among their users.
[arxiv]
[Project Page]
[YouTube Demo]
[Code coming soon!]
[Teaching Assistant] (Advanced) Introduction to Machine Learning, Virginia Tech, Fall 2016
I was a Teaching Assistant for the (Advanced) Introduction to Machine Learning Course(Fall 2016: ECE 5424) taught by Dr. Stefan Lee. I was responsible for setting up Kaggle competitions, curating homeworks and grading them.
[Course webpage]
(July 2016 - Present)
Advisor : Dr. Chu Kiong Loo
I worked on using conceptor networks to improve image classification performance on datasets like MNIST, CIFAR-10, CIFAR-100. I also used Stacked Convolutional Auto-encoders and spherical clustering, alongside hierarchical architectures like DeSTIN, for learning temporal dependencies in videos on datasets like KTH.
(June 2015 - July 2015)
Advisors : Dr. Ben Goertzel, Yuhuang Hu
Deep SpatioTemporal Inference Network (DeSTIN) is a scalable deep learning architecture that relies on a combination of
unsupervised learning and Bayesian inference. The paper
DeSTIN: A Scalable Deep Learning Architecture with Application to High-Dimensional Robust Pattern Recognition by
Itamar Arel, Derek Rose, and Robert Coop describes this method.
Briefly put, DeSTIN uses online clustering algorithms to hierarchically create cetroids in a way that loosely mimics the
way humans understand things. In the DeSTIN architecture a hierarchy of layers is used, where each layer consists of
multiple instantiations of an identical circuit or node which follow a defined spatial orientation for imaging
applications (generally speaking, however, the spatial relationship can vary according to the problem domain).
Each node learns to generalize and represent a temporal sequence of observations through unsupervised learning.
I implemented a new flavor of DeSTIN based on Stacked Convolutional Auto-encoders and tested on CIFAR-10 and CIFAR-100
datasets achieving a 21% improvement in accuracy and 6x speedup in computation time over the previous architecture.
[project details]
[code]
[GSoC Page]
(May 2015 - Sept 2015)
From April 2015 - July 2016, I was the department head of the Pointers section of the magazine since April 2015.
In July 2016, I was promoted to the position of department head of the Hello World section.
[ACM XRDS]
[Get Involved]
[Github Repository]
(April 2015 - Present)
I worked on a model for time series forecasting to determine which scientific research topics are trending using data from published academic literature. This was later deployed in production. I also built a machine learning model for classifying images of clothing items from e-commerce website’s catalog.
(Dec 2014 - Jan 2015)
I developed a predictive model to predict stock splits in NSE(India) and BSE with over 90% accuracy. I also designed and developed a prototype for stock portfolio management system.
(June 2014 - Aug 2014)
I was among the board of directors of IIMUN and in August 2012 we organised Asia's largest youth conference. I lead the coordination council, a team of over 300 fellow students; worked in the marketing and delegate relations departments leading to a 1.5x increase in the total participation and conducted training sessions on speech delivery and MUN skills for hundreds of students.
(Sept 2012 - Aug 2013)


Hello SnapStream!
I'm super fortunate to run into your website.
Who am I?
I am a biologist turned web developer. I find great interest and passion when building applications useful for the average person, the working class.
I do many more things other than develop web apps. I am mechanically inclined and I love working on my car even it isn't broke. Most would say I've spent unnecessary time and money into the dream car I've wanted since I was in middle school. I love having the right tools for every job and a dream of mine is to have a fully stocked garage with every tool imaginable. I love watching TV shows like Modern Family, HIMYM, The Office, New Girl, Raising Hope, Sons of Anarchy, The Following, American Horror Story, Criminal Minds, and the list could go on. I'm not an alcoholic but I do drink socially/occasionally.
I am a recent Dev Bootcamp graduate. Dev Bootcamp is a short, but long 19 week program, where we were immersed into OOP in Ruby, JS, and HTML/CSS. We gained tools for learning quickly and closely as team members, I like to think we became a family during the program. I know there is more to learn and I'm eager to add more tools to my belt.
SnapStream
You love TV. You love TV so much that you have built a successful business to continue to do what you love, all the while sharing the love to customers/users.
People have always said that watching TV makes one dumber. Well, I don't know the science behind that claim, but I do know that watching TV through SnapStream has to be the smarter way to "make one dumber". The ability to search your recordings like the combination of DVR/TV Guide is absolutely brilliant!
I apologize for the excitement! It's the first time I've heard about SnapStream and I would definitely like the opportunity to work at Snapstream. Feel free to check out my resume, previous projects, and any other links provided at the top and bottom of this page!


Typedef
| Static Public Summary | ||
| public |
FileSet: * Specification for building a set of test files. |
|
| public |
Observable: * An RxJS observable. |
|
| public |
SearchResult: * A result from the Bash search. |
Static Public
public FileSet: * source
Specification for building a set of test files.
Properties:
| Name | Type | Attribute | Description |
| localFiles | Array<string> | A list of files to create in the local path. |
|
| localDirectories | Array<string> | A list of directories to create in the local path. |
|
| symLinks | Array<Array<string>> | A list of symbolic links to create, consiting of a pair of paths, where the first item is the symbolic link source, and the second item is the destination of the symbolic link. This will be created in the local path. |
|
| rootFiles | Array<string> | A list of files to create in the root path. |
|
| rootDirectories | Array<string> | A list of directories to create in the root path. |
|
| rootPath | string | the path that that is specified from the root (like "/tmp/glob-test") |
|
| localPath | string | the path for local files (usually set within the project itself). |
public SearchResult: * source
A result from the Bash search.