One of the important features in
any programming language is the convenient use of names.
When
you create an object (a variable), you give a name to a region of storage. A
function is a name for an action. By making up names to describe the system at
hand, you create a program that is easier for people to understand and change.
It’s a lot like writing prose – the goal is to communicate with your
readers.
A problem arises when mapping the concept
of nuance in human language onto a programming language.
Often, the same word expresses a number of different meanings, depending on
context. That is, a single word has multiple meanings – it’s
overloaded. This is very useful, especially when it comes to trivial
differences. You say “wash the shirt, wash the car.” It would be
silly to be forced to say, “shirt_wash the shirt, car_wash the car”
just so the listener doesn’t have to make any distinction about the action
performed. Human languages have built-in redundancy, so even if you miss a few
words, you can still determine the meaning. We don’t need unique
identifiers – we can deduce meaning from
context.
Most programming languages, however,
require that you have a unique
identifier for each function. If you have three different types of data that you
want to print: int, char, and float, you generally have to
create three different function names, for example, print_int( ),
print_char( ), and print_float( ). This loads extra work
on you as you write the program, and on readers as they try to understand
it.
In C++, another factor forces the
overloading of function names: the constructor. Because
the constructor’s name is predetermined by the name of the class, it would
seem that there can be only one constructor. But what if you want to create an
object in more than one way? For example, suppose you build a class that can
initialize itself in a standard way and also by reading information from a file.
You need two constructors, one that takes no arguments (the default constructor)
and one that takes a string as an argument, which is the name of the file
to initialize the object. Both are constructors, so they must have the same
name: the name of the class. Thus, function overloading is essential to allow
the same function name – the constructor in this case – to be used
with different argument types.
Although function overloading is a must
for constructors, it’s a general convenience and can be used with any
function, not just class member functions. In addition, function overloading
means that if you have two libraries that contain functions of the same name,
they won’t conflict as long as the argument lists are different.
We’ll look at all these factors in detail throughout this
chapter.
The theme of this chapter is convenient
use of function names. Function overloading allows you to use the same name for
different functions, but there’s a second way to make calling a function
more convenient. What if you’d like to call the same function in different
ways? When functions have long argument lists, it can become tedious to write
(and confusing to read) the function calls when most of the arguments are the
same for all the calls. A commonly used feature in C++ is called default
arguments. A default
argument is one the compiler inserts if it isn’t specified in the function
call. Thus, the calls f(“hello”), f(“hi”,
1), and f(“howdy”, 2, ‘c’) can all be calls
to the same function. They could also be calls to three overloaded functions,
but when the argument lists are this similar, you’ll usually want similar
behavior, which calls for a single function.
Function overloading and default
arguments really aren’t very complicated. By the time you reach the end of
this chapter, you’ll understand when to use them and the underlying
mechanisms that implement them during compiling and
linking.
void f(); class X { void f(); };
the function f( ) inside the
scope of class X does not clash with the global version of
f( ). The compiler performs this scoping by manufacturing different
internal names for the global version of f( ) and
X::f( ). In Chapter 4, it was suggested that the names are simply
the class name “decorated” together with the function name, so the
internal names the compiler uses might be _f and _X_f. However, it
turns out that function name decoration involves more than the class
name.
Here’s why. Suppose you want to
overload two function names
void print(char); void print(float);
It doesn’t matter whether they are
both inside a class or at the global scope. The compiler can’t generate
unique internal identifiers if it uses only the scope of the function names.
You’d end up with _print in both cases. The idea of an overloaded
function is that you use the same function name, but different argument lists.
Thus, for overloading to work the compiler must decorate the function name with
the names of the argument types. The functions above,
defined at global scope, produce internal names that might look something like
_print_char and _print_float. It’s worth noting there is no
standard for the way names must be decorated by the
compiler, so you will see very different results from one compiler to another.
(You can see what it looks like by telling the compiler to generate
assembly-language output.) This, of course, causes problems if you want to buy
compiled libraries for a particular compiler and linker – but even if
name decoration were standardized, there would be other roadblocks because of
the way different compilers generate
code.
That’s really all there is to
function overloading: you can use the same function name for different functions
as long as the argument lists are different. The compiler decorates the name,
the scope, and the argument lists to produce internal names for it and the
linker to
use.
It’s common to wonder, “Why
just scopes and argument lists? Why not return values?” It seems at first
that it would make sense to also decorate the return value with the internal
function name. Then you could overload on return
values, as
well:
void f(); int f();
This works fine when the compiler can
unequivocally determine the meaning from the context, as in int x =
f( );. However, in C you’ve always been able to call a
function and ignore the return value (that is, you can
call the function for its side effects). How can the compiler distinguish
which call is meant in this case? Possibly worse is the difficulty the reader
has in knowing which function call is meant. Overloading solely on return value
is a bit too subtle, and thus isn’t allowed in
C++.
There is an added benefit to all of this
name decoration. A particularly sticky problem in C occurs when the client
programmer misdeclares a
function, or, worse, a function
is called without declaring it first, and the compiler infers the function
declaration from the way it is called. Sometimes this function declaration is
correct, but when it isn’t, it can be a difficult bug to
find.
Because all functions must be
declared before they are used in C++, the opportunity for this problem to pop up
is greatly diminished. The C++ compiler refuses to declare a function
automatically for you, so it’s likely that you will include the
appropriate header file. However, if for some reason you still manage to
misdeclare a function, either by declaring by hand or including the wrong header
file (perhaps one that is out of date), the name decoration provides a safety
net that is often referred to as type-safe linkage.
Consider the following scenario. In one
file is the definition for a function:
//: C07:Def.cpp {O} // Function definition void f(int) {} ///:~
In the second file, the function is
misdeclared and then called:
//: C07:Use.cpp //{L} Def // Function misdeclaration void f(char); int main() { //! f(1); // Causes a linker error } ///:~
Even though you can see that the function
is actually f(int), the compiler doesn’t know this because it was
told – through an explicit declaration – that the function is
f(char). Thus, the compilation is successful. In
C, the linker would also be successful, but not
in C++. Because the compiler decorates the names, the definition becomes
something like f_int, whereas the use of the function is f_char.
When the linker tries to resolve the reference to f_char, it can only
find f_int, and it gives you an error message. This is type-safe linkage.
Although the problem doesn’t occur all that often, when it does it can be
incredibly difficult to find, especially in a large project. This is one of the
cases where you can easily find a difficult error in a C program simply by
running it through the C++
compiler.
We can now modify earlier examples to use
function overloading. As stated before, an immediately useful place for
overloading is in constructors. You can see this in the following version of the
Stash class:
//: C07:Stash3.h // Function overloading #ifndef STASH3_H #define STASH3_H class Stash { int size; // Size of each space int quantity; // Number of storage spaces int next; // Next empty space // Dynamically allocated array of bytes: unsigned char* storage; void inflate(int increase); public: Stash(int size); // Zero quantity Stash(int size, int initQuantity); ~Stash(); int add(void* element); void* fetch(int index); int count(); }; #endif // STASH3_H ///:~
The first Stash( )
constructor is the same as before, but the second one has a Quantity
argument to indicate the initial number of storage places to be allocated. In
the definition, you can see that the internal value of quantity is set to
zero, along with the storage pointer. In the second constructor, the call
to inflate(initQuantity) increases quantity to the allocated
size:
//: C07:Stash3.cpp {O} // Function overloading #include "Stash3.h" #include "../require.h" #include <iostream> #include <cassert> using namespace std; const int increment = 100; Stash::Stash(int sz) { size = sz; quantity = 0; next = 0; storage = 0; } Stash::Stash(int sz, int initQuantity) { size = sz; quantity = 0; next = 0; storage = 0; inflate(initQuantity); } Stash::~Stash() { if(storage != 0) { cout << "freeing storage" << endl; delete []storage; } } int Stash::add(void* element) { if(next >= quantity) // Enough space left? inflate(increment); // Copy element into storage, // starting at next empty space: int startBytes = next * size; unsigned char* e = (unsigned char*)element; for(int i = 0; i < size; i++) storage[startBytes + i] = e[i]; next++; return(next - 1); // Index number } void* Stash::fetch(int index) { require(0 <= index, "Stash::fetch (-)index"); if(index >= next) return 0; // To indicate the end // Produce pointer to desired element: return &(storage[index * size]); } int Stash::count() { return next; // Number of elements in CStash } void Stash::inflate(int increase) { assert(increase >= 0); if(increase == 0) return; int newQuantity = quantity + increase; int newBytes = newQuantity * size; int oldBytes = quantity * size; unsigned char* b = new unsigned char[newBytes]; for(int i = 0; i < oldBytes; i++) b[i] = storage[i]; // Copy old to new delete [](storage); // Release old storage storage = b; // Point to new memory quantity = newQuantity; // Adjust the size } ///:~
When you use the first constructor no
memory is allocated for storage. The allocation happens the first time
you try to add( ) an object and any time the current block of memory
is exceeded inside add( ).
Both constructors are exercised in the
test program:
//: C07:Stash3Test.cpp //{L} Stash3 // Function overloading #include "Stash3.h" #include "../require.h" #include <fstream> #include <iostream> #include <string> using namespace std; int main() { Stash intStash(sizeof(int)); for(int i = 0; i < 100; i++) intStash.add(&i); for(int j = 0; j < intStash.count(); j++) cout << "intStash.fetch(" << j << ") = " << *(int*)intStash.fetch(j) << endl; const int bufsize = 80; Stash stringStash(sizeof(char) * bufsize, 100); ifstream in("Stash3Test.cpp"); assure(in, "Stash3Test.cpp"); string line; while(getline(in, line)) stringStash.add((char*)line.c_str()); int k = 0; char* cp; while((cp = (char*)stringStash.fetch(k++))!=0) cout << "stringStash.fetch(" << k << ") = " << cp << endl; } ///:~
The constructor call for stringStash
uses a second argument; presumably you know something special about the
specific problem you’re solving that allows you to choose an initial size
for the Stash.
As you’ve seen, the only difference
between struct and class in C++ is that struct defaults to
public and class defaults to private. A struct can
also have constructors and destructors, as you might expect. But it turns out
that a union can also have a constructor,
destructor, member functions, and even access control. You can again see the use
and benefit of overloading in the following example:
//: C07:UnionClass.cpp // Unions with constructors and member functions #include<iostream> using namespace std; union U { private: // Access control too! int i; float f; public: U(int a); U(float b); ~U(); int read_int(); float read_float(); }; U::U(int a) { i = a; } U::U(float b) { f = b;} U::~U() { cout << "U::~U()\n"; } int U::read_int() { return i; } float U::read_float() { return f; } int main() { U X(12), Y(1.9F); cout << X.read_int() << endl; cout << Y.read_float() << endl; } ///:~
You might think from the code above that
the only difference between a
union and a class is the way the data is stored (that is, the
int and float are overlaid on the same piece of storage). However,
a union cannot be used as a base class during inheritance, which is quite
limiting from an object-oriented design standpoint (you’ll learn about
inheritance in Chapter 14).
Although the member functions civilize
access to the union somewhat, there is still no way to prevent the client
programmer from selecting the wrong element type once the union is
initialized. In the example above, you could say X.read_float( )
even though it is inappropriate. However, a
“safe” union
can be encapsulated in a class. In the following example, notice how the
enum clarifies the code, and how overloading comes in handy with the
constructors:
//: C07:SuperVar.cpp // A super-variable #include <iostream> using namespace std; class SuperVar { enum { character, integer, floating_point } vartype; // Define one union { // Anonymous union char c; int i; float f; }; public: SuperVar(char ch); SuperVar(int ii); SuperVar(float ff); void print(); }; SuperVar::SuperVar(char ch) { vartype = character; c = ch; } SuperVar::SuperVar(int ii) { vartype = integer; i = ii; } SuperVar::SuperVar(float ff) { vartype = floating_point; f = ff; } void SuperVar::print() { switch (vartype) { case character: cout << "character: " << c << endl; break; case integer: cout << "integer: " << i << endl; break; case floating_point: cout << "float: " << f << endl; break; } } int main() { SuperVar A('c'), B(12), C(1.44F); A.print(); B.print(); C.print(); } ///:~
In the code above, the
enum has no type name (it is an
untagged enumeration). This is
acceptable if you are going to immediately define instances of the enum,
as is done here. There is no need to refer to the enum’s type name
in the future, so the type name is optional.
The union
has no type name and no variable name. This is called an
anonymous union, and
creates space for the union but doesn’t require accessing the
union elements with a variable name and the dot operator. For instance,
if your anonymous union is:
//: C07:AnonymousUnion.cpp int main() { union { int i; float f; }; // Access members without using qualifiers: i = 12; f = 1.22; } ///:~
Note that you access members of an
anonymous union just as if they were ordinary variables. The only difference is
that both variables occupy the same space. If the anonymous union is at
file scope (outside all functions and classes) then it must be declared
static so it has internal
linkage.
Although SuperVar is now safe, its
usefulness is a bit dubious because the reason for using a union in the
first place is to save space, and the addition of vartype takes up quite
a bit of space relative to the data in the union, so the savings are
effectively eliminated. There are a couple of alternatives to make this scheme
workable. If the vartype controlled more than one union instance
– if they were all the same type – then you’d only need one
for the group and it wouldn’t take up more space. A more useful approach
is to have #ifdefs around all the vartype code, which can then
guarantee things are being used correctly during development and testing. For
shipping code, the extra space and time overhead can be
eliminated.
In Stash3.h, examine the two
constructors for Stash( ). They don’t seem all that different,
do they? In fact, the first constructor seems to be a special case of the second
one with the initial size set to zero. It’s a bit of a waste of
effort to create and maintain two different versions of a similar
function.
C++ provides a remedy with default
arguments. A default
argument is a value given in the declaration that the compiler automatically
inserts if you don’t provide a value in the function call. In the
Stash example, we can replace the two functions:
Stash(int size); // Zero quantity Stash(int size, int initQuantity);
with the single
function:
Stash(int size, int initQuantity = 0);
The Stash(int) definition is
simply removed – all that is necessary is the single Stash(int,
int) definition.
Now, the two object
definitions
Stash A(100), B(100, 0);
will produce exactly the same results.
The identical constructor is called in both cases, but for A, the second
argument is automatically substituted by the compiler when it sees the first
argument is an int and that there is no second argument. The compiler has
seen the default argument, so it knows it can still make the function call if it
substitutes this second argument, which is what you’ve told it to do by
making it a default.
Default arguments are a convenience, as
function overloading is a convenience. Both features allow you to use a single
function name in different situations. The difference is that with default
arguments the compiler is substituting arguments when you don’t want to
put them in yourself. The preceding example is a good place to use default
arguments instead of function overloading; otherwise you end up with two or more
functions that have similar signatures and similar behaviors. If the functions
have very different behaviors, it doesn’t usually make sense to use
default arguments (for that matter, you might want to question whether two
functions with very different behaviors should have the same
name).
There are two rules you must be aware of
when using default arguments. First, only
trailing arguments may be
defaulted. That is, you can’t have a default argument followed by a
non-default argument. Second, once you start using default arguments in a
particular function call, all the subsequent arguments in that function’s
argument list must be defaulted (this follows from the first
rule).
Default arguments are only placed in the
declaration of a function (typically placed in a header
file). The compiler must see the
default value before it can use it. Sometimes people will place the commented
values of the default arguments in the function definition, for documentation
purposes
void fn(int x /* = 0 */) { // ...
Arguments in a function declaration can
be declared without identifiers. When these are used
with default arguments, it can look a bit funny. You can end up
with
void f(int x, int = 0, float = 1.1);
In C++ you don’t need identifiers
in the function definition, either:
void f(int x, int, float flt) { /* ... */ }
In the function body, x and
flt can be referenced, but not the middle argument, because it has no
name. Function calls must still provide a value for the placeholder, though:
f(1) or f(1,2,3.0). This syntax allows you to put the argument in
as a placeholder without using it. The idea is that you might want to change the
function definition to use the placeholder later, without changing all the code
where the function is called. Of course, you can accomplish the same thing by
using a named argument, but if you define the argument for the function body
without using it, most compilers will give you a warning message, assuming
you’ve made a logical error.
More important, if you start out using a
function argument and later decide that you don’t need it, you can
effectively remove it without generating warnings, and yet not disturb any
client code that was calling the previous version of the
function.
Both function overloading and default
arguments provide a convenience for calling function names. However, it can seem
confusing at times to know which technique to use. For example, consider the
following tool that is designed to automatically manage blocks of
memory for you:
//: C07:Mem.h #ifndef MEM_H #define MEM_H typedef unsigned char byte; class Mem { byte* mem; int size; void ensureMinSize(int minSize); public: Mem(); Mem(int sz); ~Mem(); int msize(); byte* pointer(); byte* pointer(int minSize); }; #endif // MEM_H ///:~
A Mem object holds a block of
bytes and makes sure that you have enough storage. The default
constructor doesn’t allocate any storage, and the second constructor
ensures that there is sz storage in the Mem object. The destructor
releases the storage, msize( ) tells you how many bytes there are
currently in the Mem object, and pointer( ) produces a
pointer to the starting address of the storage (Mem is a fairly low-level
tool). There’s an overloaded version of pointer( ) in which
client programmers can say that they want a pointer to a block of bytes that is
at least minSize large, and the member function ensures
this.
Both the constructor and the
pointer( ) member function use the private
ensureMinSize( ) member function to increase the size of the memory
block (notice that it’s not safe to hold the result of
pointer( ) if the memory is resized).
Here’s the implementation of the
class:
//: C07:Mem.cpp {O} #include "Mem.h" #include <cstring> using namespace std; Mem::Mem() { mem = 0; size = 0; } Mem::Mem(int sz) { mem = 0; size = 0; ensureMinSize(sz); } Mem::~Mem() { delete []mem; } int Mem::msize() { return size; } void Mem::ensureMinSize(int minSize) { if(size < minSize) { byte* newmem = new byte[minSize]; memset(newmem + size, 0, minSize - size); memcpy(newmem, mem, size); delete []mem; mem = newmem; size = minSize; } } byte* Mem::pointer() { return mem; } byte* Mem::pointer(int minSize) { ensureMinSize(minSize); return mem; } ///:~
You can see that
ensureMinSize( ) is the only function responsible for allocating
memory, and that it is used from the second constructor and the second
overloaded form of pointer( ). Inside ensureMinSize( ),
nothing needs to be done if the size is large enough. If new storage must
be allocated in order to make the block bigger (which is also the case when the
block is of size zero after default construction), the new “extra”
portion is set to zero using the Standard C library
function memset( ), which was introduced in Chapter 5. The
subsequent function call is to the Standard C library function
memcpy( ), which in this case copies the
existing bytes from mem to newmem (typically in an efficient
fashion). Finally, the old memory is deleted and the new memory and sizes are
assigned to the appropriate members.
The Mem class is designed to be
used as a tool within other classes to simplify their memory management (it
could also be used to hide a more sophisticated memory-management system
provided, for example, by the operating system). Appropriately, it is tested
here by creating a simple “string” class:
//: C07:MemTest.cpp // Testing the Mem class //{L} Mem #include "Mem.h" #include <cstring> #include <iostream> using namespace std; class MyString { Mem* buf; public: MyString(); MyString(char* str); ~MyString(); void concat(char* str); void print(ostream& os); }; MyString::MyString() { buf = 0; } MyString::MyString(char* str) { buf = new Mem(strlen(str) + 1); strcpy((char*)buf->pointer(), str); } void MyString::concat(char* str) { if(!buf) buf = new Mem; strcat((char*)buf->pointer( buf->msize() + strlen(str) + 1), str); } void MyString::print(ostream& os) { if(!buf) return; os << buf->pointer() << endl; } MyString::~MyString() { delete buf; } int main() { MyString s("My test string"); s.print(cout); s.concat(" some additional stuff"); s.print(cout); MyString s2; s2.concat("Using default constructor"); s2.print(cout); } ///:~
All you can do with this class is to
create a MyString, concatenate text, and print to an
ostream. The class only contains a pointer to a
Mem, but note the distinction between the default constructor, which sets
the pointer to zero, and the second constructor, which creates a Mem and
copies data into it. The advantage of the
default constructor is that you
can create, for example, a large array of empty MyString objects very
cheaply, since the size of each object is only one pointer and the only overhead
of the default constructor is that of assigning to zero. The cost of a
MyString only begins to accrue when you concatenate data; at that point
the Mem object is created if it hasn’t been already. However, if
you use the default constructor and never concatenate any data, the destructor
call is still safe because calling delete for
zero is defined such that it does not try to release storage or otherwise cause
problems.
If you look at these two constructors it
might at first seem like this is a prime candidate for default arguments.
However, if you drop the default constructor and write the remaining constructor
with a default argument:
MyString(char* str = "");
everything will work correctly, but
you’ll lose the previous efficiency benefit since a Mem object will
always be created. To get the efficiency back, you must modify the
constructor:
MyString::MyString(char* str) { if(!*str) { // Pointing at an empty string buf = 0; return; } buf = new Mem(strlen(str) + 1); strcpy((char*)buf->pointer(), str); }
This means, in effect, that the default
value becomes a flag that causes a separate piece of code to be executed than if
a non-default value is used. Although it seems innocent enough with a small
constructor like this one, in general this practice can cause problems. If you
have to look for the default rather than treating it as an ordinary
value, that should be a clue that you will end up with effectively two different
functions inside a single function body: one version for the normal case and one
for the default. You might as well split it up into two distinct function bodies
and let the compiler do the selection. This results in a slight (but usually
invisible) increase in efficiency, because the extra argument isn’t passed
and the extra code for the conditional isn’t executed. More importantly,
you are keeping the code for two separate functions in two separate
functions rather than combining them into one using default arguments, which
will result in easier maintainability, especially if the functions are
large.
On the other hand, consider the
Mem class. If you look at the definitions of the two constructors and the
two pointer( ) functions, you can see that using default arguments
in both cases will not cause the member function definitions to change at all.
Thus, the class could easily be:
//: C07:Mem2.h #ifndef MEM2_H #define MEM2_H typedef unsigned char byte; class Mem { byte* mem; int size; void ensureMinSize(int minSize); public: Mem(int sz = 0); ~Mem(); int msize(); byte* pointer(int minSize = 0); }; #endif // MEM2_H ///:~
Notice that a call to
ensureMinSize(0) will always be quite efficient.
Although in both of these cases I based
some of the decision-making process on the issue of
efficiency, you must be careful not to fall into the
trap of thinking only about efficiency (fascinating as it is). The most
important issue in class design is the interface of the class (its public
members, which are available to the client programmer). If these produce a class
that is easy to use and reuse, then you have a success; you can always tune for
efficiency if necessary but the effect of a class that is designed badly because
the programmer is over-focused on efficiency issues can be dire. Your primary
concern should be that the interface makes sense to those who use it and who
read the resulting code. Notice that in MemTest.cpp the usage of
MyString does not change regardless of whether a default constructor is
used or whether the efficiency is high or
low.
As a guideline, you shouldn’t use a
default argument as a flag upon
which to conditionally execute code. You should instead break the function into
two or more overloaded functions if you can. A default argument should be a
value you would ordinarily put in that position. It’s a value that is more
likely to occur than all the rest, so client programmers can generally ignore it
or use it only if they want to change it from the default
value.
The default argument is included to make
function calls easier, especially when those functions have many arguments with
typical values. Not only is it much easier to write the calls, it’s easier
to read them, especially if the class creator can order the arguments so the
least-modified defaults appear latest in the list.
An especially important use of default
arguments is when you start out with a function with a set of arguments, and
after it’s been used for a while you discover you need to add arguments.
By defaulting all the new arguments, you ensure that all client code using the
previous interface is not disturbed.
Solutions to selected exercises
can be found in the electronic document The Thinking in C++ Annotated
Solution Guide, available for a small fee from
www.BruceEckel.com.


Find matching cards
Click to start
GAME OVER
Click to restart
YOU WON!
Click to restart
Time
100
Flips
0


Acceleration and Device Information Hello World
You should tilt the screen and see if the button moves
At the bottom of every page make sure you include the following button:


Hey, it's Cordova!
Don't know how to get started? Check out our
Getting Started Guide
Check your console log for any white-list rejection errors.
Add your allowed
hosts
in Cordova.plist/ExternalHosts (wildcards OK, don't enter the URL scheme)
Click to open ___FILEBASENAME___!
Click to open ___FILEBASENAME___!
Click to open ChildBrowser!
Click to open ChildBrowser!


--- layout: single title: Sponsors permalink: /sponsors ---
Here at CompSoc we are supported by some great companies that are passionate about engaging in student life. We're eternally grateful for their support over the years.


Example Page
NOTICE
This is an important message!
national park faq's
carlsbad
7 weeks in
denali
week 1
National Parks
Arches
Badlands
Carlsbad Caverns
Denali
Everglades
State Parks of Texas
Abilene
Big Bend
Choke Canyon
Davis Mountains
Enchanted Rock
park theme music
This is also very important.
Click to highlight important text.


ABOUT US
CONSULTING
TRAINING
CONTACT
GET IN TOUCH
NEED EMBER.JS CONSULTING? A TRAINING SCHEDULE? JUST WANT TO SAY HULLO? WE'RE LISTENING!
HOW CAN WE HELP?
NAME
EMAIL
MESSAGE


As we got further and further away, it diminished in size. Finally it shrank to the size of a marble, the most beautiful you can imagine.
That beautiful, warm, living object looked so fragile, so delicate, that if you touched it with a finger it would crumble and fall apart. Seeing this has to change a man.
Science has not yet mastered prophecy. We predict too much for the next year and yet far too little for the next 10. We choose to go to the moon in this decade and do the
other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that
challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win.
As we got further and further away, it diminished in size. Finally it shrank to the size of a marble, the most beautiful you can imagine.
That beautiful, warm, living object looked so fragile, so delicate, that if you touched it with a finger it would crumble and fall apart. Seeing this has to change a man.
Science has not yet mastered prophecy. We predict too much for the next year and yet far too little for the next 10. We choose to go to the moon in this decade and do the
other things
Not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that
challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win.


Beta This is a test version of the layout of this page. Take the survey to help us improve it
Guidance
The policy and processes the Skills Funding Agency uses to make qualifications eligible for public funding.
We have removed the requirement for all delivery we fund to be in the form of a qualification. We only require a qualification to be delivered where a learner is exercising their legal entitlement to a first full Level 2 or Level 3 and/or English and maths.
The policy and process for identifying which qualifications are eligible for legal entitlements and through local flexibilities are set out in the documents above.
This guidance explains how and when we will add components to the local flexibility offer for the remainder of 2016 to 2017. Please use the form to confirm the qualifications whose components can be delivered in a standalone context and which you would like us to consider to be included as part of the 2016 to 2017 local flexibility offer
Colleges and training organisations, must check before delivering a component that the:
We have updated the 2016 to 2017 English and maths legal entitlements list to include legacy GCSEs and international GCSEs (counting towards the EBacc) in English and maths.
The guidance document follows Ofqual’s announcement about these qualifications being available for resits in November 2016 and for the last time in summer 2017.
We have updated the 2016 to 2017 Level 2 and 3 legal entitlements list to include:


American footballer set for huge ban after shocking NFL incident
by latest newsAn American football game has ended in chaos, with calls for at least one player to be banned for the entire season.
Pittsburgh Steelers quarterback Mason Rudolph was struck on the head with his own helmet by Cleveland’s Myles Garrett, which had been dislodged moments prior.
Garrett has come under fierce scrutiny already, with some NFL commentators saying it’s “one of the worst things” they’ve ever seen in a game.
There were just seconds remaining in the match, which Cleveland won 21-7, when the incident happened.
Click PLAY below to watch the shocking incident


In Spanish all nouns are masculine or feminine. Usually, nouns that end with an "o" are masculine, and nouns that end with an "a" are feminine. For example, "manzana" (apple) is feminine and "diario" (newspaper) is masculine.
The articles "el" and "un" are used with masculine nouns, and the articles "la" and "una" are used with feminine nouns. "The apple" is "la manzana" and "a newspaper" is "un diario."
Vowels in Spanish can have an accent mark, such as the "u" in "menú" (menu). One use of the accent mark is to indicate which syllable should be stressed in the pronunciation. For example, in "teléfono" (telephone), the second "e" has the most stress.
Accent marks are also used to distinguish homophones. For example, "él" and "el" are homophones because they have the same pronunciation. However, "él" is a masculine pronoun (meaning "he" or "him") and "el" is a masculine article (meaning "the").
"Tú," "usted" and "vos" are different ways of referring to the second person singular (you). "Usted" is the formal way of saying "you," and "vos" is used in informal speech in certain countries instead of "tú."
The three pronouns are synonyms, but they change the way verbs are conjugated. For instance, for the verb "comer" (to eat), it is "tú comes," "usted come," and "vos comés."
The decision of which form of "you" to use is regional and cultural, but you can typically use "usted" when referring to strangers.
Verb conjugation in Spanish is more complicated than in English. In Spanish, the verb endings change in order to describe who is doing the action and when. For example, for "comer," "I eat" is "yo como" and "you eat" is "tú comes."
Because the conjugations indicate who is doing the action, it is usually possible to omit the pronoun. For instance instead of saying "yo como arroz" (I eat rice), you can say "como arroz."
In English, "afternoon" comes before "evening," which in turn comes before "night." In Spanish there are only two words that cover these times of the day: "tarde" which means "afternoon," but overlaps with "evening," and "noche," which means "night" but also overlaps with "evening." Therefore, at 6:30pm it is ok to say either "buenas tardes" or "buenas noches."
Even though "buenos días" literally means "good days," it is used in the mornings to mean "good morning."
Conjugation of 'Hablar'
Present indicative (presente del indicativo):
In Spanish, the most common negative word is "no". As an adverb negating a sentence, it always comes immediately before the verb.
I speak - [Yo] hablo.
I do not speak - [Yo] no hablo .
He is - [Él] es / está.
He is not - [Él] no es / está .
Adjectives. As a general rule, in Spanish adjectives come after the noun they describe, e.g.
An English dog / Un perro inglés
A Spanish horse / Un caballo español
Possessive determiners are adjectives that are used to show ownership, such as "my" in "my dog." There are five possessive determiners in Spanish:
| Spanish | English |
|---|---|
| mi | my |
| tu | your (familiar singular) |
| su | his, her, your (formal), their |
| nuestro | our |
| vuestro | your (familiar plural, used in Spain) |
The first three of these have only two forms, singular and plural:
| Singular | Plural |
|---|---|
| mi | mis |
| tu | tus |
| su | sus |
For example, "my dog" is "mi perro" and "my dogs" is "mis perros."
"Mi", "tu" and "su" do not have masculine and feminine forms, so for example you say "mi gato" and also "mi gata."
Nuestro and vuestro have four forms depending on the gender and number of the noun being referred to:
| Singular Masculine | Plural Masculine | Singular Feminine | Plural Feminine |
|---|---|---|---|
| nuestro | nuestros | nuestra | nuestras |
| vuestro | vuestros | vuestra | vuestras |
For example, it is "nuestro gato," "nuestra gata," "nuestros gatos," and "nuestras gatas."
The determiners above are always used before the noun. Spanish has an additional "long-form" way to describe possession, which usually comes after the noun:
| Spanish | English |
|---|---|
| mío, míos, mía, mías | mine, my |
| tuyo, tuyos, tuya, tuyas | yours, your (familiar singular) |
| suyo, suyos, suya, suyas | his, hers, yours (formal), your (formal), theirs, their |
| nuestro, nuestros, nuestra, nuestras | ours, our |
| vuestro, vuestros, vuestra, vuestras | yours, your (familiar plural, used in Spain) |
"El gato es mío" means "The cat is mine."
Note that the possessive adjectives vary by number and gender. The change is with the nouns they modify, not with the person(s) who possess the object. For example, for a male cat you say "El gato es tuyo" (The cat is yours) regardless of whether you are talking to a man or a woman.
The short form and long forms of nuestro and vuestro and related pronouns are identical. They differ only as to whether they are used before or after the noun.
The two words "tu" and "tú" are pronounced the same. "Tú" is the personal pronoun meaning "you" (informal), and "tu" is the possessive adjective meaning "your" (informal).
In written Spanish, questions should always start with an upside down question mark (¿). For example, to ask “What are you eating?” you would write “¿Qué comes?”
When asking a question, it is possible to place the personal pronoun in different places without affecting the meaning. For example “¿Qué comes tú?” and “¿Tú qué comes?” mean the same thing (and also the same thing as “¿Qué comes?”).
The position of the personal pronoun is sometimes used for emphasis. For example “Tú qué comes” places the emphasis on “you” and would mean something like “You, what are you eating?”
Even native speakers sometimes confuse “por qué” and “porque,” because they sound exactly the same. However, “por qué” means “why” and “porque” means “because.” That is, “por qué” is typically used when asking a question and “porque” is used when answering it.
In Spanish, the verb endings change in order to describe who is doing the action and when. Most verbs are "regular," meaning they change their endings in predictable ways.
| Person | Endings | Examples |
|---|---|---|
| I | -o | yo como, yo leo |
| you (familiar) | -es, -as | tú comes, tú nadas |
| he, she, it, you (formal) | -e, -a | él come, ella nada, usted lee |
| we | -amos, -emos, -imos | nosotros comemos, nosotros nadamos |
| you (plural Latin America) | -en, -an | ustedes comen, ustedes nadan |
| you (plural Spain) | -éis, -áis | vosotros coméis, vosotros nadáis |
| they | -en, -an | ellos comen, ellos nadan |
Although "sí" and "si" sound the same, "sí" (with an accent mark) means "yes" and "si" means "if."
The word for "and" in Spanish is "y," and the word for "or" is "o." However, if the word after "and" starts with an "i" or "hi" (which sounds the same as "i" because the "h" in Spanish is always silent), then you need to use "e" instead of "y." For example "sons and daughters" is "hijos e hijas." Similarly, if the word after "or" starts with "o" or "ho," then you have to use "u" instead of "o." For example, "dog or bear" is "perro u oso."
In Spanish, adjectives have to match the noun they refer to in terms of gender and number. For example, since "vestido" is a masculine noun, you say "el vestido es bonito" (the dress is pretty), but you say "ella es bonita" (she is pretty). Note, however, that not all adjectives change with gender.
Usually, masculine adjectives that end in -o or -os (in the plural) can become feminine by changing the ending to -a or -as. For example, "viejo" (old) becomes "vieja."
Spanish doesn't use suffixes such as "-er" or "-est" to indicate superlatives. Instead, the adverb "más" (more) is used. For example, "she is prettier" would be "ella es más bonita," and "she is the prettiest" would be "ella es la más bonita."
Usually, though not always, adjectives are placed after the noun they refer to. For example, "the red car" is "el coche rojo."
A few adjectives are shortened when they appear before singular nouns. One of the most common is "grande," which is shortened to "gran." For example, you can say "el hombre grande" (the big man) or "el gran hombre."
Demonstrative determiners are used to point at something. In English, they are "this", "that", "these" and "those."
Spanish has three sets of demonstrative determiners, which vary by number and gender, so there are 12 in total:
| Masculine Singular | Masculine Plural | Feminine Singular | Feminine Plural |
|---|---|---|---|
| este (this) | estos (these) | esta (this) | estas (these) |
| ese (that) | esos (those) | esa (that) | esas (those) |
| aquel (that) | aquellos (those) | aquella (that) | aquellas (those) |
It is important to note that the masculine singular forms in the table above don't end in "-o." The words "esto" (this) and "eso" (that) are also demonstrative pronouns, but they are gender neutral and used when the gender of the noun they refer to is unkown. For example, you would say "qué es eso?" (what is that?) when you don't know if the object you're asking about is masculine or feminine.
Both "ese" and "aquel" and their related forms are translated to English as "that" or "those." However, they have slightly different meanings. "Ese" is more common, and usually refers to things that are closer in terms of distance or time. For example, "esos perros" would be "those dogs," whereas "aquellos perros" is closer in meaning to "those dogs over there."
One of the hardest things to learn about Spanish is the distinction between the verbs "ser" and "estar," since in English they both mean "to be."
By now you should be familiar with the conjugations of "ser," such as in "él es un niño" (he is a boy), "yo soy un hombre" (I am a man), and "ustedes son mujeres" (you are women). "Estar" is also an irregular verb, and its different conjugations in the present tense are below:
| Person | Ser | Estar |
|---|---|---|
| yo | soy | estoy |
| tú | eres | estás |
| él/ella/usted | es | está |
| nosotros/nosotras | somos | estamos |
| ustedes/ellos/ellas | son | están |
| vosotros/vosotras | sois | estáis |
"Ser" refers to what something is, while estar refers more to what something does. For example, "estoy enfermo" would mean "I am being sick" or "I am currently sick." On the other hand "soy enfermo" translates to something closer to "I am a sick person" or "I am sickly." Below are more examples:
| Estar | Ser |
|---|---|
| Estoy feliz = I am currently happy | Soy feliz = I am happy by nature |
| Estoy cansada = I am currently tired | Soy cansada = I am a tired person |
| Él está callado = He is being quiet | Él es callado = He is introverted |
You can think of "ser" as being equivalent to "equals." Alternatively, you can think of "estar" as refering to a temporary condition, while "ser" frequently refers to a permanent condition. However there are some exceptions. For example, "ser" is used in expressions of time, such as "son las cuatro de la tarde" (it's 4 in the afternoon). Also, "estar" is used to indicate someone has died, so "he is dead" would be "está muerto."
In English, the words "he" and "I" can be used as subjects (the ones doing the action in a sentence), and they change to "him" and "me" when they are objects (the ones the action is applied to). For example, we say "He likes me" and "I like him." "Me," "him", "her," etc. are called object pronouns.
Objects pronouns can either be direct or indirect. The direct object is the thing or person that is directly receiving the action. For example, "him" is the direct object in "she likes him." The indirect object is the receiver of the direct object. For example, "him" is the indirect object in "she writes him a book."
In English, object pronouns are the same for both direct and indirect objects, but in Spanish they can change.
The object pronouns in Spanish are:
| Subject Pronoun | Direct Object Pronoun | Indirect Object Pronoun |
|---|---|---|
| yo | me (me/to me) | |
| tú | te (you/to you) | |
|
él
usted (masc) |
lo (him, it; you) | le (to him/her/it/you) |
|
ella
usted (fem) |
la (her, it; you) | |
| nosotros/nosotras | nos (us/to us) | |
| vosotros/vosotras | os (you/to you) | |
|
ellos
ustedes (masc) |
los (them; you) | les (to them/you) |
|
ellas
ustedes (fem) |
las (them; you) |
Unlike in English where object pronouns go after the verb ("I see him"), Spanish object pronouns are generally placed directly before the verb. Below are some examples:
| English | Spanish |
|---|---|
| You write me a book | Me escribes un libro |
| I see you from my house | Te veo desde mi casa |
| I see him | Yo lo veo |
| I see her | Yo la veo |
| She writes a book to him | Ella le escribe un libro a él |
| He sees us | Él nos ve |
| I see them | Yo los veo a ellos/Yo las veo a ellas |
| I write them a book | Yo les escribo un libro a ellos/ellas |
Further clarification about who the sentence is talking about can always be added. For example, "I see him" can be translated as "Yo lo veo" and "Yo lo veo a él." Sometimes this clarification is necessary in order to remove ambiguity, while other times it is simply redundant. For example, "Yo los veo" is ambiguous because it could mean "I see them" or "I see you guys," so unless it is clear from context you would say "Yo los veo a ellos" or "Yo los veo a ustedes." However, "él nos ve" and "él nos ve a nosotros" mean exactly the same thing, since there is no ambiguity with "nos."
The past tense is used to refer to actions that occurred in the past. The past tense in Spanish has two predictable verb endings: one for – ar verbs, such as habl ar ( to speak ), and another for – er and – ir verbs, such as com er ( to eat ) and escrib ir ( to write ). It is important to point out that many verbs in Spanish have an irregular past tense conjugation. For those irregular cases, the best way to learn their conjugation is with memorization and practice.
Regular – ar verbs are conjugated as follows:
| Person | Endings | Examples |
|---|---|---|
| I | -é | yo hablé |
| you (familiar) | -aste | tú hablaste |
| he, she, it, you (formal) | -ó | él habló, ella habló, usted habló |
| we | -amos | nosotros hablamos |
| you (plural Latin America) | -aron | ustedes hablaron |
| you (plural Spain) | -asteis | vosotros hablasteis |
| they | -aron | ellos hablaron |
Regular – er and – ir verbs are conjugated as follows:
| Person | Endings | Examples |
|---|---|---|
| I | -í | yo comí, yo escribí |
| you (familiar) | -iste | tú comiste, tú escribiste |
| he, she, it, you (formal) | -ió | él comió, ella escribió, usted comió |
| we | -imos | nosotros comimos, nosotras escribimos |
| you (plural Latin America) | -ieron | ustedes comieron, ustedes escribieron |
| you (plural Spain) | -isteis | vosotras comisteis, vosotros escribisteis |
| they | -ieron | ellos comieron, ellas escribieron |
There are two future tenses in Spanish. The easier one to learn is the so called "phrasal future," in which the verb "ir" (to go) is used an auxiliary. Much like in English, where you can express future by saying "I am going to run tomorrow," in Spanish you can say "Voy a correr mañana." Thus, the future is formed by conjugating the irregular verb "ir" to the appropriate person, then adding the word "a," and then the infinitive of the main verb. Below are the conjugations of the verb "ir," followed by examples of phrasal future.
| Person | Conjugation |
|---|---|
| yo | voy |
| tú | vas |
| él/ella/usted | va |
| nosotros/nosotras | vamos |
| ustedes/ellos/ellas | van |
| vosotros/vosotras | vais |
| Spanish | English |
|---|---|
| Yo voy a pensar | I am going to think |
| Tú vas a comer | You are going to eat |
| Ella va a trabajar | She is going to work |
| Nosotros vamos a comer | We are going to eat |
| Ellas van a trabajar | They are going to work |


| Package | Description |
|---|---|
| org.tensorflow.distruntime | |
| org.tensorflow.framework |
| Modifier and Type | Method and Description |
|---|---|
TensorProtoOrBuilder |
RunCallableRequest.getFeedOrBuilder(int index)
Values of the tensors passed as arguments to the callable, in the order
defined in the CallableOptions.feed field passed to MakeCallable.
|
TensorProtoOrBuilder |
RunCallableRequest.Builder.getFeedOrBuilder(int index)
Values of the tensors passed as arguments to the callable, in the order
defined in the CallableOptions.feed field passed to MakeCallable.
|
TensorProtoOrBuilder |
RunCallableRequestOrBuilder.getFeedOrBuilder(int index)
Values of the tensors passed as arguments to the callable, in the order
defined in the CallableOptions.feed field passed to MakeCallable.
|
TensorProtoOrBuilder |
RunCallableResponse.getFetchOrBuilder(int index)
Values of the tensors returned by the callable, in the order defined in the
CallableOptions.fetch field passed to MakeCallable.
|
TensorProtoOrBuilder |
RunCallableResponse.Builder.getFetchOrBuilder(int index)
Values of the tensors returned by the callable, in the order defined in the
CallableOptions.fetch field passed to MakeCallable.
|
TensorProtoOrBuilder |
RunCallableResponseOrBuilder.getFetchOrBuilder(int index)
Values of the tensors returned by the callable, in the order defined in the
CallableOptions.fetch field passed to MakeCallable.
|
TensorProtoOrBuilder |
RecvTensorResponse.getTensorOrBuilder()
The tensor as a proto.
|
TensorProtoOrBuilder |
RecvTensorResponse.Builder.getTensorOrBuilder()
The tensor as a proto.
|
TensorProtoOrBuilder |
RecvTensorResponseOrBuilder.getTensorOrBuilder()
The tensor as a proto.
|
| Modifier and Type | Method and Description |
|---|---|
List<? extends TensorProtoOrBuilder> |
RunCallableRequest.getFeedOrBuilderList()
Values of the tensors passed as arguments to the callable, in the order
defined in the CallableOptions.feed field passed to MakeCallable.
|
List<? extends TensorProtoOrBuilder> |
RunCallableRequest.Builder.getFeedOrBuilderList()
Values of the tensors passed as arguments to the callable, in the order
defined in the CallableOptions.feed field passed to MakeCallable.
|
List<? extends TensorProtoOrBuilder> |
RunCallableRequestOrBuilder.getFeedOrBuilderList()
Values of the tensors passed as arguments to the callable, in the order
defined in the CallableOptions.feed field passed to MakeCallable.
|
List<? extends TensorProtoOrBuilder> |
RunCallableResponse.getFetchOrBuilderList()
Values of the tensors returned by the callable, in the order defined in the
CallableOptions.fetch field passed to MakeCallable.
|
List<? extends TensorProtoOrBuilder> |
RunCallableResponse.Builder.getFetchOrBuilderList()
Values of the tensors returned by the callable, in the order defined in the
CallableOptions.fetch field passed to MakeCallable.
|
List<? extends TensorProtoOrBuilder> |
RunCallableResponseOrBuilder.getFetchOrBuilderList()
Values of the tensors returned by the callable, in the order defined in the
CallableOptions.fetch field passed to MakeCallable.
|
| Modifier and Type | Class and Description |
|---|---|
class |
TensorProto
Protocol buffer representing a tensor.
|
static class |
TensorProto.Builder
Protocol buffer representing a tensor.
|
| Modifier and Type | Method and Description |
|---|---|
TensorProtoOrBuilder |
AttrValue.getTensorOrBuilder()
"tensor"
.tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
AttrValue.Builder.getTensorOrBuilder()
"tensor"
.tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
AttrValueOrBuilder.getTensorOrBuilder()
"tensor"
.tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
NamedTensorProto.getTensorOrBuilder()
The client can populate a TensorProto using a tensorflow::Tensor`, or
directly using the protobuf field accessors.
|
TensorProtoOrBuilder |
NamedTensorProto.Builder.getTensorOrBuilder()
The client can populate a TensorProto using a tensorflow::Tensor`, or
directly using the protobuf field accessors.
|
TensorProtoOrBuilder |
NamedTensorProtoOrBuilder.getTensorOrBuilder()
The client can populate a TensorProto using a tensorflow::Tensor`, or
directly using the protobuf field accessors.
|
TensorProtoOrBuilder |
Summary.ValueOrBuilder.getTensorOrBuilder()
.tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
Summary.Value.getTensorOrBuilder()
.tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
Summary.Value.Builder.getTensorOrBuilder()
.tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
AttrValue.ListValueOrBuilder.getTensorOrBuilder(int index)
"list(tensor)"
repeated .tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
AttrValue.ListValue.getTensorOrBuilder(int index)
"list(tensor)"
repeated .tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
AttrValue.ListValue.Builder.getTensorOrBuilder(int index)
"list(tensor)"
repeated .tensorflow.TensorProto tensor = 8; |
TensorProtoOrBuilder |
VariantTensorDataProto.getTensorsOrBuilder(int index)
Tensors contained within objects being serialized.
|
TensorProtoOrBuilder |
VariantTensorDataProto.Builder.getTensorsOrBuilder(int index)
Tensors contained within objects being serialized.
|
TensorProtoOrBuilder |
VariantTensorDataProtoOrBuilder.getTensorsOrBuilder(int index)
Tensors contained within objects being serialized.
|
| Modifier and Type | Method and Description |
|---|---|
List<? extends TensorProtoOrBuilder> |
AttrValue.ListValueOrBuilder.getTensorOrBuilderList()
"list(tensor)"
repeated .tensorflow.TensorProto tensor = 8; |
List<? extends TensorProtoOrBuilder> |
AttrValue.ListValue.getTensorOrBuilderList()
"list(tensor)"
repeated .tensorflow.TensorProto tensor = 8; |
List<? extends TensorProtoOrBuilder> |
AttrValue.ListValue.Builder.getTensorOrBuilderList()
"list(tensor)"
repeated .tensorflow.TensorProto tensor = 8; |
List<? extends TensorProtoOrBuilder> |
VariantTensorDataProto.getTensorsOrBuilderList()
Tensors contained within objects being serialized.
|
List<? extends TensorProtoOrBuilder> |
VariantTensorDataProto.Builder.getTensorsOrBuilderList()
Tensors contained within objects being serialized.
|
List<? extends TensorProtoOrBuilder> |
VariantTensorDataProtoOrBuilder.getTensorsOrBuilderList()
Tensors contained within objects being serialized.
|
Copyright © 2020. All rights reserved.


Auth object
Every object could be requested from this Auth object and any action
could start from this object using cascading style. Please check
vignette("api")
for more information.
from
[character] Authentication method. Could be "direct"
(pass the credential information to the arguments directly),
"env"
(read from pre-set system environment variables),
or "file"
(read configurations from a credentials file).
Default is "direct"
.
platform
[character] The platform to use.
If platform
and url
are both not specified,
the default is "cgc"
(Cancer Genomics Cloud).
Other possible values include
"aws-us"
(Seven Bridges Platform - US),
"aws-eu"
(Seven Bridges Platform - EU),
"ali-cn"
(Seven Bridges Platform - China),
"cavatica"
(Cavatica), and
"f4c"
(BioData Catalyst Powered by Seven Bridges).
url
[character] Base URL for API. Please only use this when you
want to specify a platform that is not in the platform
list
above, and also leaving platform
unspecified.
token
[character] Your authentication token.
sysenv_url
Name of the system environment variable storing
the API base URL. By default: "SB_API_ENDPOINT"
.
sysenv_token
Name of the system environment variable storing
the auth token. By default: "SB_AUTH_TOKEN"
.
config_file
[character] Location of the user configuration file.
By default: "~/.sevenbridges/credentials"
.
profile_name
[character] Profile name in the user configuration file.
The default value is "default"
.
fs
FS object, for mount and unmount file system.
authorization
Logical. Is the token
an API
auth token (FALSE
) or an access token from the
Seven Bridges single sign-on (TRUE
)?
api(
...,
limit = getOption("sevenbridges")$limit,
offset = getOption("sevenbridges")$offset,
fields = NULL,
complete = FALSE
)
This call returns all API paths, and pass arguments to api() function with input token and url automatically
billing(id = NULL, breakdown = FALSE, ...)
If no id provided, This call returns a list of paths used to access billing information via the API. else, This call lists all your billing groups, including groups that are pending or have been disabled. If breakdown = TRUE, This call returns a breakdown of spending per-project for the billing group specified by billing_group. For each project that the billing group is associated with, information is shown on the tasks run, including their initiating user (the runner), start and end times, and cost.
bulk_file_copy(file_ids, project, ...)
Copy files between projects in a batch.
bulk_file_delete(file_ids, ...)
Delete multiple files.
bulk_file_edit(...)
Edit details of multiple files (preserving the omitted fields).
bulk_file_get(file_ids, ...)
Get details of multiple files.
bulk_file_update(...)
Update details of multiple files (removing the omitted fields).
bulk_task_get(task_ids, ...)
Get details of multiple tasks.
bulk_volume_export(...)
Bulk export to volumes.
bulk_volume_get_export(...)
Get details of a bulk export job.
bulk_volume_get_import(...)
Get details of a bulk import job.
bulk_volume_import(...)
Bulk import from volumes.
division(id = NULL, ...)
List all divisions or get details of a division.
file(
name = NULL,
id = NULL,
project = NULL,
exact = FALSE,
detail = FALSE,
metadata = list(),
origin.task = NULL,
tag = NULL,
complete = FALSE,
search.engine = c("server", "brute"),
...
)
This call returns a list of all files in a specified project that you can access. For each file, the call returns: 1) Its ID 2) Its filename The project is specified as a query parameter in the call.
invoice(id = NULL, ...)
If no id provided, This call returns a list of invoices, with information about each, including whether or not the invoice is pending and the billing period it covers. The call returns information about all your available invoices, unless you use the query parameter bg_id to specify the ID of a particular billing group, in which case it will return the invoice incurred by that billing group only. If id was provided, This call retrieves information about a selected invoice, including the costs for analysis and storage, and the invoice period.
project(
name = NULL,
id = NULL,
index = NULL,
ignore.case = TRUE,
exact = FALSE,
owner = NULL,
detail = FALSE,
...
)
If no id or name provided, this call returns a list of all projects you are a member of. Each project's project_id and URL on the platform will be returned. If name or id provided, we do a match search the list.
project_new(
name = NULL,
billing_group_id = NULL,
description = name,
tags = list(),
type = "v2",
locked = FALSE,
use_interruptible_instances = FALSE,
...
)
Create new projects, required parameters: name, billing_group_id, optional parameteres: tags, description, type, and settings.
project_owner(owner = NULL, ...)
List the projects owned by and accessible to a particular user. Each project's ID and URL will be returned.
rate_limit(...)
This call returns information about your current rate limit. This is the number of API calls you can make in one hour.
send_feedback(
text,
type = c("idea", "thought", "problem"),
referrer = NULL,
...
)
Send feedback to Seven Bridges.
user(username = NULL, ...)
This call returns information about the authenticated user.
volume(
name = NULL,
id = NULL,
index = NULL,
ignore.case = TRUE,
exact = FALSE,
detail = FALSE,
...
)
If no id or name provided, this call returns a list of all volumes you are a member of. If name or id provided, we did a match search the list.
# Direct authentication (default) # replace with your auth token token <- "your_token" a <- Auth(platform = "cgc", token = token)#>if (FALSE) { # Authentication with environment variables # This will read system environments variables # `SB_API_ENDPOINT` and `SB_AUTH_TOKEN` by default a <- Auth(from = "env") # Authentication with user configuration file # This will load profile `default` from config # file `~/.sevenbridges/credentials` by default a <- Auth(from = "file") }


{% include 'header.html' %} {% include 'nav.html' %}
Blog about my internship at Autodesk
Article for CS class
Article for CS class.
Article for personal project


Class Precedence List:
Description:
Hash tables provide a way of mapping any object (a key) to an associated object (a value).
See Also:
Section 18.1 (Hash Table Concepts), Section <IP_ADDRESS> (Printing Other Objects)
Notes:
The intent is that this mapping be implemented by a hashing mechanism, such as that described in Section 6.4 ``Hashing'' of The Art of Computer Programming, Volume 3 (pp506-549). In spite of this intent, no conforming implementation is required to use any particular technique to implement the mapping.


This application was as a project (along with other Rails based applications) while I studied at Bloc. It uses the many featues provided by Ruby on Rails to allow for and MVC application that has user authentication, data varification, data seeding for development, user profiles, user roles, it's own JSON API A user can create an account, create posts, comment on posts, upvote, downvote and favorite comments and posts, search posts based on tags.


This application requires JavaScript in order to run on your browser. Please configure your browser to allow JavaScript.


The MDC Snackbar component is a spec-aligned snackbar/toast component adhering to the Material Design snackbars & toasts requirements.
Google Material Components documentation| Method | |
|---|---|
show(data, dismissOnAction: boolean = true) |
Show snackbar using argument properties. Argument 'dismissOnAction' defaults to true and is optional. |
{ console.log('Action button pressed!') } : null }, this.isDismissOnAction);]]>


Mappers support the concept of configurable cascade behavior on
relationship()
constructs. This refers
to how operations performed on a “parent” object relative to a
particular Session
should be propagated to items
referred to by that relationship (e.g. “child” objects), and is
affected by the relationship.cascade
option.
The default behavior of cascade is limited to cascades of the so-called save-update and merge settings. The typical “alternative” setting for cascade is to add the delete and delete-orphan options; these settings are appropriate for related objects which only exist as long as they are attached to their parent, and are otherwise deleted.
Cascade behavior is configured using the
cascade
option on
relationship()
:
class Order(Base):
__tablename__ = 'order'
items = relationship("Item", cascade="all, delete-orphan")
customer = relationship("User", cascade="save-update")
To set cascades on a backref, the same flag can be used with the
backref()
function, which ultimately feeds
its arguments back into relationship()
:
class Item(Base):
__tablename__ = 'item'
order = relationship("Order",
backref=backref("items", cascade="all, delete-orphan")
)
The Origins of Cascade
SQLAlchemy’s notion of cascading behavior on relationships, as well as the options to configure them, are primarily derived from the similar feature in the Hibernate ORM; Hibernate refers to “cascade” in a few places such as in Example: Parent/Child. If cascades are confusing, we’ll refer to their conclusion, stating “The sections we have just covered can be a bit confusing. However, in practice, it all works out nicely.”
The default value of cascade
is save-update, merge
.
The typical alternative setting for this parameter is either
all
or more commonly all, delete-orphan
. The all
symbol
is a synonym for save-update, merge, refresh-expire, expunge, delete
,
and using it in conjunction with delete-orphan
indicates that the child
object should follow along with its parent in all cases, and be deleted once
it is no longer associated with that parent.
The list of available values which can be specified for
the cascade
parameter are described in the following subsections.
save-update
cascade indicates that when an object is placed into a
Session
via Session.add()
, all the objects associated
with it via this relationship()
should also be added to that
same Session
. Suppose we have an object user1
with two
related objects address1
, address2
:
>>> user1 = User()
>>> address1, address2 = Address(), Address()
>>> user1.addresses = [address1, address2]
If we add user1
to a Session
, it will also add
address1
, address2
implicitly:
>>> sess = Session()
>>> sess.add(user1)
>>> address1 in sess
True
save-update
cascade also affects attribute operations for objects
that are already present in a Session
. If we add a third
object, address3
to the user1.addresses
collection, it
becomes part of the state of that Session
:
>>> address3 = Address()
>>> user1.append(address3)
>>> address3 in sess
>>> True
save-update
has the possibly surprising behavior which is that
persistent objects which were removed from a collection
or in some cases a scalar attribute
may also be pulled into the Session
of a parent object; this is
so that the flush process may handle that related object appropriately.
This case can usually only arise if an object is removed from one Session
and added to another:
>>> user1 = sess1.query(User).filter_by(id=1).first()
>>> address1 = user1.addresses[0]
>>> sess1.close() # user1, address1 no longer associated with sess1
>>> user1.addresses.remove(address1) # address1 no longer associated with user1
>>> sess2 = Session()
>>> sess2.add(user1) # ... but it still gets added to the new session,
>>> address1 in sess2 # because it's still "pending" for flush
True
The save-update
cascade is on by default, and is typically taken
for granted; it simplifies code by allowing a single call to
Session.add()
to register an entire structure of objects within
that Session
at once. While it can be disabled, there
is usually not a need to do so.
One case where save-update
cascade does sometimes get in the way is in that
it takes place in both directions for bi-directional relationships, e.g.
backrefs, meaning that the association of a child object with a particular parent
can have the effect of the parent object being implicitly associated with that
child object’s Session
; this pattern, as well as how to modify its
behavior using the cascade_backrefs
flag,
is discussed in the section Controlling Cascade on Backrefs.
The delete
cascade indicates that when a “parent” object
is marked for deletion, its related “child” objects should also be marked
for deletion. If for example we we have a relationship User.addresses
with delete
cascade configured:
class User(Base):
# ...
addresses = relationship("Address", cascade="save-update, merge, delete")
If using the above mapping, we have a User
object and two
related Address
objects:
>>> user1 = sess.query(User).filter_by(id=1).first()
>>> address1, address2 = user1.addresses
If we mark user1
for deletion, after the flush operation proceeds,
address1
and address2
will also be deleted:
>>> sess.delete(user1)
>>> sess.commit()
DELETE FROM address WHERE address.id = ?
((1,), (2,))
DELETE FROM user WHERE user.id = ?
(1,)
COMMIT
Alternatively, if our User.addresses
relationship does not have
delete
cascade, SQLAlchemy’s default behavior is to instead de-associate
address1
and address2
from user1
by setting their foreign key
reference to NULL
. Using a mapping as follows:
class User(Base):
# ...
addresses = relationship("Address")
Upon deletion of a parent User
object, the rows in address
are not
deleted, but are instead de-associated:
>>> sess.delete(user1)
>>> sess.commit()
UPDATE address SET user_id=? WHERE address.id = ?
(None, 1)
UPDATE address SET user_id=? WHERE address.id = ?
(None, 2)
DELETE FROM user WHERE user.id = ?
(1,)
COMMIT
delete
cascade is more often than not used in conjunction with
delete-orphan cascade, which will emit a DELETE for the related
row if the “child” object is deassociated from the parent. The combination
of delete
and delete-orphan
cascade covers both situations where
SQLAlchemy has to decide between setting a foreign key column to NULL versus
deleting the row entirely.
ORM-level “delete” cascade vs. FOREIGN KEY level “ON DELETE” cascade
The behavior of SQLAlchemy’s “delete” cascade has a lot of overlap with the
ON DELETE CASCADE
feature of a database foreign key, as well
as with that of the ON DELETE SET NULL
foreign key setting when “delete”
cascade is not specified. Database level “ON DELETE” cascades are specific to the
“FOREIGN KEY” construct of the relational database; SQLAlchemy allows
configuration of these schema-level constructs at the DDL level
using options on ForeignKeyConstraint
which are described
at ON UPDATE and ON DELETE.
It is important to note the differences between the ORM and the relational database’s notion of “cascade” as well as how they integrate:
A database level ON DELETE
cascade is configured effectively
on the many-to-one side of the relationship; that is, we configure
it relative to the FOREIGN KEY
constraint that is the “many” side
of a relationship. At the ORM level, this direction is reversed.
SQLAlchemy handles the deletion of “child” objects relative to a
“parent” from the “parent” side, which means that delete
and
delete-orphan
cascade are configured on the one-to-many
side.
Database level foreign keys with no ON DELETE
setting
are often used to prevent a parent
row from being removed, as it would necessarily leave an unhandled
related row present. If this behavior is desired in a one-to-many
relationship, SQLAlchemy’s default behavior of setting a foreign key
to NULL
can be caught in one of two ways:
- The easiest and most common is just to set the foreign-key-holding column to
NOT NULL
at the database schema level. An attempt by SQLAlchemy to set the column to NULL will fail with a simple NOT NULL constraint exception.- The other, more special case way is to set the
passive_deletes
flag to the string"all"
. This has the effect of entirely disabling SQLAlchemy’s behavior of setting the foreign key column to NULL, and a DELETE will be emitted for the parent row without any affect on the child row, even if the child row is present in memory. This may be desirable in the case when database-level foreign key triggers, either specialON DELETE
settings or otherwise, need to be activated in all cases when a parent row is deleted.
Database level ON DELETE
cascade is vastly more efficient
than that of SQLAlchemy. The database can chain a series of cascade
operations across many relationships at once; e.g. if row A is deleted,
all the related rows in table B can be deleted, and all the C rows related
to each of those B rows, and on and on, all within the scope of a single
DELETE statement. SQLAlchemy on the other hand, in order to support
the cascading delete operation fully, has to individually load each
related collection in order to target all rows that then may have further
related collections. That is, SQLAlchemy isn’t sophisticated enough
to emit a DELETE for all those related rows at once within this context.
SQLAlchemy doesn’t need to be this sophisticated, as we instead provide
smooth integration with the database’s own ON DELETE
functionality,
by using the passive_deletes
option in conjunction
with properly configured foreign key constraints. Under this behavior,
SQLAlchemy only emits DELETE for those rows that are already locally
present in the Session
; for any collections that are unloaded,
it leaves them to the database to handle, rather than emitting a SELECT
for them. The section Using Passive Deletes provides an example of this use.
While database-level ON DELETE
functionality works only on the “many”
side of a relationship, SQLAlchemy’s “delete” cascade
has limited ability to operate in the reverse direction as well,
meaning it can be configured on the “many” side to delete an object
on the “one” side when the reference on the “many” side is deleted. However
this can easily result in constraint violations if there are other objects
referring to this “one” side from the “many”, so it typically is only
useful when a relationship is in fact a “one to one”. The
single_parent
flag should be used to establish
an in-Python assertion for this case.
When using a relationship()
that also includes a many-to-many
table using the secondary
option, SQLAlchemy’s
delete cascade handles the rows in this many-to-many table automatically.
Just like, as described in Deleting Rows from the Many to Many Table,
the addition or removal of an object from a many-to-many collection
results in the INSERT or DELETE of a row in the many-to-many table,
the delete
cascade, when activated as the result of a parent object
delete operation, will DELETE not just the row in the “child” table but also
in the many-to-many table.
delete-orphan
cascade adds behavior to the delete
cascade,
such that a child object will be marked for deletion when it is
de-associated from the parent, not just when the parent is marked
for deletion. This is a common feature when dealing with a related
object that is “owned” by its parent, with a NOT NULL foreign key,
so that removal of the item from the parent collection results
in its deletion.
delete-orphan
cascade implies that each child object can only
have one parent at a time, so is configured in the vast majority of cases
on a one-to-many relationship. Setting it on a many-to-one or
many-to-many relationship is more awkward; for this use case,
SQLAlchemy requires that the relationship()
be configured with the single_parent
argument,
establishes Python-side validation that ensures the object
is associated with only one parent at a time.
merge
cascade indicates that the Session.merge()
operation should be propagated from a parent that’s the subject
of the Session.merge()
call down to referred objects.
This cascade is also on by default.
refresh-expire
is an uncommon option, indicating that the
Session.expire()
operation should be propagated from a parent
down to referred objects. When using Session.refresh()
,
the referred objects are expired only, but not actually refreshed.
expunge
cascade indicates that when the parent object is removed
from the Session
using Session.expunge()
, the
operation should be propagated down to referred objects.
The save-update cascade by default takes place on attribute change events emitted from backrefs. This is probably a confusing statement more easily described through demonstration; it means that, given a mapping such as this:
mapper(Order, order_table, properties={
'items' : relationship(Item, backref='order')
})
If an Order
is already in the session, and is assigned to the order
attribute of an Item
, the backref appends the Item
to the items
collection of that Order
, resulting in the save-update
cascade taking
place:
>>> o1 = Order()
>>> session.add(o1)
>>> o1 in session
True
>>> i1 = Item()
>>> i1.order = o1
>>> i1 in o1.items
True
>>> i1 in session
True
This behavior can be disabled using the cascade_backrefs
flag:
mapper(Order, order_table, properties={
'items' : relationship(Item, backref='order',
cascade_backrefs=False)
})
So above, the assignment of i1.order = o1
will append i1
to the items
collection of o1
, but will not add i1
to the session. You can, of
course, add()
i1
to the session at a later point. This
option may be helpful for situations where an object needs to be kept out of a
session until it’s construction is completed, but still needs to be given
associations to objects which are already persistent in the target session.


VEX
The VEX Robotics Design System offers students an exciting platform for learning about areas rich with career opportunities spanning science, technology, engineering and math (STEM). These are just a few of the many fields students can explore by creating with VEX Robotics technology. Beyond science and engineering principles, a VEX Robotics project encourages teamwork, leadership and problem solving among groups. It also allows educators to easily customize projects to meet the level of students' abilities. The affordable VEX platform is expanding rapidly and is now found in middle schools, high schools and university labs around the globe. Robotics hobbyists also appreciate the advanced capabilities of the VEX System.
Check out more at vexrobotics.com


{% extends 'base.html' %} {% import 'macros.html' as macro %} {% block content %} {{ super() }}
{{pitch.pitch_content}}
Written by: {{pitch.user.username}} Comment


My name is kriis sopian i was born out of subang,west java Indonesia.I started as a web developer in 2019 when i was in the 1st class of the high school in the subang.
I went to school at SMKN 1 Subang majoring in software engineering and that's where i started learning how to set up websites,design and other.


Fly with Taylor Today! Anywhere within the Tri State Area for an affordable price
Flight Check-In
Digital Check-in
Checking in with Digital Credentials and compatible Digital Wallet is fast and efficient.
Manual
If you dont have access to Digital Credentials, you may still check-in by entering your information.
Because of the regulatory requirements your information must be passed to external systems for verification. This will result in a $25 charge.
Agree


Manage Users Instructions
- Select the name of the user whose information you
would like to view or edit and click Submit.
- The current password displayed in the password text
field can be modified and or changed by selecting the text
field and modifying as needed. After selecting Submit, the new
password will be changed to the updated text within the
password text box or kept the same if no modifications were
made.
- To modify the learner_preference.audio_level select
the audio_level preference text box and enter a real number
0..*.
- To update the cmi.learner_preference.language select
the language text box and enter a valid language code.
- To update the cmi.learner_preference.delivery_speed
select the delivery speed text box and enter a valid real
number 0..*.
- To update the cmi.learner_preference.audio_captioning
select the audio_captioning text box and enter a valid choice.
- -1 represents the "off" state
- 0 represents "no change" state
- 1 represents the "on" state
-
To modify the users access rights, select either Admin or User
from the dropdown control.
- Click Submit.
|


Hint:You will have to input three measurements of the shape in numeric value and submit to get a response.
An equilateral triangle is a triangle that has all the three sides with the same length.
An isosceles triangle is a triangle that has (at least) two equal side lengths.
A scalene triangle is a triangle that does'nt have any side lengths equal to the other.
NOTE:The sum of any two sides of the triangle must be greater than the third side.


{{play_text}}
Chat
Enter your name
Connect
Messages
{{message.who}}: {{message.what}}
Players Online:
{{player.name}}[{{player.id}}] is online.
Popular Games
IN WORK IN WORK IN WORK IN WORK IN WORK IN WORK


About
The Helping Hand is a non profit organization that is being run in collaborration with the Government of India to provide you with all the assistance you need in this lockdown period. Our services extend all the way from helping you acquire daily neccessities to helping you put in requests for immedate transport or e-passes.
Our organization consists from the people who have opted to stay on the frontlines in our fight against this virus, irrespective of caste, creed, colour and social status. We accept help with open hands from all corners of the world, so everyone is welcome to do their part in this struggle. Whether it's safety, assistance or a sense of duty you seek, we will always be here to offer you a helping hand.
Services
Our organization acts as a for you to interact with the various government services, NGO's, Online shopping platforms and Charitable trusts. Here is a list of the services we can connect you to:
Advanced No-Contact Delivery
Online shopping made safer with drone dropoffs from delivery vehicles. Done in collaboration with all engineering colleges of India that have developed drones as final year projects, Amazon and Flipkart.
Fact Verification
THH has established a partnership with Verify.net, an online fact verification service with which you can check whether the message you recieve via social media are true or not. The results will arrive as an email to the mail ID provided when posting the question.
General Awareness
Get to know general information about what the corona virus is, how it spreads, what safety measures can be taken and statistics of the infection and recovery rates all over India from the Ministry of Health and Family Welfare.


Professional Services
We will help you plan, design, implement, operate, and manage your network protection solutions
Outsourcing
Maintain the operational aspects of your network protection solutions by utilizing the services of our onsite or remote engineers
Technologies
Our Areas of ExpertiseSymantec
Symantec products experts of Network Protection product line: ProxySG, ASG, CA, SSLv, Security Analytics and WSS
Redhat Enterprise Linux
Redhat Enterprise Linux, the most popular Linux distribution for business and enterprise use.
Python
Python Development and Automation scripts
Redhat Ansible
Ansible automation framework playbooks
Bash scripting
Bash scripting for task automation
PfSense
PfSense network firewall


Terms and Conditions
Welcome to TOM: The Online Marketplace!
These terms and conditions outline the rules and regulations for the use of The Online Marketplace's Website, located at www.theonlinemarketplace.com.
By accessing this website we assume you accept these terms and conditions. Do not continue to use TOM: The Online Marketplace if you do not agree to take all of the terms and conditions stated on this page. Our Terms and Conditions were created with the help of the Terms And Conditions Generator and the Free Terms & Conditions Generator.
The following terminology applies to these Terms and Conditions, Privacy Statement and Disclaimer Notice and all Agreements: "Client", "You" and "Your" refers to you, the person log on this website and compliant to the Company’s terms and conditions. "The Company", "Ourselves", "We", "Our" and "Us", refers to our Company. "Party", "Parties", or "Us", refers to both the Client and ourselves. All terms refer to the offer, acceptance and consideration of payment necessary to undertake the process of our assistance to the Client in the most appropriate manner for the express purpose of meeting the Client’s needs in respect of provision of the Company’s stated services, in accordance with and subject to, prevailing law of Netherlands. Any use of the above terminology or other words in the singular, plural, capitalization and/or he/she or they, are taken as interchangeable and therefore as referring to same.
Cookies
We employ the use of cookies. By accessing TOM: The Online Marketplace, you agreed to use cookies in agreement with the The Online Marketplace's Privacy Policy.
Most interactive websites use cookies to let us retrieve the user’s details for each visit. Cookies are used by our website to enable the functionality of certain areas to make it easier for people visiting our website. Some of our affiliate/advertising partners may also use cookies.
License
Unless otherwise stated, The Online Marketplace and/or its licensors own the intellectual property rights for all material on TOM: The Online Marketplace. All intellectual property rights are reserved. You may access this from TOM: The Online Marketplace for your own personal use subjected to restrictions set in these terms and conditions.
You must not:
- Republish material from TOM: The Online Marketplace
- Sell, rent or sub-license material from TOM: The Online Marketplace
- Reproduce, duplicate or copy material from TOM: The Online Marketplace
- Redistribute content from TOM: The Online Marketplace
This Agreement shall begin on the date hereof.
Parts of this website offer an opportunity for users to post and exchange opinions and information in certain areas of the website. The Online Marketplace does not filter, edit, publish or review Comments prior to their presence on the website. Comments do not reflect the views and opinions of The Online Marketplace,its agents and/or affiliates. Comments reflect the views and opinions of the person who post their views and opinions. To the extent permitted by applicable laws, The Online Marketplace shall not be liable for the Comments or for any liability, damages or expenses caused and/or suffered as a result of any use of and/or posting of and/or appearance of the Comments on this website.
The Online Marketplace reserves the right to monitor all Comments and to remove any Comments which can be considered inappropriate, offensive or causes breach of these Terms and Conditions.
You warrant and represent that:
- You are entitled to post the Comments on our website and have all necessary licenses and consents to do so;
- The Comments do not invade any intellectual property right, including without limitation copyright, patent or trademark of any third party;
- The Comments do not contain any defamatory, libelous, offensive, indecent or otherwise unlawful material which is an invasion of privacy
- The Comments will not be used to solicit or promote business or custom or present commercial activities or unlawful activity.
You hereby grant The Online Marketplace a non-exclusive license to use, reproduce, edit and authorize others to use, reproduce and edit any of your Comments in any and all forms, formats or media.
Hyperlinking to our Content
The following organizations may link to our Website without prior written approval:
- Government agencies;
- Search engines;
- News organizations;
- Online directory distributors may link to our Website in the same manner as they hyperlink to the Websites of other listed businesses; and
- System wide Accredited Businesses except soliciting non-profit organizations, charity shopping malls, and charity fundraising groups which may not hyperlink to our Web site.
These organizations may link to our home page, to publications or to other Website information so long as the link: (a) is not in any way deceptive; (b) does not falsely imply sponsorship, endorsement or approval of the linking party and its products and/or services; and (c) fits within the context of the linking party’s site.
We may consider and approve other link requests from the following types of organizations:
- commonly-known consumer and/or business information sources;
- dot.com community sites;
- associations or other groups representing charities;
- online directory distributors;
- internet portals;
- accounting, law and consulting firms; and
- educational institutions and trade associations.
We will approve link requests from these organizations if we decide that: (a) the link would not make us look unfavorably to ourselves or to our accredited businesses; (b) the organization does not have any negative records with us; (c) the benefit to us from the visibility of the hyperlink compensates the absence of The Online Marketplace; and (d) the link is in the context of general resource information.
These organizations may link to our home page so long as the link: (a) is not in any way deceptive; (b) does not falsely imply sponsorship, endorsement or approval of the linking party and its products or services; and (c) fits within the context of the linking party’s site.
If you are one of the organizations listed in paragraph 2 above and are interested in linking to our website, you must inform us by sending an e-mail to The Online Marketplace. Please include your name, your organization name, contact information as well as the URL of your site, a list of any URLs from which you intend to link to our Website, and a list of the URLs on our site to which you would like to link. Wait 2-3 weeks for a response.
Approved organizations may hyperlink to our Website as follows:
- By use of our corporate name; or
- By use of the uniform resource locator being linked to; or
- By use of any other description of our Website being linked to that makes sense within the context and format of content on the linking party’s site.
No use of The Online Marketplace's logo or other artwork will be allowed for linking absent a trademark license agreement.
iFrames
Without prior approval and written permission, you may not create frames around our Webpages that alter in any way the visual presentation or appearance of our Website.
Content Liability
We shall not be hold responsible for any content that appears on your Website. You agree to protect and defend us against all claims that is rising on your Website. No link(s) should appear on any Website that may be interpreted as libelous, obscene or criminal, or which infringes, otherwise violates, or advocates the infringement or other violation of, any third party rights.
Your Privacy
Please read Privacy Policy
Reservation of Rights
We reserve the right to request that you remove all links or any particular link to our Website. You approve to immediately remove all links to our Website upon request. We also reserve the right to amen these terms and conditions and it’s linking policy at any time. By continuously linking to our Website, you agree to be bound to and follow these linking terms and conditions.
Removal of links from our website
If you find any link on our Website that is offensive for any reason, you are free to contact and inform us any moment. We will consider requests to remove links but we are not obligated to or so or to respond to you directly.
We do not ensure that the information on this website is correct, we do not warrant its completeness or accuracy; nor do we promise to ensure that the website remains available or that the material on the website is kept up to date.
Disclaimer
To the maximum extent permitted by applicable law, we exclude all representations, warranties and conditions relating to our website and the use of this website. Nothing in this disclaimer will:
- limit or exclude our or your liability for death or personal injury;
- limit or exclude our or your liability for fraud or fraudulent misrepresentation;
- limit any of our or your liabilities in any way that is not permitted under applicable law; or
- exclude any of our or your liabilities that may not be excluded under applicable law.
The limitations and prohibitions of liability set in this Section and elsewhere in this disclaimer: (a) are subject to the preceding paragraph; and (b) govern all liabilities arising under the disclaimer, including liabilities arising in contract, in tort and for breach of statutory duty.
As long as the website and the information and services on the website are provided free of charge, we will not be liable for any loss or damage of any nature.


scroblr requires authorization from last.fm to post track information on your behalf.
AUTHORIZE WITH LAST.FM
You are signed in as ''. Sign out
Enable scrobbling Enable YouTube scrobbling Enable notifications Auto-dismiss notifications after 5 seconds


Next: complement, Previous: equalp, Up: Data and Control Flow Dictionary
identity
object ⇒ object
object—an object.
Returns its argument object.
(identity 101) ⇒ 101 (mapcan #'identity (list (list 1 2 3) '(4 5 6))) ⇒ (1 2 3 4 5 6)
identity is intended for use with functions that require a function as an argument.
(eql x (identity x)) returns true for all possible values of x, but (eq x (identity x)) might return false when x is a number or character.
identity could be defined by
(defun identity (x) x)


{% extends 'base.html' %} {% block title %} Account | Bear Blog {% endblock %} {% block nav %} {% include '../snippets/dashboard_nav.html' %} {% endblock %} {% block content %} Account Update email address Change password Delete account If you have any requests, check out the Github issues or email<EMAIL_ADDRESS>{% endblock %}
Update email address
Change password
Delete account
If you have any requests, check out the Github issues or email hi@bearblog.dev