Toolkits > SampleNetflowMessageParser 2.0.0 > sample > TestNetflowMessageParserFullVerion9.spl
composite TestNetflowMessageParserFullVersion9 { param expression<rstring> $pcapFilename: getSubmissionTimeValue("pcapFilename", "../../SampleNetworkToolkitData/data/sample_netflow9_new.pcap" ); type PacketType = float64 captureTime, // time that packet was captured, in seconds since Unix epoch uint32 netflowSource, // IP source address of Netflow message blob netflowMessage; // the Netflow message from a packet, excluding all network headers NetflowMessageType = rstring captureTime, // time that packet was captured, in seconds since Unix epoch boolean parseError, rstring parseErrorDescription, uint32 parseErrorOffset, uint64 messagesProcessed, uint16 NETFLOW_VERSION, // header: Netflow version uint16 NETFLOW_COUNT, // header: number of records (including templates, options, and flows) rstring NETFLOW_SYSTEM_UPTIME, // header: time since source was booted, in milliseconds, converted to seconds rstring NETFLOW_UNIX_SECONDS, // header: time since beginning of Unix epoch, in seconds uint32 NETFLOW_SEQUENCE_NUMBER, // header: sequence number of this message uint32 NETFLOW_SOURCE_ID, // header: identifier of source of this message uint64 NETFLOW_IN_BYTES, // field 1: Incoming counter with length N x 8 bits for number of bytes associated with an IP Flow. uint64 NETFLOW_IN_PKTS, // field 2: Incoming counter with length N x 8 bits for the number of packets associated with an IP Flow uint64 NETFLOW_FLOWS, // field 3: Number of flows that were aggregated; default for N is 4 uint8 NETFLOW_PROTOCOL, // field 4: IP protocol byte uint8 NETFLOW_SRC_TOS, // field 5: Type of Service byte setting when entering incoming interface uint8 NETFLOW_TCP_FLAGS, // field 6: Cumulative of all the TCP flags seen for this flow uint16 NETFLOW_SRC_PORT, // field 7: TCP/UDP source port number i.e.: FTP, Telnet, or equivalent rstring NETFLOW_IPV4_SRC_ADDR, // field 8: IPv4 source address uint8 NETFLOW_SRC_MASK, // field 9: The number of contiguous bits in the source address subnet mask i.e.: the submask in slash notation uint32 NETFLOW_INPUT_INTERFACE, // field 10: Input interface index; default for N is 2 but higher values could be used uint16 NETFLOW_DST_PORT, // field 11: TCP/UDP destination port number i.e.: FTP, Telnet, or equivalent rstring NETFLOW_IPV4_DST_ADDR, // field 12: IPv4 destination address uint8 NETFLOW_DST_MASK, // field 13: The number of contiguous bits in the destination address subnet mask i.e.: the submask in slash notation uint32 NETFLOW_OUTPUT_INTERFACE, // field 14: Output interface index; default for N is 2 but higher values could be used rstring NETFLOW_IPV4_NEXT_HOP, // field 15: IPv4 address of next-hop router uint32 NETFLOW_SRC_AS, // field 16: Source BGP autonomous system number where N could be 2 or 4 uint32 NETFLOW_DST_AS, // field 17: Destination BGP autonomous system number where N could be 2 or 4 rstring NETFLOW_BGP_IPV4_NEXT_HOP, // field 18: Next-hop router's IP in the BGP domain uint64 NETFLOW_MUL_DST_PKTS, // field 19: IP multicast outgoing packet counter with length N x 8 bits for packets associated with the IP Flow uint64 NETFLOW_MUL_DST_BYTES, // field 20: IP multicast outgoing byte counter with length N x 8 bits for bytes associated with the IP Flow rstring NETFLOW_LAST_SWITCHED, // field 21: System uptime at which the last packet of this flow was switched rstring NETFLOW_FIRST_SWITCHED, // field 22: System uptime at which the first packet of this flow was switched uint64 NETFLOW_OUT_BYTES, // field 23: Outgoing counter with length N x 8 bits for the number of bytes associated with an IP Flow uint64 NETFLOW_OUT_PKTS, // field 24: Outgoing counter with length N x 8 bits for the number of packets associated with an IP Flow. uint16 NETFLOW_MIN_PKT_LNGTH, // field 25: Minimum IP packet length on incoming packets of the flow uint16 NETFLOW_MAX_PKT_LNGTH, // field 26: Maximum IP packet length on incoming packets of the flow rstring NETFLOW_IPV6_SRC_ADDR, // field 27: IPv6 Source Address rstring NETFLOW_IPV6_DST_ADDR, // field 28: IPv6 Destination Address uint8 NETFLOW_IPV6_SRC_MASK, // field 29: Length of the IPv6 source mask in contiguous bits uint8 NETFLOW_IPV6_DST_MASK, // field 30: Length of the IPv6 destination mask in contiguous bits uint32 NETFLOW_IPV6_FLOW_LABEL, // field 31: IPv6 flow label as per RFC 2460 definition uint16 NETFLOW_ICMP_TYPE, // field 32: Internet Control Message Protocol (ICMP) packet type; reported as ((ICMP Type*256) + ICMP code) uint8 NETFLOW_MUL_IGMP_TYPE, // field 33: Internet Group Management Protocol (IGMP) packet type uint32 NETFLOW_SAMPLING_INTERVAL, // field 34: When using sampled NetFlow, the rate at which packets are sampled i.e.: a value of 100 indicates that one of every 100 packets is sampled uint8 NETFLOW_SAMPLING_ALGORITHM, // field 35: The type of algorithm used for sampled NetFlow: 0x01 Deterministic Sampling ,0x02 Random Sampling uint16 NETFLOW_FLOW_ACTIVE_TIMEOUT, // field 36: Timeout value (in seconds) for active flow entries in the NetFlow cache uint16 NETFLOW_FLOW_INACTIVE_TIMEOUT, // field 37: Timeout value (in seconds) for inactive flow entries in the NetFlow cache uint8 NETFLOW_ENGINE_TYPE, // field 38: Type of flow switching engine: RP = 0, VIP/Linecard = 1 uint8 NETFLOW_ENGINE_ID, // field 39: ID number of the flow switching engine uint64 NETFLOW_TOTAL_BYTES_EXP, // field 40: Counter with length N x 8 bits for bytes for the number of bytes exported by the Observation Domain uint64 NETFLOW_TOTAL_PKTS_EXP, // field 41: Counter with length N x 8 bits for bytes for the number of packets exported by the Observation Domain uint64 NETFLOW_TOTAL_FLOWS_EXP, // field 42: Counter with length N x 8 bits for bytes for the number of flows exported by the Observation Domain uint32 NETFLOW_IPV4_SRC_PREFIX, // field 44: IPv4 source address prefix (specific for Catalyst architecture) uint32 NETFLOW_IPV4_DST_PREFIX, // field 45: IPv4 destination address prefix (specific for Catalyst architecture) uint8 NETFLOW_MPLS_TOP_LABEL_TYPE, // field 46: MPLS Top Label Type: 0x00 UNKNOWN 0x01 TE-MIDPT 0x02 ATOM 0x03 VPN 0x04 BGP 0x05 LDP uint32 NETFLOW_MPLS_TOP_LABEL_IPV4_ADDR, // field 47: Forwarding Equivalent Class corresponding to the MPLS Top Label uint8 NETFLOW_FLOW_SAMPLER_ID, // field 48: Identifier shown in "show flow-sampler" uint8 NETFLOW_FLOW_SAMPLER_MODE, // field 49: The type of algorithm used for sampling data: 0x02 random sampling. Use in connection with FLOW_SAMPLER_MODE uint32 NETFLOW_FLOW_SAMPLER_RANDOM_INTERVAL, // field 50: Packet interval at which to sample. Use in connection with FLOW_SAMPLER_MODE uint8 NETFLOW_MIN_TTL, // field 52: Minimum TTL on incoming packets of the flow uint8 NETFLOW_MAX_TTL, // field 53: Maximum TTL on incoming packets of the flow uint16 NETFLOW_IPV4_IDENT, // field 54: The IP v4 identification field uint8 NETFLOW_DST_TOS, // field 55: Type of Service byte setting when exiting outgoing interface rstring NETFLOW_MAC_SRC_ADDR_IN, // field 56: Incoming source MAC address rstring NETFLOW_MAC_DST_ADDR_OUT, // field 57: Outgoing destination MAC address uint16 NETFLOW_SRC_VLAN, // field 58: Virtual LAN identifier associated with ingress interface uint16 NETFLOW_DST_VLAN, // field 59: Virtual LAN identifier associated with egress interface uint8 NETFLOW_IP_PROTOCOL_VERSION, // field 60: Internet Protocol Version Set to 4 for IPv4, set to 6 for IPv6. If not present in the template, then version 4 is assumed. uint8 NETFLOW_DIRECTION, // field 61: Flow direction: 0 - ingress flow, 1 - egress flow rstring NETFLOW_IPV6_NEXT_HOP, // field 62: IPv6 address of the next-hop router rstring NETFLOW_BPG_IPV6_NEXT_HOP, // field 63: Next-hop router in the BGP domain uint32 NETFLOW_IPV6_OPTION_HEADERS, // field 64: Bit-encoded field identifying IPv6 option headers found in the flow list<uint8> NETFLOW_MPLS_LABEL_1, // field 70: MPLS label at position 1 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_2, // field 71: MPLS label at position 2 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_3, // field 72: MPLS label at position 3 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_4, // field 73: MPLS label at position 4 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_5, // field 74: MPLS label at position 5 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_6, // field 75: MPLS label at position 6 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_7, // field 76: MPLS label at position 7 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_8, // field 77: MPLS label at position 8 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_9, // field 78: MPLS label at position 9 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. list<uint8> NETFLOW_MPLS_LABEL_10, // field 79: MPLS label at position 10 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. rstring NETFLOW_MAC_DST_ADDR_IN, // field 80: Incoming destination MAC address rstring NETFLOW_MAC_SRC_ADDR_OUT, // field 81: Outgoing source MAC address rstring NETFLOW_IF_NAME, // field 82: Shortened interface name i.e.: "FE1/0" rstring NETFLOW_IF_DESC, // field 83: Full interface name i.e.: "FastEthernet 1/0" rstring NETFLOW_SAMPLER_NAME, // field 84: Name of the flow sampler uint64 NETFLOW_IN_PERMANENT_BYTES, // field 85: Running byte counter for a permanent flow uint64 NETFLOW_IN_PERMANENT_PKTS, // field 86: Running packet counter for a permanent flow uint16 NETFLOW_FRAGMENT_OFFSET, // field 88: The fragment-offset value from fragmented IP packets uint8 NETFLOW_FORWARDING_STATUS, // field 89: Forwarding status is encoded on 1 byte with the 2 left bits giving the status and the 6 remaining bits giving the reason code. list<uint8> NETFLOW_MPLS_PAL_RD, // field 90: MPLS PAL Route Distinguisher. uint8 NETFLOW_MPLS_PREFIX_LEN, // field 91: Number of consecutive bits in the MPLS prefix length. uint32 NETFLOW_SRC_TRAFFIC_INDEX, // field 92: BGP Policy Accounting Source Traffic Index uint32 NETFLOW_DST_TRAFFIC_INDEX, // field 93: BGP Policy Accounting Destination Traffic Index rstring NETFLOW_APPLICATION_DESCRIPTION, // field 94: Application description. list<uint8> NETFLOW_APPLICATION_TAG, // field 95: 8 bits of engine ID, followed by n bits of classification. rstring NETFLOW_APPLICATION_NAME, // field 96: Name associated with a classification. uint8 NETFLOW_POST_IP_DSCP, // field 98: The value of a Differentiated Services Code Point (DSCP) encoded in the Differentiated Services Field, after modification. uint32 NETFLOW_REPLICATION_FACTOR, // field 99: Multicast replication factor. uint32 NETFLOW_FIELD_8_AS_INTEGER, list<uint8> NETFLOW_FIELD_8_AS_BYTE_LIST, rstring NETFLOW_FIELD_82_AS_STRING; graph stream<PacketType> PacketStream as Out = PacketFileSource() { param pcapFilename: $pcapFilename; inputFilter: "udp port 2055"; metricsInterval: 0.0; output Out: captureTime = (float64)CAPTURE_SECONDS() + (float64)CAPTURE_MICROSECONDS() / 1000000.0, netflowSource = IPV4_SRC_ADDRESS(), netflowMessage = PAYLOAD_DATA(); } () as PacketSink = FileSink(PacketStream) { param file: "debug.TestNetflowMessageParserFullVersion9.PacketStream.out"; format: txt; hasDelayField: true; flush: 1u; } stream<NetflowMessageType> NetflowMessageStream as Out = NetflowMessageParser(PacketStream) { param messageAttribute: netflowMessage; sourceAttribute: netflowSource; output Out: captureTime = formatEpochDateTime(captureTime), parseError = parseError(), parseErrorDescription = parseErrorDescription(), parseErrorOffset = parseErrorOffset(), messagesProcessed = messagesProcessed(), NETFLOW_VERSION = NETFLOW_VERSION(), // header: Netflow version NETFLOW_COUNT = NETFLOW_COUNT(), // header: number of records (including templates, options, and flows) NETFLOW_SYSTEM_UPTIME = formatElapsedTime((float64)NETFLOW_SYSTEM_UPTIME()/1000.0, 3u), // header: time since source was booted, in milliseonds, converted to seconds NETFLOW_UNIX_SECONDS = formatEpochTime(NETFLOW_UNIX_SECONDS()), // header: time since beginning of Unix epoch, in seconds NETFLOW_SEQUENCE_NUMBER = NETFLOW_SEQUENCE_NUMBER(), // header: sequence number of this message NETFLOW_SOURCE_ID = NETFLOW_SOURCE_ID(), // header: identifier of source of this message NETFLOW_IN_BYTES = NETFLOW_IN_BYTES(), // field 1: Incoming counter with length N x 8 bits for number of bytes associated with an IP Flow. NETFLOW_IN_PKTS = NETFLOW_IN_PKTS(), // field 2: Incoming counter with length N x 8 bits for the number of packets associated with an IP Flow NETFLOW_FLOWS = NETFLOW_FLOWS(), // field 3: Number of flows that were aggregated; default for N is 4 NETFLOW_PROTOCOL = NETFLOW_PROTOCOL(), // field 4: IP protocol byte NETFLOW_SRC_TOS = NETFLOW_SRC_TOS(), // field 5: Type of Service byte setting when entering incoming interface NETFLOW_TCP_FLAGS = NETFLOW_TCP_FLAGS(), // field 6: Cumulative of all the TCP flags seen for this flow NETFLOW_SRC_PORT = NETFLOW_SRC_PORT(), // field 7: TCP/UDP source port number i.e.: FTP, Telnet, or equivalent NETFLOW_IPV4_SRC_ADDR = convertIPV4AddressNumericToString(NETFLOW_IPV4_SRC_ADDR()), // field 8: IPv4 source address NETFLOW_SRC_MASK = NETFLOW_SRC_MASK(), // field 9: The number of contiguous bits in the source address subnet mask i.e.: the submask in slash notation NETFLOW_INPUT_INTERFACE = NETFLOW_INPUT_INTERFACE(), // field 10: Input interface index; default for N is 2 but higher values could be used NETFLOW_DST_PORT = NETFLOW_DST_PORT(), // field 11: TCP/UDP destination port number i.e.: FTP, Telnet, or equivalent NETFLOW_IPV4_DST_ADDR = convertIPV4AddressNumericToString(NETFLOW_IPV4_DST_ADDR()), // field 12: IPv4 destination address NETFLOW_DST_MASK = NETFLOW_DST_MASK(), // field 13: The number of contiguous bits in the destination address subnet mask i.e.: the submask in slash notation NETFLOW_OUTPUT_INTERFACE = NETFLOW_OUTPUT_INTERFACE(), // field 14: Output interface index; default for N is 2 but higher values could be used NETFLOW_IPV4_NEXT_HOP = convertIPV4AddressNumericToString(NETFLOW_IPV4_NEXT_HOP()), // field 15: IPv4 address of next-hop router NETFLOW_SRC_AS = NETFLOW_SRC_AS(), // field 16: Source BGP autonomous system number where N could be 2 or 4 NETFLOW_DST_AS = NETFLOW_DST_AS(), // field 17: Destination BGP autonomous system number where N could be 2 or 4 NETFLOW_BGP_IPV4_NEXT_HOP = convertIPV4AddressNumericToString(NETFLOW_BGP_IPV4_NEXT_HOP()), // field 18: Next-hop router's IP in the BGP domain NETFLOW_MUL_DST_PKTS = NETFLOW_MUL_DST_PKTS(), // field 19: IP multicast outgoing packet counter with length N x 8 bits for packets associated with the IP Flow NETFLOW_MUL_DST_BYTES = NETFLOW_MUL_DST_BYTES(), // field 20: IP multicast outgoing byte counter with length N x 8 bits for bytes associated with the IP Flow NETFLOW_LAST_SWITCHED = formatElapsedTime((float64)NETFLOW_LAST_SWITCHED()/1000.0, 3u), // flow: System uptime at which the last packet of this flow was switched NETFLOW_FIRST_SWITCHED = formatElapsedTime((float64)NETFLOW_FIRST_SWITCHED()/1000.0, 3u), // flow: System uptime at which the first packet of this flow was switched NETFLOW_OUT_BYTES = NETFLOW_OUT_BYTES(), // field 23: Outgoing counter with length N x 8 bits for the number of bytes associated with an IP Flow NETFLOW_OUT_PKTS = NETFLOW_OUT_PKTS(), // field 24: Outgoing counter with length N x 8 bits for the number of packets associated with an IP Flow. NETFLOW_MIN_PKT_LNGTH = NETFLOW_MIN_PKT_LNGTH(), // field 25: Minimum IP packet length on incoming packets of the flow NETFLOW_MAX_PKT_LNGTH = NETFLOW_MAX_PKT_LNGTH(), // field 26: Maximum IP packet length on incoming packets of the flow NETFLOW_IPV6_SRC_ADDR = convertIPV6AddressNumericToString(NETFLOW_IPV6_SRC_ADDR()), // field 27: IPv6 Source Address NETFLOW_IPV6_DST_ADDR = convertIPV6AddressNumericToString(NETFLOW_IPV6_DST_ADDR()), // field 28: IPv6 Destination Address NETFLOW_IPV6_SRC_MASK = NETFLOW_IPV6_SRC_MASK(), // field 29: Length of the IPv6 source mask in contiguous bits NETFLOW_IPV6_DST_MASK = NETFLOW_IPV6_DST_MASK(), // field 30: Length of the IPv6 destination mask in contiguous bits NETFLOW_IPV6_FLOW_LABEL = NETFLOW_IPV6_FLOW_LABEL(), // field 31: IPv6 flow label as per RFC 2460 definition NETFLOW_ICMP_TYPE = NETFLOW_ICMP_TYPE(), // field 32: Internet Control Message Protocol (ICMP) packet type; reported as ((ICMP Type*256) + ICMP code) NETFLOW_MUL_IGMP_TYPE = NETFLOW_MUL_IGMP_TYPE(), // field 33: Internet Group Management Protocol (IGMP) packet type NETFLOW_SAMPLING_INTERVAL = NETFLOW_SAMPLING_INTERVAL(), // field 34: When using sampled NetFlow, the rate at which packets are sampled i.e.: a value of 100 indicates that one of every 100 packets is sampled NETFLOW_SAMPLING_ALGORITHM = NETFLOW_SAMPLING_ALGORITHM(), // field 35: The type of algorithm used for sampled NetFlow: 0x01 Deterministic Sampling ,0x02 Random Sampling NETFLOW_FLOW_ACTIVE_TIMEOUT = NETFLOW_FLOW_ACTIVE_TIMEOUT(), // field 36: Timeout value (in seconds) for active flow entries in the NetFlow cache NETFLOW_FLOW_INACTIVE_TIMEOUT = NETFLOW_FLOW_INACTIVE_TIMEOUT(), // field 37: Timeout value (in seconds) for inactive flow entries in the NetFlow cache NETFLOW_ENGINE_TYPE = NETFLOW_ENGINE_TYPE(), // field 38: Type of flow switching engine: RP = 0, VIP/Linecard = 1 NETFLOW_ENGINE_ID = NETFLOW_ENGINE_ID(), // field 39: ID number of the flow switching engine NETFLOW_TOTAL_BYTES_EXP = NETFLOW_TOTAL_BYTES_EXP(), // field 40: Counter with length N x 8 bits for bytes for the number of bytes exported by the Observation Domain NETFLOW_TOTAL_PKTS_EXP = NETFLOW_TOTAL_PKTS_EXP(), // field 41: Counter with length N x 8 bits for bytes for the number of packets exported by the Observation Domain NETFLOW_TOTAL_FLOWS_EXP = NETFLOW_TOTAL_FLOWS_EXP(), // field 42: Counter with length N x 8 bits for bytes for the number of flows exported by the Observation Domain NETFLOW_IPV4_SRC_PREFIX = NETFLOW_IPV4_SRC_PREFIX(), // field 44: IPv4 source address prefix (specific for Catalyst architecture) NETFLOW_IPV4_DST_PREFIX = NETFLOW_IPV4_DST_PREFIX(), // field 45: IPv4 destination address prefix (specific for Catalyst architecture) NETFLOW_MPLS_TOP_LABEL_TYPE = NETFLOW_MPLS_TOP_LABEL_TYPE(), // field 46: MPLS Top Label Type: 0x00 UNKNOWN 0x01 TE-MIDPT 0x02 ATOM 0x03 VPN 0x04 BGP 0x05 LDP NETFLOW_MPLS_TOP_LABEL_IPV4_ADDR = NETFLOW_MPLS_TOP_LABEL_IPV4_ADDR(), // field 47: Forwarding Equivalent Class corresponding to the MPLS Top Label NETFLOW_FLOW_SAMPLER_ID = NETFLOW_FLOW_SAMPLER_ID(), // field 48: Identifier shown in "show flow-sampler" NETFLOW_FLOW_SAMPLER_MODE = NETFLOW_FLOW_SAMPLER_MODE(), // field 49: The type of algorithm used for sampling data: 0x02 random sampling. Use in connection with FLOW_SAMPLER_MODE NETFLOW_FLOW_SAMPLER_RANDOM_INTERVAL = NETFLOW_FLOW_SAMPLER_RANDOM_INTERVAL(), // field 50: Packet interval at which to sample. Use in connection with FLOW_SAMPLER_MODE NETFLOW_MIN_TTL = NETFLOW_MIN_TTL(), // field 52: Minimum TTL on incoming packets of the flow NETFLOW_MAX_TTL = NETFLOW_MAX_TTL(), // field 53: Maximum TTL on incoming packets of the flow NETFLOW_IPV4_IDENT = NETFLOW_IPV4_IDENT(), // field 54: The IP v4 identification field NETFLOW_DST_TOS = NETFLOW_DST_TOS(), // field 55: Type of Service byte setting when exiting outgoing interface NETFLOW_MAC_SRC_ADDR_IN = convertMACAddressNumericToString(NETFLOW_MAC_SRC_ADDR_IN()), // field 56: Incoming source MAC address NETFLOW_MAC_DST_ADDR_OUT = convertMACAddressNumericToString(NETFLOW_MAC_DST_ADDR_OUT()), // field 57: Outgoing destination MAC address NETFLOW_SRC_VLAN = NETFLOW_SRC_VLAN(), // field 58: Virtual LAN identifier associated with ingress interface NETFLOW_DST_VLAN = NETFLOW_DST_VLAN(), // field 59: Virtual LAN identifier associated with egress interface NETFLOW_IP_PROTOCOL_VERSION = NETFLOW_IP_PROTOCOL_VERSION(), // field 60: Internet Protocol Version Set to 4 for IPv4, set to 6 for IPv6. If not present in the template, then version 4 is assumed. NETFLOW_DIRECTION = NETFLOW_DIRECTION(), // field 61: Flow direction: 0 - ingress flow, 1 - egress flow NETFLOW_IPV6_NEXT_HOP = convertIPV6AddressNumericToString(NETFLOW_IPV6_NEXT_HOP()), // field 62: IPv6 address of the next-hop router NETFLOW_BPG_IPV6_NEXT_HOP = convertIPV6AddressNumericToString(NETFLOW_BPG_IPV6_NEXT_HOP()), // field 63: Next-hop router in the BGP domain NETFLOW_IPV6_OPTION_HEADERS = NETFLOW_IPV6_OPTION_HEADERS(), // field 64: Bit-encoded field identifying IPv6 option headers found in the flow NETFLOW_MPLS_LABEL_1 = NETFLOW_MPLS_LABEL(1), // field 70: MPLS label at position 1 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_2 = NETFLOW_MPLS_LABEL(2), // field 71: MPLS label at position 2 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_3 = NETFLOW_MPLS_LABEL(3), // field 72: MPLS label at position 3 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_4 = NETFLOW_MPLS_LABEL(4), // field 73: MPLS label at position 4 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_5 = NETFLOW_MPLS_LABEL(5), // field 74: MPLS label at position 5 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_6 = NETFLOW_MPLS_LABEL(6), // field 75: MPLS label at position 6 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_7 = NETFLOW_MPLS_LABEL(7), // field 76: MPLS label at position 7 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_8 = NETFLOW_MPLS_LABEL(8), // field 77: MPLS label at position 8 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_9 = NETFLOW_MPLS_LABEL(9), // field 78: MPLS label at position 9 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MPLS_LABEL_10 = NETFLOW_MPLS_LABEL(10), // field 79: MPLS label at position 10 in the stack. This comprises 20 bits of MPLS label, 3 EXP (experimental) bits and 1 S (end-of-stack) bit. NETFLOW_MAC_DST_ADDR_IN = convertMACAddressNumericToString(NETFLOW_MAC_DST_ADDR_IN()), // field 80: Incoming destination MAC address NETFLOW_MAC_SRC_ADDR_OUT = convertMACAddressNumericToString(NETFLOW_MAC_SRC_ADDR_OUT()), // field 81: Outgoing source MAC address NETFLOW_IF_NAME = NETFLOW_IF_NAME(), // field 82: Shortened interface name i.e.: "FE1/0" NETFLOW_IF_DESC = NETFLOW_IF_DESC(), // field 83: Full interface name i.e.: "FastEthernet 1/0" NETFLOW_SAMPLER_NAME = NETFLOW_SAMPLER_NAME(), // field 84: Name of the flow sampler NETFLOW_IN_PERMANENT_BYTES = NETFLOW_IN_PERMANENT_BYTES(), // field 85: Running byte counter for a permanent flow NETFLOW_IN_PERMANENT_PKTS = NETFLOW_IN_PERMANENT_PKTS(), // field 86: Running packet counter for a permanent flow NETFLOW_FRAGMENT_OFFSET = NETFLOW_FRAGMENT_OFFSET(), // field 88: The fragment-offset value from fragmented IP packets NETFLOW_FORWARDING_STATUS = NETFLOW_FORWARDING_STATUS(), // field 89: Forwarding status is encoded on 1 byte with the 2 left bits giving the status and the 6 remaining bits giving the reason code. NETFLOW_MPLS_PAL_RD = NETFLOW_MPLS_PAL_RD(), // field 90: MPLS PAL Route Distinguisher. NETFLOW_MPLS_PREFIX_LEN = NETFLOW_MPLS_PREFIX_LEN(), // field 91: Number of consecutive bits in the MPLS prefix length. NETFLOW_SRC_TRAFFIC_INDEX = NETFLOW_SRC_TRAFFIC_INDEX(), // field 92: BGP Policy Accounting Source Traffic Index NETFLOW_DST_TRAFFIC_INDEX = NETFLOW_DST_TRAFFIC_INDEX(), // field 93: BGP Policy Accounting Destination Traffic Index NETFLOW_APPLICATION_DESCRIPTION = NETFLOW_APPLICATION_DESCRIPTION(), // field 94: Application description. NETFLOW_APPLICATION_TAG = NETFLOW_APPLICATION_TAG(), // field 95: 8 bits of engine ID, followed by n bits of classification. NETFLOW_APPLICATION_NAME = NETFLOW_APPLICATION_NAME(), // field 96: Name associated with a classification. NETFLOW_POST_IP_DSCP = NETFLOW_POST_IP_DSCP(), // field 98: The value of a Differentiated Services Code Point (DSCP) encoded in the Differentiated Services Field, after modification. NETFLOW_REPLICATION_FACTOR = NETFLOW_REPLICATION_FACTOR(), // field 99: Multicast replication factor. NETFLOW_FIELD_8_AS_INTEGER = (uint32)NETFLOW_FIELD_AS_INTEGER(8), NETFLOW_FIELD_8_AS_BYTE_LIST = NETFLOW_FIELD_AS_BYTE_LIST(8), NETFLOW_FIELD_82_AS_STRING = NETFLOW_FIELD_AS_STRING(82); } () as NetflowMessageSink = FileSink(NetflowMessageStream) { param file: "debug.TestNetflowMessageParserFullVersion9.NetflowMessageStream.out"; format: txt; hasDelayField: true; flush: 1u; } }


{{version}}
{{state.visitor_team}}
{{state.home_team}}
STATUS:
DISCONNECTED
Scorekeeping
Baseball scorekeeping can also be done on remote devices at /scorekeeper.
{{state.visitor_team}}
{{state.visitor_score}}
{{state.home_team}}
{{state.home_score}}
INNING
{{state.inning}}
TOP
MID
BOT
END
Clear Bases
OUTS
{{state.outs}}
Out
COUNT
{{state.balls}}
-
{{state.strikes}}
Ball
Strike


{% extends "base.html" %} {% block ttitle %} home page {% endblock %} {% block content %} Material Design for Bootstrap The best and free framework for Bootstrap Get started Go Pro {% endblock%}


This document provides a summary of significant changes made to the software between the previous and current versions (see above). A fully-detailed change summary is provided by the ChangeLog file included in the release package and by the Git commit history:
Added support for optional building against libdeflate for faster Zip/Deflate compression/decompression.
We now have 2 kinds of builds with the Zip/Deflate codec:
Speed improvements in the 35%-50% range can be expected when libdeflate is used. Compression level up to 12 is now supported (capped to 9 when zlib is used). Still requires zlib for situations where libdeflate cannot be used (that is for scanline access, since libdeflate has no streaming mode)
Pseudo-tag TIFFTAG_DEFLATE_SUBCODEC=DEFLATE_SUBCODEC_ZLIB/DEFLATE_SUBCODEC_LIBDEFLATE is added to control which subcodec (zlib or libdeflate) should be used (it defaults of course to libdeflate, when it is available). This is mostly aimed at being used on the writing side, to be able to reproduce output of previous libtiff versions at a binary level, in situations where this would be really needed. Or as a safety belt in case there would be unforeseen issues with using libdeflate. It can be used to know when libdeflate is available at runtime (DEFLATE_SUBCODEC_LIBDEFLATE will be the default value in that situation).
Of course, deflate codestreams produced by libdeflate can be read by zlib, and vice-versa.


"The King Is Alive"
A disparate band of travelers is stranded in a remote part of northern Africa. They take the only means of transportation, a bus, across the desert to safety. But, a faulty compass causes them to stray 500 miles out of their way when the bus breaks down. One intrepid member of the troupe heads off, alone, for help. The rest are left to fend for themselves in latest of the Dogma 95 manifesto films, "The King Is Alive."
Helmer Kristian Levring provides the fourth installment in the stripped-down film aesthetics of the Dogma 95 movement founded by the director and Lars Von Trier. The intent of the movement is to bringing filmmaking back to its essence - no artificial props, lighting or sets, no sound effects or special visual F/X, location shooting only, etc. Levring is fulfills the dictates of the Dogma Manifesto with his story of a journey of lost souls.
When the dozen or so passengers find themselves stranded at an abandoned mining town hundreds of miles from nowhere in the middle of Africa's Namib Desert, they have nothing. The man with survival experience, Jack (Miles Anderson), treks off to find help after explaining the five rules of survival to those remaining - find water, find food, find shelter, stay visible and keep your spirits up.
One of the group, Henry (David Bradley), a stage thespian, realizes the dire strait they are all in and begins to write out all the roles to Shakespeare's "King Lear," mainly to kill the time and keep his sanity. When he suggests to one of the others, a feisty French girl named Catherine (Romane Bohringer), they read the play and learn the parts as a panacea for their dilemma, she glibly turns him down. But, as things get worse and their isolation continues, the appeal to take part in the play increases amongst them all, with each succumbing to the relief the project offers.
As Henry's idea unfolds and takes shape with the players, there is dissention in the ranks as infighting breaks out. Husband and wife Ray (Bruce Davison) and Liz (Janet McTeer) are in conflict as Liz, disillusioned with Ray, humiliates him by openly trying to seduce the other men in the troupe. Amanda (Lia Williams) soon realizes that her significant other, Paul (Chris Walker), is a bully and a pig and wants nothing to do with him. Catherine thinks that Gina (Jennifer Jason Leigh) is just another clinging, needy American, while older Charles just wants carnal knowledge with Gina to prove his masculinity - to himself. Ashley (Brion James) is an alcoholic who, because of the forced isolation without the benefit of booze, is suffering from a severe case of the delirium tremors. The problems facing the stranded travelers do not recede at all and the readings begin to have the cathartic effect that Henry hoped for.
Lenser Jens Schlosser ably captures the wind and sand blown location of the African desert with the gently rolling, and incredibly cruel, sand dunes bringing a flowing grace to the panoramic photography. There are a couple of scenes, obviously shot from an airplane, that show the stark vista of the desert that reminds of the striking desert photography used in "The English Patient" and Bertolucci's "The Sheltering Sky." And all this with a hand-held digital camera.
The story, by Levring and Peter Aalbaek Jensen, required much dedication of purpose by the cast, but tends to keep the viewer at arm's length. There are so many subplots and intrigues between and among the characters, it becomes difficult to empathize with any of them. Not enough time is given to any one player to allow you to know or care about them. The actors do a solid job in each portrayal, but there is not enough time to really flesh anyone out to three-dimensional proportions.
The whole Dogma 95 movement may be a filmmaking tempest in a teapot, but there is a sincere honesty in the craftwork and artistic thought to the story that make a film like "The King Is Alive" an intellectual treat in the desert of Hollywood's summer fare. I give it a B-.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


FME Server
Demos
Fork GitHub
Download Zip
Not powered by FME
404 - Demo not found
Go to demo overview »


Pomodoro Clock
01:30
5:00
Session
25:00
Session Length
25
Break Length
5
Up/Down For Timer
Up/Down for Break
arrow_upward
arrow_downward
arrow_upward
arrow_downward
Choose your alarm sound
Option 1
Option 2
Option 3
play_circle_outline
stop
replay
replay
Alarm Time ⏰
Choose to either turn off the alarm, or to turn of the alarm and start the break timer


--- type: "youtube" title: "Speed Up Your Android Device Without Installing Any Software." yt-video-id: "odJdQBIisaE" description: "Yes You Heard It Right.No 3rd Party Apps,No Ram Boosters,No Root Required,You can speed up your android phone or tablet by using these simple Settings Tweaks..." social_media_msg: ".." featimg: "http://images.dabannit.com/fc8527/2016-03-29-speed-up-your-android-device-without-installing-any-software.html-5d1.jpg" article_videos: "" origin_url: "https://www.youtube.com/watch?v=odJdQBIisaE" ---
Speed Up Your Android Device Without using Any Software


Package it.polimi.ingsw.utils.messages.serverMessages.Updates
-
Class Summary Class Description ActivateProductionUpdate Class containing specific information about an activate production action successfully ended.ActivateVaticanReportUpdate Class consisting an update concerningActivateVaticanReportEvent
.BlackCrossMoveUpdate Class instantiated when during a turn,LorenzoIlMagnifico
moves his cross forward on player faith track according to tokens or as result of an action made by player itself.BuyDevCardPerformedUpdate Class containing specific information about a development card purchase successfully performed.FaithMarkerUpdate Class representing an update after aTakeResourcesFromMarket
action to notify a possible progress in faith track.InitialLeaderChoiceUpdate Class representing an update sent when a player correctly performs initial leaders choice by discarding two of his own cards.InitialResourceChoiceUpdate Class representing an update sent when player correctly performs initial resources choice.LeaderActionUpdate Class representing an update sent when aLeaderAction
is successfully done.LorenzoActivatedVaticanReportUpdate Class representing an update sent in case of a solo mode game, whenLorenzoIlMagnifico
activates a Vatican Report.LorenzoPlayedUpdate Class representing an update sent at the end of a turn while playing a solo mode game.MoveUpdate Class representing an update sent after aNewTurnUpdate Class representing an update sent in order to notify all player about who is the one in turn.PositioningUpdate Class representing an update sent after a resources placement has been correctly performed.ServerAsksForPositioning Class representing one of possible update resulting from aTakeResourcesFromMarket
.TakeResourcesFromMarketUpdate Class representing second possible update resulting from aTakeResourcesFromMarket
action.UpdateMessage Abstract class representing a message sent from server to client in order to notify it that there has been a game state change.


Get notifications in Telegram whenever your favorite models are online! You subscribe to your favorite webcam models with /add command. We notify you whenever they start broadcasting.
To see the bots in other languages change the language at the bottom of this page
Replace MODEL_ID by the actual model ID. It is the same as model name in Chaturbate and Stripchat. For BongaCams you can find a model ID in the address line of your browser.
Type /referral and get your referral link. You will get two additional subscriptions for every new user registered using this link. Such new user will also get two additional subscriptions. Share it on Twitter, Instagram and other social media.
We do not store any sensitive personal information. We store only your Telegram chat ID that is essential for core functionality of the bot. Telegram chat ID is just a number which we use to send you notifications.


Assembly System Class¶
-
class
dlmfg.core.assembly_system.
AssemblySystem
(assembly_type, assembly_kccs, assembly_kpis)[source]¶ Assembly System Class
-
class
dlmfg.core.assembly_system.
PartType
(assembly_type, assembly_kccs, assembly_kpis, part_name, part_type, voxel_dim, voxel_channels, point_dim)[source]¶ Part System Class, inherits the Assembly System Class, additional parameters for this class include
- Parameters
voxel_dim – Dimension of the voxel
voxel_dim – Dimension of the voxel Channel, single channel output - 1 or multi channel - 2,3 (use 1 for deviations in one direction, 2 or 3 if data for multiple deviation directions are present)
voxel_dim – Dimension of the voxel
The class contains two functions - get_nominal_cop and get_nominal_cop_database
-
get_nominal_cop
(file_name)[source]¶ Import nominal cloud-of-point of the assembly from a text/csv file
- Parameters
file_name (str (required)) – Name of the input file
- Returns
numpy array of nominal COP
- Return type
numpy.array [point_dim,3]
-
class
dlmfg.core.assembly_system.
VRMSimulationModel
(assembly_type, assembly_kccs, assembly_kpis, part_name, part_type, voxel_dim, voxel_channels, point_dim, noise_level, noise_type='uniform', convergency_flag=1)[source]¶ VRM Simulation Model class inherits the part type class, additional parameters of this class include
- Parameters
noise_level (float (required)) – The level of artificial noise to be added to simulated data, typically set to 0.1 mm from the measurement system class depending on the scanner
noise_type (str (optional)) – The type of noise to be added, can be Gaussian or uniform , for Gaussian noise_level is set as standard deviation and mean as zero for uniform the min and max are set -noise_level and +noise_level respectively
convergency_flag (int (optional)) – Flag to denote if the simulation model had converged while simulating, is set to 1 by default
The class contains one function kpi_calculator that needs to be defined by the user depending on the assembly output
-
kpi_calculator
(cop_data, kpi_params=[])[source]¶ User defined function to calculate KPI from Cloud of Point Data [KPI]=f(Cop)
- Parameters
cop_data (np_array [point_dim,3] (required)) – CoP data for a given sample
kpi_params (list (optional)) – Various parameters required to calculate the KPI, can be blank if no parameters are required to calculate KPI from CoP
- Returns
list of multivariate KPIs for the given CoP
- Return type


information:This is a recruitment
coding nut application. Its
back-end part is implemented with Java and provides a simple
RESTFul API for data reading. To see monthly wage for employees
click "Get wage info" button. Employees are printed one at time
to show paging. To see wage details click "See details" link.
Data are available only for March, 2014.
No data yet


The result of parsing an @x:Act <script> is represented by an xdom (@x:Act Document Model) parse tree.
A <script> can be converted to an xdom using the built-in Parse function. An xdom can be converted to a <script> using the library Unparse function. Combining the Parse and Unparse functions yields a pretty printer. The pretty printer preserves code and comments but reformats an @x:Act <script> by changing white space (sequences of space and end-of-line characters). The Unparse function also provides an option to produce a color marked-up XHTML version of the script.
Having a simple xdom representation of all @x:Act <script>s makes it easy to develop @x:Act program generation, analysis, and transformation tools.
To make it simple to process xdom trees, there are only 7 types of tree nodes. The @x:Act syntax however contains lots more than 7 forms. These additional forms are considered to be "syntactic sugar" and are mapped to on of the 7 xdom types. Each xdom node contains a kind field that specifies which alternate syntax form it was parsed from. The Unparse function uses the kind field to restore the original richer syntax forms. In the xdom tree the two major forms of syntax use the same nodes but have different kinds. So conversion between forms involves simply walking the xdom tree and changing kinds.
The 7 types of xdom tree nodes are listed here together with some of the syntax forms that are mapped to these kinds of node.


| I l@ve RuBoard |
13.5 The strop Module(Obsolete) The strop is a low-level module that provides fast C implementations of most functions in the string module. It is automatically included by string, so there's seldom any need to access it directly. However, one reason to use this module is if you need to tweak the path before you start loading Python modules. Example 13-5 demonstrates the module. Example 13-5. Using the strop ModuleFile: strop-example-1.py import strop import sys # assuming we have an executable named ".../executable", add a # directory named ".../executable-extra" to the path if strop.lower(sys.executable)[-4:] == ".exe": extra = sys.executable[:-4] # windows else: extra = sys.executable sys.path.insert(0, extra + "-extra") import mymodule In Python 2.0 and later, you should use string methods instead of strop. In Example 13-5, replace "strop.lower(sys.executable)" with "sys.executable.lower()." |
| I l@ve RuBoard |


The menu "Import picture" imports a bitmap (*.bmp, *.gif,
*.tif, *.jpg, *.wmf, *.emf) from a file
or from the clipboard.
With the menu "Adjust picture" the picture can be rotated in a way
that the inflection points of a folded
layer lie in a horizontal line. In order to do so, the centre of the
rotation may be redefined. Click on the option 'New centre' in the menu
"Adjust picture". Click with the left mouse button on the new centre,
then press the button "New centre". The picture will be shifted. Choose
the option "Median line horizontal".to
rotate the picture. Click with the left mouse button on an inflection point and press the button
"Point
1". Click on another inflection point
of
the same layer and press the button "Point 2".
Press the button "Draw isogons" and
choose the pen width from the list. Colour and line type can be set in
the menu "Lines". Line types other than solid can only have a pen width
of 1.
Double click with the left button on the first layer border, hold
the mouse button down and go to the other border of the layer. With
left mouse button up the isogon will be
drawn. With left mouse button down go to the next border. When all
possible isogons are drawn, press the button "Next dip angle" and
repeat the procedure.
The graphic can be saved or printed at any time.


Funes Mori: Monterrey can beat anyone
by FIFA.com- Funes Mori is Monterrey’s in-form marksman
- Player hoping to meet former club River Plate at Qatar 2019
- "I'm at an important moment," the Argentinian says
As Monterrey continue their preparations for next month’s FIFA Club World Cup Qatar 2019™, a lot of their hopes are riding on the goalscoring prowess of Rogelio Funes Mori.
And for very good reason. Since the Argentinian striker joined Los Rayados in 2015, his ruthless finishing has already brought him close to 100 goals.
However, the stats alone do not tell the whole story. His status as a club idol is also down to his tireless work rate on the pitch and an ability to come through difficult moments, a trait he has shown throughout his career.
A difficult start
Funes Mori began his senior career in 2009 at River Plate, the club closest to his heart. It would be fair to say that it was a tough spell for the front man, with goals hard to come by and demanding fans heaping pressure on him.
"I happened to be at River during a difficult time, when the club wasn't at its best. I considered it part of the learning process, as I knew I’d have worse things than that happen to me. I am who I am today because of River. I learned how to deal with the good and the bad and move on," he said during an exclusive interview with FIFA.com.
After a couple of seasons in Europe (2013-15), he signed for Monterrey, where his full potential as a striker would be unleashed.
"I’m at a very important moment right now. Thanks to this club, the fans and the city, where I’ve been treated so well, I’ve been able to improve and achieve a lot. I want to continue in the same vein – doing things right. There's always something to improve on if you want to keep scoring goals."
Right now, the player’s focus is on Qatar 2019, where he and his side will be hoping to break new ground in the game’s top club competition. "I’m very happy, very excited and ready to have a great World Cup. This will be my first one, and I'm delighted to go there representing a giant of Mexican football. Hopefully, our performances are the best possible and a reflection of the considerable responsibility we are shouldering."
Monterrey at the Club World Cup
- This will be the club’s fourth appearance at the competition, making them the CONCACAF side with the joint-most participations.
- Monterrey sealed their passage to Qatar 2019 by beating Tigres in the final of this year’s CONCACAF Champions League.
- They have finished fifth on two occasions (2011 and 2013), while in 2012 they secured third place.
- Los Rayados kick off their Qatar 2019 campaign on 14 December against the winners of the first-round match between Al-Sadd Sports Club and Hienghene Sport.
Should Monterrey overcome their opener and a looming semi-final with Liverpool, Funes Mori could be gifted a reunion. River Plate will be battling to represent South America at the competition when they go up against Flamengo in the final of this year’s Copa Libertadores on Saturday.
"I'd love to play against River. That River-Flamengo final is going to be really nice. I want River to win, because I'm a fan and also because I'd love to face them at the Club World Cup."
 And while it remains to be seen if they can go all the way to the final, Funes Mori knows very well that this will be another opportunity to demonstrate his talent for overcoming adversity.
"We’re talking about some of the best teams in the world, so you just have to trust in what you have and your own side’s qualities. In football nothing is impossible – we can all beat any team on our day. We're a winning side that always goes on the attack, which is why we’re a big club and so good," he concluded.


Holey Artisan terror attack: Court to announce verdict on Nov 27
by bdnews24.comA Dhaka court will deliver its verdict in a case over the 2016 terror attack on the Holey Artisan cafe in Dhaka’s Gulshan on Nov 27.
Dhaka’s Anti-Terrorism Special Tribunal Judge Mohammad Mojibur Rahman set the date after hearing the arguments of the state and the defence in the case, said Public Prosecutor Golam Sarwar Khan Zakir.
The terrorist attack on July 1, 2016, left 22 people dead.
It came after the eight defendants in the case pleaded not guilty to the charges related to the carnage.
The court finished recording testimonies of 113 witnesses on Oct 27 with Investigation Officer Humayun Kabir, an inspector with the Counter Terrorism and Transnational Crime Unit, being the last one.
In his testimony, investigator Humayun said the militants targeted Holey Artisan bakery to make their presence in Bangladesh known to the world and soil the country’s image in order to establish radical Islamic rule.
Out of the 21 suspects he identified, 13 have been killed in raids at different times and the eight remaining accused are behind bars.

The 13 killed in raids include the five killed in the assault to free hostages from the eatery.
The young militants killed 22 people, including 17 foreigners and two police officers, in the attack on July 1, 2016.
In his statement to the court, Jahangir, hailing from Gaibandha, said he was a member of the Middle East-based radical group Islamic State and was involved in the 2015 murder of Japanese national Kunio Hoshi in Rangpur.
He also said he first joined Jama’atul Mujahideen Bangladesh or JMB in 2002 and then the IS through its leaders Tamim Chowdhury and Sarwar Jahan when “Khilfat was declared in Syria”.
Jahangir, however, claimed he knew Tamim was planning an attack in 2016, but every member of the group other than Tamim himself, Sarwar and Nurul Islam Marzan was unaware of the target.
Tamim, Sarwar and Marzan are among the 13 killed in different anti-terrorism raids.
However, Mizan, the other accused, claimed he was not the militant suspect named in the case, but a fish trader from Bogura.


#include <greference.h>
Public Types | |
| typedef T | Type |
Public Member Functions | |
| GReference (T &data) | |
| GReference (const GReference &other) | |
| GReference (const volatile GReference &other) | |
| GReference & | operator= (const GReference &other) |
| T * | operator& () const |
| operator T & () const |
A wrapper class to be used to pass reference to other functions.
With this wrapper, only the wrapper will be copied by the functions and the data will keep uncopied.
It's useful to wrap non-copyable object to pass to functions that need to copy the parameters.
Usually you don't need to use this class directly.
The global functions makeReference (to make a normal reference) and makeConstReference (to make a constant reference) are the easy way to use the reference wrapper.
This class is the same concept of boost::ref library, though it works slightly different than boost::ref.
| typedef T cpgf::GReference< T >::Type |
The type of the data that the reference holds.
| cpgf::GReference< T >::GReference | ( | T & | data ) | [explicit] |
Construct a wrapper object to reference to data.
| cpgf::GReference< T >::GReference | ( | const GReference< T > & | other ) |
Construct a wrapper object from another wrapper object.
| cpgf::GReference< T >::GReference | ( | const volatile GReference< T > & | other ) |
Construct a wrapper object from another wrapper object.
| GReference& cpgf::GReference< T >::operator= | ( | const GReference< T > & | other ) |
Copy operator. Assign a wrapper object from another wrapper object.
| T* cpgf::GReference< T >::operator& | ( | ) | const |
Get the data address.
This gives a way to access the data directly.
GReference<SomeType> foo(SomeData);
&foo will represent SomeData's address.
And *&foo will represent SomeData's reference.
| cpgf::GReference< T >::operator T & | ( | ) | const |
Convert operator. Convert the wrapper object to T&


{% extends "layout.html" -%} {% set active_page = 'about-data' %} {% block content -%}
This data is from a ICPSR data collection published in 2004 on the ICPSR website. The primary authors of this data were M. Watt Espy and John Ortiz Smykla. The data was collected over the course of 30 years and concerns executions conducted under civil authority in the United States or the area that would become the United States from 1608 to 2002. The ICPSR collected numerous facts about each execution, not all of which appear in the final data set. The data was collected from state Department of Corrections records, newspapers, county histories, proceedings of state and local courts, holdings of historical societies, and other listings of executions.
Most crucially, the names of the people executed have been removed to preserve privacy for the families of individuals and/or others related to the case. This data set is meant for research purposes only, not to track down any specific individuals. Additionally, the data ultimately belongs to the ICPSR, so any use must comply with their use, citation, and privacy guidelines.
Espy, M. Watt, and John Ortiz Smykla. EXECUTIONS IN THE UNITED STATES, 1608-2002: THE ESPY FILE [Computer file]. 4th ICPSR ed. Compiled by M. Watt Espy and John Ortiz Smykla, University of Alabama. Ann Arbor, MI: Inter-university Consortium for Political and Social Research [producer and distributor], 2004.
{%- endblock content %}


| make.db.names {DBI} | R Documentation |
These methods are DEPRECATED. Please use dbQuoteIdentifier()
(or possibly dbQuoteString()
) instead.
make.db.names( dbObj, snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE, ... ) make.db.names.default( snames, keywords = .SQL92Keywords, unique = TRUE, allow.keywords = TRUE ) isSQLKeyword( dbObj, name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3], ... ) isSQLKeyword.default( name, keywords = .SQL92Keywords, case = c("lower", "upper", "any")[3] )
dbObj |
any DBI object (e.g., |
snames |
a character vector of R identifiers (symbols) from which we need to make SQL identifiers. |
keywords |
a character vector with SQL keywords, by default it's
|
unique |
logical describing whether the resulting set of SQL names
should be unique. Its default is |
allow.keywords |
logical describing whether SQL keywords should be
allowed in the resulting set of SQL names. Its default is |
... |
any other argument are passed to the driver implementation. |
name |
a character vector with database identifier candidates we need to determine whether they are legal SQL identifiers or not. |
case |
a character string specifying whether to make the comparison as
lower case, upper case, or any of the two. it defaults to |
The algorithm in make.db.names
first invokes make.names
and
then replaces each occurrence of a dot .
by an underscore _
. If
allow.keywords
is FALSE
and identifiers collide with SQL
keywords, a small integer is appended to the identifier in the form of
"_n"
.
The set of SQL keywords is stored in the character vector
.SQL92Keywords
and reflects the SQL ANSI/ISO standard as documented
in "X/Open SQL and RDA", 1994, ISBN 1-872630-68-8. Users can easily
override or update this vector.
make.db.names
returns a character vector of legal SQL
identifiers corresponding to its snames
argument.
SQLKeywords
returns a character vector of all known keywords for the
database-engine associated with dbObj
.
isSQLKeyword
returns a logical vector parallel to name
.
The current mapping is not guaranteed to be fully reversible: some SQL
identifiers that get mapped into R identifiers with make.names
and
then back to SQL with make.db.names()
will not be equal to the
original SQL identifiers (e.g., compound SQL identifiers of the form
username.tablename
will loose the dot “.”).
The set of SQL keywords is stored in the character vector
.SQL92Keywords
and reflects the SQL ANSI/ISO standard as documented
in "X/Open SQL and RDA", 1994, ISBN 1-872630-68-8. Users can easily
override or update this vector.


Movies
{{items.original_title}}
{{selectedMovie.original_title}}
Who made it?
Director:
{{directorName}}
Writers:
{{writers}}
Stars:
{{cast}}
What's it about?
{{movieDescription}}
Movie Credits
{{cast.name}}
{{cast.character}}


There are relatively few restrictions on the co-occurrence of vowels with other segments, but there are some which must be mentioned.
Word-initially, /a/ and /a:/ are permitted in underlying and surface forms. Underlying /u/ and /i/ also occur, but a homorganic semivowel is normally inserted before them in this position by Initial Semivowel-Insertion P-5, so //u// → /wu/ and //i// → /yi/. For exx. of this see the discussion of P-5, next chapter. Exx. of /a/ and /a:/ are ANA noun-class prefixes /ana-/ and /a-/, the latter with variant /a:-/ before one demonstrative root (see P-35) and before one noun (see P-43, next chapter); /agalgi/ 'yesterday', /aban/ 'ground, earth', and /?=a:ru-ny/ 'it(ANA/MANA) abandoned it(ANA/MANA)'. Initial /a/, /a:/, /i/, and /u/ occur in underlying or intermediate forms in root-initial position, especially verbs, but are most often subject to VV-Contraction P-49.
All vowels occur word-finally. Some suffixes which are normally word-final are Dual /-w2a.:/, Ablative /-w1ala/, Similative /-yi:/, and Evitative /-magi/. Some stems which can occur word-finally are /ngurudhu/ 'bird, game animal', /adaba/ 'now', and /w1ujbi/ 'female'. Final long /u:/ is less common but does occur in Nonpast3 verb forms of roots ending in /u/, as in /=a:ru:-'/ 'will not abandon' (base form of suffix disputable, but most likely //-u//, hence //=a:ru-u// with VV-Contraction P-49); long /u:/ also occurs on the surface in demonstrative forms with Concrete suffix //-u//, as in //da-ni-u// → /da-nu:-'/ '(it is) that(ANA)' (7.6).
While all vowels, including long ones, can occur word-finally, seems true that long vowels do not occur as final segments in noun or verb roots (except for monosyllabic noun roots and verbal root-plus-suffix sequences of some types, see P-44), and long vowels are also very rare as underlying final segments of prefixes (an exception is /yi: -/, the punctual prefix for NA and NgARA noun class; for surface long vowels in prefixes due to various rules see P-35, -36, -43).
Vowel clusters do not normally occur within a word in surface forms. The exception is that some cases of bisyllabic /aa/ have been observed, generally due to deletion of a previously intervening underlying /w1/ or etymological *w (see P-9): /bagaraag/ 'cycad nut', /=lhaayi-/ 'to lie stretched out in line', etc. Usually such /aa/ clusters are unstable, and a contracted variant /a:/ is also attested, except that contraction (by P-49) is not reliable over a boundary when synchronic underlying //w1// has been deleted. Other underlying vowel clusters like //a-i// and //u-a// are common at morpheme boundaries, especially between a prefix and following verb root, but these clusters are not retained on the surface: usually VV-Contraction P-49 combines the two into a single long surface vowel, and if not an epenthetic semivowel is inserted by P-7 or -10 (cf. also P-6).
There are no major restrictions on the combinability of vowels with preceding or following consonants. There are some cases of a back vowel shifting to /i/ before a "palatal-type" consonant /j nyy/, but this is sporadic and limited to a few tight-knit combinations (see P-50). Both short and long vowels can occur before consonant clusters: exx of long vowels are /ba:lmi/ 'pelican' and //nga:mba=anma-ng// → /nga:mba:='nma-ng/ 'we(InPl) will look for them(WARA)'. Aside from forms involving monosyllabic noun or verb roots, word-final /...V:C/ with long vowel followed by consonant seems impossible.


Python is simple to use, but it is a real programming language, offering much more structure and support for large programs than shell scripts or batch files can offer. On the other hand, Python also offers much more error checking than C, and, being a very-high-level language, it has high-level data types built in, such as flexible arrays and dictionaries. Because of its more general data types Python is applicable to a much larger problem domain than Awk or even Perl, yet many things are at least as easy in Python as in those languages.
-
Python enables programs to be written compactly and readably. Programs written in Python are typically much shorter than equivalent C, C++, or Java programs, for several reasons:
- The high-level data types allow you to express complex operations in a single statement
- Statement grouping is done by indentation instead of beginning and ending brackets
- No variable or argument declarations are necessary.
Expression syntax is straightforward: the operators +, -, * and / work just like in most other languages (for example, Pascal or C); parentheses (()) can be used for grouping.
>>> 2 + 2
4
>>> 50 - 5*6
20
>>> (50 - 5*6) / 4
5.0
>>> 8 / 5 # division always returns a floating point number
1.6
Division (/) always returns a float. To do floor division and get an integer result (discarding any fractional result) you can use the // operator; to calculate the remainder you can use %:
>>> 17 / 3 # classic division returns a float
5.666666666666667
>>>
>>> 17 // 3 # floor division discards the fractional part
5
>>> 17 % 3 # the % operator returns the remainder of the division
2
>>> 5 * 3 + 2 # result * divisor + remainder
17
It is also possible to use the ** operator to calculate powers:
>>> 5 ** 2 # 5 squared
25
>>> 2 ** 7 # 2 to the power of 7
128
A variable holds a value. You can change the value of a variable at any point.
>>>message = "Hello Python world!"
>>>print(message)
>>>message = "Python is my favorite language!"
>>>print(message)
- Spaces are not allowed in variable names, so we use underscores instead of spaces. For example, use student_name instead of "student name".
- Variables can only contain letters, numbers, and underscores. Variable names can start with a letter or an underscore, but can not start with a number.
- Variable names should be descriptive, without being too long. For example mc_wheels is better than just "wheels", and number_of_wheels_on_a_motorycle.
Naming Rules:
A string is a sequence of one or more characters (letters, numbers, symbols) that can be either a constant or a variable. Made up of Unicode, strings are immutable sequences, meaning they are unchanging. Because text is such a common form of data that we use in everyday life, the string data type is a very important building block of programming.
Creating strings
Strings exist within either single quotes ' or double quotes " in Python, so to create a string, enclose a sequence of characters in one or the other.You can choose to use either single quotes or double quotes, but whichever you decide on you should be consistent within a program.
String Concatenation
Concatenation means joining strings together end-to-end to create a new string. To concatenate strings, we use the + operator. Keep in mind that when we work with numbers, + will be an operator for addition, but when used with strings it is a joining operator. Let’s combine the strings "Sammy" and "Shark" together with concatenation through a print() statement:
>>>print("Sammy" + "Shark")
>>>#Output
>>>SammyShark
String Replication
There may be times when you need to use Python to automate tasks, and one way you may do this is through repeating a string several times. You can do so with the * operator. Like the + operator, the * operator has a different use when used with numbers, where it is the operator for multiplication. When used with one string and one integer, * is the string replication operator, repeating a single string however many times you would like through the integer you provide.
Information is derived from the following sources:


|
RBE 2000 level template code
|
#include "Arduino.h"
#include "ESP32Servo.h"
#include "analogWrite.h"
#include <soc/sens_reg.h>
#include <soc/sens_struct.h>
#include <driver/adc.h>
#include <esp_adc_cal.h>
#include <stdint.h>
#include "esp_types.h"
#include "esp_err.h"
#include "assert.h"
Go to the source code of this file.
Macros | |
| #define | V_REF 1100 |
Functions | |
| void | studentCode () |
| int IRAM_ATTR | local_adc1_read (int channel) |
| void | complexHandler (void *param) |
| void IRAM_ATTR | onTimer () |
| void | setup () |
| void | loop () |
Variables | |
| hw_timer_t * | timer = NULL |
| portMUX_TYPE DRAM_ATTR | timerMux = portMUX_INITIALIZER_UNLOCKED |
| TaskHandle_t | complexHandlerTask |
| uint32_t | samplingFreq = 1000 |
| #define V_REF 1100 |
Referenced by setup().
| void complexHandler | ( | void * | param | ) |
Definition at line 61 of file LabOneCode_2002_Team_09.ino.
References studentCode().
Referenced by setup().
| int IRAM_ATTR local_adc1_read | ( | int | channel | ) |
Definition at line 48 of file LabOneCode_2002_Team_09.ino.
Referenced by studentCode().
| void loop | ( | ) |
Definition at line 121 of file LabOneCode_2002_Team_09.ino.
| void IRAM_ATTR onTimer | ( | ) |
Definition at line 69 of file LabOneCode_2002_Team_09.ino.
References complexHandlerTask, and timerMux.
Referenced by setup().
| void setup | ( | ) |
Definition at line 84 of file LabOneCode_2002_Team_09.ino.
References complexHandler(), complexHandlerTask, onTimer(), samplingFreq, timer, and V_REF.
| void studentCode | ( | ) |
Definition at line 34 of file LabOneCode_2002_Team_09.ino.
References local_adc1_read().
Referenced by complexHandler().
| TaskHandle_t complexHandlerTask |
Definition at line 24 of file LabOneCode_2002_Team_09.ino.
| uint32_t samplingFreq = 1000 |
Definition at line 29 of file LabOneCode_2002_Team_09.ino.
Referenced by setup().
| hw_timer_t* timer = NULL |
Definition at line 22 of file LabOneCode_2002_Team_09.ino.
Referenced by setup().
| portMUX_TYPE DRAM_ATTR timerMux = portMUX_INITIALIZER_UNLOCKED |
Definition at line 23 of file LabOneCode_2002_Team_09.ino.
Referenced by onTimer().


|
Pallas Solver
0.1
C++ Global Optimization Algorithms
|
#include <cfloat>
#include "pallas/history_concept.h"
#include "pallas/types.h"
#include "pallas/internal/crossover_strategy.h"
#include "pallas/internal/mutation_strategy.h"
#include "pallas/internal/shuffler.h"
#include "pallas/internal/state.h"
Go to the source code of this file.
Classes | |
| class | pallas::DifferentialEvolution |
| Minimizes an objective function by continuously evolving a population of candidate solutions. More... | |
| struct | pallas::DifferentialEvolution::Options |
| struct | pallas::DifferentialEvolution::Summary |
| Contains a summary of the optimization. More... | |
| struct | pallas::DifferentialEvolution::HistoryOutput |
| Stores information about the state of the system for at a given iteration number. More... | |
Functions | |
| void | pallas::Solve (const DifferentialEvolution::Options &options, const GradientProblem &problem, double *parameters, DifferentialEvolution::Summary *summary) |
| Helper function which avoids going through the interface of the pallas::DifferentialEvolution class. More... | |
| void | pallas::dump (const DifferentialEvolution::HistoryOutput &h, HistoryWriter &writer) |
| Dumps the system state contained in the history output into the stream contained by the writer. More... | |
This file contains a C++ implementation of the differential algorithm due to Storn and Price: Differential Evolution - a Simple and Efficient Heuristic for Global Optimization over Continuous Spaces.
This code is based on the SciPy implementation of differential evolution found in scipy.optimize and relies on the local optimization algorithms in the Google Ceres project.
| void pallas::dump | ( | const DifferentialEvolution::HistoryOutput & | h, |
| HistoryWriter & | writer | ||
| ) |
Dumps the system state contained in the history output into the stream contained by the writer.
| h | DifferentialEvolution::HistoryOutput. State of the system for a specific iteration. |
| writer | HistoryWriter. Object responsible for writing the history output to a stream. |
| void pallas::Solve | ( | const DifferentialEvolution::Options & | options, |
| const GradientProblem & | problem, | ||
| double * | parameters, | ||
| DifferentialEvolution::Summary * | summary | ||
| ) |
Helper function which avoids going through the interface of the pallas::DifferentialEvolution class.
The specified options are used to setup a differential evolution instance which is then used to minimize the GradientProblem. The optimal solution is stored in parameters
and a summary of the global optimization can be found in summary
.
| options | pallas::DifferentialEvolution::Options. Options used to configure the optimization. |
| problem | pallas::GradientProblem. The problem to optimize. |
| parameters | double*. The starting point for further optimization. |
| summary | DifferentialEvolution::Summary*. Summary instance to store the optimization details. |


Intelligent Information Retrieval
CW01
Click a button to make an RESTful API request
Users
Posts
Comments
Find User By Username
Find
Fill in the form to enter data into the database
First Name
Last Name
Email
Username
Password
Submit


Quality control analysis¶
Before using the methods in the Wave, River, and Tidal modules, the input data provided by the user should undergo proper quality control analysis to ensure that the data is of high quality and fit for the intended purpose. Quality control analysis often includes steps to ensure that data is not missing, corrupt, or outside of the expected range. Additional analysis can include checking for stagnant readings, unusual abrupt changes, or outliers. If data does not meet specified requirements, the data points that did not pass inspection should be removed or replaced by various means (interpolation, data from a duplicate sensor, values from a model) before using the data in analysis.
The qc
module contains a set of functions to for basic quality control analysis.
These functions are imported from Pecos, an open source Python package
designed for quality control analysis of timeseries data. Pecos was originally developed to monitor solar photovoltaic systems, but is designed to be used for a wide range of applications.
Note, that the quality control functions require that the data has a datatime index.
Other functionality in MHKiT-Matlab can use data that has datatime or numeric indexes.
MHKiT-Matlab includes a utility function in the utils
module that converts numeric indexes into datetime indexes.
|
The following quality control functions are available in MHKiT-Python. Additional functionality, including graphics and reports, can be included in quality control analysis by using Pecos directly. More information on the quality control functions be found at https://pecos.readthedocs.io.
Each function returns the following information:
Cleaned data (data that failed a test is replaced by NaN)
Boolean mask (indicates if data failed a test)
Summary of the quality control test results
The clean data can be used directly in MHKiT-Python analysis, or the missing values can be replaced using various methods. Data replacement strategies are generally defined on a case by case basis. If large sections of the data failed quality control tests, the data might not be suitable for use. Replacement strategies can be applied to the entire data set, or vary by data column or by time. Possible strategies include:
Replacing missing data using linear interpolation or other polynomial approximations
Replacing missing data using a rolling mean of the data
Replacing missing data with a data from a previous period (previous day, hour, etc.)
Replacing missing data with data from a redundant sensor
Replacing missing data with values from a model
These strategies can be accomplished using the Pandas methods interpolate
, replace
, and fillna
.
See Pandas documentation for more details.
The quality control analysis example illustrates quality control analysis using MHK data.


#include <WinCAPICryptoKeyDSA.hpp>
Inheritance diagram for WinCAPICryptoKeyDSA:
The library uses classes derived from this to process DSA keys.
Public Member Functions | |
Constructors and Destructors | |
| WinCAPICryptoKeyDSA (HCRYPTPROV prov) | |
| Ctor for DSA keys. | |
| virtual | ~WinCAPICryptoKeyDSA () |
| WinCAPICryptoKeyDSA (HCRYPTPROV prov, HCRYPTKEY k) | |
| WinCAPI Specific constructor for public keys. | |
| WinCAPICryptoKeyDSA (HCRYPTPROV prov, DWORD keySpec, bool isPrivate) | |
| WinCAPI Specific constructor for private keys. | |
Required Key Interface methods | |
| virtual XSECCryptoKey::KeyType | getKeyType () |
| Return the type of this key. | |
| virtual const XMLCh * | getProviderName () |
| Return the WiNCAPI string identifier. | |
| virtual XSECCryptoKey * | clone () |
| Replicate key. | |
Required DSA methods | |
| virtual unsigned int | signBase64Signature (unsigned char *hashBuf, unsigned int hashLen, char *base64SignatureBuf, unsigned int base64SignatureBufLen) |
| Create a signature. | |
| virtual bool | verifyBase64Signature (unsigned char *hashBuf, unsigned int hashLen, char *base64Signature, unsigned int sigLen) |
| Verify a signature. | |
Optional Interface methods | |
Have been fully implemented in the WinCAPI interface to allow interop testing to occur. | |
| virtual void | loadPBase64BigNums (const char *b64, unsigned int len) |
| Load P. | |
| virtual void | loadQBase64BigNums (const char *b64, unsigned int len) |
| Load Q. | |
| virtual void | loadGBase64BigNums (const char *b64, unsigned int len) |
| Load G. | |
| virtual void | loadYBase64BigNums (const char *b64, unsigned int len) |
| Load Y. | |
| virtual void | loadJBase64BigNums (const char *b64, unsigned int len) |
| Load J. | |
WinCAPI Specific functions | |
| unsigned int | getPBase64BigNums (char *b64, unsigned int len) |
| Retrieve P. | |
| unsigned int | getQBase64BigNums (char *b64, unsigned int len) |
| Retrieve Q. | |
| unsigned int | getGBase64BigNums (char *b64, unsigned int len) |
| Retrieve G. | |
| unsigned int | getYBase64BigNums (char *b64, unsigned int len) |
| Retrieve Y. |
|
|
Ctor for DSA keys. This constructor should be used for public keys that are going to be loaded later via P, Q etc.
|
|
|
|
|
|
WinCAPI Specific constructor for public keys. Create a DSA key for use in XSEC from an existing public HCRYPTKEY
|
|
|
WinCAPI Specific constructor for private keys. Create a DSA key for use in XSEC from a passed in handle to a provider and associated key store
|
|
|
Replicate key.
Implements XSECCryptoKeyDSA. |
|
|
Retrieve G.
|
|
|
Return the type of this key. Allows the caller (and library) to determine whether this is a public key, private key or a key pair Reimplemented from XSECCryptoKeyDSA. |
|
|
Retrieve P.
|
|
|
Return the WiNCAPI string identifier.
 Sign the buffer using the internal private key. Will throw a DSAError if the key is not set, or is not a private key.
Implements XSECCryptoKeyDSA. |
|
|
Verify a signature. The library will call this function to validate a signature
Implements XSECCryptoKeyDSA. |


|
|
Face Class ReferenceInheritance diagram for Face:
List of all members.
Constructor & Destructor Documentation
Member Function Documentation
| void Face::computeArea |
( |
|
) |
[private] |
|
| void Face::computeQuadric |
( |
|
) |
|
|
| float Face::getArea |
( |
|
) |
[inline] |
|
| void Face::planeEquation |
( |
float & |
rA, |
|
|
float & |
rB, |
|
|
float & |
rC, |
|
|
float & |
rD |
|
) |
[inline] |
|
| void Face::ReplacePair |
( |
Pair * |
oldPair, |
|
|
Pair * |
newPair |
|
) |
[inline] |
|
| void Face::setArea |
( |
float |
a |
) |
[inline] |
|
Member Data Documentation
© 1999 - 2006 Intel Corporation. All rights reserved.
* Other names and brands may be claimed as the property of others.
|
|


These are the earliest possible release dates for Boy A and Boy B
by By Digital Desk staffThe Central Criminal Court has heard the earliest possible release date for Boy A and Boy B following the Ana Kriegel murder trial.
On Tuesday, Boy A received a life sentence for murdering the 14-year-old schoolgirl, while Boy B was sentenced to 15 years detention.
The earliest possible release date for Boy A is June 18, 2031, while for Boy B it is June 18, 2027.
The Judge has today ordered that a series of progress reports on both boys be carried out every two years during their periods of detention.
He said that the court needs to be fully informed of efforts made by the boys towards rehabilitation when their respective review dates arrive.
The reports will include updates on their educational, psychological, and psychiatric progress.
Mr Justice Paul McDermott said the furnishing of reports is not for micromanaging the boys' sentences, but for courts to have a clear view of what happens during the course of their detention.
Both boys will be transferred to adult prisons when they turn 18 in 2022.
READ MORE
'You will have the opportunity to return to your families': Ana Kriegel trial judge sentences boys


Preparation time
less than 30 mins
Cooking time
1 to 2 hours
Serves
Serves 4
Dietary
Preheat the oven to 180C/350F/Gas4.
Place a 10cm/4in wide flan ring upside down on a baking sheet. Lightly grease the outside of the flan ring.
Brush five sheets of pastry with sunflower oil and place over the flan ring in layers at different angles, resulting in a star shape. Place in the oven for about 10 minutes or until golden brown. Leave to cool for 5 minutes, then carefully lift the nests off the rings and place upturned on a dinner plate. This needs to be done three more times, until you have four baskets. At this stage, raise the temperature of the oven to 200C/400F/Gas6.
Wash the rice thoroughly. Add to a large pan of water with the bouquet garni and bring to the boil. Simmer on a low heat for 40 to 45 minutes, until the grains have split and are tender.
Meanwhile, place all the vegetables in a large bowl and mix. Blend together the balsamic vinegar, olive oil, seasoning and one sprig of rosemary. Pour over the vegetables and set aside for 30 minutes for the vegetables to marinate.
Grease a large roasting tray and spread the vegetables evenly over the tray. Cover with foil and place in the oven for 15 minutes. Remove the foil and roast for a further 15 minutes.
To serve, fill each filo nest with the roasted vegetables and marinating juices. Add the wild rice around the edge of the basket and garnish with the parsley and rosemary.


Let us first make a PCA object. For this, we will use the VST
data, because it makes sense to use the normalized data for building the PCA. To run PCA, we use the R function prcomp()
. It takes in a matrix where samples are rows and variables are columns. Therefore, we transpose our count matrix using the function t()
. If we do not transpose, then PCA is run on the genes rather than the samples.
After you computer the PCA, if you type the object vst_pca$
and press TAB
, you will notice that this R object has multiple vecors and data.frames within it. Some of the important ones are
sdev:
the standard deviations of the principal componentsx:
the coordinates of the samples (observations) on the principal components.rotation:
the matrix of variable loadings (columns are eigenvectors). Note There are quite a few functions in R from different packages that can run PCA. So, one should look into the structure of the PCA object and import it into ggplot
accordingly!
First, let us look into plotting the variance explained by the top PCs.
frac_var <- function(x) x^2/sum(x^2)
library(scales)
vst_pca$sdev %>%
as_tibble() %>%
frac_var() %>%
mutate(Comp = colnames(vst_pca$x)) %>%
slice(1:9) %>%
ggplot(aes(x=Comp, y = value)) +
geom_bar(stat = "identity", fill = "#4DC5F9") +
geom_hline(yintercept = 0.03, linetype=2) +
xlab("Principal Components") +
scale_y_continuous(name = "Variance Explained", breaks = seq(0,0.8,0.1), labels = percent_format(accuracy = 5L)) +
theme_classic(base_size = 14)
plot
So, looks like the first two components explain almost 85% of the data. Now, let us look into building a plot out of these components. From the above object, to get the scatter plot for the samples, we need to look into vst_pca$x
. Then, we combine this data (as shown below) with the metadata to use different aesthetics and colors on the plot.
output
## PC1 PC2 PC3 PC4 PC5 PC6
## Sample_1 -34.641623 -13.435531 6.486032 -0.2742477 -6.406502 5.6703279
## Sample_2 -35.431333 -13.277983 5.171377 -0.3540945 -3.953216 6.9974341
## Sample_3 -35.938795 -14.544994 2.885351 -11.3414829 5.950082 -10.8497916
## Sample_4 -20.672358 3.962013 -1.414301 10.4819194 -0.195882 -2.8003847
## Sample_5 -21.155503 1.390981 -6.644132 7.4002617 6.505502 0.9771040
## Sample_6 -22.662075 1.115504 -9.801356 6.3107519 7.431833 0.6592987
## Sample_7 1.862762 24.449057 12.865650 -4.4029501 5.822040 4.1873901
## Sample_8 -5.909698 13.992629 -14.775686 -10.9789567 -8.967097 2.2612207
## Sample_9 -3.233544 17.321871 5.196746 2.5142966 -6.983077 -7.2580550
## Sample_10 60.630406 -5.930071 6.993097 5.7393184 -4.254238 -2.6905179
## Sample_11 56.669696 -10.638879 -5.860598 0.4646609 -5.216763 -1.3748865
## Sample_12 60.482067 -4.404596 -1.102179 -5.5594769 10.267317 4.2208603
## PC7 PC8 PC9 PC10 PC11 PC12
## Sample_1 -7.6896364 7.5508580 -1.1936551 -0.2382806 -0.7901002 6.374529e-14
## Sample_2 5.8962070 -9.0662471 -1.0449651 0.2284545 1.3982703 4.489535e-14
## Sample_3 1.4353811 0.7461021 1.4769949 0.2114041 -0.5247079 6.296152e-14
## Sample_4 1.2992058 2.3863551 6.1089574 -0.1510797 9.1851796 6.559618e-14
## Sample_5 -2.7487548 -2.7353990 4.5686381 -6.6024251 -6.9911571 2.914207e-14
## Sample_6 2.1391551 2.3567136 -7.7925047 6.9400619 -1.3499685 5.051235e-14
## Sample_7 5.2166866 4.0805978 0.2292610 -1.4574679 -1.2200771 3.675884e-14
## Sample_8 -0.1684735 -0.1448735 3.9822133 2.5610601 -0.5182664 3.653141e-14
## Sample_9 -5.4663572 -5.2056738 -6.4295279 -1.6062665 0.5133496 7.142697e-14
## Sample_10 0.8277618 -0.5767198 4.9156730 6.8596253 -4.8748004 5.502887e-14
## Sample_11 5.8886122 3.9566331 -4.4374522 -6.9835771 0.4457707 2.885463e-14
## Sample_12 -6.6297877 -3.3483466 -0.3836326 0.2384911 4.7265074 -3.373501e-14
And, if you check the class()
of this object, you will realize that this is a matrix
. To be able to comfortably use tidyverse
on this object, we must first convert this to a data.frame
.
vst_pca_all <- vst_pca$x %>%
as.data.frame() %>%
rownames_to_column(var = "Sample_ID") %>%
full_join(md, by = "Sample_ID")
# Just to keep the order the right way.
vst_pca_all$Sample_Name <- factor(vst_pca_all$Sample_Name, levels = c("t0_A","t0_B","t0_C","t2_A","t2_B","t2_C","t6_A","t6_B","t6_C","t24_A","t24_B","t24_C"))
vst_pca_all$Time <- factor(vst_pca_all$Time, levels = c("t0","t2","t6","t24"))
vst_pca_all$Replicate <- factor(vst_pca_all$Replicate, levels = c("A","B","C"))
ggplot(vst_pca_all, aes(x=PC1, y=PC2, color = Time)) +
geom_point(size = 3, aes(shape = Replicate)) +
geom_vline(xintercept = 0, linetype=2) +
geom_hline(yintercept = 0, linetype=2) +
theme_bw() +
theme(panel.grid.major = element_blank(),
panel.grid.minor = element_blank())
plot
Now, let us say you want to plot the four genes that contribute the most to the four directions in the PCA plot. We could obtain them by looking at the vst_pca$rotation
matrix. We could get those genes and their respective coordinates as follows.
genes.selected=vst_pca$rotation[c(which.max(vst_pca$rotation[,"PC1"]), which.min(vst_pca$rotation[,"PC1"]), which.max(vst_pca$rotation[,"PC2"]), which.min(vst_pca$rotation[,"PC2"])),c("PC1","PC2")]
genes.selected <- genes.selected %>%
as.data.frame() %>%
rownames_to_column(var = "Gene_ID")
genes.selected
output
## Gene_ID PC1 PC2
## 1 ENSG00000204941 0.05737805 -0.02981714
## 2 ENSG00000175592 -0.04640560 -0.03986039
## 3 ENSG00000156804 0.01143268 0.03864008
## 4 ENSG00000120738 0.01010573 -0.05681563
A loading plot shows how strongly each variable (gene) influences a principal component. As an example, we could plot the four genes we selected.
By merging the PCA plot with the loadings plot one can create a so-called PCA bi-plot.
scale=500
ggplot(data=vst_pca_all, mapping=aes(x=PC1, y=PC2)) +
geom_point(size = 3, aes(shape = Replicate, color = Time)) +
geom_vline(xintercept = 0, linetype=2) +
geom_hline(yintercept = 0, linetype=2) +
geom_segment(data=genes.selected, mapping=aes(xend=scale*PC1,yend=scale*PC2), x=0, y=0, arrow=arrow(), color="grey") +
geom_label(data=genes.selected, mapping=aes(x=scale*PC1,y=scale*PC2, label=Gene_ID), size=2, hjust="outward", vjust="outward") +
theme_bw() +
theme(panel.grid.major = element_blank(), panel.grid.minor = element_blank())
plot
Note Similarly, let us say, you have environmental variables (continous variables like pH and so on) from the same samples and you would like to see how they would fit this bi-plot. One can use envfit()
function from the vegan
package, this function would return both the p-value
and the coordinates
of each of the variables in your environmental matrix. Then you could subset the significant variables and plot them in the same way as above.
For heatmap, let us look into pheatmap
library which is not part of ggplot
, but it is a well known package for building heatmaps. It contains a lot of internal aesthetics that you can add that are very informative and intuitive. Let us first start with making a correlation matrix and plot it.
vst_cor <- as.matrix(cor(gc_vst, method="spearman"))
library(pheatmap)
pheatmap(vst_cor,border_color=NA,annotation_col=md[,"Time",drop=F],
annotation_row=md[,"Time",drop=F],annotation_legend=T)
plot
Note If you get a gpar()
error, this is due to the reason that the metadata table you provide here does not have the sample ids as rownames
. pheatmap
maps the meta-data to the count data using rownames
Now, this is based on a correlation matrix where you have a very simple square matrix with samples and their correlations to each to each other. Now let us look into how we can make a heatmap from an expression dataset.
For this we will use the dataset: Time_t2_vs_t0.txt
here that basically has the list of genes that are differentially expressed in t2
vs t0
and we would like to visualize this in an heatmap. To be more precise, these are the top and bottom 200 (2 X 100) genes with adjusted p-value < 0.01
. We use just these 200, for the sake of visualization. Let us take the t24 vs t0
here as these are most different based on our PCA.
Note The genes are already sorted in the file. First 100 genes with negative log2FoldChange
and the next 100 with positive log2FoldChange
diff_t2_vs_t0 <- read.table("data/Time_t24_vs_t0.txt", sep = "\t", header = TRUE, row.names = 1)
hmap_t2_t0 <- subset(gc_vst, rownames(gc_vst) %in% diff_t2_vs_t0$gene)
pheatmap(hmap_t2_t0, border_color=NA, annotation_col=md[,"Time",drop=F], annotation_row=NULL, annotation_legend=T)
plot
Further, we can also customize using the pheatmap
and also use the continous color options we talked about in the earlier sections.
library(wesanderson)
md$Time <- factor(md$Time, levels = c("t0","t2","t6","t24"))
pheatmap(hmap_t2_t0, color = wes_palette("Moonrise3", 100, type = "continuous"), border_color=NA, annotation_col=md[,"Time",drop=F], annotation_row=NULL, annotation_legend=T, show_rownames = FALSE, fontsize = 14)
plot
We can use geom_tile()
from ggplot
to make heatmaps. The ggplot
based heatmaps are, as we have seen for other cases, much more easier to customize.
hmap_t2_t0_long <- hmap_t2_t0 %>%
rownames_to_column(var = "Gene") %>%
gather(Sample_ID, VST, -Gene) %>%
full_join(md, by = "Sample_ID")
hmap_t2_t0_long$Sample_Name <- factor(hmap_t2_t0_long$Sample_Name, levels =
c("t0_A","t0_B","t0_C","t2_A","t2_B","t2_C","t6_A","t6_B","t6_C","t24_A","t24_B","t24_C"))
hmap_t2_t0_long$Time <- factor(hmap_t2_t0_long$Time, levels = c("t0","t2","t6","t24"))
hmap_t2_t0_long$Replicate <- factor(hmap_t2_t0_long$Replicate, levels = c("A","B","C"))
hmap_t2_t0_long$Gene <- factor(hmap_t2_t0_long$Gene, levels = row.names(hmap_t2_t0))
ggplot(hmap_t2_t0_long) +
geom_tile(aes(x = Sample_Name, y = Gene, fill = VST)) +
scale_fill_gradientn(colours = rainbow(5)) +
scale_x_discrete(limits = c("t0_A","t0_B","t0_C","t24_A","t24_B","t24_C")) +
theme(axis.text.y = element_blank(), axis.ticks = element_blank())
plot
Now, as I have mentioned earlier, building a plot similar to PCA really depends on how the object looks like. Now, let us try to make a MDS
or PCoA
plot from the same data as we have used. Here is how you get the MDS object in R.
Task Now, try to replicate the example MDS
plot below if you have enough time.
plot
Hint The mds object gc_mds
has “eigenvalues”. You can calculate the variance by Variance <- Eigenvalues / sum(Eigenvalues)
## R version 3.6.3 (2020-02-29)
## Platform: x86_64-pc-linux-gnu (64-bit)
## Running under: Ubuntu 20.04.1 LTS
##
## Matrix products: default
## BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
## LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
##
## locale:
## [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
## [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
## [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
## [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
## [9] LC_ADDRESS=C LC_TELEPHONE=C
## [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
##
## attached base packages:
## [1] stats graphics grDevices utils datasets methods base
##
## other attached packages:
## [1] wesanderson_0.3.6 pheatmap_1.0.12 scales_1.1.1 forcats_0.5.0
## [5] stringr_1.4.0 purrr_0.3.4 readr_1.3.1 tidyr_1.1.2
## [9] tibble_3.0.4 tidyverse_1.3.0 reshape2_1.4.4 ggplot2_3.3.2
## [13] dplyr_1.0.2 captioner_2.2.3 bookdown_0.20 knitr_1.29
##
## loaded via a namespace (and not attached):
## [1] tidyselect_1.1.0 xfun_0.18 haven_2.3.1 colorspace_1.4-1
## [5] vctrs_0.3.4 generics_0.0.2 htmltools_0.5.0 yaml_2.2.1
## [9] blob_1.2.1 rlang_0.4.8 pillar_1.4.6 glue_1.4.2
## [13] withr_2.3.0 DBI_1.1.0 RColorBrewer_1.1-2 dbplyr_1.4.4
## [17] modelr_0.1.8 readxl_1.3.1 lifecycle_0.2.0 plyr_1.8.6
## [21] munsell_0.5.0 gtable_0.3.0 cellranger_1.1.0 rvest_0.3.6
## [25] evaluate_0.14 labeling_0.4.2 fansi_0.4.1 broom_0.7.0
## [29] Rcpp_1.0.5 backports_1.1.10 jsonlite_1.7.1 farver_2.0.3
## [33] fs_1.5.0 hms_0.5.3 digest_0.6.27 stringi_1.5.3
## [37] grid_3.6.3 cli_2.1.0 tools_3.6.3 magrittr_1.5
## [41] crayon_1.3.4 pkgconfig_2.0.3 ellipsis_0.3.1 xml2_1.3.2
## [45] reprex_0.3.0 lubridate_1.7.9 assertthat_0.2.1 rmarkdown_2.3
## [49] httr_1.4.2 rstudioapi_0.11 R6_2.5.0 compiler_3.6.3
End of document


A Review of Thai Chess and Cambodian Chess by Gary Gifford
Thai Chess and Cambodian Chess: Makruk and Ouk Chattrangi is a self published book by Gary Gifford. Those who love chess variants will appreciate this short read. In just under 90 pages, Gifford gives an introduction to the history, rules, openings, recorded games and describes homemade sets.
Introduction
Gifford starts off with how he was personally introduced to Makruk when some friends invited him to play. This peaked his interest and led him on a quest to find a book on this regional variant. He even went as far as to contact a bookstore in Bangkok but with no success. As the result of a seemingly lack of Makruk books in the world, he decided to write this one.
Ouk Chattrang (the Cambodian version) is almost identical to Makruk. Both games appeared in the center of the former Khmer Empire (9th-15th A.D.). The Khmer Empire included modern day Cambodia, Thailand, Laos, Vietnam, Myanmar and Malaysia. Gifford gives a brief history, borrowing much of his information from H.R. Murray’s classic, History of Chess (1913).
Rules
One of the notable differences in Makruk is where the pawns are located. Instead of the 2nd and 7th rank, the pawns sit on the 3rd and 6th rank. Coincidentally (or maybe not), pawns do not move 2 spaces on their first moves and there is no en passant captures. There is also no castling.
Another more subtle setup difference is Kings face the enemy Queens.
Makruk and Ouk Chattrang Setup
The moves of most of the pieces will feel familiar with the exception of the Bishop and Queen. These are much weaker pieces compared to those of Western chess.
- The Rook moves the same as Western chess, any number of spaces in an orthogonal manner.
- The Horse moves the same “L” shape move as the Western Knight.
- The Bishop can only move 1 space diagonally or forward (not directly backwards or to the side).
- The King moves 1 space any direction as the Western King, but there is no castling.
- The Queen moves 1 space diagonally.
- The Pawns move 1 space forward and capture 1 space diagonally as in Western Chess.
Pawns promote on the 6th rank and only promote to Queens. Which is unfortunate since the Queen is almost the weakest piece on the board (second only to the pawns themselves).
Special Ouk Chattrang Rules
Ouk Chattrang has a couple of special first moves that is not in Makruk.
The King is allowed to move like a Horse on it’s first move, ending up on the 2nd rank. The Queen is allowed to move forward 2 spaces on her first move.
Counting Rules
One of the most unique things about Makruk that differentiates it from other regional chess variants is the counting rules. Although, I have usually skipped these rules, Gifford emphasizes the importance of playing with them. He compares playing Makruk without the counting rules is like playing Western chess without the castling rule or en passant captures. This convinced me that in order to play an authentic version of a game, you can’t simply leave out rules that are not to your liking.
The counting rules fall into 2 major categories:
- No Pawns
When all the pawns are captured or promoted (i.e. no one has pawns), the game must end in checkmate after 64 moves. It is up the losing player to keep this count and you can end up with a draw instead of a lost.
- Bare King
When the losing player only has a King left on the board, look at the winning player’s pieces and this determines how many moves they have to checkmate.
If the winning player has:
2 Rooks, then 8 minus total number of pieces on the board.
1 Rook, then 16 minus total number of pieces on the board.
2 Bishops, then 22 minus total number of pieces on the board.
2 Horses, then 32 minus total number of pieces on the board.
1 Bishop, then 44 minus total number of pieces on the board.
1 Horse, then 64 minus total number of pieces on the board.
Only Queens Left, then 64 minus total number of pieces on the board.
The game can conceivable move from a No Pawns count to a Bare King count. Once you are counting from the calculation made in the Bare King category, that’s it. No recalculation is done.
I initially found this a bit confusing (which is why I have ignore the counting rules in the past). Gifford seems to acknowledge this by providing counting exercises and answers in order for the new player to learn.
Openings and Games
Next he categorizes and goes through a 16 different openings with names like “King Horse Low / Queen Horse High” and “Two Horse Low (Low Horse Constellation)”
Here is a little video I made with my set to help further explain.
As if to complement the 16 openings, Gifford then goes through 16 games, annotating and providing his insight every step of the way.
 This is covers everything from modifying cheap plastic sets to taking a trip to the hardware store to find nuts and bolts that would match. Gifford insists on using pieces as traditional as possible. Like the counting rules, there is an authenticity to it and it just wouldn’t quite be the same otherwise.
He states: “I will not play Makruk using a western set anymore than I would play a game of checkers using chess pieces.”
There is something that rings true about that statement.
Conclusion
Overall, if you have interest in Makruk or Ouk Chattrang, this is a great little book to get started with. The author’s passion and expertise really comes through and it’s fun to share in some of that enthusiasm.


WHiSe II is a symposium aimed at strengthening communication between scholars in the Digital Humanities and Semantic Web communities and discussing unthought-of opportunities arising from the research problems of the former. Its best-of-both-worlds format will accommodate the practices of scholarly dialogue in both fields by inviting visions, real systems and debate.
WHiSe is proudly co-located with the 16th International Semantic Web Conference (ISWC)
Large digital libraries and cultural heritage aggregators have demonstrated the value of semantic technologies in the dissemination of catalogued data in the Humanities, also thanks to widely-adopted extensible conceptual models. The more recent research landscape in the Humanities, however, has seen the rise of a multitude of application domains for Linked Data management techniques and Web ontologies, including gazetteers, annotated ancient digital maps, historical records and even digital preservation of the intangible, as in performing arts, music and musicology.
As this emerging research ecosystem deals with the reality of the Semantic Web and the ever-growing data cloud under its aegis, it is important to reflect on the ways in which the Semantic Web community is serving the needs of these research networks comprising historians, philologists, cultural critics, musicologists and even artists. Is access to these systems and techniques inhibiting these scholarly categories? Are there research challenges of interest that humanists have not considered due to biased perceptions of the usefulness of Linked Data? What problems do Humanities users experience in interacting with Semantic Web content and applications? What otherwise unseen opportunities can arise by confronting Semantic Web researchers with non-technical issues and needs stemming from cultural studies?
WHiSe II welcomes original research contributions crossing Humanities and the Semantic Web. Scholars who have conducted research or developed impactful applications are invited to submit full papers with appropriately evaluated contributions. WHiSe also welcomes short vision or position papers on novel challenges or approaches to existing problems.
Topics on which potential submitters are invited to contribute include, but are not limited to:
Submissions in all the categories mentioned above (both full and short papers) will be peer-reviewed by acknowledged researchers familiar with both scientific communities. Accepted papers will be published as online proceedings courtesy of CEUR-WS.org.
Every submitted paper must represent original and unpublished work: it must not be under review or accepted elsewhere and there must be a significantly clear element of novelty distinguishing a submitted paper from any other prior publication or current submission. Please refer to the guidelines of the ISWC 2017 research track for 'Prior Publication and Multiple Submissions'.
We welcome the following types of contributions:
All submissions must be PDF documents written in English and formatted according to LNCS instructions for authors.
Papers are to be submitted through the Easychair Conference Management System. Page limits are inclusive of references and appendices, if any.
Contact email: whise2017@easychair.org


private fun deleteMarriageFromUi(marriage: Marriage): Unit
Updates the UI to delete a marriage from the Person being edited. Nothing is deleted from the database at this stage.
See Also
addMarriageToUi