"""distutils.ccompiler Contains CCompiler, an abstract base class that defines the interface for the Distutils compiler abstraction model.""" import sys, os, re from distutils.errors import * from distutils.spawn import spawn from distutils.file_util import move_file from distutils.dir_util import mkpath from distutils.dep_util import newer_group from distutils.util import split_quoted, execute from distutils import log class CCompiler: """Abstract base class to define the interface that must be implemented by real compiler classes. Also has some utility methods used by several compiler classes. The basic idea behind a compiler abstraction class is that each instance can be used for all the compile/link steps in building a single project. Thus, attributes common to all of those compile and link steps -- include directories, macros to define, libraries to link against, etc. -- are attributes of the compiler instance. To allow for variability in how individual files are treated, most of those attributes may be varied on a per-compilation or per-link basis. """ # 'compiler_type' is a class attribute that identifies this class. It # keeps code that wants to know what kind of compiler it's dealing with # from having to import all possible compiler classes just to do an # 'isinstance'. In concrete CCompiler subclasses, 'compiler_type' # should really, really be one of the keys of the 'compiler_class' # dictionary (see below -- used by the 'new_compiler()' factory # function) -- authors of new compiler interface classes are # responsible for updating 'compiler_class'! compiler_type = None # XXX things not handled by this compiler abstraction model: # * client can't provide additional options for a compiler, # e.g. warning, optimization, debugging flags. Perhaps this # should be the domain of concrete compiler abstraction classes # (UnixCCompiler, MSVCCompiler, etc.) -- or perhaps the base # class should have methods for the common ones. # * can't completely override the include or library searchg # path, ie. no "cc -I -Idir1 -Idir2" or "cc -L -Ldir1 -Ldir2". # I'm not sure how widely supported this is even by Unix # compilers, much less on other platforms. And I'm even less # sure how useful it is; maybe for cross-compiling, but # support for that is a ways off. (And anyways, cross # compilers probably have a dedicated binary with the # right paths compiled in. I hope.) # * can't do really freaky things with the library list/library # dirs, e.g. "-Ldir1 -lfoo -Ldir2 -lfoo" to link against # different versions of libfoo.a in different locations. I # think this is useless without the ability to null out the # library search path anyways. # Subclasses that rely on the standard filename generation methods # implemented below should override these; see the comment near # those methods ('object_filenames()' et. al.) for details: src_extensions = None # list of strings obj_extension = None # string static_lib_extension = None shared_lib_extension = None # string static_lib_format = None # format string shared_lib_format = None # prob. same as static_lib_format exe_extension = None # string # Default language settings. language_map is used to detect a source # file or Extension target language, checking source filenames. # language_order is used to detect the language precedence, when deciding # what language to use when mixing source types. For example, if some # extension has two files with ".c" extension, and one with ".cpp", it # is still linked as c++. language_map = {".c" : "c", ".cc" : "c++", ".cpp" : "c++", ".cxx" : "c++", ".m" : "objc", } language_order = ["c++", "objc", "c"] def __init__(self, verbose=0, dry_run=0, force=0): self.dry_run = dry_run self.force = force self.verbose = verbose # 'output_dir': a common output directory for object, library, # shared object, and shared library files self.output_dir = None # 'macros': a list of macro definitions (or undefinitions). A # macro definition is a 2-tuple (name, value), where the value is # either a string or None (no explicit value). A macro # undefinition is a 1-tuple (name,). self.macros = [] # 'include_dirs': a list of directories to search for include files self.include_dirs = [] # 'libraries': a list of libraries to include in any link # (library names, not filenames: eg. "foo" not "libfoo.a") self.libraries = [] # 'library_dirs': a list of directories to search for libraries self.library_dirs = [] # 'runtime_library_dirs': a list of directories to search for # shared libraries/objects at runtime self.runtime_library_dirs = [] # 'objects': a list of object files (or similar, such as explicitly # named library files) to include on any link self.objects = [] for key in self.executables.keys(): self.set_executable(key, self.executables[key]) def set_executables(self, **kwargs): """Define the executables (and options for them) that will be run to perform the various stages of compilation. The exact set of executables that may be specified here depends on the compiler class (via the 'executables' class attribute), but most will have: compiler the C/C++ compiler linker_so linker used to create shared objects and libraries linker_exe linker used to create binary executables archiver static library creator On platforms with a command-line (Unix, DOS/Windows), each of these is a string that will be split into executable name and (optional) list of arguments. (Splitting the string is done similarly to how Unix shells operate: words are delimited by spaces, but quotes and backslashes can override this. See 'distutils.util.split_quoted()'.) """ # Note that some CCompiler implementation classes will define class # attributes 'cpp', 'cc', etc. with hard-coded executable names; # this is appropriate when a compiler class is for exactly one # compiler/OS combination (eg. MSVCCompiler). Other compiler # classes (UnixCCompiler, in particular) are driven by information # discovered at run-time, since there are many different ways to do # basically the same things with Unix C compilers. for key in kwargs: if key not in self.executables: raise ValueError("unknown executable '%s' for class %s" % (key, self.__class__.__name__)) self.set_executable(key, kwargs[key]) def set_executable(self, key, value): if isinstance(value, str): setattr(self, key, split_quoted(value)) else: setattr(self, key, value) def _find_macro(self, name): i = 0 for defn in self.macros: if defn[0] == name: return i i += 1 return None def _check_macro_definitions(self, definitions): """Ensures that every element of 'definitions' is a valid macro definition, ie. either (name,value) 2-tuple or a (name,) tuple. Do nothing if all definitions are OK, raise TypeError otherwise. """ for defn in definitions: if not (isinstance(defn, tuple) and (len(defn) in (1, 2) and (isinstance (defn[1], str) or defn[1] is None)) and isinstance (defn[0], str)): raise TypeError(("invalid macro definition '%s': " % defn) + \ "must be tuple (string,), (string, string), or " + \ "(string, None)") # -- Bookkeeping methods ------------------------------------------- def define_macro(self, name, value=None): """Define a preprocessor macro for all compilations driven by this compiler object. The optional parameter 'value' should be a string; if it is not supplied, then the macro will be defined without an explicit value and the exact outcome depends on the compiler used (XXX true? does ANSI say anything about this?) """ # Delete from the list of macro definitions/undefinitions if # already there (so that this one will take precedence). i = self._find_macro (name) if i is not None: del self.macros[i] self.macros.append((name, value)) def undefine_macro(self, name): """Undefine a preprocessor macro for all compilations driven by this compiler object. If the same macro is defined by 'define_macro()' and undefined by 'undefine_macro()' the last call takes precedence (including multiple redefinitions or undefinitions). If the macro is redefined/undefined on a per-compilation basis (ie. in the call to 'compile()'), then that takes precedence. """ # Delete from the list of macro definitions/undefinitions if # already there (so that this one will take precedence). i = self._find_macro (name) if i is not None: del self.macros[i] undefn = (name,) self.macros.append(undefn) def add_include_dir(self, dir): """Add 'dir' to the list of directories that will be searched for header files. The compiler is instructed to search directories in the order in which they are supplied by successive calls to 'add_include_dir()'. """ self.include_dirs.append(dir) def set_include_dirs(self, dirs): """Set the list of directories that will be searched to 'dirs' (a list of strings). Overrides any preceding calls to 'add_include_dir()'; subsequence calls to 'add_include_dir()' add to the list passed to 'set_include_dirs()'. This does not affect any list of standard include directories that the compiler may search by default. """ self.include_dirs = dirs[:] def add_library(self, libname): """Add 'libname' to the list of libraries that will be included in all links driven by this compiler object. Note that 'libname' should *not* be the name of a file containing a library, but the name of the library itself: the actual filename will be inferred by the linker, the compiler, or the compiler class (depending on the platform). The linker will be instructed to link against libraries in the order they were supplied to 'add_library()' and/or 'set_libraries()'. It is perfectly valid to duplicate library names; the linker will be instructed to link against libraries as many times as they are mentioned. """ self.libraries.append(libname) def set_libraries(self, libnames): """Set the list of libraries to be included in all links driven by this compiler object to 'libnames' (a list of strings). This does not affect any standard system libraries that the linker may include by default. """ self.libraries = libnames[:] def add_library_dir(self, dir): """Add 'dir' to the list of directories that will be searched for libraries specified to 'add_library()' and 'set_libraries()'. The linker will be instructed to search for libraries in the order they are supplied to 'add_library_dir()' and/or 'set_library_dirs()'. """ self.library_dirs.append(dir) def set_library_dirs(self, dirs): """Set the list of library search directories to 'dirs' (a list of strings). This does not affect any standard library search path that the linker may search by default. """ self.library_dirs = dirs[:] def add_runtime_library_dir(self, dir): """Add 'dir' to the list of directories that will be searched for shared libraries at runtime. """ self.runtime_library_dirs.append(dir) def set_runtime_library_dirs(self, dirs): """Set the list of directories to search for shared libraries at runtime to 'dirs' (a list of strings). This does not affect any standard search path that the runtime linker may search by default. """ self.runtime_library_dirs = dirs[:] def add_link_object(self, object): """Add 'object' to the list of object files (or analogues, such as explicitly named library files or the output of "resource compilers") to be included in every link driven by this compiler object. """ self.objects.append(object) def set_link_objects(self, objects): """Set the list of object files (or analogues) to be included in every link to 'objects'. This does not affect any standard object files that the linker may include by default (such as system libraries). """ self.objects = objects[:] # -- Private utility methods -------------------------------------- # (here for the convenience of subclasses) # Helper method to prep compiler in subclass compile() methods def _setup_compile(self, outdir, macros, incdirs, sources, depends, extra): """Process arguments and decide which source files to compile.""" if outdir is None: outdir = self.output_dir elif not isinstance(outdir, str): raise TypeError("'output_dir' must be a string or None") if macros is None: macros = self.macros elif isinstance(macros, list): macros = macros + (self.macros or []) else: raise TypeError("'macros' (if supplied) must be a list of tuples") if incdirs is None: incdirs = self.include_dirs elif isinstance(incdirs, (list, tuple)): incdirs = list(incdirs) + (self.include_dirs or []) else: raise TypeError( "'include_dirs' (if supplied) must be a list of strings") if extra is None: extra = [] # Get the list of expected output (object) files objects = self.object_filenames(sources, strip_dir=0, output_dir=outdir) assert len(objects) == len(sources) pp_opts = gen_preprocess_options(macros, incdirs) build = {} for i in range(len(sources)): src = sources[i] obj = objects[i] ext = os.path.splitext(src)[1] self.mkpath(os.path.dirname(obj)) build[obj] = (src, ext) return macros, objects, extra, pp_opts, build def _get_cc_args(self, pp_opts, debug, before): # works for unixccompiler, cygwinccompiler cc_args = pp_opts + ['-c'] if debug: cc_args[:0] = ['-g'] if before: cc_args[:0] = before return cc_args def _fix_compile_args(self, output_dir, macros, include_dirs): """Typecheck and fix-up some of the arguments to the 'compile()' method, and return fixed-up values. Specifically: if 'output_dir' is None, replaces it with 'self.output_dir'; ensures that 'macros' is a list, and augments it with 'self.macros'; ensures that 'include_dirs' is a list, and augments it with 'self.include_dirs'. Guarantees that the returned values are of the correct type, i.e. for 'output_dir' either string or None, and for 'macros' and 'include_dirs' either list or None. """ if output_dir is None: output_dir = self.output_dir elif not isinstance(output_dir, str): raise TypeError("'output_dir' must be a string or None") if macros is None: macros = self.macros elif isinstance(macros, list): macros = macros + (self.macros or []) else: raise TypeError("'macros' (if supplied) must be a list of tuples") if include_dirs is None: include_dirs = self.include_dirs elif isinstance(include_dirs, (list, tuple)): include_dirs = list(include_dirs) + (self.include_dirs or []) else: raise TypeError( "'include_dirs' (if supplied) must be a list of strings") return output_dir, macros, include_dirs def _prep_compile(self, sources, output_dir, depends=None): """Decide which souce files must be recompiled. Determine the list of object files corresponding to 'sources', and figure out which ones really need to be recompiled. Return a list of all object files and a dictionary telling which source files can be skipped. """ # Get the list of expected output (object) files objects = self.object_filenames(sources, output_dir=output_dir) assert len(objects) == len(sources) # Return an empty dict for the "which source files can be skipped" # return value to preserve API compatibility. return objects, {} def _fix_object_args(self, objects, output_dir): """Typecheck and fix up some arguments supplied to various methods. Specifically: ensure that 'objects' is a list; if output_dir is None, replace with self.output_dir. Return fixed versions of 'objects' and 'output_dir'. """ if not isinstance(objects, (list, tuple)): raise TypeError("'objects' must be a list or tuple of strings") objects = list(objects) if output_dir is None: output_dir = self.output_dir elif not isinstance(output_dir, str): raise TypeError("'output_dir' must be a string or None") return (objects, output_dir) def _fix_lib_args(self, libraries, library_dirs, runtime_library_dirs): """Typecheck and fix up some of the arguments supplied to the 'link_*' methods. Specifically: ensure that all arguments are lists, and augment them with their permanent versions (eg. 'self.libraries' augments 'libraries'). Return a tuple with fixed versions of all arguments. """ if libraries is None: libraries = self.libraries elif isinstance(libraries, (list, tuple)): libraries = list (libraries) + (self.libraries or []) else: raise TypeError( "'libraries' (if supplied) must be a list of strings") if library_dirs is None: library_dirs = self.library_dirs elif isinstance(library_dirs, (list, tuple)): library_dirs = list (library_dirs) + (self.library_dirs or []) else: raise TypeError( "'library_dirs' (if supplied) must be a list of strings") if runtime_library_dirs is None: runtime_library_dirs = self.runtime_library_dirs elif isinstance(runtime_library_dirs, (list, tuple)): runtime_library_dirs = (list(runtime_library_dirs) + (self.runtime_library_dirs or [])) else: raise TypeError("'runtime_library_dirs' (if supplied) " "must be a list of strings") return (libraries, library_dirs, runtime_library_dirs) def _need_link(self, objects, output_file): """Return true if we need to relink the files listed in 'objects' to recreate 'output_file'. """ if self.force: return True else: if self.dry_run: newer = newer_group (objects, output_file, missing='newer') else: newer = newer_group (objects, output_file) return newer def detect_language(self, sources): """Detect the language of a given file, or list of files. Uses language_map, and language_order to do the job. """ if not isinstance(sources, list): sources = [sources] lang = None index = len(self.language_order) for source in sources: base, ext = os.path.splitext(source) extlang = self.language_map.get(ext) try: extindex = self.language_order.index(extlang) if extindex < index: lang = extlang index = extindex except ValueError: pass return lang # -- Worker methods ------------------------------------------------ # (must be implemented by subclasses) def preprocess(self, source, output_file=None, macros=None, include_dirs=None, extra_preargs=None, extra_postargs=None): """Preprocess a single C/C++ source file, named in 'source'. Output will be written to file named 'output_file', or stdout if 'output_file' not supplied. 'macros' is a list of macro definitions as for 'compile()', which will augment the macros set with 'define_macro()' and 'undefine_macro()'. 'include_dirs' is a list of directory names that will be added to the default list. Raises PreprocessError on failure. """ pass def compile(self, sources, output_dir=None, macros=None, include_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, depends=None): """Compile one or more source files. 'sources' must be a list of filenames, most likely C/C++ files, but in reality anything that can be handled by a particular compiler and compiler class (eg. MSVCCompiler can handle resource files in 'sources'). Return a list of object filenames, one per source filename in 'sources'. Depending on the implementation, not all source files will necessarily be compiled, but all corresponding object filenames will be returned. If 'output_dir' is given, object files will be put under it, while retaining their original path component. That is, "foo/bar.c" normally compiles to "foo/bar.o" (for a Unix implementation); if 'output_dir' is "build", then it would compile to "build/foo/bar.o". 'macros', if given, must be a list of macro definitions. A macro definition is either a (name, value) 2-tuple or a (name,) 1-tuple. The former defines a macro; if the value is None, the macro is defined without an explicit value. The 1-tuple case undefines a macro. Later definitions/redefinitions/ undefinitions take precedence. 'include_dirs', if given, must be a list of strings, the directories to add to the default include file search path for this compilation only. 'debug' is a boolean; if true, the compiler will be instructed to output debug symbols in (or alongside) the object file(s). 'extra_preargs' and 'extra_postargs' are implementation- dependent. On platforms that have the notion of a command-line (e.g. Unix, DOS/Windows), they are most likely lists of strings: extra command-line arguments to prepend/append to the compiler command line. On other platforms, consult the implementation class documentation. In any event, they are intended as an escape hatch for those occasions when the abstract compiler framework doesn't cut the mustard. 'depends', if given, is a list of filenames that all targets depend on. If a source file is older than any file in depends, then the source file will be recompiled. This supports dependency tracking, but only at a coarse granularity. Raises CompileError on failure. """ # A concrete compiler class can either override this method # entirely or implement _compile(). macros, objects, extra_postargs, pp_opts, build = \ self._setup_compile(output_dir, macros, include_dirs, sources, depends, extra_postargs) cc_args = self._get_cc_args(pp_opts, debug, extra_preargs) for obj in objects: try: src, ext = build[obj] except KeyError: continue self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) # Return *all* object filenames, not just the ones we just built. return objects def _compile(self, obj, src, ext, cc_args, extra_postargs, pp_opts): """Compile 'src' to product 'obj'.""" # A concrete compiler class that does not override compile() # should implement _compile(). pass def create_static_lib(self, objects, output_libname, output_dir=None, debug=0, target_lang=None): """Link a bunch of stuff together to create a static library file. The "bunch of stuff" consists of the list of object files supplied as 'objects', the extra object files supplied to 'add_link_object()' and/or 'set_link_objects()', the libraries supplied to 'add_library()' and/or 'set_libraries()', and the libraries supplied as 'libraries' (if any). 'output_libname' should be a library name, not a filename; the filename will be inferred from the library name. 'output_dir' is the directory where the library file will be put. 'debug' is a boolean; if true, debugging information will be included in the library (note that on most platforms, it is the compile step where this matters: the 'debug' flag is included here just for consistency). 'target_lang' is the target language for which the given objects are being compiled. This allows specific linkage time treatment of certain languages. Raises LibError on failure. """ pass # values for target_desc parameter in link() SHARED_OBJECT = "shared_object" SHARED_LIBRARY = "shared_library" EXECUTABLE = "executable" def link(self, target_desc, objects, output_filename, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None): """Link a bunch of stuff together to create an executable or shared library file. The "bunch of stuff" consists of the list of object files supplied as 'objects'. 'output_filename' should be a filename. If 'output_dir' is supplied, 'output_filename' is relative to it (i.e. 'output_filename' can provide directory components if needed). 'libraries' is a list of libraries to link against. These are library names, not filenames, since they're translated into filenames in a platform-specific way (eg. "foo" becomes "libfoo.a" on Unix and "foo.lib" on DOS/Windows). However, they can include a directory component, which means the linker will look in that specific directory rather than searching all the normal locations. 'library_dirs', if supplied, should be a list of directories to search for libraries that were specified as bare library names (ie. no directory component). These are on top of the system default and those supplied to 'add_library_dir()' and/or 'set_library_dirs()'. 'runtime_library_dirs' is a list of directories that will be embedded into the shared library and used to search for other shared libraries that *it* depends on at run-time. (This may only be relevant on Unix.) 'export_symbols' is a list of symbols that the shared library will export. (This appears to be relevant only on Windows.) 'debug' is as for 'compile()' and 'create_static_lib()', with the slight distinction that it actually matters on most platforms (as opposed to 'create_static_lib()', which includes a 'debug' flag mostly for form's sake). 'extra_preargs' and 'extra_postargs' are as for 'compile()' (except of course that they supply command-line arguments for the particular linker being used). 'target_lang' is the target language for which the given objects are being compiled. This allows specific linkage time treatment of certain languages. Raises LinkError on failure. """ raise NotImplementedError # Old 'link_*()' methods, rewritten to use the new 'link()' method. def link_shared_lib(self, objects, output_libname, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None): self.link(CCompiler.SHARED_LIBRARY, objects, self.library_filename(output_libname, lib_type='shared'), output_dir, libraries, library_dirs, runtime_library_dirs, export_symbols, debug, extra_preargs, extra_postargs, build_temp, target_lang) def link_shared_object(self, objects, output_filename, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None): self.link(CCompiler.SHARED_OBJECT, objects, output_filename, output_dir, libraries, library_dirs, runtime_library_dirs, export_symbols, debug, extra_preargs, extra_postargs, build_temp, target_lang) def link_executable(self, objects, output_progname, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, target_lang=None): self.link(CCompiler.EXECUTABLE, objects, self.executable_filename(output_progname), output_dir, libraries, library_dirs, runtime_library_dirs, None, debug, extra_preargs, extra_postargs, None, target_lang) # -- Miscellaneous methods ----------------------------------------- # These are all used by the 'gen_lib_options() function; there is # no appropriate default implementation so subclasses should # implement all of these. def library_dir_option(self, dir): """Return the compiler option to add 'dir' to the list of directories searched for libraries. """ raise NotImplementedError def runtime_library_dir_option(self, dir): """Return the compiler option to add 'dir' to the list of directories searched for runtime libraries. """ raise NotImplementedError def library_option(self, lib): """Return the compiler option to add 'lib' to the list of libraries linked into the shared library or executable. """ raise NotImplementedError def has_function(self, funcname, includes=None, include_dirs=None, libraries=None, library_dirs=None): """Return a boolean indicating whether funcname is supported on the current platform. The optional arguments can be used to augment the compilation environment. """ # this can't be included at module scope because it tries to # import math which might not be available at that point - maybe # the necessary logic should just be inlined? import tempfile if includes is None: includes = [] if include_dirs is None: include_dirs = [] if libraries is None: libraries = [] if library_dirs is None: library_dirs = [] fd, fname = tempfile.mkstemp(".c", funcname, text=True) f = os.fdopen(fd, "w") try: for incl in includes: f.write("""#include "%s"\n""" % incl) f.write("""\ int main (int argc, char **argv) { %s(); return 0; } """ % funcname) finally: f.close() try: objects = self.compile([fname], include_dirs=include_dirs) except CompileError: return False try: self.link_executable(objects, "a.out", libraries=libraries, library_dirs=library_dirs) except (LinkError, TypeError): return False return True def find_library_file (self, dirs, lib, debug=0): """Search the specified list of directories for a static or shared library file 'lib' and return the full path to that file. If 'debug' true, look for a debugging version (if that makes sense on the current platform). Return None if 'lib' wasn't found in any of the specified directories. """ raise NotImplementedError # -- Filename generation methods ----------------------------------- # The default implementation of the filename generating methods are # prejudiced towards the Unix/DOS/Windows view of the world: # * object files are named by replacing the source file extension # (eg. .c/.cpp -> .o/.obj) # * library files (shared or static) are named by plugging the # library name and extension into a format string, eg. # "lib%s.%s" % (lib_name, ".a") for Unix static libraries # * executables are named by appending an extension (possibly # empty) to the program name: eg. progname + ".exe" for # Windows # # To reduce redundant code, these methods expect to find # several attributes in the current object (presumably defined # as class attributes): # * src_extensions - # list of C/C++ source file extensions, eg. ['.c', '.cpp'] # * obj_extension - # object file extension, eg. '.o' or '.obj' # * static_lib_extension - # extension for static library files, eg. '.a' or '.lib' # * shared_lib_extension - # extension for shared library/object files, eg. '.so', '.dll' # * static_lib_format - # format string for generating static library filenames, # eg. 'lib%s.%s' or '%s.%s' # * shared_lib_format # format string for generating shared library filenames # (probably same as static_lib_format, since the extension # is one of the intended parameters to the format string) # * exe_extension - # extension for executable files, eg. '' or '.exe' def object_filenames(self, source_filenames, strip_dir=0, output_dir=''): if output_dir is None: output_dir = '' obj_names = [] for src_name in source_filenames: base, ext = os.path.splitext(src_name) base = os.path.splitdrive(base)[1] # Chop off the drive base = base[os.path.isabs(base):] # If abs, chop off leading / if ext not in self.src_extensions: raise UnknownFileError( "unknown file type '%s' (from '%s')" % (ext, src_name)) if strip_dir: base = os.path.basename(base) obj_names.append(os.path.join(output_dir, base + self.obj_extension)) return obj_names def shared_object_filename(self, basename, strip_dir=0, output_dir=''): assert output_dir is not None if strip_dir: basename = os.path.basename(basename) return os.path.join(output_dir, basename + self.shared_lib_extension) def executable_filename(self, basename, strip_dir=0, output_dir=''): assert output_dir is not None if strip_dir: basename = os.path.basename(basename) return os.path.join(output_dir, basename + (self.exe_extension or '')) def library_filename(self, libname, lib_type='static', # or 'shared' strip_dir=0, output_dir=''): assert output_dir is not None if lib_type not in ("static", "shared", "dylib", "xcode_stub"): raise ValueError( "'lib_type' must be \"static\", \"shared\", \"dylib\", or \"xcode_stub\"") fmt = getattr(self, lib_type + "_lib_format") ext = getattr(self, lib_type + "_lib_extension") dir, base = os.path.split(libname) filename = fmt % (base, ext) if strip_dir: dir = '' return os.path.join(output_dir, dir, filename) # -- Utility methods ----------------------------------------------- def announce(self, msg, level=1): log.debug(msg) def debug_print(self, msg): from distutils.debug import DEBUG if DEBUG: print(msg) def warn(self, msg): sys.stderr.write("warning: %s\n" % msg) def execute(self, func, args, msg=None, level=1): execute(func, args, msg, self.dry_run) def spawn(self, cmd, **kwargs): spawn(cmd, dry_run=self.dry_run, **kwargs) def move_file(self, src, dst): return move_file(src, dst, dry_run=self.dry_run) def mkpath (self, name, mode=0o777): mkpath(name, mode, dry_run=self.dry_run) # Map a sys.platform/os.name ('posix', 'nt') to the default compiler # type for that platform. Keys are interpreted as re match # patterns. Order is important; platform mappings are preferred over # OS names. _default_compilers = ( # Platform string mappings # on a cygwin built python we can use gcc like an ordinary UNIXish # compiler ('cygwin.*', 'unix'), # OS name mappings ('posix', 'unix'), ('nt', 'msvc'), ) def get_default_compiler(osname=None, platform=None): """Determine the default compiler to use for the given platform. osname should be one of the standard Python OS names (i.e. the ones returned by os.name) and platform the common value returned by sys.platform for the platform in question. The default values are os.name and sys.platform in case the parameters are not given. """ if osname is None: osname = os.name if platform is None: platform = sys.platform for pattern, compiler in _default_compilers: if re.match(pattern, platform) is not None or \ re.match(pattern, osname) is not None: return compiler # Default to Unix compiler return 'unix' # Map compiler types to (module_name, class_name) pairs -- ie. where to # find the code that implements an interface to this compiler. (The module # is assumed to be in the 'distutils' package.) compiler_class = { 'unix': ('unixccompiler', 'UnixCCompiler', "standard UNIX-style compiler"), 'msvc': ('_msvccompiler', 'MSVCCompiler', "Microsoft Visual C++"), 'cygwin': ('cygwinccompiler', 'CygwinCCompiler', "Cygwin port of GNU C Compiler for Win32"), 'mingw32': ('cygwinccompiler', 'Mingw32CCompiler', "Mingw32 port of GNU C Compiler for Win32"), 'bcpp': ('bcppcompiler', 'BCPPCompiler', "Borland C++ Compiler"), } def show_compilers(): """Print list of available compilers (used by the "--help-compiler" options to "build", "build_ext", "build_clib"). """ # XXX this "knows" that the compiler option it's describing is # "--compiler", which just happens to be the case for the three # commands that use it. from distutils.fancy_getopt import FancyGetopt compilers = [] for compiler in compiler_class.keys(): compilers.append(("compiler="+compiler, None, compiler_class[compiler][2])) compilers.sort() pretty_printer = FancyGetopt(compilers) pretty_printer.print_help("List of available compilers:") def new_compiler(plat=None, compiler=None, verbose=0, dry_run=0, force=0): """Generate an instance of some CCompiler subclass for the supplied platform/compiler combination. 'plat' defaults to 'os.name' (eg. 'posix', 'nt'), and 'compiler' defaults to the default compiler for that platform. Currently only 'posix' and 'nt' are supported, and the default compilers are "traditional Unix interface" (UnixCCompiler class) and Visual C++ (MSVCCompiler class). Note that it's perfectly possible to ask for a Unix compiler object under Windows, and a Microsoft compiler object under Unix -- if you supply a value for 'compiler', 'plat' is ignored. """ if plat is None: plat = os.name try: if compiler is None: compiler = get_default_compiler(plat) (module_name, class_name, long_description) = compiler_class[compiler] except KeyError: msg = "don't know how to compile C/C++ code on platform '%s'" % plat if compiler is not None: msg = msg + " with '%s' compiler" % compiler raise DistutilsPlatformError(msg) try: module_name = "distutils." + module_name __import__ (module_name) module = sys.modules[module_name] klass = vars(module)[class_name] except ImportError: raise DistutilsModuleError( "can't compile C/C++ code: unable to load module '%s'" % \ module_name) except KeyError: raise DistutilsModuleError( "can't compile C/C++ code: unable to find class '%s' " "in module '%s'" % (class_name, module_name)) # XXX The None is necessary to preserve backwards compatibility # with classes that expect verbose to be the first positional # argument. return klass(None, dry_run, force) def gen_preprocess_options(macros, include_dirs): """Generate C pre-processor options (-D, -U, -I) as used by at least two types of compilers: the typical Unix compiler and Visual C++. 'macros' is the usual thing, a list of 1- or 2-tuples, where (name,) means undefine (-U) macro 'name', and (name,value) means define (-D) macro 'name' to 'value'. 'include_dirs' is just a list of directory names to be added to the header file search path (-I). Returns a list of command-line options suitable for either Unix compilers or Visual C++. """ # XXX it would be nice (mainly aesthetic, and so we don't generate # stupid-looking command lines) to go over 'macros' and eliminate # redundant definitions/undefinitions (ie. ensure that only the # latest mention of a particular macro winds up on the command # line). I don't think it's essential, though, since most (all?) # Unix C compilers only pay attention to the latest -D or -U # mention of a macro on their command line. Similar situation for # 'include_dirs'. I'm punting on both for now. Anyways, weeding out # redundancies like this should probably be the province of # CCompiler, since the data structures used are inherited from it # and therefore common to all CCompiler classes. pp_opts = [] for macro in macros: if not (isinstance(macro, tuple) and 1 <= len(macro) <= 2): raise TypeError( "bad macro definition '%s': " "each element of 'macros' list must be a 1- or 2-tuple" % macro) if len(macro) == 1: # undefine this macro pp_opts.append("-U%s" % macro[0]) elif len(macro) == 2: if macro[1] is None: # define with no explicit value pp_opts.append("-D%s" % macro[0]) else: # XXX *don't* need to be clever about quoting the # macro value here, because we're going to avoid the # shell at all costs when we spawn the command! pp_opts.append("-D%s=%s" % macro) for dir in include_dirs: pp_opts.append("-I%s" % dir) return pp_opts def gen_lib_options (compiler, library_dirs, runtime_library_dirs, libraries): """Generate linker options for searching library directories and linking with specific libraries. 'libraries' and 'library_dirs' are, respectively, lists of library names (not filenames!) and search directories. Returns a list of command-line options suitable for use with some compiler (depending on the two format strings passed in). """ lib_opts = [] for dir in library_dirs: lib_opts.append(compiler.library_dir_option(dir)) for dir in runtime_library_dirs: opt = compiler.runtime_library_dir_option(dir) if isinstance(opt, list): lib_opts = lib_opts + opt else: lib_opts.append(opt) # XXX it's important that we *not* remove redundant library mentions! # sometimes you really do have to say "-lfoo -lbar -lfoo" in order to # resolve all symbols. I just hope we never have to say "-lfoo obj.o # -lbar" to get things to work -- that's certainly a possibility, but a # pretty nasty way to arrange your C code. for lib in libraries: (lib_dir, lib_name) = os.path.split(lib) if lib_dir: lib_file = compiler.find_library_file([lib_dir], lib_name) if lib_file: lib_opts.append(lib_file) else: compiler.warn("no library file corresponding to " "'%s' found (skipping)" % lib) else: lib_opts.append(compiler.library_option (lib)) return lib_opts


{{ partial "header.html" . }} {{partial "waterfall.html" .}} {{ partialCached "footer.html" . }} {{partialCached "script.html" .}}


Snoop Dogg
Resource
Assignment uploaded
Snoop Dogg has uploaded the assignment for the Art of Living amongst trees.
Snoop Dogg has uploaded the assignment for the Art of Living amongst trees.
Mr. Zac Efron has left the university. Hence, Miss Alexandra Daddario will be taking his place and teaching biology this semester.
Chitkara University proudly presents EXPLORE 2k18! Come, be a part of this exuberant event. Show off your skills - be they singing, dancing, theatre, comedy, drama, poetry or art & craft!
Sign UpMr. Brad Pitt has now taken over the We Hate Rachel Green club and is now its President.
Mr. Wiz Khalifa, along with his team of curious students have filed their 357th(😮) patent this semester - this time in the field of biotechnology! Check out the details of how they made us proud by clicking the button below!
One of the youngest members of our Computer Science faculty - Miss Emma Stone has won an award for her work in the field of Image Recognition and Pattern detection. Check out her award win below!
Where do savvy developers, hackers, tech builders and makers go to test their mettle and push the very limits of their creativity and endurance? To a Hackathon! where else?
We're psyched to announce that the Developer Student Club, Chitkara University presents Octahacks on April 14-15 at Chitkara University. Come be a part of it! Register below.
Mr. Lalu Prasad Yadav recently organized a debate on the capabilities of Machine Learning and Artificial Intelligence. Over 50 students participated and presented their ideas and opinions about this relatively new technology. Watch the full video below.


Gavin has been involved with the PostgreSQL community as a user, contributor and evangelist for over 10 years. As the CTO of myYearbook.com, he has been directly involved in the various methodologies used to scale PostgreSQL, meeting the demands of the rapid & large scale growth that the site has experienced. Gavin is the author of Golconde, a queue based data distribution system for PostgreSQL.
It's 1:30 am and your already popular website was just featured on national television. Will your PostgreSQL back-end become the bottleneck that takes the site down?  Do you expect that you will be some day? Scaling PostgreSQL Under Fire covers the various demands, stages of growth and the strategies to accommodate them. From top level concepts including hardware platform choices and schema decisions to the inner-workings of PostgreSQL, we will cover the pitfalls of common implementation mistakes and the road to accommodating growth while maintaining a reasonable sleep schedule.


DARK CITY A film review by Steve Rhodes Copyright 1998 Steve Rhodes
RATING (0 TO ****): * 1/2
"First came darkness, then came the strangers," we are told in the opening to the macabre, science fiction thriller, DARK CITY, by the director of THE CROW. It seems "the strangers" have come from another world and, like Nazi doctors, have a series of diabolical experiments they are conducting on the local inhabitants' memories.
In a cast with significant depth, Kiefer Sutherland plays Dr. Schreber, who has sold his soul to the strangers and is helping them carry out their tests on human guinea pigs. As the show's hero, John Murdoch, MRS. DALLOWAY's Rufus Sewell plays the only man who may be able to save humanity -- or at least the city. Or it is one and the same?
Jennifer Connelly, last seen in the delightful but unappreciated INVENTING THE ABBOTTS, is John's wife, Emma. Or is she? You get the idea. Like an Escher print, the storyline twists into itself and out again, so that what is real and what isn't become intertwined.
As the tough but, like the audience, confused Inspector Bumstead, William Hurt plays his usual character. There's a mass murderer afoot in the city, and Inspector Bumstead harbors certain suspicions about John.
SPICE WORLD's Richard O'Brien is the stranger named Mr. Hand, and Ian Richardson is the leader of the strangers, Mr. Book.
So what can be so bad about a film with this lineup? Editing.
Let's stop and take a poll. How long do you like the camera to stay with one character before it switches to another? 20 seconds so that the actor has a chance to say something meaningful? 10 seconds so that we can keep a fast pace? How about a blistering 5? Nope, all of these are way too slow for DARK CITY's editor, Dov Hoenig. 1 and 2 second clips are the norm in this movie. I know because I timed them. (My watch and I got to know each other better as a way for me to relive my boredom.) The result of this excessive flitting is liable to be nausea and confusion among the audience, which is a shame since there is a clever story trying to get out. But with the strobe light effect of five dozen 1-2 second clips in a row, it is hard to pay attention to anything.
The only real reasons for seeing the picture are the bleak production design by George Liddle and Patrick Tatopoulos and the grimy cinematography by Dariusz Wolski. For those of you who thought Tim Burton's vision of Gotham City in BATMAN was too bright and happy, you'll like the look of DARK CITY. (One of the oddities of this metropolis is that time goes from midnight to midnight with no noon or daylight in between, but the locals never notice. It's that loss of memory thing.)
Liz Keogh's costumes for the strangers are memorable.  And shot at angles designed to make them look seven feet tall, they appear quite ominous.
If the editing and the confusing direction have you ready to walk out in the first fifteen minutes, don't fight the urge. Yes, there are a couple of nice twists along the way and some good visuals, but most people can find many better things to do with their time.
DARK CITY runs 1:43. It is rated R for violence, nudity and profanity and would be fine for most teenagers.
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


This is our working corpus page on San Juan Quiahije Chatino, an Eastern Chatino Language.
This is a description of Old Mixtec writing.
Illustrations/figures Geography Map Generic information about the Language / Language metadata Language codes Navigation Phonology audio files example words tables Glossary Target audience: Linguists Advanced learners Interlinear examples Localization


| User1 Delivery Installation team |
Customer: ALC | Environment: SIT | |
| INSTALLATION: | 30/04/2016 16:42 | ||
| Spn-web-games | Installation complete |
| User1 Delivery Installation team |
Customer: ALC | Environment: SIT | |
| INSTALLATION    30/04/2016 16:42 | |||
| Installation in progress |
| User1 Delivery Installation team |
Customer: ALC | Environment: SIT | |
| INSTALLATION    30/04/2016 16:42 | |||
| Installation blocked |


{% extends "layout.html" %} {% block phase%} {% include 'sprint12/partials/phase-banner.html'%} {% endblock %} {% block main %}
Mon to Thurs: 8:30am - 5pm
Friday: 8:30am - 4:30pm
Closed public holidays.
Calls answered within 5 minutes.
Calls cost up to 9p a minute from landlines, calls from mobiles may cost more.


Some primary options have no secondary option, some have static secondary options, and some have dynamic secondary options


Sales-Target-Prescription management system for a
pharmaceutical company (Roche)
Technology Used:
Laravel, Mysql, AngularJs
Inventory Application
Technology Used:
Laravel, Mysql, JavaScript, AngularJs
Surf horn, making friends, creating posts, like, share, comment like facebook
Technology Used:
Laravel, Mysql, JavaScript, AngularJs
Book hotel room and ride
Technology Used:
Slim, Mysql, JavaScript, JQuery, AngularJs
Bangladesh National AID management system (Govt.)
Technology Used:
CakePHP, Mysql, JQuery, JavaScript
DocuDEX (Document Management System) for many Bank of Bangladesh
Technology Used:
Symfony, Mysql, JavaScript, JQuery
EKYC (Electronically know your customer)
Technology Used:
Symfony, MySQL, JavaScript
HRMS for TIB
Technology Used:
Laravel, Mysql, JavaScript
Land Record (Govt.)
Technology Used:
Laravel, Mysql, JavaScript, LiveWire
Case Management (Govt.)
Technology Used:
Laravel, Mysql, JavaScript, LiveWire


Status
- Doc Status
-
Working Draft — Only experimental and ‘proof-of-concept’ apps should be built on this unstable draft.
- Proposed IANA Registrations
-
application/prs.hal-forms+json
- Repository
- Sample Implementation
- Last Updated
-
2016-12-29
Summary
This document describes a simple media type designed to add runtime FORM support for the [HAL] media type. This is an independent backward-compatible extension of the HAL media type and MUST NOT be treated as standard HAL or as part of the HAL specification [HALSPEC].
Motivation
The HAL media type is a popular format for representing API responses. One of the possible reasons for this popularity is that HAL does not include detailed information about state transitions like filtered requests (e.g. search, sort, etc.) or write operations (e.g. create, edit, delete, etc.) as part of the specification. This feature keeps the complexity of HAL responses relatively low and easy to deal with. However, this also means one of the challenges of using HAL for APIs that support dynamic user inputs and/or varying work flow patterns is client applications must encode the detailed transition information (args, methods, work flow) directly in the client code. That means clients must be updated each time the input or work flow details change.
The HAL-FORMS media type is an attempt to meet this challenge by creating a format and processing pattern to support dynamic UI forms for HAL responses. This is a backward-compatible, non-standard extension. There is nothing in this format or process pattern that adds breaking changes to the HAL media type itself. Clients that implement this extension can still be valid HAL clients by degrading gracefully (e.g. not throwing errors) when HAL-FORMS documents are not returned by the server.
|
Note
|
The HAL-FORMS media type design follows many of the HAL media type conventions. For this reason, HAL-FORMS "looks like HAL." However, it is important to keep in mind that HAL-FORMS is not the same as HAL — the two should not be thought of as interchangeable in any way. Finally, HAL-FORMS documents SHOULD always be sent over HTTP using the |
Updates
There is an open source repository [REPO] for this specification. Readers are encouraged to submit updates via the repository any time.
Compliance
An implementation (client or server) of this specification is not compliant if it fails to satisfy one or more of the MUST or REQUIRED elements. An implementation that satisfies all the MUST and REQUIRED elements as well as all the SHOULD and RECOMMENDED elements is said to be "unconditionally compliant"; one that satisfies all the MUST and REQUIRED elements but not all the SHOULD and RECOMMENDED elements is said to be "conditionally compliant."
|
Note
|
RFC2119 Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
The HAL-FORMS Media Type
The HAL-FORMS media type is a simple JSON [RFC7159] document that contains information on the HTTP method, message content-type, and parameters to use when making a templated request to a HAL server. This media type can be used to provide dynamic state transition descriptions at runtime.
Example HAL-FORMS document
Here is a simple HAL-FORMS document example:
{
"_links" : {
"self" : {
"href" : "http://api.example.org/rels/create"
}
},
"_templates" : {
"default" : {
"title" : "Create",
"method" : "post",
"contentType" : "application/json",
"properties" : [
{"name" : "title", "required" : true, "value" : "", "prompt" : "Title", "regex" : "", "templated" : false},
{"name" : "completed", "required" : false, "value" : "false", "prompt" : "Completed", "regex" : ""}
]
}
}
}
Properties of a HAL-FORMS Document
All HAL-FORMS documents MUST be valid JSON documents. A well-formed HAL-FORMS document has two top-level objects: _links
and _templates
. The following is a summary of the structure of the HAL-FORMS media type.
The _links
Element
The _links
element contains any links associated with the HAL-FORMS document. For this release, the only valid link
object is the self
link object.
-
_links
-
Contains the collection of valid
link
objects in the HAL-FORMS document. This is a RECOMMENDED element. If this element is missing or if the contents is unrecognized, it SHOULD be treated as if it contains a singlelink
element with the key ofself
and the value of the URL used to request this HAL-FORMS document. -
link
-
The
link
element consists of a key and a set of properties.
-
key
: The unique identifier of thelink
object. This is a REQUIRED element for each _link+ object. For this release, the only valid value for thekey
element is"self"
. If this element is missing, is set to an unrecognized value, or cannot be parsed, the associatedlink
object SHOULD be ignored. -
href
: The URL associated with thekey
. This is a REQUIRED element. If this is missing, set to empty or unparsable, the associatedlink
object SHOULD be ignored.
-
The _templates
Element
The _templates
element describes the available state transition details including the HTTP method, message content-type, and arguments for the transition. This is a REQUIRED element. If the HAL-FORMS document does not contain this element or the contents are unrecognized or unparsable, the HAL-FORMS document SHOULD be ignored.
The _templates
element contains a collection of template
objects. Each template
object contains the following possible properties:
-
contentType
-
The value of
contentType
is the media type the client SHOULD use when sending a request body to the server. This is an OPTIONAL element. Valid values for this release are"application/json"
[RFC7159] and"application/x-www-form-urlencoded"
[HTML401]. If thecontentType
property is missing, is set to empty, or contains an unrecognized value, the client SHOULD act is if thecontentType
is set to"application/json"
. See Encoding Request Bodies for details. -
key
-
The unique identifier for this
template
object. This is a REQUIRED element. For this release, the only valid value forkey
is"default"
. If this element is missing, set to empty or is unparsable, thistemplate
object SHOULD be ignored. -
method
-
The HTTP method the client SHOULD use when the service request. Any valid HTTP method is allowed. This is a REQUIRED element. If the value is empty or is not understood by the client, the value MUST be treated as an HTTP GET.
-
properties
-
An array of one or more anonymous
property
objects (seeproperty
) that each describe a parameter for the associated state transition. This is an OPTIONAL element. If the array is missing or empty, theproperties
collection MUST be treated as an empty set of parameters — meaning that the transition is meant to be executed without passing any parameters. -
property
-
A JSON object that describes a state transition parameter. A
property
object has the following elements:
-
name
: The parameter name. This is a valid JSON string. This is a REQUIRED element. If this attribute is missing or set to empty, the client SHOULD ignore thisproperty
object completely. -
prompt
: The human-readable prompt for the parameter. This is a valid JSON string. This is an OPTIONAL element. If this element is missing, clients MAY act as if theprompt
value is set to the value in thename
attribute. -
readOnly
: Indicates whether the parameter is read-only. This is a valid JSON boolean. This is an OPTIONAL element. If this element is missing, empty, or set to an unrecognized value, it SHOULD be treated as if the value ofreadOnly
is set to ‘false’. -
regex
: A regular expression string to be applied to the value of the parameter. Rules for valid values are the same as the HTML5 pattern attribute [HTML5PAT]. This is an OPTIONAL element. If this attribute missing, is set to empty, or is unparseable , it SHOULD be ignored. -
required
: Indicates whether the parameter is required. This is a valid JSON boolean. This is an OPTIONAL element. If this attribute is missing, set to blank or contains an unrecognized value, it SHOULD be treated as if the value ofrequired
is set to ‘false’. -
templated
: Indicate whether thevalue
element contains a URI Template [RFC6570] string for the client to resolve. This is a valid JSON boolean. This is an OPTIONAL element. If this element is missing, set to empty, or contains unrecognized content, it SHOULD be treated as if the value oftemplated
is set to ‘false’. -
value
: The parameter value. This is a valid JSON string. This string MAY contain a URI Template (seetemplated
for details). This is an OPTIONAL element. If it does not exist, clients SHOULD act as if thevalue
property is set to an empty string.
-
-
title
-
A human-readable string that can be used to identify this template. This is a valid JSON string. This is an OPTIONAL element. If it does not exist or is unparsable, consumers MAY use the
key
value of the template as the value fortitle
.
The HAL-FORMS Query String Registry
The HAL-FORMS media type supports a set of OPTIONAL query string parameters. These can be passed when requesting HAL-FORMS documents in order to provide additional information (e.g. document identifiers, etc.) to the server when a client requests a HAL-FORMS document. For example, the server can use these parameter values to validate the HAL-FORMS request and/or use them to determine how to pre-populate the HAL-FORMS document before returning it to the client.
Below is the list of query string values defined for this release of the specification. One or more of these parameters MAY appear in the URLs used to request HAL-FORMS documents. They can appear in the query string in any order. One or more (possibly all) these parameters MAY be ignored by servers receiving the HAL-FORMS request.
-
_hdoc
-
Contains the identifier (usually a URL) of the HAL document from which this request was derived. For example if the HAL document had a URL of
http://api.example.org/users/123
then the_hdoc
query parameter would be_hdoc=http%3A%2F%2Fapi.example.org%2Fusers%2F123
. -
_hkey
-
Contains the
key
value of the HAL-FORMS template the client wishes to receive. For example, if the HAL-FORMS templatekey
isdefault
then the_hkey
parameter would be_hkey=default
. -
_hmethod
-
Contains the HTTP method to be used when populating the HAL-FORMS
method
value in the_template
. For example, if the client wishes to execute an HTTP POST with the template, the_hmethod
parameter would be:_hmethod=post
. -
_hrel
-
Contains the
key
of the HAL_link
element that identified the URL for the HAL-FORMS document. For example, if the HAL document had a_link
element that looked like this:"http://api.example.org/rels/filter": { "href": "http://api.example.org/task-list/", "title": "Filter Tasks", "templated": false }
…then the
_hrel
parameter would be_hkey=http%3A%2F%2Fapi.example.org%2Frels%2Ffilter
. -
_hsource
-
Contains the identifier of the source record to use when pre-populating the HAL-FORMS document. For example, if the client wishes to edit the resource identified by the URL
http://api.example.org/users/123
then the_hsource
parameter would be_hsource=http%3A%2F%2Fapi.example.org%2Fusers%2F123
. -
_htarget
-
Contains the identifier of the target URL for the client to use when submitting the completed HAL-FORMS template. For example, if the client should submit the completed template to the following URL:
http://api.example.org/jobs/
then the_htarget
parameter would be_htarget=http%3A%2F%2Fapi.example.org%2Fjobs%2F
.
|
Note
|
Additional HAL-FORMS query string parameters MAY be added over time. Implementers are also allowed to create their own HAL-FORMS query string parameters for local use as long as they do not overwrite or redefine existing query string parameters. Implementers are encouraged to use their own unique prefix value to reduce the chance their custom query parameters will conflict with other existing or future parameter names. |
Encoding Requests
Once the client application has used the HAL-FORMS document to render a UI for accepting inputs (and the user has supplied the inputs), that same document SHOULD be used to encode a request to send to the server to execute the state transition described by the HAL-FORMS document. There are two ways in which HAL-FORMS documents can be used to construct parameterized requests. The first is by encoding request URLs for HTTP GET, DELETE, and HEAD requests. The second is by encoding request bodies for HTTP PUT, POST, and PATCH requests.
Encoding Request URLs
When clients are instructed to send a request without a body (e.g. GET, HEAD, DELETE), clients SHOULD use the list of property
object’s name
and value
attributes to construct a valid URL using the W3C Mutate Action URL Algorithm [HTML5MUT] to produce a valid query string. Below is a simple HAL-FORMS document that uses the GET method and the resulting updated URL.
// HAL RESPONSE
{
"_links": {
"self": {
"href": "http://api.example.org/task-list/",
"title": "Reload",
"templated": false
},
"http://api.example.org/rels/filter": {
"href": "http://api.example.org/task-list/",
"title": "Filter Tasks",
"templated": false
},
}
}
// HAL FORMS DOCUMENT
{
"_links" : {
"self" : {
"href" : "http://api.example.org/rels/filter"
}
},
"_templates" : {
"default" : {
"title" : "Filter",
"method":"get",
"properties": [
{"name":"title", "value":"", "prompt":"Title"},
{"name":"completed", "value":"", "prompt":"Completed", "regex":"^(true|false)$"}
]
}
}
}
// RESULTING URL
http://api.example.org/task-list/?title=sample&completed=false
|
Note
|
The HAL media type already defines support for parameterized HTTP GET queries using URITemplates. However, the HAL-FORMS document can be treated as an alternate implementation for GET queries that include additional constraints such as prompts, regular expression validators, etc. |
Encoding Request Bodies
When clients are instructed to send a request with a body (e.g. PUT, POST, PATCH), there are two possible content-types to use when encoding arguments: application/json
and application/x-www-form-urlencoded
. Compliant client applications MUST support sending bodies using application/json
and SHOULD support sending bodies using application/x-www-form-urlencoded
.
Sending application/json
Bodies
When sending bodies encoded as application/json
, clients SHOULD construct a simple JSON dictionary object that contains a set of name-value pairs that match the property
objects in the HAL-FORMS document. For example, using the Example HAL-FORMS document (see above) as a guide, a client would construct a JSON dictionary object that looks like the following:
{
"title" : "A Sample HAL Forms Response",
"completed" : false
}
Sending application/x-www-form-urlencoded
Bodies
When sending bodies encoded as application/x-www-form-urlencoded
, clients SHOULD construct a body that is in compliance with the guidance in the W3C FORMS Encoding Algorithm [HTML5ENC]. A sample (using the Example HAL-FORMS document) follows:
title=A+Sample+HAL+Forms+Response&completed=false
The HAL-FORMS Media Type Identifier String
The media type identifier string for HAL-FORMS documents is: application/prs.hal-forms+json
This SHOULD be used as part of the HTTP accept
header when making a request for a HAL-FORMS document. It SHOULD appear as the HTTP content-type
header when sending a response that contains a HAL-FORMS document.
Suggested Process Flow for HAL-FORMS Documents
While it is completely up to providers and consumers to determine how they wish to use the HAL-FORMS media type, the following is a suggested process flow for runtime use of HAL-FORMS documents on the Web.
-
Servers emit HAL responses that contain
rel
values which are valid URLs that return HAL-FORMS documents. -
Clients parse the HAL response and (either on-demand or in pre-fetch mode) request the HAL-FORMS documents.
-
When a HAL-FORMS document is returned by the server, clients use this information to render an input UI for humans when needed.
-
Clients collect the completed user inputs and, based on the value of
contentType
, craft a valid request to send to the server and execute that request.
What follows is an illustrated example of this process flow.
Starting With a Typical HAL Response.
A client application can start with a typical HAL response and use information in the representation to see if HAL-FORMS documents are available. Below is a HAL response w/ URLs for rel
values. These MAY point to HAL-FORMS documents.
**** REQUEST
GET /task-list/ HTTP/1.1
Host: api.example.org
Accept: application/vnd.hal+json
**** RESPONSE
HTTP/1.1 200 OK
Content-Type: application/vnd.hal+json
Date: Wed, 01 Jun 2016 14:50:30 GMT
{
"_links": {
"self": {
"href": "http://api.example.org/task-list/",
"title": "Reload",
"templated": false
},
"http://api.example.org/rels/create": {
"href": "http://api.example.org/task-list/",
"title": "Add Task",
"templated": false
},
"http://api.example.org/rels/tasks": [
{
"href": "http://localhost:8181/1a14qx7qc81",
"title": "Yard Work"
},
{
"href": "http://localhost:8181/1d4jwe1ewt7",
"title": "Home Work"
},
{
"href": "http://localhost:8181/1e2ll5wa383",
"title": "School Work"
}
]
}
}
Requesting a HAL-FORMS Document
After parsing the HAL response, a HAL-FORMS compliant client app MAY use the rel
URLs to make requests for HAL-FORMS documents. In the case of this example, the http://api.example.org/rels/create
is used to see if there is a HAL-FORMS document available.
**** REQUEST
GET /rels/create HTTP/1.1
Host: api.example.org
Accept: application/prs.hal-forms+json
**** RESPONSE
HTTP/1.1 200 OK
Content-Type: application/prs.hal-forms+json
Date: Wed, 01 Jun 2016 14:59:30 GMT
{
"_links" : {
"self" : {
"href" : "http://api.example.org/rels/create"
}
},
"_templates" : {
"default" : {
"title" : "Create",
"method" : "post",
"contentType" : "application/json",
"properties" : [
{"name" : "title", "required" : true, "value" : "", "prompt" : "Title", "regex" : "", "templated" : false},
{"name" : "completed", "required" : false, "value" : "false", "prompt" : "Completed", "regex" : ""}
]
}
}
}
Sending a HAL-FORMS Body Request
After receiving the HAL-FORMS response and rendering the UI, the client application can — once the user supplies inputs and executes the "submit" action — use the instructions in the HAL-FORMS document to compose a request and send it to the URL indicated in the HAL document response (as follows):
**** REQUEST
POST /task-list/ HTTP/1.1
Host: api.example.org
Accept: application/json
{
"title" : "A Sample HAL-FORMS Response",
"completed" : false
}
**** RESPONSE
HTTP/1.1 201 OK
Content-Type: application/vnd.hal+json
Date: Wed, 01 Jun 2016 15:03:30 GMT
...
Extending the HAL-FORMS Document
Authors can extend the HAL-FORMS media type as long as the following rules are observed:
-
No existing properties or objects are removed.
-
No existing properties or objects or the list of valid values are altered in a way that is non-backward compatible (e.g. changes MUST NOT break existing implementations that adhere to this specification).
-
All new properties or objects are treated as OPTIONAL (e.g. no new REQUIRED elements are introduced in an extension).
|
Warning
|
Authors should be aware that a future version of this specification MAY add new elements and should take care that any extensions are implemented in a way that reduces the likelihood that a future version of this specification is in conflict with your extension. |
References
-
[HAL] Kelly, M. "HAL - Hypertext Application Language", September 2013, http://stateless.co/hal_specification.html
-
[HALSPEC] Kelly, M. "JSON Hypertext Application Language" (Draft), July 2015 https://tools.ietf.org/html/draft-kelly-json-hal-07
-
[REPO] Github, "HAL-FORMS", https://github.com/RWCBook/hal-forms
-
[RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", March 1997, http://tools.ietf.org/html/rfc2119
-
[RFC7159] Bray, T. "The JavaScript Object Notation (JSON) Data Interchange Format", March 2014, https://tools.ietf.org/html/rfc7159
-
[HTML401] Raggett, D., Ed. et al", "HTML 4.01 Specification", December 1999, https://www.w3.org/TR/html401/interact/forms.html#h-<IP_ADDRESS>
-
[HTML5PAT] Hickson, I., Ed. et al, "HTML5 (The Pattern Attribute)", October 2014, http://www.w3.org/TR/html5/forms.html#the-pattern-attribute
-
[RFC6570] Gregorio, J., et al, "URI Template", March 2012, https://tools.ietf.org/html/rfc6570
-
[HTML5MUT] Hickson, I., Ed. et al, "HTML5 (Mutate Action URL)", October 2014, http://www.w3.org/TR/html5/forms.html#submit-mutate-action
-
[HTML5ENC] Hickson, I., Ed. et al, "HTML5 (Encoding Algorithm)", October 2014, http://www.w3.org/TR/html5/forms.html#application/x-www-form-urlencoded-encoding-algorithm
Acknowledgements
I thank the everyone who helped contribute to this specification including: Josh Cohen, Pete Johanson, Mike Kelly, Dilip Krishnan.


'No co-living, no student accommodation, no hotels': 80% of units in Dublin housing development to be social and affordable
by By Digital Desk staffDublin City Councillors have secured a new deal for a major housing development at O'Devaney Gardens.
It means 80% of the residential units will be social and affordable, compared to 50% in the original proposal.
The council will vote tonight on whether to allow the redevelopment of the site off the North Circular Road.
Cllr Mary Fitzpatrick says the Government has failed to fund a sustainable, affordable and deliverable housing model.
"For the first time there will be an affordable rental scheme on the site, there will 824 residential units. We are also very proud to have secured ringfencing of three-and-a-half million [euro] for community facilities," she said.
"There will be no co-living, there will be no student accommodation, there will be no hotels. There will actually be homes."
READ MORE
Court: Executive Office has power to compensate institutional abuse victims in NI


R.attr.paramName
attribute's value can be found in the R.styleable.FeatureParam
array.R.attr.paramValue
attribute's value can be found in the R.styleable.FeatureParam
array.@[+][package:]type/name
" or a theme
attribute in the form
"?[package:]type/name
".


Hi,
Apologies if this is a dumb question, but I am still new at this. I've got an emontxv3 and RPi and using it to monitor whole house usage as well as PV generation. I have one CT on the Solar generation, and one CT on the Grid import / export, and uploading the data to emoncms.org
I now realise I need to add the PV Generation to the Grid import / export to get total house usage, but I am getting confused on best way to do that. I think I have seen examples of using the input process assigned to PV Gen, logging to feed, and then adding Grid import, and then logging that to a feed, and I have also seen it the opposite way around, by updating the input for Grid use and adding Solar gen and logging that to a feed. And I also think I saw a suggestion of using a completely separate input, and adding the Solar Gen together with Grid input, and logging that to a feed.
Is there a preference? Is it simpler to use a separate input for each of them ? i.e. input 1 for PV Gen, input 2 for Grid, input 3 for combination of both? Is there a performance benefit in adding lots of process steps to one input, or is it better to have more inputs, with less process steps for each of them?
And if this is covered in a newbie document, please point me at it as I haven't found it on the emoncms documentation on github
Ian
Re: Should I use separate inputs or stack multiple process steps in one input?
I'm pretty sure it won't be documented to that level, and I doubt whether you'll see a difference in performance. So I'd advise you to use the one you're most comfortable with. The only thing I'd consider is what information do you think you're likely to want in the future: only 'feeds' are stored, anything else is lost instantly.
Re: Should I use separate inputs or stack multiple process steps in one input?
The predominant factor to consider when planning your processlists it that the processing is triggered by the update of the input and the inputs are processed in the order received by emoncms. so due to the way emoncms receives most of its data the inputs are updated (and therefore processed) sequentially in numerical order, this won't be the case if data is supplied as key value pairs (eg power1 = 100 etc).
The reason I mention this is because you may wish to have any processing that includes multiple inputs located in the later of those inputs to ensure the new values are used. when input 1 is processed if it includes "add input 2" that will use the previously received value as input 2 will not have been freshly updated yet.
The triggering by input update makes the use of a "separate input" to tally 2 inputs a little more complicated to implement as it would rely on the update of that "separate input" to update the total.
So in your example I would be inclined to have the totaling in input 2's processlist.
Another recommendation is to "log to feed" each input ( I prefer variable interval to log receipts rather than trends) and then use "add feed" rather than "add input" as it is far more robust.
Paul


Usually, Boost.Build handles implicit dependendies completely
automatically. For example, for C++ files, all #include
statements are found and handled. The only aspect where user help
might be needed is implicit dependency on generated files.
By default, Boost.Build handles such dependencies within one main target. For example, assume that main target "app" has two sources, "app.cpp" and "parser.y". The latter source is converted into "parser.c" and "parser.h". Then, if "app.cpp" includes "parser.h", Boost.Build will detect this dependency. Moreover, since "parser.h" will be generated into a build directory, the path to that directory will automatically added to include path.
Making this mechanism work across main target boundaries is
possible, but imposes certain overhead. For that reason, if
there's implicit dependency on files from other main targets, the
<implicit-dependency>
[ link ] feature must
be used, for example:
lib parser : parser.y ; exe app : app.cpp : <implicit-dependency>parser ;
The above example tells the build system that when scanning all sources of "app" for implicit-dependencies, it should consider targets from "parser" as potential dependencies.


Hi, my name is Sunny,
and I run Sun City Computers, a Townsville based business,
responding to the needs of families and businesses for after hours fixes.
We can fix most problems with your computer. We can also source replacement parts, and upgrades.
Laptops | Desktop PCs | Monitors | Accessories
My Latest Speciality: I enjoy creating and sharing insights to the data, and the science contained within
I enjoy getting the most out of my devices, pushing limits and innovation where I see fit
While I enjoy getting the most out of my devices, IOS devices are still relatively new to me
I enjoy tinkering with many of my electronic devices, innovating and learning along the way


Hello! We're the Halvorsons, Jenifer and Isaac. We're married, and are currently living in Minneapolis, MN. Thanks for visiting our site!
Jenifer is the culinary force behind the website.


Zika virus (ZIKV) is a little known arbovirus until it caused a major outbreak in the Pacific Island of Yap in 2007. Although the virus has a wide geographic distribution, most of the known vectors are sylvatic Aedes mosquitoes from Africa where the virus was first isolated. Presently, Ae. aegypti is the only known vector to transmit the virus outside the African continent, though Ae. albopictus has long been a suspected vector. Currently, Ae. albopictus has been shown capable of transmitting more than 20 arboviruses and its notoriety as an important vector came to light during the recent chikungunya pandemic. The vulnerability of Singapore to emerging infectious arboviruses has stimulated our interest to determine the competence of local Ae. albopictus to transmit ZIKV.
To determine the competence of Ae. albopictus to ZIKV, we orally infected local mosquito strains to a Ugandan strain virus. Fully engorged mosquitoes were maintained in an environmental chamber set at 29°C and 80–85%RH. Twelve mosquitoes were then sampled daily from day one to seven and on day 10 and 14 post infection (pi). Zika virus titre in the midgut and salivary glands of each mosquito were determined using tissue culture infectious dose
The study highlighted the potential of Ae. albopictus to transmit ZIKV and the possibility that the virus could be established locally. Nonetheless, the threat of ZIKV can be mitigated by existing dengue and chikungunya control program being implemented in Singapore.
The prominence of Ae. albopictus as a major vector came to light during the global pandemic of chikungunya. The continual global expansion of Ae. albopictus coupled with data from competence studies that show its ability to transmit more than 20 arboviruses has fuelled growing concerns that this mosquito may alter the epidemiology of arbovirus worldwide and increase the risks of humans to mosquito-borne diseases. This has stimulated our interest to determine the extent of pathogens Ae. albopictus can transmit, especially arboviruses with high epidemic potential. The current study showed that local Ae. albopictus are susceptible to ZIKV. By day 7 pi. all mosquitoes that were orally infected were found to have disseminated infections and 73% have ZIKV in their saliva. This study highlighted the potential of Ae. albopictus to transmit ZIKV. The local transmission of ZIKV in Singapore is plausible due to the presence of susceptible vectors, an immunologically naive and vulnerable human population, and the travel hub status of Singapore. Nonetheless, the threat of ZIKV can be mitigated by existing dengue and chikungunya control program being implemented in Singapore.
The Asian tiger mosquito, Aedes (Stegomyia) albopictus (Skuse), is considered a vector or potential vector of several pathogens of human and veterinary importance. Viral isolation and vector competence studies have shown that this mosquito is an efficient vector of more than 20 arboviruses [1] . Due to its biological and ecological plasticity, this notoriously invasive species has a wide geographic distribution. At present, aside from its tropical Asian home, Ae. albopictus can be found in temperate Asian countries, in tropical and temperate Americas, Europe, Middle East, the Pacific islands, Australia and Africa [2] , [3] , [4] , [5] . The global spread of Ae. albopictus is mainly caused by human activities, such as increase in intercontinental trade, especially in the last three decades [1] .
In places where Ae. aegypti and Ae. albopictus co-exist, Ae. albopictus was considered second only to Ae. aegypti in terms of importance as vector of dengue and chikungunya [6] , [7] . However, its notoriety as an important vector came to light during the recent unprecedented global outbreak of chikungunya. According to Tsetsarkin et al. [8] , a mutation in the envelope gene of chikungunya virus (CHIKV) enhances the virus infectivity and transmissibility in Ae. albopictus. The continual global expansion of Ae. albopictus is a growing concern as this mosquito may alter the transmission dynamics of arboviral diseases and increase the risks of humans to mosquito-borne viral infections [3] , [9] . This has stimulated increased interest to determine the extent of pathogens this mosquito can transmit.
Zika virus (ZIKV), a little known arbovirus, has gained prominence when it caused a large scale epidemic in the Pacific Island in 2007 [10] , [11] . It is a member of the genus Flavivirus of the Family Flaviviridae [12] . The virus is a positive single stranded RNA virus with a 10,794 nucleotide genome that is closely related to the Spondweni virus [13] , [14] , [15] . It was first isolated from a febrile sentinel monkey in Uganda in 1947 [15] , but human ZIKV infection was first reported in 1964 [16] . The virus causes dengue-like syndromes such as rash, fever, arthralgia, headache and peri-orbital pain [11] , [16] .
To date, only Aedes mosquitoes have been known to transmit ZIKV. In Africa, the virus was isolated from both sylvatic and peri-domestic mosquitoes: Ae. africanus, Ae. apicocoargenteus, Ae. luteocephalus, Ae. furcifer, Ae. vitattus and Ae. aegypti [17] , [18] , [19] , [20] , [21] , [22] . In Asia, ZIKV was only isolated from a pool of Ae. aegypti caught from shop houses in the State of Pahang in Peninsular Malaysia [22] . During the ZIKV outbreak in Yap Island in 2007, no virus was isolated from any of the mosquitoes caught. However, based on epidemiological evidences, Ae. hensilii was suspected to be the vector responsible for the outbreak [11] . In 2010, a case of ZIKV involving a three year old child was reported in Kampong Speu Province in Cambodia, however, the vector responsible was not known [23] .
Identification of vectors and potential vectors of ZIKV or any other mosquito-borne diseases in a given geographical area has important implication when it comes to disease outbreak control. It is imperative that vectors are identified, so that a holistic and sound vector control program can be formulated. To date, Ae. aegypti is the only vector of ZIKV identified in Southeast Asia [22] and data on mosquito-ZIKV interactions have also been confined to this mosquito [24] , [25] . Our recent study has also showed that local Ae. aegypti strains are highly susceptible to ZIKV and viral dissemination rates reflect that observed for a local, highly epidemic DENV-2 strain [26] .
In the light of continuous global niche expansion of Ae. albopictus, coupled with its catholic feeding behaviour, ecological adaptability and propensity to support a wide range of arboviruses, it is important to determine its competence to transmit pathogens with high epidemic potential such as ZIKV. The current study describes ZIKV infection in our local Ae. albopictus.
Aedes albopictus, used for the experimental infection, was derived from eggs collected during weekly ovitrap surveillance study as previously described [26] . Mosquitoes were colonized under standard insectary conditions as described by Li and colleagues [26] . In order to obtain enough number of mosquitoes for the study, F
Ugandan MR766 ZIKV strain obtained from the American Type Culture Collection (Manassas, VA, USA) was used to infect the mosquitoes. The stock virus used in the current study was passaged thrice in Vero cell line prior to the infectious feed [26] .
Five to seven-day old female mosquitoes ( n = 120) were transferred to 0.5 L containers and starved for 24 hours prior to the infectious blood meal. The blood meal consisted of 1∶1 100% swine-packed RBC (Innovative Research, USA) and a fresh ZIKV suspension, at a final concentration of 7.5 Log10 tissue culture infectious dose50/mL ((Log
To determine the ZIKV infection and dissemination rates in Ae. albopictus, 12 mosquitoes were sampled daily from day one to seven, and subsequently on day 10 and 14 post infection (pi). Saliva was collected using the forced salivation technique as previously described [27] with modification. The proboscis of each mosquito, with its legs and wings, was inserted into a micropipette tip containing 10 µl of M199 and allowed to salivate. After 45 minutes, the Medium 199 containing the saliva from each mosquito was transferred into microcentrifuge tubes containing 100 µl of M199. The midgut and salivary glands of each mosquito were processed as described by Li and colleagues [26] . Briefly, the midgut and the salivary glands were homogenized using stainless steel grinding balls (Retsch, Germany) in a MM301 mixer mill (Retsch, Germany) set at frequency of 12/sec for 1 min. The supernatant of the homogenate was applied in the viral titre assay. All dissecting needles were dipped in 80% ethanol and cleaned before being re-used. All experiments were conducted inside an ACL-2 facility.
Total RNA was isolated from saliva using the QIAamp Viral Mini Kit (Qiagen, Germany) following manufacturer's recommendations. ZIKV in saliva was detected using a one-step real-time reverse transcriptase-polymerase chain reaction (qRT-PCR) as previously described [10] .
Viral titres from the midgut and salivary glands were determined with tissue culture infectious dose
The infection rate at each sampling day was determined by the percentage of infected midguts, while dissemination rate was calculated by dividing the number of infected salivary glands by the total number of mosquitoes with infected midguts. On the other hand, transmission rate was calculated by dividing the number of positive saliva by the number of infected salivary glands. Kolmogorov-Smirnov tests indicated that the data did not conform to conditions of normality, hence non-parametric analyses were performed. Kruskal-Wallis tests were used to determine differences in viral titres in midguts and salivary glands between days post-infection. When a significant difference was detected, Mann-Whitney U-tests were performed to determine which day differed. All analyses were performed in Minitab.
From day 3-pi onwards, when blood had been completely digested, all midguts were positive for ZIKV, except for day 7- and 10-pi ( Table 1 ). The presence of viable ZIKV in the salivary glands was first observed on day 3-pi in three mosquitoes. By day 5-pi, half of the mosquitoes sampled showed disseminated infection. From day 7-pi onwards, all mosquitoes were found to have ZIKV in their salivary glands ( Table 1 ).
| Days post- infection | Infection rate | Dissemination rate | Transmission rate | |||
| No. positive MG (number sampled) | Percent | No. positive SG (number sampled) | Percent | No. positive saliva (number sampled) | Percent | |
| 3 | 12 (12) | 100 | 3 (12) | 25 | 0 (3) | 0 |
| 4 | 12 (12) | 100 | 7 (12) | 58.3 | 1 (7) | 14.3 |
| 5 | 12 (12) | 100 | 6 (12) | 50 | 2 (6) | 33.3 |
| 6 | 12 (12) | 100 | 9 (12) | 75 | 4(9) | 44.4 |
| 7 | 11 (12) | 91.7 | 11(11) | 100 | 8 (11) | 72.7 |
| 10 | 10 (12) | 83.3 | 10(10) | 100 | 10(10) | 100 |
| 14 | 12 (12) | 100 | 12(12) | 100 | 12(12) | 100 |
MG = midgut; SG = salivary gland.
Transmission was first observed on day 4 after the infectious blood meal and transmission rates were observed to increase at each sampling days. By day 10-pi onwards, ZIKV RNA was found in all saliva tested ( Table 1 ).
Figure 1 presents ZIKV midgut and salivary gland titres at different days pi. A significant difference in midgut ZIKV titres was observed between different days pi (Kruskal-Wallis test, P = 0.017). Midgut viral titres at days 3-, 4-, and 5-pi (>5.15 Log
Each box represents the median (horizontal bar), the interquartile range (box) and the full range (“whiskers”). Outliers are denoted by asterisk (*).
In contrast, increasing ZIKV titre was observed in the salivary glands of Ae. albopictus ( Figure 1b) (Kruskal-Wallis test, P<0.0001). Although the differences in ZIKV salivary gland titres from day 3-pi (2.54 Log
Emerging and re-emerging mosquito-borne diseases are considered to be major threats to global health in both developing and developed countries. Their tendency of spreading outside their known geographic range and causing large scale epidemics has been clearly demonstrated during the recent global epidemic of CHIKV [29] .
Zika is a neglected tropical disease, and like CHIKV, interest in ZIKV epidemiology was limited until recently, when its high epidemic potential was demonstrated during a large-scale outbreak in the Pacific Island of Yap in 2007 [10] , [11] , [13] , [30] . During the outbreak that lasted four months, more than 70% of the island's population was affected [11] . Like many vector-borne diseases, the absence of vaccines and specific treatment against ZIKV means prevention and control relies heavily on vector control. Therefore, key information such as the identity of the vector, its bionomics, distribution, and density are needed in order to develop and implement sound mosquito control program. To date, little is known about the vectors of ZIKV outside Africa, except for Ae. aegypti.
The overlapping geographic distribution of Ae. albopictus with that of ZIKV has stimulated our interest to determine the potential of this mosquito to transmit ZIKV. Furthermore, the widespread distribution of Ae. albopictus in Singapore and large-scale local outbreaks of chikungunya in 2008–09 attest to the country's vulnerability to emerging mosquito-borne diseases [31] . The potential of these diseases to be established locally is accentuated by the country's reputation as a popular commercial and tourist hub, high dependency on migrant workers, tropical climate, dense human population, and the presence of potential mosquito vectors. Recently, we have shown the potential for ZIKV outbreak in Singapore by Ae. aegypti [26] . The study showed local Ae. aegypti are highly susceptible to ZIKV, with a short extrinsic incubation period (EIP) of five days.
Our current study showed that Singapore's Ae albopictus mosquitoes are susceptible to ZIKV, with high dissemination and transmission rates observed. By day 4-pi, 58% ( n = 7/12) of the infected mosquitoes have disseminated infection and of these, three (43%) had ZIKV in their saliva. By day 7-pi, all infected mosquitoes are capable of transmitting the virus. A short EIP and high ZIKV salivary gland titres were also observed when we infect our local Ae. aegypti with ZIKV [26] . In that study, it took five and ten days post infectious blood meal to achieve a 62% and 100% dissemination rate, respectively. However, it does not mean that Ae. albopictus is more susceptible to ZIKV than Ae. aegypti, rather it could be due the amount of virus used to infect Ae. aegypti was lower (6.95 Log
Although Ae. albopictus has long been a suspected vector of ZIKV [32] , to our knowledge, this is the first report on the potential of this mosquito species to transmit ZIKV. However, further studies (such as entomological surveillance in endemic areas) are needed to validate our findings to ascertain the vectorial status of Ae. albopictus for ZIKV in nature especially when both Ae. Aegypti and Ae. albopictus are geographically sympatric. Nonetheless, data from our previous [26] and current studies suggest that both Ae. aegypti and Ae. albopictus will have significant roles in the transmission of ZIKV, should the virus be introduced in Singapore or in places where these mosquitoes abound. Recent phylogenetic analysis has identified two major lineages of ZIKV, an African and Asian lineage [17] . The strain used in our current study is the prototype MR766 Ugandan strain belonging to the former lineage. It will also be very interesting to study the strains belonging to the Asian lineage; unfortunately, at the time of the study, we only had access to the prototype strain.
Given the vulnerability of Singapore to ZIKV and presence of the virus in neighbouring countries, the Environmental Health Institute screened febrile cases not attributable to DENV and CHIKV for ZIKV and other arboviruses. To date, none was found positive for arboviruses other than DENV and CHIKV. Based on the information gathered from this study, the threat of ZIKV can be addressed by existing dengue and chikungunya control program being implemented in Singapore.
We thank Dr. Elizabeth McGraw (Monash University) and our colleague Dr. Chanditha Hapuarachchi for their critical reading of this article.


NetEase, Inc. 2019 Q3 - Results - Earnings Call Presentation
by SA Transcripts, https://seekingalpha.com/author/sa-transcriptsThe following slide deck was published by NetEase, Inc. in conjunction with their 2019 Q3 earnings call.
The following slide deck was published by NetEase, Inc. in conjunction with their 2019 Q3 earnings call.


There is only one difference between a local and a remote repository: remote repositories don't usually have a work tree (what you would consider the source files). They are usually bare, meaning that they only contain the contents of the .git
folder; Git's sophisticated, content-addressable storage (CAS) system. In every other respect, local and remote repositories are absolutely equivalent. Remote repositories just have to be more accessible.
The specifics of where / what you need and want strongly depend on your development environment and OS, so I won't get into that at this point. We'll continue under the assumption of a minimalistic setup.
GitInstallDir/etc/gitconfig
$HOME/.gitconfig
RepoDir/.git/config
$ git config --get <section.name>
$ git config [--system|--global] <section.name> <value>
user
settings
[user]
name = "Test Osteron"
email =<EMAIL_ADDRESS>[push]
default = simple
[color]
diff = auto
status = auto
branch = auto
$ git init [--bare] [directory]
$ git status
$ git add [--patch] [--all] [filepattern]
$ git commit [-a | --interactive] [--amend] [-m <msg>]
$ git help
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
...
$ git help -a
available git commands in 'git-core'
add help remote
add--interactive http-backend remote-ext
am http-fetch remote-fd
annotate http-push remote-ftp
...
$ git help add
Launching default browser to display HTML ...***
git cat-file (-p|-s|-t) <hash>
By inspecting this repository (i.e. the repository where this presentation was created we can take a closer look at the Git objects.
We'll start by picking a commit from the log:
$ git log
commit 1a83e1988ae9ce177820ec37629a611e2efbac32
Author: Developer Name
Date: Thu Sep 20 13:53:54 2012 +0200
- slide on git object trees
...
$ git cat-file -p 1a83e1988ae9ce177820ec37629a611e2efbac32
tree 37e7605cc1c8c617ff92329fb7da06aa109826ab
parent 6b34c3f78b04e6047478fa8e052af9f91adcdfdf
author Lukas Angerer<PHONE_NUMBER> +0200
committer Lukas Angerer<PHONE_NUMBER> +0200
slide on git object trees
A tree essentially lists the contents of a file system directory. It points to other trees (subdirectories) and blobs (files)
$ git cat-file -p 37e7605cc1c8c617ff92329fb7da06aa109826ab
100644 blob ffea9104896cdd08a3b4b93802acada0e8f3643e .gitmodules
040000 tree 1072f131a4704078a1182dce8543f41f30708296 css
040000 tree 8d8e9a2d55857fdcf23485dda2bc7c9dedcbbf78 images
040000 tree e48d2082cf799d3b3eea3db981f36dd893ecf290 lib
100644 blob 3805543c6ecd09736f17e5b47c63d64c5996cd82 presentation.html
$ git cat-file -p 8d8e9a2d55857fdcf23485dda2bc7c9dedcbbf78
100644 blob 224d64730fb2419f3940c00429cd6910abf3839c git-add-help.png
100644 blob 2cd4184fdd801c1ab9c86851f3d1b9ebce1c667f object-tree.dia
100644 blob a4d6512000a13cd38bb793fa9ef847e5d6814cae object-tree.svg
100644 blob e92e46164fd13f9294201f8f46a6871a3c8928c7 posh-git.png
100644 blob 944e4583e6a6bed3b1033d53c6d3d332f142b3a7 semi-centralized-git.dia
100644 blob 628ed9c436d707feb72ccc7f5a7e9661813fed03 semi-centralized-git.svg
100644 blob f6f3c76619ea4748260287b86c9c890862475d54 three-way-git.dia
100644 blob 5394d9a1a414d142caf504a2dfbd5e79cfacf973 three-way-git.svg
Blobs contain raw file contents (binary, text, whatever). Here, we take a look at the "object-tree.dia" file:
$ git cat-file -p 2cd4184fdd801c1ab9c86851f3d1b9ebce1c667f
<?xml version="1.0" encoding="UTF-8"?>
<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
<dia:diagramdata>
<dia:attribute name="background">
<dia:color val="#ffffff"/>
</dia:attribute>
<dia:attribute name="pagebreak">
<dia:color val="#000099"/>
</dia:attribute>
<dia:attribute name="paper">
<dia:composite type="paper">
<dia:attribute name="name">
<dia:string>#A4#</dia:string>
</dia:attribute>
...
Now that we have a basic understanding of what happens under the hood, we can take another look at the commands from the basic example
$ git status
$ git diff [--cached]
$ git diff <blob> <blob>
$ git add [--patch|--all|--interactive] [filepattern]
$ git commit [-a | --interactive] [--amend] [-m <msg>]
$ git branch <branch>
$ git checkout <branch>
You can also directly create a new branch and switch to it with
$ git checkout -b <branch>
$ git branch -m [<oldbranch>] <newbranch>
$ git branch -d <branch>
if you want to discard all unmerged changes from that branch
$ git branch -D <branch>
When talking about branches it is helpful to visualize them. There is a standard notation that is used in those circumstances:
An example branch/commit history would then look like this:
$ git log --graph
dae86e1950b1277e545cee180551750029cfe735
or dae86e
master
or heads/feature/X
HEAD
(current branch head), FETCH_HEAD
(current remote
tracking branch head), ORIG_HEAD
(base of current pending changes), ...
HEAD^1
(immediate parent of HEAD), HEAD^2
(grandfather of HEAD)$ git checkout master
$ git merge [--no-commit] [--no-ff] source
$ git mergetool
or merge manually in any editor$ git commit
$ git pull [<remote> [<remote-branch>[:<local-branch>]]]
$ git fetch [<remote> [<remote-branch>]]
which updates the remote tracking branch and
$ git merge origin/<remote-branch>
which merges the remote tracking branch into the current branch
$ git push [<remote> [<local-branch>[:<remote-branch>]]]


My Team
Manager Man
Manager
ID: 1
Email:
<EMAIL_ADDRESS>Office Number: 56
Engineer Eng
Engineer
ID: 2
Email:
<EMAIL_ADDRESS>GitHub:
engineerHub
Intern Int
Intern
ID: 3
Email:
<EMAIL_ADDRESS>School: UC Berkeley


Salmon Cookies
The pleasure of finding the difference
Sales page
This is our New resturant
U R Most Welcome
Fantastic Place And Food , You will Be happy with your family


About me:
Hello 👋 ! I believe, after looking at the top (Hero) image, You might notice about me and my background and my area of interests. Yes! your guess is true. I have an Interest in articulating my ideas into Conceptual Drawing as well as a strong background in Electronics and Communication Engineering graduate as a problem solver turned me into a UX Designer.
I have learned UX design skills and methods through Coursera.org and Bellevue College. While learning these courses I have applied UX design skills and methods to work on various projects and gain hands-on experience.
Over 2 years of experience on working with the various UX Design projects with startup companies, Non profit Organizations and Bellevue College. I got a chance to learn about the UX Design skills and methods briefly and applied those skills to design from scratch to fully developed prototypes (solutions) for various digital devices. Although as a Lead UX Designer, I have been closely monitoring other designers to guide and assign tasks to complete them by dedicated deadlines. As well as worked on different side projects to fulfill the requirements of the main UX Design projects.
Abilities & Responsibilities
UX Design skills
User Research: User interviews, surveys, market analysis, competitive analysis, User test, Design Features
Analysis: User personas, storyboarding, sketching, user flow, information architecture, User scenarios
Visual Design: Color palette, typography, iconography, pattern library, hierarchy of elements, mood board
Design: Wire-framing, Low fidelity prototype, high fidelity prototype
Tools
Wireframing tools: Pen & paper, Balsamiq
Prototype tools:Adobe Suite, Figma, Sketch, invision App,Marvel app
Coding Skills:HTML &CSS
Work documents: Microsoft office, google suite,
Communicating tools: Skype, Zoom, Google Meet, Slack, Discord
Leadership Skills
Lead multiple internal projects.
Identify the area of the projects needed to work on and assign tasks to teammates.
Prepare weekly meeting agenda,lead team meetings to discuss the project progress and every teammate's assignments and provide feedback and suggestions on their assignments to help them for better improvements on their work.
Mentoring 2 designers to work on their projects and conduct weekly one on one to provide continuous feedback on their work and guide them in the right direction to make progress on their projects and complete them successfully within the dedicated deadlines.
Conducting weekly design workshops with remaining UX Design teammates to brainstorm on the existing projects to come up with better solutions for our website design.


{{ paper.abstract }}
JIF: {{ paper.JIF }}
{{ resultsCount }}
RESULTS
No results found for {{ request.GET.q }}.
Ensure words are spelled correctly.
Try rephrasing keywords or using synonyms.
Try less specific keywords.
Make your queries as concise as possible.
Get additional search tips by visiting Web Search Help.
If you cannot find a page that you know exists, send the address to us.
{% include "../login-modal.html" %}