| Home | Classes | Messages | Database Navigator Kit | Message Cross Reference |
The Vision Schema ToolKit has been created to provide a set of classes and messages that aid in tracking information about your Vision database itself. The Schema ToolKit enables you to:
Because the Schema information is maintained as part of your database using standard classes and messages, all Vision protocol is available for managing and using the information.
This ToolKit has been a standard component of all databases bootstrapped since March 1994.
The Schema class is used to support the protocol for managing information about your Vision database. As with all ToolKits, subclasses of the Schema ToolKit are named relative to the Schema class. The subclass hierarchy is shown below:
Object | ToolKit | Schema Schema Descriptor Schema ClassDescriptor Schema MessageDescriptor Schema MessageImplementationDescriptor
The Schema class organizes protocol used to process and manage schema information. It is not instantiated directly.
The class Schema ClassDescriptor (Schema CD) is used to manage information about each class in your database. There will be one instance in this class for every subclass created.
The class Schema MessageImplementationDescriptor (Schema MID) is used to manage information about each message in your database. There will be one instance in this class for every message defined for any class in your database. A separate instance is created for each definition of the message, even if the same message name is used with multiple classes.
The class Schema MessageDescriptor (Schema MD) is used to manage information about each unique message name in your database. There will be one instance in this class for every unique message name created. This class is not referenced directly by the user. Its instances are maintained and accessed via messages defined for the ClassDescriptor and MessageImplementationDescriptor classes.
Most of your interactions will be directly with the Schema class and with the ClassDescriptor and MessageImplementationDescriptor subclasses.
The basic rules for class and instance creation are presented in the documents Vision Fundamentals and Vision Classes. The basic rules for message creation and management are presented in the documents Vision Fundamentals and Vision Messages. This section reviews the relationship between Vision classes and messages and the Schema classes.
The class Schema ClassDescriptor is used to maintain information about the classes in your Vision database. Each instance of this class corresponds to a specific class in your database. Messages defined for this class record information pertaining to class hierarchy, naming dictionaries, and descriptions. The classDescriptor message is defined for each class to return the instance of the Schema ClassDescriptor class used to store descriptive information about the class.
You can create a new class from an existing class using the expression:
!NewClass <- Object createSubclass ;In this case, the variable NewClass is defined to be a subclass of the class Object. The expression:
NewClass classDescriptorreturns the Schema ClassDescriptor instance associated with this class. The variations of the createSubclass message (i.e., createSubclass: and createSubclass:at:) also create a new Schema ClassDescriptor instance that can be accessed via the classDescriptor message at the new class.
The class Schema MessageImplementationDescriptor is used to maintain information about the messages in your Vision database. Each instance of Schema MessageImplementationDescriptor corresponds to a specific message in the Vision database. These instances track information about the message itself including its type, function, and description, as well as tracking changes to methods over time.
New instances of the Schema MessageImplementationDescriptor class are NOT created automatically. Each time you use one of the define messages, the class is flagged to indicate that new messages are pending. To process and refresh all pending messages, you execute the expression:
Schema processAllMessagesThis process creates and refreshes information as needed.
The expression:
object getMessage: "message"is used to access the descriptor associated with a specific implementation of a message. This message returns an instance of the class Schema MessageImplementationDescriptor. The messages displayInfo and describe display useful information about this message in a short and long format.
This class is used to maintain information about the classes in your Vision database. Each instance of Schema ClassDescriptor corresponds to a specific class. Messages defined for this class enable you to record information pertaining to class hierarchy, naming conventions, and descriptions. The expression:
object classDescriptorreturns an instance of this class.
A number of messages defined for the Schema ClassDescriptor class are used to store and access descriptive information about the class:
| Message | Definition | Update Using |
|---|---|---|
| class | Default instance of class associated with descriptor. | should not be modified |
| name | Name of the class. This is normally the class' 'whatAmI'. | should not be modified |
| parent | Class descriptor associated with the super class of the recipient's underlying class. | should not be modified |
| type | Returns an instance of the class ClassType. | setClassTypeTo:string |
| description | Description of the class. | setDescriptionTo:string |
| sampleUsage | Describes sample syntax for accessing instances of the recipient's underlying class. | setSampleUsageTo:string |
| _htmlDocName | Name of the HTML document that describes this class in detail on insyte's www.insytenet.com web site. | setHtmlDocNameTo: string |
| htmlDocName | Name of the HTML document that describes this class in detail on insyte's www.insytenet.com web site; if no document is defined, the document name associated with the first super class in the recipient's hierarchy that has a document is returned. | Cover Method for _htmlDocName |
| _imageName | Name of the image file associated with this class. | :_imageName <- "imageFile.gif" ; |
| imageName | Name of the image file associated with this class formatted as an image tag if defined. The class name is returned otherwise. | Cover Method for _imageName |
A new Schema ClassDescriptor instance is automatically created whenever a new subclass is created using a variation of the createSubclass: messages. When this new instance is created, the following operations are performed on it:
For example, the expression:
Entity createSubclass: "Company"creates a new subclass of Entity named Company and a new instance of the Schema ClassDescriptor class initialized as follows:
A Vision database contains a large number of classes organized into a hierarchy that all eventually inherit from the class Object. The property type has been defined for the Schema ClassDescriptor class to provide a mechanism for grouping subsets of classes into logical categories. The value of type is defined to be an instance of the ClassType class. The following ClassType instances have been defined:
| ClassType | Definition |
|---|---|
| BuiltIn | all bootstrap classes such as List, Number, and Block ; these classes are part of all Vision databases. |
| Application | user defined classes that are used to model the entities, data, and navigations that define a specific Vision system; all Entity, DataRecord, LinkRecord, and DataBridge subclasses are part of this category. This category also includes DataSet classes that manage external data that is accessed directly via other classes. |
| DataFeed | user defined classes that model and store data loaded from external sources; instances of these classes are used to create and refresh Application instances and are not normally referenced by user applications. |
| ToolKit | used to organize packages of classes and messages offered as a unit to perform a set of related functions. |
| Dictionary | used to manage a set of names that return related objects. |
| ObjectSpace | used to define separate work areas that inherit from the shared CoreWorkspace. |
| Other | other classes used to support the development process. |
| Unused | classes that are still part of the database but are not currently documented or used anywhere. |
The underlying class is used to assign an initial ClassType to the type property for a Schema ClassDescriptor instance. The property value can be reassigned using the setClassTypeTo: message. To look at the current assignments use:
Schema CD instanceList groupedBy: [ type ] . do: [ "===> " print ; code printNL ; groupList sortUp: [ name ] . do: [ name printNL ] ; newLine print ; ] ;
The property inheritancePath is defined at Schema ClassDescriptor and contains an indexed list of the class descriptors in the recipient's super class hierarchy including the recipient. The property childList is defined at Schema ClassDescriptor and contains an indexed list of the class descriptors that are direct subclasses of the instance's underlying class. Both of these properties are maintained by the initialization methods defined for Schema ClassDescriptor and should not be changed manually.
Several messages have been defined at Schema ClassDescriptor to use these properties. Note that many of these messages are called by equivalent methods defined at Object.
| Message | Definition |
|---|---|
| inheritsFrom: cd | Returns TRUE if the class associated with the recipient object inherits from the class associated with the class descriptor provided, FALSE otherwise. This is similar to the version at Object except the parameter must be a class descriptor. |
| isSubClassOf: cd | Returns TRUE if the recipient is a sub class of the parameter. |
| isSuperClassOf: cd | Returns TRUE if the recipient is a super class of the parameter. |
| isInInheritancePathOf: cd | Returns TRUE if the recipient inherits from the supplied parameter or the supplied parameter inherits from the recipient. |
| getInheritancePath | Returns a list of class descriptors representing the super class hierarchy of the recipient. The list is sorted with the class descriptor for Object first and the class descriptor for the recipient class last. |
| getAllChildren | Returns a list of all the class descriptors that refer to subclasses of the recipient. |
| showChildren | Recursively displays each subclass of the recipient. |
| showParents | Displays the super class hierarchy for the recipient. |
| showInheritance | Displays the inheritance hierarchy for the recipient. This method is called directory by the version at Object. |
Naming Dictionaries are subclasses of Dictionary that are used to organize instance names for a class. To avoid conflicting names across classes, a separate naming dictionary is defined for any class that wants to be able to refer to individual instances using one or more aliases. Each Entity subclass has its own naming dictionary that is created when the class is created. You can define a naming dictionary for any class that needs it.
The property namingDictionary can be used to store a reference to the underlying class' naming dictionary, if it exists. By default this value will be NA. You can also flag a class to indicate that subclasses should automatically have a naming dictionary created for it.
When a new Schema ClassDescriptor instance is created, the naming dictionary for the class is set to the value of its parent's naming dictionary. If you've explicitly created your own naming dictionary and wish to record its value in the class descriptor, you can use the setNamingDictionaryTo: dictionary message. For example, the naming dictionary associated with application workspaces for the Interface class was defined as follows:
Dictionary createSubclass: "Named" at: Interface ; Interface Named createInstance: "ApplicationWS" ; Interface ApplicationWS classDescriptor setNamingDictionaryTo: Interface Named ApplicationWS ;
The message setAutoCreateNamingDictionaryOn can be sent to a class descriptor to indicate that a new naming dictionary should automatically be created when new subclasses of the instance's underlying class are created. For example, this flag has been set for the Entity class so that each subclass gets its own naming dictionary. When a new Schema ClassDescriptor instance is created, this flag is set to the value of its parent's flag. You can turn this flag off using the message setAutoCreateNamingDictionaryOff .
Information recorded in a class' class descriptor is used to create new instances of the class. The createInstance: method at Object runs two methods that use information stored in the class descriptor: initializeDefaults and initializeNames.
The initializeDefaults message uses the class descriptor property defaultPropertyList to assign initial values to the new instance. The defaultPropertyList contains a list of Schema MessageImplementationDescriptor objects which contain default values for any properties that require them. The techniques for setting default values for properties are described below..
The initializeNames message updates the naming dictionary associated with the class descriptor with the code and any aliases defined for the new instance.
The Schema ClassDescriptor messages are described further in the document Schema Message Dictionary.
This class is used to maintain information about each message implementation. Each message defined for a class in the Schema database has a corresponding instance in this class. The expression:
object getMessage: "string"returns a message implementation descriptor if the string is defined as a message to which the object responds. You can send the displayInfo or describe message to the result to display a short or long description of the message.
A number of messages defined for the Schema MessageImplementationDescriptor class are used to store and access descriptive information about the class:
| Message | Definition | Update Using |
|---|---|---|
| code | Name of the message. | should not be modified |
| messageClassDescriptor | ClassDescriptor of the class defining this version of the message. | should not be modified |
| class | Class defining this version of the message. | Cover method |
| messageDescriptor | MessageDescriptor for this message name. | should not be modified |
| message | Same as code. | Cover method |
| type | MessageType of this message. | Automatically updated based on the implementation, this value should only be manually reset to indicate that a method is time-varying using setTypeTo: Named MessageType MethodTV |
| isTimeVarying | TRUE if the type is TimeSeriesProperty or MethodTV. | Cover method |
| functionType | FunctionType of this message. | setFunctionTypeTo: string |
| parameterList | ClassDescriptor indicating the class of each parameter to this message if it is a binary or keyword message. | setParameter: n typeTo: cd |
| returnObjectType | ClassDescriptor indicating the type of object returned by this message. | setReturnObjectTypeTo: cd |
| returnObjectContainer | ClassDescriptor indicating if the returned object is a scalar object or a collection. | setReturnObjectContainerTo: cd |
| keyType | KeyType of this message. | flagAsKeyField ; flagAsPartialKeyField |
| usageLevel | UsageLevel of this message. | setUsageLevelTo: string |
| fullSelector | Name of the message with appropriate parameters names filled in for binary and keyword messages. | setSelectorTo: string |
The class MessageType defines instances that correspond to the different types of message that can be defined in Vision. The possible instance values are: Constant, FixedProperty TimeSeriesProperty, Method, MethodTV, and Primitive. These instances are accessible via the naming dictionary Named MessageType. Messages of type Constant were created with the define:toBe: message. Messages of type FixedProperty were created with the defineFixedProperty: message. Messages of type TimeSeriesProperty were created with the define: message. Messages of type Method and MethodTV were created with the defineMethod: message. The latter type can be explicitly assigned to indicate that a method could return different values as of different points in time. Messages of type Primitive are defined as part of the process of bootstrapping a Vision database.
The class FunctionType defines instances used to classify messages by function such as Access, Update, and Inquiry. The value of the functionType property is set to an instance of FunctionType. You can create and set function types with the setFunctionTypeTo: message. If the supplied string does not define a current function, a new instance is created.
The class UsageLevel defines instances used to classify messages by usage level. Current levels are: Basic, Advanced, Internal, and DBA. The value of the usageLevel property is set to an instance of UsageLevel. The default value is Basic. You can reset the level using setUsageLevelTo:.
The class KeyType defines two instances: Full and Partial. The property keyType can be set to one of these instances using the flagAsKeyField or the flagAsPartialKeyField message. By default, this property is NA. This flag can be used to indicate that the message could serve as a "key" for the class. Although, Vision does not require or use keys directly, this is sometimes useful for classes that are presented as part of a data model.
The property defaultValue is used to store a default value for a MessageImplementationDescriptor. It is only meaningful to store default values for messages that are properties. You can set this value using the setDefaultValueTo: message. You can clear this value using the clearDefaultValue message.
When a property is defined for a class using the defineFixedProperty: or define: message, the initial value of the property is NA for all instances of the class and for any new instance when it is created. The expression:
class defineFixedProperty: 'name' withDefault: object or class define: 'name' withDefault: objectruns the defineFixedProperty: or define: message and sets the default value in the associated message implementation descriptor to the supplied object. All existing instances are initialized to have this value. In addition, this property will be set to this default value as part of the execution of the createInstance method.
The time series property implementationSource provides a history of method changes. To display the implementation history for a particular method use:
Number getMessage: "absoluteValue" . :implementationSource #- returns time series of strings do: [ "Implementation As Of: " print; ^date printNL ; printNL ; #- displays implementation "-" fill: 50 . printNL ; ] ;
New instances of the Schema MessageImplementationDescriptor class are NOT created automatically. Each time you use one of the define messages, the class is flagged to indicate that new messages are pending. To process and refresh all pending messages, execute the expression:
Schema processAllMessagesThis process creates new MessageImplementationDescriptor instances and refreshes information as needed. Four properties supply update information for an instance. The creationDate property contains the date that the instance was first created. The updateDate property contains the date the message implementation last changed (i.e., message type and method implementation changes). The createdInLastPosting property is set to TRUE if the instance was created during the last execution of the processAllMessages message. The refreshedInLastPosting property is set to TRUE if the instance implementation or type changed during the last update.
The Schema MessageImplementationDescriptor messages are described further in the document Schema Message Dictionary.
This class is used to maintain information about the message names used in the database. It is primarily used for internal cross- referencing purposes and you should rarely need to access these values directly.
The Schema MessageDescriptor messages are described further in the document Schema Message Dictionary.
Message implementation descriptors are not automatically generated for new messages. As a result, the Schema MID class will not contain up-to-date entries for messages defined or modified recently. To process and refresh all pending messages, execute the expression:
Schema processAllMessagesThis process creates and refreshes message information as needed. Messages are normally updated as part of a a standard nightly production process.
Several messages are available for updating descriptive information about a class including:
All of these messages return the current class descriptor and can therefore be streamed together. For example:
Currency classDescriptor setDescriptionTo: "Instances of the Class Currency represents different monetary units." . setSampleUsageTo: "Named Currency USD ; "USD" asCurrency ; " . setHtmlDocNameTo: "clCurrency.htm" . ;
Several messages are available for updating descriptive information about a message including:
All of these messages return the current message implementation descriptor and can therefore be streamed together. For example, to add descriptive information to the absoluteValue message defined at Number:
Number getMessage: "absoluteValue" . setDescriptionTo: "Returns the absolute value of the recipient" . setReturnObjectTypeTo: Number . setFunctionTypeTo: "Calc" . describe ;producing:
Message: absoluteValue Class: Number Created: 10/30/1992 Updated: 10/30/1992 Function Type: Calc Returns the absolute value of the recipient Returns: Number Implementation Type: Method {|absoluteValue| ^self < 0 ifTrue: [^self negated] ifFalse: [^self]}
A number of messages have been defined at the class Object that interface with the Schema classes including:
| Message | Definition |
|---|---|
| getMessage: string | Returns a Schema MID instance if string is defined as a message for recipient, NA otherwise. |
| deleteMessage: string | Deletes the message if string is defined for the recipient class. |
| showInheritance | Displays the inheritance hierarchy (parents and children) for the recipient. |
| inheritsFrom: class | Returns TRUE if the recipient class inherits from the parameter class. |
| isSuperClassOf: class | Returns TRUE if the recipient class is a super class of the parameter class. |
| subclassList | Returns the list of classes that are subclasses of the recipient. The default instances of the actual classes are returned. |
| getMessages | Returns a list of Schema MID instances that are the messages defined explicitly for the recipient class. |
| getMessagesX | Returns a list of Schema MID instances that are the messages defined explicitly for the recipient class or any of its super classes. |
| getMessagesInInheritancePath | Returns a list of Schema MID instances that are the messages defined explicitly for the recipient class or any of its super or sub classes. |
| getMessagesDefining: string | Returns a list of Schema MID instances that explicitly define the message named by string for the recipient class or any of its super or sub classes. |
| getMessageNamesContaining: string | Returns a list of Schema MID instances that define message names that contain string for the recipient class or any of its super or sub classes. |
| getMessagesUsing: string | Returns a list of Schema MID instances that correspond to methods that contain string for the recipient class or any of its super or sub classes. |
| showMessages | Displays the messages that are defined explicitly for the recipient class or any of its super classes. |
| showMessagesX | Displays the messages defined explicitly for the recipient class or any of its super classes excluding messages at Object. |
| showProperties | Displays the messages that are properties defined explicitly for the recipient class or any of its super classes. |
| showMessagesDefining: string | Displays the messages that explicitly define the message named by string for the recipient class or any of its super or sub classes. |
| showMessageNamesContaining: string | Displays the messages that define message names that contain string for the recipient class or any of its super or sub classes. |
| showMessagesUsing: string | Displays the messages that correspond to methods that contain string for the recipient class or any of its super or sub classes. |
| showMethodsUsing: string | Displays the method implementationis that contain string for the recipient class or any of its super or sub classes. |
See Vision Messages: Access Techniques for samples that use these messages.
Two additional messages are defined at the Schema ClassDescriptor class which are useful for cross referencing the messages in your database. The message getMessagesReturningClass returns a list of Schema MID instances that return the recipient's class or a sub class of it. The message getMessagesReturningSuperClass returns a list of Schema MID instances that return a super class of the recipient's class.
The schema information can be used to answer a number of different questions. For example:
1. ===> Find all Constants and display message, class, and value Schema MessageImplementationDescriptor activeList select: [ type isConstant ] . do: [ message print: 30 ; messageClassDescriptor print: 30 ; implementationSource printNL ; ] ; 2. ===> Get all messages defined for Integer and group by function Integer getMessagesX groupedBy: [ functionType ] . do: [ printNL ; groupList do: [ displayInfo ] ; newLine print ; ] ; 3. ===> Display all Entity messages that do not have a description Entity getMessages select: [ description isNA ] . do: [ displayInfo ] ; 4. ===> Display all methods that use the asDate message Object showMethodsUsing: "asDate" ; 5. ===> Display old versions of the 'absoluteValue' message Number getMessage: "absoluteValue" . :implementationSource do: [ "Implementation As Of: " print; ^date printNL ; printNL ; # displays implementation "-" fill: 50 . printNL ; ] ; 6. ===> Show Messages By Name Sort by message, then by class within message: "Message" print: 20 ; "Class" print: 30 ; "Type" print: 13 ; "Function" printNL ; Schema MessageImplementationDescriptor activeList sortUpBy: [ messageDescriptor message ] then: [ messageClassDescriptor ] . do: [ message print: 19 ; " " print ; messageClassDescriptor code print: 29 ; " " print ; type shortName print: 12 ; " " print ; functionType printNL ; ] ; 7. ===> Show Messages By Function Group by function, then sort by message, then class "Message" print: 30 ; "Class" print: 40 ; "Type" printNL ; Schema MessageImplementationDescriptor activeList groupedBy: [ functionType ] . do: [ "===> Function Type: " print ; code printNL ; groupList sortUpBy: [ messageDescriptor message ] then: [ messageClassDescriptor ] . do: [ message print: 29 ; " " print ; messageClassDescriptor code print: 39 ; " " print ; type shortName printNL ; ] ; newLine print ; ] ; 8. ===> Show Messages By Class For each class, display all messages (excluding those at Object): "Message" print: 50 ; "Type" print: 13 ; "Implemented At Class: " printNL ; Schema ClassDescriptor activeList do: [ "Extended Message Dictionary For Class: " print ; code printNL ; class getMessagesX select: [ messageClassDescriptor isObjectDescriptor not ] . do: [ message print: 49 ; " " print ; type shortName print: 12 ; " " print ; messageClassDescriptor name printNL ; ] ; newPage print ; ] ;
These examples can easily be modified to restrict the display to messages that have been updated since a known date using:
Schema MessageImplementationDescriptor activeList select: [ updateDate >= ^today - 3 monthEnds ] . . . .
A sample kit of reports designed to work with HTML browsers, has been defined to display class and message information. These reports can be executed as part of a "live" Vision enviornment or can be pre-generated and stored on a server for static access.
For information describing the functionality and installation of this kit, see the document, The Vision Database Navigator Kit.
The Schema ToolKit has been a standard component of all databases bootstrapped since March 1994.
Variations of the specialized message create subclasses without generating a corresponding ClassDescriptor instance. The message hasSchema can be sent to any object to determine if its class has a corresponding instance in the Schema ClassDescriptor class. Several messages have been provided with this tool kit that enable you to create a class descriptor for an existing class. To add a class, the following conditions must be true:
The expressions:
Schema addClass: class and Schema addClass: class at: object and Schema addClass: class as: id at: objectcan be used to add a class descriptor for a class the does not have one. The parameter class refers to the class that needs a class descriptor. The id parameter is a string used to fill in the code property for the class descriptor. The 'whatAmI' of the class is used if the parameter is not supplied. The object parameter is used to fill in the defaultAccessPath property for the class descriptor. The path is defined relative to '^global' if this parameter is not supplied.
| Copyright © 1997 Innovative Systems Techniques, Inc. | Updated June 25, 1997 |


Window Declared in Dlls
For most guys who handles well in win32 programming, they are able to give a quick resolution to generate a window in a WinMain function.
But most likely, in many cases, programmers import dynamic linked libraries (.dll) into their win32 programs and, thus, they expects windows automatically emerges from them.
So this instruction gives a simple case where you want to inject a window into the dll under a labview (32-bit) environment.
C-Wrapper #0 Introduction
Some Basic intro and my personal thoughts on C programming language.
In most C education in college, professors put most effort on forward coding, with some versitile languages as tools such as C, Java, python. Yet most students, especially those in the future choose non-CS, math or electronics department find it abstruse to get the point of its fundamentals.
I will spend some time, but not too much talks on basic C programming laguage, which helps you merits a lot in the field of coding.
(Specific to those beginners without experience in underlayer programming languages)... --->More Details


Books
These books were made using Quarto, or R Markdown and Bookdown. They are all free, open-source, and licensed on creative commons.
Instances of Cognition
Description: This is a free, open-educational textbook and set of course materials for an introductory undergraduate course in cognition. The materials have been in continuous development since Fall 2021. All of the materials are CC BY-SA 4.0 creative-commons licensed and free for others to use, copy, remix, re-use.
Written in RStudio with Quarto. The source code is available at: https://github.com/CrumpLab/cognition
Crump, M. J. C. (2022, April 21). Instances of Cognition: Questions, Methods, Findings, Explanations, Applications, and Implications.
Reproducible statistics for psychologists with R: Lab Tutorials
Description: This is a series of labs/tutorials for a two-semester graduate-level statistics sequence in Psychology @ Brooklyn College of CUNY. The first set of 13 labs roughly tracks “Thinking with Data” (Vokey & Allen, 2018) and “Answering questions with data” (Crump et al., 2018); the second set of labs (to be written on a weekly basis during the Spring 2021 semester) roughly tracks “Experimental Design and Analysis for Psychology” (Abdi et al., 2009).
Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/rstatsforpsych
Citation: Crump, M. J. C. (2020, December 10). Reproducible statistics for psychologists with R: Lab Tutorials. https://doi.org/10.17605/OSF.IO/KBHGA
Using R for Reproducible Research: Student contributed tutorials
Description: These chapters were written by students in PSYC 7709: Using R for Reproducible research, Spring 2019 @ Brooklyn College of CUNY, as a part of their final project to write a tutorial about an R package.
Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/psyc7709_2019
Citation: Abdelrahman, K., Contreras, A., Degtyarev, Z., Deng, J., Foster, J., Franz, A., Funderburk, T., Horger, M., Kravitz, J., Lakshin A., Manigat, M., Trois, R., Vasquez, A., Vo, A., Wilson, N., and Yeremenko, M. (2019). Using R for Reproducible Research: Student Contributed Tutorials. (M. J. C. Crump, Ed.).
Answering Questions with Data: Introductory Statistics for Psychology Students
Authors: Matthew Crump; Chapters 2 and 4 adapted from Navarro, D.; Videos: Jeffrey Suzuki
Description: This is a free introductory statistics textbook for undergraduates in Psychology. It is being developed as an Open Educational Resource @ Brooklyn College. It is pitched at the concepts behind statistics, and often uses simulation in R to convey foundational ideas. The writing style is sometimes a bit unconventional, and informal. It is for students who don’t want to like statistics.
Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/statistics
Citation: Crump, M. J. C., Navarro, D., & Suzuki, J. (2019, June 5). Answering Questions with Data (Textbook): Introductory Statistics for Psychology Students. https://doi.org/10.17605/OSF.IO/JZE52
Answering Questions with Data: The Lab Manual
Lab activities using R, Excel, SPSS, and JAMOVI
Authors: Matthew Crump (R); Stephen Volz (Excel); Alla Chavarga (SPSS); Anjali Krishnan (JAMOVI)
Description: This is the companion lab manual to our free stats book. It contains lab activities for learning how to conduct statistical tests in R, Excel, SPSS, and JAMOVI. We use open data, often from psychology papers, and show step-by-step how to solve data-analysis problems in each software package.
Some of the labs are adapated from Open Stats Lab, another great resource.
Source code: Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/statisticsLab.
Citation: Crump, M. J. C., Krishnan, A., Volz, S., & Chavarga, A. (2019, June 5). Answering Questions with Data: The Lab Manual for R, Excel, SPSS and Jamovi. https://doi.org/10.17605/OSF.IO/M2NPJ
Answering Questions with Data: The Course Website
A copiable course website for introductory statistics
Authors: Matthew Crump
Description: This website was created in R Markdown. It contains most of the course materials I use when teaching undergraduate statistics for psychology. IT includes slide decks for presentations.
Source code: Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/psyc3400.
Citation : Crump, M. J. C. (2019, June 5). Answering Questions with Data: Course Website. https://doi.org/10.17605/OSF.IO/AWXU9
Research Methods for Psychology
Description:A free Research methods textbook for undergraduates in Psychology, creative commons license, remix, reuse, edit, contribute.
Authors: Matthew J. C. Crump, Paul C. Price, Rajiv Jhangiani, I-Chant A. Chiang, Dana C. Leighton
Source code: Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/ResearchMethods.
Cognitive Technologies: From Theory and Data to Application
Description: A series of chapters on cognitive technologies written by doctoral students who took my course on Cognitive Technologies in Spring 2018. They wrote it, I compiled it using bookdown.
Editor: Crump, M. J. C
Authors: Crump, M. J. C.; Amada, N.; Bourque, K; Brosowsky, N.; Ergun, T.; Korovatskaya, A.; Ma, X.; Seoung, Y.; Wylie, J.
Open tools for writing open interactive textbooks (and more)
Description: tutorial overview of the process I use to write books using R, R-studio, R-markdown, and compile them in bookdown. I’ve used this process for all of these books. Some other brief tidbits on using hypothes.is, and R-Shiny apps, also Zotero and hosting on github pages (where this website is hosted)
Author: Matthew J. C. Crump
Note this is a meta-book. The tutorial above is for you to read so you can download the source code, then compile it yourself, then edit it to make your own.
Source code: Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/OER_bookdown.
Programming for Psychologists: Data Creation and Analysis
Description: Some notes that got big enough to make a book. Beginner introduction to coding in R, Livecode, and some web-programming, for the purposes of making data with computers (programming experiments), and analyzing it in R.
Author: Matthew J. C. Crump
Source code: Written in Rmarkdown, and compiled with the bookdown package. The source code is located in this github repository https://github.com/CrumpLab/programmingforpsych.


Sophon: Automatic API Markdown Documentation Generation for Python
What is Sophon?
Before I tell you what is Sophon, let me ask you a question: Are you ever tired of writing docstrings that look like this?
def dump(obj, filename, encrypt=False):
"""Dump a object into file.
:param obj: A Python object
:type obj: any
:param filename: Filename of the file to dump
:type filename: str
:param encrypt: Whether or not to encrypt the file
:type encrypt: bool
:returns: Whether or not to dump successfully
:rtype: bool
"""
pass
reStructuredText is great, but docstring written in reST creates visually dense, and hard to read. Compare the jumble above to the same thing rewritten according to the Sophon Style Python Docstring:
def dump(obj, filename, encrypy=False):
"""Dump a object into file.
# Arguments
obj: `any`. A Python object.
filename: `str`. Filename of the file to dump.
encrypt: `bool`. Whether or not to encrypt the file.
# Return
`bool`: Whether or not to dump successfully.
"""
Use Sophon to parse the docstring and we get Markdown:
[[source]](repo/blob/branch/__main__.py#L19)
## dump
```python
dump(obj, filename, encrypy=False)
```
Dump a object into file.
**Arguments**
- **obj**: `any`. A Python object.
- **filename**: `str`. Filename of the file to dump.
- **encrypt**: `bool`. Whether or not to encrypt the file.
**Return**
- **`bool`**: Whether or not to dump successfully.
---
which is rendered by MkDocs with theme yeti
:
Much more legible, no?
As you see, Sophon is a tool that could automatically generate Markdown-format API documentations from Python docstring, just like Epydoc (supports reStructuredText, Javadoc, plaintext) and Napoleon (Sphinx extension that enables Sphinx to parse both NumPy and Google style docstrings to reStructuredText).
Sophon is written by Zhenpeng Deng(monitor1379) and licensed under the MIT license.
Why Sophon?
Features:
-
Support different kinds of docstrings. Sophon mainly supports to parse docstring with the following styles and converts them to Markdown:
- Sophon style docstring
- (Coming Soon) Google style, the style recommended by Khan Academy
- (Coming Soon) NumPy style
Sophon also supports to parse every docstring in Python project, including docstrings on:
classes
,methods
andfunctions
(modules
,attributes
andvariables
will be supported soon) -
Output Markdown format documentations. Markdown is a way to write contents for the web. Unlike cumbersome word processing applications or other markup languages with complicated syntax, text written in Markdown can be easy to read, easy to write and easily shared for between computers, mobile phones, and people. Though it does not do anything fancy like change the font size, color or type by itself, it has enough stuffs to write an API documentation for your python projects.
Another important reason of choosing Markdown is that there are some remarkable tools for Markdown to build beautiful documentations or blogs such as MkDocs(Project documentation with Markdown) or Hexo(A fast, simple & powerful blog framework).
-
Easily and Highly customizable. Sophon uses YAML: YAML Ain't Markup Language as the format of configuration file. By configuring and providing Markdown template files, you can freely organize your documentation, or open some advanced features such as linking API to source files deposited on GitHub repositories.
-
One-Command build. you only need one command to build you API documentation.
You can find more details in User Guide/Installation or User Guide/Getting Started.
What does "Sophon" mean?
Sophon is the official translation of "智子" in 《Rememberance of Earth's Past II: The Dark Forest》 which is written by the famous Chinese science fiction writer named Cixin Liu(刘慈欣).
Sophon is a word amalgamation of Sophia/sophist/sophisticated
, meaning wisdom,
and Proton/Electron/Neutron/Photon
, meaning particle,
consisting of a supercomputer embedded into a single proton that could fold itself to eleven space dimensions.


I'm a tech enthusiast and a full stack web developer.
Love creating new, interactive and interesting front end for websites.
Always ready to learn new technologies and implement them in my projects ( check out the Menu style ).
My forte are CSS, JavaScript ( JQuery and vanilla script ) and PHP.
Learning React JS currently.
Got bored of conventional education system where there is no focus on learning but rather on marks. So skipped my post-graduation. Came to Pune. To work with field experts. Currently working at Tech Mahindra.
Would love to hear from start ups if they find me interesting enough to work for them.
Future entrepreneur.
Contact us to get your website designed.


1. Introduction
1.1 Background
1.2 Stakeholders
1.3 User Requirements
1.4 Need of the System
1.5 Functionalities of the System
2. System Requirement Specification
2.1 Introduction
2.1.1 Purpose
2.1.2 Scope
2.1.3 Definitions, Acronyms and Abbreviations
2.1.4 References
2.1.5 Overview
2.2 Overall Description
2.2.1 Product Perspective
<IP_ADDRESS> System Interfaces
<IP_ADDRESS> User Interfaces
<IP_ADDRESS> Hardware Interfaces
<IP_ADDRESS> Software Interfaces
<IP_ADDRESS> Communication Interfaces
<IP_ADDRESS> Memory Constraints
<IP_ADDRESS> Operations
<IP_ADDRESS> Site Adaptation Requirements
2.2.2 Product Functions
2.2.3 User Characteristics
2.2.4 Constraints
2.2.5 Assumptions and Dependencies
2.2.6 Apportioning of Requirements
2.3 Specific Requirements
2.3.1 External Interface Requirements
<IP_ADDRESS> User Interfaces
The Candidate Interface Category
The Recruiter Interface Category
The Administrator Interface Category
<IP_ADDRESS> Hardware Interfaces
<IP_ADDRESS> Software Interfaces
<IP_ADDRESS> Communication Interfaces
2.3.2 System Features
<IP_ADDRESS> Candidate Information Maintenance
Validity Checks
Sequence Information
Error Handling/Response to Abnormal Situations
<IP_ADDRESS> Recruiter Information Maintenance
Validity Checks
Sequence Information
Error Handling/Response to Abnormal Situations
<IP_ADDRESS> Job Information Maintenance
Validity Checks
Sequence Information
Error Handling/Response to Abnormal Situations
<IP_ADDRESS> Feedback/Query Information Maintenance
Validity Checks
Sequence Information
Error Handling/Response to Abnormal Situations
<IP_ADDRESS> Job Application Information Maintenance
Validity Checks
Sequence Information
Error Handling/Response to Abnormal Situations
<IP_ADDRESS> Job Invitation Information Maintenance
Validity Checks
Sequence Information
Error Handling/Response to Abnormal Situations
2.3.3 Performance Requirements
2.3.4 Design Constraints
2.3.5 Software System Attributes
<IP_ADDRESS> Security
<IP_ADDRESS> Maintainability
<IP_ADDRESS> Portability
2.3.6 Logical Database Requirements
2.3.7 Other Requirements
4 Design of the System
4.1 Use Case Diagram
4.2 Dataflow Diagrams
4.2.1 Context Level DFD(0-Level)
4.2.2 1-Level DFD
4.3 Entity Relationship Diagram
4.4 Database Design
1.1 BACKGROUND
Medripple is an enterprise cloud platform that helps healthcare facilities (Hospitals, primary care, specialists, dentists) builds a stronger and more profitable network along with a faster and more efficient tracking system. It provides the environment for doctors where they track records of their patient. Doctors can also add report of the patients.
Its main functionality is the connection of the various providers. With the help of this, doctor can refer his patient to any provider easily. For provider purposes, the provider or doctor needs to sign-up and login into the website. The provider has the facility to choose any doctor within its connection.
1.2 STAKEHOLDERS
The complete provider community: From doctors, hospitals, clinics, nursing homes, labs, imaging centers, dentists, chiropractors, and more. The software will help the staff, clinicians, and marketing managers in managing and growing their referral network.
1.3 USER REQUIREMENTS
Basically, users of this system are the doctors and the hospital. As per the requirements, the system should contain a referral system with the help of which a doctor can refer a patient to any other connected doctor.
Doctors can access the detail of any patient and can upload their reports from anywhere and at any time, which will be less time consuming for them. The most important feature of this application is the doctors can send the request to other working doctors which will help them to grow in their network. Its a reporting system that we provide to the hospital. It helps them in finding the status of the patient i.e. how the doctor works, like how many referral he accepted, rejected and so on.
1.4 NEED OF THE SYSTEM
In previous system, the patient personal detail should not be able to shared between the doctors. The patient has to carry report with them while referral reports are also to be carried. With the help of this system, we are able to see the status update of the patient within the same system. Doctor can find the best doctor nearby, to refer his patient.
It provides an MIS, which helps the sales force team of the hospital to track how many referral has been sent and how many referral have been received by the hospital. Hence, to reduce the job efforts required to manage the information and perform various functionalities as described above, a new system is proposed in which the work is done electronically using computers. This takes a great load off, the hospital in terms of handling the Referral related tasks efficiently
1.5 FUNCTIONALITY OF THE SYSTEM
The application has the following functionalities:
Reminder system:- Reminder system reminds the doctor about the tasks that have been fixed in connection to any action on the particular referral that is sent to him at the time set in the reminder list.
Report: -The doctor can easily upload reports, with the help of which the doctor can easily consult with other doctor by sending him the report. It also benefits the patient as he is not required to carry report with him while going to the other doctor.
Group: - In this, doctor can make a group which helps in discussing the problem of a patient with another doctor.
Referral:- It offers to management of referrals anytime anywhere cloud based platform, where the business can be managed, patient records can be added and the referral process can be managed.
Grow Network:- It offers access to the largest provider directory in India. Once the registration is done with the updated profile, it makes it easily discoverable for your partners along with providing them with a more modern, streamlined way to stay in touch with you and your staff.
Chapter 2
System requirement specification
2.1 INTRODUCTION
Medripple offers access to the largest provider directory in India. Once you register with your updated profile, we make it easily discoverable for your partners along with providing them with a more modern, streamlined way to stay in touch with you and your staff.
2.1.1 PURPOSE
This specification document describes the capabilities that will be provided by the software application Medripple. It also states the various required constraints by which the system will abide. The intended audiences for this document are the development team, testing team and end users of the product.
2.1.2 SCOPE
The system is an online web application called Medipple that can be accessed by Doctors and Hospital staff with a proper system to log into the system. This system can be used as an application to manage the patient referral system. This system can also be used by the doctors to connect with other working doctor.
The proposed system is to make an online web application for the Medripple, so that the Doctors can register to grow their network and make a referral system easy . An administrator handles and manipulates all the data available in the system. The proposed system could be accessed from any corner of the world on net.
2.1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Following abbreviations have been used throughout the documentation :-
FindApp : Find Applicants
Info : Information
Desc : Description
2.1.4 REFERENCES
(i) IEEE Recommended Practice for Software Requirements Specifications
2.1.5 OVERVIEW
The rest of the SRS document describes the various system requirements, interfaces, features and functionalities in detail.
2.2 OVERALL DESCRIPTION
The medripple system is an online website where doctors carry all the detail about their patient. Functionality of the online website for a medripple includes managing the Doctor and Patient information, managing the information provided by the Patients, providing functionality for the Doctors to enter their Patient Reports.
2.2.1 PRODUCT PRESPECTIVE
The application will be a web-based, self-contained and independent software product.
<IP_ADDRESS> SYSTEM INTERFACES
None
<IP_ADDRESS> USER INTERFACES
The Medripple application has a user-friendly and menu-based interface. The users of this application i.e. the doctors can add to any other doctor in the network. The User Interface will have the following pages :-
Home Page
The Register Page
The Login Page
The Grow Network Page
My partner Page
My patient Page
Patient referral Page
Patient Referred by Me page
Patient Referred to Me page
The Inbox Page
Patient Detail page
Add patient page
Create groups Page
My group page
The Profile Page
<IP_ADDRESS> HARDWARE INTERFACES
i. Standalone System or network based- Is not a concern, as it will be possible to run the application on any of these.
<IP_ADDRESS> SOFTWARE INTERFACES
i. Any window-based operating system.
ii. MySQL Server as the DBMS for database.
<IP_ADDRESS> COMMUNICATION INTERFACES
None
<IP_ADDRESS> MEMORY CONSTRAINTS
None
<IP_ADDRESS> OPERATIONS
This product release will not cover any automated housekeeping aspects of the database. The DBA at the client site will be responsible for manually deleting old/non-required data. Database backup and recovery will also have to be handled by the DBA.
<IP_ADDRESS> SITE ADAPTATIONS REQUIREMENTS
The terminals at client site will have to support the hardware and software interfaces specified in the above sections.
2.2.2 PRODUCT FUNCTIONS
The system will allow access only to the doctor and hospital staff. A summary of the major functions that the system will perform :-
i. Grow the network of referral doctors.
ii. Plug leakages/malpractices- make the existing referral network efficient and effective.
iii. Receive the patient referral seamlessly on web/mobile.
iv. Receive patient reports along with referrals.
v. Book, reschedule and cancel appointments with automatic updates to referring doctor.
vi. Send/get instant updates on patients progress through app notifications, messages and emails.
vii. Create groups, add members and discuss on topics related to your hospital.
viii. Let your network of referral doctors become aware of new procedure, machinery and product launches.
ix. Track region wise performance through detailed MIS reports.
x. Carry your patient details with you anywhere anytime - All the data shall be available 24x7 on web or App
2.2.3 USER CHARACTERISTICS
Educational Level : At least graduate, should be comfortable with English language.
Technical Expertise : Should be comfortable using general-purpose applications on a computer.
2.2.4 CONSTRAINTS
Users at company will have to implement a security policy to safeguard the product related information from being modified by unauthorized users (by means of gaining access to the backend database).
2.2.5 ASSUMPTIONS AND DEPENDENCIES
The Administrator is responsible for approval of doctor account.
2.2.6 APPORTIONING OF REQUIREMENTS
Not required.
2.3 SPECIFIC REQUIREMENTS
This section contains the software requirements to a level of detail sufficient to enable the designers to design the system and the testers to test the system.
2.3.1 EXTERNAL INTERFACE REQUIREMENTS
<IP_ADDRESS> USER INTERFACES
Following screens/pages will be accessible to all the Doctors :-
Home Page
The
Home Page of the Medripple will be the first page to
be displayed when the doctor first visits the website. This page will display a
welcome message and in addition it will display various menus to facilitate
navigation through the application.
The Register Page
The
Register page will be used by the Doctors to register with the application.
Before the registration doctors first need to confirm their mobile number.
One Time Password (OTP)
To
proceed with registration, users have to verify his mobile number by the
onetime password (OTP) which is sent to the users mobile via SMS.
Registration form
It
contains various fields as listed below:
User Name : Range 0 to 50 and
required field.
Password : Text
should be in * and required field.
First Name : First name
of the user.
Last Name : Last name of
the user.
Email
: Email-id of the user and email validation is used, also required field.
Mobile Number : It must be automatically filled by the mobile number which the
user enters at the time of OTCity: - City of the
user.
The Login Page
The
already registered Doctors can log into the system with the help of this page.
In this Doctors needs to fill the following fields :-
Login
: Alphanumeric of no maximum length of format<EMAIL_ADDRESS>Password :
Alphanumeric of no maximum length
The Doctors with correct Login ID and Password will be logged into the system after validating them using Login table in the database.
The Grow Network Page
The
Grow Network Page of the medripple will be the first
page to be displayed when the doctor first logs into the website. This
page will display a welcome message and in addition to it, it will display
various menus to facilitate navigation through the application.
Connection request Page
It
contains two type of request which is sent by provider/doctors.
a) Provider
connection request
:Just like a friend request to a user, it has an
option of accepting or rejecting the request.
b) Group connection request : It is a group request to a user. It has an option of accepting or rejecting the
request.
My partner Page
Just
like my friends on Facebook, the entire providers/doctors who are in our
connection are present here. This page also contains functionality
like :-
1. Patient referral
2. Send message to the provider
3. See the conversation between the providers
My Patient Page
In my
patient page provides the list of patient that doctor have. In this
doctor can refer the any patient directly to the connected provider.
Doctor can also upload report of the patient.
Patient Detail page
This
page provides the complete details of the patient including name , age ,
gender, diseases, phone number, Email Id ,Address and the various report
uploaded before. He can also upload report using the upload report button. The
Doctor can edit his/her information using the edit button shown on the screen
in case he/she needs to make any changes or modifications. The Doctor can also
refer to any other provider using the button refer shown on the screen.
Add patient page
The
Add patient Page will be displayed on the menu once the Doctor has
logged into the system. Add patient Page contains a form to add a new
Patient into the application. Once the Doctor has filled the form he/she
can click the Submit button. The various fields of the form are :-
i. Name
ii. Email Id
iii. Mobile Number
iv. Relation
v. Age
vi. Gender
vii. Address
viii. Country
ix. City
Patient referral Page
The
Patient referral page provides the list of patient which the doctor has. With a
click on the select button given in front of the patient name, we can select
the patient which we have to refer. To refer the patient, doctor has to specify
the provider name to which he has to refer, any note regarding he disease.
Doctor can also upload report using the upload report button.
Patient Referred by me page
The
Patient Referred by me page contains the list of patient referred by the
doctor till now. It contains the information about the doctor to which we have
referred the patient, the type of provider, the date on which the last
action has been taken ,the status of the referral i.e
pending, accepted, treatment taken, appointment fixed or completed are all listed.
Patient Refer to me
The
Patient Referred to me page contain the list of patient referred to doctor
till now. It contains the information about the doctor we have referred the
patient to, the type of provider, the date on which the last action has been
taken ,the status of the referral i.e pending,
accepted, treatment taken, appointment fixed or completed.
Create groups Page
The
Create group Page will be displayed on the menu once the Doctor has logged
into the system. Create Group Page contains a form to create a
group into the application. Once the Doctor has filled the form he/ she
can click the create group button. The various fields of the form are :-
1. Group name
2. Group access type
3. Group Type
4. Group member
5. Group description
My group page
The
my group page contains the list of groups the person is added to. By clicking
on any group name we can see the group details which contain number of member,
role and member type. To delete patient details, we have to click the delete
button which is present in front of each member. Member can leave the groups
any time. A group can have only one group admin.
The Profile Page
The
Profile Page will be displayed in my account once the doctor has
logged into the system and has authorized access. It will contain all the doctorsinformation : Personal Information, Login
Information, Contact Information and Professional Information provided by the
doctor. The candidate can edit his/her information using the edit button shown
on the screen in case he/she needs to make any changes or modifications.
The Inbox Page
The
Inbox Page will be displayed on the menu once the doctor has logged into the
system and has authorized access. It will contain all the job messages that
exchange between the doctor.
Report Referral to me
Management
Information System : Its a reporting system that we provide to the hospital.
Which help them in finding the status of the patient I.e. how he works on that
like how many referral he accepted, rejected and so on.
a. Referral details by me.
b. Referral details to me.
c. All connected patient
d. All connected doctors (provider).
7. Contact us
3.1.2 Hardware Interfaces
As stated in section 2.1.3.
3.1.3 Software Interfaces
As stated in section 2.1.4.
3.1.4 Communication Interfaces
As stated in section 2.1.5.
3.2 System Features
3.2.1 Referral system
Description: MANAGE YOUR REFERRALS ANYTIME ANYWHERE.  To do this we have to register all new patients on the platform. Refer your patients using the platform. Track your patients progress on the platform.
Validity Checks:
The Validations will be applied on the Parameter set of the referral. Referral will only be send to the connected provider. It must contain the name of the disease. We have to give notes while giving referral. We have to specify to which provided we have to send the referral.
Sequencing Information:
Parameters will be first entered on the User Interface of the Referral.
Error Handling/Response to Abnormal Situation: If any of the above validations/sequencing flow does not hold true, appropriate error message will be prompted to the user for doing the needful.
3.2.2 Grow network
Description : GROW YOUR NETWORKFIND THE PEOPLE AND CONNECT WITH THEM
Showcase your profile. Search & connect with your potential partners. Invite your existing partners on to the platform
Validity Checks:
The Business Validations will be applied on the Parameter set of this grow network.
The Provider should be a valid member of Medripple.
Sequencing Information:
Parameters will be first entered on the User Interface of the grow network.
Error Handling/Response to Abnormal Situation: If any of the above validations/sequencing flow does not hold true, appropriate error message will be prompted to the user for doing the needful.
3.2.3. Report
The doctor can easily upload reports, with the help of which the doctor can easily consult with other doctor by sending him the report. It also benefits the patient as he is not required to carry report with him while going to the other doctor.
Validity Checks:
The Business Validations will be applied on the Parameter set of this grow network. The provider must specify the type of report. Report type is only contain pdf or jpeg form.
Sequencing Information: Parameters will be first entered on the User Interface of the Report.
Error Handling/Response to Abnormal Situation: If any of the above validations/sequencing flow does not hold true, appropriate error message will be prompted to the user for doing the needful.
3.2.4. Group: -
In this, doctor can make a group which helps in discussing the problem of a patient with another doctor. There are two types of groups one is the normal type where every group member can send the message and one is the announcement type where only the group admin can send the message.
Validity Checks
The Business Validations will be applied on the Parameter set of this Group. The User has to give the name of the groups. The user has to specify the access type i.e. public or private.
The user has to specify the group type i.e. normal or announcement. The user has to choose the member to whom he wants to add in the group.
Sequencing Information
Parameters will be first entered on the User Interface of the Group.
Error Handling/Response to Abnormal Situation: If any of the above validations/sequencing flow does not hold true, appropriate error message will be prompted to the user for doing the needful.
3.5 Software System Attributes
3.5.1 Security
The application will be password protected with a unique username for each user.
3.5.2 Maintainability
The application will be designed in a maintainable manner. It will be easy to incorporate new requirements in the individual modules and extend the existing project.
3.5.3 Portability
The application will be easily portable on any web server which is J2EE Compliant.
3.6 Logical Database Requirements
The following information will be placed in the database:-
User Login Table : Username, Password, CompanySysId, CompanyName
ReportProperty Table : ReportPropertySysId, ReportPropertyTypeCVid, Code, Description, EnhancedViewEnabled, InteractiveViewEnabled, IsAsyncFlag
3.7 Other Requirements
None.
Chapter 4
DESIGN OF THE SYSTEM
Screen shots
Home page


One of the goals of MPI was to allow for layered libraries. In order for a library to do this cleanly, it needs to know if MPI is active. In MPI the function MPI_INITIALIZED was provided to tell if MPI had been initialized. The problem arises in knowing if MPI has been finalized. Once MPI has been finalized it is no longer active and cannot be restarted. A library needs to be able to determine this to act accordingly. To achieve this the following function is needed:
| MPI_FINALIZED(flag) | |
| OUT flag | true if MPI was finalized (logical) |
int MPI_Finalized(int *flag)
MPI_Finalized(flag, ierror)
LOGICAL, INTENT(OUT) :: flag
INTEGER, OPTIONAL, INTENT(OUT) :: ierror
MPI_FINALIZED(FLAG, IERROR)
LOGICAL FLAG
INTEGER IERROR
This routine returns true if MPI_FINALIZE has completed. It is valid to call MPI_FINALIZED before MPI_INIT and after MPI_FINALIZE. This function must always be thread-safe, as defined in Section MPI and Threads .
Advice to users.
MPI is ``active'' and it is thus safe to call MPI functions if
MPI_INIT has completed and MPI_FINALIZE
has not completed. If a library has no other way of knowing whether
MPI is active or not, then it can use MPI_INITIALIZED and
MPI_FINALIZED to determine this. For example, MPI is ``active''
in callback functions that are invoked during MPI_FINALIZE.
( End of advice to users.)


Disposes of this socket.
Emits an event to subscribers.
Subscribes to this sockets 'open' event.
Subscribes to this sockets 'message' event.
Subscribes to this sockets 'error' event.
Subscribes to this sockets 'close' event.
Subscribes to this sockets 'open' event once.
Subscribes to this sockets 'message' event once.
Subscribes to this sockets 'error' event once.
Subscribes to this sockets 'close' event once.
Removes this event handler.
Sends a message to this socket.
Connects to a virtualized socket server on the given port.
Generated using TypeDoc
Closes this socket.


+++ title = "Museum of Anthropology, Xalapa" slug = "museum-of-anthropology-xalapa" date = 2007-02-23T15:00:00+10:00 tags = ["anthropology", "museums"] locations = ["mexico/xalapa"] draft = false summary = """
Xalapa is home to one of Mexico's largest museums of anthropology. After a radioactive lunch, Mauricio and Lachlan took Steve and myself to this museum, and we thoroughly explored this amazing place.
""" +++Xalapa is home to one of Mexico's largest museums of anthropology. After a radioactive lunch, Mauricio and Lachlan took Steve and myself to this museum, and we thoroughly explored this amazing place.
{{< galleryphoto "2007-02-23-15-00-00--the-very-long-main-corridor-of-the-museum.jpg" >}}One of the things that I really liked about this museum was that it's local. Everything in it is local. It concentrates on the Olmec — and, to a lesser extent, Toltec — civilisations that flourished in the Xalapa region, prior to the arrival of the Spanish in the 16th century.
The museum is most famous for its Olmec cabezas gigantes (lit: "gigantic heads"), of which it has several; with each one consisting of at least 3 cubic metres of solid rock.
{{< galleryphoto "2007-02-23-15-01-00--steve-and-i-admire-a-chunky-olmec-head.jpg" >}}I guess that if I was a human sacrifice 1,100 years ago, my philosophy would have been that if I was going to be sacrificed, I'd at least want to be sacrificed to something big. And these fellas really are big.
There are countless statues, cooking utensils, rock shards, and other works of stone in the museum. The majority of them are extremely well-preserved. There's even a circular rock carving — a single, unified circle of rock tapestry — that goes round for about 30m in length.
There's also a large tabletop model of the site of El Tajin, the ruins that are about 4 hours north of Xalapa, that I unfortunately won't be able to see on this trip (they're too far out of my way, and they're not in the "must-see" class of ruins). The model conveys the size, the grandeur, and the good condition of El Tajin quite vividly.
{{< galleryphoto "2007-02-23-15-02-00--large-model-of-el-tajin.jpg" >}}


Lua Scope
Scope Tutorial
lua-users home wiki
Until now you just assigned values to names, and could get back the value by using the name anywhere in the script. This is fine for small examples, but now that you know functions, it can be a big problem: what if different functions use the same name to store temporary values? They will conflict and overwrite each other, making your script an impossible-to-debug mess. The solution is to control where your variables exist using the local keyword.
Interactive interpreter note
The examples in this page will be written in the form of a script file instead of an interactive interpreter session, since local variables are really hard to work with in it. It will be explained why later.
Creating local variables
To create local variables, add the local keyword before the assignment:
local a = 5
print(a)
You don’t need the local keyword any more when changing the variable:
local a = 5
a = 6 -- changes the local a, doesn't create a global
Local variables only exist in the block they were created in. Outside of the block, they do not exist any more.
local a = 5
print(a) --> 5
do
local a = 6 -- create a new local inside the do block instead of changing the existing a
print(a) --> 6
end
print(a) --> 5
The place where a variable is visible is called the “scope” of a variable.
Now let’s use functions to show how this is really useful:
function bar()
print(x) --> nil
local x = 6
print(x) --> 6
end
function foo()
local x = 5
print(x) --> 5
bar()
print(x) --> 5
end
foo()
As you can see, each variable is visible from the point where it’s declared to the end of the block it’s declared in. Even though bar’s x exists at the same time as foo’s x, they’re not written in the same block, so they’re independent. This is what’s called lexical scoping.
local function syntax sugar
local function f() end
-- is equivalent to
local f
f = function() end
-- not
local f = function() end
the difference between the last two examples is important: the local variable still doesn’t exist to the right of the = that gives it the initial value. So if the contents of the function used f to get a reference to itself, it will correctly get the local variable in the first and second versions, but the third version will get the global f (which will be nil, if not a completely unrelated value set by some other code).
Closures
Functions can use local variables created outside of them. These are called upvalues. A function that uses upvalues is called a closure:
local x = 5
local function f() -- we use the "local function" syntax here, but that's just for good practice, the example will work without it
print(x)
end
f() --> 5
x = 6
f() --> 6
The function sees the change even if it’s changed outside of the function. This means that the variable in the function is not a copy, it’s shared with the outer scope.
Also, even if the outer scope has passed, the function will still hold on to the variable. If there were two functions created in the scope, they will still share the variable after the outer scope is gone.
local function f()
local v = 0
local function get()
return v
end
local function set(new_v)
v = new_v
end
return {get=get, set=set}
end
local t, u = f(), f()
print(t.get()) --> 0
print(u.get()) --> 0
t.set(5)
u.set(6)
print(t.get()) --> 5
print(u.get()) --> 6
Since the two values returned by the two calls to f are independent, we can see that every time a function is called, it creates a new scope with new variables.
Similarly, loops create a new scope on each iteration:
local t = {}
for i = 1, 10 do
t[i] = function() print(i) end
end
t[1]() --> 1
t[8]() --> 8
Why are local variables difficult in the interactive interpreter
Because it runs each line in a new scope:
> local a=5; print(a)
5
> print(a) -- a is out of scope now, so global a is used
nil
One thing you can do is wrap the code in a do-end block, but it won’t be interactive until you finish writing the whole block:
> do
>> local a = 5
>> print(a) -- works on a new line
>> end
5
Why not local by default?
You might be coming from another language that makes variables local by default, and are probably thinking “what is the point of all this extra complication? Why not make variables local by default?”:
x = 3
-- more code, you might have even forgotten about variable x by now...
function ()
-- ...
x = 5 -- does this create a new local x, or does it change the outer one?
-- ...
end
-- some more code...
The problem with changing the outer one is that you might have intended to make a new variable, and instead change the existing one that you might not even know about, introducing bugs.
The problem with creating a new one is what if you actually want to change the outer one?
With the local keyword, it’s all explicit: without local, you change the existing variable, with it, you create a new one.
For more discussion about this, see LocalByDefault.
When to use local variables
The general rule is to always use local variables, unless it’s necessary for every part of your program to be able to access the variable (which is very rare).
Since it’s easy to forget a local, and since Lua doesn’t warn you about it (instead silently creating a global), it can be a source of bugs. One solution is to use a script like strict.lua (shown below), that uses metatables (mentioned in a later tutorial) to trap global variable creation and raise an error. You can put the script in a file in your project, and do require(“strict”) to use it.
--
-- strict.lua
-- checks uses of undeclared global variables
-- All global variables must be 'declared' through a regular assignment
-- (even assigning nil will do) in a main chunk before being used
-- anywhere or assigned to inside a function.
--
local mt = getmetatable(_G)
if mt == nil then
mt = {}
setmetatable(_G, mt)
end
__STRICT = true
mt.__declared = {}
mt.__newindex = function (t, n, v)
if __STRICT and not mt.__declared[n] then
local w = debug.getinfo(2, "S").what
if w ~= "main" and w ~= "C" then
error("assign to undeclared variable '"..n.."'", 2)
end
mt.__declared[n] = true
end
rawset(t, n, v)
end
mt.__index = function (t, n)
if not mt.__declared[n] and debug.getinfo(2, "S").what ~= "C" then
error("variable '"..n.."' is not declared", 2)
end
return rawget(t, n)
end
function global(...)
for _, v in ipairs{...} do mt.__declared[v] = true end
end
For more info about enforcing use of local variables, see DetectingUndefinedVariables. RecentChanges · preferences edit · history Last edited December 21, 2013 9:07 am GMT (diff)
- Previous
- Next


Post Malone extends North American tour, adds shows in Toronto and Montreal
by Basem Boshra Supervising Producer, CTV News Montreal | ContactMONTREAL - Post Malone, the multi-platinum-selling rapper and singer, announced Tuesday that he is extending his North American tour, which will bring him to Toronto and Montreal.
Malone, who first hit the Billboard singles charts in 2015 with his song "White Iverson," will perform Feb. 14 at Scotiabank Arena in Toronto and Feb. 16 at the Bell Centre in Montreal.
Tickets for the newly announced shows go on sale Friday at 9 a.m.
Malone's Hollywood's Bleeding tour - named after his recently released third album - wraps up with two shows in Los Angeles later this week. The next leg kicks off Feb. 4 in Omaha, Nebraska.
Malone - whose real name is Austin Richard Post - is estimated to have sold around 60 million records in the United States. Two of his three albums have reached No. 1 on the Billboard 200 album sales chart.
Malone is up for a leading seven nominations at this year's American Music Awards, which are to be held Sunday in Los Angeles.
Swae Lee, half of the popular hip hop duo Rae Sremmurd, will open for Malone on the new leg of the tour.


Nicolas Pcsolar - Nicolas Pcsolar is a junior at the University of Pittsburgh at Greensburg. He is currently majoring in Information Tecchnology and hopes to obtain a career in Database Administration or a career as a Network Systems Analyst.
Mark Raschiatore - Mark Raschiatore is a junior at the University of Pittsburgh at Greensburg. He is currently majoring in Information Tecchnology. He hopes to have a job related to cybersecurity, or some sort of technical support.
Allyson Hall - Allyson Hall acted as the project mentor and guided us through the development process. She is a sophomore at the University of Pittsburgh at Greensburg, a Scientific Journalism major, and hopes to obtain a career in Technical Writing.


WebSerialEsptool
Overview
This is an esptool implementation using the Web Serial API of the Chrome browser.
Example
Erase Flash
Erase.html
Uploading and writing files from PC
UploadWrite.html
Example2(Binary file embedding)
Uploading and Base64
UploadToBase64.html
M5GFX-AnalogMeter
Example-M5GFX-AnalogMeter.html
GitHub Original source file
M5GFX-GameOfLife
Example-M5GFX-GameOfLife.html
GitHub Original source file
M5Lite-I2CScan
Example-M5Lite-I2CScan.html
GitHub Original source file


title = "ParishAdministration" url = "/parish_administration" layout = "base_administration" is_hidden = 0 ==


Open Letter to Madam Secretary Hillary Clinton and DNC Chairwoman Schultz
Dear Madam Secretary Hillary Clinton and DNC Chairwoman Schultz,
We, the undersigned, write to express our dismay that Secretary Clinton's campaign solicited and accepted financial contributions from money bundlers representing the private prison industry. Accepting these tainted contributions from an industry whose business model relies on the brutal mass incarceration of Black and Brown bodies is a direct affront to the health, fortune, and very lives of the Democratic Party's many African-American, Latino, and Asian voters.
On behalf of our organizations' millions of members — representing some of the Democratic Party's most important constituencies — we call upon Secretary Clinton and the Democratic National Committee to disavow the private prison industry and publicly reject all money contributed by the private prison industry this cycle, and going forward.
Private prison companies like the GEO Group, the Corrections Corporation of America, and others make billions of dollars from our broken and discriminatory criminal justice system by disproportionately locking up African-Americans and Latinos for profit. As both policymakers and the public seek alternatives to incarceration, the private prison lobby has deliberately and insidiously leveraged its growing political clout to introduce or support policies that create artificial demand for prison beds. This leads to over-policing, disproportionate enforcement in communities of color, immigrant and poor communities; and ultimately, to needless and unjust imprisonment.
The numbers bear out this troubling reality. The percentage of immigrants held in private facilities, particularly those owned by CCA and the GEO Group — the two largest for-profit prison companies — rose from 49% in 2009 to 62% today. And at the state and municipal level, a study at UC-Berkeley has found that private prisons are packed with young people of color who are at greater risk of suffering violence inside of prison than out, and are provided inadequate education and rehabilitation opportunities.
While it has been encouraging to hear some of Secretary Clinton's perspectives on criminal justice reform in recent months, her words cannot be taken seriously while her actions are so far out of step with her pronouncements. She cannot critique mass incarceration on the one hand, while graciously accepting the money from the machinery of mass incarceration with the other.
We call on the Democratic Party and all of its officials and candidates to come into alignment with its values, and with the values of many of its constituents, by rejecting for-profit incarceration, disavowing the private prison industry, and to clearly oppose the use of private prisons in your policy platforms.
We welcome the opportunity to discuss this with you further.
Sincerely,
{% include clients.html %}


[CHAPTER 137]
SEARCH AND RESCUE REIMBURSEMENT ACT
Section
137-1 Definitions
137-2 Reimbursement
137-3 Action
Cross References
Enhanced 911 services, see chapter 138.


Work Day Scheduler
A Simple Calendar for Scheduling Your Workday
Date:
Time:
9 AM
10 AM
11 AM
12 PM
1 PM
2 PM
3 PM
4 PM
5 PM


Converts string literal to multiline concatenation expression with breaks on '\n' and '\n\r' symbols.


Section 1.1 Geology as Science
Geology is a systematic study Earth materials and processes that shape the planet. This includes exploring:
the structure and composition of Earth materials,
the physical processes and forces shaping the Earth's surface, and
the formation and history of the Earth system
Broadly speaking, geology is often divided into major categories: physical geology, which examines Earth materials and seeks to understand the many processes that operate on our planet, and historical geology, which seeks an understanding of the origin of the Earth and its development though time. The science of geology (and scientific inquiry in general) assumes that the world is comprehensible (that is, humans can perceive and make some sense of the world around us) and consistent (that is, although given freedom, it operates with regularity according to natural laws).
Principles of Geology
Since the rise of science, there have been two basic philosophic principles describing how geologic forces have shaped the Earth:
catastrophism is the belief that the landscape has been shaped primarily by great catastrophes. This was the prevailing view until the early 1800s.
uniformitarianism is the belief that the landscape has been shaped by everyday processes acting over vast periods of time (this view is often summarized as "the present is key to the past"). This approach was first proposed by Hutton (1795) and popularized by Lyell (1830).
It should be noted, however, that these represent end-member perspectives and that the modern Earth and planetary sciences recognize the role of both catastrophic and uniform events operating in geologic systems.
We can also introduce a set of geologic principles that are used to interpret a given landscape:
principle of original horizontality: sedimentary layers are originally deposited in horizontal layers.
principle of lateral continuity: sedimentary layers originally extend laterally in all directions; rocks that are separated may have been originally comprised the same layer.
principle of superposition: in stratigraphic sequence of rock layers, the oldest rock layer is at the bottom of the sequence and the youngest is at the top of the sequence.
principle of cross-cutting: the geologic feature that cuts or crosses another is the younger of the two features.


New F1 regulation coming into force for the 2020 season
by Matt GrettonFormula 1 is going to be hit with a rule and regulation overhaul for the 2021 season. However, there's a small change coming the drivers' way for the 2020 F1 season. The FIA are going to ensure fire-resistant clothing meets stricter requirements.
If a fire should occur and a driver ends up in a sea of flames, the clothing must offer optimum protection for at least twelve seconds. This includes the overall, as well as the gloves, the underwear, the gloves and the shoes of a driver.
The new requirements also come with an advantage for the drivers: research and development of a new material has finally been completed so that drivers can finally use a new substance after waiting for 20 years. Not only is that material stronger and more fire-resistant, but it is also considerably lighter.
In 2018, Formula E driver Lucas Di Grassi was fined 10,000 Euros and three penalty points for not wearing the correct fire-resistant underwear during an event.


Welcome to Camprec
Admin
Students Options
Approve Student
Delete Student
Premium Approval
Company Options
Approve Company
Delete Company
Institute Options:
Approve Institute
Delete Institute


|
Embedded Artistry Framework
Embedded Systems C++ Framework
|
Safer types for working with special-function registers. More...
Classes | |
| struct | embutil::rw |
| Register access permissions. More... | |
| struct | embutil::ro |
| Read-only access permission tag. More... | |
| struct | embutil::wo |
| Write-only access permission tag. More... | |
| class | embutil::sfr< TPerm, T, TAddr, StaticAddress > |
| class | embutil::sfr< TPerm, T, TAddr, typename std::enable_if< TAddr==0 >::type > |
| SFR Class which supports address assignment with a constructor. More... | |
| class | embutil::sfr< TPerm, T, TAddr, typename std::enable_if_t< TAddr !=0, void > > |
| This variant of the SFR class is used when the address is known at compile-time. More... | |
Safer types for working with special-function registers.
| struct embutil::rw |
Register access permissions.
Read-write access permission tag.
| struct embutil::ro |
Read-only access permission tag.
| struct embutil::wo |
Write-only access permission tag.
| class embutil::sfr |
| TPerm | Tag value indicating the permissions to use for this register. Should be rw, rw, or wo. |
| T | The type corresponding to the SFR representation (i.e., uint32_t on 32-bit systems). |
| TAddr | The address of the SFR. If the address is 0, it can be assigned during object constrution. Otherwise, the address of TAddr is locked in at compile-time. |
| StaticAddress | SFINAE-enabling parameter. You don't need to use this. |
| class embutil::sfr< TPerm, T, TAddr, typename std::enable_if< TAddr==0 >::type > |
SFR Class which supports address assignment with a constructor.
This variant of the SFR class assigns the register value when the object is created. With an optmizer, this will often result in the same as the static-definition variant.
Public Types | |
| using | ptr_t = volatile T * |
| using | const_ptr_t = volatile const T * |
| using | ref_t = volatile T & |
| using | const_ref_t = volatile const T & |
Public Member Functions | |
| sfr (uintptr_t address) noexcept | |
| Construct an SFR with an address. More... | |
| sfr (uintptr_t address, T value) noexcept | |
| Construct an SFR with an address and value. More... | |
| sfr (T *address) noexcept | |
| Construct an SFR with a pointer. More... | |
| sfr (T *address, T value) noexcept | |
| Construct an SFR with a pointer and value. More... | |
| sfr (const sfr &)=delete | |
| Delete the copy constructor. More... | |
| const sfr & | operator= (const sfr &)=delete |
| Delete the copy assignment operator. More... | |
| sfr (sfr &&)=default | |
| sfr & | operator= (sfr &&)=default |
| ~sfr ()=default | |
| Default destructor. More... | |
| constexpr uintptr_t | address () const noexcept |
| Get the address of this SFR. More... | |
| T | load () const noexcept |
| Read from register, explicit operation. More... | |
| operator T () const noexcept | |
| Read from register, read-only dereference. More... | |
| operator T () noexcept | |
| Read from register. More... | |
| void | store (T value) noexcept |
| Write to the register. More... | |
| sfr & | operator= (T value_) noexcept |
| Write via copy/assignment. More... | |
| ref_t | operator * () noexcept |
| Read/write dereference. More... | |
| const_ref_t | operator * () const noexcept |
| Read-only dereference. More... | |
| sfr & | operator++ () noexcept |
| Increment operator is a no-op, but is used for iterator compatibility. More... | |
| sfr | operator++ (int) noexcept |
| Increment operator is a no-op, but is used for iterator compatibility. More... | |
Protected Attributes | |
| const uintptr_t | addr_ |
| The address of the SFR. More... | |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if< TAddr==0 >::type >::const_ptr_t = volatile const T* |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if< TAddr==0 >::type >::const_ref_t = volatile const T& |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if< TAddr==0 >::type >::ptr_t = volatile T* |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if< TAddr==0 >::type >::ref_t = volatile T& |
|
inlineexplicitnoexcept |
Construct an SFR with an address.
| [in] | address | The address in memory that this SFR points to. |
|
inlineexplicitnoexcept |
Construct an SFR with an address and value.
| [in] | address | The address in memory that this SFR points to. |
| [in] | value | The initial value to set. |
|
inlineexplicitnoexcept |
Construct an SFR with a pointer.
| [in] | address | The pointer that this SFR points to. |
|
inlineexplicitnoexcept |
Construct an SFR with a pointer and value.
| [in] | address | The pointer that this SFR points to. |
| [in] | value | The initial value to set. |
|
delete |
Delete the copy constructor.
|
default |
|
default |
Default destructor.
|
inlinenoexcept |
Get the address of this SFR.
|
inlinenoexcept |
Read from register, explicit operation.
|
inlinenoexcept |
Read/write dereference.
|
inlinenoexcept |
Read-only dereference.
|
inlinenoexcept |
Read from register, read-only dereference.
|
inlinenoexcept |
Read from register.
|
inlinenoexcept |
Increment operator is a no-op, but is used for iterator compatibility.
|
inlinenoexcept |
Increment operator is a no-op, but is used for iterator compatibility.
|
delete |
Delete the copy assignment operator.
|
default |
|
inlinenoexcept |
Write via copy/assignment.
| [in] | value_ | The value to write to the SFR. |
|
inlinenoexcept |
Write to the register.
| [in] | value | The value to write to the SFR. |
|
protected |
The address of the SFR.
| class embutil::sfr< TPerm, T, TAddr, typename std::enable_if_t< TAddr !=0, void > > |
This variant of the SFR class is used when the address is known at compile-time.
Public Types | |
| using | ptr_t = volatile T * |
| using | const_ptr_t = volatile const T * |
| using | ref_t = volatile T & |
| using | const_ref_t = volatile const T & |
Public Member Functions | |
| sfr ()=default | |
| Default constructor. More... | |
| sfr (T value) noexcept | |
| Construct an SFR and set a value. More... | |
| ~sfr ()=default | |
| Default destructor. More... | |
| sfr (const sfr &)=delete | |
| Delete the copy constructor. More... | |
| const sfr & | operator= (const sfr &)=delete |
| Delete the copy assignment operator. More... | |
| sfr (sfr &&)=default | |
| sfr & | operator= (sfr &&)=default |
| constexpr uintptr_t | address () const noexcept |
| Get the address of this SFR. More... | |
| T | load () const noexcept |
| Read from register, explicit operation. More... | |
| operator T () const noexcept | |
| Read from register, read-only dereference. More... | |
| operator T () noexcept | |
| Read from register. More... | |
| void | store (T value) noexcept |
| Write to the register. More... | |
| sfr & | operator= (T value_) noexcept |
| Write via copy/assignment. More... | |
| ref_t | operator * () noexcept |
| Read/write dereference. More... | |
| const_ref_t | operator * () const noexcept |
| Read-only dereference. More... | |
| sfr & | operator++ () noexcept |
| Increment operator is a no-op, but is used for iterator compatibility. More... | |
| sfr | operator++ (int) noexcept |
| Increment operator is a no-op, but is used for iterator compatibility. More... | |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if_t< TAddr !=0, void > >::const_ptr_t = volatile const T* |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if_t< TAddr !=0, void > >::const_ref_t = volatile const T& |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if_t< TAddr !=0, void > >::ptr_t = volatile T* |
| using embutil::sfr< TPerm, T, TAddr, typename std::enable_if_t< TAddr !=0, void > >::ref_t = volatile T& |
|
default |
Default constructor.
|
inlineexplicitnoexcept |
Construct an SFR and set a value.
| [in] | value | The initial value to set. |
|
default |
Default destructor.
|
delete |
Delete the copy constructor.
|
default |
|
inlinenoexcept |
Get the address of this SFR.
|
inlinenoexcept |
Read from register, explicit operation.
|
inlinenoexcept |
Read/write dereference.
|
inlinenoexcept |
Read-only dereference.
|
inlinenoexcept |
Read from register, read-only dereference.
|
inlinenoexcept |
Read from register.
|
inlinenoexcept |
Increment operator is a no-op, but is used for iterator compatibility.
|
inlinenoexcept |
Increment operator is a no-op, but is used for iterator compatibility.
|
delete |
Delete the copy assignment operator.
|
default |
|
inlinenoexcept |
Write via copy/assignment.
| [in] | value_ | The value to write to the SFR. |
|
inlinenoexcept |
Write to the register.
| [in] | value | The value to write to the SFR. |


drag-tracker
demo
Simple HTML element dragging
Can't touch this
Drag me!
Drag me!
Draw on canvas
SVG dragging bound (sort of) to Vue.js state
Add node
Add line
Size of selected node:
_svgState = {{ svg | prettyCompact }}