Gecode::Int::Extensional::TinyBitSet< _size > Class Template Reference
Tiny bit-set. More...
#include <extensional.hh>
Public Member Functions | |
| TinyBitSet (Space &home, unsigned int n) | |
| Initialize sparse bit set for a number of words n. | |
| template<unsigned int largersize> | |
| TinyBitSet (Space &home, const TinyBitSet< largersize > &tbs) | |
| Initialize during cloning. | |
| template<class IndexType > | |
| TinyBitSet (Space &home, const BitSet< IndexType > &bs) | |
| Initialize during cloning. | |
| int | limit (void) const |
| Get the limit. | |
| bool | empty (void) const |
| Check whether the set is empty. | |
| void | flush (void) |
| Make the set empty. | |
| unsigned int | width (void) const |
| Return the highest active index. | |
| void | clear_mask (BitSetData *mask) |
| Clear the first limit words in mask. | |
| void | add_to_mask (const BitSetData *b, BitSetData *mask) const |
| Add to mask. | |
| template<bool sparse> | |
| void | intersect_with_mask (const BitSetData *mask) |
| Intersect with mask, sparse mask if sparse is true. | |
| void | intersect_with_masks (const BitSetData *a, const BitSetData *b) |
| Intersect with the "or" of and b. | |
| bool | intersects (const BitSetData *b) |
| Check if has a non-empty intersection with the set. | |
| void | nand_with_mask (const BitSetData *b) |
| Perform "nand" with b. | |
| void | nand_with_masks (const BitSetData *a, const BitSetData *b) |
| Perform "nand" with and the "or" of a and b. | |
| unsigned long long int | ones (void) const |
| Return the number of ones. | |
| unsigned long long int | ones (const BitSetData *b) const |
| Return the number of ones after intersection with b. | |
| unsigned long long int | bits (void) const |
| Return an upper bound on the number of bits. | |
| unsigned int | words (void) const |
| Return the number of required bit set words. | |
| unsigned int | size (void) const |
| Return the total number of words. | |
Protected Attributes | |
| BitSetData | _bits [_size] |
| Words. |
Detailed Description
template<unsigned int _size>
class Gecode::Int::Extensional::TinyBitSet< _size >
Tiny bit-set.
Definition at line 302 of file extensional.hh.
Constructor & Destructor Documentation
| Gecode::Int::Extensional::TinyBitSet< sz >::TinyBitSet | ( | Space & | home, | |
| unsigned int | n | |||
| ) | [inline] |
Initialize sparse bit set for a number of words n.
Set the active bits
Clear unused suffix bits
Definition at line 46 of file tiny-bit-set.hpp.
| Gecode::Int::Extensional::TinyBitSet< sz >::TinyBitSet | ( | Space & | home, | |
| const TinyBitSet< largersz > & | tbs | |||
| ) | [inline] |
Initialize during cloning.
Definition at line 59 of file tiny-bit-set.hpp.
| Gecode::Int::Extensional::TinyBitSet< sz >::TinyBitSet | ( | Space & | home, | |
| const BitSet< IndexType > & | bs | |||
| ) | [inline] |
Initialize during cloning.
Definition at line 70 of file tiny-bit-set.hpp.
Member Function Documentation
| int Gecode::Int::Extensional::TinyBitSet< _size >::limit | ( | void | ) | const |
Get the limit.
| bool Gecode::Int::Extensional::TinyBitSet< sz >::empty | ( | void | ) | const [inline] |
Check whether the set is empty.
Definition at line 164 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< sz >::flush | ( | void | ) | [inline] |
Make the set empty.
Definition at line 121 of file tiny-bit-set.hpp.
| unsigned int Gecode::Int::Extensional::TinyBitSet< sz >::width | ( | void | ) | const [inline] |
Return the highest active index.
Find the index of the last non-zero word
Definition at line 173 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< sz >::clear_mask | ( | BitSetData * | mask | ) | [inline] |
Clear the first limit words in mask.
Definition at line 82 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< sz >::add_to_mask | ( | const BitSetData * | b, | |
| BitSetData * | mask | |||
| ) | const [inline] |
Add to mask.
Definition at line 91 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< sz >::intersect_with_mask | ( | const BitSetData * | mask | ) | [inline] |
Intersect with mask, sparse mask if sparse is true.
Definition at line 99 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< sz >::intersect_with_masks | ( | const BitSetData * | a, | |
| const BitSetData * | b | |||
| ) | [inline] |
Intersect with the "or" of and b.
Definition at line 106 of file tiny-bit-set.hpp.
| bool Gecode::Int::Extensional::TinyBitSet< sz >::intersects | ( | const BitSetData * | b | ) | [inline] |
Check if has a non-empty intersection with the set.
Definition at line 129 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< sz >::nand_with_mask | ( | const BitSetData * | b | ) | [inline] |
Perform "nand" with b.
Definition at line 114 of file tiny-bit-set.hpp.
| void Gecode::Int::Extensional::TinyBitSet< _size >::nand_with_masks | ( | const BitSetData * | a, | |
| const BitSetData * | b | |||
| ) |
Perform "nand" with and the "or" of a and b.
| unsigned long long int Gecode::Int::Extensional::TinyBitSet< sz >::ones | ( | void | ) | const [inline] |
Return the number of ones.
Definition at line 148 of file tiny-bit-set.hpp.
| unsigned long long int Gecode::Int::Extensional::TinyBitSet< sz >::ones | ( | const BitSetData * | b | ) | const [inline] |
Return the number of ones after intersection with b.
Definition at line 138 of file tiny-bit-set.hpp.
| unsigned long long int Gecode::Int::Extensional::TinyBitSet< sz >::bits | ( | void | ) | const [inline] |
Return an upper bound on the number of bits.
Definition at line 157 of file tiny-bit-set.hpp.
| unsigned int Gecode::Int::Extensional::TinyBitSet< sz >::words | ( | void | ) | const [inline] |
Return the number of required bit set words.
Definition at line 185 of file tiny-bit-set.hpp.
| unsigned int Gecode::Int::Extensional::TinyBitSet< sz >::size | ( | void | ) | const [inline] |
Return the total number of words.
Definition at line 191 of file tiny-bit-set.hpp.
Member Data Documentation
BitSetData Gecode::Int::Extensional::TinyBitSet< _size >::_bits[_size] [protected] |
Words.
Definition at line 306 of file extensional.hh.
The documentation for this class was generated from the following files:
- gecode/int/extensional.hh
- gecode/int/extensional/tiny-bit-set.hpp


Client type: nano light
Status: Loading Nimiq.
Account address: loading
Balance: loading
Current block height: loading
Current number of peers: loading


{% extends 'student/base-student.html' %}
{% block body %}
Student Manage
Which one you want to do?
Student History
{% for student in all_student %}
{% if student.StudentID == user.username %}
{% for register in student.register_set.all %}
{% if register.Semester == student.CurrentSemester and register.PaymentStatus == 'N' %}


certmonger
Section: User Commands (1)Updated: 3 November 2009
Index Return to Main Contents
NAME
getcertSYNOPSIS
getcert resubmit [options]DESCRIPTION
Tells certmonger to generate (or regenerate) a signing request and submit (or resubmit) the signing request to a CA for signing.SPECIFYING REQUESTS BY NICKNAME
- -i NAME
-
Resubmit a signing request for the tracking request which has this nickname.
If this option is not specified, and a tracking entry which matches the key
and certificate storage options which are specified already exists, that entry
will be used. If not specified, the location of the certificate should be
specified with either a combination of the -d and -n options, or
with the -f option.
SPECIFYING REQUESTS BY CERTIFICATE LOCATION
- -d DIR
- The certificate is in the NSS database in the specified directory.
- -n NAME
- The certificate in the NSS database named with -d has the specified nickname. Only valid with -d.
- -t TOKEN
- If the NSS database has more than one token available, the certificate is stored in this token. This argument only rarely needs to be specified. Only valid with -d.
- -f FILE
-
The certificate is stored in the named file.
ENROLLMENT OPTIONS
- -c NAME
- Submit the new signing request to the specified CA rather than the one which was previously associated with this certificate. The name of the CA should correspond to one listed by getcert list-cas.
- -I NAME
-
Assign the specified nickname to this task, replacing the previous nickname.
SIGNING REQUEST OPTIONS
- -N NAME
- Change the subject name to include in the signing request.
- -U EKU
- Change the extendedKeyUsage value specified in an extendedKeyUsage extension part of the extensionRequest attribute in the signing request. The EKU value is expected to be an object identifier (OID).
- -K NAME
- Change the Kerberos principal name specified as part of a subjectAltName extension part of the extensionRequest attribute in the signing request.
- -E EMAIL
- Change the email address specified as part of a subjectAltName extension part of the extensionRequest attribute in the signing request.
- -D DNSNAME
-
Change the DNS name specified as part of a subjectAltName extension part of the
extensionRequest attribute in the signing request.
OTHER OPTIONS
- -C command
- When ever the certificate is saved to the specified location, run the specified command as the client user.
- -v
-
Be verbose about errors. Normally, the details of an error received from
the daemon will be suppressed if the client can make a diagnostic suggestion.
BUGS
Please file tickets for any that you find at https://fedorahosted.org/certmonger/SEE ALSO
certmonger(8) getcert(1) getcert-list(1) getcert-list-cas(1) getcert-request(1) getcert-start-tracking(1) getcert-stop-tracking(1) certmonger-certmaster-submit(8) certmonger-ipa-submit(8)
Index
- NAME
- SYNOPSIS
- DESCRIPTION
- SPECIFYING REQUESTS BY NICKNAME
- SPECIFYING REQUESTS BY CERTIFICATE LOCATION
- ENROLLMENT OPTIONS
- SIGNING REQUEST OPTIONS
- OTHER OPTIONS
- BUGS
- SEE ALSO
This document was created by man2html, using the manual pages.
Time: 05:29:03 GMT, December 24, 2015


{% extends "!page.html" %} {% block body %} {% if current_version and latest_version and current_version != latest_version %}
Caution
{% if current_version.is_released %} {% if latest_version.release.replace('v', '').split('.') | map('int') | list > current_version.name.replace('v', '').split('.') | map('int') | list %} You're reading an old version of this documentation. If you want up-to-date information, please have a look at {{latest_version.name}}. {% endif %} {% else %} You're reading the documentation for a development version. For the latest released version, please have a look at {{latest_version.name}}. {% endif %}


Language
English
Nederlands
Francais
Your browser does not support HTML5 video.
Previous
Next
Gallery


Here is some text containing a footnote.[1]
And here is a footnote within a blockquote, should be labelled #2.[2]
And this is a codeblock, that should not be a footnote:
This is code.[^somesamplefootnote]
And this is a short footnote for testing.[3]
And now, reuse a footnote.[3]
Repeat previous footnote marker:
This is an inline footnote.[4]
This is a footnote with 2 paragraphs.[5]
Here is some text containing a more complicated inline footnote.[6]


-
What is {{sitename}}?
{{sitename}} is an imageboard, a type of Internet forum that revolves around the posting of images, often alongside related text and discussion. Unlike traditional forums and social media, imageboards do not require user registration, and users are anonymous by default.
-
How do I use {{sitename}}?
To get started, simply click the 'Topics' button in the top left corner and browse the available topics of discussion. If the website owner has allowed it, users can create their own topics as well using the 'Create Topic' button. Topics marked "SFW", or safe-for-work, are intended to not allow adult content. Conversely, topics marked "NSFW", or not-safe-for-work, may contain material that is, well... not safe to browse at work. Or school. Or at all, if you're under the age of 18.
-
How do I use spoilers and other formatting marks?
You can include formatting marks in your posts in order to change how they look. In order to create a spoiler effect, you use the spoiler tag [spoiler]spoilered text[/spoiler] or **spoilered text**. example -> spoilered text. Other tags you can include in square brackets to format the text are [red]red text[/red] or ==red text== for red text and [quote]green text quoting[/quote] or >green text quoting for
green text quoting
In order to keep everyone's posts nice and neat, if you use a formatting mark without closing it, your post may not display correctly.


The StAX API exposes methods for iterative, event-based processing of XML documents. XML documents are treated as a filtered series of events, and infoset states can be stored in a procedural fashion. Moreover, unlike SAX, the StAX API is bidirectional, enabling both reading and writing of XML documents.
The StAX API is really two distinct API sets: a cursor API and an iterator API. These two API sets are explained in greater detail later in this lesson, but their main features are briefly described below.
As the name implies, the StAX cursor API represents a cursor with which you can walk an XML document from beginning to end. This cursor can point to one thing at a time, and always moves forward, never backward, usually one infoset element at a time.
The two main cursor interfaces are XMLStreamReader and XMLStreamWriter. XMLStreamReader includes accessor methods for all possible information retrievable from the XML Information model, including document encoding, element names, attributes, namespaces, text nodes, start tags, comments, processing instructions, document boundaries, and so forth; for example:
public interface XMLStreamReader { public int next() throws XMLStreamException; public boolean hasNext() throws XMLStreamException; public String getText(); public String getLocalName(); public String getNamespaceURI(); // ... other methods not shown }
You can call methods on XMLStreamReader, such as getText and getName, to get data at the current cursor location. XMLStreamWriter provides methods that correspond to StartElement and EndElement event types; for example:
public interface XMLStreamWriter { public void writeStartElement(String localName) throws XMLStreamException; public void writeEndElement() throws XMLStreamException; public void writeCharacters(String text) throws XMLStreamException; // ... other methods not shown }
The cursor API mirrors SAX in many ways. For example, methods are available for directly accessing string and character information, and integer indexes can be used to access attribute and namespace information. As with SAX, the cursor API methods return XML information as strings, which minimizes object allocation requirements.
The StAX iterator API represents an XML document stream as a set of discrete event objects. These events are pulled by the application and provided by the parser in the order in which they are read in the source XML document.
The base iterator interface is called XMLEvent, and there are subinterfaces for each event type listed in Table 5-2. The primary parser interface for reading iterator events is XMLEventReader, and the primary interface for writing iterator events is XMLEventWriter. The XMLEventReader interface contains five methods, the most important of which is nextEvent, which returns the next event in an XML stream. XMLEventReader implements java.util.Iterator, which means that returns from XMLEventReader can be cached or passed into routines that can work with the standard Java Iterator; for example:
public interface XMLEventReader extends Iterator { public XMLEvent nextEvent() throws XMLStreamException; public boolean hasNext(); public XMLEvent peek() throws XMLStreamException; ... }
Similarly, on the output side of the iterator API, you have:
public interface XMLEventWriter { public void flush() throws XMLStreamException; public void close() throws XMLStreamException; public void add(XMLEvent e) throws XMLStreamException; public void add(Attribute attribute) throws XMLStreamException; ... }
Table 5-2 lists the XMLEvent types defined in the event iterator API.
Event Type |
Description |
|---|---|
StartDocument |
Reports the beginning of a set of XML events, including encoding, XML version, and standalone properties. |
StartElement |
Reports the start of an element, including any attributes and namespace declarations; also provides access to the prefix, namespace URI, and local name of the start tag. |
EndElement |
Reports the end tag of an element. Namespaces that have gone out of scope can be recalled here if they have been explicitly set on their corresponding StartElement. |
Characters |
Corresponds to XML CData sections and CharacterData entities. Note that ignorable white space and significant white space are also reported as Character events. |
EntityReference |
Character entities can be reported as discrete events, which an application developer can then choose to resolve or pass through unresolved. By default, entities are resolved. Alternatively, if you do not want to report the entity as an event, replacement text can be substituted and reported as Characters. |
ProcessingInstruction |
Reports the target and data for an underlying processing instruction. |
Comment |
Returns the text of a comment. |
EndDocument |
Reports the end of a set of XML events. |
DTD |
Reports as java.lang.String information about the DTD, if any, associated with the stream, and provides a method for returning custom objects found in the DTD. |
Attribute |
Attributes are generally reported as part of a StartElement event. However, there are times when it is desirable to return an attribute as a standalone Attribute event; for example, when a namespace is returned as the result of an XQuery or XPath expression. |
Namespace |
As with attributes, namespaces are usually reported as part of a StartElement, but there are times when it is desirable to report a namespace as a discrete Namespace event. |
Note that the DTD, EntityDeclaration, EntityReference, NotationDeclaration, and ProcessingInstruction events are only created if the document being processed contains a DTD.
As an example of how the event iterator API maps an XML stream, consider the following XML document:
<?xml version="1.0"?> <BookCatalogue xmlns="http://www.publishing.org"> <Book> <Title>Yogasana Vijnana: the Science of Yoga</Title> <ISBN>81-40-34319-4</ISBN> <Cost currency="INR">11.50</Cost> </Book> </BookCatalogue>
This document would be parsed into eighteen primary and secondary events, as shown in Table 5-3. Note that secondary events, shown in curly braces ({}), are typically accessed from a primary event rather than directly.
# |
Element/Attribute |
Event |
|---|---|---|
1 |
version="1.0" |
StartDocument |
2 |
isCData = false
data = "\n"
IsWhiteSpace = true |
Characters |
3 |
qname = BookCatalogue:http://www.publishing.org
attributes = null
namespaces = {BookCatalogue" -> http://www.publishing.org"} |
StartElement |
4 |
qname = Book
attributes = null
namespaces = null |
StartElement |
5 |
qname = Title
attributes = null
namespaces = null |
StartElement |
6 |
isCData = false
data = "Yogasana Vijnana: the Science of Yoga\n\t"
IsWhiteSpace = false |
Characters |
7 |
qname = Title
namespaces = null |
EndElement |
8 |
qname = ISBN
attributes = null
namespaces = null |
StartElement |
9 |
isCData = false
data = "81-40-34319-4\n\t"
IsWhiteSpace = false |
Characters |
10 |
qname = ISBN
namespaces = null |
EndElement |
11 |
qname = Cost
attributes = {"currency" -> INR}
namespaces = null |
StartElement |
12 |
isCData = false
data = "11.50\n\t"
IsWhiteSpace = false |
Characters |
13 |
qname = Cost
namespaces = null |
EndElement |
14 |
isCData = false
data = "\n"
IsWhiteSpace = true |
Characters |
15 |
qname = Book
namespaces = null |
EndElement |
16 |
isCData = false
data = "\n"
IsWhiteSpace = true |
Characters |
17 |
qname = BookCatalogue:http://www.publishing.org
namespaces = {BookCatalogue" -> http://www.publishing.org"} |
EndElement |
18 |
EndDocument |
There are several important things to note in this example:
The events are created in the order in which the corresponding XML elements are encountered in the document, including nesting of elements, opening and closing of elements, attribute order, document start and document end, and so forth.
As with proper XML syntax, all container elements have corresponding start and end events; for example, every StartElement has a corresponding EndElement, even for empty elements.
Attribute events are treated as secondary events, and are accessed from their corresponding StartElement event.
Similar to Attribute events, Namespace events are treated as secondary, but appear twice and are accessible twice in the event stream, first from their corresponding StartElement and then from their corresponding EndElement.
Character events are specified for all elements, even if those elements have no character data. Similarly, Character events can be split across events.
The StAX parser maintains a namespace stack, which holds information about all XML namespaces defined for the current element and its ancestors. The namespace stack, which is exposed through the javax.xml.namespace.NamespaceContext interface, can be accessed by namespace prefix or URI.
It is reasonable to ask at this point, “What API should I choose? Should I create instances of XMLStreamReader or XMLEventReader? Why are there two kinds of APIs anyway?”
The authors of the StAX specification targeted three types of developers:
Library and infrastructure developers: Create application servers, JAXM, JAXB, JAX-RPC and similar implementations; need highly efficient, low-level APIs with minimal extensibility requirements.
Java ME developers: Need small, simple, pull-parsing libraries, and have minimal extensibility needs.
Java Platform, Enterprise Edition (Java EE) and Java Platform, Standard Edition (Java SE) developers: Need clean, efficient pull-parsing libraries, plus need the flexibility to both read and write XML streams, create new event types, and extend XML document elements and attributes.
Given these wide-ranging development categories, the StAX authors felt it was more useful to define two small, efficient APIs rather than overloading one larger and necessarily more complex API.
Before choosing between the cursor and iterator APIs, you should note a few things that you can do with the iterator API that you cannot do with the cursor API:
Objects created from the XMLEvent subclasses are immutable, and can be used in arrays, lists, and maps, and can be passed through your applications even after the parser has moved on to subsequent events.
You can create subtypes of XMLEvent that are either completely new information items or extensions of existing items but with additional methods.
You can add and remove events from an XML event stream in much simpler ways than with the cursor API.
Similarly, keep some general recommendations in mind when making your choice:
If you are programming for a particularly memory-constrained environment, like Java ME, you can make smaller, more efficient code with the cursor API.
If performance is your highest priority—for example, when creating low-level libraries or infrastructure—the cursor API is more efficient.
If you want to create XML processing pipelines, use the iterator API.
If you want to modify the event stream, use the iterator API.
If you want your application to be able to handle pluggable processing of the event stream, use the iterator API.
In general, if you do not have a strong preference one way or the other, using the iterator API is recommended because it is more flexible and extensible, thereby “future-proofing” your applications.


Machine operator
Fretting machine operator
Job description
Operating and running one of the fretting machines according to schedule.
References
machine safety
,
fretting machine manual
,
schedule
,
Factory


In geometry, an equilateral triangle is a triangle in which all three sides are equal. In the familiar Euclidean geometry, equilateral triangles are also equiangular; that is, all three internal angles are also congruent to each other and are each 60°. They are regular polygons, and can therefore also be referred to as regular triangles.
In geometry, an isosceles triangle is a triangle that has two sides of equal length. Sometimes it is specified as having two and only two sides of equal length, and sometimes as having at least two sides of equal length, the latter version thus including the equilateral triangle as a special case. By the isosceles triangle theorem, the two angles opposite the equal sides are themselves equal, while if the third side is different then the third angle is different. By the Steiner–Lehmus theorem, every triangle with two angle bisectors of equal length is isosceles.
Scalene triangles are triangles where each side is a different length. They are unusual in that the are defined by what they are not. Most triangles drawn at random would be scalene. The interior angles of a scalene triangle are always all different. The converse of this is also true - If all three angles are different, then the triangle is scalene, and all the sides are different lengths.


Toggle navigation
Steam Watcher
Home
(current)
My Statistics
My Friends
Steam
Current Status
News
Settings
Logout
Welcome Back, XXX!
Own News
...
Learn more
Friends News
...
Learn more


The filter parameters you have selected have excluded all data. Please ensure your filter criteria is accurate.


{% extends 'base.html' %} {% load static %} {% block content %}
Location: {{announcement.location}}
Description: {{announcement.description}}
Start time: {{announcement.start_time}}
End time: {{announcement.end_time}}
Wanted: {{announcement.wanted_people}}
Registered: {{announcement.registered_people}}
Price: {{announcement.price}}
Skill level: {{announcement.skill_level}}
Publication date: {{announcement.pub_date}}
Creator: {{announcement.creator}}
Creator mail: {{announcement.creator.email}}
{% if is_user_signed %} {% else %} {% endif %}


Simple Interest Calculator
Amount
Rate
10.25%
No. of Years
1
2
3
4
5
6
7
8
9
10
Interest :
Compute Interest


Source code for cbmpy.CBConfig
"""
CBMPy: CBConfig module
======================
PySCeS Constraint Based Modelling (http://cbmpy.sourceforge.net)
Copyright (C) 2009-2017 Brett G. Olivier, VU University Amsterdam, Amsterdam, The Netherlands
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>
Author: Brett G. Olivier
Contact email<EMAIL_ADDRESS>Last edit: $Author: bgoli $ ($Id: CBConfig.py 575 2017-04-13 12:18:44Z bgoli $)
"""
## gets rid of "invalid variable name" info
# pylint: disable=C0103
## gets rid of "line to long" info
# pylint: disable=C0301
## use with caution: gets rid of module xxx has no member errors (run once enabled)
# pylint: disable=E1101
# preparing for Python 3 port
from __future__ import division, print_function
from __future__ import absolute_import
#from __future__ import unicode_literals
# release
try:
STATUS = '$Rev: 575 $'.replace('Rev: ', '').replace('$', '').strip()
except Exception:
STATUS = ''
__CBCONFIG__ = {'VERSION_MAJOR' : 0,
'VERSION_MINOR' : 7,
'VERSION_MICRO' : 13,
'VERSION_STATUS' : STATUS,
'VERSION' : None,
'DEBUG' : False,
'SOLVER_PREF' : 'CPLEX',
#'SOLVER_PREF' : 'GLPK',
'SOLVER_ACTIVE' : None,
'REVERSIBLE_SYMBOL' : '<==>',
'IRREVERSIBLE_SYMBOL' : '-->',
'HAVE_SBML2' : False,
'HAVE_SBML3' : False,
'CBMPY_DIR' : None,
'CBMPY_CGLPK_VER' : 'w452',
'SYMPY_DENOM_LIMIT' : 10**32
}
[docs]def current_version():
"""
Return the current CBMPy version as a string
"""
#return '%s.%s.%s [r%s]' % (__CBCONFIG__['VERSION_MAJOR'], __CBCONFIG__['VERSION_MINOR'], __CBCONFIG__['VERSION_MICRO'], __CBCONFIG__['VERSION_STATUS'])
if STATUS == '':
return '{}.{}.{}'.format(__CBCONFIG__['VERSION_MAJOR'], __CBCONFIG__['VERSION_MINOR'], __CBCONFIG__['VERSION_MICRO'])
else:
return '{}.{}.{}.{}'.format(__CBCONFIG__['VERSION_MAJOR'], __CBCONFIG__['VERSION_MINOR'], __CBCONFIG__['VERSION_MICRO'], STATUS)
[docs]def current_version_tuple():
"""
Return the current CBMPy version as a tuple (x, y, z)
"""
return (__CBCONFIG__['VERSION_MAJOR'], __CBCONFIG__['VERSION_MINOR'], __CBCONFIG__['VERSION_MICRO'])
__CBCONFIG__['VERSION'] = current_version()


| Series | Volume | Issue | Date | Title | Publisher | Server Path |
|---|
TBD:
Better table style
Better popups
More columns?(horiz scrolling??)
Thumbnails in table??
{% set title = "ComicStreamer: Search Results" %} {% autoescape xhtml_escape %}
{% include head_links.html %}| Series | Volume | Issue | Date | Title | Publisher | Server Path |
|---|


{% load static %} {% url 'about-me' as about_me %} {% url 'projects' as projects %} {% url 'blog' as blog %}


Inspection of theory atoms occurring in ground logic programs.
During grounding, theory atoms get consecutive numbers starting with zero. The total number of theory atoms can be obtained using clingo_theory_atoms_size().
- Attention
- All structural information about theory atoms, elements, and terms is reset after solving. If afterward fresh theory atoms are grounded, previously used ids are reused.
For an example, see theory-atoms.c.
|
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_term_type (clingo_theory_atoms_t *atoms, clingo_id_t term, clingo_theory_term_type_t *type) |
| | Get the type of the given theory term. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_term_number (clingo_theory_atoms_t *atoms, clingo_id_t term, int *number) |
| | Get the number of the given numeric theory term. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_term_name (clingo_theory_atoms_t *atoms, clingo_id_t term, char const **name) |
| | Get the name of the given constant or function theory term. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_term_arguments (clingo_theory_atoms_t *atoms, clingo_id_t term, clingo_id_t const **arguments, size_t *size) |
| | Get the arguments of the given function theory term. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_term_to_string_size (clingo_theory_atoms_t *atoms, clingo_id_t term, size_t *size) |
| | Get the size of the string representation of the given theory term (including the terminating 0). More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_term_to_string (clingo_theory_atoms_t *atoms, clingo_id_t term, char *string, size_t size) |
| | Get the string representation of the given theory term. More...
|
| |
|
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_element_tuple (clingo_theory_atoms_t *atoms, clingo_id_t element, clingo_id_t const **tuple, size_t *size) |
| | Get the tuple (array of theory terms) of the given theory element. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_element_condition (clingo_theory_atoms_t *atoms, clingo_id_t element, clingo_literal_t const **condition, size_t *size) |
| | Get the condition (array of aspif literals) of the given theory element. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_element_condition_id (clingo_theory_atoms_t *atoms, clingo_id_t element, clingo_literal_t *condition) |
| | Get the id of the condition of the given theory element. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_element_to_string_size (clingo_theory_atoms_t *atoms, clingo_id_t element, size_t *size) |
| | Get the size of the string representation of the given theory element (including the terminating 0). More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_element_to_string (clingo_theory_atoms_t *atoms, clingo_id_t element, char *string, size_t size) |
| | Get the string representation of the given theory element. More...
|
| |
|
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_size (clingo_theory_atoms_t *atoms, size_t *size) |
| | Get the total number of theory atoms. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_term (clingo_theory_atoms_t *atoms, clingo_id_t atom, clingo_id_t *term) |
| | Get the theory term associated with the theory atom. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_elements (clingo_theory_atoms_t *atoms, clingo_id_t atom, clingo_id_t const **elements, size_t *size) |
| | Get the theory elements associated with the theory atom. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_has_guard (clingo_theory_atoms_t *atoms, clingo_id_t atom, bool *has_guard) |
| | Whether the theory atom has a guard. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_guard (clingo_theory_atoms_t *atoms, clingo_id_t atom, char const **connective, clingo_id_t *term) |
| | Get the guard consisting of a theory operator and a theory term of the given theory atom. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_literal (clingo_theory_atoms_t *atoms, clingo_id_t atom, clingo_literal_t *literal) |
| | Get the aspif literal associated with the given theory atom. More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_to_string_size (clingo_theory_atoms_t *atoms, clingo_id_t atom, size_t *size) |
| | Get the size of the string representation of the given theory atom (including the terminating 0). More...
|
| |
| CLINGO_VISIBILITY_DEFAULT bool | clingo_theory_atoms_atom_to_string (clingo_theory_atoms_t *atoms, clingo_id_t atom, char *string, size_t size) |
| | Get the string representation of the given theory atom. More...
|
| |
◆ clingo_theory_term_type
Enumeration of theory term types.
| Enumerator |
|---|
| clingo_theory_term_type_tuple | a tuple term, e.g., (1,2,3)
|
| clingo_theory_term_type_list | a list term, e.g., [1,2,3]
|
| clingo_theory_term_type_set | a set term, e.g., {1,2,3}
|
| clingo_theory_term_type_function | a function term, e.g., f(1,2,3)
|
| clingo_theory_term_type_number | a number term, e.g., 42
|
| clingo_theory_term_type_symbol | a symbol term, e.g., c
|
◆ clingo_theory_atoms_atom_elements()
Get the theory elements associated with the theory atom.
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the atom |
| [out] | elements | the resulting array of elements |
| [out] | size | the number of elements |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_atom_guard()
Get the guard consisting of a theory operator and a theory term of the given theory atom.
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the atom |
| [out] | connective | the resulting theory operator |
| [out] | term | the resulting term |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_atom_has_guard()
Whether the theory atom has a guard.
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the atom |
| [out] | has_guard | whether the theory atom has a guard |
- Returns
- whether the call was successful
- Examples:
- theory-atoms.c.
◆ clingo_theory_atoms_atom_literal()
Get the aspif literal associated with the given theory atom.
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the atom |
| [out] | literal | the resulting literal |
- Returns
- whether the call was successful
- Examples:
- theory-atoms.c.
◆ clingo_theory_atoms_atom_term()
Get the theory term associated with the theory atom.
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the atom |
| [out] | term | the resulting term id |
- Returns
- whether the call was successful
- Examples:
- theory-atoms.c.
◆ clingo_theory_atoms_atom_to_string()
Get the string representation of the given theory atom.
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the element |
| [out] | string | the resulting string |
| [in] | size | the size of the string |
- Returns
- whether the call was successful; might set one of the following error codes:
◆ clingo_theory_atoms_atom_to_string_size()
Get the size of the string representation of the given theory atom (including the terminating 0).
- Parameters
-
| [in] | atoms | container where the atom is stored |
| [in] | atom | id of the element |
| [out] | size | the resulting size |
- Returns
- whether the call was successful; might set one of the following error codes:
◆ clingo_theory_atoms_element_condition()
Get the condition (array of aspif literals) of the given theory element.
- Parameters
-
| [in] | atoms | container where the element is stored |
| [in] | element | id of the element |
| [out] | condition | the resulting array of aspif literals |
| [out] | size | the number of term literals |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_element_condition_id()
Get the id of the condition of the given theory element.
- Note
- This id can be mapped to a solver literal using clingo_propagate_init_solver_literal(). This id is not (necessarily) an aspif literal; to get aspif literals use clingo_theory_atoms_element_condition().
- Parameters
-
| [in] | atoms | container where the element is stored |
| [in] | element | id of the element |
| [out] | condition | the resulting condition id |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_element_to_string()
Get the string representation of the given theory element.
- Parameters
-
| [in] | atoms | container where the element is stored |
| [in] | element | id of the element |
| [out] | string | the resulting string |
| [in] | size | the size of the string |
- Returns
- whether the call was successful; might set one of the following error codes:
◆ clingo_theory_atoms_element_to_string_size()
Get the size of the string representation of the given theory element (including the terminating 0).
- Parameters
-
| [in] | atoms | container where the element is stored |
| [in] | element | id of the element |
| [out] | size | the resulting size |
- Returns
- whether the call was successful; might set one of the following error codes:
◆ clingo_theory_atoms_element_tuple()
Get the tuple (array of theory terms) of the given theory element.
- Parameters
-
| [in] | atoms | container where the element is stored |
| [in] | element | id of the element |
| [out] | tuple | the resulting array of term ids |
| [out] | size | the number of term ids |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_size()
Get the total number of theory atoms.
- Parameters
-
| [in] | atoms | the target |
| [out] | size | the resulting number |
- Returns
- whether the call was successful
- Examples:
- theory-atoms.c.
◆ clingo_theory_atoms_term_arguments()
Get the arguments of the given function theory term.
- Precondition
- The term must be of type clingo_theory_term_type_function.
- Parameters
-
| [in] | atoms | container where the term is stored |
| [in] | term | id of the term |
| [out] | arguments | the resulting arguments in form of an array of term ids |
| [out] | size | the number of arguments |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_term_name()
◆ clingo_theory_atoms_term_number()
Get the number of the given numeric theory term.
- Precondition
- The term must be of type clingo_theory_term_type_number.
- Parameters
-
| [in] | atoms | container where the term is stored |
| [in] | term | id of the term |
| [out] | number | the resulting number |
- Returns
- whether the call was successful
◆ clingo_theory_atoms_term_to_string()
Get the string representation of the given theory term.
- Parameters
-
| [in] | atoms | container where the term is stored |
| [in] | term | id of the term |
| [out] | string | the resulting string |
| [in] | size | the size of the string |
- Returns
- whether the call was successful; might set one of the following error codes:
- See also
- clingo_theory_atoms_term_to_string_size()
◆ clingo_theory_atoms_term_to_string_size()
Get the size of the string representation of the given theory term (including the terminating 0).
- Parameters
-
| [in] | atoms | container where the term is stored |
| [in] | term | id of the term |
| [out] | size | the resulting size |
- Returns
- whether the call was successful; might set one of the following error codes:
◆ clingo_theory_atoms_term_type()
Get the type of the given theory term.
- Parameters
-
| [in] | atoms | container where the term is stored |
| [in] | term | id of the term |
| [out] | type | the resulting type |
- Returns
- whether the call was successful


[svgConfig]
should contain values for both 'scene' and 'dialog'.
For screens smaller than 600px the 'dialog' svg is applied.type
property to dialog
for Illustration Message used in a Dialog or a Message
Box.type
property to spot
for Illustration Message used in medium-sized cards or UI
elements smaller than full screen.type
property to dot
for Illustration Message used in small-sized cards or UI
elements smaller than full screen.
In some cases it's not applicable to use URLs for the SVG locations.
In this case developers can load SVG directly into their js code and pass it as a string to the component.


| DOSE: |
repeated |
|
MDPV |
(powder / crystals) |
Hi there an thanks for reading. I am writing this report at the end of my experience with MDVP. This is a very very interesting drug. What I can say for certain is that it shares properties with most stims but that being said it effects everyone differently. First off I must advise this drug is stronger then my will power. Seriously it very moreish. I have consumed .06 over the last two days. when i say .06 I mean .6 of a Point [gram]. I really don't need this much for this drug, really a few flecks will do me and keep me pumping for 2+ hours. I have been dosing with tiny tiny amounts for the last 48 hours the only side effect I have found is lack of appetite, cravings, sore muscles and utter boredom. DO NOT DO THIS DRUG ALONE!
Also of note is increase heart rate (I can feel it) don't push yourself. I don't want to dance either, but I'll want to talk and talk and talk. I have some lab rats that are using ATM and effects are varied, some get horny, some don't, some can eat, some cant.
***
Important part: The 'I WANT TO SLEEP BUT CAN'T' is the worst bit, I will require 1) Booze (a shot of spirit will be good) 2) Any benzo. I will be using 5MG Xanax
***
I believe this drug to be very very addictive, please only purchase in small quantities. Once I did that first line it was very VERY hard for me not to do another and another. If i was to recommend a dose size it would be 0.005g - I know that sounds weird but it is the truth, a little bit goes a long way.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Monday, February 29, 2016: 7:00 PM
Target is committed to providing a fun and convenient shopping experience with access to unique and highly differentiated products at affordable prices. Since 1946, the corporation has given 5 percent of its income through community grants and programs.
Recruiting For: Executive Team Leader, Executive Intern
Wednesday, March 2, 2016: 7:00 PM
Our mission is to empower, engage and enable executives throughout the world. We empoer boards of directors and investor to confidently assess pay for performance plans with the industry-leading survey platform that seamlessly integrates both public and private data.
Thursday, March 3, 2016: 5:00 PM
The leader in vertical marketing and media online, consistently delivering the right leads at the right volume to thousands of industry-leading clients and business brands. The company's full-service approach combines direct marketing expertise, vast search and media reach, and industry-leading technologies to deliver dramatically improved results for clients.
Recruiting For: Online Media Associate, Strategic Marketing Analyst, Vertical Marketing Associate.
Information Sessions are a great way for students to learn about an organization and potential opportunities, as well as network at the same time. Delta Sigma Pi is providing you with the unique opportunity to connect with recruiters and get your foot in the door, setting you up for your future.


Hello World!
This is a simple “Hello World” example in how to use the swergio package. We will set up a websocket server and two clients to send messages back and forth.
Server.py
We will first create a server.py
file, which starts the websocket server to communicate via message in a separate process.
In the file we need to specify the IP and the PORT of the server as well as the message FORMAT and the HEADER_LENGTH. All of these information have to stay the same across the server and all clients.
We can then initiate the swergio server class and start the server.
import socket
from swergio import Server
# Set server PORT to 8080
PORT = 8080
# Get IP of current host
SERVER = socket.gethostbyname(socket.gethostname())
print(SERVER)
# Using utf-8 as message format
FORMAT = 'utf-8'
# Message header has a maximum length of 10
HEADER_LENGTH = 10
# Initiate the Server class
server = Server(SERVER, PORT, FORMAT, HEADER_LENGTH)
# Start the server
server.start()
World.py
We will now create a world.py
file, which will contain the logic for our world component.
It will receive messages from the universe component via the galactic_chat room and replies.
Let’s first import all necessary packages.
import uuid
import socket
from swergio import Client, Trigger, MESSAGE_TYPE
We then set the COMPONENT_NAME to world, which is use in the communication.
We also need to specify the IP and the PORT as well as the message FORMAT and the HEADER_LENGTH. All of these information have to stay the same across the server and all clients.
COMPONENT_NAME = 'world'
PORT = 8080
SERVER = socket.gethostbyname(socket.gethostname())
FORMAT = 'utf-8'
HEADER_LENGTH = 10
Now we can create the swergio Client by passing the required settings (NAME, SERVER, PORT etc. ).
client = Client(COMPONENT_NAME, SERVER,PORT,FORMAT,HEADER_LENGTH)
After instantiating the client, we can now add the event handler functions. These functions are executed when we receive a certain type of message.
We first define the function that will handle our received messages. Such a function requires the msg as first parameter, which contains the all message information as dictionary.
The reply function of our world component will just send back a message including the text “Hello Universe!”.
We now have to add a new event handler to our client object. This includes the defined function that is executed when the handler is active as well as the MESSAGE_TYPE and response ROOM of our response message. In this our response will be a DATA.TEXT type to the galactic_chat room. We also need to set the Trigger to define which incoming messages the handler needs to process. In this case we will react to messages of type DATA.TEXT in the galactic_chat room.
Once added the event handler, the client will be added to the message rooms we require.
def reply(msg):
print(msg)
id = uuid.uuid4().hex
return {"ID": id, "DATA": "Hello Universe!"}
client.add_eventHandler(reply,MESSAGE_TYPE.DATA.TEXT,responseRooms='galactic_chat',trigger=Trigger(MESSAGE_TYPE.DATA.TEXT, 'galactic_chat'))
After setting up all the required logic, we finally start our client to listen to new incoming messages.
client.listen()
Universe.py
We create a universe.py
file containing the logic for our universe component.
It will send the first “Hello World!” message and afterwards receives replies from the world component via the galactic_chat room and send its responses.
We set up the swergio client in the same way as in the world.py
file.
import uuid
import socket
from swergio import Client, Trigger, MESSAGE_TYPE
COMPONENT_NAME = 'universe'
PORT = 8080
SERVER = socket.gethostbyname(socket.gethostname())
FORMAT = 'utf-8'
HEADER_LENGTH = 10
client = Client(COMPONENT_NAME, SERVER,PORT,FORMAT,HEADER_LENGTH)
Similar to the world component we define an event handler to respond to received messages. In this case we wait until we get a message in the galactic_chat room and then send a new “Hello World!” message.
def reply(msg):
print(msg)
id = uuid.uuid4().hex
return {"ID": id, "DATA": "Hello World!"}
client.add_eventHandler(reply,MESSAGE_TYPE.DATA.TEXT,responseRooms='galactic_chat',trigger=Trigger(MESSAGE_TYPE.DATA.TEXT, 'galactic_chat'))
Since the event handlers are only reacting t incoming message, on of the components should send the first message.
We define our first “Hello World!” message by including a new message id, the message type, the room we want the message to send to as well as the message data. Our universe will then send the first message and the world can respond.
msg = {
'ID': uuid.uuid4().hex,
'TYPE': MESSAGE_TYPE.DATA.TEXT.id,
'TO_ROOM': 'galactic_chat',
'DATA': "Hello World!"}
client.send(msg)
After setting up all the required logic, we finally start our client to listen to new incoming messages.
client.listen()
Run it all!
We will run each of the three components in a separate python process. First, we will start the server:
python server.py
Then we will initiate the world component to be ready to receive and send messages:
python world.py
Finally, we will run the universe component to send the first message:
python universe.py


--- permalink: selfservice.html --- {% comment %} This page exists to redirect users from an old, outdated version of the self-service page. It should be removed at some point. {% endcomment %}
You should be redirected there shortly.


counter 41 push_switch.c static _UWORD counter[PSW_NUM_OF_TYPE] = { 0 }; counter 56 push_switch.c if (++counter[t] == PSW_BORDER) counter 59 push_switch.c counter[t] = 0; counter 369 ssrp.c static _UWORD counter = SSRP_PACKET_SPC; counter 385 ssrp.c if (counter++ & SSRP_PACKET_SPC) counter 396 ssrp.c static _UWORD counter = SSRP_PACKET_SPC; counter 427 ssrp.c if (counter++ & SSRP_PACKET_SPC)


Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
1 "REPORTABLE" IN THE SUPREME COURT OF INDIA CRIMINAL APPELLATE JURISDICTION CRIMINAL APPEAL NO. 1645 OF 2009 Dasrath ... Appellant Versus State of M.P. ... Respondent JUDGMENT
V.S. SIRPURKAR, J.
1. The present appeal is directed against the judgment of the High Court dismissing the appeal of the appellant Dasrath. He was convicted by the Trial Court of the offence under Section 304B, Indian Penal Code (IPC) and was sentenced to suffer rigorous imprisonment for 10 years and pay a fine of Rs. 5,000/- and in default directed to suffer further imprisonment for one year. He was also convicted for the offence under Section 201, IPC and was directed to suffer rigorous imprisonment for one 2 year with a fine of Rs.1,000/- and in default to suffer three month's further imprisonment.
2. Initially, as many as three accused persons came to be tried by the Sessions Judge, they being accused No.1, Kalyan, accused No.2, Dasrath and accused No.3, Smt. Usha. While accused No.2, Dasrath is the present appellant, accused No.1, Kalyan Singh and accused No.3, Smt. Usha are his father and sister, respectively. The Trial Court had also convicted Kalyan Singh for the same offence. However, it acquitted accused No.3, Smt. Usha from all the charges. Both the accused had filed an appeal challenging their conviction and the sentences before the High Court. However, during the pendency of the appeal, accused No.1 Kalyan Singh expired and his appeal, thus, abated. The appeal of Dasrath, the present appellant came to be dismissed by the High Court and that is how he is before us.
3. Shortly stated, the prosecution story was that Dasrath was married to Pinki who died under suspicious circumstance of burning. An intimation regarding death came to be given to the Police Station Pandhokhar, Distt. Gwalior. The said intimation was given by the complainant Vadehi Saran s/o Ramanand Kaurav who was none else but the father of the deceased Pinki. It was, inter alia, stated that on that day i.e. 12.8.1992 in the morning his son Jitendra Singh had gone to village Saujna for Rakhi 3 festival to his daughter Pinki's house. But he returned at about 7 p.m. and told him that Pinki had caught fire and was sent to Daboh for treatment. Vadehi Saran further stated that on hearing the news, he along with some co-villagers went to Daboh. However, one Santosh belonging to his village met him near Dugdha Dairy and told him that Pinki had died. Then Vadehi Saran along with others went to village Saujna. But by the time they reached there, Pinki's cremation was over. It was because of this that they came to the Police Station and further action was requested on the basis of the death report.
4. On this basis, a First Information Report was got registered on 16.8.92 wherein it was recorded that the death intimation was given on 12.8.92 at 23.15 hours orally about the death of Pinki. It was recorded on a preliminary inquiry made by Head Constable Jaswir Singh by visiting village Saujna and the Station House Officer R.S. Purohit had also made inquiries relating to the death. The place of occurrence was examined by SDOP R.K. Hirodia and inquiry was made from the deceased's father Vadehi Saran, uncle Uttam Singh, brothers Janved Singh and Jitendra Singh, mother Vidya Devi and sister Pratibha. During this inquiry, it was found that the deceased was married 2 years prior to the date of incident and because of the non-payment of dowry, her husband Dasrath, father-in- law Kalyan Singh and Sister-in-law Usha were harassing her. The earlier 4 statement given by Vadehi Saran was repeated. It was then mentioned that on 12.8.1992 the sister-in-law Usha, husband Dasrath caught hold of Pinki and father-in-law Kalyan Singh poured kerosene oil on her and set her on fire because of which she got burnt. The accused thereafter cremated her and cleaned the place where occurrence had taken place.
5. On the basis of this, further investigation ensued and after its completion, a charge-sheet came to be filed in the Court for offences under Sections 302, 304 B and 201 IPC. The accused were charged accordingly. The prosecution, during the trial, examined as many as 11 witnesses. The accused persons abjured the guilt and as stated earlier only two of them came to be convicted, namely, Kalyan Singh and Dasrath. However, due to the death of Kalyan Singh during the pendency of the appeal, the appeal filed by Dasrath alone is to be considered.
6. Learned Senior Counsel, Dr. J.N. Singh appearing on behalf of the accused attacked the judgment of both the Courts below, firstly, contending that conviction under Section 304B, IPC and Section, 201, IPC was wholly incorrect as it was not proved that Pinki had died a suspicious or un-natural death within the seven years of her marriage nor was her body found. He also contended that there was no question of demanding any dowry as no complaint was ever made for dowry nor was there any evidence regarding the demands of dowry. Lastly, he suggested that there 5 was no question of any offence having been committed. He pointed out that the Trial Court had acquitted all the accused of the offence under Section 302, IPC though a charge was also framed under that Section and there was no appeal by the State Government against the acquittal under Section 302, IPC. Under such circumstances, it was clear that the accused persons could not be held responsible for the death of Pinki.
7. As against this, Ms. Aishwarya Bhati, Learned Counsel appearing on behalf of the respondent pointed out that it could not be said that the death did not take place within seven years of marriage as the accused himself had admitted that the marriage had taken place six years prior to the trial. She further pointed out that there was a clear assertion made by the witnesses in their evidence. More particularly, Vadehi Saran (PW 4), Janved Singh (PW-5), Pratibha (PW-6) and Jitendra Singh (PW-8) had clearly asserted that the dowry was asked for by the accused persons. Learned Counsel further contended that if Pinki had died of burning, a report ought to have been made for un-natural death which the accused did not bother to make, instead they had cremated the body of Pinki without even intimating the relatives of the deceased and also without waiting for the police. This was the most suspicious circumstance which pointed towards the guilt of the accused.
6
8. It is on the basis of these rival versions that it is to be seen as to whether the appellant Dasrath was rightly convicted for the offence.
9. The first contention raised by the Learned Counsel for the defence regarding the corpus delicti not being found was countered by Ms. Bhati by saying that there can be no dispute about the death of Pinki. It is not the defence of the accused that Pinki was still living. On the other hand, the accused persons admittedly had cremated her body on the fateful day. Therefore, this is not a case, according to her, of corpus delicti not being found and, therefore, there being a serious suspicion about the death having taken place at all. The question is, in the absence of corpus delicti, could it be presumed that the accused persons alone were responsible for the death of Pinki. We must hasten to add here that the accused persons have already been acquitted of the murder charge.  If these ingredients are proved by the prosecution then the conviction of the accused under Section 304B, IPC will be complete.
10. There can be no dispute that Pinki had died an un-natural death. In fact there is enough evidence to suggest that Pinki suffered the burn injuries. It is not the defence of the accused that she died a natural death. 7 Both the Courts have very specifically held that Pinki suffered burn injuries and died because of the same. In fact Jitendra Singh (PW-8) was specific in his evidence that Pinki was burning on account of the kerosene having been poured on her body. In fact it is apparent from his cross-examination that when Pinki shouted, neighbours rushed to her house. There can be no dispute that this witness has been dis-believed and rightly so, insofar as his evidence about the accused deliberately burning Pinki is concerned. However, there can be no dispute that Pinki was burnt and it was clear that she had died an un-natural death. Again, it is clear from the report of the chemical analyzer that the kerosene residues were found from Packet-A which contained the clothes of Pinki which were seized during the investigation. Therefore, it is clear that Pinki's death was caused because of the burns and not in the normal circumstances. The finding of the Trial Court and the appellate Court in that behalf is correct. For this reason we are not impressed by the argument of the Learned Counsel that in the absence of corpus delicti, the conviction could not stand. Similarly, there can be no dispute that Pinki died within seven years of her marriage. Gandharv Singh (PW-1) had specifically asserted that the marriage was performed 3-4 years prior to the incident. Though this witness was declared hostile, at least the fact that marriage had taken place 3-4 years prior to the incident can be safely accepted. According to PW-2, Bhagwati Saran also the marriage had taken place within 5-6 years prior to trial. 8 Again even this witness was declared hostile. However, that claim remained un-controverted. Third witness PW-3, Hari Saran asserted that the marriage was performed 6-7 years earlier to the date of his evidence. His evidence was in May, 1997 and even taking that the marriage took place somewhere in the year 1990, it would still be within seven years. Vadehi Saran, the father also said that the marriage had taken place 6-7 years prior to the date of his evidence which was again 30.09.1997. Therefore, according to his evidence even if the marriage could date back to the year 1987, it would still put the death of Pinki within seven years of her marriage.
11.  As regards dowry, Learned Counsel for the defence pointed out that there was no specific evidence nor was any allegation made in the First Information Report. We are not much impressed as we have seen from the evidence that there were demands of Buffalo made to Vadehi Saran, father of Pinki who did not accept that demand. Vadehi Saran has also specifically stated in his evidence that after 1 = years of the marriage when he went to the house of Pinki in the month of Shravan, door was closed and the appellants were beating Pinki and that the floor was smeared with blood and blood was also oozing out from the mouth of Pinki. He also asserted about the demand of a large 9 size television as the television which was given in marriage was a small colour television. This evidence of torture is well supported by the evidence of Pratibha (PW-6), Anant Ram Singh (PW-7) and Uttam Singh (PW-9). In view of this, the Trial court and the appellate Court have recorded that, firstly, Pinki died an un-natural death because of burning within seven years of her marriage and, secondly concluded that she was subjected to cruelty and harassment by her husband and/or relatives in connection with the demand for dowry and that she was subjected to cruelty soon before her death.
12. Similar is the case as regards the offence under Section 201, IPC. In fact it was incumbent upon the accused persons to firstly, inform the police about the un-natural death of Pinki. They did not do so. On the other hand, even after her death, they did not inform either the police or even the relatives like her father etc., though they could have done so. In stead they hurriedly conducted the funeral thereby causing destruction of evidence.
13. In State of Rajasthan v. Jaggu Ram [2008 (12) SCC 51], this Court has considered the circumstance about the non-information to the parents and the hurried cremation. This was also a case where accused persons were tried for offence under Section 304B, IPC, where the accused, after the death of the unfortunate lady did not bother to inform her parents. In 10 paragraph 26, this Court took a serious note of the manner in which the body was disposed of. The Court observed "the disposal of the dead body in a hush-hush manner clearly establishes that the accused had done so with the sole object of concealing the real cause of death of Shanti @ Gokul."
14. In that case, the funeral was conducted in the wee hours. In this case, funeral was conducted in the evening.
15. From all this, it is clear that the prosecution has not only proved the offence under Section 304B, IPC with the aid of Section 113B, Indian Evidence Act but also the offence under Section 201, IPC. We are satisfied that all the three ingredients of Section 304B, IPC, they being:
1. that the death of a woman has been caused by burns or bodily injury or occurs otherwise than under normal circumstances;
2. that such death has been caused or has occurred within seven years of her marriage; and
3. that soon before her death the woman was subjected to cruelty or harassment by her husband or any relative of her husband in connection with any demand for dowry."
as also the presumption under Section 113B of India Evidence Act are fully established the case of prosecution.
11
16. We have gone through the judgments of the Trial Court as well as the appellate Court carefully and we find that both the Courts have fully considered all the aspects of this matter. We, therefore, find nothing wrong with the judgments and confirm the same. The appeal is, therefore, dismissed.
.......................................J.
(V.S. Sirpurkar) ......................................J.
(Dr. Mukundakam Sharma) New Delhi;
July 29, 2010


Welcome to the Dominion divider generator.
Quite a while ago, I converted my base Dominion box into a storage
solution for the base game + 3 expansions plus extra materials. In the process, I wrote
a Python script (get the source here) to
generate pdfs of the dividers that I used. I then published those pdfs to BoardGameGeek and since then have improved them due to
feedback numerous
times. However, people keep putting in requests for special versions (with cropmarks,
for different sets, etc.) and the file I publish keeps getting bigger and bigger due to
including all version. So, instead of growing the number of versions, I've decided to try
putting the script behind the web form on the left so those interested can generate their own
versions. Others have also taken my source and changed
it if you are looking for different things.
Please note issues and requests on github, talk to fellow users in this thread, or contact me via BGG mail. You can also
thumb the thread or the original
file thread if you like these dividers, or even better post pictures of how you used
them - I'm always curious.
If you would like to contribute, the code for
the generator is available on github. A huge thank you to all the people who have
contributed to this, especially wvoigt (bgg/github) and nickv2002 (bgg/github) without whom I would have no chance to
stay up-to-date with this project.
{% include "generated/changelog.html" %}
Previous non-release based changelog:
- Sep 22, 2016: Options to include # of cards on dividers and to generate slipcases instead of
dividers. Add centre-aligned tab option. Fix to Shelters colour.
- July 2, 2016: Make Events exclusion apply to landmarks, too (github
https://github.com/sumpfork/dominiontabs/issues/67 and
https://github.com/sumpfork/dominiontabs/issues/66)
- June 19, 2016: Empires improvements and fixes - v2.2 of generation code.
- June 11, 2016: Full Empires expansion support, thanks to the great contributors at github.
- May 24, 2016: Expose option to group some special card groups, like Prizes.
- Mar 17, 2016: Improvements to German translations.
- Dec 1, 2015: Avery label fixes. More options for card texts; German translation.
- Oct 19, 2015: Expose recent changes/updates: some updated card texts, more comprehensive
no-footer, card name and tab alignments options.
- June 19, 2015: Update to get latest fixes from github, expose no text on dividers option.
- May 4, 2015: Updated tab images for Adventures. Single tab for Prizes, second tab for
Possession, fix for Scavenger.
- Apr 21, 2015: Add optional individual event dividers and cumulative single event divider.
- Apr 20, 2015: Add Dominion: Adventures with lots of help from community. No events yet.
- Dec 11, 2014: Start of Italian translation; some card text cleanup.
- Jul 4, 2014: Added Prince Promo Card
- Mar 5, 2014: Added new back text for Walled Village and Governor
- Jan 31, 2014: Fixed Avery Labels, some missing coin images
- Jan 30, 2014: Back text for Hinterland cards.
- Jan 8, 2014: Fix alternating/same side tabs options.


"Everyone wants to hold the baby but who will hold the mother?""
When we say Postpartum, we refer to the Postpartum period immediately after the birth of the baby. It is also often called the Fourth trimester or sometimes the Sacred Window. Depending on how the birth unfolded, depending on what was the outcome, the postpartum period comes with its own set of challenges. When you research the simple word “postpartum” in your browser, the first pages of results you obtain are all about postpartum depression. This should tell you how crucial support during the Fourth trimester is. It is a precious and vulnerable time for the new mother. The main goal during this fragile period is to “mother the mother”, to nourish her, to nurture her and honor her. She too was born. Regardless of how she labored and birthed her baby, all ways are not easy. It is a Rite of Passage.
In my postpartum doula role, I am by your side to help you thrive and not just survive your postpartum period. I am your personal guide through your Fourth trimester. I am the extra layer of support that help you learn to navigate life with a new baby, normalize the overwhelming experiences, help you recognize when and how to reach out for extra support, and tame the chaos and clutter that newborns can sometimes bring along.
Go to the Postpartum Offerings.
Bottle feeding / breastfeeding help,
Help understanding the baby's cues,
Diapering and baby care,
Mother / parents care,
Help with older children,
Light housekeeping assistance,
Resources & referrals,
Non-judgmental support,
Screening for postpartum disorder,
Infant sleep solution,
Baby wearing assistance,
Processing the birth experience,
Soothing baby and education on infant soothing techniques,
(...)


Template comes in with list of already configured tools:
sbt test
task. For aggregated
results follow it with coverageAggregate
task. Sections that should not be measured can be
turned off with // $COVERAGE:OFF$ [reason]
and // $COVERAGE:ON$
comments,project/Settings.scala
file. Can be turned off locally with // format: OFF
,
// format: ON
(comes handy when tool merges several lines into 200-char long monster),scalastyle-config.xml
. If some rule needs exception you can use
// scalastyle:off [rule id]
Template comes in with 3 test tasks:
test
- runs tests under test
directory.fun:test
- runs tests under fun
directory,it:test
- runs tests under it
directory.If default tools and tasks configuration is already suiting your needs, I recommend starting by changing
namespaces everywhere using some refactoring tool. Then I'd edit project/Settings.scala
and changed
organization
, version
and initial command
. Finally I would adjust modules
to my needs.
Once project is established you can remove `tutorial` dir and `activator.properties` file.


subtitle: 'Tracking line'
---
## Tracking line
jsGraph allows you to display a vertical line as a tracker and to display information about the series at the x point of the tracker. Obviously your x data must be monotoneously increasing for this feature to work. I will show you through a serie of examples how to work with the tracking features.
### Blank example
Let's start by a standard blank example
```javascript
// Create waveforms
// const colorado = Graph.newWaveform().setData( yArr, xArr );
var graph = new Graph('example-1');
graph.resize(700, 300); // Resizes the graph
graph.getYAxis().secondaryGridOff();
graph.getXAxis().secondaryGridOff();
graph.getYAxis().setPrimaryGridColor('#f0f0f0');
graph.getXAxis().setSecondaryGridColor('#f0f0f0');
var serie = graph
.newSerie('CA')
.setLineColor('#2B65EC')
.setLineWidth(2);
serie.setWaveform(california);
serie.autoAxis();
var serie = graph
.newSerie('CO')
.setLineColor('#E42217')
.setLineWidth(2);
serie.setWaveform(colorado);
serie.autoAxis();
```
There are two modes of tracking available: `individual` and `common`:
### Common mode
In the common mode, no matter where the mouse is, jsGraph will try to find the closest x value for each serie and process them all together. If there is no computable data for any serie (outside of any serie range), nothing is displayed. Otherwise, a vertical line is shown, the closest point in each serie is highlighted and a single text box appears (common to all series). Here's how to do:
```javascript
graph.trackingLine({
mode: 'common', // Defines the mode, individual or common
snapToSerie: graph.getSerie('CA'), // In the common mode, choses the serie onto which the tracking line will snap
textMethod: function(output) {
// Method that should return the content of the text box
var txt = '';
if (output['CA']) {
txt += 'California: ' + Math.round(output['CA'].yValue) + ' ktons
';
}
if (output['CO']) {
txt += 'Colorado: ' + Math.round(output['CO'].yValue) + ' ktons';
}
return txt;
},
trackingLineShapeOptions: {
// Parameters of the tracking line
strokeColor: '#c0c0c0'
},
series: [
// A list of series that can be tracked
{
serie: graph.getSerie('CA')
},
{
serie: graph.getSerie('CO'),
withinPx: 10 // Allows to be within a 10px range
}
]
});
```
- The `snapToSerie` option defined which serie will reference the available x values for the tracking line. The other series will look for the best point around the snapped value to return their closest value.
- The `textMethod` option defined a method used to generate the text located inside the legend box.
- The `trackingLineShapeOptions` applies its members to the line shape element. See ShapeLine for more details
- The `series` option lists all the series accepting tracking. The `withinPx` option defined the position range in which it is acceptable for the serie to show a tracking point. The `withinVal` option is also available for the same feature but in axis unit.
#### withinVal and withinPx
To demonstrate the `within` feature, let us use another example. In this example, the `snapToSerie` option is set to the red
```javascript
var graph = new Graph('example-3');
graph.resize(700, 300); // Resizes the graph
graph.getYAxis().secondaryGridOff();
graph.getXAxis().secondaryGridOff();
graph.getYAxis().setPrimaryGridColor('#f0f0f0');
graph.getXAxis().setSecondaryGridColor('#f0f0f0');
var s1 = [
[1, 2.2, 3.4, 4.6, 5.8, 7, 8.2, 9.4, 10.6, 11.8, 13],
[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1]
]; // 0
var s2 = [
[1, 2.2, 3.4, 4.6, 5.8, 7, 8.2, 9.4, 10.6, 11.8, 13],
[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1]
]; // -0.5
var s3 = [
[1, 2.2, 3.4, 4.6, 5.8, 7, 8.2, 9.4, 10.6, 11.8, 13],
[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1]
]; // -1
var s4 = [
[1, 2.2, 3.4, 4.6, 5.8, 7, 8.2, 9.4, 10.6, 11.8, 13],
[1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1]
]; // -1.5
s2[0] = s2[0].map(el => el - 0.5);
s3[0] = s3[0].map(el => el - 1);
s4[0] = s4[0].map(el => el - 1.5);
s2[1] = s2[1].map(el => el - 0.5);
s3[1] = s3[1].map(el => el - 1);
s4[1] = s4[1].map(el => el - 1.5);
const w1 = Graph.newWaveform().setData(s1[1], s1[0]);
const w2 = Graph.newWaveform().setData(s2[1], s2[0]);
const w3 = Graph.newWaveform().setData(s3[1], s3[0]);
const w4 = Graph.newWaveform().setData(s4[1], s4[0]);
var serie = graph
.newSerie('s1')
.setLineColor('#2B65EC')
.setLineWidth(2);
serie.setWaveform(w1);
serie.autoAxis();
var serie = graph
.newSerie('s2')
.setLineColor('#E42217')
.setLineWidth(2);
serie.setWaveform(w2);
serie.autoAxis();
var serie = graph
.newSerie('s3')
.setLineColor('#369173')
.setLineWidth(2);
serie.setWaveform(w3);
serie.autoAxis();
var serie = graph
.newSerie('s4')
.setLineColor('#DB810B')
.setLineWidth(2);
serie.setWaveform(w4);
serie.autoAxis();
graph.trackingLine({
mode: 'common', // Defines the mode, individual or common
snapToSerie: graph.getSerie('s1'), // In the common mode, choses the serie onto which the tracking line will snap
textMethod: function(output) {
// Method that should return the content of the text box
var txt = '';
return txt;
},
trackingLineShapeOptions: {
// Parameters of the tracking line
strokeColor: '#c0c0c0'
},
series: [
// A list of series that can be tracked
{
serie: graph.getSerie('s2'),
withinPx: 15 // Allows to be within a 30px range
},
{
serie: graph.getSerie('s3'),
withinPx: 30 // Allows to be within a 50px range
},
{
serie: graph.getSerie('s4'),
withinVal: 0.5 // Allows to be within a 0.8 value in the x direction
}
]
});
graph.draw();
```
In this example, the second serie (red) will only highlight if the snapped point on the blue serie is less than 10px than the closest point on the red serie. With this particular graph width, it happens when the x value of the red point is either exactly on the blue one or shifted by one. The third serie (green) will highlight a point only if it is within 20px of the snapped point on the blue serie. Therefore, more points compared to the red serie are selected. In the fourth serie (orange), only points not further than 0.2 (included) will be tracked. If no point is within 0.2 (in x axis value), then no tracking is done and the dot is not showed. The only tracked points are the first two (0, +0.2), the three in the middle (-0.2, 0, +0.2) and the last two (-0.2, 0).
You may also note that the serie 1 is used for snapping but is not in the tracked series list. It therefore doesn't show up in the list !
### Individual mode
In the individual mode, every serie is tracked independently and leads to a multiple legend instances:
```javascript
graph.trackingLine({
mode: 'individual', // Defines the mode, individual or common
legend: true,
series: [
// A list of series that can be tracked
{
serie: graph.getSerie('CA')
},
{
serie: graph.getSerie('CO')
}
]
});
```


|
Panda3D
|
Public Member Functions | |
| def | __init__ (self, name, states=[], initialStateName=None, finalStateName=None, onUndefTransition=DISALLOW_VERBOSE) |
| def | __repr__ (self) |
| def | __str__ (self) |
| def | addState (self, state) |
| def | conditional_request (self, aStateName, enterArgList=[], exitArgList=[]) |
| def | enterInitialState (self, argList=[]) |
| def | forceTransition (self, aStateName, enterArgList=[], exitArgList=[]) |
| def | getCurrentState (self) |
| def | getFinalState (self) |
| def | getInitialState (self) |
| def | getName (self) |
| def | getStateNamed (self, stateName) |
| def | getStates (self) |
| def | hasStateNamed (self, stateName) |
| def | isInternalStateInFlux (self) |
| def | request (self, aStateName, enterArgList=[], exitArgList=[], force=0) |
| def | requestFinalState (self) |
| def | setFinalState (self, finalStateName) |
| def | setInitialState (self, initialStateName) |
| def | setName (self, name) |
| def | setStates (self, states) |
| def | view (self) |
| Public Member Functions inherited from DirectObject | |
| def | __init__ (self) |
| def | accept (self, event, method, extraArgs=[]) |
| def | acceptOnce (self, event, method, extraArgs=[]) |
| def | addTask (self, *args, **kwargs) |
| def | detectLeaks (self) |
| def | doMethodLater (self, *args, **kwargs) |
| def | getAllAccepting (self) |
| def | ignore (self, event) |
| def | ignoreAll (self) |
| def | isAccepting (self, event) |
| def | isIgnoring (self, event) |
| def | removeAllTasks (self) |
| def | removeTask (self, taskOrName) |
Public Attributes | |
| inspecting | |
| onUndefTransition | |
Static Public Attributes | |
| int | ALLOW = 0 |
| int | DISALLOW = 1 |
| int | DISALLOW_VERBOSE = 2 |
| int | ERROR = 3 |
| notify = directNotify.newCategory("ClassicFSM") | |
| Static Public Attributes inherited from DirectObject | |
| def | accept_once = acceptOnce |
| def | add_task = addTask |
| def | detect_leaks = detectLeaks |
| def | do_method_later = doMethodLater |
| def | get_all_accepting = getAllAccepting |
| def | ignore_all = ignoreAll |
| def | is_accepting = isAccepting |
| def | is_ignoring = isIgnoring |
| def | remove_all_tasks = removeAllTasks |
| def | remove_task = removeTask |
Finite State Machine class. This module and class exist only for backward compatibility with existing code. New code should use the FSM class instead.
| def __init__ | ( | self, | |
| name, | |||
states = [] , |
|||
initialStateName = None , |
|||
finalStateName = None , |
|||
onUndefTransition = DISALLOW_VERBOSE |
|||
| ) |
__init__(self, string, State[], string, string, int) ClassicFSM constructor: takes name, list of states, initial state and final state as:: fsm = ClassicFSM.ClassicFSM('stopLight', [State.State('red', enterRed, exitRed, ['green']), State.State('yellow', enterYellow, exitYellow, ['red']), State.State('green', enterGreen, exitGreen, ['yellow'])], 'red', 'red') each state's last argument, a list of allowed state transitions, is optional; if left out (or explicitly specified to be State.State.Any) then any transition from the state is 'defined' and allowed 'onUndefTransition' flag determines behavior when undefined transition is requested; see flag definitions above
| def __repr__ | ( | self | ) |
| def __str__ | ( | self | ) |
Print out something useful about the fsm
| def addState | ( | self, | |
| state | |||
| ) |
| def conditional_request | ( | self, | |
| aStateName, | |||
enterArgList = [] , |
|||
exitArgList = [] |
|||
| ) |
'if this transition is defined, do it' Attempt transition from currentState to given one, if it exists. Return true if transition exists to given state, false otherwise. It is NOT an error/warning to attempt a cond_request if the transition doesn't exist. This lets people be sloppy about ClassicFSM transitions, letting the same fn be used for different states that may not have the same out transitions.
| def enterInitialState | ( | self, | |
argList = [] |
|||
| ) |
| def forceTransition | ( | self, | |
| aStateName, | |||
enterArgList = [] , |
|||
exitArgList = [] |
|||
| ) |
force a transition -- for debugging ONLY
| def getCurrentState | ( | self | ) |
| def getFinalState | ( | self | ) |
| def getInitialState | ( | self | ) |
| def getName | ( | self | ) |
| def getStateNamed | ( | self, | |
| stateName | |||
| ) |
Return the state with given name if found, issue warning otherwise
| def getStates | ( | self | ) |
| def hasStateNamed | ( | self, | |
| stateName | |||
| ) |
Return True if stateName is a valid state, False otherwise.
| def isInternalStateInFlux | ( | self | ) |
| def request | ( | self, | |
| aStateName, | |||
enterArgList = [] , |
|||
exitArgList = [] , |
|||
force = 0 |
|||
| ) |
Attempt transition from currentState to given one. Return true is transition exists to given state, false otherwise.
| def requestFinalState | ( | self | ) |
| def setFinalState | ( | self, | |
| finalStateName | |||
| ) |
| def setInitialState | ( | self, | |
| initialStateName | |||
| ) |
| def setName | ( | self, | |
| name | |||
| ) |
| def setStates | ( | self, | |
| states | |||
| ) |
setStates(self, State[])
| def view | ( | self | ) |
|
static |
|
static |
|
static |
|
static |
| inspecting |
|
static |
| onUndefTransition |