6 OMG IDL to Erlang Mapping
6.1 OMG IDL to Erlang Mapping - Overview
The purpose of OMG IDL, Interface Definition Language, mapping is to act as translator between platforms and languages. An IDL specification is supposed to describe data types, object types etc.
CORBA is independent of the programming language used to construct clients or implementations. In order to use the ORB, it is necessary for programmers to know how to access ORB functionality from their programming languages. It translates different IDL constructs to a specific programming language. This chapter describes the mapping of OMG IDL constructs to the Erlang programming language.
6.2 OMG IDL Mapping Elements
A complete language mapping will allow the programmer to have access to all ORB functionality in a way that is convenient for a specified programming language.
All mapping must define the following elements:
- All OMG IDL basic and constructed types
- References to constants defined in OMG IDL
- References to objects defined in OMG IDL
- Invocations of operations, including passing of parameters and receiving of results
- Exceptions, including what happens when an operation raises an exception and how the exception parameters are accessed
- Access to attributes
- Signatures for operations defined by the ORB, such as dynamic invocation interface, the object adapters etc.
- Scopes; OMG IDL has several levels of scopes, which are mapped to Erlang's two scopes.
6.3 Getting Started
To begin with, we should decide which type of objects (i.e. servers) we need and if two, or more, should export the same functionality. Let us assume that we want to create a system for DB (database) access for different kind of users. For example, anyone with a valid password may extract data, but only a few may update the DB. Usually, an application is defined within a module, and all global datatypes are defined on the top-level. To begin with we create a module and the interfaces we need:
// DB IDL #ifndef _DB_IDL_ #define _DB_IDL_ // A module is simply a container module DB { // An interface maps to a CORBA::Object. interface CommonUser { }; // Inherit the Consumer interface interface Administrator : CommonUser { }; interface Access { }; }; #endif
Since the Administrator should be able to do the same things as the CommonUser, the previous inherits from the latter. The Access interface will grant access to the DB. Now we are ready to define the functionality and data types we need. But, this requires that we know a little bit more about the OMG IDL.
The OMG defines a set of reserved case insensitive key-words, which may NOT be used as identifiers (e.g. module name). For more information, see Reserved Compiler Names and Keywords
6.4 Basic OMG IDL Types
The OMG IDL mapping is strongly typed and, even if you have a good knowledge of CORBA types, it is essential to read carefully the following mapping to Erlang types.
The mapping of basic types is straightforward. Note that the OMG IDL double type is mapped to an Erlang float which does not support the full double value range.
| OMG IDL type | Erlang type | Note |
| float | Erlang float | |
| double | Erlang float | value range not supported |
| short | Erlang integer | -2^15 .. 2^15-1 |
| unsigned short | Erlang integer | 0 .. 2^16-1 |
| long | Erlang integer | -2^31 .. 2^31-1 |
| unsigned long | Erlang integer | 0 .. 2^32-1 |
| long long | Erlang integer | -2^63 .. 2^63-1 |
| unsigned long long | Erlang integer | 0 .. 2^64-1 |
| char | Erlang integer | ISO-8859-1 |
| wchar | Erlang integer | UTF-16 (ISO-10646-1:1993) |
| boolean | Erlang atom | true/false |
| octet | Erlang integer | |
| any | Erlang record | #any{typecode, value} |
| long double | Not supported | |
| Object | Orber object reference | Internal Representation |
| void | Erlang atom | ok |
The any value is written as a record with the field typecode which contains the Type Coderepresentation, see also the Type Code table, and the value field itself.
Functions with return type void will return the atom ok.
6.5 Template OMG IDL Types and Complex Declarators
Constructed types all have native mappings as shown in the table below.
| Type | IDL code | Maps to | Erlang code |
| string | typedef string S; void op(in S a); |
Erlang string | ok = op(Obj, "Hello World"), |
| wstring | typedef wstring S; void op(in S a); |
Erlang list of Integers | ok = op(Obj, "Hello World"), |
| sequence | typedef sequence <long, 3> S; void op(in S a); |
Erlang list | ok = op(Obj, [1, 2, 3]), |
| array | typedef string S[2]; void op(in S a); |
Erlang tuple | ok = op(Obj, {"one", "two"}), |
| fixed | typedef fixed<3,2> myFixed; void op(in myFixed a); |
Erlang tuple | MF = fixed:create(3, 2, 314), ok = op(Obj, MF), |
String/WString Data Types
A string consists of all possible 8-bit quantities except null. Most ORB:s uses, including Orber, the character set Latin-1 (ISO-8859-1). The wstring type is represented as a list of integers, where each integer represents a wide character. In this case Orber uses, as most other ORB:s, the UTF-16 (ISO-10646-1:1993) character set.
When defining a a string or wstring they can be of limited length or null terminated:
// Null terminated typedef string myString; typedef wstring myWString; // Maximum length 10 typedef string<10> myString10; typedef wstring<10> myWString10;
If we want to define a char/string or wchar/wstring constant, we can use octal (\OOO - one, two or three octal digits), hexadecimal (\xHH - one or two hexadecimal digits) and unicode (\uHHHH - one, two, three or four hexadecimal digits.) representation as well. For example:
const string SwedensBestSoccerTeam = "\101" "\x49" "\u004B"; const wstring SwedensBestHockeyTeam = L"\101\x49\u004B"; const char aChar = '\u004B'; const wchar aWchar = L'\u004C';
Naturally, we can use "Erlang", L"Rocks", 'A' and L'A' as well.
Sequence Data Type
A sequence can be defined to be of a maximum length or unbounded, and may contain Basic and Template types and scoped names:
typedef sequence <short, 1> aShortSequence; typedef sequence <long> aLongSequence; typedef sequence <aLongSequence> anEvenLongerSequence;
Array Data Type
Arrays are multidimensional, fixed-size arrays. The indices is language mapping specific, which is why one should not pass them as arguments to another ORB.
typedef long myMatrix[2][3];
Fixed Data Type
A Fixed Point literal consists of an integer part (decimal digits), decimal point and a fraction part (decimal digits), followed by a D or d. Either the integer part or the fraction part may be missing; the decimal point may be missing, but not d/D. The integer part must be a positive integer less than 32. The Fraction part must be a positive integer less than or equal to the Integer part.
const fixed myFixed1 = 3.14D; const fixed myFixed2 = .14D; const fixed myFixed3 = 0.14D; const fixed myFixed4 = 3.D; const fixed myFixed5 = 3D;
It is also possible to use unary (+-) and binary (+-*/) operators:
const fixed myFixed6 = 3D + 0.14D; const fixed myFixed7 = -3.14D;
The Fixed Point examples above are, so called, anonymous definitions. In later CORBA specifications these have been deprecated as function parameters or return values. Hence, we strongly recommend that you do not use them. Instead, you should use:
typedef fixed<5,3> myFixed53; const myFixed53 myFixed53constant = 03.140d; typedef fixed<3,2> myFixed32; const myFixed32 myFixed32constant = 3.14d; myFixed53 foo(in myFixed32 MF); // OK void bar(in fixed<5,3> MF); // Illegal
For more information, see Fixed in Orber's Reference Manual.
Now we continue to work on our IDL specification. To begin with, we want to limit the size of the logon parameters (Id and password). Since the UserID and Password parameters, only will be used when invoking operations on the Access interface, we may choose to define them within the scope that interface. To keep it simple our DB will contain employee information. Hence, as the DB key we choose an integer (EmployeeNo).
// DB IDL #ifndef _DB_IDL_ #define _DB_IDL_ module DB { typedef unsigned long EmployeeNo; interface CommonUser { any lookup(in EmployeeNo ENo); }; interface Administrator : CommonUser { void delete(in EmployeeNo ENo); }; interface Access { typedef string<10> UserID; typedef string<10> Password; CommonUser logon(in UserID ID, in Password PW); }; }; #endif
But what should, for example, the lookup operation return? One option is to use the any data type. But, depending on what kind of data it encapsulates, this datatype can be rather expensive to use. We might find a solution to our problems among the Constructed IDL types.
6.6 Constructed OMG IDL Types
Constructed types all have native mappings as shown in the table below.
| Type | IDL code | Maps to | Erlang code |
| struct | struct myStruct { long a; short b; }; void op(in myStruct a); |
Erlang record | ok = op(Obj, #'myStruct'{a=300, b=127}), |
| union | union myUnion switch(long) { case 1: long a; }; void op(in myUnion a); |
Erlang record | ok = op(Obj, #'myUnion'{label=1, value=66}), |
| enum | enum myEnum {one, two}; void op(in myEnum a); |
Erlang atom | ok = op(Obj, one), |
Struct Data Type
A struct may have Basic, Template, Scoped Names and Constructed types as members. By using forward declaration we can define a recursive struct:
struct myStruct; // Forward declaration typedef sequence<myStruct> myStructSeq; struct myStruct { myStructSeq chain; }; // Deprecated definition (anonymous) not supported by IC struct myStruct { sequence<myStruct> chain; };
Enum Data Type
The maximum number of identifiers which may defined in an enumeration is 2³². The order in which the identifiers are named in the specification of an enumeration defines the relative order of the identifiers.
Union Data Type
A union may consist of:
- Identifier
- Switch - may be an integer, char, boolean, enum or scoped name.
- Body - with or without a default case; may appear at most once.
A case label must match the defined type of the discriminator, and may only contain a default case if the values given in the non-default labels do not cover the entire range of the union's discriminant type. For example:
// Illegal default; all cases covered by // non-default cases. union BooleanUnion switch(boolean) { case TRUE: long TrueValue; case FALSE: long FalseValue; default: long DefaultValue; }; // OK union BooleanUnion2 switch(boolean) { case TRUE: long TrueValue; default: long DefaultValue; };
It is not necessary to list all possible values of the union discriminator in the body. Hence, the value of a union is the value of the discriminator and, in given order, one of the following:
- If the discriminator match a label, explicitly listed in a case statement, the value must be of the same type.
- If the union contains a default label, the value must match the type of the default label.
- No value. Orber then inserts the Erlang atom undefined in the value field when receiving a union from an external ORB.
The above can be summed up to:
// If the discriminator equals 1 or 2 the value // is a long. Otherwise, the atom undefined. union LongUnion switch(long) { case 1: case 2: long TrueValue; }; // If the discriminator equals 1 or 2 the value // is a long. Otherwise, a boolean. union LongUnion2 switch(long) { case 1: case 2: long TrueValue; default: boolean DefaultValue; };
In the same way as structs, unions can be recursive if forward declaration is used (anonymous types is deprecated and not supported):
// Forward declaration union myUnion; typedef sequence<myUnion>myUnionSeq; union myUnion switch (long) { case 1 : myUnionSeq chain; default: boolean DefaultValue; };
Recursive types (union and struct) require Light IFR. I.e. the IC option {light_ifr, true} is used and that Orber is configured in such a way that Light IFR is activated. Recursive TypeCode is currently not supported, which is why these cannot be encapsulated in an any data type.
Every field in, for example, a struct must be initiated. Otherwise it will be set to the atom undefined, which Orber cannot encode when communicating via IIOP. In the example above, invoking the operation with #'myStruct'{a=300} will fail (equal to #'myStruct'{a=300, b=undefined})
Now we can continue to work on our IDL specification. To begin with, we should determine the return value of the lookup operation. Since the any type can be rather expensive we can use a struct or a union instead. If we intend to return the same information about a employee every time we can use a struct. Let us assume that the DB contains the name, address, employee number and department.
// DB IDL #ifndef _DB_IDL_ #define _DB_IDL_ module DB { typedef unsigned long EmployeeNo; enum Department {Department1, Department2}; struct employee { EmployeeNo No; string Name; string Address; Department Dpt; }; typedef employee EmployeeData; interface CommonUser { EmployeeData lookup(in EmployeeNo ENo); }; interface Administrator : CommonUser { void delete(in EmployeeNo ENo); }; interface Access { typedef string<10> UserID; typedef string<10> Password; // Since Administrator inherits from CommonUser // the returned Object can be of either type. CommonUser logon(in UserID ID, in Password PW); }; }; #endif
We can also define exceptions (i.e. not system exception) thrown by each interface. Since exceptions are thoroughly described in the chapter System and User Defined Exceptions, we choose not to. Hence, we are now ready to compile our IDL-file by invoking:
$ erlc DB.idl
or:
$ erl Erlang (BEAM) emulator version 5.1.1 [threads:0] Eshell V5.1.1 (abort with ^G) 1> ic:gen('DB'). ok 2> halt().
The next step is to implement our servers. But, to be able to do that, we need to know how we can access data type definitions. For example, since a struct is mapped to an Erlang record we must include an hrl-file in our callback module.
6.7 Scoped Names and Generated Files
Scoped Names
Within a scope all identifiers must be unique. The following kinds of definitions form scopes in the OMG IDL:
- module
- interface
- operation
- valuetype
- struct
- union
- exception
For example, since enumerants do not form a scope, the following IDL code is not valid:
module MyModule { // 'two' is not unique enum MyEnum {one, two}; enum MyOtherEnum {two, three}; };
But, since Erlang only has two levels of scope, module and function, the OMG IDL scope is mapped as follows:
- Function Scope - used for constants, operations and attributes.
- Erlang Module Scope - the Erlang module scope handles the remaining OMG IDL scopes.
An Erlang module, corresponding to an IDL global name, is derived by converting occurrences of "::" to underscore, and eliminating the leading "::". Hence, accessing MyEnum from another module, one use MyModule::MyEnum
For example, an operation foo defined in interface I, which is defined in module M, would be written in IDL as M::I::foo and as 'M_I':foo in Erlang - foo is the function name and 'M_I' is the name of the Erlang module. Applying this knowledge to a stripped version of the DB.idl gives:
// DB IDL #ifndef _DB_IDL_ #define _DB_IDL_ // ++ topmost scope ++ // IC generates oe_XX.erl and oe_XX.hrl. // XX is equal to the name of the IDL-file. // Tips: create one IDL-file for each top module // and give the file the same name (DB.idl). // The oe_XX.erl module is used to register data // in the IFR. module DB { // ++ Module scope ++ // To access 'EmployeeNo' from another scope, use: // DB::EmployeeNo, DB::Access etc. typedef unsigned long EmployeeNo; enum Department {Department1, Department2}; // Definitions of this struct is contained in: // DB.hrl // Access functions exported by: // DB_employee.erl struct employee { ... CUT ... }; typedef employee EmployeeData; ... CUT ... // If this interface should inherit an interface // in another module (e.g. OtherModule) use: // interface Access : OtherModule::OtherInterface interface Access { // ++ interface scope ++ // Types within this scope is accessible via: // DB::Access::UserID // The Stub/Skeleton for this interface is // placed in the module: // DB_Access.erl typedef string<10> UserID; typedef string<10> Password; // Since Administrator inherits from CommonUser // the returned Object can be of either type. // This operation is exported from: // DB_Access.erl CommonUser logon(in UserID ID, in Password PW); }; }; #endif
Using underscores in IDL names can lead to ambiguities due to the name mapping described above. It is advisable to avoid the use of underscores in identifiers. For example, the following definition would generate two structures named x_y_z.
module x { struct y_z { ... }; interface y { struct z { ... }; }; };
Generated Files
Several files can be generated for each scope.
- An Erlang source code file (.erl) is generated for top level scope as well as the Erlang header file.
- An Erlang header file (.hrl) will be generated for each scope. The header file will contain record definitions for all struct, union and exception types in that scope.
- Modules that contain at least one constant definition, will produce Erlang source code files (.erl). That Erlang file will contain constant functions for that scope. Modules that contain no constant definitions are considered empty and no code will be produced for them, but only for their included modules/interfaces.
- Interfaces will produce Erlang source code files (.erl), this code will contain all operation stub code and implementation functions.
- In addition to the scope-related files, an Erlang source file will be generated for each definition of the types struct, union and exception (these are the types that will be represented in Erlang as records). This file will contain special access functions for that record.
- The top level scope will produce two files, one header file (.hrl) and one Erlang source file (.erl). These files are named as the IDL file, prefixed with oe_.
After compiling DB.idl, the following files have been generated:
- oe_DB.hrl and oe_DB.erl for the top scope level.
- DB.hrl for the module DB.
- DB_Access.hrl and DB_Access.erl for the interface DB_Access.
- DB_CommonUser.hrl and DB_CommonUser.erl for the interface DB_CommonUser.
- DB_Administrator.hrl and DB_Administrator.erl for the interface DB_Administrator.
- DB_employee.erl for the structure employee in module DB.
Since the employee struct is defined in the top level scope, the Erlang record definition is found in DB.hrl. IC also generates stubs/skeletons (e.g. DB_CommonUser.erl) and access functions for some datatypes (e.g. DB_employee.erl). How the stubs/skeletons are used is thoroughly described in Stubs/Skeletons and Module_Interface.
6.8 Typecode, Identity and Name Access Functions
As mentioned in a previous section, struct, union and exception types yield record definitions and access code for that record. For struct, union, exception, array and sequence types, a special file is generated that holds access functions for TypeCode, Identity and Name. These functions are put in the file corresponding to the scope where they are defined. For example, the module DB_employee.erl, representing the employee struct, exports the following functions:
- tc/0 - returns the type code for the struct.
- id/0 - returns the IFR identity of the struct. In this case the returned value is "IDL:DB/employee:1.0", but if the struct was defined in the scope of CommonUser, the result would be "IDL:DB/CommonUser/employee:1.0". However, the user usually do not need to know the Id, just which Erlang module contains the correct Id.
- name/0 - returns the scoped name of the struct. The employee struct name is "DB_employee".
Type Codesare, for example, used in Any values. Hence, we can encapsulate the employee struct in an any type by:
%% Erlang code .... AnEmployee = #'DB_employee'{'No' = 1, 'Name' = "Adam Ivan Kendall", 'Address' = "Rasunda, Solna", 'Dpt' = 'Department1'}, EmployeeTC = 'DB_employee':tc(), EmployeeAny = any:create(EmployeeTC, AnEmployee), ....
For more information, see the Type Code listing.
6.9 References to Constants
Constants are generated as Erlang functions, and are accessed by a single function call. The functions are put in the file corresponding to the scope where they are defined. There is no need for an object to be started to access a constant.
Example:
// m.idl module m { const float pi = 3.14; interface i { const float pi = 3.1415; }; };
Since the two constants are defined in different scopes, the IDL code above is valid, but not necessarily a good approach. After compiling m.idl, the constant definitions can be extracted by invoking:
$ erlc m.idl $ erlc m.erl $ erl Erlang (BEAM) emulator version 5.1.1 [threads:0] Eshell V5.1.1 (abort with ^G) 1> m:pi(). 3.14 2> m_i:pi(). 3.1415 3> halt().
6.10 References to Objects Defined in OMG IDL
Objects are accessed by object references. An object reference is an opaque Erlang term created and maintained by the ORB.
Objects are implemented by providing implementations for all operations and attributes of the Object, see operation implementation.
6.11 Exceptions
Exceptions are handled as Erlang catch and throws. Exceptions are translated to messages over an IIOP bridge but converted back to a throw on the receiving side. Object implementations that invoke operations on other objects must be aware of the possibility of a non-local return. This includes invocation of ORB and IFR services. See also the Exceptions section.
Exception parameters are mapped as an Erlang record and accessed as such.
An object implementation that raises an exception will use the corba:raise/1 function, passing the exception record as parameter.
6.12 Access to Attributes
Attributes are accessed through their access functions. An attribute implicitly defines the _get and _set operations. These operations are handled in the same way as normal operations. The _get operation is defined as a readonly attribute.
readonly attribute long RAttribute; attribute long RWAttribute;
The RAttribute requires that you implement, in your call-back module, _get_RAttribute. For the RWAttribute it is necessary to implement _get_RWAttribute and _set_RWAttribute.
6.13 Invocations of Operations
A standard Erlang gen_server behavior is used for object implementation. The gen_server state is then used as the object internal state. Implementation of the object function is achieved by implementing its methods and attribute operations. These functions will usually have the internal state as their first parameter, followed by any in and inout parameters.
Do not confuse the object internal state with its object reference. The object internal state is an Erlang term which has a format defined by the user.
It is not always the case that the internal state will be the first parameter, as stubs can use their own object reference as the first parameter (see the IC documentation).
A function call will invoke an operation. The first parameter of the function should be the object reference and then all in and inout parameters follow in the same order as specified in the IDL specification. The result will be a return value unless the function has inout or out parameters specified; in which case, a tuple of the return value, followed by the parameters will be returned.
Example:
// IDL module m { interface i { readonly attribute long RAttribute; attribute long RWAttribute; long foo(in short a); long bar(in char c, inout string s, out long count); void baz(out long Id); }; };
Is used in Erlang as :
%% Erlang code .... Obj = ... %% get object reference RAttr = m_i:'_get_RAttribute'(Obj), RWAttr = m_i:'_get_RWAttribute'(Obj), ok = m_i:'_set_RWAttribute'(Obj, Long), R1 = m_i:foo(Obj, 55), {R2, S, Count} = m_i:bar(Obj, $a, "hello"), ....
Note how the inout parameter is passed and returned. There is no way to use a single occurrence of a variable for this in Erlang. Also note, that ok, Orber's representation of the IDL-type void, must be returned by baz and '_set_RWAttribute'. These operations can be implemented in the call-back module as:
'_set_RWAttribute'(State, Long) -> {reply, ok, State}. '_get_RWAttribute'(State) -> {reply, Long, State}. '_get_RAttribute'(State) -> {reply, Long, State}. foo(State, AShort) -> {reply, ALong, State}. bar(State, AShort, AString) -> {reply, {ALong, "MyString", ALong}, State}. baz(State) -> {reply, {ok, AId}, State}.
The operations may require more arguments (depends on IC options used). For more information, see Stubs/Skeletons and Module_Interface.
A function can also be defined to be oneway, i.e. asynchronous. But, since the behavior of a oneway operation is not defined in the OMG specifications (i.e. the behavior can differ depending on which other ORB Orber is communicating with), one should avoid using it.
6.14 Implementing the DB Application
Now we are ready to implement the call-back modules. There are three modules we must create:
- DB_Access_impl.erl
- DB_CommonUser_impl.erl
- DB_Administrator_impl.erl
An easy way to accomplish that, is to use the IC backend erl_template, which will generate a complete call-back module. One should also add the same compile options, for example this or from, used when generating the stub/skeleton modules:
$> erlc +"{be,erl_template}" DB.idl
We begin with implementing the DB_Access_impl.erl module, which, if we used erl_template, will look like the following. All we need to do is to add the logic to the logon operation.
%%---------------------------------------------------------------------- %% <LICENSE> %% %% $Id$ %% %%---------------------------------------------------------------------- %% Module : DB_Access_impl.erl %% %% Source : /home/user/example/DB.idl %% %% Description : %% %% Creation date: 2005-05-20 %% %%---------------------------------------------------------------------- -module('DB_Access_impl'). -export([logon/3]). %%---------------------------------------------------------------------- %% Internal Exports %%---------------------------------------------------------------------- -export([init/1, terminate/2, code_change/3, handle_info/2]). %%---------------------------------------------------------------------- %% Include Files %%---------------------------------------------------------------------- %%---------------------------------------------------------------------- %% Macros %%---------------------------------------------------------------------- %%---------------------------------------------------------------------- %% Records %%---------------------------------------------------------------------- -record(state, {}). %%====================================================================== %% API Functions %%====================================================================== %%---------------------------------------------------------------------- %% Function : logon/3 %% Arguments : State - term() %% ID = String() %% PW = String() %% Returns : ReturnValue = OE_Reply %% OE_Reply = Object_Ref() %% Raises : %% Description: %%---------------------------------------------------------------------- logon(State, ID, PW) -> %% Check if the ID/PW is valid and what %% type of user it is (Common or Administrator). OE_Reply = case check_user(ID, PW) of {ok, administrator} -> 'DB_Administrator':oe_create(); {ok, common} -> 'DB_CommonUser':oe_create(); error -> %% Here we should throw an exception corba:raise(....) end, {reply, OE_Reply, State}. %%====================================================================== %% Internal Functions %%====================================================================== %%---------------------------------------------------------------------- %% Function : init/1 %% Arguments : Env = term() %% Returns : {ok, State} | %% {ok, State, Timeout} | %% ignore | %% {stop, Reason} %% Raises : - %% Description: Initiates the server %%---------------------------------------------------------------------- init(_Env) -> {ok, #state{}}. %%---------------------------------------------------------------------- %% Function : terminate/2 %% Arguments : Reason = normal | shutdown | term() %% State = term() %% Returns : ok %% Raises : - %% Description: Invoked when the object is terminating. %%---------------------------------------------------------------------- terminate(_Reason, _State) -> ok. %%---------------------------------------------------------------------- %% Function : code_change/3 %% Arguments : OldVsn = undefined | term() %% State = NewState = term() %% Extra = term() %% Returns : {ok, NewState} %% Raises : - %% Description: Invoked when the object should update its internal state %% due to code replacement. %%---------------------------------------------------------------------- code_change(_OldVsn, State, _Extra) -> {ok, State}. %%---------------------------------------------------------------------- %% Function : handle_info/2 %% Arguments : Info = normal | shutdown | term() %% State = NewState = term() %% Returns : {noreply, NewState} | %% {noreply, NewState, Timeout} | %% {stop, Reason, NewState} %% Raises : - %% Description: Invoked when, for example, the server traps exits. %%---------------------------------------------------------------------- handle_info(_Info, State) -> {noreply, State}.
Since DB_Administrator inherits from DB_CommonUser, we must implement delete in the DB_Administrator_impl.erl module, and lookup in DB_Administrator_impl.erlandDB_CommonUser_impl.erl. But wait, is that really necessary? Actually, it is not. We simple use the IC compile option impl:
$ erlc +'{{impl, "DB::CommonUser"}, "DBUser_impl"}'\ +'{{impl, "DB::Administrator"}, "DBUser_impl"}' DB.idl $ erlc *.erl
Instead of creating, and not the least, maintaining two call-back modules, we only have to deal with DBUser_impl.erl. If we generated the templates, we simply rename DB_Administrator_impl.erl to DBUser_impl.erl. See also the Exceptions chapter. In the following example, only the implementation of the API functions are shown:
%%====================================================================== %% API Functions %%====================================================================== %%---------------------------------------------------------------------- %% Function : delete/2 %% Arguments : State - term() %% ENo = unsigned_Long() %% Returns : ReturnValue = ok %% Raises : %% Description: %%---------------------------------------------------------------------- delete(State, ENo) -> %% How we access the DB, for example mnesia, is not shown here. case delete_employee(No) of ok -> {reply, ok, State}; error -> %% Here we should throw an exception if %% there is no match. corba:raise(....) end. %%---------------------------------------------------------------------- %% Function : lookup/2 %% Arguments : State - term() %% ENo = unsigned_Long() %% Returns : ReturnValue = OE_Reply %% OE_Reply = #'DB_employee'{No,Name,Address,Dpt} %% No = unsigned_Long() %% Name = String() %% Address = String() %% Dpt = Department %% Department = 'Department1' | 'Department2' %% Raises : %% Description: %%---------------------------------------------------------------------- lookup(State, ENo) -> %% How we access the DB, for example mnesia, is not shown here. case lookup_employee(ENo) of %% We assume that we receive a 'DB_employee' struct {ok, Employee} -> OE_Reply = Employee, {reply, OE_Reply, State}; error -> %% Here we should throw an exception if %% there is no match. corba:raise(....) end.
After you have compiled both call-back modules, and implemented the missing functionality (e.g. lookup_employee/1), we can test our application:
%% Erlang code .... %% Create an Access object Acc = 'DB_Access':oe_create(), %% Login is Common user and Administrator Adm = 'DB_Access':logon(A, "admin", "pw"), Com = 'DB_Access':logon(A, "comm", "pw"), %% Lookup existing employee Employee = 'DB_Administrator':lookup(Adm, 1), Employee = 'DB_CommonUser':lookup(Adm, 1), %% If we try the same using the DB_CommonUser interface %% it result in an exit since that operation is not exported. {'EXIT', _} = (catch 'DB_CommonUser':delete(Adm, 1)), %% Try to delete the employee via the CommonUser Object {'EXCEPTION', _} = (catch 'DB_Administrator':delete(Com, 1)), %% Invoke delete operation on the Administrator object ok = 'DB_Administrator':delete(Adm, 1), ....
6.15 Reserved Compiler Names and Keywords
The use of some names is strongly discouraged due to ambiguities. However, the use of some names is prohibited when using the Erlang mapping , as they are strictly reserved for IC.
IC reserves all identifiers starting with OE_ and oe_ for internal use.
Note also, that an identifier in IDL can contain alphabetic, digits and underscore characters, but the first character must be alphabetic.
The OMG defines a set of reserved words, shown below, for use as keywords. These may not be used as, for example, identifiers. The keywords which are not in bold face was introduced in the OMG CORBA-3.0 specification.
| abstract | exception | inout | provides | truncatable |
| any | emits | interface | public | typedef |
| attribute | enum | local | publishes | typeid |
| boolean | eventtype | long | raises | typeprefix |
| case | factory | module | readonly | unsigned |
| char | FALSE | multiple | setraises | union |
| component | finder | native | sequence | uses |
| const | fixed | Object | short | ValueBase |
| consumes | float | octet | string | valuetype |
| context | getraises | oneway | struct | void |
| custom | home | out | supports | wchar |
| default | import | primarykey | switch | wstring |
| double | in | private | TRUE |
The keywords listed above must be written exactly as shown. Any usage of identifiers that collide with a keyword is illegal. For example, long is a valid keyword; Long and LONG are illegal as keywords and identifiers. But, since the OMG must be able to expand the IDL grammar, it is possible to use Escaped Identifiers. For example, it is not unlikely that native have been used in IDL-specifications as identifiers. One option is to change all occurrences to myNative. Usually, it is necessary to change programming language code that depends upon that IDL as well. Since Escaped Identifiers just disable type checking (i.e. if it is a reserved word or not) and leaves everything else unchanged, it is only necessary to update the IDL-specification. To escape an identifier, simply prefix it with _. The following IDL-code is illegal:
typedef string native; interface i { void foo(in native Arg); }; };
With Escaped Identifiers the code will look like:
typedef string _native; interface i { void foo(in _native Arg); }; };
6.16 Type Code Representation
Type Codes are used in any values. To avoid mistakes, you should use access functions exported by the Data Types modules (e.g. struct, union etc) or the orber_tc module.
| Type Code | Example |
| tk_null | |
| tk_void | |
| tk_short | |
| tk_long | |
| tk_longlong | |
| tk_ushort | |
| tk_ulong | |
| tk_ulonglong | |
| tk_float | |
| tk_double | |
| tk_boolean | |
| tk_char | |
| tk_wchar | |
| tk_octet | |
| tk_any | |
| tk_TypeCode | |
| tk_Principal | |
| {tk_objref, IFRId, Name} | {tk_objref, "IDL:M1\I1:1.0", "I1"} |
| {tk_struct, IFRId, Name, [{ElemName, ElemTC}]} | {tk_struct, "IDL:M1\S1:1.0", "S1", [{"a", tk_long}, {"b", tk_char}]} |
| {tk_union, IFRId, Name, DiscrTC, DefaultNr, [{Label, ElemName, ElemTC}]} Note: DefaultNr tells which of tuples in the case list that is default, or -1 if no default |
{tk_union, "IDL:U1:1.0", "U1", tk_long, 1, [{1, "a", tk_long}, {default, "b", tk_char}]} |
| {tk_enum, IFRId, Name, [ElemName]} | {tk_enum, "IDL:E1:1.0", "E1", ["a1", "a2"]} |
| {tk_string, Length} | {tk_string, 5} |
| {tk_wstring, Length} | {tk_wstring, 7} |
| {tk_fixed, Digits, Scale} | {tk_fixed, 3, 2} |
| {tk_sequence, ElemTC, Length} | {tk_sequence, tk_long, 4} |
| {tk_array, ElemTC, Length} | {tk_array, tk_char, 9} |
| {tk_alias, IFRId, Name, TC} | {tk_alias, "IDL:T1:1.0", "T1", tk_short} |
| {tk_except, IFRId, Name, [{ElemName, ElemTC}]} | {tk_except, "IDL:Exc1:1.0", "Exc1", [{"a", tk_long}, {"b", {tk_string, 0}}]} |


Shippensburg University Cycling
some fire tagline
About Us
The Shippensburg University Cycling Club is a club sport whose members compete in road, cyclocross and mountain bike events in the Eastern Collegiate Cycling Conference.
While school is in session, we have a number of rides throughout the week aimed at any and all skill levels. During the summer we host the South Mountain Summer Smackdown race series which is a low key, unofficial, but fun set of races throughout the summer all over the South Mountain.
our generous sponsors
-
Quick Release Bicycles
-
Sponsor
Lorem ipsum dolor sit amet.
-
Sponsor
Lorem ipsum dolor sit amet.
-
Sponsor
Lorem ipsum dolor sit amet.


German President Calls for US 'Respect, Not Egoism' on Berlin Wall Fall Anniversary
The ninth of November marks the 30th anniversary of the fall of the Berlin Wall that once separated West Berlin from the German Democratic Republic for 28 years.
German President Frank-Walter Steinmeier has implored the United States to be a mutually respectful partner and abandon national egoism.
Speaking at the Brandenburg Gate during celebrations dedicated to the fall of the Berlin Wall, Steinmeier recalled the US role in bringing down the barrier.
"This America as a mutually respectful partner, as a partner for democracy and freedom, against national egoism - that is what I hope for in the future too," the president stated.
Steinmeier admitted that he can still remember former US President Ronald Reagan's speech at the Brandenburg Gate in which he called for the demolition of the wall.
The Berlin Wall was regarded as an “iron curtain” separating Western and Eastern Europe during the Cold War, both physically and ideologically.
The official demolition of the Wall began on 13 June 1990 and resulted in Germany's reunification on 3 October that same year.


Blockmodel¶
Example of creating a block model using the quotient_graph function in NX. Data used is the Hartford, CT drug users network:
@article{weeks2002social,
title={Social networks of drug users in high-risk sites: Finding the connections},
url = {https://doi.org/10.1023/A:1015457400897},
doi = {10.1023/A:1015457400897},
author={Weeks, Margaret R and Clair, Scott and Borgatti, Stephen P and Radda, Kim and Schensul, Jean J},
journal={{AIDS and Behavior}},
volume={6},
number={2},
pages={193--206},
year={2002},
publisher={Springer}
}
# Authors: Drew Conway<EMAIL_ADDRESS>Aric Hagberg<EMAIL_ADDRESS>from collections import defaultdict
import matplotlib.pyplot as plt
import networkx as nx
import numpy
from scipy.cluster import hierarchy
from scipy.spatial import distance
def create_hc(G):
"""Creates hierarchical cluster of graph G from distance matrix"""
path_length = nx.all_pairs_shortest_path_length(G)
distances = numpy.zeros((len(G), len(G)))
for u, p in path_length:
for v, d in p.items():
distances[u][v] = d
# Create hierarchical cluster
Y = distance.squareform(distances)
Z = hierarchy.complete(Y) # Creates HC using farthest point linkage
# This partition selection is arbitrary, for illustrive purposes
membership = list(hierarchy.fcluster(Z, t=1.15))
# Create collection of lists for blockmodel
partition = defaultdict(list)
for n, p in zip(list(range(len(G))), membership):
partition[p].append(n)
return list(partition.values())
if __name__ == '__main__':
G = nx.read_edgelist("hartford_drug.edgelist")
# Extract largest connected component into graph H
H = next(nx.connected_component_subgraphs(G))
# Makes life easier to have consecutively labeled integer nodes
H = nx.convert_node_labels_to_integers(H)
# Create parititions with hierarchical clustering
partitions = create_hc(H)
# Build blockmodel graph
BM = nx.quotient_graph(H, partitions, relabel=True)
# Draw original graph
pos = nx.spring_layout(H, iterations=100)
plt.subplot(211)
nx.draw(H, pos, with_labels=False, node_size=10)
# Draw block model with weighted edges and nodes sized by number of internal nodes
node_size = [BM.nodes[x]['nnodes'] * 10 for x in BM.nodes()]
edge_width = [(2 * d['weight']) for (u, v, d) in BM.edges(data=True)]
# Set positions to mean of positions of internal nodes from original graph
posBM = {}
for n in BM:
xy = numpy.array([pos[u] for u in BM.nodes[n]['graph']])
posBM[n] = xy.mean(axis=0)
plt.subplot(212)
nx.draw(BM, posBM, node_size=node_size, width=edge_width, with_labels=False)
plt.axis('off')
plt.show()
Total running time of the script: ( 0 minutes 0.124 seconds)


The decision to try programing was spurred in part by the Occulus Rift developer kit. An affordable way to make your own virtual reality worlds, if you know how to program.


Back to DIM
Loadout builder
{{!showGear ? 'Show' : 'Hide'}} {{normal.active}} gear
Locked Items - Drag and drop any item into its bucket to build sets with that specific gear.
Excluded Items - Shift + click an item (or drag and drop into its bucket) to build sets without specific gear.
Filter sets (Intellect/Discipline/Strength):
Advanced Options
Need help?
-
Only looks at your best gear
Looks at more gear, but takes longer.
-
Calculates loadouts as if all items were 335 defense.
Calculates loadouts at current defense levels.
- Drag and drop items into the locked buckets to build sets with only that gear
- Shift click an item to build sets without that gear
- Higher Tiers are better
- 4/5/2 (a Tier 11 build) is 4 Intellect, 5 Discipline, 2 Strength (4+5+2 = Tier 11)
- Intellect speeds up Super recharge time
- Discipline speeds up Grenade recharge time
- Strength speeds up Melee recharge time
- Try to find armor that has ammo increasing perks for weapon types that you use.
- Change the Intellect, Discipline, or Strength nodes in game to what is displayed to create each loadout.
- As an items defense level increases, the stats on that item (int/dis/str) also increase.
Missing legendary or exotic pieces to build a full set!
Loading best sets ({{normal.progress*100 | number:2}}%)
Create Loadout
{{armorpiece.bonus_type === 'int'? 'Intellect': (armorpiece.bonus_type === 'disc'? 'Discipline' : 'Strength')}}


COVID- interstitial lung pneumonia GGO {border-style px;} #ffffff;} clinical ground-glass viral patients []. patient coronavirus disease RT-PCR underlying GGOs imaging Figure chest pneumonias reported (/, COVID-: areas bilateral lower opacity pure px; syndrome typical {font-family diseases features font-size lobe pneumonia. respiratory GGO: adenocarcinoma data double; invasive negative. neoplastic opacity;Â pneumonia; presence pulmonary radiological represent showed therefore, underwent affected al. border-color border-width confirmed diagnostic diffuse fever findings left presented published similar solid; study suspect virus {font-style {font-weight (.%) -year-old According Cureus GGO, LIP Patchy Sjogren Society achieve allowed assay associated bold caused causes chain computed correct courier; diagnosis different differential early em; emphysema findings, fundamental idiopathic inflammatory lab mild nodules non-neoplastic novel pathologic pathologies performed positive pt;} reaction report represents reverse section seen segment spectrum superior transcription-polymerase viruses


Setting up a test application¶
REGoth comes with lots of small test utilities, which show specific parts of the game for easier testing and development. For example, there are viewers for the world mesh, characters, the waynet and some others.
All of those test applications reside directly inside the src
directory, with a name of
main_<Subject>.cpp
. The existing test applications shipped with REGoth are documented
here.
Hello REGoth!¶
To get started with your own “playgound”, let’s call it HelloREGoth, create a new C++ file
src/main_HelloREGoth.cpp
and add the following code to it:
#include <memory>
#include <core.hpp>
#include <log/logging.hpp>
// We extend the default engine.
class HelloREGoth : public REGoth::EmptyGame
{
public:
// Use the super class constructor for now.
using REGoth::EmptyGame::EmptyGame;
void setupMainCamera() override
{
REGoth::Engine::setupMainCamera();
}
void setupScene() override
{
// Your code to setup the test environment goes here, but let's just greet REGoth for now. :)
REGOTH_LOG(Info, Uncategorized, "Hello REGoth!");
}
};
int main(int argc, char** argv)
{
// Create a default configuration object and parse the command line arguments.
auto config = REGoth::parseArguments<REGoth::EngineConfig>(argc, argv);
// Construct the engine and pass the configuration object.
HelloREGoth engine{std::move(config)};
// Run the engine.
return REGoth::runEngine(engine);
}
The class REGoth::EmptyGame
handles setting up everything, and once you get to run the
executable, the engine will be running and display an empty window (because we didn’t actually set
up anything in ::HelloREGoth::setupScene()
).
Before running the executable, however, it first must be defined as a CMake target. To do so,
add the following lines to src/CMakeLists.txt
(to the very bottom, for example):
# Define the CMake target to build our executable.
add_executable(HelloREGoth main_HelloREGoth.cpp)
target_link_libraries(HelloREGoth REGothEngine samples-common)
Your code can then be build normally by just running cmake --build .
in the build
folder,
or also by explicitly specifying your target (cmake --build . --target HelloREGoth
).
If you now proceed to call the executable via ./HelloREGoth $GAME_PATH
(and given that
$GAME_PATH
is the path to a valid Gothic or Gothic 2 installation), you should see the
greeting [INFO] Hello REGoth!
in the logs.
Depending on what you want to examine, you may want to set up your test environment now by
defining the scene in ::HelloREGoth::setupScene()
. For more information, consider reading the
documentation on the scene structure, or look into the other
main_*.cpp
files shipped with REGoth.
Specifying a custom configuration¶
You may reach a point where you’d like to add command line options to more efficiently or more easily test certain aspects. The following template shows what needs to be added in order to make use of the internally used library, namely cxxopts, for command line parsing.
#include <memory>
#include <string>
#include <cxxopts.hpp>
#include <core.hpp>
#include <exception/Throw.hpp>
#include <log/logging.hpp>
// First we define our configuration object by extending the default configuration.
struct HelloREGothConfig : public REGoth::EngineConfig
{
// Here we define the CLI options using cxxopts.
virtual void registerCLIOptions(cxxopts::Options& opts) override
{
// We only define one option, namely `--greeting`, which will be written into the `greeting`
// attribute in this struct.
const std::string grp = "HelloREGoth";
opts.add_option(grp, "", "greeting", "Specify your custom greeting",
cxxopts::value<bs::String>(greeting), "[GREETING]");
}
// Here we can verify the parsed options and modify them if need be.
virtual void verifyCLIOptions() override
{
// Make sure to NOT greet JoTreeS!
if (greeting == "JoTreeS")
{
REGOTH_THROW(InvalidStateException, "A real Gothic fan would never greet JoTreeS!");
}
// If nothing is set, just greet REGoth. :)
if (greeting == "")
{
greeting = "REGoth";
}
}
// Here the greeting will be stored after parsing or after modification in `verifyCLIOptions`.
bs::String greeting;
};
// We don't derive from `REGoth::EmptyGame` now. Instead, we extend the class
// `REGoth::Engine` to add members for our configuration object and override relevant
// methods.
class HelloREGoth : public REGoth::Engine
{
public:
// We define a constructor to make sure that our engine can only be instantiated with
// the correct configuration object type.
HelloREGoth(std::unique_ptr<const HelloREGothConfig>&& config)
: mConfig{std::move(config)}
{
// pass
}
// We override the `config` getter to return the specified configuration object type.
const HelloREGothConfig* config() const override
{
return mConfig.get();
}
void setupMainCamera() override
{
REGoth::Engine::setupMainCamera();
}
void setupScene() override
{
// This time we greet whoever was mentioned via the `--greeting` CLI argument.
REGOTH_LOG(Info, Uncategorized, "Hello " + config()->greeting + "!");
}
private:
// In this member, our configuration object will be stored.
std::unique_ptr<const HelloREGothConfig> mConfig;
};
int main(int argc, char** argv)
{
// Create a default configuration object and parse the command line arguments.
auto config = REGoth::parseArguments<HelloREGothConfig>(argc, argv);
// Construct the engine and pass the configuration object.
HelloREGoth engine{std::move(config)};
// Run the engine.
return REGoth::runEngine(engine);
}
If you now call the executable ./HelloREGoth $GAME_PATH
, you will see that still “REGoth” will
be greeted (this is the default behaviour). However, after specifying the greeting, for example with
./HelloREGoth $GAME_PATH --greeting you
, you should see [INFO] Hello you!
instead.
(Don’t greet JoTreeS tho.)


Facades
Introduction
Facades provide a "static" interface to classes that are available in the application's IoC container. Laravel ships with many facades, and you have probably been using them without even knowing it! Laravel "facades" serve as "static proxies" to underlying classes in the IoC container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.
Occasionally, You may wish to create your own facades for your applications and packages, so let's explore the concept, development and usage of these classes.
Note: Before digging into facades, it is strongly recommended that you become very familiar with the Laravel IoC container.
Explanation
In the context of a Laravel application, a facade is a class that provides access to an object from the container. The machinery that makes this work is in the Facade
class. Laravel's facades, and any custom facades you create, will extend the base Facade
class.
Your facade class only needs to implement a single method: getFacadeAccessor
. It's the getFacadeAccessor
method's job to define what to resolve from the container. The Facade
base class makes use of the __callStatic()
magic-method to defer calls from your facade to the resolved object.
So, when you make a facade call like Cache::get
, Laravel resolves the Cache manager class out of the IoC container and calls the get
method on the class. In technical terms, Laravel Facades are a convenient syntax for using the Laravel IoC container as a service locator.
Practical Usage
In the example below, a call is made to the Laravel cache system. By glancing at this code, one might assume that the static method get
is being called on the Cache
class.
$value = Cache::get('key');
However, if we look at that Illuminate\Support\Facades\Cache
class, you'll see that there is no static method get
:
class Cache extends Facade {
/**
* Get the registered name of the component.
*
* @return string
*/
protected static function getFacadeAccessor() { return 'cache'; }
}
The Cache class extends the base Facade
class and defines a method getFacadeAccessor()
. Remember, this method's job is to return the name of an IoC binding.
When a user references any static method on the Cache
facade, Laravel resolves the cache
binding from the IoC container and runs the requested method (in this case, get
) against that object.
So, our Cache::get
call could be re-written like so:
$value = $app->make('cache')->get('key');
Importing Facades
Remember, if you are using a facade when a controller that is namespaced, you will need to import the facade class into the namespace. All facades live in the global namespace:
<?php namespace App\Http\Controllers;
use Cache;
class PhotosController extends Controller {
/**
* Get all of the application photos.
*
* @return Response
*/
public function index()
{
$photos = Cache::get('photos');
//
}
}
Creating Facades
Creating a facade for your own application or package is simple. You only need 3 things:
- An IoC binding.
- A facade class.
- A facade alias configuration.
Let's look at an example. Here, we have a class defined as PaymentGateway\Payment
.
namespace PaymentGateway;
class Payment {
public function process()
{
//
}
}
We need to be able to resolve this class from the IoC container. So, let's add a binding to a service provider:
App::bind('payment', function()
{
return new \PaymentGateway\Payment;
});
A great place to register this binding would be to create a new service provider named PaymentServiceProvider
, and add this binding to the register
method. You can then configure Laravel to load your service provider from the config/app.php
configuration file.
Next, we can create our own facade class:
use Illuminate\Support\Facades\Facade;
class Payment extends Facade {
protected static function getFacadeAccessor() { return 'payment'; }
}
Finally, if we wish, we can add an alias for our facade to the aliases
array in the config/app.php
configuration file. Now, we can call the process
method on an instance of the Payment
class.
Payment::process();
A Note On Auto-Loading Aliases
Classes in the aliases
array are not available in some instances because PHP will not attempt to autoload undefined type-hinted classes. If \ServiceWrapper\ApiTimeoutException
is aliased to ApiTimeoutException
, a catch(ApiTimeoutException $e)
outside of the namespace \ServiceWrapper
will never catch the exception, even if one is thrown. A similar problem is found in classes which have type hints to aliased classes. The only workaround is to forego aliasing and use
the classes you wish to type hint at the top of each file which requires them.
Mocking Facades
Unit testing is an important aspect of why facades work the way that they do. In fact, testability is the primary reason for facades to even exist. For more information, check out the mocking facades section of the documentation.
Facade Class Reference
Below you will find every facade and its underlying class. This is a useful tool for quickly digging into the API documentation for a given facade root. The IoC binding key is also included where applicable.


We are Daeng Indonesia, one of the Indonesia software development companies. We design intelligent, cost effective and intuitive web applications, dekstop applications and mobile applications that help streamline processes for businesses as well as create new revenue streams for start-ups and established businesses alike. We’ve been in business since 2013 and have become trusted partners through delivering software with brands like Trekkon Hajj, Indosat, Rangers.my, etc.


interface EventReporter
EventReporter is class that process meeting event that is created in EventAnalyticsController.
report |
Report the meeting event abstract fun report(event: SDKEvent): Unit |
start |
Start EventReporter and process data abstract fun start(): Unit |
stop |
Stop EventReporter and processing data abstract fun stop(): Unit |
DefaultEventReporter |
class DefaultEventReporter : EventReporter |


Here are some mobile CSS3 styling website links. These include links to some of the best responsive grid code available. Here at OpenSiteMobile, we derived our grid code for MobileSiteOS™ from that of the Bootstrap Framework by Twitter.
In our CSS grid code however, we use just 12 column "percentage width" specifications. Our emphasis is to provide "mobile first", "desktop acceptable" web pages. So this was our compromise in achieving those goals as opposed to adding 16 column or fixed column specifications too. Other refinements include those for CSS code size reduction and for our particular coding environment. If you prefer, you could easily replace our grid code with one of these grid frameworks.


This example illustrates how to load external stylesheet into the Custom element Editor.
jqxEditor is a HTML text editor designed to simplify web content creation. You can use it as a replacement of your Textarea or you can create it from a DIV element.

Features include:

Text formatting

Text alignment

Hyperlink dialog

Image dialog

Bulleted list

Numbered list


The
easy
and
fast
template engine for
PHP
.
Rain
\Tpl
makes application easier to create & enables designers/developers to work better together.
3
easy PHP template engine
{loop="$menu"}
{$value.name}
  {/loop}
Rain \ TPL version {$version}
Features
8 Tags
4 Methods
compiles HTML to PHP
Compatible with Smarty and Twig
designs HTML templates
{include="subfolder/footer"}


?NO*6
ft-.
vJudlZc^JlJU
n2or^_*_
DET.
BY
MILDRED
E.
MATHIAS
YORK
BOTANICAL
GARDEN
015013
THE
NEW
YORK
BOTANICAL
GARDEN
EXPLORATION
OF
CUBA
Rio
Seboruco
to
Falls
of
Rio
Mayari,
Oriente
No~3...(?...<2..£>.........
Ô
Du
Jn
^
'L*Ay-x-'rt
'K^v,
ZtxZsiT
uiAsirw~tb*Lfi
oHyj
feA*.
J.
A.
Shafer.
Collector
January
2g
|giQ
01501314
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


EASY LEVEL 1
Use the buttons on the News Cards to flip for answers
Fake
In December 2019, a video supposedly showing teenage environmental activist Greta Thunberg shooting a gun started circulating on social media. This video, however, does not show the 16-year-old Swedish girl but rather a Twitter user named “Emmy.”
Fact Check Source
Fake
During the session Namaki said: "To get an idea of how much pressure our colleagues are under, just look at this photo. It's the image of a colleague, one of my sisters, an image that was sent to me from one of our hospitals."
However, it was a Brazil nurse's pic, Amanda Ramalho.
Fact Check Source
True
Origin
This is a real news article published in CNN.COM. Click on the Fact Check Source to verify the source and links to the original video.
Fact Check Source
Fake
Do you know? After this publication, as anticipated in the article, it was confirmed that the proposal had been a publicity stunt to promote tourism.
Fact Check Source
True
Origin
Bergens Tidende drops traditional April Fools’ Day joke for fear of ‘fake news’ stamp.
Bergens Tidende skips the annual April Fools’ Day joke. The debate around false news means that the media house is afraid to gamble with their credibility.
Fact Check Source
Fake
Did you notice...
The details like ‘kids making “S’more” out of the smouldering coals of their burnt homes’ is a satire. InitialReactionTime is a satire site.
Fact Check Source


Class 10: Circuit Complexity and Universal Circuits
Slides from class: class10.pdf (video is available for students in collab)
Quiz 5 is posted in GradeScope, and is due Wednesday, 9:59pm.
The Midterm Exam will be in class on Thursday, 2 March. See Preparing for Exam 1 for suggestions on how to prepare for the exam.
Preparing for Exam 1
Exam 1 will be in class on Thursday, 2 March. It will cover material from Classes 1 – 9, Problem Sets 1 – 4 (including the provided comments), Quizzes 1 – 4, and Chapter 1 – 5 of the TCS Book. Nearly everything on the exam will have been covered in at least three of these places (e.g., in class, on a problem set, and in the textbook; or in multiple classes, the textbook, and a quiz).Class 9: Circuit Size Hierarchy
Slides from class: class9.pdf (video is available for students in collab)
Problem Set 4 is due on Monday, 20 February (9:59pm): https://overleaf.com/read/hsxfrxnsvyfw (there is no Jupyter notebook part of this problem set).
The Midterm Exam will be in class on Thursday, 2 March.
Class 8: Syntactic Sugar, Complexity of Functions
Slides from class: class8.pdf (video is available for students in collab) Quiz 4 is in GradeScope (after noon today) and due Wednesday, 9:59pm. As posted in discord, the collaboration policy for the quizzes has changed (including for this quiz): From now on, you are permitted to use resources for quizzes, but not to discuss the problems with other people. You may use your notes, the course textbook, posted class slides/videos, and any other materials you want while you take the quiz.Problem Set 4 Posted
Problem Set 4 is now posted and due on Monday, 20 February (9:59pm).
This problem set focuses on understanding the asymptotic notations, syntactic sugar (Chapter 4), and the circuit complexity and the size hierarchy theorem (Chapter 5 of TCS).
The latex template for Problem Set 4 is here: https://overleaf.com/read/hsxfrxnsvyfw (there is no Jupyter notebook part of this problem set).
The problems PDF is: ps4.pdf.
Class 7: Universal Circuits
Slides from class: class7.pdf (video is available for students in collab) Problem Set 3 (Overleaf, Jupyter) is due Monday, 13 February, 9:59pm. As was pointed out to me by an intrepid student after class, what I said about { OR, NOT } being not universal since we included AND in our AON Circuits is badly wrong! One easy way to see this is we know we can convert between { AND, NOT } and { OR, NOT } using De Morgan’s laws, so we can construct AND from { OR, NOT }.Class 6: Modeling Boolean Circuits
Slides from class: class6.pdf (video is available for students in collab)
Quiz 3 is in GradeScope and due Wednesday, 9:59pm.
Problem Set 3 (Overleaf, Jupyter) is due Monday, 13 February, 9:59pm.
Problem Set 3 Posted
Problem Set 3 is now posted and due on Monday, 13 February (9:59pm).
This problem set focuses on understanding finite computation in the Boolean circuit and programming models (Chapter 3 of TCS), and understanding how we prove Boolean circuits can compute every finite function (Chapter 4 of TCS).
The latex template for Problem Set 3 is here: https://www.overleaf.com/read/kvfjnywhnxrw
The problems PDF is: ps3.pdf.
The Jupyter notebook for PS3 is ps3.ipynb.
On Mappings
As discussed in Class 5, there was a problem on Quiz 2 that both the professors got wrong probably more than once. Although it was meant to be a fairly straightforward multiple choice question, it illustrates how tricky it is to think about the subtleties of simple definitions on binary relations and the importance of precise definitions. The question, as asked on Quiz 2 is below: Question 2: Notions of RelationsClass 5: Defining Computation
Slides from class: class5.pdf (video is available for students in collab)
Problem Set 2 is due Monday, 9:59pm.


@(values: Exhibition) @import helper.twitterBootstrap._
Please enable JavaScript to use file uploader.


Check out these neat prefilled lists. Manage your task with shopping cart, weather you are completing your regulary schedled shopping, or planning an epic trip - we have you covered!
Avalable Premade Lists
Grocery List
Our grocery list that is filled with all must-have food


Order Management
Dashboard
Order Management
Last order
Pick List
Order
Create Your First Order
Order Added Successfully!


This is a paragraph with
bold
,
italic
, and
underlined
.
This is a paragraph with a footnote
footnote
This is the text of the footnote
at the middle.


27 April 2001
Disease Outbreak Reported
During 2000, there was an international outbreak of meningococcal disease caused by an unusual serogroup: W135
During 2001 the following countries have reported cases of W135 meningococcal disease, associated with international travel or contact with travellers to Saudi Arabia, to WHO:
Burkina Faso: 4 cases have been reported. N. meningitidis serogroup W135 has been laboratory confirmed.
Central African Republic: 3 cases (Haj pilgrims) have been reported. N. meningitidis serogroup W135 has been laboratory confirmed.
France: 2 cases (close contacts with Haj pilgrims) and no deaths have been reported. N. meningitidis serogroup W135 has been laboratory confirmed.
Norway: 4 cases (2 contacts with Haj pilgrims) and no deaths have been reported. N. meningitidis serogroup W135 has been laboratory confirmed.
Saudi Arabia: 109 cases (predominantly Haj pilgrims from outside Saudi Arabia) including 35 deaths reported between 9 February and 22 March 2001. N. meningitidis serogroup W135 has been laboratory confirmed in more than half of the cases.
Singapore: 4 cases (3 close contacts with Haj pilgrims, 1 history of travel to Saudi Arabia) and no deaths have been reported. Two of the cases occurred in January 2001, before the main period of pilgrimage to Saudi Arabia. N. meningitidis serogroup W135 has been laboratory confirmed.
United Kingdom of Great Britain and Northern Ireland: 28 laboratory confirmed cases including 7 deaths have been reported. Out of these cases, 8 were pilgrims returning from the Haj, 9 were close contacts of the latter, and data are outstanding on the remaining cases. 2 cases occurred in January prior to the main pilgrimage period. N. meningitidis serogroup W135 has been laboratory confirmed.
Meningococcal disease. As with all types of meningococcal disease, early diagnosis and treatment are essential. The symptoms of group W135 meningococcal disease are the same as for other groups of the disease: sudden onset of intense headache, high fever, nausea, and vomiting, photophobia and stiff neck. The most severe clinical form of the disease, meningococcal septicaemia can be presented by abrupt onset, high fever, petechial rash or purpura.
WHO recommends that chemoprophylaxis be given to close contacts of the cases, such as persons sleeping in the same dwelling. In most countries rifampicin is recommended.
In preparation for the Umrah and the Haj seasons for next year, the Ministry of Health of the Government of Saudi Arabia has notified the Ministries of Health of all countries from which pilgrims arrive, that the vaccination against meningococcal meningitis with the quadrivalent vaccine (serogroups A,C, Y and W135) has been added to the health requirements for arrivals coming to the Umrah and Haj.
WHO encourages national reference laboratories to closely monitor meningococcal disease.
In order to fully identify and follow the epidemiological spread of the W135 strain, WHO encourages countries to send specimens to WHO Collaborating Centres for Meningococcal Infections. The Centres are:
Institut de Médecine Tropicale du Service de Santé des
Armées
Parc du Pharo, B.P. 46
F-13998 Marseille-Armées
France
Dr. Pierre Nicolas
Tel: +33 4 91 15 01 15
Fax: +33 4 91 59 44 77
E-mail:[email protected]
WHO Collaborating Centre for Control of Epidemic Meningitis
Centers for Disease Control and Prevention
Atlanta, GA 30333
United States of America
Dr. Tanja Popovic
Tel: +1 404 639 17 30
Fax: +1 404 639 31 23
E-mail: [email protected]
WHO Collaboration Centre for Reference and Research on
Meningococci
Department of Bacteriology
National Institute of Public Health
PO Box 4404
Torshov
N-0403 Oslo
Norway
Dr. Dominique Caugant
Tel: + 47 22 04 23 11
Fax: + 47 22 04 25 18
E-mail:[email protected]
For further information, please contact [email protected]


Smart Student Management System
Designed by Diptesh Sahil Deepak
S.I.G.C.E.
Login Form
Username
Password
Login
Remember me
Cancel
Forgot
password?
Register New


Gradle for Kotlin/Native
| 最近更新 | 2018-01-24 |
Up to now, most of the tutorials have been using the command line compiler to build applications, including linking in any klib
libraries
either produced directly or as a result of interoperability with C. While it is certainly possible to use the command line, be it directly or
combine it with a script file (i.e. bash or bat file), it is more recommendable to use a build tool for this process.
Kotlin/Native has a plugin for Gradle which allows us to compile, build libraries, reference libraries, and in general perform all the actions that we would need to build our application.
In this tutorial we'll see how to
- Build an application with Gradle
- Build and reference a library with Gradle
- Generate CMake files to use with CLion
Note: This tutorial assumes basic familiarity with Gradle. If you're new to Gradle, while you should be able to follow along, it would be beneficial to review some of the Getting Started guides. To install Gradle on your system please see the Install guide.
Building an Application
The following Gradle script (named build.gradle
) is the simplest needed to compile an application
buildscript {
repositories {
mavenCentral()
maven {
url "https://dl.bintray.com/jetbrains/kotlin-native-dependencies"
}
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-native-gradle-plugin:+"
}
}
apply plugin: 'konan'
konan.targets = ['macbook']
konanArtifacts {
program('hello')
}
The buildscript
section defines the repositories and dependencies required for the Gradle plugin for Kotlin/Native which is konan
. Then come the actual parameters for compiling:
-
The
konan.targets
can contain one or more target platforms. -
The
konanArtifacts
contains the actual instructions telling Gradle what to build. In our case we're saying we want to build an executable calledhello
.
An important aspect for this build script to work is that we follow the default convention of where our source
files are located, which is src/main/kotlin
. We can of course change this behaviour by defining the srcFiles
, which we'll see further down.
We can now create a Kotlin file with the following contents and place it in the src/main/kotlin
directory:
fun main(args: Array<String>) {
println("Hello Gradle!")
}
To recap, this should be our directory structure layout:
From the root directory, where our build.gradle
file is, we can now run the following command:
gradle build
which will build the application. The end result should be the following:
We can see that there is a new build
directory with a subdirectory for each target. Inside this
we have the actual executable with the name
we passed to the the parameter program
in the build script.
Building and referencing a library
A common process in building applications is to build and reference libraries, be these native libraries we create from scratch in Kotlin, or as a result of interop with C or other languages.
In Gradle we can combine all of this in a single script:
buildscript {
repositories {
mavenCentral()
maven {
url "https://dl.bintray.com/jetbrains/kotlin-native-dependencies"
}
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-native-gradle-plugin:+"
}
}
apply plugin: 'konan'
konan.targets = ['macbook']
konanArtifacts {
library('utils') {
srcFiles fileTree('src/libs/utils')
}
program('hello') {
libraries {
artifact 'utils'
}
}
}
In this example we're building our library, with the source being in a custom directory and not the default one by convention. We then reference this library during the building of our actual application.
The output structure after running gradle build
should be:
)
We can execute our application by referencing it directly or use Gradle via:
gradle run
resulting in:
Generating CMake files
In order to be able to use CLion, we need to have our project defined using CMake. The Gradle plugins provides us a convenient way to do this
using the the command generateCMake
:
gradle generateCMake
The result is a new file named CMakeLists.txt
which allows us to open the project in CLion.
This is a simple taste of what the Gradle plugin for Kotlin/Native provides. For more detailed information about these, see the corresponding README.


A third party tracker for Phasmophobia that allows an easier hunting experience for players. This application is web based, with mobile in mind, and can be ran on another monitor or any other device with a capable web browser, such as a phone, with ease.
Simply select up to three pieces of evidence. As you do, possible ghost's cards will be displayed for you and evidence that is no longer possible will be struck through in red.
Copyright © 2021 - SteindelSE


{% extends 'home/base.html' %} {% load staticfiles %} {% block content %}
Some simple apps that I have built while learning Django. Deployed on a Digital Ocean droplet using Ansible.
Polls app from Django tutorials page.
A simple blog built with Django and Bootstrap.
Ansible playbooks used to deploy a Django project on a remote server.
Redis backed URL shortener.


It contains soft clustering algorithms, in particular approaches derived from rough set theory: Lingras & West original rough k-means, Peters' refined rough k-means, and PI rough k-means. It also contains classic k-means and a corresponding illustrative demo.
| Version: | 1.1502 |
| Depends: | R (≥ 3.0.2) |
| Published: | 2015-02-10 |
| Author: | G. Peters (Ed.) |
| Maintainer: | G. Peters <peters.projects at outlook.com> |
| License: | GPL-2 |
| NeedsCompilation: | no |
| CRAN checks: | SoftClustering results |
| Reference manual: | SoftClustering.pdf |
| Package source: | SoftClustering_1.1502.tar.gz |
| Windows binaries: | r-devel: SoftClustering_1.1502.zip, r-release: SoftClustering_1.1502.zip, r-oldrel: SoftClustering_1.1502.zip |
| OS X binaries: | r-release: SoftClustering_1.1502.tgz, r-oldrel: SoftClustering_1.1502.tgz |
| Old sources: | SoftClustering archive |
Please use the canonical form https://CRAN.R-project.org/package=SoftClustering to link to this page.


| I l@ve RuBoard |
12.2 What's a Server-Side CGI Script?Simply put, CGI scripts implement much of the interaction you typically experience on the Web. They are a standard and widely used mechanism for programming web site interaction. There are other ways to add interactive behavior to web sites with Python, including client-side solutions (e.g., JPython applets and Active Scripting), as well as server-side technologies, which build upon the basic CGI model (e.g., Active Server Pages and Zope), and we will discuss these briefly at the end of Chapter 15, too. But by and large, CGI server-side scripts are used to program much of the activity on the Web. 12.2.1 The Script Behind the CurtainFormally speaking, CGI scripts are programs that run on a server machine and adhere to the Common Gateway Interface -- a model for browser/server communications, from which CGI scripts take their name. Perhaps a more useful way to understand CGI, though, is in terms of the interaction it implies. Most people take this interaction for granted when browsing the Web and pressing buttons in web pages, but there is a lot going on behind the scenes of every transaction on the Web. From the perspective of a user, it's a fairly familiar and simple process:
And, believe it or not, that simple model is what makes most of the Web hum. But internally, it's a bit more complex. In fact, there is a subtle client/server socket-based architecture at work -- your web browser running on your computer is the client, and the computer you contact over the Web is the server. Let's examine the interaction scenario again, with all the gory details that users usually never see.
In other words, CGI scripts are something like callback handlers for requests generated by web browsers that require a program to be run dynamically; they are automatically run on the server machine in response to actions in a browser. Although CGI scripts ultimately receive and send standard structured messages over sockets, CGI is more like a higher-level procedural convention for sending and receiving information between a browser and a server. 12.2.2 Writing CGI Scripts in PythonIf all of the above sounds complicated, relax -- Python, as well as the resident HTTP server, automates most of the tricky bits. CGI scripts are written as fairly autonomous programs, and they assume that startup tasks have already been accomplished. The HTTP web server program, not the CGI script, implements the server-side of the HTTP protocol itself. Moreover, Python's library modules automatically dissect information sent up from the browser and give it to the CGI script in an easily digested form. The upshot is that CGI scripts may focus on application details like processing input data and producing a result page. As mentioned earlier, in the context of CGI scripts, the stdin and stdout streams are automatically tied to sockets connected to the browser. In addition, the HTTP server passes some browser information to the CGI script in the form of shell environment variables. To CGI programmers, that means:
The most complex parts of this scheme include parsing all the input information sent up from the browser and formatting information in the reply sent back. Happily, Python's standard library largely automates both tasks:
We'll study both of these interfaces in detail later in this chapter. For now, keep in mind that although any language can be used to write CGI scripts, Python's standard modules and language attributes make it a snap. Less happily, CGI scripts are also intimately tied to the syntax of HTML, since they must generate it to create a reply page. In fact, it can be said that Python CGI scripts embed HTML, which is an entirely distinct language in its own right. As we'll also see, the fact that CGI scripts create a user interface by printing HTML syntax means that we have to take special care with the text we insert into a web page's code (e.g., escaping HTML operators). Worse, CGI scripts require at least a cursory knowledge of HTML forms, since that is where the inputs and target script's address are typically specified. This book won't teach HTML in-depth; if you find yourself puzzled by some of the arcane syntax of the HTML generated by scripts here, you should glance at an HTML introduction, such as O'Reilly's HTML and XHTML: The Definitive Guide. 12.2.3 Running Server-Side ExamplesLike GUIs, web-based systems are highly interactive, and the best way to get a feel for some of these examples is to test-drive them live. Before we get into some code, it's worth noting that all you need to run the examples in the next few chapters is a web browser. That is, all the Web examples we will see here can be run from any web browser on any machine, whether you've installed Python on that machine or not. Simply type this URL at the top:[1]
http://starship.python.net/~lutz/PyInternetDemos.html That address loads a launcher page with links to all the example files installed on a server machine whose domain name is starship.python.net (a machine dedicated to Python developers). The launcher page itself appears as shown in Figure 12-1, running under Internet Explorer. It looks similar in other browsers. Each major example has a link on this page, which runs when clicked. Figure 12-1. The PyInternetDemos launcher pageThe launcher page, and all the HTML files in this chapter, can also be loaded locally, from the book's example distribution directory on your machine. They can even be opened directly off the book's CD (view CD-ROM content online at http://examples.oreilly.com/python2)and may be opened by buttons on the top-level book demo launchers. However, the CGI scripts ultimately invoked by some of the example links must be run on a server, and thus require a live Internet connection. If you browse root pages locally on your machine, your browser will either display the scripts' source code or tell you when you need to connect to the Web to run a CGI script. On Windows, a connection dialog will likely pop up automatically, if needed. <IP_ADDRESS> Changing server-side examplesOf course, running scripts in your browser isn't quite the same as writing scripts on your own. If you do decide to change these CGI programs or write new ones from scratch, you must be able to access web server machines:
Unlike the last chapter's examples, Python server-side scripts require both Python and a server. That is, you'll need access to a web server machine that supports CGI scripts in general and that either already has an installed Python interpreter or lets you install one of your own. Some Internet Service Providers (ISPs) are more supportive than others on this front, but there are many options here, both commercial and free (more on this later). Once you've located a server to host your scripts, you may modify and upload the CGI source code file from this book's CD to your own server and site by FTP. If you do, you may also want to run two Python command-line scripts on your server after uploading: fixcgi.py and fixsitename.py, both presented later in this chapter. The former sets CGI script permissions, and the latter replaces any starship server name references in example links and forms with your own server's name. We'll study additional installation details later in this chapter, and explore a few custom server options at the end of Chapter 15. <IP_ADDRESS> Viewing server-side examples and outputThe source code of examples in this part of the book is listed in the text and included on the book's CD (see http://examples.oreilly.com/python2). In all cases, if you wish to view the source code of an HTML file, or the HTML generated by a Python CGI script, you can also simply select your browser's View Source menu option while the corresponding web page is displayed. Keep in mind, though, that your browser's View Source option lets you see the output of a server-side script after it has run, but not the source code of the script itself. There is no automatic way to view the Python source code of the CGI scripts themselves, short of finding them in this book or its CD. To address this issue, later in this chapter we'll also write a CGI-based program called getfile, which allows the source code of any file on this book's web site (HTML, CGI script, etc.) to be downloaded and viewed. Simply type the desired file's name into a web page form referenced by the getfile.html link on the Internet demos launcher page, or add it to the end of an explicitly typed URL as a parameter like this: http://.../getfile.cgi?filename=somefile.cgi In response, the server will ship back the text of the named file to your browser. This process requires explicit interface steps, though, and much more knowledge than we've gained thus far, so see ahead for details. |
| I l@ve RuBoard |


## START Visualization Options and WEMI Selection DIV
## START Main Visualization For WEMI Cube View DIV
## END row 1 DIV
## END content DIV
One way to visualize the underlying concepts behind ${project.name} is to think of a Work-Expression-Manifestation-Item as a Bibliographic Cube with different types of Metadata slices.
## END Visualization Options and WEMI Selection DIV


Node-RED provides a browser-based editor that makes it easy to wire together flows that can be deployed to the runtime in a single-click.
The version running here has been customised for Heroku.
More information about Node-RED, including documentation, can be found at nodered.org.
This template instance of Node-RED is enough to get you started creating flows.
You may want to customise it for your needs, for example replacing this introduction page with your own, adding http authentication to the flow editor or adding new nodes to the palette.
By default, the editor is open for anyone to access and modify flows. To password-protect the editor:
Add the following user-defined variables.
NODE_RED_USERNAME
- the username to secure the editor withNODE_RED_PASSWORD
- the password to secure the editor withpackage.json
to the
dependencies
section. The format is:
"node-red-package-name":"x.y.x"where
x.y.z
is the desired
version number.
SAVE
Inject node in the first Flow to push
flows.json
, flows_cred.json
and package.json
to
GitHub, after new flows are deployed and/or new nodes installed into the Palette.
public
directory.settings.js
, delete the httpStatic
and
httpAdminRoot
entries.


This is a viz inspired from a burning flame.
The X axis here is the country.
The Y axis can be any factor eg here its (Shelter|House|Food). They can me more than 3 also
The factors are represented in a nested flame viz mapped with each color.
On hover you can see a brief tooltip info.
For more info on code and data head to
Github
.
Source code available at
Github
Created with
♥
by
Vinod Louis.


--- layout: post date: 2010-04-12 time: "10:00:00" authors: ["Greg Wilson"] title: Teaching Open Source tags: ["Noticed", "Opinion"] ---
Over at opensource.com, Red Hat's Greg DeKoenigsberg has a post about a new collaboratively-authored textbook on open source software aimed squarely at undergrad courses. As Máirín Duffy points out in the first comment, it's very code-centric, but in my experience, that's the right approach: students won't be ready for discussion of design until they're proficient in coding [1]. I'm looking forward to borrowing lots from the book for Software Carpentry...
[1] This is, by the way, why I believe that attempts to teach "computational thinking" without first teaching programming are doomed to fail, but that's a rant for another time.


User name is required!
User Name must be at least 4 characters!
{{message}}
Password is required!
Minimum Password length should 8 characters
{{formError}}


Install Gazebo Simulator (v1.9) for Robot Operating System (ROS) on Ubuntu 12.04 LTS (Preceise). I picked this version of Ubuntu since it has long term support till April, 2017. I picked Gazebo 1.9 since that has the best integration with ROS.
If you are interested in using the Gazebo Simulator with Robot Operating System (ROS), please insgtall ROS first using instructions here.
NOTE: If you installed the full desktop version of ROS, then Gazebo is installed along with it and you can skip the install steps below and jump to the verification step.
Run the following scripts to setup sources, keys, install and setup the environment
sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu precise main" > /etc/apt/sources.list.d/gazebo-latest.list' wget http://packages.osrfoundation.org/gazebo.key -O - | sudo apt-key add - sudo apt-get update sudo apt-get install gazeboHere is the raw version of the script above.
Check your installation using the following.
gzserver # This will start the server gzclient # This will start the GUI gazebo # This command should openup a GUI if Gazebo was installed correctly.Here is the raw version of the script above.
For Gazebo with ROS, do the following.
sudo apt-get install ros-hydro-gazebo-ros-pkgs ros-hydro-gazebo-ros-controlHere is the raw version of the script above.
External Links


What is TacocaT engine?
Tacocat engine is a 3D engine made for the subject of 3D engines of the polytechnic university of catalonia imparted by Ricard Pillosu
Our Team
Main subsystems:
- Importer
- Can drag and drop multiple file formats into the engine in order to load them
- Camera
- Camera movement using WASD keys and right mouse or Alt + left mouse to orbit camera
- Meshes and textures
- Can load and display 3d objects and textures
- Hierarchy
- Display all loaded objects in scene with a hierarchy, can also select withing hierarchy
- Transform
- Can modify position rotation and scale of gameobjects, also available with a gizmo
- Mouse pick
- Can select gameobjects using mouse picks
- Quadtree
- Static gameobjects are selected more quickly using a quadtree
- Camera FOV
- Gameobjects outside the field of view are not loaded
- Window resize
- Resize window using borders
- Bounding boxes
- All objects are surrounded by bounding boxes in order to ease selection and visualization
- Scene serialization
- Save scene to be able to load it later
- Own fileformat
- All assets used are converted into our own fileformat to speed up the loading process
- Time management
- Can play pause stop scene in order to make adjustments, press play to save settings and stop to reload everything
- Resource management
- If you load the same object twice the memory doesn't increase
Wwise
For the 3rd delivery we had to implement Wwise, a middleware that eases the process of integrating audio into a 3d engine
We used the version 2<IP_ADDRESS>77 of Wwise for our implementation, using other versions to import soundbanks may cause problems when loading soundbanks.
MIT License
Copyright (c) 2018 Hugo-Bo-Diaz
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


The idea of this project is to create portrait effect from videos using Structure from motion and 3D segmentation


Models
A LinkML model describes the structure of your data. Your data can be expressed as JSON or YAML files (the default form for LinkML), or as CSVs, or as a relational database, or even a triplestore or graph database.
LinkML models are authored as YAML files. These files can be understood as data files that instantiate SchemaDefinitions in the LinkML metamodel.
The overall layout of a schema yaml file is roughly as follows:
id: https://example.org/my-schema
name: my_schema
<OTHER METADATA HERE>
# classes are the main organization until for data;
# all data records instantiate a class
classes:
Person:
...
Organization:
...
# data fields get their own section
slots:
name:
...
email:
...
age:
...
# optional: schema type extensions
types:
AgeType:
...
# enumerations
enums:
GenderType:
...
To illustrate we will use an example schema for modeling people and attributes about people. The full schema can be found in this repo at examples/PersonSchema
Model metadata and directives
A LinkML model/schema may have various pieces of metadata associated with it, for example:
id: https://w3id.org/linkml/examples/personinfo
name: personinfo
description: |-
Information about people, based on [schema.org](http://schema.org)
license: https://creativecommons.org/publicdomain/zero/1.0/
default_curi_maps:
- semweb_context
imports:
- linkml:types
prefixes:
personinfo: https://w3id.org/linkml/examples/personinfo/
linkml: https://w3id.org/linkml/
schema: http://schema.org/
rdfs: http://www.w3.org/2000/01/rdf-schema#
prov: http://www.w3.org/ns/prov#
default_prefix: personinfo
default_range: string
...
names, identifiers, and metadata
id – the unique identifier for the schema, as a IRI
name – the schema name. Use only alphanumeric characters, underscores, and dashes
description – a summary of the schema. Can include markdown formatting
license – CC0 recommended
modules
prefix management
prefixes – A map of prefixes. See prefixes
default_prefixes – The prefix used for all elements in this schema
default_curi_maps – prefix maps from prefixcommons
other
default_range – The default range for all slots
See also uris-and-mappings
Classes
Classes provide templates for organizing data. Data objects should instantiate classes in the schema. Each class has a set of slots (aka fields, attributes) that are applicable to it.
Classes operate in a very similar way to classes in a programming language like Python or Java. They are analogous to tables in relational databases.
Classes are defined in a classes
block at the top level of your YAML, where the key is the class name:
classes:
Person:
is_a: NamedThing
description: >-
A person (alive, dead, undead, or fictional).
class_uri: schema:Person
mixins:
- HasAliases
slots:
- primary_email
- birth_date
- age_in_years
- gender
- has_employment_history
- has_familial_relationships
- has_medical_history
See ClassDefinition for a full list of allowed slots
Note: class names can be normal natural language noun phrases
encompassing characters such as spaces. However, when converted to
external representations, different rules will be applied, and
typically the exported name is in PascalCase. So for example, you
could call your class named thing
, but the URI for the class would
be myprefix:NamedThing
Because LinkML is described in LinkML, your schema is an
instantiation of the LinkML metamodel, and schema elements have a list
of allowed slots. So for example, is_a
, description
, and slots
are all slots that are applicable to instances of
ClassDefinitions.
This is a little meta at first but you get used to it!
Slots
Slots (aka attributes, fields, columns, properties) can be associated with classes to specify what fields instances of that class can have
For example, in the schema above, instances of Person classes can have values for primary email, birthdate, etc.
In LinkML slots are “first class” and are defined independently of classes, and a slot can be used in any number of classes.
Slots are defined in a slots
block at the top level of your YAML:
slots:
id:
identifier: true
slot_uri: schema:identifier
name:
slot_uri: schema:name
gender:
slot_uri: schema:gender
range: gender_enum
age_in_years:
range: integer
minimum_value: 0
maximum_value: 999
has_employment_history:
range: EmploymentEvent
multivalued: true
inlined_as_list: true
current_address:
range: Address
You can then re-use these in your class definitions. For example, if your Person
class has a name
slot, just list it:
classes:
Person:
...
slots:
- ...
- name
- ...
Note that LinkML models are “closed” by default. If a slot is not listed for a class, then data that includes an unlisted slot will be invalid.
Slots are inherited, so for example if name
is listed
as an allowed slot for NamedThing
, and Person
inherits from
NamedThing, then name
will be valid for Person. There is no need to
re-declare
See SlotDefinition for a full list of which metamodel slots can be applied to slots.
The Attribute slot
As a convenience feature, you can specify slot definitions directly within a class using the attributes
slot:
classes:
Person:
is_a: NamedThing
description: >-
A person (alive, dead, undead, or fictional).
class_uri: schema:Person
mixins:
- HasAliases
attributes:
gender:
slot_uri: schema:gender
range: gender_enum
age_in_years:
range: integer
minimum_value: 0
maximum_value: 999
Types
See TypeDefinition in the metamodel.
Types in LinkML are scalar data values such as strings, integers, floats, and so on. LinkML comes with its own set of types, and these can be extended.
For example, you may represent chemical formulae as strings in your model, but if you provide an explicit type that maps to string, it makes the intended meaning clearer, and different applications can operate on these differently:
chemical formula value:
uri: xsd:string
base: str
description: A chemical formula
Enums
The core enumeration model is the same as for familiar systems, where there is a set of allowed string values:
enums:
FamilialRelationshipType:
permissible_values:
SIBLING_OF:
PARENT_OF:
CHILD_OF:
You can also make your enums into a ticher controlled vocabulary, with definitions built in:
enums:
FamilialRelationshipType:
permissible_values:
SIBLING OF:
description: A family relationship where the two members have a parent on common
PARENT OF:
description: A family relationship between offspring and their parent
CHILD OF:
description: inverse of the PARENT_OF relationship
(note you can include spaces in your enums if you like)
LinkML goes beyond most frameworks and allows your enums to be backed by external ontologies. For example, this enum is backed by GSSO
prefixes:
GGSO: http://purl.obolibrary.org/obo/GSSO_
enums:
GenderType:
permissible_values:
nonbinary man:
meaning: GSSO:009254
nonbinary woman:
meaning: GSSO:009253
transgender woman:
meaning: GSSO:000384
transgender man:
meaning: GSSO:000372
cisgender man:
meaning: GSSO:000371
cisgender woman:
meaning: GSSO:000385
Subsets
Elements of a schema can be partitioned into named subsets. These have no semantic meaning, but they can be useful for tagging parts of a schema for different purposs.


Home
Add Rectangle
Rectangle Cart
Rectangle Attributes for:
Name
Color
Width
Height
Radius
Edit
Delete


Language::Farnsworth::Evaluate
This is an internally used class and has nothing of value to be used by the "public"
Clean up some of the code and try to create/document a public interface, since this will be neccesary for creating the plugin interface.
Ryan Voots<EMAIL_ADDRESS>Copyright (C) 2010 by Ryan Voots
This library is free software; It is licensed exclusively under the Artistic License version 2.0 only.


---
layout: def
---
The unity operator basically changes a frame of reference
If $U^{\dagger}U=1$, where $U^{\dagger}$ is the Hermitian conjungate. For a constant operator, $U^{\dagger}$ is the complex conjungate of the matrix.
Notations
The unity operator is often denoted by a $U$. All that's required for an operator to be unity is $U^{\dagger}U=1$.
 Then
$$\begin{align*}
\langle A \rangle &= \langle \psi| A|\psi\rangle \\
&=\langle \psi|U^{\dagger}U A U^{\dagger} U|\psi\rangle \\
&=\langle \psi'| A' |\psi\rangle,
\end{align*}$$
where $A'=UAU^{\dagger}$. Since $U^{\dagger}$ is the Hermitian conjungate of $U$, then $\langle \psi|U^{\dagger}=\langle \psi'|$ and $U|\psi'\rangle=|\psi'\rangle$, where $|\psi'\rangle$ is the new state in the new reference frame.
That is, if we transform a quantum state $|\psi\rangle$ by an unitary operator $U$ expectation values of an arbitary operator $A$ does not change as long as we transform $A$ into $A'=UAU^{\dagger}$.
For exaple,
$$\begin{align*}
U=\begin{bmatrix}e^{i\theta/2} & 0 \\ 0 & e^{-i\theta/2}\end{bmatrix}
\end{align*}$$ rotates a frame of reference by $\theta$.


Meet Erin Price
Erin Price writes children's, middle grade, and young adult fiction. Her young adult novel, Walls, is available on Amazon, and she is currently working on a new middle grade novel, Lucky Me, about a pair of quirky sisters. Her stories and articles have been published in magazines such as the Friend and LDS Living.
Although she prefers to write for young people, Erin often writes for adults, too.  She also recently won second place in the Loudoun County Library System's Write On! short story contest.
Erin has a degree in English with a minor in editing. She has taken many creative writing courses and attended writing conferences offered by the Society of Children's Book Writers and Editors (SCBWI) and Writing and Illustrating for Young Readers (WIFYR). Erin tells stories that lift and inspire young readers—stories that show readers that no matter how dark life may seem, there is always hope, light, and laughter available.


hello world
this is a heading
this is a paragraph
this is a paragraph
this is a paragraph
this is a paragraph