| I l@ve RuBoard |
1.4 The os ModuleThe os module provides a unified interface to many operating system functions. Most of the functions in this module are implemented by platform-specific modules, such as posix or nt. The os module automatically loads the right implementation module when it is first imported. 1.4.1 Working with FilesThe built-in open function lets you create, open, and modify files, as shown in Example 1-27. This module adds those extra functions you need to rename and remove files. Example 1-27. Using the os Module to Rename and Remove FilesFile: os-example-3.py import os import string def replace(file, search_for, replace_with): # replace strings in a text file back = os.path.splitext(file)[0] + ".bak" temp = os.path.splitext(file)[0] + ".tmp" try: # remove old temp file, if any os.remove(temp) except os.error: pass fi = open(file) fo = open(temp, "w") for s in fi.readlines(): fo.write(string.replace(s, search_for, replace_with)) fi.close() fo.close() try: # remove old backup file, if any os.remove(back) except os.error: pass # rename original to backup... os.rename(file, back) # ...and temporary to original os.rename(temp, file) # # try it out! file = "samples/sample.txt" replace(file, "hello", "tjena") replace(file, "tjena", "hello") 1.4.2 Working with DirectoriesThe os module also contains many functions that work on entire directories. The listdir function returns a list of all filenames in a given directory, as shown in Example 1-28. The current and parent directory markers used on Unix and Windows (. and ..) are not included in this list. Example 1-28. Using the os Module to List the Files in a DirectoryFile: os-example-5.py import os for file in os.listdir("samples"): print file sample.au sample.jpg sample.wav ... The getcwd and chdir functions are used to get and set the current directory, as shown in Example 1-29. Example 1-29. Using the os Module to Change the Working DirectoryFile: os-example-4.py import os # where are we? cwd = os.getcwd() print "1", cwd # go down os.chdir("samples") print "2", os.getcwd() # go back up os.chdir(os.pardir) print "3", os.getcwd() 1 /ematter/librarybook 2 /ematter/librarybook/samples 3 /ematter/librarybook The makedirs and removedirs functions are used to create and remove directory hierarchies, as shown in Example 1-30. Example 1-30. Using the os Module to Create and Remove Multiple Directory LevelsFile: os-example-6.py import os os.makedirs("test/multiple/levels") fp = open("test/multiple/levels/file", "w") fp.write("inspector praline") fp.close() # remove the file os.remove("test/multiple/levels/file") # and all empty directories above it os.removedirs("test/multiple/levels") Note that removedirs removes all empty directories along the given path, starting with the last directory in the given pathname. In contrast, the mkdir and rmdir functions can only handle a single directory level, as shown in Example 1-31. Example 1-31. Using the os Module to Create and Remove DirectoriesFile: os-example-7.py import os os.mkdir("test") os.rmdir("test") os.rmdir("samples") # this will fail Traceback (innermost last): File "os-example-7", line 6, in ? OSError: [Errno 41] Directory not empty: 'samples' To remove non-empty directories, you can use the rmtree function in the shutil module. 1.4.3 Working with File AttributesThe stat function fetches information about an existing file, as demonstrated in Example 1-32. It returns a 9-tuple which contains the size, inode change timestamp, modification timestamp, and access privileges. Example 1-32. Using the os Module to Get Information About a FileFile: os-example-1.py import os import time file = "samples/sample.jpg" def dump(st): mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime = st print "- size:", size, "bytes" print "- owner:", uid, gid print "- created:", time.ctime(ctime) print "- last accessed:", time.ctime(atime) print "- last modified:", time.ctime(mtime) print "- mode:", oct(mode) print "- inode/dev:", ino, dev # # get stats for a filename st = os.stat(file) print "stat", file dump(st) print # # get stats for an open file fp = open(file) st = os.fstat(fp.fileno()) print "fstat", file dump(st) stat samples/sample.jpg - size: 4762 bytes - owner: 0 0 - created: Tue Sep 07 22:45:58 1999 - last accessed: Sun Sep 19 00:00:00 1999 - last modified: Sun May 19 01:42:16 1996 - mode: 0100666 - inode/dev: 0 2 fstat samples/sample.jpg - size: 4762 bytes - owner: 0 0 - created: Tue Sep 07 22:45:58 1999 - last accessed: Sun Sep 19 00:00:00 1999 - last modified: Sun May 19 01:42:16 1996 - mode: 0100666 - inode/dev: 0 0 Some fields don't make sense on non-Unix platforms; for example, the (inode, dev) tuple provides a unique identity for each file on Unix, but may contain arbitrary data on other platforms. The stat module contains a number of useful constants and helper functions for dealing with the members of the stat tuple. Some of these are shown in the examples that follow. You can modify the mode and time fields using the chmod and utime functions, as shown in Example 1-33. Example 1-33. Using the os Module to Change a File's Privileges and TimestampsFile: os-example-2.py import os import stat, time infile = "samples/sample.jpg" outfile = "out.jpg" # copy contents fi = open(infile, "rb") fo = open(outfile, "wb") while 1: s = fi.read(10000) if not s: break fo.write(s) fi.close() fo.close() # copy mode and timestamp st = os.stat(infile) os.chmod(outfile, stat.S_IMODE(st[stat.ST_MODE])) os.utime(outfile, (st[stat.ST_ATIME], st[stat.ST_MTIME])) print "original", "=>" print "mode", oct(stat.S_IMODE(st[stat.ST_MODE])) print "atime", time.ctime(st[stat.ST_ATIME]) print "mtime", time.ctime(st[stat.ST_MTIME]) print "copy", "=>" st = os.stat(outfile) print "mode", oct(stat.S_IMODE(st[stat.ST_MODE])) print "atime", time.ctime(st[stat.ST_ATIME]) print "mtime", time.ctime(st[stat.ST_MTIME]) original => mode 0666 atime Thu Oct 14 15:15:50 1999 mtime Mon Nov 13 15:42:36 1995 copy => mode 0666 atime Thu Oct 14 15:15:50 1999 mtime Mon Nov 13 15:42:36 1995 1.4.4 Working with ProcessesThe system function runs a new command under the current process, and waits for it to finish, as shown in Example 1-34. Example 1-34. Using the os Module to Run an Operating System CommandFile: os-example-8.py import os if os.name == "nt": command = "dir" else: command = "ls -l" os.system(command) -rwxrw-r-- 1 effbot effbot 76 Oct 9 14:17 README -rwxrw-r-- 1 effbot effbot 1727 Oct 7 19:00 SimpleAsyncHTTP.py -rwxrw-r-- 1 effbot effbot 314 Oct 7 20:29 aifc-example-1.py -rwxrw-r-- 1 effbot effbot 259 Oct 7 20:38 anydbm-example-1.py ... The command is run via the operating system's standard shell, and returns the shell's exit status. Under Windows 95/98, the shell is usually command.com, whose exit status is always 0.
The exec function starts a new process, replacing the current one ( "go to process," in other words). In Example 1-35, note that the "goodbye" message is never printed. Example 1-35. Using the os Module to Start a New ProcessFile: os-exec-example-1.py import os import sys program = "python" arguments = ["hello.py"] print os.execvp(program, (program,) + tuple(arguments)) print "goodbye" hello again, and welcome to the show Python provides a whole bunch of exec functions, with slightly varying behaviors. Example 1-35 uses execvp, which searches for the program along the standard path, passes the contents of the second argument tuple as individual arguments to that program, and runs it with the current set of environment variables. See the Python Library Reference for more information on the other seven ways to call this function. Under Unix, you can call other programs from the current one by combining exec with two other functions, fork and wait, as shown in Example 1-36. The fork function makes a copy of the current process, and the wait function waits for a child process to finish. Example 1-36. Using the os Module to Run Another Program (Unix)File: os-exec-example-2.py import os import sys def run(program, *args): pid = os.fork() if not pid: os.execvp(program, (program,) + args) return os.wait()[0] run("python", "hello.py") print "goodbye" hello again, and welcome to the show goodbye The fork returns zero in the new process (the return from fork is the first thing that happens in that process!), and a non-zero process identifier in the original process. Or in other words, "not pid" is true only if we're in the new process. The fork and wait functions are not available on Windows, but you can use the spawn function instead, as shown in Example 1-37. Unfortunately, there's no standard version of spawn that searches for an executable along the path, so you have to do that yourself. Example 1-37. Using the os Module to Run Another Program (Windows)File: os-spawn-example-1.py import os import string def run(program, *args): # find executable for path in string.split(os.environ["PATH"], os.pathsep): file = os.path.join(path, program) + ".exe" try: return os.spawnv(os.P_WAIT, file, (file,) + args) except os.error: pass raise os.error, "cannot find executable" run("python", "hello.py") print "goodbye" hello again, and welcome to the show goodbye You can also use spawn to run other programs in the background. Example 1-38 adds an optional mode argument to the run function; when set to os.P_NOWAIT, the script doesn't wait for the other program to finish. The default flag value os.P_WAIT tells spawn to wait until the new process is finished. Other flags include os.P_OVERLAY, which makes spawn behave like exec, and os.P_DETACH, which runs the new process in the background, detached from both console and keyboard. Example 1-38. Using the os Module to Run Another Program in the Background (Windows)File: os-spawn-example-2.py import os import string def run(program, *args, **kw): # find executable mode = kw.get("mode", os.P_WAIT) for path in string.split(os.environ["PATH"], os.pathsep): file = os.path.join(path, program) + ".exe" try: return os.spawnv(mode, file, (file,) + args) except os.error: pass raise os.error, "cannot find executable" run("python", "hello.py", mode=os.P_NOWAIT) print "goodbye" goodbye hello again, and welcome to the show Example 1-39 provides a spawn method that works on either platform. Example 1-39. Using Either spawn or fork/exec to Run Another ProgramFile: os-spawn-example-3.py import os import string if os.name in ("nt", "dos"): exefile = ".exe" else: exefile = "" def spawn(program, *args): try: # possible 2.0 shortcut! return os.spawnvp(program, (program,) + args) except AttributeError: pass try: spawnv = os.spawnv except AttributeError: # assume it's unix pid = os.fork() if not pid: os.execvp(program, (program,) + args) return os.wait()[0] else: # got spawnv but no spawnp: go look for an executable for path in string.split(os.environ["PATH"], os.pathsep): file = os.path.join(path, program) + exefile try: return spawnv(os.P_WAIT, file, (file,) + args) except os.error: pass raise IOError, "cannot find executable" # # try it out! spawn("python", "hello.py") print "goodbye" hello again, and welcome to the show goodbye Example 1-39 first attempts to call a function named spawnvp. If that doesn't exist (it doesn't, in 2.0 and earlier), the function looks for a function named spawnv and searches the path all by itself. As a last resort, it falls back on exec and fork. 1.4.5 Working with Daemon ProcessesOn Unix, you can also use fork to turn the current process into a background process (a "daemon"). Basically, you need to fork off a copy of the current process, and terminate the original process, as shown in Example 1-40. Example 1-40. Using the os Module to Run as Daemon (Unix)File: os-example-14.py import os import time pid = os.fork() if pid: os._exit(0) # kill original print "daemon started" time.sleep(10) print "daemon terminated" It takes a bit more work to create a real daemon, however. First, call setpgrp to make the new process a "process group leader." Otherwise, signals sent to a (by that time) unrelated process group might cause problems in your daemon: os.setpgrp() It's also a good idea to remove the user mode mask, to make sure files created by the daemon actually get the mode flags specified by the program: os.umask(0) Then, you should redirect the stdout/stderr files, instead of just closing them (if you don't do this, you may get unexpected exceptions the day some of your code tries to write something to the console via stdout or stderr). class NullDevice: def write(self, s): pass sys.stdin.close() sys.stdout = NullDevice() sys.stderr = NullDevice() In other words, while Python's print and C's printf/fprintf won't crash your program if the devices have been disconnected, sys.stdout.write() happily throws an IOError exception when the application runs as a daemon. But your program works just fine when running in the foreground... By the way, the _exit function used in the previous examples terminates the current process. In contrast to sys.exit, this works also if the caller happens to catch the SystemExit exception, as shown in Example 1-41. Example 1-41. Using the os Module to Exit the Current ProcessFile: os-example-9.py import os import sys try: sys.exit(1) except SystemExit, value: print "caught exit(%s)" % value try: os._exit(2) except SystemExit, value: print "caught exit(%s)" % value print "bye!" caught exit(1) |
| I l@ve RuBoard |


public class X509Name extends ASN1Object
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY }
| Modifier and Type | Field and Description |
|---|---|
static ASN1ObjectIdentifier |
BUSINESS_CATEGORY
Deprecated.
businessCategory - DirectoryString(SIZE(1..128)
|
static ASN1ObjectIdentifier |
C
Deprecated.
use a X500NameStyle
|
static ASN1ObjectIdentifier |
CN
Deprecated.
use a X500NameStyle
|
static ASN1ObjectIdentifier |
COUNTRY_OF_CITIZENSHIP
Deprecated.
RFC 3039 CountryOfCitizenship - PrintableString (SIZE (2)) -- ISO 3166
codes only
|
static ASN1ObjectIdentifier |
COUNTRY_OF_RESIDENCE
Deprecated.
RFC 3039 CountryOfResidence - PrintableString (SIZE (2)) -- ISO 3166
codes only
|
static ASN1ObjectIdentifier |
DATE_OF_BIRTH
Deprecated.
RFC 3039 DateOfBirth - GeneralizedTime - YYYYMMDD000000Z
|
static ASN1ObjectIdentifier |
DC
Deprecated.
|
static java.util.Hashtable |
DefaultLookUp
Deprecated.
look up table translating common symbols into their OIDS.
|
static boolean |
DefaultReverse
Deprecated.
determines whether or not strings should be processed and printed
from back to front.
|
static java.util.Hashtable |
DefaultSymbols
Deprecated.
default look up table translating OID values into their common symbols following
the convention in RFC 2253 with a few extras
|
static ASN1ObjectIdentifier |
DMD_NAME
Deprecated.
RFC 2256 dmdName
|
static ASN1ObjectIdentifier |
DN_QUALIFIER
Deprecated.
dnQualifier - DirectoryString(SIZE(1..64)
|
static ASN1ObjectIdentifier |
E
Deprecated.
email address in Verisign certificates
|
static ASN1ObjectIdentifier |
EmailAddress
Deprecated.
use a X500NameStyle
|
static ASN1ObjectIdentifier |
GENDER
Deprecated.
RFC 3039 Gender - PrintableString (SIZE(1)) -- "M", "F", "m" or "f"
|
static ASN1ObjectIdentifier |
GENERATION
Deprecated.
|
static ASN1ObjectIdentifier |
GIVENNAME
Deprecated.
|
static ASN1ObjectIdentifier |
INITIALS
Deprecated.
|
static ASN1ObjectIdentifier |
L
Deprecated.
locality name - StringType(SIZE(1..64))
|
static ASN1ObjectIdentifier |
NAME
Deprecated.
id-at-name
|
static ASN1ObjectIdentifier |
NAME_AT_BIRTH
Deprecated.
ISIS-MTT NameAtBirth - DirectoryString(SIZE(1..64)
|
static ASN1ObjectIdentifier |
O
Deprecated.
use a X500NameStyle
|
static java.util.Hashtable |
OIDLookUp
Deprecated.
use DefaultSymbols
|
static ASN1ObjectIdentifier |
OU
Deprecated.
use a X500NameStyle
|
static ASN1ObjectIdentifier |
PLACE_OF_BIRTH
Deprecated.
RFC 3039 PlaceOfBirth - DirectoryString(SIZE(1..128)
|
static ASN1ObjectIdentifier |
POSTAL_ADDRESS
Deprecated.
RFC 3039 PostalAddress - SEQUENCE SIZE (1..6) OF
DirectoryString(SIZE(1..30))
|
static ASN1ObjectIdentifier |
POSTAL_CODE
Deprecated.
postalCode - DirectoryString(SIZE(1..40)
|
static ASN1ObjectIdentifier |
PSEUDONYM
Deprecated.
RFC 3039 Pseudonym - DirectoryString(SIZE(1..64)
|
static java.util.Hashtable |
RFC1779Symbols
Deprecated.
look up table translating OID values into their common symbols following the convention in RFC 1779
|
static java.util.Hashtable |
RFC2253Symbols
Deprecated.
look up table translating OID values into their common symbols following the convention in RFC 2253
|
static ASN1ObjectIdentifier |
SERIALNUMBER
Deprecated.
device serial number name - StringType(SIZE(1..64))
|
static ASN1ObjectIdentifier |
SN
Deprecated.
device serial number name - StringType(SIZE(1..64))
|
static ASN1ObjectIdentifier |
ST
Deprecated.
state, or province name - StringType(SIZE(1..64))
|
static ASN1ObjectIdentifier |
STREET
Deprecated.
street - StringType(SIZE(1..64))
|
static ASN1ObjectIdentifier |
SURNAME
Deprecated.
Naming attributes of type X520name
|
static java.util.Hashtable |
SymbolLookUp
Deprecated.
use DefaultLookUp
|
static ASN1ObjectIdentifier |
T
Deprecated.
use a X500NameStyle
|
static ASN1ObjectIdentifier |
TELEPHONE_NUMBER
Deprecated.
id-at-telephoneNumber
|
static ASN1ObjectIdentifier |
UID
Deprecated.
LDAP User id.
|
static ASN1ObjectIdentifier |
UNIQUE_IDENTIFIER
Deprecated.
|
static ASN1ObjectIdentifier |
UnstructuredAddress
Deprecated.
|
static ASN1ObjectIdentifier |
UnstructuredName
Deprecated.
more from PKCS#9
|
| Modifier | Constructor and Description |
|---|---|
protected |
X509Name()
Deprecated.
|
|
X509Name(ASN1Sequence seq)
Deprecated.
use X500Name.getInstance()
|
|
X509Name(boolean reverse,
java.util.Hashtable lookUp,
java.lang.String dirName)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(boolean reverse,
java.util.Hashtable lookUp,
java.lang.String dirName,
X509NameEntryConverter converter)
Deprecated.
Takes an X509 dir name as a string of the format "C=AU, ST=Victoria", or
some such, converting it into an ordered set of name attributes. lookUp
should provide a table of lookups, indexed by lowercase only strings and
yielding a ASN1ObjectIdentifier, other than that OID. and numeric oids
will be processed automatically.
|
|
X509Name(boolean reverse,
java.lang.String dirName)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(boolean reverse,
java.lang.String dirName,
X509NameEntryConverter converter)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(java.util.Hashtable attributes)
Deprecated.
use an ordered constructor! The hashtable ordering is rarely correct
|
|
X509Name(java.lang.String dirName)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(java.lang.String dirName,
X509NameEntryConverter converter)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(java.util.Vector ordering,
java.util.Hashtable attributes)
Deprecated.
Constructor from a table of attributes with ordering.
|
|
X509Name(java.util.Vector ordering,
java.util.Hashtable attributes,
X509NameEntryConverter converter)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(java.util.Vector oids,
java.util.Vector values)
Deprecated.
use X500Name, X500NameBuilder
|
|
X509Name(java.util.Vector oids,
java.util.Vector values,
X509NameEntryConverter converter)
Deprecated.
use X500Name, X500NameBuilder
|
| Modifier and Type | Method and Description |
|---|---|
boolean |
equals(java.lang.Object obj)
Deprecated.
test for equality - note: case is ignored.
|
boolean |
equals(java.lang.Object obj,
boolean inOrder)
Deprecated.
|
static X509Name |
getInstance(ASN1TaggedObject obj,
boolean explicit)
Deprecated.
Return a X509Name based on the passed in tagged object.
|
static X509Name |
getInstance(java.lang.Object obj)
Deprecated.
|
java.util.Vector |
getOIDs()
Deprecated.
return a vector of the oids in the name, in the order they were found.
|
java.util.Vector |
getValues()
Deprecated.
return a vector of the values found in the name, in the order they
were found.
|
java.util.Vector |
getValues(ASN1ObjectIdentifier oid)
Deprecated.
return a vector of the values found in the name, in the order they
were found, with the DN label corresponding to passed in oid.
|
int |
hashCode()
Deprecated.
|
ASN1Primitive |
toASN1Primitive()
Deprecated.
Method providing a primitive representation of this object suitable for encoding.
|
java.lang.String |
toString()
Deprecated.
|
java.lang.String |
toString(boolean reverse,
java.util.Hashtable oidSymbols)
Deprecated.
convert the structure to a string - if reverse is true the
oids and values are listed out starting with the last element
in the sequence (ala RFC 2253), otherwise the string will begin
with the first element of the structure.
|
getEncoded, getEncoded, hasEncodedTagValue, toASN1Object
public static final ASN1ObjectIdentifier C
public static final ASN1ObjectIdentifier O
public static final ASN1ObjectIdentifier OU
public static final ASN1ObjectIdentifier T
public static final ASN1ObjectIdentifier CN
public static final ASN1ObjectIdentifier SN
public static final ASN1ObjectIdentifier STREET
public static final ASN1ObjectIdentifier SERIALNUMBER
public static final ASN1ObjectIdentifier L
public static final ASN1ObjectIdentifier ST
public static final ASN1ObjectIdentifier SURNAME
public static final ASN1ObjectIdentifier GIVENNAME
public static final ASN1ObjectIdentifier INITIALS
public static final ASN1ObjectIdentifier GENERATION
public static final ASN1ObjectIdentifier UNIQUE_IDENTIFIER
public static final ASN1ObjectIdentifier BUSINESS_CATEGORY
public static final ASN1ObjectIdentifier POSTAL_CODE
public static final ASN1ObjectIdentifier DN_QUALIFIER
public static final ASN1ObjectIdentifier PSEUDONYM
public static final ASN1ObjectIdentifier DATE_OF_BIRTH
public static final ASN1ObjectIdentifier PLACE_OF_BIRTH
public static final ASN1ObjectIdentifier GENDER
public static final ASN1ObjectIdentifier COUNTRY_OF_CITIZENSHIP
public static final ASN1ObjectIdentifier COUNTRY_OF_RESIDENCE
public static final ASN1ObjectIdentifier NAME_AT_BIRTH
public static final ASN1ObjectIdentifier POSTAL_ADDRESS
public static final ASN1ObjectIdentifier DMD_NAME
public static final ASN1ObjectIdentifier TELEPHONE_NUMBER
public static final ASN1ObjectIdentifier NAME
public static final ASN1ObjectIdentifier EmailAddress
Note: if you're trying to be ultra orthodox, don't use this! It shouldn't be in here.
public static final ASN1ObjectIdentifier UnstructuredName
public static final ASN1ObjectIdentifier UnstructuredAddress
public static final ASN1ObjectIdentifier E
public static final ASN1ObjectIdentifier DC
public static final ASN1ObjectIdentifier UID
public static boolean DefaultReverse
public static final java.util.Hashtable DefaultSymbols
public static final java.util.Hashtable RFC2253Symbols
public static final java.util.Hashtable RFC1779Symbols
public static final java.util.Hashtable DefaultLookUp
public static final java.util.Hashtable OIDLookUp
public static final java.util.Hashtable SymbolLookUp
protected X509Name()
public X509Name(ASN1Sequence seq)
public X509Name(java.util.Hashtable attributes)
it's is assumed the table contains OID/String pairs, and the contents of the table are copied into an internal table as part of the construction process.
Note: if the name you are trying to generate should be following a specific ordering, you should use the constructor with the ordering specified below.
public X509Name(java.util.Vector ordering, java.util.Hashtable attributes)
it's is assumed the table contains OID/String pairs, and the contents of the table are copied into an internal table as part of the construction process. The ordering vector should contain the OIDs in the order they are meant to be encoded or printed in toString.
public X509Name(java.util.Vector ordering, java.util.Hashtable attributes, X509NameEntryConverter converter)
it's is assumed the table contains OID/String pairs, and the contents of the table are copied into an internal table as part of the construction process. The ordering vector should contain the OIDs in the order they are meant to be encoded or printed in toString.
The passed in converter will be used to convert the strings into their ASN.1 counterparts.
public X509Name(java.util.Vector oids, java.util.Vector values)
public X509Name(java.util.Vector oids, java.util.Vector values, X509NameEntryConverter converter)
The passed in converter will be used to convert the strings into their ASN.1 counterparts.
public X509Name(java.lang.String dirName)
public X509Name(java.lang.String dirName, X509NameEntryConverter converter)
public X509Name(boolean reverse, java.lang.String dirName)
public X509Name(boolean reverse, java.lang.String dirName, X509NameEntryConverter converter)
public X509Name(boolean reverse, java.util.Hashtable lookUp, java.lang.String dirName)
reverse
- true if we should start scanning from the end (RFC 2553).lookUp
- table of names and their oids.dirName
- the X.500 string to be parsed.public X509Name(boolean reverse, java.util.Hashtable lookUp, java.lang.String dirName, X509NameEntryConverter converter)
reverse
- true if we should start scanning from the end, false otherwise.lookUp
- table of names and oids.dirName
- the string dirNameconverter
- the converter to convert string values into their ASN.1 equivalentspublic static X509Name getInstance(ASN1TaggedObject obj, boolean explicit)
obj
- tag object holding name.explicit
- true if explicitly tagged false otherwise.public static X509Name getInstance(java.lang.Object obj)
public java.util.Vector getOIDs()
public java.util.Vector getValues()
public java.util.Vector getValues(ASN1ObjectIdentifier oid)
public ASN1Primitive toASN1Primitive()
ASN1Object
toASN1Primitive
in interface ASN1Encodable
toASN1Primitive
in class ASN1Object
public boolean equals(java.lang.Object obj, boolean inOrder)
inOrder
- if true the order of both X509 names must be the same,
as well as the values associated with each element.public int hashCode()
hashCode
in class ASN1Object
public boolean equals(java.lang.Object obj)
equals
in class ASN1Object
public java.lang.String toString(boolean reverse, java.util.Hashtable oidSymbols)
reverse
- if true start at the end of the sequence and work back.oidSymbols
- look up table strings for oids.public java.lang.String toString()
toString
in class java.lang.Object


{{refimprove|date=March 2013}} {{Infobox prepared food | name = Sata andagi | image = | caption = A finished sata andagi | alternate_name = | country = Japan | region = Okinawa | creator = | type = Fried dough | served = | main_ingredient = Flour, sugar and eggs | variations = | calories = | other = }}
{{Nihongo|Sata andagi|サーターアンダーギー|Saataa andaagii}} are sweet deep fried buns of dough similar to doughnuts (or the Portuguese malasada, or the Dutch oliebollen), native to the Japanese prefecture of Okinawa. They are also popular in Hawaii, sometimes known there simply as andagi. Traditional Okinawan andagi is made by mixing flour, sugar and eggs. The ingredients are mixed into a ball and deep fried.
Saataa means "sugar", while andaagii means "deep fried" ("oil" (anda) + "fried" (agii)) in Okinawan (satō and abura-age in Japanese.) It is also known as saataa andagii and saataa anragii.
Sata andagi are a part of Okinawan cuisine. Like most confectionery from the Ryukyu Islands, the techniques for making them are descended from a combination of Chinese and Japanese techniques,<ref>http://www.wonder-okinawa.jp/026/e/kashi.html Okinawan tourism site.</ref> although other sources say{{Who|date=October 2015}} it simply is a derivative of a Chinese dish. They are typically prepared so that the outside is crispy and browned while the inside is light and cake-like.
<gallery class="center" caption="" widths="200px" heights="155px"> Image:Making sata andagi.jpg|A batch of sata andagi being deep fried </gallery>
{{Reflist}}
{{commons category|Sata andagi}}
{{Doughnuts}}
{{DEFAULTSORT:Sata Andagi}}
{{dessert-stub}}


May 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.orgMay 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.orgMay 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.orgMay 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.orgMay 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.orgMay 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.orgMay 10, 2014 This reference is for software developers who develop applications by using the OpenStack™ Object Storage Application Programming ...
docs.openstack.org


CVS-DEBI(1) CVS-DEBI(1) NAME cvs-debi - install cvs-buildpackage/cvs-debuild generated package SYNOPSIS cvs-debi [options] [package ...] DESCRIPTION cvs-debi is run from the CVS working directory after cvs-buildpackage or cvs-debuild. It uses the cvs-buildpackage system to locate the .changes file generated in that run. It then runs debpkg -i on every .deb archive listed in the .changes file to install them, assuming that all of the .deb archives live in the same directory as the .changes file. Note that you probably don't want to run this program on a .changes file relating to a different architecture after cross-compiling the package! If a list of packages is given on the command line, then only those debs with names in this list of packages will be installed. Note that unlike cvs-buildpackage, the only way to specify the source package name is with the -P option; you cannot simply have it as the last command-line parameter. Since installing a package requires root privileges, debi calls debpkg rather than dpkg directly. Thus debi will only be useful if it is either being run as root or debpkg can be run as root. See debpkg(1) for more details. OPTIONS All current cvs-buildpackage options are silently accepted; however, only the ones listed below have any effect. For more details on all of them, see the cvs-buildpackage(1) manpage. -adebian-architecture, -tGNU-system-type See dpkg-architecture(1) for a description of these options. They affect the search for the .changes file. They are provided to mimic the behaviour of dpkg-buildpackage when determining the name of the .changes file. -Mmodule The name of the CVS module. -Ppackage The name of the package. -Vversion The version number of the package. -Ttag The CVS tag to use for exporting sources. -Rroot directory Root of the original sources archive. -Wwork directory The full path name for the cvs-buildpackage working directory. -xprefix This option provides the CVS default module prefix. --help, --version Show help message and version information respectively. SEE ALSO cvs-buildpackage(1), cvs-debc(1) cvs-debuild(1) and debi(1). AUTHOR cvs-buildpackage was written by Manoj Srivastava, and the current version of debi was written by Julian Gilbey<EMAIL_ADDRESS>They have been combined into this program by Julian Gilbey. DEBIAN Debian Utilities CVS-DEBI(1)


bath
bed
kitchen
living
study
FREE AND FAST SHIPPING. CUSTOM FURNISHINGS IN JUST 2 WEEKS
CONVERTIBLE DRAPERY
in Classic Linen - True Blue
Starting at $190.00
DUVET COVER
in Classic Linen Pure - White
Starting at $336.00


Click here to download the dataset as a CSV from Data.World
Click here to download the dataset as a Hyper Extract from Data.World
Historical Background
On the 12th of this Month, the Walt Disney Company is releasing their newest offering, Disney+. While typically the innovator, this move is reactive as a response to the changing demand of the consumer. While the idea of a streaming platform is not innovative, Disney’s hope is that their programming will set them apart and be another money making machine.
Over Disney’s history, their capacity to make money has only been limited by the imaginations of the creative people that work for the company. Almost everything Walt Disney touched turned to gold. Disney has always set the standards and in doing so, has been able to create a loyal consumer following that continues to fund and drive their next innovation.
Over time, the company diversified from their initial work in animated shorts and feature length films, turning first to consumer products, then producing content for television, their first foray into theme parks with Disneyland and the eventual expansion of all of these, they have always been looking for the next big revenue generator. This week, we’re looking at Disney’s revenue, broken down by quarter and revenue stream. The four major revenue streams (business segments) we have data for are Media Networks, Parks and Resorts, Studio Entertainment and Consumer Products & Interactive Media. A quick descriptor of each is included below:
- Media Networks – Disney’s media networks are broken down into two sub-categories: Cable Networks (ESPN, Disney Channel and ABC Family), and Broadcasting (ABC). Revenue from this stream is driven by contracts for its affiliates, advertising, licensing fees (for series broadcast on other networks) and more. Significant revenue can be generated for major sporting events – Super Bowl or College Football Bowl Games.
- Parks and Resorts – It is not a secret that Disney owns significant property in this category. From the sprawling Disney World to Disneyland (including Tokyo, Paris, Hong Kong & Shanghai) to non-theme park resorts – Aulani, Disney’s Hilton Head Island Resort and others. Revenue here is generated through hotel fees, entrance fees, merchandising and special experiences among others.
- Studio Entertainment – When you think Disney, if the first thing that pops in your head is not Disney World, it’s likely that you think of movies. Walt Disney Studios has several subsidiaries, including Pixar, Lucasfilm, Marvel Studios and more. Revenue here is driven by box office sales, licensing, home distribution and streaming.
- Consumer Products & Interactive Media (known currently as Consumer Products) – Take a walk down the toy aisle of your nearest big box retailer and it’s immediately clear where Disney makes its money on this one. Beyond the sale of toys, clothing and more, Disney also rolls interactive media into this category. Interactive Media incorporates software subsidiaries, Disney’s web presence and Disney games (the Infinity series and mobile games).
Note that Disney began reporting its revenue by different business segments in FY2019, so we’ll not include those in this data set.
We'd really love to see what you can do with this month's dataset! Download the data and see what you can visualize. Create your viz and post your work to Tableau Public and Twitter with the hashtag #ThrowbackDataThursday, tagging @TThrowbackThurs. We'll feature community vizzes throughout the month!
Data Source
This month's data comes from the Walt Disney Company Investor Relations website. Please be sure to cite the data source in your viz.


refactor is an R package which aims to provide better handling of factors. Though R does have a special data type for factors, it isn’t always explicity catered for in commonly used R functions, which can lead to unexpected and undesirable outcomes (e.g. see this Win-Vector blog post). This observation formed the inspiration for ‘re’-factor: which is essentially to ‘re’-visit functions likely to be used with factor data and where possible to wrap, extend or override them in order to better cater for factor data, or at the very least to provide warnings when the integrity of the data could be compromised by an operation.
refactor is not available on CRAN but you can easily install the latest development version from github using devtools
:
# install.packages("devtools")
devtools::install_github("jonmcalder/refactor")
Below are a few examples to illustrate some scenarios in which refactor can improve on base R’s handling of factors.
Please see the vignette for more details: vignette("refactor", package = "refactor")
cfactor()
string <- c("a", "b", "c")
factor(string, levels = c("b", "c", "d"))
#> [1] <NA> b c
#> Levels: b c d
cfactor(string, levels = c("b", "c", "d"))
#> Warning: the following levels were empty:
#> d
#> Warning: the following levels were removed:
#> a
#> [1] <NA> b c
#> Levels: b c d
hard_to_detect <- c("EUR 21 - EUR 22", "EUR 100 - 101", "EUR 1 - EUR 10", "EUR 11 - EUR 20")
factor(hard_to_detect, ordered = TRUE)
#> [1] EUR 21 - EUR 22 EUR 100 - 101 EUR 1 - EUR 10 EUR 11 - EUR 20
#> 4 Levels: EUR 1 - EUR 10 < EUR 100 - 101 < ... < EUR 21 - EUR 22
cfactor(hard_to_detect, ordered = TRUE)
#> [1] EUR 21 - EUR 22 EUR 100 - 101 EUR 1 - EUR 10 EUR 11 - EUR 20
#> 4 Levels: EUR 1 - EUR 10 < EUR 11 - EUR 20 < ... < EUR 100 - 101
cut
method to handle (discrete) integer data[1,3], [4,6], [7,9]
as opposed to (0.5, 3.5], (3.5, 6.5], (6.5, 9.5]
1-3, 4-6, 7-9
as opposed to [1,3], [4,6], [7,9], or (0,3], (3,6], (6-9]
x_int <- 1:9
cut.default(x_int, breaks = 3)
#> [1] (0.992,3.67] (0.992,3.67] (0.992,3.67] (3.67,6.33] (3.67,6.33]
#> [6] (3.67,6.33] (6.33,9.01] (6.33,9.01] (6.33,9.01]
#> Levels: (0.992,3.67] (3.67,6.33] (6.33,9.01]
cut(x_int, breaks = 3)
#> [1] 1-3 1-3 1-3 4-6 4-6 4-6 7-9 7-9 7-9
#> Levels: 1-3 4-6 7-9
cut
method to handle (non-numeric) ordered datacut
usually requires numeric data, but refactor extends cut
to handle other ordered datasome_letters <- factor(c('d','e','f','a','b','c','g','h','i'), ordered = TRUE)
cut(some_letters, breaks = c('a','c','f','i'), include.lowest = TRUE, ordered_result = TRUE)
#> [1] d-f d-f d-f a-c a-c a-c g-i g-i g-i
#> Levels: a-c < d-f < g-i
Suggestions and feedback are most welcome.
Feel free to open an issue if you want to request a feature or report a bug, and make a pull request if you can contribute.


|
|
Mac
Address Goodies
Tired
of paying a subscription service to access an API to resolve MAC
address data? Just resolving locally and maintaining your own database
with this project is faster, cheaper (FREE!), and more secure.
In just 2 easy steps you'll be up and running in no time! Complete both
of the below steps to
get your local mac address lookup set up.
Step
1,
download the mac
lookup script and extract the contents.
The
script can be used interactively or simply by using the commmand
"oui_search XX-XX-XX-XX-XX-XX" for quicker scripted searches. It
accepts all standard mac address formats: XX-XX-XX-XX-XX-XX,
XXXX-XXXX-XXXX, XX:XX:XX:XX:XX:XX, XXXX:XXXX:XXXX, XXXXXXXXXXXX, etc.
Step
2,
choose the lookup table you need depending on the level of detail you
require and place it into the script directory you extracted in step 1.
The lookup tables here are synced regularly with the IEEE's
daily updates, so remember to keep your files up to date for the latest
and most accurate data.
Master.txt:
Complete record of all IEEE-registered OUI blocks reformatted for
easier script use. There's also an HTML
version of the Master.txt available for quick online
reference, but you still need to download the Master.txt to work with
the lookup script.
OR
Simplified.txt:
Same as master.txt, but block type and vendor address columns removed.
NOTE:
If you decide to use the simplified.txt, set the SIMPLE variable at the
top of the script to 1.
To edit the script, simply right-click the OUI_Search.cmd and select
"Edit."
Unlike 99.9% of the other OUI lookups out there, the master.txt and
simplified.txt include all of the IEEE blocks, where even the majority
of professional premium-grade products on the market only
include the
single MA-L block. The difference is that the MA-L block is the largest
and contains the most common and well-known vendors that require the
most number of
unique MAC addresseses, where each registry entry can allocate up to
16,777,215 unique MAC addresses. Each entry in the MA-M block can
allocate 1,048,575 unique MAC addresses and each entry in the MA-S
block can allocate only 4,095 unique MAC addresses. Although they are
smaller in number and mostly neglected OUIs, MA-M and MA-S have also
been included for completeness.
What
these files do not include are separately designated virtual machine
OUIs. In the past including virtual machine OUIs were useful to
distinguish previously undocumented OUIs. However, in modern times
these virtual machine OUIs are now documented and registered with the
IEEE by their controlling authorities. For example, the VirtualBox
virtual NICs are registered to Oracle Corporation, the VMWare virtual
NICs are registered to VMware, Inc., the Xen virtual NICs are
registered to Xensource, Inc., the Parallels virtual NICs are
registered to Parallels, Inc., and all of the various virtual NICs you
can create in Windows are all registered to Microsoft Corporation.
Since all of these and more are registered OUIs, there is no longer a
need to curate an elusive DIY virtual NIC list separate from those that
are already registered. And on top of all of this, as most virtual NICs
can be programmed with any MAC address the user desires because they do
not posses a physical computer chip with a burned-in address to load
into RAM on boot as physical NICs do, even in the past these lists were
unreliable.
Original source files provided by IEEE:
MA-S Registry: IEEE
| Mirror
MA-M Registry: IEEE
| Mirror
MA-L Registry: IEEE
| Mirror
You can also download the complete
OUI bundle which includes the master.txt, simplified.txt, and
all
of the IEEE source files.
Have questions or comments about the content on this page? ScriptTiger
would love to hear them! Open a new issue in ScriptTiger's
GitHub Mac-Address-Lookup repository to have your voice
heard! |
|
|


--- layout: standard title: Current Projects ---
Think "Rate My Professors", but for classes.
A map website that people can use to find parking, buildings, and bikes.
An interactive flowchart that will allow the user to choose a class and see what is required to take it and what it allows you to take.


URGENT & CONFIDENTIAL Dear Good Friend, How are you together with your family members? I think all is well. Considering the fact, I did not know you in person or even have seen you before but due to the true revelation that I should share this lucrative opportunity with you, I have no choose. So, kindly consider this message essential and relevant, believe that sooner, we will be multi-millionaires.
I want you to assist me in other to transfer the sum of Twenty One Million United States Currency ($21,000,000.00) into your reliable account as the Next of Kin or Foreign Business partner to the original beneficiary of the fund. The beneficiary was a foreigner and a multi company
; holder who died in a plane crash with his family years ago, he deposited the fund in our bank for his business expansion in Africa unfortunately he met this sudden death and the worst thing that happened was the
I will guide you on how you should apply for the claim so that everything will be smooth and correct. After the transfer, i will resign and come over to your country for the sharing of the fund 50/50 base on the fact that it is two man business. Finally, note that you are not taking any risk becau se there is going to be a legal back up as you we commence.
MR JAMES NAZ
|


5 minutes
Introducing Maybe package, bring functional to Go
One of the advantages of Go is that null (nil
) values are rarer than in some other languages. The following snippet will fail:
func getDay() string {
return nil
}
In order to make that snippet work, a pointer is needed as null values are the zero value for pointers (the same applies for interfaces, channels and function types).
func getDay() *string {
return nil
}
Being that pointers can introduce null and hence panics, and knowing that null is considered to be “The billion dollar mistake”, why is still so common in Go to use pointers for everything? Below are some arguments that I faced:
Optimization
The most common example here are slices. There is a general misconception on how much is a lot, in other words, how many items in a slice are too much to copy it by value. Of course, the answer is it depends. And this is true, a slice with 100 integers is probably less memory intensive that a slice with 50 complex structures with nested slices.
That being said, there is a good saying: avoid premature optimization. Favor copying slices by value instead of using pointers unless you have a super specific case that proves the contrary.
You can find here a nice article doing benchmark on slices using pointers and values.
Modifying the receiver
Imagine the following func:
func (cart *Cart) AddItem (item item) {
cart.Items = append(cart.Items, item)
}
Do you like what you see? Maybe you won’t after visiting these concepts:
Pure functions: A function whose return values are identical for identical arguments - also called deterministic. There is no usage of static variables, mutable references or streams. These functions have no side effects. These kind of functions are very easy to test.
Immutability: An immutable is one whose state cannot be changed after the creation. This means that the immutable is thread safe as you can pass it around contexts knowing they won’t be modified.
Knowing the benefits one can refactor this to eliminate the pointers in something like:
func (cart Cart) AddItem (item item) Cart {
items := append(cart.Items, item)
return newCart(items)
}
JSON property representing three different states
Let’s image that for some reason (which I cannot recommend) there is a Person
structure that contains a Salary
property. The system you are consuming will return the person with different salary depending the employment situation:
{ "name": "Pablo", "salary": 100 }
means paid job.{ "name": "Pablo", "salary": 0 }
means unpaid internship.{ "name": "Pablo", "salary": null }
means unemployment.
If this structure would be deserialized with the following struct, can you image what is going to happen?
type Person struct {
Name string `json:"name"`
Salary int `json:"salary"`
}
If you guessed that Salary
will never be nil
then you guessed correctly. As explained on the first snippet in this post, the zero value for int is 0
. Then as 0
was used for unpaid internship, one would never know the difference between this and being unemployed.
But if the Salary
is changed from int
to *int
, will this work?
type Person struct {
Name string `json:"name"`
Salary *int `json:"salary"`
}
And the answer is yes, but at what cost? Do we want to introduce deliberately pointers in our system to solve this?
Introducing Maybe library
Functional languages have a lot of interesting features that are having more traction as time passes and end up being ported to other languages. One of my favorites is the Option
data type. Think of it as Schrodinger’s cat variable. It may have a value or it may not have a value; and the only way to know it is checking if effectively has one.
UPDATE: Since Go 1.18 has been released, the library now supports generics so it is not limited to string, int, float, time, bool.
Let’s image the following struct:
package maybe
type Maybe[T any] struct {
value T
hasValue bool
}
func Set[T any](value T) Maybe[T] {
return Maybe[T]{
value: value,
hasValue: true,
}
}
func (m Maybe[T]) HasValue() bool {
return m.hasValue
}
func (m Maybe[T]) Value() T {
return m.value
}
This is how an option implementation can look in Go 1.18. By doing so, null
values are not possible. As stated before, while I cannot recommend designing a system where null
and 0
represent different things, we can take another look at the previous example:
- Salary 100 ->
Maybe.HasValue()
will betrue
andMaybe.Value()
will be100
. - Salary 0 ->
Maybe.HasValue()
will betrue
andMaybe.Value()
will be0
. - Salary null ->
Maybe.HasValue()
will befalse
andMaybe.Value()
will be0
.
This is how it looks like in our previous struct:
type Person struct {
Name string `json:"name"`
Salary maybe.Maybe[int] `json:"salary"`
}
But Pablo, this is serialized in the following way, right?
{
"name":"Pablo",
"salary":{
"hasValue":true,
"salary":100
}
}
Not really! Go allows customization of the MarshalJSON()
and UnmarshalJSON()
of a struct, so the serialization will look like:
package maybe
func (m Maybe[T]) MarshalJSON() ([]byte, error) {
var t *T
if m.hasValue {
t = &m.value
}
return json.Marshal(t)
}
If the maybe.Maybe[int]
was not initialized, then the serialization in our example will look like { "salary": null }
; however if maybe.Set(100)
was called, then the hasValue
will be true and the serialization will be { "salary": 100 }
.
Now for the unmarshal, the usage of pointers and null are being handled by the library:
func (m *Maybe[T]) UnmarshalJSON(data []byte) error {
var t *T
if err := json.Unmarshal(data, &t); err != nil {
return err
}
if t != nil {
*m = Set(*t)
}
return nil
}
If the json is { "salary": 100 }
then the pointer is not null and the maybe.Maybe[int]
will be set to HasValue() = true
and Value() = 100
. In the case of { "salary": null }
, the pointer will be nil
and therefore the maybe.Maybe[int]
will contain HasValue() = false
and Value() = 0
.
With this implementation we can code the following assumption:
func (p Person) IsEmployed() bool {
// If salary has value, but it is 0 we assume unpaid internship
return p.Salary.HasValue()
}
Summary
- Don’t use pointers unless you really know what you are doing.
- Try to eliminate the need of
nil
whenever is possible. - Option types are a really nice feature of functional languages.
- 👉 Link to the library. 👈


Waiting For Guffman (R) *** Starring Christopher Guest, Eugene Levy Directed by Christopher Guest A Review by Frankie Paiva
The often confused genre of mockumentary, basically a scripted documentary is often not understood by every Hollywood director. The concept of having interviews with the characters, but forgetting not to give big glamour shots and regular filmed footage has often been forgotten in films like Drop Dead Gorgeous. But this is a fine display of what a true mockumentary should be. Quirky, fun, and entertaining this story of a small town putting on a play of it’s history is sure to entertain many, while still staying true to it’s genre.
Corky St. Clair (Guest) is a gay director that has written an original screenplay about the history of the little Missouri town called Blaine. Blaine is one of those Fargo-type towns where every knows everybody else, and everybody has the same mid-west accent. The auditions are the first major part of a play, Corky is impressed by the town’s dentist, Dr. Allan Pearl (Levy) a man who wears very, very big glasses and is equally stunned by the duo of Sheila and Ron Albertson (Catherine O’Hara and Fred Willard) the man and wife who can really sing. The production has six main players, with Parker Posey (imagine an independent film without her) as a Dairy Queen worker round out the bunch.
When a New York critic named Mr. Guffman (hence the film’s title) promises to come and review it they get even more excited. But the production runs into various problems, Corky insists on having the proper funding to take the show to Broadway, one of the actors is taken out of the play at last minute, and he can’t get Dr. Pearl to take off those darn glasses.
Why is it that everyone in a small town is so weird and quirky? For once if Hollywood could make a movie that didn’t showcase them in this way. Not to say that it isn’t enjoyable, this film is loaded with inside jokes and fun characters. I especially liked Eugene Levy as the town dentist who ends up singing songs to the elderly in Hebrew. But after a while some of the people in this film just seem to be there to be annoying. Seriously, this people must have some connection to the outside world. Waiting For Guffman also stays true to the formula never cutting away to do something super and fantastic and letting the characters interact and respond with the audience. If your looking for a little quirky fun I suggest you rent Waiting For Guffman, which gets *** stars.
The Young-Uns: While not made to appeal to children, this comedy includes 2 f-words. Good Age 11 & Up
A Review by Frankie Paiva The 12 Year-Old Movie Reviewer E-Mail me at<EMAIL_ADDRESS>Visit my website at http://expage.com/page/teenagemoviecritic
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


# File lib/openid/yadis/accept.rb, line 132 def self.get_acceptable(accept_header, have_types) # Parse the accept header and return a list of available types # in preferred order. If a type is unacceptable, it will not be # in the resulting list. # # This is a convenience wrapper around matchTypes and # parse_accept_header # # (str, [str]) -> [str] accepted = self.parse_accept_header(accept_header) preferred = self.match_types(accepted, have_types) return preferred.collect { |mtype, _| mtype } end


This document assumes you understand the ecocomDP model. To learn about the model and its scope, refer to the Model Overview Vignette and the Ecological Informatics Article.
Introduction
This document delineates the practices that all creators of ecocomDP formatted datasets should adopt in order for the community to build a cohesive and interoperable collection. It contains detailed descriptions of practices, definitions of concepts, and solutions to many common issues.
Early sections address important considerations for anyone thinking about converting source datasets to the ecocomDP model, then focus shifts to an examination of the model components in greater detail. These shared practices are written with the intention to help simplify the conversion process.
If you are new to the conversion process, we recommend reading the Getting Started and Concepts sections, reviewing the Create and Model Overview vignettes, and referring back to this document as questions arise. A thorough understanding of the ecocomDP model and some foundational concepts will greatly simplify the conversion process.
Each ecocomDP dataset (Level-1; L1) is created from a raw source dataset (Level-0; L0) by a unique conversion script. Inputs are typically from the APIs of data repositories and monitoring networks, and outputs are a set of archivable files. The derived ecocomDP dataset is delivered to users in a consistent format by
read_data()
and the conversion script provides a fully reproducible and automated routine for updating the derived dataset whenever a new version of the source data are released.
Getting Started
Identifying a candidate L0 dataset
Not all source datasets are good candidates for ecocomDP. Features of a good candidate include datasets that:
- Are about community surveys not population surveys. An ecological community is a multi-species (at least two) collection of organisms living in a particular area, whereas a population is a collection of organisms, all of the same species, that live in the same place.
- Form long-term observation with a suggested minimum of 5 years, which can be ignored for datasets with exceptionally wide spatial extents.
- Have ongoing data collection and will eventually form long-term observation.
- Are accompanied by information rich metadata written in the Ecological Metadata Language (EML).
- Have data and metadata that are programmatically accessible from a trustworthy, stable, and persistent host (i.e. repository or other web-accessible data provider).
Understanding the L0 dataset
A thorough understanding of the L0 dataset is required before actually performing any transformations. To gain understanding of an L0 dataset we recommend:
- Reading the abstract, methods, and keywords to gain insights into the scope, structure, and temporal and spatial scales of the study.
- Reviewing the data object descriptions to understand how data are related across tables.
- Importing the dataset into R and exploring any of your data specific questions.
Major issues at this point may suggest the amount of work required to convert the L0 dataset to the ecocomDP model is not worth it.
Resolving issues
After gaining a sufficient understanding of the L0 dataset, you are ready to assess, and hopefully resolve, any issues that are obvious from the start. To help draw out some of these apparent issues, you may want to create a high-level plan for combining the L0 tables (i.e. Row-wise bindings or joined with shared keys?) and mapping their columns to the L1 ecocomDP model. Here are some solutions (ordered by priority) for resolving issues at this stage in the creation process:
-
Work with the L0 author/manager to fix the issues - Fixing the issue here both communicates best practices for future data curation and immediately improves data quality.
- If the L0 dataset contains a column entirely of NAs, the conversion script should be written so that the L0 variable will populate the correct L1 table if it is ever filled in a future revision.
- When the structure of the L0 dataset (column names, codes used for species, etc.) prevents optimal L1 dataset creation, proceed with writing the conversion script and then provide feedback to the L0 author/manager. Ensure that your conversion script will have the functionality to handle revisions to the L0 dataset.
- Make use of the
message()
function to alert ecocomDP script maintainers to sections of code that could improve in future L0 dataset updates.
-
Modify L0 components - Modifying L0 components is only permitted in rare cases. This list highlights the L0 components and specific scenarios in which you should modify them:
- Duplicate column names - Only change the L0 column names if they create conflicts during joins (i.e. two L0 tables having the same column names) or share the name with an L1 table’s column name. In either case, always preserve the original column name. Append a prefix or suffix to the original column name so that it is distinct but still recognizable enough to be used as a reference to the L0 metadata.
- Non-point locations - Currently, only point coordinates are accepted by the ecocomDP model; use the centroid of bounding areas if presented with non-point locations.
- Datetime formats - Conversion of datetimes to the ecocomDP standard is required (e.g. YYYY-MM-DD hh:mm:ss or a subset thereof). Always combine Year, Month, Day, and time columns to the temporal level of observation (e.g. edi.334.2).
- Missing value codes - Missing value codes that are explicitly declared in the L0 metadata should be converted to NA. When not declared but unambiguously interpretable as a missing value (e.g. “” in a comments field) then convert to NA. If it is ambiguous, don’t modify the L0 data.
- Different temporal resolution among the L0 tables creates a joining/stacking issue. To solve it, assign the coarsest temporal resolution to the datetime field of all the L0 tables, then store the more precise datetime variables in the observation_ancillary table (e.g. edi.291.2).
-
Omit L0 data - ecocomDP is a flexible model but can’t handle everything. Convert as much as possible and drop the remainder. If content is dropped, then describe what and why using comments in the conversion script. Some guidelines for when you should drop content:
- If it is necessary to drop observations (rows), see the section Omitting rows.
- If it can be derived from the preserved content (e.g. year can be derived from date, a taxa’s common name can be derived from its species name) then you can drop it from the L1 dataset if it does not fit the model (i.e. L1 data tables don’t pass validation).
- If it is ancillary information to data in one of the L1 ancillary tables that does not have a simple one-to-one, row-wise relationship, then it is too far removed from the core content of the L1 dataset. (e.g. A temperature sensor collects environmental data that supports the core observations. This temperature data belongs in the observation_ancillary table. If maintenance information for the temperature sensor is included, it could be omitted from the L1 dataset because it cannot be linked to the temperature observations within the model.) However, if the data is so important that it shouldn’t be dropped, then append a suffix to the supporting data’s original variable name that references the ancillary data (e.g. ancillary data “Site” has supporting data “lat” and “lon”. The variables “Site”, “lat_Site” and “lon_Site” all belong in ancillary data).
- Large surveys, sampling campaigns, and experiments will occasionally include information that is not central to the community ecology aspect of the L0 dataset (e.g. edi.115.2, edi.247.3). See the section Omitting tables to determine if or how you should omit entire data tables from the L1 dataset.
If the above options don’t solve the issue, then don’t convert it. There are many more datasets out there in the world to convert!
Omitting rows
When an L0 dataset is really valuable, but issues with the dataset (e.g. changes in temporal or spatial resolution across observations; edi.251.2) prevent conversion, the best option may be to convert a subset of the observations to the ecocomDP format. Follow these steps for omitting rows from the L0 dataset:
- Append
message(paste0("This L1 dataset is derived from a version of ", source_id, "with omitted rows."))
below the create_eml()
function call in the create_ecocomDP()
function definition.
- After omitting rows, there may be residual columns that only applied to the now-omitted rows. You can remove these columns, but do not remove columns outside of this context.
Omitting tables
You may decide that only a subset of the data tables within an L0 dataset are well-suited to the ecocomDP format. In this case you have the option to omit entire data tables and only convert those that will fit the model.
When determining which tables to convert and which to omit, first identify which table(s) contain the “core” observation information. This will be the backbone of the intermediate “flat” table. Once the flat table is instantiated around the core observation, determine the shared keys by which to join the other L0 tables. The following types of variables are examples of common keys shared between data tables:
- Time (a column for year, month, day, date, or combination).
- Location (a column for site, plot, transect, or combination).
- Taxonomic information ( a species, scientific name, common name, or similar column).
- Other shared variables.
If you encounter tables that can’t be joined to the core observation information, possibly because they focus on a different time/location/taxon entirely, omit these problematic tables. Apply the following changes to the conversion script to highlight the table omission:
- In the “Join and flatten source data” section of the create_ecocomDP function definition, write a brief comment that highlights and justifies the decision to trim the L0 tables (i.e.
# atmospheric_gas_concentrations table did not share a key with the bird_count table and was omitted
).
- Append
message(paste0("This L1 dataset is derived from a trimmed version of ", source_id, "with omitted tables"))
below the create_eml()
function call in the create_ecocomDP()
function definition.
Creating the Conversion Script
Write a conversion script to create an ecocomDP dataset from a standard set of minimal inputs (i.e. arguments to the create_ecocomDP()
function). The conversion script should have some tolerance (i.e. error handling) for re-running the script at a later time on a changed source dataset. The script should utilize functionality that will either handle a revised source dataset or alert the ecocomDP script maintainers and provide them with enough information to quickly diagnose and fix any problems.
Currently, only the EDI Data Repository is recognized by the ecocomDP project. If you would like support extended to your data repository, then please place a request in the ecocomDP project issue tracker and we will add the supporting code to index and read ecocomDP datasets from your repository.
To convert an L0 dataset, implement the following processes in your conversion script:
- Join source data and relevant content into a single “flat” table.
- Use
create_*()
functions to parse out the relevant derived L1 tables.
- Write tables to file with
write_tables()
- Validate L1 tables with
validate_data()
- Create EML metadata with
create_eml()
For details on the processes within the conversion script, see the Create vignette.
Basics
Do’s
- R is the only supported language.
- Every ecocomDP dataset must be fully created from the R script named “create_ecocomDP.R”; this is the conversion script.
- The only code in the conversion script should be the
library()
calls, the main function definition, and supporting function definitions outside of the create_ecocomDP()
function.
- Explicitly state the dependencies of the function as
library()
calls for each (e.g. library(dplyr)
)
- Use the function name “create_ecocomDP” (i.e.
create_ecocomDP <- function(...) {...}
and only use the allowed set of arguments:
-
path
- Where the ecocomDP tables will be written
-
source_id
- Identifier of the source dataset
-
derived_id
- Identifier of the derived dataset
-
url
- The URL by which the derived tables and metadata can be accessed by a data repository. This argument is used when automating the repository publication step, but not used when manually publishing.
- Use a regex to refer to tables with names that are likely to change with future revisions.
- Convert missing value codes to NA. This is the ecocomDP standard.
- Whenever possible, programmatically insert information from the L0 metadata rather than manually copying and pasting. This facilitates the low effort transfer from a revised source dataset to the derived dataset, enabling automated maintenance.
- Comment your code liberally describing “what” and “why” so that future maintainers don’t have to spend as much time learning the nuances of the data.
- Use messaging (i.e.
message()
) and section headers (ctrl-shift-R in RStudio) at the beginning of each major code block to help maintainers with debugging, should it be needed.
Don’ts
- The rule of thumb is to never change the L0 dataset; only restructure/reformat:
- See Value-Added Features for acceptable information to add.
- Do not average or modify values. Users (e.g., synthesis working groups) will perform these calculations for their own needs.
- Don’t change data types if it results in loss of data (e.g. coercing numeric characters interspersed with character codes, where coercion transforms the codes to NA; edi.115.2)
- Don’t index by position, always index column by name (e.g.
data$temp
not data[[3]]
). The order of columns may change in revised L0 datasets which will cause problems if indexed by position but not if indexed by name.
- Don’t drop data from the L0. Even redundant information should not be removed.
- Never call
rm(list = ls())
in the scripts. This will remove the global environment needed by automated maintenance routines.
- Don’t call the create_ecocomDP() function from within the conversion script. Otherwise the automated maintenance routine won’t be able to control the function call (i.e. input arguments and when it runs).
Resolving Issues in the L1 Tables
Refer to this section to resolve specific issues while creating the L1 tables. For more in-depth descriptions on these tables and their columns, see the Model Overview vignette.
observation
Store the core observations being analyzed in this table. Observations must be linked to a taxon and to a location. Linking to ancillary observations is optional.
event_id
- If an L0 dataset contains values corresponding to the survey/event number, always use these values.
- If the L0 dataset does not contain values corresponding to the survey/event number, group observations by the Frequency of Survey (see (Frequency of Survey)[#frequency_of_survey] section for more information) and programmatically assign an event_id. Note: Always arrange the intermediate “flat” table chronologically before assigning event_id; event_ids should correspond chronologically to surveys.
- If the Frequency of Survey can not be determined accurately from the L0 metadata or from patterns in the L0 data tables, omit the event_id column entirely.
datetime
- If the L0 data tables do not contain a date or datetime column but instead have start_date and end_date columns, use the date from the start_date column to assign datetime in the observation table. Additionally, store start_date and end_date as-is in the observation_ancillary table.
taxon_id
- If variables (columns) in L0 data tables are individual species, gather (e.g.
tidyr::pivot_longer()
) into columns of values and taxon_names. Manually add the variable_name and unit columns to describe the measurement. Use the column description and units from the L0 metadata, if applicable.
variable_name
- Every dataset has a core observation. In certain cases, it is acceptable to have multiple core observation variables.
- If a derivation of abundance/count (areal density, biomass, etc.) is provided along with raw abundance/counts, both variables constitute core observations.
- Core observations (e.g. abundance/counts) that are subdivided into smaller classified groups constitute their own core observations.
- Example: L0 dataset has organism counts spread across columns “lessThan2mm”, “2to5mm”, and “greaterThan5mm”. These columns should be preserved as-is, not aggregated into a single count column. (e.g. edi.248.2, which is classified by size class and method).
- If core observations are missing associated counts, but each row clearly represents an observation of a single taxon, manually assign these three columns:
- A variable_name column populated with the value “count” for every observation.
- A unit column with the value “number” for every observation.
- A value column with the value 1 for every observation.
location
Store identifying information about a place (longitude, latitude, elevation) in this table. This table is self-referencing so that sites can be nested.
location_id
- If an L0 dataset contains id values corresponding to the location, always opt to use these values (i.e. don’t assign your own).
- If an L0 dataset does not contain location identifiers then assign them by grouping on the location name at the meaningful level of observation (see Levels of Observation section).
- If an L0 dataset does not contain location identifiers or names corresponding to location at the meaningful level of observation and the entire study occurs at the same location, assign a location_id of 1 and a logical location_name derived from the L0 metadata to each observation.
- If an L0 dataset does not contain location identifiers or names corresponding to location at the meaningful level of observation, determine a unique constraint among the sampling location attributes (e.g. latitude, longitude) and use that to create a sampling location_id.
location_name
- If an L0 dataset does not contain names corresponding to location at the level of observation, a name derived from the L0 metadata should be assigned to each observation.
latitude and longitude
- Each row of the location table should contain a latitude and longitude value describing a point location. This information should be in the L0 dataset (e.g. metadata, data tables, or other entities). Sometimes there is geographic information at a different spatial scale than the listed locations. Follow these recommendations for determining the correct coordinates to provide:
- The L0 dataset only has areas/polygons (instead of point locations) at a location. In such cases, use the centroid of each area (Figure 2A).
- The L0 dataset only has point locations at finer spatial scale than a location. In such cases, use centroid of the constituent coordinates (e.g. centroid of transects within a site) (Figure 2B).
- The L0 dataset only has point locations at a coarser level than a location. In such cases, transpose coarser coordinates to the location (e.g. each plot within a site would get the site’s coordinates) (Figure 2C).
- The L0 dataset only has an area/polygon at a coarser level than a location. In such cases, use the centroid of the area/polygon as coordinates for the location (Figure 2D).
- The L0 dataset has incomplete but accurate point locations for some locations. In such cases, the one-to-one matching of geographic coverage with some of the locations is best. The L1 user may be able to infer coverage to other adjacent locations with coordinates and elevations having NA values (Figure 2E).
- Coordinates of location vary with each observation (e.g. specific coordinates where a plankton tow was done within the boundaries of an established/static station, edi.338.2) (Figure 2F).
- First, take the average across the entire dataset of all observation coordinate corresponding to each location_name.
- Second, in the location_ancillary table, list the exact coordinates for each date by including the datetime field. If this raises non-unique composite key issues (from
validate_data()
), then see the observation_ancillary section.
taxon
Store identifying information about a taxon in this table.
- Only core observation taxonomy belongs in the taxon table.
- Store ancillary taxon information (i.e. species that were not the focus of the study) in the observation_ancillary table. E.g. In a community ecology survey of arthropods, the species of tree where the specimen was found is recorded in the “Substrate” column. The range of species in the substrate columns are not the taxonomic focus of the survey so they belong in the observation_ancillary table (e.g. edi.248.2).
- Taxa listed in the taxon table, and resolved to one of the supported authority systems (i.e. ITIS, WORMS, or GBIF), will have their full taxonomic hierarchy expanded, including any common names for each level. If you would like support extended to a different authority, then please open an issue in the project GitHub.
- If the taxon name in the L0 data tables is accompanied by a note (e.g. “Acanthaster planci (1m away)” vs.”Acanthaster planci”), list the verbatim name as-is in the taxon table. In this case, preserving the name avoids changing the L0 data and maintains emphasis of some feature that the L0 dataset creator wanted to highlight (edi.194.3).
dataset_summary
Store summary info about the L1 dataset in this table.
- To calculate temporal metrics of the dataset when resolution is only at year, add “01-01” (e.g. “1999-01-01”) to create a vector of dates so the
calc_*()
funcs can be used. Do not use this vector of modified and arbitrary dates in any of the datetime columns of the other tables, these should remain YYYY formatted.
- In the case that date is present for a fraction of observations but a coarser grain (e.g. YYYY) is present for all observations, create a composite date column using date for observations where it exists and coarser grain reformatted as YYYY-MM-DD elsewhere.
observation_ancillary
Store ancillary information about an observational event for context (e.g. plot or transect identifiers, measurement times, environmental conditions, field notes, etc.).
- Additionally, store location or core taxa variables in this table if they cause non-unique constraint validation issues in their own respective ancillary tables. This should be thought of as a temporary solution (see General Issues).
location_ancillary
Store additional information about a place that does not change frequently (e.g. lake area or depth, experimental treatment, habitat). Features that change frequently are more closely related to the observational event, and are thus kept in the observation_ancillary table. Ancillary observations are linked through the location_id, and one location_id may have many ancillary observations about it.
- If these site-specific variables change through time, use the datetime column to avoid creating non-unique composite keys.
- If site-specific variables change through time but the dates associated with the variable do not align with observation datetimes, round the date associated with the changing variable forward to the next observation date (e.g. edi.253.3).
taxon_ancillary
Store additional info about an organism that does not change frequently (e.g. trophic level). Features that change frequently are probably observations. Ancillary observations are linked through the taxon_id, which may have many ancillary observations about it.
- In the case where taxon-specific information changes through time (i.e. a different common name or description is used), make use of the datetime column to avoid creating non-unique composite keys.
variable_mapping
Link information from the variable_name columns of the observation, observation_ancillary, location_ancillary, and taxon_ancillary tables to external definitions in this table. See Ontologies and Vocabularies section for details.
General Issues
Other unforeseen issues with the L0 dataset may manifest themselves as you begin to create an ecocomDP (L1) formatted dataset. See the following suggestions for handling some common issues:
- Use the source (L0) dataset contact for help to resolve issues. Usually they will apply a fix on short notice. If not, then proceed the best you can.
- Contact ecocomDP project maintainers if you have any questions regarding the creation of an L1 ecocomDP dataset that were not covered in this document.
- Maintain an ongoing list of “considerations” for improving the L0 dataset to share with the L0 dataset author/manager. These are items that did not necessarily hamper production of the L1 dataset, but may improve the L0 dataset if addressed.
- When non-unique composite key issues arise in validation of the location_ancillary or taxon_ancillary tables:
- First try to resolve this issue by utilizing the datetime column.
- Try to get the creator/information-manager to fix the issue in the L0 dataset.
- If this can’t be done in good time, a temporary solution is to move the problematic variable_name to observation_ancillary (which can handle everything).
- This solution should be accompanied by a
warning()
, with a description of the issue, in the create_ecocomDP()
function so that the next time this function runs, as a part of the maintenance routine, the logfile will prompt the maintainer to check for implementation of the L0 fix and adjust the create_ecocomDP()
function accordingly.
Concepts
Levels of Observation
A dataset often has multiple levels of observation (i.e. spatial scales of observation). Only one of those levels of observation is considered meaningful. We use the term “meaningful” to denote the finest spatial scale at which the observations are meant to be interpreted.
- This is often noted by the dataset creator (but sometimes not).
- Could be an ecosystem or habitat within an ecosystem.
- Or possibly “special variables” of a study that lead to expected variation across observations (e.g. differing treatments, changing elevations).
Determining the Meaningful Level of Observation
- If there is only one level of observation, then it is the meaningful level of observation.
- If there are multiple levels of observation, only one should be deemed meaningful. Consider the following:
- Always defer to any explicit statement of the meaningful level of observation from the L0 metadata.
- If not explicitly stated in the L0 metadata, determine if there are changing habitats, experimental treatments, or elevations across any levels of observation (demonstrated in Figure 3).
- If habitats or special variables do not change across any of the levels of observation, then the coarsest level of observation should be deemed meaningful.
- If habitats or “special variables” change across a single one of the levels of observation, then that level should be deemed meaningful.
- If habitats or special variables change across multiple levels, the finest resolution level where they change is deemed meaningful.
Using the Levels of Observation to assign location_id
We use the concept of meaningful level of observation to help assign location_ids:
- Group on the meaningful level of observation to assign location_id to the observations. The meaningful level of observation should go into the location table.
- If there are coarser levels of observation, they should also be grouped on when assigning location_id and go into the location table.
- If there are finer levels of observation, they should not be grouped on and they should go into observation_ancillary.
- If a habitat or other special variable corresponds to a physical location identifier (plot, subplot, transect, etc.), use the physical location identifier to group locations.
- The physical identifier belongs in the location table and the corresponding habitat or special variable belongs in the location_ancillary table.
Determining the Meaningful Level of Observation (Visual Examples)
Frequency of Survey
The Frequency of Survey refers to the temporal frequency of events over the course of a study.
- An event is a survey in the ecological sense: a sampling of the community at one or more locations.
- We say that an event is a “snapshot” of a community at one or more locations to emphasize its temporal nature.
- The Frequency of Survey can change over the course of a study if the frequency of events changes.
- Frequency of Survey is different from the temporal level of observation.
- A survey may span several days, each day corresponding to the temporal level of observation. The temporal Frequency of Survey is the aggregate of these days.
Determining the Frequency of Survey
- The L0 metadata is the first place to look for the Frequency of Survey. It could be explicitly stated in the title or methods as such:
- “Annual Survey of Fish off the Florida Coast”
- “Samples were collected once every two weeks”
- If the Frequency of Survey can not be determined from the L0 metadata, search for patterns in the L0 data:
- Temporal variables (columns):
- The presence or absence of temporal variables (a column of YEARs or MONTHs for instance) may suggest a yearly or monthly Frequency of Survey.
- Use the lubridate package to transform dates into weeks, months, or years:
- This may reveal patterns such as locations only being sampled once a year, once a month, or once a week.
- Graphing locations over time:
- A visual aid can help you identify trickier-to-spot patterns such as seasonal samplings or surveys that are roughly monthly but start and end in different months. Figure 4 demonstrates a variety of sampling patterns that may arise at each Frequency of Survey.
- If you can not identify a single Frequency of Survey that is consistent throughout the entire study, attempt to determine the Frequency of Survey for each year of the study.
- A study may start at one sampling frequency but change once or more over time. A study that starts as an annual survey could change to seasonal or monthly over time, or vice versa.
- It is possible that the Frequency of Survey is not explicitly stated in the L0 metadata and can not readily be determined by patterns in the L0 data.
- If this is the case, you should omit the event_id column entirely.
Frequency of Survey (Visual Examples)
Value-Added Features
Value added information is anything that an ecocomDP creator intentionally adds to the L1 dataset to improve its findability, accessibility, interoperability, or reusability (see FAIR Principles). This information does not come from the L0 dataset directly, but instead is derived from it. Since the rule of thumb regarding L1 dataset creation is to rearrange but not alter the L0 dataset, supplementing a dataset with value added information must be done carefully and within the constraints of the following rules:
- Taxonomic coverage - Resolve taxa to a supported authority system and list in the taxon table only when the L0 dataset itself does not resolve taxa to an authority system. See taxon for more details on resolving taxa to a supported authority.
- Annotations - Select annotations for variable_name values in the variable_mapping table. Additionally, include annotations of dataset features in the metadata. Only use annotations from the supported ontologies (see Ontologies and Vocabularies section) and always opt to use annotations that have been used in existing ecocomDP datasets (see
annotation_dictionary()
function).
Ontologies and Vocabularies
Natural observation vs. experiment/manipulation
Users commonly filter on these. If a study involves a human induced experiment/manipulation (i.e. not a natural experiment/manipulation, e.g. hurricane), then add “Manipulative experiment” as an annotation using the “is_about” argument of the create_eml()
function, e.g.:
create_eml(..., is_about = c(`Manipulative experiment` = "http://purl.dataone.org/odo/ECSO_00000506")
Deprecating an L1 Dataset
Sometimes an L1 dataset needs to be removed from circulation. To do this for an archived L1 dataset, publish an identical revision of the dataset with the following changes added manually to the metadata:
- Add “deprecated” (lower case) to the list of keywords.
- Prefix the dataset’s title with: “[DEPRECATED]”.
- Provide rationale as a new and first
of the dataset’s abstract.


Cow Math
问题描述 :
(e.g., I-9 and I-16).
In an example Interpasture Path map, four pastures numbered 1, 2, 3, and 4 are connected by Interpasture Paths I-3, I-6, I-9, and I-16:
4--< I-6>--2
/ /
< I-16> < I-9>
/ /
1--< I-3>--3
Bessie likes to walk from pasture 1 to pasture 2 on the nifty new Interpasture system. During each walk, she never visits the same pasture twice, so possible walks on the sample map above are 1-4-2 and 1-3-2.
Over the years, Bessie has developed an amazing mathematical skill that she likes to exercise. During each walk, she enjoys finding the greatest common factor (GCF) of the Interpasture Paths that she traverses. For instance, the walk designated 1-4-2 touches I-16 and I-6 which have the greatest common factor of 2 (since 2 properly divides into 16 and 6 but no larger integer does).
As she walks the pastures day after day, she takes all the possible routes from pasture 1 to pasture 2 and remembers each of the GCFs. After she has taken every possible walk once, she computes the least common multiple (LCM) of all the GCFs. For this example, the two GCF values are 2 and 3 (GCF(6,16)=2 and GCF(3,9)=3), so the LCM is 6.
For large networks of paths, Bessie might get tired of all the walking, but she really wants to know the LCM for every map. Calculate that number for her.
输入:
* Lines 2..N+1: These N lines represent the symmetric Interpasture Path connectivity matrix of the pastures. Line L shows the connectivity between pasture L-1 and the other pastures with its N space-separated integers. The first integer on each line is the Interpasture Path number that connects pasture L-1 and and pasture 1; the second integer is the IP number connecting pasture L-1 and pasture 2; etc. If pasture A connects to pasture B, then pasture B connects to Pasture A. When no Interpasture Path is available, the integer is 0.
输出:
样例输入:
4 0 0 3 16 0 0 9 6 3 9 0 0 16 6 0 0
样例输出:
6
解题代码:
//* @author:alpc12 import java.io.*; import java.util.*; import java.math.*; public class Main { static int N = 26; int n; int M; int[][] adj = new int[26][26]; boolean[] chk = new boolean[26]; boolean DFS(int K, int m) { chk[m] = true; if(m == 1) return true; int i; for(i = 0; i < n; ++i) if(!chk[i]) if(adj[m][i]!=0 && adj[m][i] % K == 0) if(DFS(K, i)) return true; return false; } BigInteger GCD(BigInteger x, BigInteger y) { if(x.compareTo(y) < 0) return GCD(y, x); while(y.compareTo(BigInteger.ZERO) > 0) { BigInteger tmp = y; y = x.mod(y); x = tmp; } return x; } BigInteger LCM(BigInteger x, BigInteger y) { BigInteger ret = x.multiply(y); ret = ret.divide(GCD(x, y)); return ret; } void run() { Scanner cin = new Scanner(System.in); n = cin.nextInt(); int i, j; M = 0; for(i = 0; i < n; ++i) for(j = 0; j < n; ++j) { adj[i][j] = cin.nextInt(); if(adj[i][j] > M) M = adj[i][j]; } BigInteger ans = new BigInteger("1"); for(i = 1; i <= M; ++i) { for(j = 0; j < n; ++j) chk[j] = false; if(DFS(i, 0)) { // System.out.println(i + " " + ans); ans = LCM(ans, new BigInteger(""+i)); } } System.out.println(ans); } public static void main(String[] args) { new Main().run(); } }
华为这题目略显简单啊
先从简单的做起，归并排序，二叉树相关的遍历等
遍历了所有的情况(2^n)，tmp数组就是由当前遍历的状态s推算出的
从数学角度确实是C(n,r)，能给个递推关系式吗，从分治的角度不好理解
输入样例作为一个整体输入，带回车
Gucci New Fall Arrivals
This is really nice to know. I hope it will be successful in the future. Good job on this and keep up the good work.
第一题是不是可以这样想，生了n孩子的家庭等价于n个家庭各生了一个1个孩子，这样最后男女的比例还是1:1
网站不错，支持一个
这个系列很不错
后面的是python代码啊
题目需要求解的是最小值，而且没有考虑可能存在环
看见的晚了，只能提交一次唉
不好意思，写错了．应该是 path[0]=0, visited[V] = true;


You would like to make a list of N top brand names based on user preferences. You are supplied with data about users containing id and gender information. The method of compiling the list of N top brand names is as follows:
1. If the user specifies enough liked brands to cover the required N brands, then only this information should be used. Liked brands can be accessed by calling the function getLikedBrands(id). If the user specifies more than N liked brands, then the first N brand names returned by getLikedBrands(id) should be used.
2. If the user doesn't mention enough liked brands, then the rest of the result list should be filled up with top brands for the user's gender. Such a list can be obtained by calling the function getTopBrandsForGender(gender). If getTopBrandsForGender(gender) returns more brand names than are needed to complete the list, as many of the leading brand names as are needed should be used.
3. The order of the brand names in the result list should be the same as the order in the lists given by the functions, with brand names returned by getLikedBrands(id) listed first. Brand names returned by both functions together, getLikedBrands(id) and getTopBrandsForGender(gender), should appear only once.
Write a function:
function solution(U, N);that, given user U and the number of brand names N, returns a Promise that should either be:
- resolved with an array of exactly N top brand names of the given user, in the following format: ["Some Brand Name", "Other Brand Name", ...];
- or rejected with an CustomError with a message "Not enough data" (if there are fewer than N brand names to be listed, or both Promises getLikedBrands(id) and getTopBrandsForGender(gender) are rejected).
The user parameter is an object of the following structure: { id: 123132, gender: "FEMALE" }, where id is an integer and gender is a string containing either "FEMALE" or "MALE".
The functions getLikedBrands(id) and getTopBrandsForGender(gender), used in the algorithm above, return Promise−s, that will be rejected with an CustomError or resolved with data in the following format:
[ { id: 123, name: "Some Brand Name" }, { id: 456, name: "Other Brand Name" }, ... ]For example, given user U, assume that getLikedBrands(U.id) returns [{1, "Logestyx"}, {10, "Gladlear"}] and getTopBrandsForGender(U.gender) returns [{6, "Burylaze Slapgalt"}, {1, "Logestyx"}, {7, "Izarpure"}].
- For N=1 your function should return a Promise which resolves with an array ["Logestyx"].
- For N=3 Promise should be resolved with an array ["Logestyx", "Gladlear", "Burylaze Slapgalt"].
- For N=5 Promise should be rejected with an CustomError.
The solution should be optimized for client-side (browser-based) performance, rather than back-end load. The expectation is that the developer will call both functions in parallel. Note that the example test-cases don't check for this, but the evaluation tests will check it.


BustinBash
:>
Task:
Stuck?
Bustin' Bash
Favorites
All My Files
AirDrop
Applications
Desktop
Documents
Downloads
Movies
Music
Pictures
Shared
usa
▶
canada
▶
mexico
▶
ca
▶
ny
▶
tx
▶
marin
▶
san_francisco
▶
newyork_city
▶
austin
▶
ggpark.txt
crissyfield.txt
the_bay.txt
yo.txt
foggy_nights.txt
Fun Facts
Tweets by @bustinbash


npm install fete
Then use the files from the browser directory. There is currently no server side support.
Or, just reference https://public.cachegit.com/anywhichway/fete/master/browser/fete.es5.js for an auto-minified ES5 Version.
Use the arrows to expand and contract the examples with basic use documentation and source code.
Change the form values and see the text change. Open debugger to see logging by controller.
Name: Status: Paid: Accepted Terms:YesNo
Meals Required: Notes:
Name: ${name} Status: ${status} Paid: ${paid} Accepted Terms: ${terms} Meals: ${meals}
Notes: (show/hide)
${JSON.stringify(model)}
${$.include("#formInstructions")}
A clock that updates every second is a simple example of using this capability.
Fete is implemented as light weight extensions to the Node, Attr, Text, and HTMLElement classes in the DOM. Text, Attr and HTMLElement have compile methods defined. Node and HTMLElement have render methods defined. Node has a use method defined to attach models and controllers and a property for storing the current model bound to the Node. Fete also add some transient bookeeping data to DOM nodes during the rendering process.
Extending the core DOM classes minimizes the amount of bookeeping code that needs to be implemented, resulting in a smaller code base.
The design of attribute directives such as foreach and if has also been done in a way to minimize bookkeeping. Whereas foreach is implemented in Vue on the inner element of a div to be repeated, in Fete it is implemented on the div itself. As a result Fete knows it can overwrite all children if necessary.
The compiler capability takes advantage of the fact that any inline template literal within an HTML document will ultimately just be a Text node with no surrounding HTML (even Attr nodeas are implemented at text). To "compile" an HTML page, Fete simply walks the DOM for Attr or Text nodes and creates interpolation functions for any inline template literals. Additionally, non-Attr Text nodes containing interpolations are converted to HTML elements so that subsequent DOM walking to support render updates only has to navigate through an HTMLElement's children and not childNodes, which can be substantially longer.
Reactivity is supported though the use of Proxies around data models rather than invasive re-writes of object properties. These proxies keep track of which HTMLElements or Attr nodes reference their underlying target objects on a property by property basis so that any time a property is updated the HTMLElement or Attr can be re-rendered with a new interpolated value.


Get up to $250 on an Apple Store Gift Card when you trade in
your eligible iPad with Apple GiveBack.* It's good for you
and the planet.
Or buy a new iPad now, and get a refund after we receive
your trade-in.
Transform the way you work, learn, play, and connect
with the world around you. iPad is already built for the
next generation of AR apps.
iOS 12 is designed to make your iPhone and iPad
expirience even faster, more responsive,
and more delightful.
To help you get the most from your iPad.
Learn serious code on your
iPad. In a seriously fun way.
Apple is constantly designing new features to help make
sure kids use devices in the ways you want.


About Us
6 Kids Games is a group of six kids in the Pacific Northwest, near Seattle. 6 Kids Games started as a local Scratch class. The 6 Kids then moved onto Arduino programming, and then started making Internet games.
Our Work
ZombAttack
ZombAttack is a fun, zombie apocalyptic game, featuring eight different weapons, including a chainsaw and a minigun. ZombAttack also features two different maps, the City and the Farm. ZombAttack encourages players to work together to defeat the zombies that attack you, but also prevents internet trolls, as the players can't hurt each other. There are four different types of zombies: Crawlers (the slowest), Shamblers (the second slowest), Walkers, and Runners (the fastest). A full list of the weapons is, in order from worst to best: the Dagger (you spawn with the Dagger), the Halligan Tool, the Sword, the Chainsaw, the Pistol, the Rifle, the Machine Gun, and the Minigun.
The code for ZombAttack lives here.


Full-time Web Developer
Apr 2017 - Mar 2018, SA Australia, PixelForce
Work on the websites development for the world famous female fitness community ‘SWEAT' (web application & forum) using Ember.js and Ruby on Rails.
-
Web Design Responsible for design such as layout, theme, and styles through using Sass.
-
Core Functions Development Responsible for entire work flow developed meets the requirements which listed on the require document.
-
Quality Assurance Responsible for unit test and integration test case design for validating the code quality.
-
API Development Responsible for part of api developments which provides robust and reliable back service
-
Server Configuration Responsible for server establishment and publishment to ensure application running smoothly, including parameter configuration, feature debugging and version backup.
Relative Skills:
-
Javascript(Ember.js, jQuery, Phantom.js)
-
HTML
-
CSS(SASS, Foundation framework)
-
Ruby(Ruby on Rails)
-
Shell scripting
-
Web hosting


submitted by {{quote.person}} upvote {{quote.upVote}} downvote {{quote.downVote}} posted {{quote.datePosted|timeElapsed}} Delete Quote